Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2012/ch2a 2w13 sm

2012-10-27T22:30:48Z

Svmankar: /* Integration Testing */

==Introduction==
Test stubs are programs which simulate the behaviors of software components (or [http://en.wikipedia.org/wiki/Modular_programming modules]) on which other modules that are being tested are dependent upon.
Stubs are replacements for missing components that the components being tested will call as part of the test. While doing an [http://en.wikipedia.org/wiki/Integration_testing Integration], if we don't have all the modules ready and need to test a particular module which is ready then we use Stubs and Drivers.
Stubs are used in Integration testing for a [http://en.wikipedia.org/wiki/Top-down_and_bottom-up_design Top Down] Integration testing and Bottom Up Integration Testing.

[[File:Stubs.jpg|center]]

In the above figure, we can see that the Modules 2 and 3 are not yet implemented. However, if we need to test the modules 4,5 and 6 which are dependent on modules 2 and 3, we can simple use some dummy code in the form of Stubs 1 and 2 in place of the modules that return the values as expected by the modules beneath them. This piece of Dummy code is Called a Stub in a Top Down Integration. Hence Stubs are called Functions in Top Down Integration tests.

==Stubs in different phases of testing==
===Unit Testing===

In developing a huge software if we are following top down approach of development there may be some functionality which may not have been implemented. This can be overcome by implementing all the required functions. However, then we would be testing a huge chunk of code without actually testing it. This will lead to bugs and lot of time will be wasted on debugging. Consider the following example:

Suppose we want to evaluate an expression [http://en.wikipedia.org/wiki/Factorial factorial](x)/( sin(x) + tan(x) ). Assuming that we don't have library support available for calculating factorial,sin and tan of the given input we would have to write those functions. Using stubs we can write functions which would return appropriate values. Thus, assuming that factorial(x) is implemented then we can write stubs for sin and cos functions returning floating point values. We can than verify if our main function gives expected results for those values. This shows us that our main function, factorial are working correct without actually implementing sin and cos functions
<pre>
code:
int main()
{
float y=factorial(x) / (sin(x) + tan(x) );
return 0;
}
int factorial(x)
{

//implmentation of factorial
}

float sin(int x)
{
return 0.5;
}

float cos(int x)
{
return 0.3;
}
</pre>

===Functional Testing===

The idea of stub remains the same in different forms of testing. In unit testing we are dealing with working inside a module and hence we overwrite the dependent implementations by stub. This allows us to test the calling code without the actual implementation. In functional testing we will replace other modules or collaborators of a class. The client class might be interested in some service from some other class ( collaborator class ). However, again instead of implementing the actual class we will have a stub implementation. In ruby the [https://www.ruby-toolbox.com/projects/mocha mocha] gem provides support for functional test using stubbing. This helps in avoiding overlapping test cases. We can see the use of stubs in functional testing using mocha in ruby in the programming languages section.

===Integration Testing===
[http://en.wikipedia.org/wiki/Integration_testing Integration testing] is a logical extension of unit testing. In its simplest form, two units that have already been tested are combined into a component and the interface between them is tested. A component, in this sense, refers to an integrated aggregate of more than one unit. In a realistic scenario, many units are combined into components, which are in turn aggregated into even larger parts of the program. The idea is to test combinations of pieces and eventually expand the process to test your modules with those of other groups. Eventually all the modules making up a process are tested together. Beyond that, if the program is composed of more than one process, they should be tested in pairs rather than all at once.

Integration testing identifies problems that occur when units are combined. By using a test plan that requires you to test each unit and ensure the viability of each before combining units, you know that any errors discovered when combining units are likely related to the interface between units. This method reduces the number of possibilities to a far simpler level of analysis.
The top-down approach to integration testing requires the highest-level modules be test and integrated first. This allows high-level logic and data flow to be tested early in the process and it tends to minimize the need for drivers. However, the need for stubs complicates test management and low-level utilities are tested relatively late in the development cycle. Another disadvantage of top-down integration testing is its poor support for early release of limited functionality.

===Regression Testing===
[http://en.wikipedia.org/wiki/Regression_testing Regression testing] is any type of software testing that seeks to uncover new software bugs, or regressions, in existing functional and non-functional areas of a system after changes, such as enhancements, patches or configuration changes, have been made to them.
The intent of regression testing is to ensure that a change, such as a bugfix, did not introduce new faults. One of the main reasons for regression testing is to determine whether a change in one part of the software affects other parts of the software.
Common methods of regression testing include rerunning previously run tests and checking whether program behavior has changed and whether previously fixed faults have re-emerged. Regression testing can be used to test a system efficiently by systematically selecting the appropriate minimum set of tests needed to adequately cover a particular change.
In Regression testing the use of test stubs is minimized as most of the system is already implemented and the main goal of the regression test is to see if there are any bugs that might have been ‘regressed’ from the previous stages of integrations. Ideally there will not be unimplemented modules by the time a system is tested for regression. However, in case of mutually exclusive modules of a system, a test stub for one of them can be used to test the regression of the other.

==Stubs in software development==
===Agile Development Methodology===
[http://en.wikipedia.org/wiki/Agile_software_development Agile software development] is a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change. It is a conceptual framework that promotes foreseen interactions throughout the development cycle.
In such a development system, it recognizes that testing is not a separate phase, but an integral part of software development, along with coding. Agile testing is a software testing practice that follows the principles of agile software development. Agile testing involves all members of a cross-functional agile team, with special expertise contributed by testers, to ensure delivering the business value desired by the customer at frequent intervals, working at a sustainable pace. Specification by example, also known as acceptance test-driven development, is used to capture examples of desired and undesired behavior and guide coding.
In the agile testing toolkit, a stub is a piece of code that behaves in a predefined way, in order to simplify the testing process. Here are the kind of simplifications that a stub can bring:

* If the code under test never returns the same value (usage of a timestamp or of a random value), a stub can be used to fix the root of the undeterminism.

* If the code depends on some other class that has complex behavior that you don’t want to take into account in this test, using a stub for this other class can simplify its behavior and clarify the intent of the test

* If the code depends on some other code that is not yet written or released, it is possible to start building the rest of the code before the dependency is actually finished.

===Rapid Application Development===
[http://en.wikipedia.org/wiki/Rapid_application_development Rapid Application Development] or RAD is a style of programming that focuses on having tools that allow a program to be created quickly. This is particularly useful for graphically based programs as it is easy to create a frontend which can then be used for testing the backend code. It is a software development methodology that uses minimal planning in favor of rapid prototyping. The "planning" of software developed using RAD is interleaved with writing the software itself. The lack of extensive pre-planning generally allows software to be written much faster, and makes it easier to change requirements. In such a development scenario it becomes increasingly important to be able to write tests and successfully test the software the is being developed so that a complete product is developed in quick time. Test stubs ensure that the testing of code is not stalled in case other modules are still being developed. A programmer can immediately use test stubs and test their code and move on the the next module once its completed.

==Examples of Stubs==
===Java===
In Java, the basic technique is to implement the stub collaborators as concrete classes which only exhibit the small part of the overall behaviour of the collaborator which is needed by the class under test. As an example consider the case where a service implementation is under test. The implementation has a collaborator:

<pre>
public class SimpleService implements Service {
private Collaborator collaborator;
public void setCollaborator(Collaborator collaborator) {
this.collaborator = collaborator;
}

// part of Service interface
public boolean isActive() {
return collaborator.isActive();
}
}
</pre>

We could have a stub collaborator for testing as defined below:

<pre>
public class StubCollaboratorAdapter implements Collaborator {
public boolean isActive() {
return false;
}
}
</pre>

Now, a test case can be written as something like this:

<pre>
public void testActiveWhenCollaboratorIsActive() throws Exception {
Service service = new SimpleService();
service.setCollaborator(new StubCollaboratorAdapter() {
public boolean isActive() {
return true;
}
});
assertTrue(service.isActive());
}
</pre>

===Ruby===
While writing stubs, one might decide to replace a whole object or simply change the results of a single method. When you're replacing a whole object, it's easy—just write the new object and replace it within your test case. Methods might be tougher in some languages, but using dynamic languages such as Ruby, stubbing is easy because you're simply redefining a method.
Imagine you have a user interface that prints a document. You want to test code that handles a print failure. You really don't care if the print method gets called. You just want to verify that if your code does call print, that code will handle a failed print effectively. Think of what a pseudo-code sentence would look like.
On an instance of the document object, stub the print method, returning false.
You can break that sentence down into two parts. The first part identifies what you want to stub. The second part defines what the stub should do.
Below is an example of the Mocha framework that can be used to build stubs in Ruby:
<pre>
class Document
def print
# doesn't matter -- we are stubbing it out
end
end

class View
attr :document

def initialize(document)
@document = document
end

def print()
if document.print
puts "Excellent!"
true
else
puts "Not Great."
false
end
end
end
</pre>
Test code can be written as follows:
<pre>
require 'test/unit'
require 'rubygems'
require 'mocha'
require 'document'

class ViewTest < Test::Unit::TestCase

def test_should_return_false_for_failed_print
document = stub("my document")
document.stubs(:print).returns(false)

ui = View.new(document)
assert_equal false, ui.print
end

end
</pre>
You can see how this works. I build a simple, named stub object with the statement stub("my document"). Then, I define the behavior for print within the stub with the line of code document.stubs(:print).returns(false). If you look carefully, this line of code looks remarkably similar to the pseudo-code from earlier:
On an instance of the document object, stub the print method, returning false.

==IDE support for Stubs==
===Eclipse===

Eclipse provides support to create test stub methods to test the methods developed during development. We can create the junit test case on a java class. We can then select the methods in the class which we would like to test. This will automatically create test stubs to test those methods. In the figure below we are testing methods of ArrayList class

[[File:Eclipse123.png|center]]

===RubyMine===
The most basic way to create test templates in RubyMine is to use the regular procedure of creating files in the project. This means is both available for both plain Ruby projets, and for the Rails applications, and allows creating stub tests for Test::Unit, RSpec and Test-Spec.

For RSpec and Test-Spec, RubyMine provides a number of generators. These generators are context sensitive and become available depending on the selected location, and on the gems activated for your project. For example, ir rspec-rails is activated, the usual generators are hidden, and the list of generators includes only those specific for RSpec.

===Visual Studio===
Visual Studio is a fine IDE that provides good support for automatically generating stubs for methods. Generate Method Stub is an IntelliSense Automatic Code Generation feature that provides an easy way to have Visual Studio create a new method declaration at the time you are writing a method call. Visual Studio infers the declaration from the call. Some programming styles, such as test-driven development, suggest that you should consume before you define. That way, it is easier to figure out the form of the API that you are developing. You can use IntelliSense to program in that style. Using the Generate Method Stub operation, you avoid defining everything before you consume it.

The Generate Method Stub IntelliSense operation can also increase productivity because you do not need to move from the calling code, your present focus, to the defining code, a separate focus, in order to generate a new method. You can instead write a method call, and then invoke the Generate Method Stub operation without dividing your attention.

==Conclusion==
We need tests that “run fast, and help us localize problems.” This can be hard to accomplish when your code accesses a database, hits another server, is time-dependent, etc. By substituting custom objects such as stubs for some of your module's dependencies, you can thoroughly test your code, increase your coverage, and still run in less than a second. You can even simulate rare scenarios like database failures and test your error handling code.

One cannot rely on the traditional approach and wait for the entire system to be developed before subjecting it to various tests. With the increase in the demand for faster and more accurate software, stubs provide a great mechanism for testing. In general, Stubs greatly increase the speed of running unit tests and provide a means of testing code independently.

==References==
*[http://blog.springsource.org/2007/01/15/unit-testing-with-stubs-and-mocks/ Test Stubs and Mocks]
*[http://en.wikipedia.org/wiki/Test_stub Test Stubs on wikipedia]
*[http://www.jetbrains.com/ruby/webhelp/creating-test-templates.pdf Test Stub support in RubyMine]
*[http://googletesting.blogspot.com/2007/04/tott-stubs-speed-up-your-unit-tests.html Advantages of Stubs]
*[http://sqa.fyicenter.com/FAQ/Manual-Testing/What_is_stub_Explain_in_testing_point_of_view_.html Stubs and Testing]
*[http://martinfowler.com/articles/mocksArentStubs.html Mocks aren't Stubs]
*[http://www.captaindebug.com/2011/11/regular-unit-tests-and-stubs-testing.html Testing techniques]
* http://www.ibm.com/developerworks/web/library/wa-mockrails/index.html

CSC/ECE 517 Fall 2012/ch2a 2w13 sm

2012-10-27T22:30:11Z

Svmankar: /* Integration Testing */

==Introduction==
Test stubs are programs which simulate the behaviors of software components (or [http://en.wikipedia.org/wiki/Modular_programming modules]) on which other modules that are being tested are dependent upon.
Stubs are replacements for missing components that the components being tested will call as part of the test. While doing an [http://en.wikipedia.org/wiki/Integration_testing Integration], if we don't have all the modules ready and need to test a particular module which is ready then we use Stubs and Drivers.
Stubs are used in Integration testing for a [http://en.wikipedia.org/wiki/Top-down_and_bottom-up_design Top Down] Integration testing and Bottom Up Integration Testing.

[[File:Stubs.jpg|center]]

In the above figure, we can see that the Modules 2 and 3 are not yet implemented. However, if we need to test the modules 4,5 and 6 which are dependent on modules 2 and 3, we can simple use some dummy code in the form of Stubs 1 and 2 in place of the modules that return the values as expected by the modules beneath them. This piece of Dummy code is Called a Stub in a Top Down Integration. Hence Stubs are called Functions in Top Down Integration tests.

==Stubs in different phases of testing==
===Unit Testing===

In developing a huge software if we are following top down approach of development there may be some functionality which may not have been implemented. This can be overcome by implementing all the required functions. However, then we would be testing a huge chunk of code without actually testing it. This will lead to bugs and lot of time will be wasted on debugging. Consider the following example:

Suppose we want to evaluate an expression [http://en.wikipedia.org/wiki/Factorial factorial](x)/( sin(x) + tan(x) ). Assuming that we don't have library support available for calculating factorial,sin and tan of the given input we would have to write those functions. Using stubs we can write functions which would return appropriate values. Thus, assuming that factorial(x) is implemented then we can write stubs for sin and cos functions returning floating point values. We can than verify if our main function gives expected results for those values. This shows us that our main function, factorial are working correct without actually implementing sin and cos functions
<pre>
code:
int main()
{
float y=factorial(x) / (sin(x) + tan(x) );
return 0;
}
int factorial(x)
{

//implmentation of factorial
}

float sin(int x)
{
return 0.5;
}

float cos(int x)
{
return 0.3;
}
</pre>

===Functional Testing===

The idea of stub remains the same in different forms of testing. In unit testing we are dealing with working inside a module and hence we overwrite the dependent implementations by stub. This allows us to test the calling code without the actual implementation. In functional testing we will replace other modules or collaborators of a class. The client class might be interested in some service from some other class ( collaborator class ). However, again instead of implementing the actual class we will have a stub implementation. In ruby the [https://www.ruby-toolbox.com/projects/mocha mocha] gem provides support for functional test using stubbing. This helps in avoiding overlapping test cases. We can see the use of stubs in functional testing using mocha in ruby in the programming languages section.

===Integration Testing===
[http://en.wikipedia.org/wiki/Integration_testing Integration testing] is a logical extension of unit testing. In its simplest form, two units that have already been tested are combined into a component and the interface between them is tested. A component, in this sense, refers to an integrated aggregate of more than one unit. In a realistic scenario, many units are combined into components, which are in turn aggregated into even larger parts of the program. The idea is to test combinations of pieces and eventually expand the process to test your modules with those of other groups. Eventually all the modules making up a process are tested together. Beyond that, if the program is composed of more than one process, they should be tested in pairs rather than all at once.
Integration testing identifies problems that occur when units are combined. By using a test plan that requires you to test each unit and ensure the viability of each before combining units, you know that any errors discovered when combining units are likely related to the interface between units. This method reduces the number of possibilities to a far simpler level of analysis.
The top-down approach to integration testing requires the highest-level modules be test and integrated first. This allows high-level logic and data flow to be tested early in the process and it tends to minimize the need for drivers. However, the need for stubs complicates test management and low-level utilities are tested relatively late in the development cycle. Another disadvantage of top-down integration testing is its poor support for early release of limited functionality.

===Regression Testing===
[http://en.wikipedia.org/wiki/Regression_testing Regression testing] is any type of software testing that seeks to uncover new software bugs, or regressions, in existing functional and non-functional areas of a system after changes, such as enhancements, patches or configuration changes, have been made to them.
The intent of regression testing is to ensure that a change, such as a bugfix, did not introduce new faults. One of the main reasons for regression testing is to determine whether a change in one part of the software affects other parts of the software.
Common methods of regression testing include rerunning previously run tests and checking whether program behavior has changed and whether previously fixed faults have re-emerged. Regression testing can be used to test a system efficiently by systematically selecting the appropriate minimum set of tests needed to adequately cover a particular change.
In Regression testing the use of test stubs is minimized as most of the system is already implemented and the main goal of the regression test is to see if there are any bugs that might have been ‘regressed’ from the previous stages of integrations. Ideally there will not be unimplemented modules by the time a system is tested for regression. However, in case of mutually exclusive modules of a system, a test stub for one of them can be used to test the regression of the other.

==Stubs in software development==
===Agile Development Methodology===
[http://en.wikipedia.org/wiki/Agile_software_development Agile software development] is a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change. It is a conceptual framework that promotes foreseen interactions throughout the development cycle.
In such a development system, it recognizes that testing is not a separate phase, but an integral part of software development, along with coding. Agile testing is a software testing practice that follows the principles of agile software development. Agile testing involves all members of a cross-functional agile team, with special expertise contributed by testers, to ensure delivering the business value desired by the customer at frequent intervals, working at a sustainable pace. Specification by example, also known as acceptance test-driven development, is used to capture examples of desired and undesired behavior and guide coding.
In the agile testing toolkit, a stub is a piece of code that behaves in a predefined way, in order to simplify the testing process. Here are the kind of simplifications that a stub can bring:

* If the code under test never returns the same value (usage of a timestamp or of a random value), a stub can be used to fix the root of the undeterminism.

* If the code depends on some other class that has complex behavior that you don’t want to take into account in this test, using a stub for this other class can simplify its behavior and clarify the intent of the test

* If the code depends on some other code that is not yet written or released, it is possible to start building the rest of the code before the dependency is actually finished.

===Rapid Application Development===
[http://en.wikipedia.org/wiki/Rapid_application_development Rapid Application Development] or RAD is a style of programming that focuses on having tools that allow a program to be created quickly. This is particularly useful for graphically based programs as it is easy to create a frontend which can then be used for testing the backend code. It is a software development methodology that uses minimal planning in favor of rapid prototyping. The "planning" of software developed using RAD is interleaved with writing the software itself. The lack of extensive pre-planning generally allows software to be written much faster, and makes it easier to change requirements. In such a development scenario it becomes increasingly important to be able to write tests and successfully test the software the is being developed so that a complete product is developed in quick time. Test stubs ensure that the testing of code is not stalled in case other modules are still being developed. A programmer can immediately use test stubs and test their code and move on the the next module once its completed.

==Examples of Stubs==
===Java===
In Java, the basic technique is to implement the stub collaborators as concrete classes which only exhibit the small part of the overall behaviour of the collaborator which is needed by the class under test. As an example consider the case where a service implementation is under test. The implementation has a collaborator:

<pre>
public class SimpleService implements Service {
private Collaborator collaborator;
public void setCollaborator(Collaborator collaborator) {
this.collaborator = collaborator;
}

// part of Service interface
public boolean isActive() {
return collaborator.isActive();
}
}
</pre>

We could have a stub collaborator for testing as defined below:

<pre>
public class StubCollaboratorAdapter implements Collaborator {
public boolean isActive() {
return false;
}
}
</pre>

Now, a test case can be written as something like this:

<pre>
public void testActiveWhenCollaboratorIsActive() throws Exception {
Service service = new SimpleService();
service.setCollaborator(new StubCollaboratorAdapter() {
public boolean isActive() {
return true;
}
});
assertTrue(service.isActive());
}
</pre>

===Ruby===
While writing stubs, one might decide to replace a whole object or simply change the results of a single method. When you're replacing a whole object, it's easy—just write the new object and replace it within your test case. Methods might be tougher in some languages, but using dynamic languages such as Ruby, stubbing is easy because you're simply redefining a method.
Imagine you have a user interface that prints a document. You want to test code that handles a print failure. You really don't care if the print method gets called. You just want to verify that if your code does call print, that code will handle a failed print effectively. Think of what a pseudo-code sentence would look like.
On an instance of the document object, stub the print method, returning false.
You can break that sentence down into two parts. The first part identifies what you want to stub. The second part defines what the stub should do.
Below is an example of the Mocha framework that can be used to build stubs in Ruby:
<pre>
class Document
def print
# doesn't matter -- we are stubbing it out
end
end

class View
attr :document

def initialize(document)
@document = document
end

def print()
if document.print
puts "Excellent!"
true
else
puts "Not Great."
false
end
end
end
</pre>
Test code can be written as follows:
<pre>
require 'test/unit'
require 'rubygems'
require 'mocha'
require 'document'

class ViewTest < Test::Unit::TestCase

def test_should_return_false_for_failed_print
document = stub("my document")
document.stubs(:print).returns(false)

ui = View.new(document)
assert_equal false, ui.print
end

end
</pre>
You can see how this works. I build a simple, named stub object with the statement stub("my document"). Then, I define the behavior for print within the stub with the line of code document.stubs(:print).returns(false). If you look carefully, this line of code looks remarkably similar to the pseudo-code from earlier:
On an instance of the document object, stub the print method, returning false.

==IDE support for Stubs==
===Eclipse===

Eclipse provides support to create test stub methods to test the methods developed during development. We can create the junit test case on a java class. We can then select the methods in the class which we would like to test. This will automatically create test stubs to test those methods. In the figure below we are testing methods of ArrayList class

[[File:Eclipse123.png|center]]

===RubyMine===
The most basic way to create test templates in RubyMine is to use the regular procedure of creating files in the project. This means is both available for both plain Ruby projets, and for the Rails applications, and allows creating stub tests for Test::Unit, RSpec and Test-Spec.

For RSpec and Test-Spec, RubyMine provides a number of generators. These generators are context sensitive and become available depending on the selected location, and on the gems activated for your project. For example, ir rspec-rails is activated, the usual generators are hidden, and the list of generators includes only those specific for RSpec.

===Visual Studio===
Visual Studio is a fine IDE that provides good support for automatically generating stubs for methods. Generate Method Stub is an IntelliSense Automatic Code Generation feature that provides an easy way to have Visual Studio create a new method declaration at the time you are writing a method call. Visual Studio infers the declaration from the call. Some programming styles, such as test-driven development, suggest that you should consume before you define. That way, it is easier to figure out the form of the API that you are developing. You can use IntelliSense to program in that style. Using the Generate Method Stub operation, you avoid defining everything before you consume it.

The Generate Method Stub IntelliSense operation can also increase productivity because you do not need to move from the calling code, your present focus, to the defining code, a separate focus, in order to generate a new method. You can instead write a method call, and then invoke the Generate Method Stub operation without dividing your attention.

==Conclusion==
We need tests that “run fast, and help us localize problems.” This can be hard to accomplish when your code accesses a database, hits another server, is time-dependent, etc. By substituting custom objects such as stubs for some of your module's dependencies, you can thoroughly test your code, increase your coverage, and still run in less than a second. You can even simulate rare scenarios like database failures and test your error handling code.

One cannot rely on the traditional approach and wait for the entire system to be developed before subjecting it to various tests. With the increase in the demand for faster and more accurate software, stubs provide a great mechanism for testing. In general, Stubs greatly increase the speed of running unit tests and provide a means of testing code independently.

==References==
*[http://blog.springsource.org/2007/01/15/unit-testing-with-stubs-and-mocks/ Test Stubs and Mocks]
*[http://en.wikipedia.org/wiki/Test_stub Test Stubs on wikipedia]
*[http://www.jetbrains.com/ruby/webhelp/creating-test-templates.pdf Test Stub support in RubyMine]
*[http://googletesting.blogspot.com/2007/04/tott-stubs-speed-up-your-unit-tests.html Advantages of Stubs]
*[http://sqa.fyicenter.com/FAQ/Manual-Testing/What_is_stub_Explain_in_testing_point_of_view_.html Stubs and Testing]
*[http://martinfowler.com/articles/mocksArentStubs.html Mocks aren't Stubs]
*[http://www.captaindebug.com/2011/11/regular-unit-tests-and-stubs-testing.html Testing techniques]
* http://www.ibm.com/developerworks/web/library/wa-mockrails/index.html

CSC/ECE 517 Fall 2012/ch2a 2w13 sm

2012-10-27T22:29:32Z

Svmankar: /* Regression Testing */

==Introduction==
Test stubs are programs which simulate the behaviors of software components (or [http://en.wikipedia.org/wiki/Modular_programming modules]) on which other modules that are being tested are dependent upon.
Stubs are replacements for missing components that the components being tested will call as part of the test. While doing an [http://en.wikipedia.org/wiki/Integration_testing Integration], if we don't have all the modules ready and need to test a particular module which is ready then we use Stubs and Drivers.
Stubs are used in Integration testing for a [http://en.wikipedia.org/wiki/Top-down_and_bottom-up_design Top Down] Integration testing and Bottom Up Integration Testing.

[[File:Stubs.jpg|center]]

In the above figure, we can see that the Modules 2 and 3 are not yet implemented. However, if we need to test the modules 4,5 and 6 which are dependent on modules 2 and 3, we can simple use some dummy code in the form of Stubs 1 and 2 in place of the modules that return the values as expected by the modules beneath them. This piece of Dummy code is Called a Stub in a Top Down Integration. Hence Stubs are called Functions in Top Down Integration tests.

==Stubs in different phases of testing==
===Unit Testing===

In developing a huge software if we are following top down approach of development there may be some functionality which may not have been implemented. This can be overcome by implementing all the required functions. However, then we would be testing a huge chunk of code without actually testing it. This will lead to bugs and lot of time will be wasted on debugging. Consider the following example:

Suppose we want to evaluate an expression [http://en.wikipedia.org/wiki/Factorial factorial](x)/( sin(x) + tan(x) ). Assuming that we don't have library support available for calculating factorial,sin and tan of the given input we would have to write those functions. Using stubs we can write functions which would return appropriate values. Thus, assuming that factorial(x) is implemented then we can write stubs for sin and cos functions returning floating point values. We can than verify if our main function gives expected results for those values. This shows us that our main function, factorial are working correct without actually implementing sin and cos functions
<pre>
code:
int main()
{
float y=factorial(x) / (sin(x) + tan(x) );
return 0;
}
int factorial(x)
{

//implmentation of factorial
}

float sin(int x)
{
return 0.5;
}

float cos(int x)
{
return 0.3;
}
</pre>

===Functional Testing===

The idea of stub remains the same in different forms of testing. In unit testing we are dealing with working inside a module and hence we overwrite the dependent implementations by stub. This allows us to test the calling code without the actual implementation. In functional testing we will replace other modules or collaborators of a class. The client class might be interested in some service from some other class ( collaborator class ). However, again instead of implementing the actual class we will have a stub implementation. In ruby the [https://www.ruby-toolbox.com/projects/mocha mocha] gem provides support for functional test using stubbing. This helps in avoiding overlapping test cases. We can see the use of stubs in functional testing using mocha in ruby in the programming languages section.

===Integration Testing===
Integration testing is a logical extension of unit testing. In its simplest form, two units that have already been tested are combined into a component and the interface between them is tested. A component, in this sense, refers to an integrated aggregate of more than one unit. In a realistic scenario, many units are combined into components, which are in turn aggregated into even larger parts of the program. The idea is to test combinations of pieces and eventually expand the process to test your modules with those of other groups. Eventually all the modules making up a process are tested together. Beyond that, if the program is composed of more than one process, they should be tested in pairs rather than all at once.
Integration testing identifies problems that occur when units are combined. By using a test plan that requires you to test each unit and ensure the viability of each before combining units, you know that any errors discovered when combining units are likely related to the interface between units. This method reduces the number of possibilities to a far simpler level of analysis.
The top-down approach to integration testing requires the highest-level modules be test and integrated first. This allows high-level logic and data flow to be tested early in the process and it tends to minimize the need for drivers. However, the need for stubs complicates test management and low-level utilities are tested relatively late in the development cycle. Another disadvantage of top-down integration testing is its poor support for early release of limited functionality.

===Regression Testing===
[http://en.wikipedia.org/wiki/Regression_testing Regression testing] is any type of software testing that seeks to uncover new software bugs, or regressions, in existing functional and non-functional areas of a system after changes, such as enhancements, patches or configuration changes, have been made to them.
The intent of regression testing is to ensure that a change, such as a bugfix, did not introduce new faults. One of the main reasons for regression testing is to determine whether a change in one part of the software affects other parts of the software.
Common methods of regression testing include rerunning previously run tests and checking whether program behavior has changed and whether previously fixed faults have re-emerged. Regression testing can be used to test a system efficiently by systematically selecting the appropriate minimum set of tests needed to adequately cover a particular change.
In Regression testing the use of test stubs is minimized as most of the system is already implemented and the main goal of the regression test is to see if there are any bugs that might have been ‘regressed’ from the previous stages of integrations. Ideally there will not be unimplemented modules by the time a system is tested for regression. However, in case of mutually exclusive modules of a system, a test stub for one of them can be used to test the regression of the other.

==Stubs in software development==
===Agile Development Methodology===
[http://en.wikipedia.org/wiki/Agile_software_development Agile software development] is a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change. It is a conceptual framework that promotes foreseen interactions throughout the development cycle.
In such a development system, it recognizes that testing is not a separate phase, but an integral part of software development, along with coding. Agile testing is a software testing practice that follows the principles of agile software development. Agile testing involves all members of a cross-functional agile team, with special expertise contributed by testers, to ensure delivering the business value desired by the customer at frequent intervals, working at a sustainable pace. Specification by example, also known as acceptance test-driven development, is used to capture examples of desired and undesired behavior and guide coding.
In the agile testing toolkit, a stub is a piece of code that behaves in a predefined way, in order to simplify the testing process. Here are the kind of simplifications that a stub can bring:

* If the code under test never returns the same value (usage of a timestamp or of a random value), a stub can be used to fix the root of the undeterminism.

* If the code depends on some other class that has complex behavior that you don’t want to take into account in this test, using a stub for this other class can simplify its behavior and clarify the intent of the test

* If the code depends on some other code that is not yet written or released, it is possible to start building the rest of the code before the dependency is actually finished.

===Rapid Application Development===
[http://en.wikipedia.org/wiki/Rapid_application_development Rapid Application Development] or RAD is a style of programming that focuses on having tools that allow a program to be created quickly. This is particularly useful for graphically based programs as it is easy to create a frontend which can then be used for testing the backend code. It is a software development methodology that uses minimal planning in favor of rapid prototyping. The "planning" of software developed using RAD is interleaved with writing the software itself. The lack of extensive pre-planning generally allows software to be written much faster, and makes it easier to change requirements. In such a development scenario it becomes increasingly important to be able to write tests and successfully test the software the is being developed so that a complete product is developed in quick time. Test stubs ensure that the testing of code is not stalled in case other modules are still being developed. A programmer can immediately use test stubs and test their code and move on the the next module once its completed.

==Examples of Stubs==
===Java===
In Java, the basic technique is to implement the stub collaborators as concrete classes which only exhibit the small part of the overall behaviour of the collaborator which is needed by the class under test. As an example consider the case where a service implementation is under test. The implementation has a collaborator:

<pre>
public class SimpleService implements Service {
private Collaborator collaborator;
public void setCollaborator(Collaborator collaborator) {
this.collaborator = collaborator;
}

// part of Service interface
public boolean isActive() {
return collaborator.isActive();
}
}
</pre>

We could have a stub collaborator for testing as defined below:

<pre>
public class StubCollaboratorAdapter implements Collaborator {
public boolean isActive() {
return false;
}
}
</pre>

Now, a test case can be written as something like this:

<pre>
public void testActiveWhenCollaboratorIsActive() throws Exception {
Service service = new SimpleService();
service.setCollaborator(new StubCollaboratorAdapter() {
public boolean isActive() {
return true;
}
});
assertTrue(service.isActive());
}
</pre>

===Ruby===
While writing stubs, one might decide to replace a whole object or simply change the results of a single method. When you're replacing a whole object, it's easy—just write the new object and replace it within your test case. Methods might be tougher in some languages, but using dynamic languages such as Ruby, stubbing is easy because you're simply redefining a method.
Imagine you have a user interface that prints a document. You want to test code that handles a print failure. You really don't care if the print method gets called. You just want to verify that if your code does call print, that code will handle a failed print effectively. Think of what a pseudo-code sentence would look like.
On an instance of the document object, stub the print method, returning false.
You can break that sentence down into two parts. The first part identifies what you want to stub. The second part defines what the stub should do.
Below is an example of the Mocha framework that can be used to build stubs in Ruby:
<pre>
class Document
def print
# doesn't matter -- we are stubbing it out
end
end

class View
attr :document

def initialize(document)
@document = document
end

def print()
if document.print
puts "Excellent!"
true
else
puts "Not Great."
false
end
end
end
</pre>
Test code can be written as follows:
<pre>
require 'test/unit'
require 'rubygems'
require 'mocha'
require 'document'

class ViewTest < Test::Unit::TestCase

def test_should_return_false_for_failed_print
document = stub("my document")
document.stubs(:print).returns(false)

ui = View.new(document)
assert_equal false, ui.print
end

end
</pre>
You can see how this works. I build a simple, named stub object with the statement stub("my document"). Then, I define the behavior for print within the stub with the line of code document.stubs(:print).returns(false). If you look carefully, this line of code looks remarkably similar to the pseudo-code from earlier:
On an instance of the document object, stub the print method, returning false.

==IDE support for Stubs==
===Eclipse===

Eclipse provides support to create test stub methods to test the methods developed during development. We can create the junit test case on a java class. We can then select the methods in the class which we would like to test. This will automatically create test stubs to test those methods. In the figure below we are testing methods of ArrayList class

[[File:Eclipse123.png|center]]

===RubyMine===
The most basic way to create test templates in RubyMine is to use the regular procedure of creating files in the project. This means is both available for both plain Ruby projets, and for the Rails applications, and allows creating stub tests for Test::Unit, RSpec and Test-Spec.

For RSpec and Test-Spec, RubyMine provides a number of generators. These generators are context sensitive and become available depending on the selected location, and on the gems activated for your project. For example, ir rspec-rails is activated, the usual generators are hidden, and the list of generators includes only those specific for RSpec.

===Visual Studio===
Visual Studio is a fine IDE that provides good support for automatically generating stubs for methods. Generate Method Stub is an IntelliSense Automatic Code Generation feature that provides an easy way to have Visual Studio create a new method declaration at the time you are writing a method call. Visual Studio infers the declaration from the call. Some programming styles, such as test-driven development, suggest that you should consume before you define. That way, it is easier to figure out the form of the API that you are developing. You can use IntelliSense to program in that style. Using the Generate Method Stub operation, you avoid defining everything before you consume it.

The Generate Method Stub IntelliSense operation can also increase productivity because you do not need to move from the calling code, your present focus, to the defining code, a separate focus, in order to generate a new method. You can instead write a method call, and then invoke the Generate Method Stub operation without dividing your attention.

==Conclusion==
We need tests that “run fast, and help us localize problems.” This can be hard to accomplish when your code accesses a database, hits another server, is time-dependent, etc. By substituting custom objects such as stubs for some of your module's dependencies, you can thoroughly test your code, increase your coverage, and still run in less than a second. You can even simulate rare scenarios like database failures and test your error handling code.

One cannot rely on the traditional approach and wait for the entire system to be developed before subjecting it to various tests. With the increase in the demand for faster and more accurate software, stubs provide a great mechanism for testing. In general, Stubs greatly increase the speed of running unit tests and provide a means of testing code independently.

==References==
*[http://blog.springsource.org/2007/01/15/unit-testing-with-stubs-and-mocks/ Test Stubs and Mocks]
*[http://en.wikipedia.org/wiki/Test_stub Test Stubs on wikipedia]
*[http://www.jetbrains.com/ruby/webhelp/creating-test-templates.pdf Test Stub support in RubyMine]
*[http://googletesting.blogspot.com/2007/04/tott-stubs-speed-up-your-unit-tests.html Advantages of Stubs]
*[http://sqa.fyicenter.com/FAQ/Manual-Testing/What_is_stub_Explain_in_testing_point_of_view_.html Stubs and Testing]
*[http://martinfowler.com/articles/mocksArentStubs.html Mocks aren't Stubs]
*[http://www.captaindebug.com/2011/11/regular-unit-tests-and-stubs-testing.html Testing techniques]
* http://www.ibm.com/developerworks/web/library/wa-mockrails/index.html

CSC/ECE 517 Fall 2012/ch2a 2w13 sm

2012-10-27T22:28:18Z

Svmankar: /* Rapid Application Development */

==Introduction==
Test stubs are programs which simulate the behaviors of software components (or [http://en.wikipedia.org/wiki/Modular_programming modules]) on which other modules that are being tested are dependent upon.
Stubs are replacements for missing components that the components being tested will call as part of the test. While doing an [http://en.wikipedia.org/wiki/Integration_testing Integration], if we don't have all the modules ready and need to test a particular module which is ready then we use Stubs and Drivers.
Stubs are used in Integration testing for a [http://en.wikipedia.org/wiki/Top-down_and_bottom-up_design Top Down] Integration testing and Bottom Up Integration Testing.

[[File:Stubs.jpg|center]]

In the above figure, we can see that the Modules 2 and 3 are not yet implemented. However, if we need to test the modules 4,5 and 6 which are dependent on modules 2 and 3, we can simple use some dummy code in the form of Stubs 1 and 2 in place of the modules that return the values as expected by the modules beneath them. This piece of Dummy code is Called a Stub in a Top Down Integration. Hence Stubs are called Functions in Top Down Integration tests.

==Stubs in different phases of testing==
===Unit Testing===

In developing a huge software if we are following top down approach of development there may be some functionality which may not have been implemented. This can be overcome by implementing all the required functions. However, then we would be testing a huge chunk of code without actually testing it. This will lead to bugs and lot of time will be wasted on debugging. Consider the following example:

Suppose we want to evaluate an expression [http://en.wikipedia.org/wiki/Factorial factorial](x)/( sin(x) + tan(x) ). Assuming that we don't have library support available for calculating factorial,sin and tan of the given input we would have to write those functions. Using stubs we can write functions which would return appropriate values. Thus, assuming that factorial(x) is implemented then we can write stubs for sin and cos functions returning floating point values. We can than verify if our main function gives expected results for those values. This shows us that our main function, factorial are working correct without actually implementing sin and cos functions
<pre>
code:
int main()
{
float y=factorial(x) / (sin(x) + tan(x) );
return 0;
}
int factorial(x)
{

//implmentation of factorial
}

float sin(int x)
{
return 0.5;
}

float cos(int x)
{
return 0.3;
}
</pre>

===Functional Testing===

The idea of stub remains the same in different forms of testing. In unit testing we are dealing with working inside a module and hence we overwrite the dependent implementations by stub. This allows us to test the calling code without the actual implementation. In functional testing we will replace other modules or collaborators of a class. The client class might be interested in some service from some other class ( collaborator class ). However, again instead of implementing the actual class we will have a stub implementation. In ruby the [https://www.ruby-toolbox.com/projects/mocha mocha] gem provides support for functional test using stubbing. This helps in avoiding overlapping test cases. We can see the use of stubs in functional testing using mocha in ruby in the programming languages section.

===Integration Testing===
Integration testing is a logical extension of unit testing. In its simplest form, two units that have already been tested are combined into a component and the interface between them is tested. A component, in this sense, refers to an integrated aggregate of more than one unit. In a realistic scenario, many units are combined into components, which are in turn aggregated into even larger parts of the program. The idea is to test combinations of pieces and eventually expand the process to test your modules with those of other groups. Eventually all the modules making up a process are tested together. Beyond that, if the program is composed of more than one process, they should be tested in pairs rather than all at once.
Integration testing identifies problems that occur when units are combined. By using a test plan that requires you to test each unit and ensure the viability of each before combining units, you know that any errors discovered when combining units are likely related to the interface between units. This method reduces the number of possibilities to a far simpler level of analysis.
The top-down approach to integration testing requires the highest-level modules be test and integrated first. This allows high-level logic and data flow to be tested early in the process and it tends to minimize the need for drivers. However, the need for stubs complicates test management and low-level utilities are tested relatively late in the development cycle. Another disadvantage of top-down integration testing is its poor support for early release of limited functionality.

===Regression Testing===
Regression testing is any type of software testing that seeks to uncover new software bugs, or regressions, in existing functional and non-functional areas of a system after changes, such as enhancements, patches or configuration changes, have been made to them.
The intent of regression testing is to ensure that a change, such as a bugfix, did not introduce new faults.[1] One of the main reasons for regression testing is to determine whether a change in one part of the software affects other parts of the software.[2]
Common methods of regression testing include rerunning previously run tests and checking whether program behavior has changed and whether previously fixed faults have re-emerged. Regression testing can be used to test a system efficiently by systematically selecting the appropriate minimum set of tests needed to adequately cover a particular change.
In Regression testing the use of test stubs is minimized as most of the system is already implemented and the main goal of the regression test is to see if there are any bugs that might have been ‘regressed’ from the previous stages of integrations. Ideally there will not be unimplemented modules by the time a system is tested for regression. However, in case of mutually exclusive modules of a system, a test stub for one of them can be used to test the regression of the other.

==Stubs in software development==
===Agile Development Methodology===
[http://en.wikipedia.org/wiki/Agile_software_development Agile software development] is a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change. It is a conceptual framework that promotes foreseen interactions throughout the development cycle.
In such a development system, it recognizes that testing is not a separate phase, but an integral part of software development, along with coding. Agile testing is a software testing practice that follows the principles of agile software development. Agile testing involves all members of a cross-functional agile team, with special expertise contributed by testers, to ensure delivering the business value desired by the customer at frequent intervals, working at a sustainable pace. Specification by example, also known as acceptance test-driven development, is used to capture examples of desired and undesired behavior and guide coding.
In the agile testing toolkit, a stub is a piece of code that behaves in a predefined way, in order to simplify the testing process. Here are the kind of simplifications that a stub can bring:

* If the code under test never returns the same value (usage of a timestamp or of a random value), a stub can be used to fix the root of the undeterminism.

* If the code depends on some other class that has complex behavior that you don’t want to take into account in this test, using a stub for this other class can simplify its behavior and clarify the intent of the test

* If the code depends on some other code that is not yet written or released, it is possible to start building the rest of the code before the dependency is actually finished.

===Rapid Application Development===
[http://en.wikipedia.org/wiki/Rapid_application_development Rapid Application Development] or RAD is a style of programming that focuses on having tools that allow a program to be created quickly. This is particularly useful for graphically based programs as it is easy to create a frontend which can then be used for testing the backend code. It is a software development methodology that uses minimal planning in favor of rapid prototyping. The "planning" of software developed using RAD is interleaved with writing the software itself. The lack of extensive pre-planning generally allows software to be written much faster, and makes it easier to change requirements. In such a development scenario it becomes increasingly important to be able to write tests and successfully test the software the is being developed so that a complete product is developed in quick time. Test stubs ensure that the testing of code is not stalled in case other modules are still being developed. A programmer can immediately use test stubs and test their code and move on the the next module once its completed.

==Examples of Stubs==
===Java===
In Java, the basic technique is to implement the stub collaborators as concrete classes which only exhibit the small part of the overall behaviour of the collaborator which is needed by the class under test. As an example consider the case where a service implementation is under test. The implementation has a collaborator:

<pre>
public class SimpleService implements Service {
private Collaborator collaborator;
public void setCollaborator(Collaborator collaborator) {
this.collaborator = collaborator;
}

// part of Service interface
public boolean isActive() {
return collaborator.isActive();
}
}
</pre>

We could have a stub collaborator for testing as defined below:

<pre>
public class StubCollaboratorAdapter implements Collaborator {
public boolean isActive() {
return false;
}
}
</pre>

Now, a test case can be written as something like this:

<pre>
public void testActiveWhenCollaboratorIsActive() throws Exception {
Service service = new SimpleService();
service.setCollaborator(new StubCollaboratorAdapter() {
public boolean isActive() {
return true;
}
});
assertTrue(service.isActive());
}
</pre>

===Ruby===
While writing stubs, one might decide to replace a whole object or simply change the results of a single method. When you're replacing a whole object, it's easy—just write the new object and replace it within your test case. Methods might be tougher in some languages, but using dynamic languages such as Ruby, stubbing is easy because you're simply redefining a method.
Imagine you have a user interface that prints a document. You want to test code that handles a print failure. You really don't care if the print method gets called. You just want to verify that if your code does call print, that code will handle a failed print effectively. Think of what a pseudo-code sentence would look like.
On an instance of the document object, stub the print method, returning false.
You can break that sentence down into two parts. The first part identifies what you want to stub. The second part defines what the stub should do.
Below is an example of the Mocha framework that can be used to build stubs in Ruby:
<pre>
class Document
def print
# doesn't matter -- we are stubbing it out
end
end

class View
attr :document

def initialize(document)
@document = document
end

def print()
if document.print
puts "Excellent!"
true
else
puts "Not Great."
false
end
end
end
</pre>
Test code can be written as follows:
<pre>
require 'test/unit'
require 'rubygems'
require 'mocha'
require 'document'

class ViewTest < Test::Unit::TestCase

def test_should_return_false_for_failed_print
document = stub("my document")
document.stubs(:print).returns(false)

ui = View.new(document)
assert_equal false, ui.print
end

end
</pre>
You can see how this works. I build a simple, named stub object with the statement stub("my document"). Then, I define the behavior for print within the stub with the line of code document.stubs(:print).returns(false). If you look carefully, this line of code looks remarkably similar to the pseudo-code from earlier:
On an instance of the document object, stub the print method, returning false.

==IDE support for Stubs==
===Eclipse===

Eclipse provides support to create test stub methods to test the methods developed during development. We can create the junit test case on a java class. We can then select the methods in the class which we would like to test. This will automatically create test stubs to test those methods. In the figure below we are testing methods of ArrayList class

[[File:Eclipse123.png|center]]

===RubyMine===
The most basic way to create test templates in RubyMine is to use the regular procedure of creating files in the project. This means is both available for both plain Ruby projets, and for the Rails applications, and allows creating stub tests for Test::Unit, RSpec and Test-Spec.

For RSpec and Test-Spec, RubyMine provides a number of generators. These generators are context sensitive and become available depending on the selected location, and on the gems activated for your project. For example, ir rspec-rails is activated, the usual generators are hidden, and the list of generators includes only those specific for RSpec.

===Visual Studio===
Visual Studio is a fine IDE that provides good support for automatically generating stubs for methods. Generate Method Stub is an IntelliSense Automatic Code Generation feature that provides an easy way to have Visual Studio create a new method declaration at the time you are writing a method call. Visual Studio infers the declaration from the call. Some programming styles, such as test-driven development, suggest that you should consume before you define. That way, it is easier to figure out the form of the API that you are developing. You can use IntelliSense to program in that style. Using the Generate Method Stub operation, you avoid defining everything before you consume it.

The Generate Method Stub IntelliSense operation can also increase productivity because you do not need to move from the calling code, your present focus, to the defining code, a separate focus, in order to generate a new method. You can instead write a method call, and then invoke the Generate Method Stub operation without dividing your attention.

==Conclusion==
We need tests that “run fast, and help us localize problems.” This can be hard to accomplish when your code accesses a database, hits another server, is time-dependent, etc. By substituting custom objects such as stubs for some of your module's dependencies, you can thoroughly test your code, increase your coverage, and still run in less than a second. You can even simulate rare scenarios like database failures and test your error handling code.

One cannot rely on the traditional approach and wait for the entire system to be developed before subjecting it to various tests. With the increase in the demand for faster and more accurate software, stubs provide a great mechanism for testing. In general, Stubs greatly increase the speed of running unit tests and provide a means of testing code independently.

==References==
*[http://blog.springsource.org/2007/01/15/unit-testing-with-stubs-and-mocks/ Test Stubs and Mocks]
*[http://en.wikipedia.org/wiki/Test_stub Test Stubs on wikipedia]
*[http://www.jetbrains.com/ruby/webhelp/creating-test-templates.pdf Test Stub support in RubyMine]
*[http://googletesting.blogspot.com/2007/04/tott-stubs-speed-up-your-unit-tests.html Advantages of Stubs]
*[http://sqa.fyicenter.com/FAQ/Manual-Testing/What_is_stub_Explain_in_testing_point_of_view_.html Stubs and Testing]
*[http://martinfowler.com/articles/mocksArentStubs.html Mocks aren't Stubs]
*[http://www.captaindebug.com/2011/11/regular-unit-tests-and-stubs-testing.html Testing techniques]
* http://www.ibm.com/developerworks/web/library/wa-mockrails/index.html

CSC/ECE 517 Fall 2012/ch2a 2w13 sm

2012-10-27T22:27:44Z

Svmankar: /* Agile Development Methodology */

==Introduction==
Test stubs are programs which simulate the behaviors of software components (or [http://en.wikipedia.org/wiki/Modular_programming modules]) on which other modules that are being tested are dependent upon.
Stubs are replacements for missing components that the components being tested will call as part of the test. While doing an [http://en.wikipedia.org/wiki/Integration_testing Integration], if we don't have all the modules ready and need to test a particular module which is ready then we use Stubs and Drivers.
Stubs are used in Integration testing for a [http://en.wikipedia.org/wiki/Top-down_and_bottom-up_design Top Down] Integration testing and Bottom Up Integration Testing.

[[File:Stubs.jpg|center]]

In the above figure, we can see that the Modules 2 and 3 are not yet implemented. However, if we need to test the modules 4,5 and 6 which are dependent on modules 2 and 3, we can simple use some dummy code in the form of Stubs 1 and 2 in place of the modules that return the values as expected by the modules beneath them. This piece of Dummy code is Called a Stub in a Top Down Integration. Hence Stubs are called Functions in Top Down Integration tests.

==Stubs in different phases of testing==
===Unit Testing===

In developing a huge software if we are following top down approach of development there may be some functionality which may not have been implemented. This can be overcome by implementing all the required functions. However, then we would be testing a huge chunk of code without actually testing it. This will lead to bugs and lot of time will be wasted on debugging. Consider the following example:

Suppose we want to evaluate an expression [http://en.wikipedia.org/wiki/Factorial factorial](x)/( sin(x) + tan(x) ). Assuming that we don't have library support available for calculating factorial,sin and tan of the given input we would have to write those functions. Using stubs we can write functions which would return appropriate values. Thus, assuming that factorial(x) is implemented then we can write stubs for sin and cos functions returning floating point values. We can than verify if our main function gives expected results for those values. This shows us that our main function, factorial are working correct without actually implementing sin and cos functions
<pre>
code:
int main()
{
float y=factorial(x) / (sin(x) + tan(x) );
return 0;
}
int factorial(x)
{

//implmentation of factorial
}

float sin(int x)
{
return 0.5;
}

float cos(int x)
{
return 0.3;
}
</pre>

===Functional Testing===

The idea of stub remains the same in different forms of testing. In unit testing we are dealing with working inside a module and hence we overwrite the dependent implementations by stub. This allows us to test the calling code without the actual implementation. In functional testing we will replace other modules or collaborators of a class. The client class might be interested in some service from some other class ( collaborator class ). However, again instead of implementing the actual class we will have a stub implementation. In ruby the [https://www.ruby-toolbox.com/projects/mocha mocha] gem provides support for functional test using stubbing. This helps in avoiding overlapping test cases. We can see the use of stubs in functional testing using mocha in ruby in the programming languages section.

===Integration Testing===
Integration testing is a logical extension of unit testing. In its simplest form, two units that have already been tested are combined into a component and the interface between them is tested. A component, in this sense, refers to an integrated aggregate of more than one unit. In a realistic scenario, many units are combined into components, which are in turn aggregated into even larger parts of the program. The idea is to test combinations of pieces and eventually expand the process to test your modules with those of other groups. Eventually all the modules making up a process are tested together. Beyond that, if the program is composed of more than one process, they should be tested in pairs rather than all at once.
Integration testing identifies problems that occur when units are combined. By using a test plan that requires you to test each unit and ensure the viability of each before combining units, you know that any errors discovered when combining units are likely related to the interface between units. This method reduces the number of possibilities to a far simpler level of analysis.
The top-down approach to integration testing requires the highest-level modules be test and integrated first. This allows high-level logic and data flow to be tested early in the process and it tends to minimize the need for drivers. However, the need for stubs complicates test management and low-level utilities are tested relatively late in the development cycle. Another disadvantage of top-down integration testing is its poor support for early release of limited functionality.

===Regression Testing===
Regression testing is any type of software testing that seeks to uncover new software bugs, or regressions, in existing functional and non-functional areas of a system after changes, such as enhancements, patches or configuration changes, have been made to them.
The intent of regression testing is to ensure that a change, such as a bugfix, did not introduce new faults.[1] One of the main reasons for regression testing is to determine whether a change in one part of the software affects other parts of the software.[2]
Common methods of regression testing include rerunning previously run tests and checking whether program behavior has changed and whether previously fixed faults have re-emerged. Regression testing can be used to test a system efficiently by systematically selecting the appropriate minimum set of tests needed to adequately cover a particular change.
In Regression testing the use of test stubs is minimized as most of the system is already implemented and the main goal of the regression test is to see if there are any bugs that might have been ‘regressed’ from the previous stages of integrations. Ideally there will not be unimplemented modules by the time a system is tested for regression. However, in case of mutually exclusive modules of a system, a test stub for one of them can be used to test the regression of the other.

==Stubs in software development==
===Agile Development Methodology===
[http://en.wikipedia.org/wiki/Agile_software_development Agile software development] is a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change. It is a conceptual framework that promotes foreseen interactions throughout the development cycle.
In such a development system, it recognizes that testing is not a separate phase, but an integral part of software development, along with coding. Agile testing is a software testing practice that follows the principles of agile software development. Agile testing involves all members of a cross-functional agile team, with special expertise contributed by testers, to ensure delivering the business value desired by the customer at frequent intervals, working at a sustainable pace. Specification by example, also known as acceptance test-driven development, is used to capture examples of desired and undesired behavior and guide coding.
In the agile testing toolkit, a stub is a piece of code that behaves in a predefined way, in order to simplify the testing process. Here are the kind of simplifications that a stub can bring:

* If the code under test never returns the same value (usage of a timestamp or of a random value), a stub can be used to fix the root of the undeterminism.

* If the code depends on some other class that has complex behavior that you don’t want to take into account in this test, using a stub for this other class can simplify its behavior and clarify the intent of the test

* If the code depends on some other code that is not yet written or released, it is possible to start building the rest of the code before the dependency is actually finished.

===Rapid Application Development===
Rapid Application Development or RAD is a style of programming that focuses on having tools that allow a program to be created quickly. This is particularly useful for graphically based programs as it is easy to create a frontend which can then be used for testing the backend code. It is a software development methodology that uses minimal planning in favor of rapid prototyping. The "planning" of software developed using RAD is interleaved with writing the software itself. The lack of extensive pre-planning generally allows software to be written much faster, and makes it easier to change requirements. In such a development scenario it becomes increasingly important to be able to write tests and successfully test the software the is being developed so that a complete product is developed in quick time. Test stubs ensure that the testing of code is not stalled in case other modules are still being developed. A programmer can immediately use test stubs and test their code and move on the the next module once its completed.

==Examples of Stubs==
===Java===
In Java, the basic technique is to implement the stub collaborators as concrete classes which only exhibit the small part of the overall behaviour of the collaborator which is needed by the class under test. As an example consider the case where a service implementation is under test. The implementation has a collaborator:

<pre>
public class SimpleService implements Service {
private Collaborator collaborator;
public void setCollaborator(Collaborator collaborator) {
this.collaborator = collaborator;
}

// part of Service interface
public boolean isActive() {
return collaborator.isActive();
}
}
</pre>

We could have a stub collaborator for testing as defined below:

<pre>
public class StubCollaboratorAdapter implements Collaborator {
public boolean isActive() {
return false;
}
}
</pre>

Now, a test case can be written as something like this:

<pre>
public void testActiveWhenCollaboratorIsActive() throws Exception {
Service service = new SimpleService();
service.setCollaborator(new StubCollaboratorAdapter() {
public boolean isActive() {
return true;
}
});
assertTrue(service.isActive());
}
</pre>

===Ruby===
While writing stubs, one might decide to replace a whole object or simply change the results of a single method. When you're replacing a whole object, it's easy—just write the new object and replace it within your test case. Methods might be tougher in some languages, but using dynamic languages such as Ruby, stubbing is easy because you're simply redefining a method.
Imagine you have a user interface that prints a document. You want to test code that handles a print failure. You really don't care if the print method gets called. You just want to verify that if your code does call print, that code will handle a failed print effectively. Think of what a pseudo-code sentence would look like.
On an instance of the document object, stub the print method, returning false.
You can break that sentence down into two parts. The first part identifies what you want to stub. The second part defines what the stub should do.
Below is an example of the Mocha framework that can be used to build stubs in Ruby:
<pre>
class Document
def print
# doesn't matter -- we are stubbing it out
end
end

class View
attr :document

def initialize(document)
@document = document
end

def print()
if document.print
puts "Excellent!"
true
else
puts "Not Great."
false
end
end
end
</pre>
Test code can be written as follows:
<pre>
require 'test/unit'
require 'rubygems'
require 'mocha'
require 'document'

class ViewTest < Test::Unit::TestCase

def test_should_return_false_for_failed_print
document = stub("my document")
document.stubs(:print).returns(false)

ui = View.new(document)
assert_equal false, ui.print
end

end
</pre>
You can see how this works. I build a simple, named stub object with the statement stub("my document"). Then, I define the behavior for print within the stub with the line of code document.stubs(:print).returns(false). If you look carefully, this line of code looks remarkably similar to the pseudo-code from earlier:
On an instance of the document object, stub the print method, returning false.

==IDE support for Stubs==
===Eclipse===

Eclipse provides support to create test stub methods to test the methods developed during development. We can create the junit test case on a java class. We can then select the methods in the class which we would like to test. This will automatically create test stubs to test those methods. In the figure below we are testing methods of ArrayList class

[[File:Eclipse123.png|center]]

===RubyMine===
The most basic way to create test templates in RubyMine is to use the regular procedure of creating files in the project. This means is both available for both plain Ruby projets, and for the Rails applications, and allows creating stub tests for Test::Unit, RSpec and Test-Spec.

For RSpec and Test-Spec, RubyMine provides a number of generators. These generators are context sensitive and become available depending on the selected location, and on the gems activated for your project. For example, ir rspec-rails is activated, the usual generators are hidden, and the list of generators includes only those specific for RSpec.

===Visual Studio===
Visual Studio is a fine IDE that provides good support for automatically generating stubs for methods. Generate Method Stub is an IntelliSense Automatic Code Generation feature that provides an easy way to have Visual Studio create a new method declaration at the time you are writing a method call. Visual Studio infers the declaration from the call. Some programming styles, such as test-driven development, suggest that you should consume before you define. That way, it is easier to figure out the form of the API that you are developing. You can use IntelliSense to program in that style. Using the Generate Method Stub operation, you avoid defining everything before you consume it.

The Generate Method Stub IntelliSense operation can also increase productivity because you do not need to move from the calling code, your present focus, to the defining code, a separate focus, in order to generate a new method. You can instead write a method call, and then invoke the Generate Method Stub operation without dividing your attention.

==Conclusion==
We need tests that “run fast, and help us localize problems.” This can be hard to accomplish when your code accesses a database, hits another server, is time-dependent, etc. By substituting custom objects such as stubs for some of your module's dependencies, you can thoroughly test your code, increase your coverage, and still run in less than a second. You can even simulate rare scenarios like database failures and test your error handling code.

One cannot rely on the traditional approach and wait for the entire system to be developed before subjecting it to various tests. With the increase in the demand for faster and more accurate software, stubs provide a great mechanism for testing. In general, Stubs greatly increase the speed of running unit tests and provide a means of testing code independently.

==References==
*[http://blog.springsource.org/2007/01/15/unit-testing-with-stubs-and-mocks/ Test Stubs and Mocks]
*[http://en.wikipedia.org/wiki/Test_stub Test Stubs on wikipedia]
*[http://www.jetbrains.com/ruby/webhelp/creating-test-templates.pdf Test Stub support in RubyMine]
*[http://googletesting.blogspot.com/2007/04/tott-stubs-speed-up-your-unit-tests.html Advantages of Stubs]
*[http://sqa.fyicenter.com/FAQ/Manual-Testing/What_is_stub_Explain_in_testing_point_of_view_.html Stubs and Testing]
*[http://martinfowler.com/articles/mocksArentStubs.html Mocks aren't Stubs]
*[http://www.captaindebug.com/2011/11/regular-unit-tests-and-stubs-testing.html Testing techniques]
* http://www.ibm.com/developerworks/web/library/wa-mockrails/index.html

CSC/ECE 517 Fall 2012/ch2a 2w13 sm

2012-10-27T22:26:52Z

Svmankar: /* Functional Testing */

==Introduction==
Test stubs are programs which simulate the behaviors of software components (or [http://en.wikipedia.org/wiki/Modular_programming modules]) on which other modules that are being tested are dependent upon.
Stubs are replacements for missing components that the components being tested will call as part of the test. While doing an [http://en.wikipedia.org/wiki/Integration_testing Integration], if we don't have all the modules ready and need to test a particular module which is ready then we use Stubs and Drivers.
Stubs are used in Integration testing for a [http://en.wikipedia.org/wiki/Top-down_and_bottom-up_design Top Down] Integration testing and Bottom Up Integration Testing.

[[File:Stubs.jpg|center]]

In the above figure, we can see that the Modules 2 and 3 are not yet implemented. However, if we need to test the modules 4,5 and 6 which are dependent on modules 2 and 3, we can simple use some dummy code in the form of Stubs 1 and 2 in place of the modules that return the values as expected by the modules beneath them. This piece of Dummy code is Called a Stub in a Top Down Integration. Hence Stubs are called Functions in Top Down Integration tests.

==Stubs in different phases of testing==
===Unit Testing===

In developing a huge software if we are following top down approach of development there may be some functionality which may not have been implemented. This can be overcome by implementing all the required functions. However, then we would be testing a huge chunk of code without actually testing it. This will lead to bugs and lot of time will be wasted on debugging. Consider the following example:

Suppose we want to evaluate an expression [http://en.wikipedia.org/wiki/Factorial factorial](x)/( sin(x) + tan(x) ). Assuming that we don't have library support available for calculating factorial,sin and tan of the given input we would have to write those functions. Using stubs we can write functions which would return appropriate values. Thus, assuming that factorial(x) is implemented then we can write stubs for sin and cos functions returning floating point values. We can than verify if our main function gives expected results for those values. This shows us that our main function, factorial are working correct without actually implementing sin and cos functions
<pre>
code:
int main()
{
float y=factorial(x) / (sin(x) + tan(x) );
return 0;
}
int factorial(x)
{

//implmentation of factorial
}

float sin(int x)
{
return 0.5;
}

float cos(int x)
{
return 0.3;
}
</pre>

===Functional Testing===

The idea of stub remains the same in different forms of testing. In unit testing we are dealing with working inside a module and hence we overwrite the dependent implementations by stub. This allows us to test the calling code without the actual implementation. In functional testing we will replace other modules or collaborators of a class. The client class might be interested in some service from some other class ( collaborator class ). However, again instead of implementing the actual class we will have a stub implementation. In ruby the [https://www.ruby-toolbox.com/projects/mocha mocha] gem provides support for functional test using stubbing. This helps in avoiding overlapping test cases. We can see the use of stubs in functional testing using mocha in ruby in the programming languages section.

===Integration Testing===
Integration testing is a logical extension of unit testing. In its simplest form, two units that have already been tested are combined into a component and the interface between them is tested. A component, in this sense, refers to an integrated aggregate of more than one unit. In a realistic scenario, many units are combined into components, which are in turn aggregated into even larger parts of the program. The idea is to test combinations of pieces and eventually expand the process to test your modules with those of other groups. Eventually all the modules making up a process are tested together. Beyond that, if the program is composed of more than one process, they should be tested in pairs rather than all at once.
Integration testing identifies problems that occur when units are combined. By using a test plan that requires you to test each unit and ensure the viability of each before combining units, you know that any errors discovered when combining units are likely related to the interface between units. This method reduces the number of possibilities to a far simpler level of analysis.
The top-down approach to integration testing requires the highest-level modules be test and integrated first. This allows high-level logic and data flow to be tested early in the process and it tends to minimize the need for drivers. However, the need for stubs complicates test management and low-level utilities are tested relatively late in the development cycle. Another disadvantage of top-down integration testing is its poor support for early release of limited functionality.

===Regression Testing===
Regression testing is any type of software testing that seeks to uncover new software bugs, or regressions, in existing functional and non-functional areas of a system after changes, such as enhancements, patches or configuration changes, have been made to them.
The intent of regression testing is to ensure that a change, such as a bugfix, did not introduce new faults.[1] One of the main reasons for regression testing is to determine whether a change in one part of the software affects other parts of the software.[2]
Common methods of regression testing include rerunning previously run tests and checking whether program behavior has changed and whether previously fixed faults have re-emerged. Regression testing can be used to test a system efficiently by systematically selecting the appropriate minimum set of tests needed to adequately cover a particular change.
In Regression testing the use of test stubs is minimized as most of the system is already implemented and the main goal of the regression test is to see if there are any bugs that might have been ‘regressed’ from the previous stages of integrations. Ideally there will not be unimplemented modules by the time a system is tested for regression. However, in case of mutually exclusive modules of a system, a test stub for one of them can be used to test the regression of the other.

==Stubs in software development==
===Agile Development Methodology===
Agile software development is a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change. It is a conceptual framework that promotes foreseen interactions throughout the development cycle.
In such a development system, it recognizes that testing is not a separate phase, but an integral part of software development, along with coding. Agile testing is a software testing practice that follows the principles of agile software development. Agile testing involves all members of a cross-functional agile team, with special expertise contributed by testers, to ensure delivering the business value desired by the customer at frequent intervals, working at a sustainable pace. Specification by example, also known as acceptance test-driven development, is used to capture examples of desired and undesired behavior and guide coding.
In the agile testing toolkit, a stub is a piece of code that behaves in a predefined way, in order to simplify the testing process. Here are the kind of simplifications that a stub can bring:

* If the code under test never returns the same value (usage of a timestamp or of a random value), a stub can be used to fix the root of the undeterminism.

* If the code depends on some other class that has complex behavior that you don’t want to take into account in this test, using a stub for this other class can simplify its behavior and clarify the intent of the test

* If the code depends on some other code that is not yet written or released, it is possible to start building the rest of the code before the dependency is actually finished.

===Rapid Application Development===
Rapid Application Development or RAD is a style of programming that focuses on having tools that allow a program to be created quickly. This is particularly useful for graphically based programs as it is easy to create a frontend which can then be used for testing the backend code. It is a software development methodology that uses minimal planning in favor of rapid prototyping. The "planning" of software developed using RAD is interleaved with writing the software itself. The lack of extensive pre-planning generally allows software to be written much faster, and makes it easier to change requirements. In such a development scenario it becomes increasingly important to be able to write tests and successfully test the software the is being developed so that a complete product is developed in quick time. Test stubs ensure that the testing of code is not stalled in case other modules are still being developed. A programmer can immediately use test stubs and test their code and move on the the next module once its completed.

==Examples of Stubs==
===Java===
In Java, the basic technique is to implement the stub collaborators as concrete classes which only exhibit the small part of the overall behaviour of the collaborator which is needed by the class under test. As an example consider the case where a service implementation is under test. The implementation has a collaborator:

<pre>
public class SimpleService implements Service {
private Collaborator collaborator;
public void setCollaborator(Collaborator collaborator) {
this.collaborator = collaborator;
}

// part of Service interface
public boolean isActive() {
return collaborator.isActive();
}
}
</pre>

We could have a stub collaborator for testing as defined below:

<pre>
public class StubCollaboratorAdapter implements Collaborator {
public boolean isActive() {
return false;
}
}
</pre>

Now, a test case can be written as something like this:

<pre>
public void testActiveWhenCollaboratorIsActive() throws Exception {
Service service = new SimpleService();
service.setCollaborator(new StubCollaboratorAdapter() {
public boolean isActive() {
return true;
}
});
assertTrue(service.isActive());
}
</pre>

===Ruby===
While writing stubs, one might decide to replace a whole object or simply change the results of a single method. When you're replacing a whole object, it's easy—just write the new object and replace it within your test case. Methods might be tougher in some languages, but using dynamic languages such as Ruby, stubbing is easy because you're simply redefining a method.
Imagine you have a user interface that prints a document. You want to test code that handles a print failure. You really don't care if the print method gets called. You just want to verify that if your code does call print, that code will handle a failed print effectively. Think of what a pseudo-code sentence would look like.
On an instance of the document object, stub the print method, returning false.
You can break that sentence down into two parts. The first part identifies what you want to stub. The second part defines what the stub should do.
Below is an example of the Mocha framework that can be used to build stubs in Ruby:
<pre>
class Document
def print
# doesn't matter -- we are stubbing it out
end
end

class View
attr :document

def initialize(document)
@document = document
end

def print()
if document.print
puts "Excellent!"
true
else
puts "Not Great."
false
end
end
end
</pre>
Test code can be written as follows:
<pre>
require 'test/unit'
require 'rubygems'
require 'mocha'
require 'document'

class ViewTest < Test::Unit::TestCase

def test_should_return_false_for_failed_print
document = stub("my document")
document.stubs(:print).returns(false)

ui = View.new(document)
assert_equal false, ui.print
end

end
</pre>
You can see how this works. I build a simple, named stub object with the statement stub("my document"). Then, I define the behavior for print within the stub with the line of code document.stubs(:print).returns(false). If you look carefully, this line of code looks remarkably similar to the pseudo-code from earlier:
On an instance of the document object, stub the print method, returning false.

==IDE support for Stubs==
===Eclipse===

Eclipse provides support to create test stub methods to test the methods developed during development. We can create the junit test case on a java class. We can then select the methods in the class which we would like to test. This will automatically create test stubs to test those methods. In the figure below we are testing methods of ArrayList class

[[File:Eclipse123.png|center]]

===RubyMine===
The most basic way to create test templates in RubyMine is to use the regular procedure of creating files in the project. This means is both available for both plain Ruby projets, and for the Rails applications, and allows creating stub tests for Test::Unit, RSpec and Test-Spec.

For RSpec and Test-Spec, RubyMine provides a number of generators. These generators are context sensitive and become available depending on the selected location, and on the gems activated for your project. For example, ir rspec-rails is activated, the usual generators are hidden, and the list of generators includes only those specific for RSpec.

===Visual Studio===
Visual Studio is a fine IDE that provides good support for automatically generating stubs for methods. Generate Method Stub is an IntelliSense Automatic Code Generation feature that provides an easy way to have Visual Studio create a new method declaration at the time you are writing a method call. Visual Studio infers the declaration from the call. Some programming styles, such as test-driven development, suggest that you should consume before you define. That way, it is easier to figure out the form of the API that you are developing. You can use IntelliSense to program in that style. Using the Generate Method Stub operation, you avoid defining everything before you consume it.

The Generate Method Stub IntelliSense operation can also increase productivity because you do not need to move from the calling code, your present focus, to the defining code, a separate focus, in order to generate a new method. You can instead write a method call, and then invoke the Generate Method Stub operation without dividing your attention.

==Conclusion==
We need tests that “run fast, and help us localize problems.” This can be hard to accomplish when your code accesses a database, hits another server, is time-dependent, etc. By substituting custom objects such as stubs for some of your module's dependencies, you can thoroughly test your code, increase your coverage, and still run in less than a second. You can even simulate rare scenarios like database failures and test your error handling code.

One cannot rely on the traditional approach and wait for the entire system to be developed before subjecting it to various tests. With the increase in the demand for faster and more accurate software, stubs provide a great mechanism for testing. In general, Stubs greatly increase the speed of running unit tests and provide a means of testing code independently.

==References==
*[http://blog.springsource.org/2007/01/15/unit-testing-with-stubs-and-mocks/ Test Stubs and Mocks]
*[http://en.wikipedia.org/wiki/Test_stub Test Stubs on wikipedia]
*[http://www.jetbrains.com/ruby/webhelp/creating-test-templates.pdf Test Stub support in RubyMine]
*[http://googletesting.blogspot.com/2007/04/tott-stubs-speed-up-your-unit-tests.html Advantages of Stubs]
*[http://sqa.fyicenter.com/FAQ/Manual-Testing/What_is_stub_Explain_in_testing_point_of_view_.html Stubs and Testing]
*[http://martinfowler.com/articles/mocksArentStubs.html Mocks aren't Stubs]
*[http://www.captaindebug.com/2011/11/regular-unit-tests-and-stubs-testing.html Testing techniques]
* http://www.ibm.com/developerworks/web/library/wa-mockrails/index.html

CSC/ECE 517 Fall 2012/ch2a 2w13 sm

2012-10-27T22:25:55Z

Svmankar: /* Unit Testing */

==Introduction==
Test stubs are programs which simulate the behaviors of software components (or [http://en.wikipedia.org/wiki/Modular_programming modules]) on which other modules that are being tested are dependent upon.
Stubs are replacements for missing components that the components being tested will call as part of the test. While doing an [http://en.wikipedia.org/wiki/Integration_testing Integration], if we don't have all the modules ready and need to test a particular module which is ready then we use Stubs and Drivers.
Stubs are used in Integration testing for a [http://en.wikipedia.org/wiki/Top-down_and_bottom-up_design Top Down] Integration testing and Bottom Up Integration Testing.

[[File:Stubs.jpg|center]]

In the above figure, we can see that the Modules 2 and 3 are not yet implemented. However, if we need to test the modules 4,5 and 6 which are dependent on modules 2 and 3, we can simple use some dummy code in the form of Stubs 1 and 2 in place of the modules that return the values as expected by the modules beneath them. This piece of Dummy code is Called a Stub in a Top Down Integration. Hence Stubs are called Functions in Top Down Integration tests.

==Stubs in different phases of testing==
===Unit Testing===

In developing a huge software if we are following top down approach of development there may be some functionality which may not have been implemented. This can be overcome by implementing all the required functions. However, then we would be testing a huge chunk of code without actually testing it. This will lead to bugs and lot of time will be wasted on debugging. Consider the following example:

Suppose we want to evaluate an expression [http://en.wikipedia.org/wiki/Factorial factorial](x)/( sin(x) + tan(x) ). Assuming that we don't have library support available for calculating factorial,sin and tan of the given input we would have to write those functions. Using stubs we can write functions which would return appropriate values. Thus, assuming that factorial(x) is implemented then we can write stubs for sin and cos functions returning floating point values. We can than verify if our main function gives expected results for those values. This shows us that our main function, factorial are working correct without actually implementing sin and cos functions
<pre>
code:
int main()
{
float y=factorial(x) / (sin(x) + tan(x) );
return 0;
}
int factorial(x)
{

//implmentation of factorial
}

float sin(int x)
{
return 0.5;
}

float cos(int x)
{
return 0.3;
}
</pre>

===Functional Testing===

The idea of stub remains the same in different forms of testing. In unit testing we are dealing with working inside a module and hence we overwrite the dependent implementations by stub. This allows us to test the calling code without the actual implementation. In functional testing we will replace other modules or collaborators of a class. The client class might be interested in some service from some other class ( collaborator class ). However, again instead of implementing the actual class we will have a stub implementation. In ruby the mocha gem provides support for functional test using stubbing. This helps in avoiding overlapping test cases. We can see the use of stubs in functional testing using mocha in ruby in the programming languages section.

===Integration Testing===
Integration testing is a logical extension of unit testing. In its simplest form, two units that have already been tested are combined into a component and the interface between them is tested. A component, in this sense, refers to an integrated aggregate of more than one unit. In a realistic scenario, many units are combined into components, which are in turn aggregated into even larger parts of the program. The idea is to test combinations of pieces and eventually expand the process to test your modules with those of other groups. Eventually all the modules making up a process are tested together. Beyond that, if the program is composed of more than one process, they should be tested in pairs rather than all at once.
Integration testing identifies problems that occur when units are combined. By using a test plan that requires you to test each unit and ensure the viability of each before combining units, you know that any errors discovered when combining units are likely related to the interface between units. This method reduces the number of possibilities to a far simpler level of analysis.
The top-down approach to integration testing requires the highest-level modules be test and integrated first. This allows high-level logic and data flow to be tested early in the process and it tends to minimize the need for drivers. However, the need for stubs complicates test management and low-level utilities are tested relatively late in the development cycle. Another disadvantage of top-down integration testing is its poor support for early release of limited functionality.

===Regression Testing===
Regression testing is any type of software testing that seeks to uncover new software bugs, or regressions, in existing functional and non-functional areas of a system after changes, such as enhancements, patches or configuration changes, have been made to them.
The intent of regression testing is to ensure that a change, such as a bugfix, did not introduce new faults.[1] One of the main reasons for regression testing is to determine whether a change in one part of the software affects other parts of the software.[2]
Common methods of regression testing include rerunning previously run tests and checking whether program behavior has changed and whether previously fixed faults have re-emerged. Regression testing can be used to test a system efficiently by systematically selecting the appropriate minimum set of tests needed to adequately cover a particular change.
In Regression testing the use of test stubs is minimized as most of the system is already implemented and the main goal of the regression test is to see if there are any bugs that might have been ‘regressed’ from the previous stages of integrations. Ideally there will not be unimplemented modules by the time a system is tested for regression. However, in case of mutually exclusive modules of a system, a test stub for one of them can be used to test the regression of the other.

==Stubs in software development==
===Agile Development Methodology===
Agile software development is a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change. It is a conceptual framework that promotes foreseen interactions throughout the development cycle.
In such a development system, it recognizes that testing is not a separate phase, but an integral part of software development, along with coding. Agile testing is a software testing practice that follows the principles of agile software development. Agile testing involves all members of a cross-functional agile team, with special expertise contributed by testers, to ensure delivering the business value desired by the customer at frequent intervals, working at a sustainable pace. Specification by example, also known as acceptance test-driven development, is used to capture examples of desired and undesired behavior and guide coding.
In the agile testing toolkit, a stub is a piece of code that behaves in a predefined way, in order to simplify the testing process. Here are the kind of simplifications that a stub can bring:

* If the code under test never returns the same value (usage of a timestamp or of a random value), a stub can be used to fix the root of the undeterminism.

* If the code depends on some other class that has complex behavior that you don’t want to take into account in this test, using a stub for this other class can simplify its behavior and clarify the intent of the test

* If the code depends on some other code that is not yet written or released, it is possible to start building the rest of the code before the dependency is actually finished.

===Rapid Application Development===
Rapid Application Development or RAD is a style of programming that focuses on having tools that allow a program to be created quickly. This is particularly useful for graphically based programs as it is easy to create a frontend which can then be used for testing the backend code. It is a software development methodology that uses minimal planning in favor of rapid prototyping. The "planning" of software developed using RAD is interleaved with writing the software itself. The lack of extensive pre-planning generally allows software to be written much faster, and makes it easier to change requirements. In such a development scenario it becomes increasingly important to be able to write tests and successfully test the software the is being developed so that a complete product is developed in quick time. Test stubs ensure that the testing of code is not stalled in case other modules are still being developed. A programmer can immediately use test stubs and test their code and move on the the next module once its completed.

==Examples of Stubs==
===Java===
In Java, the basic technique is to implement the stub collaborators as concrete classes which only exhibit the small part of the overall behaviour of the collaborator which is needed by the class under test. As an example consider the case where a service implementation is under test. The implementation has a collaborator:

<pre>
public class SimpleService implements Service {
private Collaborator collaborator;
public void setCollaborator(Collaborator collaborator) {
this.collaborator = collaborator;
}

// part of Service interface
public boolean isActive() {
return collaborator.isActive();
}
}
</pre>

We could have a stub collaborator for testing as defined below:

<pre>
public class StubCollaboratorAdapter implements Collaborator {
public boolean isActive() {
return false;
}
}
</pre>

Now, a test case can be written as something like this:

<pre>
public void testActiveWhenCollaboratorIsActive() throws Exception {
Service service = new SimpleService();
service.setCollaborator(new StubCollaboratorAdapter() {
public boolean isActive() {
return true;
}
});
assertTrue(service.isActive());
}
</pre>

===Ruby===
While writing stubs, one might decide to replace a whole object or simply change the results of a single method. When you're replacing a whole object, it's easy—just write the new object and replace it within your test case. Methods might be tougher in some languages, but using dynamic languages such as Ruby, stubbing is easy because you're simply redefining a method.
Imagine you have a user interface that prints a document. You want to test code that handles a print failure. You really don't care if the print method gets called. You just want to verify that if your code does call print, that code will handle a failed print effectively. Think of what a pseudo-code sentence would look like.
On an instance of the document object, stub the print method, returning false.
You can break that sentence down into two parts. The first part identifies what you want to stub. The second part defines what the stub should do.
Below is an example of the Mocha framework that can be used to build stubs in Ruby:
<pre>
class Document
def print
# doesn't matter -- we are stubbing it out
end
end

class View
attr :document

def initialize(document)
@document = document
end

def print()
if document.print
puts "Excellent!"
true
else
puts "Not Great."
false
end
end
end
</pre>
Test code can be written as follows:
<pre>
require 'test/unit'
require 'rubygems'
require 'mocha'
require 'document'

class ViewTest < Test::Unit::TestCase

def test_should_return_false_for_failed_print
document = stub("my document")
document.stubs(:print).returns(false)

ui = View.new(document)
assert_equal false, ui.print
end

end
</pre>
You can see how this works. I build a simple, named stub object with the statement stub("my document"). Then, I define the behavior for print within the stub with the line of code document.stubs(:print).returns(false). If you look carefully, this line of code looks remarkably similar to the pseudo-code from earlier:
On an instance of the document object, stub the print method, returning false.

==IDE support for Stubs==
===Eclipse===

Eclipse provides support to create test stub methods to test the methods developed during development. We can create the junit test case on a java class. We can then select the methods in the class which we would like to test. This will automatically create test stubs to test those methods. In the figure below we are testing methods of ArrayList class

[[File:Eclipse123.png|center]]

===RubyMine===
The most basic way to create test templates in RubyMine is to use the regular procedure of creating files in the project. This means is both available for both plain Ruby projets, and for the Rails applications, and allows creating stub tests for Test::Unit, RSpec and Test-Spec.

For RSpec and Test-Spec, RubyMine provides a number of generators. These generators are context sensitive and become available depending on the selected location, and on the gems activated for your project. For example, ir rspec-rails is activated, the usual generators are hidden, and the list of generators includes only those specific for RSpec.

===Visual Studio===
Visual Studio is a fine IDE that provides good support for automatically generating stubs for methods. Generate Method Stub is an IntelliSense Automatic Code Generation feature that provides an easy way to have Visual Studio create a new method declaration at the time you are writing a method call. Visual Studio infers the declaration from the call. Some programming styles, such as test-driven development, suggest that you should consume before you define. That way, it is easier to figure out the form of the API that you are developing. You can use IntelliSense to program in that style. Using the Generate Method Stub operation, you avoid defining everything before you consume it.

The Generate Method Stub IntelliSense operation can also increase productivity because you do not need to move from the calling code, your present focus, to the defining code, a separate focus, in order to generate a new method. You can instead write a method call, and then invoke the Generate Method Stub operation without dividing your attention.

==Conclusion==
We need tests that “run fast, and help us localize problems.” This can be hard to accomplish when your code accesses a database, hits another server, is time-dependent, etc. By substituting custom objects such as stubs for some of your module's dependencies, you can thoroughly test your code, increase your coverage, and still run in less than a second. You can even simulate rare scenarios like database failures and test your error handling code.

One cannot rely on the traditional approach and wait for the entire system to be developed before subjecting it to various tests. With the increase in the demand for faster and more accurate software, stubs provide a great mechanism for testing. In general, Stubs greatly increase the speed of running unit tests and provide a means of testing code independently.

==References==
*[http://blog.springsource.org/2007/01/15/unit-testing-with-stubs-and-mocks/ Test Stubs and Mocks]
*[http://en.wikipedia.org/wiki/Test_stub Test Stubs on wikipedia]
*[http://www.jetbrains.com/ruby/webhelp/creating-test-templates.pdf Test Stub support in RubyMine]
*[http://googletesting.blogspot.com/2007/04/tott-stubs-speed-up-your-unit-tests.html Advantages of Stubs]
*[http://sqa.fyicenter.com/FAQ/Manual-Testing/What_is_stub_Explain_in_testing_point_of_view_.html Stubs and Testing]
*[http://martinfowler.com/articles/mocksArentStubs.html Mocks aren't Stubs]
*[http://www.captaindebug.com/2011/11/regular-unit-tests-and-stubs-testing.html Testing techniques]
* http://www.ibm.com/developerworks/web/library/wa-mockrails/index.html

CSC/ECE 517 Fall 2012/ch2a 2w13 sm

2012-10-27T22:24:52Z

Svmankar: /* Unit Testing */

==Introduction==
Test stubs are programs which simulate the behaviors of software components (or [http://en.wikipedia.org/wiki/Modular_programming modules]) on which other modules that are being tested are dependent upon.
Stubs are replacements for missing components that the components being tested will call as part of the test. While doing an [http://en.wikipedia.org/wiki/Integration_testing Integration], if we don't have all the modules ready and need to test a particular module which is ready then we use Stubs and Drivers.
Stubs are used in Integration testing for a [http://en.wikipedia.org/wiki/Top-down_and_bottom-up_design Top Down] Integration testing and Bottom Up Integration Testing.

[[File:Stubs.jpg|center]]

In the above figure, we can see that the Modules 2 and 3 are not yet implemented. However, if we need to test the modules 4,5 and 6 which are dependent on modules 2 and 3, we can simple use some dummy code in the form of Stubs 1 and 2 in place of the modules that return the values as expected by the modules beneath them. This piece of Dummy code is Called a Stub in a Top Down Integration. Hence Stubs are called Functions in Top Down Integration tests.

==Stubs in different phases of testing==
===Unit Testing===

In developing a huge software if we are following top down approach of development there may be some functionality which may not have been implemented. This can be overcome by implementing all the required functions. However, then we would be testing a huge chunk of code without actually testing it. This will lead to bugs and lot of time will be wasted on debugging. Consider the following example:

Suppose we want to evaluate an expression factorial(x)/( sin(x) + tan(x) ). Assuming that we don't have library support available for calculating factorial,sin and tan of the given input we would have to write those functions. Using stubs we can write functions which would return appropriate values. Thus, assuming that factorial(x) is implemented then we can write stubs for sin and cos functions returning floating point values. We can than verify if our main function gives expected results for those values. This shows us that our main function, factorial are working correct without actually implementing sin and cos functions
<pre>
code:
int main()
{
float y=factorial(x) / (sin(x) + tan(x) );
return 0;
}
int factorial(x)
{

//implmentation of factorial
}

float sin(int x)
{
return 0.5;
}

float cos(int x)
{
return 0.3;
}
</pre>

===Functional Testing===

The idea of stub remains the same in different forms of testing. In unit testing we are dealing with working inside a module and hence we overwrite the dependent implementations by stub. This allows us to test the calling code without the actual implementation. In functional testing we will replace other modules or collaborators of a class. The client class might be interested in some service from some other class ( collaborator class ). However, again instead of implementing the actual class we will have a stub implementation. In ruby the mocha gem provides support for functional test using stubbing. This helps in avoiding overlapping test cases. We can see the use of stubs in functional testing using mocha in ruby in the programming languages section.

===Integration Testing===
Integration testing is a logical extension of unit testing. In its simplest form, two units that have already been tested are combined into a component and the interface between them is tested. A component, in this sense, refers to an integrated aggregate of more than one unit. In a realistic scenario, many units are combined into components, which are in turn aggregated into even larger parts of the program. The idea is to test combinations of pieces and eventually expand the process to test your modules with those of other groups. Eventually all the modules making up a process are tested together. Beyond that, if the program is composed of more than one process, they should be tested in pairs rather than all at once.
Integration testing identifies problems that occur when units are combined. By using a test plan that requires you to test each unit and ensure the viability of each before combining units, you know that any errors discovered when combining units are likely related to the interface between units. This method reduces the number of possibilities to a far simpler level of analysis.
The top-down approach to integration testing requires the highest-level modules be test and integrated first. This allows high-level logic and data flow to be tested early in the process and it tends to minimize the need for drivers. However, the need for stubs complicates test management and low-level utilities are tested relatively late in the development cycle. Another disadvantage of top-down integration testing is its poor support for early release of limited functionality.

===Regression Testing===
Regression testing is any type of software testing that seeks to uncover new software bugs, or regressions, in existing functional and non-functional areas of a system after changes, such as enhancements, patches or configuration changes, have been made to them.
The intent of regression testing is to ensure that a change, such as a bugfix, did not introduce new faults.[1] One of the main reasons for regression testing is to determine whether a change in one part of the software affects other parts of the software.[2]
Common methods of regression testing include rerunning previously run tests and checking whether program behavior has changed and whether previously fixed faults have re-emerged. Regression testing can be used to test a system efficiently by systematically selecting the appropriate minimum set of tests needed to adequately cover a particular change.
In Regression testing the use of test stubs is minimized as most of the system is already implemented and the main goal of the regression test is to see if there are any bugs that might have been ‘regressed’ from the previous stages of integrations. Ideally there will not be unimplemented modules by the time a system is tested for regression. However, in case of mutually exclusive modules of a system, a test stub for one of them can be used to test the regression of the other.

==Stubs in software development==
===Agile Development Methodology===
Agile software development is a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change. It is a conceptual framework that promotes foreseen interactions throughout the development cycle.
In such a development system, it recognizes that testing is not a separate phase, but an integral part of software development, along with coding. Agile testing is a software testing practice that follows the principles of agile software development. Agile testing involves all members of a cross-functional agile team, with special expertise contributed by testers, to ensure delivering the business value desired by the customer at frequent intervals, working at a sustainable pace. Specification by example, also known as acceptance test-driven development, is used to capture examples of desired and undesired behavior and guide coding.
In the agile testing toolkit, a stub is a piece of code that behaves in a predefined way, in order to simplify the testing process. Here are the kind of simplifications that a stub can bring:

* If the code under test never returns the same value (usage of a timestamp or of a random value), a stub can be used to fix the root of the undeterminism.

* If the code depends on some other class that has complex behavior that you don’t want to take into account in this test, using a stub for this other class can simplify its behavior and clarify the intent of the test

* If the code depends on some other code that is not yet written or released, it is possible to start building the rest of the code before the dependency is actually finished.

===Rapid Application Development===
Rapid Application Development or RAD is a style of programming that focuses on having tools that allow a program to be created quickly. This is particularly useful for graphically based programs as it is easy to create a frontend which can then be used for testing the backend code. It is a software development methodology that uses minimal planning in favor of rapid prototyping. The "planning" of software developed using RAD is interleaved with writing the software itself. The lack of extensive pre-planning generally allows software to be written much faster, and makes it easier to change requirements. In such a development scenario it becomes increasingly important to be able to write tests and successfully test the software the is being developed so that a complete product is developed in quick time. Test stubs ensure that the testing of code is not stalled in case other modules are still being developed. A programmer can immediately use test stubs and test their code and move on the the next module once its completed.

==Examples of Stubs==
===Java===
In Java, the basic technique is to implement the stub collaborators as concrete classes which only exhibit the small part of the overall behaviour of the collaborator which is needed by the class under test. As an example consider the case where a service implementation is under test. The implementation has a collaborator:

<pre>
public class SimpleService implements Service {
private Collaborator collaborator;
public void setCollaborator(Collaborator collaborator) {
this.collaborator = collaborator;
}

// part of Service interface
public boolean isActive() {
return collaborator.isActive();
}
}
</pre>

We could have a stub collaborator for testing as defined below:

<pre>
public class StubCollaboratorAdapter implements Collaborator {
public boolean isActive() {
return false;
}
}
</pre>

Now, a test case can be written as something like this:

<pre>
public void testActiveWhenCollaboratorIsActive() throws Exception {
Service service = new SimpleService();
service.setCollaborator(new StubCollaboratorAdapter() {
public boolean isActive() {
return true;
}
});
assertTrue(service.isActive());
}
</pre>

===Ruby===
While writing stubs, one might decide to replace a whole object or simply change the results of a single method. When you're replacing a whole object, it's easy—just write the new object and replace it within your test case. Methods might be tougher in some languages, but using dynamic languages such as Ruby, stubbing is easy because you're simply redefining a method.
Imagine you have a user interface that prints a document. You want to test code that handles a print failure. You really don't care if the print method gets called. You just want to verify that if your code does call print, that code will handle a failed print effectively. Think of what a pseudo-code sentence would look like.
On an instance of the document object, stub the print method, returning false.
You can break that sentence down into two parts. The first part identifies what you want to stub. The second part defines what the stub should do.
Below is an example of the Mocha framework that can be used to build stubs in Ruby:
<pre>
class Document
def print
# doesn't matter -- we are stubbing it out
end
end

class View
attr :document

def initialize(document)
@document = document
end

def print()
if document.print
puts "Excellent!"
true
else
puts "Not Great."
false
end
end
end
</pre>
Test code can be written as follows:
<pre>
require 'test/unit'
require 'rubygems'
require 'mocha'
require 'document'

class ViewTest < Test::Unit::TestCase

def test_should_return_false_for_failed_print
document = stub("my document")
document.stubs(:print).returns(false)

ui = View.new(document)
assert_equal false, ui.print
end

end
</pre>
You can see how this works. I build a simple, named stub object with the statement stub("my document"). Then, I define the behavior for print within the stub with the line of code document.stubs(:print).returns(false). If you look carefully, this line of code looks remarkably similar to the pseudo-code from earlier:
On an instance of the document object, stub the print method, returning false.

==IDE support for Stubs==
===Eclipse===

Eclipse provides support to create test stub methods to test the methods developed during development. We can create the junit test case on a java class. We can then select the methods in the class which we would like to test. This will automatically create test stubs to test those methods. In the figure below we are testing methods of ArrayList class

[[File:Eclipse123.png|center]]

===RubyMine===
The most basic way to create test templates in RubyMine is to use the regular procedure of creating files in the project. This means is both available for both plain Ruby projets, and for the Rails applications, and allows creating stub tests for Test::Unit, RSpec and Test-Spec.

For RSpec and Test-Spec, RubyMine provides a number of generators. These generators are context sensitive and become available depending on the selected location, and on the gems activated for your project. For example, ir rspec-rails is activated, the usual generators are hidden, and the list of generators includes only those specific for RSpec.

===Visual Studio===
Visual Studio is a fine IDE that provides good support for automatically generating stubs for methods. Generate Method Stub is an IntelliSense Automatic Code Generation feature that provides an easy way to have Visual Studio create a new method declaration at the time you are writing a method call. Visual Studio infers the declaration from the call. Some programming styles, such as test-driven development, suggest that you should consume before you define. That way, it is easier to figure out the form of the API that you are developing. You can use IntelliSense to program in that style. Using the Generate Method Stub operation, you avoid defining everything before you consume it.

The Generate Method Stub IntelliSense operation can also increase productivity because you do not need to move from the calling code, your present focus, to the defining code, a separate focus, in order to generate a new method. You can instead write a method call, and then invoke the Generate Method Stub operation without dividing your attention.

==Conclusion==
We need tests that “run fast, and help us localize problems.” This can be hard to accomplish when your code accesses a database, hits another server, is time-dependent, etc. By substituting custom objects such as stubs for some of your module's dependencies, you can thoroughly test your code, increase your coverage, and still run in less than a second. You can even simulate rare scenarios like database failures and test your error handling code.

One cannot rely on the traditional approach and wait for the entire system to be developed before subjecting it to various tests. With the increase in the demand for faster and more accurate software, stubs provide a great mechanism for testing. In general, Stubs greatly increase the speed of running unit tests and provide a means of testing code independently.

==References==
*[http://blog.springsource.org/2007/01/15/unit-testing-with-stubs-and-mocks/ Test Stubs and Mocks]
*[http://en.wikipedia.org/wiki/Test_stub Test Stubs on wikipedia]
*[http://www.jetbrains.com/ruby/webhelp/creating-test-templates.pdf Test Stub support in RubyMine]
*[http://googletesting.blogspot.com/2007/04/tott-stubs-speed-up-your-unit-tests.html Advantages of Stubs]
*[http://sqa.fyicenter.com/FAQ/Manual-Testing/What_is_stub_Explain_in_testing_point_of_view_.html Stubs and Testing]
*[http://martinfowler.com/articles/mocksArentStubs.html Mocks aren't Stubs]
*[http://www.captaindebug.com/2011/11/regular-unit-tests-and-stubs-testing.html Testing techniques]
* http://www.ibm.com/developerworks/web/library/wa-mockrails/index.html

CSC/ECE 517 Fall 2012/ch2a 2w13 sm

2012-10-27T22:24:19Z

Svmankar: /* Conclusion */

==Introduction==
Test stubs are programs which simulate the behaviors of software components (or [http://en.wikipedia.org/wiki/Modular_programming modules]) on which other modules that are being tested are dependent upon.
Stubs are replacements for missing components that the components being tested will call as part of the test. While doing an [http://en.wikipedia.org/wiki/Integration_testing Integration], if we don't have all the modules ready and need to test a particular module which is ready then we use Stubs and Drivers.
Stubs are used in Integration testing for a [http://en.wikipedia.org/wiki/Top-down_and_bottom-up_design Top Down] Integration testing and Bottom Up Integration Testing.

[[File:Stubs.jpg|center]]

In the above figure, we can see that the Modules 2 and 3 are not yet implemented. However, if we need to test the modules 4,5 and 6 which are dependent on modules 2 and 3, we can simple use some dummy code in the form of Stubs 1 and 2 in place of the modules that return the values as expected by the modules beneath them. This piece of Dummy code is Called a Stub in a Top Down Integration. Hence Stubs are called Functions in Top Down Integration tests.

==Stubs in different phases of testing==
===Unit Testing===

Unit testing with Stubs:

In developing a huge software if we are following top down approach of development there may be some functionality which may not have been implemented. This can be overcome by implementing all the required functions. However, then we would be testing a huge chunk of code without actually testing it. This will lead to bugs and lot of time will be wasted on debugging. Consider the following example:

Suppose we want to evaluate an expression factorial(x)/( sin(x) + tan(x) ). Assuming that we don't have library support available for calculating factorial,sin and tan of the given input we would have to write those functions. Using stubs we can write functions which would return appropriate values. Thus, assuming that factorial(x) is implemented then we can write stubs for sin and cos functions returning floating point values. We can than verify if our main function gives expected results for those values. This shows us that our main function, factorial are working correct without actually implementing sin and cos functions
<pre>
code:
int main()
{
float y=factorial(x) / (sin(x) + tan(x) );
return 0;
}
int factorial(x)
{

//implmentation of factorial
}

float sin(int x)
{
return 0.5;
}

float cos(int x)
{
return 0.3;
}
</pre>
===Functional Testing===

The idea of stub remains the same in different forms of testing. In unit testing we are dealing with working inside a module and hence we overwrite the dependent implementations by stub. This allows us to test the calling code without the actual implementation. In functional testing we will replace other modules or collaborators of a class. The client class might be interested in some service from some other class ( collaborator class ). However, again instead of implementing the actual class we will have a stub implementation. In ruby the mocha gem provides support for functional test using stubbing. This helps in avoiding overlapping test cases. We can see the use of stubs in functional testing using mocha in ruby in the programming languages section.

===Integration Testing===
Integration testing is a logical extension of unit testing. In its simplest form, two units that have already been tested are combined into a component and the interface between them is tested. A component, in this sense, refers to an integrated aggregate of more than one unit. In a realistic scenario, many units are combined into components, which are in turn aggregated into even larger parts of the program. The idea is to test combinations of pieces and eventually expand the process to test your modules with those of other groups. Eventually all the modules making up a process are tested together. Beyond that, if the program is composed of more than one process, they should be tested in pairs rather than all at once.
Integration testing identifies problems that occur when units are combined. By using a test plan that requires you to test each unit and ensure the viability of each before combining units, you know that any errors discovered when combining units are likely related to the interface between units. This method reduces the number of possibilities to a far simpler level of analysis.
The top-down approach to integration testing requires the highest-level modules be test and integrated first. This allows high-level logic and data flow to be tested early in the process and it tends to minimize the need for drivers. However, the need for stubs complicates test management and low-level utilities are tested relatively late in the development cycle. Another disadvantage of top-down integration testing is its poor support for early release of limited functionality.

===Regression Testing===
Regression testing is any type of software testing that seeks to uncover new software bugs, or regressions, in existing functional and non-functional areas of a system after changes, such as enhancements, patches or configuration changes, have been made to them.
The intent of regression testing is to ensure that a change, such as a bugfix, did not introduce new faults.[1] One of the main reasons for regression testing is to determine whether a change in one part of the software affects other parts of the software.[2]
Common methods of regression testing include rerunning previously run tests and checking whether program behavior has changed and whether previously fixed faults have re-emerged. Regression testing can be used to test a system efficiently by systematically selecting the appropriate minimum set of tests needed to adequately cover a particular change.
In Regression testing the use of test stubs is minimized as most of the system is already implemented and the main goal of the regression test is to see if there are any bugs that might have been ‘regressed’ from the previous stages of integrations. Ideally there will not be unimplemented modules by the time a system is tested for regression. However, in case of mutually exclusive modules of a system, a test stub for one of them can be used to test the regression of the other.

==Stubs in software development==
===Agile Development Methodology===
Agile software development is a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change. It is a conceptual framework that promotes foreseen interactions throughout the development cycle.
In such a development system, it recognizes that testing is not a separate phase, but an integral part of software development, along with coding. Agile testing is a software testing practice that follows the principles of agile software development. Agile testing involves all members of a cross-functional agile team, with special expertise contributed by testers, to ensure delivering the business value desired by the customer at frequent intervals, working at a sustainable pace. Specification by example, also known as acceptance test-driven development, is used to capture examples of desired and undesired behavior and guide coding.
In the agile testing toolkit, a stub is a piece of code that behaves in a predefined way, in order to simplify the testing process. Here are the kind of simplifications that a stub can bring:

* If the code under test never returns the same value (usage of a timestamp or of a random value), a stub can be used to fix the root of the undeterminism.

* If the code depends on some other class that has complex behavior that you don’t want to take into account in this test, using a stub for this other class can simplify its behavior and clarify the intent of the test

* If the code depends on some other code that is not yet written or released, it is possible to start building the rest of the code before the dependency is actually finished.

===Rapid Application Development===
Rapid Application Development or RAD is a style of programming that focuses on having tools that allow a program to be created quickly. This is particularly useful for graphically based programs as it is easy to create a frontend which can then be used for testing the backend code. It is a software development methodology that uses minimal planning in favor of rapid prototyping. The "planning" of software developed using RAD is interleaved with writing the software itself. The lack of extensive pre-planning generally allows software to be written much faster, and makes it easier to change requirements. In such a development scenario it becomes increasingly important to be able to write tests and successfully test the software the is being developed so that a complete product is developed in quick time. Test stubs ensure that the testing of code is not stalled in case other modules are still being developed. A programmer can immediately use test stubs and test their code and move on the the next module once its completed.

==Examples of Stubs==
===Java===
In Java, the basic technique is to implement the stub collaborators as concrete classes which only exhibit the small part of the overall behaviour of the collaborator which is needed by the class under test. As an example consider the case where a service implementation is under test. The implementation has a collaborator:

<pre>
public class SimpleService implements Service {
private Collaborator collaborator;
public void setCollaborator(Collaborator collaborator) {
this.collaborator = collaborator;
}

// part of Service interface
public boolean isActive() {
return collaborator.isActive();
}
}
</pre>

We could have a stub collaborator for testing as defined below:

<pre>
public class StubCollaboratorAdapter implements Collaborator {
public boolean isActive() {
return false;
}
}
</pre>

Now, a test case can be written as something like this:

<pre>
public void testActiveWhenCollaboratorIsActive() throws Exception {
Service service = new SimpleService();
service.setCollaborator(new StubCollaboratorAdapter() {
public boolean isActive() {
return true;
}
});
assertTrue(service.isActive());
}
</pre>

===Ruby===
While writing stubs, one might decide to replace a whole object or simply change the results of a single method. When you're replacing a whole object, it's easy—just write the new object and replace it within your test case. Methods might be tougher in some languages, but using dynamic languages such as Ruby, stubbing is easy because you're simply redefining a method.
Imagine you have a user interface that prints a document. You want to test code that handles a print failure. You really don't care if the print method gets called. You just want to verify that if your code does call print, that code will handle a failed print effectively. Think of what a pseudo-code sentence would look like.
On an instance of the document object, stub the print method, returning false.
You can break that sentence down into two parts. The first part identifies what you want to stub. The second part defines what the stub should do.
Below is an example of the Mocha framework that can be used to build stubs in Ruby:
<pre>
class Document
def print
# doesn't matter -- we are stubbing it out
end
end

class View
attr :document

def initialize(document)
@document = document
end

def print()
if document.print
puts "Excellent!"
true
else
puts "Not Great."
false
end
end
end
</pre>
Test code can be written as follows:
<pre>
require 'test/unit'
require 'rubygems'
require 'mocha'
require 'document'

class ViewTest < Test::Unit::TestCase

def test_should_return_false_for_failed_print
document = stub("my document")
document.stubs(:print).returns(false)

ui = View.new(document)
assert_equal false, ui.print
end

end
</pre>
You can see how this works. I build a simple, named stub object with the statement stub("my document"). Then, I define the behavior for print within the stub with the line of code document.stubs(:print).returns(false). If you look carefully, this line of code looks remarkably similar to the pseudo-code from earlier:
On an instance of the document object, stub the print method, returning false.

==IDE support for Stubs==
===Eclipse===

Eclipse provides support to create test stub methods to test the methods developed during development. We can create the junit test case on a java class. We can then select the methods in the class which we would like to test. This will automatically create test stubs to test those methods. In the figure below we are testing methods of ArrayList class

[[File:Eclipse123.png|center]]

===RubyMine===
The most basic way to create test templates in RubyMine is to use the regular procedure of creating files in the project. This means is both available for both plain Ruby projets, and for the Rails applications, and allows creating stub tests for Test::Unit, RSpec and Test-Spec.

For RSpec and Test-Spec, RubyMine provides a number of generators. These generators are context sensitive and become available depending on the selected location, and on the gems activated for your project. For example, ir rspec-rails is activated, the usual generators are hidden, and the list of generators includes only those specific for RSpec.

===Visual Studio===
Visual Studio is a fine IDE that provides good support for automatically generating stubs for methods. Generate Method Stub is an IntelliSense Automatic Code Generation feature that provides an easy way to have Visual Studio create a new method declaration at the time you are writing a method call. Visual Studio infers the declaration from the call. Some programming styles, such as test-driven development, suggest that you should consume before you define. That way, it is easier to figure out the form of the API that you are developing. You can use IntelliSense to program in that style. Using the Generate Method Stub operation, you avoid defining everything before you consume it.

The Generate Method Stub IntelliSense operation can also increase productivity because you do not need to move from the calling code, your present focus, to the defining code, a separate focus, in order to generate a new method. You can instead write a method call, and then invoke the Generate Method Stub operation without dividing your attention.

==Conclusion==
We need tests that “run fast, and help us localize problems.” This can be hard to accomplish when your code accesses a database, hits another server, is time-dependent, etc. By substituting custom objects such as stubs for some of your module's dependencies, you can thoroughly test your code, increase your coverage, and still run in less than a second. You can even simulate rare scenarios like database failures and test your error handling code.

One cannot rely on the traditional approach and wait for the entire system to be developed before subjecting it to various tests. With the increase in the demand for faster and more accurate software, stubs provide a great mechanism for testing. In general, Stubs greatly increase the speed of running unit tests and provide a means of testing code independently.

==References==
*[http://blog.springsource.org/2007/01/15/unit-testing-with-stubs-and-mocks/ Test Stubs and Mocks]
*[http://en.wikipedia.org/wiki/Test_stub Test Stubs on wikipedia]
*[http://www.jetbrains.com/ruby/webhelp/creating-test-templates.pdf Test Stub support in RubyMine]
*[http://googletesting.blogspot.com/2007/04/tott-stubs-speed-up-your-unit-tests.html Advantages of Stubs]
*[http://sqa.fyicenter.com/FAQ/Manual-Testing/What_is_stub_Explain_in_testing_point_of_view_.html Stubs and Testing]
*[http://martinfowler.com/articles/mocksArentStubs.html Mocks aren't Stubs]
*[http://www.captaindebug.com/2011/11/regular-unit-tests-and-stubs-testing.html Testing techniques]
* http://www.ibm.com/developerworks/web/library/wa-mockrails/index.html

CSC/ECE 517 Fall 2012/ch2a 2w13 sm

2012-10-27T22:18:16Z

Svmankar: /* Ruby */

==Introduction==
Test stubs are programs which simulate the behaviors of software components (or [http://en.wikipedia.org/wiki/Modular_programming modules]) on which other modules that are being tested are dependent upon.
Stubs are replacements for missing components that the components being tested will call as part of the test. While doing an [http://en.wikipedia.org/wiki/Integration_testing Integration], if we don't have all the modules ready and need to test a particular module which is ready then we use Stubs and Drivers.
Stubs are used in Integration testing for a [http://en.wikipedia.org/wiki/Top-down_and_bottom-up_design Top Down] Integration testing and Bottom Up Integration Testing.

[[File:Stubs.jpg|center]]

In the above figure, we can see that the Modules 2 and 3 are not yet implemented. However, if we need to test the modules 4,5 and 6 which are dependent on modules 2 and 3, we can simple use some dummy code in the form of Stubs 1 and 2 in place of the modules that return the values as expected by the modules beneath them. This piece of Dummy code is Called a Stub in a Top Down Integration. Hence Stubs are called Functions in Top Down Integration tests.

==Stubs in different phases of testing==
===Unit Testing===

Unit testing with Stubs:

In developing a huge software if we are following top down approach of development there may be some functionality which may not have been implemented. This can be overcome by implementing all the required functions. However, then we would be testing a huge chunk of code without actually testing it. This will lead to bugs and lot of time will be wasted on debugging. Consider the following example:

Suppose we want to evaluate an expression factorial(x)/( sin(x) + tan(x) ). Assuming that we don't have library support available for calculating factorial,sin and tan of the given input we would have to write those functions. Using stubs we can write functions which would return appropriate values. Thus, assuming that factorial(x) is implemented then we can write stubs for sin and cos functions returning floating point values. We can than verify if our main function gives expected results for those values. This shows us that our main function, factorial are working correct without actually implementing sin and cos functions
<pre>
code:
int main()
{
float y=factorial(x) / (sin(x) + tan(x) );
return 0;
}
int factorial(x)
{

//implmentation of factorial
}

float sin(int x)
{
return 0.5;
}

float cos(int x)
{
return 0.3;
}
</pre>
===Functional Testing===

The idea of stub remains the same in different forms of testing. In unit testing we are dealing with working inside a module and hence we overwrite the dependent implementations by stub. This allows us to test the calling code without the actual implementation. In functional testing we will replace other modules or collaborators of a class. The client class might be interested in some service from some other class ( collaborator class ). However, again instead of implementing the actual class we will have a stub implementation. In ruby the mocha gem provides support for functional test using stubbing. This helps in avoiding overlapping test cases. We can see the use of stubs in functional testing using mocha in ruby in the programming languages section.

===Integration Testing===
Integration testing is a logical extension of unit testing. In its simplest form, two units that have already been tested are combined into a component and the interface between them is tested. A component, in this sense, refers to an integrated aggregate of more than one unit. In a realistic scenario, many units are combined into components, which are in turn aggregated into even larger parts of the program. The idea is to test combinations of pieces and eventually expand the process to test your modules with those of other groups. Eventually all the modules making up a process are tested together. Beyond that, if the program is composed of more than one process, they should be tested in pairs rather than all at once.
Integration testing identifies problems that occur when units are combined. By using a test plan that requires you to test each unit and ensure the viability of each before combining units, you know that any errors discovered when combining units are likely related to the interface between units. This method reduces the number of possibilities to a far simpler level of analysis.
The top-down approach to integration testing requires the highest-level modules be test and integrated first. This allows high-level logic and data flow to be tested early in the process and it tends to minimize the need for drivers. However, the need for stubs complicates test management and low-level utilities are tested relatively late in the development cycle. Another disadvantage of top-down integration testing is its poor support for early release of limited functionality.

===Regression Testing===
Regression testing is any type of software testing that seeks to uncover new software bugs, or regressions, in existing functional and non-functional areas of a system after changes, such as enhancements, patches or configuration changes, have been made to them.
The intent of regression testing is to ensure that a change, such as a bugfix, did not introduce new faults.[1] One of the main reasons for regression testing is to determine whether a change in one part of the software affects other parts of the software.[2]
Common methods of regression testing include rerunning previously run tests and checking whether program behavior has changed and whether previously fixed faults have re-emerged. Regression testing can be used to test a system efficiently by systematically selecting the appropriate minimum set of tests needed to adequately cover a particular change.
In Regression testing the use of test stubs is minimized as most of the system is already implemented and the main goal of the regression test is to see if there are any bugs that might have been ‘regressed’ from the previous stages of integrations. Ideally there will not be unimplemented modules by the time a system is tested for regression. However, in case of mutually exclusive modules of a system, a test stub for one of them can be used to test the regression of the other.

==Stubs in software development==
===Agile Development Methodology===
Agile software development is a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change. It is a conceptual framework that promotes foreseen interactions throughout the development cycle.
In such a development system, it recognizes that testing is not a separate phase, but an integral part of software development, along with coding. Agile testing is a software testing practice that follows the principles of agile software development. Agile testing involves all members of a cross-functional agile team, with special expertise contributed by testers, to ensure delivering the business value desired by the customer at frequent intervals, working at a sustainable pace. Specification by example, also known as acceptance test-driven development, is used to capture examples of desired and undesired behavior and guide coding.
In the agile testing toolkit, a stub is a piece of code that behaves in a predefined way, in order to simplify the testing process. Here are the kind of simplifications that a stub can bring:

* If the code under test never returns the same value (usage of a timestamp or of a random value), a stub can be used to fix the root of the undeterminism.

* If the code depends on some other class that has complex behavior that you don’t want to take into account in this test, using a stub for this other class can simplify its behavior and clarify the intent of the test

* If the code depends on some other code that is not yet written or released, it is possible to start building the rest of the code before the dependency is actually finished.

===Rapid Application Development===
Rapid Application Development or RAD is a style of programming that focuses on having tools that allow a program to be created quickly. This is particularly useful for graphically based programs as it is easy to create a frontend which can then be used for testing the backend code. It is a software development methodology that uses minimal planning in favor of rapid prototyping. The "planning" of software developed using RAD is interleaved with writing the software itself. The lack of extensive pre-planning generally allows software to be written much faster, and makes it easier to change requirements. In such a development scenario it becomes increasingly important to be able to write tests and successfully test the software the is being developed so that a complete product is developed in quick time. Test stubs ensure that the testing of code is not stalled in case other modules are still being developed. A programmer can immediately use test stubs and test their code and move on the the next module once its completed.

==Examples of Stubs==
===Java===
In Java, the basic technique is to implement the stub collaborators as concrete classes which only exhibit the small part of the overall behaviour of the collaborator which is needed by the class under test. As an example consider the case where a service implementation is under test. The implementation has a collaborator:

<pre>
public class SimpleService implements Service {
private Collaborator collaborator;
public void setCollaborator(Collaborator collaborator) {
this.collaborator = collaborator;
}

// part of Service interface
public boolean isActive() {
return collaborator.isActive();
}
}
</pre>

We could have a stub collaborator for testing as defined below:

<pre>
public class StubCollaboratorAdapter implements Collaborator {
public boolean isActive() {
return false;
}
}
</pre>

Now, a test case can be written as something like this:

<pre>
public void testActiveWhenCollaboratorIsActive() throws Exception {
Service service = new SimpleService();
service.setCollaborator(new StubCollaboratorAdapter() {
public boolean isActive() {
return true;
}
});
assertTrue(service.isActive());
}
</pre>

===Ruby===
While writing stubs, one might decide to replace a whole object or simply change the results of a single method. When you're replacing a whole object, it's easy—just write the new object and replace it within your test case. Methods might be tougher in some languages, but using dynamic languages such as Ruby, stubbing is easy because you're simply redefining a method.
Imagine you have a user interface that prints a document. You want to test code that handles a print failure. You really don't care if the print method gets called. You just want to verify that if your code does call print, that code will handle a failed print effectively. Think of what a pseudo-code sentence would look like.
On an instance of the document object, stub the print method, returning false.
You can break that sentence down into two parts. The first part identifies what you want to stub. The second part defines what the stub should do.
Below is an example of the Mocha framework that can be used to build stubs in Ruby:
<pre>
class Document
def print
# doesn't matter -- we are stubbing it out
end
end

class View
attr :document

def initialize(document)
@document = document
end

def print()
if document.print
puts "Excellent!"
true
else
puts "Not Great."
false
end
end
end
</pre>
Test code can be written as follows:
<pre>
require 'test/unit'
require 'rubygems'
require 'mocha'
require 'document'

class ViewTest < Test::Unit::TestCase

def test_should_return_false_for_failed_print
document = stub("my document")
document.stubs(:print).returns(false)

ui = View.new(document)
assert_equal false, ui.print
end

end
</pre>
You can see how this works. I build a simple, named stub object with the statement stub("my document"). Then, I define the behavior for print within the stub with the line of code document.stubs(:print).returns(false). If you look carefully, this line of code looks remarkably similar to the pseudo-code from earlier:
On an instance of the document object, stub the print method, returning false.

==IDE support for Stubs==
===Eclipse===

Eclipse provides support to create test stub methods to test the methods developed during development. We can create the junit test case on a java class. We can then select the methods in the class which we would like to test. This will automatically create test stubs to test those methods. In the figure below we are testing methods of ArrayList class

[[File:Eclipse123.png|center]]

===RubyMine===
The most basic way to create test templates in RubyMine is to use the regular procedure of creating files in the project. This means is both available for both plain Ruby projets, and for the Rails applications, and allows creating stub tests for Test::Unit, RSpec and Test-Spec.

For RSpec and Test-Spec, RubyMine provides a number of generators. These generators are context sensitive and become available depending on the selected location, and on the gems activated for your project. For example, ir rspec-rails is activated, the usual generators are hidden, and the list of generators includes only those specific for RSpec.

===Visual Studio===
Visual Studio is a fine IDE that provides good support for automatically generating stubs for methods. Generate Method Stub is an IntelliSense Automatic Code Generation feature that provides an easy way to have Visual Studio create a new method declaration at the time you are writing a method call. Visual Studio infers the declaration from the call. Some programming styles, such as test-driven development, suggest that you should consume before you define. That way, it is easier to figure out the form of the API that you are developing. You can use IntelliSense to program in that style. Using the Generate Method Stub operation, you avoid defining everything before you consume it.

The Generate Method Stub IntelliSense operation can also increase productivity because you do not need to move from the calling code, your present focus, to the defining code, a separate focus, in order to generate a new method. You can instead write a method call, and then invoke the Generate Method Stub operation without dividing your attention.

==Conclusion==
We need tests that “run fast, and help us localize problems.” This can be hard to accomplish when your code accesses a database, hits another server, is time-dependent, etc. By substituting custom objects such as stubs for some of your module's dependencies, you can thoroughly test your code, increase your coverage, and still run in less than a second. You can even simulate rare scenarios like database failures and test your error handling code. In general, Stubs greatly increase the speed of running unit tests and provide a means of testing code independently.

==References==
*[http://blog.springsource.org/2007/01/15/unit-testing-with-stubs-and-mocks/ Test Stubs and Mocks]
*[http://en.wikipedia.org/wiki/Test_stub Test Stubs on wikipedia]
*[http://www.jetbrains.com/ruby/webhelp/creating-test-templates.pdf Test Stub support in RubyMine]
*[http://googletesting.blogspot.com/2007/04/tott-stubs-speed-up-your-unit-tests.html Advantages of Stubs]
*[http://sqa.fyicenter.com/FAQ/Manual-Testing/What_is_stub_Explain_in_testing_point_of_view_.html Stubs and Testing]
*[http://martinfowler.com/articles/mocksArentStubs.html Mocks aren't Stubs]
*[http://www.captaindebug.com/2011/11/regular-unit-tests-and-stubs-testing.html Testing techniques]
* http://www.ibm.com/developerworks/web/library/wa-mockrails/index.html

CSC/ECE 517 Fall 2012/ch2a 2w13 sm

2012-10-27T22:17:47Z

Svmankar: /* Introduction */

==Introduction==
Test stubs are programs which simulate the behaviors of software components (or [http://en.wikipedia.org/wiki/Modular_programming modules]) on which other modules that are being tested are dependent upon.
Stubs are replacements for missing components that the components being tested will call as part of the test. While doing an [http://en.wikipedia.org/wiki/Integration_testing Integration], if we don't have all the modules ready and need to test a particular module which is ready then we use Stubs and Drivers.
Stubs are used in Integration testing for a [http://en.wikipedia.org/wiki/Top-down_and_bottom-up_design Top Down] Integration testing and Bottom Up Integration Testing.

[[File:Stubs.jpg|center]]

In the above figure, we can see that the Modules 2 and 3 are not yet implemented. However, if we need to test the modules 4,5 and 6 which are dependent on modules 2 and 3, we can simple use some dummy code in the form of Stubs 1 and 2 in place of the modules that return the values as expected by the modules beneath them. This piece of Dummy code is Called a Stub in a Top Down Integration. Hence Stubs are called Functions in Top Down Integration tests.

==Stubs in different phases of testing==
===Unit Testing===

Unit testing with Stubs:

In developing a huge software if we are following top down approach of development there may be some functionality which may not have been implemented. This can be overcome by implementing all the required functions. However, then we would be testing a huge chunk of code without actually testing it. This will lead to bugs and lot of time will be wasted on debugging. Consider the following example:

Suppose we want to evaluate an expression factorial(x)/( sin(x) + tan(x) ). Assuming that we don't have library support available for calculating factorial,sin and tan of the given input we would have to write those functions. Using stubs we can write functions which would return appropriate values. Thus, assuming that factorial(x) is implemented then we can write stubs for sin and cos functions returning floating point values. We can than verify if our main function gives expected results for those values. This shows us that our main function, factorial are working correct without actually implementing sin and cos functions
<pre>
code:
int main()
{
float y=factorial(x) / (sin(x) + tan(x) );
return 0;
}
int factorial(x)
{

//implmentation of factorial
}

float sin(int x)
{
return 0.5;
}

float cos(int x)
{
return 0.3;
}
</pre>
===Functional Testing===

The idea of stub remains the same in different forms of testing. In unit testing we are dealing with working inside a module and hence we overwrite the dependent implementations by stub. This allows us to test the calling code without the actual implementation. In functional testing we will replace other modules or collaborators of a class. The client class might be interested in some service from some other class ( collaborator class ). However, again instead of implementing the actual class we will have a stub implementation. In ruby the mocha gem provides support for functional test using stubbing. This helps in avoiding overlapping test cases. We can see the use of stubs in functional testing using mocha in ruby in the programming languages section.

===Integration Testing===
Integration testing is a logical extension of unit testing. In its simplest form, two units that have already been tested are combined into a component and the interface between them is tested. A component, in this sense, refers to an integrated aggregate of more than one unit. In a realistic scenario, many units are combined into components, which are in turn aggregated into even larger parts of the program. The idea is to test combinations of pieces and eventually expand the process to test your modules with those of other groups. Eventually all the modules making up a process are tested together. Beyond that, if the program is composed of more than one process, they should be tested in pairs rather than all at once.
Integration testing identifies problems that occur when units are combined. By using a test plan that requires you to test each unit and ensure the viability of each before combining units, you know that any errors discovered when combining units are likely related to the interface between units. This method reduces the number of possibilities to a far simpler level of analysis.
The top-down approach to integration testing requires the highest-level modules be test and integrated first. This allows high-level logic and data flow to be tested early in the process and it tends to minimize the need for drivers. However, the need for stubs complicates test management and low-level utilities are tested relatively late in the development cycle. Another disadvantage of top-down integration testing is its poor support for early release of limited functionality.

===Regression Testing===
Regression testing is any type of software testing that seeks to uncover new software bugs, or regressions, in existing functional and non-functional areas of a system after changes, such as enhancements, patches or configuration changes, have been made to them.
The intent of regression testing is to ensure that a change, such as a bugfix, did not introduce new faults.[1] One of the main reasons for regression testing is to determine whether a change in one part of the software affects other parts of the software.[2]
Common methods of regression testing include rerunning previously run tests and checking whether program behavior has changed and whether previously fixed faults have re-emerged. Regression testing can be used to test a system efficiently by systematically selecting the appropriate minimum set of tests needed to adequately cover a particular change.
In Regression testing the use of test stubs is minimized as most of the system is already implemented and the main goal of the regression test is to see if there are any bugs that might have been ‘regressed’ from the previous stages of integrations. Ideally there will not be unimplemented modules by the time a system is tested for regression. However, in case of mutually exclusive modules of a system, a test stub for one of them can be used to test the regression of the other.

==Stubs in software development==
===Agile Development Methodology===
Agile software development is a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change. It is a conceptual framework that promotes foreseen interactions throughout the development cycle.
In such a development system, it recognizes that testing is not a separate phase, but an integral part of software development, along with coding. Agile testing is a software testing practice that follows the principles of agile software development. Agile testing involves all members of a cross-functional agile team, with special expertise contributed by testers, to ensure delivering the business value desired by the customer at frequent intervals, working at a sustainable pace. Specification by example, also known as acceptance test-driven development, is used to capture examples of desired and undesired behavior and guide coding.
In the agile testing toolkit, a stub is a piece of code that behaves in a predefined way, in order to simplify the testing process. Here are the kind of simplifications that a stub can bring:

* If the code under test never returns the same value (usage of a timestamp or of a random value), a stub can be used to fix the root of the undeterminism.

* If the code depends on some other class that has complex behavior that you don’t want to take into account in this test, using a stub for this other class can simplify its behavior and clarify the intent of the test

* If the code depends on some other code that is not yet written or released, it is possible to start building the rest of the code before the dependency is actually finished.

===Rapid Application Development===
Rapid Application Development or RAD is a style of programming that focuses on having tools that allow a program to be created quickly. This is particularly useful for graphically based programs as it is easy to create a frontend which can then be used for testing the backend code. It is a software development methodology that uses minimal planning in favor of rapid prototyping. The "planning" of software developed using RAD is interleaved with writing the software itself. The lack of extensive pre-planning generally allows software to be written much faster, and makes it easier to change requirements. In such a development scenario it becomes increasingly important to be able to write tests and successfully test the software the is being developed so that a complete product is developed in quick time. Test stubs ensure that the testing of code is not stalled in case other modules are still being developed. A programmer can immediately use test stubs and test their code and move on the the next module once its completed.

==Examples of Stubs==
===Java===
In Java, the basic technique is to implement the stub collaborators as concrete classes which only exhibit the small part of the overall behaviour of the collaborator which is needed by the class under test. As an example consider the case where a service implementation is under test. The implementation has a collaborator:

<pre>
public class SimpleService implements Service {
private Collaborator collaborator;
public void setCollaborator(Collaborator collaborator) {
this.collaborator = collaborator;
}

// part of Service interface
public boolean isActive() {
return collaborator.isActive();
}
}
</pre>

We could have a stub collaborator for testing as defined below:

<pre>
public class StubCollaboratorAdapter implements Collaborator {
public boolean isActive() {
return false;
}
}
</pre>

Now, a test case can be written as something like this:

<pre>
public void testActiveWhenCollaboratorIsActive() throws Exception {
Service service = new SimpleService();
service.setCollaborator(new StubCollaboratorAdapter() {
public boolean isActive() {
return true;
}
});
assertTrue(service.isActive());
}
</pre>

===Ruby===
While writing stubs, one might decide to replace a whole object or simply change the results of a single method. When you're replacing a whole object, it's easy—just write the new object and replace it within your test case. Methods might be tougher in some languages, but using dynamic languages such as Ruby, stubbing is easy because you're simply redefining a method.
Imagine you have a user interface that prints a document. You want to test code that handles a print failure. You really don't care if the print method gets called. You just want to verify that if your code does call print, that code will handle a failed print effectively. Think of what a pseudo-code sentence would look like.
On an instance of the document object, stub the print method, returning false.
You can break that sentence down into two parts. The first part identifies what you want to stub. The second part defines what the stub should do.
Below is an example of the Mocha framework that can be used to build stubs in Ruby:
<pre>
class Document
def print
# doesn't matter -- we are stubbing it out
end
end

class View
attr :document

def initialize(document)
@document = document
end

def print()
if document.print
puts "Excellent!"
true
else
puts "Bummer."
false
end
end
end
</pre>
Test code can be written as follows:
<pre>
require 'test/unit'
require 'rubygems'
require 'mocha'
require 'document'

class ViewTest < Test::Unit::TestCase

def test_should_return_false_for_failed_print
document = stub("my document")
document.stubs(:print).returns(false)

ui = View.new(document)
assert_equal false, ui.print
end

end
</pre>
You can see how this works. I build a simple, named stub object with the statement stub("my document"). Then, I define the behavior for print within the stub with the line of code document.stubs(:print).returns(false). If you look carefully, this line of code looks remarkably similar to the pseudo-code from earlier:
On an instance of the document object, stub the print method, returning false.

==IDE support for Stubs==
===Eclipse===

Eclipse provides support to create test stub methods to test the methods developed during development. We can create the junit test case on a java class. We can then select the methods in the class which we would like to test. This will automatically create test stubs to test those methods. In the figure below we are testing methods of ArrayList class

[[File:Eclipse123.png|center]]

===RubyMine===
The most basic way to create test templates in RubyMine is to use the regular procedure of creating files in the project. This means is both available for both plain Ruby projets, and for the Rails applications, and allows creating stub tests for Test::Unit, RSpec and Test-Spec.

For RSpec and Test-Spec, RubyMine provides a number of generators. These generators are context sensitive and become available depending on the selected location, and on the gems activated for your project. For example, ir rspec-rails is activated, the usual generators are hidden, and the list of generators includes only those specific for RSpec.

===Visual Studio===
Visual Studio is a fine IDE that provides good support for automatically generating stubs for methods. Generate Method Stub is an IntelliSense Automatic Code Generation feature that provides an easy way to have Visual Studio create a new method declaration at the time you are writing a method call. Visual Studio infers the declaration from the call. Some programming styles, such as test-driven development, suggest that you should consume before you define. That way, it is easier to figure out the form of the API that you are developing. You can use IntelliSense to program in that style. Using the Generate Method Stub operation, you avoid defining everything before you consume it.

The Generate Method Stub IntelliSense operation can also increase productivity because you do not need to move from the calling code, your present focus, to the defining code, a separate focus, in order to generate a new method. You can instead write a method call, and then invoke the Generate Method Stub operation without dividing your attention.

==Conclusion==
We need tests that “run fast, and help us localize problems.” This can be hard to accomplish when your code accesses a database, hits another server, is time-dependent, etc. By substituting custom objects such as stubs for some of your module's dependencies, you can thoroughly test your code, increase your coverage, and still run in less than a second. You can even simulate rare scenarios like database failures and test your error handling code. In general, Stubs greatly increase the speed of running unit tests and provide a means of testing code independently.

==References==
*[http://blog.springsource.org/2007/01/15/unit-testing-with-stubs-and-mocks/ Test Stubs and Mocks]
*[http://en.wikipedia.org/wiki/Test_stub Test Stubs on wikipedia]
*[http://www.jetbrains.com/ruby/webhelp/creating-test-templates.pdf Test Stub support in RubyMine]
*[http://googletesting.blogspot.com/2007/04/tott-stubs-speed-up-your-unit-tests.html Advantages of Stubs]
*[http://sqa.fyicenter.com/FAQ/Manual-Testing/What_is_stub_Explain_in_testing_point_of_view_.html Stubs and Testing]
*[http://martinfowler.com/articles/mocksArentStubs.html Mocks aren't Stubs]
*[http://www.captaindebug.com/2011/11/regular-unit-tests-and-stubs-testing.html Testing techniques]
* http://www.ibm.com/developerworks/web/library/wa-mockrails/index.html

CSC/ECE 517 Fall 2012/ch2a 2w13 sm

2012-10-27T22:17:32Z

Svmankar: /* Eclipse */

==Introduction==
Test stubs are programs which simulate the behaviors of software components (or [http://en.wikipedia.org/wiki/Modular_programming modules]) on which other modules that are being tested are dependent upon.
Stubs are replacements for missing components that the components being tested will call as part of the test. While doing an [http://en.wikipedia.org/wiki/Integration_testing Integration], if we don't have all the modules ready and need to test a particular module which is ready then we use Stubs and Drivers.
Stubs are used in Integration testing for a [http://en.wikipedia.org/wiki/Top-down_and_bottom-up_design Top Down] Integration testing and Bottom Up Integration Testing.

[[File:Stubs.jpg]]

In the above figure, we can see that the Modules 2 and 3 are not yet implemented. However, if we need to test the modules 4,5 and 6 which are dependent on modules 2 and 3, we can simple use some dummy code in the form of Stubs 1 and 2 in place of the modules that return the values as expected by the modules beneath them. This piece of Dummy code is Called a Stub in a Top Down Integration. Hence Stubs are called Functions in Top Down Integration tests.

==Stubs in different phases of testing==
===Unit Testing===

Unit testing with Stubs:

In developing a huge software if we are following top down approach of development there may be some functionality which may not have been implemented. This can be overcome by implementing all the required functions. However, then we would be testing a huge chunk of code without actually testing it. This will lead to bugs and lot of time will be wasted on debugging. Consider the following example:

Suppose we want to evaluate an expression factorial(x)/( sin(x) + tan(x) ). Assuming that we don't have library support available for calculating factorial,sin and tan of the given input we would have to write those functions. Using stubs we can write functions which would return appropriate values. Thus, assuming that factorial(x) is implemented then we can write stubs for sin and cos functions returning floating point values. We can than verify if our main function gives expected results for those values. This shows us that our main function, factorial are working correct without actually implementing sin and cos functions
<pre>
code:
int main()
{
float y=factorial(x) / (sin(x) + tan(x) );
return 0;
}
int factorial(x)
{

//implmentation of factorial
}

float sin(int x)
{
return 0.5;
}

float cos(int x)
{
return 0.3;
}
</pre>
===Functional Testing===

The idea of stub remains the same in different forms of testing. In unit testing we are dealing with working inside a module and hence we overwrite the dependent implementations by stub. This allows us to test the calling code without the actual implementation. In functional testing we will replace other modules or collaborators of a class. The client class might be interested in some service from some other class ( collaborator class ). However, again instead of implementing the actual class we will have a stub implementation. In ruby the mocha gem provides support for functional test using stubbing. This helps in avoiding overlapping test cases. We can see the use of stubs in functional testing using mocha in ruby in the programming languages section.

===Integration Testing===
Integration testing is a logical extension of unit testing. In its simplest form, two units that have already been tested are combined into a component and the interface between them is tested. A component, in this sense, refers to an integrated aggregate of more than one unit. In a realistic scenario, many units are combined into components, which are in turn aggregated into even larger parts of the program. The idea is to test combinations of pieces and eventually expand the process to test your modules with those of other groups. Eventually all the modules making up a process are tested together. Beyond that, if the program is composed of more than one process, they should be tested in pairs rather than all at once.
Integration testing identifies problems that occur when units are combined. By using a test plan that requires you to test each unit and ensure the viability of each before combining units, you know that any errors discovered when combining units are likely related to the interface between units. This method reduces the number of possibilities to a far simpler level of analysis.
The top-down approach to integration testing requires the highest-level modules be test and integrated first. This allows high-level logic and data flow to be tested early in the process and it tends to minimize the need for drivers. However, the need for stubs complicates test management and low-level utilities are tested relatively late in the development cycle. Another disadvantage of top-down integration testing is its poor support for early release of limited functionality.

===Regression Testing===
Regression testing is any type of software testing that seeks to uncover new software bugs, or regressions, in existing functional and non-functional areas of a system after changes, such as enhancements, patches or configuration changes, have been made to them.
The intent of regression testing is to ensure that a change, such as a bugfix, did not introduce new faults.[1] One of the main reasons for regression testing is to determine whether a change in one part of the software affects other parts of the software.[2]
Common methods of regression testing include rerunning previously run tests and checking whether program behavior has changed and whether previously fixed faults have re-emerged. Regression testing can be used to test a system efficiently by systematically selecting the appropriate minimum set of tests needed to adequately cover a particular change.
In Regression testing the use of test stubs is minimized as most of the system is already implemented and the main goal of the regression test is to see if there are any bugs that might have been ‘regressed’ from the previous stages of integrations. Ideally there will not be unimplemented modules by the time a system is tested for regression. However, in case of mutually exclusive modules of a system, a test stub for one of them can be used to test the regression of the other.

==Stubs in software development==
===Agile Development Methodology===
Agile software development is a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change. It is a conceptual framework that promotes foreseen interactions throughout the development cycle.
In such a development system, it recognizes that testing is not a separate phase, but an integral part of software development, along with coding. Agile testing is a software testing practice that follows the principles of agile software development. Agile testing involves all members of a cross-functional agile team, with special expertise contributed by testers, to ensure delivering the business value desired by the customer at frequent intervals, working at a sustainable pace. Specification by example, also known as acceptance test-driven development, is used to capture examples of desired and undesired behavior and guide coding.
In the agile testing toolkit, a stub is a piece of code that behaves in a predefined way, in order to simplify the testing process. Here are the kind of simplifications that a stub can bring:

* If the code under test never returns the same value (usage of a timestamp or of a random value), a stub can be used to fix the root of the undeterminism.

* If the code depends on some other class that has complex behavior that you don’t want to take into account in this test, using a stub for this other class can simplify its behavior and clarify the intent of the test

* If the code depends on some other code that is not yet written or released, it is possible to start building the rest of the code before the dependency is actually finished.

===Rapid Application Development===
Rapid Application Development or RAD is a style of programming that focuses on having tools that allow a program to be created quickly. This is particularly useful for graphically based programs as it is easy to create a frontend which can then be used for testing the backend code. It is a software development methodology that uses minimal planning in favor of rapid prototyping. The "planning" of software developed using RAD is interleaved with writing the software itself. The lack of extensive pre-planning generally allows software to be written much faster, and makes it easier to change requirements. In such a development scenario it becomes increasingly important to be able to write tests and successfully test the software the is being developed so that a complete product is developed in quick time. Test stubs ensure that the testing of code is not stalled in case other modules are still being developed. A programmer can immediately use test stubs and test their code and move on the the next module once its completed.

==Examples of Stubs==
===Java===
In Java, the basic technique is to implement the stub collaborators as concrete classes which only exhibit the small part of the overall behaviour of the collaborator which is needed by the class under test. As an example consider the case where a service implementation is under test. The implementation has a collaborator:

<pre>
public class SimpleService implements Service {
private Collaborator collaborator;
public void setCollaborator(Collaborator collaborator) {
this.collaborator = collaborator;
}

// part of Service interface
public boolean isActive() {
return collaborator.isActive();
}
}
</pre>

We could have a stub collaborator for testing as defined below:

<pre>
public class StubCollaboratorAdapter implements Collaborator {
public boolean isActive() {
return false;
}
}
</pre>

Now, a test case can be written as something like this:

<pre>
public void testActiveWhenCollaboratorIsActive() throws Exception {
Service service = new SimpleService();
service.setCollaborator(new StubCollaboratorAdapter() {
public boolean isActive() {
return true;
}
});
assertTrue(service.isActive());
}
</pre>

===Ruby===
While writing stubs, one might decide to replace a whole object or simply change the results of a single method. When you're replacing a whole object, it's easy—just write the new object and replace it within your test case. Methods might be tougher in some languages, but using dynamic languages such as Ruby, stubbing is easy because you're simply redefining a method.
Imagine you have a user interface that prints a document. You want to test code that handles a print failure. You really don't care if the print method gets called. You just want to verify that if your code does call print, that code will handle a failed print effectively. Think of what a pseudo-code sentence would look like.
On an instance of the document object, stub the print method, returning false.
You can break that sentence down into two parts. The first part identifies what you want to stub. The second part defines what the stub should do.
Below is an example of the Mocha framework that can be used to build stubs in Ruby:
<pre>
class Document
def print
# doesn't matter -- we are stubbing it out
end
end

class View
attr :document

def initialize(document)
@document = document
end

def print()
if document.print
puts "Excellent!"
true
else
puts "Bummer."
false
end
end
end
</pre>
Test code can be written as follows:
<pre>
require 'test/unit'
require 'rubygems'
require 'mocha'
require 'document'

class ViewTest < Test::Unit::TestCase

def test_should_return_false_for_failed_print
document = stub("my document")
document.stubs(:print).returns(false)

ui = View.new(document)
assert_equal false, ui.print
end

end
</pre>
You can see how this works. I build a simple, named stub object with the statement stub("my document"). Then, I define the behavior for print within the stub with the line of code document.stubs(:print).returns(false). If you look carefully, this line of code looks remarkably similar to the pseudo-code from earlier:
On an instance of the document object, stub the print method, returning false.

==IDE support for Stubs==
===Eclipse===

Eclipse provides support to create test stub methods to test the methods developed during development. We can create the junit test case on a java class. We can then select the methods in the class which we would like to test. This will automatically create test stubs to test those methods. In the figure below we are testing methods of ArrayList class

[[File:Eclipse123.png|center]]

===RubyMine===
The most basic way to create test templates in RubyMine is to use the regular procedure of creating files in the project. This means is both available for both plain Ruby projets, and for the Rails applications, and allows creating stub tests for Test::Unit, RSpec and Test-Spec.

For RSpec and Test-Spec, RubyMine provides a number of generators. These generators are context sensitive and become available depending on the selected location, and on the gems activated for your project. For example, ir rspec-rails is activated, the usual generators are hidden, and the list of generators includes only those specific for RSpec.

===Visual Studio===
Visual Studio is a fine IDE that provides good support for automatically generating stubs for methods. Generate Method Stub is an IntelliSense Automatic Code Generation feature that provides an easy way to have Visual Studio create a new method declaration at the time you are writing a method call. Visual Studio infers the declaration from the call. Some programming styles, such as test-driven development, suggest that you should consume before you define. That way, it is easier to figure out the form of the API that you are developing. You can use IntelliSense to program in that style. Using the Generate Method Stub operation, you avoid defining everything before you consume it.

The Generate Method Stub IntelliSense operation can also increase productivity because you do not need to move from the calling code, your present focus, to the defining code, a separate focus, in order to generate a new method. You can instead write a method call, and then invoke the Generate Method Stub operation without dividing your attention.

==Conclusion==
We need tests that “run fast, and help us localize problems.” This can be hard to accomplish when your code accesses a database, hits another server, is time-dependent, etc. By substituting custom objects such as stubs for some of your module's dependencies, you can thoroughly test your code, increase your coverage, and still run in less than a second. You can even simulate rare scenarios like database failures and test your error handling code. In general, Stubs greatly increase the speed of running unit tests and provide a means of testing code independently.

==References==
*[http://blog.springsource.org/2007/01/15/unit-testing-with-stubs-and-mocks/ Test Stubs and Mocks]
*[http://en.wikipedia.org/wiki/Test_stub Test Stubs on wikipedia]
*[http://www.jetbrains.com/ruby/webhelp/creating-test-templates.pdf Test Stub support in RubyMine]
*[http://googletesting.blogspot.com/2007/04/tott-stubs-speed-up-your-unit-tests.html Advantages of Stubs]
*[http://sqa.fyicenter.com/FAQ/Manual-Testing/What_is_stub_Explain_in_testing_point_of_view_.html Stubs and Testing]
*[http://martinfowler.com/articles/mocksArentStubs.html Mocks aren't Stubs]
*[http://www.captaindebug.com/2011/11/regular-unit-tests-and-stubs-testing.html Testing techniques]
* http://www.ibm.com/developerworks/web/library/wa-mockrails/index.html

CSC/ECE 517 Fall 2012/ch2a 2w13 sm

2012-10-27T22:16:18Z

Svmankar: /* Eclipse */

==Introduction==
Test stubs are programs which simulate the behaviors of software components (or [http://en.wikipedia.org/wiki/Modular_programming modules]) on which other modules that are being tested are dependent upon.
Stubs are replacements for missing components that the components being tested will call as part of the test. While doing an [http://en.wikipedia.org/wiki/Integration_testing Integration], if we don't have all the modules ready and need to test a particular module which is ready then we use Stubs and Drivers.
Stubs are used in Integration testing for a [http://en.wikipedia.org/wiki/Top-down_and_bottom-up_design Top Down] Integration testing and Bottom Up Integration Testing.

[[File:Stubs.jpg]]

In the above figure, we can see that the Modules 2 and 3 are not yet implemented. However, if we need to test the modules 4,5 and 6 which are dependent on modules 2 and 3, we can simple use some dummy code in the form of Stubs 1 and 2 in place of the modules that return the values as expected by the modules beneath them. This piece of Dummy code is Called a Stub in a Top Down Integration. Hence Stubs are called Functions in Top Down Integration tests.

==Stubs in different phases of testing==
===Unit Testing===

Unit testing with Stubs:

In developing a huge software if we are following top down approach of development there may be some functionality which may not have been implemented. This can be overcome by implementing all the required functions. However, then we would be testing a huge chunk of code without actually testing it. This will lead to bugs and lot of time will be wasted on debugging. Consider the following example:

Suppose we want to evaluate an expression factorial(x)/( sin(x) + tan(x) ). Assuming that we don't have library support available for calculating factorial,sin and tan of the given input we would have to write those functions. Using stubs we can write functions which would return appropriate values. Thus, assuming that factorial(x) is implemented then we can write stubs for sin and cos functions returning floating point values. We can than verify if our main function gives expected results for those values. This shows us that our main function, factorial are working correct without actually implementing sin and cos functions
<pre>
code:
int main()
{
float y=factorial(x) / (sin(x) + tan(x) );
return 0;
}
int factorial(x)
{

//implmentation of factorial
}

float sin(int x)
{
return 0.5;
}

float cos(int x)
{
return 0.3;
}
</pre>
===Functional Testing===

The idea of stub remains the same in different forms of testing. In unit testing we are dealing with working inside a module and hence we overwrite the dependent implementations by stub. This allows us to test the calling code without the actual implementation. In functional testing we will replace other modules or collaborators of a class. The client class might be interested in some service from some other class ( collaborator class ). However, again instead of implementing the actual class we will have a stub implementation. In ruby the mocha gem provides support for functional test using stubbing. This helps in avoiding overlapping test cases. We can see the use of stubs in functional testing using mocha in ruby in the programming languages section.

===Integration Testing===
Integration testing is a logical extension of unit testing. In its simplest form, two units that have already been tested are combined into a component and the interface between them is tested. A component, in this sense, refers to an integrated aggregate of more than one unit. In a realistic scenario, many units are combined into components, which are in turn aggregated into even larger parts of the program. The idea is to test combinations of pieces and eventually expand the process to test your modules with those of other groups. Eventually all the modules making up a process are tested together. Beyond that, if the program is composed of more than one process, they should be tested in pairs rather than all at once.
Integration testing identifies problems that occur when units are combined. By using a test plan that requires you to test each unit and ensure the viability of each before combining units, you know that any errors discovered when combining units are likely related to the interface between units. This method reduces the number of possibilities to a far simpler level of analysis.
The top-down approach to integration testing requires the highest-level modules be test and integrated first. This allows high-level logic and data flow to be tested early in the process and it tends to minimize the need for drivers. However, the need for stubs complicates test management and low-level utilities are tested relatively late in the development cycle. Another disadvantage of top-down integration testing is its poor support for early release of limited functionality.

===Regression Testing===
Regression testing is any type of software testing that seeks to uncover new software bugs, or regressions, in existing functional and non-functional areas of a system after changes, such as enhancements, patches or configuration changes, have been made to them.
The intent of regression testing is to ensure that a change, such as a bugfix, did not introduce new faults.[1] One of the main reasons for regression testing is to determine whether a change in one part of the software affects other parts of the software.[2]
Common methods of regression testing include rerunning previously run tests and checking whether program behavior has changed and whether previously fixed faults have re-emerged. Regression testing can be used to test a system efficiently by systematically selecting the appropriate minimum set of tests needed to adequately cover a particular change.
In Regression testing the use of test stubs is minimized as most of the system is already implemented and the main goal of the regression test is to see if there are any bugs that might have been ‘regressed’ from the previous stages of integrations. Ideally there will not be unimplemented modules by the time a system is tested for regression. However, in case of mutually exclusive modules of a system, a test stub for one of them can be used to test the regression of the other.

==Stubs in software development==
===Agile Development Methodology===
Agile software development is a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change. It is a conceptual framework that promotes foreseen interactions throughout the development cycle.
In such a development system, it recognizes that testing is not a separate phase, but an integral part of software development, along with coding. Agile testing is a software testing practice that follows the principles of agile software development. Agile testing involves all members of a cross-functional agile team, with special expertise contributed by testers, to ensure delivering the business value desired by the customer at frequent intervals, working at a sustainable pace. Specification by example, also known as acceptance test-driven development, is used to capture examples of desired and undesired behavior and guide coding.
In the agile testing toolkit, a stub is a piece of code that behaves in a predefined way, in order to simplify the testing process. Here are the kind of simplifications that a stub can bring:

* If the code under test never returns the same value (usage of a timestamp or of a random value), a stub can be used to fix the root of the undeterminism.

* If the code depends on some other class that has complex behavior that you don’t want to take into account in this test, using a stub for this other class can simplify its behavior and clarify the intent of the test

* If the code depends on some other code that is not yet written or released, it is possible to start building the rest of the code before the dependency is actually finished.

===Rapid Application Development===
Rapid Application Development or RAD is a style of programming that focuses on having tools that allow a program to be created quickly. This is particularly useful for graphically based programs as it is easy to create a frontend which can then be used for testing the backend code. It is a software development methodology that uses minimal planning in favor of rapid prototyping. The "planning" of software developed using RAD is interleaved with writing the software itself. The lack of extensive pre-planning generally allows software to be written much faster, and makes it easier to change requirements. In such a development scenario it becomes increasingly important to be able to write tests and successfully test the software the is being developed so that a complete product is developed in quick time. Test stubs ensure that the testing of code is not stalled in case other modules are still being developed. A programmer can immediately use test stubs and test their code and move on the the next module once its completed.

==Examples of Stubs==
===Java===
In Java, the basic technique is to implement the stub collaborators as concrete classes which only exhibit the small part of the overall behaviour of the collaborator which is needed by the class under test. As an example consider the case where a service implementation is under test. The implementation has a collaborator:

<pre>
public class SimpleService implements Service {
private Collaborator collaborator;
public void setCollaborator(Collaborator collaborator) {
this.collaborator = collaborator;
}

// part of Service interface
public boolean isActive() {
return collaborator.isActive();
}
}
</pre>

We could have a stub collaborator for testing as defined below:

<pre>
public class StubCollaboratorAdapter implements Collaborator {
public boolean isActive() {
return false;
}
}
</pre>

Now, a test case can be written as something like this:

<pre>
public void testActiveWhenCollaboratorIsActive() throws Exception {
Service service = new SimpleService();
service.setCollaborator(new StubCollaboratorAdapter() {
public boolean isActive() {
return true;
}
});
assertTrue(service.isActive());
}
</pre>

===Ruby===
While writing stubs, one might decide to replace a whole object or simply change the results of a single method. When you're replacing a whole object, it's easy—just write the new object and replace it within your test case. Methods might be tougher in some languages, but using dynamic languages such as Ruby, stubbing is easy because you're simply redefining a method.
Imagine you have a user interface that prints a document. You want to test code that handles a print failure. You really don't care if the print method gets called. You just want to verify that if your code does call print, that code will handle a failed print effectively. Think of what a pseudo-code sentence would look like.
On an instance of the document object, stub the print method, returning false.
You can break that sentence down into two parts. The first part identifies what you want to stub. The second part defines what the stub should do.
Below is an example of the Mocha framework that can be used to build stubs in Ruby:
<pre>
class Document
def print
# doesn't matter -- we are stubbing it out
end
end

class View
attr :document

def initialize(document)
@document = document
end

def print()
if document.print
puts "Excellent!"
true
else
puts "Bummer."
false
end
end
end
</pre>
Test code can be written as follows:
<pre>
require 'test/unit'
require 'rubygems'
require 'mocha'
require 'document'

class ViewTest < Test::Unit::TestCase

def test_should_return_false_for_failed_print
document = stub("my document")
document.stubs(:print).returns(false)

ui = View.new(document)
assert_equal false, ui.print
end

end
</pre>
You can see how this works. I build a simple, named stub object with the statement stub("my document"). Then, I define the behavior for print within the stub with the line of code document.stubs(:print).returns(false). If you look carefully, this line of code looks remarkably similar to the pseudo-code from earlier:
On an instance of the document object, stub the print method, returning false.

==IDE support for Stubs==
===Eclipse===

Eclipse provides support to create test stub methods to test the methods developed during development. We can create the junit test case on a java class. We can then select the methods in the class which we would like to test. This will automatically create test stubs to test those methods. In the figure below we are testing methods of ArrayList class

[[File:Eclipse123.png]]

===RubyMine===
The most basic way to create test templates in RubyMine is to use the regular procedure of creating files in the project. This means is both available for both plain Ruby projets, and for the Rails applications, and allows creating stub tests for Test::Unit, RSpec and Test-Spec.

For RSpec and Test-Spec, RubyMine provides a number of generators. These generators are context sensitive and become available depending on the selected location, and on the gems activated for your project. For example, ir rspec-rails is activated, the usual generators are hidden, and the list of generators includes only those specific for RSpec.

===Visual Studio===
Visual Studio is a fine IDE that provides good support for automatically generating stubs for methods. Generate Method Stub is an IntelliSense Automatic Code Generation feature that provides an easy way to have Visual Studio create a new method declaration at the time you are writing a method call. Visual Studio infers the declaration from the call. Some programming styles, such as test-driven development, suggest that you should consume before you define. That way, it is easier to figure out the form of the API that you are developing. You can use IntelliSense to program in that style. Using the Generate Method Stub operation, you avoid defining everything before you consume it.

The Generate Method Stub IntelliSense operation can also increase productivity because you do not need to move from the calling code, your present focus, to the defining code, a separate focus, in order to generate a new method. You can instead write a method call, and then invoke the Generate Method Stub operation without dividing your attention.

==Conclusion==
We need tests that “run fast, and help us localize problems.” This can be hard to accomplish when your code accesses a database, hits another server, is time-dependent, etc. By substituting custom objects such as stubs for some of your module's dependencies, you can thoroughly test your code, increase your coverage, and still run in less than a second. You can even simulate rare scenarios like database failures and test your error handling code. In general, Stubs greatly increase the speed of running unit tests and provide a means of testing code independently.

==References==
*[http://blog.springsource.org/2007/01/15/unit-testing-with-stubs-and-mocks/ Test Stubs and Mocks]
*[http://en.wikipedia.org/wiki/Test_stub Test Stubs on wikipedia]
*[http://www.jetbrains.com/ruby/webhelp/creating-test-templates.pdf Test Stub support in RubyMine]
*[http://googletesting.blogspot.com/2007/04/tott-stubs-speed-up-your-unit-tests.html Advantages of Stubs]
*[http://sqa.fyicenter.com/FAQ/Manual-Testing/What_is_stub_Explain_in_testing_point_of_view_.html Stubs and Testing]
*[http://martinfowler.com/articles/mocksArentStubs.html Mocks aren't Stubs]
*[http://www.captaindebug.com/2011/11/regular-unit-tests-and-stubs-testing.html Testing techniques]
* http://www.ibm.com/developerworks/web/library/wa-mockrails/index.html

File:Eclipse123.png

2012-10-27T22:15:45Z

Svmankar:

CSC/ECE 517 Fall 2012/ch2a 2w13 sm

2012-10-27T21:44:23Z

Svmankar: /* Python */

==Introduction==
Test stubs are programs which simulate the behaviors of software components (or [http://en.wikipedia.org/wiki/Modular_programming modules]) on which other modules that are being tested are dependent upon.
Stubs are replacements for missing components that the components being tested will call as part of the test. While doing an [http://en.wikipedia.org/wiki/Integration_testing Integration], if we don't have all the modules ready and need to test a particular module which is ready then we use Stubs and Drivers.
Stubs are used in Integration testing for a [http://en.wikipedia.org/wiki/Top-down_and_bottom-up_design Top Down] Integration testing and Bottom Up Integration Testing.

[[File:Stubs.jpg]]

In the above figure, we can see that the Modules 2 and 3 are not yet implemented. However, if we need to test the modules 4,5 and 6 which are dependent on modules 2 and 3, we can simple use some dummy code in the form of Stubs 1 and 2 in place of the modules that return the values as expected by the modules beneath them. This piece of Dummy code is Called a Stub in a Top Down Integration. Hence Stubs are called Functions in Top Down Integration tests.

==Stubs in different phases of testing==
===Unit Testing===

Unit testing with Stubs:

In developing a huge software if we are following top down approach of development there may be some functionality which may not have been implemented. This can be overcome by implementing all the required functions. However, then we would be testing a huge chunk of code without actually testing it. This will lead to bugs and lot of time will be wasted on debugging. Consider the following example:

Suppose we want to evaluate an expression factorial(x)/( sin(x) + tan(x) ). Assuming that we don't have library support available for calculating factorial,sin and tan of the given input we would have to write those functions. Using stubs we can write functions which would return appropriate values. Thus, assuming that factorial(x) is implemented then we can write stubs for sin and cos functions returning floating point values. We can than verify if our main function gives expected results for those values. This shows us that our main function, factorial are working correct without actually implementing sin and cos functions
<pre>
code:
int main()
{
float y=factorial(x) / (sin(x) + tan(x) );
return 0;
}
int factorial(x)
{

//implmentation of factorial
}

float sin(int x)
{
return 0.5;
}

float cos(int x)
{
return 0.3;
}
</pre>
===Functional Testing===

The idea of stub remains the same in different forms of testing. In unit testing we are dealing with working inside a module and hence we overwrite the dependent implementations by stub. This allows us to test the calling code without the actual implementation. In functional testing we will replace other modules or collaborators of a class. The client class might be interested in some service from some other class ( collaborator class ). However, again instead of implementing the actual class we will have a stub implementation. In ruby the mocha gem provides support for functional test using stubbing. This helps in avoiding overlapping test cases. We can see the use of stubs in functional testing using mocha in ruby in the programming languages section.

===Integration Testing===
Integration testing is a logical extension of unit testing. In its simplest form, two units that have already been tested are combined into a component and the interface between them is tested. A component, in this sense, refers to an integrated aggregate of more than one unit. In a realistic scenario, many units are combined into components, which are in turn aggregated into even larger parts of the program. The idea is to test combinations of pieces and eventually expand the process to test your modules with those of other groups. Eventually all the modules making up a process are tested together. Beyond that, if the program is composed of more than one process, they should be tested in pairs rather than all at once.
Integration testing identifies problems that occur when units are combined. By using a test plan that requires you to test each unit and ensure the viability of each before combining units, you know that any errors discovered when combining units are likely related to the interface between units. This method reduces the number of possibilities to a far simpler level of analysis.
The top-down approach to integration testing requires the highest-level modules be test and integrated first. This allows high-level logic and data flow to be tested early in the process and it tends to minimize the need for drivers. However, the need for stubs complicates test management and low-level utilities are tested relatively late in the development cycle. Another disadvantage of top-down integration testing is its poor support for early release of limited functionality.

===Regression Testing===
Regression testing is any type of software testing that seeks to uncover new software bugs, or regressions, in existing functional and non-functional areas of a system after changes, such as enhancements, patches or configuration changes, have been made to them.
The intent of regression testing is to ensure that a change, such as a bugfix, did not introduce new faults.[1] One of the main reasons for regression testing is to determine whether a change in one part of the software affects other parts of the software.[2]
Common methods of regression testing include rerunning previously run tests and checking whether program behavior has changed and whether previously fixed faults have re-emerged. Regression testing can be used to test a system efficiently by systematically selecting the appropriate minimum set of tests needed to adequately cover a particular change.
In Regression testing the use of test stubs is minimized as most of the system is already implemented and the main goal of the regression test is to see if there are any bugs that might have been ‘regressed’ from the previous stages of integrations. Ideally there will not be unimplemented modules by the time a system is tested for regression. However, in case of mutually exclusive modules of a system, a test stub for one of them can be used to test the regression of the other.

==Stubs in software development==
===Agile Development Methodology===
Agile software development is a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change. It is a conceptual framework that promotes foreseen interactions throughout the development cycle.
In such a development system, it recognizes that testing is not a separate phase, but an integral part of software development, along with coding. Agile testing is a software testing practice that follows the principles of agile software development. Agile testing involves all members of a cross-functional agile team, with special expertise contributed by testers, to ensure delivering the business value desired by the customer at frequent intervals, working at a sustainable pace. Specification by example, also known as acceptance test-driven development, is used to capture examples of desired and undesired behavior and guide coding.
In the agile testing toolkit, a stub is a piece of code that behaves in a predefined way, in order to simplify the testing process. Here are the kind of simplifications that a stub can bring:

* If the code under test never returns the same value (usage of a timestamp or of a random value), a stub can be used to fix the root of the undeterminism.

* If the code depends on some other class that has complex behavior that you don’t want to take into account in this test, using a stub for this other class can simplify its behavior and clarify the intent of the test

* If the code depends on some other code that is not yet written or released, it is possible to start building the rest of the code before the dependency is actually finished.

===Rapid Application Development===
Rapid Application Development or RAD is a style of programming that focuses on having tools that allow a program to be created quickly. This is particularly useful for graphically based programs as it is easy to create a frontend which can then be used for testing the backend code. It is a software development methodology that uses minimal planning in favor of rapid prototyping. The "planning" of software developed using RAD is interleaved with writing the software itself. The lack of extensive pre-planning generally allows software to be written much faster, and makes it easier to change requirements. In such a development scenario it becomes increasingly important to be able to write tests and successfully test the software the is being developed so that a complete product is developed in quick time. Test stubs ensure that the testing of code is not stalled in case other modules are still being developed. A programmer can immediately use test stubs and test their code and move on the the next module once its completed.

==Examples of Stubs==
===Java===
In Java, the basic technique is to implement the stub collaborators as concrete classes which only exhibit the small part of the overall behaviour of the collaborator which is needed by the class under test. As an example consider the case where a service implementation is under test. The implementation has a collaborator:

<pre>
public class SimpleService implements Service {
private Collaborator collaborator;
public void setCollaborator(Collaborator collaborator) {
this.collaborator = collaborator;
}

// part of Service interface
public boolean isActive() {
return collaborator.isActive();
}
}
</pre>

We could have a stub collaborator for testing as defined below:

<pre>
public class StubCollaboratorAdapter implements Collaborator {
public boolean isActive() {
return false;
}
}
</pre>

Now, a test case can be written as something like this:

<pre>
public void testActiveWhenCollaboratorIsActive() throws Exception {
Service service = new SimpleService();
service.setCollaborator(new StubCollaboratorAdapter() {
public boolean isActive() {
return true;
}
});
assertTrue(service.isActive());
}
</pre>

===Ruby===
While writing stubs, one might decide to replace a whole object or simply change the results of a single method. When you're replacing a whole object, it's easy—just write the new object and replace it within your test case. Methods might be tougher in some languages, but using dynamic languages such as Ruby, stubbing is easy because you're simply redefining a method.
Imagine you have a user interface that prints a document. You want to test code that handles a print failure. You really don't care if the print method gets called. You just want to verify that if your code does call print, that code will handle a failed print effectively. Think of what a pseudo-code sentence would look like.
On an instance of the document object, stub the print method, returning false.
You can break that sentence down into two parts. The first part identifies what you want to stub. The second part defines what the stub should do.
Below is an example of the Mocha framework that can be used to build stubs in Ruby:
<pre>
class Document
def print
# doesn't matter -- we are stubbing it out
end
end

class View
attr :document

def initialize(document)
@document = document
end

def print()
if document.print
puts "Excellent!"
true
else
puts "Bummer."
false
end
end
end
</pre>
Test code can be written as follows:
<pre>
require 'test/unit'
require 'rubygems'
require 'mocha'
require 'document'

class ViewTest < Test::Unit::TestCase

def test_should_return_false_for_failed_print
document = stub("my document")
document.stubs(:print).returns(false)

ui = View.new(document)
assert_equal false, ui.print
end

end
</pre>
You can see how this works. I build a simple, named stub object with the statement stub("my document"). Then, I define the behavior for print within the stub with the line of code document.stubs(:print).returns(false). If you look carefully, this line of code looks remarkably similar to the pseudo-code from earlier:
On an instance of the document object, stub the print method, returning false.

==IDE support for Stubs==
===Eclipse===

Eclipse provides support to create test stub methods to test the methods developed during development. We can create the junit test case on a java class. We can then select the methods in the class which we would like to test. This will automatically create test stubs to test those methods. In the figure below we are testing methods of ArrayList class

[[File:Eclipsestub1.png]]

===RubyMine===
The most basic way to create test templates in RubyMine is to use the regular procedure of creating files in the project. This means is both available for both plain Ruby projets, and for the Rails applications, and allows creating stub tests for Test::Unit, RSpec and Test-Spec.

For RSpec and Test-Spec, RubyMine provides a number of generators. These generators are context sensitive and become available depending on the selected location, and on the gems activated for your project. For example, ir rspec-rails is activated, the usual generators are hidden, and the list of generators includes only those specific for RSpec.

===Visual Studio===
Visual Studio is a fine IDE that provides good support for automatically generating stubs for methods. Generate Method Stub is an IntelliSense Automatic Code Generation feature that provides an easy way to have Visual Studio create a new method declaration at the time you are writing a method call. Visual Studio infers the declaration from the call. Some programming styles, such as test-driven development, suggest that you should consume before you define. That way, it is easier to figure out the form of the API that you are developing. You can use IntelliSense to program in that style. Using the Generate Method Stub operation, you avoid defining everything before you consume it.

The Generate Method Stub IntelliSense operation can also increase productivity because you do not need to move from the calling code, your present focus, to the defining code, a separate focus, in order to generate a new method. You can instead write a method call, and then invoke the Generate Method Stub operation without dividing your attention.

==Conclusion==
We need tests that “run fast, and help us localize problems.” This can be hard to accomplish when your code accesses a database, hits another server, is time-dependent, etc. By substituting custom objects such as stubs for some of your module's dependencies, you can thoroughly test your code, increase your coverage, and still run in less than a second. You can even simulate rare scenarios like database failures and test your error handling code. In general, Stubs greatly increase the speed of running unit tests and provide a means of testing code independently.

==References==
*[http://blog.springsource.org/2007/01/15/unit-testing-with-stubs-and-mocks/ Test Stubs and Mocks]
*[http://en.wikipedia.org/wiki/Test_stub Test Stubs on wikipedia]
*[http://www.jetbrains.com/ruby/webhelp/creating-test-templates.pdf Test Stub support in RubyMine]
*[http://googletesting.blogspot.com/2007/04/tott-stubs-speed-up-your-unit-tests.html Advantages of Stubs]
*[http://sqa.fyicenter.com/FAQ/Manual-Testing/What_is_stub_Explain_in_testing_point_of_view_.html Stubs and Testing]
*[http://martinfowler.com/articles/mocksArentStubs.html Mocks aren't Stubs]
*[http://www.captaindebug.com/2011/11/regular-unit-tests-and-stubs-testing.html Testing techniques]
* http://www.ibm.com/developerworks/web/library/wa-mockrails/index.html

CSC/ECE 517 Fall 2012/ch2a 2w13 sm

2012-10-27T21:40:28Z

Svmankar: /* Eclipse */

==Introduction==
Test stubs are programs which simulate the behaviors of software components (or [http://en.wikipedia.org/wiki/Modular_programming modules]) on which other modules that are being tested are dependent upon.
Stubs are replacements for missing components that the components being tested will call as part of the test. While doing an [http://en.wikipedia.org/wiki/Integration_testing Integration], if we don't have all the modules ready and need to test a particular module which is ready then we use Stubs and Drivers.
Stubs are used in Integration testing for a [http://en.wikipedia.org/wiki/Top-down_and_bottom-up_design Top Down] Integration testing and Bottom Up Integration Testing.

[[File:Stubs.jpg]]

In the above figure, we can see that the Modules 2 and 3 are not yet implemented. However, if we need to test the modules 4,5 and 6 which are dependent on modules 2 and 3, we can simple use some dummy code in the form of Stubs 1 and 2 in place of the modules that return the values as expected by the modules beneath them. This piece of Dummy code is Called a Stub in a Top Down Integration. Hence Stubs are called Functions in Top Down Integration tests.

==Stubs in different phases of testing==
===Unit Testing===

Unit testing with Stubs:

In developing a huge software if we are following top down approach of development there may be some functionality which may not have been implemented. This can be overcome by implementing all the required functions. However, then we would be testing a huge chunk of code without actually testing it. This will lead to bugs and lot of time will be wasted on debugging. Consider the following example:

Suppose we want to evaluate an expression factorial(x)/( sin(x) + tan(x) ). Assuming that we don't have library support available for calculating factorial,sin and tan of the given input we would have to write those functions. Using stubs we can write functions which would return appropriate values. Thus, assuming that factorial(x) is implemented then we can write stubs for sin and cos functions returning floating point values. We can than verify if our main function gives expected results for those values. This shows us that our main function, factorial are working correct without actually implementing sin and cos functions
<pre>
code:
int main()
{
float y=factorial(x) / (sin(x) + tan(x) );
return 0;
}
int factorial(x)
{

//implmentation of factorial
}

float sin(int x)
{
return 0.5;
}

float cos(int x)
{
return 0.3;
}
</pre>
===Functional Testing===

The idea of stub remains the same in different forms of testing. In unit testing we are dealing with working inside a module and hence we overwrite the dependent implementations by stub. This allows us to test the calling code without the actual implementation. In functional testing we will replace other modules or collaborators of a class. The client class might be interested in some service from some other class ( collaborator class ). However, again instead of implementing the actual class we will have a stub implementation. In ruby the mocha gem provides support for functional test using stubbing. This helps in avoiding overlapping test cases. We can see the use of stubs in functional testing using mocha in ruby in the programming languages section.

===Integration Testing===
Integration testing is a logical extension of unit testing. In its simplest form, two units that have already been tested are combined into a component and the interface between them is tested. A component, in this sense, refers to an integrated aggregate of more than one unit. In a realistic scenario, many units are combined into components, which are in turn aggregated into even larger parts of the program. The idea is to test combinations of pieces and eventually expand the process to test your modules with those of other groups. Eventually all the modules making up a process are tested together. Beyond that, if the program is composed of more than one process, they should be tested in pairs rather than all at once.
Integration testing identifies problems that occur when units are combined. By using a test plan that requires you to test each unit and ensure the viability of each before combining units, you know that any errors discovered when combining units are likely related to the interface between units. This method reduces the number of possibilities to a far simpler level of analysis.
The top-down approach to integration testing requires the highest-level modules be test and integrated first. This allows high-level logic and data flow to be tested early in the process and it tends to minimize the need for drivers. However, the need for stubs complicates test management and low-level utilities are tested relatively late in the development cycle. Another disadvantage of top-down integration testing is its poor support for early release of limited functionality.

===Regression Testing===
Regression testing is any type of software testing that seeks to uncover new software bugs, or regressions, in existing functional and non-functional areas of a system after changes, such as enhancements, patches or configuration changes, have been made to them.
The intent of regression testing is to ensure that a change, such as a bugfix, did not introduce new faults.[1] One of the main reasons for regression testing is to determine whether a change in one part of the software affects other parts of the software.[2]
Common methods of regression testing include rerunning previously run tests and checking whether program behavior has changed and whether previously fixed faults have re-emerged. Regression testing can be used to test a system efficiently by systematically selecting the appropriate minimum set of tests needed to adequately cover a particular change.
In Regression testing the use of test stubs is minimized as most of the system is already implemented and the main goal of the regression test is to see if there are any bugs that might have been ‘regressed’ from the previous stages of integrations. Ideally there will not be unimplemented modules by the time a system is tested for regression. However, in case of mutually exclusive modules of a system, a test stub for one of them can be used to test the regression of the other.

==Stubs in software development==
===Agile Development Methodology===
Agile software development is a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change. It is a conceptual framework that promotes foreseen interactions throughout the development cycle.
In such a development system, it recognizes that testing is not a separate phase, but an integral part of software development, along with coding. Agile testing is a software testing practice that follows the principles of agile software development. Agile testing involves all members of a cross-functional agile team, with special expertise contributed by testers, to ensure delivering the business value desired by the customer at frequent intervals, working at a sustainable pace. Specification by example, also known as acceptance test-driven development, is used to capture examples of desired and undesired behavior and guide coding.
In the agile testing toolkit, a stub is a piece of code that behaves in a predefined way, in order to simplify the testing process. Here are the kind of simplifications that a stub can bring:

* If the code under test never returns the same value (usage of a timestamp or of a random value), a stub can be used to fix the root of the undeterminism.

* If the code depends on some other class that has complex behavior that you don’t want to take into account in this test, using a stub for this other class can simplify its behavior and clarify the intent of the test

* If the code depends on some other code that is not yet written or released, it is possible to start building the rest of the code before the dependency is actually finished.

===Rapid Application Development===
Rapid Application Development or RAD is a style of programming that focuses on having tools that allow a program to be created quickly. This is particularly useful for graphically based programs as it is easy to create a frontend which can then be used for testing the backend code. It is a software development methodology that uses minimal planning in favor of rapid prototyping. The "planning" of software developed using RAD is interleaved with writing the software itself. The lack of extensive pre-planning generally allows software to be written much faster, and makes it easier to change requirements. In such a development scenario it becomes increasingly important to be able to write tests and successfully test the software the is being developed so that a complete product is developed in quick time. Test stubs ensure that the testing of code is not stalled in case other modules are still being developed. A programmer can immediately use test stubs and test their code and move on the the next module once its completed.

==Examples of Stubs==
===Java===
In Java, the basic technique is to implement the stub collaborators as concrete classes which only exhibit the small part of the overall behaviour of the collaborator which is needed by the class under test. As an example consider the case where a service implementation is under test. The implementation has a collaborator:

<pre>
public class SimpleService implements Service {
private Collaborator collaborator;
public void setCollaborator(Collaborator collaborator) {
this.collaborator = collaborator;
}

// part of Service interface
public boolean isActive() {
return collaborator.isActive();
}
}
</pre>

We could have a stub collaborator for testing as defined below:

<pre>
public class StubCollaboratorAdapter implements Collaborator {
public boolean isActive() {
return false;
}
}
</pre>

Now, a test case can be written as something like this:

<pre>
public void testActiveWhenCollaboratorIsActive() throws Exception {
Service service = new SimpleService();
service.setCollaborator(new StubCollaboratorAdapter() {
public boolean isActive() {
return true;
}
});
assertTrue(service.isActive());
}
</pre>

===Ruby===
While writing stubs, one might decide to replace a whole object or simply change the results of a single method. When you're replacing a whole object, it's easy—just write the new object and replace it within your test case. Methods might be tougher in some languages, but using dynamic languages such as Ruby, stubbing is easy because you're simply redefining a method.
Imagine you have a user interface that prints a document. You want to test code that handles a print failure. You really don't care if the print method gets called. You just want to verify that if your code does call print, that code will handle a failed print effectively. Think of what a pseudo-code sentence would look like.
On an instance of the document object, stub the print method, returning false.
You can break that sentence down into two parts. The first part identifies what you want to stub. The second part defines what the stub should do.
Below is an example of the Mocha framework that can be used to build stubs in Ruby:
<pre>
class Document
def print
# doesn't matter -- we are stubbing it out
end
end

class View
attr :document

def initialize(document)
@document = document
end

def print()
if document.print
puts "Excellent!"
true
else
puts "Bummer."
false
end
end
end
</pre>
Test code can be written as follows:
<pre>
require 'test/unit'
require 'rubygems'
require 'mocha'
require 'document'

class ViewTest < Test::Unit::TestCase

def test_should_return_false_for_failed_print
document = stub("my document")
document.stubs(:print).returns(false)

ui = View.new(document)
assert_equal false, ui.print
end

end
</pre>
You can see how this works. I build a simple, named stub object with the statement stub("my document"). Then, I define the behavior for print within the stub with the line of code document.stubs(:print).returns(false). If you look carefully, this line of code looks remarkably similar to the pseudo-code from earlier:
On an instance of the document object, stub the print method, returning false.

===Python===

==IDE support for Stubs==
===Eclipse===

Eclipse provides support to create test stub methods to test the methods developed during development. We can create the junit test case on a java class. We can then select the methods in the class which we would like to test. This will automatically create test stubs to test those methods. In the figure below we are testing methods of ArrayList class

[[File:Eclipsestub1.png]]

===RubyMine===
The most basic way to create test templates in RubyMine is to use the regular procedure of creating files in the project. This means is both available for both plain Ruby projets, and for the Rails applications, and allows creating stub tests for Test::Unit, RSpec and Test-Spec.

For RSpec and Test-Spec, RubyMine provides a number of generators. These generators are context sensitive and become available depending on the selected location, and on the gems activated for your project. For example, ir rspec-rails is activated, the usual generators are hidden, and the list of generators includes only those specific for RSpec.

===Visual Studio===
Visual Studio is a fine IDE that provides good support for automatically generating stubs for methods. Generate Method Stub is an IntelliSense Automatic Code Generation feature that provides an easy way to have Visual Studio create a new method declaration at the time you are writing a method call. Visual Studio infers the declaration from the call. Some programming styles, such as test-driven development, suggest that you should consume before you define. That way, it is easier to figure out the form of the API that you are developing. You can use IntelliSense to program in that style. Using the Generate Method Stub operation, you avoid defining everything before you consume it.

The Generate Method Stub IntelliSense operation can also increase productivity because you do not need to move from the calling code, your present focus, to the defining code, a separate focus, in order to generate a new method. You can instead write a method call, and then invoke the Generate Method Stub operation without dividing your attention.

==Conclusion==
We need tests that “run fast, and help us localize problems.” This can be hard to accomplish when your code accesses a database, hits another server, is time-dependent, etc. By substituting custom objects such as stubs for some of your module's dependencies, you can thoroughly test your code, increase your coverage, and still run in less than a second. You can even simulate rare scenarios like database failures and test your error handling code. In general, Stubs greatly increase the speed of running unit tests and provide a means of testing code independently.

==References==
*[http://blog.springsource.org/2007/01/15/unit-testing-with-stubs-and-mocks/ Test Stubs and Mocks]
*[http://en.wikipedia.org/wiki/Test_stub Test Stubs on wikipedia]
*[http://www.jetbrains.com/ruby/webhelp/creating-test-templates.pdf Test Stub support in RubyMine]
*[http://googletesting.blogspot.com/2007/04/tott-stubs-speed-up-your-unit-tests.html Advantages of Stubs]
*[http://sqa.fyicenter.com/FAQ/Manual-Testing/What_is_stub_Explain_in_testing_point_of_view_.html Stubs and Testing]
*[http://martinfowler.com/articles/mocksArentStubs.html Mocks aren't Stubs]
*[http://www.captaindebug.com/2011/11/regular-unit-tests-and-stubs-testing.html Testing techniques]
* http://www.ibm.com/developerworks/web/library/wa-mockrails/index.html

File:Eclipsestub1.png

2012-10-27T21:39:45Z

Svmankar:

CSC/ECE 517 Fall 2012/ch2a 2w13 sm

2012-10-27T18:36:37Z

Svmankar: /* Stubs in software development */

==Introduction==
Test stubs are programs which simulate the behaviors of software components (or [http://en.wikipedia.org/wiki/Modular_programming modules]) on which other modules that are being tested are dependent upon.
Stubs are replacements for missing components that the components being tested will call as part of the test. While doing an [http://en.wikipedia.org/wiki/Integration_testing Integration], if we don't have all the modules ready and need to test a particular module which is ready then we use Stubs and Drivers.
Stubs are used in Integration testing for a [http://en.wikipedia.org/wiki/Top-down_and_bottom-up_design Top Down] Integration testing and Bottom Up Integration Testing.

[[File:Stubs.jpg]]

In the above figure, we can see that the Modules 2 and 3 are not yet implemented. However, if we need to test the modules 4,5 and 6 which are dependent on modules 2 and 3, we can simple use some dummy code in the form of Stubs 1 and 2 in place of the modules that return the values as expected by the modules beneath them. This piece of Dummy code is Called a Stub in a Top Down Integration. Hence Stubs are called Functions in Top Down Integration tests.

==Stubs in different phases of testing==
===Unit Testing===

Unit testing with Stubs:

In developing a huge software if we are following top down approach of development there may be some functionality which may not have been implemented. This can be overcome by implementing all the required functions. However, then we would be testing a huge chunk of code without actually testing it. This will lead to bugs and lot of time will be wasted on debugging. Consider the following example:

Suppose we want to evaluate an expression factorial(x)/( sin(x) + tan(x) ). Assuming that we don't have library support available for calculating factorial,sin and tan of the given input we would have to write those functions. Using stubs we can write functions which would return appropriate values. Thus, assuming that factorial(x) is implemented then we can write stubs for sin and cos functions returning floating point values. We can than verify if our main function gives expected results for those values. This shows us that our main function, factorial are working correct without actually implementing sin and cos functions
<pre>
code:
int main()
{
float y=factorial(x) / (sin(x) + tan(x) );
return 0;
}
int factorial(x)
{

//implmentation of factorial
}

float sin(int x)
{
return 0.5;
}

float cos(int x)
{
return 0.3;
}
</pre>
===Functional Testing===

The idea of stub remains the same in different forms of testing. In unit testing we are dealing with working inside a module and hence we overwrite the dependent implementations by stub. This allows us to test the calling code without the actual implementation. In functional testing we will replace other modules or collaborators of a class. The client class might be interested in some service from some other class ( collaborator class ). However, again instead of implementing the actual class we will have a stub implementation. In ruby the mocha gem provides support for functional test using stubbing. This helps in avoiding overlapping test cases. We can see the use of stubs in functional testing using mocha in ruby in the programming languages section.

===Integration Testing===
Integration testing is a logical extension of unit testing. In its simplest form, two units that have already been tested are combined into a component and the interface between them is tested. A component, in this sense, refers to an integrated aggregate of more than one unit. In a realistic scenario, many units are combined into components, which are in turn aggregated into even larger parts of the program. The idea is to test combinations of pieces and eventually expand the process to test your modules with those of other groups. Eventually all the modules making up a process are tested together. Beyond that, if the program is composed of more than one process, they should be tested in pairs rather than all at once.
Integration testing identifies problems that occur when units are combined. By using a test plan that requires you to test each unit and ensure the viability of each before combining units, you know that any errors discovered when combining units are likely related to the interface between units. This method reduces the number of possibilities to a far simpler level of analysis.
The top-down approach to integration testing requires the highest-level modules be test and integrated first. This allows high-level logic and data flow to be tested early in the process and it tends to minimize the need for drivers. However, the need for stubs complicates test management and low-level utilities are tested relatively late in the development cycle. Another disadvantage of top-down integration testing is its poor support for early release of limited functionality.

===Regression Testing===
Regression testing is any type of software testing that seeks to uncover new software bugs, or regressions, in existing functional and non-functional areas of a system after changes, such as enhancements, patches or configuration changes, have been made to them.
The intent of regression testing is to ensure that a change, such as a bugfix, did not introduce new faults.[1] One of the main reasons for regression testing is to determine whether a change in one part of the software affects other parts of the software.[2]
Common methods of regression testing include rerunning previously run tests and checking whether program behavior has changed and whether previously fixed faults have re-emerged. Regression testing can be used to test a system efficiently by systematically selecting the appropriate minimum set of tests needed to adequately cover a particular change.
In Regression testing the use of test stubs is minimized as most of the system is already implemented and the main goal of the regression test is to see if there are any bugs that might have been ‘regressed’ from the previous stages of integrations. Ideally there will not be unimplemented modules by the time a system is tested for regression. However, in case of mutually exclusive modules of a system, a test stub for one of them can be used to test the regression of the other.

==Stubs in software development==
===Agile Development Methodology===
Agile software development is a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change. It is a conceptual framework that promotes foreseen interactions throughout the development cycle.
In such a development system, it recognizes that testing is not a separate phase, but an integral part of software development, along with coding. Agile testing is a software testing practice that follows the principles of agile software development. Agile testing involves all members of a cross-functional agile team, with special expertise contributed by testers, to ensure delivering the business value desired by the customer at frequent intervals, working at a sustainable pace. Specification by example, also known as acceptance test-driven development, is used to capture examples of desired and undesired behavior and guide coding.
In the agile testing toolkit, a stub is a piece of code that behaves in a predefined way, in order to simplify the testing process. Here are the kind of simplifications that a stub can bring:

* If the code under test never returns the same value (usage of a timestamp or of a random value), a stub can be used to fix the root of the undeterminism.

* If the code depends on some other class that has complex behavior that you don’t want to take into account in this test, using a stub for this other class can simplify its behavior and clarify the intent of the test

* If the code depends on some other code that is not yet written or released, it is possible to start building the rest of the code before the dependency is actually finished.

===Rapid Application Development===
Rapid Application Development or RAD is a style of programming that focuses on having tools that allow a program to be created quickly. This is particularly useful for graphically based programs as it is easy to create a frontend which can then be used for testing the backend code. It is a software development methodology that uses minimal planning in favor of rapid prototyping. The "planning" of software developed using RAD is interleaved with writing the software itself. The lack of extensive pre-planning generally allows software to be written much faster, and makes it easier to change requirements. In such a development scenario it becomes increasingly important to be able to write tests and successfully test the software the is being developed so that a complete product is developed in quick time. Test stubs ensure that the testing of code is not stalled in case other modules are still being developed. A programmer can immediately use test stubs and test their code and move on the the next module once its completed.

==Examples of Stubs==
===Java===
In Java, the basic technique is to implement the stub collaborators as concrete classes which only exhibit the small part of the overall behaviour of the collaborator which is needed by the class under test. As an example consider the case where a service implementation is under test. The implementation has a collaborator:

<pre>
public class SimpleService implements Service {
private Collaborator collaborator;
public void setCollaborator(Collaborator collaborator) {
this.collaborator = collaborator;
}

// part of Service interface
public boolean isActive() {
return collaborator.isActive();
}
}
</pre>

We could have a stub collaborator for testing as defined below:

<pre>
public class StubCollaboratorAdapter implements Collaborator {
public boolean isActive() {
return false;
}
}
</pre>

Now, a test case can be written as something like this:

<pre>
public void testActiveWhenCollaboratorIsActive() throws Exception {
Service service = new SimpleService();
service.setCollaborator(new StubCollaboratorAdapter() {
public boolean isActive() {
return true;
}
});
assertTrue(service.isActive());
}
</pre>

===Ruby===
While writing stubs, one might decide to replace a whole object or simply change the results of a single method. When you're replacing a whole object, it's easy—just write the new object and replace it within your test case. Methods might be tougher in some languages, but using dynamic languages such as Ruby, stubbing is easy because you're simply redefining a method.
Imagine you have a user interface that prints a document. You want to test code that handles a print failure. You really don't care if the print method gets called. You just want to verify that if your code does call print, that code will handle a failed print effectively. Think of what a pseudo-code sentence would look like.
On an instance of the document object, stub the print method, returning false.
You can break that sentence down into two parts. The first part identifies what you want to stub. The second part defines what the stub should do.
Below is an example of the Mocha framework that can be used to build stubs in Ruby:
<pre>
class Document
def print
# doesn't matter -- we are stubbing it out
end
end

class View
attr :document

def initialize(document)
@document = document
end

def print()
if document.print
puts "Excellent!"
true
else
puts "Bummer."
false
end
end
end
</pre>
Test code can be written as follows:
<pre>
require 'test/unit'
require 'rubygems'
require 'mocha'
require 'document'

class ViewTest < Test::Unit::TestCase

def test_should_return_false_for_failed_print
document = stub("my document")
document.stubs(:print).returns(false)

ui = View.new(document)
assert_equal false, ui.print
end

end
</pre>
You can see how this works. I build a simple, named stub object with the statement stub("my document"). Then, I define the behavior for print within the stub with the line of code document.stubs(:print).returns(false). If you look carefully, this line of code looks remarkably similar to the pseudo-code from earlier:
On an instance of the document object, stub the print method, returning false.

===Python===

==IDE support for Stubs==
===Eclipse===

Eclipse provides support to create test stub methods to test the methods developed during development. We can create the junit test case on a java class. We can then select the methods in the class which we would like to test. This will automatically create test stubs to test those methods. In the figure below we are testing methods of ArrayList class

[[File:Eclipsestub.png]]

===RubyMine===
The most basic way to create test templates in RubyMine is to use the regular procedure of creating files in the project. This means is both available for both plain Ruby projets, and for the Rails applications, and allows creating stub tests for Test::Unit, RSpec and Test-Spec.

For RSpec and Test-Spec, RubyMine provides a number of generators. These generators are context sensitive and become available depending on the selected location, and on the gems activated for your project. For example, ir rspec-rails is activated, the usual generators are hidden, and the list of generators includes only those specific for RSpec.

===Visual Studio===
Visual Studio is a fine IDE that provides good support for automatically generating stubs for methods. Generate Method Stub is an IntelliSense Automatic Code Generation feature that provides an easy way to have Visual Studio create a new method declaration at the time you are writing a method call. Visual Studio infers the declaration from the call. Some programming styles, such as test-driven development, suggest that you should consume before you define. That way, it is easier to figure out the form of the API that you are developing. You can use IntelliSense to program in that style. Using the Generate Method Stub operation, you avoid defining everything before you consume it.

The Generate Method Stub IntelliSense operation can also increase productivity because you do not need to move from the calling code, your present focus, to the defining code, a separate focus, in order to generate a new method. You can instead write a method call, and then invoke the Generate Method Stub operation without dividing your attention.

==Conclusion==
We need tests that “run fast, and help us localize problems.” This can be hard to accomplish when your code accesses a database, hits another server, is time-dependent, etc. By substituting custom objects such as stubs for some of your module's dependencies, you can thoroughly test your code, increase your coverage, and still run in less than a second. You can even simulate rare scenarios like database failures and test your error handling code. In general, Stubs greatly increase the speed of running unit tests and provide a means of testing code independently.

==References==
*[http://blog.springsource.org/2007/01/15/unit-testing-with-stubs-and-mocks/ Test Stubs and Mocks]
*[http://en.wikipedia.org/wiki/Test_stub Test Stubs on wikipedia]
*[http://www.jetbrains.com/ruby/webhelp/creating-test-templates.pdf Test Stub support in RubyMine]
*[http://googletesting.blogspot.com/2007/04/tott-stubs-speed-up-your-unit-tests.html Advantages of Stubs]
*[http://sqa.fyicenter.com/FAQ/Manual-Testing/What_is_stub_Explain_in_testing_point_of_view_.html Stubs and Testing]
*[http://martinfowler.com/articles/mocksArentStubs.html Mocks aren't Stubs]
*[http://www.captaindebug.com/2011/11/regular-unit-tests-and-stubs-testing.html Testing techniques]
* http://www.ibm.com/developerworks/web/library/wa-mockrails/index.html

CSC/ECE 517 Fall 2012/ch2a 2w13 sm

2012-10-27T18:13:25Z

Svmankar: /* Stubs in software development methodologies */

==Introduction==
Test stubs are programs which simulate the behaviors of software components (or [http://en.wikipedia.org/wiki/Modular_programming modules]) on which other modules that are being tested are dependent upon.
Stubs are replacements for missing components that the components being tested will call as part of the test. While doing an [http://en.wikipedia.org/wiki/Integration_testing Integration], if we don't have all the modules ready and need to test a particular module which is ready then we use Stubs and Drivers.
Stubs are used in Integration testing for a [http://en.wikipedia.org/wiki/Top-down_and_bottom-up_design Top Down] Integration testing and Bottom Up Integration Testing.

[[File:Stubs.jpg]]

In the above figure, we can see that the Modules 2 and 3 are not yet implemented. However, if we need to test the modules 4,5 and 6 which are dependent on modules 2 and 3, we can simple use some dummy code in the form of Stubs 1 and 2 in place of the modules that return the values as expected by the modules beneath them. This piece of Dummy code is Called a Stub in a Top Down Integration. Hence Stubs are called Functions in Top Down Integration tests.

==Stubs in different phases of testing==
===Unit Testing===

Unit testing with Stubs:

In developing a huge software if we are following top down approach of development there may be some functionality which may not have been implemented. This can be overcome by implementing all the required functions. However, then we would be testing a huge chunk of code without actually testing it. This will lead to bugs and lot of time will be wasted on debugging. Consider the following example:

Suppose we want to evaluate an expression factorial(x)/( sin(x) + tan(x) ). Assuming that we don't have library support available for calculating factorial,sin and tan of the given input we would have to write those functions. Using stubs we can write functions which would return appropriate values. Thus, assuming that factorial(x) is implemented then we can write stubs for sin and cos functions returning floating point values. We can than verify if our main function gives expected results for those values. This shows us that our main function, factorial are working correct without actually implementing sin and cos functions
<pre>
code:
int main()
{
float y=factorial(x) / (sin(x) + tan(x) );
return 0;
}
int factorial(x)
{

//implmentation of factorial
}

float sin(int x)
{
return 0.5;
}

float cos(int x)
{
return 0.3;
}
</pre>
===Functional Testing===

The idea of stub remains the same in different forms of testing. In unit testing we are dealing with working inside a module and hence we overwrite the dependent implementations by stub. This allows us to test the calling code without the actual implementation. In functional testing we will replace other modules or collaborators of a class. The client class might be interested in some service from some other class ( collaborator class ). However, again instead of implementing the actual class we will have a stub implementation. In ruby the mocha gem provides support for functional test using stubbing. This helps in avoiding overlapping test cases. We can see the use of stubs in functional testing using mocha in ruby in the programming languages section.

===Integration Testing===
Integration testing is a logical extension of unit testing. In its simplest form, two units that have already been tested are combined into a component and the interface between them is tested. A component, in this sense, refers to an integrated aggregate of more than one unit. In a realistic scenario, many units are combined into components, which are in turn aggregated into even larger parts of the program. The idea is to test combinations of pieces and eventually expand the process to test your modules with those of other groups. Eventually all the modules making up a process are tested together. Beyond that, if the program is composed of more than one process, they should be tested in pairs rather than all at once.
Integration testing identifies problems that occur when units are combined. By using a test plan that requires you to test each unit and ensure the viability of each before combining units, you know that any errors discovered when combining units are likely related to the interface between units. This method reduces the number of possibilities to a far simpler level of analysis.
The top-down approach to integration testing requires the highest-level modules be test and integrated first. This allows high-level logic and data flow to be tested early in the process and it tends to minimize the need for drivers. However, the need for stubs complicates test management and low-level utilities are tested relatively late in the development cycle. Another disadvantage of top-down integration testing is its poor support for early release of limited functionality.

===Regression Testing===
Regression testing is any type of software testing that seeks to uncover new software bugs, or regressions, in existing functional and non-functional areas of a system after changes, such as enhancements, patches or configuration changes, have been made to them.
The intent of regression testing is to ensure that a change, such as a bugfix, did not introduce new faults.[1] One of the main reasons for regression testing is to determine whether a change in one part of the software affects other parts of the software.[2]
Common methods of regression testing include rerunning previously run tests and checking whether program behavior has changed and whether previously fixed faults have re-emerged. Regression testing can be used to test a system efficiently by systematically selecting the appropriate minimum set of tests needed to adequately cover a particular change.
In Regression testing the use of test stubs is minimized as most of the system is already implemented and the main goal of the regression test is to see if there are any bugs that might have been ‘regressed’ from the previous stages of integrations. Ideally there will not be unimplemented modules by the time a system is tested for regression. However, in case of mutually exclusive modules of a system, a test stub for one of them can be used to test the regression of the other.

==Stubs in software development==
===Agile Development Methodology===
Agile software development is a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change. It is a conceptual framework that promotes foreseen interactions throughout the development cycle.
In such a development system, it recognizes that testing is not a separate phase, but an integral part of software development, along with coding. Agile testing is a software testing practice that follows the principles of agile software development. Agile testing involves all members of a cross-functional agile team, with special expertise contributed by testers, to ensure delivering the business value desired by the customer at frequent intervals, working at a sustainable pace. Specification by example, also known as acceptance test-driven development, is used to capture examples of desired and undesired behavior and guide coding.
In the agile testing toolkit, a stub is a piece of code that behaves in a predefined way, in order to simplify the testing process. Here are the kind of simplifications that a stub can bring:

* If the code under test never returns the same value (usage of a timestamp or of a random value), a stub can be used to fix the root of the undeterminism.

* If the code depends on some other class that has complex behavior that you don’t want to take into account in this test, using a stub for this other class can simplify its behavior and clarify the intent of the test

* If the code depends on some other code that is not yet written or released, it is possible to start building the rest of the code before the dependency is actually finished.

==Examples of Stubs==
===Java===
In Java, the basic technique is to implement the stub collaborators as concrete classes which only exhibit the small part of the overall behaviour of the collaborator which is needed by the class under test. As an example consider the case where a service implementation is under test. The implementation has a collaborator:

<pre>
public class SimpleService implements Service {
private Collaborator collaborator;
public void setCollaborator(Collaborator collaborator) {
this.collaborator = collaborator;
}

// part of Service interface
public boolean isActive() {
return collaborator.isActive();
}
}
</pre>

We could have a stub collaborator for testing as defined below:

<pre>
public class StubCollaboratorAdapter implements Collaborator {
public boolean isActive() {
return false;
}
}
</pre>

Now, a test case can be written as something like this:

<pre>
public void testActiveWhenCollaboratorIsActive() throws Exception {
Service service = new SimpleService();
service.setCollaborator(new StubCollaboratorAdapter() {
public boolean isActive() {
return true;
}
});
assertTrue(service.isActive());
}
</pre>

===Ruby===
While writing stubs, one might decide to replace a whole object or simply change the results of a single method. When you're replacing a whole object, it's easy—just write the new object and replace it within your test case. Methods might be tougher in some languages, but using dynamic languages such as Ruby, stubbing is easy because you're simply redefining a method.
Imagine you have a user interface that prints a document. You want to test code that handles a print failure. You really don't care if the print method gets called. You just want to verify that if your code does call print, that code will handle a failed print effectively. Think of what a pseudo-code sentence would look like.
On an instance of the document object, stub the print method, returning false.
You can break that sentence down into two parts. The first part identifies what you want to stub. The second part defines what the stub should do.
Below is an example of the Mocha framework that can be used to build stubs in Ruby:
<pre>
class Document
def print
# doesn't matter -- we are stubbing it out
end
end

class View
attr :document

def initialize(document)
@document = document
end

def print()
if document.print
puts "Excellent!"
true
else
puts "Bummer."
false
end
end
end
</pre>
Test code can be written as follows:
<pre>
require 'test/unit'
require 'rubygems'
require 'mocha'
require 'document'

class ViewTest < Test::Unit::TestCase

def test_should_return_false_for_failed_print
document = stub("my document")
document.stubs(:print).returns(false)

ui = View.new(document)
assert_equal false, ui.print
end

end
</pre>
You can see how this works. I build a simple, named stub object with the statement stub("my document"). Then, I define the behavior for print within the stub with the line of code document.stubs(:print).returns(false). If you look carefully, this line of code looks remarkably similar to the pseudo-code from earlier:
On an instance of the document object, stub the print method, returning false.

===Python===

==IDE support for Stubs==
===Eclipse===

Eclipse provides support to create test stub methods to test the methods developed during development. We can create the junit test case on a java class. We can then select the methods in the class which we would like to test. This will automatically create test stubs to test those methods. In the figure below we are testing methods of ArrayList class

[[File:Eclipsestub.png]]

===RubyMine===
The most basic way to create test templates in RubyMine is to use the regular procedure of creating files in the project. This means is both available for both plain Ruby projets, and for the Rails applications, and allows creating stub tests for Test::Unit, RSpec and Test-Spec.

For RSpec and Test-Spec, RubyMine provides a number of generators. These generators are context sensitive and become available depending on the selected location, and on the gems activated for your project. For example, ir rspec-rails is activated, the usual generators are hidden, and the list of generators includes only those specific for RSpec.

===Visual Studio===
Visual Studio is a fine IDE that provides good support for automatically generating stubs for methods. Generate Method Stub is an IntelliSense Automatic Code Generation feature that provides an easy way to have Visual Studio create a new method declaration at the time you are writing a method call. Visual Studio infers the declaration from the call. Some programming styles, such as test-driven development, suggest that you should consume before you define. That way, it is easier to figure out the form of the API that you are developing. You can use IntelliSense to program in that style. Using the Generate Method Stub operation, you avoid defining everything before you consume it.

The Generate Method Stub IntelliSense operation can also increase productivity because you do not need to move from the calling code, your present focus, to the defining code, a separate focus, in order to generate a new method. You can instead write a method call, and then invoke the Generate Method Stub operation without dividing your attention.

==Conclusion==
We need tests that “run fast, and help us localize problems.” This can be hard to accomplish when your code accesses a database, hits another server, is time-dependent, etc. By substituting custom objects such as stubs for some of your module's dependencies, you can thoroughly test your code, increase your coverage, and still run in less than a second. You can even simulate rare scenarios like database failures and test your error handling code. In general, Stubs greatly increase the speed of running unit tests and provide a means of testing code independently.

==References==
*[http://blog.springsource.org/2007/01/15/unit-testing-with-stubs-and-mocks/ Test Stubs and Mocks]
*[http://en.wikipedia.org/wiki/Test_stub Test Stubs on wikipedia]
*[http://www.jetbrains.com/ruby/webhelp/creating-test-templates.pdf Test Stub support in RubyMine]
*[http://googletesting.blogspot.com/2007/04/tott-stubs-speed-up-your-unit-tests.html Advantages of Stubs]
*[http://sqa.fyicenter.com/FAQ/Manual-Testing/What_is_stub_Explain_in_testing_point_of_view_.html Stubs and Testing]
*[http://martinfowler.com/articles/mocksArentStubs.html Mocks aren't Stubs]
*[http://www.captaindebug.com/2011/11/regular-unit-tests-and-stubs-testing.html Testing techniques]
* http://www.ibm.com/developerworks/web/library/wa-mockrails/index.html

CSC/ECE 517 Fall 2012/ch2a 2w13 sm

2012-10-26T23:59:25Z

Svmankar: /* Introduction */

==Introduction==
Test stubs are programs which simulate the behaviors of software components (or [http://en.wikipedia.org/wiki/Modular_programming modules]) on which other modules that are being tested are dependent upon.
Stubs are replacements for missing components that the components being tested will call as part of the test. While doing an [http://en.wikipedia.org/wiki/Integration_testing Integration], if we don't have all the modules ready and need to test a particular module which is ready then we use Stubs and Drivers.
Stubs are used in Integration testing for a [http://en.wikipedia.org/wiki/Top-down_and_bottom-up_design Top Down] Integration testing and Bottom Up Integration Testing.

[[File:Stubs.jpg]]

In the above figure, we can see that the Modules 2 and 3 are not yet implemented. However, if we need to test the modules 4,5 and 6 which are dependent on modules 2 and 3, we can simple use some dummy code in the form of Stubs 1 and 2 in place of the modules that return the values as expected by the modules beneath them. This piece of Dummy code is Called a Stub in a Top Down Integration. Hence Stubs are called Functions in Top Down Integration tests.

==Stubs in different phases of testing==
===Unit Testing===
===Functional Testing===
===Integration Testing===
Integration testing is a logical extension of unit testing. In its simplest form, two units that have already been tested are combined into a component and the interface between them is tested. A component, in this sense, refers to an integrated aggregate of more than one unit. In a realistic scenario, many units are combined into components, which are in turn aggregated into even larger parts of the program. The idea is to test combinations of pieces and eventually expand the process to test your modules with those of other groups. Eventually all the modules making up a process are tested together. Beyond that, if the program is composed of more than one process, they should be tested in pairs rather than all at once.
Integration testing identifies problems that occur when units are combined. By using a test plan that requires you to test each unit and ensure the viability of each before combining units, you know that any errors discovered when combining units are likely related to the interface between units. This method reduces the number of possibilities to a far simpler level of analysis.
The top-down approach to integration testing requires the highest-level modules be test and integrated first. This allows high-level logic and data flow to be tested early in the process and it tends to minimize the need for drivers. However, the need for stubs complicates test management and low-level utilities are tested relatively late in the development cycle. Another disadvantage of top-down integration testing is its poor support for early release of limited functionality.

===Regression Testing===
Regression testing is any type of software testing that seeks to uncover new software bugs, or regressions, in existing functional and non-functional areas of a system after changes, such as enhancements, patches or configuration changes, have been made to them.
The intent of regression testing is to ensure that a change, such as a bugfix, did not introduce new faults.[1] One of the main reasons for regression testing is to determine whether a change in one part of the software affects other parts of the software.[2]
Common methods of regression testing include rerunning previously run tests and checking whether program behavior has changed and whether previously fixed faults have re-emerged. Regression testing can be used to test a system efficiently by systematically selecting the appropriate minimum set of tests needed to adequately cover a particular change.
In Regression testing the use of test stubs is minimized as most of the system is already implemented and the main goal of the regression test is to see if there are any bugs that might have been ‘regressed’ from the previous stages of integrations. Ideally there will not be unimplemented modules by the time a system is tested for regression. However, in case of mutually exclusive modules of a system, a test stub for one of them can be used to test the regression of the other.

==Stubs in software development methodologies==
===Agile Development Methodology===
Agile software development is a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change. It is a conceptual framework that promotes foreseen interactions throughout the development cycle.
In such a development system, it recognizes that testing is not a separate phase, but an integral part of software development, along with coding. Agile testing is a software testing practice that follows the principles of agile software development. Agile testing involves all members of a cross-functional agile team, with special expertise contributed by testers, to ensure delivering the business value desired by the customer at frequent intervals, working at a sustainable pace. Specification by example, also known as acceptance test-driven development, is used to capture examples of desired and undesired behavior and guide coding.
In the agile testing toolkit, a stub is a piece of code that behaves in a predefined way, in order to simplify the testing process. Here are the kind of simplifications that a stub can bring:

* If the code under test never returns the same value (usage of a timestamp or of a random value), a stub can be used to fix the root of the undeterminism.

* If the code depends on some other class that has complex behavior that you don’t want to take into account in this test, using a stub for this other class can simplify its behavior and clarify the intent of the test

* If the code depends on some other code that is not yet written or released, it is possible to start building the rest of the code before the dependency is actually finished.

==Examples of Stubs==
===Java===
In Java, the basic technique is to implement the stub collaborators as concrete classes which only exhibit the small part of the overall behaviour of the collaborator which is needed by the class under test. As an example consider the case where a service implementation is under test. The implementation has a collaborator:

<pre>
public class SimpleService implements Service {
private Collaborator collaborator;
public void setCollaborator(Collaborator collaborator) {
this.collaborator = collaborator;
}

// part of Service interface
public boolean isActive() {
return collaborator.isActive();
}
}
</pre>

We could have a stub collaborator for testing as defined below:

<pre>
public class StubCollaboratorAdapter implements Collaborator {
public boolean isActive() {
return false;
}
}
</pre>

Now, a test case can be written as something like this:

<pre>
public void testActiveWhenCollaboratorIsActive() throws Exception {
Service service = new SimpleService();
service.setCollaborator(new StubCollaboratorAdapter() {
public boolean isActive() {
return true;
}
});
assertTrue(service.isActive());
}
</pre>

===Ruby===
While writing stubs, one might decide to replace a whole object or simply change the results of a single method. When you're replacing a whole object, it's easy—just write the new object and replace it within your test case. Methods might be tougher in some languages, but using dynamic languages such as Ruby, stubbing is easy because you're simply redefining a method.
Imagine you have a user interface that prints a document. You want to test code that handles a print failure. You really don't care if the print method gets called. You just want to verify that if your code does call print, that code will handle a failed print effectively. Think of what a pseudo-code sentence would look like.
On an instance of the document object, stub the print method, returning false.
You can break that sentence down into two parts. The first part identifies what you want to stub. The second part defines what the stub should do.
Below is an example of the Mocha framework that can be used to build stubs in Ruby:
<pre>
class Document
def print
# doesn't matter -- we are stubbing it out
end
end

class View
attr :document

def initialize(document)
@document = document
end

def print()
if document.print
puts "Excellent!"
true
else
puts "Bummer."
false
end
end
end
</pre>
Test code can be written as follows:
<pre>
require 'test/unit'
require 'rubygems'
require 'mocha'
require 'document'

class ViewTest < Test::Unit::TestCase

def test_should_return_false_for_failed_print
document = stub("my document")
document.stubs(:print).returns(false)

ui = View.new(document)
assert_equal false, ui.print
end

end
</pre>
You can see how this works. I build a simple, named stub object with the statement stub("my document"). Then, I define the behavior for print within the stub with the line of code document.stubs(:print).returns(false). If you look carefully, this line of code looks remarkably similar to the pseudo-code from earlier:
On an instance of the document object, stub the print method, returning false.

===Python===

==IDE support for Stubs==
===Eclipse===
===RubyMine===
The most basic way to create test templates in RubyMine is to use the regular procedure of creating files in the project. This means is both available for both plain Ruby projets, and for the Rails applications, and allows creating stub tests for Test::Unit, RSpec and Test-Spec.

For RSpec and Test-Spec, RubyMine provides a number of generators. These generators are context sensitive and become available depending on the selected location, and on the gems activated for your project. For example, ir rspec-rails is activated, the usual generators are hidden, and the list of generators includes only those specific for RSpec.

===Visual Studio===
Visual Studio is a fine IDE that provides good support for automatically generating stubs for methods. Generate Method Stub is an IntelliSense Automatic Code Generation feature that provides an easy way to have Visual Studio create a new method declaration at the time you are writing a method call. Visual Studio infers the declaration from the call. Some programming styles, such as test-driven development, suggest that you should consume before you define. That way, it is easier to figure out the form of the API that you are developing. You can use IntelliSense to program in that style. Using the Generate Method Stub operation, you avoid defining everything before you consume it.

The Generate Method Stub IntelliSense operation can also increase productivity because you do not need to move from the calling code, your present focus, to the defining code, a separate focus, in order to generate a new method. You can instead write a method call, and then invoke the Generate Method Stub operation without dividing your attention.

==Conclusion==
We need tests that “run fast, and help us localize problems.” This can be hard to accomplish when your code accesses a database, hits another server, is time-dependent, etc. By substituting custom objects such as stubs for some of your module's dependencies, you can thoroughly test your code, increase your coverage, and still run in less than a second. You can even simulate rare scenarios like database failures and test your error handling code. In general, Stubs greatly increase the speed of running unit tests and provide a means of testing code independently.

==References==
*[http://blog.springsource.org/2007/01/15/unit-testing-with-stubs-and-mocks/ Test Stubs and Mocks]
*[http://en.wikipedia.org/wiki/Test_stub Test Stubs on wikipedia]
*[http://www.jetbrains.com/ruby/webhelp/creating-test-templates.pdf Test Stub support in RubyMine]
*[http://googletesting.blogspot.com/2007/04/tott-stubs-speed-up-your-unit-tests.html Advantages of Stubs]
*[http://sqa.fyicenter.com/FAQ/Manual-Testing/What_is_stub_Explain_in_testing_point_of_view_.html Stubs and Testing]
*[http://martinfowler.com/articles/mocksArentStubs.html Mocks aren't Stubs]
*[http://www.captaindebug.com/2011/11/regular-unit-tests-and-stubs-testing.html Testing techniques]

CSC/ECE 517 Fall 2012/ch2a 2w13 sm

2012-10-26T23:49:19Z

Svmankar: /* References */

==Introduction==
Test stubs are programs which simulate the behaviors of software components (or modules) that are depended upon modules of the module being tested.
Stubs are replacements for missing components that the components being tested will call as part of the test. While doing an Integration, if we don't have all the modules ready and need to test a particular module which is ready then we use Stubs and Drivers.
Stubs are used in Integration testing for a Top Down Integration testing and Bottom Up Integration Testing.

[[File:Stubs.jpg]]

In the above figure, we can see that the Modules 2 and 3 are not yet implemented. However, if we need to test the modules 4,5 and 6 which are dependent on modules 2 and 3, we can simple use some dummy code in the form of Stubs 1 and 2 in place of the modules that return the values as expected by the modules beneath them. This piece of Dummy code is Called a Stub in a Top Down Integration. Hence Stubs are called Functions in Top Down Integration tests.

==Stubs in different phases of testing==
===Unit Testing===
===Functional Testing===
===Integration Testing===
Integration testing is a logical extension of unit testing. In its simplest form, two units that have already been tested are combined into a component and the interface between them is tested. A component, in this sense, refers to an integrated aggregate of more than one unit. In a realistic scenario, many units are combined into components, which are in turn aggregated into even larger parts of the program. The idea is to test combinations of pieces and eventually expand the process to test your modules with those of other groups. Eventually all the modules making up a process are tested together. Beyond that, if the program is composed of more than one process, they should be tested in pairs rather than all at once.
Integration testing identifies problems that occur when units are combined. By using a test plan that requires you to test each unit and ensure the viability of each before combining units, you know that any errors discovered when combining units are likely related to the interface between units. This method reduces the number of possibilities to a far simpler level of analysis.
The top-down approach to integration testing requires the highest-level modules be test and integrated first. This allows high-level logic and data flow to be tested early in the process and it tends to minimize the need for drivers. However, the need for stubs complicates test management and low-level utilities are tested relatively late in the development cycle. Another disadvantage of top-down integration testing is its poor support for early release of limited functionality.

===Regression Testing===
Regression testing is any type of software testing that seeks to uncover new software bugs, or regressions, in existing functional and non-functional areas of a system after changes, such as enhancements, patches or configuration changes, have been made to them.
The intent of regression testing is to ensure that a change, such as a bugfix, did not introduce new faults.[1] One of the main reasons for regression testing is to determine whether a change in one part of the software affects other parts of the software.[2]
Common methods of regression testing include rerunning previously run tests and checking whether program behavior has changed and whether previously fixed faults have re-emerged. Regression testing can be used to test a system efficiently by systematically selecting the appropriate minimum set of tests needed to adequately cover a particular change.
In Regression testing the use of test stubs is minimized as most of the system is already implemented and the main goal of the regression test is to see if there are any bugs that might have been ‘regressed’ from the previous stages of integrations. Ideally there will not be unimplemented modules by the time a system is tested for regression. However, in case of mutually exclusive modules of a system, a test stub for one of them can be used to test the regression of the other.

==Stubs in software development methodologies==
===Agile Development Methodology===
Agile software development is a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change. It is a conceptual framework that promotes foreseen interactions throughout the development cycle.
In such a development system, it recognizes that testing is not a separate phase, but an integral part of software development, along with coding. Agile testing is a software testing practice that follows the principles of agile software development. Agile testing involves all members of a cross-functional agile team, with special expertise contributed by testers, to ensure delivering the business value desired by the customer at frequent intervals, working at a sustainable pace. Specification by example, also known as acceptance test-driven development, is used to capture examples of desired and undesired behavior and guide coding.
In the agile testing toolkit, a stub is a piece of code that behaves in a predefined way, in order to simplify the testing process. Here are the kind of simplifications that a stub can bring:

* If the code under test never returns the same value (usage of a timestamp or of a random value), a stub can be used to fix the root of the undeterminism.

* If the code depends on some other class that has complex behavior that you don’t want to take into account in this test, using a stub for this other class can simplify its behavior and clarify the intent of the test

* If the code depends on some other code that is not yet written or released, it is possible to start building the rest of the code before the dependency is actually finished.

==Examples of Stubs==
===Java===
In Java, the basic technique is to implement the stub collaborators as concrete classes which only exhibit the small part of the overall behaviour of the collaborator which is needed by the class under test. As an example consider the case where a service implementation is under test. The implementation has a collaborator:

<pre>
public class SimpleService implements Service {
private Collaborator collaborator;
public void setCollaborator(Collaborator collaborator) {
this.collaborator = collaborator;
}

// part of Service interface
public boolean isActive() {
return collaborator.isActive();
}
}
</pre>

We could have a stub collaborator for testing as defined below:

<pre>
public class StubCollaboratorAdapter implements Collaborator {
public boolean isActive() {
return false;
}
}
</pre>

Now, a test case can be written as something like this:

<pre>
public void testActiveWhenCollaboratorIsActive() throws Exception {
Service service = new SimpleService();
service.setCollaborator(new StubCollaboratorAdapter() {
public boolean isActive() {
return true;
}
});
assertTrue(service.isActive());
}
</pre>

===Ruby===
While writing stubs, one might decide to replace a whole object or simply change the results of a single method. When you're replacing a whole object, it's easy—just write the new object and replace it within your test case. Methods might be tougher in some languages, but using dynamic languages such as Ruby, stubbing is easy because you're simply redefining a method.
Imagine you have a user interface that prints a document. You want to test code that handles a print failure. You really don't care if the print method gets called. You just want to verify that if your code does call print, that code will handle a failed print effectively. Think of what a pseudo-code sentence would look like.
On an instance of the document object, stub the print method, returning false.
You can break that sentence down into two parts. The first part identifies what you want to stub. The second part defines what the stub should do.
Below is an example of the Mocha framework that can be used to build stubs in Ruby:
<pre>
class Document
def print
# doesn't matter -- we are stubbing it out
end
end

class View
attr :document

def initialize(document)
@document = document
end

def print()
if document.print
puts "Excellent!"
true
else
puts "Bummer."
false
end
end
end
</pre>
Test code can be written as follows:
<pre>
require 'test/unit'
require 'rubygems'
require 'mocha'
require 'document'

class ViewTest < Test::Unit::TestCase

def test_should_return_false_for_failed_print
document = stub("my document")
document.stubs(:print).returns(false)

ui = View.new(document)
assert_equal false, ui.print
end

end
</pre>
You can see how this works. I build a simple, named stub object with the statement stub("my document"). Then, I define the behavior for print within the stub with the line of code document.stubs(:print).returns(false). If you look carefully, this line of code looks remarkably similar to the pseudo-code from earlier:
On an instance of the document object, stub the print method, returning false.

===Python===

==IDE support for Stubs==
===Eclipse===
===RubyMine===
The most basic way to create test templates in RubyMine is to use the regular procedure of creating files in the project. This means is both available for both plain Ruby projets, and for the Rails applications, and allows creating stub tests for Test::Unit, RSpec and Test-Spec.

For RSpec and Test-Spec, RubyMine provides a number of generators. These generators are context sensitive and become available depending on the selected location, and on the gems activated for your project. For example, ir rspec-rails is activated, the usual generators are hidden, and the list of generators includes only those specific for RSpec.

===Visual Studio===
Visual Studio is a fine IDE that provides good support for automatically generating stubs for methods. Generate Method Stub is an IntelliSense Automatic Code Generation feature that provides an easy way to have Visual Studio create a new method declaration at the time you are writing a method call. Visual Studio infers the declaration from the call. Some programming styles, such as test-driven development, suggest that you should consume before you define. That way, it is easier to figure out the form of the API that you are developing. You can use IntelliSense to program in that style. Using the Generate Method Stub operation, you avoid defining everything before you consume it.

The Generate Method Stub IntelliSense operation can also increase productivity because you do not need to move from the calling code, your present focus, to the defining code, a separate focus, in order to generate a new method. You can instead write a method call, and then invoke the Generate Method Stub operation without dividing your attention.

==Conclusion==
We need tests that “run fast, and help us localize problems.” This can be hard to accomplish when your code accesses a database, hits another server, is time-dependent, etc. By substituting custom objects such as stubs for some of your module's dependencies, you can thoroughly test your code, increase your coverage, and still run in less than a second. You can even simulate rare scenarios like database failures and test your error handling code. In general, Stubs greatly increase the speed of running unit tests and provide a means of testing code independently.

==References==
*[http://blog.springsource.org/2007/01/15/unit-testing-with-stubs-and-mocks/ Test Stubs and Mocks]
*[http://en.wikipedia.org/wiki/Test_stub Test Stubs on wikipedia]
*[http://www.jetbrains.com/ruby/webhelp/creating-test-templates.pdf Test Stub support in RubyMine]
*[http://googletesting.blogspot.com/2007/04/tott-stubs-speed-up-your-unit-tests.html Advantages of Stubs]
*[http://sqa.fyicenter.com/FAQ/Manual-Testing/What_is_stub_Explain_in_testing_point_of_view_.html Stubs and Testing]
*[http://martinfowler.com/articles/mocksArentStubs.html Mocks aren't Stubs]
*[http://www.captaindebug.com/2011/11/regular-unit-tests-and-stubs-testing.html Testing techniques]

CSC/ECE 517 Fall 2012/ch2a 2w13 sm

2012-10-26T23:22:43Z

Svmankar: /* Introduction */

CSC/ECE 517 Fall 2012/ch2a 2w13 sm

2012-10-26T23:18:06Z

Svmankar: /* Introduction */

==Introduction==
Test stubs are programs which simulate the behaviors of software components (or modules) that are depended upon modules of the module being tested.
Stubs are replacements for missing components that the components being tested will call as part of the test. While doing an Integration , If we dont have all the modules get ready and Need to test a particualr module which is ready then We Use Stubs and Drivers.
Stubs are used in Integration testing for a Top Down Integration testing and Botton Up Integration Testing.
For example, if we have Modules x,y,z . X module is ready and Need to Test it , But it calls functions from y and z.(Which are not ready)To test this particular module we can write a Small Dummy piece of code which Simulates Y and Z Which will return values that X expects. This piece of Dummy code is Called a Stub in a Top Down Integration
So Stubs are called Functions in Top Down Integration.

[[File:Stubs.jpg]]

In the above figure, we can see that the Modules 2 and 3 are not yet implemented. However, if we need to test the modules 4,5 and 6 which are dependent on modules 2 and 3, we can simple use Stubs 1 and 2 in place of the modules that return the values as expected by the modules beneath them.

==Stubs in different phases of testing==
===Unit Testing===
===Functional Testing===
===Integration Testing===
Integration testing is a logical extension of unit testing. In its simplest form, two units that have already been tested are combined into a component and the interface between them is tested. A component, in this sense, refers to an integrated aggregate of more than one unit. In a realistic scenario, many units are combined into components, which are in turn aggregated into even larger parts of the program. The idea is to test combinations of pieces and eventually expand the process to test your modules with those of other groups. Eventually all the modules making up a process are tested together. Beyond that, if the program is composed of more than one process, they should be tested in pairs rather than all at once.
Integration testing identifies problems that occur when units are combined. By using a test plan that requires you to test each unit and ensure the viability of each before combining units, you know that any errors discovered when combining units are likely related to the interface between units. This method reduces the number of possibilities to a far simpler level of analysis.
The top-down approach to integration testing requires the highest-level modules be test and integrated first. This allows high-level logic and data flow to be tested early in the process and it tends to minimize the need for drivers. However, the need for stubs complicates test management and low-level utilities are tested relatively late in the development cycle. Another disadvantage of top-down integration testing is its poor support for early release of limited functionality.

===Regression Testing===
Regression testing is any type of software testing that seeks to uncover new software bugs, or regressions, in existing functional and non-functional areas of a system after changes, such as enhancements, patches or configuration changes, have been made to them.
The intent of regression testing is to ensure that a change, such as a bugfix, did not introduce new faults.[1] One of the main reasons for regression testing is to determine whether a change in one part of the software affects other parts of the software.[2]
Common methods of regression testing include rerunning previously run tests and checking whether program behavior has changed and whether previously fixed faults have re-emerged. Regression testing can be used to test a system efficiently by systematically selecting the appropriate minimum set of tests needed to adequately cover a particular change.
In Regression testing the use of test stubs is minimized as most of the system is already implemented and the main goal of the regression test is to see if there are any bugs that might have been ‘regressed’ from the previous stages of integrations. Ideally there will not be unimplemented modules by the time a system is tested for regression. However, in case of mutually exclusive modules of a system, a test stub for one of them can be used to test the regression of the other.

==Stubs in software development methodologies==
===Agile Development Methodology===
Agile software development is a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change. It is a conceptual framework that promotes foreseen interactions throughout the development cycle.
In such a development system, it recognizes that testing is not a separate phase, but an integral part of software development, along with coding. Agile testing is a software testing practice that follows the principles of agile software development. Agile testing involves all members of a cross-functional agile team, with special expertise contributed by testers, to ensure delivering the business value desired by the customer at frequent intervals, working at a sustainable pace. Specification by example, also known as acceptance test-driven development, is used to capture examples of desired and undesired behavior and guide coding.
In the agile testing toolkit, a stub is a piece of code that behaves in a predefined way, in order to simplify the testing process. Here are the kind of simplifications that a stub can bring:

* If the code under test never returns the same value (usage of a timestamp or of a random value), a stub can be used to fix the root of the undeterminism.

* If the code depends on some other class that has complex behavior that you don’t want to take into account in this test, using a stub for this other class can simplify its behavior and clarify the intent of the test

* If the code depends on some other code that is not yet written or released, it is possible to start building the rest of the code before the dependency is actually finished.

==Examples of Stubs==
===Java===
In Java, the basic technique is to implement the stub collaborators as concrete classes which only exhibit the small part of the overall behaviour of the collaborator which is needed by the class under test. As an example consider the case where a service implementation is under test. The implementation has a collaborator:

<pre>
public class SimpleService implements Service {
private Collaborator collaborator;
public void setCollaborator(Collaborator collaborator) {
this.collaborator = collaborator;
}

// part of Service interface
public boolean isActive() {
return collaborator.isActive();
}
}
</pre>

We could have a stub collaborator for testing as defined below:

<pre>
public class StubCollaboratorAdapter implements Collaborator {
public boolean isActive() {
return false;
}
}
</pre>

Now, a test case can be written as something like this:

<pre>
public void testActiveWhenCollaboratorIsActive() throws Exception {
Service service = new SimpleService();
service.setCollaborator(new StubCollaboratorAdapter() {
public boolean isActive() {
return true;
}
});
assertTrue(service.isActive());
}
</pre>

===Ruby===
While writing stubs, one might decide to replace a whole object or simply change the results of a single method. When you're replacing a whole object, it's easy—just write the new object and replace it within your test case. Methods might be tougher in some languages, but using dynamic languages such as Ruby, stubbing is easy because you're simply redefining a method.
Imagine you have a user interface that prints a document. You want to test code that handles a print failure. You really don't care if the print method gets called. You just want to verify that if your code does call print, that code will handle a failed print effectively. Think of what a pseudo-code sentence would look like.
On an instance of the document object, stub the print method, returning false.
You can break that sentence down into two parts. The first part identifies what you want to stub. The second part defines what the stub should do.
Below is an example of the Mocha framework that can be used to build stubs in Ruby:
<pre>
class Document
def print
# doesn't matter -- we are stubbing it out
end
end

class View
attr :document

def initialize(document)
@document = document
end

def print()
if document.print
puts "Excellent!"
true
else
puts "Bummer."
false
end
end
end
</pre>
Test code can be written as follows:
<pre>
require 'test/unit'
require 'rubygems'
require 'mocha'
require 'document'

class ViewTest < Test::Unit::TestCase

def test_should_return_false_for_failed_print
document = stub("my document")
document.stubs(:print).returns(false)

ui = View.new(document)
assert_equal false, ui.print
end

end
</pre>
You can see how this works. I build a simple, named stub object with the statement stub("my document"). Then, I define the behavior for print within the stub with the line of code document.stubs(:print).returns(false). If you look carefully, this line of code looks remarkably similar to the pseudo-code from earlier:
On an instance of the document object, stub the print method, returning false.

===Python===

==IDE support for Stubs==
===Eclipse===
===RubyMine===
The most basic way to create test templates in RubyMine is to use the regular procedure of creating files in the project. This means is both available for both plain Ruby projets, and for the Rails applications, and allows creating stub tests for Test::Unit, RSpec and Test-Spec.

For RSpec and Test-Spec, RubyMine provides a number of generators. These generators are context sensitive and become available depending on the selected location, and on the gems activated for your project. For example, ir rspec-rails is activated, the usual generators are hidden, and the list of generators includes only those specific for RSpec.

===Visual Studio===
Visual Studio is a fine IDE that provides good support for automatically generating stubs for methods. Generate Method Stub is an IntelliSense Automatic Code Generation feature that provides an easy way to have Visual Studio create a new method declaration at the time you are writing a method call. Visual Studio infers the declaration from the call. Some programming styles, such as test-driven development, suggest that you should consume before you define. That way, it is easier to figure out the form of the API that you are developing. You can use IntelliSense to program in that style. Using the Generate Method Stub operation, you avoid defining everything before you consume it.

The Generate Method Stub IntelliSense operation can also increase productivity because you do not need to move from the calling code, your present focus, to the defining code, a separate focus, in order to generate a new method. You can instead write a method call, and then invoke the Generate Method Stub operation without dividing your attention.

==Conclusion==
We need tests that “run fast, and help us localize problems.” This can be hard to accomplish when your code accesses a database, hits another server, is time-dependent, etc. By substituting custom objects such as stubs for some of your module's dependencies, you can thoroughly test your code, increase your coverage, and still run in less than a second. You can even simulate rare scenarios like database failures and test your error handling code. In general, Stubs greatly increase the speed of running unit tests and provide a means of testing code independently.

==References==

File:Stubs.jpg

2012-10-26T23:15:09Z

Svmankar:

CSC/ECE 517 Fall 2012/ch2a 2w13 sm

2012-10-26T23:00:20Z

Svmankar: /* Conclusion */

==Introduction==
Test stubs are programs which simulate the behaviors of software components (or modules) that are depended upon modules of the module being tested.
Stubs are replacements for missing components that the components being tested will call as part of the test. While doing an Integration , If we dont have all the modules get ready and Need to test a particualr module which is ready then We Use Stubs and Drivers.
Stubs are used in Integration testing for a Top Down Integration testing and Botton Up Integration Testing.
For example, if we have Modules x,y,z . X module is ready and Need to Test it , But it calls functions from y and z.(Which are not ready)To test this particular module we can write a Small Dummy piece of code which Simulates Y and Z Which will return values that X expects. This piece of Dummy code is Called a Stub in a Top Down Integration
So Stubs are called Functions in Top Down Integration.

==Stubs in different phases of testing==
===Unit Testing===
===Functional Testing===
===Integration Testing===
Integration testing is a logical extension of unit testing. In its simplest form, two units that have already been tested are combined into a component and the interface between them is tested. A component, in this sense, refers to an integrated aggregate of more than one unit. In a realistic scenario, many units are combined into components, which are in turn aggregated into even larger parts of the program. The idea is to test combinations of pieces and eventually expand the process to test your modules with those of other groups. Eventually all the modules making up a process are tested together. Beyond that, if the program is composed of more than one process, they should be tested in pairs rather than all at once.
Integration testing identifies problems that occur when units are combined. By using a test plan that requires you to test each unit and ensure the viability of each before combining units, you know that any errors discovered when combining units are likely related to the interface between units. This method reduces the number of possibilities to a far simpler level of analysis.
The top-down approach to integration testing requires the highest-level modules be test and integrated first. This allows high-level logic and data flow to be tested early in the process and it tends to minimize the need for drivers. However, the need for stubs complicates test management and low-level utilities are tested relatively late in the development cycle. Another disadvantage of top-down integration testing is its poor support for early release of limited functionality.

===Regression Testing===
Regression testing is any type of software testing that seeks to uncover new software bugs, or regressions, in existing functional and non-functional areas of a system after changes, such as enhancements, patches or configuration changes, have been made to them.
The intent of regression testing is to ensure that a change, such as a bugfix, did not introduce new faults.[1] One of the main reasons for regression testing is to determine whether a change in one part of the software affects other parts of the software.[2]
Common methods of regression testing include rerunning previously run tests and checking whether program behavior has changed and whether previously fixed faults have re-emerged. Regression testing can be used to test a system efficiently by systematically selecting the appropriate minimum set of tests needed to adequately cover a particular change.
In Regression testing the use of test stubs is minimized as most of the system is already implemented and the main goal of the regression test is to see if there are any bugs that might have been ‘regressed’ from the previous stages of integrations. Ideally there will not be unimplemented modules by the time a system is tested for regression. However, in case of mutually exclusive modules of a system, a test stub for one of them can be used to test the regression of the other.

==Stubs in software development methodologies==
===Agile Development Methodology===
Agile software development is a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change. It is a conceptual framework that promotes foreseen interactions throughout the development cycle.
In such a development system, it recognizes that testing is not a separate phase, but an integral part of software development, along with coding. Agile testing is a software testing practice that follows the principles of agile software development. Agile testing involves all members of a cross-functional agile team, with special expertise contributed by testers, to ensure delivering the business value desired by the customer at frequent intervals, working at a sustainable pace. Specification by example, also known as acceptance test-driven development, is used to capture examples of desired and undesired behavior and guide coding.
In the agile testing toolkit, a stub is a piece of code that behaves in a predefined way, in order to simplify the testing process. Here are the kind of simplifications that a stub can bring:

* If the code under test never returns the same value (usage of a timestamp or of a random value), a stub can be used to fix the root of the undeterminism.

* If the code depends on some other class that has complex behavior that you don’t want to take into account in this test, using a stub for this other class can simplify its behavior and clarify the intent of the test

* If the code depends on some other code that is not yet written or released, it is possible to start building the rest of the code before the dependency is actually finished.

==Examples of Stubs==
===Java===
In Java, the basic technique is to implement the stub collaborators as concrete classes which only exhibit the small part of the overall behaviour of the collaborator which is needed by the class under test. As an example consider the case where a service implementation is under test. The implementation has a collaborator:

<pre>
public class SimpleService implements Service {
private Collaborator collaborator;
public void setCollaborator(Collaborator collaborator) {
this.collaborator = collaborator;
}

// part of Service interface
public boolean isActive() {
return collaborator.isActive();
}
}
</pre>

We could have a stub collaborator for testing as defined below:

<pre>
public class StubCollaboratorAdapter implements Collaborator {
public boolean isActive() {
return false;
}
}
</pre>

Now, a test case can be written as something like this:

<pre>
public void testActiveWhenCollaboratorIsActive() throws Exception {
Service service = new SimpleService();
service.setCollaborator(new StubCollaboratorAdapter() {
public boolean isActive() {
return true;
}
});
assertTrue(service.isActive());
}
</pre>

===Ruby===
While writing stubs, one might decide to replace a whole object or simply change the results of a single method. When you're replacing a whole object, it's easy—just write the new object and replace it within your test case. Methods might be tougher in some languages, but using dynamic languages such as Ruby, stubbing is easy because you're simply redefining a method.
Imagine you have a user interface that prints a document. You want to test code that handles a print failure. You really don't care if the print method gets called. You just want to verify that if your code does call print, that code will handle a failed print effectively. Think of what a pseudo-code sentence would look like.
On an instance of the document object, stub the print method, returning false.
You can break that sentence down into two parts. The first part identifies what you want to stub. The second part defines what the stub should do.
Below is an example of the Mocha framework that can be used to build stubs in Ruby:
<pre>
class Document
def print
# doesn't matter -- we are stubbing it out
end
end

class View
attr :document

def initialize(document)
@document = document
end

def print()
if document.print
puts "Excellent!"
true
else
puts "Bummer."
false
end
end
end
</pre>
Test code can be written as follows:
<pre>
require 'test/unit'
require 'rubygems'
require 'mocha'
require 'document'

class ViewTest < Test::Unit::TestCase

def test_should_return_false_for_failed_print
document = stub("my document")
document.stubs(:print).returns(false)

ui = View.new(document)
assert_equal false, ui.print
end

end
</pre>
You can see how this works. I build a simple, named stub object with the statement stub("my document"). Then, I define the behavior for print within the stub with the line of code document.stubs(:print).returns(false). If you look carefully, this line of code looks remarkably similar to the pseudo-code from earlier:
On an instance of the document object, stub the print method, returning false.

===Python===

==IDE support for Stubs==
===Eclipse===
===RubyMine===
The most basic way to create test templates in RubyMine is to use the regular procedure of creating files in the project. This means is both available for both plain Ruby projets, and for the Rails applications, and allows creating stub tests for Test::Unit, RSpec and Test-Spec.

For RSpec and Test-Spec, RubyMine provides a number of generators. These generators are context sensitive and become available depending on the selected location, and on the gems activated for your project. For example, ir rspec-rails is activated, the usual generators are hidden, and the list of generators includes only those specific for RSpec.

===Visual Studio===
Visual Studio is a fine IDE that provides good support for automatically generating stubs for methods. Generate Method Stub is an IntelliSense Automatic Code Generation feature that provides an easy way to have Visual Studio create a new method declaration at the time you are writing a method call. Visual Studio infers the declaration from the call. Some programming styles, such as test-driven development, suggest that you should consume before you define. That way, it is easier to figure out the form of the API that you are developing. You can use IntelliSense to program in that style. Using the Generate Method Stub operation, you avoid defining everything before you consume it.

The Generate Method Stub IntelliSense operation can also increase productivity because you do not need to move from the calling code, your present focus, to the defining code, a separate focus, in order to generate a new method. You can instead write a method call, and then invoke the Generate Method Stub operation without dividing your attention.

==Conclusion==
We need tests that “run fast, and help us localize problems.” This can be hard to accomplish when your code accesses a database, hits another server, is time-dependent, etc. By substituting custom objects such as stubs for some of your module's dependencies, you can thoroughly test your code, increase your coverage, and still run in less than a second. You can even simulate rare scenarios like database failures and test your error handling code. In general, Stubs greatly increase the speed of running unit tests and provide a means of testing code independently.

==References==

CSC/ECE 517 Fall 2012/ch2a 2w13 sm

2012-10-26T22:25:04Z

Svmankar:

==Introduction==
Test stubs are programs which simulate the behaviors of software components (or modules) that are depended upon modules of the module being tested.
Stubs are replacements for missing components that the components being tested will call as part of the test. While doing an Integration , If we dont have all the modules get ready and Need to test a particualr module which is ready then We Use Stubs and Drivers.
Stubs are used in Integration testing for a Top Down Integration testing and Botton Up Integration Testing.
For example, if we have Modules x,y,z . X module is ready and Need to Test it , But it calls functions from y and z.(Which are not ready)To test this particular module we can write a Small Dummy piece of code which Simulates Y and Z Which will return values that X expects. This piece of Dummy code is Called a Stub in a Top Down Integration
So Stubs are called Functions in Top Down Integration.

==Stubs in different phases of testing==
===Unit Testing===
===Functional Testing===
===Integration Testing===
Integration testing is a logical extension of unit testing. In its simplest form, two units that have already been tested are combined into a component and the interface between them is tested. A component, in this sense, refers to an integrated aggregate of more than one unit. In a realistic scenario, many units are combined into components, which are in turn aggregated into even larger parts of the program. The idea is to test combinations of pieces and eventually expand the process to test your modules with those of other groups. Eventually all the modules making up a process are tested together. Beyond that, if the program is composed of more than one process, they should be tested in pairs rather than all at once.
Integration testing identifies problems that occur when units are combined. By using a test plan that requires you to test each unit and ensure the viability of each before combining units, you know that any errors discovered when combining units are likely related to the interface between units. This method reduces the number of possibilities to a far simpler level of analysis.
The top-down approach to integration testing requires the highest-level modules be test and integrated first. This allows high-level logic and data flow to be tested early in the process and it tends to minimize the need for drivers. However, the need for stubs complicates test management and low-level utilities are tested relatively late in the development cycle. Another disadvantage of top-down integration testing is its poor support for early release of limited functionality.

===Regression Testing===
Regression testing is any type of software testing that seeks to uncover new software bugs, or regressions, in existing functional and non-functional areas of a system after changes, such as enhancements, patches or configuration changes, have been made to them.
The intent of regression testing is to ensure that a change, such as a bugfix, did not introduce new faults.[1] One of the main reasons for regression testing is to determine whether a change in one part of the software affects other parts of the software.[2]
Common methods of regression testing include rerunning previously run tests and checking whether program behavior has changed and whether previously fixed faults have re-emerged. Regression testing can be used to test a system efficiently by systematically selecting the appropriate minimum set of tests needed to adequately cover a particular change.
In Regression testing the use of test stubs is minimized as most of the system is already implemented and the main goal of the regression test is to see if there are any bugs that might have been ‘regressed’ from the previous stages of integrations. Ideally there will not be unimplemented modules by the time a system is tested for regression. However, in case of mutually exclusive modules of a system, a test stub for one of them can be used to test the regression of the other.

==Stubs in software development methodologies==
===Agile Development Methodology===
Agile software development is a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change. It is a conceptual framework that promotes foreseen interactions throughout the development cycle.
In such a development system, it recognizes that testing is not a separate phase, but an integral part of software development, along with coding. Agile testing is a software testing practice that follows the principles of agile software development. Agile testing involves all members of a cross-functional agile team, with special expertise contributed by testers, to ensure delivering the business value desired by the customer at frequent intervals, working at a sustainable pace. Specification by example, also known as acceptance test-driven development, is used to capture examples of desired and undesired behavior and guide coding.
In the agile testing toolkit, a stub is a piece of code that behaves in a predefined way, in order to simplify the testing process. Here are the kind of simplifications that a stub can bring:

* If the code under test never returns the same value (usage of a timestamp or of a random value), a stub can be used to fix the root of the undeterminism.

* If the code depends on some other class that has complex behavior that you don’t want to take into account in this test, using a stub for this other class can simplify its behavior and clarify the intent of the test

* If the code depends on some other code that is not yet written or released, it is possible to start building the rest of the code before the dependency is actually finished.

==Examples of Stubs==
===Java===
In Java, the basic technique is to implement the stub collaborators as concrete classes which only exhibit the small part of the overall behaviour of the collaborator which is needed by the class under test. As an example consider the case where a service implementation is under test. The implementation has a collaborator:

<pre>
public class SimpleService implements Service {
private Collaborator collaborator;
public void setCollaborator(Collaborator collaborator) {
this.collaborator = collaborator;
}

// part of Service interface
public boolean isActive() {
return collaborator.isActive();
}
}
</pre>

We could have a stub collaborator for testing as defined below:

<pre>
public class StubCollaboratorAdapter implements Collaborator {
public boolean isActive() {
return false;
}
}
</pre>

Now, a test case can be written as something like this:

<pre>
public void testActiveWhenCollaboratorIsActive() throws Exception {
Service service = new SimpleService();
service.setCollaborator(new StubCollaboratorAdapter() {
public boolean isActive() {
return true;
}
});
assertTrue(service.isActive());
}
</pre>

===Ruby===
While writing stubs, one might decide to replace a whole object or simply change the results of a single method. When you're replacing a whole object, it's easy—just write the new object and replace it within your test case. Methods might be tougher in some languages, but using dynamic languages such as Ruby, stubbing is easy because you're simply redefining a method.
Imagine you have a user interface that prints a document. You want to test code that handles a print failure. You really don't care if the print method gets called. You just want to verify that if your code does call print, that code will handle a failed print effectively. Think of what a pseudo-code sentence would look like.
On an instance of the document object, stub the print method, returning false.
You can break that sentence down into two parts. The first part identifies what you want to stub. The second part defines what the stub should do.
Below is an example of the Mocha framework that can be used to build stubs in Ruby:
<pre>
class Document
def print
# doesn't matter -- we are stubbing it out
end
end

class View
attr :document

def initialize(document)
@document = document
end

def print()
if document.print
puts "Excellent!"
true
else
puts "Bummer."
false
end
end
end
</pre>
Test code can be written as follows:
<pre>
require 'test/unit'
require 'rubygems'
require 'mocha'
require 'document'

class ViewTest < Test::Unit::TestCase

def test_should_return_false_for_failed_print
document = stub("my document")
document.stubs(:print).returns(false)

ui = View.new(document)
assert_equal false, ui.print
end

end
</pre>
You can see how this works. I build a simple, named stub object with the statement stub("my document"). Then, I define the behavior for print within the stub with the line of code document.stubs(:print).returns(false). If you look carefully, this line of code looks remarkably similar to the pseudo-code from earlier:
On an instance of the document object, stub the print method, returning false.

===Python===

==IDE support for Stubs==
===Eclipse===
===RubyMine===
The most basic way to create test templates in RubyMine is to use the regular procedure of creating files in the project. This means is both available for both plain Ruby projets, and for the Rails applications, and allows creating stub tests for Test::Unit, RSpec and Test-Spec.

For RSpec and Test-Spec, RubyMine provides a number of generators. These generators are context sensitive and become available depending on the selected location, and on the gems activated for your project. For example, ir rspec-rails is activated, the usual generators are hidden, and the list of generators includes only those specific for RSpec.

===Visual Studio===
Visual Studio is a fine IDE that provides good support for automatically generating stubs for methods. Generate Method Stub is an IntelliSense Automatic Code Generation feature that provides an easy way to have Visual Studio create a new method declaration at the time you are writing a method call. Visual Studio infers the declaration from the call. Some programming styles, such as test-driven development, suggest that you should consume before you define. That way, it is easier to figure out the form of the API that you are developing. You can use IntelliSense to program in that style. Using the Generate Method Stub operation, you avoid defining everything before you consume it.

The Generate Method Stub IntelliSense operation can also increase productivity because you do not need to move from the calling code, your present focus, to the defining code, a separate focus, in order to generate a new method. You can instead write a method call, and then invoke the Generate Method Stub operation without dividing your attention.

==Conclusion==

==References==

CSC/ECE 517 Fall 2012/ch2a 2w13 sm

2012-10-26T22:24:33Z

Svmankar: /* Introduction */

==Introduction==
Test stubs are programs which simulate the behaviors of software components (or modules) that are depended upon modules of the module being tested.
Stubs are replacements for missing components that the components being tested will call as part of the test. While doing an Integration , If we dont have all the modules get ready and Need to test a particualr module which is ready then We Use Stubs and Drivers.
Stubs are used in Integration testing for a Top Down Integration testing and Botton Up Integration Testing.
For example, if we have Modules x,y,z . X module is ready and Need to Test it , But it calls functions from y and z.(Which are not ready)To test this particular module we can write a Small Dummy piece of code which Simulates Y and Z Which will return values that X expects. This piece of Dummy code is Called a Stub in a Top Down Integration
So Stubs are called Functions in Top Down Integration.

==Stubs in different phases of testing==
===Unit Testing===
===Functional Testing===
===Integration Testing===
Integration testing is a logical extension of unit testing. In its simplest form, two units that have already been tested are combined into a component and the interface between them is tested. A component, in this sense, refers to an integrated aggregate of more than one unit. In a realistic scenario, many units are combined into components, which are in turn aggregated into even larger parts of the program. The idea is to test combinations of pieces and eventually expand the process to test your modules with those of other groups. Eventually all the modules making up a process are tested together. Beyond that, if the program is composed of more than one process, they should be tested in pairs rather than all at once.
Integration testing identifies problems that occur when units are combined. By using a test plan that requires you to test each unit and ensure the viability of each before combining units, you know that any errors discovered when combining units are likely related to the interface between units. This method reduces the number of possibilities to a far simpler level of analysis.
The top-down approach to integration testing requires the highest-level modules be test and integrated first. This allows high-level logic and data flow to be tested early in the process and it tends to minimize the need for drivers. However, the need for stubs complicates test management and low-level utilities are tested relatively late in the development cycle. Another disadvantage of top-down integration testing is its poor support for early release of limited functionality.

===Regression Testing===
Regression testing is any type of software testing that seeks to uncover new software bugs, or regressions, in existing functional and non-functional areas of a system after changes, such as enhancements, patches or configuration changes, have been made to them.
The intent of regression testing is to ensure that a change, such as a bugfix, did not introduce new faults.[1] One of the main reasons for regression testing is to determine whether a change in one part of the software affects other parts of the software.[2]
Common methods of regression testing include rerunning previously run tests and checking whether program behavior has changed and whether previously fixed faults have re-emerged. Regression testing can be used to test a system efficiently by systematically selecting the appropriate minimum set of tests needed to adequately cover a particular change.
In Regression testing the use of test stubs is minimized as most of the system is already implemented and the main goal of the regression test is to see if there are any bugs that might have been ‘regressed’ from the previous stages of integrations. Ideally there will not be unimplemented modules by the time a system is tested for regression. However, in case of mutually exclusive modules of a system, a test stub for one of them can be used to test the regression of the other.

==Stubs in software development methodologies==
===Agile Development Methodology===
Agile software development is a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change. It is a conceptual framework that promotes foreseen interactions throughout the development cycle.
In such a development system, it recognizes that testing is not a separate phase, but an integral part of software development, along with coding. Agile testing is a software testing practice that follows the principles of agile software development. Agile testing involves all members of a cross-functional agile team, with special expertise contributed by testers, to ensure delivering the business value desired by the customer at frequent intervals, working at a sustainable pace. Specification by example, also known as acceptance test-driven development, is used to capture examples of desired and undesired behavior and guide coding.
In the agile testing toolkit, a stub is a piece of code that behaves in a predefined way, in order to simplify the testing process. Here are the kind of simplifications that a stub can bring:

* If the code under test never returns the same value (usage of a timestamp or of a random value), a stub can be used to fix the root of the undeterminism.

* If the code depends on some other class that has complex behavior that you don’t want to take into account in this test, using a stub for this other class can simplify its behavior and clarify the intent of the test

* If the code depends on some other code that is not yet written or released, it is possible to start building the rest of the code before the dependency is actually finished.

==Examples of Stubs==
===Java===
In Java, the basic technique is to implement the stub collaborators as concrete classes which only exhibit the small part of the overall behaviour of the collaborator which is needed by the class under test. As an example consider the case where a service implementation is under test. The implementation has a collaborator:

<pre>
public class SimpleService implements Service {
private Collaborator collaborator;
public void setCollaborator(Collaborator collaborator) {
this.collaborator = collaborator;
}

// part of Service interface
public boolean isActive() {
return collaborator.isActive();
}
}
</pre>

We could have a stub collaborator for testing as defined below:

<pre>
public class StubCollaboratorAdapter implements Collaborator {
public boolean isActive() {
return false;
}
}
</pre>

Now, a test case can be written as something like this:

<pre>
public void testActiveWhenCollaboratorIsActive() throws Exception {
Service service = new SimpleService();
service.setCollaborator(new StubCollaboratorAdapter() {
public boolean isActive() {
return true;
}
});
assertTrue(service.isActive());
}
</pre>

===Ruby===
While writing stubs, one might decide to replace a whole object or simply change the results of a single method. When you're replacing a whole object, it's easy—just write the new object and replace it within your test case. Methods might be tougher in some languages, but using dynamic languages such as Ruby, stubbing is easy because you're simply redefining a method.
Imagine you have a user interface that prints a document. You want to test code that handles a print failure. You really don't care if the print method gets called. You just want to verify that if your code does call print, that code will handle a failed print effectively. Think of what a pseudo-code sentence would look like.
On an instance of the document object, stub the print method, returning false.
You can break that sentence down into two parts. The first part identifies what you want to stub. The second part defines what the stub should do.
Below is an example of the Mocha framework that can be used to build stubs in Ruby:
<pre>
class Document
def print
# doesn't matter -- we are stubbing it out
end
end

class View
attr :document

def initialize(document)
@document = document
end

def print()
if document.print
puts "Excellent!"
true
else
puts "Bummer."
false
end
end
end
</pre>
Test code can be written as follows:
<pre>
require 'test/unit'
require 'rubygems'
require 'mocha'
require 'document'

class ViewTest < Test::Unit::TestCase

def test_should_return_false_for_failed_print
document = stub("my document")
document.stubs(:print).returns(false)

ui = View.new(document)
assert_equal false, ui.print
end

end
</pre>
You can see how this works. I build a simple, named stub object with the statement stub("my document"). Then, I define the behavior for print within the stub with the line of code document.stubs(:print).returns(false). If you look carefully, this line of code looks remarkably similar to the pseudo-code from earlier:
On an instance of the document object, stub the print method, returning false.

===Python===

==IDE support for Stubs==
===Eclipse===
===RubyMine===
The most basic way to create test templates in RubyMine is to use the regular procedure of creating files in the project. This means is both available for both plain Ruby projets, and for the Rails applications, and allows creating stub tests for Test::Unit, RSpec and Test-Spec.

For RSpec and Test-Spec, RubyMine provides a number of generators. These generators are context sensitive and become available depending on the selected location, and on the gems activated for your project. For example, ir rspec-rails is activated, the usual generators are hidden, and the list of generators includes only those specific for RSpec.

===Visual Studio===
Visual Studio is a fine IDE that provides good support for automatically generating stubs for methods. Generate Method Stub is an IntelliSense Automatic Code Generation feature that provides an easy way to have Visual Studio create a new method declaration at the time you are writing a method call. Visual Studio infers the declaration from the call. Some programming styles, such as test-driven development, suggest that you should consume before you define. That way, it is easier to figure out the form of the API that you are developing. You can use IntelliSense to program in that style. Using the Generate Method Stub operation, you avoid defining everything before you consume it.

The Generate Method Stub IntelliSense operation can also increase productivity because you do not need to move from the calling code, your present focus, to the defining code, a separate focus, in order to generate a new method. You can instead write a method call, and then invoke the Generate Method Stub operation without dividing your attention.

==Conclusion==

CSC/ECE 517 Fall 2012/ch2a 2w13 sm

2012-10-26T22:23:50Z

Svmankar:

==Introduction==
Test stubs are programs which simulate the behaviors of software components (or modules) that are depended upon modules of the module being tested.
Stubs are replacements for missing components that the components being tested will call as part of the test. While doing an Integration , If we dont have all the modules get ready and Need to test a particualr module which is ready then We Use Stubs and Drivers.
Stubs are used in Integration testing for a Top Down Integration testing and Botton Up Integration Testing.
For Eg: If we have Modules x,y,z . X module is ready and Need to Test it , But it calls functions from y and z.(Which are not ready)To test this particular module we can write a Small Dummy piece of code which Simulates Y and Z Which will return values that X expects. This piece of Dummy code is Called a Stub in a Top Down Integration
So Stubs are called Functions in Top Down Integration.

==Stubs in different phases of testing==
===Unit Testing===
===Functional Testing===
===Integration Testing===
Integration testing is a logical extension of unit testing. In its simplest form, two units that have already been tested are combined into a component and the interface between them is tested. A component, in this sense, refers to an integrated aggregate of more than one unit. In a realistic scenario, many units are combined into components, which are in turn aggregated into even larger parts of the program. The idea is to test combinations of pieces and eventually expand the process to test your modules with those of other groups. Eventually all the modules making up a process are tested together. Beyond that, if the program is composed of more than one process, they should be tested in pairs rather than all at once.
Integration testing identifies problems that occur when units are combined. By using a test plan that requires you to test each unit and ensure the viability of each before combining units, you know that any errors discovered when combining units are likely related to the interface between units. This method reduces the number of possibilities to a far simpler level of analysis.
The top-down approach to integration testing requires the highest-level modules be test and integrated first. This allows high-level logic and data flow to be tested early in the process and it tends to minimize the need for drivers. However, the need for stubs complicates test management and low-level utilities are tested relatively late in the development cycle. Another disadvantage of top-down integration testing is its poor support for early release of limited functionality.

===Regression Testing===
Regression testing is any type of software testing that seeks to uncover new software bugs, or regressions, in existing functional and non-functional areas of a system after changes, such as enhancements, patches or configuration changes, have been made to them.
The intent of regression testing is to ensure that a change, such as a bugfix, did not introduce new faults.[1] One of the main reasons for regression testing is to determine whether a change in one part of the software affects other parts of the software.[2]
Common methods of regression testing include rerunning previously run tests and checking whether program behavior has changed and whether previously fixed faults have re-emerged. Regression testing can be used to test a system efficiently by systematically selecting the appropriate minimum set of tests needed to adequately cover a particular change.
In Regression testing the use of test stubs is minimized as most of the system is already implemented and the main goal of the regression test is to see if there are any bugs that might have been ‘regressed’ from the previous stages of integrations. Ideally there will not be unimplemented modules by the time a system is tested for regression. However, in case of mutually exclusive modules of a system, a test stub for one of them can be used to test the regression of the other.

==Stubs in software development methodologies==
===Agile Development Methodology===
Agile software development is a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change. It is a conceptual framework that promotes foreseen interactions throughout the development cycle.
In such a development system, it recognizes that testing is not a separate phase, but an integral part of software development, along with coding. Agile testing is a software testing practice that follows the principles of agile software development. Agile testing involves all members of a cross-functional agile team, with special expertise contributed by testers, to ensure delivering the business value desired by the customer at frequent intervals, working at a sustainable pace. Specification by example, also known as acceptance test-driven development, is used to capture examples of desired and undesired behavior and guide coding.
In the agile testing toolkit, a stub is a piece of code that behaves in a predefined way, in order to simplify the testing process. Here are the kind of simplifications that a stub can bring:

* If the code under test never returns the same value (usage of a timestamp or of a random value), a stub can be used to fix the root of the undeterminism.

* If the code depends on some other class that has complex behavior that you don’t want to take into account in this test, using a stub for this other class can simplify its behavior and clarify the intent of the test

* If the code depends on some other code that is not yet written or released, it is possible to start building the rest of the code before the dependency is actually finished.

==Examples of Stubs==
===Java===
In Java, the basic technique is to implement the stub collaborators as concrete classes which only exhibit the small part of the overall behaviour of the collaborator which is needed by the class under test. As an example consider the case where a service implementation is under test. The implementation has a collaborator:

<pre>
public class SimpleService implements Service {
private Collaborator collaborator;
public void setCollaborator(Collaborator collaborator) {
this.collaborator = collaborator;
}

// part of Service interface
public boolean isActive() {
return collaborator.isActive();
}
}
</pre>

We could have a stub collaborator for testing as defined below:

<pre>
public class StubCollaboratorAdapter implements Collaborator {
public boolean isActive() {
return false;
}
}
</pre>

Now, a test case can be written as something like this:

<pre>
public void testActiveWhenCollaboratorIsActive() throws Exception {
Service service = new SimpleService();
service.setCollaborator(new StubCollaboratorAdapter() {
public boolean isActive() {
return true;
}
});
assertTrue(service.isActive());
}
</pre>

===Ruby===
While writing stubs, one might decide to replace a whole object or simply change the results of a single method. When you're replacing a whole object, it's easy—just write the new object and replace it within your test case. Methods might be tougher in some languages, but using dynamic languages such as Ruby, stubbing is easy because you're simply redefining a method.
Imagine you have a user interface that prints a document. You want to test code that handles a print failure. You really don't care if the print method gets called. You just want to verify that if your code does call print, that code will handle a failed print effectively. Think of what a pseudo-code sentence would look like.
On an instance of the document object, stub the print method, returning false.
You can break that sentence down into two parts. The first part identifies what you want to stub. The second part defines what the stub should do.
Below is an example of the Mocha framework that can be used to build stubs in Ruby:
<pre>
class Document
def print
# doesn't matter -- we are stubbing it out
end
end

class View
attr :document

def initialize(document)
@document = document
end

def print()
if document.print
puts "Excellent!"
true
else
puts "Bummer."
false
end
end
end
</pre>
Test code can be written as follows:
<pre>
require 'test/unit'
require 'rubygems'
require 'mocha'
require 'document'

class ViewTest < Test::Unit::TestCase

def test_should_return_false_for_failed_print
document = stub("my document")
document.stubs(:print).returns(false)

ui = View.new(document)
assert_equal false, ui.print
end

end
</pre>
You can see how this works. I build a simple, named stub object with the statement stub("my document"). Then, I define the behavior for print within the stub with the line of code document.stubs(:print).returns(false). If you look carefully, this line of code looks remarkably similar to the pseudo-code from earlier:
On an instance of the document object, stub the print method, returning false.

===Python===

==IDE support for Stubs==
===Eclipse===
===RubyMine===
The most basic way to create test templates in RubyMine is to use the regular procedure of creating files in the project. This means is both available for both plain Ruby projets, and for the Rails applications, and allows creating stub tests for Test::Unit, RSpec and Test-Spec.

For RSpec and Test-Spec, RubyMine provides a number of generators. These generators are context sensitive and become available depending on the selected location, and on the gems activated for your project. For example, ir rspec-rails is activated, the usual generators are hidden, and the list of generators includes only those specific for RSpec.

===Visual Studio===
Visual Studio is a fine IDE that provides good support for automatically generating stubs for methods. Generate Method Stub is an IntelliSense Automatic Code Generation feature that provides an easy way to have Visual Studio create a new method declaration at the time you are writing a method call. Visual Studio infers the declaration from the call. Some programming styles, such as test-driven development, suggest that you should consume before you define. That way, it is easier to figure out the form of the API that you are developing. You can use IntelliSense to program in that style. Using the Generate Method Stub operation, you avoid defining everything before you consume it.

The Generate Method Stub IntelliSense operation can also increase productivity because you do not need to move from the calling code, your present focus, to the defining code, a separate focus, in order to generate a new method. You can instead write a method call, and then invoke the Generate Method Stub operation without dividing your attention.

==Conclusion==

CSC/ECE 517 Fall 2012/ch2a 2w13 sm

2012-10-26T22:23:34Z

Svmankar:

==Introduction==
Test stubs are programs which simulate the behaviors of software components (or modules) that are depended upon modules of the module being tested.
Stubs are replacements for missing components that the components being tested will call as part of the test. While doing an Integration , If we dont have all the modules get ready and Need to test a particualr module which is ready then We Use Stubs and Drivers.
Stubs are used in Integration testing for a Top Down Integration testing and Botton Up Integration Testing.
For Eg: If we have Modules x,y,z . X module is ready and Need to Test it , But it calls functions from y and z.(Which are not ready)To test this particular module we can write a Small Dummy piece of code which Simulates Y and Z Which will return values that X expects. This piece of Dummy code is Called a Stub in a Top Down Integration
So Stubs are called Functions in Top Down Integration.

==Stubs in different phases of testing==
===Unit Testing===
===Functional Testing===
===Integration Testing===
Integration testing is a logical extension of unit testing. In its simplest form, two units that have already been tested are combined into a component and the interface between them is tested. A component, in this sense, refers to an integrated aggregate of more than one unit. In a realistic scenario, many units are combined into components, which are in turn aggregated into even larger parts of the program. The idea is to test combinations of pieces and eventually expand the process to test your modules with those of other groups. Eventually all the modules making up a process are tested together. Beyond that, if the program is composed of more than one process, they should be tested in pairs rather than all at once.
Integration testing identifies problems that occur when units are combined. By using a test plan that requires you to test each unit and ensure the viability of each before combining units, you know that any errors discovered when combining units are likely related to the interface between units. This method reduces the number of possibilities to a far simpler level of analysis.
The top-down approach to integration testing requires the highest-level modules be test and integrated first. This allows high-level logic and data flow to be tested early in the process and it tends to minimize the need for drivers. However, the need for stubs complicates test management and low-level utilities are tested relatively late in the development cycle. Another disadvantage of top-down integration testing is its poor support for early release of limited functionality.

===Regression Testing===
Regression testing is any type of software testing that seeks to uncover new software bugs, or regressions, in existing functional and non-functional areas of a system after changes, such as enhancements, patches or configuration changes, have been made to them.
The intent of regression testing is to ensure that a change, such as a bugfix, did not introduce new faults.[1] One of the main reasons for regression testing is to determine whether a change in one part of the software affects other parts of the software.[2]
Common methods of regression testing include rerunning previously run tests and checking whether program behavior has changed and whether previously fixed faults have re-emerged. Regression testing can be used to test a system efficiently by systematically selecting the appropriate minimum set of tests needed to adequately cover a particular change.
In Regression testing the use of test stubs is minimized as most of the system is already implemented and the main goal of the regression test is to see if there are any bugs that might have been ‘regressed’ from the previous stages of integrations. Ideally there will not be unimplemented modules by the time a system is tested for regression. However, in case of mutually exclusive modules of a system, a test stub for one of them can be used to test the regression of the other.

==Stubs in software development methodologies==
===Agile Development Methodology===
Agile software development is a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change. It is a conceptual framework that promotes foreseen interactions throughout the development cycle.
In such a development system, it recognizes that testing is not a separate phase, but an integral part of software development, along with coding. Agile testing is a software testing practice that follows the principles of agile software development. Agile testing involves all members of a cross-functional agile team, with special expertise contributed by testers, to ensure delivering the business value desired by the customer at frequent intervals, working at a sustainable pace. Specification by example, also known as acceptance test-driven development, is used to capture examples of desired and undesired behavior and guide coding.
In the agile testing toolkit, a stub is a piece of code that behaves in a predefined way, in order to simplify the testing process. Here are the kind of simplifications that a stub can bring:

* If the code under test never returns the same value (usage of a timestamp or of a random value), a stub can be used to fix the root of the undeterminism.

* If the code depends on some other class that has complex behavior that you don’t want to take into account in this test, using a stub for this other class can simplify its behavior and clarify the intent of the test

* If the code depends on some other code that is not yet written or released, it is possible to start building the rest of the code before the dependency is actually finished.

==Examples of Stubs==
===Java===
In Java, the basic technique is to implement the stub collaborators as concrete classes which only exhibit the small part of the overall behaviour of the collaborator which is needed by the class under test. As an example consider the case where a service implementation is under test. The implementation has a collaborator:

<pre>
public class SimpleService implements Service {
private Collaborator collaborator;
public void setCollaborator(Collaborator collaborator) {
this.collaborator = collaborator;
}

// part of Service interface
public boolean isActive() {
return collaborator.isActive();
}
}
</pre>

We could have a stub collaborator for testing as defined below:

<pre>
public class StubCollaboratorAdapter implements Collaborator {
public boolean isActive() {
return false;
}
}
</pre>

Now, a test case can be written as something like this:

<pre>
public void testActiveWhenCollaboratorIsActive() throws Exception {
Service service = new SimpleService();
service.setCollaborator(new StubCollaboratorAdapter() {
public boolean isActive() {
return true;
}
});
assertTrue(service.isActive());
}
</pre>

===Ruby===
While writing stubs, one might decide to replace a whole object or simply change the results of a single method. When you're replacing a whole object, it's easy—just write the new object and replace it within your test case. Methods might be tougher in some languages, but using dynamic languages such as Ruby, stubbing is easy because you're simply redefining a method.
Imagine you have a user interface that prints a document. You want to test code that handles a print failure. You really don't care if the print method gets called. You just want to verify that if your code does call print, that code will handle a failed print effectively. Think of what a pseudo-code sentence would look like.
On an instance of the document object, stub the print method, returning false.
You can break that sentence down into two parts. The first part identifies what you want to stub. The second part defines what the stub should do.
Below is an example of the Mocha framework that can be used to build stubs in Ruby:
<pre>
class Document
def print
# doesn't matter -- we are stubbing it out
end
end

class View
attr :document

def initialize(document)
@document = document
end

def print()
if document.print
puts "Excellent!"
true
else
puts "Bummer."
false
end
end
end
</pre>
Test code can be written as follows:
<pre>
require 'test/unit'
require 'rubygems'
require 'mocha'
require 'document'

class ViewTest < Test::Unit::TestCase

def test_should_return_false_for_failed_print
document = stub("my document")
document.stubs(:print).returns(false)

ui = View.new(document)
assert_equal false, ui.print
end

end
</pre>
You can see how this works. I build a simple, named stub object with the statement stub("my document"). Then, I define the behavior for print within the stub with the line of code document.stubs(:print).returns(false). If you look carefully, this line of code looks remarkably similar to the pseudo-code from earlier:
On an instance of the document object, stub the print method, returning false.

===Python===

==IDE support for Stubs==
===Eclipse===
===RubyMine===
The most basic way to create test templates in RubyMine is to use the regular procedure of creating files in the project. This means is both available for both plain Ruby projets, and for the Rails applications, and allows creating stub tests for Test::Unit, RSpec and Test-Spec.

For RSpec and Test-Spec, RubyMine provides a number of generators. These generators are context sensitive and become available depending on the selected location, and on the gems activated for your project. For example, ir rspec-rails is activated, the usual generators are hidden, and the list of generators includes only those specific for RSpec.

===Visual Studio===
Visual Studio is a fine IDE that provides good support for automatically generating stubs for methods. Generate Method Stub is an IntelliSense Automatic Code Generation feature that provides an easy way to have Visual Studio create a new method declaration at the time you are writing a method call. Visual Studio infers the declaration from the call. Some programming styles, such as test-driven development, suggest that you should consume before you define. That way, it is easier to figure out the form of the API that you are developing. You can use IntelliSense to program in that style. Using the Generate Method Stub operation, you avoid defining everything before you consume it.

The Generate Method Stub IntelliSense operation can also increase productivity because you do not need to move from the calling code, your present focus, to the defining code, a separate focus, in order to generate a new method. You can instead write a method call, and then invoke the Generate Method Stub operation without dividing your attention.

===Conclusion===

CSC/ECE 517 Fall 2012/ch2a 2w13 sm

2012-10-26T22:21:37Z

Svmankar: /* Agile Development Methodology */

==Introduction==
Test stubs are programs which simulate the behaviors of software components (or modules) that are depended upon modules of the module being tested.
Stubs are replacements for missing components that the components being tested will call as part of the test. While doing an Integration , If we dont have all the modules get ready and Need to test a particualr module which is ready then We Use Stubs and Drivers.
Stubs are used in Integration testing for a Top Down Integration testing and Botton Up Integration Testing.
For Eg: If we have Modules x,y,z . X module is ready and Need to Test it , But it calls functions from y and z.(Which are not ready)To test this particular module we can write a Small Dummy piece of code which Simulates Y and Z Which will return values that X expects. This piece of Dummy code is Called a Stub in a Top Down Integration
So Stubs are called Functions in Top Down Integration.

==Stubs in different phases of testing==
===Unit Testing===
===Functional Testing===
===Integration Testing===
Integration testing is a logical extension of unit testing. In its simplest form, two units that have already been tested are combined into a component and the interface between them is tested. A component, in this sense, refers to an integrated aggregate of more than one unit. In a realistic scenario, many units are combined into components, which are in turn aggregated into even larger parts of the program. The idea is to test combinations of pieces and eventually expand the process to test your modules with those of other groups. Eventually all the modules making up a process are tested together. Beyond that, if the program is composed of more than one process, they should be tested in pairs rather than all at once.
Integration testing identifies problems that occur when units are combined. By using a test plan that requires you to test each unit and ensure the viability of each before combining units, you know that any errors discovered when combining units are likely related to the interface between units. This method reduces the number of possibilities to a far simpler level of analysis.
The top-down approach to integration testing requires the highest-level modules be test and integrated first. This allows high-level logic and data flow to be tested early in the process and it tends to minimize the need for drivers. However, the need for stubs complicates test management and low-level utilities are tested relatively late in the development cycle. Another disadvantage of top-down integration testing is its poor support for early release of limited functionality.

===Regression Testing===
Regression testing is any type of software testing that seeks to uncover new software bugs, or regressions, in existing functional and non-functional areas of a system after changes, such as enhancements, patches or configuration changes, have been made to them.
The intent of regression testing is to ensure that a change, such as a bugfix, did not introduce new faults.[1] One of the main reasons for regression testing is to determine whether a change in one part of the software affects other parts of the software.[2]
Common methods of regression testing include rerunning previously run tests and checking whether program behavior has changed and whether previously fixed faults have re-emerged. Regression testing can be used to test a system efficiently by systematically selecting the appropriate minimum set of tests needed to adequately cover a particular change.
In Regression testing the use of test stubs is minimized as most of the system is already implemented and the main goal of the regression test is to see if there are any bugs that might have been ‘regressed’ from the previous stages of integrations. Ideally there will not be unimplemented modules by the time a system is tested for regression. However, in case of mutually exclusive modules of a system, a test stub for one of them can be used to test the regression of the other.

==Stubs in software development methodologies==
===Agile Development Methodology===
Agile software development is a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change. It is a conceptual framework that promotes foreseen interactions throughout the development cycle.
In such a development system, it recognizes that testing is not a separate phase, but an integral part of software development, along with coding. Agile testing is a software testing practice that follows the principles of agile software development. Agile testing involves all members of a cross-functional agile team, with special expertise contributed by testers, to ensure delivering the business value desired by the customer at frequent intervals, working at a sustainable pace. Specification by example, also known as acceptance test-driven development, is used to capture examples of desired and undesired behavior and guide coding.
In the agile testing toolkit, a stub is a piece of code that behaves in a predefined way, in order to simplify the testing process. Here are the kind of simplifications that a stub can bring:

* If the code under test never returns the same value (usage of a timestamp or of a random value), a stub can be used to fix the root of the undeterminism.

* If the code depends on some other class that has complex behavior that you don’t want to take into account in this test, using a stub for this other class can simplify its behavior and clarify the intent of the test

* If the code depends on some other code that is not yet written or released, it is possible to start building the rest of the code before the dependency is actually finished.

==Examples of Stubs==
===Java===
In Java, the basic technique is to implement the stub collaborators as concrete classes which only exhibit the small part of the overall behaviour of the collaborator which is needed by the class under test. As an example consider the case where a service implementation is under test. The implementation has a collaborator:

<pre>
public class SimpleService implements Service {
private Collaborator collaborator;
public void setCollaborator(Collaborator collaborator) {
this.collaborator = collaborator;
}

// part of Service interface
public boolean isActive() {
return collaborator.isActive();
}
}
</pre>

We could have a stub collaborator for testing as defined below:

<pre>
public class StubCollaboratorAdapter implements Collaborator {
public boolean isActive() {
return false;
}
}
</pre>

Now, a test case can be written as something like this:

<pre>
public void testActiveWhenCollaboratorIsActive() throws Exception {
Service service = new SimpleService();
service.setCollaborator(new StubCollaboratorAdapter() {
public boolean isActive() {
return true;
}
});
assertTrue(service.isActive());
}
</pre>

===Ruby===
While writing stubs, one might decide to replace a whole object or simply change the results of a single method. When you're replacing a whole object, it's easy—just write the new object and replace it within your test case. Methods might be tougher in some languages, but using dynamic languages such as Ruby, stubbing is easy because you're simply redefining a method.
Imagine you have a user interface that prints a document. You want to test code that handles a print failure. You really don't care if the print method gets called. You just want to verify that if your code does call print, that code will handle a failed print effectively. Think of what a pseudo-code sentence would look like.
On an instance of the document object, stub the print method, returning false.
You can break that sentence down into two parts. The first part identifies what you want to stub. The second part defines what the stub should do.
Below is an example of the Mocha framework that can be used to build stubs in Ruby:
<pre>
class Document
def print
# doesn't matter -- we are stubbing it out
end
end

class View
attr :document

def initialize(document)
@document = document
end

def print()
if document.print
puts "Excellent!"
true
else
puts "Bummer."
false
end
end
end
</pre>
Test code can be written as follows:
<pre>
require 'test/unit'
require 'rubygems'
require 'mocha'
require 'document'

class ViewTest < Test::Unit::TestCase

def test_should_return_false_for_failed_print
document = stub("my document")
document.stubs(:print).returns(false)

ui = View.new(document)
assert_equal false, ui.print
end

end
</pre>
You can see how this works. I build a simple, named stub object with the statement stub("my document"). Then, I define the behavior for print within the stub with the line of code document.stubs(:print).returns(false). If you look carefully, this line of code looks remarkably similar to the pseudo-code from earlier:
On an instance of the document object, stub the print method, returning false.

===Python===

==IDE support for Stubs==
===Eclipse===
===RubyMine===
The most basic way to create test templates in RubyMine is to use the regular procedure of creating files in the project. This means is both available for both plain Ruby projets, and for the Rails applications, and allows creating stub tests for Test::Unit, RSpec and Test-Spec.

For RSpec and Test-Spec, RubyMine provides a number of generators. These generators are context sensitive and become available depending on the selected location, and on the gems activated for your project. For example, ir rspec-rails is activated, the usual generators are hidden, and the list of generators includes only those specific for RSpec.

===Visual Studio===
Visual Studio is a fine IDE that provides good support for automatically generating stubs for methods. Generate Method Stub is an IntelliSense Automatic Code Generation feature that provides an easy way to have Visual Studio create a new method declaration at the time you are writing a method call. Visual Studio infers the declaration from the call. Some programming styles, such as test-driven development, suggest that you should consume before you define. That way, it is easier to figure out the form of the API that you are developing. You can use IntelliSense to program in that style. Using the Generate Method Stub operation, you avoid defining everything before you consume it.

The Generate Method Stub IntelliSense operation can also increase productivity because you do not need to move from the calling code, your present focus, to the defining code, a separate focus, in order to generate a new method. You can instead write a method call, and then invoke the Generate Method Stub operation without dividing your attention.

CSC/ECE 517 Fall 2012/ch2a 2w13 sm

2012-10-26T22:20:49Z

Svmankar: /* Agile Development Methodology */

==Introduction==
Test stubs are programs which simulate the behaviors of software components (or modules) that are depended upon modules of the module being tested.
Stubs are replacements for missing components that the components being tested will call as part of the test. While doing an Integration , If we dont have all the modules get ready and Need to test a particualr module which is ready then We Use Stubs and Drivers.
Stubs are used in Integration testing for a Top Down Integration testing and Botton Up Integration Testing.
For Eg: If we have Modules x,y,z . X module is ready and Need to Test it , But it calls functions from y and z.(Which are not ready)To test this particular module we can write a Small Dummy piece of code which Simulates Y and Z Which will return values that X expects. This piece of Dummy code is Called a Stub in a Top Down Integration
So Stubs are called Functions in Top Down Integration.

==Stubs in different phases of testing==
===Unit Testing===
===Functional Testing===
===Integration Testing===
Integration testing is a logical extension of unit testing. In its simplest form, two units that have already been tested are combined into a component and the interface between them is tested. A component, in this sense, refers to an integrated aggregate of more than one unit. In a realistic scenario, many units are combined into components, which are in turn aggregated into even larger parts of the program. The idea is to test combinations of pieces and eventually expand the process to test your modules with those of other groups. Eventually all the modules making up a process are tested together. Beyond that, if the program is composed of more than one process, they should be tested in pairs rather than all at once.
Integration testing identifies problems that occur when units are combined. By using a test plan that requires you to test each unit and ensure the viability of each before combining units, you know that any errors discovered when combining units are likely related to the interface between units. This method reduces the number of possibilities to a far simpler level of analysis.
The top-down approach to integration testing requires the highest-level modules be test and integrated first. This allows high-level logic and data flow to be tested early in the process and it tends to minimize the need for drivers. However, the need for stubs complicates test management and low-level utilities are tested relatively late in the development cycle. Another disadvantage of top-down integration testing is its poor support for early release of limited functionality.

===Regression Testing===
Regression testing is any type of software testing that seeks to uncover new software bugs, or regressions, in existing functional and non-functional areas of a system after changes, such as enhancements, patches or configuration changes, have been made to them.
The intent of regression testing is to ensure that a change, such as a bugfix, did not introduce new faults.[1] One of the main reasons for regression testing is to determine whether a change in one part of the software affects other parts of the software.[2]
Common methods of regression testing include rerunning previously run tests and checking whether program behavior has changed and whether previously fixed faults have re-emerged. Regression testing can be used to test a system efficiently by systematically selecting the appropriate minimum set of tests needed to adequately cover a particular change.
In Regression testing the use of test stubs is minimized as most of the system is already implemented and the main goal of the regression test is to see if there are any bugs that might have been ‘regressed’ from the previous stages of integrations. Ideally there will not be unimplemented modules by the time a system is tested for regression. However, in case of mutually exclusive modules of a system, a test stub for one of them can be used to test the regression of the other.

==Stubs in software development methodologies==
===Agile Development Methodology===
Agile software development is a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change. It is a conceptual framework that promotes foreseen interactions throughout the development cycle.
In such a development system, it recognizes that testing is not a separate phase, but an integral part of software development, along with coding. Agile testing is a software testing practice that follows the principles of agile software development. Agile testing involves all members of a cross-functional agile team, with special expertise contributed by testers, to ensure delivering the business value desired by the customer at frequent intervals, working at a sustainable pace. Specification by example, also known as acceptance test-driven development, is used to capture examples of desired and undesired behavior and guide coding.
In the agile testing toolkit, a stub is a piece of code that behaves in a predefined way, in order to simplify the testing process. Here are the kind of simplifications that a stub can bring:

* If the code under test never returns the same value (usage of a timestamp or of a random value), a stub can be used to fix the root of the undeterminism

* If the code depends on some other class that has complex behaviour that you don’t want to take into account in this test, using a stub for this other class can simplify its behaviour and clarify the intent of the test

* If the code depends on some other code that is not yet written or released, it is possible to start building the rest of the code before the dependency is actualy finished.

==Examples of Stubs==
===Java===
In Java, the basic technique is to implement the stub collaborators as concrete classes which only exhibit the small part of the overall behaviour of the collaborator which is needed by the class under test. As an example consider the case where a service implementation is under test. The implementation has a collaborator:

<pre>
public class SimpleService implements Service {
private Collaborator collaborator;
public void setCollaborator(Collaborator collaborator) {
this.collaborator = collaborator;
}

// part of Service interface
public boolean isActive() {
return collaborator.isActive();
}
}
</pre>

We could have a stub collaborator for testing as defined below:

<pre>
public class StubCollaboratorAdapter implements Collaborator {
public boolean isActive() {
return false;
}
}
</pre>

Now, a test case can be written as something like this:

<pre>
public void testActiveWhenCollaboratorIsActive() throws Exception {
Service service = new SimpleService();
service.setCollaborator(new StubCollaboratorAdapter() {
public boolean isActive() {
return true;
}
});
assertTrue(service.isActive());
}
</pre>

===Ruby===
While writing stubs, one might decide to replace a whole object or simply change the results of a single method. When you're replacing a whole object, it's easy—just write the new object and replace it within your test case. Methods might be tougher in some languages, but using dynamic languages such as Ruby, stubbing is easy because you're simply redefining a method.
Imagine you have a user interface that prints a document. You want to test code that handles a print failure. You really don't care if the print method gets called. You just want to verify that if your code does call print, that code will handle a failed print effectively. Think of what a pseudo-code sentence would look like.
On an instance of the document object, stub the print method, returning false.
You can break that sentence down into two parts. The first part identifies what you want to stub. The second part defines what the stub should do.
Below is an example of the Mocha framework that can be used to build stubs in Ruby:
<pre>
class Document
def print
# doesn't matter -- we are stubbing it out
end
end

class View
attr :document

def initialize(document)
@document = document
end

def print()
if document.print
puts "Excellent!"
true
else
puts "Bummer."
false
end
end
end
</pre>
Test code can be written as follows:
<pre>
require 'test/unit'
require 'rubygems'
require 'mocha'
require 'document'

class ViewTest < Test::Unit::TestCase

def test_should_return_false_for_failed_print
document = stub("my document")
document.stubs(:print).returns(false)

ui = View.new(document)
assert_equal false, ui.print
end

end
</pre>
You can see how this works. I build a simple, named stub object with the statement stub("my document"). Then, I define the behavior for print within the stub with the line of code document.stubs(:print).returns(false). If you look carefully, this line of code looks remarkably similar to the pseudo-code from earlier:
On an instance of the document object, stub the print method, returning false.

===Python===

==IDE support for Stubs==
===Eclipse===
===RubyMine===
The most basic way to create test templates in RubyMine is to use the regular procedure of creating files in the project. This means is both available for both plain Ruby projets, and for the Rails applications, and allows creating stub tests for Test::Unit, RSpec and Test-Spec.

For RSpec and Test-Spec, RubyMine provides a number of generators. These generators are context sensitive and become available depending on the selected location, and on the gems activated for your project. For example, ir rspec-rails is activated, the usual generators are hidden, and the list of generators includes only those specific for RSpec.

===Visual Studio===
Visual Studio is a fine IDE that provides good support for automatically generating stubs for methods. Generate Method Stub is an IntelliSense Automatic Code Generation feature that provides an easy way to have Visual Studio create a new method declaration at the time you are writing a method call. Visual Studio infers the declaration from the call. Some programming styles, such as test-driven development, suggest that you should consume before you define. That way, it is easier to figure out the form of the API that you are developing. You can use IntelliSense to program in that style. Using the Generate Method Stub operation, you avoid defining everything before you consume it.

The Generate Method Stub IntelliSense operation can also increase productivity because you do not need to move from the calling code, your present focus, to the defining code, a separate focus, in order to generate a new method. You can instead write a method call, and then invoke the Generate Method Stub operation without dividing your attention.

CSC/ECE 517 Fall 2012/ch2a 2w13 sm

2012-10-26T22:20:34Z

Svmankar: /* Agile Development Methodology */

==Introduction==
Test stubs are programs which simulate the behaviors of software components (or modules) that are depended upon modules of the module being tested.
Stubs are replacements for missing components that the components being tested will call as part of the test. While doing an Integration , If we dont have all the modules get ready and Need to test a particualr module which is ready then We Use Stubs and Drivers.
Stubs are used in Integration testing for a Top Down Integration testing and Botton Up Integration Testing.
For Eg: If we have Modules x,y,z . X module is ready and Need to Test it , But it calls functions from y and z.(Which are not ready)To test this particular module we can write a Small Dummy piece of code which Simulates Y and Z Which will return values that X expects. This piece of Dummy code is Called a Stub in a Top Down Integration
So Stubs are called Functions in Top Down Integration.

==Stubs in different phases of testing==
===Unit Testing===
===Functional Testing===
===Integration Testing===
Integration testing is a logical extension of unit testing. In its simplest form, two units that have already been tested are combined into a component and the interface between them is tested. A component, in this sense, refers to an integrated aggregate of more than one unit. In a realistic scenario, many units are combined into components, which are in turn aggregated into even larger parts of the program. The idea is to test combinations of pieces and eventually expand the process to test your modules with those of other groups. Eventually all the modules making up a process are tested together. Beyond that, if the program is composed of more than one process, they should be tested in pairs rather than all at once.
Integration testing identifies problems that occur when units are combined. By using a test plan that requires you to test each unit and ensure the viability of each before combining units, you know that any errors discovered when combining units are likely related to the interface between units. This method reduces the number of possibilities to a far simpler level of analysis.
The top-down approach to integration testing requires the highest-level modules be test and integrated first. This allows high-level logic and data flow to be tested early in the process and it tends to minimize the need for drivers. However, the need for stubs complicates test management and low-level utilities are tested relatively late in the development cycle. Another disadvantage of top-down integration testing is its poor support for early release of limited functionality.

===Regression Testing===
Regression testing is any type of software testing that seeks to uncover new software bugs, or regressions, in existing functional and non-functional areas of a system after changes, such as enhancements, patches or configuration changes, have been made to them.
The intent of regression testing is to ensure that a change, such as a bugfix, did not introduce new faults.[1] One of the main reasons for regression testing is to determine whether a change in one part of the software affects other parts of the software.[2]
Common methods of regression testing include rerunning previously run tests and checking whether program behavior has changed and whether previously fixed faults have re-emerged. Regression testing can be used to test a system efficiently by systematically selecting the appropriate minimum set of tests needed to adequately cover a particular change.
In Regression testing the use of test stubs is minimized as most of the system is already implemented and the main goal of the regression test is to see if there are any bugs that might have been ‘regressed’ from the previous stages of integrations. Ideally there will not be unimplemented modules by the time a system is tested for regression. However, in case of mutually exclusive modules of a system, a test stub for one of them can be used to test the regression of the other.

==Stubs in software development methodologies==
===Agile Development Methodology===
Agile software development is a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change. It is a conceptual framework that promotes foreseen interactions throughout the development cycle.
In such a development system, it recognizes that testing is not a separate phase, but an integral part of software development, along with coding. Agile testing is a software testing practice that follows the principles of agile software development. Agile testing involves all members of a cross-functional agile team, with special expertise contributed by testers, to ensure delivering the business value desired by the customer at frequent intervals, working at a sustainable pace. Specification by example, also known as acceptance test-driven development, is used to capture examples of desired and undesired behavior and guide coding.
In the agile testing toolkit, a stub is a piece of code that behaves in a predefined way, in order to simplify the testing process. Here are the kind of simplifications that a stub can bring:

* if the code under test never returns the same value (usage of a timestamp or of a random value), a stub can be used to fix the root of the undeterminism

* if the code depends on some other class that has complex behaviour that you don’t want to take into account in this test, using a stub for this other class can simplify its behaviour and clarify the intent of the test

* if the code depends on some other code that is not yet written or released, it is possible to start building the rest of the code before the dependency is actualy finished.

==Examples of Stubs==
===Java===
In Java, the basic technique is to implement the stub collaborators as concrete classes which only exhibit the small part of the overall behaviour of the collaborator which is needed by the class under test. As an example consider the case where a service implementation is under test. The implementation has a collaborator:

<pre>
public class SimpleService implements Service {
private Collaborator collaborator;
public void setCollaborator(Collaborator collaborator) {
this.collaborator = collaborator;
}

// part of Service interface
public boolean isActive() {
return collaborator.isActive();
}
}
</pre>

We could have a stub collaborator for testing as defined below:

<pre>
public class StubCollaboratorAdapter implements Collaborator {
public boolean isActive() {
return false;
}
}
</pre>

Now, a test case can be written as something like this:

<pre>
public void testActiveWhenCollaboratorIsActive() throws Exception {
Service service = new SimpleService();
service.setCollaborator(new StubCollaboratorAdapter() {
public boolean isActive() {
return true;
}
});
assertTrue(service.isActive());
}
</pre>

===Ruby===
While writing stubs, one might decide to replace a whole object or simply change the results of a single method. When you're replacing a whole object, it's easy—just write the new object and replace it within your test case. Methods might be tougher in some languages, but using dynamic languages such as Ruby, stubbing is easy because you're simply redefining a method.
Imagine you have a user interface that prints a document. You want to test code that handles a print failure. You really don't care if the print method gets called. You just want to verify that if your code does call print, that code will handle a failed print effectively. Think of what a pseudo-code sentence would look like.
On an instance of the document object, stub the print method, returning false.
You can break that sentence down into two parts. The first part identifies what you want to stub. The second part defines what the stub should do.
Below is an example of the Mocha framework that can be used to build stubs in Ruby:
<pre>
class Document
def print
# doesn't matter -- we are stubbing it out
end
end

class View
attr :document

def initialize(document)
@document = document
end

def print()
if document.print
puts "Excellent!"
true
else
puts "Bummer."
false
end
end
end
</pre>
Test code can be written as follows:
<pre>
require 'test/unit'
require 'rubygems'
require 'mocha'
require 'document'

class ViewTest < Test::Unit::TestCase

def test_should_return_false_for_failed_print
document = stub("my document")
document.stubs(:print).returns(false)

ui = View.new(document)
assert_equal false, ui.print
end

end
</pre>
You can see how this works. I build a simple, named stub object with the statement stub("my document"). Then, I define the behavior for print within the stub with the line of code document.stubs(:print).returns(false). If you look carefully, this line of code looks remarkably similar to the pseudo-code from earlier:
On an instance of the document object, stub the print method, returning false.

===Python===

==IDE support for Stubs==
===Eclipse===
===RubyMine===
The most basic way to create test templates in RubyMine is to use the regular procedure of creating files in the project. This means is both available for both plain Ruby projets, and for the Rails applications, and allows creating stub tests for Test::Unit, RSpec and Test-Spec.

For RSpec and Test-Spec, RubyMine provides a number of generators. These generators are context sensitive and become available depending on the selected location, and on the gems activated for your project. For example, ir rspec-rails is activated, the usual generators are hidden, and the list of generators includes only those specific for RSpec.

===Visual Studio===
Visual Studio is a fine IDE that provides good support for automatically generating stubs for methods. Generate Method Stub is an IntelliSense Automatic Code Generation feature that provides an easy way to have Visual Studio create a new method declaration at the time you are writing a method call. Visual Studio infers the declaration from the call. Some programming styles, such as test-driven development, suggest that you should consume before you define. That way, it is easier to figure out the form of the API that you are developing. You can use IntelliSense to program in that style. Using the Generate Method Stub operation, you avoid defining everything before you consume it.

The Generate Method Stub IntelliSense operation can also increase productivity because you do not need to move from the calling code, your present focus, to the defining code, a separate focus, in order to generate a new method. You can instead write a method call, and then invoke the Generate Method Stub operation without dividing your attention.

CSC/ECE 517 Fall 2012/ch2a 2w13 sm

2012-10-26T22:19:50Z

Svmankar: /* Agile Development Methodology */

==Introduction==
Test stubs are programs which simulate the behaviors of software components (or modules) that are depended upon modules of the module being tested.
Stubs are replacements for missing components that the components being tested will call as part of the test. While doing an Integration , If we dont have all the modules get ready and Need to test a particualr module which is ready then We Use Stubs and Drivers.
Stubs are used in Integration testing for a Top Down Integration testing and Botton Up Integration Testing.
For Eg: If we have Modules x,y,z . X module is ready and Need to Test it , But it calls functions from y and z.(Which are not ready)To test this particular module we can write a Small Dummy piece of code which Simulates Y and Z Which will return values that X expects. This piece of Dummy code is Called a Stub in a Top Down Integration
So Stubs are called Functions in Top Down Integration.

==Stubs in different phases of testing==
===Unit Testing===
===Functional Testing===
===Integration Testing===
Integration testing is a logical extension of unit testing. In its simplest form, two units that have already been tested are combined into a component and the interface between them is tested. A component, in this sense, refers to an integrated aggregate of more than one unit. In a realistic scenario, many units are combined into components, which are in turn aggregated into even larger parts of the program. The idea is to test combinations of pieces and eventually expand the process to test your modules with those of other groups. Eventually all the modules making up a process are tested together. Beyond that, if the program is composed of more than one process, they should be tested in pairs rather than all at once.
Integration testing identifies problems that occur when units are combined. By using a test plan that requires you to test each unit and ensure the viability of each before combining units, you know that any errors discovered when combining units are likely related to the interface between units. This method reduces the number of possibilities to a far simpler level of analysis.
The top-down approach to integration testing requires the highest-level modules be test and integrated first. This allows high-level logic and data flow to be tested early in the process and it tends to minimize the need for drivers. However, the need for stubs complicates test management and low-level utilities are tested relatively late in the development cycle. Another disadvantage of top-down integration testing is its poor support for early release of limited functionality.

===Regression Testing===
Regression testing is any type of software testing that seeks to uncover new software bugs, or regressions, in existing functional and non-functional areas of a system after changes, such as enhancements, patches or configuration changes, have been made to them.
The intent of regression testing is to ensure that a change, such as a bugfix, did not introduce new faults.[1] One of the main reasons for regression testing is to determine whether a change in one part of the software affects other parts of the software.[2]
Common methods of regression testing include rerunning previously run tests and checking whether program behavior has changed and whether previously fixed faults have re-emerged. Regression testing can be used to test a system efficiently by systematically selecting the appropriate minimum set of tests needed to adequately cover a particular change.
In Regression testing the use of test stubs is minimized as most of the system is already implemented and the main goal of the regression test is to see if there are any bugs that might have been ‘regressed’ from the previous stages of integrations. Ideally there will not be unimplemented modules by the time a system is tested for regression. However, in case of mutually exclusive modules of a system, a test stub for one of them can be used to test the regression of the other.

==Stubs in software development methodologies==
===Agile Development Methodology===
Agile software development is a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change. It is a conceptual framework that promotes foreseen interactions throughout the development cycle.
In such a development system, it recognizes that testing is not a separate phase, but an integral part of software development, along with coding. Agile testing is a software testing practice that follows the principles of agile software development. Agile testing involves all members of a cross-functional agile team, with special expertise contributed by testers, to ensure delivering the business value desired by the customer at frequent intervals, working at a sustainable pace. Specification by example, also known as acceptance test-driven development, is used to capture examples of desired and undesired behavior and guide coding.
In the agile testing toolkit, a stub is a piece of code that behaves in a predefined way, in order to simplify the testing process. Here are the kind of simplifications that a stub can bring:

• if the code under test never returns the same value (usage of a timestamp or of a random value), a stub can be used to fix the root of the undeterminism

• if the code depends on some other class that has complex behaviour that you don’t want to take into account in this test, using a stub for this other class can simplify its behaviour and clarify the intent of the test

• if the code depends on some other code that is not yet written or released, it is possible to start building the rest of the code before the dependency is actualy finished.

==Examples of Stubs==
===Java===
In Java, the basic technique is to implement the stub collaborators as concrete classes which only exhibit the small part of the overall behaviour of the collaborator which is needed by the class under test. As an example consider the case where a service implementation is under test. The implementation has a collaborator:

<pre>
public class SimpleService implements Service {
private Collaborator collaborator;
public void setCollaborator(Collaborator collaborator) {
this.collaborator = collaborator;
}

// part of Service interface
public boolean isActive() {
return collaborator.isActive();
}
}
</pre>

We could have a stub collaborator for testing as defined below:

<pre>
public class StubCollaboratorAdapter implements Collaborator {
public boolean isActive() {
return false;
}
}
</pre>

Now, a test case can be written as something like this:

<pre>
public void testActiveWhenCollaboratorIsActive() throws Exception {
Service service = new SimpleService();
service.setCollaborator(new StubCollaboratorAdapter() {
public boolean isActive() {
return true;
}
});
assertTrue(service.isActive());
}
</pre>

===Ruby===
While writing stubs, one might decide to replace a whole object or simply change the results of a single method. When you're replacing a whole object, it's easy—just write the new object and replace it within your test case. Methods might be tougher in some languages, but using dynamic languages such as Ruby, stubbing is easy because you're simply redefining a method.
Imagine you have a user interface that prints a document. You want to test code that handles a print failure. You really don't care if the print method gets called. You just want to verify that if your code does call print, that code will handle a failed print effectively. Think of what a pseudo-code sentence would look like.
On an instance of the document object, stub the print method, returning false.
You can break that sentence down into two parts. The first part identifies what you want to stub. The second part defines what the stub should do.
Below is an example of the Mocha framework that can be used to build stubs in Ruby:
<pre>
class Document
def print
# doesn't matter -- we are stubbing it out
end
end

class View
attr :document

def initialize(document)
@document = document
end

def print()
if document.print
puts "Excellent!"
true
else
puts "Bummer."
false
end
end
end
</pre>
Test code can be written as follows:
<pre>
require 'test/unit'
require 'rubygems'
require 'mocha'
require 'document'

class ViewTest < Test::Unit::TestCase

def test_should_return_false_for_failed_print
document = stub("my document")
document.stubs(:print).returns(false)

ui = View.new(document)
assert_equal false, ui.print
end

end
</pre>
You can see how this works. I build a simple, named stub object with the statement stub("my document"). Then, I define the behavior for print within the stub with the line of code document.stubs(:print).returns(false). If you look carefully, this line of code looks remarkably similar to the pseudo-code from earlier:
On an instance of the document object, stub the print method, returning false.

===Python===

==IDE support for Stubs==
===Eclipse===
===RubyMine===
The most basic way to create test templates in RubyMine is to use the regular procedure of creating files in the project. This means is both available for both plain Ruby projets, and for the Rails applications, and allows creating stub tests for Test::Unit, RSpec and Test-Spec.

For RSpec and Test-Spec, RubyMine provides a number of generators. These generators are context sensitive and become available depending on the selected location, and on the gems activated for your project. For example, ir rspec-rails is activated, the usual generators are hidden, and the list of generators includes only those specific for RSpec.

===Visual Studio===
Visual Studio is a fine IDE that provides good support for automatically generating stubs for methods. Generate Method Stub is an IntelliSense Automatic Code Generation feature that provides an easy way to have Visual Studio create a new method declaration at the time you are writing a method call. Visual Studio infers the declaration from the call. Some programming styles, such as test-driven development, suggest that you should consume before you define. That way, it is easier to figure out the form of the API that you are developing. You can use IntelliSense to program in that style. Using the Generate Method Stub operation, you avoid defining everything before you consume it.

The Generate Method Stub IntelliSense operation can also increase productivity because you do not need to move from the calling code, your present focus, to the defining code, a separate focus, in order to generate a new method. You can instead write a method call, and then invoke the Generate Method Stub operation without dividing your attention.

CSC/ECE 517 Fall 2012/ch2a 2w13 sm

2012-10-26T22:18:43Z

Svmankar: /* Ruby */

==Introduction==
Test stubs are programs which simulate the behaviors of software components (or modules) that are depended upon modules of the module being tested.
Stubs are replacements for missing components that the components being tested will call as part of the test. While doing an Integration , If we dont have all the modules get ready and Need to test a particualr module which is ready then We Use Stubs and Drivers.
Stubs are used in Integration testing for a Top Down Integration testing and Botton Up Integration Testing.
For Eg: If we have Modules x,y,z . X module is ready and Need to Test it , But it calls functions from y and z.(Which are not ready)To test this particular module we can write a Small Dummy piece of code which Simulates Y and Z Which will return values that X expects. This piece of Dummy code is Called a Stub in a Top Down Integration
So Stubs are called Functions in Top Down Integration.

==Stubs in different phases of testing==
===Unit Testing===
===Functional Testing===
===Integration Testing===
Integration testing is a logical extension of unit testing. In its simplest form, two units that have already been tested are combined into a component and the interface between them is tested. A component, in this sense, refers to an integrated aggregate of more than one unit. In a realistic scenario, many units are combined into components, which are in turn aggregated into even larger parts of the program. The idea is to test combinations of pieces and eventually expand the process to test your modules with those of other groups. Eventually all the modules making up a process are tested together. Beyond that, if the program is composed of more than one process, they should be tested in pairs rather than all at once.
Integration testing identifies problems that occur when units are combined. By using a test plan that requires you to test each unit and ensure the viability of each before combining units, you know that any errors discovered when combining units are likely related to the interface between units. This method reduces the number of possibilities to a far simpler level of analysis.
The top-down approach to integration testing requires the highest-level modules be test and integrated first. This allows high-level logic and data flow to be tested early in the process and it tends to minimize the need for drivers. However, the need for stubs complicates test management and low-level utilities are tested relatively late in the development cycle. Another disadvantage of top-down integration testing is its poor support for early release of limited functionality.

===Regression Testing===
Regression testing is any type of software testing that seeks to uncover new software bugs, or regressions, in existing functional and non-functional areas of a system after changes, such as enhancements, patches or configuration changes, have been made to them.
The intent of regression testing is to ensure that a change, such as a bugfix, did not introduce new faults.[1] One of the main reasons for regression testing is to determine whether a change in one part of the software affects other parts of the software.[2]
Common methods of regression testing include rerunning previously run tests and checking whether program behavior has changed and whether previously fixed faults have re-emerged. Regression testing can be used to test a system efficiently by systematically selecting the appropriate minimum set of tests needed to adequately cover a particular change.
In Regression testing the use of test stubs is minimized as most of the system is already implemented and the main goal of the regression test is to see if there are any bugs that might have been ‘regressed’ from the previous stages of integrations. Ideally there will not be unimplemented modules by the time a system is tested for regression. However, in case of mutually exclusive modules of a system, a test stub for one of them can be used to test the regression of the other.

==Stubs in software development methodologies==
===Agile Development Methodology===
Agile software development is a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change. It is a conceptual framework that promotes foreseen interactions throughout the development cycle.
In such a development system, it recognizes that testing is not a separate phase, but an integral part of software development, along with coding. Agile testing is a software testing practice that follows the principles of agile software development. Agile testing involves all members of a cross-functional agile team, with special expertise contributed by testers, to ensure delivering the business value desired by the customer at frequent intervals, working at a sustainable pace. Specification by example, also known as acceptance test-driven development, is used to capture examples of desired and undesired behavior and guide coding.
In the agile testing toolkit, a stub is a piece of code that behaves in a predefined way, in order to simplify the testing process. Here are the kind of simplifications that a stub can bring:
• if the code under test never returns the same value (usage of a timestamp or of a random value), a stub can be used to fix the root of the undeterminism
• if the code depends on some other class that has complex behaviour that you don’t want to take into account in this test, using a stub for this other class can simplify its behaviour and clarify the intent of the test
• if the code depends on some other code that is not yet written or released, it is possible to start building the rest of the code before the dependency is actualy finished.

==Examples of Stubs==
===Java===
In Java, the basic technique is to implement the stub collaborators as concrete classes which only exhibit the small part of the overall behaviour of the collaborator which is needed by the class under test. As an example consider the case where a service implementation is under test. The implementation has a collaborator:

<pre>
public class SimpleService implements Service {
private Collaborator collaborator;
public void setCollaborator(Collaborator collaborator) {
this.collaborator = collaborator;
}

// part of Service interface
public boolean isActive() {
return collaborator.isActive();
}
}
</pre>

We could have a stub collaborator for testing as defined below:

<pre>
public class StubCollaboratorAdapter implements Collaborator {
public boolean isActive() {
return false;
}
}
</pre>

Now, a test case can be written as something like this:

<pre>
public void testActiveWhenCollaboratorIsActive() throws Exception {
Service service = new SimpleService();
service.setCollaborator(new StubCollaboratorAdapter() {
public boolean isActive() {
return true;
}
});
assertTrue(service.isActive());
}
</pre>

===Ruby===
While writing stubs, one might decide to replace a whole object or simply change the results of a single method. When you're replacing a whole object, it's easy—just write the new object and replace it within your test case. Methods might be tougher in some languages, but using dynamic languages such as Ruby, stubbing is easy because you're simply redefining a method.
Imagine you have a user interface that prints a document. You want to test code that handles a print failure. You really don't care if the print method gets called. You just want to verify that if your code does call print, that code will handle a failed print effectively. Think of what a pseudo-code sentence would look like.
On an instance of the document object, stub the print method, returning false.
You can break that sentence down into two parts. The first part identifies what you want to stub. The second part defines what the stub should do.
Below is an example of the Mocha framework that can be used to build stubs in Ruby:
<pre>
class Document
def print
# doesn't matter -- we are stubbing it out
end
end

class View
attr :document

def initialize(document)
@document = document
end

def print()
if document.print
puts "Excellent!"
true
else
puts "Bummer."
false
end
end
end
</pre>
Test code can be written as follows:
<pre>
require 'test/unit'
require 'rubygems'
require 'mocha'
require 'document'

class ViewTest < Test::Unit::TestCase

def test_should_return_false_for_failed_print
document = stub("my document")
document.stubs(:print).returns(false)

ui = View.new(document)
assert_equal false, ui.print
end

end
</pre>
You can see how this works. I build a simple, named stub object with the statement stub("my document"). Then, I define the behavior for print within the stub with the line of code document.stubs(:print).returns(false). If you look carefully, this line of code looks remarkably similar to the pseudo-code from earlier:
On an instance of the document object, stub the print method, returning false.

===Python===

==IDE support for Stubs==
===Eclipse===
===RubyMine===
The most basic way to create test templates in RubyMine is to use the regular procedure of creating files in the project. This means is both available for both plain Ruby projets, and for the Rails applications, and allows creating stub tests for Test::Unit, RSpec and Test-Spec.

For RSpec and Test-Spec, RubyMine provides a number of generators. These generators are context sensitive and become available depending on the selected location, and on the gems activated for your project. For example, ir rspec-rails is activated, the usual generators are hidden, and the list of generators includes only those specific for RSpec.

===Visual Studio===
Visual Studio is a fine IDE that provides good support for automatically generating stubs for methods. Generate Method Stub is an IntelliSense Automatic Code Generation feature that provides an easy way to have Visual Studio create a new method declaration at the time you are writing a method call. Visual Studio infers the declaration from the call. Some programming styles, such as test-driven development, suggest that you should consume before you define. That way, it is easier to figure out the form of the API that you are developing. You can use IntelliSense to program in that style. Using the Generate Method Stub operation, you avoid defining everything before you consume it.

The Generate Method Stub IntelliSense operation can also increase productivity because you do not need to move from the calling code, your present focus, to the defining code, a separate focus, in order to generate a new method. You can instead write a method call, and then invoke the Generate Method Stub operation without dividing your attention.

CSC/ECE 517 Fall 2012/ch2a 2w13 sm

2012-10-26T22:17:47Z

Svmankar: /* Java */

==Introduction==
Test stubs are programs which simulate the behaviors of software components (or modules) that are depended upon modules of the module being tested.
Stubs are replacements for missing components that the components being tested will call as part of the test. While doing an Integration , If we dont have all the modules get ready and Need to test a particualr module which is ready then We Use Stubs and Drivers.
Stubs are used in Integration testing for a Top Down Integration testing and Botton Up Integration Testing.
For Eg: If we have Modules x,y,z . X module is ready and Need to Test it , But it calls functions from y and z.(Which are not ready)To test this particular module we can write a Small Dummy piece of code which Simulates Y and Z Which will return values that X expects. This piece of Dummy code is Called a Stub in a Top Down Integration
So Stubs are called Functions in Top Down Integration.

==Stubs in different phases of testing==
===Unit Testing===
===Functional Testing===
===Integration Testing===
Integration testing is a logical extension of unit testing. In its simplest form, two units that have already been tested are combined into a component and the interface between them is tested. A component, in this sense, refers to an integrated aggregate of more than one unit. In a realistic scenario, many units are combined into components, which are in turn aggregated into even larger parts of the program. The idea is to test combinations of pieces and eventually expand the process to test your modules with those of other groups. Eventually all the modules making up a process are tested together. Beyond that, if the program is composed of more than one process, they should be tested in pairs rather than all at once.
Integration testing identifies problems that occur when units are combined. By using a test plan that requires you to test each unit and ensure the viability of each before combining units, you know that any errors discovered when combining units are likely related to the interface between units. This method reduces the number of possibilities to a far simpler level of analysis.
The top-down approach to integration testing requires the highest-level modules be test and integrated first. This allows high-level logic and data flow to be tested early in the process and it tends to minimize the need for drivers. However, the need for stubs complicates test management and low-level utilities are tested relatively late in the development cycle. Another disadvantage of top-down integration testing is its poor support for early release of limited functionality.

===Regression Testing===
Regression testing is any type of software testing that seeks to uncover new software bugs, or regressions, in existing functional and non-functional areas of a system after changes, such as enhancements, patches or configuration changes, have been made to them.
The intent of regression testing is to ensure that a change, such as a bugfix, did not introduce new faults.[1] One of the main reasons for regression testing is to determine whether a change in one part of the software affects other parts of the software.[2]
Common methods of regression testing include rerunning previously run tests and checking whether program behavior has changed and whether previously fixed faults have re-emerged. Regression testing can be used to test a system efficiently by systematically selecting the appropriate minimum set of tests needed to adequately cover a particular change.
In Regression testing the use of test stubs is minimized as most of the system is already implemented and the main goal of the regression test is to see if there are any bugs that might have been ‘regressed’ from the previous stages of integrations. Ideally there will not be unimplemented modules by the time a system is tested for regression. However, in case of mutually exclusive modules of a system, a test stub for one of them can be used to test the regression of the other.

==Stubs in software development methodologies==
===Agile Development Methodology===
Agile software development is a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change. It is a conceptual framework that promotes foreseen interactions throughout the development cycle.
In such a development system, it recognizes that testing is not a separate phase, but an integral part of software development, along with coding. Agile testing is a software testing practice that follows the principles of agile software development. Agile testing involves all members of a cross-functional agile team, with special expertise contributed by testers, to ensure delivering the business value desired by the customer at frequent intervals, working at a sustainable pace. Specification by example, also known as acceptance test-driven development, is used to capture examples of desired and undesired behavior and guide coding.
In the agile testing toolkit, a stub is a piece of code that behaves in a predefined way, in order to simplify the testing process. Here are the kind of simplifications that a stub can bring:
• if the code under test never returns the same value (usage of a timestamp or of a random value), a stub can be used to fix the root of the undeterminism
• if the code depends on some other class that has complex behaviour that you don’t want to take into account in this test, using a stub for this other class can simplify its behaviour and clarify the intent of the test
• if the code depends on some other code that is not yet written or released, it is possible to start building the rest of the code before the dependency is actualy finished.

==Examples of Stubs==
===Java===
In Java, the basic technique is to implement the stub collaborators as concrete classes which only exhibit the small part of the overall behaviour of the collaborator which is needed by the class under test. As an example consider the case where a service implementation is under test. The implementation has a collaborator:

<pre>
public class SimpleService implements Service {
private Collaborator collaborator;
public void setCollaborator(Collaborator collaborator) {
this.collaborator = collaborator;
}

// part of Service interface
public boolean isActive() {
return collaborator.isActive();
}
}
</pre>

We could have a stub collaborator for testing as defined below:

<pre>
public class StubCollaboratorAdapter implements Collaborator {
public boolean isActive() {
return false;
}
}
</pre>

Now, a test case can be written as something like this:

<pre>
public void testActiveWhenCollaboratorIsActive() throws Exception {
Service service = new SimpleService();
service.setCollaborator(new StubCollaboratorAdapter() {
public boolean isActive() {
return true;
}
});
assertTrue(service.isActive());
}
</pre>

===Ruby===
While writing stubs, one might decide to replace a whole object or simply change the results of a single method. When you're replacing a whole object, it's easy—just write the new object and replace it within your test case. Methods might be tougher in some languages, but using dynamic languages such as Ruby, stubbing is easy because you're simply redefining a method.
Imagine you have a user interface that prints a document. You want to test code that handles a print failure. You really don't care if the print method gets called. You just want to verify that if your code does call print, that code will handle a failed print effectively. Think of what a pseudo-code sentence would look like.
On an instance of the document object, stub the print method, returning false.
You can break that sentence down into two parts. The first part identifies what you want to stub. The second part defines what the stub should do.
Below is an example of the Mocha framework that can be used to build stubs in Ruby:
class Document
def print
# doesn't matter -- we are stubbing it out
end
end

class View
attr :document

def initialize(document)
@document = document
end

def print()
if document.print
puts "Excellent!"
true
else
puts "Bummer."
false
end
end
end

Test code can be written as follows:
require 'test/unit'
require 'rubygems'
require 'mocha'
require 'document'

class ViewTest < Test::Unit::TestCase

def test_should_return_false_for_failed_print
document = stub("my document")
document.stubs(:print).returns(false)

ui = View.new(document)
assert_equal false, ui.print
end

end

You can see how this works. I build a simple, named stub object with the statement stub("my document"). Then, I define the behavior for print within the stub with the line of code document.stubs(:print).returns(false). If you look carefully, this line of code looks remarkably similar to the pseudo-code from earlier:
On an instance of the document object, stub the print method, returning false.

===Python===

==IDE support for Stubs==
===Eclipse===
===RubyMine===
The most basic way to create test templates in RubyMine is to use the regular procedure of creating files in the project. This means is both available for both plain Ruby projets, and for the Rails applications, and allows creating stub tests for Test::Unit, RSpec and Test-Spec.

For RSpec and Test-Spec, RubyMine provides a number of generators. These generators are context sensitive and become available depending on the selected location, and on the gems activated for your project. For example, ir rspec-rails is activated, the usual generators are hidden, and the list of generators includes only those specific for RSpec.

===Visual Studio===
Visual Studio is a fine IDE that provides good support for automatically generating stubs for methods. Generate Method Stub is an IntelliSense Automatic Code Generation feature that provides an easy way to have Visual Studio create a new method declaration at the time you are writing a method call. Visual Studio infers the declaration from the call. Some programming styles, such as test-driven development, suggest that you should consume before you define. That way, it is easier to figure out the form of the API that you are developing. You can use IntelliSense to program in that style. Using the Generate Method Stub operation, you avoid defining everything before you consume it.

The Generate Method Stub IntelliSense operation can also increase productivity because you do not need to move from the calling code, your present focus, to the defining code, a separate focus, in order to generate a new method. You can instead write a method call, and then invoke the Generate Method Stub operation without dividing your attention.

CSC/ECE 517 Fall 2012/ch2a 2w13 sm

2012-10-26T22:16:16Z

Svmankar: /* Java */

==Introduction==
Test stubs are programs which simulate the behaviors of software components (or modules) that are depended upon modules of the module being tested.
Stubs are replacements for missing components that the components being tested will call as part of the test. While doing an Integration , If we dont have all the modules get ready and Need to test a particualr module which is ready then We Use Stubs and Drivers.
Stubs are used in Integration testing for a Top Down Integration testing and Botton Up Integration Testing.
For Eg: If we have Modules x,y,z . X module is ready and Need to Test it , But it calls functions from y and z.(Which are not ready)To test this particular module we can write a Small Dummy piece of code which Simulates Y and Z Which will return values that X expects. This piece of Dummy code is Called a Stub in a Top Down Integration
So Stubs are called Functions in Top Down Integration.

==Stubs in different phases of testing==
===Unit Testing===
===Functional Testing===
===Integration Testing===
Integration testing is a logical extension of unit testing. In its simplest form, two units that have already been tested are combined into a component and the interface between them is tested. A component, in this sense, refers to an integrated aggregate of more than one unit. In a realistic scenario, many units are combined into components, which are in turn aggregated into even larger parts of the program. The idea is to test combinations of pieces and eventually expand the process to test your modules with those of other groups. Eventually all the modules making up a process are tested together. Beyond that, if the program is composed of more than one process, they should be tested in pairs rather than all at once.
Integration testing identifies problems that occur when units are combined. By using a test plan that requires you to test each unit and ensure the viability of each before combining units, you know that any errors discovered when combining units are likely related to the interface between units. This method reduces the number of possibilities to a far simpler level of analysis.
The top-down approach to integration testing requires the highest-level modules be test and integrated first. This allows high-level logic and data flow to be tested early in the process and it tends to minimize the need for drivers. However, the need for stubs complicates test management and low-level utilities are tested relatively late in the development cycle. Another disadvantage of top-down integration testing is its poor support for early release of limited functionality.

===Regression Testing===
Regression testing is any type of software testing that seeks to uncover new software bugs, or regressions, in existing functional and non-functional areas of a system after changes, such as enhancements, patches or configuration changes, have been made to them.
The intent of regression testing is to ensure that a change, such as a bugfix, did not introduce new faults.[1] One of the main reasons for regression testing is to determine whether a change in one part of the software affects other parts of the software.[2]
Common methods of regression testing include rerunning previously run tests and checking whether program behavior has changed and whether previously fixed faults have re-emerged. Regression testing can be used to test a system efficiently by systematically selecting the appropriate minimum set of tests needed to adequately cover a particular change.
In Regression testing the use of test stubs is minimized as most of the system is already implemented and the main goal of the regression test is to see if there are any bugs that might have been ‘regressed’ from the previous stages of integrations. Ideally there will not be unimplemented modules by the time a system is tested for regression. However, in case of mutually exclusive modules of a system, a test stub for one of them can be used to test the regression of the other.

==Stubs in software development methodologies==
===Agile Development Methodology===
Agile software development is a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change. It is a conceptual framework that promotes foreseen interactions throughout the development cycle.
In such a development system, it recognizes that testing is not a separate phase, but an integral part of software development, along with coding. Agile testing is a software testing practice that follows the principles of agile software development. Agile testing involves all members of a cross-functional agile team, with special expertise contributed by testers, to ensure delivering the business value desired by the customer at frequent intervals, working at a sustainable pace. Specification by example, also known as acceptance test-driven development, is used to capture examples of desired and undesired behavior and guide coding.
In the agile testing toolkit, a stub is a piece of code that behaves in a predefined way, in order to simplify the testing process. Here are the kind of simplifications that a stub can bring:
• if the code under test never returns the same value (usage of a timestamp or of a random value), a stub can be used to fix the root of the undeterminism
• if the code depends on some other class that has complex behaviour that you don’t want to take into account in this test, using a stub for this other class can simplify its behaviour and clarify the intent of the test
• if the code depends on some other code that is not yet written or released, it is possible to start building the rest of the code before the dependency is actualy finished.

==Examples of Stubs==
===Java===
In Java, the basic technique is to implement the stub collaborators as concrete classes which only exhibit the small part of the overall behaviour of the collaborator which is needed by the class under test. As an example consider the case where a service implementation is under test. The implementation has a collaborator:

<code>
public class SimpleService implements Service {
private Collaborator collaborator;
public void setCollaborator(Collaborator collaborator) {
this.collaborator = collaborator;
}

// part of Service interface
public boolean isActive() {
return collaborator.isActive();
}
}
</code>

We could have a stub collaborator for testing as defined below:

[code]
public class StubCollaboratorAdapter implements Collaborator {
public boolean isActive() {
return false;
}
}
[/code]

Now, a test case can be written as something like this:

[code]
public void testActiveWhenCollaboratorIsActive() throws Exception {
Service service = new SimpleService();
service.setCollaborator(new StubCollaboratorAdapter() {
public boolean isActive() {
return true;
}
});
assertTrue(service.isActive());
}
[/code]

===Ruby===
While writing stubs, one might decide to replace a whole object or simply change the results of a single method. When you're replacing a whole object, it's easy—just write the new object and replace it within your test case. Methods might be tougher in some languages, but using dynamic languages such as Ruby, stubbing is easy because you're simply redefining a method.
Imagine you have a user interface that prints a document. You want to test code that handles a print failure. You really don't care if the print method gets called. You just want to verify that if your code does call print, that code will handle a failed print effectively. Think of what a pseudo-code sentence would look like.
On an instance of the document object, stub the print method, returning false.
You can break that sentence down into two parts. The first part identifies what you want to stub. The second part defines what the stub should do.
Below is an example of the Mocha framework that can be used to build stubs in Ruby:
class Document
def print
# doesn't matter -- we are stubbing it out
end
end

class View
attr :document

def initialize(document)
@document = document
end

def print()
if document.print
puts "Excellent!"
true
else
puts "Bummer."
false
end
end
end

Test code can be written as follows:
require 'test/unit'
require 'rubygems'
require 'mocha'
require 'document'

class ViewTest < Test::Unit::TestCase

def test_should_return_false_for_failed_print
document = stub("my document")
document.stubs(:print).returns(false)

ui = View.new(document)
assert_equal false, ui.print
end

end

You can see how this works. I build a simple, named stub object with the statement stub("my document"). Then, I define the behavior for print within the stub with the line of code document.stubs(:print).returns(false). If you look carefully, this line of code looks remarkably similar to the pseudo-code from earlier:
On an instance of the document object, stub the print method, returning false.

===Python===

==IDE support for Stubs==
===Eclipse===
===RubyMine===
The most basic way to create test templates in RubyMine is to use the regular procedure of creating files in the project. This means is both available for both plain Ruby projets, and for the Rails applications, and allows creating stub tests for Test::Unit, RSpec and Test-Spec.

For RSpec and Test-Spec, RubyMine provides a number of generators. These generators are context sensitive and become available depending on the selected location, and on the gems activated for your project. For example, ir rspec-rails is activated, the usual generators are hidden, and the list of generators includes only those specific for RSpec.

===Visual Studio===
Visual Studio is a fine IDE that provides good support for automatically generating stubs for methods. Generate Method Stub is an IntelliSense Automatic Code Generation feature that provides an easy way to have Visual Studio create a new method declaration at the time you are writing a method call. Visual Studio infers the declaration from the call. Some programming styles, such as test-driven development, suggest that you should consume before you define. That way, it is easier to figure out the form of the API that you are developing. You can use IntelliSense to program in that style. Using the Generate Method Stub operation, you avoid defining everything before you consume it.

The Generate Method Stub IntelliSense operation can also increase productivity because you do not need to move from the calling code, your present focus, to the defining code, a separate focus, in order to generate a new method. You can instead write a method call, and then invoke the Generate Method Stub operation without dividing your attention.

CSC/ECE 517 Fall 2012/ch2a 2w13 sm

2012-10-26T22:15:48Z

Svmankar: /* Java */

==Introduction==
Test stubs are programs which simulate the behaviors of software components (or modules) that are depended upon modules of the module being tested.
Stubs are replacements for missing components that the components being tested will call as part of the test. While doing an Integration , If we dont have all the modules get ready and Need to test a particualr module which is ready then We Use Stubs and Drivers.
Stubs are used in Integration testing for a Top Down Integration testing and Botton Up Integration Testing.
For Eg: If we have Modules x,y,z . X module is ready and Need to Test it , But it calls functions from y and z.(Which are not ready)To test this particular module we can write a Small Dummy piece of code which Simulates Y and Z Which will return values that X expects. This piece of Dummy code is Called a Stub in a Top Down Integration
So Stubs are called Functions in Top Down Integration.

==Stubs in different phases of testing==
===Unit Testing===
===Functional Testing===
===Integration Testing===
Integration testing is a logical extension of unit testing. In its simplest form, two units that have already been tested are combined into a component and the interface between them is tested. A component, in this sense, refers to an integrated aggregate of more than one unit. In a realistic scenario, many units are combined into components, which are in turn aggregated into even larger parts of the program. The idea is to test combinations of pieces and eventually expand the process to test your modules with those of other groups. Eventually all the modules making up a process are tested together. Beyond that, if the program is composed of more than one process, they should be tested in pairs rather than all at once.
Integration testing identifies problems that occur when units are combined. By using a test plan that requires you to test each unit and ensure the viability of each before combining units, you know that any errors discovered when combining units are likely related to the interface between units. This method reduces the number of possibilities to a far simpler level of analysis.
The top-down approach to integration testing requires the highest-level modules be test and integrated first. This allows high-level logic and data flow to be tested early in the process and it tends to minimize the need for drivers. However, the need for stubs complicates test management and low-level utilities are tested relatively late in the development cycle. Another disadvantage of top-down integration testing is its poor support for early release of limited functionality.

===Regression Testing===
Regression testing is any type of software testing that seeks to uncover new software bugs, or regressions, in existing functional and non-functional areas of a system after changes, such as enhancements, patches or configuration changes, have been made to them.
The intent of regression testing is to ensure that a change, such as a bugfix, did not introduce new faults.[1] One of the main reasons for regression testing is to determine whether a change in one part of the software affects other parts of the software.[2]
Common methods of regression testing include rerunning previously run tests and checking whether program behavior has changed and whether previously fixed faults have re-emerged. Regression testing can be used to test a system efficiently by systematically selecting the appropriate minimum set of tests needed to adequately cover a particular change.
In Regression testing the use of test stubs is minimized as most of the system is already implemented and the main goal of the regression test is to see if there are any bugs that might have been ‘regressed’ from the previous stages of integrations. Ideally there will not be unimplemented modules by the time a system is tested for regression. However, in case of mutually exclusive modules of a system, a test stub for one of them can be used to test the regression of the other.

==Stubs in software development methodologies==
===Agile Development Methodology===
Agile software development is a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change. It is a conceptual framework that promotes foreseen interactions throughout the development cycle.
In such a development system, it recognizes that testing is not a separate phase, but an integral part of software development, along with coding. Agile testing is a software testing practice that follows the principles of agile software development. Agile testing involves all members of a cross-functional agile team, with special expertise contributed by testers, to ensure delivering the business value desired by the customer at frequent intervals, working at a sustainable pace. Specification by example, also known as acceptance test-driven development, is used to capture examples of desired and undesired behavior and guide coding.
In the agile testing toolkit, a stub is a piece of code that behaves in a predefined way, in order to simplify the testing process. Here are the kind of simplifications that a stub can bring:
• if the code under test never returns the same value (usage of a timestamp or of a random value), a stub can be used to fix the root of the undeterminism
• if the code depends on some other class that has complex behaviour that you don’t want to take into account in this test, using a stub for this other class can simplify its behaviour and clarify the intent of the test
• if the code depends on some other code that is not yet written or released, it is possible to start building the rest of the code before the dependency is actualy finished.

==Examples of Stubs==
===Java===
In Java, the basic technique is to implement the stub collaborators as concrete classes which only exhibit the small part of the overall behaviour of the collaborator which is needed by the class under test. As an example consider the case where a service implementation is under test. The implementation has a collaborator:

<code>
public class SimpleService implements Service {

private Collaborator collaborator;
public void setCollaborator(Collaborator collaborator) {
this.collaborator = collaborator;
}

// part of Service interface
public boolean isActive() {
return collaborator.isActive();
}
}
</code>

We could have a stub collaborator for testing as defined below:

[code]
public class StubCollaboratorAdapter implements Collaborator {
public boolean isActive() {
return false;
}
}
[/code]

Now, a test case can be written as something like this:

[code]
public void testActiveWhenCollaboratorIsActive() throws Exception {

Service service = new SimpleService();
service.setCollaborator(new StubCollaboratorAdapter() {
public boolean isActive() {
return true;
}
});
assertTrue(service.isActive());

}
[/code]

===Ruby===
While writing stubs, one might decide to replace a whole object or simply change the results of a single method. When you're replacing a whole object, it's easy—just write the new object and replace it within your test case. Methods might be tougher in some languages, but using dynamic languages such as Ruby, stubbing is easy because you're simply redefining a method.
Imagine you have a user interface that prints a document. You want to test code that handles a print failure. You really don't care if the print method gets called. You just want to verify that if your code does call print, that code will handle a failed print effectively. Think of what a pseudo-code sentence would look like.
On an instance of the document object, stub the print method, returning false.
You can break that sentence down into two parts. The first part identifies what you want to stub. The second part defines what the stub should do.
Below is an example of the Mocha framework that can be used to build stubs in Ruby:
class Document
def print
# doesn't matter -- we are stubbing it out
end
end

class View
attr :document

def initialize(document)
@document = document
end

def print()
if document.print
puts "Excellent!"
true
else
puts "Bummer."
false
end
end
end

Test code can be written as follows:
require 'test/unit'
require 'rubygems'
require 'mocha'
require 'document'

class ViewTest < Test::Unit::TestCase

def test_should_return_false_for_failed_print
document = stub("my document")
document.stubs(:print).returns(false)

ui = View.new(document)
assert_equal false, ui.print
end

end

You can see how this works. I build a simple, named stub object with the statement stub("my document"). Then, I define the behavior for print within the stub with the line of code document.stubs(:print).returns(false). If you look carefully, this line of code looks remarkably similar to the pseudo-code from earlier:
On an instance of the document object, stub the print method, returning false.

===Python===

==IDE support for Stubs==
===Eclipse===
===RubyMine===
The most basic way to create test templates in RubyMine is to use the regular procedure of creating files in the project. This means is both available for both plain Ruby projets, and for the Rails applications, and allows creating stub tests for Test::Unit, RSpec and Test-Spec.

For RSpec and Test-Spec, RubyMine provides a number of generators. These generators are context sensitive and become available depending on the selected location, and on the gems activated for your project. For example, ir rspec-rails is activated, the usual generators are hidden, and the list of generators includes only those specific for RSpec.

===Visual Studio===
Visual Studio is a fine IDE that provides good support for automatically generating stubs for methods. Generate Method Stub is an IntelliSense Automatic Code Generation feature that provides an easy way to have Visual Studio create a new method declaration at the time you are writing a method call. Visual Studio infers the declaration from the call. Some programming styles, such as test-driven development, suggest that you should consume before you define. That way, it is easier to figure out the form of the API that you are developing. You can use IntelliSense to program in that style. Using the Generate Method Stub operation, you avoid defining everything before you consume it.

The Generate Method Stub IntelliSense operation can also increase productivity because you do not need to move from the calling code, your present focus, to the defining code, a separate focus, in order to generate a new method. You can instead write a method call, and then invoke the Generate Method Stub operation without dividing your attention.

CSC/ECE 517 Fall 2012/ch2a 2w13 sm

2012-10-26T22:15:07Z

Svmankar: /* Java */

==Introduction==
Test stubs are programs which simulate the behaviors of software components (or modules) that are depended upon modules of the module being tested.
Stubs are replacements for missing components that the components being tested will call as part of the test. While doing an Integration , If we dont have all the modules get ready and Need to test a particualr module which is ready then We Use Stubs and Drivers.
Stubs are used in Integration testing for a Top Down Integration testing and Botton Up Integration Testing.
For Eg: If we have Modules x,y,z . X module is ready and Need to Test it , But it calls functions from y and z.(Which are not ready)To test this particular module we can write a Small Dummy piece of code which Simulates Y and Z Which will return values that X expects. This piece of Dummy code is Called a Stub in a Top Down Integration
So Stubs are called Functions in Top Down Integration.

==Stubs in different phases of testing==
===Unit Testing===
===Functional Testing===
===Integration Testing===
Integration testing is a logical extension of unit testing. In its simplest form, two units that have already been tested are combined into a component and the interface between them is tested. A component, in this sense, refers to an integrated aggregate of more than one unit. In a realistic scenario, many units are combined into components, which are in turn aggregated into even larger parts of the program. The idea is to test combinations of pieces and eventually expand the process to test your modules with those of other groups. Eventually all the modules making up a process are tested together. Beyond that, if the program is composed of more than one process, they should be tested in pairs rather than all at once.
Integration testing identifies problems that occur when units are combined. By using a test plan that requires you to test each unit and ensure the viability of each before combining units, you know that any errors discovered when combining units are likely related to the interface between units. This method reduces the number of possibilities to a far simpler level of analysis.
The top-down approach to integration testing requires the highest-level modules be test and integrated first. This allows high-level logic and data flow to be tested early in the process and it tends to minimize the need for drivers. However, the need for stubs complicates test management and low-level utilities are tested relatively late in the development cycle. Another disadvantage of top-down integration testing is its poor support for early release of limited functionality.

===Regression Testing===
Regression testing is any type of software testing that seeks to uncover new software bugs, or regressions, in existing functional and non-functional areas of a system after changes, such as enhancements, patches or configuration changes, have been made to them.
The intent of regression testing is to ensure that a change, such as a bugfix, did not introduce new faults.[1] One of the main reasons for regression testing is to determine whether a change in one part of the software affects other parts of the software.[2]
Common methods of regression testing include rerunning previously run tests and checking whether program behavior has changed and whether previously fixed faults have re-emerged. Regression testing can be used to test a system efficiently by systematically selecting the appropriate minimum set of tests needed to adequately cover a particular change.
In Regression testing the use of test stubs is minimized as most of the system is already implemented and the main goal of the regression test is to see if there are any bugs that might have been ‘regressed’ from the previous stages of integrations. Ideally there will not be unimplemented modules by the time a system is tested for regression. However, in case of mutually exclusive modules of a system, a test stub for one of them can be used to test the regression of the other.

==Stubs in software development methodologies==
===Agile Development Methodology===
Agile software development is a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change. It is a conceptual framework that promotes foreseen interactions throughout the development cycle.
In such a development system, it recognizes that testing is not a separate phase, but an integral part of software development, along with coding. Agile testing is a software testing practice that follows the principles of agile software development. Agile testing involves all members of a cross-functional agile team, with special expertise contributed by testers, to ensure delivering the business value desired by the customer at frequent intervals, working at a sustainable pace. Specification by example, also known as acceptance test-driven development, is used to capture examples of desired and undesired behavior and guide coding.
In the agile testing toolkit, a stub is a piece of code that behaves in a predefined way, in order to simplify the testing process. Here are the kind of simplifications that a stub can bring:
• if the code under test never returns the same value (usage of a timestamp or of a random value), a stub can be used to fix the root of the undeterminism
• if the code depends on some other class that has complex behaviour that you don’t want to take into account in this test, using a stub for this other class can simplify its behaviour and clarify the intent of the test
• if the code depends on some other code that is not yet written or released, it is possible to start building the rest of the code before the dependency is actualy finished.

==Examples of Stubs==
===Java===
In Java, the basic technique is to implement the stub collaborators as concrete classes which only exhibit the small part of the overall behaviour of the collaborator which is needed by the class under test. As an example consider the case where a service implementation is under test. The implementation has a collaborator:
<code>
public class SimpleService implements Service {

private Collaborator collaborator;
public void setCollaborator(Collaborator collaborator) {
this.collaborator = collaborator;
}

// part of Service interface
public boolean isActive() {
return collaborator.isActive();
}
}
</code>
We could have a stub collaborator for testing as defined below:
[code]
public class StubCollaboratorAdapter implements Collaborator {
public boolean isActive() {
return false;
}
}
[/code]
Now, a test case can be written as something like this:
[code]
public void testActiveWhenCollaboratorIsActive() throws Exception {

Service service = new SimpleService();
service.setCollaborator(new StubCollaboratorAdapter() {
public boolean isActive() {
return true;
}
});
assertTrue(service.isActive());

}
[/code]

===Ruby===
While writing stubs, one might decide to replace a whole object or simply change the results of a single method. When you're replacing a whole object, it's easy—just write the new object and replace it within your test case. Methods might be tougher in some languages, but using dynamic languages such as Ruby, stubbing is easy because you're simply redefining a method.
Imagine you have a user interface that prints a document. You want to test code that handles a print failure. You really don't care if the print method gets called. You just want to verify that if your code does call print, that code will handle a failed print effectively. Think of what a pseudo-code sentence would look like.
On an instance of the document object, stub the print method, returning false.
You can break that sentence down into two parts. The first part identifies what you want to stub. The second part defines what the stub should do.
Below is an example of the Mocha framework that can be used to build stubs in Ruby:
class Document
def print
# doesn't matter -- we are stubbing it out
end
end

class View
attr :document

def initialize(document)
@document = document
end

def print()
if document.print
puts "Excellent!"
true
else
puts "Bummer."
false
end
end
end

Test code can be written as follows:
require 'test/unit'
require 'rubygems'
require 'mocha'
require 'document'

class ViewTest < Test::Unit::TestCase

def test_should_return_false_for_failed_print
document = stub("my document")
document.stubs(:print).returns(false)

ui = View.new(document)
assert_equal false, ui.print
end

end

You can see how this works. I build a simple, named stub object with the statement stub("my document"). Then, I define the behavior for print within the stub with the line of code document.stubs(:print).returns(false). If you look carefully, this line of code looks remarkably similar to the pseudo-code from earlier:
On an instance of the document object, stub the print method, returning false.

===Python===

==IDE support for Stubs==
===Eclipse===
===RubyMine===
The most basic way to create test templates in RubyMine is to use the regular procedure of creating files in the project. This means is both available for both plain Ruby projets, and for the Rails applications, and allows creating stub tests for Test::Unit, RSpec and Test-Spec.

For RSpec and Test-Spec, RubyMine provides a number of generators. These generators are context sensitive and become available depending on the selected location, and on the gems activated for your project. For example, ir rspec-rails is activated, the usual generators are hidden, and the list of generators includes only those specific for RSpec.

===Visual Studio===
Visual Studio is a fine IDE that provides good support for automatically generating stubs for methods. Generate Method Stub is an IntelliSense Automatic Code Generation feature that provides an easy way to have Visual Studio create a new method declaration at the time you are writing a method call. Visual Studio infers the declaration from the call. Some programming styles, such as test-driven development, suggest that you should consume before you define. That way, it is easier to figure out the form of the API that you are developing. You can use IntelliSense to program in that style. Using the Generate Method Stub operation, you avoid defining everything before you consume it.

The Generate Method Stub IntelliSense operation can also increase productivity because you do not need to move from the calling code, your present focus, to the defining code, a separate focus, in order to generate a new method. You can instead write a method call, and then invoke the Generate Method Stub operation without dividing your attention.

CSC/ECE 517 Fall 2012/ch2a 2w13 sm

2012-10-26T22:13:33Z

Svmankar: /* Java */

==Introduction==
Test stubs are programs which simulate the behaviors of software components (or modules) that are depended upon modules of the module being tested.
Stubs are replacements for missing components that the components being tested will call as part of the test. While doing an Integration , If we dont have all the modules get ready and Need to test a particualr module which is ready then We Use Stubs and Drivers.
Stubs are used in Integration testing for a Top Down Integration testing and Botton Up Integration Testing.
For Eg: If we have Modules x,y,z . X module is ready and Need to Test it , But it calls functions from y and z.(Which are not ready)To test this particular module we can write a Small Dummy piece of code which Simulates Y and Z Which will return values that X expects. This piece of Dummy code is Called a Stub in a Top Down Integration
So Stubs are called Functions in Top Down Integration.

==Stubs in different phases of testing==
===Unit Testing===
===Functional Testing===
===Integration Testing===
Integration testing is a logical extension of unit testing. In its simplest form, two units that have already been tested are combined into a component and the interface between them is tested. A component, in this sense, refers to an integrated aggregate of more than one unit. In a realistic scenario, many units are combined into components, which are in turn aggregated into even larger parts of the program. The idea is to test combinations of pieces and eventually expand the process to test your modules with those of other groups. Eventually all the modules making up a process are tested together. Beyond that, if the program is composed of more than one process, they should be tested in pairs rather than all at once.
Integration testing identifies problems that occur when units are combined. By using a test plan that requires you to test each unit and ensure the viability of each before combining units, you know that any errors discovered when combining units are likely related to the interface between units. This method reduces the number of possibilities to a far simpler level of analysis.
The top-down approach to integration testing requires the highest-level modules be test and integrated first. This allows high-level logic and data flow to be tested early in the process and it tends to minimize the need for drivers. However, the need for stubs complicates test management and low-level utilities are tested relatively late in the development cycle. Another disadvantage of top-down integration testing is its poor support for early release of limited functionality.

===Regression Testing===
Regression testing is any type of software testing that seeks to uncover new software bugs, or regressions, in existing functional and non-functional areas of a system after changes, such as enhancements, patches or configuration changes, have been made to them.
The intent of regression testing is to ensure that a change, such as a bugfix, did not introduce new faults.[1] One of the main reasons for regression testing is to determine whether a change in one part of the software affects other parts of the software.[2]
Common methods of regression testing include rerunning previously run tests and checking whether program behavior has changed and whether previously fixed faults have re-emerged. Regression testing can be used to test a system efficiently by systematically selecting the appropriate minimum set of tests needed to adequately cover a particular change.
In Regression testing the use of test stubs is minimized as most of the system is already implemented and the main goal of the regression test is to see if there are any bugs that might have been ‘regressed’ from the previous stages of integrations. Ideally there will not be unimplemented modules by the time a system is tested for regression. However, in case of mutually exclusive modules of a system, a test stub for one of them can be used to test the regression of the other.

==Stubs in software development methodologies==
===Agile Development Methodology===
Agile software development is a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change. It is a conceptual framework that promotes foreseen interactions throughout the development cycle.
In such a development system, it recognizes that testing is not a separate phase, but an integral part of software development, along with coding. Agile testing is a software testing practice that follows the principles of agile software development. Agile testing involves all members of a cross-functional agile team, with special expertise contributed by testers, to ensure delivering the business value desired by the customer at frequent intervals, working at a sustainable pace. Specification by example, also known as acceptance test-driven development, is used to capture examples of desired and undesired behavior and guide coding.
In the agile testing toolkit, a stub is a piece of code that behaves in a predefined way, in order to simplify the testing process. Here are the kind of simplifications that a stub can bring:
• if the code under test never returns the same value (usage of a timestamp or of a random value), a stub can be used to fix the root of the undeterminism
• if the code depends on some other class that has complex behaviour that you don’t want to take into account in this test, using a stub for this other class can simplify its behaviour and clarify the intent of the test
• if the code depends on some other code that is not yet written or released, it is possible to start building the rest of the code before the dependency is actualy finished.

==Examples of Stubs==
===Java===
In Java, the basic technique is to implement the stub collaborators as concrete classes which only exhibit the small part of the overall behaviour of the collaborator which is needed by the class under test. As an example consider the case where a service implementation is under test. The implementation has a collaborator:
[code]
public class SimpleService implements Service {

private Collaborator collaborator;
public void setCollaborator(Collaborator collaborator) {
this.collaborator = collaborator;
}

// part of Service interface
public boolean isActive() {
return collaborator.isActive();
}
}
[/code]
We could have a stub collaborator for testing as defined below:
[code]
public class StubCollaboratorAdapter implements Collaborator {
public boolean isActive() {
return false;
}
}
[/code]
Now, a test case can be written as something like this:
[code]
public void testActiveWhenCollaboratorIsActive() throws Exception {

Service service = new SimpleService();
service.setCollaborator(new StubCollaboratorAdapter() {
public boolean isActive() {
return true;
}
});
assertTrue(service.isActive());

}
[/code]

===Ruby===
While writing stubs, one might decide to replace a whole object or simply change the results of a single method. When you're replacing a whole object, it's easy—just write the new object and replace it within your test case. Methods might be tougher in some languages, but using dynamic languages such as Ruby, stubbing is easy because you're simply redefining a method.
Imagine you have a user interface that prints a document. You want to test code that handles a print failure. You really don't care if the print method gets called. You just want to verify that if your code does call print, that code will handle a failed print effectively. Think of what a pseudo-code sentence would look like.
On an instance of the document object, stub the print method, returning false.
You can break that sentence down into two parts. The first part identifies what you want to stub. The second part defines what the stub should do.
Below is an example of the Mocha framework that can be used to build stubs in Ruby:
class Document
def print
# doesn't matter -- we are stubbing it out
end
end

class View
attr :document

def initialize(document)
@document = document
end

def print()
if document.print
puts "Excellent!"
true
else
puts "Bummer."
false
end
end
end

Test code can be written as follows:
require 'test/unit'
require 'rubygems'
require 'mocha'
require 'document'

class ViewTest < Test::Unit::TestCase

def test_should_return_false_for_failed_print
document = stub("my document")
document.stubs(:print).returns(false)

ui = View.new(document)
assert_equal false, ui.print
end

end

You can see how this works. I build a simple, named stub object with the statement stub("my document"). Then, I define the behavior for print within the stub with the line of code document.stubs(:print).returns(false). If you look carefully, this line of code looks remarkably similar to the pseudo-code from earlier:
On an instance of the document object, stub the print method, returning false.

===Python===

==IDE support for Stubs==
===Eclipse===
===RubyMine===
The most basic way to create test templates in RubyMine is to use the regular procedure of creating files in the project. This means is both available for both plain Ruby projets, and for the Rails applications, and allows creating stub tests for Test::Unit, RSpec and Test-Spec.

For RSpec and Test-Spec, RubyMine provides a number of generators. These generators are context sensitive and become available depending on the selected location, and on the gems activated for your project. For example, ir rspec-rails is activated, the usual generators are hidden, and the list of generators includes only those specific for RSpec.

===Visual Studio===
Visual Studio is a fine IDE that provides good support for automatically generating stubs for methods. Generate Method Stub is an IntelliSense Automatic Code Generation feature that provides an easy way to have Visual Studio create a new method declaration at the time you are writing a method call. Visual Studio infers the declaration from the call. Some programming styles, such as test-driven development, suggest that you should consume before you define. That way, it is easier to figure out the form of the API that you are developing. You can use IntelliSense to program in that style. Using the Generate Method Stub operation, you avoid defining everything before you consume it.

The Generate Method Stub IntelliSense operation can also increase productivity because you do not need to move from the calling code, your present focus, to the defining code, a separate focus, in order to generate a new method. You can instead write a method call, and then invoke the Generate Method Stub operation without dividing your attention.

CSC/ECE 517 Fall 2012/ch2a 2w13 sm

2012-10-26T22:11:45Z

Svmankar: /* RubyMine */

==Introduction==
Test stubs are programs which simulate the behaviors of software components (or modules) that are depended upon modules of the module being tested.
Stubs are replacements for missing components that the components being tested will call as part of the test. While doing an Integration , If we dont have all the modules get ready and Need to test a particualr module which is ready then We Use Stubs and Drivers.
Stubs are used in Integration testing for a Top Down Integration testing and Botton Up Integration Testing.
For Eg: If we have Modules x,y,z . X module is ready and Need to Test it , But it calls functions from y and z.(Which are not ready)To test this particular module we can write a Small Dummy piece of code which Simulates Y and Z Which will return values that X expects. This piece of Dummy code is Called a Stub in a Top Down Integration
So Stubs are called Functions in Top Down Integration.

==Stubs in different phases of testing==
===Unit Testing===
===Functional Testing===
===Integration Testing===
Integration testing is a logical extension of unit testing. In its simplest form, two units that have already been tested are combined into a component and the interface between them is tested. A component, in this sense, refers to an integrated aggregate of more than one unit. In a realistic scenario, many units are combined into components, which are in turn aggregated into even larger parts of the program. The idea is to test combinations of pieces and eventually expand the process to test your modules with those of other groups. Eventually all the modules making up a process are tested together. Beyond that, if the program is composed of more than one process, they should be tested in pairs rather than all at once.
Integration testing identifies problems that occur when units are combined. By using a test plan that requires you to test each unit and ensure the viability of each before combining units, you know that any errors discovered when combining units are likely related to the interface between units. This method reduces the number of possibilities to a far simpler level of analysis.
The top-down approach to integration testing requires the highest-level modules be test and integrated first. This allows high-level logic and data flow to be tested early in the process and it tends to minimize the need for drivers. However, the need for stubs complicates test management and low-level utilities are tested relatively late in the development cycle. Another disadvantage of top-down integration testing is its poor support for early release of limited functionality.

===Regression Testing===
Regression testing is any type of software testing that seeks to uncover new software bugs, or regressions, in existing functional and non-functional areas of a system after changes, such as enhancements, patches or configuration changes, have been made to them.
The intent of regression testing is to ensure that a change, such as a bugfix, did not introduce new faults.[1] One of the main reasons for regression testing is to determine whether a change in one part of the software affects other parts of the software.[2]
Common methods of regression testing include rerunning previously run tests and checking whether program behavior has changed and whether previously fixed faults have re-emerged. Regression testing can be used to test a system efficiently by systematically selecting the appropriate minimum set of tests needed to adequately cover a particular change.
In Regression testing the use of test stubs is minimized as most of the system is already implemented and the main goal of the regression test is to see if there are any bugs that might have been ‘regressed’ from the previous stages of integrations. Ideally there will not be unimplemented modules by the time a system is tested for regression. However, in case of mutually exclusive modules of a system, a test stub for one of them can be used to test the regression of the other.

==Stubs in software development methodologies==
===Agile Development Methodology===
Agile software development is a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change. It is a conceptual framework that promotes foreseen interactions throughout the development cycle.
In such a development system, it recognizes that testing is not a separate phase, but an integral part of software development, along with coding. Agile testing is a software testing practice that follows the principles of agile software development. Agile testing involves all members of a cross-functional agile team, with special expertise contributed by testers, to ensure delivering the business value desired by the customer at frequent intervals, working at a sustainable pace. Specification by example, also known as acceptance test-driven development, is used to capture examples of desired and undesired behavior and guide coding.
In the agile testing toolkit, a stub is a piece of code that behaves in a predefined way, in order to simplify the testing process. Here are the kind of simplifications that a stub can bring:
• if the code under test never returns the same value (usage of a timestamp or of a random value), a stub can be used to fix the root of the undeterminism
• if the code depends on some other class that has complex behaviour that you don’t want to take into account in this test, using a stub for this other class can simplify its behaviour and clarify the intent of the test
• if the code depends on some other code that is not yet written or released, it is possible to start building the rest of the code before the dependency is actualy finished.

==Examples of Stubs==
===Java===
In Java, the basic technique is to implement the stub collaborators as concrete classes which only exhibit the small part of the overall behaviour of the collaborator which is needed by the class under test. As an example consider the case where a service implementation is under test. The implementation has a collaborator:
public class SimpleService implements Service {

private Collaborator collaborator;
public void setCollaborator(Collaborator collaborator) {
this.collaborator = collaborator;
}

// part of Service interface
public boolean isActive() {
return collaborator.isActive();
}
}

We could have a stub collaborator for testing as defined below:
public class StubCollaboratorAdapter implements Collaborator {
public boolean isActive() {
return false;
}
}
Now, a test case can be written as something like this:
public void testActiveWhenCollaboratorIsActive() throws Exception {

Service service = new SimpleService();
service.setCollaborator(new StubCollaboratorAdapter() {
public boolean isActive() {
return true;
}
});
assertTrue(service.isActive());

}

===Ruby===
While writing stubs, one might decide to replace a whole object or simply change the results of a single method. When you're replacing a whole object, it's easy—just write the new object and replace it within your test case. Methods might be tougher in some languages, but using dynamic languages such as Ruby, stubbing is easy because you're simply redefining a method.
Imagine you have a user interface that prints a document. You want to test code that handles a print failure. You really don't care if the print method gets called. You just want to verify that if your code does call print, that code will handle a failed print effectively. Think of what a pseudo-code sentence would look like.
On an instance of the document object, stub the print method, returning false.
You can break that sentence down into two parts. The first part identifies what you want to stub. The second part defines what the stub should do.
Below is an example of the Mocha framework that can be used to build stubs in Ruby:
class Document
def print
# doesn't matter -- we are stubbing it out
end
end

class View
attr :document

def initialize(document)
@document = document
end

def print()
if document.print
puts "Excellent!"
true
else
puts "Bummer."
false
end
end
end

Test code can be written as follows:
require 'test/unit'
require 'rubygems'
require 'mocha'
require 'document'

class ViewTest < Test::Unit::TestCase

def test_should_return_false_for_failed_print
document = stub("my document")
document.stubs(:print).returns(false)

ui = View.new(document)
assert_equal false, ui.print
end

end

You can see how this works. I build a simple, named stub object with the statement stub("my document"). Then, I define the behavior for print within the stub with the line of code document.stubs(:print).returns(false). If you look carefully, this line of code looks remarkably similar to the pseudo-code from earlier:
On an instance of the document object, stub the print method, returning false.

===Python===

==IDE support for Stubs==
===Eclipse===
===RubyMine===
The most basic way to create test templates in RubyMine is to use the regular procedure of creating files in the project. This means is both available for both plain Ruby projets, and for the Rails applications, and allows creating stub tests for Test::Unit, RSpec and Test-Spec.

For RSpec and Test-Spec, RubyMine provides a number of generators. These generators are context sensitive and become available depending on the selected location, and on the gems activated for your project. For example, ir rspec-rails is activated, the usual generators are hidden, and the list of generators includes only those specific for RSpec.

===Visual Studio===
Visual Studio is a fine IDE that provides good support for automatically generating stubs for methods. Generate Method Stub is an IntelliSense Automatic Code Generation feature that provides an easy way to have Visual Studio create a new method declaration at the time you are writing a method call. Visual Studio infers the declaration from the call. Some programming styles, such as test-driven development, suggest that you should consume before you define. That way, it is easier to figure out the form of the API that you are developing. You can use IntelliSense to program in that style. Using the Generate Method Stub operation, you avoid defining everything before you consume it.

The Generate Method Stub IntelliSense operation can also increase productivity because you do not need to move from the calling code, your present focus, to the defining code, a separate focus, in order to generate a new method. You can instead write a method call, and then invoke the Generate Method Stub operation without dividing your attention.

CSC/ECE 517 Fall 2012/ch2a 2w13 sm

2012-10-26T21:40:28Z

Svmankar: /* Visual Studio */

==Introduction==
Test stubs are programs which simulate the behaviors of software components (or modules) that are depended upon modules of the module being tested.
Stubs are replacements for missing components that the components being tested will call as part of the test. While doing an Integration , If we dont have all the modules get ready and Need to test a particualr module which is ready then We Use Stubs and Drivers.
Stubs are used in Integration testing for a Top Down Integration testing and Botton Up Integration Testing.
For Eg: If we have Modules x,y,z . X module is ready and Need to Test it , But it calls functions from y and z.(Which are not ready)To test this particular module we can write a Small Dummy piece of code which Simulates Y and Z Which will return values that X expects. This piece of Dummy code is Called a Stub in a Top Down Integration
So Stubs are called Functions in Top Down Integration.

==Stubs in different phases of testing==
===Unit Testing===
===Functional Testing===
===Integration Testing===
Integration testing is a logical extension of unit testing. In its simplest form, two units that have already been tested are combined into a component and the interface between them is tested. A component, in this sense, refers to an integrated aggregate of more than one unit. In a realistic scenario, many units are combined into components, which are in turn aggregated into even larger parts of the program. The idea is to test combinations of pieces and eventually expand the process to test your modules with those of other groups. Eventually all the modules making up a process are tested together. Beyond that, if the program is composed of more than one process, they should be tested in pairs rather than all at once.
Integration testing identifies problems that occur when units are combined. By using a test plan that requires you to test each unit and ensure the viability of each before combining units, you know that any errors discovered when combining units are likely related to the interface between units. This method reduces the number of possibilities to a far simpler level of analysis.
The top-down approach to integration testing requires the highest-level modules be test and integrated first. This allows high-level logic and data flow to be tested early in the process and it tends to minimize the need for drivers. However, the need for stubs complicates test management and low-level utilities are tested relatively late in the development cycle. Another disadvantage of top-down integration testing is its poor support for early release of limited functionality.

===Regression Testing===
Regression testing is any type of software testing that seeks to uncover new software bugs, or regressions, in existing functional and non-functional areas of a system after changes, such as enhancements, patches or configuration changes, have been made to them.
The intent of regression testing is to ensure that a change, such as a bugfix, did not introduce new faults.[1] One of the main reasons for regression testing is to determine whether a change in one part of the software affects other parts of the software.[2]
Common methods of regression testing include rerunning previously run tests and checking whether program behavior has changed and whether previously fixed faults have re-emerged. Regression testing can be used to test a system efficiently by systematically selecting the appropriate minimum set of tests needed to adequately cover a particular change.
In Regression testing the use of test stubs is minimized as most of the system is already implemented and the main goal of the regression test is to see if there are any bugs that might have been ‘regressed’ from the previous stages of integrations. Ideally there will not be unimplemented modules by the time a system is tested for regression. However, in case of mutually exclusive modules of a system, a test stub for one of them can be used to test the regression of the other.

==Stubs in software development methodologies==
===Agile Development Methodology===
Agile software development is a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change. It is a conceptual framework that promotes foreseen interactions throughout the development cycle.
In such a development system, it recognizes that testing is not a separate phase, but an integral part of software development, along with coding. Agile testing is a software testing practice that follows the principles of agile software development. Agile testing involves all members of a cross-functional agile team, with special expertise contributed by testers, to ensure delivering the business value desired by the customer at frequent intervals, working at a sustainable pace. Specification by example, also known as acceptance test-driven development, is used to capture examples of desired and undesired behavior and guide coding.
In the agile testing toolkit, a stub is a piece of code that behaves in a predefined way, in order to simplify the testing process. Here are the kind of simplifications that a stub can bring:
• if the code under test never returns the same value (usage of a timestamp or of a random value), a stub can be used to fix the root of the undeterminism
• if the code depends on some other class that has complex behaviour that you don’t want to take into account in this test, using a stub for this other class can simplify its behaviour and clarify the intent of the test
• if the code depends on some other code that is not yet written or released, it is possible to start building the rest of the code before the dependency is actualy finished.

==Examples of Stubs==
===Java===
In Java, the basic technique is to implement the stub collaborators as concrete classes which only exhibit the small part of the overall behaviour of the collaborator which is needed by the class under test. As an example consider the case where a service implementation is under test. The implementation has a collaborator:
public class SimpleService implements Service {

private Collaborator collaborator;
public void setCollaborator(Collaborator collaborator) {
this.collaborator = collaborator;
}

// part of Service interface
public boolean isActive() {
return collaborator.isActive();
}
}

We could have a stub collaborator for testing as defined below:
public class StubCollaboratorAdapter implements Collaborator {
public boolean isActive() {
return false;
}
}
Now, a test case can be written as something like this:
public void testActiveWhenCollaboratorIsActive() throws Exception {

Service service = new SimpleService();
service.setCollaborator(new StubCollaboratorAdapter() {
public boolean isActive() {
return true;
}
});
assertTrue(service.isActive());

}

===Ruby===
While writing stubs, one might decide to replace a whole object or simply change the results of a single method. When you're replacing a whole object, it's easy—just write the new object and replace it within your test case. Methods might be tougher in some languages, but using dynamic languages such as Ruby, stubbing is easy because you're simply redefining a method.
Imagine you have a user interface that prints a document. You want to test code that handles a print failure. You really don't care if the print method gets called. You just want to verify that if your code does call print, that code will handle a failed print effectively. Think of what a pseudo-code sentence would look like.
On an instance of the document object, stub the print method, returning false.
You can break that sentence down into two parts. The first part identifies what you want to stub. The second part defines what the stub should do.
Below is an example of the Mocha framework that can be used to build stubs in Ruby:
class Document
def print
# doesn't matter -- we are stubbing it out
end
end

class View
attr :document

def initialize(document)
@document = document
end

def print()
if document.print
puts "Excellent!"
true
else
puts "Bummer."
false
end
end
end

Test code can be written as follows:
require 'test/unit'
require 'rubygems'
require 'mocha'
require 'document'

class ViewTest < Test::Unit::TestCase

def test_should_return_false_for_failed_print
document = stub("my document")
document.stubs(:print).returns(false)

ui = View.new(document)
assert_equal false, ui.print
end

end

You can see how this works. I build a simple, named stub object with the statement stub("my document"). Then, I define the behavior for print within the stub with the line of code document.stubs(:print).returns(false). If you look carefully, this line of code looks remarkably similar to the pseudo-code from earlier:
On an instance of the document object, stub the print method, returning false.

===Python===

==IDE support for Stubs==
===Eclipse===
===RubyMine===
===Visual Studio===
Visual Studio is a fine IDE that provides good support for automatically generating stubs for methods. Generate Method Stub is an IntelliSense Automatic Code Generation feature that provides an easy way to have Visual Studio create a new method declaration at the time you are writing a method call. Visual Studio infers the declaration from the call. Some programming styles, such as test-driven development, suggest that you should consume before you define. That way, it is easier to figure out the form of the API that you are developing. You can use IntelliSense to program in that style. Using the Generate Method Stub operation, you avoid defining everything before you consume it.

The Generate Method Stub IntelliSense operation can also increase productivity because you do not need to move from the calling code, your present focus, to the defining code, a separate focus, in order to generate a new method. You can instead write a method call, and then invoke the Generate Method Stub operation without dividing your attention.

CSC/ECE 517 Fall 2012/ch2a 2w13 sm

2012-10-26T21:38:57Z

Svmankar: /* IDE support for Stubs */

==Introduction==
Test stubs are programs which simulate the behaviors of software components (or modules) that are depended upon modules of the module being tested.
Stubs are replacements for missing components that the components being tested will call as part of the test. While doing an Integration , If we dont have all the modules get ready and Need to test a particualr module which is ready then We Use Stubs and Drivers.
Stubs are used in Integration testing for a Top Down Integration testing and Botton Up Integration Testing.
For Eg: If we have Modules x,y,z . X module is ready and Need to Test it , But it calls functions from y and z.(Which are not ready)To test this particular module we can write a Small Dummy piece of code which Simulates Y and Z Which will return values that X expects. This piece of Dummy code is Called a Stub in a Top Down Integration
So Stubs are called Functions in Top Down Integration.

==Stubs in different phases of testing==
===Unit Testing===
===Functional Testing===
===Integration Testing===
Integration testing is a logical extension of unit testing. In its simplest form, two units that have already been tested are combined into a component and the interface between them is tested. A component, in this sense, refers to an integrated aggregate of more than one unit. In a realistic scenario, many units are combined into components, which are in turn aggregated into even larger parts of the program. The idea is to test combinations of pieces and eventually expand the process to test your modules with those of other groups. Eventually all the modules making up a process are tested together. Beyond that, if the program is composed of more than one process, they should be tested in pairs rather than all at once.
Integration testing identifies problems that occur when units are combined. By using a test plan that requires you to test each unit and ensure the viability of each before combining units, you know that any errors discovered when combining units are likely related to the interface between units. This method reduces the number of possibilities to a far simpler level of analysis.
The top-down approach to integration testing requires the highest-level modules be test and integrated first. This allows high-level logic and data flow to be tested early in the process and it tends to minimize the need for drivers. However, the need for stubs complicates test management and low-level utilities are tested relatively late in the development cycle. Another disadvantage of top-down integration testing is its poor support for early release of limited functionality.

===Regression Testing===
Regression testing is any type of software testing that seeks to uncover new software bugs, or regressions, in existing functional and non-functional areas of a system after changes, such as enhancements, patches or configuration changes, have been made to them.
The intent of regression testing is to ensure that a change, such as a bugfix, did not introduce new faults.[1] One of the main reasons for regression testing is to determine whether a change in one part of the software affects other parts of the software.[2]
Common methods of regression testing include rerunning previously run tests and checking whether program behavior has changed and whether previously fixed faults have re-emerged. Regression testing can be used to test a system efficiently by systematically selecting the appropriate minimum set of tests needed to adequately cover a particular change.
In Regression testing the use of test stubs is minimized as most of the system is already implemented and the main goal of the regression test is to see if there are any bugs that might have been ‘regressed’ from the previous stages of integrations. Ideally there will not be unimplemented modules by the time a system is tested for regression. However, in case of mutually exclusive modules of a system, a test stub for one of them can be used to test the regression of the other.

==Stubs in software development methodologies==
===Agile Development Methodology===
Agile software development is a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change. It is a conceptual framework that promotes foreseen interactions throughout the development cycle.
In such a development system, it recognizes that testing is not a separate phase, but an integral part of software development, along with coding. Agile testing is a software testing practice that follows the principles of agile software development. Agile testing involves all members of a cross-functional agile team, with special expertise contributed by testers, to ensure delivering the business value desired by the customer at frequent intervals, working at a sustainable pace. Specification by example, also known as acceptance test-driven development, is used to capture examples of desired and undesired behavior and guide coding.
In the agile testing toolkit, a stub is a piece of code that behaves in a predefined way, in order to simplify the testing process. Here are the kind of simplifications that a stub can bring:
• if the code under test never returns the same value (usage of a timestamp or of a random value), a stub can be used to fix the root of the undeterminism
• if the code depends on some other class that has complex behaviour that you don’t want to take into account in this test, using a stub for this other class can simplify its behaviour and clarify the intent of the test
• if the code depends on some other code that is not yet written or released, it is possible to start building the rest of the code before the dependency is actualy finished.

==Examples of Stubs==
===Java===
In Java, the basic technique is to implement the stub collaborators as concrete classes which only exhibit the small part of the overall behaviour of the collaborator which is needed by the class under test. As an example consider the case where a service implementation is under test. The implementation has a collaborator:
public class SimpleService implements Service {

private Collaborator collaborator;
public void setCollaborator(Collaborator collaborator) {
this.collaborator = collaborator;
}

// part of Service interface
public boolean isActive() {
return collaborator.isActive();
}
}

We could have a stub collaborator for testing as defined below:
public class StubCollaboratorAdapter implements Collaborator {
public boolean isActive() {
return false;
}
}
Now, a test case can be written as something like this:
public void testActiveWhenCollaboratorIsActive() throws Exception {

Service service = new SimpleService();
service.setCollaborator(new StubCollaboratorAdapter() {
public boolean isActive() {
return true;
}
});
assertTrue(service.isActive());

}

===Ruby===
While writing stubs, one might decide to replace a whole object or simply change the results of a single method. When you're replacing a whole object, it's easy—just write the new object and replace it within your test case. Methods might be tougher in some languages, but using dynamic languages such as Ruby, stubbing is easy because you're simply redefining a method.
Imagine you have a user interface that prints a document. You want to test code that handles a print failure. You really don't care if the print method gets called. You just want to verify that if your code does call print, that code will handle a failed print effectively. Think of what a pseudo-code sentence would look like.
On an instance of the document object, stub the print method, returning false.
You can break that sentence down into two parts. The first part identifies what you want to stub. The second part defines what the stub should do.
Below is an example of the Mocha framework that can be used to build stubs in Ruby:
class Document
def print
# doesn't matter -- we are stubbing it out
end
end

class View
attr :document

def initialize(document)
@document = document
end

def print()
if document.print
puts "Excellent!"
true
else
puts "Bummer."
false
end
end
end

Test code can be written as follows:
require 'test/unit'
require 'rubygems'
require 'mocha'
require 'document'

class ViewTest < Test::Unit::TestCase

def test_should_return_false_for_failed_print
document = stub("my document")
document.stubs(:print).returns(false)

ui = View.new(document)
assert_equal false, ui.print
end

end

You can see how this works. I build a simple, named stub object with the statement stub("my document"). Then, I define the behavior for print within the stub with the line of code document.stubs(:print).returns(false). If you look carefully, this line of code looks remarkably similar to the pseudo-code from earlier:
On an instance of the document object, stub the print method, returning false.

===Python===

==IDE support for Stubs==
===Eclipse===
===RubyMine===
===Visual Studio===
Generate Method Stub is an IntelliSense Automatic Code Generation feature that provides an easy way to have Visual Studio create a new method declaration at the time you are writing a method call. Visual Studio infers the declaration from the call.

Some programming styles, such as test-driven development, suggest that you should consume before you define. That way, it is easier to figure out the form of the API that you are developing. You can use IntelliSense to program in that style. Using the Generate Method Stub operation, you avoid defining everything before you consume it.

The Generate Method Stub IntelliSense operation can also increase productivity because you do not need to move from the calling code, your present focus, to the defining code, a separate focus, in order to generate a new method. You can instead write a method call, and then invoke the Generate Method Stub operation without dividing your attention.

CSC/ECE 517 Fall 2012/ch2a 2w13 sm

2012-10-26T20:45:31Z

Svmankar: /* Introduction */

==Introduction==
Test stubs are programs which simulate the behaviors of software components (or modules) that are depended upon modules of the module being tested.
Stubs are replacements for missing components that the components being tested will call as part of the test. While doing an Integration , If we dont have all the modules get ready and Need to test a particualr module which is ready then We Use Stubs and Drivers.
Stubs are used in Integration testing for a Top Down Integration testing and Botton Up Integration Testing.
For Eg: If we have Modules x,y,z . X module is ready and Need to Test it , But it calls functions from y and z.(Which are not ready)To test this particular module we can write a Small Dummy piece of code which Simulates Y and Z Which will return values that X expects. This piece of Dummy code is Called a Stub in a Top Down Integration
So Stubs are called Functions in Top Down Integration.

==Stubs in different phases of testing==
===Unit Testing===
===Functional Testing===
===Integration Testing===
Integration testing is a logical extension of unit testing. In its simplest form, two units that have already been tested are combined into a component and the interface between them is tested. A component, in this sense, refers to an integrated aggregate of more than one unit. In a realistic scenario, many units are combined into components, which are in turn aggregated into even larger parts of the program. The idea is to test combinations of pieces and eventually expand the process to test your modules with those of other groups. Eventually all the modules making up a process are tested together. Beyond that, if the program is composed of more than one process, they should be tested in pairs rather than all at once.
Integration testing identifies problems that occur when units are combined. By using a test plan that requires you to test each unit and ensure the viability of each before combining units, you know that any errors discovered when combining units are likely related to the interface between units. This method reduces the number of possibilities to a far simpler level of analysis.
The top-down approach to integration testing requires the highest-level modules be test and integrated first. This allows high-level logic and data flow to be tested early in the process and it tends to minimize the need for drivers. However, the need for stubs complicates test management and low-level utilities are tested relatively late in the development cycle. Another disadvantage of top-down integration testing is its poor support for early release of limited functionality.

===Regression Testing===
Regression testing is any type of software testing that seeks to uncover new software bugs, or regressions, in existing functional and non-functional areas of a system after changes, such as enhancements, patches or configuration changes, have been made to them.
The intent of regression testing is to ensure that a change, such as a bugfix, did not introduce new faults.[1] One of the main reasons for regression testing is to determine whether a change in one part of the software affects other parts of the software.[2]
Common methods of regression testing include rerunning previously run tests and checking whether program behavior has changed and whether previously fixed faults have re-emerged. Regression testing can be used to test a system efficiently by systematically selecting the appropriate minimum set of tests needed to adequately cover a particular change.
In Regression testing the use of test stubs is minimized as most of the system is already implemented and the main goal of the regression test is to see if there are any bugs that might have been ‘regressed’ from the previous stages of integrations. Ideally there will not be unimplemented modules by the time a system is tested for regression. However, in case of mutually exclusive modules of a system, a test stub for one of them can be used to test the regression of the other.

==Stubs in software development methodologies==
===Agile Development Methodology===
Agile software development is a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change. It is a conceptual framework that promotes foreseen interactions throughout the development cycle.
In such a development system, it recognizes that testing is not a separate phase, but an integral part of software development, along with coding. Agile testing is a software testing practice that follows the principles of agile software development. Agile testing involves all members of a cross-functional agile team, with special expertise contributed by testers, to ensure delivering the business value desired by the customer at frequent intervals, working at a sustainable pace. Specification by example, also known as acceptance test-driven development, is used to capture examples of desired and undesired behavior and guide coding.
In the agile testing toolkit, a stub is a piece of code that behaves in a predefined way, in order to simplify the testing process. Here are the kind of simplifications that a stub can bring:
• if the code under test never returns the same value (usage of a timestamp or of a random value), a stub can be used to fix the root of the undeterminism
• if the code depends on some other class that has complex behaviour that you don’t want to take into account in this test, using a stub for this other class can simplify its behaviour and clarify the intent of the test
• if the code depends on some other code that is not yet written or released, it is possible to start building the rest of the code before the dependency is actualy finished.

==Examples of Stubs==
===Java===
In Java, the basic technique is to implement the stub collaborators as concrete classes which only exhibit the small part of the overall behaviour of the collaborator which is needed by the class under test. As an example consider the case where a service implementation is under test. The implementation has a collaborator:
public class SimpleService implements Service {

private Collaborator collaborator;
public void setCollaborator(Collaborator collaborator) {
this.collaborator = collaborator;
}

// part of Service interface
public boolean isActive() {
return collaborator.isActive();
}
}

We could have a stub collaborator for testing as defined below:
public class StubCollaboratorAdapter implements Collaborator {
public boolean isActive() {
return false;
}
}
Now, a test case can be written as something like this:
public void testActiveWhenCollaboratorIsActive() throws Exception {

Service service = new SimpleService();
service.setCollaborator(new StubCollaboratorAdapter() {
public boolean isActive() {
return true;
}
});
assertTrue(service.isActive());

}

===Ruby===
While writing stubs, one might decide to replace a whole object or simply change the results of a single method. When you're replacing a whole object, it's easy—just write the new object and replace it within your test case. Methods might be tougher in some languages, but using dynamic languages such as Ruby, stubbing is easy because you're simply redefining a method.
Imagine you have a user interface that prints a document. You want to test code that handles a print failure. You really don't care if the print method gets called. You just want to verify that if your code does call print, that code will handle a failed print effectively. Think of what a pseudo-code sentence would look like.
On an instance of the document object, stub the print method, returning false.
You can break that sentence down into two parts. The first part identifies what you want to stub. The second part defines what the stub should do.
Below is an example of the Mocha framework that can be used to build stubs in Ruby:
class Document
def print
# doesn't matter -- we are stubbing it out
end
end

class View
attr :document

def initialize(document)
@document = document
end

def print()
if document.print
puts "Excellent!"
true
else
puts "Bummer."
false
end
end
end

Test code can be written as follows:
require 'test/unit'
require 'rubygems'
require 'mocha'
require 'document'

class ViewTest < Test::Unit::TestCase

def test_should_return_false_for_failed_print
document = stub("my document")
document.stubs(:print).returns(false)

ui = View.new(document)
assert_equal false, ui.print
end

end

You can see how this works. I build a simple, named stub object with the statement stub("my document"). Then, I define the behavior for print within the stub with the line of code document.stubs(:print).returns(false). If you look carefully, this line of code looks remarkably similar to the pseudo-code from earlier:
On an instance of the document object, stub the print method, returning false.

===Python===

==IDE support for Stubs==

CSC/ECE 517 Fall 2012/ch2a 2w13 sm

2012-10-25T02:05:06Z

Svmankar: Created page with "==Introduction== Test stubs are programs which simulate the behaviors of software components (or modules) that are depended upon modules of the module being tested. Stubs are rep..."

==Introduction==
Test stubs are programs which simulate the behaviors of software components (or modules) that are depended upon modules of the module being tested.
Stubs are replacements for missing components that the components being tested will call as part of the test. While doing an Integration , If we dont have all the modules get ready and Need to test a particualr module which is ready then We Use Stubs and Drivers.
Stubs are used in Integration testing for a Top Down Integration testing and Botton Up Integration Testing.
For EX : If we have Modules x,y,z . X module is ready and Need to Test it , But it calls functions from y and z.(Which are not ready)To test this particular module we can write a Small Dummy piece of code which Simulates Y and Z Which will return values that X expects. This piece of Dummy code is Called a Stub in a Top Down Integration
So Stubs are called Functions in Top Down Integration.

==Stubs in different phases of testing==
===Unit Testing===
===Functional Testing===
===Integration Testing===
Integration testing is a logical extension of unit testing. In its simplest form, two units that have already been tested are combined into a component and the interface between them is tested. A component, in this sense, refers to an integrated aggregate of more than one unit. In a realistic scenario, many units are combined into components, which are in turn aggregated into even larger parts of the program. The idea is to test combinations of pieces and eventually expand the process to test your modules with those of other groups. Eventually all the modules making up a process are tested together. Beyond that, if the program is composed of more than one process, they should be tested in pairs rather than all at once.
Integration testing identifies problems that occur when units are combined. By using a test plan that requires you to test each unit and ensure the viability of each before combining units, you know that any errors discovered when combining units are likely related to the interface between units. This method reduces the number of possibilities to a far simpler level of analysis.
The top-down approach to integration testing requires the highest-level modules be test and integrated first. This allows high-level logic and data flow to be tested early in the process and it tends to minimize the need for drivers. However, the need for stubs complicates test management and low-level utilities are tested relatively late in the development cycle. Another disadvantage of top-down integration testing is its poor support for early release of limited functionality.

===Regression Testing===
Regression testing is any type of software testing that seeks to uncover new software bugs, or regressions, in existing functional and non-functional areas of a system after changes, such as enhancements, patches or configuration changes, have been made to them.
The intent of regression testing is to ensure that a change, such as a bugfix, did not introduce new faults.[1] One of the main reasons for regression testing is to determine whether a change in one part of the software affects other parts of the software.[2]
Common methods of regression testing include rerunning previously run tests and checking whether program behavior has changed and whether previously fixed faults have re-emerged. Regression testing can be used to test a system efficiently by systematically selecting the appropriate minimum set of tests needed to adequately cover a particular change.
In Regression testing the use of test stubs is minimized as most of the system is already implemented and the main goal of the regression test is to see if there are any bugs that might have been ‘regressed’ from the previous stages of integrations. Ideally there will not be unimplemented modules by the time a system is tested for regression. However, in case of mutually exclusive modules of a system, a test stub for one of them can be used to test the regression of the other.

==Stubs in software development methodologies==
===Agile Development Methodology===
Agile software development is a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change. It is a conceptual framework that promotes foreseen interactions throughout the development cycle.
In such a development system, it recognizes that testing is not a separate phase, but an integral part of software development, along with coding. Agile testing is a software testing practice that follows the principles of agile software development. Agile testing involves all members of a cross-functional agile team, with special expertise contributed by testers, to ensure delivering the business value desired by the customer at frequent intervals, working at a sustainable pace. Specification by example, also known as acceptance test-driven development, is used to capture examples of desired and undesired behavior and guide coding.
In the agile testing toolkit, a stub is a piece of code that behaves in a predefined way, in order to simplify the testing process. Here are the kind of simplifications that a stub can bring:
• if the code under test never returns the same value (usage of a timestamp or of a random value), a stub can be used to fix the root of the undeterminism
• if the code depends on some other class that has complex behaviour that you don’t want to take into account in this test, using a stub for this other class can simplify its behaviour and clarify the intent of the test
• if the code depends on some other code that is not yet written or released, it is possible to start building the rest of the code before the dependency is actualy finished.

==Examples of Stubs==
===Java===
In Java, the basic technique is to implement the stub collaborators as concrete classes which only exhibit the small part of the overall behaviour of the collaborator which is needed by the class under test. As an example consider the case where a service implementation is under test. The implementation has a collaborator:
public class SimpleService implements Service {

private Collaborator collaborator;
public void setCollaborator(Collaborator collaborator) {
this.collaborator = collaborator;
}

// part of Service interface
public boolean isActive() {
return collaborator.isActive();
}
}

We could have a stub collaborator for testing as defined below:
public class StubCollaboratorAdapter implements Collaborator {
public boolean isActive() {
return false;
}
}
Now, a test case can be written as something like this:
public void testActiveWhenCollaboratorIsActive() throws Exception {

Service service = new SimpleService();
service.setCollaborator(new StubCollaboratorAdapter() {
public boolean isActive() {
return true;
}
});
assertTrue(service.isActive());

}

===Ruby===
While writing stubs, one might decide to replace a whole object or simply change the results of a single method. When you're replacing a whole object, it's easy—just write the new object and replace it within your test case. Methods might be tougher in some languages, but using dynamic languages such as Ruby, stubbing is easy because you're simply redefining a method.
Imagine you have a user interface that prints a document. You want to test code that handles a print failure. You really don't care if the print method gets called. You just want to verify that if your code does call print, that code will handle a failed print effectively. Think of what a pseudo-code sentence would look like.
On an instance of the document object, stub the print method, returning false.
You can break that sentence down into two parts. The first part identifies what you want to stub. The second part defines what the stub should do.
Below is an example of the Mocha framework that can be used to build stubs in Ruby:
class Document
def print
# doesn't matter -- we are stubbing it out
end
end

class View
attr :document

def initialize(document)
@document = document
end

def print()
if document.print
puts "Excellent!"
true
else
puts "Bummer."
false
end
end
end

Test code can be written as follows:
require 'test/unit'
require 'rubygems'
require 'mocha'
require 'document'

class ViewTest < Test::Unit::TestCase

def test_should_return_false_for_failed_print
document = stub("my document")
document.stubs(:print).returns(false)

ui = View.new(document)
assert_equal false, ui.print
end

end

You can see how this works. I build a simple, named stub object with the statement stub("my document"). Then, I define the behavior for print within the stub with the line of code document.stubs(:print).returns(false). If you look carefully, this line of code looks remarkably similar to the pseudo-code from earlier:
On an instance of the document object, stub the print method, returning false.

===Python===

==IDE support for Stubs==

CSC/ECE 517 Fall 2012

2012-10-25T01:58:17Z

Svmankar:

*[[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/ch1b 1w40 as

2012-10-04T00:49:40Z

Svmankar: /* Additional Reading */

==Introduction==
[http://en.wikipedia.org/wiki/Reflection_%28computer_programming%29 Reflection ]is a relatively common [http://en.wikipedia.org/wiki/Computer_programming computer programming] concept where in the program has the inherent ability to examine itself at run time. Based on its observations the program can modify it's behavior for the given situation.The modifications can be any aspect of the programming language .i.e syntax, semantics, or implementation. Precisely, "Reflection" can be defined as a language's ability to inspect and dynamically call [http://en.wikipedia.org/wiki/Class_%28computer_programming%29 classes], methods, attributes, etc. at runtime. More advanced uses of reflection let you list and call methods, [http://en.wikipedia.org/wiki/Constructor_%28object-oriented_programming%29 constructors], etc.

Reflection is important since it lets you write programs that does not have to "know" everything at compile time, making them more dynamic, since they can be tied together at runtime. For example in a high level object oriented language the ability to inspect its class , interfaces and methods at run time without knowing their names at compile time. It provides the ability to modify , instantiate and access to methods such as getter's and setter's of a class. Since the program need not have all the information at compile time it makes the program more dynamic. The code can be written against known interfaces, but the actual classes to be used can be instantiated using reflection from configuration files. Lots of modern frameworks uses reflection extensively for this very reason. In [http://en.wikipedia.org/wiki/Scripting_language scripting languages] like Python reflection is even more tightly integrated, since it matches more naturally with the general programming model.

Reflection as a concept was first introduced in the doctoral dissertation of Dr. Brian Cantwell Smith<ref>[http://hdl.handle.net/1721.1/15961 Brian Cantwell Smith, Procedural Reflection in Programming Languages, Department of Electrical Engineering and Computer Science, Massachusetts Institute of Technology, PhD Thesis, 1982.]</ref><ref>[http://publications.csail.mit.edu/lcs/specpub.php?id=840 Brian C. Smith. Reflection and semantics in a procedural language. Technical Report MIT-LCS-TR-272, Massachusetts Institute of Technology, Cambridge, Mass., January 1982.]</ref> in 1992.

In the simple illustration provided below in ruby we can see how the name of a class can be obtained from the object and how we can get the ancestor classes and modules of a particular class.
<pre>

7.class #=> Fixnum

"helloworld".class #=> String

String.ancestors #=> [String, Enumerable, Comparable, Object, Kernel]

</pre>
Some of the common information that can be obtained from reflection are :
* Object type
* [http://en.wikipedia.org/wiki/Superclass_%28computer_science%29#Subclasses_and_superclasses Super classes] of any class
* [http://en.wikipedia.org/wiki/Method_(computer_programming) Methods]
* class fields
* [http://download.oracle.com/javase/tutorial/java/concepts/interface.html Interfaces]

These are discussed in detail in the below sections.
Common languages that exhibit reflection to varying degrees are Ruby, Java, Smalltalk, C# and more.

There are two basic types of reflection:
* Behavioral Reflection: This type of reflection changes the behaviour of the execution of the program based on observation and modification.
* Structural Reflection: This type of reflection deals with changing the very structure of the program such as the data structures and flow of control in the program.

==Implementation==
There are many challenges faced by designers of reflective languages. They must provide as much leeway as possible for late binging and at the same time they must optimize the compilation of the static components so that they are ready for run-time. Reflection is in essense a connection between the object-level (program) and meta-level (the processor). The ability of the object level to be able to observe and modify the meta-level information is the consequence of this connection. These actions can be termed as [http://en.wikipedia.org/wiki/Type_introspection introspection] (This involves the action of observing the class) and intercession (this involves the operation of modifying the behavior of the class). These actions can implemented with the implementation of the following components:

* Ability to create [http://en.wikipedia.org/wiki/First-class_object first class objects] ie [http://en.wikipedia.org/wiki/Reification_(computer_science) reification].

* Ability to convert a string that denotes a class or a method into its corresponding reference or invocation.

* Ability to use and create symbolic links to methods and classes.

==Reflection in C# ==
===Features===
In C#, Reflection uses the type system. C# is a [http://en.wikipedia.org/wiki/Strong_typing strongly-typed] language in which every variable and constant has a type. Not only this, but every expression that evaluates to a value is also associated with a type. Every method signature specifies a type for each input parameter and for the return value. A typical C# program uses the types from the class library as an addition to the user-defined types that are specific to the program's problem domain.

C# maintains a special database called the [http://en.wikipedia.org/wiki/Metadata ‘metadata’] where a compiled C# program is usually encoded and stored. This metadata can then be used by reflection to act upon and read the required data present in it. This provides astonishing features such as accessing the members of an object or class based on their string names. This can be done by using the System.Reflection namespace provided in C#.

As an example, the below program uses the System.Reflection namespace to access the metadata of itself. It searches for the public field with the name "_mynumber" and then acquires its value.

<pre>
using System;
using System.Reflection;

class ReflectionUsage
{
public static int _mynumber = 4;
static void Main()
{
Type type = typeof(ReflectionUsage);
FieldInfo info = type.GetField("_mynumber");
object obj = type.GetValue(null);
Console.WriteLine(obj);
}
}
</pre>
This program would then output the number ‘4’ which is the value that is assigned to the variable “_mynumber”.

Here is how the System.Reflection class contains in C#.

[[File:Csharp.jpg]]

Below are the several powerful reflection features that are provided by C#:

Field Reflection: This gives the power to scan or search the fields in your C# program by using the [http://msdn.microsoft.com/en-us/library/system.type.getfield%28v=vs.71%29.aspx GetField] or GetFields methods. Using this reflection we can load field values and then loop through those fields and display their names and values. The System.Reflection namespace provides a powerful and maintainable way to enumerate fields and properties. It can then access these fields by name.

SetValue Reflection: [http://msdn.microsoft.com/en-us/library/system.reflection.propertyinfo.setvalue%28v=vs.71%29.aspx SetValue] accesses the fields by their names. We can take a string that usually represents a target field, and then using the System.Reflection namespace methods, change the actual value of that field.
Below is an example that does precisely this:

<pre>
using System;
using System.Reflection;
class ReflectionUsage
{
public static int _myfield;
static void Main()
{
FieldInfo info = typeof(ReflectionUsage).GetField("_myfield");
info.SetValue(null, 2012);
Console.WriteLine(_myfield);
}
}
</pre>

The above program would output 2012 which is the value that we set using the SetValue reflection.

MethodInfo Invoke: Let us say we have the name of a method in the string format and want to invoke it. In such a case, one can use the [http://msdn.microsoft.com/en-us/library/system.type.getmethod%28v=vs.71%29.aspx GetMethod] method and then invoke the MethodInfo that can be acquired from it. The invoke method can be called to invoke method with the name specified by the string.

Type Reflection: [http://msdn.microsoft.com/en-us/library/system.type.aspx Type] is one of the most important types when using reflection in C#. The Type type is used to describe data types. It stores the C# type information in a variable, property or field and can be used as an argument.

Sizeof: The [http://msdn.microsoft.com/en-us/library/eahchzkf.aspx sizeof] operator exposes information about the implementation of types in the code. It does not require the System.Reflection namespace. However, it is related to reflection in the sense that it expresses information about the program itself.

===Advantages:===

1. In C#, one can write code that uses for example a System.Xml.XMLDataDocument class, which loads and parses an XML document and then allows you to parse the DOM during runtime. During parsing, every time that an <object> node is scanned, a new object needs to be created using its FQN (fully qualified name). Every time a <property> node is parsed, then its parent node's property needs to be set to a newly created object. Also, every time that a <function> node is parsed, the parent object that is created must have the function, by name, called on it using the arguments that are later defined. This would allow you to create any object type that you want, and set properties and call functions for initialization, in a very recursive manner. The use of reflection would render this code to be surprisingly small because it takes advantage of recursion and the generic nature of reflection.

2. Programs that use reflection have the ability to look inside themselves to see their own inner workings and structure. This capacity can lend them unique and powerful features that can be used to write better code.

===Disadvantages:===

1. One main disadvantage of using reflection would be that reflection in general is that they can render programs that are less clear to read, harder to understand. A new person reading the code can find it hard to grasp what the code is actually doing.

2. Another disadvantage is that it can render programs that are generally slower.

==Reflection in Java==
Reflection is a part of Java API which enables Java code to inspect and reflect Java components like class and objects during runtime. Classes in the [http://docs.oracle.com/javase/6/docs/api/java/lang/reflect/package-summary.html java.lang.reflect] package along with [http://docs.oracle.com/javase/1.5.0/docs/api/java/lang/Class.html java.lang.Class] and [http://docs.oracle.com/javase/1.4.2/docs/api/java/lang/Package.html java.lang.Package] take care of applications like degugger, interpreters, objects inspectors, class browsers. Important protocols such as [http://en.wikipedia.org/wiki/SOAP SOAP] and JavaBeans would not have been possible, if it weren't for Reflection. The aid a developer gets from an IDE (Integrated Development Environment) during coding is achieved by using nothing else but Reflection. Reflection is one of the advanced features of Java, it gives runtime information about the objects, classes, fields and methods in a class, interfaces, etc. The image below shows some major functions related to java reflection.

[[File:Tjava_reflection.gif]]

Now we will have a look at some of the important features in Java Reflection and will see how they are implemented.
===Features ===
Classes: 
The first thing any programmer would do using reflection would be to inspect Java classes at runtime. The java package java.lang.Class helps to gather all important information about the class at runtime. We can obtain class name, class modifiers, constructors, field, method, superclass, implemented interface etc.

Before you can do any inspection on a class you need to obtain its java.lang.Class object. All types in Java including the primitive types (int, long, float etc.) including arrays have an associated Class object. If you know the name of the class at compile time you can obtain a Class object like this:
Code:
<pre>
public class DemoClass{
public static void main(String[] args)
{
Class obtainClass = DemoClass.class;
String className = obtainClass.getName();
System.out.printf("ClassName: %s\n",className);
}
}
</pre>
 Constructors: 

Using Java reflection one can inspect the constructors of classes and instantiate object of that class at runtime. This is done using Java class java.lang.reflect.Constructor. The steps to do this operation are as follows:
1) obtaining constructor objects
2) get constructor parameters
3) Instantiating Objects using constructors
<pre>
import java.lang.reflect.*;
public class DemoClass{

public String msg;

public DemoClass(String forMsg){
msg = forMsg;
}

public static void main(String[] args)
{
try{
Class obtainClass = DemoClass.class;
Constructor constructor = obtainClass.getConstructor(new Class[]{String.class});
DemoClass myDemo = (DemoClass)constructor.newInstance("Welcome to Java Reflection");
System.out.printf("New Instance String: %s\n",myDemo.msg);

}
catch(Exception e)
{
System.err.printf(e.getMessage());
}
}
}
</pre>
 Field: 
Inspecting the fields of classes and get/set them at runtime is another feature provided by Java Reflection. This is done using Java class java.lang.reflect.Field. To get/set a field value using Java reflection following are steps involved: obtaining field objects, field name, field type and getting and setting field values.
eg:
<pre>
Class objClass = MyObject.class;
Field[] methods = objClass.getFields();
</pre>

 Methods: 
One can also inspect the methods of class at runtime and invoke them. The class to implement this functionality is java.lang.reflect.Method. The steps to obtain methods from a class are:
Obtaining Method Objects
Method Parameters and Return Types
Invoking Methods using Method object.

For eg:
<pre>
Class objClass = MyObject.class;
Field[] methods = objClass.getMethods();
</pre>

===Advantages===

1) One of the major advantage of Java reflection is in debugging. While debugging one should be able to examine the private members of classes.
2) Also while testing one should be able to enlist all members of class along with the relationship with superclass so as to ensure that all code branches are covered.

===Disadvantages===
1) Java reflection provides access to private variables and methods, this exposes the implementation of the class. Such use of class functionalities which break the abstraction can result is portability problems in future upgrades.

2) Reflection involves method execution which resolve at runtime, so with certain Java virtual machines which do not perform optimizations can result in performance overhead with use to Java reflection.

==Reflection in Ruby==
Ruby is a dynamic language and one of many advantages which Ruby provides is its ability to introspect into a class or object known as reflection. What kind of introspection Ruby provides? It provides a way to inspect class objects using instance_of?, class hierarchy using ancestors, contents & behavior of class like which operations it supports, instance variables, etc and information on methods.

===Dynamic binding : Making reflection possible===

Ruby implements [http://en.wikipedia.org/wiki/Dynamic_dispatch dynamic binding] of objects. Dynamic binding plays a very important role in [http://en.wikipedia.org/wiki/Metaprogramming meta-programming].

In languages like C,C++; a simple assignment "a = b", would require 'a' and 'b' to be of the same type. The assignment is interpreted as copying b into a and is implemented by copying the contents of b into the space occupied by a. Thus if 'a' had been declared as an object whose memory size is less than b's object, then object slicing takes place i.e. only that part of 'b' which fits into a's memory would be copied. This behavior might lead to unintended consequences.

[[File:Slicing.gif]]

But dynamic binding in Ruby ensures that the type of object stored in a variable is determined at run time and not at compile time. Thus the assignment "a = b" is interpreted as binding 'a' to the same object that 'b' is bound to. It is implemented by copying the reference stored in b into the (pointer-sized) memory cell of 'a'. Thus 'a' and 'b' point to the same object after the assignment.

[[File:Before_binding.png]] [[File:After_binding.png]]

===Symbols and their usage in reflection techniques===

====Basics====
[http://en.wikipedia.org/wiki/Symbol_%28programming%29 Symbols] are objects used to represent names and strings inside a Ruby [http://en.wikipedia.org/wiki/Interpreter_%28computing%29 interpreter]. They are immutable and remain unique i.e. every instance of a particular symbol is the same symbol.

====Usage in reflection techniques====
Symbols are widely used in reflection to invoke methods dynamically. Reflection methods like 'respond_to', 'send' make use of symbols as a reference to other methods. Strings can also be used in place of symbols. However symbols are more efficient compared to strings in terms of memory and performance.

====Examples====

====Passing method by reference using a symbol====
<pre>
class Float
def poly
self*self*self + 2*self*self + 3*self + 4
end
end
</pre>
And we can pass poly to an integration routine:
<pre>
area = integrate(:poly, 0, 10)
</pre>

====Symbols in reflection====
[http://ruby-doc.org/core-1.9.2/Object.html#method-i-send Send] method

<pre>
irb(main):015:0> to = [:to_s , :to_f]
=> [:to_s, :to_f]
irb(main):016:0> to.each{|method| puts "#{method} => #{5.send method}"}
to_s => 5
to_f => 5.0
=> [:to_s, :to_f]
</pre>

[http://ruby-doc.org/core-1.9.2/Object.html#method-i-respond_to-3F respond_to] method

<pre>
5.respond_to? :slice #=> false
5.respond_to? :to_f #=> true
</pre>
<pre>
obj = Object.new
if obj.respond_to?(:program)
obj.program
else
puts "Sorry, the object doesn't understand the 'program' message."
end
</pre>

===method_missing===

Whenever a call to a method is made on an object , Ruby does a method look up. If the method is not found, Ruby calls a method named '[http://ruby-doc.org/docs/ProgrammingRuby/html/ref_c_object.html#Object.method_missing method_missing]'. Ruby knows the existence of the 'method_missing' as all objects are instances of 'BasicObject' which includes 'method_missing'. The default behavior of BasicObject#method_missing is to respond by raising a [http://www.ruby-doc.org/core-1.9.2/NoMethodError.html NoMethodError].

[http://en.wikipedia.org/wiki/Method_overriding Overriding] 'method_missing' allows users to call methods that don't really exist. The example below illustrates overriding of 'method_missing' to the programmer's advantage. Ruby passes as parameters the name of the method called and the arguments passed to it.

'''Example1'''
<pre>
class Cat
def mew
puts "Meow"
end
def method_missing(meth, *args)
puts "Sorry, I do not #{meth}"
end
end
c = Cat.new
c.mew
>>Meow
c.bark
>> Sorry, I do not bark
</pre>

In the above example, as the method 'bark' does not exist, method_missing is called with the meth (method name as a symbol) :bark. Hence the result " Sorry, I do not bark "

'''Example2'''
Using method_missing to convert Roman numerals <ref>http://www.rubyquiz.com/quiz22.html</ref> to integers

<pre>
class Roman

DIGITS = {
'I' => 1,
'V' => 5,
'X' => 10,
'L' => 50,
'C' => 100,
'D' => 500,
'M' => 1000,
}

def roman_to_integer(roman_string)
last = nil
roman_string.to_s.upcase.split(//).reverse.inject(0) do |memo, digit|
if digit_value = DIGITS[digit]
if last && last > digit_value
memo -= digit_value
else
memo += digit_value
end
last = digit_value
end
memo
end
end

def method_missing(method)
str = method.id2name
roman_to_integer(str)
end
end
</pre>

Evaluating Roman.xix calls the xix method of module Roman. Roman has no xix method, so method_missing is invoked with :xix as the argument.The id2name method of class Symbol is invoked on xix returning "xix". The "xix" is then parsed according to the rules for evaluating Roman numerals, and evaluates to 19.

''' Example 3 '''
<pre>
class Performer
def method_missing(name, *args)
"The duck will #{name}: #{args[0]}"
end
end

duck = Performer.new
duck.sing("Quacking in the Rain") # => "The duck will sing: Quacking in the Rain"
duck.dance("Swan Lake") # => "The duck will dance: Swan Lake"
</pre>

==Applications of Reflection==
*Reflection has become invaluable to programmers who need to connect code with data. For example in a GUI environment a button might need to invoke different methods in different classes. Reflection can be used here to call the method on any given class.

*Programmers who deal with a multitude of classes at the same time can use reflection to create a “serializer” that for a given class uses reflection to go through all the instance variables and processes them accordingly.

*Reflection is used in large test frameworks where reflection helps in identifying the test methods for different scenarios.

*Reflection provides the ability to morph the code based on dynamic situations. This provides a sense of artificial intelligence to the program as whole.

*Reflection can be used to debug and verify code as it provides access to the insides of a program.

*Reflection is very useful when the software is upgraded regularly. It provides an easy method to check for available methods and classes. This prevents the errors caused by the absense of methods and classes when they are deprecated.

==Feature Comparison==
Ruby provides a very good reflection ability where one can introspect various properties about an object and the class it belongs to, during runtime. One can obtain the list of methods that are supported on an object by using the 'methods' reflection method on the object. In addition, the 'class' reflection method enables one to query the class that an object belongs to. Similarly, the 'superclass' method allows one to inspect all the super classes of the class that an object belongs to.

In PHP, we have a class called as ReflectionClass which holds the class type for a particlar class. In the class row for PHP we can see that all Reflection operations can be performed on only class Reflection. So as to check if a particular instance belongs to class 'Foo', we need to first create the ReflectionClass object as shown and then call isInstance(argument) method on it. PHP also has getMethods() method which returns a list of class methods.

In Objective C, every type we see is of type class, whether it be String, Integer or Double. So type check in Objective C can be done using method isKindOfClass. But to perform other Reflection tasks, one needs to obtain the object of class first using the object_getClass(Class_Object) method. Once this object is obtained we can then perform operations like getting method list, etc as shown in table.
{|border="1" cellpadding="5" cellspacing="0" align="center"
|-
|
! scope="col" style="background:#efefef;" | Ruby
! scope="col" style="background:#efefef;" | PHP
! scope="col" style="background:#efefef;" | Objective C
|-
! scope="row" style="background:#efefef;" | Class
|Method: instance_of?
<pre>
obj.instance_of? String
</pre>
|Method: isInstance()
<pre>
<?php
$class = new ReflectionClass('Foo');
if ($class->isInstance($arg)) {
echo "Yes";
}
?>
</pre>
|Method: isKindOfClass
<pre>
if([myObject isKindOfClass:[MyObject class])
{
//do something
}
</pre>
|-
! scope="row" style="background:#efefef;" | Method
|Method: methods
<pre>
list = r.methods
</pre>
|Method: ReflectionClass::getMethods
<pre>
$class = new ReflectionClass('Apple');
$methods = $class->getMethods();
</pre>
|Method: class_copyMethodList()
<pre>
SomeClass * t = [[SomeClass alloc] init];
unsigned int mc = 0;
Method * mlist =
class_copyMethodList
(object_getClass(t), &mc);
</pre>
|-
! scope="row" style="background:#efefef;" | Type
|Method: Object.class
<pre>
"Hello".class
>>String
</pre>
|Method: gettype()
<pre>
<?php
$data = array(1, 'foo');
foreach ($data as $value) {
echo gettype($value), "\n";
}?>
</pre>
|Method: isKindOfClass
<pre>
if([myDemo isKindOfClass:[DemoClass class]])
{
//code
}
</pre>
|-
! scope="row" style="background:#efefef;" | String representation of an object
|Method: to_s
<pre>
obj.to_s
</pre>
|Method: ReflectionClass::__toString —
<pre>
<?php
$reflectionClass =
new ReflectionClass(MyDemoClass);
echo $reflectionClass->__toString();
?>
</pre>
|Method: [NSString stringWithFormat:""]
<pre>
*objString = [NSString
stringWithFormat:”%@”,myObject]
</pre>
|}

==Advantages and Disadvantages of reflection==

===Advantages===
* Extensibility: Reflection provides the capability of using external and user defined classes by instantiation of extensibility objects using their fully qualified names.
* Class browsers in IDEs: The ability to examine the members of classes makes implementation of visual aids, auto-completion and documentation easy in development tools for programmers.
* Debugging and Test Harness: Reflection allows the user to observe the private members in classes. This capability can be used to debug classes and their interactions. Reflection can be used to call a set of testing APIs defined on a class for maximum coverage of testing.
* Correctness: Reflection improves the robustness and the correctness of a program especially in dynamically typed languages as runtime checks can be added to check the availability of the methods or classes.

===Disadvantages===
* Performance Overhead: Reflection resolves types of objects and classes are dynamically at runtime, this introduces lot of performance overhead when compared to non-reflective code. Hence it should be used judiciously.
* Security: At run-time binding in reflection we loose the security of compile time checks and verification. It also provides access to the internals of a class or an encapsulated object like private methods and variables which makes security a major issue.
*Portability: Another issue is of portability, over a period of time the code may change during updates and a Reflective code breaks abstraction. Such a code may change behavior during updates and may become dysfunctional.

==Conclusion==
This article makes an attempt to explain the concept of Reflection in Object Oriented Programming. The article mentions the different approaches to reflection in Ruby and other languages.It mentions the usage of Reflections and the advantages and disadvantages of using Reflection. A follow up to this article would be to study the concept of [http://en.wikipedia.org/wiki/Metaprogramming Metaprogramming].

==References==
<references/>

==Additional Reading==
*[http://en.wikipedia.org/wiki/Reflection_(computer_programming) Reflection]
*[http://www.cs.indiana.edu/~jsobel/rop.html An Introduction to Reflection-Oriented Programming]
*[http://tutorials.jenkov.com/java-reflection/classes.html Java Reflection]
*[http://www.slideshare.net/CiaranMcHale/java-reflection-explained-simply Java reflection basics]
*[http://www2.parc.com/csl/groups/sda/projects/reflection96/docs/malenfant/ref96/ref96.html A Tutorial on Behavioral Reflection and its Implementation]
*[http://www.quora.com/Computer-Programming/How-is-reflection-useful Uses of reflection]
*[http://download.oracle.com/javase/tutorial/reflect/index.html Java reflection official website]
*[http://ruby-doc.org/docs/ProgrammingRuby/html/builtins.html Ruby Documentation]
*[http://www.slideshare.net/MarcusDenker/behavioral-reflection Behavioral reflection]
*[http://csharp.net-tutorials.com/reflection/introduction/ Csharp reflection 1]
*[http://www.codeguru.com/csharp/csharp/cs_misc/reflection/article.php/c4257/An-Introduction-to-Reflection-in-C.htm Csharp reflection 2]

CSC/ECE 517 Fall 2012/ch1b 1w40 as

2012-10-04T00:49:01Z

Svmankar: /* Additional Reading */

==Introduction==
[http://en.wikipedia.org/wiki/Reflection_%28computer_programming%29 Reflection ]is a relatively common [http://en.wikipedia.org/wiki/Computer_programming computer programming] concept where in the program has the inherent ability to examine itself at run time. Based on its observations the program can modify it's behavior for the given situation.The modifications can be any aspect of the programming language .i.e syntax, semantics, or implementation. Precisely, "Reflection" can be defined as a language's ability to inspect and dynamically call [http://en.wikipedia.org/wiki/Class_%28computer_programming%29 classes], methods, attributes, etc. at runtime. More advanced uses of reflection let you list and call methods, [http://en.wikipedia.org/wiki/Constructor_%28object-oriented_programming%29 constructors], etc.

Reflection is important since it lets you write programs that does not have to "know" everything at compile time, making them more dynamic, since they can be tied together at runtime. For example in a high level object oriented language the ability to inspect its class , interfaces and methods at run time without knowing their names at compile time. It provides the ability to modify , instantiate and access to methods such as getter's and setter's of a class. Since the program need not have all the information at compile time it makes the program more dynamic. The code can be written against known interfaces, but the actual classes to be used can be instantiated using reflection from configuration files. Lots of modern frameworks uses reflection extensively for this very reason. In [http://en.wikipedia.org/wiki/Scripting_language scripting languages] like Python reflection is even more tightly integrated, since it matches more naturally with the general programming model.

Reflection as a concept was first introduced in the doctoral dissertation of Dr. Brian Cantwell Smith<ref>[http://hdl.handle.net/1721.1/15961 Brian Cantwell Smith, Procedural Reflection in Programming Languages, Department of Electrical Engineering and Computer Science, Massachusetts Institute of Technology, PhD Thesis, 1982.]</ref><ref>[http://publications.csail.mit.edu/lcs/specpub.php?id=840 Brian C. Smith. Reflection and semantics in a procedural language. Technical Report MIT-LCS-TR-272, Massachusetts Institute of Technology, Cambridge, Mass., January 1982.]</ref> in 1992.

In the simple illustration provided below in ruby we can see how the name of a class can be obtained from the object and how we can get the ancestor classes and modules of a particular class.
<pre>

7.class #=> Fixnum

"helloworld".class #=> String

String.ancestors #=> [String, Enumerable, Comparable, Object, Kernel]

</pre>
Some of the common information that can be obtained from reflection are :
* Object type
* [http://en.wikipedia.org/wiki/Superclass_%28computer_science%29#Subclasses_and_superclasses Super classes] of any class
* [http://en.wikipedia.org/wiki/Method_(computer_programming) Methods]
* class fields
* [http://download.oracle.com/javase/tutorial/java/concepts/interface.html Interfaces]

These are discussed in detail in the below sections.
Common languages that exhibit reflection to varying degrees are Ruby, Java, Smalltalk, C# and more.

There are two basic types of reflection:
* Behavioral Reflection: This type of reflection changes the behaviour of the execution of the program based on observation and modification.
* Structural Reflection: This type of reflection deals with changing the very structure of the program such as the data structures and flow of control in the program.

==Implementation==
There are many challenges faced by designers of reflective languages. They must provide as much leeway as possible for late binging and at the same time they must optimize the compilation of the static components so that they are ready for run-time. Reflection is in essense a connection between the object-level (program) and meta-level (the processor). The ability of the object level to be able to observe and modify the meta-level information is the consequence of this connection. These actions can be termed as [http://en.wikipedia.org/wiki/Type_introspection introspection] (This involves the action of observing the class) and intercession (this involves the operation of modifying the behavior of the class). These actions can implemented with the implementation of the following components:

* Ability to create [http://en.wikipedia.org/wiki/First-class_object first class objects] ie [http://en.wikipedia.org/wiki/Reification_(computer_science) reification].

* Ability to convert a string that denotes a class or a method into its corresponding reference or invocation.

* Ability to use and create symbolic links to methods and classes.

==Reflection in C# ==
===Features===
In C#, Reflection uses the type system. C# is a [http://en.wikipedia.org/wiki/Strong_typing strongly-typed] language in which every variable and constant has a type. Not only this, but every expression that evaluates to a value is also associated with a type. Every method signature specifies a type for each input parameter and for the return value. A typical C# program uses the types from the class library as an addition to the user-defined types that are specific to the program's problem domain.

C# maintains a special database called the [http://en.wikipedia.org/wiki/Metadata ‘metadata’] where a compiled C# program is usually encoded and stored. This metadata can then be used by reflection to act upon and read the required data present in it. This provides astonishing features such as accessing the members of an object or class based on their string names. This can be done by using the System.Reflection namespace provided in C#.

As an example, the below program uses the System.Reflection namespace to access the metadata of itself. It searches for the public field with the name "_mynumber" and then acquires its value.

<pre>
using System;
using System.Reflection;

class ReflectionUsage
{
public static int _mynumber = 4;
static void Main()
{
Type type = typeof(ReflectionUsage);
FieldInfo info = type.GetField("_mynumber");
object obj = type.GetValue(null);
Console.WriteLine(obj);
}
}
</pre>
This program would then output the number ‘4’ which is the value that is assigned to the variable “_mynumber”.

Here is how the System.Reflection class contains in C#.

[[File:Csharp.jpg]]

Below are the several powerful reflection features that are provided by C#:

Field Reflection: This gives the power to scan or search the fields in your C# program by using the [http://msdn.microsoft.com/en-us/library/system.type.getfield%28v=vs.71%29.aspx GetField] or GetFields methods. Using this reflection we can load field values and then loop through those fields and display their names and values. The System.Reflection namespace provides a powerful and maintainable way to enumerate fields and properties. It can then access these fields by name.

SetValue Reflection: [http://msdn.microsoft.com/en-us/library/system.reflection.propertyinfo.setvalue%28v=vs.71%29.aspx SetValue] accesses the fields by their names. We can take a string that usually represents a target field, and then using the System.Reflection namespace methods, change the actual value of that field.
Below is an example that does precisely this:

<pre>
using System;
using System.Reflection;
class ReflectionUsage
{
public static int _myfield;
static void Main()
{
FieldInfo info = typeof(ReflectionUsage).GetField("_myfield");
info.SetValue(null, 2012);
Console.WriteLine(_myfield);
}
}
</pre>

The above program would output 2012 which is the value that we set using the SetValue reflection.

MethodInfo Invoke: Let us say we have the name of a method in the string format and want to invoke it. In such a case, one can use the [http://msdn.microsoft.com/en-us/library/system.type.getmethod%28v=vs.71%29.aspx GetMethod] method and then invoke the MethodInfo that can be acquired from it. The invoke method can be called to invoke method with the name specified by the string.

Type Reflection: [http://msdn.microsoft.com/en-us/library/system.type.aspx Type] is one of the most important types when using reflection in C#. The Type type is used to describe data types. It stores the C# type information in a variable, property or field and can be used as an argument.

Sizeof: The [http://msdn.microsoft.com/en-us/library/eahchzkf.aspx sizeof] operator exposes information about the implementation of types in the code. It does not require the System.Reflection namespace. However, it is related to reflection in the sense that it expresses information about the program itself.

===Advantages:===

1. In C#, one can write code that uses for example a System.Xml.XMLDataDocument class, which loads and parses an XML document and then allows you to parse the DOM during runtime. During parsing, every time that an <object> node is scanned, a new object needs to be created using its FQN (fully qualified name). Every time a <property> node is parsed, then its parent node's property needs to be set to a newly created object. Also, every time that a <function> node is parsed, the parent object that is created must have the function, by name, called on it using the arguments that are later defined. This would allow you to create any object type that you want, and set properties and call functions for initialization, in a very recursive manner. The use of reflection would render this code to be surprisingly small because it takes advantage of recursion and the generic nature of reflection.

2. Programs that use reflection have the ability to look inside themselves to see their own inner workings and structure. This capacity can lend them unique and powerful features that can be used to write better code.

===Disadvantages:===

1. One main disadvantage of using reflection would be that reflection in general is that they can render programs that are less clear to read, harder to understand. A new person reading the code can find it hard to grasp what the code is actually doing.

2. Another disadvantage is that it can render programs that are generally slower.

==Reflection in Java==
Reflection is a part of Java API which enables Java code to inspect and reflect Java components like class and objects during runtime. Classes in the [http://docs.oracle.com/javase/6/docs/api/java/lang/reflect/package-summary.html java.lang.reflect] package along with [http://docs.oracle.com/javase/1.5.0/docs/api/java/lang/Class.html java.lang.Class] and [http://docs.oracle.com/javase/1.4.2/docs/api/java/lang/Package.html java.lang.Package] take care of applications like degugger, interpreters, objects inspectors, class browsers. Important protocols such as [http://en.wikipedia.org/wiki/SOAP SOAP] and JavaBeans would not have been possible, if it weren't for Reflection. The aid a developer gets from an IDE (Integrated Development Environment) during coding is achieved by using nothing else but Reflection. Reflection is one of the advanced features of Java, it gives runtime information about the objects, classes, fields and methods in a class, interfaces, etc. The image below shows some major functions related to java reflection.

[[File:Tjava_reflection.gif]]

Now we will have a look at some of the important features in Java Reflection and will see how they are implemented.
===Features ===
Classes: 
The first thing any programmer would do using reflection would be to inspect Java classes at runtime. The java package java.lang.Class helps to gather all important information about the class at runtime. We can obtain class name, class modifiers, constructors, field, method, superclass, implemented interface etc.

Before you can do any inspection on a class you need to obtain its java.lang.Class object. All types in Java including the primitive types (int, long, float etc.) including arrays have an associated Class object. If you know the name of the class at compile time you can obtain a Class object like this:
Code:
<pre>
public class DemoClass{
public static void main(String[] args)
{
Class obtainClass = DemoClass.class;
String className = obtainClass.getName();
System.out.printf("ClassName: %s\n",className);
}
}
</pre>
 Constructors: 

Using Java reflection one can inspect the constructors of classes and instantiate object of that class at runtime. This is done using Java class java.lang.reflect.Constructor. The steps to do this operation are as follows:
1) obtaining constructor objects
2) get constructor parameters
3) Instantiating Objects using constructors
<pre>
import java.lang.reflect.*;
public class DemoClass{

public String msg;

public DemoClass(String forMsg){
msg = forMsg;
}

public static void main(String[] args)
{
try{
Class obtainClass = DemoClass.class;
Constructor constructor = obtainClass.getConstructor(new Class[]{String.class});
DemoClass myDemo = (DemoClass)constructor.newInstance("Welcome to Java Reflection");
System.out.printf("New Instance String: %s\n",myDemo.msg);

}
catch(Exception e)
{
System.err.printf(e.getMessage());
}
}
}
</pre>
 Field: 
Inspecting the fields of classes and get/set them at runtime is another feature provided by Java Reflection. This is done using Java class java.lang.reflect.Field. To get/set a field value using Java reflection following are steps involved: obtaining field objects, field name, field type and getting and setting field values.
eg:
<pre>
Class objClass = MyObject.class;
Field[] methods = objClass.getFields();
</pre>

 Methods: 
One can also inspect the methods of class at runtime and invoke them. The class to implement this functionality is java.lang.reflect.Method. The steps to obtain methods from a class are:
Obtaining Method Objects
Method Parameters and Return Types
Invoking Methods using Method object.

For eg:
<pre>
Class objClass = MyObject.class;
Field[] methods = objClass.getMethods();
</pre>

===Advantages===

1) One of the major advantage of Java reflection is in debugging. While debugging one should be able to examine the private members of classes.
2) Also while testing one should be able to enlist all members of class along with the relationship with superclass so as to ensure that all code branches are covered.

===Disadvantages===
1) Java reflection provides access to private variables and methods, this exposes the implementation of the class. Such use of class functionalities which break the abstraction can result is portability problems in future upgrades.

2) Reflection involves method execution which resolve at runtime, so with certain Java virtual machines which do not perform optimizations can result in performance overhead with use to Java reflection.

==Reflection in Ruby==
Ruby is a dynamic language and one of many advantages which Ruby provides is its ability to introspect into a class or object known as reflection. What kind of introspection Ruby provides? It provides a way to inspect class objects using instance_of?, class hierarchy using ancestors, contents & behavior of class like which operations it supports, instance variables, etc and information on methods.

===Dynamic binding : Making reflection possible===

Ruby implements [http://en.wikipedia.org/wiki/Dynamic_dispatch dynamic binding] of objects. Dynamic binding plays a very important role in [http://en.wikipedia.org/wiki/Metaprogramming meta-programming].

In languages like C,C++; a simple assignment "a = b", would require 'a' and 'b' to be of the same type. The assignment is interpreted as copying b into a and is implemented by copying the contents of b into the space occupied by a. Thus if 'a' had been declared as an object whose memory size is less than b's object, then object slicing takes place i.e. only that part of 'b' which fits into a's memory would be copied. This behavior might lead to unintended consequences.

[[File:Slicing.gif]]

But dynamic binding in Ruby ensures that the type of object stored in a variable is determined at run time and not at compile time. Thus the assignment "a = b" is interpreted as binding 'a' to the same object that 'b' is bound to. It is implemented by copying the reference stored in b into the (pointer-sized) memory cell of 'a'. Thus 'a' and 'b' point to the same object after the assignment.

[[File:Before_binding.png]] [[File:After_binding.png]]

===Symbols and their usage in reflection techniques===

====Basics====
[http://en.wikipedia.org/wiki/Symbol_%28programming%29 Symbols] are objects used to represent names and strings inside a Ruby [http://en.wikipedia.org/wiki/Interpreter_%28computing%29 interpreter]. They are immutable and remain unique i.e. every instance of a particular symbol is the same symbol.

====Usage in reflection techniques====
Symbols are widely used in reflection to invoke methods dynamically. Reflection methods like 'respond_to', 'send' make use of symbols as a reference to other methods. Strings can also be used in place of symbols. However symbols are more efficient compared to strings in terms of memory and performance.

====Examples====

====Passing method by reference using a symbol====
<pre>
class Float
def poly
self*self*self + 2*self*self + 3*self + 4
end
end
</pre>
And we can pass poly to an integration routine:
<pre>
area = integrate(:poly, 0, 10)
</pre>

====Symbols in reflection====
[http://ruby-doc.org/core-1.9.2/Object.html#method-i-send Send] method

<pre>
irb(main):015:0> to = [:to_s , :to_f]
=> [:to_s, :to_f]
irb(main):016:0> to.each{|method| puts "#{method} => #{5.send method}"}
to_s => 5
to_f => 5.0
=> [:to_s, :to_f]
</pre>

[http://ruby-doc.org/core-1.9.2/Object.html#method-i-respond_to-3F respond_to] method

<pre>
5.respond_to? :slice #=> false
5.respond_to? :to_f #=> true
</pre>
<pre>
obj = Object.new
if obj.respond_to?(:program)
obj.program
else
puts "Sorry, the object doesn't understand the 'program' message."
end
</pre>

===method_missing===

Whenever a call to a method is made on an object , Ruby does a method look up. If the method is not found, Ruby calls a method named '[http://ruby-doc.org/docs/ProgrammingRuby/html/ref_c_object.html#Object.method_missing method_missing]'. Ruby knows the existence of the 'method_missing' as all objects are instances of 'BasicObject' which includes 'method_missing'. The default behavior of BasicObject#method_missing is to respond by raising a [http://www.ruby-doc.org/core-1.9.2/NoMethodError.html NoMethodError].

[http://en.wikipedia.org/wiki/Method_overriding Overriding] 'method_missing' allows users to call methods that don't really exist. The example below illustrates overriding of 'method_missing' to the programmer's advantage. Ruby passes as parameters the name of the method called and the arguments passed to it.

'''Example1'''
<pre>
class Cat
def mew
puts "Meow"
end
def method_missing(meth, *args)
puts "Sorry, I do not #{meth}"
end
end
c = Cat.new
c.mew
>>Meow
c.bark
>> Sorry, I do not bark
</pre>

In the above example, as the method 'bark' does not exist, method_missing is called with the meth (method name as a symbol) :bark. Hence the result " Sorry, I do not bark "

'''Example2'''
Using method_missing to convert Roman numerals <ref>http://www.rubyquiz.com/quiz22.html</ref> to integers

<pre>
class Roman

DIGITS = {
'I' => 1,
'V' => 5,
'X' => 10,
'L' => 50,
'C' => 100,
'D' => 500,
'M' => 1000,
}

def roman_to_integer(roman_string)
last = nil
roman_string.to_s.upcase.split(//).reverse.inject(0) do |memo, digit|
if digit_value = DIGITS[digit]
if last && last > digit_value
memo -= digit_value
else
memo += digit_value
end
last = digit_value
end
memo
end
end

def method_missing(method)
str = method.id2name
roman_to_integer(str)
end
end
</pre>

Evaluating Roman.xix calls the xix method of module Roman. Roman has no xix method, so method_missing is invoked with :xix as the argument.The id2name method of class Symbol is invoked on xix returning "xix". The "xix" is then parsed according to the rules for evaluating Roman numerals, and evaluates to 19.

''' Example 3 '''
<pre>
class Performer
def method_missing(name, *args)
"The duck will #{name}: #{args[0]}"
end
end

duck = Performer.new
duck.sing("Quacking in the Rain") # => "The duck will sing: Quacking in the Rain"
duck.dance("Swan Lake") # => "The duck will dance: Swan Lake"
</pre>

==Applications of Reflection==
*Reflection has become invaluable to programmers who need to connect code with data. For example in a GUI environment a button might need to invoke different methods in different classes. Reflection can be used here to call the method on any given class.

*Programmers who deal with a multitude of classes at the same time can use reflection to create a “serializer” that for a given class uses reflection to go through all the instance variables and processes them accordingly.

*Reflection is used in large test frameworks where reflection helps in identifying the test methods for different scenarios.

*Reflection provides the ability to morph the code based on dynamic situations. This provides a sense of artificial intelligence to the program as whole.

*Reflection can be used to debug and verify code as it provides access to the insides of a program.

*Reflection is very useful when the software is upgraded regularly. It provides an easy method to check for available methods and classes. This prevents the errors caused by the absense of methods and classes when they are deprecated.

==Feature Comparison==
Ruby provides a very good reflection ability where one can introspect various properties about an object and the class it belongs to, during runtime. One can obtain the list of methods that are supported on an object by using the 'methods' reflection method on the object. In addition, the 'class' reflection method enables one to query the class that an object belongs to. Similarly, the 'superclass' method allows one to inspect all the super classes of the class that an object belongs to.

In PHP, we have a class called as ReflectionClass which holds the class type for a particlar class. In the class row for PHP we can see that all Reflection operations can be performed on only class Reflection. So as to check if a particular instance belongs to class 'Foo', we need to first create the ReflectionClass object as shown and then call isInstance(argument) method on it. PHP also has getMethods() method which returns a list of class methods.

In Objective C, every type we see is of type class, whether it be String, Integer or Double. So type check in Objective C can be done using method isKindOfClass. But to perform other Reflection tasks, one needs to obtain the object of class first using the object_getClass(Class_Object) method. Once this object is obtained we can then perform operations like getting method list, etc as shown in table.
{|border="1" cellpadding="5" cellspacing="0" align="center"
|-
|
! scope="col" style="background:#efefef;" | Ruby
! scope="col" style="background:#efefef;" | PHP
! scope="col" style="background:#efefef;" | Objective C
|-
! scope="row" style="background:#efefef;" | Class
|Method: instance_of?
<pre>
obj.instance_of? String
</pre>
|Method: isInstance()
<pre>
<?php
$class = new ReflectionClass('Foo');
if ($class->isInstance($arg)) {
echo "Yes";
}
?>
</pre>
|Method: isKindOfClass
<pre>
if([myObject isKindOfClass:[MyObject class])
{
//do something
}
</pre>
|-
! scope="row" style="background:#efefef;" | Method
|Method: methods
<pre>
list = r.methods
</pre>
|Method: ReflectionClass::getMethods
<pre>
$class = new ReflectionClass('Apple');
$methods = $class->getMethods();
</pre>
|Method: class_copyMethodList()
<pre>
SomeClass * t = [[SomeClass alloc] init];
unsigned int mc = 0;
Method * mlist =
class_copyMethodList
(object_getClass(t), &mc);
</pre>
|-
! scope="row" style="background:#efefef;" | Type
|Method: Object.class
<pre>
"Hello".class
>>String
</pre>
|Method: gettype()
<pre>
<?php
$data = array(1, 'foo');
foreach ($data as $value) {
echo gettype($value), "\n";
}?>
</pre>
|Method: isKindOfClass
<pre>
if([myDemo isKindOfClass:[DemoClass class]])
{
//code
}
</pre>
|-
! scope="row" style="background:#efefef;" | String representation of an object
|Method: to_s
<pre>
obj.to_s
</pre>
|Method: ReflectionClass::__toString —
<pre>
<?php
$reflectionClass =
new ReflectionClass(MyDemoClass);
echo $reflectionClass->__toString();
?>
</pre>
|Method: [NSString stringWithFormat:""]
<pre>
*objString = [NSString
stringWithFormat:”%@”,myObject]
</pre>
|}

==Advantages and Disadvantages of reflection==

===Advantages===
* Extensibility: Reflection provides the capability of using external and user defined classes by instantiation of extensibility objects using their fully qualified names.
* Class browsers in IDEs: The ability to examine the members of classes makes implementation of visual aids, auto-completion and documentation easy in development tools for programmers.
* Debugging and Test Harness: Reflection allows the user to observe the private members in classes. This capability can be used to debug classes and their interactions. Reflection can be used to call a set of testing APIs defined on a class for maximum coverage of testing.
* Correctness: Reflection improves the robustness and the correctness of a program especially in dynamically typed languages as runtime checks can be added to check the availability of the methods or classes.

===Disadvantages===
* Performance Overhead: Reflection resolves types of objects and classes are dynamically at runtime, this introduces lot of performance overhead when compared to non-reflective code. Hence it should be used judiciously.
* Security: At run-time binding in reflection we loose the security of compile time checks and verification. It also provides access to the internals of a class or an encapsulated object like private methods and variables which makes security a major issue.
*Portability: Another issue is of portability, over a period of time the code may change during updates and a Reflective code breaks abstraction. Such a code may change behavior during updates and may become dysfunctional.

==Conclusion==
This article makes an attempt to explain the concept of Reflection in Object Oriented Programming. The article mentions the different approaches to reflection in Ruby and other languages.It mentions the usage of Reflections and the advantages and disadvantages of using Reflection. A follow up to this article would be to study the concept of [http://en.wikipedia.org/wiki/Metaprogramming Metaprogramming].

==References==
<references/>

==Additional Reading==
*[http://en.wikipedia.org/wiki/Reflection_(computer_programming) Reflection]
*[http://www.cs.indiana.edu/~jsobel/rop.html An Introduction to Reflection-Oriented Programming]
*[http://tutorials.jenkov.com/java-reflection/classes.html Java Reflection]
*[http://www.slideshare.net/CiaranMcHale/java-reflection-explained-simply Java reflection basics]
*[http://www2.parc.com/csl/groups/sda/projects/reflection96/docs/malenfant/ref96/ref96.html A Tutorial on Behavioral Reflection and its Implementation]
*[http://www.quora.com/Computer-Programming/How-is-reflection-useful Uses of reflection]
*[http://download.oracle.com/javase/tutorial/reflect/index.html Java reflection official website]
*[http://ruby-doc.org/docs/ProgrammingRuby/html/builtins.html Ruby Documentation]
*[http://www.slideshare.net/MarcusDenker/behavioral-reflection Behavioral reflection]
*[http://csharp.net-tutorials.com/reflection/introduction/]
*[http://www.codeguru.com/csharp/csharp/cs_misc/reflection/article.php/c4257/An-Introduction-to-Reflection-in-C.htm]

CSC/ECE 517 Fall 2012/ch1b 1w40 as

2012-10-03T22:05:58Z

Svmankar: /* Reflection in Java */

CSC/ECE 517 Fall 2012/ch1b 1w40 as

2012-10-03T22:02:38Z

Svmankar: /* Features */

==Introduction==
[http://en.wikipedia.org/wiki/Reflection_%28computer_programming%29 Reflection ]is a relatively common [http://en.wikipedia.org/wiki/Computer_programming computer programming] concept where in the program has the inherent ability to examine itself at run time. Based on its observations the program can modify it's behavior for the given situation.The modifications can be any aspect of the programming language .i.e syntax, semantics, or implementation. Precisely, "Reflection" can be defined as a language's ability to inspect and dynamically call [http://en.wikipedia.org/wiki/Class_%28computer_programming%29 classes], methods, attributes, etc. at runtime. More advanced uses of reflection let you list and call methods, [http://en.wikipedia.org/wiki/Constructor_%28object-oriented_programming%29 constructors], etc.

Reflection is important since it lets you write programs that does not have to "know" everything at compile time, making them more dynamic, since they can be tied together at runtime. For example in a high level object oriented language the ability to inspect its class , interfaces and methods at run time without knowing their names at compile time. It provides the ability to modify , instantiate and access to methods such as getter's and setter's of a class. Since the program need not have all the information at compile time it makes the program more dynamic. The code can be written against known interfaces, but the actual classes to be used can be instantiated using reflection from configuration files. Lots of modern frameworks uses reflection extensively for this very reason. In [http://en.wikipedia.org/wiki/Scripting_language scripting languages] like Python reflection is even more tightly integrated, since it matches more naturally with the general programming model.

Reflection as a concept was first introduced in the doctoral dissertation of Dr. Brian Cantwell Smith<ref>[http://hdl.handle.net/1721.1/15961 Brian Cantwell Smith, Procedural Reflection in Programming Languages, Department of Electrical Engineering and Computer Science, Massachusetts Institute of Technology, PhD Thesis, 1982.]</ref><ref>[http://publications.csail.mit.edu/lcs/specpub.php?id=840 Brian C. Smith. Reflection and semantics in a procedural language. Technical Report MIT-LCS-TR-272, Massachusetts Institute of Technology, Cambridge, Mass., January 1982.]</ref> in 1992.

In the simple illustration provided below in ruby we can see how the name of a class can be obtained from the object and how we can get the ancestor classes and modules of a particular class.
<pre>

7.class #=> Fixnum

"helloworld".class #=> String

String.ancestors #=> [String, Enumerable, Comparable, Object, Kernel]

</pre>
Some of the common information that can be obtained from reflection are :
* Object type
* [http://en.wikipedia.org/wiki/Superclass_%28computer_science%29#Subclasses_and_superclasses Super classes] of any class
* [http://en.wikipedia.org/wiki/Method_(computer_programming) Methods]
* class fields
* [http://download.oracle.com/javase/tutorial/java/concepts/interface.html Interfaces]

These are discussed in detail in the below sections.
Common languages that exhibit reflection to varying degrees are Ruby, Java, Smalltalk, C# and more.

There are two basic types of reflection:
* Behavioral Reflection: This type of reflection changes the behaviour of the execution of the program based on observation and modification.
* Structural Reflection: This type of reflection deals with changing the very structure of the program such as the data structures and flow of control in the program.

==Implementation==
There are many challenges faced by designers of reflective languages. They must provide as much leeway as possible for late binging and at the same time they must optimize the compilation of the static components so that they are ready for run-time. Reflection is in essense a connection between the object-level (program) and meta-level (the processor). The ability of the object level to be able to observe and modify the meta-level information is the consequence of this connection. These actions can be termed as [http://en.wikipedia.org/wiki/Type_introspection introspection] (This involves the action of observing the class) and intercession (this involves the operation of modifying the behavior of the class). These actions can implemented with the implementation of the following components:

* Ability to create [http://en.wikipedia.org/wiki/First-class_object first class objects] ie [http://en.wikipedia.org/wiki/Reification_(computer_science) reification].

* Ability to convert a string that denotes a class or a method into its corresponding reference or invocation.

* Ability to use and create symbolic links to methods and classes.

==Reflection in C# ==
===Features===
In C#, Reflection uses the type system. C# is a [http://en.wikipedia.org/wiki/Strong_typing strongly-typed] language in which every variable and constant has a type. Not only this, but every expression that evaluates to a value is also associated with a type. Every method signature specifies a type for each input parameter and for the return value. A typical C# program uses the types from the class library as an addition to the user-defined types that are specific to the program's problem domain.

C# maintains a special database called the [http://en.wikipedia.org/wiki/Metadata ‘metadata’] where a compiled C# program is usually encoded and stored. This metadata can then be used by reflection to act upon and read the required data present in it. This provides astonishing features such as accessing the members of an object or class based on their string names. This can be done by using the System.Reflection namespace provided in C#.

As an example, the below program uses the System.Reflection namespace to access the metadata of itself. It searches for the public field with the name "_mynumber" and then acquires its value.

<pre>
using System;
using System.Reflection;

class ReflectionUsage
{
public static int _mynumber = 4;
static void Main()
{
Type type = typeof(ReflectionUsage);
FieldInfo info = type.GetField("_mynumber");
object obj = type.GetValue(null);
Console.WriteLine(obj);
}
}
</pre>
This program would then output the number ‘4’ which is the value that is assigned to the variable “_mynumber”.

Here is how the System.Reflection class contains in C#.

[[File:Csharp.jpg]]

Below are the several powerful reflection features that are provided by C#:

Field Reflection: This gives the power to scan or search the fields in your C# program by using the [http://msdn.microsoft.com/en-us/library/system.type.getfield%28v=vs.71%29.aspx GetField] or GetFields methods. Using this reflection we can load field values and then loop through those fields and display their names and values. The System.Reflection namespace provides a powerful and maintainable way to enumerate fields and properties. It can then access these fields by name.

SetValue Reflection: [http://msdn.microsoft.com/en-us/library/system.reflection.propertyinfo.setvalue%28v=vs.71%29.aspx SetValue] accesses the fields by their names. We can take a string that usually represents a target field, and then using the System.Reflection namespace methods, change the actual value of that field.
Below is an example that does precisely this:

<pre>
using System;
using System.Reflection;
class ReflectionUsage
{
public static int _myfield;
static void Main()
{
FieldInfo info = typeof(ReflectionUsage).GetField("_myfield");
info.SetValue(null, 2012);
Console.WriteLine(_myfield);
}
}
</pre>

The above program would output 2012 which is the value that we set using the SetValue reflection.

MethodInfo Invoke: Let us say we have the name of a method in the string format and want to invoke it. In such a case, one can use the [http://msdn.microsoft.com/en-us/library/system.type.getmethod%28v=vs.71%29.aspx GetMethod] method and then invoke the MethodInfo that can be acquired from it. The invoke method can be called to invoke method with the name specified by the string.

Type Reflection: [http://msdn.microsoft.com/en-us/library/system.type.aspx Type] is one of the most important types when using reflection in C#. The Type type is used to describe data types. It stores the C# type information in a variable, property or field and can be used as an argument.

Sizeof: The [http://msdn.microsoft.com/en-us/library/eahchzkf.aspx sizeof] operator exposes information about the implementation of types in the code. It does not require the System.Reflection namespace. However, it is related to reflection in the sense that it expresses information about the program itself.

===Advantages:===

1. In C#, one can write code that uses for example a System.Xml.XMLDataDocument class, which loads and parses an XML document and then allows you to parse the DOM during runtime. During parsing, every time that an <object> node is scanned, a new object needs to be created using its FQN (fully qualified name). Every time a <property> node is parsed, then its parent node's property needs to be set to a newly created object. Also, every time that a <function> node is parsed, the parent object that is created must have the function, by name, called on it using the arguments that are later defined. This would allow you to create any object type that you want, and set properties and call functions for initialization, in a very recursive manner. The use of reflection would render this code to be surprisingly small because it takes advantage of recursion and the generic nature of reflection.

2. Programs that use reflection have the ability to look inside themselves to see their own inner workings and structure. This capacity can lend them unique and powerful features that can be used to write better code.

===Disadvantages:===

1. One main disadvantage of using reflection would be that reflection in general is that they can render programs that are less clear to read, harder to understand. A new person reading the code can find it hard to grasp what the code is actually doing.

2. Another disadvantage is that it can render programs that are generally slower.

==Reflection in Java==
Reflection is a part of Java API which enables Java code to inspect and reflect Java components like class and objects during runtime. Classes in the java.lang.reflect package along with java.lang.Class and java.lang.Package take care of applications like degugger, interpreters, objects inspectors, class browsers. Important protocols such as SOAP and JavaBeans would not have been possible, if it weren't for Reflection. The aid a developer gets from an IDE during coding is achieved by using nothing else but Reflection. Reflection is one of the advanced features of Java, it gives runtime information about the objects, classes, fields and methods in a class, interfaces, etc. The image below shows some major functions related to java reflection.

[[File:Tjava_reflection.gif]]

Now we will have a look at some of the important features in Java Reflection and will see how they are implemented.
===Features ===
Classes: 
The first thing any programmer would do using reflection would be to inspect Java classes at runtime. The java package java.lang.Class helps to gather all important information about the class at runtime. We can obtain class name, class modifiers, constructors, field, method, superclass, implemented interface etc.

Before you can do any inspection on a class you need to obtain its java.lang.Class object. All types in Java including the primitive types (int, long, float etc.) including arrays have an associated Class object. If you know the name of the class at compile time you can obtain a Class object like this:
Code:
<pre>
public class DemoClass{
public static void main(String[] args)
{
Class obtainClass = DemoClass.class;
String className = obtainClass.getName();
System.out.printf("ClassName: %s\n",className);
}
}
</pre>
 Constructors: 

Using Java reflection one can inspect the constructors of classes and instantiate object of that class at runtime. This is done using Java class java.lang.reflect.Constructor. The steps to do this operation are as follows:
1) obtaining constructor objects
2) get constructor parameters
3) Instantiating Objects using constructors
<pre>
import java.lang.reflect.*;
public class DemoClass{

public String msg;

public DemoClass(String forMsg){
msg = forMsg;
}

public static void main(String[] args)
{
try{
Class obtainClass = DemoClass.class;
Constructor constructor = obtainClass.getConstructor(new Class[]{String.class});
DemoClass myDemo = (DemoClass)constructor.newInstance("Welcome to Java Reflection");
System.out.printf("New Instance String: %s\n",myDemo.msg);

}
catch(Exception e)
{
System.err.printf(e.getMessage());
}
}
}
</pre>
 Field: 
Inspecting the fields of classes and get/set them at runtime is another feature provided by Java Reflection. This is done using Java class java.lang.reflect.Field. To get/set a field value using Java reflection following are steps involved: obtaining field objects, field name, field type and getting and setting field values.
eg:
<pre>
Class objClass = MyObject.class;
Field[] methods = objClass.getFields();
</pre>

 Methods: 
One can also inspect the methods of class at runtime and invoke them. The class to implement this functionality is java.lang.reflect.Method. The steps to obtain methods from a class are:
Obtaining Method Objects
Method Parameters and Return Types
Invoking Methods using Method object.

For eg:
<pre>
Class objClass = MyObject.class;
Field[] methods = objClass.getMethods();
</pre>

===Advantages===

1) One of the major advantage of Java reflection is in debugging. While debugging one should be able to examine the private members of classes.
2) Also while testing one should be able to enlist all members of class along with the relationship with superclass so as to ensure that all code branches are covered.

===Disadvantages===
1) Java reflection provides access to private variables and methods, this exposes the implementation of the class. Such use of class functionalities which break the abstraction can result is portability problems in future upgrades.

2) Reflection involves method execution which resolve at runtime, so with certain Java virtual machines which do not perform optimizations can result in performance overhead with use to Java reflection.

==Reflection in Ruby==
Ruby is a dynamic language and one of many advantages which Ruby provides is its ability to introspect into a class or object known as reflection. What kind of introspection Ruby provides? It provides a way to inspect class objects using instance_of?, class hierarchy using ancestors, contents & behavior of class like which operations it supports, instance variables, etc and information on methods.

===Dynamic binding : Making reflection possible===

Ruby implements [http://en.wikipedia.org/wiki/Dynamic_dispatch dynamic binding] of objects. Dynamic binding plays a very important role in [http://en.wikipedia.org/wiki/Metaprogramming meta-programming].

In languages like C,C++; a simple assignment "a = b", would require 'a' and 'b' to be of the same type. The assignment is interpreted as copying b into a and is implemented by copying the contents of b into the space occupied by a. Thus if 'a' had been declared as an object whose memory size is less than b's object, then object slicing takes place i.e. only that part of 'b' which fits into a's memory would be copied. This behavior might lead to unintended consequences.

[[File:Slicing.gif]]

But dynamic binding in Ruby ensures that the type of object stored in a variable is determined at run time and not at compile time. Thus the assignment "a = b" is interpreted as binding 'a' to the same object that 'b' is bound to. It is implemented by copying the reference stored in b into the (pointer-sized) memory cell of 'a'. Thus 'a' and 'b' point to the same object after the assignment.

[[File:Before_binding.png]] [[File:After_binding.png]]

===Symbols and their usage in reflection techniques===

====Basics====
[http://en.wikipedia.org/wiki/Symbol_%28programming%29 Symbols] are objects used to represent names and strings inside a Ruby [http://en.wikipedia.org/wiki/Interpreter_%28computing%29 interpreter]. They are immutable and remain unique i.e. every instance of a particular symbol is the same symbol.

====Usage in reflection techniques====
Symbols are widely used in reflection to invoke methods dynamically. Reflection methods like 'respond_to', 'send' make use of symbols as a reference to other methods. Strings can also be used in place of symbols. However symbols are more efficient compared to strings in terms of memory and performance.

====Examples====

====Passing method by reference using a symbol====
<pre>
class Float
def poly
self*self*self + 2*self*self + 3*self + 4
end
end
</pre>
And we can pass poly to an integration routine:
<pre>
area = integrate(:poly, 0, 10)
</pre>

====Symbols in reflection====
[http://ruby-doc.org/core-1.9.2/Object.html#method-i-send Send] method

<pre>
irb(main):015:0> to = [:to_s , :to_f]
=> [:to_s, :to_f]
irb(main):016:0> to.each{|method| puts "#{method} => #{5.send method}"}
to_s => 5
to_f => 5.0
=> [:to_s, :to_f]
</pre>

[http://ruby-doc.org/core-1.9.2/Object.html#method-i-respond_to-3F respond_to] method

<pre>
5.respond_to? :slice #=> false
5.respond_to? :to_f #=> true
</pre>
<pre>
obj = Object.new
if obj.respond_to?(:program)
obj.program
else
puts "Sorry, the object doesn't understand the 'program' message."
end
</pre>

===method_missing===

Whenever a call to a method is made on an object , Ruby does a method look up. If the method is not found, Ruby calls a method named '[http://ruby-doc.org/docs/ProgrammingRuby/html/ref_c_object.html#Object.method_missing method_missing]'. Ruby knows the existence of the 'method_missing' as all objects are instances of 'BasicObject' which includes 'method_missing'. The default behavior of BasicObject#method_missing is to respond by raising a [http://www.ruby-doc.org/core-1.9.2/NoMethodError.html NoMethodError].

[http://en.wikipedia.org/wiki/Method_overriding Overriding] 'method_missing' allows users to call methods that don't really exist. The example below illustrates overriding of 'method_missing' to the programmer's advantage. Ruby passes as parameters the name of the method called and the arguments passed to it.

'''Example1'''
<pre>
class Cat
def mew
puts "Meow"
end
def method_missing(meth, *args)
puts "Sorry, I do not #{meth}"
end
end
c = Cat.new
c.mew
>>Meow
c.bark
>> Sorry, I do not bark
</pre>

In the above example, as the method 'bark' does not exist, method_missing is called with the meth (method name as a symbol) :bark. Hence the result " Sorry, I do not bark "

'''Example2'''
Using method_missing to convert Roman numerals <ref>http://www.rubyquiz.com/quiz22.html</ref> to integers

<pre>
class Roman

DIGITS = {
'I' => 1,
'V' => 5,
'X' => 10,
'L' => 50,
'C' => 100,
'D' => 500,
'M' => 1000,
}

def roman_to_integer(roman_string)
last = nil
roman_string.to_s.upcase.split(//).reverse.inject(0) do |memo, digit|
if digit_value = DIGITS[digit]
if last && last > digit_value
memo -= digit_value
else
memo += digit_value
end
last = digit_value
end
memo
end
end

def method_missing(method)
str = method.id2name
roman_to_integer(str)
end
end
</pre>

Evaluating Roman.xix calls the xix method of module Roman. Roman has no xix method, so method_missing is invoked with :xix as the argument.The id2name method of class Symbol is invoked on xix returning "xix". The "xix" is then parsed according to the rules for evaluating Roman numerals, and evaluates to 19.

''' Example 3 '''
<pre>
class Performer
def method_missing(name, *args)
"The duck will #{name}: #{args[0]}"
end
end

duck = Performer.new
duck.sing("Quacking in the Rain") # => "The duck will sing: Quacking in the Rain"
duck.dance("Swan Lake") # => "The duck will dance: Swan Lake"
</pre>

==Applications of Reflection==
*Reflection has become invaluable to programmers who need to connect code with data. For example in a GUI environment a button might need to invoke different methods in different classes. Reflection can be used here to call the method on any given class.

*Programmers who deal with a multitude of classes at the same time can use reflection to create a “serializer” that for a given class uses reflection to go through all the instance variables and processes them accordingly.

*Reflection is used in large test frameworks where reflection helps in identifying the test methods for different scenarios.

*Reflection provides the ability to morph the code based on dynamic situations. This provides a sense of artificial intelligence to the program as whole.

*Reflection can be used to debug and verify code as it provides access to the insides of a program.

*Reflection is very useful when the software is upgraded regularly. It provides an easy method to check for available methods and classes. This prevents the errors caused by the absense of methods and classes when they are deprecated.

==Feature Comparison==
Ruby provides a very good reflection ability where one can introspect various properties about an object and the class it belongs to, during runtime. One can obtain the list of methods that are supported on an object by using the 'methods' reflection method on the object. In addition, the 'class' reflection method enables one to query the class that an object belongs to. Similarly, the 'superclass' method allows one to inspect all the super classes of the class that an object belongs to.

In PHP, we have a class called as ReflectionClass which holds the class type for a particlar class. In the class row for PHP we can see that all Reflection operations can be performed on only class Reflection. So as to check if a particular instance belongs to class 'Foo', we need to first create the ReflectionClass object as shown and then call isInstance(argument) method on it. PHP also has getMethods() method which returns a list of class methods.

In Objective C, every type we see is of type class, whether it be String, Integer or Double. So type check in Objective C can be done using method isKindOfClass. But to perform other Reflection tasks, one needs to obtain the object of class first using the object_getClass(Class_Object) method. Once this object is obtained we can then perform operations like getting method list, etc as shown in table.
{|border="1" cellpadding="5" cellspacing="0" align="center"
|-
|
! scope="col" style="background:#efefef;" | Ruby
! scope="col" style="background:#efefef;" | PHP
! scope="col" style="background:#efefef;" | Objective C
|-
! scope="row" style="background:#efefef;" | Class
|Method: instance_of?
<pre>
obj.instance_of? String
</pre>
|Method: isInstance()
<pre>
<?php
$class = new ReflectionClass('Foo');
if ($class->isInstance($arg)) {
echo "Yes";
}
?>
</pre>
|Method: isKindOfClass
<pre>
if([myObject isKindOfClass:[MyObject class])
{
//do something
}
</pre>
|-
! scope="row" style="background:#efefef;" | Method
|Method: methods
<pre>
list = r.methods
</pre>
|Method: ReflectionClass::getMethods
<pre>
$class = new ReflectionClass('Apple');
$methods = $class->getMethods();
</pre>
|Method: class_copyMethodList()
<pre>
SomeClass * t = [[SomeClass alloc] init];
unsigned int mc = 0;
Method * mlist =
class_copyMethodList
(object_getClass(t), &mc);
</pre>
|-
! scope="row" style="background:#efefef;" | Type
|Method: Object.class
<pre>
"Hello".class
>>String
</pre>
|Method: gettype()
<pre>
<?php
$data = array(1, 'foo');
foreach ($data as $value) {
echo gettype($value), "\n";
}?>
</pre>
|Method: isKindOfClass
<pre>
if([myDemo isKindOfClass:[DemoClass class]])
{
//code
}
</pre>
|-
! scope="row" style="background:#efefef;" | String representation of an object
|Method: to_s
<pre>
obj.to_s
</pre>
|Method: ReflectionClass::__toString —
<pre>
<?php
$reflectionClass =
new ReflectionClass(MyDemoClass);
echo $reflectionClass->__toString();
?>
</pre>
|Method: [NSString stringWithFormat:""]
<pre>
*objString = [NSString
stringWithFormat:”%@”,myObject]
</pre>
|}

==Advantages and Disadvantages of reflection==

===Advantages===
* Extensibility: Reflection provides the capability of using external and user defined classes by instantiation of extensibility objects using their fully qualified names.
* Class browsers in IDEs: The ability to examine the members of classes makes implementation of visual aids, auto-completion and documentation easy in development tools for programmers.
* Debugging and Test Harness: Reflection allows the user to observe the private members in classes. This capability can be used to debug classes and their interactions. Reflection can be used to call a set of testing APIs defined on a class for maximum coverage of testing.
* Correctness: Reflection improves the robustness and the correctness of a program especially in dynamically typed languages as runtime checks can be added to check the availability of the methods or classes.

===Disadvantages===
* Performance Overhead: Reflection resolves types of objects and classes are dynamically at runtime, this introduces lot of performance overhead when compared to non-reflective code. Hence it should be used judiciously.
* Security: At run-time binding in reflection we loose the security of compile time checks and verification. It also provides access to the internals of a class or an encapsulated object like private methods and variables which makes security a major issue.
*Portability: Another issue is of portability, over a period of time the code may change during updates and a Reflective code breaks abstraction. Such a code may change behavior during updates and may become dysfunctional.

==Conclusion==
This article makes an attempt to explain the concept of Reflection in Object Oriented Programming. The article mentions the different approaches to reflection in Ruby and other languages.It mentions the usage of Reflections and the advantages and disadvantages of using Reflection. A follow up to this article would be to study the concept of [http://en.wikipedia.org/wiki/Metaprogramming Metaprogramming].

==References==
<references/>

==Additional Reading==
*[http://en.wikipedia.org/wiki/Reflection_(computer_programming) Reflection]
*[http://www.cs.indiana.edu/~jsobel/rop.html An Introduction to Reflection-Oriented Programming]
*[http://tutorials.jenkov.com/java-reflection/classes.html Java Reflection]
*[http://www.slideshare.net/CiaranMcHale/java-reflection-explained-simply Java reflection basics]
*[http://www2.parc.com/csl/groups/sda/projects/reflection96/docs/malenfant/ref96/ref96.html A Tutorial on Behavioral Reflection and its Implementation]
*[http://www.quora.com/Computer-Programming/How-is-reflection-useful Uses of reflection]
*[http://download.oracle.com/javase/tutorial/reflect/index.html Java reflection official website]
*[http://ruby-doc.org/docs/ProgrammingRuby/html/builtins.html Ruby Documentation]
*[http://www.slideshare.net/MarcusDenker/behavioral-reflection Behavioral reflection]

CSC/ECE 517 Fall 2012/ch1b 1w40 as

2012-10-03T21:58:23Z

Svmankar: /* Features */

==Introduction==
[http://en.wikipedia.org/wiki/Reflection_%28computer_programming%29 Reflection ]is a relatively common [http://en.wikipedia.org/wiki/Computer_programming computer programming] concept where in the program has the inherent ability to examine itself at run time. Based on its observations the program can modify it's behavior for the given situation.The modifications can be any aspect of the programming language .i.e syntax, semantics, or implementation. Precisely, "Reflection" can be defined as a language's ability to inspect and dynamically call [http://en.wikipedia.org/wiki/Class_%28computer_programming%29 classes], methods, attributes, etc. at runtime. More advanced uses of reflection let you list and call methods, [http://en.wikipedia.org/wiki/Constructor_%28object-oriented_programming%29 constructors], etc.

Reflection is important since it lets you write programs that does not have to "know" everything at compile time, making them more dynamic, since they can be tied together at runtime. For example in a high level object oriented language the ability to inspect its class , interfaces and methods at run time without knowing their names at compile time. It provides the ability to modify , instantiate and access to methods such as getter's and setter's of a class. Since the program need not have all the information at compile time it makes the program more dynamic. The code can be written against known interfaces, but the actual classes to be used can be instantiated using reflection from configuration files. Lots of modern frameworks uses reflection extensively for this very reason. In [http://en.wikipedia.org/wiki/Scripting_language scripting languages] like Python reflection is even more tightly integrated, since it matches more naturally with the general programming model.

Reflection as a concept was first introduced in the doctoral dissertation of Dr. Brian Cantwell Smith<ref>[http://hdl.handle.net/1721.1/15961 Brian Cantwell Smith, Procedural Reflection in Programming Languages, Department of Electrical Engineering and Computer Science, Massachusetts Institute of Technology, PhD Thesis, 1982.]</ref><ref>[http://publications.csail.mit.edu/lcs/specpub.php?id=840 Brian C. Smith. Reflection and semantics in a procedural language. Technical Report MIT-LCS-TR-272, Massachusetts Institute of Technology, Cambridge, Mass., January 1982.]</ref> in 1992.

In the simple illustration provided below in ruby we can see how the name of a class can be obtained from the object and how we can get the ancestor classes and modules of a particular class.
<pre>

7.class #=> Fixnum

"helloworld".class #=> String

String.ancestors #=> [String, Enumerable, Comparable, Object, Kernel]

</pre>
Some of the common information that can be obtained from reflection are :
* Object type
* [http://en.wikipedia.org/wiki/Superclass_%28computer_science%29#Subclasses_and_superclasses Super classes] of any class
* [http://en.wikipedia.org/wiki/Method_(computer_programming) Methods]
* class fields
* [http://download.oracle.com/javase/tutorial/java/concepts/interface.html Interfaces]

These are discussed in detail in the below sections.
Common languages that exhibit reflection to varying degrees are Ruby, Java, Smalltalk, C# and more.

There are two basic types of reflection:
* Behavioral Reflection: This type of reflection changes the behaviour of the execution of the program based on observation and modification.
* Structural Reflection: This type of reflection deals with changing the very structure of the program such as the data structures and flow of control in the program.

==Implementation==
There are many challenges faced by designers of reflective languages. They must provide as much leeway as possible for late binging and at the same time they must optimize the compilation of the static components so that they are ready for run-time. Reflection is in essense a connection between the object-level (program) and meta-level (the processor). The ability of the object level to be able to observe and modify the meta-level information is the consequence of this connection. These actions can be termed as [http://en.wikipedia.org/wiki/Type_introspection introspection] (This involves the action of observing the class) and intercession (this involves the operation of modifying the behavior of the class). These actions can implemented with the implementation of the following components:

* Ability to create [http://en.wikipedia.org/wiki/First-class_object first class objects] ie [http://en.wikipedia.org/wiki/Reification_(computer_science) reification].

* Ability to convert a string that denotes a class or a method into its corresponding reference or invocation.

* Ability to use and create symbolic links to methods and classes.

==Reflection in C# ==
===Features===
In C#, Reflection uses the type system. C# is a [http://en.wikipedia.org/wiki/Strong_typing strongly-typed] language in which every variable and constant has a type. Not only this, but every expression that evaluates to a value is also associated with a type. Every method signature specifies a type for each input parameter and for the return value. A typical C# program uses the types from the class library as an addition to the user-defined types that are specific to the program's problem domain.

C# maintains a special database called the [http://en.wikipedia.org/wiki/Metadata ‘metadata’] where a compiled C# program is usually encoded and stored. This metadata can then be used by reflection to act upon and read the required data present in it. This provides astonishing features such as accessing the members of an object or class based on their string names. This can be done by using the System.Reflection namespace provided in C#.

As an example, the below program uses the System.Reflection namespace to access the metadata of itself. It searches for the public field with the name "_mynumber" and then acquires its value.

<pre>
using System;
using System.Reflection;

class ReflectionUsage
{
public static int _mynumber = 4;
static void Main()
{
Type type = typeof(ReflectionUsage);
FieldInfo info = type.GetField("_mynumber");
object obj = type.GetValue(null);
Console.WriteLine(obj);
}
}
</pre>
This program would then output the number ‘4’ which is the value that is assigned to the variable “_mynumber”.

Here is how the System.Reflection class contains in C#.

[[File:Csharp.jpg]]

Below are the several powerful reflection features that are provided by C#:

Field Reflection: This gives the power to scan or search the fields in your C# program by using the GetField or GetFields methods. Using this reflection we can load field values and then loop through those fields and display their names and values. The System.Reflection namespace provides a powerful and maintainable way to enumerate fields and properties. It can then access these fields by name.

SetValue Reflection: SetValue accesses the fields by their names. We can take a string that usually represents a target field, and then using the System.Reflection namespace methods, change the actual value of that field.
Below is an example that does precisely this:

<pre>
using System;
using System.Reflection;
class ReflectionUsage
{
public static int _myfield;
static void Main()
{
FieldInfo info = typeof(ReflectionUsage).GetField("_myfield");
info.SetValue(null, 2012);
Console.WriteLine(_myfield);
}
}
</pre>

The above program would output 2012 which is the value that we set using the SetValue reflection.

MethodInfo Invoke: Let us say we have the name of a method in the string format and want to invoke it. In such a case, one can use the GetMethod method and then invoke the MethodInfo that can be acquired from it. The invoke method can be called to invoke method with the name specified by the string.

Type Reflection: Type is one of the most important types when using reflection in C#. The Type type is used to describe data types. It stores the C# type information in a variable, property or field and can be used as an argument.

Sizeof: The sizeof operator exposes information about the implementation of types in the code. It does not require the System.Reflection namespace. However, it is related to reflection in the sense that it expresses information about the program itself.

===Advantages:===

1. In C#, one can write code that uses for example a System.Xml.XMLDataDocument class, which loads and parses an XML document and then allows you to parse the DOM during runtime. During parsing, every time that an <object> node is scanned, a new object needs to be created using its FQN (fully qualified name). Every time a <property> node is parsed, then its parent node's property needs to be set to a newly created object. Also, every time that a <function> node is parsed, the parent object that is created must have the function, by name, called on it using the arguments that are later defined. This would allow you to create any object type that you want, and set properties and call functions for initialization, in a very recursive manner. The use of reflection would render this code to be surprisingly small because it takes advantage of recursion and the generic nature of reflection.

2. Programs that use reflection have the ability to look inside themselves to see their own inner workings and structure. This capacity can lend them unique and powerful features that can be used to write better code.

===Disadvantages:===

1. One main disadvantage of using reflection would be that reflection in general is that they can render programs that are less clear to read, harder to understand. A new person reading the code can find it hard to grasp what the code is actually doing.

2. Another disadvantage is that it can render programs that are generally slower.

==Reflection in Java==
Reflection is a part of Java API which enables Java code to inspect and reflect Java components like class and objects during runtime. Classes in the java.lang.reflect package along with java.lang.Class and java.lang.Package take care of applications like degugger, interpreters, objects inspectors, class browsers. Important protocols such as SOAP and JavaBeans would not have been possible, if it weren't for Reflection. The aid a developer gets from an IDE during coding is achieved by using nothing else but Reflection. Reflection is one of the advanced features of Java, it gives runtime information about the objects, classes, fields and methods in a class, interfaces, etc. The image below shows some major functions related to java reflection.

[[File:Tjava_reflection.gif]]

Now we will have a look at some of the important features in Java Reflection and will see how they are implemented.
===Features ===
Classes: 
The first thing any programmer would do using reflection would be to inspect Java classes at runtime. The java package java.lang.Class helps to gather all important information about the class at runtime. We can obtain class name, class modifiers, constructors, field, method, superclass, implemented interface etc.

Before you can do any inspection on a class you need to obtain its java.lang.Class object. All types in Java including the primitive types (int, long, float etc.) including arrays have an associated Class object. If you know the name of the class at compile time you can obtain a Class object like this:
Code:
<pre>
public class DemoClass{
public static void main(String[] args)
{
Class obtainClass = DemoClass.class;
String className = obtainClass.getName();
System.out.printf("ClassName: %s\n",className);
}
}
</pre>
 Constructors: 

Using Java reflection one can inspect the constructors of classes and instantiate object of that class at runtime. This is done using Java class java.lang.reflect.Constructor. The steps to do this operation are as follows:
1) obtaining constructor objects
2) get constructor parameters
3) Instantiating Objects using constructors
<pre>
import java.lang.reflect.*;
public class DemoClass{

public String msg;

public DemoClass(String forMsg){
msg = forMsg;
}

public static void main(String[] args)
{
try{
Class obtainClass = DemoClass.class;
Constructor constructor = obtainClass.getConstructor(new Class[]{String.class});
DemoClass myDemo = (DemoClass)constructor.newInstance("Welcome to Java Reflection");
System.out.printf("New Instance String: %s\n",myDemo.msg);

}
catch(Exception e)
{
System.err.printf(e.getMessage());
}
}
}
</pre>
 Field: 
Inspecting the fields of classes and get/set them at runtime is another feature provided by Java Reflection. This is done using Java class java.lang.reflect.Field. To get/set a field value using Java reflection following are steps involved: obtaining field objects, field name, field type and getting and setting field values.
eg:
<pre>
Class objClass = MyObject.class;
Field[] methods = objClass.getFields();
</pre>

 Methods: 
One can also inspect the methods of class at runtime and invoke them. The class to implement this functionality is java.lang.reflect.Method. The steps to obtain methods from a class are:
Obtaining Method Objects
Method Parameters and Return Types
Invoking Methods using Method object.

For eg:
<pre>
Class objClass = MyObject.class;
Field[] methods = objClass.getMethods();
</pre>

===Advantages===

1) One of the major advantage of Java reflection is in debugging. While debugging one should be able to examine the private members of classes.
2) Also while testing one should be able to enlist all members of class along with the relationship with superclass so as to ensure that all code branches are covered.

===Disadvantages===
1) Java reflection provides access to private variables and methods, this exposes the implementation of the class. Such use of class functionalities which break the abstraction can result is portability problems in future upgrades.

2) Reflection involves method execution which resolve at runtime, so with certain Java virtual machines which do not perform optimizations can result in performance overhead with use to Java reflection.

==Reflection in Ruby==
Ruby is a dynamic language and one of many advantages which Ruby provides is its ability to introspect into a class or object known as reflection. What kind of introspection Ruby provides? It provides a way to inspect class objects using instance_of?, class hierarchy using ancestors, contents & behavior of class like which operations it supports, instance variables, etc and information on methods.

===Dynamic binding : Making reflection possible===

Ruby implements [http://en.wikipedia.org/wiki/Dynamic_dispatch dynamic binding] of objects. Dynamic binding plays a very important role in [http://en.wikipedia.org/wiki/Metaprogramming meta-programming].

In languages like C,C++; a simple assignment "a = b", would require 'a' and 'b' to be of the same type. The assignment is interpreted as copying b into a and is implemented by copying the contents of b into the space occupied by a. Thus if 'a' had been declared as an object whose memory size is less than b's object, then object slicing takes place i.e. only that part of 'b' which fits into a's memory would be copied. This behavior might lead to unintended consequences.

[[File:Slicing.gif]]

But dynamic binding in Ruby ensures that the type of object stored in a variable is determined at run time and not at compile time. Thus the assignment "a = b" is interpreted as binding 'a' to the same object that 'b' is bound to. It is implemented by copying the reference stored in b into the (pointer-sized) memory cell of 'a'. Thus 'a' and 'b' point to the same object after the assignment.

[[File:Before_binding.png]] [[File:After_binding.png]]

===Symbols and their usage in reflection techniques===

====Basics====
[http://en.wikipedia.org/wiki/Symbol_%28programming%29 Symbols] are objects used to represent names and strings inside a Ruby [http://en.wikipedia.org/wiki/Interpreter_%28computing%29 interpreter]. They are immutable and remain unique i.e. every instance of a particular symbol is the same symbol.

====Usage in reflection techniques====
Symbols are widely used in reflection to invoke methods dynamically. Reflection methods like 'respond_to', 'send' make use of symbols as a reference to other methods. Strings can also be used in place of symbols. However symbols are more efficient compared to strings in terms of memory and performance.

====Examples====

====Passing method by reference using a symbol====
<pre>
class Float
def poly
self*self*self + 2*self*self + 3*self + 4
end
end
</pre>
And we can pass poly to an integration routine:
<pre>
area = integrate(:poly, 0, 10)
</pre>

====Symbols in reflection====
[http://ruby-doc.org/core-1.9.2/Object.html#method-i-send Send] method

<pre>
irb(main):015:0> to = [:to_s , :to_f]
=> [:to_s, :to_f]
irb(main):016:0> to.each{|method| puts "#{method} => #{5.send method}"}
to_s => 5
to_f => 5.0
=> [:to_s, :to_f]
</pre>

[http://ruby-doc.org/core-1.9.2/Object.html#method-i-respond_to-3F respond_to] method

<pre>
5.respond_to? :slice #=> false
5.respond_to? :to_f #=> true
</pre>
<pre>
obj = Object.new
if obj.respond_to?(:program)
obj.program
else
puts "Sorry, the object doesn't understand the 'program' message."
end
</pre>

===method_missing===

Whenever a call to a method is made on an object , Ruby does a method look up. If the method is not found, Ruby calls a method named '[http://ruby-doc.org/docs/ProgrammingRuby/html/ref_c_object.html#Object.method_missing method_missing]'. Ruby knows the existence of the 'method_missing' as all objects are instances of 'BasicObject' which includes 'method_missing'. The default behavior of BasicObject#method_missing is to respond by raising a [http://www.ruby-doc.org/core-1.9.2/NoMethodError.html NoMethodError].

[http://en.wikipedia.org/wiki/Method_overriding Overriding] 'method_missing' allows users to call methods that don't really exist. The example below illustrates overriding of 'method_missing' to the programmer's advantage. Ruby passes as parameters the name of the method called and the arguments passed to it.

'''Example1'''
<pre>
class Cat
def mew
puts "Meow"
end
def method_missing(meth, *args)
puts "Sorry, I do not #{meth}"
end
end
c = Cat.new
c.mew
>>Meow
c.bark
>> Sorry, I do not bark
</pre>

In the above example, as the method 'bark' does not exist, method_missing is called with the meth (method name as a symbol) :bark. Hence the result " Sorry, I do not bark "

'''Example2'''
Using method_missing to convert Roman numerals <ref>http://www.rubyquiz.com/quiz22.html</ref> to integers

<pre>
class Roman

DIGITS = {
'I' => 1,
'V' => 5,
'X' => 10,
'L' => 50,
'C' => 100,
'D' => 500,
'M' => 1000,
}

def roman_to_integer(roman_string)
last = nil
roman_string.to_s.upcase.split(//).reverse.inject(0) do |memo, digit|
if digit_value = DIGITS[digit]
if last && last > digit_value
memo -= digit_value
else
memo += digit_value
end
last = digit_value
end
memo
end
end

def method_missing(method)
str = method.id2name
roman_to_integer(str)
end
end
</pre>

Evaluating Roman.xix calls the xix method of module Roman. Roman has no xix method, so method_missing is invoked with :xix as the argument.The id2name method of class Symbol is invoked on xix returning "xix". The "xix" is then parsed according to the rules for evaluating Roman numerals, and evaluates to 19.

''' Example 3 '''
<pre>
class Performer
def method_missing(name, *args)
"The duck will #{name}: #{args[0]}"
end
end

duck = Performer.new
duck.sing("Quacking in the Rain") # => "The duck will sing: Quacking in the Rain"
duck.dance("Swan Lake") # => "The duck will dance: Swan Lake"
</pre>

==Applications of Reflection==
*Reflection has become invaluable to programmers who need to connect code with data. For example in a GUI environment a button might need to invoke different methods in different classes. Reflection can be used here to call the method on any given class.

*Programmers who deal with a multitude of classes at the same time can use reflection to create a “serializer” that for a given class uses reflection to go through all the instance variables and processes them accordingly.

*Reflection is used in large test frameworks where reflection helps in identifying the test methods for different scenarios.

*Reflection provides the ability to morph the code based on dynamic situations. This provides a sense of artificial intelligence to the program as whole.

*Reflection can be used to debug and verify code as it provides access to the insides of a program.

*Reflection is very useful when the software is upgraded regularly. It provides an easy method to check for available methods and classes. This prevents the errors caused by the absense of methods and classes when they are deprecated.

==Feature Comparison==
Ruby provides a very good reflection ability where one can introspect various properties about an object and the class it belongs to, during runtime. One can obtain the list of methods that are supported on an object by using the 'methods' reflection method on the object. In addition, the 'class' reflection method enables one to query the class that an object belongs to. Similarly, the 'superclass' method allows one to inspect all the super classes of the class that an object belongs to.

In PHP, we have a class called as ReflectionClass which holds the class type for a particlar class. In the class row for PHP we can see that all Reflection operations can be performed on only class Reflection. So as to check if a particular instance belongs to class 'Foo', we need to first create the ReflectionClass object as shown and then call isInstance(argument) method on it. PHP also has getMethods() method which returns a list of class methods.

In Objective C, every type we see is of type class, whether it be String, Integer or Double. So type check in Objective C can be done using method isKindOfClass. But to perform other Reflection tasks, one needs to obtain the object of class first using the object_getClass(Class_Object) method. Once this object is obtained we can then perform operations like getting method list, etc as shown in table.
{|border="1" cellpadding="5" cellspacing="0" align="center"
|-
|
! scope="col" style="background:#efefef;" | Ruby
! scope="col" style="background:#efefef;" | PHP
! scope="col" style="background:#efefef;" | Objective C
|-
! scope="row" style="background:#efefef;" | Class
|Method: instance_of?
<pre>
obj.instance_of? String
</pre>
|Method: isInstance()
<pre>
<?php
$class = new ReflectionClass('Foo');
if ($class->isInstance($arg)) {
echo "Yes";
}
?>
</pre>
|Method: isKindOfClass
<pre>
if([myObject isKindOfClass:[MyObject class])
{
//do something
}
</pre>
|-
! scope="row" style="background:#efefef;" | Method
|Method: methods
<pre>
list = r.methods
</pre>
|Method: ReflectionClass::getMethods
<pre>
$class = new ReflectionClass('Apple');
$methods = $class->getMethods();
</pre>
|Method: class_copyMethodList()
<pre>
SomeClass * t = [[SomeClass alloc] init];
unsigned int mc = 0;
Method * mlist =
class_copyMethodList
(object_getClass(t), &mc);
</pre>
|-
! scope="row" style="background:#efefef;" | Type
|Method: Object.class
<pre>
"Hello".class
>>String
</pre>
|Method: gettype()
<pre>
<?php
$data = array(1, 'foo');
foreach ($data as $value) {
echo gettype($value), "\n";
}?>
</pre>
|Method: isKindOfClass
<pre>
if([myDemo isKindOfClass:[DemoClass class]])
{
//code
}
</pre>
|-
! scope="row" style="background:#efefef;" | String representation of an object
|Method: to_s
<pre>
obj.to_s
</pre>
|Method: ReflectionClass::__toString —
<pre>
<?php
$reflectionClass =
new ReflectionClass(MyDemoClass);
echo $reflectionClass->__toString();
?>
</pre>
|Method: [NSString stringWithFormat:""]
<pre>
*objString = [NSString
stringWithFormat:”%@”,myObject]
</pre>
|}

==Advantages and Disadvantages of reflection==

===Advantages===
* Extensibility: Reflection provides the capability of using external and user defined classes by instantiation of extensibility objects using their fully qualified names.
* Class browsers in IDEs: The ability to examine the members of classes makes implementation of visual aids, auto-completion and documentation easy in development tools for programmers.
* Debugging and Test Harness: Reflection allows the user to observe the private members in classes. This capability can be used to debug classes and their interactions. Reflection can be used to call a set of testing APIs defined on a class for maximum coverage of testing.
* Correctness: Reflection improves the robustness and the correctness of a program especially in dynamically typed languages as runtime checks can be added to check the availability of the methods or classes.

===Disadvantages===
* Performance Overhead: Reflection resolves types of objects and classes are dynamically at runtime, this introduces lot of performance overhead when compared to non-reflective code. Hence it should be used judiciously.
* Security: At run-time binding in reflection we loose the security of compile time checks and verification. It also provides access to the internals of a class or an encapsulated object like private methods and variables which makes security a major issue.
*Portability: Another issue is of portability, over a period of time the code may change during updates and a Reflective code breaks abstraction. Such a code may change behavior during updates and may become dysfunctional.

==Conclusion==
This article makes an attempt to explain the concept of Reflection in Object Oriented Programming. The article mentions the different approaches to reflection in Ruby and other languages.It mentions the usage of Reflections and the advantages and disadvantages of using Reflection. A follow up to this article would be to study the concept of [http://en.wikipedia.org/wiki/Metaprogramming Metaprogramming].

==References==
<references/>

==Additional Reading==
*[http://en.wikipedia.org/wiki/Reflection_(computer_programming) Reflection]
*[http://www.cs.indiana.edu/~jsobel/rop.html An Introduction to Reflection-Oriented Programming]
*[http://tutorials.jenkov.com/java-reflection/classes.html Java Reflection]
*[http://www.slideshare.net/CiaranMcHale/java-reflection-explained-simply Java reflection basics]
*[http://www2.parc.com/csl/groups/sda/projects/reflection96/docs/malenfant/ref96/ref96.html A Tutorial on Behavioral Reflection and its Implementation]
*[http://www.quora.com/Computer-Programming/How-is-reflection-useful Uses of reflection]
*[http://download.oracle.com/javase/tutorial/reflect/index.html Java reflection official website]
*[http://ruby-doc.org/docs/ProgrammingRuby/html/builtins.html Ruby Documentation]
*[http://www.slideshare.net/MarcusDenker/behavioral-reflection Behavioral reflection]