I’ve ignored Rails Tests for too long. In fact, I’ve skipped over Test chapter in Agile Web Development with Rails in both the first and second editions. After fighting with the same bug over and over again, I knew now was the time for tests.
On the surface, tests seemed very un-DRY1 – like I’m writing the code twice – once to make it work and again to make sure it works. Rails is so good at minimizing dupliation and using scripts to generate things that might be duplicated – shouldn’t the generation of tests be auto-generated2. Plus, if I’m continually refactoring code and I have a test for each method – feels like I’d be continually rewriting the test. Argh. I’m too lazy for that.
This morning as Ben helped me fix a previously hidden bugs via a single functional test3 he framed tests in a way that finally clicked: Tests are requirements.
Also known as the Test Driven Development approach and it’s attractive for a number of reasons:
- Eliminiates separate, external, no fun, and less DRY, documentation
- Encourages tests to be written early and in English
- Puts the focus on refactoring the code, not keeping the tests synchronized.
1. Don’t Repeat Yourself, a core programming principle from early Ruby advocates.
2. I know they are when using the scaffolding. I haven’t found scaffolding to be useful for anything other than Wow-ing people in screencasts.
3. We didn’t even need to run the test to identify and fix the bug. But we did. Passed.