CSC/ECE 517 Fall 2012/ch2a 2w31 up

SaaS - 5.3 - The TDD cycle: red-green-refactor<ref>Video :SaaS - 5.3 - The TDD cycle: red-green-refactor</ref>

Introduction

Test Driven Development(TDD) is an evolutionary approach to software development that requires a developer to write test code before the actual code and then write the minimum code to pass that test. This process is done iteratively to ensure that all units in the application are tested for optimum functionality, both individually and in synergy with others. This produces applications of high quality in less time.

BDD Vs TDD

Behavior driven development (BDD) is a software development process built on TDD. BDD helps to capture requirement as user stories both narrative and scenarios. "User stories in BDD are written with a rigid structure having a narrative that uses a Role/Benefit/Value grammar and scenarios that use a Given/When/Then grammar" <ref>TDD vs BDD </ref>. TDD helps to capture this behavior directly using test cases. Thus TDD captures low level requirements whereas BDD captures high level requirements.

Concepts

The following topics provide an overview of a few concepts which would be helpful in understanding the TDD cycle and its example better.

Seams

The concept of CWWWH(code we wish we had) is about a missing/buggy piece of code in TDD. In test driven development, we generally write a test and then the implement the functionality. But it may happen that the program which implements a certain feature, is dependent on some other feature which is not yet implemented or has errors. That piece of code is named as "CWWWH".
Given that scenario, a test case for such a functionality is expected to fail owing to the dependency. Nevertheless, the tests can be made to pass, with a concept called Seams, defined by Michael Feather's in his book Working Effectively With Legacy Code<ref>Working Effectively With Legacy Code by Michael Feather</ref>
A seam is a place where one can alter the application's behavior without editing the actual code. This helps us to isolate a code from its dependent counterpart. Thus, one can work with a given code, abstracting out the implementation of its dependency, and assuming it works right. This is explained clearly with an example below.

RSpec

RSpec<ref>RSpec</ref> is a great testing tool, which provides features like :

• textual descriptions of examples and groups (rspec-core)

• extension for Rails (rspec-rails)
  If we are testing a rails application specifically (as opposed to an arbitrary Ruby program), we need to be able to simulate
  * posting to a controller action
  * the ability to examine the expected view

• extensible expectation language (rspec-expectations), letting an user express expected outcomes of an object.
  Uses instance methods like "should" and "should_not" to check for equivalence, identity, regular expressions, etc.

[1,2,3].should include(1, 2)

• built-in mocking/stubbing framework (rspec-mocks):
  Rspec has built-in facility to setup mock methods or stub objects. There can be several dependencies of a method, that is tested. It is important to test(unit test) only a particular behavior and mock out the other methods that are called from there. Rspec provides "should_receive" clause which overwrites the foreign method implementation and makes sure that missing methods or buggy methods do not affect the current behavior that is tested.

obj.should_receive(a).with(b)

For any given object, we can set up an expectation that the object should receive a method call. In this case the method name is specified as "a" and it is called on object "obj". The method could be optionally called with an argument which is specified using "with". If arguments exist then two things are checked-- a) whether the method gets called b) whether correct arguments are passed. If arguments are absent then the second check is skipped.

Red – Green – Refactor

The following steps define the TDD cycle :

Add a Test

• Think about one thing the code should do : The developer identifies a new functionality from the use cases and user stories, which contain detailed requirements and constraints.
• Capture that thought in a test, which fails  : An automated test case (new or a variant of an existing test) is then written, corresponding to the new feature, taking into consideration all possible inputs, error conditions and outputs. Run all the automated tests. The new test inevitably fails because it is written prior to the implementation of the feature. This validates that the feature is rightly tested and would pass if the feature is implemented correctly, which drives a developer to the next step.

Implement the feature

• Write the simplest possible code that lets the test pass  : Minimal code is written to make the test pass. The entire functionality need not be implemented in this step. It is not uncommon to see empty methods or methods that simply return a constant value. The code can be improved in the next iterations. Future tests will be written to further define what these methods should do. The only intention of the developer is to write "just enough" code to ensure it meets all the tested requirements and doesn't cause any other tests to fail. <ref>What is Test Driven Development?</ref> Run the tests again. Ideally, all the tests should pass, making the developer confident about the features implemented so far.

Refactor

• DRY out commonality with other tests : Remove duplication of code wherever possible. Organizational changes can be made as well to make the code appear cleaner so it’s easier to maintain. TDD encourages frequent refactoring. Automated tests can be run to ensure the code refactoring does not break any existing functionality

Iterate

• Continue with the next thing (new or improvement of a feature), the code should do.
• Aim to have working code always.

Examples

TMDb : The Movie Database rails application

New Feature : Search TMDb for movies

Controller Action : Setup

1. Add the route to config/routes.rb :
   To add a new feature to this Rails application, we first add a route, which maps a URL to the controller method <ref>Routing in Rails</ref>
   
   # Route that posts 'Search TMDb' form
post '/movies/search_tmdb'
   This route would map to MoviesController#search_tmdb owing to Convention over Configuration, that is, it would post to the search_tmdb "action" in the Movies "controller".
   
   
2. Create an empty view:
   When a controller method is triggered, it gets some user input, does some computation and renders a view. So, the invocation of a controller needs a view to render, which we need to create even though it is not required to be tested. We start with an empty view. "touch" unix command is used to create a file of size 0 bytes.
   
   touch app/views/movies/search_tmdb.html.haml
   
   The above creates a view in the right directory with the file name, same as Movie controller's method name. (Convention over Configuration)
   This view can be refined in later iterations and user stories are used to verify if the view has everything that is needed.
   
   
3. Replace fake “hardwired” method in movies_controller.rb with empty method:
   If the method has a default functionality to return an empty list, then replace the method to one that does nothing.
   
   def search_tmdb
end
   

What model method?

It is the responsibility of the model to call TMDb and search for movies. But, no model method exists as yet to do this.
One may wonder that to test the controller's functionality, one has to get the model method working. Nevertheless, that is not required.
Seam is used in this case, to test the code we wish we had(“CWWWH”). Let us call the "non-existent" model method as Movie.find_in_tmdb

Testing plan

1. Simulate POSTing search form to controller action.
2. Check that controller action tries to call Movie.find_in_tmdb with the function argument as data from the submitted form. Here, the functionality of the model is not tested, instead the test ensures the controller invokes the right method with the right arguments.
3. The test will fail (red), because the (empty) controller method doesnʼt call find_in_tmdb.
4. Fix controller action to make the test pass (green).

Test MoviesController : Code<ref>TMDb : MoviesController Test Code</ref>

-------- movies_controller.rb --------

class MoviesController < ApplicationController

  def search_tmdb
  end

end

-------- movies_controller_spec.rb --------

require 'spec_helper'
describe MoviesController do
  describe 'searching TMDb' do
    it 'should call the model method that performs TMDb search' do
      Movie.should_receive(:find_in_tmdb).with('hardware')
      post :search_tmdb, {:search_terms => 'hardware'}
    end
  end
end

The above test case for the MoviesController has an 'it' block, which has a string defining what the test is supposed to check. A do-end block to that 'it' has the actual test code.

The line Movie.should_receive(:find_in_tmdb).with('hardware') creates an expectation that the Movie class should receive the find_in_tmdb method call with a particular argument. An assumption is made here, that the user has actually filled in hardware in the search_terms box on the page that says Search for TMDb.

Once the expectation is setup, we simulate the post using rspec-rails post :search_tmdb, {:search_terms => 'hardware'} as if it were a form and was submitted to the search_tmdb method in the controller (after looking up a route). The hash in this call is the contents of the params, which quacks like a hash, and can be accessed inside the controller method.

Thus, the test would fail if:

• once the post action is completed, should_receive finds that the method find_in_tmdb was not invoked.
• and if the method was indeed called, that single argument 'hardware' was not passed.

Testing

Autotest runs continuously and watches for any change in a file. Once the changes are saved, the test corresponding to the change is automatically run and the result is reported immediately.

Run the test written above.

The test FAILS .
Reason for error : MoviesController searching TMDb should call the model method that performs TMDb search

                  FailureError: Movie.should_receive(:find_in_tmdb).with('hardware')
                                expected: 1 time
                               received: 0 times

The test is expressing what is expected (identifying the right reason of failure).
To make the test pass, we change the MovieController's search_tmdb method to invoke the Model's find_in_tmdb method.

Changes made to the controller

-------- movies_controller.rb --------

class MoviesController < ApplicationController

  def search_tmdb
    Movie.find_in_tmdb(params[:search_terms])
  end

end

Movie.find_in_tmdb(params[:search_terms]) invokes the model's method with the value of search_Terms from the params hash.

Tests are run again. The test PASSES saying MoviesController searching TMDb should call the model method that performs TMDb search pass with 0 failures.
The following explains how invoking the non-existent method works and why the test case passed.

Use of Seams

The test fails as the controller is empty and the method does not call find_in_tmdb. The test case is made to pass by having the controller action invoke "Movie.find_in_tmdb" (which is, the code we wish we had) with data from submitted form. So here the concept of Seams comes in.
should_receive uses Rubyʼs open classes to create a seam for isolating controller action from behavior of a missing or buggy controller function. Thus, it overrides the find_in_tmdb method. Although it does not implement the logic of the method, it checks whether it is being called with the right argument. Even if the actual code for find_in_tmdb existed, the method defined in should_receive would have overwritten it. This is something we would need, as we don't want to be affected by bugs in some other code that we are not testing. This is an example of stub and every time a single test case is completed, all the mocks and stubs are automatically refreshed by Rspec. This helps to keep tests independent.

Return value from should_receive

In this example find_in_tmdb should return a set of movies for which we had called the function. Thus we should be checking its return value. However this should be checked in a different test case. Its important to remember that each "it" clause or each spec should test only one clause/behavior. In this example the first requirement was to make sure that find_in_tmdb is called with proper arguments and the second requirement is make sure that the result of search_tmdb is passed to the view so that it can be rendered. We have two different requirements and hence there must be two different test cases.

Conclusion

Advantages and Disadvantages

Advantages

• ensures the code is tested and enables you to retest your code quickly and easily, since it’s automated.
• immediate feedback
• improves code quality
• less time spent for debugging
• faster identification of the problem
• early and frequent detection of errors prevent them from becoming expensive and hard problems later<ref>TDD Advantages</ref>

Disadvantages

• Does not scale well with web-based GUI or database development <ref>Disadvantages of TDD</ref>
• reliant on refactoring and programming skills
• increases the project complexity and delivery time
• tightly coupled with the developer's interpretation, since developer writes the test cases mostly <ref>Shortcomings of TDD</ref>

References

<references/>

See Also

• Wiki page of TDD
• Definition of TDD
• TDD in different languagues
• The Newbie’s Guide to Test-Driven Development
• TDD vs BDD

Books

• Test Driven Development: By Example , Kent Beck
• Disciplined Agile Delivery (DAD): A Practitioner’s Guide to Agile Software Delivery in the Enterprise by Scott W. Ambler and Mark Lines, IBM Press, ISBN: 0132810131