Home arrow Ruby-on-Rails arrow Author Management for an Online Bookstore

Author Management for an Online Bookstore

In a recent series of articles, you learned how to set up a proof of concept for an online bookstore created using Ruby-on-Rails. In this four-part article series, you'll start creating the application for real, using test-driven development. This article is excerpted from chapter two of the book Practical Rails Projects, written by Eldon Alameda (Apress; ISBN: 1590597818).

Author Info:
By: Apress Publishing
Rating: 5 stars5 stars5 stars5 stars5 stars / 1
May 07, 2010
  1. · Author Management for an Online Bookstore
  2. · Testing in Rails
  3. · Creating the ActiveRecord Model
  4. · Editing the Migration File

print this article

Author Management for an Online Bookstore
(Page 1 of 4 )

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_

  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.

blog comments powered by Disqus

- Ruby-on-Rails Faces Second Security Flaw in ...
- Ruby 2.0 Prepped for February 2013 Release
- Why LinkedIn Switched from Ruby on Rails
- Adding Style with Action Pack
- Handling HTML in Templates with Action Pack
- Filters, Controllers and Helpers in Action P...
- Action Pack and Controller Filters
- Action Pack Categories and Events
- Logging Out, Events and Templates with Actio...
- Action Pack Sessions and Architecture
- More on Action Pack Partial Templates
- Action Pack Partial Templates
- Displaying Error Messages with the Action Pa...
- Action Pack Request Parameters
- Creating an Action Pack Registration Form

Watch our Tech Videos 
Dev Articles Forums 
 RSS  Articles
 RSS  Forums
 RSS  All Feeds
Write For Us 
Weekly Newsletter
Developer Updates  
Free Website Content 
Contact Us 
Site Map 
Privacy Policy 

Developer Shed Affiliates


© 2003-2019 by Developer Shed. All rights reserved. DS Cluster - Follow our Sitemap
Popular Web Development Topics
All Web Development Tutorials