Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2009/wiki3 5 rm

2009-11-19T01:39:11Z

Sniper: /* References */

=Dependency Inversion policy=

==Introduction==
The Dependency Inversion Principle has been proposed by Robert C. Martin. It states that:

''"High level modules should not depend upon low level modules. Both should depend upon abstractions. Abstractions should not depend upon details. Details should depend upon abstractions."''

The principle is reverse the conventional philosophy of high level functions in softwares need to depend on the low level functions.
The principle states that high level or low level modules should not depend upon each other, instead they should depend upon abstractions. Further it also states that these abstractions should not depend on the details and inversely the details should depend on the abstractions.
According to this principle the way of designing a class structure is to start from high level modules to the low level modules:

'''High Level Classes → Abstraction Layer → Low Level Classes'''

==Overview==
The Dependency Inversion Principle is defined as follows:

#High-level modules should not depend upon low-level modules. Both should depend upon abstractions.
#Abstractions should not depend upon details. Details should depend upon abstractions.

The problem with the conventional design architecture is that the higher level components depends on the lower level components. This can be understood from the diagram below.
[[Image:wiki3_5_rm1.png|450px|thumb|center|Figure 1: Higher-level components depend upon lower-level components]]

From the above diagram we see that the component A depends on component B, which in turn depends on component C. These dependencies make the higher level modules or components more complex and inflexible. This also leads to tight coupling of higher and lower level components. Thus reducing the over all flexibility of the system.

The primary motive of the ''dependency inversion principle'' is to decouple the high level components from their dependency on the low level components of the system. This can be obtained by creating interfaces as a part of the higher level component package which define the components for the extra functionality required. This protects the component from depending on any specific implementation of the provided interface/functionality. Thus making the given function more portable.
The above example can be restructured as follows

[[Image:wiki3_5_rm2.png|450px|thumb|center|Figure 2: Relationship diagram]]
As one can see in the above figure the component B doesn't depend on A but rather depends on the interface that is also used by A. The same relationship is additionally shown between components B and C. Take special note that the interfaces are packaged together with the higher-level components and are defined in terms of the higher-level component’s needs, not the lower-level component’s behavior. It is this association of the interface with the client component which logically inverts the conventional dependency flow.

==Example of Dependency inversion principle==
// Dependency Inversion Principle - Bad example
class Worker {
public void work() {
// ....working
}
}
class Manager {
Worker m_worker;
public void setWorker(Worker w) {
m_worker=w;
}
public void manage() {
m_worker.work();
}
}
class SuperWorker {
public void work() {
//.... working much more
}
}

The code shown below implements the code above using Dependency Inversion principle.This helps us in solving the following problems.
#Manager class should not be changed.
#Minimized risk to affect old funtionallity present in Manager class.
#No need to redone the unit testing for Manager class.

// Dependency Inversion Principle - Good example
interface IWorker {
public void work();
}
class Worker implements IWorker{
public void work() {
// ....working
}
}
class SuperWorker implements IWorker{
public void work() {
//.... working much more
}
}
class Manager {
IWorker m_worker;
public void setWorker(IWorker w) {
m_worker=w;
}
public void manage() {
m_worker.work();
}
}

==A design pattern based on dependency inversion policy (Template design pattern)==
The Template Design pattern implements the Dependency Inversion Principle by setting up the outline or skeleton of an algorithm, leaving the details to be implemented by the classes or modules implementing it. This way, the sub classes will be getting there information from the abstract classes. Further these abstract classes are not dependent on the details while the vice versa is true. The UML diagram below gives you better understanding of the Template design pattern. There are method calls to operation1() and operation2(). The definition of these methods are defined in the subclass which override them.
[[Image:wiki3_5_rm3.png|450px|thumb|center|Figure 3: Template Design Pattern]]

==Why call it dependency inversion policy?==

The dependency structure of a well designed object oriented application is "inverted" with respect to the dependency structure that normally results from a "traditional" application which is implemented in a more procedural style. In a procedural application high level modules depend upon low level modules and abstractions depend upon details.

Consider the implications of high level modules that depend upon low level modules. It is the high level modules that contain the important policy decisions and business models of an application. It is these models that contain the identity of the application. Yet, when these modules depend upon the lower level modules, then changes to the lower level modules can have direct effects upon them; and can force them to change.
It is the high level modules that ought to be forcing the low level modules to change. It is the high level modules that should take precedence over the lower level modules. High level modules simply should not depend upon low level modules in any way. Moreover, it is high level modules that we want to be able to reuse. When high level modules depend upon low level modules, it becomes very difficult to reuse those high level modules in different contexts. However, when the high level modules are independent of the low level modules, then the high level modules can be reused quite simply.

==Benefits and Consequences==
Dependency Inversion Principle proposes a useful mechanism in decoupling the dependencies between the high and low level components of the system. This not only makes sure that the high level components don't directly depend on the low level components, it also makes sure that the core functionality with n the application can be more easily reused in other contexts.Applying Dependency Inversion Principle makes it easier for reusing the higher level components, but the negative aspect of this is that it prevents the reuse of low level components. Further Dependency Inversion Principle does account for the reuse of lower-level components by maintaining the client interface in a separate package, assigning ownership of this package to one or more consumers of a lower-level component can itself be problematic.

==Conclusion==
This principle is applied to make sure that the high level classes are not directly dependent on the low level classes, they are doing that using either by interfaces or abstract classes.In that case the creation of new low level objects inside the high level classes(if necessary) can not be done using the operator new. Instead, some of the Creational design patterns can be used, such as Factory Method, Abstract Factory, Prototype.
Of course, using this principle implies an increased effort and a more complex code, but more flexible. This principle can not be applied for every class or every module. If we have a class functionality that is more likely to remain unchanged in the future there is not need to apply this principle.When a component does not depend on lower level components directly but only through abstractions this component is mobile that is, the component is reusable in many different contexts.

=References=

[1] http://www.objectmentor.com/resources/articles/dip.pdf 
[2] http://www.ctrl-shift-b.com/2008/12/examining-dependency-inversion.html 
[3] http://blogs.imeta.co.uk/jyoung/archive/2008/12/17/540.aspx 
[4] http://en.wikipedia.org/wiki/Dependency_inversion_principle 
[5] http://www.lostechies.com/blogs/gabrielschenker/archive/2009/01/30/the-dependency-inversion-principle.aspx 
[6] http://www.oodesign.com/dependency-inversion-principle.html 
[7] http://www.eventhelix.com/realtimemantra/Object_Oriented/dependency_inversion_principle.htm 
[8] http://davidhayden.com/blog/dave/archive/2005/06/10/1261.aspx 
[9] http://doodleproject.sourceforge.net/articles/2001/dependencyInversionPrinciple.html 
[10] http://stackoverflow.com/questions/62539/what-is-the-dependency-inversion-principle-and-why-is-it-important 
[11] http://www.surfscranton.com/architecture/DIPandOCP/img0.html 
[12] http://iface.wordpress.com/2006/03/16/dependency-inversion-principle-and-interface/ 
[13] http://www.exciton.cs.rice.edu/JavaResources/DesignPatterns/TemplatePattern.htm 
[14] Martin, R. C. (1996, May). The Dependency Inversion Principle. C++ Report.

CSC/ECE 517 Fall 2009/wiki3 5 rm

2009-11-19T01:38:59Z

Sniper: /* References */

CSC/ECE 517 Fall 2009/wiki3 5 rm

2009-11-19T01:38:22Z

Sniper: /* Conclusion */

CSC/ECE 517 Fall 2009/wiki3 5 rm

2009-11-19T01:38:09Z

Sniper: /* Conclusion */

=Dependency Inversion policy=

==Introduction==
The Dependency Inversion Principle has been proposed by Robert C. Martin. It states that:

''"High level modules should not depend upon low level modules. Both should depend upon abstractions. Abstractions should not depend upon details. Details should depend upon abstractions."''

The principle is reverse the conventional philosophy of high level functions in softwares need to depend on the low level functions.
The principle states that high level or low level modules should not depend upon each other, instead they should depend upon abstractions. Further it also states that these abstractions should not depend on the details and inversely the details should depend on the abstractions.
According to this principle the way of designing a class structure is to start from high level modules to the low level modules:

'''High Level Classes → Abstraction Layer → Low Level Classes'''

==Overview==
The Dependency Inversion Principle is defined as follows:

#High-level modules should not depend upon low-level modules. Both should depend upon abstractions.
#Abstractions should not depend upon details. Details should depend upon abstractions.

The problem with the conventional design architecture is that the higher level components depends on the lower level components. This can be understood from the diagram below.
[[Image:wiki3_5_rm1.png|450px|thumb|center|Figure 1: Higher-level components depend upon lower-level components]]

From the above diagram we see that the component A depends on component B, which in turn depends on component C. These dependencies make the higher level modules or components more complex and inflexible. This also leads to tight coupling of higher and lower level components. Thus reducing the over all flexibility of the system.

The primary motive of the ''dependency inversion principle'' is to decouple the high level components from their dependency on the low level components of the system. This can be obtained by creating interfaces as a part of the higher level component package which define the components for the extra functionality required. This protects the component from depending on any specific implementation of the provided interface/functionality. Thus making the given function more portable.
The above example can be restructured as follows

[[Image:wiki3_5_rm2.png|450px|thumb|center|Figure 2: Relationship diagram]]
As one can see in the above figure the component B doesn't depend on A but rather depends on the interface that is also used by A. The same relationship is additionally shown between components B and C. Take special note that the interfaces are packaged together with the higher-level components and are defined in terms of the higher-level component’s needs, not the lower-level component’s behavior. It is this association of the interface with the client component which logically inverts the conventional dependency flow.

==Example of Dependency inversion principle==
// Dependency Inversion Principle - Bad example
class Worker {
public void work() {
// ....working
}
}
class Manager {
Worker m_worker;
public void setWorker(Worker w) {
m_worker=w;
}
public void manage() {
m_worker.work();
}
}
class SuperWorker {
public void work() {
//.... working much more
}
}

The code shown below implements the code above using Dependency Inversion principle.This helps us in solving the following problems.
#Manager class should not be changed.
#Minimized risk to affect old funtionallity present in Manager class.
#No need to redone the unit testing for Manager class.

// Dependency Inversion Principle - Good example
interface IWorker {
public void work();
}
class Worker implements IWorker{
public void work() {
// ....working
}
}
class SuperWorker implements IWorker{
public void work() {
//.... working much more
}
}
class Manager {
IWorker m_worker;
public void setWorker(IWorker w) {
m_worker=w;
}
public void manage() {
m_worker.work();
}
}

==A design pattern based on dependency inversion policy (Template design pattern)==
The Template Design pattern implements the Dependency Inversion Principle by setting up the outline or skeleton of an algorithm, leaving the details to be implemented by the classes or modules implementing it. This way, the sub classes will be getting there information from the abstract classes. Further these abstract classes are not dependent on the details while the vice versa is true. The UML diagram below gives you better understanding of the Template design pattern. There are method calls to operation1() and operation2(). The definition of these methods are defined in the subclass which override them.
[[Image:wiki3_5_rm3.png|450px|thumb|center|Figure 3: Template Design Pattern]]

==Why call it dependency inversion policy?==

The dependency structure of a well designed object oriented application is "inverted" with respect to the dependency structure that normally results from a "traditional" application which is implemented in a more procedural style. In a procedural application high level modules depend upon low level modules and abstractions depend upon details.

Consider the implications of high level modules that depend upon low level modules. It is the high level modules that contain the important policy decisions and business models of an application. It is these models that contain the identity of the application. Yet, when these modules depend upon the lower level modules, then changes to the lower level modules can have direct effects upon them; and can force them to change.
It is the high level modules that ought to be forcing the low level modules to change. It is the high level modules that should take precedence over the lower level modules. High level modules simply should not depend upon low level modules in any way. Moreover, it is high level modules that we want to be able to reuse. When high level modules depend upon low level modules, it becomes very difficult to reuse those high level modules in different contexts. However, when the high level modules are independent of the low level modules, then the high level modules can be reused quite simply.

==Benefits and Consequences==
Dependency Inversion Principle proposes a useful mechanism in decoupling the dependencies between the high and low level components of the system. This not only makes sure that the high level components don't directly depend on the low level components, it also makes sure that the core functionality with n the application can be more easily reused in other contexts.Applying Dependency Inversion Principle makes it easier for reusing the higher level components, but the negative aspect of this is that it prevents the reuse of low level components. Further Dependency Inversion Principle does account for the reuse of lower-level components by maintaining the client interface in a separate package, assigning ownership of this package to one or more consumers of a lower-level component can itself be problematic.

==Conclusion==
This principle is applied to make sure that the high level classes are not directly dependent on the low level classes, they are doing that using either by interfaces or abstract classes.In that case the creation of new low level objects inside the high level classes(if necessary) can not be done using the operator new. Instead, some of the Creational design patterns can be used, such as Factory Method, Abstract Factory, Prototype.
Of course, using this principle implies an increased effort and a more complex code, but more flexible. This principle can not be applied for every class or every module. If we have a class functionality that is more likely to remain unchanged in the future there is not need to apply this principle.When a component does not depend on lower level components directly but only through abstractions this component is mobile that is, the component is reusable in many different contexts.

This is the conclusion

=References=

[1] http://www.objectmentor.com/resources/articles/dip.pdf 
[2] http://www.ctrl-shift-b.com/2008/12/examining-dependency-inversion.html 
[3] http://blogs.imeta.co.uk/jyoung/archive/2008/12/17/540.aspx 
[4] http://en.wikipedia.org/wiki/Dependency_inversion_principle 
[5] http://www.lostechies.com/blogs/gabrielschenker/archive/2009/01/30/the-dependency-inversion-principle.aspx 
[6] http://www.oodesign.com/dependency-inversion-principle.html 
[7] http://www.eventhelix.com/realtimemantra/Object_Oriented/dependency_inversion_principle.htm 
[8] http://davidhayden.com/blog/dave/archive/2005/06/10/1261.aspx 
[9] http://doodleproject.sourceforge.net/articles/2001/dependencyInversionPrinciple.html 
[10] http://stackoverflow.com/questions/62539/what-is-the-dependency-inversion-principle-and-why-is-it-important 
[11] http://www.surfscranton.com/architecture/DIPandOCP/img0.html 
[12] http://iface.wordpress.com/2006/03/16/dependency-inversion-principle-and-interface/ 
[13] http://www.exciton.cs.rice.edu/JavaResources/DesignPatterns/TemplatePattern.htm 
[14] Martin, R. C. (1996, May). The Dependency Inversion Principle. C++ Report.

CSC/ECE 517 Fall 2009/wiki3 5 rm

2009-11-19T01:37:53Z

Sniper: /* Why call it dependency inversion policy? */

CSC/ECE 517 Fall 2009/wiki3 5 rm

2009-11-19T01:37:39Z

Sniper: /* Why call it dependency inversion policy? */

=Dependency Inversion policy=

==Introduction==
The Dependency Inversion Principle has been proposed by Robert C. Martin. It states that:

''"High level modules should not depend upon low level modules. Both should depend upon abstractions. Abstractions should not depend upon details. Details should depend upon abstractions."''

The principle is reverse the conventional philosophy of high level functions in softwares need to depend on the low level functions.
The principle states that high level or low level modules should not depend upon each other, instead they should depend upon abstractions. Further it also states that these abstractions should not depend on the details and inversely the details should depend on the abstractions.
According to this principle the way of designing a class structure is to start from high level modules to the low level modules:

'''High Level Classes → Abstraction Layer → Low Level Classes'''

==Overview==
The Dependency Inversion Principle is defined as follows:

#High-level modules should not depend upon low-level modules. Both should depend upon abstractions.
#Abstractions should not depend upon details. Details should depend upon abstractions.

The problem with the conventional design architecture is that the higher level components depends on the lower level components. This can be understood from the diagram below.
[[Image:wiki3_5_rm1.png|450px|thumb|center|Figure 1: Higher-level components depend upon lower-level components]]

From the above diagram we see that the component A depends on component B, which in turn depends on component C. These dependencies make the higher level modules or components more complex and inflexible. This also leads to tight coupling of higher and lower level components. Thus reducing the over all flexibility of the system.

The primary motive of the ''dependency inversion principle'' is to decouple the high level components from their dependency on the low level components of the system. This can be obtained by creating interfaces as a part of the higher level component package which define the components for the extra functionality required. This protects the component from depending on any specific implementation of the provided interface/functionality. Thus making the given function more portable.
The above example can be restructured as follows

[[Image:wiki3_5_rm2.png|450px|thumb|center|Figure 2: Relationship diagram]]
As one can see in the above figure the component B doesn't depend on A but rather depends on the interface that is also used by A. The same relationship is additionally shown between components B and C. Take special note that the interfaces are packaged together with the higher-level components and are defined in terms of the higher-level component’s needs, not the lower-level component’s behavior. It is this association of the interface with the client component which logically inverts the conventional dependency flow.

==Example of Dependency inversion principle==
// Dependency Inversion Principle - Bad example
class Worker {
public void work() {
// ....working
}
}
class Manager {
Worker m_worker;
public void setWorker(Worker w) {
m_worker=w;
}
public void manage() {
m_worker.work();
}
}
class SuperWorker {
public void work() {
//.... working much more
}
}

The code shown below implements the code above using Dependency Inversion principle.This helps us in solving the following problems.
#Manager class should not be changed.
#Minimized risk to affect old funtionallity present in Manager class.
#No need to redone the unit testing for Manager class.

// Dependency Inversion Principle - Good example
interface IWorker {
public void work();
}
class Worker implements IWorker{
public void work() {
// ....working
}
}
class SuperWorker implements IWorker{
public void work() {
//.... working much more
}
}
class Manager {
IWorker m_worker;
public void setWorker(IWorker w) {
m_worker=w;
}
public void manage() {
m_worker.work();
}
}

==A design pattern based on dependency inversion policy (Template design pattern)==
The Template Design pattern implements the Dependency Inversion Principle by setting up the outline or skeleton of an algorithm, leaving the details to be implemented by the classes or modules implementing it. This way, the sub classes will be getting there information from the abstract classes. Further these abstract classes are not dependent on the details while the vice versa is true. The UML diagram below gives you better understanding of the Template design pattern. There are method calls to operation1() and operation2(). The definition of these methods are defined in the subclass which override them.
[[Image:wiki3_5_rm3.png|450px|thumb|center|Figure 3: Template Design Pattern]]

==Why call it dependency inversion policy?==

The dependency structure of a well designed object oriented application is "inverted" with respect to the dependency structure that normally results from a "traditional" application which is implemented in a more procedural style. In a procedural application high level modules depend upon low level modules and abstractions depend upon details.

Consider the implications of high level modules that depend upon low level modules. It is the high level modules that contain the important policy decisions and business models of an application. It is these models that contain the identity of the application. Yet, when these modules depend upon the lower level modules, then changes to the lower level modules can have direct effects upon them; and can force them to change.
It is the high level modules that ought to be forcing the low level modules to change. It is the high level modules that should take precedence over the lower level modules. High level modules simply should not depend upon low level modules in any way. Moreover, it is high level modules that we want to be able to reuse. When high level modules depend upon low level modules, it becomes very difficult to reuse those high level modules in different contexts. However, when the high level modules are independent of the low level modules, then the high level modules can be reused quite simply.

OMG OMG

==Benefits and Consequences==
Dependency Inversion Principle proposes a useful mechanism in decoupling the dependencies between the high and low level components of the system. This not only makes sure that the high level components don't directly depend on the low level components, it also makes sure that the core functionality with n the application can be more easily reused in other contexts.Applying Dependency Inversion Principle makes it easier for reusing the higher level components, but the negative aspect of this is that it prevents the reuse of low level components. Further Dependency Inversion Principle does account for the reuse of lower-level components by maintaining the client interface in a separate package, assigning ownership of this package to one or more consumers of a lower-level component can itself be problematic.

==Conclusion==
This principle is applied to make sure that the high level classes are not directly dependent on the low level classes, they are doing that using either by interfaces or abstract classes.In that case the creation of new low level objects inside the high level classes(if necessary) can not be done using the operator new. Instead, some of the Creational design patterns can be used, such as Factory Method, Abstract Factory, Prototype.
Of course, using this principle implies an increased effort and a more complex code, but more flexible. This principle can not be applied for every class or every module. If we have a class functionality that is more likely to remain unchanged in the future there is not need to apply this principle.When a component does not depend on lower level components directly but only through abstractions this component is mobile that is, the component is reusable in many different contexts.

=References=

[1] http://www.objectmentor.com/resources/articles/dip.pdf 
[2] http://www.ctrl-shift-b.com/2008/12/examining-dependency-inversion.html 
[3] http://blogs.imeta.co.uk/jyoung/archive/2008/12/17/540.aspx 
[4] http://en.wikipedia.org/wiki/Dependency_inversion_principle 
[5] http://www.lostechies.com/blogs/gabrielschenker/archive/2009/01/30/the-dependency-inversion-principle.aspx 
[6] http://www.oodesign.com/dependency-inversion-principle.html 
[7] http://www.eventhelix.com/realtimemantra/Object_Oriented/dependency_inversion_principle.htm 
[8] http://davidhayden.com/blog/dave/archive/2005/06/10/1261.aspx 
[9] http://doodleproject.sourceforge.net/articles/2001/dependencyInversionPrinciple.html 
[10] http://stackoverflow.com/questions/62539/what-is-the-dependency-inversion-principle-and-why-is-it-important 
[11] http://www.surfscranton.com/architecture/DIPandOCP/img0.html 
[12] http://iface.wordpress.com/2006/03/16/dependency-inversion-principle-and-interface/ 
[13] http://www.exciton.cs.rice.edu/JavaResources/DesignPatterns/TemplatePattern.htm 
[14] Martin, R. C. (1996, May). The Dependency Inversion Principle. C++ Report.

CSC/ECE 517 Fall 2009/wiki3 5 rm

2009-11-19T01:37:18Z

Sniper: /* Introduction */

CSC/ECE 517 Fall 2009/wiki3 5 rm

2009-11-19T01:37:03Z

Sniper: /* Introduction */

=Dependency Inversion policy=

==Introduction==
The Dependency Inversion Principle has been proposed by Robert C. Martin. It states that:

''"High level modules should not depend upon low level modules. Both should depend upon abstractions. Abstractions should not depend upon details. Details should depend upon abstractions."''

The principle is reverse the conventional philosophy of high level functions in softwares need to depend on the low level functions.
The principle states that high level or low level modules should not depend upon each other, instead they should depend upon abstractions. Further it also states that these abstractions should not depend on the details and inversely the details should depend on the abstractions.
According to this principle the way of designing a class structure is to start from high level modules to the low level modules:

'''High Level Classes → Abstraction Layer → Low Level Classes'''
This is my article

==Overview==
The Dependency Inversion Principle is defined as follows:

#High-level modules should not depend upon low-level modules. Both should depend upon abstractions.
#Abstractions should not depend upon details. Details should depend upon abstractions.

The problem with the conventional design architecture is that the higher level components depends on the lower level components. This can be understood from the diagram below.
[[Image:wiki3_5_rm1.png|450px|thumb|center|Figure 1: Higher-level components depend upon lower-level components]]

From the above diagram we see that the component A depends on component B, which in turn depends on component C. These dependencies make the higher level modules or components more complex and inflexible. This also leads to tight coupling of higher and lower level components. Thus reducing the over all flexibility of the system.

The primary motive of the ''dependency inversion principle'' is to decouple the high level components from their dependency on the low level components of the system. This can be obtained by creating interfaces as a part of the higher level component package which define the components for the extra functionality required. This protects the component from depending on any specific implementation of the provided interface/functionality. Thus making the given function more portable.
The above example can be restructured as follows

[[Image:wiki3_5_rm2.png|450px|thumb|center|Figure 2: Relationship diagram]]
As one can see in the above figure the component B doesn't depend on A but rather depends on the interface that is also used by A. The same relationship is additionally shown between components B and C. Take special note that the interfaces are packaged together with the higher-level components and are defined in terms of the higher-level component’s needs, not the lower-level component’s behavior. It is this association of the interface with the client component which logically inverts the conventional dependency flow.

==Example of Dependency inversion principle==
// Dependency Inversion Principle - Bad example
class Worker {
public void work() {
// ....working
}
}
class Manager {
Worker m_worker;
public void setWorker(Worker w) {
m_worker=w;
}
public void manage() {
m_worker.work();
}
}
class SuperWorker {
public void work() {
//.... working much more
}
}

The code shown below implements the code above using Dependency Inversion principle.This helps us in solving the following problems.
#Manager class should not be changed.
#Minimized risk to affect old funtionallity present in Manager class.
#No need to redone the unit testing for Manager class.

// Dependency Inversion Principle - Good example
interface IWorker {
public void work();
}
class Worker implements IWorker{
public void work() {
// ....working
}
}
class SuperWorker implements IWorker{
public void work() {
//.... working much more
}
}
class Manager {
IWorker m_worker;
public void setWorker(IWorker w) {
m_worker=w;
}
public void manage() {
m_worker.work();
}
}

==A design pattern based on dependency inversion policy (Template design pattern)==
The Template Design pattern implements the Dependency Inversion Principle by setting up the outline or skeleton of an algorithm, leaving the details to be implemented by the classes or modules implementing it. This way, the sub classes will be getting there information from the abstract classes. Further these abstract classes are not dependent on the details while the vice versa is true. The UML diagram below gives you better understanding of the Template design pattern. There are method calls to operation1() and operation2(). The definition of these methods are defined in the subclass which override them.
[[Image:wiki3_5_rm3.png|450px|thumb|center|Figure 3: Template Design Pattern]]

==Why call it dependency inversion policy?==

The dependency structure of a well designed object oriented application is "inverted" with respect to the dependency structure that normally results from a "traditional" application which is implemented in a more procedural style. In a procedural application high level modules depend upon low level modules and abstractions depend upon details.

Consider the implications of high level modules that depend upon low level modules. It is the high level modules that contain the important policy decisions and business models of an application. It is these models that contain the identity of the application. Yet, when these modules depend upon the lower level modules, then changes to the lower level modules can have direct effects upon them; and can force them to change.
It is the high level modules that ought to be forcing the low level modules to change. It is the high level modules that should take precedence over the lower level modules. High level modules simply should not depend upon low level modules in any way. Moreover, it is high level modules that we want to be able to reuse. When high level modules depend upon low level modules, it becomes very difficult to reuse those high level modules in different contexts. However, when the high level modules are independent of the low level modules, then the high level modules can be reused quite simply.

==Benefits and Consequences==
Dependency Inversion Principle proposes a useful mechanism in decoupling the dependencies between the high and low level components of the system. This not only makes sure that the high level components don't directly depend on the low level components, it also makes sure that the core functionality with n the application can be more easily reused in other contexts.Applying Dependency Inversion Principle makes it easier for reusing the higher level components, but the negative aspect of this is that it prevents the reuse of low level components. Further Dependency Inversion Principle does account for the reuse of lower-level components by maintaining the client interface in a separate package, assigning ownership of this package to one or more consumers of a lower-level component can itself be problematic.

==Conclusion==
This principle is applied to make sure that the high level classes are not directly dependent on the low level classes, they are doing that using either by interfaces or abstract classes.In that case the creation of new low level objects inside the high level classes(if necessary) can not be done using the operator new. Instead, some of the Creational design patterns can be used, such as Factory Method, Abstract Factory, Prototype.
Of course, using this principle implies an increased effort and a more complex code, but more flexible. This principle can not be applied for every class or every module. If we have a class functionality that is more likely to remain unchanged in the future there is not need to apply this principle.When a component does not depend on lower level components directly but only through abstractions this component is mobile that is, the component is reusable in many different contexts.

=References=

[1] http://www.objectmentor.com/resources/articles/dip.pdf 
[2] http://www.ctrl-shift-b.com/2008/12/examining-dependency-inversion.html 
[3] http://blogs.imeta.co.uk/jyoung/archive/2008/12/17/540.aspx 
[4] http://en.wikipedia.org/wiki/Dependency_inversion_principle 
[5] http://www.lostechies.com/blogs/gabrielschenker/archive/2009/01/30/the-dependency-inversion-principle.aspx 
[6] http://www.oodesign.com/dependency-inversion-principle.html 
[7] http://www.eventhelix.com/realtimemantra/Object_Oriented/dependency_inversion_principle.htm 
[8] http://davidhayden.com/blog/dave/archive/2005/06/10/1261.aspx 
[9] http://doodleproject.sourceforge.net/articles/2001/dependencyInversionPrinciple.html 
[10] http://stackoverflow.com/questions/62539/what-is-the-dependency-inversion-principle-and-why-is-it-important 
[11] http://www.surfscranton.com/architecture/DIPandOCP/img0.html 
[12] http://iface.wordpress.com/2006/03/16/dependency-inversion-principle-and-interface/ 
[13] http://www.exciton.cs.rice.edu/JavaResources/DesignPatterns/TemplatePattern.htm 
[14] Martin, R. C. (1996, May). The Dependency Inversion Principle. C++ Report.

File:JRapture.jpg

2009-10-15T03:29:56Z

Sniper: jRapture

jRapture

CSC/ECE 517 Fall 2009/wiki2 10 mk

2009-10-15T03:25:17Z

Sniper: /* 7. jRapture: */

=GUI Testing Frameworks=

==Introduction==
Most software developed in recent years has a graphical user interface (GUI). The only way for the end-user to interact with the software application is through the GUI. Hence, acceptance and system testing of the software requires GUI testing. In this wiki we aim at covering the different approaches, including patterns and tools for GUI testing.

==Some problems of GUI testing==
*GUIs are tested manually, often by the developers themselves. This is very unreliable and expensive. For new GUIs or those being significantly changed, quality is low, and failures at integration time or during user acceptance tests are common.
*[http://en.wikipedia.org/wiki/Data_scraping#Screen_scraping ScreenScrapper] based GUI test does a nice job but to a certain extent. Even though they are cheap, the problem with these tests is that if you change the screen layout all existing tests become useless, which means you have no [http://en.wikipedia.org/wiki/Regression_testing regression tests]. Another problem here is that test creators can't start writing tests till the GUIs are finished. Example: [http://en.wikipedia.org/wiki/Test_harness test harnesses], [http://www.citeulike.org/user/V/article/2682599 capture/replay tools](Example provided in the appendix), and [http://en.wikipedia.org/wiki/Model-based_testing model-based methods]
*The user has an extremely wide choice of actions. The user could click on any pixel on the screen. Using manual tools to mimic the usage of the GUI only provides limited testing.
*There are tools which try to capture [http://en.wikipedia.org/wiki/GUI_widget GUI widgets] rather than mouse coordinates. These tools, however, require a significant amount of manual effort to be effective, including developing test scripts and manually detecting failures.Modifications to the GUI require changes to the scripts as well. Example: [http://en.wikipedia.org/wiki/HP_WinRunner Winrunner], [http://www.testingfaqs.org/t-gui.html#Abbot Abbot], and [http://www-01.ibm.com/software/awdtools/tester/robot/index.html Rational Robot]

==Approaches for GUI testing==

===1. An Ontology-Based Approach for GUI Testing [http://www2.computer.org/portal/web/csdl/doi/10.1109/COMPSAC.2009.92]===

In the approach an GUI testing [http://en.wikipedia.org/wiki/Ontology ontology] is established by analyzing the source code with [http://en.wikipedia.org/wiki/Reverse_engineering reverse engineering] techniques. Then from the user experience the generation rules are extracted to create test cases. GUI testing is proposed for the purpose of making use of the knowledge provided by GUI systems and testers’ experience. GUI ontology is used to store potential
information in a GUI system, while test case generation rules extract useful information from testers’ experience. In a word, ontology based GUI testing is a new branch of software testing, which not only takes the knowledge intensive features of GUI testing into account, but also sufficiently make use of them.

===2. Automation of GUI testing using a model-driven approach [http://portal.acm.org/citation.cfm?id=1138932]===
In this approach the generated test cases are based on [http://en.wikipedia.org/wiki/Unified_Modeling_Language Unified Modelling Language]. This introduces data into the UML model via the [http://portal.acm.org/citation.cfm?id=62964 Category-Partition method]. The functions that have to be tested are specified using the [http://en.wikipedia.org/wiki/Use_case use cases] and [http://en.wikipedia.org/wiki/Activity_diagram activity diagrams]. This also specifies how they have to be tested. A combination like this has the potential to generate large number of test cases.The test can be managed in two ways.Firstly the Category-partitioned data which allows the designer full control over the possible and impossible paths for the system to run.Secondly automation allows different configuration for both data and graph coverage.Using all this we can generate test scripts which can be used for GUI testing.

[[Image:usecase.png|450px|thumb|center|Figure 1:Example Use Case Diagram]]

===3. Plan Generation GUI testing [http://www.cs.virginia.edu/~soffa/research/SE/AIPS00.pdf]===
This is based on the AI techniques, for partially automating GUI testing.In this method of testing the tester specifies the initial and the final goal states for the users of the system.The automated system produces a set of sequences or plans which will start with the initial state and end with the final state specified by the user. Each of the plans generated will represent a test case of a user of the system.

===4. A practical approach to testing GUI systems [http://www.springerlink.com/content/d08681k5081553r7/]===
In this approach, GUI is divided into two tires. One the component and other the system. [http://en.wikipedia.org/wiki/Control_flow_graph Flow graphs] will be created for each GUI component. The flow graph represents a set of preconditions, event sequences and post conditions of the corresponding component. On the system tire we build a viewpoint by integrating the components of the system. This will ensure that the components are working fine and are interacting as required. This is a simple, effective and practical method of performing GUI testing.

===5. A Dynamic Partitioning Approach for GUI Testing [http://www2.computer.org/portal/web/csdl/doi/10.1109/COMPSAC.2006.94]===
The above approaches specify how to generate the test cases without actually specifying how to run them. This approach specifies how the test cases have to run in order to make GUI testing effective and useful. Th GUI primitive actions are partitioned into two classes. They are prioritized primitive actions and non-prioritized primitive actions. This further divides the testing into two stages which contains two feed back loops.The first stage prioritizes primitive actions and the second stage selects and performs prioritized primitive actions. The first feedback loop is local and occurs in the second stage, which adjusts the memberships of primitive actions after they are performed. The second feedback loop is global and occurs between the first and second stages. It switches GUI testing from the second stage to the first stage when no prioritized primitive actions are available. The two testing experiments with real GUI applications show that the proposed dynamic partitioning approach can really work in practice and may significantly outperform the random testing approach.

==Tools for GUI testing==
===1. GUITAR===
The [http://guitar.sourceforge.net/ GUITAR] (GUI Testing frAmewoRk) project helps in simplifying GUI testing by automatically creating test cases that intelligently challenge a GUI's functionality. 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|figure 1:[http://guitar.sourceforge.net/ Guitar Framework]]]

In order to test the GUI of the AUT, the tester has to perform a certain set of steps. These steps are detailed below
*Initialize configurations in GUITAR for the AUT. This can be done using the below window
[[Image:guitar1.jpg|650px|thumb|center|figure 2:[http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/Perform%20Tests%20on%20the%20AUT.htm#Initialise Preferences window for initializing the application type]]]

*Rip the GUI structure of the AUT : To begin testing an application, the tester first needs to determine the GUI structure of the AUT. Running the Ripper applications on the AUT automatically does this. Types of rippers are available for analyzing the AUT. For analyzing an AUT developed using
**Java use the [http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/JavaGUIRipper.htm JavaGUIRipper]
**Native Win32 use [http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/GUIRipper.htm Windows GUI Ripper]

*Generate the Event Flow Graph : The Event Flow Graph is generated from the GUI structure, ripped in the above step. The EFGGenerator generates the event-flow graph for an AUT’s GUI. To see how to analyzes a window-based application and understand its GUI integration tree. This is explained in detail [http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/EFGGenerator.htm here]

*Generate Test cases : To generate testcases from the event flow graphs use the [http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/TCGenerator.htm TCGenerator]

*Replay the Testcases :

[[Image:guitar2.jpg|650px|thumb|center|figure 3:[http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/Perform%20Tests%20on%20the%20AUT.htm#Replayer Testcase execution]]]

*Coverage Evaluation
Execute the coverage evaluator to analyze the coverage generated when the testcases were executed on the instrumented AUT. A coverage report is generated by the instrumented code, when the testcases are replayed on it. The coverage evaluator analyzes this report and a summary report is generated.

[[Image:guitar3.jpg|650px|thumb|center|figure 4:[http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/Perform%20Tests%20on%20the%20AUT.htm#Coverager Running the coverage evaluator]]]

===2. Planning Assisted Tester for grapHical user interface Systems (PATHS)===
This is based on the event interaction sequences. This tests the GUI software using interactions which are mostly likely to be used in actual scenarios. This accepts an operator, initial state and a final state, with which the planning sequence produces a series of sequences which transforms the system form the initial state to the final state. The GUI tester can use this to generate interactions sequences by specifying the final state.

===3. GUIdancer===
[http://www.bredex.de/en/guidancer/first.html GUIdancer] is an [http://en.wikipedia.org/wiki/Eclipse_(software) Eclipse]-based automated GUI test-tool which runs as a standalone application or as an Eclipse Plugin.

GUIdancer is different from other GUI test-tools because automated tests can be written before the Application Under Test (AUT) is ready. This means that GUIdancer is not a tool which tests an application by recording user actions and replaying them. Tests can be created from the requirements without access to the AUT, and involve no programming, script or code. GUIdancer tests can be created, run and maintained without support from automation experts.

Each Test Step (the smallest unit in GUIdancer) consists of three pieces of information chosen from interactive dialogs: the GUI-component to be tested, the action to execute on this component, and the parameters (or data) the action requires. A Test Step to enter “hello” into a text field would look like this:

* GUI-component: Text field
* Action: Enter Text
* Parameter: Hello

===4. SeliniumHQ===
[http://seleniumhq.org/ Selenium] is a robust set of tools that supports rapid development of test automation for web-based applications. Selenium provides a rich set of testing functions specifically geared to the needs of testing of a web application. These operations are highly flexible, allowing many options for locating UI elements and comparing expected test results against actual application behavior.
'''How Selenium Works'''

[[Image:selenium.png|650px|thumb|center|Figure 1:[http://seleniumhq.org/about/how.html How Selenium Works]]]

===6. Cucumber:===
Cucumber is a tool that can execute plain-text functional descriptions as automated tests. The language that Cucumber understands is called [http://wiki.github.com/aslakhellesoy/cucumber/gherkin Gherkin]. Here is an example [http://wiki.github.com/aslakhellesoy/cucumber source]:
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 |

Cucumber itself is written in Ruby, but it can be used to “test” code written in Ruby or other languages including but not limited to Java, C# and Python. Cucumber only requires minimal use of Ruby programming and Ruby is easy, so don’t be afraid even if the code you’re developing in is not Ruby.

===7. jRapture:===
jRapture is a tool for capturing and replying Java program execution in the field.This works with the Java binaries and the Java virtual machine. It employs a lightweight , transparent capture process that permits unobtrusive of a Java programs executions. jRapture captures the interactions between a Java program and the system, which includes GUI.It has a profiling interface that permits a Java program to be instrumented for profiling after its executions have been captured.Using an XML-based profiling specification language a tester can specify various forms of profiling to be carried out during replay.

[[Image:selenium.png|650px|thumb|center|Figure 1:[http://seleniumhq.org/about/how.html How Selenium Works]]]

==Conclusion==
In summary, GUI testing is a complicated task. Systematic test design helps us to focus on the important tests and gives us an objective way of addressing risks. Tools are appropriate for many but not all tests and a staged approach to testing enables us to identify which tests to automate much more easily. Tools can therefore be used to detect errors pro-actively as well as to execute regression tests.

=References=
[1] http://c2.com/cgi/wiki?GuiTesting 
[2] http://chandlerproject.org/Journal/AutomatedGuiTestingProject 
[3] http://en.wikipedia.org/wiki/GUI_software_testing 
[4] http://www.open-xchange.com/wiki/index.php?title=Automated_GUI_Tests 
[5] http://agilistas.org/presentations/codecamp06/ 
[6] http://www.ranorex.com/?gclid=CNvA_YnesJ0CFchW2godpT5YrQ 
[7] http://www.gerrardconsulting.com/GUI/TestGui.html 
[8] http://www.slideshare.net/rpires/GUI-Test-Patterns 
[9] http://en.wikipedia.org/wiki/List_of_GUI_testing_tools 
[10] http://www.junit.org/taxonomy/term/6 
[11] http://www.cs.umd.edu/~atif/papers/MemonSQW2000.pdf 
[12] http://www.testingfaqs.org/t-gui.html 
[13] http://www.springerlink.com/content/d08681k5081553r7/ 
[14] http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/Perform%20Tests%20on%20the%20AUT.htm#Rip 
[15] http://seleniumhq.org/ 
[16] http://www2.computer.org/portal/web/csdl/doi/10.1109/COMPSAC.2006.94

CSC/ECE 517 Fall 2009/wiki2 10 mk

2009-10-15T03:22:43Z

Sniper: /* Tools for GUI testing */

=GUI Testing Frameworks=

==Introduction==
Most software developed in recent years has a graphical user interface (GUI). The only way for the end-user to interact with the software application is through the GUI. Hence, acceptance and system testing of the software requires GUI testing. In this wiki we aim at covering the different approaches, including patterns and tools for GUI testing.

==Some problems of GUI testing==
*GUIs are tested manually, often by the developers themselves. This is very unreliable and expensive. For new GUIs or those being significantly changed, quality is low, and failures at integration time or during user acceptance tests are common.
*[http://en.wikipedia.org/wiki/Data_scraping#Screen_scraping ScreenScrapper] based GUI test does a nice job but to a certain extent. Even though they are cheap, the problem with these tests is that if you change the screen layout all existing tests become useless, which means you have no [http://en.wikipedia.org/wiki/Regression_testing regression tests]. Another problem here is that test creators can't start writing tests till the GUIs are finished. Example: [http://en.wikipedia.org/wiki/Test_harness test harnesses], [http://www.citeulike.org/user/V/article/2682599 capture/replay tools](Example provided in the appendix), and [http://en.wikipedia.org/wiki/Model-based_testing model-based methods]
*The user has an extremely wide choice of actions. The user could click on any pixel on the screen. Using manual tools to mimic the usage of the GUI only provides limited testing.
*There are tools which try to capture [http://en.wikipedia.org/wiki/GUI_widget GUI widgets] rather than mouse coordinates. These tools, however, require a significant amount of manual effort to be effective, including developing test scripts and manually detecting failures.Modifications to the GUI require changes to the scripts as well. Example: [http://en.wikipedia.org/wiki/HP_WinRunner Winrunner], [http://www.testingfaqs.org/t-gui.html#Abbot Abbot], and [http://www-01.ibm.com/software/awdtools/tester/robot/index.html Rational Robot]

==Approaches for GUI testing==

===1. An Ontology-Based Approach for GUI Testing [http://www2.computer.org/portal/web/csdl/doi/10.1109/COMPSAC.2009.92]===

In the approach an GUI testing [http://en.wikipedia.org/wiki/Ontology ontology] is established by analyzing the source code with [http://en.wikipedia.org/wiki/Reverse_engineering reverse engineering] techniques. Then from the user experience the generation rules are extracted to create test cases. GUI testing is proposed for the purpose of making use of the knowledge provided by GUI systems and testers’ experience. GUI ontology is used to store potential
information in a GUI system, while test case generation rules extract useful information from testers’ experience. In a word, ontology based GUI testing is a new branch of software testing, which not only takes the knowledge intensive features of GUI testing into account, but also sufficiently make use of them.

===2. Automation of GUI testing using a model-driven approach [http://portal.acm.org/citation.cfm?id=1138932]===
In this approach the generated test cases are based on [http://en.wikipedia.org/wiki/Unified_Modeling_Language Unified Modelling Language]. This introduces data into the UML model via the [http://portal.acm.org/citation.cfm?id=62964 Category-Partition method]. The functions that have to be tested are specified using the [http://en.wikipedia.org/wiki/Use_case use cases] and [http://en.wikipedia.org/wiki/Activity_diagram activity diagrams]. This also specifies how they have to be tested. A combination like this has the potential to generate large number of test cases.The test can be managed in two ways.Firstly the Category-partitioned data which allows the designer full control over the possible and impossible paths for the system to run.Secondly automation allows different configuration for both data and graph coverage.Using all this we can generate test scripts which can be used for GUI testing.

[[Image:usecase.png|450px|thumb|center|Figure 1:Example Use Case Diagram]]

===3. Plan Generation GUI testing [http://www.cs.virginia.edu/~soffa/research/SE/AIPS00.pdf]===
This is based on the AI techniques, for partially automating GUI testing.In this method of testing the tester specifies the initial and the final goal states for the users of the system.The automated system produces a set of sequences or plans which will start with the initial state and end with the final state specified by the user. Each of the plans generated will represent a test case of a user of the system.

===4. A practical approach to testing GUI systems [http://www.springerlink.com/content/d08681k5081553r7/]===
In this approach, GUI is divided into two tires. One the component and other the system. [http://en.wikipedia.org/wiki/Control_flow_graph Flow graphs] will be created for each GUI component. The flow graph represents a set of preconditions, event sequences and post conditions of the corresponding component. On the system tire we build a viewpoint by integrating the components of the system. This will ensure that the components are working fine and are interacting as required. This is a simple, effective and practical method of performing GUI testing.

===5. A Dynamic Partitioning Approach for GUI Testing [http://www2.computer.org/portal/web/csdl/doi/10.1109/COMPSAC.2006.94]===
The above approaches specify how to generate the test cases without actually specifying how to run them. This approach specifies how the test cases have to run in order to make GUI testing effective and useful. Th GUI primitive actions are partitioned into two classes. They are prioritized primitive actions and non-prioritized primitive actions. This further divides the testing into two stages which contains two feed back loops.The first stage prioritizes primitive actions and the second stage selects and performs prioritized primitive actions. The first feedback loop is local and occurs in the second stage, which adjusts the memberships of primitive actions after they are performed. The second feedback loop is global and occurs between the first and second stages. It switches GUI testing from the second stage to the first stage when no prioritized primitive actions are available. The two testing experiments with real GUI applications show that the proposed dynamic partitioning approach can really work in practice and may significantly outperform the random testing approach.

==Tools for GUI testing==
===1. GUITAR===
The [http://guitar.sourceforge.net/ GUITAR] (GUI Testing frAmewoRk) project helps in simplifying GUI testing by automatically creating test cases that intelligently challenge a GUI's functionality. 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|figure 1:[http://guitar.sourceforge.net/ Guitar Framework]]]

In order to test the GUI of the AUT, the tester has to perform a certain set of steps. These steps are detailed below
*Initialize configurations in GUITAR for the AUT. This can be done using the below window
[[Image:guitar1.jpg|650px|thumb|center|figure 2:[http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/Perform%20Tests%20on%20the%20AUT.htm#Initialise Preferences window for initializing the application type]]]

*Rip the GUI structure of the AUT : To begin testing an application, the tester first needs to determine the GUI structure of the AUT. Running the Ripper applications on the AUT automatically does this. Types of rippers are available for analyzing the AUT. For analyzing an AUT developed using
**Java use the [http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/JavaGUIRipper.htm JavaGUIRipper]
**Native Win32 use [http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/GUIRipper.htm Windows GUI Ripper]

*Generate the Event Flow Graph : The Event Flow Graph is generated from the GUI structure, ripped in the above step. The EFGGenerator generates the event-flow graph for an AUT’s GUI. To see how to analyzes a window-based application and understand its GUI integration tree. This is explained in detail [http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/EFGGenerator.htm here]

*Generate Test cases : To generate testcases from the event flow graphs use the [http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/TCGenerator.htm TCGenerator]

*Replay the Testcases :

[[Image:guitar2.jpg|650px|thumb|center|figure 3:[http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/Perform%20Tests%20on%20the%20AUT.htm#Replayer Testcase execution]]]

*Coverage Evaluation
Execute the coverage evaluator to analyze the coverage generated when the testcases were executed on the instrumented AUT. A coverage report is generated by the instrumented code, when the testcases are replayed on it. The coverage evaluator analyzes this report and a summary report is generated.

[[Image:guitar3.jpg|650px|thumb|center|figure 4:[http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/Perform%20Tests%20on%20the%20AUT.htm#Coverager Running the coverage evaluator]]]

===2. Planning Assisted Tester for grapHical user interface Systems (PATHS)===
This is based on the event interaction sequences. This tests the GUI software using interactions which are mostly likely to be used in actual scenarios. This accepts an operator, initial state and a final state, with which the planning sequence produces a series of sequences which transforms the system form the initial state to the final state. The GUI tester can use this to generate interactions sequences by specifying the final state.

===3. GUIdancer===
[http://www.bredex.de/en/guidancer/first.html GUIdancer] is an [http://en.wikipedia.org/wiki/Eclipse_(software) Eclipse]-based automated GUI test-tool which runs as a standalone application or as an Eclipse Plugin.

GUIdancer is different from other GUI test-tools because automated tests can be written before the Application Under Test (AUT) is ready. This means that GUIdancer is not a tool which tests an application by recording user actions and replaying them. Tests can be created from the requirements without access to the AUT, and involve no programming, script or code. GUIdancer tests can be created, run and maintained without support from automation experts.

Each Test Step (the smallest unit in GUIdancer) consists of three pieces of information chosen from interactive dialogs: the GUI-component to be tested, the action to execute on this component, and the parameters (or data) the action requires. A Test Step to enter “hello” into a text field would look like this:

* GUI-component: Text field
* Action: Enter Text
* Parameter: Hello

===4. SeliniumHQ===
[http://seleniumhq.org/ Selenium] is a robust set of tools that supports rapid development of test automation for web-based applications. Selenium provides a rich set of testing functions specifically geared to the needs of testing of a web application. These operations are highly flexible, allowing many options for locating UI elements and comparing expected test results against actual application behavior.
'''How Selenium Works'''

[[Image:selenium.png|650px|thumb|center|Figure 1:[http://seleniumhq.org/about/how.html How Selenium Works]]]

===6. Cucumber:===
Cucumber is a tool that can execute plain-text functional descriptions as automated tests. The language that Cucumber understands is called [http://wiki.github.com/aslakhellesoy/cucumber/gherkin Gherkin]. Here is an example [http://wiki.github.com/aslakhellesoy/cucumber source]:
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 |

Cucumber itself is written in Ruby, but it can be used to “test” code written in Ruby or other languages including but not limited to Java, C# and Python. Cucumber only requires minimal use of Ruby programming and Ruby is easy, so don’t be afraid even if the code you’re developing in is not Ruby.

===7. jRapture:===
jRapture is a tool for capturing and replying Java program execution in the field.This works with the Java binaries and the Java virtual machine. It employs a lightweight , transparent capture process that permits unobtrusive of a Java programs executions. jRapture captures the interactions between a Java program and the system, which includes GUI.It has a profiling interface that permits a Java program to be instrumented for profiling after its executions have been captured.Using an XML-based profiling specification language a tester can specify various forms of profiling to be carried out during replay.

==Conclusion==
In summary, GUI testing is a complicated task. Systematic test design helps us to focus on the important tests and gives us an objective way of addressing risks. Tools are appropriate for many but not all tests and a staged approach to testing enables us to identify which tests to automate much more easily. Tools can therefore be used to detect errors pro-actively as well as to execute regression tests.

=References=
[1] http://c2.com/cgi/wiki?GuiTesting 
[2] http://chandlerproject.org/Journal/AutomatedGuiTestingProject 
[3] http://en.wikipedia.org/wiki/GUI_software_testing 
[4] http://www.open-xchange.com/wiki/index.php?title=Automated_GUI_Tests 
[5] http://agilistas.org/presentations/codecamp06/ 
[6] http://www.ranorex.com/?gclid=CNvA_YnesJ0CFchW2godpT5YrQ 
[7] http://www.gerrardconsulting.com/GUI/TestGui.html 
[8] http://www.slideshare.net/rpires/GUI-Test-Patterns 
[9] http://en.wikipedia.org/wiki/List_of_GUI_testing_tools 
[10] http://www.junit.org/taxonomy/term/6 
[11] http://www.cs.umd.edu/~atif/papers/MemonSQW2000.pdf 
[12] http://www.testingfaqs.org/t-gui.html 
[13] http://www.springerlink.com/content/d08681k5081553r7/ 
[14] http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/Perform%20Tests%20on%20the%20AUT.htm#Rip 
[15] http://seleniumhq.org/ 
[16] http://www2.computer.org/portal/web/csdl/doi/10.1109/COMPSAC.2006.94

CSC/ECE 517 Fall 2009/wiki2 10 mk

2009-10-11T00:29:01Z

Sniper: /* 1. An Ontology-Based Approach for GUI Testing [http://www2.computer.org/portal/web/csdl/doi/10.1109/COMPSAC.2009.92] */

=GUI Testing Frameworks=

==Problem Statement==
Most software developed in recent years has a graphical user interface (GUI). The only way for the end-user to interact with the software application is through the GUI. Hence, acceptance and system testing of the software requires GUI testing. In this wiki we aim at covering the different approaches, including patterns and tools for GUI testing.

==Some problems of GUI testing==
*GUIs are tested manually, often by the developers themselves. This is very unreliable and expensive. For new GUIs or those being significantly changed, quality is low, and failures at integration time or during user acceptance tests are common.
*[http://en.wikipedia.org/wiki/Data_scraping#Screen_scraping ScreenScrapper] based GUI test does a nice job but to a certain extent. Even though they are cheap, the problem with these tests is that if you change the screen layout all existing tests become useless, which means you have no [http://en.wikipedia.org/wiki/Regression_testing regression tests]. Another problem here is that test creators can't start writing tests till the GUIs are finished. Example: [http://en.wikipedia.org/wiki/Test_harness test harnesses], [http://www.citeulike.org/user/V/article/2682599 capture/replay tools], and [http://en.wikipedia.org/wiki/Model-based_testing model-based methods]
*The user has an extremely wide choice of actions. The user could click on any pixel on the screen. Using manual tools to mimic the usage of the GUI only provides limited testing.
*There are tools which try to capture [http://en.wikipedia.org/wiki/GUI_widget GUI widgets] rather than mouse coordinates. These tools, however, require a significant amount of manual effort to be effective, including developing test scripts and manually detecting failures.Modifications to the GUI require changes to the scripts as well. Example: [http://en.wikipedia.org/wiki/HP_WinRunner Winrunner], [http://www.testingfaqs.org/t-gui.html#Abbot Abbot], and [http://www-01.ibm.com/software/awdtools/tester/robot/index.html Rational Robot]

==Approaches for GUI testing==

===1. An Ontology-Based Approach for GUI Testing [http://www2.computer.org/portal/web/csdl/doi/10.1109/COMPSAC.2009.92]===

In the approach an GUI testing [http://en.wikipedia.org/wiki/Ontology ontology] is established by analyzing the source code with [http://en.wikipedia.org/wiki/Reverse_engineering reverse engineering] techniques. Then from the user experience the generation rules are extracted to create test cases. GUI testing is proposed for the purpose of making use of the knowledge provided by GUI systems and testers’ experience. GUI ontology is used to store potential
information in a GUI system, while test case generation rules extract useful information from testers’ experience. In a word, ontology based GUI testing is a new branch of software testing, which not only takes the knowledge intensive features of GUI testing into account, but also sufficiently make use of them.

===2. Automation of GUI testing using a model-driven approach [http://portal.acm.org/citation.cfm?id=1138932]===
In this approach the generated test cases are based on [http://en.wikipedia.org/wiki/Unified_Modeling_Language Unified Modelling Language]. This introduces data into the UML model via the [http://portal.acm.org/citation.cfm?id=62964 Category-Partition method]. The functions that have to be tested are specified using the [http://en.wikipedia.org/wiki/Use_case use cases] and [http://en.wikipedia.org/wiki/Activity_diagram activity diagrams]. This also specifies how they have to be tested. A combination like this has the potential to generate large number of test cases.The test can be managed in two ways.Firstly the Category-partitioned data which allows the designer full control over the possible and impossible paths for the system to run.Secondly automation allows different configuration for both data and graph coverage.Using all this we can generate test scripts which can be used for GUI testing.

[[Image:usecase.png|450px|thumb|center|Figure 1:Example Use Case Diagram]]

===3. Plan Generation GUI testing [http://www.cs.virginia.edu/~soffa/research/SE/AIPS00.pdf]===
This is based on the AI techniques, for partially automating GUI testing.In this method of testing the tester specifies the initial and the final goal states for the users of the system.The automated system produces a set of sequences or plans which will start with the initial state and end with the final state specified by the user. Each of the plans generated will represent a test case of a user of the system.

===4. A practical approach to testing GUI systems [http://www.springerlink.com/content/d08681k5081553r7/]===
In this approach, GUI is divided into two tires. One the component and other the system. [http://en.wikipedia.org/wiki/Control_flow_graph Flow graphs] will be created for each GUI component. The flow graph represents a set of preconditions, event sequences and post conditions of the corresponding component. On the system tire we build a viewpoint by integrating the components of the system. This will ensure that the components are working fine and are interacting as required. This is a simple, effective and practical method of performing GUI testing.

===5. A Dynamic Partitioning Approach for GUI Testing [http://www2.computer.org/portal/web/csdl/doi/10.1109/COMPSAC.2006.94]===
The above approaches specify how to generate the test cases without actually specifying how to run them. This approach specifies how the test cases have to run in order to make GUI testing effective and useful. Th GUI primitive actions are partitioned into two classes. They are prioritized primitive actions and non-prioritized primitive actions. This further divides the testing into two stages which contains two feed back loops.The first stage prioritizes primitive actions and the second stage selects and performs prioritized primitive actions. The first feedback loop is local and occurs in the second stage, which adjusts the memberships of primitive actions after they are performed. The second feedback loop is global and occurs between the first and second stages. It switches GUI testing from the second stage to the first stage when no prioritized primitive actions are available. The two testing experiments with real GUI applications show that the proposed dynamic partitioning approach can really work in practice and may significantly outperform the random testing approach.

==Tools for GUI testing==
===1. GUITAR===
The [http://guitar.sourceforge.net/ GUITAR] (GUI Testing frAmewoRk) project helps in simplifying GUI testing by automatically creating test cases that intelligently challenge a GUI's functionality. 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|figure 1:[http://guitar.sourceforge.net/ Guitar Framework]]]

In order to test the GUI of the AUT, the tester has to perform a certain set of steps. These steps are detailed below
*Initialize configurations in GUITAR for the AUT. This can be done using the below window
[[Image:guitar1.jpg|650px|thumb|center|figure 2:[http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/Perform%20Tests%20on%20the%20AUT.htm#Initialise Preferences window for initializing the application type]]]

*Replay the Testcases
[[Image:guitar2.jpg|650px|thumb|center|figure 3:[http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/Perform%20Tests%20on%20the%20AUT.htm#Replayer Testcase execution]]]

*Coverage Evaluation
Execute the coverage evaluator to analyze the coverage generated when the testcases were executed on the instrumented AUT. A coverage report is generated by the instrumented code, when the testcases are replayed on it. The coverage evaluator analyzes this report and a summary report is generated.
[[Image:guitar3.jpg|650px|thumb|center|figure 4:[http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/Perform%20Tests%20on%20the%20AUT.htm#Coverager Running the coverage evaluator]]]

===2. Planning Assisted Tester for grapHical user interface Systems (PATHS)===
This is based on the event interaction sequences. This tests the GUI software using interactions which are mostly likely to be used in actual scenarios. This accepts an operator, initial state and a final state, with which the planning sequence produces a series of sequences which transforms the system form the initial state to the final state. The GUI tester can use this to generate interactions sequences by specifying the final state.

===3. GUIdancer===
[http://www.bredex.de/en/guidancer/first.html GUIdancer] is an [http://en.wikipedia.org/wiki/Eclipse_(software) Eclipse]-based automated GUI test-tool which runs as a standalone application or as an Eclipse Plugin.

GUIdancer is different from other GUI test-tools because automated tests can be written before the Application Under Test (AUT) is ready. This means that GUIdancer is not a tool which tests an application by recording user actions and replaying them. Tests can be created from the requirements without access to the AUT, and involve no programming, script or code. GUIdancer tests can be created, run and maintained without support from automation experts.

Each Test Step (the smallest unit in GUIdancer) consists of three pieces of information chosen from interactive dialogs: the GUI-component to be tested, the action to execute on this component, and the parameters (or data) the action requires. A Test Step to enter “hello” into a text field would look like this:

* GUI-component: Text field
* Action: Enter Text
* Parameter: Hello

===4. SeliniumHQ===
[http://seleniumhq.org/ Selenium] is a robust set of tools that supports rapid development of test automation for web-based applications. Selenium provides a rich set of testing functions specifically geared to the needs of testing of a web application. These operations are highly flexible, allowing many options for locating UI elements and comparing expected test results against actual application behavior.
'''How Selenium Works'''

[[Image:selenium.png|650px|thumb|center|Figure 1:[http://seleniumhq.org/about/how.html How Selenium Works]]]

===6. Cucumber:===
Cucumber is a tool that can execute plain-text functional descriptions as automated tests. The language that Cucumber understands is called [http://wiki.github.com/aslakhellesoy/cucumber/gherkin Gherkin]. Here is an example:
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 |

Cucumber itself is written in Ruby, but it can be used to “test” code written in Ruby or other languages including but not limited to Java, C# and Python. Cucumber only requires minimal use of Ruby programming and Ruby is easy, so don’t be afraid even if the code you’re developing in is not Ruby.

==Conclusion==
In summary, GUI testing is a complicated task. Systematic test design helps us to focus on the important tests and gives us an objective way of addressing risks. Tools are appropriate for many but not all tests and a staged approach to testing enables us to identify which tests to automate much more easily. Tools can therefore be used to detect errors pro-actively as well as to execute regression tests.

=References=
[1] http://c2.com/cgi/wiki?GuiTesting 
[2] http://chandlerproject.org/Journal/AutomatedGuiTestingProject 
[3] http://en.wikipedia.org/wiki/GUI_software_testing 
[4] http://www.open-xchange.com/wiki/index.php?title=Automated_GUI_Tests 
[5] http://agilistas.org/presentations/codecamp06/ 
[6] http://www.ranorex.com/?gclid=CNvA_YnesJ0CFchW2godpT5YrQ 
[7] http://www.gerrardconsulting.com/GUI/TestGui.html 
[8] http://www.slideshare.net/rpires/GUI-Test-Patterns 
[9] http://en.wikipedia.org/wiki/List_of_GUI_testing_tools 
[10] http://www.junit.org/taxonomy/term/6 
[11] http://www.cs.umd.edu/~atif/papers/MemonSQW2000.pdf 
[12] http://www.testingfaqs.org/t-gui.html 
[13] http://www.springerlink.com/content/d08681k5081553r7/ 
[14] http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/Perform%20Tests%20on%20the%20AUT.htm#Rip 
[15] http://seleniumhq.org/ 
[16] http://www2.computer.org/portal/web/csdl/doi/10.1109/COMPSAC.2006.94

CSC/ECE 517 Fall 2009/wiki2 10 mk

2009-10-11T00:28:30Z

Sniper: /* 1. An Ontology-Based Approach for GUI Testing [http://www2.computer.org/portal/web/csdl/doi/10.1109/COMPSAC.2009.92] */

=GUI Testing Frameworks=

==Problem Statement==
Most software developed in recent years has a graphical user interface (GUI). The only way for the end-user to interact with the software application is through the GUI. Hence, acceptance and system testing of the software requires GUI testing. In this wiki we aim at covering the different approaches, including patterns and tools for GUI testing.

==Some problems of GUI testing==
*GUIs are tested manually, often by the developers themselves. This is very unreliable and expensive. For new GUIs or those being significantly changed, quality is low, and failures at integration time or during user acceptance tests are common.
*[http://en.wikipedia.org/wiki/Data_scraping#Screen_scraping ScreenScrapper] based GUI test does a nice job but to a certain extent. Even though they are cheap, the problem with these tests is that if you change the screen layout all existing tests become useless, which means you have no [http://en.wikipedia.org/wiki/Regression_testing regression tests]. Another problem here is that test creators can't start writing tests till the GUIs are finished. Example: [http://en.wikipedia.org/wiki/Test_harness test harnesses], [http://www.citeulike.org/user/V/article/2682599 capture/replay tools], and [http://en.wikipedia.org/wiki/Model-based_testing model-based methods]
*The user has an extremely wide choice of actions. The user could click on any pixel on the screen. Using manual tools to mimic the usage of the GUI only provides limited testing.
*There are tools which try to capture [http://en.wikipedia.org/wiki/GUI_widget GUI widgets] rather than mouse coordinates. These tools, however, require a significant amount of manual effort to be effective, including developing test scripts and manually detecting failures.Modifications to the GUI require changes to the scripts as well. Example: [http://en.wikipedia.org/wiki/HP_WinRunner Winrunner], [http://www.testingfaqs.org/t-gui.html#Abbot Abbot], and [http://www-01.ibm.com/software/awdtools/tester/robot/index.html Rational Robot]

==Approaches for GUI testing==

===1. An Ontology-Based Approach for GUI Testing [http://www2.computer.org/portal/web/csdl/doi/10.1109/COMPSAC.2009.92]===

In the approach an GUI testing [http://en.wikipedia.org/wiki/Ontology ontology] is established by analyzing the source code with [http://en.wikipedia.org/wiki/Reverse_engineering reverse engineering] techniques. Then from the user experience the generation rules are extracted to create test cases. GUI testing is proposed for the purpose of making use of the knowledge provided by GUI systems and testers’ experience. GUI ontology is used to store potential
information in a GUI system, while test case generation rules extract useful information from testers’ experience. In a word, ontology based GUI testing is a new branch of software testing, which not only takes the knowledge intensive features of GUI testing into account, but also sufficiently make use of them.
thi

===2. Automation of GUI testing using a model-driven approach [http://portal.acm.org/citation.cfm?id=1138932]===
In this approach the generated test cases are based on [http://en.wikipedia.org/wiki/Unified_Modeling_Language Unified Modelling Language]. This introduces data into the UML model via the [http://portal.acm.org/citation.cfm?id=62964 Category-Partition method]. The functions that have to be tested are specified using the [http://en.wikipedia.org/wiki/Use_case use cases] and [http://en.wikipedia.org/wiki/Activity_diagram activity diagrams]. This also specifies how they have to be tested. A combination like this has the potential to generate large number of test cases.The test can be managed in two ways.Firstly the Category-partitioned data which allows the designer full control over the possible and impossible paths for the system to run.Secondly automation allows different configuration for both data and graph coverage.Using all this we can generate test scripts which can be used for GUI testing.

[[Image:usecase.png|450px|thumb|center|Figure 1:Example Use Case Diagram]]

===3. Plan Generation GUI testing [http://www.cs.virginia.edu/~soffa/research/SE/AIPS00.pdf]===
This is based on the AI techniques, for partially automating GUI testing.In this method of testing the tester specifies the initial and the final goal states for the users of the system.The automated system produces a set of sequences or plans which will start with the initial state and end with the final state specified by the user. Each of the plans generated will represent a test case of a user of the system.

===4. A practical approach to testing GUI systems [http://www.springerlink.com/content/d08681k5081553r7/]===
In this approach, GUI is divided into two tires. One the component and other the system. [http://en.wikipedia.org/wiki/Control_flow_graph Flow graphs] will be created for each GUI component. The flow graph represents a set of preconditions, event sequences and post conditions of the corresponding component. On the system tire we build a viewpoint by integrating the components of the system. This will ensure that the components are working fine and are interacting as required. This is a simple, effective and practical method of performing GUI testing.

===5. A Dynamic Partitioning Approach for GUI Testing [http://www2.computer.org/portal/web/csdl/doi/10.1109/COMPSAC.2006.94]===
The above approaches specify how to generate the test cases without actually specifying how to run them. This approach specifies how the test cases have to run in order to make GUI testing effective and useful. Th GUI primitive actions are partitioned into two classes. They are prioritized primitive actions and non-prioritized primitive actions. This further divides the testing into two stages which contains two feed back loops.The first stage prioritizes primitive actions and the second stage selects and performs prioritized primitive actions. The first feedback loop is local and occurs in the second stage, which adjusts the memberships of primitive actions after they are performed. The second feedback loop is global and occurs between the first and second stages. It switches GUI testing from the second stage to the first stage when no prioritized primitive actions are available. The two testing experiments with real GUI applications show that the proposed dynamic partitioning approach can really work in practice and may significantly outperform the random testing approach.

==Tools for GUI testing==
===1. GUITAR===
The [http://guitar.sourceforge.net/ GUITAR] (GUI Testing frAmewoRk) project helps in simplifying GUI testing by automatically creating test cases that intelligently challenge a GUI's functionality. 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|figure 1:[http://guitar.sourceforge.net/ Guitar Framework]]]

In order to test the GUI of the AUT, the tester has to perform a certain set of steps. These steps are detailed below
*Initialize configurations in GUITAR for the AUT. This can be done using the below window
[[Image:guitar1.jpg|650px|thumb|center|figure 2:[http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/Perform%20Tests%20on%20the%20AUT.htm#Initialise Preferences window for initializing the application type]]]

*Replay the Testcases
[[Image:guitar2.jpg|650px|thumb|center|figure 3:[http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/Perform%20Tests%20on%20the%20AUT.htm#Replayer Testcase execution]]]

*Coverage Evaluation
Execute the coverage evaluator to analyze the coverage generated when the testcases were executed on the instrumented AUT. A coverage report is generated by the instrumented code, when the testcases are replayed on it. The coverage evaluator analyzes this report and a summary report is generated.
[[Image:guitar3.jpg|650px|thumb|center|figure 4:[http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/Perform%20Tests%20on%20the%20AUT.htm#Coverager Running the coverage evaluator]]]

===2. Planning Assisted Tester for grapHical user interface Systems (PATHS)===
This is based on the event interaction sequences. This tests the GUI software using interactions which are mostly likely to be used in actual scenarios. This accepts an operator, initial state and a final state, with which the planning sequence produces a series of sequences which transforms the system form the initial state to the final state. The GUI tester can use this to generate interactions sequences by specifying the final state.

===3. GUIdancer===
[http://www.bredex.de/en/guidancer/first.html GUIdancer] is an [http://en.wikipedia.org/wiki/Eclipse_(software) Eclipse]-based automated GUI test-tool which runs as a standalone application or as an Eclipse Plugin.

GUIdancer is different from other GUI test-tools because automated tests can be written before the Application Under Test (AUT) is ready. This means that GUIdancer is not a tool which tests an application by recording user actions and replaying them. Tests can be created from the requirements without access to the AUT, and involve no programming, script or code. GUIdancer tests can be created, run and maintained without support from automation experts.

Each Test Step (the smallest unit in GUIdancer) consists of three pieces of information chosen from interactive dialogs: the GUI-component to be tested, the action to execute on this component, and the parameters (or data) the action requires. A Test Step to enter “hello” into a text field would look like this:

* GUI-component: Text field
* Action: Enter Text
* Parameter: Hello

===4. SeliniumHQ===
[http://seleniumhq.org/ Selenium] is a robust set of tools that supports rapid development of test automation for web-based applications. Selenium provides a rich set of testing functions specifically geared to the needs of testing of a web application. These operations are highly flexible, allowing many options for locating UI elements and comparing expected test results against actual application behavior.
'''How Selenium Works'''

[[Image:selenium.png|650px|thumb|center|Figure 1:[http://seleniumhq.org/about/how.html How Selenium Works]]]

===6. Cucumber:===
Cucumber is a tool that can execute plain-text functional descriptions as automated tests. The language that Cucumber understands is called [http://wiki.github.com/aslakhellesoy/cucumber/gherkin Gherkin]. Here is an example:
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 |

Cucumber itself is written in Ruby, but it can be used to “test” code written in Ruby or other languages including but not limited to Java, C# and Python. Cucumber only requires minimal use of Ruby programming and Ruby is easy, so don’t be afraid even if the code you’re developing in is not Ruby.

==Conclusion==
In summary, GUI testing is a complicated task. Systematic test design helps us to focus on the important tests and gives us an objective way of addressing risks. Tools are appropriate for many but not all tests and a staged approach to testing enables us to identify which tests to automate much more easily. Tools can therefore be used to detect errors pro-actively as well as to execute regression tests.

=References=
[1] http://c2.com/cgi/wiki?GuiTesting 
[2] http://chandlerproject.org/Journal/AutomatedGuiTestingProject 
[3] http://en.wikipedia.org/wiki/GUI_software_testing 
[4] http://www.open-xchange.com/wiki/index.php?title=Automated_GUI_Tests 
[5] http://agilistas.org/presentations/codecamp06/ 
[6] http://www.ranorex.com/?gclid=CNvA_YnesJ0CFchW2godpT5YrQ 
[7] http://www.gerrardconsulting.com/GUI/TestGui.html 
[8] http://www.slideshare.net/rpires/GUI-Test-Patterns 
[9] http://en.wikipedia.org/wiki/List_of_GUI_testing_tools 
[10] http://www.junit.org/taxonomy/term/6 
[11] http://www.cs.umd.edu/~atif/papers/MemonSQW2000.pdf 
[12] http://www.testingfaqs.org/t-gui.html 
[13] http://www.springerlink.com/content/d08681k5081553r7/ 
[14] http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/Perform%20Tests%20on%20the%20AUT.htm#Rip 
[15] http://seleniumhq.org/ 
[16] http://www2.computer.org/portal/web/csdl/doi/10.1109/COMPSAC.2006.94

CSC/ECE 517 Fall 2009/wiki2 10 mk

2009-10-10T02:44:18Z

Sniper: /* Some problems of GUI testing */

=GUI Testing Frameworks=

==Problem Statement==
Most software developed in recent years has a graphical user interface (GUI). The only way for the end-user to interact with the software application is through the GUI. Hence, acceptance and system testing of the software requires GUI testing. In this wiki we aim at covering the different approaches, including patterns and tools for GUI testing.

==Some problems of GUI testing==
*GUIs are tested manually, often by the developers themselves. This is very unreliable and expensive. For new GUIs or those being significantly changed, quality is low, and failures at integration time or during user acceptance tests are common.
*[http://en.wikipedia.org/wiki/Data_scraping#Screen_scraping ScreenScrapper] based GUI test does a nice job but to a certain extent. Even though they are cheap, the problem with these tests are that if you change the screen layout all existing tests become useless, which means you have no [http://en.wikipedia.org/wiki/Regression_testing regression tests]. Another problem here is that test creators can't start writing tests ill the GUIs are finished. Example: [http://en.wikipedia.org/wiki/Test_harness test harnesses], [http://www.citeulike.org/user/V/article/2682599 capture/replay tools], and [http://en.wikipedia.org/wiki/Model-based_testing model-based methods]
*The user has an extremely wide choice of actions. The user could click on any pixel on the screen using manual tools to mimic the usage of the GUI, only provides limited testing.
*There are tools which try to capture [http://en.wikipedia.org/wiki/GUI_widget GUI widgets] rather than mouse coordinates. These tools, however, require a significant amount of manual effort to be effective, including developing test scripts and manually detecting failures.Modifications to the GUI require changes to the scripts as well. Example: [http://en.wikipedia.org/wiki/HP_WinRunner Winrunner], [http://www.testingfaqs.org/t-gui.html#Abbot Abbot], and [http://www-01.ibm.com/software/awdtools/tester/robot/index.html Rational Robot]

==Approaches for GUI testing==

===1. An Ontology-Based Approach for GUI Testing [http://www2.computer.org/portal/web/csdl/doi/10.1109/COMPSAC.2009.92]===

In the approach an GUI testing [http://en.wikipedia.org/wiki/Ontology ontology] is is established by analyzing the source code with [http://en.wikipedia.org/wiki/Reverse_engineering reverse engineering] techniques. Then from the user experience the generation rules are extracted to create test cases. GUI testing is proposed for the purpose of making use of the knowledge provided by GUI systems and testers’ experience. GUI ontology is used to store potential
information in a GUI system, while test case generation rules extract useful information from testers’ experience. In a word, ontology based GUI testing is a new branch of software testing, which not only takes the knowledge intensive features of GUI testing into account, but also sufficiently make use of them.

===2. Automation of GUI testing using a model-driven approach [http://portal.acm.org/citation.cfm?id=1138932]===
In this approach the generates test cases based on [http://en.wikipedia.org/wiki/Unified_Modeling_Language Unified Modelling Language]. This introduces data into the UML model via the [http://portal.acm.org/citation.cfm?id=62964 Category-Partition method]. The functions that have to be tested are specified using the [http://en.wikipedia.org/wiki/Use_case use cases] and [http://en.wikipedia.org/wiki/Activity_diagram activity diagrams]. This also specifies how they have to be tested. A combination like this has the potential to generate large number of test cases.The test can be managed in two ways.Firstly the Category-partitioned data which allows the designer full control over the possible and impossible paths for the system to run.Secondly automation allows different configuration for both data and graph coverage.Using all this we can generate test scripts which can be used for GUI testing.

[[Image:usecase.png|450px|thumb|center|Figure 1:Example Use Case Diagram]]

===3. Plan Generation GUI testing [http://www.cs.virginia.edu/~soffa/research/SE/AIPS00.pdf]===
This is based on the AI techniques, for partially automating GUI testing.In this method of the testing the tester specifies the initial and the final goal states for the users of the system.The automated system produces a set of sequences or plans which will start with the initial state and end with the final state specified by the user. Each of the plans generated will represent a test case of a user of the system

===4. A practical approach to testing GUI systems [http://www.springerlink.com/content/d08681k5081553r7/]===
In this approach, GUI is divided into two tires. One the component and other the system. [http://en.wikipedia.org/wiki/Control_flow_graph Flow graphs] will be created for each GUI component. The flow graph represents a set of preconditions, event sequences and post conditions of the corresponding component. On the system tire we build a viewpoint by integrating the components of the system. This will ensure that the components are working fine and are interacting as required. This is a simple, effective and practical method of performing GUI testing.

===5. A Dynamic Partitioning Approach for GUI Testing [http://www2.computer.org/portal/web/csdl/doi/10.1109/COMPSAC.2006.94]===
The above approaches specify how to generate the test cases without actually specifying how to run them. This approach specifies how the test cases have to run in order to make GUI testing effective and useful. Th GUI primitive actions are partitioned into two classes. They are prioritized primitive actions and non-prioritized primitive actions. This further divides the testing into two stages which contains two feed back loops.The first stage prioritizes primitive actions and the second stage selects and performs prioritized primitive actions. The first feedback loop is local and occurs in the second stage, which adjusts the memberships of primitive actions after they are performed. The second feedback loop is global and occurs between the first and second stages. It switches GUI testing from the second stage to the first stage upon no prioritized primitive actions are available. The two testing experiments with real GUI applications show that the proposed dynamic partitioning approach can really work in practice and may significantly outperform the random testing approach.

==Tools for GUI testing==
===1. GUITAR===
The [http://guitar.sourceforge.net/ GUITAR] (GUI Testing frAmewoRk) project which helps in simplifying GUI testing by automatically creating test cases that intelligently challenge a GUI's functionality. 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|figure 1:[http://guitar.sourceforge.net/ Guitar Framework]]]

In order to test the GUI of the AUT, the tester has to perform a certain set of steps. These steps are detailed below
*Initialize configurations in GUITAR for the AUT. This can be done using the below window
[[Image:guitar1.jpg|650px|thumb|center|figure 2:[http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/Perform%20Tests%20on%20the%20AUT.htm#Initialise Preferences window for initializing the application type]]]

*Replay the Testcases
[[Image:guitar2.jpg|650px|thumb|center|figure 3:[http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/Perform%20Tests%20on%20the%20AUT.htm#Replayer Testcase execution]]]

*Coverage Evaluation
Execute the coverage evaluator to analyze the coverage generated when the testcases were executed on the instrumented AUT. A coverage report is generated by the instrumented code, when the testcases are replayed on it. The coverage evaluator analyzes this report and a summary report is generated.
[[Image:guitar3.jpg|650px|thumb|center|figure 4:[http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/Perform%20Tests%20on%20the%20AUT.htm#Coverager Running the coverage evaluator]]]

===2. Planning Assisted Tester for grapHical user interface Systems (PATHS)===
This is based on the event interaction sequences. This tests the GUI software using interactions which are mostly likely to be used in actual scenarios. This accepts an operator, initial state and a final state, with which the planning sequence produces a series of sequences which transforms the system form the initial state to the final state. The GUI tester can use this to generate interactions sequences by specifying the final state.

===3. GUIdancer===
[http://www.bredex.de/en/guidancer/first.html GUIdancer] is an [http://en.wikipedia.org/wiki/Eclipse_(software) Eclipse]-based automated GUI test-tool which runs as a standalone application or as an Eclipse Plugin.

GUIdancer is different from other GUI test-tools because automated tests can be written before the Application Under Test (AUT) is ready. This means that GUIdancer is not a tool which tests an application by recording user actions and replaying them. Tests can be created from the requirements without access to the AUT, and involve no programming, script or code. GUIdancer tests can be created, run and maintained without support from automation experts.

Each Test Step (the smallest unit in GUIdancer) consists of three pieces of information chosen from interactive dialogs: the GUI-component to be tested, the action to execute on this component, and the parameters (or data) the action requires. A Test Step to enter “hello” into a text field would look like this:

* GUI-component: Text field
* Action: Enter Text
* Parameter: Hello

===4. SeliniumHQ===
[http://seleniumhq.org/ Selenium] is a robust set of tools that supports rapid development of test automation for web-based applications. Selenium provides a rich set of testing functions specifically geared to the needs of testing of a web application. These operations are highly flexible, allowing many options for locating UI elements and comparing expected test results against actual application behavior.
'''How Selenium Works'''

[[Image:selenium.png|650px|thumb|center|Figure 1:[http://seleniumhq.org/about/how.html How Selenium Works]]]

===6. Cucumber:===
Cucumber is a tool that can execute plain-text functional descriptions as automated tests. The language that Cucumber understands is called [http://wiki.github.com/aslakhellesoy/cucumber/gherkin Gherkin]. Here is an example:
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 |

Cucumber itself is written in Ruby, but it can be used to “test” code written in Ruby or other languages including but not limited to Java, C# and Python. Cucumber only requires minimal use of Ruby programming and Ruby is easy, so don’t be afraid even if the code you’re developing in is not Ruby.

==Conclusion==
In summary, GUI testing is a complicated task. Systematic test design helps us to focus on the important tests and gives us an objective way of addressing risks. Tools are appropriate for many but not all tests and a staged approach to testing enables us to identify which tests to automate much more easily. Tools can therefore be used to detect errors pro-actively as well as to execute regression tests.

=References=
[1] http://c2.com/cgi/wiki?GuiTesting 
[2] http://chandlerproject.org/Journal/AutomatedGuiTestingProject 
[3] http://en.wikipedia.org/wiki/GUI_software_testing 
[4] http://www.open-xchange.com/wiki/index.php?title=Automated_GUI_Tests 
[5] http://agilistas.org/presentations/codecamp06/ 
[6] http://www.ranorex.com/?gclid=CNvA_YnesJ0CFchW2godpT5YrQ 
[7] http://www.gerrardconsulting.com/GUI/TestGui.html 
[8] http://www.slideshare.net/rpires/GUI-Test-Patterns 
[9] http://en.wikipedia.org/wiki/List_of_GUI_testing_tools 
[10] http://www.junit.org/taxonomy/term/6 
[11] http://www.cs.umd.edu/~atif/papers/MemonSQW2000.pdf 
[12] http://www.testingfaqs.org/t-gui.html 
[13] http://www.springerlink.com/content/d08681k5081553r7/ 
[14] http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/Perform%20Tests%20on%20the%20AUT.htm#Rip 
[15] http://seleniumhq.org/ 
[16] http://www2.computer.org/portal/web/csdl/doi/10.1109/COMPSAC.2006.94

CSC/ECE 517 Fall 2009/wiki2 10 mk

2009-10-10T02:44:01Z

Sniper: /* Some problems of GUI testing */

=GUI Testing Frameworks=

==Problem Statement==
Most software developed in recent years has a graphical user interface (GUI). The only way for the end-user to interact with the software application is through the GUI. Hence, acceptance and system testing of the software requires GUI testing. In this wiki we aim at covering the different approaches, including patterns and tools for GUI testing.

==Some problems of GUI testing==
*GUIs are tested manually, often by the developers themselves. This is very unreliable and expensive. For new GUIs or those being significantly changed, quality is low, and failures at integration time or during user acceptance tests are common.
*[http://en.wikipedia.org/wiki/Data_scraping#Screen_scraping ScreenScrapper] based GUI test does a nice job but to a certain extent. Even though they are cheap, the problem with these tests are that if you change the screen layout all existing tests become useless, which means you have no [http://en.wikipedia.org/wiki/Regression_testing regression tests]. Another problem here is that test creators can't start writing tests ill the GUIs are finished. Example: [http://en.wikipedia.org/wiki/Test_harness test harnesses], [http://www.citeulike.org/user/V/article/2682599 capture/replay tools], and [http://en.wikipedia.org/wiki/Model-based_testing model-based methods]
*The user has an extremely wide choice of actions. The user could click on any pixel on the screen using manual tools to mimic the usage of the GUI, only provides limited testing.
*There are tools which try to capture [http://en.wikipedia.org/wiki/GUI_widget GUI widgets] rather than mouse coordinates. These tools, however, require a significant amount of manual effort to be effective, including developing test scripts and manually detecting failures.Modifications to the GUI require changes to the scripts as well. Example: [http://en.wikipedia.org/wiki/HP_WinRunner Winrunner], [http://www.testingfaqs.org/t-gui.html#Abbot Abbot], and [http://www-01.ibm.com/software/awdtools/tester/robot/index.html Rational Robot]

h

==Approaches for GUI testing==

===1. An Ontology-Based Approach for GUI Testing [http://www2.computer.org/portal/web/csdl/doi/10.1109/COMPSAC.2009.92]===

In the approach an GUI testing [http://en.wikipedia.org/wiki/Ontology ontology] is is established by analyzing the source code with [http://en.wikipedia.org/wiki/Reverse_engineering reverse engineering] techniques. Then from the user experience the generation rules are extracted to create test cases. GUI testing is proposed for the purpose of making use of the knowledge provided by GUI systems and testers’ experience. GUI ontology is used to store potential
information in a GUI system, while test case generation rules extract useful information from testers’ experience. In a word, ontology based GUI testing is a new branch of software testing, which not only takes the knowledge intensive features of GUI testing into account, but also sufficiently make use of them.

===2. Automation of GUI testing using a model-driven approach [http://portal.acm.org/citation.cfm?id=1138932]===
In this approach the generates test cases based on [http://en.wikipedia.org/wiki/Unified_Modeling_Language Unified Modelling Language]. This introduces data into the UML model via the [http://portal.acm.org/citation.cfm?id=62964 Category-Partition method]. The functions that have to be tested are specified using the [http://en.wikipedia.org/wiki/Use_case use cases] and [http://en.wikipedia.org/wiki/Activity_diagram activity diagrams]. This also specifies how they have to be tested. A combination like this has the potential to generate large number of test cases.The test can be managed in two ways.Firstly the Category-partitioned data which allows the designer full control over the possible and impossible paths for the system to run.Secondly automation allows different configuration for both data and graph coverage.Using all this we can generate test scripts which can be used for GUI testing.

[[Image:usecase.png|450px|thumb|center|Figure 1:Example Use Case Diagram]]

===3. Plan Generation GUI testing [http://www.cs.virginia.edu/~soffa/research/SE/AIPS00.pdf]===
This is based on the AI techniques, for partially automating GUI testing.In this method of the testing the tester specifies the initial and the final goal states for the users of the system.The automated system produces a set of sequences or plans which will start with the initial state and end with the final state specified by the user. Each of the plans generated will represent a test case of a user of the system

===4. A practical approach to testing GUI systems [http://www.springerlink.com/content/d08681k5081553r7/]===
In this approach, GUI is divided into two tires. One the component and other the system. [http://en.wikipedia.org/wiki/Control_flow_graph Flow graphs] will be created for each GUI component. The flow graph represents a set of preconditions, event sequences and post conditions of the corresponding component. On the system tire we build a viewpoint by integrating the components of the system. This will ensure that the components are working fine and are interacting as required. This is a simple, effective and practical method of performing GUI testing.

===5. A Dynamic Partitioning Approach for GUI Testing [http://www2.computer.org/portal/web/csdl/doi/10.1109/COMPSAC.2006.94]===
The above approaches specify how to generate the test cases without actually specifying how to run them. This approach specifies how the test cases have to run in order to make GUI testing effective and useful. Th GUI primitive actions are partitioned into two classes. They are prioritized primitive actions and non-prioritized primitive actions. This further divides the testing into two stages which contains two feed back loops.The first stage prioritizes primitive actions and the second stage selects and performs prioritized primitive actions. The first feedback loop is local and occurs in the second stage, which adjusts the memberships of primitive actions after they are performed. The second feedback loop is global and occurs between the first and second stages. It switches GUI testing from the second stage to the first stage upon no prioritized primitive actions are available. The two testing experiments with real GUI applications show that the proposed dynamic partitioning approach can really work in practice and may significantly outperform the random testing approach.

==Tools for GUI testing==
===1. GUITAR===
The [http://guitar.sourceforge.net/ GUITAR] (GUI Testing frAmewoRk) project which helps in simplifying GUI testing by automatically creating test cases that intelligently challenge a GUI's functionality. 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|figure 1:[http://guitar.sourceforge.net/ Guitar Framework]]]

In order to test the GUI of the AUT, the tester has to perform a certain set of steps. These steps are detailed below
*Initialize configurations in GUITAR for the AUT. This can be done using the below window
[[Image:guitar1.jpg|650px|thumb|center|figure 2:[http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/Perform%20Tests%20on%20the%20AUT.htm#Initialise Preferences window for initializing the application type]]]

*Replay the Testcases
[[Image:guitar2.jpg|650px|thumb|center|figure 3:[http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/Perform%20Tests%20on%20the%20AUT.htm#Replayer Testcase execution]]]

*Coverage Evaluation
Execute the coverage evaluator to analyze the coverage generated when the testcases were executed on the instrumented AUT. A coverage report is generated by the instrumented code, when the testcases are replayed on it. The coverage evaluator analyzes this report and a summary report is generated.
[[Image:guitar3.jpg|650px|thumb|center|figure 4:[http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/Perform%20Tests%20on%20the%20AUT.htm#Coverager Running the coverage evaluator]]]

===2. Planning Assisted Tester for grapHical user interface Systems (PATHS)===
This is based on the event interaction sequences. This tests the GUI software using interactions which are mostly likely to be used in actual scenarios. This accepts an operator, initial state and a final state, with which the planning sequence produces a series of sequences which transforms the system form the initial state to the final state. The GUI tester can use this to generate interactions sequences by specifying the final state.

===3. GUIdancer===
[http://www.bredex.de/en/guidancer/first.html GUIdancer] is an [http://en.wikipedia.org/wiki/Eclipse_(software) Eclipse]-based automated GUI test-tool which runs as a standalone application or as an Eclipse Plugin.

GUIdancer is different from other GUI test-tools because automated tests can be written before the Application Under Test (AUT) is ready. This means that GUIdancer is not a tool which tests an application by recording user actions and replaying them. Tests can be created from the requirements without access to the AUT, and involve no programming, script or code. GUIdancer tests can be created, run and maintained without support from automation experts.

Each Test Step (the smallest unit in GUIdancer) consists of three pieces of information chosen from interactive dialogs: the GUI-component to be tested, the action to execute on this component, and the parameters (or data) the action requires. A Test Step to enter “hello” into a text field would look like this:

* GUI-component: Text field
* Action: Enter Text
* Parameter: Hello

===4. SeliniumHQ===
[http://seleniumhq.org/ Selenium] is a robust set of tools that supports rapid development of test automation for web-based applications. Selenium provides a rich set of testing functions specifically geared to the needs of testing of a web application. These operations are highly flexible, allowing many options for locating UI elements and comparing expected test results against actual application behavior.
'''How Selenium Works'''

[[Image:selenium.png|650px|thumb|center|Figure 1:[http://seleniumhq.org/about/how.html How Selenium Works]]]

===6. Cucumber:===
Cucumber is a tool that can execute plain-text functional descriptions as automated tests. The language that Cucumber understands is called [http://wiki.github.com/aslakhellesoy/cucumber/gherkin Gherkin]. Here is an example:
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 |

Cucumber itself is written in Ruby, but it can be used to “test” code written in Ruby or other languages including but not limited to Java, C# and Python. Cucumber only requires minimal use of Ruby programming and Ruby is easy, so don’t be afraid even if the code you’re developing in is not Ruby.

==Conclusion==
In summary, GUI testing is a complicated task. Systematic test design helps us to focus on the important tests and gives us an objective way of addressing risks. Tools are appropriate for many but not all tests and a staged approach to testing enables us to identify which tests to automate much more easily. Tools can therefore be used to detect errors pro-actively as well as to execute regression tests.

=References=
[1] http://c2.com/cgi/wiki?GuiTesting 
[2] http://chandlerproject.org/Journal/AutomatedGuiTestingProject 
[3] http://en.wikipedia.org/wiki/GUI_software_testing 
[4] http://www.open-xchange.com/wiki/index.php?title=Automated_GUI_Tests 
[5] http://agilistas.org/presentations/codecamp06/ 
[6] http://www.ranorex.com/?gclid=CNvA_YnesJ0CFchW2godpT5YrQ 
[7] http://www.gerrardconsulting.com/GUI/TestGui.html 
[8] http://www.slideshare.net/rpires/GUI-Test-Patterns 
[9] http://en.wikipedia.org/wiki/List_of_GUI_testing_tools 
[10] http://www.junit.org/taxonomy/term/6 
[11] http://www.cs.umd.edu/~atif/papers/MemonSQW2000.pdf 
[12] http://www.testingfaqs.org/t-gui.html 
[13] http://www.springerlink.com/content/d08681k5081553r7/ 
[14] http://www.cs.umd.edu/~atif/GUITAR-distribution/manuals/Perform%20Tests%20on%20the%20AUT.htm#Rip 
[15] http://seleniumhq.org/ 
[16] http://www2.computer.org/portal/web/csdl/doi/10.1109/COMPSAC.2006.94

CSC/ECE 517 Fall 2009/wiki1a 9 mk

2009-09-09T21:37:07Z

Sniper: /* Conclusion */

=Research in Refactoring Tools=

==Refactoring==

Refactoring is the process of modifying existing source codebase in a structured and incremental
way while preserving its external behavior. This process preserves the functionality of the program
without introducing new bugs. Refactoring also promotes reuse of the existing [http://en.wikipedia.org/wiki/Codebase codebase] for other purposes thus increasing code reusability.

==Overview==

One of the most important aspect of any software meant for real world applications is its ability to evolve.Many surveys conducted by major software organizations have reavealed that, maintenance is the major part of the total [http://en.wikipedia.org/wiki/Systems_Development_Life_Cycle Software Development life cycle]. Maintenance of the code would be much less difficult, if the code has the capacity to evolve, where in refactoring comes into picture.
Refactoring improves the internal structure of the codebase keeping the behaviour/functionality of the program same as before and therefore any program which meets its specifications before refactoring will
continue to meet those specifications even afterwards. Refactoring can be done on any codebase and it
is a general set of operations. Hence, it comes with preconditions which specifies under what circumstances
refactoring can be performed, also with the conformation that the dependency graphs are unchanged even after the
refactoring is performed.

Code smell:
[http://en.wikipedia.org/wiki/Code_smell Code smell] is the surface indication that usually corresponds to problem in the code [system].

So of the common code smell examples are:
*A class that has grown too large.
*A class that uses methods of another class excessively.
*Classes that depend on the implementation details of other classes.
*Identical or very similar code exists in more than one location.
*A class that does too little or which can be implemented as a method in some other class.
*A method, function, or procedure that has grown too large.
*A method, function, or procedure that is very similar to another.
*A situation where in a complicated design pattern is chosen over a simple design which would be sufficient.

These are some of the indications that code refactoring needs to be done. Code Refactoring is done to remove the above specified code smells.

Code Smell(Duplicate Code) example

if (this.o.ChkSum()) {
Operation1();
}

and in another method you have:

if (this.o.ChkSum()) {
Operation2();
}

==Current Automated Refactoring Tools==

Most of Refactoring tool features can be grouped into three broad categories.

1. Changing the name and physical organization of code, including renaming fields, variables, classes,
and [http://en.wikipedia.org/wiki/Interface_(computer_science) interfaces], and moving [http://en.wikipedia.org/wiki/Software_package_(programming) packages] and classes.

2. Changing the logical organization of code at the class level, including turning [http://en.wikipedia.org/wiki/Class_(computer_science) anonymous classes]
into nested classes, turning nested classes into top-level classes, creating interfaces from
concrete classes, and moving methods or fields from a class to a subclass or superclass.

3. Changing the code within a class, including turning local variables into class fields, turning
selected code in a method into a separate method, and generating getter and setter methods for
fields.

Given below is an example of Refactoring, demonstrating how it enhances reusability

void displayValues() {
double averageSalary = 0;
double totalCars = 0;
for (int i = 0; i < people.length; i++) {
averageSalary += people[i].salary;
totalCars += people[i].carCount;
}
averageSalary = averageSalary / people.length;
System.out.println(averageSalary);
System.out.println(totalCars);
}

The refactored code:

void printValues() {
System.out.println(averageSalary());
System.out.println(totalCars());
}

private double averageSalary() {
double result = 0;
for (int i = 0; i < people.length; i++) {
result += people[i].salary;
}
return result / people.length;
}

private double totalCars() {
double result = 0;
for (int i = 0; i < people.length; i++) {
result += people[i].carCount;
}
return result;
}

Given below is the list of most used automated refactoring tools

* [http://en.wikipedia.org/wiki/Aptana Aptana for Ruby](Can be used as a Plug-in for Eclipse)
* [http://en.wikipedia.org/wiki/IntelliJ_IDEA IntelliJ IDEA]
* [http://en.wikipedia.org/wiki/Eclipse_(software) Eclipse's JDT]
* [http://en.wikipedia.org/wiki/NetBeans NetBeans] (for Java)
* [http://en.wikipedia.org/wiki/Microsoft_Visual_Studio Visual Studio 2008] (for .NET)
* [http://en.wikipedia.org/wiki/ReSharper ReSharper] (An addon for Visual Studio)
* [http://weblogs.asp.net/bsimser/archive/2006/03/02/439473.aspx Refactor Pro] (An addon for Visual Studio)

==Academic underpinnings behind the refactoring work==
[http://en.wikipedia.org/wiki/William_Opdyke William F. Opdyke], who is one of the important person behind the success of refactoring, was the first to think in the lines of "why people could be reluctant to refactor their software, given that refactoring improves the software.They found mainly four reasons

1. "I don't understand how to refactor."

2. "If the benefits are long-term, why exert the effort now? In the long term, I may no longer be with the project.”

3. "Refactoring code is an overhead activity; I’m paid to write new features."

4. "Refactoring might break the code."

The first two issues were addressed by defining a taxonomy of refactoring, which helped both in short term as well as in long term. For example, when defining a new feature that is a variant on
an existing feature, one can define classes (usually [http://en.wikipedia.org/wiki/Abstract_type abstract] classes) that
capture the common behavior, and use subclassing to capture the feature
differences.
The approach for addressing the latter two of these issues was by providing automated assistance, which help to increase the speed of program restructuring.

William F. Opdyke, in one his other research found that, object-oriented programming makes program components more reusable, but in the long run reusing the design of an application is more important than reusing the implementation of any
one of its components. An important object-oriented technique to facilitate design-level reuse is an application frame-
work, which is an abstract design of an application, consisting of an abstract class for each
major component. The important aspects of the framework are given below, most of which are self explainatory

* Preserving Behavior During Refactoring: Refactoring is likely to violate seven properties: a class is allowed to have no more than one superclass, which cannot be one of its subclasses; class names and memeber names must be distinct; inherited member variables should not be overridden; signatures compatibility between [http://en.wikipedia.org/wiki/Method_overriding overriding] methods and the overridden method; assignments must always be [http://en.wikipedia.org/wiki/Type_safety typesafe]; semantic equivalence between references and operations i.e., the mapping of inputs to outputs must be the same.

* Twenty-six low-level refactorings whose correctness is argued, fall in one of the categories:Creating a Program Entity, Deleting a Program Entity, Changing Program Entity, Moving a member variables.

* Refactoring To Generalize: Creating An [http://en.wikipedia.org/wiki/Abstract_type Abstract] Super-class involves, identifying and moving common features between classes to an abstract superclass.

* Refactoring To Specialize: Subclassing and Simplifying Conditionals.

* Capturing [http://en.wikipedia.org/wiki/Object_composition Aggregations and Components]: Refactorings involving aggregations include moving members between an aggregate and component classes and converting inheritance to aggregation. These require that components be distinguishable from non-component members and that all components be exclusive, i.e., exist in only one aggregate object at any time. We take a Matrix and 2D array example to demonstrate, why refactoring preferably converts inheritance to aggregation. Matrix class inheriting from 2D array, which in turn has an array to store elements and get/set operations to access elements, seems resonable at one glance. Lets take a function of matrix multiply as shown below

Matrix matrixMultiply(Matrix m){
j=get(x,y);
put(k,x,y);
...
...
}
There is a problem with this representation because, if a matrix is a special matrix like [http://en.wikipedia.org/wiki/Sparse_matrix sparse], it can be more efficiently stored than storing in a 2D array. In inheritance, the matrix class is tighlty coupled to the 2D class, so it cannot be changed. A matrix ''has a representation'' and is ''not a representation''. So, the operations on abstraction and representation class need to be separated.So, we introduce a new class Matrix representation and we can create an instance of 2D array class inside the aggregate of Matrix class given as below.

Matrix matrixMultiply(Matrix m){
j=matrixRep->get(x,y);
matrixRep->put(k,x,y);
...
...
}

Now, the get and set are referenced through new component and inheritance link can be modified.

==Improvements Current Refactoring Tools need==

Tools that help the programmers with refactoring should:

* Be lightweight. Users can normally [http://www.acm.org/src/subpages/murphy-hill/acm_src_final.html select code quickly] and efficiently, and any tool to assist selection should not add overhead to slow down the common case.

* Help the programmer overcome unfamiliar or unusual code formatting.

* Allow the programmer to select code in a manner specific to the task they are performing. For example, while bracket matching can be helpful, bracketed statements are not the only meaningful program construct that a programmer needs to select.

* Language Independent, all of the current refactoring tools depend on language-dependent refactoring engines, which prevents a smooth integration with mainstream development environments.They should minimize the language-dependent part of refactoring tools, providing a standard way for programmers and tools to perform refactorings no matter what language they work in.
** Meta-model Approach
*:Program Auditing facilities like [http://en.wikipedia.org/wiki/Unified_Modeling_Language UML] diagrams, documentation etc help in understanding the programs better and a tight integration between these auditing facilities and refactory tools will be real good. Most commonly, integration in software development environments is achieved by means of a repository: a shared database accumulating all knowledge about the software system underdevelopment. Thus, for refactoring tools to become part of mainstream software development environments, the most natural way would be to adhere to a repository architecture. Such a repository architecture requires a central data model (the so-called meta-model) which should be highly language independent and contain sufficient information to represent refactorings.

* Capable of performing Security Oriented transformation, which mean automated transformations that change programs to eliminate security threats;they can be source to source or binary to binary transformations. They improve the security of systems, which means that they do not preserve all types of behavior (although this is against the very definition of refactoring). They preserve expected behavior, but should change a system’s response to security attacks.

==Conclusion==

Refactoring is an integral part of all software development projects and it is very important for refactoring tools to make refactoring fast and functionality preserving. There are many improvements that have been suggested for code refactoring and it is required that it gets implemented to reduce code smell, provide easier understanding of code, as well as re usability of code. These qualities will be adopted by new refactoring tools, making them usable and thus more used, and eventually contribute to the production of more reliable, on-time refactored software. It is also important that the refactoring tools improve the experience of refactoring, help programmers correctly identify problems with a proposed refactoring, and increase speed of the refactoring process.

==See Also==
* [http://books.google.com/books?id=1MsETFPD3I0C&dq=refactoring+fowler&printsec=frontcover&source=bn&hl=en&ei=cMimSqP0J5GCtgeAkb2ZCA&sa=X&oi=book_result&ct=result&resnum=4#v=onepage&q=&f=false Refactoring: Improving the Design of Existing Code by Martin Fowler, Kent Beck, John Brant]
* [http://en.wikipedia.org/wiki/Design_pattern_(computer_science) Design pattern (computer science)]
* [http://en.wikipedia.org/wiki/Code_refactoring Code Factoring]
* [http://en.wikipedia.org/wiki/Redesign_(software) Redesign (software)]

==References==
[1] http://www.refactoring.com 
[2] https://netfiles.uiuc.edu/dig/RefactoringInfo/ 
[3] William F. Opdyke. Refactoring Object-Oriented Frameworks. Ph.D.thesis, University of Illinois at Urbana-Champaign, 1992. 
[4] A Meta-model for Language-Independent Refactoring (2000) Sander Tichelaar , Stéphane Ducasse , Serge Demeyer , Oscar Nierstrasz 
[5] Refactoring Object-Oriented Software to Support Evolution and Reuse, William F. Opdyke 
[6] Security Oriented ProgramTransformations (Or How to Add Security on Demand), Munawar Hafiz