Author Management for an Online Bookstore

In this chapter, we start building the online bookstore for George for real. We first explain test-driven development (TDD), why we should use it, and how we can use it with Rails. We also describe the testing schemes that exist in Rails. After the introduction to TDD, we dive into our first sprint, implementing the author management system for our application. This is the first part of the administration interface to our bookstore application, to allow handling creating, reading, updating, and deleting of book authors (often referred to as CRUD capabilities). After completing this chapter, you should be able to use TDD to make a simple application in Rails.

Using Test-Driven Development

Software testing means using quality-assurance metrics to make sure the software works as it should. There are basically two ways to test software: manual testing, with dedicated test engineers banging the heck out of the software, and automated testing. While manual testing is needed in parts of the software that are hard to test programmatically (mainly the user interface), the bulk of testing can be done automatically. Automated testing is much faster and repeatable, and thus more systematic and less error-prone than testing everything manually.

While Ruby on Rails makes it easy to write automated tests for your application, we’ll take this one step further and write our application test-driven. TDD starts from so-called user stories. One user story could be “George logs in to the system and adds a new author.” After we have a user story, we have enough information to write a test. In our example, we could test that the login works and a new author is really created when George uses the application.

The real meat of TDD is that the actual code is written only after you have created the test for a user story, using the following process (fromhttp://wiki.marklunds.com/index.php?title=Test_Driven_Development_with_Ruby#What_
is_Test_Driven_Development_.28TDD.29.3F):

1. Write a test that specifies a bit of functionality.
   
2. Ensure the test fails. (You haven’t built the functionality yet!) 
    
3. Write only the code necessary to make the test pass. 
    
4. Refactor the code, ensuring that it has the simplest design possible for the functionality built to date.

You read that correctly. No real code is written until you have a failing test in place to test the story at hand.

So what do we get from developing our application using TDD? First and foremost, when our tests pass without errors or failures, we can be certain that our application works just as we want it to—given that we wrote our tests well. Instead of throwing our application over the wall to George, crossing our fingers, and hoping that it won’t explode, we can sleep well at night, knowing everything will go fine during that first demo.

But there is also another very important reason for TDD. As we try to be as agile as possible, we also want to obey one of the golden rules of Rails and 37signals: “Write less software.” When we create the tests first and implement the functionality after that, writing the code has a clear goal: to implement the user story and make the tests pass. It is a lot easier to write only the code needed when you have a clear target than it is to first write the code and then start writing tests afterwards to test functionality you’ve already implemented.