File:2-26.jpg

2009-11-18T04:27:06Z

Abhatt:

CSC/ECE 517 Fall 2009/wiki1b 13 zz

2009-11-18T04:20:10Z

Abhatt:

Bob Martin's Stable Dependencies Principle says, "The dependencies between packages should be in the direction of the stability of the packages. A package should only depend upon packages that are more stable than it is."

=Bob Martin=

[http://today.java.net/pub/au/90 Robert C. Martin] (Uncle Bob) defines the domain of [http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf design patterns] to be the architecture of systems modules (packages, classes and components) and their interconnections. His design patterns address the four major reasons for failure of the systems: rigidity, fragility, immobility and viscosity [http://www.objectmentor.com/resources/articles/oodmetrc.pdf].

Following are the list of few design principles quoted by him to avoid the pitfalls associated with unsuccessful software engineering,
[http://labs.cs.utt.ro/labs/ip2/html/lectures/5/lecture5.ppt Reuse/Release Equivalence Principle],
[http://iface.wordpress.com/2006/04/08/common-closure-principle/ Common Closure Principle],
[http://www.objectmentor.com/omSolutions/oops_what.html Common Reuse Principle],
[http://ifacethoughts.net/2006/04/10/acyclic-dependencies-principle/ Acyclic Dependencies Principle],
[http://www.objectmentor.com/resources/articles/stability.pdf Staple Dependencies Principle],
[http://ifacethoughts.net/2006/04/20/stable-abstractions-principle/ Stable Abstraction Principle].

The objective of this article is to discuss in detail Stable Dependencies Principle. Each of the four problems discussed above can be caused by improper dependencies between the modules of the software. It is the dependency architecture that degrades the ability of the software to be maintained. The Stable Dependencies Principle is one of the principle which discusses its concern with coupling of packages, or the degree to which they rely on each other.

=Stable Dependencies Principle=
<blockquote>
Principle:
''The dependencies between packages should be in the direction of the stability of the packages. A package should only depend upon packages that are more stable than it is.''
</blockquote>

Essentially, if we want stuff to be changed, we want it to be easy, so we need to ensure our design is such that we keep all the changing stuff in one place and independent. This can be done by measuring the afferent (from outside in) and efferent (from inside out) dependencies of classes in the package.

Packages can be classified as stable(difficult to change) and volatile(easy to change). Stable packages must not depend on Volatile one because

- It makes Volatile packages harder to change

- Or It may force stable packages to be changed often, in other words volatile becomes stable

Thus we have to ensure that volatile packages must depend on stable packages.

//does this example make sense ???

Lets consider an example where a Class library L depends on the collection class library C which further depends on special memory allocation library M. For execution speed, API of C is modeled after API of M. Now M has a serious bug which needs to be fixed. Thus Class C needs to be updated. How does this affect all the classes here?

- Fixing issues in Class M causes API changes in C which requires changes in the header files of Class C

- As API of M reflects in API of C, L also has to be modified too.

==Stability==
What does stability mean? By simply goggling stability, we get definitions like resistance to change, reliability etc [http://www.answers.com/topic/stability]. Thus it roughly means "hard to change", whereas instability means "easy to change".

Consider an example, in which you stand a penny on its side. Is this penny stable in that position? Mostly people would answer a no, even though it does not change its position for a very long time. Thus, stability has nothing directly to do with the frequency of change. It more relates to the amount of work required to make a change. The penny is not stable because it takes little work to topple it.

Thus stability of a software package would depend on various factors like size, complexity, clarity, etc. But with respect to our principle, stability focus on a different factor. A software package would be difficult to change, if it has lots of other software packages depend on upon it. Thus a package with lots of incoming dependencies is very stable because it requires a great deal of work for any change to propagate with all the dependent packages.

==Stability and Dependencies==
With the above definition of stability, you don't want to increase stability of the packages as your software can not change easily then. But if the system has been designed well then hard to change packages or stable packages will not change that frequently. Thus, we need to understand the relationship between stability and dependencies.

Consider a following example, Here package x, depends on three other packages. Thus, it is said that x is responsible to the other three packages. On other hand, x does not depend on anything, thus it does not influence any other change. It is said to be independent [http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf].

[[Image:2-25.jpg]]

(Could you put an image here figure 2-25 on page 23)

Another example, here package y has no packages depending upon it, thus we call it irresponsible. It is very instable package. But there are three other packages that y depends upon, so changes from these three external packages may affect it and thus we say y is dependent.

(Could you put an image here figure 2-26 on page 23)

Thus we need to be careful while designing packages especially lower level packages (which would have more users) and higher level packages (which would tend to have fewer users).

File:2-25.jpg

2009-11-18T04:15:03Z

Abhatt: Stablity and dependencies

Stablity and dependencies

CSC/ECE 517 Fall 2009/wiki1b 13 zz

2009-11-18T02:33:43Z

Abhatt: /* Stable Dependencies Principle */

Bob Martin's Stable Dependencies Principle says, "The dependencies between packages should be in the direction of the stability of the packages. A package should only depend upon packages that are more stable than it is."

=Bob Martin=

[http://today.java.net/pub/au/90 Robert C. Martin] (Uncle Bob) defines the domain of [http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf design patterns] to be the architecture of systems modules (packages, classes and components) and their interconnections. His design patterns address the four major reasons for failure of the systems: rigidity, fragility, immobility and viscosity [http://www.objectmentor.com/resources/articles/oodmetrc.pdf].

Following are the list of few design principles quoted by him to avoid the pitfalls associated with unsuccessful software engineering,
[http://labs.cs.utt.ro/labs/ip2/html/lectures/5/lecture5.ppt Reuse/Release Equivalence Principle],
[http://iface.wordpress.com/2006/04/08/common-closure-principle/ Common Closure Principle],
[http://www.objectmentor.com/omSolutions/oops_what.html Common Reuse Principle],
[http://ifacethoughts.net/2006/04/10/acyclic-dependencies-principle/ Acyclic Dependencies Principle],
[http://www.objectmentor.com/resources/articles/stability.pdf Staple Dependencies Principle],
[http://ifacethoughts.net/2006/04/20/stable-abstractions-principle/ Stable Abstraction Principle].

The objective of this article is to discuss in detail Stable Dependencies Principle. Each of the four problems discussed above can be caused by improper dependencies between the modules of the software. It is the dependency architecture that degrades the ability of the software to be maintained. The Stable Dependencies Principle is one of the principle which discusses its concern with coupling of packages, or the degree to which they rely on each other.

=Stable Dependencies Principle=
<blockquote>
Principle:
''The dependencies between packages should be in the direction of the stability of the packages. A package should only depend upon packages that are more stable than it is.''
</blockquote>

Essentially, if we want stuff to be changed, we want it to be easy, so we need to ensure our design is such that we keep all the changing stuff in one place and independent. This can be done by measuring the afferent (from outside in) and efferent (from inside out) dependencies of classes in the package.

Packages can be classified as stable(difficult to change) and volatile(easy to change). Stable packages must not depend on Volatile one because

- It makes Volatile packages harder to change

- Or It may force stable packages to be changed often, in other words volatile becomes stable

Thus we have to ensure that volatile packages must depend on stable packages.

//does this example make sense ???

Lets consider an example where a Class library L depends on the collection class library C which further depends on special memory allocation library M. For execution speed, API of C is modeled after API of M. Now M has a serious bug which needs to be fixed. Thus Class C needs to be updated. How does this affect all the classes here?

- Fixing issues in Class M causes API changes in C which requires changes in the header files of Class C

- As API of M reflects in API of C, L also has to be modified too.

==Stability==
What does stability mean? By simply goggling stability, we get definitions like resistance to change, reliability etc [http://www.answers.com/topic/stability]. Thus it roughly means "hard to change", whereas instability means "easy to change".

Consider an example, in which you stand a penny on its side. Is this penny stable in that position? Mostly people would answer a no, even though it does not change its position for a very long time. Thus, stability has nothing directly to do with the frequency of change. It more relates to the amount of work required to make a change. The penny is not stable because it takes little work to topple it.

Thus stability of a software package would depend on various factors like size, complexity, clarity, etc. But with respect to our principle, stability focus on a different factor. A software package would be difficult to change, if it has lots of other software packages depend on upon it. Thus a package with lots of incoming dependencies is very stable because it requires a great deal of work for any change to propagate with all the dependent packages.

==Stability and Dependencies==
With the above definition of stability, you don't want to increase stability of the packages as your software can not change easily then. But if the system has been designed well then hard to change packages or stable packages will not change that frequently. Thus, we need to understand the relationship between stability and dependencies.

Consider a following example, Here package x, depends on three other packages. Thus, it is said that x is responsible to the other three packages. On other hand, x does not depend on anything, thus it does not influence any other change. It is said to be independent [http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf].

(Could you put an image here figure 2-25 on page 23)

Another example, here package y has no packages depending upon it, thus we call it irresponsible. It is very instable package. But there are three other packages that y depends upon, so changes from these three external packages may affect it and thus we say y is dependent.

(Could you put an image here figure 2-26 on page 23)

Thus we need to be careful while designing packages especially lower level packages (which would have more users) and higher level packages (which would tend to have fewer users).

CSC/ECE 517 Fall 2009/wiki1b 13 zz

2009-11-18T02:32:47Z

Abhatt: /* Stable Dependencies Principle */

Bob Martin's Stable Dependencies Principle says, "The dependencies between packages should be in the direction of the stability of the packages. A package should only depend upon packages that are more stable than it is."

=Bob Martin=

[http://today.java.net/pub/au/90 Robert C. Martin] (Uncle Bob) defines the domain of [http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf design patterns] to be the architecture of systems modules (packages, classes and components) and their interconnections. His design patterns address the four major reasons for failure of the systems: rigidity, fragility, immobility and viscosity [http://www.objectmentor.com/resources/articles/oodmetrc.pdf].

Following are the list of few design principles quoted by him to avoid the pitfalls associated with unsuccessful software engineering,
[http://labs.cs.utt.ro/labs/ip2/html/lectures/5/lecture5.ppt Reuse/Release Equivalence Principle],
[http://iface.wordpress.com/2006/04/08/common-closure-principle/ Common Closure Principle],
[http://www.objectmentor.com/omSolutions/oops_what.html Common Reuse Principle],
[http://ifacethoughts.net/2006/04/10/acyclic-dependencies-principle/ Acyclic Dependencies Principle],
[http://www.objectmentor.com/resources/articles/stability.pdf Staple Dependencies Principle],
[http://ifacethoughts.net/2006/04/20/stable-abstractions-principle/ Stable Abstraction Principle].

The objective of this article is to discuss in detail Stable Dependencies Principle. Each of the four problems discussed above can be caused by improper dependencies between the modules of the software. It is the dependency architecture that degrades the ability of the software to be maintained. The Stable Dependencies Principle is one of the principle which discusses its concern with coupling of packages, or the degree to which they rely on each other.

=Stable Dependencies Principle=
<blockquote>
Principle:
''The dependencies between packages should be in the direction of the stability of the packages. A package should only depend upon packages that are more stable than it is.''
</blockquote>

Essentially, if we want stuff to be changed, we want it to be easy, so we need to ensure our design is such that we keep all the changing stuff in one place and independent. This can be done by measuring the afferent (from outside in) and efferent (from inside out) dependencies of classes in the package.

Packages can be classified as stable(difficult to change) and volatile(easy to change). Stable packages must not depend on Volatile one because

- It makes Volatile packages harder to change

- Or It may force stable packages to be changed often, in other words volatile becomes stable

Thus we have to ensure that volatile packages must depend on stable packages.

Lets consider an example where a Class library L depends on the collection class library C which further depends on special memory allocation library M. For execution speed, API of C is modeled after API of M. Now M(a volatile class here)has a serious bug which needs to be fixed. Thus Class C(a stable class)needs to be updated. How does this affect all the classes here?

- Fixing issues in Class M causes API changes in C which requires changes in the header files of Class C

- As API of M reflects in API of C, L also has to be modified too.

==Stability==
What does stability mean? By simply goggling stability, we get definitions like resistance to change, reliability etc [http://www.answers.com/topic/stability]. Thus it roughly means "hard to change", whereas instability means "easy to change".

Consider an example, in which you stand a penny on its side. Is this penny stable in that position? Mostly people would answer a no, even though it does not change its position for a very long time. Thus, stability has nothing directly to do with the frequency of change. It more relates to the amount of work required to make a change. The penny is not stable because it takes little work to topple it.

Thus stability of a software package would depend on various factors like size, complexity, clarity, etc. But with respect to our principle, stability focus on a different factor. A software package would be difficult to change, if it has lots of other software packages depend on upon it. Thus a package with lots of incoming dependencies is very stable because it requires a great deal of work for any change to propagate with all the dependent packages.

==Stability and Dependencies==
With the above definition of stability, you don't want to increase stability of the packages as your software can not change easily then. But if the system has been designed well then hard to change packages or stable packages will not change that frequently. Thus, we need to understand the relationship between stability and dependencies.

Consider a following example, Here package x, depends on three other packages. Thus, it is said that x is responsible to the other three packages. On other hand, x does not depend on anything, thus it does not influence any other change. It is said to be independent [http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf].

(Could you put an image here figure 2-25 on page 23)

Another example, here package y has no packages depending upon it, thus we call it irresponsible. It is very instable package. But there are three other packages that y depends upon, so changes from these three external packages may affect it and thus we say y is dependent.

(Could you put an image here figure 2-26 on page 23)

Thus we need to be careful while designing packages especially lower level packages (which would have more users) and higher level packages (which would tend to have fewer users).

CSC/ECE 517 Fall 2009/wiki1b 13 zz

2009-11-18T01:00:31Z

Abhatt: /* Stable Dependencies Principle */

Bob Martin's Stable Dependencies Principle says, "The dependencies between packages should be in the direction of the stability of the packages. A package should only depend upon packages that are more stable than it is."

=Bob Martin=

[http://today.java.net/pub/au/90 Robert C. Martin] (Uncle Bob) defines the domain of [http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf design patterns] to be the architecture of systems modules (packages, classes and components) and their interconnections. His design patterns address the four major reasons for failure of the systems: rigidity, fragility, immobility and viscosity [http://www.objectmentor.com/resources/articles/oodmetrc.pdf].

Following are the list of few design principles quoted by him to avoid the pitfalls associated with unsuccessful software engineering,
[http://labs.cs.utt.ro/labs/ip2/html/lectures/5/lecture5.ppt Reuse/Release Equivalence Principle],
[http://iface.wordpress.com/2006/04/08/common-closure-principle/ Common Closure Principle],
[http://www.objectmentor.com/omSolutions/oops_what.html Common Reuse Principle],
[http://ifacethoughts.net/2006/04/10/acyclic-dependencies-principle/ Acyclic Dependencies Principle],
[http://www.objectmentor.com/resources/articles/stability.pdf Staple Dependencies Principle],
[http://ifacethoughts.net/2006/04/20/stable-abstractions-principle/ Stable Abstraction Principle].

The objective of this article is to discuss in detail Stable Dependencies Principle. Each of the four problems discussed above can be caused by improper dependencies between the modules of the software. It is the dependency architecture that degrades the ability of the software to be maintained. The Stable Dependencies Principle is one of the principle which discusses its concern with coupling of packages, or the degree to which they rely on each other.

=Stable Dependencies Principle=
<blockquote>
Principle:
''The dependencies between packages should be in the direction of the stability of the packages. A package should only depend upon packages that are more stable than it is.''
</blockquote>

Essentially, if we want stuff to be changed, we want it to be easy, so we need to ensure our design is such that we keep all the changing stuff in one place and independent. This can be done by measuring the afferent (from outside in) and efferent (from inside out) dependencies of classes in the package.

Packages can be classified as stable(difficult to change) and volatile(easy to change). Stable packages must not depend on Volatile one because
* It makes Volatile packages harder to change
* Or It may force stable packages to be changed often, in other words volatile becomes stable

Thus we have to ensure that volatile packages must depend on stable packages.

[have to exagerate here with respect to basic definition]. To explain the principle in detail, we need to first understand few terms like stability, dependencies etc first.

==Stability==
What does stability mean? By simply goggling stability, we get definitions like resistance to change, reliability etc [http://www.answers.com/topic/stability]. Thus it roughly means "hard to change", whereas instability means "easy to change".

Consider an example, in which you stand a penny on its side. Is this penny stable in that position? Mostly people would answer a no, even though it does not change its position for a very long time. Thus, stability has nothing directly to do with the frequency of change. It more relates to the amount of work required to make a change. The penny is not stable because it takes little work to topple it.

Thus stability of a software package would depend on various factors like size, complexity, clarity, etc. But with respect to our principle, stability focus on a different factor. A software package would be difficult to change, if it has lots of other software packages depend on upon it. Thus a package with lots of incoming dependencies is very stable because it requires a great deal of work for any change to propagate with all the dependent packages.

==Stability and Dependencies==
With the above definition of stability, you don't want to increase stability of the packages as your software can not change easily then. But if the system has been designed well then hard to change packages or stable packages will not change that frequently. Thus, we need to understand the relationship between stability and dependencies.

Consider a following example, Here package x, depends on three other packages. Thus, it is said that x is responsible to the other three packages. On other hand, x does not depend on anything, thus it does not influence any other change. It is said to be independent [http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf].

(Could you put an image here figure 2-25 on page 23)

Another example, here package y has no packages depending upon it, thus we call it irresponsible. It is very instable package. But there are three other packages that y depends upon, so changes from these three external packages may affect it and thus we say y is dependent.

(Could you put an image here figure 2-26 on page 23)

Thus we need to be careful while designing packages especially lower level packages (which would have more users) and higher level packages (which would tend to have fewer users).

CSC/ECE 517 Fall 2009/wiki2 10 Gui Testing Frameworks aa

2009-10-09T19:25:19Z

Abhatt: /* GUI Testing Difficulties */

=='''GUI TESTING FRAMEWORKS'''==

===Introduction===

A [http://en.wikipedia.org/wiki/Graphical_user_interface Graphical User Interface] is a program interface that takes advantage of the computer's graphics capabilities to make the program easier to use. They are the assumed user interface for virtually all systems development using modern technologies.They deliver the system functionality for the clients in the client/server system.Ideally, user interfaces should only be thin shells on top of the next layer in an application displaying information in a useful fashion, and passing user input as quickly as possible to some code that knows what to do with it.However testing systmes with GUIs becomes very difficult because of the event-driven nature of [http://en.wikipedia.org/wiki/Graphical_user_interface GUI], unsolicited events and a never ending input domain.

The article here describes the problems associated with GUI testing and several possible patterns and tools used for [http://en.wikipedia.org/wiki/GUI_software_testing GUI Testing.]
----

===GUI Testing Difficulties===

[http://www.gerrardconsulting.com/GUI/TestGui.html GUI testing] is comparatively difficult because of the following reasons:

#There is an infinite number of events that occur when a user is using the application. This makes it really difficult for a coder to anticipate all contexts and include event handlers for all of them.Also the number of potential paths from feature to feature within the application is so high that the scope for programmers to make errors is dramatically increased. The ‘infinite paths’ problem also makes it extremely unlikely that they will all be tested.
#Unsolicited events like a LAN printer going offline and an operating system popping up a dialog box asking the user to feed more paper can occur any time.Here not only is the number of test cases high but also special test drivers may be necessary to generate such events within the operating systems.
#A major problem involved with GUI testing is a large number of input spaces wherein user can click on any point on the screen at any time and there may be an undefined number of applications running simultaneously. This means that the application code needs to check the next event irrespective of whether it’s meant for it. This event driven approach makes testing an extremely complicated issue.
#GUIs are better suited to object oriented paradigm. A large number of methods and attributes are associated with each object that deals with GUI events thus making it even more complex. For example even for a simple text box there may be around thirty attributes which means a larger set of test cases to deal with.
#GUI environment deals with windows and user take the standard features of window management (re-size, move, maximize and minimize) for granted. These events do affect the application and thus need to be taken care of. For instance testing backward, forward, refresh etc makes testing a challenging task.
#GUI tests can’t be written until you finish the implementation phase. This is an issue considering the fact that there may be contractors developing the GUI who may not be available for testing thus forcing the tester to reverse engineer making life miserable for him.
#GUIs involve complex dependencies thereby resulting in a synchronization problem. For example if an application involves two windows one showing a portfolio of your stock market investments and the other making transactions then as soon as you buy a stock the user would like to see it in the portfolio, now for that to happen you need the two windows to be synchronized. With a large number of windows involved with the application the dependencies are extremely complex. Now a user may also want his transaction history window, the order book window etc be synchronized too with the transaction window. This shows the problem of a large number of dependencies which makes synchronization complicated.
#There can be many ways a user can reach a point in the application which may be a keyboard shortcut, function keys or mouse movements creating a never ending list of test cases.
#An infinite input domain problem is an issue wherein a user has an option of clicking anywhere on the window in view and entering data in any order he wishes too. This may result in a n factorial ways of inputting data where n is the number of fields in the GUI application. Greater the n larger the input domain and more the complexity for a tester.

===GUI Test Principles===

To develop a test process which is applicable for GUI testing in general we need to follow a set of principles. These principles deal with errors involved with GUI and using the GUI to exercise tests so is very-oriented toward black-box testing.

• The errors can be broken down into types, and we can design tests to diagnose each type of error. So, we can channelize the efforts in the direction of testing.

• A divide and conquer approach helps to separate out concerns. A complex problem is broken down into a large number of simple ones thereby concentrating on designing test cases for specific types of error.

• Automating GUI tests is complicated as seen before. Thus we need to ensure that we include this feature only when needed in stead of using it in general for everything.

• Layering as for everything helps separate complexity. Similarly layering of tests can be an effective solution as we implement the tests of individual components(low level tests) first and then test the integrated application at the end.

• We can use traditional techniques that are used for form based applications called black box test techniques wherever appropriate.

----

===Different Approaches used for GUI Testing===

The different approaches used for [http://en.wikipedia.org/wiki/GUI_software_testing GUI testing] are as follows:

==== Capture and Replay Tool ====

In this approach, as the name suggests,in [http://www.site.uottawa.ca/~awilliam/seg3203/Capture.ppt Capture & Replay] the user starts testing the web applications manually thereby invoking the events and the test software starts recording all the actions. These actions identify the respective GUI widgets and are collected in the form of events. The recording forms the basis of automating the test for web applications which are replayed via the GUI.

[[Image:Record.jpg|650px|thumb|center|figure 1: testing web applications with Capture & Replay – workflow.]]

'''Drawbacks'''

*As mentioned in the problems before, this can be tested only after the development has finished.
*A layout may change over the time and hence the test cases may become invalid owing to the changes in the physical interface.
*It lacks the necessary support to design the test cases and coverage criteria evaluation.

----

====MVC Design Pattern====

It is typically more difficult to perform automated tests on code residing in the user interface, and the more logic contained there, the greater the need for automated testing. The solution is the [http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller Model View Controller pattern.] The basic idea behind this approach is to add a new level of indirection behind the user interface and the domain model with the intention of isolating UI changes and prevent them from requiring changes to the domain logic of the application.
MVC divides an application into three concerns:
*Model - Encapsulates core application data and functionality domain logic.
*View - obtains data from the model and presents it to the user.
*Controller - receives and translates input to requests on the model or the view.
It pulls the complex part of the user interface code into a library that can be unit-tested, thus making GUI testing simpler.

----

====Test Stubs and Drivers====
A [http://en.wikipedia.org/wiki/Test_stubs test stub] is a dummy software component or object used (during development and testing) to simulate the behavior of a real component. More specifically while intergrating all the modules in top to bottom approach whenever any mandatory module is missing that module is replaced by a temperoary program which is called as [http://en.wikipedia.org/wiki/Test_stubs stub.]
<pre> If the function A you are testing, calls another function B,then use a simplified version of function B, called a stub.
void function_under_test(int& x, int& y) {
...
p = price(x);
...
}
double price(int x) {return 10.00;}
The value returned by function price is good enough for testing.The real price() function may not yet have been tested, or even
written.</pre>

Similarly, while integrating all the modules in bottom to top approach whenever any mandatory module is missing that module is replaced by a temperoary program which is called as [http://wiki.answers.com/Q/What_is_the_difference_between_stub_and_driver test driver.]

<pre>//Driver program for the function get_input.
#include <iostream.h>
void get_input(x& cost, int& y);
//Precondition: User is ready to enters values correctly.Postconditions: The value of cost has been set to the.
//wholesale cost of one item. The value of turnover has been set to the expected number of days until the item is sold.
int main( )
{ double a;
int b;
char ans;
do {
get_input(a, b);
cout.setf(ios::fixed);
cout.setf(ios::showpoint);
cout.precision(2);
cout << "a is " << a << endl;
cout << "b is " << b << endl;
cout << "Test again?"
<< " (Type y for yes or n for no): ";
cin >> ans;
cout << endl;
} while (ans == 'y' || ans == 'Y');
return 0;
}</pre>

----

====Capture and Replay Tool====

----

====Guitar GUI Testing Framework====

[http://guitar.sourceforge.net/ GUITAR] is an extensible framework for testing software applications. It presents a unified solution to the software testing problem. [http://guitar.sourceforge.net/ GUITAR’s] architecture allows testers to create new “process plug-ins” (i.e., tools/techniques/algorithms) to perform different testing activities. It currently contains a rich collection of plug-ins that may be used to test an application through its graphical user interface. For example, the “test case generator” plug-in, a tester can automatically generate various types of test cases for the Application Under Test (AUT); the “replayer” plug-in may be used to execute these test cases on the AUT automatically; during the various development phases of the AUT, the “regression tester” plug-in can be used to efficiently perform regression testing on the AUT.

[[Image:Guitar.jpg|650px|thumb|center|Overview of the [http://guitar.sourceforge.net/ GUITAR Guitar Framework].]]

----

====Cucumber====

[http://wiki.github.com/aslakhellesoy/cucumber Cucumber] is a tool that can execute plain-text functional descriptions as automated tests. The language that [http://wiki.github.com/aslakhellesoy/cucumber Cucumber] understands is called [http://wiki.github.com/aslakhellesoy/cucumber/gherkin Gherkin.] Here is an example:

<pre>Feature: Search courses
In order to ensure better utilization of courses
Potential students should be able to search for courses

Scenario: Search by topic
Given there are 240 courses which do not have the topic "biology"
And there are 2 courses A001, B205 that each have "biology" as one of the topics
When I search for "biology"
Then I should see the following courses:
| Course code |
| A001 |
| B205 |</pre>
While [http://wiki.github.com/aslakhellesoy/cucumber Cucumber] can be thought of as a “testing” tool, the intent of the tool is to support [http://behaviour-driven.org/ BDD.] This means that the “tests” (plain text feature descriptions with scenarios) are typically written before anything else and verified by business analysts, domain experts, etc. non technical stakeholders. The production code is then written outside-in, to make the stories pass.

----

===Conclusion===

----

===References===

----

CSC/ECE 517 Fall 2009/wiki2 10 Gui Testing Frameworks aa

2009-10-09T19:09:15Z

Abhatt: /* GUI Test Principles */

=='''GUI TESTING FRAMEWORKS'''==

===Introduction===

A [http://en.wikipedia.org/wiki/Graphical_user_interface Graphical User Interface] is a program interface that takes advantage of the computer's graphics capabilities to make the program easier to use. They are the assumed user interface for virtually all systems development using modern technologies.They deliver the system functionality for the clients in the client/server system.Ideally, user interfaces should only be thin shells on top of the next layer in an application displaying information in a useful fashion, and passing user input as quickly as possible to some code that knows what to do with it.However testing systmes with GUIs becomes very difficult because of the event-driven nature of [http://en.wikipedia.org/wiki/Graphical_user_interface GUI], unsolicited events and a never ending input domain.

The article here describes the problems associated with GUI testing and several possible patterns and tools used for [http://en.wikipedia.org/wiki/GUI_software_testing GUI Testing.]
----

===GUI Testing Difficulties===

GUI testing is comparatively difficult because of the following reasons:

#There is an infinite number of events that occur when a user is using the application. This makes it really difficult for a coder to anticipate all contexts and include event handlers for all of them.Also the number of potential paths from feature to feature within the application is so high that the scope for programmers to make errors is dramatically increased. The ‘infinite paths’ problem also makes it extremely unlikely that they will all be tested.
#Unsolicited events like a LAN printer going offline and an operating system popping up a dialog box asking the user to feed more paper can occur any time.Here not only is the number of test cases high but also special test drivers may be necessary to generate such events within the operating systems.
#A major problem involved with GUI testing is a large number of input spaces wherein user can click on any point on the screen at any time and there may be an undefined number of applications running simultaneously. This means that the application code needs to check the next event irrespective of whether it’s meant for it. This event driven approach makes testing an extremely complicated issue.
#GUIs are better suited to object oriented paradigm. A large number of methods and attributes are associated with each object that deals with GUI events thus making it even more complex. For example even for a simple text box there may be around thirty attributes which means a larger set of test cases to deal with.
#GUI environment deals with windows and user take the standard features of window management (re-size, move, maximize and minimize) for granted. These events do affect the application and thus need to be taken care of. For instance testing backward, forward, refresh etc makes testing a challenging task.
#GUI tests can’t be written until you finish the implementation phase. This is an issue considering the fact that there may be contractors developing the GUI who may not be available for testing thus forcing the tester to reverse engineer making life miserable for him.
#GUIs involve complex dependencies thereby resulting in a synchronization problem. For example if an application involves two windows one showing a portfolio of your stock market investments and the other making transactions then as soon as you buy a stock the user would like to see it in the portfolio, now for that to happen you need the two windows to be synchronized. With a large number of windows involved with the application the dependencies are extremely complex. Now a user may also want his transaction history window, the order book window etc be synchronized too with the transaction window. This shows the problem of a large number of dependencies which makes synchronization complicated.
#There can be many ways a user can reach a point in the application which may be a keyboard shortcut, function keys or mouse movements creating a never ending list of test cases.
#An infinite input domain problem is an issue wherein a user has an option of clicking anywhere on the window in view and entering data in any order he wishes too. This may result in a n factorial ways of inputting data where n is the number of fields in the GUI application. Greater the n larger the input domain and more the complexity for a tester.

===GUI Test Principles===

To develop a test process which is applicable for GUI testing in general we need to follow a set of principles. These principles deal with errors involved with GUI and using the GUI to exercise tests so is very-oriented toward black-box testing.

• The errors can be broken down into types, and we can design tests to diagnose each type of error. So, we can channelize the efforts in the direction of testing.

• A divide and conquer approach helps to separate out concerns. A complex problem is broken down into a large number of simple ones thereby concentrating on designing test cases for specific types of error.

• Automating GUI tests is complicated as seen before. Thus we need to ensure that we include this feature only when needed in stead of using it in general for everything.

• Layering as for everything helps separate complexity. Similarly layering of tests can be an effective solution as we implement the tests of individual components(low level tests) first and then test the integrated application at the end.

• We can use traditional techniques that are used for form based applications called black box test techniques wherever appropriate.

----

===Different Approaches used for GUI Testing===

The different approaches used for [http://en.wikipedia.org/wiki/GUI_software_testing GUI testing] are as follows:

==== Capture and Replay Tool ====

In this approach, as the name suggests, the user starts testing the web applications manually thereby invoking the events and the test software starts recording all the actions. These actions identify the respective GUI widgets and are collected in the form of events. The recording forms the basis of automating the test for web applications which are replayed via the GUI.

[[Image:Record.jpg|650px|thumb|center|figure 1: testing web applications with Capture & Replay – workflow.]]

'''Drawbacks'''

*As mentioned in the problems before, this can be tested only after the development has finished.
*A layout may change over the time and hence the test cases may become invalid owing to the changes in the physical interface.
*It lacks the necessary support to design the test cases and coverage criteria evaluation.

====MVC Design Pattern====

It is typically more difficult to perform automated tests on code residing in the user interface, and the more logic contained there, the greater the need for automated testing. The solution is the [http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller Model View Controller pattern.] The basic idea behind this approach is to add a new level of indirection behind the user interface and the domain model with the intention of isolating UI changes and prevent them from requiring changes to the domain logic of the application.
MVC divides an application into three concerns:
*Model - Encapsulates core application data and functionality domain logic.
*View - obtains data from the model and presents it to the user.
*Controller - receives and translates input to requests on the model or the view.
It pulls the complex part of the user interface code into a library that can be unit-tested, thus making GUI testing simpler.

----

====Test Stubs and Drivers====
A [http://en.wikipedia.org/wiki/Test_stubs test stub] is a dummy software component or object used (during development and testing) to simulate the behavior of a real component. More specifically while intergrating all the modules in top to bottom approach whenever any mandatory module is missing that module is replaced by a temperoary program which is called as [http://en.wikipedia.org/wiki/Test_stubs stub.]
<pre> If the function A you are testing, calls another function B,then use a simplified version of function B, called a stub.
void function_under_test(int& x, int& y) {
...
p = price(x);
...
}
double price(int x) {return 10.00;}
The value returned by function price is good enough for testing.The real price() function may not yet have been tested, or even
written.</pre>

Similarly, while integrating all the modules in bottom to top approach whenever any mandatory module is missing that module is replaced by a temperoary program which is called as [http://wiki.answers.com/Q/What_is_the_difference_between_stub_and_driver test driver.]

<pre>//Driver program for the function get_input.
#include <iostream.h>
void get_input(x& cost, int& y);
//Precondition: User is ready to enters values correctly.Postconditions: The value of cost has been set to the.
//wholesale cost of one item. The value of turnover has been set to the expected number of days until the item is sold.
int main( )
{ double a;
int b;
char ans;
do {
get_input(a, b);
cout.setf(ios::fixed);
cout.setf(ios::showpoint);
cout.precision(2);
cout << "a is " << a << endl;
cout << "b is " << b << endl;
cout << "Test again?"
<< " (Type y for yes or n for no): ";
cin >> ans;
cout << endl;
} while (ans == 'y' || ans == 'Y');
return 0;
}</pre>

----

====Capture and Replay Tool====

----

====Guitar GUI Testing Framework====

[http://guitar.sourceforge.net/ GUITAR] is an extensible framework for testing software applications. It presents a unified solution to the software testing problem. [http://guitar.sourceforge.net/ GUITAR’s] architecture allows testers to create new “process plug-ins” (i.e., tools/techniques/algorithms) to perform different testing activities. It currently contains a rich collection of plug-ins that may be used to test an application through its graphical user interface. For example, the “test case generator” plug-in, a tester can automatically generate various types of test cases for the Application Under Test (AUT); the “replayer” plug-in may be used to execute these test cases on the AUT automatically; during the various development phases of the AUT, the “regression tester” plug-in can be used to efficiently perform regression testing on the AUT.

[[Image:Guitar.jpg|650px|thumb|center|Overview of the [http://guitar.sourceforge.net/ GUITAR Guitar Framework].]]

----

====Cucumber====

[http://wiki.github.com/aslakhellesoy/cucumber Cucumber] is a tool that can execute plain-text functional descriptions as automated tests. The language that [http://wiki.github.com/aslakhellesoy/cucumber Cucumber] understands is called [http://wiki.github.com/aslakhellesoy/cucumber/gherkin Gherkin.] Here is an example:

<pre>Feature: Search courses
In order to ensure better utilization of courses
Potential students should be able to search for courses

Scenario: Search by topic
Given there are 240 courses which do not have the topic "biology"
And there are 2 courses A001, B205 that each have "biology" as one of the topics
When I search for "biology"
Then I should see the following courses:
| Course code |
| A001 |
| B205 |</pre>
While [http://wiki.github.com/aslakhellesoy/cucumber Cucumber] can be thought of as a “testing” tool, the intent of the tool is to support [http://behaviour-driven.org/ BDD.] This means that the “tests” (plain text feature descriptions with scenarios) are typically written before anything else and verified by business analysts, domain experts, etc. non technical stakeholders. The production code is then written outside-in, to make the stories pass.

----

===Conclusion===

----

===References===

----

CSC/ECE 517 Fall 2009/wiki2 10 Gui Testing Frameworks aa

2009-10-09T19:08:58Z

Abhatt: /* GUI Testing Difficulties */

=='''GUI TESTING FRAMEWORKS'''==

===Introduction===

A [http://en.wikipedia.org/wiki/Graphical_user_interface Graphical User Interface] is a program interface that takes advantage of the computer's graphics capabilities to make the program easier to use. They are the assumed user interface for virtually all systems development using modern technologies.They deliver the system functionality for the clients in the client/server system.Ideally, user interfaces should only be thin shells on top of the next layer in an application displaying information in a useful fashion, and passing user input as quickly as possible to some code that knows what to do with it.However testing systmes with GUIs becomes very difficult because of the event-driven nature of [http://en.wikipedia.org/wiki/Graphical_user_interface GUI], unsolicited events and a never ending input domain.

The article here describes the problems associated with GUI testing and several possible patterns and tools used for [http://en.wikipedia.org/wiki/GUI_software_testing GUI Testing.]
----

===GUI Testing Difficulties===

GUI testing is comparatively difficult because of the following reasons:

#There is an infinite number of events that occur when a user is using the application. This makes it really difficult for a coder to anticipate all contexts and include event handlers for all of them.Also the number of potential paths from feature to feature within the application is so high that the scope for programmers to make errors is dramatically increased. The ‘infinite paths’ problem also makes it extremely unlikely that they will all be tested.
#Unsolicited events like a LAN printer going offline and an operating system popping up a dialog box asking the user to feed more paper can occur any time.Here not only is the number of test cases high but also special test drivers may be necessary to generate such events within the operating systems.
#A major problem involved with GUI testing is a large number of input spaces wherein user can click on any point on the screen at any time and there may be an undefined number of applications running simultaneously. This means that the application code needs to check the next event irrespective of whether it’s meant for it. This event driven approach makes testing an extremely complicated issue.
#GUIs are better suited to object oriented paradigm. A large number of methods and attributes are associated with each object that deals with GUI events thus making it even more complex. For example even for a simple text box there may be around thirty attributes which means a larger set of test cases to deal with.
#GUI environment deals with windows and user take the standard features of window management (re-size, move, maximize and minimize) for granted. These events do affect the application and thus need to be taken care of. For instance testing backward, forward, refresh etc makes testing a challenging task.
#GUI tests can’t be written until you finish the implementation phase. This is an issue considering the fact that there may be contractors developing the GUI who may not be available for testing thus forcing the tester to reverse engineer making life miserable for him.
#GUIs involve complex dependencies thereby resulting in a synchronization problem. For example if an application involves two windows one showing a portfolio of your stock market investments and the other making transactions then as soon as you buy a stock the user would like to see it in the portfolio, now for that to happen you need the two windows to be synchronized. With a large number of windows involved with the application the dependencies are extremely complex. Now a user may also want his transaction history window, the order book window etc be synchronized too with the transaction window. This shows the problem of a large number of dependencies which makes synchronization complicated.
#There can be many ways a user can reach a point in the application which may be a keyboard shortcut, function keys or mouse movements creating a never ending list of test cases.
#An infinite input domain problem is an issue wherein a user has an option of clicking anywhere on the window in view and entering data in any order he wishes too. This may result in a n factorial ways of inputting data where n is the number of fields in the GUI application. Greater the n larger the input domain and more the complexity for a tester.

===GUI Test Principles===

To develop a test process which is applicable for GUI testing in general we need to follow a set of principles. These principles deal with errors involved with GUI and using the GUI to exercise tests so is very-oriented toward black-box testing.

• The errors csn be broken down into types, and we can design tests to diagnose each type of error. So, we can channelize the efforts in the direction of testing.

• A divide and conquer approach helps to separate out concerns. A complex problem is broken down into a large number of simple ones thereby concentrating on designing test cases for specific types of error.

• Automating GUI tests is complicated as seen before. Thus we need to ensure that we include this feature only when needed in stead of using it in general for everything.

• Layering as for everything helps separate complexity. Similarly layering of tests can be an effective solution as we implement the tests of individual components(low level tests) first and then test the integrated application at the end.

• We can use traditional techniques that are used for form based applications called black box test techniques wherever appropriate.

----

===Different Approaches used for GUI Testing===

The different approaches used for [http://en.wikipedia.org/wiki/GUI_software_testing GUI testing] are as follows:

==== Capture and Replay Tool ====

In this approach, as the name suggests, the user starts testing the web applications manually thereby invoking the events and the test software starts recording all the actions. These actions identify the respective GUI widgets and are collected in the form of events. The recording forms the basis of automating the test for web applications which are replayed via the GUI.

[[Image:Record.jpg|650px|thumb|center|figure 1: testing web applications with Capture & Replay – workflow.]]

'''Drawbacks'''

*As mentioned in the problems before, this can be tested only after the development has finished.
*A layout may change over the time and hence the test cases may become invalid owing to the changes in the physical interface.
*It lacks the necessary support to design the test cases and coverage criteria evaluation.

====MVC Design Pattern====

It is typically more difficult to perform automated tests on code residing in the user interface, and the more logic contained there, the greater the need for automated testing. The solution is the [http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller Model View Controller pattern.] The basic idea behind this approach is to add a new level of indirection behind the user interface and the domain model with the intention of isolating UI changes and prevent them from requiring changes to the domain logic of the application.
MVC divides an application into three concerns:
*Model - Encapsulates core application data and functionality domain logic.
*View - obtains data from the model and presents it to the user.
*Controller - receives and translates input to requests on the model or the view.
It pulls the complex part of the user interface code into a library that can be unit-tested, thus making GUI testing simpler.

----

====Test Stubs and Drivers====
A [http://en.wikipedia.org/wiki/Test_stubs test stub] is a dummy software component or object used (during development and testing) to simulate the behavior of a real component. More specifically while intergrating all the modules in top to bottom approach whenever any mandatory module is missing that module is replaced by a temperoary program which is called as [http://en.wikipedia.org/wiki/Test_stubs stub.]
<pre> If the function A you are testing, calls another function B,then use a simplified version of function B, called a stub.
void function_under_test(int& x, int& y) {
...
p = price(x);
...
}
double price(int x) {return 10.00;}
The value returned by function price is good enough for testing.The real price() function may not yet have been tested, or even
written.</pre>

Similarly, while integrating all the modules in bottom to top approach whenever any mandatory module is missing that module is replaced by a temperoary program which is called as [http://wiki.answers.com/Q/What_is_the_difference_between_stub_and_driver test driver.]

<pre>//Driver program for the function get_input.
#include <iostream.h>
void get_input(x& cost, int& y);
//Precondition: User is ready to enters values correctly.Postconditions: The value of cost has been set to the.
//wholesale cost of one item. The value of turnover has been set to the expected number of days until the item is sold.
int main( )
{ double a;
int b;
char ans;
do {
get_input(a, b);
cout.setf(ios::fixed);
cout.setf(ios::showpoint);
cout.precision(2);
cout << "a is " << a << endl;
cout << "b is " << b << endl;
cout << "Test again?"
<< " (Type y for yes or n for no): ";
cin >> ans;
cout << endl;
} while (ans == 'y' || ans == 'Y');
return 0;
}</pre>

----

====Capture and Replay Tool====

----

====Guitar GUI Testing Framework====

[http://guitar.sourceforge.net/ GUITAR] is an extensible framework for testing software applications. It presents a unified solution to the software testing problem. [http://guitar.sourceforge.net/ GUITAR’s] architecture allows testers to create new “process plug-ins” (i.e., tools/techniques/algorithms) to perform different testing activities. It currently contains a rich collection of plug-ins that may be used to test an application through its graphical user interface. For example, the “test case generator” plug-in, a tester can automatically generate various types of test cases for the Application Under Test (AUT); the “replayer” plug-in may be used to execute these test cases on the AUT automatically; during the various development phases of the AUT, the “regression tester” plug-in can be used to efficiently perform regression testing on the AUT.

[[Image:Guitar.jpg|650px|thumb|center|Overview of the [http://guitar.sourceforge.net/ GUITAR Guitar Framework].]]

----

====Cucumber====

[http://wiki.github.com/aslakhellesoy/cucumber Cucumber] is a tool that can execute plain-text functional descriptions as automated tests. The language that [http://wiki.github.com/aslakhellesoy/cucumber Cucumber] understands is called [http://wiki.github.com/aslakhellesoy/cucumber/gherkin Gherkin.] Here is an example:

<pre>Feature: Search courses
In order to ensure better utilization of courses
Potential students should be able to search for courses

Scenario: Search by topic
Given there are 240 courses which do not have the topic "biology"
And there are 2 courses A001, B205 that each have "biology" as one of the topics
When I search for "biology"
Then I should see the following courses:
| Course code |
| A001 |
| B205 |</pre>
While [http://wiki.github.com/aslakhellesoy/cucumber Cucumber] can be thought of as a “testing” tool, the intent of the tool is to support [http://behaviour-driven.org/ BDD.] This means that the “tests” (plain text feature descriptions with scenarios) are typically written before anything else and verified by business analysts, domain experts, etc. non technical stakeholders. The production code is then written outside-in, to make the stories pass.

----

===Conclusion===

----

===References===

----

CSC/ECE 517 Fall 2009/wiki2 10 Gui Testing Frameworks aa

2009-10-09T18:18:45Z

Abhatt: /* Different Approaches used for GUI Testing */

=='''GUI TESTING FRAMEWORKS'''==

===Introduction===

A Graphical User Interface is a program interface that takes advantage of the computer's graphics capabilities to make the program easier to use.Ideally, user interfaces should only be thin shells on top of the next layer in an application displaying information in a useful fashion, and passing user input as quickly as possible to some code that knows what to do with it.However due to its nature there are many difficulties that arise with GUI testing.

GUIs are the assumed user interface for virtually all systems development using modern technologies. Graphical User Interface deliver the system functionality for the clients in the client/server system. Testing systems become more complex with GUI because of the event-driven nature of GUI, unsolicited events and a never ending input domain. Thus there aren’t any developed or implemented testing patterns for GUI testing.

The article here describes the problems associated with GUI testing and several possible patterns and tools used for GUI Testing.
----

===GUI Testing Difficulties===

As GUI hides the complexity from the user and from the programmers too on using development frameworks but the hidden issues become really obvious when it comes to testing. GUI testing is much more difficult comparatively because

1. There is an infinite number of unnoticed events that occur when a user is using the application making. This makes it really difficult for a code to include all of them and to complicate the issue further special test drivers are needed in the Operating system to generate such events. For instance when a printer in a LAN is switched off, and the operating system puts up a dialog box inviting the user to feed more paper into the printer.

2. A major problem involved with GUI testing is a large number of input spaces wherein user can click on any point on the screen at any time and there may be an undefined number of applications running simultaneously. This means that the application code needs to check the next event irrespective of whether it’s meant for it. This event driven approach makes testing an extremely complicated issue.

3. GUIs are better suited to object oriented paradigm. A large number of methods and attributes are associated with each object that deals with GUI events thus making it even more complex. For example even for a simple text box there may be around thirty attributes which means a larger set of test cases to deal with.

4. GUI environment deals with windows and user take the standard features of window management (re-size, move, maximize and minimize) for granted. These events do affect the application and thus needs to be taken care of. For instance testing backward, forward, refresh etc makes testing a challenging task.

5. GUI tests can’t be written until you finish the implementation phase. This is an issue considering the fact that there may be contractors developing the GUI who may not be available for testing thus forcing the tester to reverse engineer making life miserable for him.

6. GUIs involve complex dependencies thereby resulting in a synchronization problem. For example if an application involves two windows one showing a portfolio of your stock market investments and the other making transactions then as soon as you buy a stock the user would like to see it in the portfolio, now for that to happen you need the two windows to be synchronized. With a large number of windows involved with the application the dependencies are extremely complex. Now a user may also want his transaction history window, the order book window etc be synchronized too with the transaction window. This shows the problem of a large number of dependencies which makes synchronization complicated.

7. There can be many ways a user can reach a point in the application which may be a keyboard shortcut, function keys or mouse movements creating a never ending list of test cases

8. An infinite input domain problem is an issue wherein a user has an option of clicking anywhere on the window in view and entering data in any order he wishes too. This may result in a n factorial ways of inputting data where n is the number of fields in the GUI application. Greater the n larger the input domain and more the complexity for a tester.

----

===Different Approaches used for GUI Testing===

The different approaches used for GUI testing are as follows

==== Capture and Replay Tool ====

In this approach, as the name suggests, the user starts testing the web applications manually thereby invoking the events and the test software starts recording all the actions. These actions identify the respective GUI widgets and are collected in the form of events. The recording forms the basis of automating the test for web applications which are replayed via the GUI.

A simple workflow explaining the test approach is shown below

PLZ INSERT IMAGE

figure 1 testing web applications with Capture & Replay – workflow

'''Drawbacks'''

• As mentioned in the problems before, this can be tested only after the development has finished.

• A layout may change over the time and hence the test cases may become invalid owing to the changes in the physical interface.

• It lacks the necessary support to design the test cases and coverage criteria evaluation.

====MVC Design Pattern====

It is typically more difficult to perform automated tests on code residing in the user interface, and the more logic contained there, the greater the need for automated testing. The solution is the Model View Controller pattern. The basic idea behind this approach is to add a new level of indirection behind the user interface and the domain model with the intention of isolating UI changes and prevent them from requiring changes to the domain logic of the application.
MVC divides an application into three concerns:
*Model - Encapsulates core application data and functionality domain logic.
*View - obtains data from the model and presents it to the user.
*Controller - receives and translates input to requests on the model or the view.
It pulls the complex part of the user interface code into a library that can be unit-tested, thus making GUI testing simpler.

----

====Test Stubs and Drivers====
A [http://en.wikipedia.org/wiki/Test_stubs test stub] is a dummy software component or object used (during development and testing) to simulate the behavior of a real component. More specifically while intergrating all the modules in top to bottom approach whenever any mandatory module is missing that module is replaced by a temperoary program which is called as [http://en.wikipedia.org/wiki/Test_stubs stub.]
<pre> If the function A you are testing, calls another function B,then use a simplified version of function B, called a stub.
void function_under_test(int& x, int& y) {
...
p = price(x);
...
}
double price(int x) {return 10.00;}
The value returned by function price is good enough for testing.The real price() function may not yet have been tested, or even
written.</pre>

Similarly, while integrating all the modules in bottom to top approach whenever any mandatory module is missing that module is replaced by a temperoary program which is called as driver.

<pre>//Driver program for the function get_input.
#include <iostream.h>
void get_input(x& cost, int& y);
//Precondition: User is ready to enters values correctly.Postconditions: The value of cost has been set to the.
//wholesale cost of one item. The value of turnover has been set to the expected number of days until the item is sold.
int main( )
{ double a;
int b;
char ans;
do {
get_input(a, b);
cout.setf(ios::fixed);
cout.setf(ios::showpoint);
cout.precision(2);
cout << "a is " << a << endl;
cout << "b is " << b << endl;
cout << "Test again?"
<< " (Type y for yes or n for no): ";
cin >> ans;
cout << endl;
} while (ans == 'y' || ans == 'Y');
return 0;
}</pre>

----

====Capture and Replay Tool====

----

====Guitar GUI Testing Framework====

[http://guitar.sourceforge.net/ GUITAR] is an extensible framework for testing software applications. It presents a unified solution to the software testing problem. [http://guitar.sourceforge.net/ GUITAR’s] architecture allows testers to create new “process plug-ins” (i.e., tools/techniques/algorithms) to perform different testing activities. It currently contains a rich collection of plug-ins that may be used to test an application through its graphical user interface. For example, the “test case generator” plug-in, a tester can automatically generate various types of test cases for the Application Under Test (AUT); the “replayer” plug-in may be used to execute these test cases on the AUT automatically; during the various development phases of the AUT, the “regression tester” plug-in can be used to efficiently perform regression testing on the AUT.

[[Image:Guitar.jpg|650px|thumb|center|Overview of the [http://guitar.sourceforge.net/ GUITAR Guitar Framework].]]

----

====Cucumber====

[http://wiki.github.com/aslakhellesoy/cucumber Cucumber] is a tool that can execute plain-text functional descriptions as automated tests. The language that [http://wiki.github.com/aslakhellesoy/cucumber Cucumber] understands is called [http://wiki.github.com/aslakhellesoy/cucumber/gherkin Gherkin.] Here is an example:

<pre>Feature: Search courses
In order to ensure better utilization of courses
Potential students should be able to search for courses

Scenario: Search by topic
Given there are 240 courses which do not have the topic "biology"
And there are 2 courses A001, B205 that each have "biology" as one of the topics
When I search for "biology"
Then I should see the following courses:
| Course code |
| A001 |
| B205 |</pre>
While [http://wiki.github.com/aslakhellesoy/cucumber Cucumber] can be thought of as a “testing” tool, the intent of the tool is to support [http://behaviour-driven.org/ BDD.] This means that the “tests” (plain text feature descriptions with scenarios) are typically written before anything else and verified by business analysts, domain experts, etc. non technical stakeholders. The production code is then written outside-in, to make the stories pass.

----

===Conclusion===

----

===References===

----

CSC/ECE 517 Fall 2009/wiki2 10 Gui Testing Frameworks aa

2009-10-09T16:41:31Z

Abhatt: /* Introduction */

=='''GUI TESTING FRAMEWORKS'''==

===Introduction===

A Graphical User Interface is a program interface that takes advantage of the computer's graphics capabilities to make the program easier to use.Ideally, user interfaces should only be thin shells on top of the next layer in an application displaying information in a useful fashion, and passing user input as quickly as possible to some code that knows what to do with it.However due to its nature there are many difficulties that arise with GUI testing.

GUIs are the assumed user interface for virtually all systems development using modern technologies. Graphical User Interface deliver the system functionality for the clients in the client/server system. Testing systems become more complex with GUI because of the event-driven nature of GUI, unsolicited events and a never ending input domain. Thus there aren’t any developed or implemented testing patterns for GUI testing.

The article here describes the problems associated with GUI testing and several possible patterns and tools for the testing inputs

----

===GUI Testing Difficulties===

As GUI hides the complexity from the user and from the programmers too on using development frameworks but the hidden issues become really obvious when it comes to testing. GUI testing is much more difficult comparatively because

1. There is an infinite number of unnoticed events that occur when a user is using the application making. This makes it really difficult for a code to include all of them and to complicate the issue further special test drivers are needed in the Operating system to generate such events. For instance when a printer in a LAN is switched off, and the operating system puts up a dialog box inviting the user to feed more paper into the printer.

2. A major problem involved with GUI testing is a large number of input spaces wherein user can click on any point on the screen at any time and there may be an undefined number of applications running simultaneously. This means that the application code needs to check the next event irrespective of whether it’s meant for it. This event driven approach makes testing an extremely complicated issue.

3. GUIs are better suited to object oriented paradigm. A large number of methods and attributes are associated with each object that deals with GUI events thus making it even more complex. For example even for a simple text box there may be around thirty attributes which means a larger set of test cases to deal with.

4. GUI environment deals with windows and user take the standard features of window management (re-size, move, maximize and minimize) for granted. These events do affect the application and thus needs to be taken care of. For instance testing backward, forward, refresh etc makes testing a challenging task.

5. GUI tests can’t be written until you finish the implementation phase. This is an issue considering the fact that there may be contractors developing the GUI who may not be available for testing thus forcing the tester to reverse engineer making life miserable for him.

6. GUIs involve complex dependencies thereby resulting in a synchronization problem. For example if an application involves two windows one showing a portfolio of your stock market investments and the other making transactions then as soon as you buy a stock the user would like to see it in the portfolio, now for that to happen you need the two windows to be synchronized. With a large number of windows involved with the application the dependencies are extremely complex. Now a user may also want his transaction history window, the order book window etc be synchronized too with the transaction window. This shows the problem of a large number of dependencies which makes synchronization complicated.

7. There can be many ways a user can reach a point in the application which may be a keyboard shortcut, function keys or mouse movements creating a never ending list of test cases

8. An infinite input domain problem is an issue wherein a user has an option of clicking anywhere on the window in view and entering data in any order he wishes too. This may result in a n factorial ways of inputting data where n is the number of fields in the GUI application. Greater the n larger the input domain and more the complexity for a tester.

----

===Different Approaches used for GUI Testing===

====MVC Design Pattern====

It is typically more difficult to perform automated tests on code residing in the user interface, and the more logic contained there, the greater the need for automated testing. The solution is the Model View Controller pattern. The basic idea behind this approach is to add a new level of indirection behind the user interface and the domain model with the intention of isolating UI changes and prevent them from requiring changes to the domain logic of the application.
MVC divides an application into three concerns:
*Model - Encapsulates core application data and functionality domain logic.
*View - obtains data from the model and presents it to the user.
*Controller - receives and translates input to requests on the model or the view.
It pulls the complex part of the user interface code into a library that can be unit-tested, thus making GUI testing simpler.

----

====Test Stubs====

----

====Capture and Replay Tool====

----

====Guitar GUI Testing Framework====

[http://guitar.sourceforge.net/ GUITAR] is an extensible framework for testing software applications. It presents a unified solution to the software testing problem. [http://guitar.sourceforge.net/ GUITAR’s] architecture allows testers to create new “process plug-ins” (i.e., tools/techniques/algorithms) to perform different testing activities. It currently contains a rich collection of plug-ins that may be used to test an application through its graphical user interface. For example, the “test case generator” plug-in, a tester can automatically generate various types of test cases for the Application Under Test (AUT); the “replayer” plug-in may be used to execute these test cases on the AUT automatically; during the various development phases of the AUT, the “regression tester” plug-in can be used to efficiently perform regression testing on the AUT.

[[Image:Guitar.jpg|650px|thumb|center|Overview of the [http://guitar.sourceforge.net/ GUITAR Guitar Framework].]]

----

====Cucumber====

Cucumber is a tool that can execute plain-text functional descriptions as automated tests. The language that Cucumber understands is called Gherkin. Here is an example:

<pre>Feature: Search courses
In order to ensure better utilization of courses
Potential students should be able to search for courses

Scenario: Search by topic
Given there are 240 courses which do not have the topic "biology"
And there are 2 courses A001, B205 that each have "biology" as one of the topics
When I search for "biology"
Then I should see the following courses:
| Course code |
| A001 |
| B205 |</pre>
While Cucumber can be thought of as a “testing” tool, the intent of the tool is to support BDD. This means that the “tests” (plain text feature descriptions with scenarios) are typically written before anything else and verified by business analysts, domain experts, etc. non technical stakeholders. The production code is then written outside-in, to make the stories pass.

----

===Conclusion===

----

===References===

----

CSC/ECE 517 Fall 2009/wiki2 10 Gui Testing Frameworks aa

2009-10-09T16:35:02Z

Abhatt: /* GUI Testing Difficulties */

CSC/ECE 517 Fall 2009/wiki2 10 Gui Testing Frameworks aa

2009-10-09T16:34:01Z

Abhatt: /* GUI Testing Difficulties */

CSC/ECE 517 Fall 2009/wiki2 10 Gui Testing Frameworks aa

2009-10-09T16:32:42Z

Abhatt: /* GUI Testing Difficulties */

CSC/ECE 517 Fall 2009/wiki2 10 Gui Testing Frameworks aa

2009-10-09T16:32:05Z

Abhatt: /* GUI Testing Difficulties */

2009-09-21T20:51:40Z

Abhatt: /* Ruby */

== Python ==

'''Doctest''': It is a simple, ingenuine technology that allows you to write a narrative in a document which can directly be executed as a test. It is included in Python as a module.

Although doctest makes testing code readable for non-programmers ,the simplicity of a narrative test like doctest is accompanied by it’s own flaws .Some of the disadvantages of using doctest are

• These tests are difficult to handle in case of failures as they are more generic. Specific tests are narrower and better in communicating intent and ensuring coverage.

• The test code is executed in a special way thus making it difficult to reason about how it will be executed. It is also harder to program around the tests.

• It is actually difficult to get an outline of the tests at glance. There’s no tool that can give an overview of the unit tests in a doc test file [2].

An detailed information about doctest with thorough examples can be read at http://docs.python.org/library/doctest.html

'''Unittest''': Unittest are more specific tests which are more functional in nature allowing it to be written for individual functions or the class as a whole.

The fact that Unittest is based on jUnit makes people with the xUnit familiarity pick it up really quick hence it is more Java based than python .It has been introduced in the Python’s library since version 2.1

The disadvantages of using the unit test are

• The tests have a different look and feel with respect to the code under test

• The assertions used in the text use custom syntax which makes it difficult

• The test code is difficult to understand compared to the Doctest and the strong basis on jUnit makes it difficult for the pure Python coders [3]

A detailed information about doctest with thorough examples can be read at http://docs.python.org/library/unittest.html

'''Doctest vs Unittest'''

Here we compare simple features of both the tests thus giving us an idea of which one to use based on the requirement

{| {{table}}
| align="center" style="background:#f0f0f0;"|''''''
| align="center" style="background:#f0f0f0;"|'''doctest'''
| align="center" style="background:#f0f0f0;"|'''unittest'''
|-
| '''Simplicity'''||Best suited for novice programmers||A little complex to use specially if unaware of Junit
|-
| '''Documentation'''||Better Narratives||Tests have little or no comments
|-
| '''Comprehensive testing'''||Doctests get clutterd for comprehensive tests and thus less readable||Best suited for comprehensive tests
|-
| '''Flexibility and Control'''||Less flexible||More flexible
|-
|
|}

== Ruby ==

The basic testing framework for RUBY is xUnit . There are some frameworks which have evolved over the years which include RSpec, Trantula, Flog, RunCodeRun, Cucumber etc. We’ll talk about each of them in brief

{| {{table}}
| style="background:#f0f0f0;"|'''Testing Framework'''
| align="center" style="background:#f0f0f0;"|''''''
|-
| '''Rspec[4]'''||It is Behavior Driven Development whose basic features are
|-
| ||· Behavior counts first, testing follows
|-
| ||· It focuses more on business values
|-
| ||· It’s more about getting the words right rather than just writing the test first
|-
| ||Advantages:
|-
| ||· These are extremely easy to read and makes sense to a non-programmer
|-
| ||· Rspec lets you unit test while also providing mocking and stubbing support
|-
| ||· Rspec can help with the coverage tests using Rcov
|-
| ||· One can also perform integration test using Rspec
|-
| ||Disadvantages:
|-
| ||· It involves a lot of behind the scene metaprogramming which makes the tests very difficult to understand
|-
| ||A simple Rspec example can be read at http://rspec.info/
|-
| '''Cucumber[5]'''||Cucumber, the latest addition to the Rspec family allows one to execute documentation written in plain text(known as ‘stories’)
|-
| ||A very good example of writing a test in cucumber can be read at http://cukes.info/
|-
| ||
|-
| '''Tarantula[6]'''||Tarantula is a Rail’s plugin that produces a detailed report describing the URL’s that it has crawled across and the responses that it received from each one of them.
|-
| ||Tarantula\'s functionality somewhat overlaps with the on site testing, particularly if you are practicing test-driven development (TDD). Tarantula runs against your actual Web site thereby helping you to identify the problems associated with your production server, user-generated data, and HTML compliance.
|-
| '''Flog[7]'''||Flog is a tool which gives you a profile of your code’s complexity. It can given the complexity pertaining to each method in your code. One can also set threshold for each method using flog
|-
| ||The complexity of a code can be important to
|-
| ||· Find the bugs as they are highly probable in complex code areas
|-
| ||· Complex codes can be considered for refactoring
|-
| ||A flog report has been explained and shown here http://www.ruby-forum.com/topic/131931
|-
| ||
|-
|
|}

== C# ==

The list of frameworks that apply for .NET are applied for C#. A long list of testing frameworks are available for C# which are csUnit, NUnit, dotunit, VSNUnit, Nester[8].

{| {{table}}
| align="center" style="background:#f0f0f0;"|''''''
| align="center" style="background:#f0f0f0;"|'''NUnit'''
| align="center" style="background:#f0f0f0;"|'''csUnit'''
| align="center" style="background:#f0f0f0;"|'''Systin'''
|-
| Description||NUnit has been ported from JUnit and has been written completely to take the advantage of the .NET languages.||It is a free open source unit testing tool for all the test-driven development .NET languages including C#. ||Systin creates a domain specific testing language which allows an automatic testing of applications at the system level.
|-
| ||The major advancements with NUnit are parameterized tests which provides a concise method to express a set of examples that can used to run individual test cases.||It has been inspired from JUnit and can be used as an add-in along with the NUnit||The tests can be written in a simple document which can be converted to a .net language driver class
|-
| Examples||http://www.nunit.org/blogs/||http://www.csunit.org/tutorials/tutorial7/||
|-
| ||||||
|-
| Used as||Testing framework, GUI and console tool||Testing Framework , Console tool and VS.NET Add In||
|-
|
|}

== References ==

[1] http://www.c2.com/cgi/wiki?TestingFramework

[2] http://en.wikipedia.org/wiki/Doctest

[3] http://en.wikipedia.org/wiki/Unit_testing

[4] http://www.elctech.com/tutorials/rspec-tutorial

[5] http://www.rubyinside.com/cucumber-the-latest-in-ruby-testing-1342.html

[6] http://www.ruby-forum.com/topic/144083

[7] http://www.brynary.com/2007/9/13/scourging-your-ruby-code-with-flog

[8] http://csharp-source.net/open-source/testing-tools

Http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE 517 Fall 2010/ch1 S10 MS

2009-09-21T20:50:58Z

Abhatt: /* C# */

Http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE 517 Fall 2010/ch1 S10 MS

2009-09-21T20:19:44Z

Abhatt: /* Python */

Http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE 517 Fall 2010/ch1 S10 MS

2009-09-21T20:19:05Z

Abhatt: /* Python */

== Python ==

'''Doctest''': It is a simple, ingenuine technology that allows you to write a narrative in a document which can directly be executed as a test. It is included in Python as a module.

Although doctest makes testing code readable for non-programmers ,the simplicity of a narrative test like doctest is accompanied by it’s own flaws .Some of the disadvantages of using doctest are

• These tests are difficult to handle in case of failures as they are more generic. Specific tests are narrower and better in communicating intent and ensuring coverage.

• The test code is executed in a special way thus making it difficult to reason about how it will be executed. It is also harder to program around the tests.

• It is actually difficult to get an outline of the tests at glance. There’s no tool that can give an overview of the unit tests in a doc test file [[2]].

An detailed information about doctest with thorough examples can be read at http://docs.python.org/library/doctest.html

'''Unittest''': Unittest are more specific tests which are more functional in nature allowing it to be written for individual functions or the class as a whole.

The fact that Unittest is based on jUnit makes people with the xUnit familiarity pick it up really quick hence it is more Java based than python .It has been introduced in the Python’s library since version 2.1

The disadvantages of using the unit test are

• The tests have a different look and feel with respect to the code under test

• The assertions used in the text use custom syntax which makes it difficult

• The test code is difficult to understand compared to the Doctest and the strong basis on jUnit makes it difficult for the pure Python coders [3]

A detailed information about doctest with thorough examples can be read at http://docs.python.org/library/unittest.html

'''Doctest vs Unittest'''

Here we compare simple features of both the tests thus giving us an idea of which one to use based on the requirement

{| {{table}}
| align="center" style="background:#f0f0f0;"|''''''
| align="center" style="background:#f0f0f0;"|'''doctest'''
| align="center" style="background:#f0f0f0;"|'''unittest'''
|-
| '''Simplicity'''||Best suited for novice programmers||A little complex to use specially if unaware of Junit
|-
| '''Documentation'''||Better Narratives||Tests have little or no comments
|-
| '''Comprehensive testing'''||Doctests get clutterd for comprehensive tests and thus less readable||Best suited for comprehensive tests
|-
| '''Flexibility and Control'''||Less flexible||More flexible
|-
|
|}

== Ruby ==

The basic testing framework for RUBY is xUnit . There are some frameworks which have evolved over the years which include RSpec, Trantula, Flog, RunCodeRun, Cucumber etc. We’ll talk about each of them in brief

{| {{table}}
| style="background:#f0f0f0;"|'''Testing Framework'''
| align="center" style="background:#f0f0f0;"|''''''
|-
| '''Rspec[4]'''||It is Behavior Driven Development whose basic features are
|-
| ||· Behavior counts first, testing follows
|-
| ||· It focuses more on business values
|-
| ||· It’s more about getting the words right rather than just writing the test first
|-
| ||Advantages:
|-
| ||· These are extremely easy to read and makes sense to a non-programmer
|-
| ||· Rspec lets you unit test while also providing mocking and stubbing support
|-
| ||· Rspec can help with the coverage tests using Rcov
|-
| ||· One can also perform integration test using Rspec
|-
| ||Disadvantages:
|-
| ||· It involves a lot of behind the scene metaprogramming which makes the tests very difficult to understand
|-
| ||A simple Rspec example can be read at http://rspec.info/
|-
| '''Cucumber[5]'''||Cucumber, the latest addition to the Rspec family allows one to execute documentation written in plain text(known as ‘stories’)
|-
| ||A very good example of writing a test in cucumber can be read at http://cukes.info/
|-
| ||
|-
| '''Tarantula[6]'''||Tarantula is a Rail’s plugin that produces a detailed report describing the URL’s that it has crawled across and the responses that it received from each one of them.
|-
| ||Tarantula\'s functionality somewhat overlaps with the on site testing, particularly if you are practicing test-driven development (TDD). Tarantula runs against your actual Web site thereby helping you to identify the problems associated with your production server, user-generated data, and HTML compliance.
|-
| '''Flog[7]'''||Flog is a tool which gives you a profile of your code’s complexity. It can given the complexity pertaining to each method in your code. One can also set threshold for each method using flog
|-
| ||The complexity of a code can be important to
|-
| ||· Find the bugs as they are highly probable in complex code areas
|-
| ||· Complex codes can be considered for refactoring
|-
| ||A flog report has been explained and shown here http://www.ruby-forum.com/topic/131931
|-
| ||
|-
|
|}

== C# ==

The list of frameworks that apply for .NET are applied for C#. A long list of testing frameworks are available for C# which are csUnit, NUnit, dotunit, VSNUnit, Nester[8].

{| {{table}}
| align="center" style="background:#f0f0f0;"|''''''
| align="center" style="background:#f0f0f0;"|'''NUnit'''
| align="center" style="background:#f0f0f0;"|'''csUnit'''
| align="center" style="background:#f0f0f0;"|'''Systin'''
|-
| Description||NUnit has been ported from JUnit and has been written completely to take the advantage of the .NET languages.||It is a free open source unit testing tool for all the test-driven development .NET languages including C#. ||Systin creates a domain specific testing language which allows an automatic testing of applications at the system level.
|-
| ||The major advancements with NUnit are parameterized tests which provides a concise method to express a set of examples that can used to run individual test cases.||It has been inspired from JUnit and can be used as an add-in along with the NUnit||The tests can be written in a simple document which can be converted to a .net language driver class
|-
| Examples||http://www.nunit.org/blogs/||http://www.csunit.org/tutorials/tutorial7/||
|-
| ||||||
|-
| Used as||Testing framework, GUI and console tool||Testing Framework , Console tool and VS.NET Add In||
|-
|
|}

== References ==

[1] http://www.c2.com/cgi/wiki?TestingFramework

[2] http://en.wikipedia.org/wiki/Doctest

[3] http://en.wikipedia.org/wiki/Unit_testing

[4] http://www.elctech.com/tutorials/rspec-tutorial

[5] http://www.rubyinside.com/cucumber-the-latest-in-ruby-testing-1342.html

[6] http://www.ruby-forum.com/topic/144083

[7] http://www.brynary.com/2007/9/13/scourging-your-ruby-code-with-flog

[8] http://csharp-source.net/open-source/testing-tools

Http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE 517 Fall 2010/ch1 S10 MS

2009-09-21T20:18:29Z

Abhatt: /* References */

Http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE 517 Fall 2010/ch1 S10 MS

2009-09-21T20:17:59Z

Abhatt:

== Python ==

'''Doctest''': It is a simple, ingenuine technology that allows you to write a narrative in a document which can directly be executed as a test. It is included in Python as a module.

Although doctest makes testing code readable for non-programmers ,the simplicity of a narrative test like doctest is accompanied by it’s own flaws .Some of the disadvantages of using doctest are

• These tests are difficult to handle in case of failures as they are more generic. Specific tests are narrower and better in communicating intent and ensuring coverage.

• The test code is executed in a special way thus making it difficult to reason about how it will be executed. It is also harder to program around the tests.

• It is actually difficult to get an outline of the tests at glance. There’s no tool that can give an overview of the unit tests in a doc test file [2].

An detailed information about doctest with thorough examples can be read at http://docs.python.org/library/doctest.html

'''Unittest''': Unittest are more specific tests which are more functional in nature allowing it to be written for individual functions or the class as a whole.

The fact that Unittest is based on jUnit makes people with the xUnit familiarity pick it up really quick hence it is more Java based than python .It has been introduced in the Python’s library since version 2.1

The disadvantages of using the unit test are

• The tests have a different look and feel with respect to the code under test

• The assertions used in the text use custom syntax which makes it difficult

• The test code is difficult to understand compared to the Doctest and the strong basis on jUnit makes it difficult for the pure Python coders [3]

A detailed information about doctest with thorough examples can be read at http://docs.python.org/library/unittest.html

'''Doctest vs Unittest'''

Here we compare simple features of both the tests thus giving us an idea of which one to use based on the requirement

{| {{table}}
| align="center" style="background:#f0f0f0;"|''''''
| align="center" style="background:#f0f0f0;"|'''doctest'''
| align="center" style="background:#f0f0f0;"|'''unittest'''
|-
| '''Simplicity'''||Best suited for novice programmers||A little complex to use specially if unaware of Junit
|-
| '''Documentation'''||Better Narratives||Tests have little or no comments
|-
| '''Comprehensive testing'''||Doctests get clutterd for comprehensive tests and thus less readable||Best suited for comprehensive tests
|-
| '''Flexibility and Control'''||Less flexible||More flexible
|-
|
|}

== Ruby ==

The basic testing framework for RUBY is xUnit . There are some frameworks which have evolved over the years which include RSpec, Trantula, Flog, RunCodeRun, Cucumber etc. We’ll talk about each of them in brief

{| {{table}}
| style="background:#f0f0f0;"|'''Testing Framework'''
| align="center" style="background:#f0f0f0;"|''''''
|-
| '''Rspec[4]'''||It is Behavior Driven Development whose basic features are
|-
| ||· Behavior counts first, testing follows
|-
| ||· It focuses more on business values
|-
| ||· It’s more about getting the words right rather than just writing the test first
|-
| ||Advantages:
|-
| ||· These are extremely easy to read and makes sense to a non-programmer
|-
| ||· Rspec lets you unit test while also providing mocking and stubbing support
|-
| ||· Rspec can help with the coverage tests using Rcov
|-
| ||· One can also perform integration test using Rspec
|-
| ||Disadvantages:
|-
| ||· It involves a lot of behind the scene metaprogramming which makes the tests very difficult to understand
|-
| ||A simple Rspec example can be read at http://rspec.info/
|-
| '''Cucumber[5]'''||Cucumber, the latest addition to the Rspec family allows one to execute documentation written in plain text(known as ‘stories’)
|-
| ||A very good example of writing a test in cucumber can be read at http://cukes.info/
|-
| ||
|-
| '''Tarantula[6]'''||Tarantula is a Rail’s plugin that produces a detailed report describing the URL’s that it has crawled across and the responses that it received from each one of them.
|-
| ||Tarantula\'s functionality somewhat overlaps with the on site testing, particularly if you are practicing test-driven development (TDD). Tarantula runs against your actual Web site thereby helping you to identify the problems associated with your production server, user-generated data, and HTML compliance.
|-
| '''Flog[7]'''||Flog is a tool which gives you a profile of your code’s complexity. It can given the complexity pertaining to each method in your code. One can also set threshold for each method using flog
|-
| ||The complexity of a code can be important to
|-
| ||· Find the bugs as they are highly probable in complex code areas
|-
| ||· Complex codes can be considered for refactoring
|-
| ||A flog report has been explained and shown here http://www.ruby-forum.com/topic/131931
|-
| ||
|-
|
|}

== C# ==

The list of frameworks that apply for .NET are applied for C#. A long list of testing frameworks are available for C# which are csUnit, NUnit, dotunit, VSNUnit, Nester[8].

{| {{table}}
| align="center" style="background:#f0f0f0;"|''''''
| align="center" style="background:#f0f0f0;"|'''NUnit'''
| align="center" style="background:#f0f0f0;"|'''csUnit'''
| align="center" style="background:#f0f0f0;"|'''Systin'''
|-
| Description||NUnit has been ported from JUnit and has been written completely to take the advantage of the .NET languages.||It is a free open source unit testing tool for all the test-driven development .NET languages including C#. ||Systin creates a domain specific testing language which allows an automatic testing of applications at the system level.
|-
| ||The major advancements with NUnit are parameterized tests which provides a concise method to express a set of examples that can used to run individual test cases.||It has been inspired from JUnit and can be used as an add-in along with the NUnit||The tests can be written in a simple document which can be converted to a .net language driver class
|-
| Examples||http://www.nunit.org/blogs/||http://www.csunit.org/tutorials/tutorial7/||
|-
| ||||||
|-
| Used as||Testing framework, GUI and console tool||Testing Framework , Console tool and VS.NET Add In||
|-
|
|}

== References ==

[1] http://www.c2.com/cgi/wiki?TestingFramework
[2] http://en.wikipedia.org/wiki/Doctest
[3] http://en.wikipedia.org/wiki/Unit_testing
[4] http://www.elctech.com/tutorials/rspec-tutorial
[5] http://www.rubyinside.com/cucumber-the-latest-in-ruby-testing-1342.html
[6] http://www.ruby-forum.com/topic/144083
[7] http://www.brynary.com/2007/9/13/scourging-your-ruby-code-with-flog
[8] http://csharp-source.net/open-source/testing-tools

Http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE 517 Fall 2010/ch1 S10 MS

2009-09-21T20:16:13Z

Abhatt: /* Python */

== Python ==

'''Doctest''': It is a simple, ingenuine technology that allows you to write a narrative in a document which can directly be executed as a test. It is included in Python as a module.

Although doctest makes testing code readable for non-programmers ,the simplicity of a narrative test like doctest is accompanied by it’s own flaws .Some of the disadvantages of using doctest are

• These tests are difficult to handle in case of failures as they are more generic. Specific tests are narrower and better in communicating intent and ensuring coverage.

• The test code is executed in a special way thus making it difficult to reason about how it will be executed. It is also harder to program around the tests.

• It is actually difficult to get an outline of the tests at glance. There’s no tool that can give an overview of the unit tests in a doc test file [2].

An detailed information about doctest with thorough examples can be read at http://docs.python.org/library/doctest.html

'''Unittest''': Unittest are more specific tests which are more functional in nature allowing it to be written for individual functions or the class as a whole.

The fact that Unittest is based on jUnit makes people with the xUnit familiarity pick it up really quick hence it is more Java based than python .It has been introduced in the Python’s library since version 2.1

The disadvantages of using the unit test are

• The tests have a different look and feel with respect to the code under test

• The assertions used in the text use custom syntax which makes it difficult

• The test code is difficult to understand compared to the Doctest and the strong basis on jUnit makes it difficult for the pure Python coders [3]

A detailed information about doctest with thorough examples can be read at http://docs.python.org/library/unittest.html

'''Doctest vs Unittest'''

Here we compare simple features of both the tests thus giving us an idea of which one to use based on the requirement

{| {{table}}
| align="center" style="background:#f0f0f0;"|''''''
| align="center" style="background:#f0f0f0;"|'''doctest'''
| align="center" style="background:#f0f0f0;"|'''unittest'''
|-
| '''Simplicity'''||Best suited for novice programmers||A little complex to use specially if unaware of Junit
|-
| '''Documentation'''||Better Narratives||Tests have little or no comments
|-
| '''Comprehensive testing'''||Doctests get clutterd for comprehensive tests and thus less readable||Best suited for comprehensive tests
|-
| '''Flexibility and Control'''||Less flexible||More flexible
|-
|
|}

== C# ==

The list of frameworks that apply for .NET are applied for C#. A long list of testing frameworks are available for C# which are csUnit, NUnit, dotunit, VSNUnit, Nester[8].

{| {{table}}
| align="center" style="background:#f0f0f0;"|''''''
| align="center" style="background:#f0f0f0;"|'''NUnit'''
| align="center" style="background:#f0f0f0;"|'''csUnit'''
| align="center" style="background:#f0f0f0;"|'''Systin'''
|-
| Description||NUnit has been ported from JUnit and has been written completely to take the advantage of the .NET languages.||It is a free open source unit testing tool for all the test-driven development .NET languages including C#. ||Systin creates a domain specific testing language which allows an automatic testing of applications at the system level.
|-
| ||The major advancements with NUnit are parameterized tests which provides a concise method to express a set of examples that can used to run individual test cases.||It has been inspired from JUnit and can be used as an add-in along with the NUnit||The tests can be written in a simple document which can be converted to a .net language driver class
|-
| Examples||http://www.nunit.org/blogs/||http://www.csunit.org/tutorials/tutorial7/||
|-
| ||||||
|-
| Used as||Testing framework, GUI and console tool||Testing Framework , Console tool and VS.NET Add In||
|-
|
|}

== References ==

[1] http://www.c2.com/cgi/wiki?TestingFramework
[2] http://en.wikipedia.org/wiki/Doctest
[3] http://en.wikipedia.org/wiki/Unit_testing
[4] http://www.elctech.com/tutorials/rspec-tutorial
[5] http://www.rubyinside.com/cucumber-the-latest-in-ruby-testing-1342.html
[6] http://www.ruby-forum.com/topic/144083
[7] http://www.brynary.com/2007/9/13/scourging-your-ruby-code-with-flog
[8] http://csharp-source.net/open-source/testing-tools

== Ruby ==

The basic testing framework for RUBY is xUnit . There are some frameworks which have evolved over the years which include RSpec, Trantula, Flog, RunCodeRun, Cucumber etc. We’ll talk about each of them in brief

{| {{table}}
| style="background:#f0f0f0;"|'''Testing Framework'''
| align="center" style="background:#f0f0f0;"|''''''
|-
| '''Rspec[4]'''||It is Behavior Driven Development whose basic features are
|-
| ||· Behavior counts first, testing follows
|-
| ||· It focuses more on business values
|-
| ||· It’s more about getting the words right rather than just writing the test first
|-
| ||Advantages:
|-
| ||· These are extremely easy to read and makes sense to a non-programmer
|-
| ||· Rspec lets you unit test while also providing mocking and stubbing support
|-
| ||· Rspec can help with the coverage tests using Rcov
|-
| ||· One can also perform integration test using Rspec
|-
| ||Disadvantages:
|-
| ||· It involves a lot of behind the scene metaprogramming which makes the tests very difficult to understand
|-
| ||A simple Rspec example can be read at http://rspec.info/
|-
| '''Cucumber[5]'''||Cucumber, the latest addition to the Rspec family allows one to execute documentation written in plain text(known as ‘stories’)
|-
| ||A very good example of writing a test in cucumber can be read at http://cukes.info/
|-
| ||
|-
| '''Tarantula[6]'''||Tarantula is a Rail’s plugin that produces a detailed report describing the URL’s that it has crawled across and the responses that it received from each one of them.
|-
| ||Tarantula\'s functionality somewhat overlaps with the on site testing, particularly if you are practicing test-driven development (TDD). Tarantula runs against your actual Web site thereby helping you to identify the problems associated with your production server, user-generated data, and HTML compliance.
|-
| '''Flog[7]'''||Flog is a tool which gives you a profile of your code’s complexity. It can given the complexity pertaining to each method in your code. One can also set threshold for each method using flog
|-
| ||The complexity of a code can be important to
|-
| ||· Find the bugs as they are highly probable in complex code areas
|-
| ||· Complex codes can be considered for refactoring
|-
| ||A flog report has been explained and shown here http://www.ruby-forum.com/topic/131931
|-
| ||
|-
|
|}

Http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE 517 Fall 2010/ch1 S10 MS

2009-09-21T20:12:21Z

Abhatt: /* Python */

Http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE 517 Fall 2010/ch1 S10 MS

2009-09-21T20:11:54Z

Abhatt: /* Python */

== Python ==

'''Doctest''': It is a simple, ingenuine technology that allows you to write a narrative in a document which can directly be executed as a test. It is included in Python as a module.

Although doctest makes testing code readable for non-programmers ,the simplicity of a narrative test like doctest is accompanied by it’s own flaws .Some of the disadvantages of using doctest are

• These tests are difficult to handle in case of failures as they are more generic. Specific tests are narrower and better in communicating intent and ensuring coverage.

• The test code is executed in a special way thus making it difficult to reason about how it will be executed. It is also harder to program around the tests.

• It is actually difficult to get an outline of the tests at glance. There’s no tool that can give an overview of the unit tests in a doc test file [2].

An detailed information about doctest with thorough examples can be read at http://docs.python.org/library/doctest.html

'''Unittest''': Unittest are more specific tests which are more functional in nature allowing it to be written for individual functions or the class as a whole.

The fact that Unittest is based on jUnit makes people with the xUnit familiarity pick it up really quick hence it is more Java based than python .It has been introduced in the Python’s library since version 2.1

The disadvantages of using the unit test are

• The tests have a different look and feel with respect to the code under test

• The assertions used in the text use custom syntax which makes it difficult

• The test code is difficult to understand compared to the Doctest and the strong basis on jUnit makes it difficult for the pure Python coders [3]

A detailed information about doctest with thorough examples can be read at http://docs.python.org/library/unittest.html

'''Doctest vs Unittest'''

Here we compare simple features of both the tests thus giving us an idea of which one to use based on the requirement

{| {{table}}
| align="center" style="background:#f0f0f0;"|''''''
| align="center" style="background:#f0f0f0;"|'''Doctest'''
| align="center" style="background:#f0f0f0;"|'''unittest'''
|-
| '''Simplicity'''||Best suited for novice programmers||A little complex to use specially if unaware of Junit
|-
| '''Documentation'''||Better Narratives||Tests have little or no comments
|-
| '''Comprehensive testing'''||Doctests get clutterd for comprehensive tests and thus less readable||Best suited for comprehensive tests
|-
| '''Flexibility and Control'''||Less flexible||More flexible
|-
|
|}

== Ruby ==

The basic testing framework for RUBY is xUnit . There are some frameworks which have evolved over the years which include RSpec, Trantula, Flog, RunCodeRun, Cucumber etc. We’ll talk about each of them in brief

{| {{table}}
| style="background:#f0f0f0;"|'''Testing Framework'''
| align="center" style="background:#f0f0f0;"|''''''
|-
| '''Rspec[4]'''||It is Behavior Driven Development whose basic features are
|-
| ||· Behavior counts first, testing follows
|-
| ||· It focuses more on business values
|-
| ||· It’s more about getting the words right rather than just writing the test first
|-
| ||Advantages:
|-
| ||· These are extremely easy to read and makes sense to a non-programmer
|-
| ||· Rspec lets you unit test while also providing mocking and stubbing support
|-
| ||· Rspec can help with the coverage tests using Rcov
|-
| ||· One can also perform integration test using Rspec
|-
| ||Disadvantages:
|-
| ||· It involves a lot of behind the scene metaprogramming which makes the tests very difficult to understand
|-
| ||A simple Rspec example can be read at http://rspec.info/
|-
| '''Cucumber[5]'''||Cucumber, the latest addition to the Rspec family allows one to execute documentation written in plain text(known as ‘stories’)
|-
| ||A very good example of writing a test in cucumber can be read at http://cukes.info/
|-
| ||
|-
| '''Tarantula[6]'''||Tarantula is a Rail’s plugin that produces a detailed report describing the URL’s that it has crawled across and the responses that it received from each one of them.
|-
| ||Tarantula\'s functionality somewhat overlaps with the on site testing, particularly if you are practicing test-driven development (TDD). Tarantula runs against your actual Web site thereby helping you to identify the problems associated with your production server, user-generated data, and HTML compliance.
|-
| '''Flog[7]'''||Flog is a tool which gives you a profile of your code’s complexity. It can given the complexity pertaining to each method in your code. One can also set threshold for each method using flog
|-
| ||The complexity of a code can be important to
|-
| ||· Find the bugs as they are highly probable in complex code areas
|-
| ||· Complex codes can be considered for refactoring
|-
| ||A flog report has been explained and shown here http://www.ruby-forum.com/topic/131931
|-
| ||
|-
|
|}

Http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE 517 Fall 2010/ch1 S10 MS

2009-09-21T20:10:53Z

Abhatt: /* Python */

== Python ==

'''Doctest''': It is a simple, ingenuine technology that allows you to write a narrative in a document which can directly be executed as a test. It is included in Python as a module.

Although doctest makes testing code readable for non-programmers ,the simplicity of a narrative test like doctest is accompanied by it’s own flaws .Some of the disadvantages of using doctest are

• These tests are difficult to handle in case of failures as they are more generic. Specific tests are narrower and better in communicating intent and ensuring coverage.

• The test code is executed in a special way thus making it difficult to reason about how it will be executed. It is also harder to program around the tests.

• It is actually difficult to get an outline of the tests at glance. There’s no tool that can give an overview of the unit tests in a doc test file [2].

An detailed information about doctest with thorough examples can be read at http://docs.python.org/library/doctest.html

'''Unittest''': Unittest are more specific tests which are more functional in nature allowing it to be written for individual functions or the class as a whole.

The fact that Unittest is based on jUnit makes people with the xUnit familiarity pick it up really quick hence it is more Java based than python .It has been introduced in the Python’s library since version 2.1

The disadvantages of using the unit test are

• The tests have a different look and feel with respect to the code under test

• The assertions used in the text use custom syntax which makes it difficult

• The test code is difficult to understand compared to the Doctest and the strong basis on jUnit makes it difficult for the pure Python coders [3]

A detailed information about doctest with thorough examples can be read at http://docs.python.org/library/unittest.html

'''Doctest vs Unittest'''

Here we compare simple features of both the tests thus giving us an idea of which one to use based on the requirement

{| {{table}}
| align="center" style="background:#f0f0f0;"|''''''
| align="center" style="background:#f0f0f0;"|'''Doctest'''
| align="center" style="background:#f0f0f0;"|'''unittest'''
|-
| '''Simplicity'''||Best suited for novice programmers||A little complex to use specially if unaware of Junit
|-
| '''Documentation'''||Better Narratives||Tests have little or no comments
|-
| '''Comprehensive testing'''||Doctests get clutterd for comprehensive tests and thus less readable||Best suited for comprehensive tests
|-
| '''Flexibility and Control'''||Less flexible||More flexible
|-
|
|}

== Ruby
==

The basic testing framework for RUBY is xUnit . There are some frameworks which have evolved over the years which include RSpec, Trantula, Flog, RunCodeRun, Cucumber etc. We’ll talk about each of them in brief

{| {{table}}
| align="center" style="background:#f0f0f0;"|'''Testing Framework'''
| align="center" style="background:#f0f0f0;"|''''''
|-
| '''Rspec[4]'''||It is Behavior Driven Development whose basic features are
|-
| ||· Behavior counts first, testing follows
|-
| ||· It focuses more on business values
|-
| ||· It’s more about getting the words right rather than just writing the test first
|-
| ||Advantages:
|-
| ||· These are extremely easy to read and makes sense to a non-programmer
|-
| ||· Rspec lets you unit test while also providing mocking and stubbing support
|-
| ||· Rspec can help with the coverage tests using Rcov
|-
| ||· One can also perform integration test using Rspec
|-
| ||Disadvantages:
|-
| ||· It involves a lot of behind the scene metaprogramming which makes the tests very difficult to understand
|-
| ||A simple Rspec example can be read at http://rspec.info/
|-
| '''Cucumber[5]'''||Cucumber, the latest addition to the Rspec family allows one to execute documentation written in plain text(known as ‘stories’)
|-
| ||A very good example of writing a test in cucumber can be read at http://cukes.info/
|-
| ||
|-
| '''Tarantula[6]'''||Tarantula is a Rail’s plugin that produces a detailed report describing the URL’s that it has crawled across and the responses that it received from each one of them.
|-
| ||Tarantula\'s functionality somewhat overlaps with the on site testing, particularly if you are practicing test-driven development (TDD). Tarantula runs against your actual Web site thereby helping you to identify the problems associated with your production server, user-generated data, and HTML compliance.
|-
| '''Flog[7]'''||Flog is a tool which gives you a profile of your code’s complexity. It can given the complexity pertaining to each method in your code. One can also set threshold for each method using flog
|-
| ||The complexity of a code can be important to
|-
| ||· Find the bugs as they are highly probable in complex code areas
|-
| ||· Complex codes can be considered for refactoring
|-
| ||A flog report has been explained and shown here http://www.ruby-forum.com/topic/131931
|-
| ||
|-
|
|}

Http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE 517 Fall 2010/ch1 S10 MS

2009-09-21T20:09:26Z

2009-09-21T19:58:16Z

Abhatt:

Python

Doctest: It is a simple, ingenuine technology that allows you to write a narrative in a document which can directly be executed as a test. It is included in Python as a module.
Although doctest makes testing code readable for non-programmers ,the simplicity of a narrative test like doctest is accompanied by it’s own flaws .Some of the disadvantages of using doctest are

• These tests are difficult to handle in case of failures as they are more generic. Specific tests are narrower and better in communicating intent and ensuring coverage.
• The test code is executed in a special way thus making it difficult to reason about how it will be executed. It is also harder to program around the tests.
• It is actually difficult to get an outline of the tests at glance. There’s no tool that can give an overview of the unit tests in a doc test file [2]
An detailed information about doctest with thorough examples can be read at http://docs.python.org/library/doctest.html

Unittest: Unittest are more specific tests which are more functional in nature allowing it to be written for individual functions or the class as a whole.
The fact that Unittest is based on jUnit makes people with the xUnit familiarity pick it up really quick hence it is more Java based than python .It has been introduced in the Python’s library since version 2.1
The disadvantages of using the unit test are
• The tests have a different look and feel with respect to the code under test
• The assertions used in the text use custom syntax which makes it difficult
• The test code is difficult to understand compared to the Doctest and the strong basis on jUnit makes it difficult for the pure Python coders [3]
A detailed information about doctest with thorough examples can be read at http://docs.python.org/library/unittest.html

Doctest vs Unittest

Here we compare simple features of both the tests thus giving us an idea of which one to use based on the requirement

Http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE 517 Fall 2010/ch1 S10 MS

2009-09-21T19:57:04Z

Abhatt:

<nowiki>
Python

Doctest: It is a simple, ingenuine technology that allows you to write a narrative in a document which can directly be executed as a test. It is included in Python as a module.
Although doctest makes testing code readable for non-programmers ,the simplicity of a narrative test like doctest is accompanied by it’s own flaws .Some of the disadvantages of using doctest are

• These tests are difficult to handle in case of failures as they are more generic. Specific tests are narrower and better in communicating intent and ensuring coverage.
• The test code is executed in a special way thus making it difficult to reason about how it will be executed. It is also harder to program around the tests.
• It is actually difficult to get an outline of the tests at glance. There’s no tool that can give an overview of the unit tests in a doc test file [2]
An detailed information about doctest with thorough examples can be read at http://docs.python.org/library/doctest.html

Unittest: Unittest are more specific tests which are more functional in nature allowing it to be written for individual functions or the class as a whole.
The fact that Unittest is based on jUnit makes people with the xUnit familiarity pick it up really quick hence it is more Java based than python .It has been introduced in the Python’s library since version 2.1
The disadvantages of using the unit test are
• The tests have a different look and feel with respect to the code under test
• The assertions used in the text use custom syntax which makes it difficult
• The test code is difficult to understand compared to the Doctest and the strong basis on jUnit makes it difficult for the pure Python coders [3]
A detailed information about doctest with thorough examples can be read at http://docs.python.org/library/unittest.html

Doctest vs Unittest

Here we compare simple features of both the tests thus giving us an idea of which one to use based on the requirement

</nowiki>