My Journey into Test Driven Development
If you wonder about Unit Testing and Test Driven Development, but are afraid of commitment, do yourself a favour, read Terrance Ryan's thoughts on "How to convince yourself to Unit Test". A couple of months ago, I made a commitment to start unit testing. I'll admit that it took a little while to wrap my head around the terminology and process. A good practice point for me was to run some of my first CFCs though Seth Petry-Johnson's var scope checker. When I discovered a plethora of un-scoped vars, I used the opportunity to write tests against the methods I was going to change. After only a few tests, I started to get this warm feeling of security. By the time my updates and tests were complete, I had a nice little suite that I could return to any time a change was required.
Long story short (beware... plug alert!): mxunit came about as a way to make unit testing simpler, and one of the things we put in there fairly early was a facility for seeing your data. cfdump, cfoutput, cfcatch. whatever. no more one-off throwaway scripts, etc. It saves me a ton of time!
One other thing unrelated to frameworks at all... this notion of a test harness. I ran across something a little bit ago, a really nice image from a book called "Test Driven". Its focus is java testing but the concepts are the same. Anyway, the author's image of a test harness is one of a fat inner circle and a thin outer circle. the outer circle is test test harness. the inner circle is your application. thus the test harness keeps your app together. And when you break your harness (your tests aren't updated, you leave big chunks untested, etc), the application can "leak" out and get all nasty. I liked the metaphor because it was a good way for me to digest the concept. You mentioned that it's a more advanced concept related to automation. You know what I do? I set up a scheduled task in CFAdmin that runs a run.cfm file. run.cfm is about 10 lines of code. it runs a directory of tests then emails me. nothing fancy! if you're into ant, you can really do some cool things with a combination of a few simple ant tasks. I think at least to start, most shops don't need a full blown fancy continuous integration server with oodles of metrics and reports and whatnot. an email at noon that says "100 tests passed, but these 3 failed" is often just enough to keep you honest.
Thanks for the great post! I love these posts (like yours and terrence's and sam larbi's recent one) that make unit testing seem so much more accessible than it has seemed in the past... at least to me. I feel like it's always been one of those "you should do it... like you should exercise, and eat brussel sprouts, and take robitussin" kind of things. Very daunting and enterprisey and all that but not for regular folks. But not anymore.
@Marc: I know what you mean about unit testing being "daunting and enterprisey and all that", especially at the beginning. The good thing is that (In my experience, anyway), automated testing is one of those things where even an incomplete solution is a huge improvement over no solution at all!
@Seth, Thanks for building an awesome tool! It helped me get into the write a little, test a little frame of mind so I could fix un-scoped vars and test the changes immediately to ensure I wasn't breaking anything.