This post originated from an RSS feed registered with Ruby Buzz
by Andrew Montgomery.
Original Post: Testing Rocks
Feed Title: Dark Liquid - Ruby
Feed URL: http://feeds.feedburner.com/DarkLiquid-Ruby
Feed Description: Ruby and Rails related ramblings by Andrew Montgomery
Well, recently I embraced unit testing. Over the last year I���ve been so busy, with such tight deadlines, often working on existing software (which had no testing framework already setup for it), that I just haven���t had the time. Or, more accurately, I was afraid that taking the time to learn test driven development and using the test framework would take longer than just getting the stuff done so I wouldn���t meet the deadline.
As it turns out, my fears were completely unfounded.
A little while ago we took the plunge and made the commitment to develop something test first. It was slow for the first day. Learning the way tests actually work, and what not, and how to think about what we wanted the code to do - completely - instead of writing it to fit what we wanted as we go was what took up most of the time, but after that, things progressed quickly.
We write the code we wanted to be able to write in our app in the tests, and then wrote the code to make the tests pass. As we developed further, we had to check that our outputs made sense given different inputs. We came across errors as we changed things, but the tests told us where everything was going wrong and we fixed it.
Later on, we reshuffled all our behind the scenes code to tidy it up and DRY out somethings, testing kept us aware of weird issues.
Things went really quickly, and before long our entire things was tested well and finished. We had worked out how to test class method DSLs, private methods and all sorts and quickly. Now we have a fully tested, working library that we can reuse in various apps.
Due to the nature of our library, we made use of FakeWeb, which helped speed up our tests no end. As we develop our tests and testing abilities, we���ll have to look into things like RCov so we can ensure full test coverage and the like.
In the end, testing turned out a hell of a lot easier than I thought it would be, and now we are ahead of schedule in fact for completing our library, which kicks some serious ass. If you are reticent about picking up TDD because you think it will slow down your existing workflow learning how to do it, don���t worry. You���ll find that after a short while it becomes second nature and in fact speeds up your develop no end because you can trust your own code a lot more. However, I wouldn���t recommend starting TDD on an existing, already well-developed codebase because retroactively writing tests sucks and makes the whole idea of testing seem laborious and slow. Of course, getting that done will help you do any future development test-first, but if you are just starting out with TDD you���ll find it easiest with a new project than an existing one.
Eventually I���ll have to take the time to retroactively test my old code for various old projects still being maintained, but I���m dreading it because of the sheer amount of work involved, but it will be nice to be able to pick up things I���ve not handled to make my older code more robust.
Previous Topic
