Spring is in the air all around Boston and it just begs the question, “Why not write more acceptance tests for your projects?” As the crocuses come up, they are new to the world, just as I am new to the world of programming. Thus, in order to stop them wreaking havoc on everything, you need to put tests in place that stop them from growing into some monstrosity.

In fact, Outside-In development is a lot like having a shared garden space. A gardener could just go to town and plant everything that his or her heart desires early on in the season, but he or she needs to consider what flora will grow first, how big it will grow, how much space it will need, and the organization. Otherwise, the gardener will end up with a tangle of vines, some under-grown vegetables and some huge vegetables, and perhaps a handful of stunted flowers.

Test driven development sets goals from the start. The user stories and acceptance criteria on the outside of the circle come first, allowing the developer to decide what it is that he or she wants to make. It is sort of like plotting off the various parts of the garden to different types of vegetation — parts of it to flowers and parts to vegetables, etc. Wireframing is visualization method that should be done to see what the site will look like. After that, the acceptance tests are written. These tests will check that your application actually works. Let’s say that an acceptance criterion said something like “I want to be able to login”; then the acceptance test should check whether a user can login. There are lots of tools that can be used for the tests, and it makes it ridiculously easy in some ways, especially Capybara (not capybara).

Unit tests are more honed in on one aspect of the program. They check all of the associations and whether the behaviour and design is as it should be. Being meticulous here is very important, since it is the details of your site that can often be the most enjoyable, or the biggest headache.

Now that I’ve gotten the hang of some of the tools, and have an idea of what is going on “under the hood”, I think that outside in development becomes the drive that pushes a project forward, if implemented properly. Capybara, FactoryGirl, Shoulda, Valid Attribute…these tools all make it much easier to outside in develop. The best part of writing all of tests before I’ve even started programming is that I then know what to program. If I realize that something has been left out, I can add it, but most of the key application features are going to be there, written out, so that valuable brain power need not be wasted on thinking of what to do next. You can just put your head down and write code.