Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2012/ch2a 2w32 mk

2012-10-27T04:13:08Z

Hpkancha:

CSC/ECE 517 Fall 2012/ch2a 2w32 mk

2012-10-27T04:11:10Z

Hpkancha:

CSC/ECE 517 Fall 2012/ch2a 2w32 mk

2012-10-27T04:10:49Z

Hpkancha:

CSC/ECE 517 Fall 2012/ch2a 2w32 mk

2012-10-27T04:08:35Z

Hpkancha:

CSC/ECE 517 Fall 2012/ch2a 2w32 mk

2012-10-27T03:26:43Z

Hpkancha:

<h2>SaaS - 5.4 - More Controller Specs and Refactoring </h2>
__TOC__
==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].
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.

==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 [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.

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.

<pre>
obj.should match-condition
</pre>

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

<pre>
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/)
</pre>

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.

<pre>
result.should render_template('search_tmdb')
</pre>

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.

<pre>
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
</pre>

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.

==Importance of Software Testing==
Importance of Software Testing:

The importance of software testing can be explained in brief in the following points.

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.

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.

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.

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.
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.

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.
<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:
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.

A typical waterfall model consists of the following sequential phases

It consists of the following sequential phases through which the development life cycle progresses:
<ref>http://www.guru99.com/testing-methodology.html</ref>

[[File: Waterfall_model.png]]

* 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.
* 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:
* 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.
* 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.

Waterfall model has the following disadvantages:
* 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:
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>

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.
<br>
<br>
[[File:Iterative_dev.jpg]]
<br>
<br>
The main advantage of iterative development model is that corrective actions can be taken at end of each iteration.

The main disadvantages of iterative development model are:
* 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:
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.

<h4>Agile Methodology</h4>
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.
<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 .

Testing approach:
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.

<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>

Following is an example of a cucumber scenario in the BackChannel app:
<pre>
Feature: User can add post

Scenario: Add a post
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>
# 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==
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.

==References==
<references/>

The video of the lecture can be found [https://www.youtube.com/watch?v=Hpg9303P0Ts here].

CSC/ECE 517 Fall 2012/ch2a 2w32 mk

2012-10-27T03:25:12Z

Hpkancha:

<h2>SaaS - 5.4 - More Controller Specs and Refactoring </h2>
__TOC__
==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].
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.

==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 [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.

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.

<pre>
obj.should match-condition
</pre>

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

<pre>
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/)
</pre>

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.

<pre>
result.should render_template('search_tmdb')
</pre>

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.

<pre>
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
</pre>

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.

Specifically, the survey highlighted the following:
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.
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.

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.

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.

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.

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.
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.

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.
<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:
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.

A typical waterfall model consists of the following sequential phases

It consists of the following sequential phases through which the development life cycle progresses:
<ref>http://www.guru99.com/testing-methodology.html</ref>

[[File: Waterfall_model.png]]

* 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.
* 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:
* 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.
* 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.

Waterfall model has the following disadvantages:
* 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:
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>

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.
<br>
<br>
[[File:Iterative_dev.jpg]]
<br>
<br>
The main advantage of iterative development model is that corrective actions can be taken at end of each iteration.

The main disadvantages of iterative development model are:
* 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:
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.

<h4>Agile Methodology</h4>
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.
<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 .

Testing approach:
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.

<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>

Following is an example of a cucumber scenario in the BackChannel app:
<pre>
Feature: User can add post

Scenario: Add a post
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>
# 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==
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.

==References==
<references/>

The video of the lecture can be found [https://www.youtube.com/watch?v=Hpg9303P0Ts here].

CSC/ECE 517 Fall 2012/ch2a 2w32 mk

2012-10-27T02:41:01Z

Hpkancha:

<h2>SaaS - 5.4 - More Controller Specs and Refactoring </h2>
__TOC__
==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].
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.

==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 [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.

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.

<pre>
obj.should match-condition
</pre>

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

<pre>
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/)
</pre>

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

Specifically, the survey highlighted the following:
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.
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.

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.

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.

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.

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.
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.

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.
<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:
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.

A typical waterfall model consists of the following sequential phases

It consists of the following sequential phases through which the development life cycle progresses:
<ref>http://www.guru99.com/testing-methodology.html</ref>

[[File: Waterfall_model.png]]

* 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.
* 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:
* 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.
* 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.

Waterfall model has the following disadvantages:
* 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:
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>

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.
<br>
<br>
[[File:Iterative_dev.jpg]]
<br>
<br>
The main advantage of iterative development model is that corrective actions can be taken at end of each iteration.

The main disadvantages of iterative development model are:
* 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:
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.

<h4>Agile Methodology</h4>
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.
<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 .

Testing approach:
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.

<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>

Following is an example of a cucumber scenario in the BackChannel app:
<pre>
Feature: User can add post

Scenario: Add a post
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>
# 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==
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.

==References==
<references/>

The video of the lecture can be found [https://www.youtube.com/watch?v=Hpg9303P0Ts here].

CSC/ECE 517 Fall 2012/ch2a 2w32 mk

2012-10-27T02:38:13Z

Hpkancha:

<h2>SaaS - 5.4 - More Controller Specs and Refactoring </h2>
__TOC__
==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].
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.

==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 [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.

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.

<pre>
obj.should match-condition
</pre>

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

<pre>
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/)
</pre>

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

Specifically, the survey highlighted the following:
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.
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.

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.

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.

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.

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.
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.

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.
<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:
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.

A typical waterfall model consists of the following sequential phases

It consists of the following sequential phases through which the development life cycle progresses:
<ref>http://www.guru99.com/testing-methodology.html</ref>

[[File: Waterfall_model.png]]

* 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.
* 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:
* 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.
* 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.

Waterfall model has the following disadvantages:
* 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:
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>

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.
<br>
<br>
[[File:Iterative_dev.jpg]]
<br>
<br>
The main advantage of iterative development model is that corrective actions can be taken at end of each iteration.

The main disadvantages of iterative development model are:
* 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:
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.

<h4>Agile Methodology</h4>
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.
<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 .

Testing approach:
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.

<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>

Following is an example of a cucumber scenario in the BackChannel app:
<pre>
Feature: User can add post

Scenario: Add a post
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>
# 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==
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.

==References==
<references/>

The video of the lecture can be found [https://www.youtube.com/watch?v=Hpg9303P0Ts here].

CSC/ECE 517 Fall 2012/ch2a 2w32 mk

2012-10-27T02:34:25Z

Hpkancha:

<h2>SaaS - 5.4 - More Controller Specs and Refactoring </h2>
__TOC__
==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].
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.

==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 [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.

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.

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.

<pre>
obj.should match-condition
</pre>

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

<pre>
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/)
</pre>

Specifically, the survey highlighted the following:
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.
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.

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.

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.

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.

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.
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.

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.
<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:
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.

A typical waterfall model consists of the following sequential phases

It consists of the following sequential phases through which the development life cycle progresses:
<ref>http://www.guru99.com/testing-methodology.html</ref>

[[File: Waterfall_model.png]]

* 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.
* 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:
* 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.
* 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.

Waterfall model has the following disadvantages:
* 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:
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>

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.
<br>
<br>
[[File:Iterative_dev.jpg]]
<br>
<br>
The main advantage of iterative development model is that corrective actions can be taken at end of each iteration.

The main disadvantages of iterative development model are:
* 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:
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.

<h4>Agile Methodology</h4>
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.
<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 .

Testing approach:
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.

<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>

Following is an example of a cucumber scenario in the BackChannel app:
<pre>
Feature: User can add post

Scenario: Add a post
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>
# 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==
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.

==References==
<references/>

The video of the lecture can be found [https://www.youtube.com/watch?v=Hpg9303P0Ts here].

CSC/ECE 517 Fall 2012/ch2a 2w32 mk

2012-10-27T02:33:25Z

Hpkancha:

<h2>SaaS - 5.4 - More Controller Specs and Refactoring </h2>
__TOC__
==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].
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.

==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 [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.

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.

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.

<pre>
obj.should match-condition
</pre>

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

<pre>
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/)
</pre>

Specifically, the survey highlighted the following:
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.
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.

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.

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.

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.

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.
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.

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.
<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:
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.

A typical waterfall model consists of the following sequential phases

It consists of the following sequential phases through which the development life cycle progresses:
<ref>http://www.guru99.com/testing-methodology.html</ref>

[[File: Waterfall_model.png]]

* 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.
* 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:
* 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.
* 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.

Waterfall model has the following disadvantages:
* 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:
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>

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.
<br>
<br>
[[File:Iterative_dev.jpg]]
<br>
<br>
The main advantage of iterative development model is that corrective actions can be taken at end of each iteration.

The main disadvantages of iterative development model are:
* 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:
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.

<h4>Agile Methodology</h4>
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.
<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 .

Testing approach:
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.

<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>

Following is an example of a cucumber scenario in the BackChannel app:
<pre>
Feature: User can add post

Scenario: Add a post
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>
# 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==
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.

==References==
<references/>

The video of the lecture can be found [https://www.youtube.com/watch?v=Hpg9303P0Ts here].

CSC/ECE 517 Fall 2012/ch2a 2w32 mk

2012-10-27T02:22:33Z

Hpkancha:

<h2>SaaS - 5.4 - More Controller Specs and Refactoring </h2>
__TOC__
==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].
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.

==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 pevious [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.

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.

In order to accomplish both of these specs, an expectation construct '''should''' is used.

<pre>
obj.should match-condition
</pre>

Specifically, the survey highlighted the following:
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.
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.

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.

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.

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.

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.
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.

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.
<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:
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.

A typical waterfall model consists of the following sequential phases

It consists of the following sequential phases through which the development life cycle progresses:
<ref>http://www.guru99.com/testing-methodology.html</ref>

[[File: Waterfall_model.png]]

* 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.
* 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:
* 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.
* 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.

Waterfall model has the following disadvantages:
* 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:
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>

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.
<br>
<br>
[[File:Iterative_dev.jpg]]
<br>
<br>
The main advantage of iterative development model is that corrective actions can be taken at end of each iteration.

The main disadvantages of iterative development model are:
* 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:
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.

<h4>Agile Methodology</h4>
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.
<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 .

Testing approach:
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.

<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>

Following is an example of a cucumber scenario in the BackChannel app:
<pre>
Feature: User can add post

Scenario: Add a post
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>
# 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==
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.

==References==
<references/>

The video of the lecture can be found [https://www.youtube.com/watch?v=Hpg9303P0Ts here].

CSC/ECE 517 Fall 2012/ch2a 2w32 mk

2012-10-27T01:58:30Z

Hpkancha:

<h2>SaaS - 5.4 - More Controller Specs and Refactoring </h2>
__TOC__
==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].
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.

==The Code You Wish You Had==
'''Example'''

'''TMDb : The Movie Database rails application'''

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.

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.

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>

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.

{|class="wikitable"
|-
!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.
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:
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.
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.

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.

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.

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.

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.
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.

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.
<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:
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.

A typical waterfall model consists of the following sequential phases

It consists of the following sequential phases through which the development life cycle progresses:
<ref>http://www.guru99.com/testing-methodology.html</ref>

[[File: Waterfall_model.png]]

* 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.
* 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:
* 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.
* 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.

Waterfall model has the following disadvantages:
* 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:
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>

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.
<br>
<br>
[[File:Iterative_dev.jpg]]
<br>
<br>
The main advantage of iterative development model is that corrective actions can be taken at end of each iteration.

The main disadvantages of iterative development model are:
* 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:
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.

<h4>Agile Methodology</h4>
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.
<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 .

Testing approach:
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.

<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>

Following is an example of a cucumber scenario in the BackChannel app:
<pre>
Feature: User can add post

Scenario: Add a post
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>
# 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==
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.

==References==
<references/>

The video of the lecture can be found [https://www.youtube.com/watch?v=Hpg9303P0Ts here].

CSC/ECE 517 Fall 2012/ch2a 2w32 mk

2012-10-27T01:58:11Z

Hpkancha:

<h2>SaaS - 5.4 - More Controller Specs and Refactoring </h2>
__TOC__
==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].
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.

==The Code You Wish You Had==
'''Example'''
'''TMDb : The Movie Database rails application'''
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.

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.

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>

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.

{|class="wikitable"
|-
!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.
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:
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.
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.

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.

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.

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.

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.
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.

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.
<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:
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.

A typical waterfall model consists of the following sequential phases

It consists of the following sequential phases through which the development life cycle progresses:
<ref>http://www.guru99.com/testing-methodology.html</ref>

[[File: Waterfall_model.png]]

* 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.
* 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:
* 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.
* 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.

Waterfall model has the following disadvantages:
* 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:
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>

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.
<br>
<br>
[[File:Iterative_dev.jpg]]
<br>
<br>
The main advantage of iterative development model is that corrective actions can be taken at end of each iteration.

The main disadvantages of iterative development model are:
* 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:
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.

<h4>Agile Methodology</h4>
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.
<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 .

Testing approach:
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.

<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>

Following is an example of a cucumber scenario in the BackChannel app:
<pre>
Feature: User can add post

Scenario: Add a post
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>
# 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==
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.

==References==
<references/>

The video of the lecture can be found [https://www.youtube.com/watch?v=Hpg9303P0Ts here].

CSC/ECE 517 Fall 2012/ch2a 2w32 mk

2012-10-27T01:55:16Z

Hpkancha:

<h2>SaaS - 5.4 - More Controller Specs and Refactoring </h2>
__TOC__
==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].
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.

'''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.

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.

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>

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.

{|class="wikitable"
|-
!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.
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:
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.
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.

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.

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.

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.

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.
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.

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.
<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:
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.

A typical waterfall model consists of the following sequential phases

It consists of the following sequential phases through which the development life cycle progresses:
<ref>http://www.guru99.com/testing-methodology.html</ref>

[[File: Waterfall_model.png]]

* 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.
* 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:
* 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.
* 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.

Waterfall model has the following disadvantages:
* 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:
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>

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.
<br>
<br>
[[File:Iterative_dev.jpg]]
<br>
<br>
The main advantage of iterative development model is that corrective actions can be taken at end of each iteration.

The main disadvantages of iterative development model are:
* 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:
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.

<h4>Agile Methodology</h4>
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.
<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 .

Testing approach:
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.

<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>

Following is an example of a cucumber scenario in the BackChannel app:
<pre>
Feature: User can add post

Scenario: Add a post
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>
# 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==
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.

==References==
<references/>

The video of the lecture can be found [https://www.youtube.com/watch?v=Hpg9303P0Ts here].

CSC/ECE 517 Fall 2012/ch2a 2w32 mk

2012-10-27T01:54:09Z

Hpkancha:

<h2>SaaS - 5.4 - More Controller Specs and Refactoring </h2>
__TOC__
==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].
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.
'''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.

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.

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>

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.

{|class="wikitable"
|-
!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.
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:
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.
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.

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.

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.

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.

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.
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.

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.
<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:
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.

A typical waterfall model consists of the following sequential phases

It consists of the following sequential phases through which the development life cycle progresses:
<ref>http://www.guru99.com/testing-methodology.html</ref>

[[File: Waterfall_model.png]]

* 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.
* 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:
* 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.
* 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.

Waterfall model has the following disadvantages:
* 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:
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>

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.
<br>
<br>
[[File:Iterative_dev.jpg]]
<br>
<br>
The main advantage of iterative development model is that corrective actions can be taken at end of each iteration.

The main disadvantages of iterative development model are:
* 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:
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.

<h4>Agile Methodology</h4>
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.
<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 .

Testing approach:
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.

<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>

Following is an example of a cucumber scenario in the BackChannel app:
<pre>
Feature: User can add post

Scenario: Add a post
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>
# 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==
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.

==References==
<references/>

The video of the lecture can be found [https://www.youtube.com/watch?v=Hpg9303P0Ts here].

CSC/ECE 517 Fall 2012/ch2a 2w32 mk

2012-10-27T01:38:06Z

Hpkancha:

<h2>SaaS - 5.4 - More Controller Specs and Refactoring </h2>
__TOC__
==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].
Gone are the days when the developers used to write code and toss it to the QA team for testing. Today’s developers are far more responsible for testing their own code. Testing these days is far more automated in the sense that the tester doesn’t need to manually check the output if its correct or not. In this document, we give the history of software testing and introduce some of the newer methods that are being used today such as Behavior Driven Development and Test Driven Development.
==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.

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.

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>

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.

{|class="wikitable"
|-
!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.
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:
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.
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.

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.

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.

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.

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.
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.

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.
<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:
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.

A typical waterfall model consists of the following sequential phases

It consists of the following sequential phases through which the development life cycle progresses:
<ref>http://www.guru99.com/testing-methodology.html</ref>

[[File: Waterfall_model.png]]

* 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.
* 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:
* 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.
* 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.

Waterfall model has the following disadvantages:
* 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:
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>

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.
<br>
<br>
[[File:Iterative_dev.jpg]]
<br>
<br>
The main advantage of iterative development model is that corrective actions can be taken at end of each iteration.

The main disadvantages of iterative development model are:
* 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:
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.

<h4>Agile Methodology</h4>
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.
<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 .

Testing approach:
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.

<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>

Following is an example of a cucumber scenario in the BackChannel app:
<pre>
Feature: User can add post

Scenario: Add a post
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>
# 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==
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.

==References==
<references/>

The video of the lecture can be found [https://www.youtube.com/watch?v=Hpg9303P0Ts here].

CSC/ECE 517 Fall 2012/ch2a 2w32 mk

2012-10-27T01:33:18Z

Hpkancha:

= SaaS - 5.4 - More Controller Specs and Refactoring<ref>[https://www.youtube.com/watch?v=ZWvtrc-ysa4&feature=relmfu Video :SaaS - 5.4 - More Controller Specs and Refactoring]</ref><ref>[https://www.youtube.com/watch?v=BU9k5t1yYgQ Video :SaaS - 5.4 - More Controller Specs and Refactoring (Continued)]</ref> =

== Introduction ==
[http://en.wikipedia.org/wiki/Test-driven_development 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>[http://neelnarayan.blogspot.com/2010/07/bdd-is-more-than-tdd-done-right.html 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".
<br/> 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>[http://www.objectmentor.com/resources/articles/WorkingEffectivelyWithLegacyCode.pdf Working Effectively With Legacy Code by Michael Feather]</ref>
<br/>
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>[http://rspec.info/ RSpec]</ref> is a great testing tool, which provides features like :
* textual descriptions of examples and groups ([http://rubydoc.info/gems/rspec-core/frames rspec-core])

* extension for Rails ([http://rubydoc.info/gems/rspec-rails/frames rspec-rails])<br/>If we are testing a rails application specifically (as opposed to an arbitrary Ruby program), we need to be able to simulate<br/>* posting to a controller action<br/>* the ability to examine the expected view

* extensible expectation language ([http://rubydoc.info/gems/rspec-expectations/frames rspec-expectations]), letting an user express expected outcomes of an object.<br/>Uses instance methods like "should" and "should_not" to check for equivalence, identity, regular expressions, etc.
<pre>[1,2,3].should include(1, 2)</pre>

* built-in mocking/stubbing framework ([http://rubydoc.info/gems/rspec-mocks/frames rspec-mocks]): <br/>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.
<pre>obj.should_receive(a).with(b)</pre>
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.

== <span style="color:#FF0000">Red</span> – <span style="color:#32CD32">Green</span> – Refactor ==
The following steps define the TDD cycle :
=== Add a Test ===
* <b>Think about one thing the code should do :</b> The developer identifies a new functionality from the use cases and user stories, which contain detailed requirements and constraints.
* <b>Capture that thought in a test, which<span style="color:#FF0000"> fails </span> :</b> 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 ===
* <b>Write the simplest possible code that lets the test <span style="color:#32CD32"> pass </span> :</b> 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>[http://ruby.about.com/od/advancedruby/a/tdd.htm 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 ===
* <b>DRY out commonality with other tests :</b> 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 =====
#Add the route to <span style="color:blue"> config/routes.rb </span>:<br/>To add a new feature to this Rails application, we first add a route, which maps a URL to the controller method <ref>[http://guides.rubyonrails.org/routing.html Routing in Rails]</ref> <br/><br/><code><span style="color:grey"># Route that posts 'Search TMDb' form </span><br/><span style="color:blue"> post </span> '/<span style="color:red">movies</span>/<span style="color:green">search_tmdb</span>'</code><br/>This route would map to <code> <span style="color:red">Movies</span><span style="color:blue">Controller#</span><span style="color:green">search_tmdb</span></code> owing to [http://en.wikipedia.org/wiki/Convention_over_configuration Convention over Configuration], that is, it would post to the search_tmdb "action" in the Movies "controller".<br/><br/>
#Create an empty view: <br/> 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. "[http://en.wikipedia.org/wiki/Touch_(Unix) touch]" unix command is used to create a file of size 0 bytes. <br/> <br/><code><span style="color:blue">touch app/views/<span style="color:red">movies</span>/<span style="color:green">search_tmdb</span>.html.haml </span></code><br/><br/>The above creates a view in the right directory with the file name, same as Movie controller's method name. (Convention over Configuration) <br/>This view can be refined in later iterations and user stories are used to verify if the view has everything that is needed.<br/><br/>
#Replace fake “hardwired” method in <span style="color:blue">movies_controller.rb</span> with empty method: <br/>If the method has a default functionality to return an empty list, then replace the method to one that does nothing.<br/><br/><code>def search_tmdb<br/>end</code><br/>

=====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.<br/>
One may wonder that to test the controller's functionality, one has to get the model method working. Nevertheless, that is not required.<br/>
Seam is used in this case, to test the code we wish we had(“<span style="color:red">CWWWH</span>”). Let us call the "non-existent" model method as <span style="color:blue">Movie.find_in_tmdb</span>

=====Testing plan=====
#Simulate POSTing search form to controller action.
#Check that controller action tries to call <span style="color:blue">Movie.find_in_tmdb</span> 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.
#The test will fail (<span style="color:red">red</span>), because the (empty) controller method doesnʼt call ﬁnd_in_tmdb.
#Fix controller action to make the test pass (<span style="color:green">green</span>).

=====Test MoviesController : Code<ref>[http://pastebin.com/zKnwphQZ TMDb : MoviesController Test Code]</ref>=====

<pre>
-------- 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
</pre>

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. <br/>

The line <code><b>Movie</b>.<span style="color:violet">should_receive</span>(<span style="color:red">:find_in_tmdb</span>).<span style="color:violet">with</span>('<span style="color:brown">hardware</span>')</code> creates an expectation that the <b>Movie</b> class should receive the <span style="color:red">find_in_tmdb</span> method call with a particular argument. An assumption is made here, that the user has actually filled in <span style="color:brown">hardware</span> in the search_terms box on the page that says Search for TMDb. <br/>

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

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 =====

[https://github.com/rspec/rspec/wiki/autotest 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.<br/>

The test <span style="color:red"> FAILS </span>. <br/>
Reason for error : MoviesController searching TMDb should call the model method that performs TMDb search <br/>
FailureError: Movie.should_receive(:find_in_tmdb).with('hardware')
<span style="color:red"> expected: 1 time
received: 0 times</span>
<br/>
The test is expressing what is expected (identifying the right reason of failure).<br/>
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
<pre>
-------- movies_controller.rb --------

class MoviesController < ApplicationController

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

end
</pre>

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

Tests are run again. The test <span style="color:green">PASSES</span> saying MoviesController searching TMDb should call the model method that performs TMDb search pass with 0 failures.
<br/> The following explains how invoking the non-existent method works and why the test case passed.

===== Use of Seams=====
The test <span style="color:red">fails</span> as the controller is empty and the method does not call <span style="color:blue">find_in_tmdb</span>. The test case is made to <span style="color:green">pass</span> by having the controller action invoke "Movie.<span style="color:blue">find_in_tmdb</span>" (which is, the code we wish we had) with data from submitted form. So here the concept of Seams comes in.<br/>
<span style="color:violet">should_receive</span> uses Rubyʼs open classes to create a seam for <b><i>isolating controller action from
behavior of a missing or buggy controller function</i></b>. Thus, it overrides the <span style="color:blue">find_in_tmdb</span> 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 <span style="color:blue">find_in_tmdb</span> 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 <span style="color:blue">find_in_tmdb</span> 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>[http://en.wikipedia.org/wiki/Test-driven_development#Benefits TDD Advantages]</ref>

==== Disadvantages ====
* Does not scale well with web-based GUI or database development <ref>[http://www.pnexpert.com/files/Test_Driven_Development.pdf 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>[http://en.wikipedia.org/wiki/Test-driven_development#Shortcomings Shortcomings of TDD]</ref>

== References ==
<references/>

== See Also ==
*[http://en.wikipedia.org/wiki/Test-driven_development Wiki page of TDD]
*[http://searchsoftwarequality.techtarget.com/definition/test-driven-development Definition of TDD]
*[http://www.slideshare.net/Skud/test-driven-development-tutorial TDD in different languagues]
*[http://net.tutsplus.com/tutorials/php/the-newbies-guide-to-test-driven-development/ The Newbie’s Guide to Test-Driven Development]
*[http://blog.pluralsight.com/2012/09/11/tdd-vs-bdd/ TDD vs BDD]
=== Books ===
* [http://www.amazon.com/Test-Driven-Development-By-Example/dp/0321146530 Test Driven Development: By Example , Kent Beck]
* [http://www.agiledata.org/essays/tdd.html 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]

CSC/ECE 517 Fall 2012/ch2a 2w32 mk

2012-10-27T01:29:54Z

Hpkancha: Created page with "= SaaS - 5.4 - More Controller Specs and Refactoring<ref>[https://www.youtube.com/watch?v=ZWvtrc-ysa4&feature=relmfu Video :SaaS - 5.4 - More Controller Specs and Refactoring]</r..."

= SaaS - 5.4 - More Controller Specs and Refactoring<ref>[https://www.youtube.com/watch?v=ZWvtrc-ysa4&feature=relmfu Video :SaaS - 5.4 - More Controller Specs and Refactoring]</ref> =

== Introduction ==
[http://en.wikipedia.org/wiki/Test-driven_development 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>[http://neelnarayan.blogspot.com/2010/07/bdd-is-more-than-tdd-done-right.html 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".
<br/> 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>[http://www.objectmentor.com/resources/articles/WorkingEffectivelyWithLegacyCode.pdf Working Effectively With Legacy Code by Michael Feather]</ref>
<br/>
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>[http://rspec.info/ RSpec]</ref> is a great testing tool, which provides features like :
* textual descriptions of examples and groups ([http://rubydoc.info/gems/rspec-core/frames rspec-core])

* extension for Rails ([http://rubydoc.info/gems/rspec-rails/frames rspec-rails])<br/>If we are testing a rails application specifically (as opposed to an arbitrary Ruby program), we need to be able to simulate<br/>* posting to a controller action<br/>* the ability to examine the expected view

* extensible expectation language ([http://rubydoc.info/gems/rspec-expectations/frames rspec-expectations]), letting an user express expected outcomes of an object.<br/>Uses instance methods like "should" and "should_not" to check for equivalence, identity, regular expressions, etc.
<pre>[1,2,3].should include(1, 2)</pre>

* built-in mocking/stubbing framework ([http://rubydoc.info/gems/rspec-mocks/frames rspec-mocks]): <br/>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.
<pre>obj.should_receive(a).with(b)</pre>
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.

== <span style="color:#FF0000">Red</span> – <span style="color:#32CD32">Green</span> – Refactor ==
The following steps define the TDD cycle :
=== Add a Test ===
* <b>Think about one thing the code should do :</b> The developer identifies a new functionality from the use cases and user stories, which contain detailed requirements and constraints.
* <b>Capture that thought in a test, which<span style="color:#FF0000"> fails </span> :</b> 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 ===
* <b>Write the simplest possible code that lets the test <span style="color:#32CD32"> pass </span> :</b> 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>[http://ruby.about.com/od/advancedruby/a/tdd.htm 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 ===
* <b>DRY out commonality with other tests :</b> 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 =====
#Add the route to <span style="color:blue"> config/routes.rb </span>:<br/>To add a new feature to this Rails application, we first add a route, which maps a URL to the controller method <ref>[http://guides.rubyonrails.org/routing.html Routing in Rails]</ref> <br/><br/><code><span style="color:grey"># Route that posts 'Search TMDb' form </span><br/><span style="color:blue"> post </span> '/<span style="color:red">movies</span>/<span style="color:green">search_tmdb</span>'</code><br/>This route would map to <code> <span style="color:red">Movies</span><span style="color:blue">Controller#</span><span style="color:green">search_tmdb</span></code> owing to [http://en.wikipedia.org/wiki/Convention_over_configuration Convention over Configuration], that is, it would post to the search_tmdb "action" in the Movies "controller".<br/><br/>
#Create an empty view: <br/> 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. "[http://en.wikipedia.org/wiki/Touch_(Unix) touch]" unix command is used to create a file of size 0 bytes. <br/> <br/><code><span style="color:blue">touch app/views/<span style="color:red">movies</span>/<span style="color:green">search_tmdb</span>.html.haml </span></code><br/><br/>The above creates a view in the right directory with the file name, same as Movie controller's method name. (Convention over Configuration) <br/>This view can be refined in later iterations and user stories are used to verify if the view has everything that is needed.<br/><br/>
#Replace fake “hardwired” method in <span style="color:blue">movies_controller.rb</span> with empty method: <br/>If the method has a default functionality to return an empty list, then replace the method to one that does nothing.<br/><br/><code>def search_tmdb<br/>end</code><br/>

=====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.<br/>
One may wonder that to test the controller's functionality, one has to get the model method working. Nevertheless, that is not required.<br/>
Seam is used in this case, to test the code we wish we had(“<span style="color:red">CWWWH</span>”). Let us call the "non-existent" model method as <span style="color:blue">Movie.find_in_tmdb</span>

=====Testing plan=====
#Simulate POSTing search form to controller action.
#Check that controller action tries to call <span style="color:blue">Movie.find_in_tmdb</span> 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.
#The test will fail (<span style="color:red">red</span>), because the (empty) controller method doesnʼt call ﬁnd_in_tmdb.
#Fix controller action to make the test pass (<span style="color:green">green</span>).

=====Test MoviesController : Code<ref>[http://pastebin.com/zKnwphQZ TMDb : MoviesController Test Code]</ref>=====

<pre>
-------- 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
</pre>

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. <br/>

The line <code><b>Movie</b>.<span style="color:violet">should_receive</span>(<span style="color:red">:find_in_tmdb</span>).<span style="color:violet">with</span>('<span style="color:brown">hardware</span>')</code> creates an expectation that the <b>Movie</b> class should receive the <span style="color:red">find_in_tmdb</span> method call with a particular argument. An assumption is made here, that the user has actually filled in <span style="color:brown">hardware</span> in the search_terms box on the page that says Search for TMDb. <br/>

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

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 =====

[https://github.com/rspec/rspec/wiki/autotest 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.<br/>

The test <span style="color:red"> FAILS </span>. <br/>
Reason for error : MoviesController searching TMDb should call the model method that performs TMDb search <br/>
FailureError: Movie.should_receive(:find_in_tmdb).with('hardware')
<span style="color:red"> expected: 1 time
received: 0 times</span>
<br/>
The test is expressing what is expected (identifying the right reason of failure).<br/>
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
<pre>
-------- movies_controller.rb --------

class MoviesController < ApplicationController

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

end
</pre>

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

Tests are run again. The test <span style="color:green">PASSES</span> saying MoviesController searching TMDb should call the model method that performs TMDb search pass with 0 failures.
<br/> The following explains how invoking the non-existent method works and why the test case passed.

===== Use of Seams=====
The test <span style="color:red">fails</span> as the controller is empty and the method does not call <span style="color:blue">find_in_tmdb</span>. The test case is made to <span style="color:green">pass</span> by having the controller action invoke "Movie.<span style="color:blue">find_in_tmdb</span>" (which is, the code we wish we had) with data from submitted form. So here the concept of Seams comes in.<br/>
<span style="color:violet">should_receive</span> uses Rubyʼs open classes to create a seam for <b><i>isolating controller action from
behavior of a missing or buggy controller function</i></b>. Thus, it overrides the <span style="color:blue">find_in_tmdb</span> 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 <span style="color:blue">find_in_tmdb</span> 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 <span style="color:blue">find_in_tmdb</span> 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>[http://en.wikipedia.org/wiki/Test-driven_development#Benefits TDD Advantages]</ref>

==== Disadvantages ====
* Does not scale well with web-based GUI or database development <ref>[http://www.pnexpert.com/files/Test_Driven_Development.pdf 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>[http://en.wikipedia.org/wiki/Test-driven_development#Shortcomings Shortcomings of TDD]</ref>

== References ==
<references/>

== See Also ==
*[http://en.wikipedia.org/wiki/Test-driven_development Wiki page of TDD]
*[http://searchsoftwarequality.techtarget.com/definition/test-driven-development Definition of TDD]
*[http://www.slideshare.net/Skud/test-driven-development-tutorial TDD in different languagues]
*[http://net.tutsplus.com/tutorials/php/the-newbies-guide-to-test-driven-development/ The Newbie’s Guide to Test-Driven Development]
*[http://blog.pluralsight.com/2012/09/11/tdd-vs-bdd/ TDD vs BDD]
=== Books ===
* [http://www.amazon.com/Test-Driven-Development-By-Example/dp/0321146530 Test Driven Development: By Example , Kent Beck]
* [http://www.agiledata.org/essays/tdd.html 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]

CSC/ECE 517 Fall 2012

2012-10-27T01:22:55Z

Hpkancha:

*[[CSC/ECE 517 Fall 2012/ch1 n xx]]
*[[CSC/ECE 517 Fall 2012/ch1 1w1 rk]]
*[[CSC/ECE 517 Fall 2012/ch1 1w20 pp]]
*[[CSC/ECE 517 Fall 2012/ch1 1w5 su]]
*[[CSC/ECE 517 Fall 2012/ch1 1w6 pp]]
*[[CSC/ECE 517 Fall 2012/ch1 1w4 aj]]
*[[CSC/ECE 517 Fall 2012/ch1 1w7 am]]
*[[CSC/ECE 517 Fall 2012/ch1 1w8 aa]]
*[[CSC/ECE 517 Fall 2012/ch1 1w9 av]]
*[[CSC/ECE 517 Fall 2012/ch1 1w10 pk]]
*[[CSC/ECE 517 Fall 2012/ch1 1w11 ap]]
*[[CSC/ECE 517 Fall 2012/ch1a 1w12 mv]]
*[[CSC/ECE 517 Fall 2012/ch1 1w14 gv]]
*[[CSC/ECE 517 Fall 2012/ch1 1w17 ir]]
*[[CSC/ECE 517 Fall 2012/ch1 1w18 as]]
*[[CSC/ECE 517 Fall 2012/ch1 1w22 an]]
*[[CSC/ECE 517 Fall 2012/ch1 1w21 aa]]
*[[CSC/ECE 517 Fall 2012/ch1 1w21 wi]]
*[[CSC/ECE 517 Fall 2012/ch1 1w31 sa]]
*[[CSC/ECE 517 Fall 2012/ch1a 1w16 br]]
*[[CSC/ECE 517 Fall 2012/ch1a 1w23 as]]
*[[CSC/ECE 517 Fall 2012/ch1 1w24 nr]]
*[[CSC/ECE 517 Fall 2012/ch1 1w15 rt]]
*[[CSC/ECE 517 Fall 2012/ch1 1w3 pl]]
*[[CSC/ECE 517 Fall 2012/ch1 1w32 cm]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w5 dp]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w37 ss]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w67 ks]]

*[[CSC/ECE 517 Fall 2012/ch1 1w27 ms]]
*[[CSC/ECE 517 Fall 2012/ch1 1w29 sa]]
*[[CSC/ECE 517 Fall 2012/ch1 1w33 op]]
*[[CSC/ECE 517 Fall 2012/ch1 1w19 sa]]
*[[CSC/ECE 517 Fall 2012/ch1 1w34 vd]]
*[[CSC/ECE 517 Fall 2012/ch1 1w35 sa]]
*[[CSC/ECE 517 Fall 2012/ch1 1w30 rp]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w58 am]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w47 sk]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w69 mv]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w44 as]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w45 is]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w53 kc]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w40 ar]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w39 sn]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w54 go]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w56 ms]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w64 nn]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w66 as]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w40 as]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w42 js]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w46 sm]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w71 gs]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w63 dv]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w55 ms]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w57 mp]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w52 an]]
*[[CSC/ECE_517_Fall_2012/ch1b 1w38 nm]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w60 ac]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w62 rb]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w29 st]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w30 an]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w17 pt]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w31 up]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w9 ms]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w19 is]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w26 aj]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w5 dp]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w16 dp]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w8 vp]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w18 as]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w3 jm]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w23 sr]]
*[[CSC/ECE_517_Fall_2012/ch2a_2w11_aa]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w15 rr]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w33 pv]]
*[[CSC/ECE_517_Fall_2012/ch2a_2w20_aa]]
*[[CSC/ECE_517_Fall_2012/ch2a_2w14_bb]]
*[[CSC/ECE_517_Fall_2012/ch2a_2w21_ap]]
*[[CSC/ECE_517_Fall_2012/ch2a_2w13_sm]]
*[[CSC/ECE_517_Fall_2012/ch2a_2w4_sa]]
*[[CSC/ECE_517_Fall_2012/ch2a_2w25_nr]]
*[[CSC/ECE_517_Fall_2012/ch2a_2w12_sv]]
*[[CSC/ECE_517_Fall_2012/ch2a_2w7_ma]]
*[[CSC/ECE_517_Fall_2012/ch2a_2w6_ar]]
*[[CSC/ECE_517_Fall_2012/ch2a_2w3_sm]]
*[[CSC/ECE_517_Fall_2012/ch2a_2w32_mk]]

CSC/ECE 517 Fall 2012/ch1b 1w53 kc

2012-09-28T05:04:29Z

Hpkancha:

'''Metaprogramming in dynamically typed languages'''

----

==Introduction==
One of the most under-used programming techniques is writing programs that generate programs or program parts. Code-generating programs are sometimes called metaprograms; writing such programs is called metaprogramming. Writing programs that write code has numerous applications. In this article, we will learn why [http://en.wikipedia.org/wiki/Metaprogramming metaprogramming] is necessary and look at some of the components of metaprogramming in [http://en.wikipedia.org/wiki/Dynamic_programming_language dynamically typed languages].

==What is Metaprogramming?==
Metaprogramming is the writing of computer programs that write or manipulate other programs (or themselves) as their data, or that do part of the work at compile time that would otherwise be done at runtime. In some cases, this allows programmers to minimize the number of lines of code to express a solution (hence reducing development time), or it gives programs greater flexibility to efficiently handle new situations without recompilation. Typically, you use a metaprogram to eliminate or reduce a tedious or error-prone programming task. So, for example, instead of writing a machine code program by hand, you would use a high-level language, such as C, and then let the C compiler do the translation to the equivalent low-level machine instructions.

==Metaprogramming Example==
Let us consider one big main function with 1,000 printf instructions.

#include <stdio.h>
int main(void) {
printf("1. I must not chat in class.\n");
printf("2. I must not chat in class.\n");
/* 996 printf instructions omitted. */
printf("999. I must not chat in class.\n");
printf("1000. I must not chat in class.\n");
return 0;
}

Taking the above pseudo code example, we can see how that can be made much simpler and elegant using a metaprogram in Ruby.

File.open('punishment.c', 'w') do |output|
output.puts '#include <stdio.h>'
output.puts 'int main(void) {'
1.upto(1000) do |i|
output.puts " printf(\"#{i}. " +
"I must not chat in class.\\n\");"
end
output.puts ' return 0;'
output.puts '}'
end

This code creates a file called punishment.c with the expected 1,000+ lines of C source code

==Dynamically Typed Programming Languages==
Before defining what dynamic typing is, it is easiest to define its opposite. [http://www.sitepoint.com/typing-versus-dynamic-typing/ Statically typed languages] are those which define and enforce types at compile-time. Statically typed languages typically have clearly distinct compile-time and run-time phases, with program code converted by a compiler into a binary executable which is then run separately. Dynamically typed languages have distinct compilation and execution phases and therefore we use the terms compile-time and run-time identically for both statically and dynamically typed languages. In most dynamically typed languages (e.g. Ruby, Perl, and Python) ‘running’ a file both compiles and executes it.

==Metaprogramming in Dynamically Typed Languages==

Metaprogramming can not only be used for programs to write programs, it can also be used to manipulate itself at runtime. Let us look at some examples that do this in ruby and the equivalent code in Javascript and Python.

===Adding a method dynamically to a class===
We can reopen an already existing class/prototype and add a new method to it dynamically. In ruby we reopen the class simply using the class keyword. In Javascript we grab the prototype for our object and just attach a new function.

====Ruby====
class Ninja
def battle_cry
puts "#{name} says zing!!!"
end
end
drew.battle_cry
# => Drew says zing!!!
adam.battle_cry
# => Adam says zing!!!

====JavaScript====
Ninja.prototype.battleCry = function () {
puts(this.name + " says zing!!!");
}
drew.battleCry();
// => Drew says zing!!!
adam.battleCry();
// => Adam says zing!!!

====Python====
def battle_cry(self):
print '%s says zing!!!' % self.name
Ninja.battle_cry = battle_cry
drew.battle_cry()
# => Drew says zing!!!
adam.battle_cry()
# => Adam says zing!!!

===Invoking a method dynamically===
The next thing we’ll look at is calling methods dynamically. The ability to call a method with a name given to us at runtime is a powerful tool in [http://en.wikipedia.org/wiki/Domain-specific_language DSL] creation and metaprogramming. Here’s the code. In case of Ruby, we supply the method name as a string and invoke it.

====Ruby====
drew.send(:battle_cry)
# => Drew says zing!!!

====JavaScript====
drew['battleCry']();
// => Drew says zing!!!

====Python====
drew.__getattribute__('battle_cry')()
# => Drew says zing!!!

===Defining class level methods dynamically with closures===
Here a class level method is defined which closes over some of the attributes in its context (in this case the method color is able to access the variable color_name as a closure). In Ruby, we’re using send to call define_method. This is a trick (hack) in ruby that allows us to call private methods without self being the implicit receiver. define_method takes a name for the new method and a block which describes the body of the method. In ruby, this block is a [http://en.wikipedia.org/wiki/Closure_%28computer_science%29 closure] which means we have access to the scope at the time of the method definition. In Javascript example, Javascript functions are closures. This means we get the ability to capture the scope at the time of definition for free. The ubiquity of closures in Javascript is extremely powerful and, as we have seen so far, makes metaprogramming very easy.

====Ruby====
color_name = 'black'
Ninja.send(:define_method, 'color') do
puts "#{name}'s color is #{color_name}"
end
drew.color
# => Drew's color is black
adam.color
# => Adam's color is black

====JavaScript====
var colorName = "black";
Ninja.prototype['color'] = function () {
puts(this.name + "'s color is " + colorName);
}
drew.color();
// => Drew's color is black
adam.color();
// => Adam's color is black

====Python====
color_name = 'black'
def color(self):
print "%s's color is %s" % (self.name, color_name)
Ninja.color = color
drew.color()
# => Drew's color is black
adam.color()
# => Adam's color is black

==Putting it all together==
How does metaprogamming work with dynamic typed languages?

*Interpreted Languages
Most dynamic languages are interpreted, not compiled. The basic idea here is for the code to be interpreted at run-time, allows generic objects to dynamically interact with each other. This interaction in itself is potentially manipulating the behavior of the program as it is executing. Generic objects are not the only uniqueness of an interpreted language, the 'eval' statement is something else to consider. The ability to evaluate an expression via the 'eval' statement allows for the program to redefine functions at run-time. These two capabilities for dynamic languages have become immensely valuable to programmers.

*Dynamic methods
These types of methods are very flexible. The program have have an object created from a class, then you can add additional methods to the instance of that class. Therefore manipulating the program at run time by allowing for only this instance of the object to have additional methods. Not to be confused with extending classes or adding additional methods to classes.

*Singletons classes
Singleton classes should not be mistake for the Singleton design pattern. These types of classes available in some dynamic languages allow for [http://en.wikipedia.org/wiki/Dynamic_dispatch dynamic dispatching]. An common technique often used on singleton classes is to add dynamic methods to the instance.

*"Everything is an object"
Many languages a 'weak-typed' which means that potentially anything can be anything else. The most obvious way to have this behavior is by making everything an object. What historically are considered primitive data types now are all considered objects (e.g. string, integers, etc). In some of these languages even functions and procedures are considered objects. In some languages such as Ruby, even classes are Objects since they (as well as everything else) inherits from Object. Since classes can be used to define, extend, or redefine other classes (often referred to as a [http://en.wikipedia.org/wiki/Metaclass metaclass]) this is also potentially changing the behavior of the original program.

Some other traits of some common dynamic languages worth mentioning are: the use of method_missing, [http://en.wikipedia.org/wiki/Introspection introspection], [http://en.wikipedia.org/wiki/Lazy_loading lazy loading], [http://en.wikipedia.org/wiki/Declarative_programming declarative code], extensible type system, and method aliasing.

==Advantages & Disadvantages==

===Advantages===
* Using metaprogramming, you can create more expressive [http://en.wikipedia.org/wiki/Application_programming_interface APIs] (for example ActiveRecord uses metaprogramming to define accessor methods based on a table's column names, so you can write things like person.age instead of something like person.read_attribute("age"), where person is an active record object and the people table has a column called age) and you can accomplish some things with significantly less code than you otherwise would.

* Performance: Meta-programs represent data to be processed in terms of the low level data structures used by the script interpreter to represent the scripting language itself. Therefore, instead of being processed by an interpreted script manipulating script-level data structures, the data is processed by the compiled code of the language interpreter manipulating low level data structures directly. This removes the levels of indirection that slow down the execution of scripts, and so results in significant performance improvements.

===Disadvanatges===
* Metaprogramming code can be very difficult to read and understand: that is because the metaprogramming code will not necessarily express what the code it is creating is about, but only how it is creating that code. As such the code it is creating can be invisible to you as a reader of the source code - the created code will only start to exist at runtime. One would therefore expect that programmers would try especially hard when they metaprogram to make that particular kind of code expressive and easy to understand.

* Another consequence of the fact that the code produced by metaprogramming is not necessarily visible, is that debugging becomes more difficult: when analyzing problems you’ll not only be unsure how the programm works, but in addition, you won’t even be sure how the code that is executed looks like - since it is only generated at runtime.

==Conclusion==
Dynamic languages are increasingly recognized for playing a major role in software development, specifically for quick prototyping because of the forgiveness of the languages letting requirements evolve. These languages are historically looked at as scripting languages that are inexpensive and not scalable. Once you're familiar with the techniques, metaprogramming is not as complicated as it might sound initially. Metaprogramming allows you to automate error-prone or repetitive programming tasks. You can use it to pre-generate data tables, to generate boilerplate code automatically that can't be abstracted into a function, or even to test your ingenuity on writing self-replicating code.

==References==
Websites:
#http://en.wikipedia.org/wiki/Metaprogramming
#http://en.wikipedia.org/wiki/Dynamic_programming_language
#http://en.wikipedia.org/wiki/Application_programming_interface
#http://www.linuxjournal.com/article/9604
#http://www.ibm.com/developerworks/linux/library/l-metaprog1/index.html
#http://tratt.net/laurie/research/publications/html/tratt__dynamically_typed_languages/
#http://www.sitepoint.com/typing-versus-dynamic-typing/
#http://www.bias2build.com/thesis/ruby_v_js_MP.html
#http://codeblog.dhananjaynene.com/2010/01/dynamically-adding-methods-with-metaprogramming-ruby-and-python/
#http://fingernailsinoatmeal.com/post/292301859/metaprogramming-ruby-vs-javascript
#http://www.ibm.com/developerworks/linux/library/l-pymeta/index.html

Books/Articles:
#Tratt, L. 2005. Compile-time meta-programming in a dynamically typed OO language. In Proceedings of the 2005 Symposium on Dynamic Languages (San Diego, California, October 18 - 18, 2005). DLS '05. ACM, New York, NY, 49-63. http://doi.acm.org.www.lib.ncsu.edu:2048/10.1145/1146841.1146846
#Tratt, L. 2009. Dynamically typed languages, Advances in Computers, 77, pp. 149-184
#Perrotta, P. 2010. Metaprogramming Ruby: Program Like the Ruby Pros

CSC/ECE 517 Fall 2012/ch1b 1w53 kc

2012-09-28T05:01:20Z

Hpkancha:

'''Metaprogramming in dynamically typed languages'''

----

==Introduction==
One of the most under-used programming techniques is writing programs that generate programs or program parts. Code-generating programs are sometimes called metaprograms; writing such programs is called metaprogramming. Writing programs that write code has numerous applications. In this article, we will learn why [http://en.wikipedia.org/wiki/Metaprogramming metaprogramming] is necessary and look at some of the components of metaprogramming in [http://en.wikipedia.org/wiki/Dynamic_programming_language dynamically typed languages].

==What is Metaprogramming?==
Metaprogramming is the writing of computer programs that write or manipulate other programs (or themselves) as their data, or that do part of the work at compile time that would otherwise be done at runtime. In some cases, this allows programmers to minimize the number of lines of code to express a solution (hence reducing development time), or it gives programs greater flexibility to efficiently handle new situations without recompilation. Typically, you use a metaprogram to eliminate or reduce a tedious or error-prone programming task. So, for example, instead of writing a machine code program by hand, you would use a high-level language, such as C, and then let the C compiler do the translation to the equivalent low-level machine instructions.

==Metaprogramming Example==
Let us consider one big main function with 1,000 printf instructions.

#include <stdio.h>
int main(void) {
printf("1. I must not chat in class.\n");
printf("2. I must not chat in class.\n");
/* 996 printf instructions omitted. */
printf("999. I must not chat in class.\n");
printf("1000. I must not chat in class.\n");
return 0;
}

Taking the above pseudo code example, we can see how that can be made much simpler and elegant using a metaprogram in Ruby.

File.open('punishment.c', 'w') do |output|
output.puts '#include <stdio.h>'
output.puts 'int main(void) {'
1.upto(1000) do |i|
output.puts " printf(\"#{i}. " +
"I must not chat in class.\\n\");"
end
output.puts ' return 0;'
output.puts '}'
end

This code creates a file called punishment.c with the expected 1,000+ lines of C source code

==Dynamically Typed Programming Languages==
Before defining what dynamic typing is, it is easiest to define its opposite. [http://www.sitepoint.com/typing-versus-dynamic-typing/ Statically typed languages] are those which define and enforce types at compile-time. Statically typed languages typically have clearly distinct compile-time and run-time phases, with program code converted by a compiler into a binary executable which is then run separately. Dynamically typed languages have distinct compilation and execution phases and therefore we use the terms compile-time and run-time identically for both statically and dynamically typed languages. In most dynamically typed languages (e.g. Ruby, Perl, and Python) ‘running’ a file both compiles and executes it.

==Metaprogramming in Dynamically Typed Languages==

Metaprogramming can not only be used for programs to write programs, it can also be used to manipulate itself at runtime. Let us look at some examples that do this in ruby and the equivalent code in Javascript and Python.

===Adding a method dynamically to a class===
We can reopen an already existing class/prototype and add a new method to it dynamically. In ruby we reopen the class simply using the class keyword. In Javascript we grab the prototype for our object and just attach a new function.

====Ruby====
class Ninja
def battle_cry
puts "#{name} says zing!!!"
end
end
drew.battle_cry
# => Drew says zing!!!
adam.battle_cry
# => Adam says zing!!!

====JavaScript====
Ninja.prototype.battleCry = function () {
puts(this.name + " says zing!!!");
}
drew.battleCry();
// => Drew says zing!!!
adam.battleCry();
// => Adam says zing!!!

====Python====
def battle_cry(self):
print '%s says zing!!!' % self.name
Ninja.battle_cry = battle_cry
drew.battle_cry()
# => Drew says zing!!!
adam.battle_cry()
# => Adam says zing!!!

===Invoking a method dynamically===
The next thing we’ll look at is calling methods dynamically. The ability to call a method with a name given to us at runtime is a powerful tool in [http://en.wikipedia.org/wiki/Domain-specific_language DSL] creation and metaprogramming. Here’s the code. In case of Ruby, we supply the method name as a string and invoke it.

====Ruby====
drew.send(:battle_cry)
# => Drew says zing!!!

====JavaScript====
drew['battleCry']();
// => Drew says zing!!!

====Python====
drew.__getattribute__('battle_cry')()
# => Drew says zing!!!

===Defining class level methods dynamically with closures===
Here a class level method is defined which closes over some of the attributes in its context (in this case the method color is able to access the variable color_name as a closure). In Ruby, we’re using send to call define_method. This is a trick (hack) in ruby that allows us to call private methods without self being the implicit receiver. define_method takes a name for the new method and a block which describes the body of the method. In ruby, this block is a closure which means we have access to the scope at the time of the method definition. In Javascript example, Javascript functions are closures. This means we get the ability to capture the scope at the time of definition for free. The ubiquity of closures in Javascript is extremely powerful and, as we have seen so far, makes metaprogramming very easy.

====Ruby====
color_name = 'black'
Ninja.send(:define_method, 'color') do
puts "#{name}'s color is #{color_name}"
end
drew.color
# => Drew's color is black
adam.color
# => Adam's color is black

====JavaScript====
var colorName = "black";
Ninja.prototype['color'] = function () {
puts(this.name + "'s color is " + colorName);
}
drew.color();
// => Drew's color is black
adam.color();
// => Adam's color is black

====Python====
color_name = 'black'
def color(self):
print "%s's color is %s" % (self.name, color_name)
Ninja.color = color
drew.color()
# => Drew's color is black
adam.color()
# => Adam's color is black

==Putting it all together==
How does metaprogamming work with dynamic typed languages?

*Interpreted Languages
Most dynamic languages are interpreted, not compiled. The basic idea here is for the code to be interpreted at run-time, allows generic objects to dynamically interact with each other. This interaction in itself is potentially manipulating the behavior of the program as it is executing. Generic objects are not the only uniqueness of an interpreted language, the 'eval' statement is something else to consider. The ability to evaluate an expression via the 'eval' statement allows for the program to redefine functions at run-time. These two capabilities for dynamic languages have become immensely valuable to programmers.

*Dynamic methods
These types of methods are very flexible. The program have have an object created from a class, then you can add additional methods to the instance of that class. Therefore manipulating the program at run time by allowing for only this instance of the object to have additional methods. Not to be confused with extending classes or adding additional methods to classes.

*Singletons classes
Singleton classes should not be mistake for the Singleton design pattern. These types of classes available in some dynamic languages allow for [http://en.wikipedia.org/wiki/Dynamic_dispatch dynamic dispatching]. An common technique often used on singleton classes is to add dynamic methods to the instance.

*"Everything is an object"
Many languages a 'weak-typed' which means that potentially anything can be anything else. The most obvious way to have this behavior is by making everything an object. What historically are considered primitive data types now are all considered objects (e.g. string, integers, etc). In some of these languages even functions and procedures are considered objects. In some languages such as Ruby, even classes are Objects since they (as well as everything else) inherits from Object. Since classes can be used to define, extend, or redefine other classes (often referred to as a [http://en.wikipedia.org/wiki/Metaclass metaclass]) this is also potentially changing the behavior of the original program.

Some other traits of some common dynamic languages worth mentioning are: the use of method_missing, [http://en.wikipedia.org/wiki/Introspection introspection], [http://en.wikipedia.org/wiki/Lazy_loading lazy loading], [http://en.wikipedia.org/wiki/Declarative_programming declarative code], extensible type system, and method aliasing.

==Advantages & Disadvantages==

===Advantages===
* Using metaprogramming, you can create more expressive [http://en.wikipedia.org/wiki/Application_programming_interface APIs] (for example ActiveRecord uses metaprogramming to define accessor methods based on a table's column names, so you can write things like person.age instead of something like person.read_attribute("age"), where person is an active record object and the people table has a column called age) and you can accomplish some things with significantly less code than you otherwise would.

* Performance: Meta-programs represent data to be processed in terms of the low level data structures used by the script interpreter to represent the scripting language itself. Therefore, instead of being processed by an interpreted script manipulating script-level data structures, the data is processed by the compiled code of the language interpreter manipulating low level data structures directly. This removes the levels of indirection that slow down the execution of scripts, and so results in significant performance improvements.

===Disadvanatges===
* Metaprogramming code can be very difficult to read and understand: that is because the metaprogramming code will not necessarily express what the code it is creating is about, but only how it is creating that code. As such the code it is creating can be invisible to you as a reader of the source code - the created code will only start to exist at runtime. One would therefore expect that programmers would try especially hard when they metaprogram to make that particular kind of code expressive and easy to understand.

* Another consequence of the fact that the code produced by metaprogramming is not necessarily visible, is that debugging becomes more difficult: when analyzing problems you’ll not only be unsure how the programm works, but in addition, you won’t even be sure how the code that is executed looks like - since it is only generated at runtime.

==Conclusion==
Dynamic languages are increasingly recognized for playing a major role in software development, specifically for quick prototyping because of the forgiveness of the languages letting requirements evolve. These languages are historically looked at as scripting languages that are inexpensive and not scalable. Once you're familiar with the techniques, metaprogramming is not as complicated as it might sound initially. Metaprogramming allows you to automate error-prone or repetitive programming tasks. You can use it to pre-generate data tables, to generate boilerplate code automatically that can't be abstracted into a function, or even to test your ingenuity on writing self-replicating code.

==References==
Websites:
#http://en.wikipedia.org/wiki/Metaprogramming
#http://en.wikipedia.org/wiki/Dynamic_programming_language
#http://en.wikipedia.org/wiki/Application_programming_interface
#http://www.linuxjournal.com/article/9604
#http://www.ibm.com/developerworks/linux/library/l-metaprog1/index.html
#http://tratt.net/laurie/research/publications/html/tratt__dynamically_typed_languages/
#http://www.sitepoint.com/typing-versus-dynamic-typing/
#http://www.bias2build.com/thesis/ruby_v_js_MP.html
#http://codeblog.dhananjaynene.com/2010/01/dynamically-adding-methods-with-metaprogramming-ruby-and-python/
#http://fingernailsinoatmeal.com/post/292301859/metaprogramming-ruby-vs-javascript
#http://www.ibm.com/developerworks/linux/library/l-pymeta/index.html

Books/Articles:
#Tratt, L. 2005. Compile-time meta-programming in a dynamically typed OO language. In Proceedings of the 2005 Symposium on Dynamic Languages (San Diego, California, October 18 - 18, 2005). DLS '05. ACM, New York, NY, 49-63. http://doi.acm.org.www.lib.ncsu.edu:2048/10.1145/1146841.1146846
#Tratt, L. 2009. Dynamically typed languages, Advances in Computers, 77, pp. 149-184
#Perrotta, P. 2010. Metaprogramming Ruby: Program Like the Ruby Pros

CSC/ECE 517 Fall 2012/ch1b 1w53 kc

2012-09-28T04:55:25Z

Hpkancha:

'''Metaprogramming in dynamically typed languages'''

----

==Introduction==
One of the most under-used programming techniques is writing programs that generate programs or program parts. Code-generating programs are sometimes called metaprograms; writing such programs is called metaprogramming. Writing programs that write code has numerous applications. In this article, we will learn why [http://en.wikipedia.org/wiki/Metaprogramming metaprogramming] is necessary and look at some of the components of metaprogramming in [http://en.wikipedia.org/wiki/Dynamic_programming_language dynamically typed languages].

==What is Metaprogramming?==
Metaprogramming is the writing of computer programs that write or manipulate other programs (or themselves) as their data, or that do part of the work at compile time that would otherwise be done at runtime. In some cases, this allows programmers to minimize the number of lines of code to express a solution (hence reducing development time), or it gives programs greater flexibility to efficiently handle new situations without recompilation. Typically, you use a metaprogram to eliminate or reduce a tedious or error-prone programming task. So, for example, instead of writing a machine code program by hand, you would use a high-level language, such as C, and then let the C compiler do the translation to the equivalent low-level machine instructions.

==Metaprogramming Example==
Let us consider one big main function with 1,000 printf instructions.

#include <stdio.h>
int main(void) {
printf("1. I must not chat in class.\n");
printf("2. I must not chat in class.\n");
/* 996 printf instructions omitted. */
printf("999. I must not chat in class.\n");
printf("1000. I must not chat in class.\n");
return 0;
}

Taking the above pseudo code example, we can see how that can be made much simpler and elegant using a metaprogram in Ruby.

File.open('punishment.c', 'w') do |output|
output.puts '#include <stdio.h>'
output.puts 'int main(void) {'
1.upto(1000) do |i|
output.puts " printf(\"#{i}. " +
"I must not chat in class.\\n\");"
end
output.puts ' return 0;'
output.puts '}'
end

This code creates a file called punishment.c with the expected 1,000+ lines of C source code

==Dynamically Typed Programming Languages==
Before defining what dynamic typing is, it is easiest to define its opposite. [http://www.sitepoint.com/typing-versus-dynamic-typing/ Statically typed languages] are those which define and enforce types at compile-time. Statically typed languages typically have clearly distinct compile-time and run-time phases, with program code converted by a compiler into a binary executable which is then run separately. Dynamically typed languages have distinct compilation and execution phases and therefore we use the terms compile-time and run-time identically for both statically and dynamically typed languages. In most dynamically typed languages (e.g. Ruby, Perl, and Python) ‘running’ a file both compiles and executes it.

==Metaprogramming in Dynamically Typed Languages==

Metaprogramming can not only be used for programs to write programs, it can also be used to manipulate itself at runtime. Let us look at some examples that do this in ruby and the equivalent code in Javascript and Python.

===Adding a method dynamically to a class===
We can reopen an already existing class/prototype and add a new method to it dynamically. In ruby we reopen the class simply using the class keyword. In Javascript we grab the prototype for our object and just attach a new function.

====Ruby====
class Ninja
def battle_cry
puts "#{name} says zing!!!"
end
end
drew.battle_cry
# => Drew says zing!!!
adam.battle_cry
# => Adam says zing!!!

====JavaScript====
Ninja.prototype.battleCry = function () {
puts(this.name + " says zing!!!");
}
drew.battleCry();
// => Drew says zing!!!
adam.battleCry();
// => Adam says zing!!!

====Python====
def battle_cry(self):
print '%s says zing!!!' % self.name
Ninja.battle_cry = battle_cry
drew.battle_cry()
# => Drew says zing!!!
adam.battle_cry()
# => Adam says zing!!!

===Invoking a method dynamically===
The next thing we’ll look at is calling methods dynamically. The ability to call a method with a name given to us at runtime is a powerful tool in [http://en.wikipedia.org/wiki/Domain-specific_language DSL] creation and metaprogramming. Here’s the code. In case of Ruby, we supply the method name as a string and invoke it.

====Ruby====
drew.send(:battle_cry)
# => Drew says zing!!!

====JavaScript====
drew['battleCry']();
// => Drew says zing!!!

====Python====
drew.__getattribute__('battle_cry')()
# => Drew says zing!!!

===Defining class level methods dynamically with closures===
Here a class level method is defined which closes over some of the attributes in its context (in this case the method color is able to access the variable color_name as a closure). In Ruby, we’re using send to call define_method. This is a trick (hack) in ruby that allows us to call private methods without self being the implicit receiver. define_method takes a name for the new method and a block which describes the body of the method. In ruby, this block is a closure which means we have access to the scope at the time of the method definition. In Javascript example, Javascript functions are closures. This means we get the ability to capture the scope at the time of definition for free. The ubiquity of closures in Javascript is extremely powerful and, as we have seen so far, makes metaprogramming very easy.

====Ruby====
color_name = 'black'
Ninja.send(:define_method, 'color') do
puts "#{name}'s color is #{color_name}"
end
drew.color
# => Drew's color is black
adam.color
# => Adam's color is black

====JavaScript====
var colorName = "black";
Ninja.prototype['color'] = function () {
puts(this.name + "'s color is " + colorName);
}
drew.color();
// => Drew's color is black
adam.color();
// => Adam's color is black

====Python====
color_name = 'black'
def color(self):
print "%s's color is %s" % (self.name, color_name)
Ninja.color = color
drew.color()
# => Drew's color is black
adam.color()
# => Adam's color is black

==Putting it all together==
How does metaprogamming work with dynamic typed languages?

*Interpreted Languages
Most dynamic languages are interpreted, not compiled. The basic idea here is for the code to be interpreted at run-time, allows generic objects to dynamically interact with each other. This interaction in itself is potentially manipulating the behavior of the program as it is executing. Generic objects are not the only uniqueness of an interpreted language, the 'eval' statement is something else to consider. The ability to evaluate an expression via the 'eval' statement allows for the program to redefine functions at run-time. These two capabilities for dynamic languages have become immensely valuable to programmers.

*Dynamic methods
These types of methods are very flexible. The program have have an object created from a class, then you can add additional methods to the instance of that class. Therefore manipulating the program at run time by allowing for only this instance of the object to have additional methods. Not to be confused with extending classes or adding additional methods to classes.

*Singletons classes
Singleton classes should not be mistake for the Singleton design pattern. These types of classes available in some dynamic languages allow for [http://en.wikipedia.org/wiki/Dynamic_dispatch dynamic dispatching]. An common technique often used on singleton classes is to add dynamic methods to the instance.

*"Everything is an object"
Many languages a 'weak-typed' which means that potentially anything can be anything else. The most obvious way to have this behavior is by making everything an object. What historically are considered primitive data types now are all considered objects (e.g. string, integers, etc). In some of these languages even functions and procedures are considered objects. In some languages such as Ruby, even classes are Objects since they (as well as everything else) inherits from Object. Since classes can be used to define, extend, or redefine other classes (often referred to as a [http://en.wikipedia.org/wiki/Metaclass metaclass]) this is also potentially changing the behavior of the original program.

Some other traits of some common dynamic languages worth mentioning are: the use of method_missing, [http://en.wikipedia.org/wiki/Introspection introspection], [http://en.wikipedia.org/wiki/Lazy_loading lazy loading], [http://en.wikipedia.org/wiki/Declarative_programming declarative code], extensible type system, and method aliasing.

==Advantages & Disadvantages==

===Advantages===
* Using metaprogramming, you can create more expressive [http://en.wikipedia.org/wiki/Application_programming_interface APIs] (for example ActiveRecord uses metaprogramming to define accessor methods based on a table's column names, so you can write things like person.age instead of something like person.read_attribute("age"), where person is an active record object and the people table has a column called age) and you can accomplish some things with significantly less code than you otherwise would.

* Performance: Meta-programs represent data to be processed in terms of the low level data structures used by the script interpreter to represent the scripting language itself. Therefore, instead of being processed by an interpreted script manipulating script-level data structures, the data is processed by the compiled code of the language interpreter manipulating low level data structures directly. This removes the levels of indirection that slow down the execution of scripts, and so results in significant performance improvements.

===Disadvanatges===
* Metaprogramming code can be very difficult to read and understand: that is because the metaprogramming code will not necessarily express what the code it is creating is about, but only how it is creating that code. As such the code it is creating can be invisible to you as a reader of the source code - the created code will only start to exist at runtime. One would therefore expect that programmers would try especially hard when they metaprogram to make that particular kind of code expressive and easy to understand.

* Another consequence of the fact that the code produced by metaprogramming is not necessarily visible, is that debugging becomes more difficult: when analyzing problems you’ll not only be unsure how the programm works, but in addition, you won’t even be sure how the code that is executed looks like - since it is only generated at runtime.

==Conclusion==
Dynamic languages are increasingly recognized for playing a major role in software development, specifically for quick prototyping because of the forgiveness of the languages letting requirements evolve. These languages are historically looked at as scripting languages that are inexpensive and not scalable. Once you're familiar with the techniques, metaprogramming is not as complicated as it might sound initially. Metaprogramming allows you to automate error-prone or repetitive programming tasks. You can use it to pre-generate data tables, to generate boilerplate code automatically that can't be abstracted into a function, or even to test your ingenuity on writing self-replicating code.

==References==
Websites:
#http://en.wikipedia.org/wiki/Metaprogramming
#http://en.wikipedia.org/wiki/Dynamic_programming_language
#http://en.wikipedia.org/wiki/Application_programming_interface
#http://www.linuxjournal.com/article/9604
#http://www.ibm.com/developerworks/linux/library/l-metaprog1/index.html
#http://tratt.net/laurie/research/publications/html/tratt__dynamically_typed_languages/
#http://www.sitepoint.com/typing-versus-dynamic-typing/
#http://www.bias2build.com/thesis/ruby_v_js_MP.html
#http://codeblog.dhananjaynene.com/2010/01/dynamically-adding-methods-with-metaprogramming-ruby-and-python/
#http://fingernailsinoatmeal.com/post/292301859/metaprogramming-ruby-vs-javascript
#http://www.ibm.com/developerworks/linux/library/l-pymeta/index.html

Books/Articles:
#Tratt, L. 2005. Compile-time meta-programming in a dynamically typed OO language. In Proceedings of the 2005 Symposium on Dynamic Languages (San Diego, California, October 18 - 18, 2005). DLS '05. ACM, New York, NY, 49-63. http://doi.acm.org.www.lib.ncsu.edu:2048/10.1145/1146841.1146846
#Madsen, O.L.; Nogaard, C.; , "An object-oriented metaprogramming system," System Sciences, 1988. Vol.II. Software Track, Proceedings of the Twenty-First Annual Hawaii International Conference on , vol.2, no., pp.406-415, 5-8 Jan 1988, http://ieeexplore.ieee.org.www.lib.ncsu.edu:2048/stamp/stamp.jsp?tp=&arnumber=11831&isnumber=538

CSC/ECE 517 Fall 2012/ch1b 1w53 kc

2012-09-28T04:54:33Z

Hpkancha:

'''Metaprogramming in dynamically typed languages'''

----

==Introduction==
One of the most under-used programming techniques is writing programs that generate programs or program parts. Code-generating programs are sometimes called metaprograms; writing such programs is called metaprogramming. Writing programs that write code has numerous applications. In this article, we will learn why [http://en.wikipedia.org/wiki/Metaprogramming metaprogramming] is necessary and look at some of the components of metaprogramming in [http://en.wikipedia.org/wiki/Dynamic_programming_language dynamically typed languages].

==What is Metaprogramming?==
Metaprogramming is the writing of computer programs that write or manipulate other programs (or themselves) as their data, or that do part of the work at compile time that would otherwise be done at runtime. In some cases, this allows programmers to minimize the number of lines of code to express a solution (hence reducing development time), or it gives programs greater flexibility to efficiently handle new situations without recompilation. Typically, you use a metaprogram to eliminate or reduce a tedious or error-prone programming task. So, for example, instead of writing a machine code program by hand, you would use a high-level language, such as C, and then let the C compiler do the translation to the equivalent low-level machine instructions.

==Metaprogramming Example==
Let us consider one big main function with 1,000 printf instructions.

#include <stdio.h>
int main(void) {
printf("1. I must not chat in class.\n");
printf("2. I must not chat in class.\n");
/* 996 printf instructions omitted. */
printf("999. I must not chat in class.\n");
printf("1000. I must not chat in class.\n");
return 0;
}

Taking the above pseudo code example, we can see how that can be made much simpler and elegant using a metaprogram in Ruby.

File.open('punishment.c', 'w') do |output|
output.puts '#include <stdio.h>'
output.puts 'int main(void) {'
1.upto(1000) do |i|
output.puts " printf(\"#{i}. " +
"I must not chat in class.\\n\");"
end
output.puts ' return 0;'
output.puts '}'
end

This code creates a file called punishment.c with the expected 1,000+ lines of C source code

==Dynamically Typed Programming Languages==
Before defining what dynamic typing is, it is easiest to define its opposite. [http://www.sitepoint.com/typing-versus-dynamic-typing/ Statically typed languages] are those which define and enforce types at compile-time. Statically typed languages typically have clearly distinct compile-time and run-time phases, with program code converted by a compiler into a binary executable which is then run separately. Dynamically typed languages have distinct compilation and execution phases and therefore we use the terms compile-time and run-time identically for both statically and dynamically typed languages. In most dynamically typed languages (e.g. Ruby, Perl, and Python) ‘running’ a file both compiles and executes it.

==Metaprogramming in Dynamically Typed Languages==

Metaprogramming can not only be used for programs to write programs, it can also be used to manipulate itself at runtime. Let us look at some examples that do this in ruby and the equivalent code in Javascript and Python.

===Adding a method dynamically to a class===
We can reopen an already existing class/prototype and add a new method to it dynamically. In ruby we reopen the class simply using the class keyword. In Javascript we grab the prototype for our object and just attach a new function.

====Ruby====
class Ninja
def battle_cry
puts "#{name} says zing!!!"
end
end
drew.battle_cry
# => Drew says zing!!!
adam.battle_cry
# => Adam says zing!!!

====JavaScript====
Ninja.prototype.battleCry = function () {
puts(this.name + " says zing!!!");
}
drew.battleCry();
// => Drew says zing!!!
adam.battleCry();
// => Adam says zing!!!

====Python====
def battle_cry(self):
print '%s says zing!!!' % self.name
Ninja.battle_cry = battle_cry
drew.battle_cry()
# => Drew says zing!!!
adam.battle_cry()
# => Adam says zing!!!

===Invoking a method dynamically===
The next thing we’ll look at is calling methods dynamically. The ability to call a method with a name given to us at runtime is a powerful tool in [http://en.wikipedia.org/wiki/Domain-specific_language DSL] creation and metaprogramming. Here’s the code. In case of Ruby, we supply the method name as a string and invoke it.

====Ruby====
drew.send(:battle_cry)
# => Drew says zing!!!

====JavaScript====
drew['battleCry']();
// => Drew says zing!!!

====Python====
drew.__getattribute__('battle_cry')()
# => Drew says zing!!!

===Defining class level methods dynamically with closures===
Here a class level method is defined which closes over some of the attributes in its context (in this case the method color is able to access the variable color_name as a closure). In Ruby, we’re using send to call define_method. This is a trick (hack) in ruby that allows us to call private methods without self being the implicit receiver. define_method takes a name for the new method and a block which describes the body of the method. In ruby, this block is a closure which means we have access to the scope at the time of the method definition. In Javascript example, Javascript functions are closures. This means we get the ability to capture the scope at the time of definition for free. The ubiquity of closures in Javascript is extremely powerful and, as we have seen so far, makes metaprogramming very easy.

====Ruby====
color_name = 'black'
Ninja.send(:define_method, 'color') do
puts "#{name}'s color is #{color_name}"
end
drew.color
# => Drew's color is black
adam.color
# => Adam's color is black

====JavaScript====
var colorName = "black";
Ninja.prototype['color'] = function () {
puts(this.name + "'s color is " + colorName);
}
drew.color();
// => Drew's color is black
adam.color();
// => Adam's color is black

====Python====
color_name = 'black'
def color(self):
print "%s's color is %s" % (self.name, color_name)
Ninja.color = color
drew.color()
# => Drew's color is black
adam.color()
# => Adam's color is black

==Putting it all together==
How does metaprogamming work with dynamic typed languages?

*Interpreted Languages
Most dynamic languages are interpreted, not compiled. The basic idea here is for the code to be interpreted at run-time, allows generic objects to dynamically interact with each other. This interaction in itself is potentially manipulating the behavior of the program as it is executing. Generic objects are not the only uniqueness of an interpreted language, the 'eval' statement is something else to consider. The ability to evaluate an expression via the 'eval' statement allows for the program to redefine functions at run-time. These two capabilities for dynamic languages have become immensely valuable to programmers.

*Dynamic methods
These types of methods are very flexible. The program have have an object created from a class, then you can add additional methods to the instance of that class. Therefore manipulating the program at run time by allowing for only this instance of the object to have additional methods. Not to be confused with extending classes or adding additional methods to classes.

*Singletons classes
Singleton classes should not be mistake for the Singleton design pattern. These types of classes available in some dynamic languages allow for [http://en.wikipedia.org/wiki/Dynamic_dispatch dynamic dispatching]. An common technique often used on singleton classes is to add dynamic methods to the instance.

*"Everything is an object"
Many languages a 'weak-typed' which means that potentially anything can be anything else. The most obvious way to have this behavior is by making everything an object. What historically are considered primitive data types now are all considered objects (e.g. string, integers, etc). In some of these languages even functions and procedures are considered objects. In some languages such as Ruby, even classes are Objects since they (as well as everything else) inherits from Object. Since classes can be used to define, extend, or redefine other classes (often referred to as a [http://en.wikipedia.org/wiki/Metaclass metaclass]) this is also potentially changing the behavior of the original program.

Some other traits of some common dynamic languages worth mentioning are: the use of method_missing, [http://en.wikipedia.org/wiki/Introspection introspection], [http://en.wikipedia.org/wiki/Lazy_loading lazy loading], [http://en.wikipedia.org/wiki/Declarative_programming declarative code], extensible type system, and method aliasing.

==Advantages & Disadvantages==

===Advantages===
* Using metaprogramming, you can create more expressive [http://en.wikipedia.org/wiki/Application_programming_interface APIs] (for example ActiveRecord uses metaprogramming to define accessor methods based on a table's column names, so you can write things like person.age instead of something like person.read_attribute("age"), where person is an active record object and the people table has a column called age) and you can accomplish some things with significantly less code than you otherwise would.

* Performance: Meta-programs represent data to be processed in terms of the low level data structures used by the script interpreter to represent the scripting language itself. Therefore, instead of being processed by an interpreted script manipulating script-level data structures, the data is processed by the compiled code of the language interpreter manipulating low level data structures directly. This removes the levels of indirection that slow down the execution of scripts, and so results in significant performance improvements.

===Disadvanatges===
* Metaprogramming code can be very difficult to read and understand: that is because the metaprogramming code will not necessarily express what the code it is creating is about, but only how it is creating that code. As such the code it is creating can be invisible to you as a reader of the source code - the created code will only start to exist at runtime. One would therefore expect that programmers would try especially hard when they metaprogram to make that particular kind of code expressive and easy to understand.

* Another consequence of the fact that the code produced by metaprogramming is not necessarily visible, is that debugging becomes more difficult: when analyzing problems you’ll not only be unsure how the programm works, but in addition, you won’t even be sure how the code that is executed looks like - since it is only generated at runtime.

==Conclusion==
Dynamic languages are increasingly recognized for playing a major role in software development, specifically for quick prototyping because of the forgiveness of the languages letting requirements evolve. These languages are historically looked at as scripting languages that are inexpensive and not scalable. Once you're familiar with the techniques, metaprogramming is not as complicated as it might sound initially. Metaprogramming allows you to automate error-prone or repetitive programming tasks. You can use it to pre-generate data tables, to generate boilerplate code automatically that can't be abstracted into a function, or even to test your ingenuity on writing self-replicating code.

==References==
Websites:
#Metaprogramming, http://en.wikipedia.org/wiki/Metaprogramming
#Dynamic Programming Languages, http://en.wikipedia.org/wiki/Dynamic_programming_language
#Application Programming Interfaces (API's), http://en.wikipedia.org/wiki/Application_programming_interface
#http://www.linuxjournal.com/article/9604
#http://www.ibm.com/developerworks/linux/library/l-metaprog1/index.html
#http://tratt.net/laurie/research/publications/html/tratt__dynamically_typed_languages/
#http://www.sitepoint.com/typing-versus-dynamic-typing/
#http://www.bias2build.com/thesis/ruby_v_js_MP.html
#http://codeblog.dhananjaynene.com/2010/01/dynamically-adding-methods-with-metaprogramming-ruby-and-python/
#http://fingernailsinoatmeal.com/post/292301859/metaprogramming-ruby-vs-javascript
#http://www.ibm.com/developerworks/linux/library/l-pymeta/index.html

Books/Articles:
*Tratt, L. 2005. Compile-time meta-programming in a dynamically typed OO language. In Proceedings of the 2005 Symposium on Dynamic Languages (San Diego, California, October 18 - 18, 2005). DLS '05. ACM, New York, NY, 49-63. http://doi.acm.org.www.lib.ncsu.edu:2048/10.1145/1146841.1146846
*Madsen, O.L.; Nogaard, C.; , "An object-oriented metaprogramming system," System Sciences, 1988. Vol.II. Software Track, Proceedings of the Twenty-First Annual Hawaii International Conference on , vol.2, no., pp.406-415, 5-8 Jan 1988, http://ieeexplore.ieee.org.www.lib.ncsu.edu:2048/stamp/stamp.jsp?tp=&arnumber=11831&isnumber=538

CSC/ECE 517 Fall 2012/ch1b 1w53 kc

2012-09-28T04:52:16Z

Hpkancha:

'''Metaprogramming in dynamically typed languages'''

----

==Introduction==
One of the most under-used programming techniques is writing programs that generate programs or program parts. Code-generating programs are sometimes called metaprograms; writing such programs is called metaprogramming. Writing programs that write code has numerous applications. In this article, we will learn why [http://en.wikipedia.org/wiki/Metaprogramming metaprogramming] is necessary and look at some of the components of metaprogramming in [http://en.wikipedia.org/wiki/Dynamic_programming_language dynamically typed languages].

==What is Metaprogramming?==
Metaprogramming is the writing of computer programs that write or manipulate other programs (or themselves) as their data, or that do part of the work at compile time that would otherwise be done at runtime. In some cases, this allows programmers to minimize the number of lines of code to express a solution (hence reducing development time), or it gives programs greater flexibility to efficiently handle new situations without recompilation. Typically, you use a metaprogram to eliminate or reduce a tedious or error-prone programming task. So, for example, instead of writing a machine code program by hand, you would use a high-level language, such as C, and then let the C compiler do the translation to the equivalent low-level machine instructions.

==Metaprogramming Example==
Let us consider one big main function with 1,000 printf instructions.

#include <stdio.h>
int main(void) {
printf("1. I must not chat in class.\n");
printf("2. I must not chat in class.\n");
/* 996 printf instructions omitted. */
printf("999. I must not chat in class.\n");
printf("1000. I must not chat in class.\n");
return 0;
}

Taking the above pseudo code example, we can see how that can be made much simpler and elegant using a metaprogram in Ruby.

File.open('punishment.c', 'w') do |output|
output.puts '#include <stdio.h>'
output.puts 'int main(void) {'
1.upto(1000) do |i|
output.puts " printf(\"#{i}. " +
"I must not chat in class.\\n\");"
end
output.puts ' return 0;'
output.puts '}'
end

This code creates a file called punishment.c with the expected 1,000+ lines of C source code

==Dynamically Typed Programming Languages==
Before defining what dynamic typing is, it is easiest to define its opposite. [http://www.sitepoint.com/typing-versus-dynamic-typing/ Statically typed languages] are those which define and enforce types at compile-time. Statically typed languages typically have clearly distinct compile-time and run-time phases, with program code converted by a compiler into a binary executable which is then run separately. Dynamically typed languages have distinct compilation and execution phases and therefore we use the terms compile-time and run-time identically for both statically and dynamically typed languages. In most dynamically typed languages (e.g. Ruby, Perl, and Python) ‘running’ a file both compiles and executes it.

==Metaprogramming in Dynamically Typed Languages==

Metaprogramming can not only be used for programs to write programs, it can also be used to manipulate itself at runtime. Let us look at some examples that do this in ruby and the equivalent code in Javascript and Python.

===Adding a method dynamically to a class===
We can reopen an already existing class/prototype and add a new method to it dynamically. In ruby we reopen the class simply using the class keyword. In Javascript we grab the prototype for our object and just attach a new function.

====Ruby====
class Ninja
def battle_cry
puts "#{name} says zing!!!"
end
end
drew.battle_cry
# => Drew says zing!!!
adam.battle_cry
# => Adam says zing!!!

====JavaScript====
Ninja.prototype.battleCry = function () {
puts(this.name + " says zing!!!");
}
drew.battleCry();
// => Drew says zing!!!
adam.battleCry();
// => Adam says zing!!!

====Python====
def battle_cry(self):
print '%s says zing!!!' % self.name
Ninja.battle_cry = battle_cry
drew.battle_cry()
# => Drew says zing!!!
adam.battle_cry()
# => Adam says zing!!!

===Invoking a method dynamically===
The next thing we’ll look at is calling methods dynamically. The ability to call a method with a name given to us at runtime is a powerful tool in [http://en.wikipedia.org/wiki/Domain-specific_language DSL] creation and metaprogramming. Here’s the code. In case of Ruby, we supply the method name as a string and invoke it.

====Ruby====
drew.send(:battle_cry)
# => Drew says zing!!!

====JavaScript====
drew['battleCry']();
// => Drew says zing!!!

====Python====
drew.__getattribute__('battle_cry')()
# => Drew says zing!!!

===Defining class level methods dynamically with closures===
Here a class level method is defined which closes over some of the attributes in its context (in this case the method color is able to access the variable color_name as a closure). In Ruby, we’re using send to call define_method. This is a trick (hack) in ruby that allows us to call private methods without self being the implicit receiver. define_method takes a name for the new method and a block which describes the body of the method. In ruby, this block is a closure which means we have access to the scope at the time of the method definition. In Javascript example, Javascript functions are closures. This means we get the ability to capture the scope at the time of definition for free. The ubiquity of closures in Javascript is extremely powerful and, as we have seen so far, makes metaprogramming very easy.

====Ruby====
color_name = 'black'
Ninja.send(:define_method, 'color') do
puts "#{name}'s color is #{color_name}"
end
drew.color
# => Drew's color is black
adam.color
# => Adam's color is black

====JavaScript====
var colorName = "black";
Ninja.prototype['color'] = function () {
puts(this.name + "'s color is " + colorName);
}
drew.color();
// => Drew's color is black
adam.color();
// => Adam's color is black

====Python====
color_name = 'black'
def color(self):
print "%s's color is %s" % (self.name, color_name)
Ninja.color = color
drew.color()
# => Drew's color is black
adam.color()
# => Adam's color is black

==Putting it all together==
How does metaprogamming work with dynamic typed languages?

*Interpreted Languages
Most dynamic languages are interpreted, not compiled. The basic idea here is for the code to be interpreted at run-time, allows generic objects to dynamically interact with each other. This interaction in itself is potentially manipulating the behavior of the program as it is executing. Generic objects are not the only uniqueness of an interpreted language, the 'eval' statement is something else to consider. The ability to evaluate an expression via the 'eval' statement allows for the program to redefine functions at run-time. These two capabilities for dynamic languages have become immensely valuable to programmers.

*Dynamic methods
These types of methods are very flexible. The program have have an object created from a class, then you can add additional methods to the instance of that class. Therefore manipulating the program at run time by allowing for only this instance of the object to have additional methods. Not to be confused with extending classes or adding additional methods to classes.

*Singletons classes
Singleton classes should not be mistake for the Singleton design pattern. These types of classes available in some dynamic languages allow for [http://en.wikipedia.org/wiki/Dynamic_dispatch dynamic dispatching]. An common technique often used on singleton classes is to add dynamic methods to the instance.

*"Everything is an object"
Many languages a 'weak-typed' which means that potentially anything can be anything else. The most obvious way to have this behavior is by making everything an object. What historically are considered primitive data types now are all considered objects (e.g. string, integers, etc). In some of these languages even functions and procedures are considered objects. In some languages such as Ruby, even classes are Objects since they (as well as everything else) inherits from Object. Since classes can be used to define, extend, or redefine other classes (often referred to as a [http://en.wikipedia.org/wiki/Metaclass metaclass]) this is also potentially changing the behavior of the original program.

Some other traits of some common dynamic languages worth mentioning are: the use of method_missing, [http://en.wikipedia.org/wiki/Introspection introspection], [http://en.wikipedia.org/wiki/Lazy_loading lazy loading], [http://en.wikipedia.org/wiki/Declarative_programming declarative code], extensible type system, and method aliasing.

==Advantages & Disadvantages==

===Advantages===
* Using metaprogramming, you can create more expressive [http://en.wikipedia.org/wiki/Application_programming_interface APIs] (for example ActiveRecord uses metaprogramming to define accessor methods based on a table's column names, so you can write things like person.age instead of something like person.read_attribute("age"), where person is an active record object and the people table has a column called age) and you can accomplish some things with significantly less code than you otherwise would.

* Performance: Meta-programs represent data to be processed in terms of the low level data structures used by the script interpreter to represent the scripting language itself. Therefore, instead of being processed by an interpreted script manipulating script-level data structures, the data is processed by the compiled code of the language interpreter manipulating low level data structures directly. This removes the levels of indirection that slow down the execution of scripts, and so results in significant performance improvements.

===Disadvanatges===
* Metaprogramming code can be very difficult to read and understand: that is because the metaprogramming code will not necessarily express what the code it is creating is about, but only how it is creating that code. As such the code it is creating can be invisible to you as a reader of the source code - the created code will only start to exist at runtime. One would therefore expect that programmers would try especially hard when they metaprogram to make that particular kind of code expressive and easy to understand.

* Another consequence of the fact that the code produced by metaprogramming is not necessarily visible, is that debugging becomes more difficult: when analyzing problems you’ll not only be unsure how the programm works, but in addition, you won’t even be sure how the code that is executed looks like - since it is only generated at runtime.

==Conclusion==
Dynamic languages are increasingly recognized for playing a major role in software development, specifically for quick prototyping because of the forgiveness of the languages letting requirements evolve. These languages are historically looked at as scripting languages that are inexpensive and not scalable. Once you're familiar with the techniques, metaprogramming is not as complicated as it might sound initially. Metaprogramming allows you to automate error-prone or repetitive programming tasks. You can use it to pre-generate data tables, to generate boilerplate code automatically that can't be abstracted into a function, or even to test your ingenuity on writing self-replicating code.

==References==
Websites:
*Wikipedia.org: Metaprogramming, http://en.wikipedia.org/wiki/Metaprogramming
*Wikipedia.org: Dynamic Programming Languages, http://en.wikipedia.org/wiki/Dynamic_programming_language
*Wikipedia.org: Application Programming Interfaces (API's), http://en.wikipedia.org/wiki/Application_programming_interface
*http://www.linuxjournal.com/article/9604
*http://www.ibm.com/developerworks/linux/library/l-metaprog1/index.html
*http://tratt.net/laurie/research/publications/html/tratt__dynamically_typed_languages/
*http://www.sitepoint.com/typing-versus-dynamic-typing/
*http://www.bias2build.com/thesis/ruby_v_js_MP.html
*http://codeblog.dhananjaynene.com/2010/01/dynamically-adding-methods-with-metaprogramming-ruby-and-python/
*http://www.ibm.com/developerworks/linux/library/l-pymeta/index.html

Books/Articles:
*Tratt, L. 2005. Compile-time meta-programming in a dynamically typed OO language. In Proceedings of the 2005 Symposium on Dynamic Languages (San Diego, California, October 18 - 18, 2005). DLS '05. ACM, New York, NY, 49-63. http://doi.acm.org.www.lib.ncsu.edu:2048/10.1145/1146841.1146846
*Madsen, O.L.; Nogaard, C.; , "An object-oriented metaprogramming system," System Sciences, 1988. Vol.II. Software Track, Proceedings of the Twenty-First Annual Hawaii International Conference on , vol.2, no., pp.406-415, 5-8 Jan 1988, http://ieeexplore.ieee.org.www.lib.ncsu.edu:2048/stamp/stamp.jsp?tp=&arnumber=11831&isnumber=538

CSC/ECE 517 Fall 2012/ch1b 1w53 kc

2012-09-28T04:48:52Z

Hpkancha:

'''Metaprogramming in dynamically typed languages'''

----

==Introduction==
One of the most under-used programming techniques is writing programs that generate programs or program parts. Code-generating programs are sometimes called metaprograms; writing such programs is called metaprogramming. Writing programs that write code has numerous applications. In this article, we will learn why [http://en.wikipedia.org/wiki/Metaprogramming metaprogramming] is necessary and look at some of the components of metaprogramming in [http://en.wikipedia.org/wiki/Dynamic_programming_language dynamically typed languages].

==What is Metaprogramming?==
Metaprogramming is the writing of computer programs that write or manipulate other programs (or themselves) as their data, or that do part of the work at compile time that would otherwise be done at runtime. In some cases, this allows programmers to minimize the number of lines of code to express a solution (hence reducing development time), or it gives programs greater flexibility to efficiently handle new situations without recompilation. Typically, you use a metaprogram to eliminate or reduce a tedious or error-prone programming task. So, for example, instead of writing a machine code program by hand, you would use a high-level language, such as C, and then let the C compiler do the translation to the equivalent low-level machine instructions.

==Metaprogramming Example==
Let us consider one big main function with 1,000 printf instructions.

#include <stdio.h>
int main(void) {
printf("1. I must not chat in class.\n");
printf("2. I must not chat in class.\n");
/* 996 printf instructions omitted. */
printf("999. I must not chat in class.\n");
printf("1000. I must not chat in class.\n");
return 0;
}

Taking the above pseudo code example, we can see how that can be made much simpler and elegant using a metaprogram in Ruby.

File.open('punishment.c', 'w') do |output|
output.puts '#include <stdio.h>'
output.puts 'int main(void) {'
1.upto(1000) do |i|
output.puts " printf(\"#{i}. " +
"I must not chat in class.\\n\");"
end
output.puts ' return 0;'
output.puts '}'
end

This code creates a file called punishment.c with the expected 1,000+ lines of C source code

==Dynamically Typed Programming Languages==
Before defining what dynamic typing is, it is easiest to define its opposite. [http://www.sitepoint.com/typing-versus-dynamic-typing/ Statically typed languages] are those which define and enforce types at compile-time. Statically typed languages typically have clearly distinct compile-time and run-time phases, with program code converted by a compiler into a binary executable which is then run separately. Dynamically typed languages have distinct compilation and execution phases and therefore we use the terms compile-time and run-time identically for both statically and dynamically typed languages. In most dynamically typed languages (e.g. Ruby, Perl, and Python) ‘running’ a file both compiles and executes it.

==Metaprogramming in Dynamically Typed Languages==

Metaprogramming can not only be used for programs to write programs, it can also be used to manipulate itself at runtime. Let us look at some examples that do this in ruby and the equivalent code in Javascript and Python.

===Adding a method dynamically to a class===
We can reopen an already existing class/prototype and add a new method to it dynamically. In ruby we reopen the class simply using the class keyword. In Javascript we grab the prototype for our object and just attach a new function.

====Ruby====
class Ninja
def battle_cry
puts "#{name} says zing!!!"
end
end
drew.battle_cry
# => Drew says zing!!!
adam.battle_cry
# => Adam says zing!!!

====JavaScript====
Ninja.prototype.battleCry = function () {
puts(this.name + " says zing!!!");
}
drew.battleCry();
// => Drew says zing!!!
adam.battleCry();
// => Adam says zing!!!

====Python====
def battle_cry(self):
print '%s says zing!!!' % self.name
Ninja.battle_cry = battle_cry
drew.battle_cry()
# => Drew says zing!!!
adam.battle_cry()
# => Adam says zing!!!

===Invoking a method dynamically===
The next thing we’ll look at is calling methods dynamically. The ability to call a method with a name given to us at runtime is a powerful tool in [http://en.wikipedia.org/wiki/Domain-specific_language DSL] creation and metaprogramming. Here’s the code. In case of Ruby, we supply the method name as a string and invoke it.

====Ruby====
drew.send(:battle_cry)
# => Drew says zing!!!

====JavaScript====
drew['battleCry']();
// => Drew says zing!!!

====Python====
drew.__getattribute__('battle_cry')()
# => Drew says zing!!!

===Defining class level methods dynamically with closures===
Here a class level method is defined which closes over some of the attributes in its context (in this case the method color is able to access the variable color_name as a closure). In Ruby, we’re using send to call define_method. This is a trick (hack) in ruby that allows us to call private methods without self being the implicit receiver. define_method takes a name for the new method and a block which describes the body of the method. In ruby, this block is a closure which means we have access to the scope at the time of the method definition. In Javascript example, Javascript functions are closures. This means we get the ability to capture the scope at the time of definition for free. The ubiquity of closures in Javascript is extremely powerful and, as we have seen so far, makes metaprogramming very easy.

====Ruby====
color_name = 'black'
Ninja.send(:define_method, 'color') do
puts "#{name}'s color is #{color_name}"
end
drew.color
# => Drew's color is black
adam.color
# => Adam's color is black

====JavaScript====
var colorName = "black";
Ninja.prototype['color'] = function () {
puts(this.name + "'s color is " + colorName);
}
drew.color();
// => Drew's color is black
adam.color();
// => Adam's color is black

====Python====
color_name = 'black'
def color(self):
print "%s's color is %s" % (self.name, color_name)
Ninja.color = color
drew.color()
# => Drew's color is black
adam.color()
# => Adam's color is black

==Putting it all together==
How does metaprogamming work with dynamic typed languages?

*Interpreted Languages
Most dynamic languages are interpreted, not compiled. The basic idea here is for the code to be interpreted at run-time, allows generic objects to dynamically interact with each other. This interaction in itself is potentially manipulating the behavior of the program as it is executing. Generic objects are not the only uniqueness of an interpreted language, the 'eval' statement is something else to consider. The ability to evaluate an expression via the 'eval' statement allows for the program to redefine functions at run-time. These two capabilities for dynamic languages have become immensely valuable to programmers.

*Dynamic methods
These types of methods are very flexible. The program have have an object created from a class, then you can add additional methods to the instance of that class. Therefore manipulating the program at run time by allowing for only this instance of the object to have additional methods. Not to be confused with extending classes or adding additional methods to classes.

*Singletons classes
Singleton classes should not be mistake for the Singleton design pattern. These types of classes available in some dynamic languages allow for [http://en.wikipedia.org/wiki/Dynamic_dispatch dynamic dispatching]. An common technique often used on singleton classes is to add dynamic methods to the instance.

*"Everything is an object"
Many languages a 'weak-typed' which means that potentially anything can be anything else. The most obvious way to have this behavior is by making everything an object. What historically are considered primitive data types now are all considered objects (e.g. string, integers, etc). In some of these languages even functions and procedures are considered objects. In some languages such as Ruby, even classes are Objects since they (as well as everything else) inherits from Object. Since classes can be used to define, extend, or redefine other classes (often referred to as a [http://en.wikipedia.org/wiki/Metaclass metaclass]) this is also potentially changing the behavior of the original program.

Some other traits of some common dynamic languages worth mentioning are: the use of method_missing, [http://en.wikipedia.org/wiki/Introspection introspection], [http://en.wikipedia.org/wiki/Lazy_loading lazy loading], [http://en.wikipedia.org/wiki/Declarative_programming declarative code], extensible type system, and method aliasing.

==Advantages & Disadvantages==

===Advantages===
Using metaprogramming, you can create more expressive [http://en.wikipedia.org/wiki/Application_programming_interface APIs] (for example ActiveRecord uses metaprogramming to define accessor methods based on a table's column names, so you can write things like person.age instead of something like person.read_attribute("age"), where person is an active record object and the people table has a column called age) and you can accomplish some things with significantly less code than you otherwise would.

Performance: Meta-programs represent data to be processed in terms of the low level data structures used by the script interpreter to represent the scripting language itself. Therefore, instead of being processed by an interpreted script manipulating script-level data structures, the data is processed by the compiled code of the language interpreter manipulating low level data structures directly. This removes the levels of indirection that slow down the execution of scripts, and so results in significant performance improvements.

===Disadvanatges===
Metaprogramming code can be very difficult to read and understand: that is because the metaprogramming code will not necessarily express what the code it is creating is about, but only how it is creating that code. As such the code it is creating can be invisible to you as a reader of the source code - the created code will only start to exist at runtime. One would therefore expect that programmers would try especially hard when they metaprogram to make that particular kind of code expressive and easy to understand.

Another consequence of the fact that the code produced by metaprogramming is not necessarily visible, is that debugging becomes more difficult: when analyzing problems you’ll not only be unsure how the programm works, but in addition, you won’t even be sure how the code that is executed looks like - since it is only generated at runtime.

==Conclusion==
Dynamic languages are increasingly recognized for playing a major role in software development, specifically for quick prototyping because of the forgiveness of the languages letting requirements evolve. These languages are historically looked at as scripting languages that are inexpensive and not scalable. Once you're familiar with the techniques, metaprogramming is not as complicated as it might sound initially. Metaprogramming allows you to automate error-prone or repetitive programming tasks. You can use it to pre-generate data tables, to generate boilerplate code automatically that can't be abstracted into a function, or even to test your ingenuity on writing self-replicating code.

==References==
Websites:
*Wikipedia.org: Metaprogramming, http://en.wikipedia.org/wiki/Metaprogramming
*Wikipedia.org: Dynamic Programming Languages, http://en.wikipedia.org/wiki/Dynamic_programming_language
*Wikipedia.org: Application Programming Interfaces (API's), http://en.wikipedia.org/wiki/Application_programming_interface
*http://www.linuxjournal.com/article/9604
*http://www.ibm.com/developerworks/linux/library/l-metaprog1/index.html
*http://tratt.net/laurie/research/publications/html/tratt__dynamically_typed_languages/
*http://www.sitepoint.com/typing-versus-dynamic-typing/
*http://www.bias2build.com/thesis/ruby_v_js_MP.html
*http://codeblog.dhananjaynene.com/2010/01/dynamically-adding-methods-with-metaprogramming-ruby-and-python/
*http://www.ibm.com/developerworks/linux/library/l-pymeta/index.html

Books/Articles:
*Tratt, L. 2005. Compile-time meta-programming in a dynamically typed OO language. In Proceedings of the 2005 Symposium on Dynamic Languages (San Diego, California, October 18 - 18, 2005). DLS '05. ACM, New York, NY, 49-63. http://doi.acm.org.www.lib.ncsu.edu:2048/10.1145/1146841.1146846
*Madsen, O.L.; Nogaard, C.; , "An object-oriented metaprogramming system," System Sciences, 1988. Vol.II. Software Track, Proceedings of the Twenty-First Annual Hawaii International Conference on , vol.2, no., pp.406-415, 5-8 Jan 1988, http://ieeexplore.ieee.org.www.lib.ncsu.edu:2048/stamp/stamp.jsp?tp=&arnumber=11831&isnumber=538

CSC/ECE 517 Fall 2012/ch1b 1w53 kc

2012-09-28T04:40:22Z

Hpkancha:

'''Metaprogramming in dynamically typed languages'''

----

==Introduction==
One of the most under-used programming techniques is writing programs that generate programs or program parts. Code-generating programs are sometimes called metaprograms; writing such programs is called metaprogramming. Writing programs that write code has numerous applications. In this article, we will learn why [http://en.wikipedia.org/wiki/Metaprogramming metaprogramming] is necessary and look at some of the components of metaprogramming in [http://en.wikipedia.org/wiki/Dynamic_programming_language dynamically typed languages].

==What is Metaprogramming?==
Metaprogramming is the writing of computer programs that write or manipulate other programs (or themselves) as their data, or that do part of the work at compile time that would otherwise be done at runtime. In some cases, this allows programmers to minimize the number of lines of code to express a solution (hence reducing development time), or it gives programs greater flexibility to efficiently handle new situations without recompilation. Typically, you use a metaprogram to eliminate or reduce a tedious or error-prone programming task. So, for example, instead of writing a machine code program by hand, you would use a high-level language, such as C, and then let the C compiler do the translation to the equivalent low-level machine instructions.

==Metaprogramming Example==
Let us consider one big main function with 1,000 printf instructions.

#include <stdio.h>
int main(void) {
printf("1. I must not chat in class.\n");
printf("2. I must not chat in class.\n");
/* 996 printf instructions omitted. */
printf("999. I must not chat in class.\n");
printf("1000. I must not chat in class.\n");
return 0;
}

Taking the above pseudo code example, we can see how that can be made much simpler and elegant using a metaprogram in Ruby.

File.open('punishment.c', 'w') do |output|
output.puts '#include <stdio.h>'
output.puts 'int main(void) {'
1.upto(1000) do |i|
output.puts " printf(\"#{i}. " +
"I must not chat in class.\\n\");"
end
output.puts ' return 0;'
output.puts '}'
end

This code creates a file called punishment.c with the expected 1,000+ lines of C source code

==Dynamically Typed Programming Languages==
Before defining what dynamic typing is, it is easiest to define its opposite. [http://www.sitepoint.com/typing-versus-dynamic-typing/ Statically typed languages] are those which define and enforce types at compile-time. Statically typed languages typically have clearly distinct compile-time and run-time phases, with program code converted by a compiler into a binary executable which is then run separately. Dynamically typed languages have distinct compilation and execution phases and therefore we use the terms compile-time and run-time identically for both statically and dynamically typed languages. In most dynamically typed languages (e.g. Ruby, Perl, and Python) ‘running’ a file both compiles and executes it.

==Metaprogramming in Dynamically Typed Languages==

Metaprogramming can not only be used for programs to write programs, it can also be used to manipulate itself at runtime. Let us look at some examples that do this in ruby and the equivalent code in Javascript and Python.

===Adding a method dynamically to a class===
We can reopen an already existing class/prototype and add a new method to it dynamically. In ruby we reopen the class simply using the class keyword. In Javascript we grab the prototype for our object and just attach a new function.

====Ruby====
class Ninja
def battle_cry
puts "#{name} says zing!!!"
end
end
drew.battle_cry
# => Drew says zing!!!
adam.battle_cry
# => Adam says zing!!!

====JavaScript====
Ninja.prototype.battleCry = function () {
puts(this.name + " says zing!!!");
}
drew.battleCry();
// => Drew says zing!!!
adam.battleCry();
// => Adam says zing!!!

====Python====
def battle_cry(self):
print '%s says zing!!!' % self.name
Ninja.battle_cry = battle_cry
drew.battle_cry()
# => Drew says zing!!!
adam.battle_cry()
# => Adam says zing!!!

===Invoking a method dynamically===
The next thing we’ll look at is calling methods dynamically. The ability to call a method with a name given to us at runtime is a powerful tool in [http://en.wikipedia.org/wiki/Domain-specific_language DSL] creation and metaprogramming. Here’s the code. In case of Ruby, we supply the method name as a string and invoke it.

====Ruby====
drew.send(:battle_cry)
# => Drew says zing!!!

====JavaScript====
drew['battleCry']();
// => Drew says zing!!!

====Python====
drew.__getattribute__('battle_cry')()
# => Drew says zing!!!

===Defining class level methods dynamically with closures===
Here a class level method is defined which closes over some of the attributes in its context (in this case the method color is able to access the variable color_name as a closure). In Ruby, we’re using send to call define_method. This is a trick (hack) in ruby that allows us to call private methods without self being the implicit receiver. define_method takes a name for the new method and a block which describes the body of the method. In ruby, this block is a closure which means we have access to the scope at the time of the method definition. In Javascript example, Javascript functions are closures. This means we get the ability to capture the scope at the time of definition for free. The ubiquity of closures in Javascript is extremely powerful and, as we have seen so far, makes metaprogramming very easy.

====Ruby====
color_name = 'black'
Ninja.send(:define_method, 'color') do
puts "#{name}'s color is #{color_name}"
end
drew.color
# => Drew's color is black
adam.color
# => Adam's color is black

====JavaScript====
var colorName = "black";
Ninja.prototype['color'] = function () {
puts(this.name + "'s color is " + colorName);
}
drew.color();
// => Drew's color is black
adam.color();
// => Adam's color is black

====Python====
color_name = 'black'
def color(self):
print "%s's color is %s" % (self.name, color_name)
Ninja.color = color
drew.color()
# => Drew's color is black
adam.color()
# => Adam's color is black

==Putting it all together==
How does metaprogamming work with dynamic typed languages?

*Interpreted Languages
Most dynamic languages are interpreted, not compiled. The basic idea here is for the code to be interpreted at run-time, allows generic objects to dynamically interact with each other. This interaction in itself is potentially manipulating the behavior of the program as it is executing. Generic objects are not the only uniqueness of an interpreted language, the 'eval' statement is something else to consider. The ability to evaluate an expression via the 'eval' statement allows for the program to redefine functions at run-time. These two capabilities for dynamic languages have become immensely valuable to programmers.

*Dynamic methods
These types of methods are very flexible. The program have have an object created from a class, then you can add additional methods to the instance of that class. Therefore manipulating the program at run time by allowing for only this instance of the object to have additional methods. Not to be confused with extending classes or adding additional methods to classes.

*Singletons classes
Singleton classes should not be mistake for the Singleton design pattern. These types of classes available in some dynamic languages allow for [http://en.wikipedia.org/wiki/Dynamic_dispatch dynamic dispatching]. An common technique often used on singleton classes is to add dynamic methods to the instance.

*"Everything is an object"
Many languages a 'weak-typed' which means that potentially anything can be anything else. The most obvious way to have this behavior is by making everything an object. What historically are considered primitive data types now are all considered objects (e.g. string, integers, etc). In some of these languages even functions and procedures are considered objects. In some languages such as Ruby, even classes are Objects since they (as well as everything else) inherits from Object. Since classes can be used to define, extend, or redefine other classes (often referred to as a [http://en.wikipedia.org/wiki/Metaclass metaclass]) this is also potentially changing the behavior of the original program.

Some other traits of some common dynamic languages worth mentioning are: the use of method_missing, [http://en.wikipedia.org/wiki/Introspection introspection], [http://en.wikipedia.org/wiki/Lazy_loading lazy loading], [http://en.wikipedia.org/wiki/Declarative_programming declarative code], extensible type system, and method aliasing.

==Advantages & Disadvantages==

===Advantages===
Using metaprogramming, you can create more expressive [http://en.wikipedia.org/wiki/Application_programming_interface APIs] (for example ActiveRecord uses metaprogramming to define accessor methods based on a table's column names, so you can write things like person.age instead of something like person.read_attribute("age"), where person is an active record object and the people table has a column called age) and you can accomplish some things with significantly less code than you otherwise would.

Performance: Meta-programs represent data to be processed in terms of the low level data structures used by the script interpreter to represent the scripting language itself. Therefore, instead of being processed by an interpreted script manipulating script-level data structures, the data is processed by the compiled code of the language interpreter manipulating low level data structures directly. This removes the levels of indirection that slow down the execution of scripts, and so results in significant performance improvements.

===Disadvanatges===
Metaprogramming code can be very difficult to read and understand: that is because the metaprogramming code will not necessarily express what the code it is creating is about, but only how it is creating that code. As such the code it is creating can be invisible to you as a reader of the source code - the created code will only start to exist at runtime. One would therefore expect that programmers would try especially hard when they metaprogram to make that particular kind of code expressive and easy to understand.

Another consequence of the fact that the code produced by metaprogramming is not necessarily visible, is that debugging becomes more difficult: when analyzing problems you’ll not only be unsure how the programm works, but in addition, you won’t even be sure how the code that is executed looks like - since it is only generated at runtime.

==Conclusion==
Dynamic languages are increasingly recognized for playing a major role in software development, specifically for quick prototyping because of the forgiveness of the languages letting requirements evolve. These languages are historically looked at as scripting languages that are inexpensive and not scalable. Allowing for these types of behavior comes at a price. The price is the potential for poor performance since the code is runtime optimized. Another downfall is that rapid development is great but the flexibility allowed between type conversions means that there is a higher probability for runtime errors. While understanding these limitation and accepting the risks, these languages can be very powerful specifically in the area of Metaprogramming.

==What’s Next?==
In the [http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2010/ch4_4h next article for which the link does not exist yet], we will look at [http://en.wikipedia.org/wiki/Static_analysis static-analysis] tools for Ruby.

==References==
Websites:
*Wikipedia.org: Metaprogramming, http://en.wikipedia.org/wiki/Metaprogramming
*c2.com Wiki: Metaprogramming article, http://c2.com/cgi/wiki?MetaProgramming
*Code generation Vs Metaprogramming, http://www.qcodo.com/wiki/article/background/metaprogramming
*Solenoid, The first metaprogramming framework for [http://exist-db.org eXist-db], http://solenoid.schematronic.org
*The Art of Enterprise Metaprogramming, http://www.ibm.com/developerworks/linux/library/l-metaprog3/?ca=dgr-wikiaMetaprogP3
*Wikipedia.org: Dynamic Programming Languages, http://en.wikipedia.org/wiki/Dynamic_programming_language
*Eclipse.org, Dynamic Languages Toolkit, http://www.eclipse.org/dltk/
*Wikipedia.org: Application Programming Interfaces (API's), http://en.wikipedia.org/wiki/Application_programming_interface

Books/Articles:
*Tratt, L. 2005. Compile-time meta-programming in a dynamically typed OO language. In Proceedings of the 2005 Symposium on Dynamic Languages (San Diego, California, October 18 - 18, 2005). DLS '05. ACM, New York, NY, 49-63. http://doi.acm.org.www.lib.ncsu.edu:2048/10.1145/1146841.1146846
*Madsen, O.L.; Nogaard, C.; , "An object-oriented metaprogramming system," System Sciences, 1988. Vol.II. Software Track, Proceedings of the Twenty-First Annual Hawaii International Conference on , vol.2, no., pp.406-415, 5-8 Jan 1988, http://ieeexplore.ieee.org.www.lib.ncsu.edu:2048/stamp/stamp.jsp?tp=&arnumber=11831&isnumber=538

CSC/ECE 517 Fall 2012/ch1b 1w53 kc

2012-09-28T02:49:22Z

Hpkancha:

'''Metaprogramming in dynamically typed languages'''

----

==Introduction==
One of the most under-used programming techniques is writing programs that generate programs or program parts. Code-generating programs are sometimes called metaprograms; writing such programs is called metaprogramming. Writing programs that write code has numerous applications. In this article, we will learn why [http://en.wikipedia.org/wiki/Metaprogramming metaprogramming] is necessary and look at some of the components of metaprogramming in [http://en.wikipedia.org/wiki/Dynamic_programming_language dynamically typed languages].

==What is Metaprogramming?==
Metaprogramming is the writing of computer programs that write or manipulate other programs (or themselves) as their data, or that do part of the work at compile time that would otherwise be done at runtime. In some cases, this allows programmers to minimize the number of lines of code to express a solution (hence reducing development time), or it gives programs greater flexibility to efficiently handle new situations without recompilation. Typically, you use a metaprogram to eliminate or reduce a tedious or error-prone programming task. So, for example, instead of writing a machine code program by hand, you would use a high-level language, such as C, and then let the C compiler do the translation to the equivalent low-level machine instructions.

==Metaprogramming Example==
Let us consider one big main function with 1,000 printf instructions.

#include <stdio.h>
int main(void) {
printf("1. I must not chat in class.\n");
printf("2. I must not chat in class.\n");
/* 996 printf instructions omitted. */
printf("999. I must not chat in class.\n");
printf("1000. I must not chat in class.\n");
return 0;
}

Taking the above pseudo code example, we can see how that can be made much simpler and elegant using a metaprogram in Ruby.

File.open('punishment.c', 'w') do |output|
output.puts '#include <stdio.h>'
output.puts 'int main(void) {'
1.upto(1000) do |i|
output.puts " printf(\"#{i}. " +
"I must not chat in class.\\n\");"
end
output.puts ' return 0;'
output.puts '}'
end

This code creates a file called punishment.c with the expected 1,000+ lines of C source code

==Dynamically Typed Programming Languages==
Before defining what dynamic typing is, it is easiest to define its opposite. [http://www.sitepoint.com/typing-versus-dynamic-typing/ Statically typed languages] are those which define and enforce types at compile-time. Statically typed languages typically have clearly distinct compile-time and run-time phases, with program code converted by a compiler into a binary executable which is then run separately. Dynamically typed languages have distinct compilation and execution phases and therefore we use the terms compile-time and run-time identically for both statically and dynamically typed languages. In most dynamically typed languages (e.g. Ruby, Perl, and Python) ‘running’ a file both compiles and executes it.

==Metaprogramming in Dynamically Typed Languages==

Metaprogramming can not only be used for programs to write programs, it can also be used to manipulate itself at runtime. Let us look at some examples that do this in ruby and the equivalent code in Javascript and Python.

===Adding a method dynamically to a class===
We can reopen an already existing class/prototype and add a new method to it dynamically. In ruby we reopen the class simply using the class keyword. In Javascript we grab the prototype for our object and just attach a new function.

====Ruby====
class Ninja
def battle_cry
puts "#{name} says zing!!!"
end
end
drew.battle_cry
# => Drew says zing!!!
adam.battle_cry
# => Adam says zing!!!

====JavaScript====
Ninja.prototype.battleCry = function () {
puts(this.name + " says zing!!!");
}
drew.battleCry();
// => Drew says zing!!!
adam.battleCry();
// => Adam says zing!!!

====Python====
def battle_cry(self):
print '%s says zing!!!' % self.name
Ninja.battle_cry = battle_cry
drew.battle_cry()
# => Drew says zing!!!
adam.battle_cry()
# => Adam says zing!!!

===Invoking a method dynamically===
The next thing we’ll look at is calling methods dynamically. The ability to call a method with a name given to us at runtime is a powerful tool in [http://en.wikipedia.org/wiki/Domain-specific_language DSL] creation and metaprogramming. Here’s the code. In case of Ruby, we supply the method name as a string and invoke it.

====Ruby====
drew.send(:battle_cry)
# => Drew says zing!!!

====JavaScript====
drew['battleCry']();
// => Drew says zing!!!

====Python====
drew.__getattribute__('battle_cry')()
# => Drew says zing!!!

===Defining class level methods dynamically with closures===
Here a class level method is defined which closes over some of the attributes in its context (in this case the method color is able to access the variable color_name as a closure). In Ruby, we’re using send to call define_method. This is a trick (hack) in ruby that allows us to call private methods without self being the implicit receiver. define_method takes a name for the new method and a block which describes the body of the method. In ruby, this block is a closure which means we have access to the scope at the time of the method definition. In Javascript example, Javascript functions are closures. This means we get the ability to capture the scope at the time of definition for free. The ubiquity of closures in Javascript is extremely powerful and, as we have seen so far, makes metaprogramming very easy.

====Ruby====
color_name = 'black'
Ninja.send(:define_method, 'color') do
puts "#{name}'s color is #{color_name}"
end
drew.color
# => Drew's color is black
adam.color
# => Adam's color is black

====JavaScript====
var colorName = "black";
Ninja.prototype['color'] = function () {
puts(this.name + "'s color is " + colorName);
}
drew.color();
// => Drew's color is black
adam.color();
// => Adam's color is black

====Python====
color_name = 'black'
def color(self):
print "%s's color is %s" % (self.name, color_name)
Ninja.color = color
drew.color()
# => Drew's color is black
adam.color()
# => Adam's color is black

==Putting it all together==
How does metaprogamming work with dynamic typed languages?

*Interpreted Languages
Most dynamic languages are interpreted, not compiled. The basic idea here is for the code to be interpreted at run-time, allows generic objects to dynamically interact with each other. This interaction in itself is potentially manipulating the behavior of the program as it is executing. Generic objects are not the only uniqueness of an interpreted language, the 'eval' statement is something else to consider. The ability to evaluate an expression via the 'eval' statement allows for the program to redefine functions at run-time. These two capabilities for dynamic languages have become immensely valuable to programmers.

*Dynamic methods
These types of methods are very flexible. The program have have an object created from a class, then you can add additional methods to the instance of that class. Therefore manipulating the program at run time by allowing for only this instance of the object to have additional methods. Not to be confused with extending classes or adding additional methods to classes.

*Singletons classes
Singleton classes should not be mistake for the Singleton design pattern. These types of classes available in some dynamic languages allow for [http://en.wikipedia.org/wiki/Dynamic_dispatch dynamic dispatching]. An common technique often used on singleton classes is to add dynamic methods to the instance.

*"Everything is an object"
Many languages a 'weak-typed' which means that potentially anything can be anything else. The most obvious way to have this behavior is by making everything an object. What historically are considered primitive data types now are all considered objects (e.g. string, integers, etc). In some of these languages even functions and procedures are considered objects. In some languages such as Ruby, even classes are Objects since they (as well as everything else) inherits from Object. Since classes can be used to define, extend, or redefine other classes (often referred to as a [http://en.wikipedia.org/wiki/Metaclass metaclass]) this is also potentially changing the behavior of the original program.

Some other traits of some common dynamic languages worth mentioning are: the use of method_missing, [http://en.wikipedia.org/wiki/Introspection introspection], [http://en.wikipedia.org/wiki/Lazy_loading lazy loading], [http://en.wikipedia.org/wiki/Declarative_programming declarative code], extensible type system, and method aliasing.

==Conclusion==
Dynamic languages are increasingly recognized for playing a major role in software development, specifically for quick prototyping because of the forgiveness of the languages letting requirements evolve. These languages are historically looked at as scripting languages that are inexpensive and not scalable. Allowing for these types of behavior comes at a price. The price is the potential for poor performance since the code is runtime optimized. Another downfall is that rapid development is great but the flexibility allowed between type conversions means that there is a higher probability for runtime errors. While understanding these limitation and accepting the risks, these languages can be very powerful specifically in the area of Metaprogramming.

==What’s Next?==
In the [http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2010/ch4_4h next article for which the link does not exist yet], we will look at [http://en.wikipedia.org/wiki/Static_analysis static-analysis] tools for Ruby.

==References==
Websites:
*Wikipedia.org: Metaprogramming, http://en.wikipedia.org/wiki/Metaprogramming
*c2.com Wiki: Metaprogramming article, http://c2.com/cgi/wiki?MetaProgramming
*Code generation Vs Metaprogramming, http://www.qcodo.com/wiki/article/background/metaprogramming
*Solenoid, The first metaprogramming framework for [http://exist-db.org eXist-db], http://solenoid.schematronic.org
*The Art of Enterprise Metaprogramming, http://www.ibm.com/developerworks/linux/library/l-metaprog3/?ca=dgr-wikiaMetaprogP3
*Wikipedia.org: Dynamic Programming Languages, http://en.wikipedia.org/wiki/Dynamic_programming_language
*Eclipse.org, Dynamic Languages Toolkit, http://www.eclipse.org/dltk/
*Wikipedia.org: Application Programming Interfaces (API's), http://en.wikipedia.org/wiki/Application_programming_interface

Books/Articles:
*Tratt, L. 2005. Compile-time meta-programming in a dynamically typed OO language. In Proceedings of the 2005 Symposium on Dynamic Languages (San Diego, California, October 18 - 18, 2005). DLS '05. ACM, New York, NY, 49-63. http://doi.acm.org.www.lib.ncsu.edu:2048/10.1145/1146841.1146846
*Madsen, O.L.; Nogaard, C.; , "An object-oriented metaprogramming system," System Sciences, 1988. Vol.II. Software Track, Proceedings of the Twenty-First Annual Hawaii International Conference on , vol.2, no., pp.406-415, 5-8 Jan 1988, http://ieeexplore.ieee.org.www.lib.ncsu.edu:2048/stamp/stamp.jsp?tp=&arnumber=11831&isnumber=538

CSC/ECE 517 Fall 2012/ch1b 1w53 kc

2012-09-28T02:39:25Z

Hpkancha:

'''Metaprogramming in dynamically typed languages'''

----

==Introduction==
One of the most under-used programming techniques is writing programs that generate programs or program parts. Code-generating programs are sometimes called metaprograms; writing such programs is called metaprogramming. Writing programs that write code has numerous applications. In this article, we will learn why [http://en.wikipedia.org/wiki/Metaprogramming metaprogramming] is necessary and look at some of the components of metaprogramming in [http://en.wikipedia.org/wiki/Dynamic_programming_language dynamically typed languages].

==What is Metaprogramming?==
Metaprogramming is the writing of computer programs that write or manipulate other programs (or themselves) as their data, or that do part of the work at compile time that would otherwise be done at runtime. In some cases, this allows programmers to minimize the number of lines of code to express a solution (hence reducing development time), or it gives programs greater flexibility to efficiently handle new situations without recompilation. Typically, you use a metaprogram to eliminate or reduce a tedious or error-prone programming task. So, for example, instead of writing a machine code program by hand, you would use a high-level language, such as C, and then let the C compiler do the translation to the equivalent low-level machine instructions.

==Metaprogramming Example==
Let us consider one big main function with 1,000 printf instructions.

#include <stdio.h>
int main(void) {
printf("1. I must not chat in class.\n");
printf("2. I must not chat in class.\n");
/* 996 printf instructions omitted. */
printf("999. I must not chat in class.\n");
printf("1000. I must not chat in class.\n");
return 0;
}

Taking the above pseudo code example, we can see how that can be made much simpler and elegant using a metaprogram in Ruby.

File.open('punishment.c', 'w') do |output|
output.puts '#include <stdio.h>'
output.puts 'int main(void) {'
1.upto(1000) do |i|
output.puts " printf(\"#{i}. " +
"I must not chat in class.\\n\");"
end
output.puts ' return 0;'
output.puts '}'
end

This code creates a file called punishment.c with the expected 1,000+ lines of C source code

==Dynamically Typed Programming Languages==
Before defining what dynamic typing is, it is easiest to define its opposite. [http://www.sitepoint.com/typing-versus-dynamic-typing/ Statically typed languages] are those which define and enforce types at compile-time. Statically typed languages typically have clearly distinct compile-time and run-time phases, with program code converted by a compiler into a binary executable which is then run separately. Dynamically typed languages have distinct compilation and execution phases and therefore we use the terms compile-time and run-time identically for both statically and dynamically typed languages. In most dynamically typed languages (e.g. Ruby, Perl, and Python) ‘running’ a file both compiles and executes it.

==Metaprogramming in Dynamically Typed Languages==

Metaprogramming can not only be used for programs to write programs, it can also be used to manipulate itself at runtime. Let us look at some examples that do this in ruby and the equivalent code in Javascript and Python.

===Adding a method dynamically to a class===
We can reopen an already existing class/prototype and add a new method to it dynamically. In ruby we reopen the class simply using the class keyword. In Javascript we grab the prototype for our object and just attach a new function.

====Ruby====
class Ninja
def battle_cry
puts "#{name} says zing!!!"
end
end
drew.battle_cry
# => Drew says zing!!!
adam.battle_cry
# => Adam says zing!!!

====JavaScript====
Ninja.prototype.battleCry = function () {
puts(this.name + " says zing!!!");
}
drew.battleCry();
// => Drew says zing!!!
adam.battleCry();
// => Adam says zing!!!

====Python====
def battle_cry(self):
print '%s says zing!!!' % self.name
Ninja.battle_cry = battle_cry
drew.battle_cry()
# => Drew says zing!!!
adam.battle_cry()
# => Adam says zing!!!

===Invoking a method dynamically===
The next thing we’ll look at is calling methods dynamically. The ability to call a method with a name given to us at runtime is a powerful tool in [http://en.wikipedia.org/wiki/Domain-specific_language DSL] creation and metaprogramming. Here’s the code.
====Ruby====
drew.send(:battle_cry)
# => Drew says zing!!!
====JavaScript====
drew['battleCry']();
// => Drew says zing!!!
====Python====
drew.__getattribute__('battle_cry')()
# => Drew says zing!!!

==Putting it all together==
How does metaprogamming work with dynamic typed languages?

*Interpreted Languages
Most dynamic languages are interpreted, not compiled. The basic idea here is for the code to be interpreted at run-time, allows generic objects to dynamically interact with each other. This interaction in itself is potentially manipulating the behavior of the program as it is executing. Generic objects are not the only uniqueness of an interpreted language, the 'eval' statement is something else to consider. The ability to evaluate an expression via the 'eval' statement allows for the program to redefine functions at run-time. These two capabilities for dynamic languages have become immensely valuable to programmers.

*Dynamic methods
These types of methods are very flexible. The program have have an object created from a class, then you can add additional methods to the instance of that class. Therefore manipulating the program at run time by allowing for only this instance of the object to have additional methods. Not to be confused with extending classes or adding additional methods to classes.

*Singletons classes
Singleton classes should not be mistake for the Singleton design pattern. These types of classes available in some dynamic languages allow for [http://en.wikipedia.org/wiki/Dynamic_dispatch dynamic dispatching]. An common technique often used on singleton classes is to add dynamic methods to the instance.

*"Everything is an object"
Many languages a 'weak-typed' which means that potentially anything can be anything else. The most obvious way to have this behavior is by making everything an object. What historically are considered primitive data types now are all considered objects (e.g. string, integers, etc). In some of these languages even functions and procedures are considered objects. In some languages such as Ruby, even classes are Objects since they (as well as everything else) inherits from Object. Since classes can be used to define, extend, or redefine other classes (often referred to as a [http://en.wikipedia.org/wiki/Metaclass metaclass]) this is also potentially changing the behavior of the original program.

Some other traits of some common dynamic languages worth mentioning are: the use of method_missing, [http://en.wikipedia.org/wiki/Introspection introspection], [http://en.wikipedia.org/wiki/Lazy_loading lazy loading], [http://en.wikipedia.org/wiki/Declarative_programming declarative code], extensible type system, and method aliasing.

==Conclusion==
Dynamic languages are increasingly recognized for playing a major role in software development, specifically for quick prototyping because of the forgiveness of the languages letting requirements evolve. These languages are historically looked at as scripting languages that are inexpensive and not scalable. Allowing for these types of behavior comes at a price. The price is the potential for poor performance since the code is runtime optimized. Another downfall is that rapid development is great but the flexibility allowed between type conversions means that there is a higher probability for runtime errors. While understanding these limitation and accepting the risks, these languages can be very powerful specifically in the area of Metaprogramming.

==What’s Next?==
In the [http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2010/ch4_4h next article for which the link does not exist yet], we will look at [http://en.wikipedia.org/wiki/Static_analysis static-analysis] tools for Ruby.

==References==
Websites:
*Wikipedia.org: Metaprogramming, http://en.wikipedia.org/wiki/Metaprogramming
*c2.com Wiki: Metaprogramming article, http://c2.com/cgi/wiki?MetaProgramming
*Code generation Vs Metaprogramming, http://www.qcodo.com/wiki/article/background/metaprogramming
*Solenoid, The first metaprogramming framework for [http://exist-db.org eXist-db], http://solenoid.schematronic.org
*The Art of Enterprise Metaprogramming, http://www.ibm.com/developerworks/linux/library/l-metaprog3/?ca=dgr-wikiaMetaprogP3
*Wikipedia.org: Dynamic Programming Languages, http://en.wikipedia.org/wiki/Dynamic_programming_language
*Eclipse.org, Dynamic Languages Toolkit, http://www.eclipse.org/dltk/
*Wikipedia.org: Application Programming Interfaces (API's), http://en.wikipedia.org/wiki/Application_programming_interface

Books/Articles:
*Tratt, L. 2005. Compile-time meta-programming in a dynamically typed OO language. In Proceedings of the 2005 Symposium on Dynamic Languages (San Diego, California, October 18 - 18, 2005). DLS '05. ACM, New York, NY, 49-63. http://doi.acm.org.www.lib.ncsu.edu:2048/10.1145/1146841.1146846
*Madsen, O.L.; Nogaard, C.; , "An object-oriented metaprogramming system," System Sciences, 1988. Vol.II. Software Track, Proceedings of the Twenty-First Annual Hawaii International Conference on , vol.2, no., pp.406-415, 5-8 Jan 1988, http://ieeexplore.ieee.org.www.lib.ncsu.edu:2048/stamp/stamp.jsp?tp=&arnumber=11831&isnumber=538

CSC/ECE 517 Fall 2012/ch1b 1w53 kc

2012-09-28T02:38:16Z

Hpkancha:

'''Metaprogramming in dynamically typed languages'''

----

==Introduction==
One of the most under-used programming techniques is writing programs that generate programs or program parts. Code-generating programs are sometimes called metaprograms; writing such programs is called metaprogramming. Writing programs that write code has numerous applications. In this article, we will learn why [http://en.wikipedia.org/wiki/Metaprogramming metaprogramming] is necessary and look at some of the components of metaprogramming in [http://en.wikipedia.org/wiki/Dynamic_programming_language dynamically typed languages].

==What is Metaprogramming?==
Metaprogramming is the writing of computer programs that write or manipulate other programs (or themselves) as their data, or that do part of the work at compile time that would otherwise be done at runtime. In some cases, this allows programmers to minimize the number of lines of code to express a solution (hence reducing development time), or it gives programs greater flexibility to efficiently handle new situations without recompilation. Typically, you use a metaprogram to eliminate or reduce a tedious or error-prone programming task. So, for example, instead of writing a machine code program by hand, you would use a high-level language, such as C, and then let the C compiler do the translation to the equivalent low-level machine instructions.

==Metaprogramming Example==
Let us consider one big main function with 1,000 printf instructions.

#include <stdio.h>
int main(void) {
printf("1. I must not chat in class.\n");
printf("2. I must not chat in class.\n");
/* 996 printf instructions omitted. */
printf("999. I must not chat in class.\n");
printf("1000. I must not chat in class.\n");
return 0;
}

Taking the above pseudo code example, we can see how that can be made much simpler and elegant using a metaprogram in Ruby.

File.open('punishment.c', 'w') do |output|
output.puts '#include <stdio.h>'
output.puts 'int main(void) {'
1.upto(1000) do |i|
output.puts " printf(\"#{i}. " +
"I must not chat in class.\\n\");"
end
output.puts ' return 0;'
output.puts '}'
end

This code creates a file called punishment.c with the expected 1,000+ lines of C source code

==Dynamically Typed Programming Languages==
Before defining what dynamic typing is, it is easiest to define its opposite. [http://www.sitepoint.com/typing-versus-dynamic-typing/ Statically typed languages] are those which define and enforce types at compile-time. Statically typed languages typically have clearly distinct compile-time and run-time phases, with program code converted by a compiler into a binary executable which is then run separately. Dynamically typed languages have distinct compilation and execution phases and therefore we use the terms compile-time and run-time identically for both statically and dynamically typed languages. In most dynamically typed languages (e.g. Ruby, Perl, and Python) ‘running’ a file both compiles and executes it.

==Metaprogramming in Dynamically Typed Languages==

Metaprogramming can not only be used for programs to write programs, it can also be used to manipulate itself at runtime. Let us look at some examples that do this in ruby and the equivalent code in Javascript and Python.

===Adding a method dynamically to a class===
We can reopen an already existing class/prototype and add a new method to it dynamically. In ruby we reopen the class simply using the class keyword. In Javascript we grab the prototype for our object and just attach a new function.

====Ruby====
class Ninja
def battle_cry
puts "#{name} says zing!!!"
end
end
drew.battle_cry
# => Drew says zing!!!
adam.battle_cry
# => Adam says zing!!!

====JavaScript====
Ninja.prototype.battleCry = function () {
puts(this.name + " says zing!!!");
}
drew.battleCry();
// => Drew says zing!!!
adam.battleCry();
// => Adam says zing!!!

====Python====
def battle_cry(self):
print '%s says zing!!!' % self.name
Ninja.battle_cry = battle_cry
drew.battle_cry()
# => Drew says zing!!!
adam.battle_cry()
# => Adam says zing!!!

===Invoking a method dynamically===
The next thing we’ll look at is calling methods dynamically. The ability to call a method with a name given to us at runtime is a powerful tool in [http://en.wikipedia.org/wiki/Domain-specific_language DSL] creation and metaprogramming. Here’s the code.

====Ruby====
drew.send(:battle_cry)
# => Drew says zing!!!

====JavaScript====
drew['battleCry']();
// => Drew says zing!!!

====Python====
drew.__getattribute__('battle_cry')()
# => Drew says zing!!!

==Putting it all together==
How does metaprogamming work with dynamic typed languages?

*Interpreted Languages
Most dynamic languages are interpreted, not compiled. The basic idea here is for the code to be interpreted at run-time, allows generic objects to dynamically interact with each other. This interaction in itself is potentially manipulating the behavior of the program as it is executing. Generic objects are not the only uniqueness of an interpreted language, the 'eval' statement is something else to consider. The ability to evaluate an expression via the 'eval' statement allows for the program to redefine functions at run-time. These two capabilities for dynamic languages have become immensely valuable to programmers.

*Dynamic methods
These types of methods are very flexible. The program have have an object created from a class, then you can add additional methods to the instance of that class. Therefore manipulating the program at run time by allowing for only this instance of the object to have additional methods. Not to be confused with extending classes or adding additional methods to classes.

*Singletons classes
Singleton classes should not be mistake for the Singleton design pattern. These types of classes available in some dynamic languages allow for [http://en.wikipedia.org/wiki/Dynamic_dispatch dynamic dispatching]. An common technique often used on singleton classes is to add dynamic methods to the instance.

*"Everything is an object"
Many languages a 'weak-typed' which means that potentially anything can be anything else. The most obvious way to have this behavior is by making everything an object. What historically are considered primitive data types now are all considered objects (e.g. string, integers, etc). In some of these languages even functions and procedures are considered objects. In some languages such as Ruby, even classes are Objects since they (as well as everything else) inherits from Object. Since classes can be used to define, extend, or redefine other classes (often referred to as a [http://en.wikipedia.org/wiki/Metaclass metaclass]) this is also potentially changing the behavior of the original program.

Some other traits of some common dynamic languages worth mentioning are: the use of method_missing, [http://en.wikipedia.org/wiki/Introspection introspection], [http://en.wikipedia.org/wiki/Lazy_loading lazy loading], [http://en.wikipedia.org/wiki/Declarative_programming declarative code], extensible type system, and method aliasing.

==Conclusion==
Dynamic languages are increasingly recognized for playing a major role in software development, specifically for quick prototyping because of the forgiveness of the languages letting requirements evolve. These languages are historically looked at as scripting languages that are inexpensive and not scalable. Allowing for these types of behavior comes at a price. The price is the potential for poor performance since the code is runtime optimized. Another downfall is that rapid development is great but the flexibility allowed between type conversions means that there is a higher probability for runtime errors. While understanding these limitation and accepting the risks, these languages can be very powerful specifically in the area of Metaprogramming.

==What’s Next?==
In the [http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2010/ch4_4h next article for which the link does not exist yet], we will look at [http://en.wikipedia.org/wiki/Static_analysis static-analysis] tools for Ruby.

==References==
Websites:
*Wikipedia.org: Metaprogramming, http://en.wikipedia.org/wiki/Metaprogramming
*c2.com Wiki: Metaprogramming article, http://c2.com/cgi/wiki?MetaProgramming
*Code generation Vs Metaprogramming, http://www.qcodo.com/wiki/article/background/metaprogramming
*Solenoid, The first metaprogramming framework for [http://exist-db.org eXist-db], http://solenoid.schematronic.org
*The Art of Enterprise Metaprogramming, http://www.ibm.com/developerworks/linux/library/l-metaprog3/?ca=dgr-wikiaMetaprogP3
*Wikipedia.org: Dynamic Programming Languages, http://en.wikipedia.org/wiki/Dynamic_programming_language
*Eclipse.org, Dynamic Languages Toolkit, http://www.eclipse.org/dltk/
*Wikipedia.org: Application Programming Interfaces (API's), http://en.wikipedia.org/wiki/Application_programming_interface

Books/Articles:
*Tratt, L. 2005. Compile-time meta-programming in a dynamically typed OO language. In Proceedings of the 2005 Symposium on Dynamic Languages (San Diego, California, October 18 - 18, 2005). DLS '05. ACM, New York, NY, 49-63. http://doi.acm.org.www.lib.ncsu.edu:2048/10.1145/1146841.1146846
*Madsen, O.L.; Nogaard, C.; , "An object-oriented metaprogramming system," System Sciences, 1988. Vol.II. Software Track, Proceedings of the Twenty-First Annual Hawaii International Conference on , vol.2, no., pp.406-415, 5-8 Jan 1988, http://ieeexplore.ieee.org.www.lib.ncsu.edu:2048/stamp/stamp.jsp?tp=&arnumber=11831&isnumber=538

CSC/ECE 517 Fall 2012/ch1b 1w53 kc

2012-09-28T02:33:17Z

Hpkancha:

CSC/ECE 517 Fall 2012/ch1b 1w53 kc

2012-09-28T02:28:58Z

Hpkancha:

CSC/ECE 517 Fall 2012/ch1b 1w53 kc

2012-09-28T02:15:45Z

Hpkancha:

CSC/ECE 517 Fall 2012/ch1b 1w53 kc

2012-09-28T02:14:24Z

Hpkancha:

CSC/ECE 517 Fall 2012/ch1b 1w53 kc

2012-09-28T02:09:00Z

Hpkancha:

'''Metaprogramming in dynamically typed languages'''

----

==Introduction==
One of the most under-used programming techniques is writing programs that generate programs or program parts. Code-generating programs are sometimes called metaprograms; writing such programs is called metaprogramming. Writing programs that write code has numerous applications. In this article, we will learn why [http://en.wikipedia.org/wiki/Metaprogramming metaprogramming] is necessary and look at some of the components of metaprogramming in [http://en.wikipedia.org/wiki/Dynamic_programming_language dynamically typed languages].

==What is Metaprogramming?==
Metaprogramming is the writing of computer programs that write or manipulate other programs (or themselves) as their data, or that do part of the work at compile time that would otherwise be done at runtime. In some cases, this allows programmers to minimize the number of lines of code to express a solution (hence reducing development time), or it gives programs greater flexibility to efficiently handle new situations without recompilation. Typically, you use a metaprogram to eliminate or reduce a tedious or error-prone programming task. So, for example, instead of writing a machine code program by hand, you would use a high-level language, such as C, and then let the C compiler do the translation to the equivalent low-level machine instructions.

==Metaprogramming Example==
Let us consider one big main function with 1,000 printf instructions.

#include <stdio.h>
int main(void) {
printf("1. I must not chat in class.\n");
printf("2. I must not chat in class.\n");
/* 996 printf instructions omitted. */
printf("999. I must not chat in class.\n");
printf("1000. I must not chat in class.\n");
return 0;
}

Taking the above pseudo code example, we can see how that can be made much simpler and elegant using a metaprogram in Ruby.

File.open('punishment.c', 'w') do |output|
output.puts '#include <stdio.h>'
output.puts 'int main(void) {'
1.upto(1000) do |i|
output.puts " printf(\"#{i}. " +
"I must not chat in class.\\n\");"
end
output.puts ' return 0;'
output.puts '}'
end

This code creates a file called punishment.c with the expected 1,000+ lines of C source code.

===Python===
f = open('outputfile.py', 'w') // Open the file for writing
f.write('#!/usr/bin/python \n')
for i in range(1, 100):
f.write('print' + i + '\n') // Write the string to a file
f.closed // Close the file

===JavaScript===
f = fopen('outputfile.js', 3); // Open the file for writing
if(f!=-1) { // If the file has been successfully opened
for (i=0;i<=100;i++) {
str = 'document.write' + i;
fwrite(f, str); // Write the string to a file
}
fclose(f); // Close the file
}

===Ruby===
f = File.open(outputfile.rb, 'w') // Open the file for writing
1.upto 100 do |i|
f.write("puts #{i}") // Write the string to a file
end
f.close // Close the file

==Dynamic Typed Programming Languages==
Dynamic typed programming languages are often referred to as 'weak typed' languages since it is not required for the variables to bound to a particular type at compile time instead each variable is bound to an object. Another unique characteristic of dynamic languages is that while variables need to be defined before they can be used, you don’t need to define them at the beginning of the program, just define it before its first usage. These characteristics are allowed because it is not the compiler that checks for proper variable declaration, these type errors will only occur at runtime and potentially the program will suddenly stop due to a crash.

==Metaprogramming in some Dynamic Languages==

We have already seen how some languages can be used for programs to write programs, now lets examine how they handle one of the other characteristics of metaprogramming: Manipulate itself at runtime. Each of the following will take a class (SomeClassThatAlreadyExists) that was already defined and add an new method (some_method) to it.

===Python===
class SomeClassThatAlreadyExists
def some_method
print "some code"
end
end

===JavaScript===
SomeClassThatAlreadyExists.prototype.some_method = function () {
document.write("some_code");
}

===Ruby===
class SomeClassThatAlreadyExists
def some_method
puts "some code"
end
end

==Putting it all together==
How does metaprogamming work with dynamic typed languages?

*Interpreted Languages
Most dynamic languages are interpreted, not compiled. The basic idea here is for the code to be interpreted at run-time, allows generic objects to dynamically interact with each other. This interaction in itself is potentially manipulating the behavior of the program as it is executing. Generic objects are not the only uniqueness of an interpreted language, the 'eval' statement is something else to consider. The ability to evaluate an expression via the 'eval' statement allows for the program to redefine functions at run-time. These two capabilities for dynamic languages have become immensely valuable to programmers.

*Dynamic methods
These types of methods are very flexible. The program have have an object created from a class, then you can add additional methods to the instance of that class. Therefore manipulating the program at run time by allowing for only this instance of the object to have additional methods. Not to be confused with extending classes or adding additional methods to classes.

*Singletons classes
Singleton classes should not be mistake for the Singleton design pattern. These types of classes available in some dynamic languages allow for [http://en.wikipedia.org/wiki/Dynamic_dispatch dynamic dispatching]. An common technique often used on singleton classes is to add dynamic methods to the instance.

*"Everything is an object"
Many languages a 'weak-typed' which means that potentially anything can be anything else. The most obvious way to have this behavior is by making everything an object. What historically are considered primitive data types now are all considered objects (e.g. string, integers, etc). In some of these languages even functions and procedures are considered objects. In some languages such as Ruby, even classes are Objects since they (as well as everything else) inherits from Object. Since classes can be used to define, extend, or redefine other classes (often referred to as a [http://en.wikipedia.org/wiki/Metaclass metaclass]) this is also potentially changing the behavior of the original program.

Some other traits of some common dynamic languages worth mentioning are: the use of method_missing, [http://en.wikipedia.org/wiki/Introspection introspection], [http://en.wikipedia.org/wiki/Lazy_loading lazy loading], [http://en.wikipedia.org/wiki/Declarative_programming declarative code], extensible type system, and method aliasing.

==Conclusion==
Dynamic languages are increasingly recognized for playing a major role in software development, specifically for quick prototyping because of the forgiveness of the languages letting requirements evolve. These languages are historically looked at as scripting languages that are inexpensive and not scalable. Allowing for these types of behavior comes at a price. The price is the potential for poor performance since the code is runtime optimized. Another downfall is that rapid development is great but the flexibility allowed between type conversions means that there is a higher probability for runtime errors. While understanding these limitation and accepting the risks, these languages can be very powerful specifically in the area of Metaprogramming.

==What’s Next?==
In the [http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2010/ch4_4h next article for which the link does not exist yet], we will look at [http://en.wikipedia.org/wiki/Static_analysis static-analysis] tools for Ruby.

==References==
Websites:
*Wikipedia.org: Metaprogramming, http://en.wikipedia.org/wiki/Metaprogramming
*c2.com Wiki: Metaprogramming article, http://c2.com/cgi/wiki?MetaProgramming
*Code generation Vs Metaprogramming, http://www.qcodo.com/wiki/article/background/metaprogramming
*Solenoid, The first metaprogramming framework for [http://exist-db.org eXist-db], http://solenoid.schematronic.org
*The Art of Enterprise Metaprogramming, http://www.ibm.com/developerworks/linux/library/l-metaprog3/?ca=dgr-wikiaMetaprogP3
*Wikipedia.org: Dynamic Programming Languages, http://en.wikipedia.org/wiki/Dynamic_programming_language
*Eclipse.org, Dynamic Languages Toolkit, http://www.eclipse.org/dltk/
*Wikipedia.org: Application Programming Interfaces (API's), http://en.wikipedia.org/wiki/Application_programming_interface

Books/Articles:
*Tratt, L. 2005. Compile-time meta-programming in a dynamically typed OO language. In Proceedings of the 2005 Symposium on Dynamic Languages (San Diego, California, October 18 - 18, 2005). DLS '05. ACM, New York, NY, 49-63. http://doi.acm.org.www.lib.ncsu.edu:2048/10.1145/1146841.1146846
*Madsen, O.L.; Nogaard, C.; , "An object-oriented metaprogramming system," System Sciences, 1988. Vol.II. Software Track, Proceedings of the Twenty-First Annual Hawaii International Conference on , vol.2, no., pp.406-415, 5-8 Jan 1988, http://ieeexplore.ieee.org.www.lib.ncsu.edu:2048/stamp/stamp.jsp?tp=&arnumber=11831&isnumber=538

CSC/ECE 517 Fall 2012/ch1b 1w53 kc

2012-09-28T01:55:07Z

Hpkancha:

'''Metaprogramming in dynamically typed languages'''

----

==Introduction==
One of the most under-used programming techniques is writing programs that generate programs or program parts. Code-generating programs are sometimes called metaprograms; writing such programs is called metaprogramming. Writing programs that write code has numerous applications. In this article, we will learn why [http://en.wikipedia.org/wiki/Metaprogramming metaprogramming] is necessary and look at some of the components of metaprogramming in [http://en.wikipedia.org/wiki/Dynamic_programming_language dynamically typed languages].

==What is Metaprogramming?==
Metaprogramming is the writing of computer programs that write or manipulate other programs (or themselves) as their data, or that do part of the work at compile time that would otherwise be done at runtime. In some cases, this allows programmers to minimize the number of lines of code to express a solution (hence reducing development time), or it gives programs greater flexibility to efficiently handle new situations without recompilation. Typically, you use a metaprogram to eliminate or reduce a tedious or error-prone programming task. So, for example, instead of writing a machine code program by hand, you would use a high-level language, such as C, and then let the C compiler do the translation to the equivalent low-level machine instructions.

==Example of Metaprogramming==
There is a classic example of use for metaprogramming that involves some form of writing a program that outputs some set of numbers in order but the trick is that it cannot be done in a loop. For this example we will ask for a program that outputs the numbers from 1 to 100 without using any looping. Ideally one would like to write the following (in pseudo code):
for i = 1 to 100
print i

which outputs
1
2
...
100
however since a loop is not allowed, you could use the loop to write code that will write the code:
for i = 1 to 100
print "print i"

which outputs
print 1
print 2
...
print 100
which then outputs
1
2
...
100
the elegance of this technique is that it is very easy to repeat or manipulate.

Taking the same pseudo code example, we can see how each of the following languages would incorporate this.

===Python===
f = open('outputfile.py', 'w') // Open the file for writing
f.write('#!/usr/bin/python \n')
for i in range(1, 100):
f.write('print' + i + '\n') // Write the string to a file
f.closed // Close the file

===JavaScript===
f = fopen('outputfile.js', 3); // Open the file for writing
if(f!=-1) { // If the file has been successfully opened
for (i=0;i<=100;i++) {
str = 'document.write' + i;
fwrite(f, str); // Write the string to a file
}
fclose(f); // Close the file
}

===Ruby===
f = File.open(outputfile.rb, 'w') // Open the file for writing
1.upto 100 do |i|
f.write("puts #{i}") // Write the string to a file
end
f.close // Close the file

==Dynamic Typed Programming Languages==
Dynamic typed programming languages are often referred to as 'weak typed' languages since it is not required for the variables to bound to a particular type at compile time instead each variable is bound to an object. Another unique characteristic of dynamic languages is that while variables need to be defined before they can be used, you don’t need to define them at the beginning of the program, just define it before its first usage. These characteristics are allowed because it is not the compiler that checks for proper variable declaration, these type errors will only occur at runtime and potentially the program will suddenly stop due to a crash.

==Metaprogramming in some Dynamic Languages==

We have already seen how some languages can be used for programs to write programs, now lets examine how they handle one of the other characteristics of metaprogramming: Manipulate itself at runtime. Each of the following will take a class (SomeClassThatAlreadyExists) that was already defined and add an new method (some_method) to it.

===Python===
class SomeClassThatAlreadyExists
def some_method
print "some code"
end
end

===JavaScript===
SomeClassThatAlreadyExists.prototype.some_method = function () {
document.write("some_code");
}

===Ruby===
class SomeClassThatAlreadyExists
def some_method
puts "some code"
end
end

==Putting it all together==
How does metaprogamming work with dynamic typed languages?

*Interpreted Languages
Most dynamic languages are interpreted, not compiled. The basic idea here is for the code to be interpreted at run-time, allows generic objects to dynamically interact with each other. This interaction in itself is potentially manipulating the behavior of the program as it is executing. Generic objects are not the only uniqueness of an interpreted language, the 'eval' statement is something else to consider. The ability to evaluate an expression via the 'eval' statement allows for the program to redefine functions at run-time. These two capabilities for dynamic languages have become immensely valuable to programmers.

*Dynamic methods
These types of methods are very flexible. The program have have an object created from a class, then you can add additional methods to the instance of that class. Therefore manipulating the program at run time by allowing for only this instance of the object to have additional methods. Not to be confused with extending classes or adding additional methods to classes.

*Singletons classes
Singleton classes should not be mistake for the Singleton design pattern. These types of classes available in some dynamic languages allow for [http://en.wikipedia.org/wiki/Dynamic_dispatch dynamic dispatching]. An common technique often used on singleton classes is to add dynamic methods to the instance.

*"Everything is an object"
Many languages a 'weak-typed' which means that potentially anything can be anything else. The most obvious way to have this behavior is by making everything an object. What historically are considered primitive data types now are all considered objects (e.g. string, integers, etc). In some of these languages even functions and procedures are considered objects. In some languages such as Ruby, even classes are Objects since they (as well as everything else) inherits from Object. Since classes can be used to define, extend, or redefine other classes (often referred to as a [http://en.wikipedia.org/wiki/Metaclass metaclass]) this is also potentially changing the behavior of the original program.

Some other traits of some common dynamic languages worth mentioning are: the use of method_missing, [http://en.wikipedia.org/wiki/Introspection introspection], [http://en.wikipedia.org/wiki/Lazy_loading lazy loading], [http://en.wikipedia.org/wiki/Declarative_programming declarative code], extensible type system, and method aliasing.

==Conclusion==
Dynamic languages are increasingly recognized for playing a major role in software development, specifically for quick prototyping because of the forgiveness of the languages letting requirements evolve. These languages are historically looked at as scripting languages that are inexpensive and not scalable. Allowing for these types of behavior comes at a price. The price is the potential for poor performance since the code is runtime optimized. Another downfall is that rapid development is great but the flexibility allowed between type conversions means that there is a higher probability for runtime errors. While understanding these limitation and accepting the risks, these languages can be very powerful specifically in the area of Metaprogramming.

==What’s Next?==
In the [http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2010/ch4_4h next article for which the link does not exist yet], we will look at [http://en.wikipedia.org/wiki/Static_analysis static-analysis] tools for Ruby.

==References==
Websites:
*Wikipedia.org: Metaprogramming, http://en.wikipedia.org/wiki/Metaprogramming
*c2.com Wiki: Metaprogramming article, http://c2.com/cgi/wiki?MetaProgramming
*Code generation Vs Metaprogramming, http://www.qcodo.com/wiki/article/background/metaprogramming
*Solenoid, The first metaprogramming framework for [http://exist-db.org eXist-db], http://solenoid.schematronic.org
*The Art of Enterprise Metaprogramming, http://www.ibm.com/developerworks/linux/library/l-metaprog3/?ca=dgr-wikiaMetaprogP3
*Wikipedia.org: Dynamic Programming Languages, http://en.wikipedia.org/wiki/Dynamic_programming_language
*Eclipse.org, Dynamic Languages Toolkit, http://www.eclipse.org/dltk/
*Wikipedia.org: Application Programming Interfaces (API's), http://en.wikipedia.org/wiki/Application_programming_interface

Books/Articles:
*Tratt, L. 2005. Compile-time meta-programming in a dynamically typed OO language. In Proceedings of the 2005 Symposium on Dynamic Languages (San Diego, California, October 18 - 18, 2005). DLS '05. ACM, New York, NY, 49-63. http://doi.acm.org.www.lib.ncsu.edu:2048/10.1145/1146841.1146846
*Madsen, O.L.; Nogaard, C.; , "An object-oriented metaprogramming system," System Sciences, 1988. Vol.II. Software Track, Proceedings of the Twenty-First Annual Hawaii International Conference on , vol.2, no., pp.406-415, 5-8 Jan 1988, http://ieeexplore.ieee.org.www.lib.ncsu.edu:2048/stamp/stamp.jsp?tp=&arnumber=11831&isnumber=538

CSC/ECE 517 Fall 2012/ch1b 1w53 kc

2012-09-28T01:49:45Z

Hpkancha:

'''Metaprogramming in dynamically typed languages'''

----

==Introduction==
One of the most under-used programming techniques is writing programs that generate programs or program parts. Code-generating programs are sometimes called metaprograms; writing such programs is called metaprogramming. Writing programs that write code has numerous applications. In this article, we will learn why [http://en.wikipedia.org/wiki/Metaprogramming metaprogramming] is necessary and look at some of the components of metaprogramming in [http://en.wikipedia.org/wiki/Dynamic_programming_language dynamically typed languages].

==What is Metaprogramming?==
Metaprogramming is the ability for a computer program to manipulate itself or other programs at the time of compilation as opposed to performing this manipulations at runtime. This tends to allow for greater flexibility for a program to handle new situations and plan for growth. Metaprogramming is ideal for several scenarios to include the use of [http://en.wikipedia.org/wiki/Application_programming_interface application programming interfaces (API's)], programs writing programs, and working with other programs outside of itself. API's allow the run-time engine to be exposed externally where it normally would not be. When a program writes another program that just means the running program dynamically outputs strings that can later be ran as en executed program. And finally, working with other programs outside itself refers to the running program's ability to accept language descriptions that it can execute transformations of the outside language. Ideally metaprogramming has one main objective, to allow for new features.

==Example of Metaprogramming==
There is a classic example of use for metaprogramming that involves some form of writing a program that outputs some set of numbers in order but the trick is that it cannot be done in a loop. For this example we will ask for a program that outputs the numbers from 1 to 100 without using any looping. Ideally one would like to write the following (in pseudo code):
for i = 1 to 100
print i

which outputs
1
2
...
100
however since a loop is not allowed, you could use the loop to write code that will write the code:
for i = 1 to 100
print "print i"

which outputs
print 1
print 2
...
print 100
which then outputs
1
2
...
100
the elegance of this technique is that it is very easy to repeat or manipulate.

Taking the same pseudo code example, we can see how each of the following languages would incorporate this.

===Python===
f = open('outputfile.py', 'w') // Open the file for writing
f.write('#!/usr/bin/python \n')
for i in range(1, 100):
f.write('print' + i + '\n') // Write the string to a file
f.closed // Close the file

===JavaScript===
f = fopen('outputfile.js', 3); // Open the file for writing
if(f!=-1) { // If the file has been successfully opened
for (i=0;i<=100;i++) {
str = 'document.write' + i;
fwrite(f, str); // Write the string to a file
}
fclose(f); // Close the file
}

===Ruby===
f = File.open(outputfile.rb, 'w') // Open the file for writing
1.upto 100 do |i|
f.write("puts #{i}") // Write the string to a file
end
f.close // Close the file

==Dynamic Typed Programming Languages==
Dynamic typed programming languages are often referred to as 'weak typed' languages since it is not required for the variables to bound to a particular type at compile time instead each variable is bound to an object. Another unique characteristic of dynamic languages is that while variables need to be defined before they can be used, you don’t need to define them at the beginning of the program, just define it before its first usage. These characteristics are allowed because it is not the compiler that checks for proper variable declaration, these type errors will only occur at runtime and potentially the program will suddenly stop due to a crash.

==Metaprogramming in some Dynamic Languages==

We have already seen how some languages can be used for programs to write programs, now lets examine how they handle one of the other characteristics of metaprogramming: Manipulate itself at runtime. Each of the following will take a class (SomeClassThatAlreadyExists) that was already defined and add an new method (some_method) to it.

===Python===
class SomeClassThatAlreadyExists
def some_method
print "some code"
end
end

===JavaScript===
SomeClassThatAlreadyExists.prototype.some_method = function () {
document.write("some_code");
}

===Ruby===
class SomeClassThatAlreadyExists
def some_method
puts "some code"
end
end

==Putting it all together==
How does metaprogamming work with dynamic typed languages?

*Interpreted Languages
Most dynamic languages are interpreted, not compiled. The basic idea here is for the code to be interpreted at run-time, allows generic objects to dynamically interact with each other. This interaction in itself is potentially manipulating the behavior of the program as it is executing. Generic objects are not the only uniqueness of an interpreted language, the 'eval' statement is something else to consider. The ability to evaluate an expression via the 'eval' statement allows for the program to redefine functions at run-time. These two capabilities for dynamic languages have become immensely valuable to programmers.

*Dynamic methods
These types of methods are very flexible. The program have have an object created from a class, then you can add additional methods to the instance of that class. Therefore manipulating the program at run time by allowing for only this instance of the object to have additional methods. Not to be confused with extending classes or adding additional methods to classes.

*Singletons classes
Singleton classes should not be mistake for the Singleton design pattern. These types of classes available in some dynamic languages allow for [http://en.wikipedia.org/wiki/Dynamic_dispatch dynamic dispatching]. An common technique often used on singleton classes is to add dynamic methods to the instance.

*"Everything is an object"
Many languages a 'weak-typed' which means that potentially anything can be anything else. The most obvious way to have this behavior is by making everything an object. What historically are considered primitive data types now are all considered objects (e.g. string, integers, etc). In some of these languages even functions and procedures are considered objects. In some languages such as Ruby, even classes are Objects since they (as well as everything else) inherits from Object. Since classes can be used to define, extend, or redefine other classes (often referred to as a [http://en.wikipedia.org/wiki/Metaclass metaclass]) this is also potentially changing the behavior of the original program.

Some other traits of some common dynamic languages worth mentioning are: the use of method_missing, [http://en.wikipedia.org/wiki/Introspection introspection], [http://en.wikipedia.org/wiki/Lazy_loading lazy loading], [http://en.wikipedia.org/wiki/Declarative_programming declarative code], extensible type system, and method aliasing.

==Conclusion==
Dynamic languages are increasingly recognized for playing a major role in software development, specifically for quick prototyping because of the forgiveness of the languages letting requirements evolve. These languages are historically looked at as scripting languages that are inexpensive and not scalable. Allowing for these types of behavior comes at a price. The price is the potential for poor performance since the code is runtime optimized. Another downfall is that rapid development is great but the flexibility allowed between type conversions means that there is a higher probability for runtime errors. While understanding these limitation and accepting the risks, these languages can be very powerful specifically in the area of Metaprogramming.

==What’s Next?==
In the [http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2010/ch4_4h next article for which the link does not exist yet], we will look at [http://en.wikipedia.org/wiki/Static_analysis static-analysis] tools for Ruby.

==References==
Websites:
*Wikipedia.org: Metaprogramming, http://en.wikipedia.org/wiki/Metaprogramming
*c2.com Wiki: Metaprogramming article, http://c2.com/cgi/wiki?MetaProgramming
*Code generation Vs Metaprogramming, http://www.qcodo.com/wiki/article/background/metaprogramming
*Solenoid, The first metaprogramming framework for [http://exist-db.org eXist-db], http://solenoid.schematronic.org
*The Art of Enterprise Metaprogramming, http://www.ibm.com/developerworks/linux/library/l-metaprog3/?ca=dgr-wikiaMetaprogP3
*Wikipedia.org: Dynamic Programming Languages, http://en.wikipedia.org/wiki/Dynamic_programming_language
*Eclipse.org, Dynamic Languages Toolkit, http://www.eclipse.org/dltk/
*Wikipedia.org: Application Programming Interfaces (API's), http://en.wikipedia.org/wiki/Application_programming_interface

Books/Articles:
*Tratt, L. 2005. Compile-time meta-programming in a dynamically typed OO language. In Proceedings of the 2005 Symposium on Dynamic Languages (San Diego, California, October 18 - 18, 2005). DLS '05. ACM, New York, NY, 49-63. http://doi.acm.org.www.lib.ncsu.edu:2048/10.1145/1146841.1146846
*Madsen, O.L.; Nogaard, C.; , "An object-oriented metaprogramming system," System Sciences, 1988. Vol.II. Software Track, Proceedings of the Twenty-First Annual Hawaii International Conference on , vol.2, no., pp.406-415, 5-8 Jan 1988, http://ieeexplore.ieee.org.www.lib.ncsu.edu:2048/stamp/stamp.jsp?tp=&arnumber=11831&isnumber=538

CSC/ECE 517 Fall 2012/ch1b 1w53 kc

2012-09-28T01:24:54Z

Hpkancha: Created page with "'''Metaprogramming in dynamically typed languages''' ---- ==Introduction== In the [http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2010/ch4_4f previous arti..."

'''Metaprogramming in dynamically typed languages'''

----

==Introduction==
In the [http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2010/ch4_4f previous article for which the link does not exist yet], we learn that [http://en.wikipedia.org/wiki/Command_pattern command patterns] in static and dynamic languages provide separation of objects that request actions from the objects that ultimately perform actions. This is done by encapsulating the request for an action on a specific object. These command patterns are executed at runtime and simply hide the fact that another program is being called. Another technique of encapsulating behavior is for the program to have changes initiated at compile time. This type of design requires that the program not only can call another piece of code at runtime but it can build these calls at compile time via [http://en.wikipedia.org/wiki/Metaprogramming metaprogramming]. In this article we take a closer look at metaprogramming in [http://en.wikipedia.org/wiki/Dynamic_programming_language dynamically typed languages].

==What is Metaprogramming?==
Metaprogramming is the ability for a computer program to manipulate itself or other programs at the time of compilation as opposed to performing this manipulations at runtime. This tends to allow for greater flexibility for a program to handle new situations and plan for growth. Metaprogramming is ideal for several scenarios to include the use of [http://en.wikipedia.org/wiki/Application_programming_interface application programming interfaces (API's)], programs writing programs, and working with other programs outside of itself. API's allow the run-time engine to be exposed externally where it normally would not be. When a program writes another program that just means the running program dynamically outputs strings that can later be ran as en executed program. And finally, working with other programs outside itself refers to the running program's ability to accept language descriptions that it can execute transformations of the outside language. Ideally metaprogramming has one main objective, to allow for new features.

==Example of Metaprogramming==
There is a classic example of use for metaprogramming that involves some form of writing a program that outputs some set of numbers in order but the trick is that it cannot be done in a loop. For this example we will ask for a program that outputs the numbers from 1 to 100 without using any looping. Ideally one would like to write the following (in pseudo code):
for i = 1 to 100
print i

which outputs
1
2
...
100
however since a loop is not allowed, you could use the loop to write code that will write the code:
for i = 1 to 100
print "print i"

which outputs
print 1
print 2
...
print 100
which then outputs
1
2
...
100
the elegance of this technique is that it is very easy to repeat or manipulate.

Taking the same pseudo code example, we can see how each of the following languages would incorporate this.

===Python===
f = open('outputfile.py', 'w') // Open the file for writing
f.write('#!/usr/bin/python \n')
for i in range(1, 100):
f.write('print' + i + '\n') // Write the string to a file
f.closed // Close the file

===JavaScript===
f = fopen('outputfile.js', 3); // Open the file for writing
if(f!=-1) { // If the file has been successfully opened
for (i=0;i<=100;i++) {
str = 'document.write' + i;
fwrite(f, str); // Write the string to a file
}
fclose(f); // Close the file
}

===Ruby===
f = File.open(outputfile.rb, 'w') // Open the file for writing
1.upto 100 do |i|
f.write("puts #{i}") // Write the string to a file
end
f.close // Close the file

==Dynamic Typed Programming Languages==
Dynamic typed programming languages are often referred to as 'weak typed' languages since it is not required for the variables to bound to a particular type at compile time instead each variable is bound to an object. Another unique characteristic of dynamic languages is that while variables need to be defined before they can be used, you don’t need to define them at the beginning of the program, just define it before its first usage. These characteristics are allowed because it is not the compiler that checks for proper variable declaration, these type errors will only occur at runtime and potentially the program will suddenly stop due to a crash.

==Metaprogramming in some Dynamic Languages==

We have already seen how some languages can be used for programs to write programs, now lets examine how they handle one of the other characteristics of metaprogramming: Manipulate itself at runtime. Each of the following will take a class (SomeClassThatAlreadyExists) that was already defined and add an new method (some_method) to it.

===Python===
class SomeClassThatAlreadyExists
def some_method
print "some code"
end
end

===JavaScript===
SomeClassThatAlreadyExists.prototype.some_method = function () {
document.write("some_code");
}

===Ruby===
class SomeClassThatAlreadyExists
def some_method
puts "some code"
end
end

==Putting it all together==
How does metaprogamming work with dynamic typed languages?

*Interpreted Languages
Most dynamic languages are interpreted, not compiled. The basic idea here is for the code to be interpreted at run-time, allows generic objects to dynamically interact with each other. This interaction in itself is potentially manipulating the behavior of the program as it is executing. Generic objects are not the only uniqueness of an interpreted language, the 'eval' statement is something else to consider. The ability to evaluate an expression via the 'eval' statement allows for the program to redefine functions at run-time. These two capabilities for dynamic languages have become immensely valuable to programmers.

*Dynamic methods
These types of methods are very flexible. The program have have an object created from a class, then you can add additional methods to the instance of that class. Therefore manipulating the program at run time by allowing for only this instance of the object to have additional methods. Not to be confused with extending classes or adding additional methods to classes.

*Singletons classes
Singleton classes should not be mistake for the Singleton design pattern. These types of classes available in some dynamic languages allow for [http://en.wikipedia.org/wiki/Dynamic_dispatch dynamic dispatching]. An common technique often used on singleton classes is to add dynamic methods to the instance.

*"Everything is an object"
Many languages a 'weak-typed' which means that potentially anything can be anything else. The most obvious way to have this behavior is by making everything an object. What historically are considered primitive data types now are all considered objects (e.g. string, integers, etc). In some of these languages even functions and procedures are considered objects. In some languages such as Ruby, even classes are Objects since they (as well as everything else) inherits from Object. Since classes can be used to define, extend, or redefine other classes (often referred to as a [http://en.wikipedia.org/wiki/Metaclass metaclass]) this is also potentially changing the behavior of the original program.

Some other traits of some common dynamic languages worth mentioning are: the use of method_missing, [http://en.wikipedia.org/wiki/Introspection introspection], [http://en.wikipedia.org/wiki/Lazy_loading lazy loading], [http://en.wikipedia.org/wiki/Declarative_programming declarative code], extensible type system, and method aliasing.

==Conclusion==
Dynamic languages are increasingly recognized for playing a major role in software development, specifically for quick prototyping because of the forgiveness of the languages letting requirements evolve. These languages are historically looked at as scripting languages that are inexpensive and not scalable. Allowing for these types of behavior comes at a price. The price is the potential for poor performance since the code is runtime optimized. Another downfall is that rapid development is great but the flexibility allowed between type conversions means that there is a higher probability for runtime errors. While understanding these limitation and accepting the risks, these languages can be very powerful specifically in the area of Metaprogramming.

==What’s Next?==
In the [http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2010/ch4_4h next article for which the link does not exist yet], we will look at [http://en.wikipedia.org/wiki/Static_analysis static-analysis] tools for Ruby.

==References==
Websites:
*Wikipedia.org: Metaprogramming, http://en.wikipedia.org/wiki/Metaprogramming
*c2.com Wiki: Metaprogramming article, http://c2.com/cgi/wiki?MetaProgramming
*Code generation Vs Metaprogramming, http://www.qcodo.com/wiki/article/background/metaprogramming
*Solenoid, The first metaprogramming framework for [http://exist-db.org eXist-db], http://solenoid.schematronic.org
*The Art of Enterprise Metaprogramming, http://www.ibm.com/developerworks/linux/library/l-metaprog3/?ca=dgr-wikiaMetaprogP3
*Wikipedia.org: Dynamic Programming Languages, http://en.wikipedia.org/wiki/Dynamic_programming_language
*Eclipse.org, Dynamic Languages Toolkit, http://www.eclipse.org/dltk/
*Wikipedia.org: Application Programming Interfaces (API's), http://en.wikipedia.org/wiki/Application_programming_interface

Books/Articles:
*Tratt, L. 2005. Compile-time meta-programming in a dynamically typed OO language. In Proceedings of the 2005 Symposium on Dynamic Languages (San Diego, California, October 18 - 18, 2005). DLS '05. ACM, New York, NY, 49-63. http://doi.acm.org.www.lib.ncsu.edu:2048/10.1145/1146841.1146846
*Madsen, O.L.; Nogaard, C.; , "An object-oriented metaprogramming system," System Sciences, 1988. Vol.II. Software Track, Proceedings of the Twenty-First Annual Hawaii International Conference on , vol.2, no., pp.406-415, 5-8 Jan 1988, http://ieeexplore.ieee.org.www.lib.ncsu.edu:2048/stamp/stamp.jsp?tp=&arnumber=11831&isnumber=538

CSC/ECE 517 Fall 2012

2012-09-28T01:24:21Z

Hpkancha: