CSC/ECE 517 Fall 2012/ch2a 2w32 mk: Difference between revisions

From Expertiza_Wiki
Jump to navigation Jump to search
No edit summary
No edit summary
 
(13 intermediate revisions by the same user not shown)
Line 3: Line 3:
==Introduction==
==Introduction==
This ia a textbook section that covers the online [https://www.youtube.com/watch?v=BU9k5t1yYgQ lectures] on [https://www.youtube.com/watch?v=ZWvtrc-ysa4&feature=relmfu Controller Specs and Refactoring].
This ia a textbook section that covers the online [https://www.youtube.com/watch?v=BU9k5t1yYgQ lectures] on [https://www.youtube.com/watch?v=ZWvtrc-ysa4&feature=relmfu Controller Specs and Refactoring].
The main focus is to write expectations that drive development of the controller method. While writing the tests for a controller method, it is discovered that it must collaborate with its model method. Instead of coding a model method, a stub model could be coded that acts as the code we wish we had ('''CWWWH'''). T he main idea is to isolate the code of the controller method from the model method. It is an important idea useful in software design but more specifically useful in software testing.  
The main focus is to write expectations that drive development of the controller method. While writing the tests for a controller method, it is discovered that it must collaborate with its model method. Instead of coding a model method, a stub model could be coded that acts as the code we wish we had ('''CWWWH'''). The main idea is to isolate the code of the controller method from the model method. It is an important idea useful in software design but more specifically useful in software testing.  
 
'''Key Idea''' - to break dependency between the method under test and its collaborators. This is what [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w31_up#Seams seams] are designed to do.
'''Key Idea''' - to break dependency between the method under test and its collaborators. This is what [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w31_up#Seams seams] are designed to do.
==History==
Brian Kernighan famously quoted that “Debugging is twice as hard as writing the code in the first place.” Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.
In other words it meant if you’re as clever as you can be when you write your code, how will you ever debug it.


Another famous computer scientist Dijkstra famously remarked that "testing can be used to show the presence of bugs but never to show their absence”.The fact is that NOTHING, not inspection, not formal proof, not testing, can give 100% certainty of no errors. Yet all these techniques, at some cost, can in fact reduce the errors to whatever level you wish.
==The Code You Wish You Had==
'''Example'''


In the initial stages i.e when the software industry was in a nascent stage, there was no stress upon software testing. In most of the cases there was just a quick check on the software and then the software was handed over to the client.A thorough testing of application was considered to be huge waste of time and resources.This was basically done so that items in the checklist could just be ticked off and software could be developed and handed over to client as soon as possible.However as time passed the importance of software testing was realized. Now software testing is given as much importance as that of developing a software.The change in trend can be easily explained.
'''TMDb : The Movie Database rails application'''


A Study conducted in 2002 by NIST reported that software bugs cost the U.S. economy a loss of atleast 59.5 billion dollars annually.It further reports that more than one third of this cost could have been avoided if better software testing was performed. <ref>http://www.abeacha.com/NIST_press_release_bugs_cost.htm</ref>
'''New Feature : Search TMDb for movies'''


It is commonly believed that the earlier a defect is found the cheaper it is to fix it. The following table shows the cost of fixing the defect depending on the stage it was found.For example, if a problem in the requirements is found only post-release, then it would cost 10–100 times more to fix than if it had already been found by the requirements review. With the advent of modern continuous deployment practices and cloud-based services, the cost of re-deployment and maintenance may lessen over time.
When the controller method receives the search form:


{|class="wikitable"
1. As explained in the previous [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w31_up#New_Feature_:_Search_TMDb_for_movies textbook section] , the controller method should call a method that will search TMDb for a specified movie.
|-
!Cost to fix a defect
!
!Time detected
!
!
!
!
|-
!
!
!Requirements
!Architecture
!Construction
!System test
!Post-release
|-
!Time introduced
!Requirements
!1×
!3x
!5-10x
!10x
!10-100x
|-
!
!Architecture
!-
!1x
!10x
!15x
!25-100x
|-
!
!Construction
!-
!-
!1x
!10x
!10-25x
|}


Another survey by Electric Cloud, the leading provider of software production management (SPM) solutions, conducted in partnership with Osterman Research showed that the majority of software bugs are attributed to poor testing procedures or infrastructure limitations rather than design problems. Additionally, the software test process is generally considered an unpleasant process, with software development professionals rating the use of their companies’ test systems more painful than preparing taxes.
2. If a match is found, the controller method should select "Search Results" view to display the match. This involves two specs - the controller should first decide to render Search Results, this is particularly important when different views can be rendered depending on outcome. The controller should also make the list of matches available to the rendered view.
Fifty-eight percent of respondents pointed to problems in the testing process or infrastructure as the cause of their last major bug found in delivered or deployed software, not design defects.


Specifically, the survey highlighted the following:
===Should and Should Not===
Completely automated software testing environments are still rare, with just 12 percent of software development organizations using fully automated test systems. Almost 10 percent reported that all testing was done manually.
In order to accomplish both of these specs, an expectation construct '''should''' is used. '''should''' is a method in a module that is mixed into the Object class. In Ruby, all the classes inherit from object class. Hence, when running RSpec, all the objects are capable of responding to the should method.
Forty-six percent of software developers said they do not have time to test as much as they should.
More than a third of developers, 36 percent, said they do not believe their companies perform enough pre-release testing.
Fifty-three percent said their testing is limited by compute resources.<ref>http://www.electric-cloud.com/news/2010-0602.php</ref>
==Importance of Software Testing==
Importance of Software Testing:


The importance of software testing can be explained in brief in the following points.
<pre>
obj.should match-condition
</pre>


Error Free Software: Software testing needs to be done thoroughly to deliver an error free software to the client. Even a very minute mistake in the the software can have a disastrous effect for the client. For example a small failure in a banking software can result in a wrong balance and millions of dollars worth loss to the client or customers of the client. So it is of prime importance that the software delivered to the client be bug free and accurate.
RSpec defines some built-in matchers that can be used as the match-condition. We can also define some methods of our own.


Variance from the Requirement:One important factor while building a software is to adhere to the client requirements. if a software is not built in accordance to the requirements then the software becomes useless and redundant for the client.This is a lot of trouble and overhead for the software developing firm also as the requirement was not well understood.The budget fixed for the development of th software can easily go overboard.In such scenarios verification and validation process come into picture. The two most important questions that needs to be answered are “Is the product being built right” and “Is the right product being built”.If the answer is negative to any one of these questions it means that the the product developed has a variance from the client requirements and necessary changes needs to be made before going ahead with further development.
<pre>
count.should == 5                    (Syntactic sugar for count.should.==(5))


Identify Defect and Prevent their Migration: If a defect is detected in the requirement analysis stage ,then rectifying the defect is a lot easier and cheaper. But if the defect is not identified and carried over to the next phases of software development then it become more difficult to fix the defects,So it is highly recommended that software testing process be started right when the software development starts.
5.should(be.<(7))                    (be creates a lambda that tests the predicate expression)


Identify Undiscovered Error: If proper importance is not given to software testing i.e it is not done  thoroughly and just a superficial testing is done there is high probability that some of the errors will creep through  to the next phase. In such case using different software testing methodologies help in identifying the hidden errors.Exploratory testing is one such method. In such case the tester randomly tests the software for bugs and finds out the error.
5.should be < 7                      (Syntactic sugar allowed)
Use the Software in Real Time Environment: Testing a software in development and running it in production are two completely different scenarios.When a developer develops a software he tests it only in a development environment. There is high probability that the software will fail  miserably in real time environment.  


Do Away with Developer Bias: When a person is designated a tester role his prime responsibility is to test the software. The element of bias is removed. For example when we have a developer testing a software in majority of the cases he is going to be biased towards the software. This is because he has developed the software and its natural human instinct to think one’s product is the best. In such scenario many problems will remain unearthed.
5.should be_odd                      (use method_missing to call odd? on 5)


Provide Confidence in the Software: Software testing is also used for asserting the confidence on a developed product. There is a huge difference between being an usable product to operable product. When a software is tested time and over again with a huge degree of success then one can easily approve of the quality of the software developed.
result.should include(elt)            (Calls Enumerable#include?)
<ref>http://www.cbwc-ontario.org/importance-of-software-testing.html</ref>
==Testing Today==
There are various software development life cycle methodologies available for executing software development projects.Each methodology is unique i.e it is designed for a special purpose and compared to other methodologies has its own advantages and disadvantages.But most methodologies work by dividing the entire life cycle into phases and then sharing tasks across this phases.The common methodologies used for software development and their relationship with respect to testing can be summarized below:


The Waterfall model:
result.should match(/regex/)
It is one of the most common and earliest structured models for software development.Waterfall models stresses that one should only move to a phase after the completing and perfecting the preceding phase.As a result of this the phases of software development in waterfall model are unique and there is no jumping back and forth between the various stages.
</pre>


A typical waterfall model consists of the following sequential phases
In all the above cases, '''should_not''' can also be used in place of '''should'''.


It consists of the following sequential phases through which the development life cycle progresses:
===Check for Rendering===
<ref>http://www.guru99.com/testing-methodology.html</ref>
There is an RSpec construct '''render_template''' that checks whether a controller method would render a template with a particular name.  


[[File: Waterfall_model.png]]
<pre>
result.should render_template('search_tmdb')
</pre>


* Requirement analysis: In this phase, software requirements are captured in such a fashion that they can be translated into actual use cases for the system. The requirements can be derived from performance goals, use cases, target deployment, etc.
The RSpec method '''post''' simulates posting a form so that the controller method gets called. Once the post is done, there is another RSpec method called '''response()''' that returns the controller's response object. The render_template matcher can use the response object to check what view the controller would have tried to render.
* System design: In this phase,the interacting components that make up the system are identified, The exposed interfaces and the communication between them,key algorithms and sequence of interaction are defined, In the end of this phase an architecture and design review is conducted to ensure that the design conforms to the previously defined requirements.
* Implementation : This phase is also termed as Coding and unit testing. In this phase,coding is done for the modules that build the system.Code can also be reviewed and functionality of each module individually tested.
* Verification: Also termed as Integration and system testing. In this phase,all the modules in the system are integrated together and tested as a single system for all the use cases.The primary emphasis is upon making sure that all the modules meet the requirements.
* Deployment and maintenance. This is the final phase where the software system is deployed into the production environment. Any errors identified in this phase are corrected and functionality is added/modified to the system based on the updated requirements.


Waterfall model has the following advantages:
<pre>
* The life cycle can be compartmentalized into various phases which helps in planning the resources and the amount of effort required through the development process.
    require 'spec_helper'
* Testing is enforced in every stage in the form of unit testing and reviews.During various stages of the lifecycle different form of reviews like design and code reviews and various forms of testing like unit and integration testing are performed.
   
* After each phase of lifecycle expectations for deliverables can be set.
    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
        it 'should select the Search Results template for rendering' do
          Movie.stub(:find_in_tmdb)
          post :search_tmdb, {:search_terms => 'hardware'}
          response.should render_template('search_tmdb')
        end
      end
    end
</pre>


Waterfall model has the following disadvantages:
Post and render_template are the extensions in Rails that have been added specifically by RSpec to test rails code.
* There is no working version of software until its late in the life cycle.So problems can’t be detcted until the system testing phase.Problems are always hard to fix in the latter phases of life cycle.
* Also for a phase to get started the previous phase must be complete.A system design principle cannot start until the requirement analysis phase is complete and the requirements are frozen. So waterfall model cannot accommodate uncertainties that that may persist after  a phase is over.This can lead to delays and extended project schedules.


Testing approach:
Controller specs are like functional tests. They test more than one thing, not just call the controller method in isolation. They do the same thing a real browser does. The controller method does a post and the url is going to touch the routing subsystem, the dispatcher is going to call the controller method and when the controller method tries to call the view, the view should exist. Post will try to do the whole MVC flow, including rendering the view.
During the requirements phase the project requirements are completely defined.Simultaneously the test team brainstorms the scope of testing,test strategy and drafts a detailed test plan.


<h4>Incremental or Iterative Development</h4>
===Make search results available to template===
When you setup instance variables in the controller, those are available in the view for access. There is another RSpec-rails addition assign(), which when passed a symbol that stands for a controller instance variable, it returns the value of the instance variable that the controller has assigned to it. If the controller has never assigned a value to it, it would return Nil.


The fundamental principle behind incremental or iterative development is to break down the project into small parts. When one iteration is complete a new module is completed or an existing module is improved. The module is then integrated into the structure and finally the structure is then tested as a whole. In the iterative development model a project is usually broken down into 12 iterations of one to four week duration each.Finally the system is tested at the end of each duration and the test feedback is immediately incorporated. Time spent on the successive iterations can be modified on the basis of experience gained from past iterations. So the system grows by incorporating new functions during the development portion of each iteration.Each iteration thus involves adding of new functions during the development phase.testing evolves as the system evolves.
<pre>
<br>
    require 'spec_helper'
<br>
   
[[File:Iterative_dev.jpg]]
    describe MoviesController do
<br>
      describe 'searching TMDb' do
<br>
        before :each do
The main advantage of iterative development model is that corrective actions can be taken at end of each iteration.
          @fake_results = [mock('movie1'), mock('movie2')]
        end
        it 'should call the model method that performs TMDb search' do
          Movie.should_receive(:find_in_tmdb).with('hardware').
            and_return(@fake_results)
          post :search_tmdb, {:search_terms => 'hardware'}
        end
        it 'should select the Search Results template for rendering' do
          Movie.stub(:find_in_tmdb).and_return(@fake_results)
          post :search_tmdb, {:search_terms => 'hardware'}
          response.should render_template('search_tmdb')
        end
        it 'should make the TMDb search results available to that template' do
          Movie.stub(:find_in_tmdb).and_return(@fake_results)
          post :search_tmdb, {:search_terms => 'hardware'}
          assigns(:movies).should == @fake_results
        end
      end
    end
</pre>


The main disadvantages of iterative development model are:
@movies instance variable is passed to assigns method and the value of @fake_results is assigned to @movies. The general strategy is to decouple the behavior that is being tested from the other behavior that it depends on. The controller should make the results returned by model method '''find_in_tmdb''' to the view. Either the actual results can be returned or the behavior can be mimicked to return fake results. The movie stub can be forced to return the fake results. Mock objects are going to stand in for the real movie objects. It doesn't matter whether the model returns real movie objects for the purposes of this test. In this test, the only thing being checked is whether the results passed by the model are being displayed in the view. The fake_results does not even have to be an array of movies, it could even be a string. Our major concern is whether the results from the model object are being sent correctly to the view.
* Each iteraton involved giving feedback about the deliverables,timelines,efforts and so on.SO the overhead is considerably higher.
* It is hard to freeze the requirements as requirements may need change based on feedback and increasing customer demands.This can lead to more number of iterations and thus delay in deliverables.
* An efficient control change mechanism is needed to manage the system changes made during each iteration.


Testing approach:
==Seam Concepts==
As soon as iteration is complete the entire system is subjected to testing.The feedback from testing is immediately available and further incorporated into the next cycle.Testing time required for the successive iterations can be reduced based on the experience gained from past iterations.
Seams are used to enable just enough functionality for some specific behavior under test.
===stub===
It is similar to '''should_receive'''. But, should_receive also monitors whether the method gets called or not whereas the stub method doesn't care whether the method is called or not. If the stub gets called, we can chain '''and_return''' to the end of it to control the return value.


<h4>Agile Methodology</h4>
===mock===
Previously Majority of the software development life cycle methodologies could be categorised into either iterative or sequential model like waterfall model does.But as software systems evolved and became more complex both of these models couldn’t efficiently adapt to the significant and continuous number of changes.Agile methodology was developed to solve this issue.It was develoepd to respond to changes quicly and smoothly. The drawback with iterative model was that even though it removed the disadvantage of sequential models it was still based on the waterfall model.In Agile methodology  , software is developed in  incremental, rapid cycles. Interactions amongst customers, developers and client are emphasized rather than processes and tools. Agile methodology focuses on responding to change rather than extensive planning.
It is a kind of 'stunt double' object. It can be used to stub individual methods on it. For example, we can make the stub method return the value of the title as 'Rambo' even though the mock object is not of movie type.
<br>
<br>
[[File: Agile_dev.gif]]
<br>
<br>
The main differences between agile and traditional methodologies are as follows:
* An incremental method of development is followed rather than the traditional sequential method.There are small incremental releases and each release is based on previous functionality.
* Each release is thoroughly tested and that helps to ensure that the defects are addressed in the next iteration.
* There is more emphasis given on people and their interactions rather than processes and tools.The developers,customers and testers continuously interact with each other.This interaction ensures that the tester us aware of the features being developed during a particular iteration and so can easily identify any sort of discrepancy between the system and the requirements.
* More priority is given to working software rather than detailed documentation. Agile methodologies rely on face-to-face communication and collaboration, with people working in pairs. As there is extensive communication between customers and team members, there is no need for comprehensive requirements document. All agile projects have customers as an integral part of the team.When developers have a query regarding program requirements thy can get it immediately clarified from the customers.


The disadvantage is that a constant client interaction leads to and added time pressure on all stakeholders including the client themselves , software development and test teams .
<pre>
m = mock('movie1')
m.stub(:title).and_return('Rambo')


Testing approach:
-shortcut: m = mock('movie1', :title=>'Rambo')
Incremental testing approach is followed and thus every release of the project is tested thoroughly.This ensures that any bugs in the system are fixed before the next release.
</pre>
 
<h4>Extreme Programming</h4>
Extreme programming<ref>http://xprogramming.com/book/whatisxp</ref> is a form of agile methodology that believes in short development cycles.So rather than designing the whole of the system at the start of the project the preliminary design work is shortened down to solve the simple tasks that have already been identified.The developers have to interact frequently with customers and other developers. A simple task is started and as soon as it is developed customer feedback is taken.The system is delivered to the customer as soon as possible and the requirements are then refined on the basis of customer feedback.So the requirements evolve over a period of time and developers are able to respond to changes quickly.Extreme programming emphasizes on pair programming.This means one developer writes the code for a particular feature and the other developer reviews it. In theory, the driver focuses on the code at hand: the syntax, semantics, and algorithm. The navigator focuses less on that, and more on a level of abstraction higher: the test they are trying to get to pass, the technical task to be delivered next, the time elapsed since all the tests were run, the time elapsed since the last repository commit, and the quality of the overall design. The theory is that pairing results in better designs, fewer bugs, and much better spread of knowledge across a development team, and therefore more functionality per unit time, measured over the long term.
[[File:Extreme_prog.jpg]]
 
<br>
Extreme Programming is highly useful in the many situations.
 
* If a customer doesn't have a clear understanding of the system then the developers can interact continuously with the customer ,deliver small pieces and ask the customer for feedback.Corrective action is then taken.
* If a technology used to develop a system is significantly new and its a completely new platform then frequent test cycles in extreme programing mitigate the risk of incompatibility with other existing systems.
* If you want automated unit and functional tests there may be a need to change system design such that each module can be tested in isolation sing automation. XP(Extreme programming) comes handy in such scenario.
 
The main advantage of following XP is that customers having a vague software design in mind can go ahead to implement their product. The continuous testing and integration ensures that  the software code delivered is of the highest standards.
 
Testing approach:
Extreme programming follows a test driven development.It is explained in brief in the subsequent section.
 
==Test Driven Development (TDD)==
Test-driven development is one of the core practices of Extreme Programming. Test cases are written first and then code is written to pass the existing test cases. Then new test cases are added to test the existing functionality, and then the  entire test suite is run to ensure that the code fails. Then new functionality is added or existing functionality is modified so that the code can withstand the failed test cases. This cycle continues until the test code passes all of the test cases that the team can create. The code is then refactored to make it DRY and more maintainable.
 
Test-driven development is totally non conventional in the sense that instead of writing code first and then testing it, you write the tests first and then write code to make the tests pass. This is done iteratively. Only when one test case passes, the developer moves on to the next test case and writes code to make it pass. This process is continued until all tests pass.
 
With test-driven development we can even start with an unclear set of requirements and then can discuss with the customer later about new requirements or change in existing requirements. Even if the code is not ready for a particular functionality but the tests are written, it will ensure that the functionality is addressing all the requirements given by the customer and unnecessary functionality is not included. It allows you to build your software step-by-step and then as the requirements become more clear it evolves the system.<br>
Other advantages of TDD:
* Loosely coupled and highly cohesive code is promoted by Test-driven development because the functionality is evolved in small steps.
* The tests that we write can act as documentation for the final system’s specifications.
* Time for retesting is reduced because of automated testing. So we don’t have to waste time in retesting existing functionality.
* You know exactly what you have to do in order to make a test pass. Your effort can be measured in terms of number of tests passed.
Unit testing is also ensured through Test-driven development. We will still need to all other kinds of testing such as acceptance testing, system integration testing etc.
 
<h4>Steps in Test-Driven Development</h4>
The following figure shows the steps involved in test-driven development process
<ref>http://msdn.microsoft.com/en-us/library/ff649520.aspx</ref>
<br>
[[File:TDD.gif]]
<br>
==Behavior Driven Development (BDD)==
Behavior Driven Development provides a common language between developers, analysts, and customers, thereby, reducing miscommunication between which was common in earlier forms of software development. This language is used by developers to communicate while developing and explaining code. It makes sure that the customers and the developers have a common vocabulary while talking about the system being developed.
 
While TDD makes sure that the technical quality of software is up to the mark, behavior-driven development makes sure that the needs of the customer are fulfilled. TDD takes care of the verification part i.e. building the thing right, BDD takes care of the validation part i.e. building the right thing.
 
Building the Right Thing :
 
BDD helps to ensure that the right features are built and delivered the first time. By remembering the three categories of problems that we’re typically trying to solve, and by beginning with the stakeholders—the people who are actually going to be using the software we write—we are able to clearly specify what the most important features are, and arrive at a definition of done that encapsulates the business driver for the software.
 
Reducing Risk :
BDD also reduces risk—risk that, as developers, we’ll go off at a tangent. If our focus is on making a test pass, and that test encapsulates the customer requirement in terms of the behavior of the end result, the likelihood that we’ll get distracted or write something unnecessary is greatly reduced. Interestingly, a suite of acceptance tests developed this way, in partnership with the stakeholder, also forms an excellent starting point for monitoring the system throughout its lifecycle. We know how the system should behave, and if we can automate tests that prove the system is working according to specification, and put alerts around them (both in the development process so we capture defects, and when live so we can resolve and respond to service degradation), we have grounded our monitoring in the behavior of the application that the stakeholder has defined as being of paramount importance to the business.
 
Evolving Design :
It also helps us to think about the design of the system. The benefits of writing unit tests to increase confidence in our code are pretty obvious. Maturing to the point that we write these tests first helps us focus on writing only the code that is explicitly needed. The tests also serve as a map to the code, and offer lightweight documentation. By tweaking our approach towards thinking about specifying behavior rather than testing classes and methods, we come to appreciate test-driven development as a practice that helps us discover how the system should work, and molds our thinking towards elegant solutions that meet the requirements.
 
How does all of this relate to Infrastructure as Code? Well, as infrastructure developers, we are providing the underlying systems which make it possible to effectively deliver software. This means our customers are often application developers or test and QA teams. Of course, our customers are also the end users of the software that runs on our systems, so we’re responsible for ensuring our infrastructure performs well and remains available when needed. Having accepted that we need some kind of mechanism for testing our infrastructure to ensure it evolves rapidly without unwanted side effects, bringing the principle of BDD into the equation helps us to ensure that we’re delivering business value by providing the infrastructure that is actually needed. We can avoid wasting time pursuing the latest and greatest technology by realizing we could meet the requirements of the business more readily with a simpler and established solution.
<ref>http://my.safaribooksonline.com/book/software-engineering-and-development/software-testing/9781449309718</ref>
<ref>http://bubusdaybook.blogspot.com/2011/08/extreme-programming-in-nutshell.html</ref>
 
 
==Cucumber and RSpec==
Using cucumber, we can describe, in plain text, how a software should behave. It executes plain-text functional descriptions as automated tests. Cucumber supports Behavior Driven Development. The tests are written before the code is written and is verified by non technical stakeholders. The production code is then written to make the stories pass.
<ref> https://github.com/cucumber/cucumber/wiki</ref>


==Test Cookery==
1. Each spec should test just one behavior.


Following is an example of a cucumber scenario in the BackChannel app:
2. Use seams as needed to isolate that behavior.
<pre>
Feature: User can add post


Scenario: Add a post
3. Determine which explanation you will use to check that behavior.
Given I am on the posts index page
When I follow “Add new post”
Then I should be on the Create New Post page
When I fill in “Title” with “Fight Club”
And I fill in “Content” with “The things you own, end up owning you”
And I press “Save Changes”
Then I should be on the posts index page
And I should see “Fight Club”
</pre>


There are six steps to behavior driven development using Cucumber and Rspec<ref>http://cukes.info/</ref>
4. Write the test and make sure it fails for the right reason.
# Describe behavior in plain text using Cucumber
# Write a step definition in ruby using Rspec
# Run the test and it will fail because the code is not been written yet
# Write code to make the step pass
# Run the test again and see the step pass
# Repeat 2-5 until all steps pass in the behavior
<br>
[[File:Cucumber.jpg|Cucumber and RSpec loop]]
<br>
The test driven development loop is also known as Red-Green-Refactor.
<ref>Aramando, Fox (2012). Engineering Long Lasting Software. San Francisco: Strawberry Canyon</ref>
<br>
Red step: Run the test and verify that it fails because you haven’t yet implemented the code.<br>
Green step: Write the simplest possible code that causes this test to pass without breaking any existing tests.<br>
Refactor step: Refactor the code if there is any scope of refactoring.<br>


==Conclusion==
5. Add code until test is green.
BDD and TDD may seem strange at first but once you use it you realize you have been using these techniques in conventional development also, while doing unit testing. Rather than coding first and then debugging the code to find the problem, TDD is much better of way of developing a system in that you can isolate the problem really easily because you whole is divided into features and specs.


If we write code first and then debug, we end up using the same techniques as TDD but less efficiently and less productively. Using TDD, bugs can be spotted quickly and regression testing is easy because all the testing is automated.
6. Look for opportunities to refactor/beautify.


==References==
==References==
<references/>
<references/>
1. https://www.youtube.com/watch?v=BU9k5t1yYgQ


The video of the lecture can be found [https://www.youtube.com/watch?v=Hpg9303P0Ts here].
2. https://www.youtube.com/watch?v=ZWvtrc-ysa4&feature=relmfu

Latest revision as of 04:13, 27 October 2012

SaaS - 5.4 - More Controller Specs and Refactoring

Introduction

This ia a textbook section that covers the online lectures on Controller Specs and Refactoring. The main focus is to write expectations that drive development of the controller method. While writing the tests for a controller method, it is discovered that it must collaborate with its model method. Instead of coding a model method, a stub model could be coded that acts as the code we wish we had (CWWWH). The main idea is to isolate the code of the controller method from the model method. It is an important idea useful in software design but more specifically useful in software testing.

Key Idea - to break dependency between the method under test and its collaborators. This is what seams are designed to do.

The Code You Wish You Had

Example

TMDb : The Movie Database rails application

New Feature : Search TMDb for movies

When the controller method receives the search form:

1. As explained in the previous textbook section , the controller method should call a method that will search TMDb for a specified movie.

2. If a match is found, the controller method should select "Search Results" view to display the match. This involves two specs - the controller should first decide to render Search Results, this is particularly important when different views can be rendered depending on outcome. The controller should also make the list of matches available to the rendered view.

Should and Should Not

In order to accomplish both of these specs, an expectation construct should is used. should is a method in a module that is mixed into the Object class. In Ruby, all the classes inherit from object class. Hence, when running RSpec, all the objects are capable of responding to the should method.

obj.should match-condition

RSpec defines some built-in matchers that can be used as the match-condition. We can also define some methods of our own.

count.should == 5                     (Syntactic sugar for count.should.==(5))

5.should(be.<(7))                     (be creates a lambda that tests the predicate expression)

5.should be < 7                       (Syntactic sugar allowed)

5.should be_odd                       (use method_missing to call odd? on 5)

result.should include(elt)            (Calls Enumerable#include?)

result.should match(/regex/)

In all the above cases, should_not can also be used in place of should.

Check for Rendering

There is an RSpec construct render_template that checks whether a controller method would render a template with a particular name.

result.should render_template('search_tmdb')

The RSpec method post simulates posting a form so that the controller method gets called. Once the post is done, there is another RSpec method called response() that returns the controller's response object. The render_template matcher can use the response object to check what view the controller would have tried to render.

    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
        it 'should select the Search Results template for rendering' do
          Movie.stub(:find_in_tmdb)
          post :search_tmdb, {:search_terms => 'hardware'}
          response.should render_template('search_tmdb')
        end
      end
    end

Post and render_template are the extensions in Rails that have been added specifically by RSpec to test rails code.

Controller specs are like functional tests. They test more than one thing, not just call the controller method in isolation. They do the same thing a real browser does. The controller method does a post and the url is going to touch the routing subsystem, the dispatcher is going to call the controller method and when the controller method tries to call the view, the view should exist. Post will try to do the whole MVC flow, including rendering the view.

Make search results available to template

When you setup instance variables in the controller, those are available in the view for access. There is another RSpec-rails addition assign(), which when passed a symbol that stands for a controller instance variable, it returns the value of the instance variable that the controller has assigned to it. If the controller has never assigned a value to it, it would return Nil.

    require 'spec_helper'
     
    describe MoviesController do
      describe 'searching TMDb' do
        before :each do
          @fake_results = [mock('movie1'), mock('movie2')]
        end
        it 'should call the model method that performs TMDb search' do
          Movie.should_receive(:find_in_tmdb).with('hardware').
            and_return(@fake_results)
          post :search_tmdb, {:search_terms => 'hardware'}
        end
        it 'should select the Search Results template for rendering' do
          Movie.stub(:find_in_tmdb).and_return(@fake_results)
          post :search_tmdb, {:search_terms => 'hardware'}
          response.should render_template('search_tmdb')
        end
        it 'should make the TMDb search results available to that template' do
          Movie.stub(:find_in_tmdb).and_return(@fake_results)
          post :search_tmdb, {:search_terms => 'hardware'}
          assigns(:movies).should == @fake_results
        end
      end
    end

@movies instance variable is passed to assigns method and the value of @fake_results is assigned to @movies. The general strategy is to decouple the behavior that is being tested from the other behavior that it depends on. The controller should make the results returned by model method find_in_tmdb to the view. Either the actual results can be returned or the behavior can be mimicked to return fake results. The movie stub can be forced to return the fake results. Mock objects are going to stand in for the real movie objects. It doesn't matter whether the model returns real movie objects for the purposes of this test. In this test, the only thing being checked is whether the results passed by the model are being displayed in the view. The fake_results does not even have to be an array of movies, it could even be a string. Our major concern is whether the results from the model object are being sent correctly to the view.

Seam Concepts

Seams are used to enable just enough functionality for some specific behavior under test.

stub

It is similar to should_receive. But, should_receive also monitors whether the method gets called or not whereas the stub method doesn't care whether the method is called or not. If the stub gets called, we can chain and_return to the end of it to control the return value.

mock

It is a kind of 'stunt double' object. It can be used to stub individual methods on it. For example, we can make the stub method return the value of the title as 'Rambo' even though the mock object is not of movie type.

m = mock('movie1')
m.stub(:title).and_return('Rambo')

-shortcut: m = mock('movie1', :title=>'Rambo')

Test Cookery

1. Each spec should test just one behavior.

2. Use seams as needed to isolate that behavior.

3. Determine which explanation you will use to check that behavior.

4. Write the test and make sure it fails for the right reason.

5. Add code until test is green.

6. Look for opportunities to refactor/beautify.

References

<references/> 1. https://www.youtube.com/watch?v=BU9k5t1yYgQ

2. https://www.youtube.com/watch?v=ZWvtrc-ysa4&feature=relmfu