Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2009/wiki3 17 am

2009-12-01T06:13:21Z

Akimbo:

=='''Single Choice Principle'''==
===Introduction===

Single Choice Principle states that whenever a software system must support a set of alternatives, one and only one module in the system should know their exhaustive list. It is one of the five principles of software construction as stated by Bertrand Meyer, the other four being the [http://hebb.cis.uoguelph.ca/~dave/343/Lectures/swquality.html#linguistic Linguistic Modular Units Principle], the Self- Documentation Principle, the [http://en.wikipedia.org/wiki/Uniform_access_principle Uniform- Access Principle], and the [http://en.wikipedia.org/wiki/Open/closed_principle Open- Closed Principle]. The Single Choice Principle may be viewed as a consequence of both the Open-Closed and information Hiding rules. It was applied when designing [http://en.wikipedia.org/wiki/Eiffel_%28programming_language%29 Eiffel].This principle is a particular case of the [http://en.wikipedia.org/wiki/Don%27t_repeat_yourself Don't repeat yourself principle].

===Violation of SCP===

Consider a type used to manage a declared in Pascal-Ada syntax :
<pre>Type Publication=
record
author,title:STRING;
publication_year:INTEGER;
case pubtype: (book,journal,conference_proceedings)of
book: (publisher:STRING);
journal: (volume,issue:STRING);
proceedings: (editor, place:STRING) – Conference proceedings
end</pre>
Let B be a typical client of A. B will manipulate publications through a variable such as
p:PUBLICATION
and to do anything useful with p, will need to discriminate explicitly between the various cases, as in:
<pre> case p of
book:...Instructions which may access the field p.publisher
journal:...Instructions which may access fields p.volume,p.issue
proceedings:...Instructions which may access fields p.editor,p.place
end</pre>

Now, whenever there is a need for a new variant, say technical reports of companies in this case, there is a need to extend the definition of type PUBLICATION in module A to support the new case, as well as any client of A, such as B, will also require updating if it is used as a structure such as above, relying on an explicit list of cases for p.
What is observed is a violation of the SCP and is a disastrous situation for software change and evolution as a simple and natural addition may cause a chain reaction of changes across many client changes. This violation will occur whenever a certain notion admits a number of variants for ex. -

*In graphics system: the notion of figure, with such variants as polygon, circle, ellipse, and other basic figure types.
<pre>For example old style procedural code to print different "shape" objects might read:

if (type==CIRCLE)
print "Circle. r=" + radius;
else if (type==Square)
print "Square. sides=" + sideLength;
else if (type==Rectangle)
print "Rect. h=" + height + " w=" + width;
endif</pre>

This same list of alternatives would be used in computing the area, and it rendering to a GUI and in checking for overlap with another shape, etc., etc. So these lists of cases have to be modified in all locations whenever you add a new shape.

*In a text editor: the notion of user command, with such variants as line insertion, line deletion, character deletion.
*In a compiler for a programming language, the notion of language construct, with such variants as instruction, expression, procedure.

===Implementation of SCP===
Traditional methods do not provide a solution to the SCP violations. Inheritance related concepts of [http://en.wikipedia.org/wiki/Polymorphism polymorphism] and [http://en.wikipedia.org/wiki/Dynamic_binding_%28computer_science%29 Dynamic binding] provide the solution to this problem.

The graphics system given above can be reimplemented in the Object Oriented Manner as:

<pre>
class SHAPE
display_details
end
end

class CIRCLE < SHAPE
display_details
print "Circle. r=" + radius;
end
end

class SQUARE < SHAPE
display_details
print "Square. sides=" + sideLength;
end
end

class RECTANGLE < SHAPE
display_details
print "Rect. h=" + height + " w=" + width;
end
end
</pre>
Thus a new sub class of shape is created for each new type of shape. The function display_details to be called depends upon the type of the invoking object. Thus the list of switch case / if else statements would only be needed while creating the object. Further on no such statements have to be written for any of the other operations such as computing the area, rendering to a GUI or checking for overlap with another shape, etc., etc.

===Other Highlights===
# According to the Single Choice principle exactly one module should know the list of choices, which contrasts the modularity goal which suggests that at most one module should have this knowledge.
# The principle is about distribution of knowledge in a software system. The amount of information available to each module should be limited to the information that is required for its proper functioning. This can analogous to the "need-to-know" policy. That is, a module only knows that much as it needs to know.
# SCP is a direct consequence of the [http://en.wikipedia.org/wiki/Open/closed_principle Open Closed Principle].
# SCP is a strong form of [http://en.wikipedia.org/wiki/Information_hiding Information Hiding]. The module containing the list of choices tries to hide it from the the other modules.

===Conclusion===
The single choice principle is a principle of [http://en.wikipedia.org/wiki/Imperative_programming imperative] [http://en.wikipedia.org/wiki/Computer_programming computer programming].It directs us to limit the dissemination of exhaustive knowledge about variants of a certain notion. It is an impetus to [http://en.wikipedia.org/wiki/Polymorphism polymorphism] and aims at achieving high [http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 cohesion] and low [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 coupling], one of the most important aspects of [http://en.wikipedia.org/wiki/Modular_programming Modular Programming].

===References===
# Object-Oriented Software Construction Second Edition, Bertrand Meyer pgs 62-64.
# [http://c2.com/cgi/wiki?SingleChoicePrinciple Single Choice Principle]

CSC/ECE 517 Fall 2009/wiki3 17 Single Choice Pattern am

2009-12-01T05:52:14Z

Akimbo:

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

2009-10-09T20:09:17Z

Akimbo: /* Conclusion */

=='''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 [http://www.testingfaqs.org/t-gui.html|1|].

----

===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.[http://www.testingfaqs.org/t-gui.html|1|]

----

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

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

====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[http://misko.hevery.com/2008/07/05/testing-ui-part1/|3|].

----

====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 " <> ans;
cout << endl;
} while (ans == 'y' || ans == 'Y');
return 0;
}</pre>

----

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

As the name suggests,[http://www.site.uottawa.ca/~awilliam/seg3203/Capture.ppt Capture & Replay tool] captures the user interactions with the system under test.Inputs, outputs, and other information needed to reproduce a session with the system under test need to be recorded during the capture process.It is used mostly for regression testing.Some Java testing frameworks employing this approach are [http://jacareto.sourceforge.net Jacareto] and [http://abbot.sourceforge.net/doc/overview.shtml Abbot].

During the capture process, the tool will register as an event listener.Event notification method for the tool will record the details of all events that occurred.During the replay process, the tool will register as an event source (possibly also as a listener)and compare results.For mouse and keyboard events, the tool has to substitute for the actual devices as the event source.At test checkpoints, the tool can ask various controls for their state and record it, for eg GUI radio button properties.Replay events should be initiated at the same relative time as during the capture.

[[Image:Record.jpg|650px|thumb|center|figure 1:[http://en.web2test.de/web-testing-knowledgebase/testing-web-applications/ 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[http://en.web2test.de/web-testing-knowledgebase/testing-web-applications/|4|]

----

====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.Another elaborate example of cucumber can be found [http://cukes.info/ here.]

----

===Conclusion===

In summary, GUIs have introduced new types of error, increased complexity and made testing more difficult.But with new and sophisticated patterns and tools errors can be detected more proactively as well as regression tests can be executed on the GUIs,thus making GUI testing more reliable.[http://www.testingfaqs.org/t-gui.html Here] is an extensive list of all the GUI testing tools available till date.
----

===References===
[1] http://www.gerrardconsulting.com/GUI/TestGui.html

[2] http://wiki.github.com

[3] http://misko.hevery.com/2008/07/05/testing-ui-part1/

[4] http://en.web2test.de/web-testing-knowledgebase/testing-web-applications/

[5] http://www.testingfaqs.org/t-gui.html

----

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

2009-10-09T20:08:42Z

Akimbo: /* Conclusion */

=='''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 [http://www.testingfaqs.org/t-gui.html|1|].

----

===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.[http://www.testingfaqs.org/t-gui.html|1|]

----

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

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

====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[http://misko.hevery.com/2008/07/05/testing-ui-part1/|3|].

----

====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 " <> ans;
cout << endl;
} while (ans == 'y' || ans == 'Y');
return 0;
}</pre>

----

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

As the name suggests,[http://www.site.uottawa.ca/~awilliam/seg3203/Capture.ppt Capture & Replay tool] captures the user interactions with the system under test.Inputs, outputs, and other information needed to reproduce a session with the system under test need to be recorded during the capture process.It is used mostly for regression testing.Some Java testing frameworks employing this approach are [http://jacareto.sourceforge.net Jacareto] and [http://abbot.sourceforge.net/doc/overview.shtml Abbot].

During the capture process, the tool will register as an event listener.Event notification method for the tool will record the details of all events that occurred.During the replay process, the tool will register as an event source (possibly also as a listener)and compare results.For mouse and keyboard events, the tool has to substitute for the actual devices as the event source.At test checkpoints, the tool can ask various controls for their state and record it, for eg GUI radio button properties.Replay events should be initiated at the same relative time as during the capture.

[[Image:Record.jpg|650px|thumb|center|figure 1:[http://en.web2test.de/web-testing-knowledgebase/testing-web-applications/ 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[http://en.web2test.de/web-testing-knowledgebase/testing-web-applications/|4|]

----

====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.Another elaborate example of cucumber can be found [http://cukes.info/ here.]

----

===Conclusion===

In summary, GUIs have introduced new types of error, increased complexity and made testing more difficult.But with new and sophisticated patterns and tools errors can be detected more proactively as well as regression tests can be executed on the GUIs,thus making GUI testing more reliable.Here is an extensive list of all the GUI testing tools available till date.
----

===References===
[1] http://www.gerrardconsulting.com/GUI/TestGui.html

[2] http://wiki.github.com

[3] http://misko.hevery.com/2008/07/05/testing-ui-part1/

[4] http://en.web2test.de/web-testing-knowledgebase/testing-web-applications/

[5] http://www.testingfaqs.org/t-gui.html

----

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

2009-10-09T19:59:38Z

Akimbo: /* '''GUI TESTING FRAMEWORKS''' */

=='''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 [http://www.testingfaqs.org/t-gui.html|1|].

----

===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.[http://www.testingfaqs.org/t-gui.html|1|]

----

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

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

====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[http://misko.hevery.com/2008/07/05/testing-ui-part1/|3|].

----

====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 " <> ans;
cout << endl;
} while (ans == 'y' || ans == 'Y');
return 0;
}</pre>

----

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

As the name suggests,[http://www.site.uottawa.ca/~awilliam/seg3203/Capture.ppt Capture & Replay tool] captures the user interactions with the system under test.Inputs, outputs, and other information needed to reproduce a session with the system under test need to be recorded during the capture process.It is used mostly for regression testing.Some Java testing frameworks employing this approach are [http://jacareto.sourceforge.net Jacareto] and [http://abbot.sourceforge.net/doc/overview.shtml Abbot].

During the capture process, the tool will register as an event listener.Event notification method for the tool will record the details of all events that occurred.During the replay process, the tool will register as an event source (possibly also as a listener)and compare results.For mouse and keyboard events, the tool has to substitute for the actual devices as the event source.At test checkpoints, the tool can ask various controls for their state and record it, for eg GUI radio button properties.Replay events should be initiated at the same relative time as during the capture.

[[Image:Record.jpg|650px|thumb|center|figure 1:[http://en.web2test.de/web-testing-knowledgebase/testing-web-applications/ 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[http://en.web2test.de/web-testing-knowledgebase/testing-web-applications/|4|]

----

====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.Another elaborate example of cucumber can be found [http://cukes.info/ here.]

----

===Conclusion===

----

===References===
[1] http://www.gerrardconsulting.com/GUI/TestGui.html

[2] http://wiki.github.com

[3] http://misko.hevery.com/2008/07/05/testing-ui-part1/

[4] http://en.web2test.de/web-testing-knowledgebase/testing-web-applications/

[5] http://www.testingfaqs.org/t-gui.html

----

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

2009-10-09T19:59:00Z

Akimbo: /* MVC Design Pattern */

=='''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 [http://www.testingfaqs.org/t-gui.html|1|].

----

===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.[http://www.testingfaqs.org/t-gui.html|1|]

----

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

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

====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[http://misko.hevery.com/2008/07/05/testing-ui-part1/|3|].

----

====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 " <> ans;
cout << endl;
} while (ans == 'y' || ans == 'Y');
return 0;
}</pre>

----

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

As the name suggests,[http://www.site.uottawa.ca/~awilliam/seg3203/Capture.ppt Capture & Replay tool] captures the user interactions with the system under test.Inputs, outputs, and other information needed to reproduce a session with the system under test need to be recorded during the capture process.It is used mostly for regression testing.Some Java testing frameworks employing this approach are [http://jacareto.sourceforge.net Jacareto] and [http://abbot.sourceforge.net/doc/overview.shtml Abbot].

During the capture process, the tool will register as an event listener.Event notification method for the tool will record the details of all events that occurred.During the replay process, the tool will register as an event source (possibly also as a listener)and compare results.For mouse and keyboard events, the tool has to substitute for the actual devices as the event source.At test checkpoints, the tool can ask various controls for their state and record it, for eg GUI radio button properties.Replay events should be initiated at the same relative time as during the capture.

[[Image:Record.jpg|650px|thumb|center|figure 1:[http://en.web2test.de/web-testing-knowledgebase/testing-web-applications/ 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[http://en.web2test.de/web-testing-knowledgebase/testing-web-applications/|4|]

----

====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.Another elaborate example of cucumber can be found [http://cukes.info/ here.]

----

===Conclusion===

----

===References===
[1] http://www.gerrardconsulting.com/GUI/TestGui.html

[2] http://wiki.github.com

[3] http://misko.hevery.com/2008/07/05/testing-ui-part1/

[4] http://en.web2test.de/web-testing-knowledgebase/testing-web-applications/

[5] http://www.testingfaqs.org/t-gui.html

----

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

2009-10-09T19:58:16Z

Akimbo: /* References */

=='''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 [http://www.testingfaqs.org/t-gui.html|1|].

----

===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.[http://www.testingfaqs.org/t-gui.html|1|]

----

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

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

====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 " <> ans;
cout << endl;
} while (ans == 'y' || ans == 'Y');
return 0;
}</pre>

----

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

As the name suggests,[http://www.site.uottawa.ca/~awilliam/seg3203/Capture.ppt Capture & Replay tool] captures the user interactions with the system under test.Inputs, outputs, and other information needed to reproduce a session with the system under test need to be recorded during the capture process.It is used mostly for regression testing.Some Java testing frameworks employing this approach are [http://jacareto.sourceforge.net Jacareto] and [http://abbot.sourceforge.net/doc/overview.shtml Abbot].

During the capture process, the tool will register as an event listener.Event notification method for the tool will record the details of all events that occurred.During the replay process, the tool will register as an event source (possibly also as a listener)and compare results.For mouse and keyboard events, the tool has to substitute for the actual devices as the event source.At test checkpoints, the tool can ask various controls for their state and record it, for eg GUI radio button properties.Replay events should be initiated at the same relative time as during the capture.

[[Image:Record.jpg|650px|thumb|center|figure 1:[http://en.web2test.de/web-testing-knowledgebase/testing-web-applications/ 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[http://en.web2test.de/web-testing-knowledgebase/testing-web-applications/|4|]

----

====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.Another elaborate example of cucumber can be found [http://cukes.info/ here.]

----

===Conclusion===

----

===References===
[1] http://www.gerrardconsulting.com/GUI/TestGui.html

[2] http://wiki.github.com

[3] http://misko.hevery.com/2008/07/05/testing-ui-part1/

[4] http://en.web2test.de/web-testing-knowledgebase/testing-web-applications/

[5] http://www.testingfaqs.org/t-gui.html

----

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

2009-10-09T19:57:00Z

Akimbo: /* Cucumber */

=='''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 [http://www.testingfaqs.org/t-gui.html|1|].

----

===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.[http://www.testingfaqs.org/t-gui.html|1|]

----

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

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

====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 " <> ans;
cout << endl;
} while (ans == 'y' || ans == 'Y');
return 0;
}</pre>

----

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

As the name suggests,[http://www.site.uottawa.ca/~awilliam/seg3203/Capture.ppt Capture & Replay tool] captures the user interactions with the system under test.Inputs, outputs, and other information needed to reproduce a session with the system under test need to be recorded during the capture process.It is used mostly for regression testing.Some Java testing frameworks employing this approach are [http://jacareto.sourceforge.net Jacareto] and [http://abbot.sourceforge.net/doc/overview.shtml Abbot].

During the capture process, the tool will register as an event listener.Event notification method for the tool will record the details of all events that occurred.During the replay process, the tool will register as an event source (possibly also as a listener)and compare results.For mouse and keyboard events, the tool has to substitute for the actual devices as the event source.At test checkpoints, the tool can ask various controls for their state and record it, for eg GUI radio button properties.Replay events should be initiated at the same relative time as during the capture.

[[Image:Record.jpg|650px|thumb|center|figure 1:[http://en.web2test.de/web-testing-knowledgebase/testing-web-applications/ 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[http://en.web2test.de/web-testing-knowledgebase/testing-web-applications/|4|]

----

====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.Another elaborate example of cucumber can be found [http://cukes.info/ here.]

----

===Conclusion===

----

===References===
[1] http://www.gerrardconsulting.com/GUI/TestGui.html

[2] http://wiki.github.com

[3] http://www.slideshare.net/rpires/GUI-Test-Patterns

[4] http://en.web2test.de/web-testing-knowledgebase/testing-web-applications/

[5] http://www.testingfaqs.org/t-gui.html

----

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

2009-10-09T19:54:14Z

Akimbo: /* Capture and Replay Tool */

=='''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 [http://www.testingfaqs.org/t-gui.html|1|].

----

===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.[http://www.testingfaqs.org/t-gui.html|1|]

----

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

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

====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 " <> ans;
cout << endl;
} while (ans == 'y' || ans == 'Y');
return 0;
}</pre>

----

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

As the name suggests,[http://www.site.uottawa.ca/~awilliam/seg3203/Capture.ppt Capture & Replay tool] captures the user interactions with the system under test.Inputs, outputs, and other information needed to reproduce a session with the system under test need to be recorded during the capture process.It is used mostly for regression testing.Some Java testing frameworks employing this approach are [http://jacareto.sourceforge.net Jacareto] and [http://abbot.sourceforge.net/doc/overview.shtml Abbot].

During the capture process, the tool will register as an event listener.Event notification method for the tool will record the details of all events that occurred.During the replay process, the tool will register as an event source (possibly also as a listener)and compare results.For mouse and keyboard events, the tool has to substitute for the actual devices as the event source.At test checkpoints, the tool can ask various controls for their state and record it, for eg GUI radio button properties.Replay events should be initiated at the same relative time as during the capture.

[[Image:Record.jpg|650px|thumb|center|figure 1:[http://en.web2test.de/web-testing-knowledgebase/testing-web-applications/ 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[http://en.web2test.de/web-testing-knowledgebase/testing-web-applications/|4|]

----

====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===
[1] http://www.gerrardconsulting.com/GUI/TestGui.html

[2] http://wiki.github.com

[3] http://www.slideshare.net/rpires/GUI-Test-Patterns

[4] http://en.web2test.de/web-testing-knowledgebase/testing-web-applications/

[5] http://www.testingfaqs.org/t-gui.html

----

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

2009-10-09T19:53:39Z

Akimbo: /* Capture and Replay Tool */

=='''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 [http://www.testingfaqs.org/t-gui.html|1|].

----

===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.[http://www.testingfaqs.org/t-gui.html|1|]

----

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

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

====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 " <> ans;
cout << endl;
} while (ans == 'y' || ans == 'Y');
return 0;
}</pre>

----

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

As the name suggests,[http://www.site.uottawa.ca/~awilliam/seg3203/Capture.ppt Capture & Replay tool] captures the user interactions with the system under test.Inputs, outputs, and other information needed to reproduce a session with the system under test need to be recorded during the capture process.It is used mostly for regression testing.Some Java testing frameworks employing this approach are [http://jacareto.sourceforge.net Jacareto] and [http://abbot.sourceforge.net/doc/overview.shtml Abbot].

During the capture process, the tool will register as an event listener.Event notification method for the tool will record the details of all events that occurred.During the replay process, the tool will register as an event source (possibly also as a listener)and compare results.For mouse and keyboard events, the tool has to substitute for the actual devices as the event source.At test checkpoints, the tool can ask various controls for their state and record it, for eg GUI radio button properties.Replay events should be initiated at the same relative time as during the capture.

[[Image:Record.jpg|650px|thumb|center|http://en.web2test.de/web-testing-knowledgebase/testing-web-applications/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[http://en.web2test.de/web-testing-knowledgebase/testing-web-applications/|4|]

----

====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===
[1] http://www.gerrardconsulting.com/GUI/TestGui.html

[2] http://wiki.github.com

[3] http://www.slideshare.net/rpires/GUI-Test-Patterns

[4] http://en.web2test.de/web-testing-knowledgebase/testing-web-applications/

[5] http://www.testingfaqs.org/t-gui.html

----

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

2009-10-09T19:53:10Z

Akimbo: /* Capture and Replay Tool */

=='''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 [http://www.testingfaqs.org/t-gui.html|1|].

----

===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.[http://www.testingfaqs.org/t-gui.html|1|]

----

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

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

====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 " <> ans;
cout << endl;
} while (ans == 'y' || ans == 'Y');
return 0;
}</pre>

----

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

As the name suggests,[http://www.site.uottawa.ca/~awilliam/seg3203/Capture.ppt Capture & Replay tool] captures the user interactions with the system under test.Inputs, outputs, and other information needed to reproduce a session with the system under test need to be recorded during the capture process.It is used mostly for regression testing.Some Java testing frameworks employing this approach are [http://jacareto.sourceforge.net Jacareto] and [http://abbot.sourceforge.net/doc/overview.shtml Abbot].

During the capture process, the tool will register as an event listener.Event notification method for the tool will record the details of all events that occurred.During the replay process, the tool will register as an event source (possibly also as a listener)and compare results.For mouse and keyboard events, the tool has to substitute for the actual devices as the event source.At test checkpoints, the tool can ask various controls for their state and record it, for eg GUI radio button properties.Replay events should be initiated at the same relative time as during the capture.

[[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[http://en.web2test.de/web-testing-knowledgebase/testing-web-applications/|4|]

----

====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===
[1] http://www.gerrardconsulting.com/GUI/TestGui.html

[2] http://wiki.github.com

[3] http://www.slideshare.net/rpires/GUI-Test-Patterns

[4] http://en.web2test.de/web-testing-knowledgebase/testing-web-applications/

[5] http://www.testingfaqs.org/t-gui.html

----

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

2009-10-09T19:52:15Z

Akimbo: /* Capture and Replay Tool */

=='''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 [http://www.testingfaqs.org/t-gui.html|1|].

----

===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.[http://www.testingfaqs.org/t-gui.html|1|]

----

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

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

====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 " <> ans;
cout << endl;
} while (ans == 'y' || ans == 'Y');
return 0;
}</pre>

----

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

As the name suggests,[http://www.site.uottawa.ca/~awilliam/seg3203/Capture.ppt Capture & Replay tool] captures the user interactions with the system under test.Inputs, outputs, and other information needed to reproduce a session with the system under test need to be recorded during the capture process.It is used mostly for regression testing.Some Java testing frameworks employing this approach are [http://jacareto.sourceforge.net Jacareto] and [http://abbot.sourceforge.net/doc/overview.shtml Abbot].

During the capture process, the tool will register as an event listener.Event notification method for the tool will record the details of all events that occurred.During the replay process, the tool will register as an event source (possibly also as a listener)and compare results.For mouse and keyboard events, the tool has to substitute for the actual devices as the event source.At test checkpoints, the tool can ask various controls for their state and record it, for eg GUI radio button properties.Replay events should be initiated at the same relative time as during the capture.

[[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[http://www.slideshare.net/rpires/GUI-Test-Patterns|4|]

----

====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===
[1] http://www.gerrardconsulting.com/GUI/TestGui.html

[2] http://wiki.github.com

[3] http://www.slideshare.net/rpires/GUI-Test-Patterns

[4] http://en.web2test.de/web-testing-knowledgebase/testing-web-applications/

[5] http://www.testingfaqs.org/t-gui.html

----

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

2009-10-09T19:50:49Z

Akimbo: /* Capture and Replay Tool */

=='''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 [http://www.testingfaqs.org/t-gui.html|1|].

----

===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.[http://www.testingfaqs.org/t-gui.html|1|]

----

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

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

====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 " <> ans;
cout << endl;
} while (ans == 'y' || ans == 'Y');
return 0;
}</pre>

----

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

As the name suggests,[http://www.site.uottawa.ca/~awilliam/seg3203/Capture.ppt Capture & Replay tool] captures the user interactions with the system under test.Inputs, outputs, and other information needed to reproduce a session with the system under test need to be recorded during the capture process.It is used mostly for regression testing.Some Java testing frameworks employing this approach are [http://jacareto.sourceforge.net Jacareto] and [http://abbot.sourceforge.net/doc/overview.shtml Abbot].

During the capture process, the tool will register as an event listener.Event notification method for the tool will record the details of all events that occurred.During the replay process, the tool will register as an event source (possibly also as a listener)and compare results.For mouse and keyboard events, the tool has to substitute for the actual devices as the event source.At test checkpoints, the tool can ask various controls for their state and record it, for eg GUI radio button properties.Replay events should be initiated at the same relative time as during the capture.

[[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[http://www.slideshare.net/rpires/GUI-Test-Patterns|3|]

----

====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===
[1] http://www.gerrardconsulting.com/GUI/TestGui.html

[2] http://wiki.github.com

[3] http://www.slideshare.net/rpires/GUI-Test-Patterns

[4] http://en.web2test.de/web-testing-knowledgebase/testing-web-applications/

[5] http://www.testingfaqs.org/t-gui.html

----

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

2009-10-09T19:49:26Z

Akimbo: /* 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===

[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 [http://www.testingfaqs.org/t-gui.html|1|].

----

===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.[http://www.testingfaqs.org/t-gui.html|1|]

----

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

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

====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 " <> ans;
cout << endl;
} while (ans == 'y' || ans == 'Y');
return 0;
}</pre>

----

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

As the name suggests,[http://www.site.uottawa.ca/~awilliam/seg3203/Capture.ppt Capture & Replay tool] captures the user interactions with the system under test.Inputs, outputs, and other information needed to reproduce a session with the system under test need to be recorded during the capture process.It is used mostly for regression testing.Some Java testing frameworks employing this approach are [http://jacareto.sourceforge.net Jacareto] and [http://abbot.sourceforge.net/doc/overview.shtml Abbot].

During the capture process, the tool will register as an event listener.Event notification method for the tool will record the details of all events that occurred.During the replay process, the tool will register as an event source (possibly also as a listener)and compare results.For mouse and keyboard events, the tool has to substitute for the actual devices as the event source.At test checkpoints, the tool can ask various controls for their state and record it, for eg GUI radio button properties.Replay events should be initiated at the same relative time as during the capture.

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

----

====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===
[1] http://www.gerrardconsulting.com/GUI/TestGui.html

[2] http://wiki.github.com

[3] http://www.slideshare.net/rpires/GUI-Test-Patterns

[4] http://en.web2test.de/web-testing-knowledgebase/testing-web-applications/

[5] http://www.testingfaqs.org/t-gui.html

----

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

2009-10-09T19:49:00Z

Akimbo: /* 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 [http://www.testingfaqs.org/t-gui.html|1|].

----

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

====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 " <> ans;
cout << endl;
} while (ans == 'y' || ans == 'Y');
return 0;
}</pre>

----

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

As the name suggests,[http://www.site.uottawa.ca/~awilliam/seg3203/Capture.ppt Capture & Replay tool] captures the user interactions with the system under test.Inputs, outputs, and other information needed to reproduce a session with the system under test need to be recorded during the capture process.It is used mostly for regression testing.Some Java testing frameworks employing this approach are [http://jacareto.sourceforge.net Jacareto] and [http://abbot.sourceforge.net/doc/overview.shtml Abbot].

During the capture process, the tool will register as an event listener.Event notification method for the tool will record the details of all events that occurred.During the replay process, the tool will register as an event source (possibly also as a listener)and compare results.For mouse and keyboard events, the tool has to substitute for the actual devices as the event source.At test checkpoints, the tool can ask various controls for their state and record it, for eg GUI radio button properties.Replay events should be initiated at the same relative time as during the capture.

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

----

====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===
[1] http://www.gerrardconsulting.com/GUI/TestGui.html

[2] http://wiki.github.com

[3] http://www.slideshare.net/rpires/GUI-Test-Patterns

[4] http://en.web2test.de/web-testing-knowledgebase/testing-web-applications/

[5] http://www.testingfaqs.org/t-gui.html

----

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

2009-10-09T19:44:11Z

Akimbo: /* References */

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

====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 " <> ans;
cout << endl;
} while (ans == 'y' || ans == 'Y');
return 0;
}</pre>

----

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

As the name suggests,[http://www.site.uottawa.ca/~awilliam/seg3203/Capture.ppt Capture & Replay tool] captures the user interactions with the system under test.Inputs, outputs, and other information needed to reproduce a session with the system under test need to be recorded during the capture process.It is used mostly for regression testing.Some Java testing frameworks employing this approach are [http://jacareto.sourceforge.net Jacareto] and [http://abbot.sourceforge.net/doc/overview.shtml Abbot].

During the capture process, the tool will register as an event listener.Event notification method for the tool will record the details of all events that occurred.During the replay process, the tool will register as an event source (possibly also as a listener)and compare results.For mouse and keyboard events, the tool has to substitute for the actual devices as the event source.At test checkpoints, the tool can ask various controls for their state and record it, for eg GUI radio button properties.Replay events should be initiated at the same relative time as during the capture.

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

----

====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===
[1] http://www.gerrardconsulting.com/GUI/TestGui.html

[2] http://wiki.github.com

[3] http://www.slideshare.net/rpires/GUI-Test-Patterns

[4] http://en.web2test.de/web-testing-knowledgebase/testing-web-applications/

[5] http://www.testingfaqs.org/t-gui.html

----

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

2009-10-09T19:36:49Z

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

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

====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 " <> ans;
cout << endl;
} while (ans == 'y' || ans == 'Y');
return 0;
}</pre>

----

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

As the name suggests,[http://www.site.uottawa.ca/~awilliam/seg3203/Capture.ppt Capture & Replay tool] captures the user interactions with the system under test.Inputs, outputs, and other information needed to reproduce a session with the system under test need to be recorded during the capture process.It is used mostly for regression testing.Some Java testing frameworks employing this approach are [http://jacareto.sourceforge.net Jacareto] and [http://abbot.sourceforge.net/doc/overview.shtml Abbot].

During the capture process, the tool will register as an event listener.Event notification method for the tool will record the details of all events that occurred.During the replay process, the tool will register as an event source (possibly also as a listener)and compare results.For mouse and keyboard events, the tool has to substitute for the actual devices as the event source.At test checkpoints, the tool can ask various controls for their state and record it, for eg GUI radio button properties.Replay events should be initiated at the same relative time as during the capture.

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

----

====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:36:28Z

Akimbo: /* 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:

====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 " <> ans;
cout << endl;
} while (ans == 'y' || ans == 'Y');
return 0;
}</pre>

----

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

As the name suggests,[http://www.site.uottawa.ca/~awilliam/seg3203/Capture.ppt Capture & Replay tool] captures the user interactions with the system under test.Inputs, outputs, and other information needed to reproduce a session with the system under test need to be recorded during the capture process.It is used mostly for regression testing.Some Java testing frameworks employing this approach are [http://jacareto.sourceforge.net Jacareto] and [http://abbot.sourceforge.net/doc/overview.shtml Abbot].

During the capture process, the tool will register as an event listener.Event notification method for the tool will record the details of all events that occurred.During the replay process, the tool will register as an event source (possibly also as a listener)and compare results.For mouse and keyboard events, the tool has to substitute for the actual devices as the event source.At test checkpoints, the tool can ask various controls for their state and record it, for eg GUI radio button properties.Replay events should be initiated at the same relative time as during the capture.

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

----

====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:36:07Z

Akimbo: /* 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===

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

====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 " <> ans;
cout << endl;
} while (ans == 'y' || ans == 'Y');
return 0;
}</pre>

----

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

As the name suggests,[http://www.site.uottawa.ca/~awilliam/seg3203/Capture.ppt Capture & Replay tool] captures the user interactions with the system under test.Inputs, outputs, and other information needed to reproduce a session with the system under test need to be recorded during the capture process.It is used mostly for regression testing.Some Java testing frameworks employing this approach are [http://jacareto.sourceforge.net Jacareto] and [http://abbot.sourceforge.net/doc/overview.shtml Abbot].

During the capture process, the tool will register as an event listener.Event notification method for the tool will record the details of all events that occurred.During the replay process, the tool will register as an event source (possibly also as a listener)and compare results.For mouse and keyboard events, the tool has to substitute for the actual devices as the event source.At test checkpoints, the tool can ask various controls for their state and record it, for eg GUI radio button properties.Replay events should be initiated at the same relative time as during the capture.

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

----

====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:34:44Z

Akimbo: /* Capture and Replay Tool */

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

====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 " <> ans;
cout << endl;
} while (ans == 'y' || ans == 'Y');
return 0;
}</pre>

----

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

As the name suggests,[http://www.site.uottawa.ca/~awilliam/seg3203/Capture.ppt Capture & Replay tool] captures the user interactions with the system under test.Inputs, outputs, and other information needed to reproduce a session with the system under test need to be recorded during the capture process.It is used mostly for regression testing.Some Java testing frameworks employing this approach are [http://jacareto.sourceforge.net Jacareto] and [http://abbot.sourceforge.net/doc/overview.shtml Abbot].

During the capture process, the tool will register as an event listener.Event notification method for the tool will record the details of all events that occurred.During the replay process, the tool will register as an event source (possibly also as a listener)and compare results.For mouse and keyboard events, the tool has to substitute for the actual devices as the event source.At test checkpoints, the tool can ask various controls for their state and record it, for eg GUI radio button properties.Replay events should be initiated at the same relative time as during the capture.

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

----

====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:34:24Z

Akimbo: /* Capture and Replay Tool */

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

As the name suggests,[http://www.site.uottawa.ca/~awilliam/seg3203/Capture.ppt Capture & Replay tool] captures the user interactions with the system under test.Inputs, outputs, and other information needed to reproduce a session with the system under test need to be recorded during the capture process.It is used mostly for regression testing.Some Java testing frameworks employing this approach are [http://jacareto.sourceforge.net Jacareto] and [http://abbot.sourceforge.net/doc/overview.shtml Abbot].

During the capture process, the tool will register as an event listener.Event notification method for the tool will record the details of all events that occurred.During the replay process, the tool will register as an event source (possibly also as a listener)and compare results.For mouse and keyboard events, the tool has to substitute for the actual devices as the event source.At test checkpoints, the tool can ask various controls for their state and record it, for eg GUI radio button properties.Replay events should be initiated at the same relative time as during the capture.

[[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 " <> ans;
cout << endl;
} while (ans == 'y' || ans == 'Y');
return 0;
}</pre>

----

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

As the name suggests,[http://www.site.uottawa.ca/~awilliam/seg3203/Capture.ppt Capture & Replay tool] captures the user interactions with the system under test.Inputs, outputs, and other information needed to reproduce a session with the system under test need to be recorded during the capture process.It is used mostly for regression testing.Some Java testing frameworks employing this approach are [http://jacareto.sourceforge.net Jacareto] and [http://abbot.sourceforge.net/doc/overview.shtml Abbot].

During the capture process, the tool will register as an event listener.Event notification method for the tool will record the details of all events that occurred.During the replay process, the tool will register as an event source (possibly also as a listener)and compare results.For mouse and keyboard events, the tool has to substitute for the actual devices as the event source.At test checkpoints, the tool can ask various controls for their state and record it, for eg GUI radio button properties.Replay events should be initiated at the same relative time as during the capture.

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

----

====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:32:45Z

Akimbo: /* References */

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

As the name suggests,[http://www.site.uottawa.ca/~awilliam/seg3203/Capture.ppt Capture & Replay tool] captures the user interactions with the system under test.Inputs, outputs, and other information needed to reproduce a session with the system under test need to be recorded during the capture process.It is used mostly for regression testing.Some Java testing frameworks employing this approach are [http://jacareto.sourceforge.net Jacareto] and [http://abbot.sourceforge.net/doc/overview.shtml Abbot].

During the capture process, the tool will register as an event listener.Event notification method for the tool will record the details of all events that occurred.During the replay process, the tool will register as an event source (possibly also as a listener)and compare results.For mouse and keyboard events, the tool has to substitute for the actual devices as the event source.At test checkpoints, the tool can ask various controls for their state and record it, for eg GUI radio button properties.Replay events should be initiated at the same relative time as during the capture.

[[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 " <> 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:30:22Z

Akimbo: /* Capture and Replay Tool */

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

As the name suggests,[http://www.site.uottawa.ca/~awilliam/seg3203/Capture.ppt Capture & Replay tool] captures the user interactions with the system under test.Inputs, outputs, and other information needed to reproduce a session with the system under test need to be recorded during the capture process.It is used mostly for regression testing.Some Java testing frameworks employing this approach are [http://jacareto.sourceforge.net Jacareto] and [http://abbot.sourceforge.net/doc/overview.shtml Abbot].

During the capture process, the tool will register as an event listener.Event notification method for the tool will record the details of all events that occurred.During the replay process, the tool will register as an event source (possibly also as a listener)and compare results.For mouse and keyboard events, the tool has to substitute for the actual devices as the event source.At test checkpoints, the tool can ask various controls for their state and record it, for eg GUI radio button properties.Replay events should be initiated at the same relative time as during the capture.

[[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 " <> 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:27:00Z

Akimbo: /* Capture and Replay Tool */

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

As the name suggests,[http://www.site.uottawa.ca/~awilliam/seg3203/Capture.ppt Capture & Replay tool] captures the user interactions with the system under test.Inputs, outputs, and other information needed to reproduce a session with the system under test need to be recorded during the capture process.

During the capture process, the tool will register as an event listener.Event notification method for the tool will record the details of all events that occurred.During the replay process, the tool will register as an event source (possibly also as a listener)and compare results.For mouse and keyboard events, the tool has to substitute for the actual devices as the event source.At test checkpoints, the tool can ask various controls for their state and record it, for eg GUI radio button properties.Replay events should be initiated at the same relative time as during the capture.

[[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 " <> 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:16:25Z

Akimbo: /* Capture and Replay Tool */

=='''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,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 " <> 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:14:20Z

Akimbo: /* Capture and Replay Approach */

=='''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,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 " <> 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:13:15Z

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

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

In this approach, as the name suggests,in [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 " <> 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:03:14Z

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

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

----

===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 " <> 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:02:37Z

Akimbo: /* Introduction */

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

----

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

[[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 " <> 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:01:28Z

Akimbo: /* Introduction */

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

----

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

[[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 " <> 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:58:56Z

Akimbo: /* GUI Testing Difficulties */

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

----

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

[[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 " <> 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:55:54Z

Akimbo: /* GUI Testing Difficulties */

=='''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.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.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 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 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.
#Unsilicited 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 needs 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.

----

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

[[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 " <> 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:45:27Z

Akimbo: /* GUI Testing Difficulties */

=='''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.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.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 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 GUI Testing.
----

===GUI Testing Difficulties===

GUI testing is comparatively difficult because of the following reasons:

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

----

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

[[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 " <> 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:44:40Z

Akimbo: /* GUI Testing Difficulties */

=='''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.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.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 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 GUI Testing.
----

===GUI Testing Difficulties===
GUI testing is comparatively difficult because of the following reasons-

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

----

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

[[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 " <> 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:42:12Z

Akimbo: /* MVC Design Pattern */

=='''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.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.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 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 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 of the following reasons-

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

----

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

[[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 " <> 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:40:37Z

Akimbo: /* GUI Testing Difficulties */

=='''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.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.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 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 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 of the following reasons-

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

----

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

[[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 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 " <> 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:37:01Z

Akimbo: /* Capture and Replay Tool */

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

[[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 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 " <> 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:36:27Z

Akimbo: /* Capture and Replay Tool */

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

[[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 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 " <> 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:35:22Z

Akimbo: /* Capture and Replay Tool */

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

[[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 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 " <> 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:33:40Z

Akimbo: /* Capture and Replay Tool */

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

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

----

File:Record.jpg

2009-10-09T18:31:41Z

Akimbo:

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

2009-10-09T18:25:54Z

Akimbo: /* 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.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.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 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 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 [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 " <> 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:21:35Z

Akimbo: /* Test Stubs and Drivers */

=='''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 [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 " <> 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:17:12Z

Akimbo: /* Test Stubs and Drivers */

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

====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 " <> 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:15:32Z

Akimbo: /* Test Stubs and Drivers */

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

====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 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 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 " <> 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:15:05Z

Akimbo: /* Test Stubs and Drivers */

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

====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 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 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 " <> 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:08:31Z

Akimbo: /* Test Stub */

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

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

First, a test-specific implementation of an interface on which the System under testing(SUT) depends is defined. This implementation is configured to respond to calls from the SUT with the values (or exceptions) that will exercise the Untested Code within the SUT. Before exercising the SUT, we install the Test Stub so that the SUT uses it instead of the real implementation. When called by the SUT during test execution, the Test Stub returns the previously defined values. The test can then verify the expected outcome in the normal way.

----

====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-09T17:55:41Z

Akimbo: /* Test Stub */

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

====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 Stub====
A test stub is a dummy software component or object used (during development and testing) to simulate the behavior of a real component. More specifically it is programs which simulates the behavior of software components (or modules) that are the dependent modules of a under test module. It is a pattern used for testing interfaces in an application if the real components have not been implemented or are too expensive to use for testing.

<pre>A pattern is a recurring solution to a recurring problem in a context.</pre>

First, a test-specific implementation of an interface on which the System under testing(SUT) depends is defined. This implementation is configured to respond to calls from the SUT with the values (or exceptions) that will exercise the Untested Code within the SUT. Before exercising the SUT, we install the Test Stub so that the SUT uses it instead of the real implementation. When called by the SUT during test execution, the Test Stub returns the previously defined values. The test can then verify the expected outcome in the normal way.

----

====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-09T17:43:30Z

Akimbo: /* Test Stubs */

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

====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 Stub====
A test stub is a dummy software component or object used (during development and testing) to simulate the behavior of a real component. It is a pattern used for testing interfaces in an application if the real components have not been implemented or are too expensive to use for testing.

<pre>A pattern is a recurring solution to a recurring problem in a context.</pre>

First, a test-specific implementation of an interface on which the System under testing(SUT) depends is defined. This implementation is configured to respond to calls from the SUT with the values (or exceptions) that will exercise the Untested Code within the SUT. Before exercising the SUT, we install the Test Stub so that the SUT uses it instead of the real implementation. When called by the SUT during test execution, the Test Stub returns the previously defined values. The test can then verify the expected outcome in the normal way.

----

====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:52:17Z

Akimbo: /* Cucumber */

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

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

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

----