w5d1 - The Chupacabra

Week 5 has begun and interestingly it seems to have started off a bit slow. We spent the day in pairs writing another web app. This time it was a goal tracking app. The purpose of it was for users to be able to sign up and enter goals for themselves. These goals could be public or private, and other users on the site could go to another users page and see a list of their public goals. Obviously, private goals were only visible to the owner. In addition, users could comment on other user’s goals, or on the actual user’s page. This gave us a chance to use polymorphic associations in conjunction with “concerns” to keep our code DRY.

This was all pretty straightforward after everything we worked on last week, but the twist was that we had to do it by implementing TDD: Test Driven Development. This means that instead of jumping right into coding the app, we had to write tests that described how our application should behave. The idea is that you write a test (or small series of tests, depending on how strictly you are adhering to TDD), then run the tests (which should all fail, typically shown in Red). Once the tests fail, you write the code to make your tests pass (typically shown in Green). Once you have passing tests, you can go back and optimize your code, running the tests as you go to make sure everything still works properly. This cycle is known as “Red, Green, Refactor.”

This was only the second time we’ve had to write our own tests, and this time we had to do it for a much more complex application. However, I found that it was a lot easier this time around, as the testing felt a lot more natural. Maybe it’s because we are that much better than we were when we first saw it. Maybe it’s because the suite we used, Capybara (or as I like to call it: Chupacabra), made Rspec easier to understand. Maybe it’s because we were doing integration testing rather than unit testing (testing functionality of the app rather than testing the implementation of specific pieces). It’s probably a combination of all of those, but it certainly wasn’t as bad as I thought it was going to be.

In some ways it made the development process easier, since our decisions about what to build next were always driven by the tests we wrote, which were themselves driven by the process of someone just using the app. What would they do? Where would they click? What should they be allowed to see and do? What shouldn’t they be allowed to see and do? When approached from this way, it forces you to break the process down into small pieces, which makes the whole thing easier to manage. Also, the fact that you have reliable tests for your app’s functionality gives you more confidence to make changes without fear of breaking something you hadn’t thought of. Of course, all of this means that the development process tends to be slower, and that can be frustrating when you feel like you already know what needs to be done. Also, you have to make sure you’re testing the right things and that your tests are written correctly, otherwise you may end up falsely relying on tests that don’t tell you what you might be missing.

Whether you love it or hate it, it seems like TDD is here to stay. You can’t escape the Chupacabra!