Since I just posted a request, I thought it only fair to add some actual content as a balance.
I do a live show and I want a way to "sequence" an entire show and control it from my instrument without ever having to touch the mouse during the whole show. I wanted a way I could hook together sets from songs without having to build new max patches for each set. I wanted a much better way to manage all the many sounds I have from my instrument.
I wanted to share my experiences with doing "rapid development" this way and of course get feedback.
I don't think there was ever a point where I didn't expect to have to write tests, so I've been using some sort of hand-rolled, cheap unit test system since I started this. In code like this where I'm trying to bang out a lot of experimental stuff and make massive changes to the data structures all the time I simply have to have complete tests for everything - I have 45 tests right now.
I know rapid development and heavy unit testing seem to be contradictory, but I've banged around the data structures pretty hard by now in many different ways and for the last week or so I've been attempting to delete as many of them as possible and replace them with either lists or dictionaries (associative arrays).
And debugging is really hard... so might as well try to avoid it as much as possible!
Here's how it works.
I use the C preprocessor to put these together properly in exactly the same way you'd use include files in C (pretty simply if you don't know how that works).
So if my code is in command.js and includes other files, the preprocessor puts them together into a file called command.jso.
This is all accomplished with a simple Makefile and gcc.
There's a test subdirectory - with lots of JS test code and a tiny Max patch called tests.maxpat which just has a js box with tests.jso and a single message button "compile, test".
So how do I write non-trivial tests?
So I make heavy use of mocks, where I create a "fake" version of say this.patcher that I use for testing which has methods that record what happens to them. At the end of running the test, I can look at what commands the mock patcher had to execute, and see if they are what I want.
And you have no idea how many bugs I've found this way before I ever played a note!
Early on, I define: