Articles

Test Your Max Software Like We Do

Visit our Github page to download or fork the Max-Test package.

It takes a special kind of nerd to appreciate certain aspects of software development. So it is with frameworks and methodologies for structured software testing. But really, who doesn't want their Max systems to be more reliable, easier to change, and easier to maintain?

The max-test package is one tool in our quiver that helps to achieve these goals, and now we get to share it with the world. This package makes it possible for mere mortals to approach the topic of structured and/or automated testing by creating patchers. There is no need for arcane or complex programming. Just make a patcher and decorate it with a few new objects.

A test patcher is a declaration of what you expect Max to do. When you open the patcher it is immediately obvious what the expectations are, and if the expectations are met. That makes a test patcher a powerful way to communicate with each other. As an engineer working on the software, if a bug comes to me in test patcher form I am likely to solve the problem much more quickly than if I receive the report in any other form.

One success story is the Jamoma project. The Jamoma project has been using automated testing with Max patchers for several years and even published academic papers about the process. Having a thorough suite of tests in target areas has allowed for radical changes to be made while knowing that nothing has been accidentally broken in the process.

You can get the max-test package from Github

by Timothy Place on May 15, 2015

Creative Commons License
do.while's icon

A very handy suite . Thank you Cycling !

Lee's icon

looking forward to checking this out!!

Diemo Schwarz's icon

Thanks, Tim, this is great! Maybe there could be a paragraph in the readme about where and how to install (in case one missed it in the video), and what to do when the ruby script hangs with 'Sending ping to Max.'
Cheers!

Diemo Schwarz's icon

Delving deeper, I find this enthralling remark in oscar's source readme:

* There is also a default set, which tries to spam any given object with all kinds of messages to try and make it crash or mis-behave under the stress. This default set is inspired by the auval program Apple provides for AudioUnits.

Does this mean, we could do such a stability test on any third-party object? If yes, could you please give an example how to kick this off?

Diemo Schwarz's icon

Hi again, Tim!

I wrote my first test patcher (and sql scripts to get at results), and the test rig looks really promising.

One annoyance is that all test patchers have to auto-close themselves, leading to stressful keyboard virtuosity trying to hit cmd-shift right after cmd-o to defeat the loadbang that'll close the patcher immediately.
Couldn't the test.terminate determine if it is running under automation, and otherwise not close the patcher?

Best...
...Diemo

Diemo Schwarz's icon

Been trying to run tests under Max 8 but get this:
sqlite_exec: 1 (no such table: objects)
sqlite_exec_query: SELECT DISTINCT name FROM objects JOIN files ON objects.file_id_ext = files.file_id JOIN roles ON objects.role_id_ext = roles.role_id WHERE ((( role_id_ext IN (SELECT role_id FROM roles WHERE rolename = 'patcher' OR rolename = 'project') AND (validity > 0) OR flags & 2))) AND name LIKE '%.maxtest'

Iain Duncan's icon

Oh awesome, I'm all over this. Thanks Tim!