“unit testing is a test that validates that individual units of source code are working properly”, that’s what Wikipedia says about unit testing. That’s general knowledge.
But what motivates me even more than the increased software quality is that it saves me development time. This sounds odd as you might believe that TDD means writing more code.
Here’s a real-life example:
For our internal invoicing system I had the task of changing the way we generate invoice numbers. Instead of a global number range each tilllate Ltd. subsidiary should receive it’s own distinct number range. And all invoices must have subsequent numbers to be compliant with the legal regulations. Invoices are being generated by about 100 staffs via a web front end. So I wrote the classes InvoiceNumber and InvoiceNumberFactory.
Testing it manually: Boring!
Now, how do I test them? Without a unit test framework I would have had to test it via the web based front end:
- Create a test customer (= fill out a form with about 30 fields, click save, wait)
- Create a new order (= fill out two forms with each 10 fields, click save, wait)
- Create an invoice (= another form)
- Check if the generated invoice number is correct
- If not, delete all created db entries and start over again
My code would not have worked immediately. I would have had to go through the procedure above over and over again. Each iteration was 120 seconds of clicking and waiting. YAWN.
Speeding it up by automating the test
By using unit tests I was able to avoid this manual labor: I set up my test environment (1 – 3) programatically in my setUp method. I cleaned up everything (step 5) in the tearDown method of my test. To run the test I just called it via the shell:
pluto unit # php -f test_InvoiceNumber.php TestInvoiceNumber OK Test cases run: 1/1, Passes: 20, Failures: 0, Exceptions: 0
The whole set up, testing and tear down process was done programmatically. Time elapsed: 0.54 seconds.
Thats 240 times faster than the manual testing via the web front end.*
And definitely much more fun!
*sure, writing the test is not free. But in the bottom line I believe it save me time.
Yeah, but how long to write the test? 🙂
(not bashing unit testing, you just didn’t mention it, thats all)
the positives are clear, your test is 100% repeatable, whereas filling in the form manually is not 🙂
I think “fun” is pushing it a bit but it certainly makes it less boring.
@Mike: “more fun / less boring” is like “the glass is half full / half empty” 🙂
@Joe: You know, I am so fast writing those tests. The time it takes me to write them is negligible 😛
I definitely find TDD more fun.
When I’m writing the tests, I feel like a demanding guest at a restaurant, making the most obscure requests I can imagine. I try not to think about how the code will work but what I need it to do. I even try to forget that I’m going to have to write the code that passes the tests and imagine that a junior temp will have to make the program work.
Once the tests are in place, coding is also more fun. As the program is fleshed out you get a satisfaction like ticking the items of a list.
You’re also more free to experiment with different algorithms and so on so long as the code passes all the tests.
Pingback: | Webgedanken
How do you do the actual tests? You can test the different php functions, but there can still be errors in the html code (forms) which you wouldn’t find in your tests.
Did you create something on your own to test the actual websites (eg. with login etc…). How do you to these tests?
(The not so mysterious me ;))
@mysterious me: To test the form you need functional tests. Selenium would help you on that one.
Currently we are doing these manually as we have not found an efficient way to program them with Selenium (Selenium IDE did not help us much on that one due to a high cost for setting up the fixture and many special cases to cover). Maybe someone else has a clue?
… Without a unit test framework I would have had to test it via the web based front end …
Why? You can call class methods without UI. Simple cycle with different arguments suffices.
Good article, I’ve written a tool that illeviates the need for running the tests on the command line (making refactoring/coding even more fun!).
Basically it’s an ajax’d web application that automatically runs tests and caches their dependencies.
The beauty of the dependency cache is that when you change a source file, all of the tests associated with it are automatically re-run.
Tests can be written for files that do not exist, or contain fatal errors, etc.
Its available here: http://www.blerby.com/project/testrunner