Peter Marklund's Home |
Rails Testing: Switching from Test::Unit to RSpec, What are the Advantages?
It's been a couple of months now since I switched from Rails built in Test::Unit framework to using RSpec and I've realized that RSpec has already brought some major advantages for me. Just to clarify, I still run all my old Test::Unit tests and I still write Test::Unit integration tests to complement my specs. The Rails testing framework and RSpec can run nicely side by side through the rake command. Here is what RSpec has given me:
- It has made me more spec/test driven. Now for the first time I mostly write the specs before I write the code. I've found that if I postpone writing tests the test coverage will suffer a lot. A lot of times the tests don't get written or I end up writing just the most rudimentary tests. Tests/specs need to be written while you are in the process of writing the code. That's when you have the domain logic loaded into your head. Push it off for a few days, or even just half a day, and you will need ramp up time to load the logic into your head again. A lot of times, there is no room for such ramp up time.
- Specs are more accepted and appreciated by clients than tests. I have clients who appreciate and really understand specs (in Word documents or PDFs) but are not in the tradition of test driven development. It makes more sense to them that I spend time writing specs, especially since I can show them the nice green HTML spec doc that RSpec generates. Clients who want to control and monitor the details of what you do will like your specs even more. Specs communicate better than tests.
- RSpec is syntactically nicer than Test::Unit and thus it reads better.
Another realization that has come to me lately, is that yes, regardless of what code you are writing TDD/BDD is a good idea. However, if you are writing any kind of API or framework that is to be reused across several applications, tests/specs and well defined interfaces are almost a necessity. If you don't have them, you might be better off opting for no reuse. Reuse is the holy grail of software development, and it's hard.