Unit test

Is there a one class unit test framework for Codea?

I don’t think anyone has written one, though I may be wrong.

Some people may not like hearing this, but the philosophy of Codea is not to write solid, stable code. It’s for writing messy, hacked-together code that quickly produces an interactive concept on the screen. At least that’s how I use it.

Hear, hear. Such philosophy is the bricoleur’s dream.

It’s much easier to hack together something that rests on a solid, stable base (e.g. a vec2 class that doesn’t crash Codea when used wrong! :stuck_out_tongue: ). I’m steadily building up a collection of classes – game controllers, animation, particles, collistion detection, font rendering, etc. – that makes it easy and fast for me to knock together games and animations. But I’d be happier if I was more confident that these worked correctly and I could work faster if I didn’t have to debug them – because let’s face it, debugging in Codea is a huge pain.

True, @Nat. Codea definitely shouldn’t be the bit that’s hacked together - does 1.1.2 have any further vec2 crashes? I thought I fixed them.

That wasn’t my point, just a cheap joke. Sorry.

What I mean is that Codea is just the lowest level of code that helps me write things very quickly. As I’ve worked with it, I’ve built up my own code that helps me write things faster and faster. But as soon as I hit a bug, my progress grinds to a halt. Codea has no debugging support except for manual testing with print statements (which are very slow and can scroll off the screen) and watches (which can change too fast). No breakpoints, conditional breaks, single stepping, etc.

I rarely use a debugger in other programming environments because I write automated tests for my code. But that’s not possible in Codea either at the moment.

I guess I could test my code outside Codea and then copy it in, but I usually program in Codea when commuting, away from my other computers, so for me it’s not practical.

I’d love like a “test” button that sat next to the “run” button and would call a test() function if it existed (and would be greyed out if it didn’t). Then I could write whatever I needed to test my foundation code.

I’ll be adding action parameters soon. Essentially these parameters that call a function and show up as a button in the parameter list, rather than a slider. Would this let you solve the “test” button issue?

The API would be

fparameter( "FunctionName" )

What other sorts of debugging features would you like to see?

Yes. That would work.