Day of Ruby (Part 2)
May 19th, 2009This contains only the first iteration of the hand-ons learning session based on my notes from Cory’s presentation and additional information from Tom S. who was sitting next to me sprinkled with my opinion. There was much more mentioned in the session. Bear in mind that this is new person’s perspective using Rails and Cucumber. So, take what I write here with a grain of salt.
The development cycle that I am accustomed to consists of the following steps.
- Requirements
- Design
- Code
- Test
Coding and test steps are a repetitive cycle for me. I have a tendency to code in bite sized pieces and test each step.
However, the development cycle introduced at this event reverses two steps.
- Requirements (Create user stories.)
- Test
- Code
The concept of creating unit tests prior to coding is something that I do not practice as most of the emphasis is focused on performing work (coding) and then ensuring what I wrote works correctly, accounting for things that the user might do, some of which I don’t find until later.
Cucumber creates tests for RSpec and RSpec in turn creates code level based tests. This is a new concept to me as I see the first feature displayed on the projector:
Note: I’m omitting installing the rails app and gems required for running Cucumber.
File: features/view_tasks.feature
Features: View Tasks So I can see at a glance As a person with the things to do I want to see a list of my tasks Scenario: Add Task to List Given a task called "Take out the trash" When I browse the tasks page Then I should see "Take out the trash"
The awkward wording says that I should be able to view a list of tasks. The test scenario: If I create a task then I should see it on the task list. Adding more features with the words “Take out the trash,” a placeholder for a task, become quite redundant. This can be addressed in something called background stories.
The following command processed the features.
script/generate features/
Running the command on my home computer does not work. At the session Cory provided a zip file provided containing a plugin directory which permitted the above command to run.
Following this GIT Hub wiki article, when not using the plugin the following commands must be run:
rake db:migrate
rake features
After the database is created the first time, running rake features will suffice. This was mentioned on Saturday.
rake features outputs the following RSpec code:
Given /^a task called "([^\"]*)"$/ do |arg1| pending end When /^I browse the tasks page$/ do pending end
Now, this were I work backwards and proceed to code, replacing the word pending with what I the web application to do.
File: features/step_definitions/tasks.rb
Given /^a task called "([^\"]*)"$/ do |task_name| # Create a task record in the database @task = Task.create!(:name => task_name) end When /^I browse the tasks page$/ do visit tasks_path # simulates web browser end
Running rake features generates the following error:
uninitialized constant Task (NameError)
./features/step_definitions/tasks.rb:2:in `/^a task called "([^\"]*)"$/'
features/view_tasks.feature:9:in `Given a task called "Take out the trash"'
In my opinion, these errors are somewhat difficult to figure out. I suppose it becomes easier once you have more practice with it. The above error wants a tasks table in a database with an attribute name of type string. The following command will produce code for creating a prefabricated web UI and the migration code for creating the database table.
script/generate scaffold task name:string
Apply the database change.
rake db:migrate
Test the feature:
rake feature
This outputs:
1 scenario (1 passed)
3 steps (3 passed)
Start the web-server.
script/server
Browse to http://localhost:3000/tasks
We see an empty to do list. Let’s add something.
Yes, I will write that next.
Your accustomed development cycle looks like what many authors call the Incremental Model with a focus on unit testing which covers most aspects of verification which test whether the product is built right. The development cycle presented at the event (2 steps reversed) looks like a description of what an ITG (Independent Test Group) would be using, i.e. developing the test cases from requirements and preparing to perform product validation which test whether the right product is being built.