Tests are and should be the backbone of an application. Rails comes with a test suite when generating a new application. This encourages Test Driven Development  now Behavior Driven Development. Writing tests may sound cumbersome but if it is embraced as a part of the project life cycle like we do here in Rubysoftware — we have a portion of the development set aside to ensure writing solid tests, the absence of tests deems a project as incomplete.

When there is a client requirement, in an agile environment the business analyst will jot down a story going back and forth with the client on the specifics of the requirement which may include user clicks and user navigation to the minu-test detail. These stories are a life saver to a professional programmer as it enables him/her to come up with test cases and in modern terminology “specs” which in turn helps coming up good code designs and in turn applications with fewwer bugs and better performance.

Let’s say our client wants a login page that is to positioned at the top right of the navigation bar and a “submit” button which when clicked processes the entered details. When it comes to writing it as a story, it brings in a behavior aspect to the feature when it is written in the format:

When a user visits a certain page, the user should see a place at the top right of the screen for entering username/password details

Then the user enters the username and password

Then the user is taken to the index listing page

This is a clean slate for writing up specs. There are so many stories that arise from this single story, in terms of what would happen if the username was not entered, what would happen if the password was omitted, what are the error messages or warnings the user should see. Everything will be crystal clear to the programmer who will be in sync with the client and his/her requirements.

The next step would be to write testcases for the requirement. This encourages healthy thinking about the all possible scenarios that could go wrong with the new addition. It encourages developers to ensure all sides of the feature are accounted for. The next obvious thing to do is to write the code to satisfy the testcases. Now is where the “red green refactor” idiom comes in. This purges the code and ensures tests for all aspects of the feature and now the feature is ready to be showcased to the client.