A Head-First Guide to RocketUnit

1. Checkout from SVN or  download and unzip RocketUnit into your web root*. This will create two folders, /com and /test.
2. Browse {your site}/com/rocketboots/rocketunit/rocketunittests/testRocketUnit.cfm to confirm that RocketUnit is installed.
3. Browse {your site}/test/com/rocketboots/sample/ to see the sample test case output. Note the verbose explanation when the test fails.
4. Open /test/com/rocketboots/sample/index.cfm to see how the test was invoked.
5. Open /test/com/rocketboots/sample/TestSample.cfc to see what a RocketUnit test case looks like. There are plenty of comments to explain what is going on. Note that all the test cases use either assert() or fail() to record test results.
6. Read the header comments in /com/rocketboots/rocketunit/Test.cfc for a more general usage guide.
7. To make your own test case, copy index.cfm and TestSample.cfc to use as a starting point. Here's a simple checklist for the tests you might want to create:

• Normal processing - typical inputs produce expected outputs (for each method if testing a cfc).
• Boundary processing - if there are loops in the code, what happens if you pass empty or very large arrays, queries or collections as input?
• Abnormal processing - does the code being tested detect invalid or missing arguments and throw the appropriate exceptions or use the correct defaults?

8. Note that you can create your test cases before you create your code if you like - all that will happen is that you'll get failures or errors coming up in the report. The objective of subsequent development then becomes to make the test cases pass successfully. This is called Test Driven Development and is widely regarded as a Good Thing. That said it's also a good idea to create test cases for legacy code, particularly if you're about to embark on some refactoring fixes and you want to make sure you aren't breaking anything.
9. When you discover a bug in your code, the first thing to do is write a test case that reproduces the bug. Then you fix the bug and check to see the test passes. In this way you make sure that no-one can reintroduce the bug without causing a test to fail.
10. If you want to watch your test results while you code, add a <meta http-equiv="refresh" content="5"> to your test index page head block and open it in a browser, ideally the one built in to CFEclipse. While you code you'll get an update of what tests are passing every few seconds.

* To make it easy for you to deploy RocketUnit the instructions say to expand it in the webroot, taking advantage of the implicit "/" cf mapping that points to the webroot. We normally keep our code in packages outside the webroot. Feel free to rearrange the code under CF mappings - as long as com.rocketboots.* and test.com.rocketboots.* are mapped the code will work - just copy the index.cfm files to somewhere you can browse.

It is a standard practice to keep your test cases in a package structure starting with "test", which then shadows the original package structure of the software being tested - however you do not need to follow this practice for RocketUnit to work.