Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2009/wiki3 21 MobileDesignPattern

2009-11-19T15:13:49Z

Wolverine: /* Ways to Adapt Using Design Patterns */

== Design Pattern for Mobile Applications ==

The popularity of mobile applications is rising. Design patterns are useful in almost any coding tasks. While almost any design pattern could be used within mobile applications, certain patterns are well suited for the unique environment of mobile applications. This wiki explains the mobile application environment, then focuses on design patterns that work well within this new emerging environment.

__TOC__

== The Mobile Application Environment ==

The mobile application environment is new and presents many unique opportunities and challenges for developers. It seems almost everyone now has a cellphone, blackberry, or other small portable device. These devices are "getting smarter" in that many people are developing new applications for them. Cell phones no longer are just used to call people, they often have features like text messaging, cameras, video games, web browsers and more. There is much opportunity for developers to write new applications for mobile devices.

While opportunity abounds, there are also quite a few challenges. Mobile applications have less resources than are typically found in other development environments. The screen on mobile devices is typically smaller, there is usually not a keyboard and mouse (user inputs are reduced) [5]. CPU resources are generally less than those found in the typical environment [7]. Power usage is also limited because a battery is typically used, so reducing power use by the application is an important goal [7]. Connections are typically expensive and are often prone to loss of signals [6].

Another problem is that there is a high demand for applications to be developed quickly [7]. The mobile environment is changing rapidly [2]. Some of the lower level programming languages were useful because they produced fast applications, but they took too long to develop with[22 http://www.umsl.edu/~subramaniana/concepts1.html]. Now, with the increased demand for applications quickly, Object Oriented Programming (OOP) is used more. While this causes a greater usage of resources, this is outweighed by the much quicker development cycle and the re-use of code. In particular, good solutions may be re-used in OOP [7].

In the mobile environment, applications are often written on different operating systems [http://en.wikipedia.org/wiki/Mobile_operating_system] on different mobile systems. There is increased interaction between mobile systems, especially for cell phones. The Service Oriented Architecture design pattern is especially well suited for this situation. This is a fairly new field, and methods are currently being developed to aid developers.

== Ways to Adapt Using Design Patterns ==

Several principles and patterns have been understood and developed in developing for mobile applications. Many of these methods are still undergoing change and experimentation. There are new methods being developed and others left behind. A design pattern can be defined as a repeatable solution to a common problem in software. It is a template for how to solve the problem, not actual code [7].

Ease of navigation is a particularly important principle, because of the reduced number of user inputs (for example, buttons from 0 to 9 instead of a mouse and keyboard). Everything in an application should be no more than three clicks away. If a program is too "deep", requiring many clicks, this will be a problem because it takes longer to navigate on a mobile device. If the application is to "broad" as in too many links on one page, the data may not all fit on the screen. One way to mitigate this problem is to reduce functionality, to keep the application as simple as possible [5].

The [http://www.javaworld.com/javaworld/jw-10-2005/jw-1003-mvc.html Model View Controller] pattern [1] fits the mobile environment well. Models may be set up so that optimum data structures are used, as was discussed for the EC Factory pattern [7]. Effecient designs may be built into the controllers. Views may be standardized for the application to handle the small screens.

We will now discuss few important ones. 

Two major design patterns that have come up to help in mobile softwares and to address the above discussed issues in a mobile device are : Energy Conscious design pattern and Mobile agent design pattern

=== Energy Conscious Factory Design ===
According to the research published in ''[10]''

Power consumption has not been much of a concern to developers in the past, but this is important in the mobile environment. Battery power on cell phones is limited. [7]
- Use registers instead of memory whenever possible (registers use less energy)
- Use structs instead of classes
- Use static instead of dynamic

Some strategies and their experimental results are discussed in [10]: 
[[Image:ECFactory_Fig8.jpg| General Strategies]]

'''''Factory Method pattern''''' is a pattern that returns an object from one of various possible classes. Which class is chosen to be an object generator is depended on data provided to it.
Factory Method Pattern is a good pattern to build upon for energy conscious pattern. 
Lets look at both versions. 
Class Diagram of sample Factory Method pattern::
[[Image:ECFactory_Fig1.jpg|Class Diagram of sample Factory Method pattern ]]

Sequence Diagram (with Activations) of sample Factory Method pattern ::
[[Image:ECFactory_Fig2.jpg|Sequence Diagram (with Activations) of sample Factory Method pattern ]]

'''''Modified Factory Method pattern'''''
As regular Factory Method pattern was not designed for being energy concerned, so, it is slightly modified. Some of the critical tweaks are:
*Factory Method Pattern that mixes usage of struct and class in several manners.
*Factory Method Pattern that uses static factory method in Factory struct
*Factory Method Pattern that applies generics principle which is parametered type
*Factory Method Pattern That Uses ConcreteProduct Class, ConcreteCreator Struct with Non-Static FactoryMethod()

Modified Factory Method pattern applies both struct and class recommendations.

''Factory Method Pattern That Uses ConcreteProduct Class, ConcreteCreator Struct with Non-Static FactoryMethod()::''
[[Image:ECFactory_Fig3.jpg|Class Diagram of Factory Method pattern]]

In this case, we use VehicleChooser which is a ConcreteCreator as struct while Car, Plane and Ship which are ConcreteProduct as class. Method ChooseVehicle(...) which is as FactoryMethod() is non-static.

''Factory Method Pattern That Uses ConcreteProduct Struct, ConcreteCreator Struct with Static FactoryMethod()::''
[[Image:ECFactory_Fig4.jpg|Class Diagram of Factory Method pattern]] 
If we use static method appropriately, CPU workload will be reduced. This affects directly in lessening power consumption as a whole.

'''''Experimental Result:'''''
 For various combination shown in figure, the tests were run, and the result obtained are shown in the graph below.
 ''Characteristic of components in each combination::''
[[Image:ECFactory_Fig5.jpg|Characteristic of components in each combination ]] 

''CPU Usage Comparison ::''
[[Image:ECFactory_Fig6.jpg|CPU Usage Comparison ]] 
UPT is utilized processor time and TPT is total processor time

 ''Energy Usage Comparison::''

[[Image:ECFactory_Fig7.jpg|Energy Usage Comparison]] 

It is observed that Energy Concerned Factory Method Pattern can be obtained from the combination of ConcreteProduct classes and ConcreteCreator struct with static FactoryMethod(). The ECFactory Method Pattern consumes less CPU time than regular Factory Method Pattern around 11% while it is better than the worst case around 80%. The bigger the ConcreteProduct type size is, the more range between the best and the worst case in term of energy consumption will be.
So it is clearly proven how this pattern can save energy.

===Service Oriented Architecture ===
Service Oriented Architectures are well suited for the mobile environment [3]. Within this architecture, applications can make use of various services by sending messages to them via a protocol. Applications may interact with services on operating systems and written in different languages, as long as the protocol is followed. Services may be located on different mobile devices. This protocol is a good fit, allowing applications to reach out to services on other mobile devices, even though they may be on very different devices.

''Example of an SOA::''
[[Image:SOA_Example.jpg]]

===Meeting pattern Example===
According to the research published in [6]. 
The meeting pattern is especially useful in mobile environments. One device or application serves as the meeting manager. The meeting manager coordinates and tracks the other agents (programs or applications). These agents communicate with the oversight of the meeting manager. Agents may be located on different devices, even on computers with more resources. This is especially well suited for the mobile environment because it is a good way to manage the communications and relatively small applications. A further benefit of the meeting pattern is that mobile applications may be combined (somewhat in the fashion of parallel computing) to do more and provide more resources [6].

''Meeting pattern Example::''

[[Image:MCFigure3.jpg]]

The master slave pattern is simmilar to the meeting pattern. Instead of a meeting manager and agents, there is a master that creates, uses, and destroys slave objects. The master assigns the slaves tasks to complete. Like agents in the meeting pattern, slaves may be located on different mobile devices, or even on computers that have more resources. The master / slave pattern is very useful for performing actions in parallel on different mobile devices [6].

== Conclusion ==
In conclusion, certain design patterns are especially useful in the mobile design environment. These patterns help developers to produce applications quickly and applications which make efficient use of the limited resources in the mobile environment. Most design patterns can be of benefit to mobile applications, but certain patterns have features that are especially well suited. The EC factory pattern was designed for the mobile environment to reduce energy use [7]. A few other patterns show much promise with mobile devices, including the meeting pattern, master / slave pattern, and service oriented architectures.

== References ==

1. http://www.javaworld.com/javaworld/jw-10-2005/jw-1003-mvc.html - Model View Controller Architecture

2. http://patterns.littlespringsdesign.com/index.php/The_mobile_challenge - Challenges of the Mobile Environment

3. http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki2_17_va - Service Oriented Architecture

4. http://wiki.forum.nokia.com/index.php/Understading_Desing_Patterns - Understanding Design Patterns

5. http://dev.opera.com/articles/view/designing-and-developing-mobile-web-site/ - Designing and Developing mobile web sites in the real world

6. Emerson F.A Lima, Patrícia D. L. Machado, Fláavio R. Sampaio, and Jorge C. A. Figueiredo. ACM SIGSOFT Software Engineering Notes. Volume 29, issue 3 ISSN: 0163-5948 http://portal.acm.org/citation.cfm?id=986710.986726 Universidade Federal de Campina Grande, Paraíba, Brazil, May, 2004.

7. Kayun Chantarasathaporn, Chonawat Srisa-an. ACM International Conference Proceeding Series; Vol. 270 Proceedings of the 3rd international conference on Mobile technology, applications & systems SESSION: Mobile applications, article 29. ISBN:1-59593-519-3 http://portal.acm.org/citation.cfm?id=1292331.1292364 Bangkok, Thailand, 2006

8. WIM Workshop,Uppsala, 17.9.2004

9. Mobile Application Development, Sam Nasr , www.CleavelandDotNet.info

10. Energy Conscious Factory Method Design Pattern for Mobile Devices with C# and Intermediate Language, by Kayun Chantarasathaporn and Chonawat Srisa-an, Ph.D. at Faculty of Information Technology, Rangsit University, Thailand.

11. http://www.codeproject.com/csharp/structs_in_csharp.asp

CSC/ECE 517 Fall 2009/wiki3 21 MobileDesignPattern

2009-11-19T15:07:33Z

Wolverine: /* Energy Conscious Factory Design */

== Design Pattern for Mobile Applications ==

The popularity of mobile applications is rising. Design patterns are useful in almost any coding tasks. While almost any design pattern could be used within mobile applications, certain patterns are well suited for the unique environment of mobile applications. This wiki explains the mobile application environment, then focuses on design patterns that work well within this new emerging environment.

__TOC__

== The Mobile Application Environment ==

The mobile application environment is new and presents many unique opportunities and challenges for developers. It seems almost everyone now has a cellphone, blackberry, or other small portable device. These devices are "getting smarter" in that many people are developing new applications for them. Cell phones no longer are just used to call people, they often have features like text messaging, cameras, video games, web browsers and more. There is much opportunity for developers to write new applications for mobile devices.

While opportunity abounds, there are also quite a few challenges. Mobile applications have less resources than are typically found in other development environments. The screen on mobile devices is typically smaller, there is usually not a keyboard and mouse (user inputs are reduced) [5]. CPU resources are generally less than those found in the typical environment [7]. Power usage is also limited because a battery is typically used, so reducing power use by the application is an important goal [7]. Connections are typically expensive and are often prone to loss of signals [6].

Another problem is that there is a high demand for applications to be developed quickly [7]. The mobile environment is changing rapidly [2]. Some of the lower level programming languages were useful because they produced fast applications, but they took too long to develop with[22 http://www.umsl.edu/~subramaniana/concepts1.html]. Now, with the increased demand for applications quickly, Object Oriented Programming (OOP) is used more. While this causes a greater usage of resources, this is outweighed by the much quicker development cycle and the re-use of code. In particular, good solutions may be re-used in OOP [7].

In the mobile environment, applications are often written on different operating systems [http://en.wikipedia.org/wiki/Mobile_operating_system] on different mobile systems. There is increased interaction between mobile systems, especially for cell phones. The Service Oriented Architecture design pattern is especially well suited for this situation. This is a fairly new field, and methods are currently being developed to aid developers.

== Ways to Adapt Using Design Patterns ==

Several principles and patterns have been understood and developed in developing for mobile applications. Many of these methods are still undergoing change and experimentation. There are new methods being developed and others left behind. A design pattern can be defined as a repeatable solution to a common problem in software. It is a template for how to solve the problem, not actual code [7].

Ease of navigation is a particularly important principle, because of the reduced number of user inputs (for example, buttons from 0 to 9 instead of a mouse and keyboard). Everything in an application should be no more than three clicks away. If a program is too "deep", requiring many clicks, this will be a problem because it takes longer to navigate on a mobile device. If the application is to "broad" as in too many links on one page, the data may not all fit on the screen. One way to mitigate this problem is to reduce functionality, to keep the application as simple as possible [5].

Service Oriented Architectures are well suited for the mobile environment [3]. Within this architecture, applications can make use of various services by sending messages to them via a protocol. Applications may interact with services on operating systems and written in different languages, as long as the protocol is followed. Services may be located on different mobile devices. This protocol is a good fit, allowing applications to reach out to services on other mobile devices, even though they may be on very different devices.

*'''''Service Oriented Architecture Example''''' [3]

[[Image:SOA_Example.jpg]]

Two major design patterns that have come up to help in mobile softwares and to address the above discussed issues in a mobile device are : Energy Conscious design pattern and Mobile agent design pattern

=== Energy Conscious Factory Design ===
According to the research published in ''[10]''

Power consumption has not been much of a concern to developers in the past, but this is important in the mobile environment. Battery power on cell phones is limited. [7]
- Use registers instead of memory whenever possible (registers use less energy)
- Use structs instead of classes
- Use static instead of dynamic

Some strategies and their experimental results are discussed in [10]: 
[[Image:ECFactory_Fig8.jpg| General Strategies]]

'''''Factory Method pattern''''' is a pattern that returns an object from one of various possible classes. Which class is chosen to be an object generator is depended on data provided to it.
Factory Method Pattern is a good pattern to build upon for energy conscious pattern. 
Lets look at both versions. 
Class Diagram of sample Factory Method pattern::
[[Image:ECFactory_Fig1.jpg|Class Diagram of sample Factory Method pattern ]]

Sequence Diagram (with Activations) of sample Factory Method pattern ::
[[Image:ECFactory_Fig2.jpg|Sequence Diagram (with Activations) of sample Factory Method pattern ]]

'''''Modified Factory Method pattern'''''
As regular Factory Method pattern was not designed for being energy concerned, so, it is slightly modified. Some of the critical tweaks are:
*Factory Method Pattern that mixes usage of struct and class in several manners.
*Factory Method Pattern that uses static factory method in Factory struct
*Factory Method Pattern that applies generics principle which is parametered type
*Factory Method Pattern That Uses ConcreteProduct Class, ConcreteCreator Struct with Non-Static FactoryMethod()

Modified Factory Method pattern applies both struct and class recommendations.

''Factory Method Pattern That Uses ConcreteProduct Class, ConcreteCreator Struct with Non-Static FactoryMethod()::''
[[Image:ECFactory_Fig3.jpg|Class Diagram of Factory Method pattern]]

In this case, we use VehicleChooser which is a ConcreteCreator as struct while Car, Plane and Ship which are ConcreteProduct as class. Method ChooseVehicle(...) which is as FactoryMethod() is non-static.

''Factory Method Pattern That Uses ConcreteProduct Struct, ConcreteCreator Struct with Static FactoryMethod()::''
[[Image:ECFactory_Fig4.jpg|Class Diagram of Factory Method pattern]] 
If we use static method appropriately, CPU workload will be reduced. This affects directly in lessening power consumption as a whole.

'''''Experimental Result:'''''
 For various combination shown in figure, the tests were run, and the result obtained are shown in the graph below.
 ''Characteristic of components in each combination::''
[[Image:ECFactory_Fig5.jpg|Characteristic of components in each combination ]] 

''CPU Usage Comparison ::''
[[Image:ECFactory_Fig6.jpg|CPU Usage Comparison ]] 
UPT is utilized processor time and TPT is total processor time

 ''Energy Usage Comparison::''

[[Image:ECFactory_Fig7.jpg|Energy Usage Comparison]] 

It is observed that Energy Concerned Factory Method Pattern can be obtained from the combination of ConcreteProduct classes and ConcreteCreator struct with static FactoryMethod(). The ECFactory Method Pattern consumes less CPU time than regular Factory Method Pattern around 11% while it is better than the worst case around 80%. The bigger the ConcreteProduct type size is, the more range between the best and the worst case in term of energy consumption will be.
So it is clearly proven how this pattern can save energy.

The [http://www.javaworld.com/javaworld/jw-10-2005/jw-1003-mvc.html Model View Controller] pattern [1] fits the mobile environment well. Models may be set up so that optimum data structures are used, as was discussed for the EC Factory pattern [7]. Effecient designs may be built into the controllers. Views may be standardized for the application to handle the small screens.

The meeting pattern is especially useful in mobile environments. One device or application serves as the meeting manager. The meeting manager coordinates and tracks the other agents (programs or applications). These agents communicate with the oversight of the meeting manager. Agents may be located on different devices, even on computers with more resources. This is especially well suited for the mobile environment because it is a good way to manage the communications and relatively small applications. A further benefit of the meeting pattern is that mobile applications may be combined (somewhat in the fashion of parallel computing) to do more and provide more resources [6].

*'''''Meeting pattern Example''''' [6]

[[Image:MCFigure3.jpg]]

The master slave pattern is simmilar to the meeting pattern. Instead of a meeting manager and agents, there is a master that creates, uses, and destroys slave objects. The master assigns the slaves tasks to complete. Like agents in the meeting pattern, slaves may be located on different mobile devices, or even on computers that have more resources. The master / slave pattern is very useful for performing actions in parallel on different mobile devices [6].

== Conclusion ==
In conclusion, certain design patterns are especially useful in the mobile design environment. These patterns help developers to produce applications quickly and applications which make efficient use of the limited resources in the mobile environment. Most design patterns can be of benefit to mobile applications, but certain patterns have features that are especially well suited. The EC factory pattern was designed for the mobile environment to reduce energy use [7]. A few other patterns show much promise with mobile devices, including the meeting pattern, master / slave pattern, and service oriented architectures.

== References ==

1. http://www.javaworld.com/javaworld/jw-10-2005/jw-1003-mvc.html - Model View Controller Architecture

2. http://patterns.littlespringsdesign.com/index.php/The_mobile_challenge - Challenges of the Mobile Environment

3. http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki2_17_va - Service Oriented Architecture

4. http://wiki.forum.nokia.com/index.php/Understading_Desing_Patterns - Understanding Design Patterns

5. http://dev.opera.com/articles/view/designing-and-developing-mobile-web-site/ - Designing and Developing mobile web sites in the real world

6. Emerson F.A Lima, Patrícia D. L. Machado, Fláavio R. Sampaio, and Jorge C. A. Figueiredo. ACM SIGSOFT Software Engineering Notes. Volume 29, issue 3 ISSN: 0163-5948 http://portal.acm.org/citation.cfm?id=986710.986726 Universidade Federal de Campina Grande, Paraíba, Brazil, May, 2004.

7. Kayun Chantarasathaporn, Chonawat Srisa-an. ACM International Conference Proceeding Series; Vol. 270 Proceedings of the 3rd international conference on Mobile technology, applications & systems SESSION: Mobile applications, article 29. ISBN:1-59593-519-3 http://portal.acm.org/citation.cfm?id=1292331.1292364 Bangkok, Thailand, 2006

8. WIM Workshop,Uppsala, 17.9.2004

9. Mobile Application Development, Sam Nasr , www.CleavelandDotNet.info

10. Energy Conscious Factory Method Design Pattern for Mobile Devices with C# and Intermediate Language, by Kayun Chantarasathaporn and Chonawat Srisa-an, Ph.D. at Faculty of Information Technology, Rangsit University, Thailand.

11. http://www.codeproject.com/csharp/structs_in_csharp.asp

CSC/ECE 517 Fall 2009/wiki3 21 MobileDesignPattern

2009-11-19T15:07:21Z

Wolverine: /* Ways to Adapt Using Design Patterns */

== Design Pattern for Mobile Applications ==

The popularity of mobile applications is rising. Design patterns are useful in almost any coding tasks. While almost any design pattern could be used within mobile applications, certain patterns are well suited for the unique environment of mobile applications. This wiki explains the mobile application environment, then focuses on design patterns that work well within this new emerging environment.

__TOC__

== The Mobile Application Environment ==

The mobile application environment is new and presents many unique opportunities and challenges for developers. It seems almost everyone now has a cellphone, blackberry, or other small portable device. These devices are "getting smarter" in that many people are developing new applications for them. Cell phones no longer are just used to call people, they often have features like text messaging, cameras, video games, web browsers and more. There is much opportunity for developers to write new applications for mobile devices.

While opportunity abounds, there are also quite a few challenges. Mobile applications have less resources than are typically found in other development environments. The screen on mobile devices is typically smaller, there is usually not a keyboard and mouse (user inputs are reduced) [5]. CPU resources are generally less than those found in the typical environment [7]. Power usage is also limited because a battery is typically used, so reducing power use by the application is an important goal [7]. Connections are typically expensive and are often prone to loss of signals [6].

Another problem is that there is a high demand for applications to be developed quickly [7]. The mobile environment is changing rapidly [2]. Some of the lower level programming languages were useful because they produced fast applications, but they took too long to develop with[22 http://www.umsl.edu/~subramaniana/concepts1.html]. Now, with the increased demand for applications quickly, Object Oriented Programming (OOP) is used more. While this causes a greater usage of resources, this is outweighed by the much quicker development cycle and the re-use of code. In particular, good solutions may be re-used in OOP [7].

In the mobile environment, applications are often written on different operating systems [http://en.wikipedia.org/wiki/Mobile_operating_system] on different mobile systems. There is increased interaction between mobile systems, especially for cell phones. The Service Oriented Architecture design pattern is especially well suited for this situation. This is a fairly new field, and methods are currently being developed to aid developers.

== Ways to Adapt Using Design Patterns ==

Several principles and patterns have been understood and developed in developing for mobile applications. Many of these methods are still undergoing change and experimentation. There are new methods being developed and others left behind. A design pattern can be defined as a repeatable solution to a common problem in software. It is a template for how to solve the problem, not actual code [7].

Ease of navigation is a particularly important principle, because of the reduced number of user inputs (for example, buttons from 0 to 9 instead of a mouse and keyboard). Everything in an application should be no more than three clicks away. If a program is too "deep", requiring many clicks, this will be a problem because it takes longer to navigate on a mobile device. If the application is to "broad" as in too many links on one page, the data may not all fit on the screen. One way to mitigate this problem is to reduce functionality, to keep the application as simple as possible [5].

Service Oriented Architectures are well suited for the mobile environment [3]. Within this architecture, applications can make use of various services by sending messages to them via a protocol. Applications may interact with services on operating systems and written in different languages, as long as the protocol is followed. Services may be located on different mobile devices. This protocol is a good fit, allowing applications to reach out to services on other mobile devices, even though they may be on very different devices.

*'''''Service Oriented Architecture Example''''' [3]

[[Image:SOA_Example.jpg]]

Two major design patterns that have come up to help in mobile softwares and to address the above discussed issues in a mobile device are : Energy Conscious design pattern and Mobile agent design pattern

=== Energy Conscious Factory Design ===
Accordin to the research published in ''[10]''

Power consumption has not been much of a concern to developers in the past, but this is important in the mobile environment. Battery power on cell phones is limited. [7]
- Use registers instead of memory whenever possible (registers use less energy)
- Use structs instead of classes
- Use static instead of dynamic

Some strategies and their experimental results are discussed in [10]: 
[[Image:ECFactory_Fig8.jpg| General Strategies]]

'''''Factory Method pattern''''' is a pattern that returns an object from one of various possible classes. Which class is chosen to be an object generator is depended on data provided to it.
Factory Method Pattern is a good pattern to build upon for energy conscious pattern. 
Lets look at both versions. 
Class Diagram of sample Factory Method pattern::
[[Image:ECFactory_Fig1.jpg|Class Diagram of sample Factory Method pattern ]]

Sequence Diagram (with Activations) of sample Factory Method pattern ::
[[Image:ECFactory_Fig2.jpg|Sequence Diagram (with Activations) of sample Factory Method pattern ]]

'''''Modified Factory Method pattern'''''
As regular Factory Method pattern was not designed for being energy concerned, so, it is slightly modified. Some of the critical tweaks are:
*Factory Method Pattern that mixes usage of struct and class in several manners.
*Factory Method Pattern that uses static factory method in Factory struct
*Factory Method Pattern that applies generics principle which is parametered type
*Factory Method Pattern That Uses ConcreteProduct Class, ConcreteCreator Struct with Non-Static FactoryMethod()

Modified Factory Method pattern applies both struct and class recommendations.

''Factory Method Pattern That Uses ConcreteProduct Class, ConcreteCreator Struct with Non-Static FactoryMethod()::''
[[Image:ECFactory_Fig3.jpg|Class Diagram of Factory Method pattern]]

In this case, we use VehicleChooser which is a ConcreteCreator as struct while Car, Plane and Ship which are ConcreteProduct as class. Method ChooseVehicle(...) which is as FactoryMethod() is non-static.

''Factory Method Pattern That Uses ConcreteProduct Struct, ConcreteCreator Struct with Static FactoryMethod()::''
[[Image:ECFactory_Fig4.jpg|Class Diagram of Factory Method pattern]] 
If we use static method appropriately, CPU workload will be reduced. This affects directly in lessening power consumption as a whole.

'''''Experimental Result:'''''
 For various combination shown in figure, the tests were run, and the result obtained are shown in the graph below.
 ''Characteristic of components in each combination::''
[[Image:ECFactory_Fig5.jpg|Characteristic of components in each combination ]] 

''CPU Usage Comparison ::''
[[Image:ECFactory_Fig6.jpg|CPU Usage Comparison ]] 
UPT is utilized processor time and TPT is total processor time

 ''Energy Usage Comparison::''

[[Image:ECFactory_Fig7.jpg|Energy Usage Comparison]] 

It is observed that Energy Concerned Factory Method Pattern can be obtained from the combination of ConcreteProduct classes and ConcreteCreator struct with static FactoryMethod(). The ECFactory Method Pattern consumes less CPU time than regular Factory Method Pattern around 11% while it is better than the worst case around 80%. The bigger the ConcreteProduct type size is, the more range between the best and the worst case in term of energy consumption will be.
So it is clearly proven how this pattern can save energy.

The [http://www.javaworld.com/javaworld/jw-10-2005/jw-1003-mvc.html Model View Controller] pattern [1] fits the mobile environment well. Models may be set up so that optimum data structures are used, as was discussed for the EC Factory pattern [7]. Effecient designs may be built into the controllers. Views may be standardized for the application to handle the small screens.

The meeting pattern is especially useful in mobile environments. One device or application serves as the meeting manager. The meeting manager coordinates and tracks the other agents (programs or applications). These agents communicate with the oversight of the meeting manager. Agents may be located on different devices, even on computers with more resources. This is especially well suited for the mobile environment because it is a good way to manage the communications and relatively small applications. A further benefit of the meeting pattern is that mobile applications may be combined (somewhat in the fashion of parallel computing) to do more and provide more resources [6].

*'''''Meeting pattern Example''''' [6]

[[Image:MCFigure3.jpg]]

The master slave pattern is simmilar to the meeting pattern. Instead of a meeting manager and agents, there is a master that creates, uses, and destroys slave objects. The master assigns the slaves tasks to complete. Like agents in the meeting pattern, slaves may be located on different mobile devices, or even on computers that have more resources. The master / slave pattern is very useful for performing actions in parallel on different mobile devices [6].

== Conclusion ==
In conclusion, certain design patterns are especially useful in the mobile design environment. These patterns help developers to produce applications quickly and applications which make efficient use of the limited resources in the mobile environment. Most design patterns can be of benefit to mobile applications, but certain patterns have features that are especially well suited. The EC factory pattern was designed for the mobile environment to reduce energy use [7]. A few other patterns show much promise with mobile devices, including the meeting pattern, master / slave pattern, and service oriented architectures.

== References ==

1. http://www.javaworld.com/javaworld/jw-10-2005/jw-1003-mvc.html - Model View Controller Architecture

2. http://patterns.littlespringsdesign.com/index.php/The_mobile_challenge - Challenges of the Mobile Environment

3. http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki2_17_va - Service Oriented Architecture

4. http://wiki.forum.nokia.com/index.php/Understading_Desing_Patterns - Understanding Design Patterns

5. http://dev.opera.com/articles/view/designing-and-developing-mobile-web-site/ - Designing and Developing mobile web sites in the real world

6. Emerson F.A Lima, Patrícia D. L. Machado, Fláavio R. Sampaio, and Jorge C. A. Figueiredo. ACM SIGSOFT Software Engineering Notes. Volume 29, issue 3 ISSN: 0163-5948 http://portal.acm.org/citation.cfm?id=986710.986726 Universidade Federal de Campina Grande, Paraíba, Brazil, May, 2004.

7. Kayun Chantarasathaporn, Chonawat Srisa-an. ACM International Conference Proceeding Series; Vol. 270 Proceedings of the 3rd international conference on Mobile technology, applications & systems SESSION: Mobile applications, article 29. ISBN:1-59593-519-3 http://portal.acm.org/citation.cfm?id=1292331.1292364 Bangkok, Thailand, 2006

8. WIM Workshop,Uppsala, 17.9.2004

9. Mobile Application Development, Sam Nasr , www.CleavelandDotNet.info

10. Energy Conscious Factory Method Design Pattern for Mobile Devices with C# and Intermediate Language, by Kayun Chantarasathaporn and Chonawat Srisa-an, Ph.D. at Faculty of Information Technology, Rangsit University, Thailand.

11. http://www.codeproject.com/csharp/structs_in_csharp.asp

CSC/ECE 517 Fall 2009/wiki3 21 MobileDesignPattern

2009-11-19T15:06:26Z

Wolverine: /* Energy Conscious Factory Design [10] */

== Design Pattern for Mobile Applications ==

The popularity of mobile applications is rising. Design patterns are useful in almost any coding tasks. While almost any design pattern could be used within mobile applications, certain patterns are well suited for the unique environment of mobile applications. This wiki explains the mobile application environment, then focuses on design patterns that work well within this new emerging environment.

__TOC__

== The Mobile Application Environment ==

The mobile application environment is new and presents many unique opportunities and challenges for developers. It seems almost everyone now has a cellphone, blackberry, or other small portable device. These devices are "getting smarter" in that many people are developing new applications for them. Cell phones no longer are just used to call people, they often have features like text messaging, cameras, video games, web browsers and more. There is much opportunity for developers to write new applications for mobile devices.

While opportunity abounds, there are also quite a few challenges. Mobile applications have less resources than are typically found in other development environments. The screen on mobile devices is typically smaller, there is usually not a keyboard and mouse (user inputs are reduced) [5]. CPU resources are generally less than those found in the typical environment [7]. Power usage is also limited because a battery is typically used, so reducing power use by the application is an important goal [7]. Connections are typically expensive and are often prone to loss of signals [6].

Another problem is that there is a high demand for applications to be developed quickly [7]. The mobile environment is changing rapidly [2]. Some of the lower level programming languages were useful because they produced fast applications, but they took too long to develop with[22 http://www.umsl.edu/~subramaniana/concepts1.html]. Now, with the increased demand for applications quickly, Object Oriented Programming (OOP) is used more. While this causes a greater usage of resources, this is outweighed by the much quicker development cycle and the re-use of code. In particular, good solutions may be re-used in OOP [7].

In the mobile environment, applications are often written on different operating systems [http://en.wikipedia.org/wiki/Mobile_operating_system] on different mobile systems. There is increased interaction between mobile systems, especially for cell phones. The Service Oriented Architecture design pattern is especially well suited for this situation. This is a fairly new field, and methods are currently being developed to aid developers.

== Ways to Adapt Using Design Patterns ==

Several principles and patterns have been understood and developed in developing for mobile applications. Many of these methods are still undergoing change and experimentation. There are new methods being developed and others left behind. A design pattern can be defined as a repeatable solution to a common problem in software. It is a template for how to solve the problem, not actual code [7].

Ease of navigation is a particularly important principle, because of the reduced number of user inputs (for example, buttons from 0 to 9 instead of a mouse and keyboard). Everything in an application should be no more than three clicks away. If a program is too "deep", requiring many clicks, this will be a problem because it takes longer to navigate on a mobile device. If the application is to "broad" as in too many links on one page, the data may not all fit on the screen. One way to mitigate this problem is to reduce functionality, to keep the application as simple as possible [5].

Service Oriented Architectures are well suited for the mobile environment [3]. Within this architecture, applications can make use of various services by sending messages to them via a protocol. Applications may interact with services on operating systems and written in different languages, as long as the protocol is followed. Services may be located on different mobile devices. This protocol is a good fit, allowing applications to reach out to services on other mobile devices, even though they may be on very different devices.

*'''''Service Oriented Architecture Example''''' [3]

[[Image:SOA_Example.jpg]]

Two major design patterns that have come up to help in mobile softwares and to address the above discussed issues in a mobile device are : Energy Conscious design pattern and Mobile agent design pattern

=== Energy Conscious Factory Design === ''[10]''

Power consumption has not been much of a concern to developers in the past, but this is important in the mobile environment. Battery power on cell phones is limited. [7]
- Use registers instead of memory whenever possible (registers use less energy)
- Use structs instead of classes
- Use static instead of dynamic

Some strategies and their experimental results are discussed in [10]: 
[[Image:ECFactory_Fig8.jpg| General Strategies]]

'''''Factory Method pattern''''' is a pattern that returns an object from one of various possible classes. Which class is chosen to be an object generator is depended on data provided to it.
Factory Method Pattern is a good pattern to build upon for energy conscious pattern. 
Lets look at both versions. 
Class Diagram of sample Factory Method pattern::
[[Image:ECFactory_Fig1.jpg|Class Diagram of sample Factory Method pattern ]]

Sequence Diagram (with Activations) of sample Factory Method pattern ::
[[Image:ECFactory_Fig2.jpg|Sequence Diagram (with Activations) of sample Factory Method pattern ]]

'''''Modified Factory Method pattern'''''
As regular Factory Method pattern was not designed for being energy concerned, so, it is slightly modified. Some of the critical tweaks are:
*Factory Method Pattern that mixes usage of struct and class in several manners.
*Factory Method Pattern that uses static factory method in Factory struct
*Factory Method Pattern that applies generics principle which is parametered type
*Factory Method Pattern That Uses ConcreteProduct Class, ConcreteCreator Struct with Non-Static FactoryMethod()

Modified Factory Method pattern applies both struct and class recommendations.

''Factory Method Pattern That Uses ConcreteProduct Class, ConcreteCreator Struct with Non-Static FactoryMethod()::''
[[Image:ECFactory_Fig3.jpg|Class Diagram of Factory Method pattern]]

In this case, we use VehicleChooser which is a ConcreteCreator as struct while Car, Plane and Ship which are ConcreteProduct as class. Method ChooseVehicle(...) which is as FactoryMethod() is non-static.

''Factory Method Pattern That Uses ConcreteProduct Struct, ConcreteCreator Struct with Static FactoryMethod()::''
[[Image:ECFactory_Fig4.jpg|Class Diagram of Factory Method pattern]] 
If we use static method appropriately, CPU workload will be reduced. This affects directly in lessening power consumption as a whole.

'''''Experimental Result:'''''
 For various combination shown in figure, the tests were run, and the result obtained are shown in the graph below.
 ''Characteristic of components in each combination::''
[[Image:ECFactory_Fig5.jpg|Characteristic of components in each combination ]] 

''CPU Usage Comparison ::''
[[Image:ECFactory_Fig6.jpg|CPU Usage Comparison ]] 
UPT is utilized processor time and TPT is total processor time

 ''Energy Usage Comparison::''

[[Image:ECFactory_Fig7.jpg|Energy Usage Comparison]] 

It is observed that Energy Concerned Factory Method Pattern can be obtained from the combination of ConcreteProduct classes and ConcreteCreator struct with static FactoryMethod(). The ECFactory Method Pattern consumes less CPU time than regular Factory Method Pattern around 11% while it is better than the worst case around 80%. The bigger the ConcreteProduct type size is, the more range between the best and the worst case in term of energy consumption will be.
So it is clearly proven how this pattern can save energy.

The [http://www.javaworld.com/javaworld/jw-10-2005/jw-1003-mvc.html Model View Controller] pattern [1] fits the mobile environment well. Models may be set up so that optimum data structures are used, as was discussed for the EC Factory pattern [7]. Effecient designs may be built into the controllers. Views may be standardized for the application to handle the small screens.

The meeting pattern is especially useful in mobile environments. One device or application serves as the meeting manager. The meeting manager coordinates and tracks the other agents (programs or applications). These agents communicate with the oversight of the meeting manager. Agents may be located on different devices, even on computers with more resources. This is especially well suited for the mobile environment because it is a good way to manage the communications and relatively small applications. A further benefit of the meeting pattern is that mobile applications may be combined (somewhat in the fashion of parallel computing) to do more and provide more resources [6].

*'''''Meeting pattern Example''''' [6]

[[Image:MCFigure3.jpg]]

The master slave pattern is simmilar to the meeting pattern. Instead of a meeting manager and agents, there is a master that creates, uses, and destroys slave objects. The master assigns the slaves tasks to complete. Like agents in the meeting pattern, slaves may be located on different mobile devices, or even on computers that have more resources. The master / slave pattern is very useful for performing actions in parallel on different mobile devices [6].

== Conclusion ==
In conclusion, certain design patterns are especially useful in the mobile design environment. These patterns help developers to produce applications quickly and applications which make efficient use of the limited resources in the mobile environment. Most design patterns can be of benefit to mobile applications, but certain patterns have features that are especially well suited. The EC factory pattern was designed for the mobile environment to reduce energy use [7]. A few other patterns show much promise with mobile devices, including the meeting pattern, master / slave pattern, and service oriented architectures.

== References ==

1. http://www.javaworld.com/javaworld/jw-10-2005/jw-1003-mvc.html - Model View Controller Architecture

2. http://patterns.littlespringsdesign.com/index.php/The_mobile_challenge - Challenges of the Mobile Environment

3. http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki2_17_va - Service Oriented Architecture

4. http://wiki.forum.nokia.com/index.php/Understading_Desing_Patterns - Understanding Design Patterns

5. http://dev.opera.com/articles/view/designing-and-developing-mobile-web-site/ - Designing and Developing mobile web sites in the real world

6. Emerson F.A Lima, Patrícia D. L. Machado, Fláavio R. Sampaio, and Jorge C. A. Figueiredo. ACM SIGSOFT Software Engineering Notes. Volume 29, issue 3 ISSN: 0163-5948 http://portal.acm.org/citation.cfm?id=986710.986726 Universidade Federal de Campina Grande, Paraíba, Brazil, May, 2004.

7. Kayun Chantarasathaporn, Chonawat Srisa-an. ACM International Conference Proceeding Series; Vol. 270 Proceedings of the 3rd international conference on Mobile technology, applications & systems SESSION: Mobile applications, article 29. ISBN:1-59593-519-3 http://portal.acm.org/citation.cfm?id=1292331.1292364 Bangkok, Thailand, 2006

8. WIM Workshop,Uppsala, 17.9.2004

9. Mobile Application Development, Sam Nasr , www.CleavelandDotNet.info

10. Energy Conscious Factory Method Design Pattern for Mobile Devices with C# and Intermediate Language, by Kayun Chantarasathaporn and Chonawat Srisa-an, Ph.D. at Faculty of Information Technology, Rangsit University, Thailand.

11. http://www.codeproject.com/csharp/structs_in_csharp.asp

CSC/ECE 517 Fall 2009/wiki3 21 MobileDesignPattern

2009-11-19T15:06:08Z

Wolverine: /* Energy Conscious Factory Design */

== Design Pattern for Mobile Applications ==

The popularity of mobile applications is rising. Design patterns are useful in almost any coding tasks. While almost any design pattern could be used within mobile applications, certain patterns are well suited for the unique environment of mobile applications. This wiki explains the mobile application environment, then focuses on design patterns that work well within this new emerging environment.

__TOC__

== The Mobile Application Environment ==

The mobile application environment is new and presents many unique opportunities and challenges for developers. It seems almost everyone now has a cellphone, blackberry, or other small portable device. These devices are "getting smarter" in that many people are developing new applications for them. Cell phones no longer are just used to call people, they often have features like text messaging, cameras, video games, web browsers and more. There is much opportunity for developers to write new applications for mobile devices.

While opportunity abounds, there are also quite a few challenges. Mobile applications have less resources than are typically found in other development environments. The screen on mobile devices is typically smaller, there is usually not a keyboard and mouse (user inputs are reduced) [5]. CPU resources are generally less than those found in the typical environment [7]. Power usage is also limited because a battery is typically used, so reducing power use by the application is an important goal [7]. Connections are typically expensive and are often prone to loss of signals [6].

Another problem is that there is a high demand for applications to be developed quickly [7]. The mobile environment is changing rapidly [2]. Some of the lower level programming languages were useful because they produced fast applications, but they took too long to develop with[22 http://www.umsl.edu/~subramaniana/concepts1.html]. Now, with the increased demand for applications quickly, Object Oriented Programming (OOP) is used more. While this causes a greater usage of resources, this is outweighed by the much quicker development cycle and the re-use of code. In particular, good solutions may be re-used in OOP [7].

In the mobile environment, applications are often written on different operating systems [http://en.wikipedia.org/wiki/Mobile_operating_system] on different mobile systems. There is increased interaction between mobile systems, especially for cell phones. The Service Oriented Architecture design pattern is especially well suited for this situation. This is a fairly new field, and methods are currently being developed to aid developers.

== Ways to Adapt Using Design Patterns ==

Several principles and patterns have been understood and developed in developing for mobile applications. Many of these methods are still undergoing change and experimentation. There are new methods being developed and others left behind. A design pattern can be defined as a repeatable solution to a common problem in software. It is a template for how to solve the problem, not actual code [7].

Ease of navigation is a particularly important principle, because of the reduced number of user inputs (for example, buttons from 0 to 9 instead of a mouse and keyboard). Everything in an application should be no more than three clicks away. If a program is too "deep", requiring many clicks, this will be a problem because it takes longer to navigate on a mobile device. If the application is to "broad" as in too many links on one page, the data may not all fit on the screen. One way to mitigate this problem is to reduce functionality, to keep the application as simple as possible [5].

Service Oriented Architectures are well suited for the mobile environment [3]. Within this architecture, applications can make use of various services by sending messages to them via a protocol. Applications may interact with services on operating systems and written in different languages, as long as the protocol is followed. Services may be located on different mobile devices. This protocol is a good fit, allowing applications to reach out to services on other mobile devices, even though they may be on very different devices.

*'''''Service Oriented Architecture Example''''' [3]

[[Image:SOA_Example.jpg]]

Two major design patterns that have come up to help in mobile softwares and to address the above discussed issues in a mobile device are : Energy Conscious design pattern and Mobile agent design pattern

=== Energy Conscious Factory Design [10]===

Power consumption has not been much of a concern to developers in the past, but this is important in the mobile environment. Battery power on cell phones is limited. [7]
- Use registers instead of memory whenever possible (registers use less energy)
- Use structs instead of classes
- Use static instead of dynamic

Some strategies and their experimental results are discussed in [10]: 
[[Image:ECFactory_Fig8.jpg| General Strategies]]

'''''Factory Method pattern''''' is a pattern that returns an object from one of various possible classes. Which class is chosen to be an object generator is depended on data provided to it.
Factory Method Pattern is a good pattern to build upon for energy conscious pattern. 
Lets look at both versions. 
Class Diagram of sample Factory Method pattern::
[[Image:ECFactory_Fig1.jpg|Class Diagram of sample Factory Method pattern ]]

Sequence Diagram (with Activations) of sample Factory Method pattern ::
[[Image:ECFactory_Fig2.jpg|Sequence Diagram (with Activations) of sample Factory Method pattern ]]

'''''Modified Factory Method pattern'''''
As regular Factory Method pattern was not designed for being energy concerned, so, it is slightly modified. Some of the critical tweaks are:
*Factory Method Pattern that mixes usage of struct and class in several manners.
*Factory Method Pattern that uses static factory method in Factory struct
*Factory Method Pattern that applies generics principle which is parametered type
*Factory Method Pattern That Uses ConcreteProduct Class, ConcreteCreator Struct with Non-Static FactoryMethod()

Modified Factory Method pattern applies both struct and class recommendations.

''Factory Method Pattern That Uses ConcreteProduct Class, ConcreteCreator Struct with Non-Static FactoryMethod()::''
[[Image:ECFactory_Fig3.jpg|Class Diagram of Factory Method pattern]]

In this case, we use VehicleChooser which is a ConcreteCreator as struct while Car, Plane and Ship which are ConcreteProduct as class. Method ChooseVehicle(...) which is as FactoryMethod() is non-static.

''Factory Method Pattern That Uses ConcreteProduct Struct, ConcreteCreator Struct with Static FactoryMethod()::''
[[Image:ECFactory_Fig4.jpg|Class Diagram of Factory Method pattern]] 
If we use static method appropriately, CPU workload will be reduced. This affects directly in lessening power consumption as a whole.

'''''Experimental Result:'''''
 For various combination shown in figure, the tests were run, and the result obtained are shown in the graph below.
 ''Characteristic of components in each combination::''
[[Image:ECFactory_Fig5.jpg|Characteristic of components in each combination ]] 

''CPU Usage Comparison ::''
[[Image:ECFactory_Fig6.jpg|CPU Usage Comparison ]] 
UPT is utilized processor time and TPT is total processor time

 ''Energy Usage Comparison::''

[[Image:ECFactory_Fig7.jpg|Energy Usage Comparison]] 

It is observed that Energy Concerned Factory Method Pattern can be obtained from the combination of ConcreteProduct classes and ConcreteCreator struct with static FactoryMethod(). The ECFactory Method Pattern consumes less CPU time than regular Factory Method Pattern around 11% while it is better than the worst case around 80%. The bigger the ConcreteProduct type size is, the more range between the best and the worst case in term of energy consumption will be.
So it is clearly proven how this pattern can save energy.

The [http://www.javaworld.com/javaworld/jw-10-2005/jw-1003-mvc.html Model View Controller] pattern [1] fits the mobile environment well. Models may be set up so that optimum data structures are used, as was discussed for the EC Factory pattern [7]. Effecient designs may be built into the controllers. Views may be standardized for the application to handle the small screens.

The meeting pattern is especially useful in mobile environments. One device or application serves as the meeting manager. The meeting manager coordinates and tracks the other agents (programs or applications). These agents communicate with the oversight of the meeting manager. Agents may be located on different devices, even on computers with more resources. This is especially well suited for the mobile environment because it is a good way to manage the communications and relatively small applications. A further benefit of the meeting pattern is that mobile applications may be combined (somewhat in the fashion of parallel computing) to do more and provide more resources [6].

*'''''Meeting pattern Example''''' [6]

[[Image:MCFigure3.jpg]]

The master slave pattern is simmilar to the meeting pattern. Instead of a meeting manager and agents, there is a master that creates, uses, and destroys slave objects. The master assigns the slaves tasks to complete. Like agents in the meeting pattern, slaves may be located on different mobile devices, or even on computers that have more resources. The master / slave pattern is very useful for performing actions in parallel on different mobile devices [6].

== Conclusion ==
In conclusion, certain design patterns are especially useful in the mobile design environment. These patterns help developers to produce applications quickly and applications which make efficient use of the limited resources in the mobile environment. Most design patterns can be of benefit to mobile applications, but certain patterns have features that are especially well suited. The EC factory pattern was designed for the mobile environment to reduce energy use [7]. A few other patterns show much promise with mobile devices, including the meeting pattern, master / slave pattern, and service oriented architectures.

== References ==

1. http://www.javaworld.com/javaworld/jw-10-2005/jw-1003-mvc.html - Model View Controller Architecture

2. http://patterns.littlespringsdesign.com/index.php/The_mobile_challenge - Challenges of the Mobile Environment

3. http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki2_17_va - Service Oriented Architecture

4. http://wiki.forum.nokia.com/index.php/Understading_Desing_Patterns - Understanding Design Patterns

5. http://dev.opera.com/articles/view/designing-and-developing-mobile-web-site/ - Designing and Developing mobile web sites in the real world

6. Emerson F.A Lima, Patrícia D. L. Machado, Fláavio R. Sampaio, and Jorge C. A. Figueiredo. ACM SIGSOFT Software Engineering Notes. Volume 29, issue 3 ISSN: 0163-5948 http://portal.acm.org/citation.cfm?id=986710.986726 Universidade Federal de Campina Grande, Paraíba, Brazil, May, 2004.

7. Kayun Chantarasathaporn, Chonawat Srisa-an. ACM International Conference Proceeding Series; Vol. 270 Proceedings of the 3rd international conference on Mobile technology, applications & systems SESSION: Mobile applications, article 29. ISBN:1-59593-519-3 http://portal.acm.org/citation.cfm?id=1292331.1292364 Bangkok, Thailand, 2006

8. WIM Workshop,Uppsala, 17.9.2004

9. Mobile Application Development, Sam Nasr , www.CleavelandDotNet.info

10. Energy Conscious Factory Method Design Pattern for Mobile Devices with C# and Intermediate Language, by Kayun Chantarasathaporn and Chonawat Srisa-an, Ph.D. at Faculty of Information Technology, Rangsit University, Thailand.

11. http://www.codeproject.com/csharp/structs_in_csharp.asp

CSC/ECE 517 Fall 2009/wiki3 21 MobileDesignPattern

2009-11-19T15:04:29Z

Wolverine:

== Design Pattern for Mobile Applications ==

The popularity of mobile applications is rising. Design patterns are useful in almost any coding tasks. While almost any design pattern could be used within mobile applications, certain patterns are well suited for the unique environment of mobile applications. This wiki explains the mobile application environment, then focuses on design patterns that work well within this new emerging environment.

__TOC__

== The Mobile Application Environment ==

The mobile application environment is new and presents many unique opportunities and challenges for developers. It seems almost everyone now has a cellphone, blackberry, or other small portable device. These devices are "getting smarter" in that many people are developing new applications for them. Cell phones no longer are just used to call people, they often have features like text messaging, cameras, video games, web browsers and more. There is much opportunity for developers to write new applications for mobile devices.

While opportunity abounds, there are also quite a few challenges. Mobile applications have less resources than are typically found in other development environments. The screen on mobile devices is typically smaller, there is usually not a keyboard and mouse (user inputs are reduced) [5]. CPU resources are generally less than those found in the typical environment [7]. Power usage is also limited because a battery is typically used, so reducing power use by the application is an important goal [7]. Connections are typically expensive and are often prone to loss of signals [6].

Another problem is that there is a high demand for applications to be developed quickly [7]. The mobile environment is changing rapidly [2]. Some of the lower level programming languages were useful because they produced fast applications, but they took too long to develop with[22 http://www.umsl.edu/~subramaniana/concepts1.html]. Now, with the increased demand for applications quickly, Object Oriented Programming (OOP) is used more. While this causes a greater usage of resources, this is outweighed by the much quicker development cycle and the re-use of code. In particular, good solutions may be re-used in OOP [7].

In the mobile environment, applications are often written on different operating systems [http://en.wikipedia.org/wiki/Mobile_operating_system] on different mobile systems. There is increased interaction between mobile systems, especially for cell phones. The Service Oriented Architecture design pattern is especially well suited for this situation. This is a fairly new field, and methods are currently being developed to aid developers.

== Ways to Adapt Using Design Patterns ==

Several principles and patterns have been understood and developed in developing for mobile applications. Many of these methods are still undergoing change and experimentation. There are new methods being developed and others left behind. A design pattern can be defined as a repeatable solution to a common problem in software. It is a template for how to solve the problem, not actual code [7].

Ease of navigation is a particularly important principle, because of the reduced number of user inputs (for example, buttons from 0 to 9 instead of a mouse and keyboard). Everything in an application should be no more than three clicks away. If a program is too "deep", requiring many clicks, this will be a problem because it takes longer to navigate on a mobile device. If the application is to "broad" as in too many links on one page, the data may not all fit on the screen. One way to mitigate this problem is to reduce functionality, to keep the application as simple as possible [5].

Service Oriented Architectures are well suited for the mobile environment [3]. Within this architecture, applications can make use of various services by sending messages to them via a protocol. Applications may interact with services on operating systems and written in different languages, as long as the protocol is followed. Services may be located on different mobile devices. This protocol is a good fit, allowing applications to reach out to services on other mobile devices, even though they may be on very different devices.

*'''''Service Oriented Architecture Example''''' [3]

[[Image:SOA_Example.jpg]]

Two major design patterns that have come up to help in mobile softwares and to address the above discussed issues in a mobile device are : Energy Conscious design pattern and Mobile agent design pattern

=== Energy Conscious Factory Design ===

Power consumption has not been much of a concern to developers in the past, but this is important in the mobile environment. Battery power on cell phones is limited. [7]
- Use registers instead of memory whenever possible (registers use less energy)
- Use structs instead of classes
- Use static instead of dynamic

Some strategies and their experimental results are discussed in [10]: 
[[Image:ECFactory_Fig8.jpg| General Strategies]]

'''''Factory Method pattern''''' is a pattern that returns an object from one of various possible classes. Which class is chosen to be an object generator is depended on data provided to it.
Factory Method Pattern is a good pattern to build upon for energy conscious pattern. 
Lets look at both versions. 
Class Diagram of sample Factory Method pattern::
[[Image:ECFactory_Fig1.jpg|Class Diagram of sample Factory Method pattern ]]

Sequence Diagram (with Activations) of sample Factory Method pattern ::
[[Image:ECFactory_Fig2.jpg|Sequence Diagram (with Activations) of sample Factory Method pattern ]]

'''''Modified Factory Method pattern'''''
As regular Factory Method pattern was not designed for being energy concerned, so, it is slightly modified. Some of the critical tweaks are:
*Factory Method Pattern that mixes usage of struct and class in several manners.
*Factory Method Pattern that uses static factory method in Factory struct
*Factory Method Pattern that applies generics principle which is parametered type
*Factory Method Pattern That Uses ConcreteProduct Class, ConcreteCreator Struct with Non-Static FactoryMethod()

Modified Factory Method pattern applies both struct and class recommendations.

''Factory Method Pattern That Uses ConcreteProduct Class, ConcreteCreator Struct with Non-Static FactoryMethod()::''
[[Image:ECFactory_Fig3.jpg|Class Diagram of Factory Method pattern]]

In this case, we use VehicleChooser which is a ConcreteCreator as struct while Car, Plane and Ship which are ConcreteProduct as class. Method ChooseVehicle(...) which is as FactoryMethod() is non-static.

''Factory Method Pattern That Uses ConcreteProduct Struct, ConcreteCreator Struct with Static FactoryMethod()::''
[[Image:ECFactory_Fig4.jpg|Class Diagram of Factory Method pattern]] 
If we use static method appropriately, CPU workload will be reduced. This affects directly in lessening power consumption as a whole.

'''''Experimental Result:'''''
 For various combination shown in figure, the tests were run, and the result obtained are shown in the graph below.
 ''Characteristic of components in each combination::''
[[Image:ECFactory_Fig5.jpg|Characteristic of components in each combination ]] 

''CPU Usage Comparison ::''
[[Image:ECFactory_Fig6.jpg|CPU Usage Comparison ]] 
UPT is utilized processor time and TPT is total processor time

 ''Energy Usage Comparison::''

[[Image:ECFactory_Fig7.jpg|Energy Usage Comparison]] 

It is observed that Energy Concerned Factory Method Pattern can be obtained from the combination of ConcreteProduct classes and ConcreteCreator struct with static FactoryMethod(). The ECFactory Method Pattern consumes less CPU time than regular Factory Method Pattern around 11% while it is better than the worst case around 80%. The bigger the ConcreteProduct type size is, the more range between the best and the worst case in term of energy consumption will be.
So it is clearly proven how this pattern can save energy.

The [http://www.javaworld.com/javaworld/jw-10-2005/jw-1003-mvc.html Model View Controller] pattern [1] fits the mobile environment well. Models may be set up so that optimum data structures are used, as was discussed for the EC Factory pattern [7]. Effecient designs may be built into the controllers. Views may be standardized for the application to handle the small screens.

The meeting pattern is especially useful in mobile environments. One device or application serves as the meeting manager. The meeting manager coordinates and tracks the other agents (programs or applications). These agents communicate with the oversight of the meeting manager. Agents may be located on different devices, even on computers with more resources. This is especially well suited for the mobile environment because it is a good way to manage the communications and relatively small applications. A further benefit of the meeting pattern is that mobile applications may be combined (somewhat in the fashion of parallel computing) to do more and provide more resources [6].

*'''''Meeting pattern Example''''' [6]

[[Image:MCFigure3.jpg]]

The master slave pattern is simmilar to the meeting pattern. Instead of a meeting manager and agents, there is a master that creates, uses, and destroys slave objects. The master assigns the slaves tasks to complete. Like agents in the meeting pattern, slaves may be located on different mobile devices, or even on computers that have more resources. The master / slave pattern is very useful for performing actions in parallel on different mobile devices [6].

== Conclusion ==
In conclusion, certain design patterns are especially useful in the mobile design environment. These patterns help developers to produce applications quickly and applications which make efficient use of the limited resources in the mobile environment. Most design patterns can be of benefit to mobile applications, but certain patterns have features that are especially well suited. The EC factory pattern was designed for the mobile environment to reduce energy use [7]. A few other patterns show much promise with mobile devices, including the meeting pattern, master / slave pattern, and service oriented architectures.

== References ==

1. http://www.javaworld.com/javaworld/jw-10-2005/jw-1003-mvc.html - Model View Controller Architecture

2. http://patterns.littlespringsdesign.com/index.php/The_mobile_challenge - Challenges of the Mobile Environment

3. http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki2_17_va - Service Oriented Architecture

4. http://wiki.forum.nokia.com/index.php/Understading_Desing_Patterns - Understanding Design Patterns

5. http://dev.opera.com/articles/view/designing-and-developing-mobile-web-site/ - Designing and Developing mobile web sites in the real world

6. Emerson F.A Lima, Patrícia D. L. Machado, Fláavio R. Sampaio, and Jorge C. A. Figueiredo. ACM SIGSOFT Software Engineering Notes. Volume 29, issue 3 ISSN: 0163-5948 http://portal.acm.org/citation.cfm?id=986710.986726 Universidade Federal de Campina Grande, Paraíba, Brazil, May, 2004.

7. Kayun Chantarasathaporn, Chonawat Srisa-an. ACM International Conference Proceeding Series; Vol. 270 Proceedings of the 3rd international conference on Mobile technology, applications & systems SESSION: Mobile applications, article 29. ISBN:1-59593-519-3 http://portal.acm.org/citation.cfm?id=1292331.1292364 Bangkok, Thailand, 2006

8. WIM Workshop,Uppsala, 17.9.2004

9. Mobile Application Development, Sam Nasr , www.CleavelandDotNet.info

10. Energy Conscious Factory Method Design Pattern for Mobile Devices with C# and Intermediate Language, by Kayun Chantarasathaporn and Chonawat Srisa-an, Ph.D. at Faculty of Information Technology, Rangsit University, Thailand.

11. http://www.codeproject.com/csharp/structs_in_csharp.asp

CSC/ECE 517 Fall 2009/wiki3 21 MobileDesignPattern

2009-11-19T15:02:48Z

Wolverine: /* Energy Conscious Factory Design */

== Design Pattern for Mobile Applications ==

The popularity of mobile applications is rising. Design patterns are useful in almost any coding tasks. While almost any design pattern could be used within mobile applications, certain patterns are well suited for the unique environment of mobile applications. This wiki explains the mobile application environment, then focuses on design patterns that work well within this new emerging environment.

__TOC__

== The Mobile Application Environment ==

The mobile application environment is new and presents many unique opportunities and challenges for developers. It seems almost everyone now has a cellphone, blackberry, or other small portable device. These devices are "getting smarter" in that many people are developing new applications for them. Cell phones no longer are just used to call people, they often have features like text messaging, cameras, video games, web browsers and more. There is much opportunity for developers to write new applications for mobile devices.

While opportunity abounds, there are also quite a few challenges. Mobile applications have less resources than are typically found in other development environments. The screen on mobile devices is typically smaller, there is usually not a keyboard and mouse (user inputs are reduced) [5]. CPU resources are generally less than those found in the typical environment [7]. Power usage is also limited because a battery is typically used, so reducing power use by the application is an important goal [7]. Connections are typically expensive and are often prone to loss of signals [6].

Another problem is that there is a high demand for applications to be developed quickly [7]. The mobile environment is changing rapidly [2]. Some of the lower level programming languages were useful because they produced fast applications, but they took too long to develop with[22 http://www.umsl.edu/~subramaniana/concepts1.html]. Now, with the increased demand for applications quickly, Object Oriented Programming (OOP) is used more. While this causes a greater usage of resources, this is outweighed by the much quicker development cycle and the re-use of code. In particular, good solutions may be re-used in OOP [7].

In the mobile environment, applications are often written on different operating systems [http://en.wikipedia.org/wiki/Mobile_operating_system] on different mobile systems. There is increased interaction between mobile systems, especially for cell phones. The Service Oriented Architecture design pattern is especially well suited for this situation. This is a fairly new field, and methods are currently being developed to aid developers.

== Ways to Adapt Using Design Patterns ==

Several principles and patterns have been understood and developed in developing for mobile applications. Many of these methods are still undergoing change and experimentation. There are new methods being developed and others left behind. A design pattern can be defined as a repeatable solution to a common problem in software. It is a template for how to solve the problem, not actual code [7].

Ease of navigation is a particularly important principle, because of the reduced number of user inputs (for example, buttons from 0 to 9 instead of a mouse and keyboard). Everything in an application should be no more than three clicks away. If a program is too "deep", requiring many clicks, this will be a problem because it takes longer to navigate on a mobile device. If the application is to "broad" as in too many links on one page, the data may not all fit on the screen. One way to mitigate this problem is to reduce functionality, to keep the application as simple as possible [5].

Service Oriented Architectures are well suited for the mobile environment [3]. Within this architecture, applications can make use of various services by sending messages to them via a protocol. Applications may interact with services on operating systems and written in different languages, as long as the protocol is followed. Services may be located on different mobile devices. This protocol is a good fit, allowing applications to reach out to services on other mobile devices, even though they may be on very different devices.

*'''''Service Oriented Architecture Example''''' [3]

[[Image:SOA_Example.jpg]]

The Energy Conscious (EC) Factory model [7]!!!!

The [http://www.javaworld.com/javaworld/jw-10-2005/jw-1003-mvc.html Model View Controller] pattern [1] fits the mobile environment well. Models may be set up so that optimum data structures are used, as was discussed for the EC Factory pattern [7]. Effecient designs may be built into the controllers. Views may be standardized for the application to handle the small screens.

The meeting pattern is especially useful in mobile environments. One device or application serves as the meeting manager. The meeting manager coordinates and tracks the other agents (programs or applications). These agents communicate with the oversight of the meeting manager. Agents may be located on different devices, even on computers with more resources. This is especially well suited for the mobile environment because it is a good way to manage the communications and relatively small applications. A further benefit of the meeting pattern is that mobile applications may be combined (somewhat in the fashion of parallel computing) to do more and provide more resources [6].

*'''''Meeting pattern Example''''' [6]

[[Image:MCFigure3.jpg]]

The master slave pattern is simmilar to the meeting pattern. Instead of a meeting manager and agents, there is a master that creates, uses, and destroys slave objects. The master assigns the slaves tasks to complete. Like agents in the meeting pattern, slaves may be located on different mobile devices, or even on computers that have more resources. The master / slave pattern is very useful for performing actions in parallel on different mobile devices [6].

== Conclusion ==
In conclusion, certain design patterns are especially useful in the mobile design environment. These patterns help developers to produce applications quickly and applications which make efficient use of the limited resources in the mobile environment. Most design patterns can be of benefit to mobile applications, but certain patterns have features that are especially well suited. The EC factory pattern was designed for the mobile environment to reduce energy use [7]. A few other patterns show much promise with mobile devices, including the meeting pattern, master / slave pattern, and service oriented architectures.

== References ==

1. http://www.javaworld.com/javaworld/jw-10-2005/jw-1003-mvc.html - Model View Controller Architecture

2. http://patterns.littlespringsdesign.com/index.php/The_mobile_challenge - Challenges of the Mobile Environment

3. http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki2_17_va - Service Oriented Architecture

4. http://wiki.forum.nokia.com/index.php/Understading_Desing_Patterns - Understanding Design Patterns

5. http://dev.opera.com/articles/view/designing-and-developing-mobile-web-site/ - Designing and Developing mobile web sites in the real world

6. Emerson F.A Lima, Patrícia D. L. Machado, Fláavio R. Sampaio, and Jorge C. A. Figueiredo. ACM SIGSOFT Software Engineering Notes. Volume 29, issue 3 ISSN: 0163-5948 http://portal.acm.org/citation.cfm?id=986710.986726 Universidade Federal de Campina Grande, Paraíba, Brazil, May, 2004.

7. Kayun Chantarasathaporn, Chonawat Srisa-an. ACM International Conference Proceeding Series; Vol. 270 Proceedings of the 3rd international conference on Mobile technology, applications & systems SESSION: Mobile applications, article 29. ISBN:1-59593-519-3 http://portal.acm.org/citation.cfm?id=1292331.1292364 Bangkok, Thailand, 2006

8. WIM Workshop,Uppsala, 17.9.2004

9. Mobile Application Development, Sam Nasr , www.CleavelandDotNet.info

10. Energy Conscious Factory Method Design Pattern for Mobile Devices with C# and Intermediate Language, by Kayun Chantarasathaporn and Chonawat Srisa-an, Ph.D. at Faculty of Information Technology, Rangsit University, Thailand.

11. http://www.codeproject.com/csharp/structs_in_csharp.asp
== Working Notes ==

Two major design patterns that have come up to help in mobile softwares and to address the above discussed issues in a mobile device are : Energy Conscious design pattern and Mobile agent design pattern

=== Energy Conscious Factory Design ===

Power consumption has not been much of a concern to developers in the past, but this is important in the mobile environment. Battery power on cell phones is limited. [7]
- Use registers instead of memory whenever possible (registers use less energy)
- Use structs instead of classes
- Use static instead of dynamic

Some strategies and their experimental results are discussed in [10]: 
[[Image:ECFactory_Fig8.jpg| General Strategies]]

'''''Factory Method pattern''''' is a pattern that returns an object from one of various possible classes. Which class is chosen to be an object generator is depended on data provided to it.
Factory Method Pattern is a good pattern to build upon for energy conscious pattern. 
Lets look at both versions. 
Class Diagram of sample Factory Method pattern::
[[Image:ECFactory_Fig1.jpg|Class Diagram of sample Factory Method pattern ]]

Sequence Diagram (with Activations) of sample Factory Method pattern ::
[[Image:ECFactory_Fig2.jpg|Sequence Diagram (with Activations) of sample Factory Method pattern ]]

'''''Modified Factory Method pattern'''''
As regular Factory Method pattern was not designed for being energy concerned, so, it is slightly modified. Some of the critical tweaks are:
*Factory Method Pattern that mixes usage of struct and class in several manners.
*Factory Method Pattern that uses static factory method in Factory struct
*Factory Method Pattern that applies generics principle which is parametered type
*Factory Method Pattern That Uses ConcreteProduct Class, ConcreteCreator Struct with Non-Static FactoryMethod()

Modified Factory Method pattern applies both struct and class recommendations.

''Factory Method Pattern That Uses ConcreteProduct Class, ConcreteCreator Struct with Non-Static FactoryMethod()::''
[[Image:ECFactory_Fig3.jpg|Class Diagram of Factory Method pattern]]

In this case, we use VehicleChooser which is a ConcreteCreator as struct while Car, Plane and Ship which are ConcreteProduct as class. Method ChooseVehicle(...) which is as FactoryMethod() is non-static.

''Factory Method Pattern That Uses ConcreteProduct Struct, ConcreteCreator Struct with Static FactoryMethod()::''
[[Image:ECFactory_Fig4.jpg|Class Diagram of Factory Method pattern]] 
If we use static method appropriately, CPU workload will be reduced. This affects directly in lessening power consumption as a whole.

'''''Experimental Result:'''''
 For various combination shown in figure, the tests were run, and the result obtained are shown in the graph below.
 ''Characteristic of components in each combination::''
[[Image:ECFactory_Fig5.jpg|Characteristic of components in each combination ]] 

''CPU Usage Comparison ::''
[[Image:ECFactory_Fig6.jpg|CPU Usage Comparison ]] 
UPT is utilized processor time and TPT is total processor time

 ''Energy Usage Comparison::''

[[Image:ECFactory_Fig7.jpg|Energy Usage Comparison]] 

It is observed that Energy Concerned Factory Method Pattern can be obtained from the combination of ConcreteProduct classes and ConcreteCreator struct with static FactoryMethod(). The ECFactory Method Pattern consumes less CPU time than regular Factory Method Pattern around 11% while it is better than the worst case around 80%. The bigger the ConcreteProduct type size is, the more range between the best and the worst case in term of energy consumption will be.
So it is clearly proven how this pattern can save energy.

CSC/ECE 517 Fall 2009/wiki3 21 MobileDesignPattern

2009-11-19T14:55:41Z

Wolverine: /* Energy Conscious Factory Design */

== Design Pattern for Mobile Applications ==

The popularity of mobile applications is rising. Design patterns are useful in almost any coding tasks. While almost any design pattern could be used within mobile applications, certain patterns are well suited for the unique environment of mobile applications. This wiki explains the mobile application environment, then focuses on design patterns that work well within this new emerging environment.

__TOC__

== The Mobile Application Environment ==

The mobile application environment is new and presents many unique opportunities and challenges for developers. It seems almost everyone now has a cellphone, blackberry, or other small portable device. These devices are "getting smarter" in that many people are developing new applications for them. Cell phones no longer are just used to call people, they often have features like text messaging, cameras, video games, web browsers and more. There is much opportunity for developers to write new applications for mobile devices.

While opportunity abounds, there are also quite a few challenges. Mobile applications have less resources than are typically found in other development environments. The screen on mobile devices is typically smaller, there is usually not a keyboard and mouse (user inputs are reduced) [5]. CPU resources are generally less than those found in the typical environment [7]. Power usage is also limited because a battery is typically used, so reducing power use by the application is an important goal [7]. Connections are typically expensive and are often prone to loss of signals [6].

Another problem is that there is a high demand for applications to be developed quickly [7]. The mobile environment is changing rapidly [2]. Some of the lower level programming languages were useful because they produced fast applications, but they took too long to develop with[22 http://www.umsl.edu/~subramaniana/concepts1.html]. Now, with the increased demand for applications quickly, Object Oriented Programming (OOP) is used more. While this causes a greater usage of resources, this is outweighed by the much quicker development cycle and the re-use of code. In particular, good solutions may be re-used in OOP [7].

In the mobile environment, applications are often written on different operating systems [http://en.wikipedia.org/wiki/Mobile_operating_system] on different mobile systems. There is increased interaction between mobile systems, especially for cell phones. The Service Oriented Architecture design pattern is especially well suited for this situation. This is a fairly new field, and methods are currently being developed to aid developers.

== Ways to Adapt Using Design Patterns ==

Several principles and patterns have been understood and developed in developing for mobile applications. Many of these methods are still undergoing change and experimentation. There are new methods being developed and others left behind. A design pattern can be defined as a repeatable solution to a common problem in software. It is a template for how to solve the problem, not actual code [7].

Ease of navigation is a particularly important principle, because of the reduced number of user inputs (for example, buttons from 0 to 9 instead of a mouse and keyboard). Everything in an application should be no more than three clicks away. If a program is too "deep", requiring many clicks, this will be a problem because it takes longer to navigate on a mobile device. If the application is to "broad" as in too many links on one page, the data may not all fit on the screen. One way to mitigate this problem is to reduce functionality, to keep the application as simple as possible [5].

Service Oriented Architectures are well suited for the mobile environment [3]. Within this architecture, applications can make use of various services by sending messages to them via a protocol. Applications may interact with services on operating systems and written in different languages, as long as the protocol is followed. Services may be located on different mobile devices. This protocol is a good fit, allowing applications to reach out to services on other mobile devices, even though they may be on very different devices.

*'''''Service Oriented Architecture Example''''' [3]

[[Image:SOA_Example.jpg]]

The Energy Conscious (EC) Factory model [7]!!!!

The [http://www.javaworld.com/javaworld/jw-10-2005/jw-1003-mvc.html Model View Controller] pattern [1] fits the mobile environment well. Models may be set up so that optimum data structures are used, as was discussed for the EC Factory pattern [7]. Effecient designs may be built into the controllers. Views may be standardized for the application to handle the small screens.

The meeting pattern is especially useful in mobile environments. One device or application serves as the meeting manager. The meeting manager coordinates and tracks the other agents (programs or applications). These agents communicate with the oversight of the meeting manager. Agents may be located on different devices, even on computers with more resources. This is especially well suited for the mobile environment because it is a good way to manage the communications and relatively small applications. A further benefit of the meeting pattern is that mobile applications may be combined (somewhat in the fashion of parallel computing) to do more and provide more resources [6].

*'''''Meeting pattern Example''''' [6]

[[Image:MCFigure3.jpg]]

The master slave pattern is simmilar to the meeting pattern. Instead of a meeting manager and agents, there is a master that creates, uses, and destroys slave objects. The master assigns the slaves tasks to complete. Like agents in the meeting pattern, slaves may be located on different mobile devices, or even on computers that have more resources. The master / slave pattern is very useful for performing actions in parallel on different mobile devices [6].

== Conclusion ==
In conclusion, certain design patterns are especially useful in the mobile design environment. These patterns help developers to produce applications quickly and applications which make efficient use of the limited resources in the mobile environment. Most design patterns can be of benefit to mobile applications, but certain patterns have features that are especially well suited. The EC factory pattern was designed for the mobile environment to reduce energy use [7]. A few other patterns show much promise with mobile devices, including the meeting pattern, master / slave pattern, and service oriented architectures.

== References ==

1. http://www.javaworld.com/javaworld/jw-10-2005/jw-1003-mvc.html - Model View Controller Architecture

2. http://patterns.littlespringsdesign.com/index.php/The_mobile_challenge - Challenges of the Mobile Environment

3. http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki2_17_va - Service Oriented Architecture

4. http://wiki.forum.nokia.com/index.php/Understading_Desing_Patterns - Understanding Design Patterns

5. http://dev.opera.com/articles/view/designing-and-developing-mobile-web-site/ - Designing and Developing mobile web sites in the real world

6. Emerson F.A Lima, Patrícia D. L. Machado, Fláavio R. Sampaio, and Jorge C. A. Figueiredo. ACM SIGSOFT Software Engineering Notes. Volume 29, issue 3 ISSN: 0163-5948 http://portal.acm.org/citation.cfm?id=986710.986726 Universidade Federal de Campina Grande, Paraíba, Brazil, May, 2004.

7. Kayun Chantarasathaporn, Chonawat Srisa-an. ACM International Conference Proceeding Series; Vol. 270 Proceedings of the 3rd international conference on Mobile technology, applications & systems SESSION: Mobile applications, article 29. ISBN:1-59593-519-3 http://portal.acm.org/citation.cfm?id=1292331.1292364 Bangkok, Thailand, 2006

8. WIM Workshop,Uppsala, 17.9.2004

9. Mobile Application Development, Sam Nasr , www.CleavelandDotNet.info

10. Energy Conscious Factory Method Design Pattern for Mobile Devices with C# and Intermediate Language, by Kayun Chantarasathaporn and Chonawat Srisa-an, Ph.D. at Faculty of Information Technology, Rangsit University, Thailand.

11. http://www.codeproject.com/csharp/structs_in_csharp.asp
== Working Notes ==

Two major design patterns that have come up to help in mobile softwares and to address the above discussed issues in a mobile device are : Energy Conscious design pattern and Mobile agent design pattern

=== Energy Conscious Factory Design ===

Power consumption has not been much of a concern to developers in the past, but this is important in the mobile environment. Battery power on cell phones is limited. [7]
- Use registers instead of memory whenever possible (registers use less energy)
- Use structs instead of classes
- Use static instead of dynamic

Some strategies and their experimental results are discussed in [10]: 
[[Image:ECFactory_Fig8.jpg| General Strategies]]

'''''Factory Method pattern''''' is a pattern that returns an object from one of various possible classes. Which class is chosen to be an object generator is depended on data provided to it.
Factory Method Pattern is a good pattern to build upon for energy conscious pattern. 
Lets look at both versions. 
Class Diagram of sample Factory Method pattern::
[[Image:ECFactory_Fig1.jpg|Class Diagram of sample Factory Method pattern ]]

Sequence Diagram (with Activations) of sample Factory Method pattern ::
[[Image:ECFactory_Fig2.jpg|Sequence Diagram (with Activations) of sample Factory Method pattern ]]

'''''Modified Factory Method pattern'''''
As regular Factory Method pattern was not designed for being energy concerned, so, it is slightly modified. Some of the critical tweaks are:
*Factory Method Pattern that mixes usage of struct and class in several manners.
*Factory Method Pattern that uses static factory method in Factory struct
*Factory Method Pattern that applies generics principle which is parametered type
*Factory Method Pattern That Uses ConcreteProduct Class, ConcreteCreator Struct with Non-Static FactoryMethod()

Modified Factory Method pattern applies both struct and class recommendations.

''Factory Method Pattern That Uses ConcreteProduct Class, ConcreteCreator Struct with Non-Static FactoryMethod()::''
[[Image:ECFactory_Fig3.jpg|Class Diagram of Factory Method pattern]]

In this case, we use VehicleChooser which is a ConcreteCreator as struct while Car, Plane and Ship which are ConcreteProduct as class. Method ChooseVehicle(...) which is as FactoryMethod() is non-static.

''Factory Method Pattern That Uses ConcreteProduct Struct, ConcreteCreator Struct with Static FactoryMethod()::''
[[Image:ECFactory_Fig4.jpg|Class Diagram of Factory Method pattern]]
If we use static method appropriately, CPU workload will be reduced. This affects directly in lessening power consumption as a whole.

'''''Experimental Result:'''''
 For various combination shown in figure, the tests were run, and the result obtained are shown in the graph below.
 Characteristic of components in each combination::
[[Image:ECFactory_Fig5.jpg|Characteristic of components in each combination ]] 
CPU Usage Comparison ::
[[Image:ECFactory_Fig6.jpg|CPU Usage Comparison ]] 
Energy Usage Comparison::
[[Image:ECFactory_Fig7.jpg|Energy Usage Comparison]] 

It is observed that Energy Concerned Factory Method Pattern can be obtained from the combination of ConcreteProduct classes and ConcreteCreator struct with static FactoryMethod(). The ECFactory Method Pattern consumes less CPU time than regular Factory Method Pattern around 11% while it is better than the worst case around 80%. The bigger the ConcreteProduct type size is, the more range between the best and the worst case in term of energy consumption will be.
So it is clearly proven how this pattern can save energy.

CSC/ECE 517 Fall 2009/wiki3 21 MobileDesignPattern

2009-11-19T14:53:53Z

Wolverine: /* Energy Conscious Factory Design */

== Design Pattern for Mobile Applications ==

The popularity of mobile applications is rising. Design patterns are useful in almost any coding tasks. While almost any design pattern could be used within mobile applications, certain patterns are well suited for the unique environment of mobile applications. This wiki explains the mobile application environment, then focuses on design patterns that work well within this new emerging environment.

__TOC__

== The Mobile Application Environment ==

The mobile application environment is new and presents many unique opportunities and challenges for developers. It seems almost everyone now has a cellphone, blackberry, or other small portable device. These devices are "getting smarter" in that many people are developing new applications for them. Cell phones no longer are just used to call people, they often have features like text messaging, cameras, video games, web browsers and more. There is much opportunity for developers to write new applications for mobile devices.

While opportunity abounds, there are also quite a few challenges. Mobile applications have less resources than are typically found in other development environments. The screen on mobile devices is typically smaller, there is usually not a keyboard and mouse (user inputs are reduced) [5]. CPU resources are generally less than those found in the typical environment [7]. Power usage is also limited because a battery is typically used, so reducing power use by the application is an important goal [7]. Connections are typically expensive and are often prone to loss of signals [6].

Another problem is that there is a high demand for applications to be developed quickly [7]. The mobile environment is changing rapidly [2]. Some of the lower level programming languages were useful because they produced fast applications, but they took too long to develop with[22 http://www.umsl.edu/~subramaniana/concepts1.html]. Now, with the increased demand for applications quickly, Object Oriented Programming (OOP) is used more. While this causes a greater usage of resources, this is outweighed by the much quicker development cycle and the re-use of code. In particular, good solutions may be re-used in OOP [7].

In the mobile environment, applications are often written on different operating systems [http://en.wikipedia.org/wiki/Mobile_operating_system] on different mobile systems. There is increased interaction between mobile systems, especially for cell phones. The Service Oriented Architecture design pattern is especially well suited for this situation. This is a fairly new field, and methods are currently being developed to aid developers.

== Ways to Adapt Using Design Patterns ==

Several principles and patterns have been understood and developed in developing for mobile applications. Many of these methods are still undergoing change and experimentation. There are new methods being developed and others left behind. A design pattern can be defined as a repeatable solution to a common problem in software. It is a template for how to solve the problem, not actual code [7].

Ease of navigation is a particularly important principle, because of the reduced number of user inputs (for example, buttons from 0 to 9 instead of a mouse and keyboard). Everything in an application should be no more than three clicks away. If a program is too "deep", requiring many clicks, this will be a problem because it takes longer to navigate on a mobile device. If the application is to "broad" as in too many links on one page, the data may not all fit on the screen. One way to mitigate this problem is to reduce functionality, to keep the application as simple as possible [5].

Service Oriented Architectures are well suited for the mobile environment [3]. Within this architecture, applications can make use of various services by sending messages to them via a protocol. Applications may interact with services on operating systems and written in different languages, as long as the protocol is followed. Services may be located on different mobile devices. This protocol is a good fit, allowing applications to reach out to services on other mobile devices, even though they may be on very different devices.

*'''''Service Oriented Architecture Example''''' [3]

[[Image:SOA_Example.jpg]]

The Energy Conscious (EC) Factory model [7]!!!!

The [http://www.javaworld.com/javaworld/jw-10-2005/jw-1003-mvc.html Model View Controller] pattern [1] fits the mobile environment well. Models may be set up so that optimum data structures are used, as was discussed for the EC Factory pattern [7]. Effecient designs may be built into the controllers. Views may be standardized for the application to handle the small screens.

The meeting pattern is especially useful in mobile environments. One device or application serves as the meeting manager. The meeting manager coordinates and tracks the other agents (programs or applications). These agents communicate with the oversight of the meeting manager. Agents may be located on different devices, even on computers with more resources. This is especially well suited for the mobile environment because it is a good way to manage the communications and relatively small applications. A further benefit of the meeting pattern is that mobile applications may be combined (somewhat in the fashion of parallel computing) to do more and provide more resources [6].

*'''''Meeting pattern Example''''' [6]

[[Image:MCFigure3.jpg]]

The master slave pattern is simmilar to the meeting pattern. Instead of a meeting manager and agents, there is a master that creates, uses, and destroys slave objects. The master assigns the slaves tasks to complete. Like agents in the meeting pattern, slaves may be located on different mobile devices, or even on computers that have more resources. The master / slave pattern is very useful for performing actions in parallel on different mobile devices [6].

== Conclusion ==
In conclusion, certain design patterns are especially useful in the mobile design environment. These patterns help developers to produce applications quickly and applications which make efficient use of the limited resources in the mobile environment. Most design patterns can be of benefit to mobile applications, but certain patterns have features that are especially well suited. The EC factory pattern was designed for the mobile environment to reduce energy use [7]. A few other patterns show much promise with mobile devices, including the meeting pattern, master / slave pattern, and service oriented architectures.

== References ==

1. http://www.javaworld.com/javaworld/jw-10-2005/jw-1003-mvc.html - Model View Controller Architecture

2. http://patterns.littlespringsdesign.com/index.php/The_mobile_challenge - Challenges of the Mobile Environment

3. http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki2_17_va - Service Oriented Architecture

4. http://wiki.forum.nokia.com/index.php/Understading_Desing_Patterns - Understanding Design Patterns

5. http://dev.opera.com/articles/view/designing-and-developing-mobile-web-site/ - Designing and Developing mobile web sites in the real world

6. Emerson F.A Lima, Patrícia D. L. Machado, Fláavio R. Sampaio, and Jorge C. A. Figueiredo. ACM SIGSOFT Software Engineering Notes. Volume 29, issue 3 ISSN: 0163-5948 http://portal.acm.org/citation.cfm?id=986710.986726 Universidade Federal de Campina Grande, Paraíba, Brazil, May, 2004.

7. Kayun Chantarasathaporn, Chonawat Srisa-an. ACM International Conference Proceeding Series; Vol. 270 Proceedings of the 3rd international conference on Mobile technology, applications & systems SESSION: Mobile applications, article 29. ISBN:1-59593-519-3 http://portal.acm.org/citation.cfm?id=1292331.1292364 Bangkok, Thailand, 2006

8. WIM Workshop,Uppsala, 17.9.2004

9. Mobile Application Development, Sam Nasr , www.CleavelandDotNet.info

10. Energy Conscious Factory Method Design Pattern for Mobile Devices with C# and Intermediate Language, by Kayun Chantarasathaporn and Chonawat Srisa-an, Ph.D. at Faculty of Information Technology, Rangsit University, Thailand.

11. http://www.codeproject.com/csharp/structs_in_csharp.asp
== Working Notes ==

Two major design patterns that have come up to help in mobile softwares and to address the above discussed issues in a mobile device are : Energy Conscious design pattern and Mobile agent design pattern

=== Energy Conscious Factory Design ===

Power consumption has not been much of a concern to developers in the past, but this is important in the mobile environment. Battery power on cell phones is limited. [7]
- Use registers instead of memory whenever possible (registers use less energy)
- Use structs instead of classes
- Use static instead of dynamic

Some strategies and their experimental results are discussed in [10]: 
[[Image:ECFactory_Fig8.jpg| General Strategies]]

'''''Factory Method pattern''''' is a pattern that returns an object from one of various possible classes. Which class is chosen to be an object generator is depended on data provided to it.
Factory Method Pattern is a good pattern to build upon for energy conscious pattern. 
Lets look at both versions. 
Class Diagram of sample Factory Method pattern::
[[Image:ECFactory_Fig1.jpg|Class Diagram of sample Factory Method pattern ]]

Sequence Diagram (with Activations) of sample Factory Method pattern ::
[[Image:ECFactory_Fig2.jpg|Sequence Diagram (with Activations) of sample Factory Method pattern ]]

'''''Modified Factory Method pattern'''''
As regular Factory Method pattern was not designed for being energy concerned, so, it is slightly modified. Some of the critical tweaks are:
*Factory Method Pattern that mixes usage of struct and class in several manners.
*Factory Method Pattern that uses static factory method in Factory struct
*Factory Method Pattern that applies generics principle which is parametered type
*Factory Method Pattern That Uses ConcreteProduct Class, ConcreteCreator Struct with Non-Static FactoryMethod()

Modified Factory Method pattern applies both struct and class recommendations.

''Factory Method Pattern That Uses ConcreteProduct Class, ConcreteCreator Struct with Non-Static FactoryMethod()::''
[[Image:ECFactory_Fig3.jpg|Class Diagram of Factory Method pattern]]

In this case, we use VehicleChooser which is a ConcreteCreator as struct while Car, Plane and Ship which are ConcreteProduct as class. Method ChooseVehicle(...) which is as FactoryMethod() is non-static.

''Factory Method Pattern That Uses ConcreteProduct Struct, ConcreteCreator Struct with Static FactoryMethod()::''
[[Image:ECFactory_Fig4.jpg|Class Diagram of Factory Method pattern]]
If we use static method appropriately, CPU workload will be reduced. This affects directly in lessening power consumption as a whole.

'''''Experimental Result:'''''
 For various combination shown in figure, the tests were run, and the result obtained are shown in the graph below.
 Characteristic of components in each combination
[[Image:ECFactory_Fig5.jpg|Characteristic of components in each combination ]]
CPU Usage Comparison ::
[[Image:ECFactory_Fig6.jpg|CPU Usage Comparison ]]
Energy Usage Comparison::
[[Image:ECFactory_Fig7.jpg|Energy Usage Comparison]]

It is observed that Energy Concerned Factory Method Pattern can be obtained from the combination of ConcreteProduct classes and ConcreteCreator struct with static FactoryMethod(). The ECFactory Method Pattern consumes less CPU time than regular Factory Method Pattern around 11% while it is better than the worst case around 80%. The bigger the ConcreteProduct type size is, the more range between the best and the worst case in term of energy consumption will be.
So it is clearly proven how this pattern can save energy.

CSC/ECE 517 Fall 2009/wiki3 21 MobileDesignPattern

2009-11-19T14:51:16Z

Wolverine: /* Energy Conscious Factory Design */

== Design Pattern for Mobile Applications ==

The popularity of mobile applications is rising. Design patterns are useful in almost any coding tasks. While almost any design pattern could be used within mobile applications, certain patterns are well suited for the unique environment of mobile applications. This wiki explains the mobile application environment, then focuses on design patterns that work well within this new emerging environment.

__TOC__

== The Mobile Application Environment ==

The mobile application environment is new and presents many unique opportunities and challenges for developers. It seems almost everyone now has a cellphone, blackberry, or other small portable device. These devices are "getting smarter" in that many people are developing new applications for them. Cell phones no longer are just used to call people, they often have features like text messaging, cameras, video games, web browsers and more. There is much opportunity for developers to write new applications for mobile devices.

While opportunity abounds, there are also quite a few challenges. Mobile applications have less resources than are typically found in other development environments. The screen on mobile devices is typically smaller, there is usually not a keyboard and mouse (user inputs are reduced) [5]. CPU resources are generally less than those found in the typical environment [7]. Power usage is also limited because a battery is typically used, so reducing power use by the application is an important goal [7]. Connections are typically expensive and are often prone to loss of signals [6].

Another problem is that there is a high demand for applications to be developed quickly [7]. The mobile environment is changing rapidly [2]. Some of the lower level programming languages were useful because they produced fast applications, but they took too long to develop with[22 http://www.umsl.edu/~subramaniana/concepts1.html]. Now, with the increased demand for applications quickly, Object Oriented Programming (OOP) is used more. While this causes a greater usage of resources, this is outweighed by the much quicker development cycle and the re-use of code. In particular, good solutions may be re-used in OOP [7].

In the mobile environment, applications are often written on different operating systems [http://en.wikipedia.org/wiki/Mobile_operating_system] on different mobile systems. There is increased interaction between mobile systems, especially for cell phones. The Service Oriented Architecture design pattern is especially well suited for this situation. This is a fairly new field, and methods are currently being developed to aid developers.

== Ways to Adapt Using Design Patterns ==

Several principles and patterns have been understood and developed in developing for mobile applications. Many of these methods are still undergoing change and experimentation. There are new methods being developed and others left behind. A design pattern can be defined as a repeatable solution to a common problem in software. It is a template for how to solve the problem, not actual code [7].

Ease of navigation is a particularly important principle, because of the reduced number of user inputs (for example, buttons from 0 to 9 instead of a mouse and keyboard). Everything in an application should be no more than three clicks away. If a program is too "deep", requiring many clicks, this will be a problem because it takes longer to navigate on a mobile device. If the application is to "broad" as in too many links on one page, the data may not all fit on the screen. One way to mitigate this problem is to reduce functionality, to keep the application as simple as possible [5].

Service Oriented Architectures are well suited for the mobile environment [3]. Within this architecture, applications can make use of various services by sending messages to them via a protocol. Applications may interact with services on operating systems and written in different languages, as long as the protocol is followed. Services may be located on different mobile devices. This protocol is a good fit, allowing applications to reach out to services on other mobile devices, even though they may be on very different devices.

*'''''Service Oriented Architecture Example''''' [3]

[[Image:SOA_Example.jpg]]

The Energy Conscious (EC) Factory model [7]!!!!

The [http://www.javaworld.com/javaworld/jw-10-2005/jw-1003-mvc.html Model View Controller] pattern [1] fits the mobile environment well. Models may be set up so that optimum data structures are used, as was discussed for the EC Factory pattern [7]. Effecient designs may be built into the controllers. Views may be standardized for the application to handle the small screens.

The meeting pattern is especially useful in mobile environments. One device or application serves as the meeting manager. The meeting manager coordinates and tracks the other agents (programs or applications). These agents communicate with the oversight of the meeting manager. Agents may be located on different devices, even on computers with more resources. This is especially well suited for the mobile environment because it is a good way to manage the communications and relatively small applications. A further benefit of the meeting pattern is that mobile applications may be combined (somewhat in the fashion of parallel computing) to do more and provide more resources [6].

*'''''Meeting pattern Example''''' [6]

[[Image:MCFigure3.jpg]]

The master slave pattern is simmilar to the meeting pattern. Instead of a meeting manager and agents, there is a master that creates, uses, and destroys slave objects. The master assigns the slaves tasks to complete. Like agents in the meeting pattern, slaves may be located on different mobile devices, or even on computers that have more resources. The master / slave pattern is very useful for performing actions in parallel on different mobile devices [6].

== Conclusion ==
In conclusion, certain design patterns are especially useful in the mobile design environment. These patterns help developers to produce applications quickly and applications which make efficient use of the limited resources in the mobile environment. Most design patterns can be of benefit to mobile applications, but certain patterns have features that are especially well suited. The EC factory pattern was designed for the mobile environment to reduce energy use [7]. A few other patterns show much promise with mobile devices, including the meeting pattern, master / slave pattern, and service oriented architectures.

== References ==

1. http://www.javaworld.com/javaworld/jw-10-2005/jw-1003-mvc.html - Model View Controller Architecture

2. http://patterns.littlespringsdesign.com/index.php/The_mobile_challenge - Challenges of the Mobile Environment

3. http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki2_17_va - Service Oriented Architecture

4. http://wiki.forum.nokia.com/index.php/Understading_Desing_Patterns - Understanding Design Patterns

5. http://dev.opera.com/articles/view/designing-and-developing-mobile-web-site/ - Designing and Developing mobile web sites in the real world

6. Emerson F.A Lima, Patrícia D. L. Machado, Fláavio R. Sampaio, and Jorge C. A. Figueiredo. ACM SIGSOFT Software Engineering Notes. Volume 29, issue 3 ISSN: 0163-5948 http://portal.acm.org/citation.cfm?id=986710.986726 Universidade Federal de Campina Grande, Paraíba, Brazil, May, 2004.

7. Kayun Chantarasathaporn, Chonawat Srisa-an. ACM International Conference Proceeding Series; Vol. 270 Proceedings of the 3rd international conference on Mobile technology, applications & systems SESSION: Mobile applications, article 29. ISBN:1-59593-519-3 http://portal.acm.org/citation.cfm?id=1292331.1292364 Bangkok, Thailand, 2006

8. WIM Workshop,Uppsala, 17.9.2004

9. Mobile Application Development, Sam Nasr , www.CleavelandDotNet.info

10. Energy Conscious Factory Method Design Pattern for Mobile Devices with C# and Intermediate Language, by Kayun Chantarasathaporn and Chonawat Srisa-an, Ph.D. at Faculty of Information Technology, Rangsit University, Thailand.

11. http://www.codeproject.com/csharp/structs_in_csharp.asp
== Working Notes ==

Two major design patterns that have come up to help in mobile softwares and to address the above discussed issues in a mobile device are : Energy Conscious design pattern and Mobile agent design pattern

=== Energy Conscious Factory Design ===

Power consumption has not been much of a concern to developers in the past, but this is important in the mobile environment. Battery power on cell phones is limited. [7]
- Use registers instead of memory whenever possible (registers use less energy)
- Use structs instead of classes
- Use static instead of dynamic

Some strategies and their experimental results are discussed in [10]: 
[[Image:ECFactory_Fig8.jpg| General Strategies]]

'''''Factory Method pattern''''' is a pattern that returns an object from one of various possible classes. Which class is chosen to be an object generator is depended on data provided to it.
Factory Method Pattern is a good pattern to build upon for energy conscious pattern. 
Lets look at both versions. 
Class Diagram of sample Factory Method pattern::
[[Image:ECFactory_Fig1.jpg|Class Diagram of sample Factory Method pattern ]]

Sequence Diagram (with Activations) of sample Factory Method pattern ::
[[Image:ECFactory_Fig2.jpg|Sequence Diagram (with Activations) of sample Factory Method pattern ]]

'''''Modified Factory Method pattern'''''
As regular Factory Method pattern was not designed for being energy concerned, so, it is slightly modified. Some of the critical tweaks are:
*Factory Method Pattern that mixes usage of struct and class in several manners.
*Factory Method Pattern that uses static factory method in Factory struct
*Factory Method Pattern that applies generics principle which is parametered type
*Factory Method Pattern That Uses ConcreteProduct Class, ConcreteCreator Struct with Non-Static FactoryMethod()

Modified Factory Method pattern applies both struct and class recommendations.

''Factory Method Pattern That Uses ConcreteProduct Class, ConcreteCreator Struct with Non-Static FactoryMethod()''
[[Image:ECFactory_Fig3.jpg|Class Diagram of Factory Method pattern]]

In this case, we use VehicleChooser which is a ConcreteCreator as struct while Car, Plane and Ship which are ConcreteProduct as class. Method ChooseVehicle(...) which is as FactoryMethod() is non-static.

''Factory Method Pattern That Uses ConcreteProduct Struct, ConcreteCreator Struct with Static FactoryMethod()''
[[Image:ECFactory_Fig4.jpg|Class Diagram of Factory Method pattern]]
If we use static method appropriately, CPU workload will be reduced. This affects directly in lessening power consumption as a whole.

'''''Experimental Result:'''''
For various combination shown in figure, the tests were run, and the result obtained are shown in the graph below.
Characteristic of components in each combination
[[Image:ECFactory_Fig5.jpg|Characteristic of components in each combination ]]
CPU Usage Comparison
[[Image:ECFactory_Fig6.jpg|CPU Usage Comparison ]]
Energy Usage Comparison
[[Image:ECFactory_Fig7.jpg]|Energy Usage Comparison]

It is observed that Energy Concerned Factory Method Pattern can be obtained from the combination of ConcreteProduct classes and ConcreteCreator struct with static FactoryMethod(). The ECFactory Method Pattern consumes less CPU time than regular Factory Method Pattern around 11% while it is better than the worst case around 80%. The bigger the ConcreteProduct type size is, the more range between the best and the worst case in term of energy consumption will be.
So it is clearly proven how this pattern can save energy.

CSC/ECE 517 Fall 2009/wiki3 21 MobileDesignPattern

2009-11-19T14:43:37Z

Wolverine: /* Energy Conscious Factory Design */

== Design Pattern for Mobile Applications ==

The popularity of mobile applications is rising. Design patterns are useful in almost any coding tasks. While almost any design pattern could be used within mobile applications, certain patterns are well suited for the unique environment of mobile applications. This wiki explains the mobile application environment, then focuses on design patterns that work well within this new emerging environment.

__TOC__

== The Mobile Application Environment ==

The mobile application environment is new and presents many unique opportunities and challenges for developers. It seems almost everyone now has a cellphone, blackberry, or other small portable device. These devices are "getting smarter" in that many people are developing new applications for them. Cell phones no longer are just used to call people, they often have features like text messaging, cameras, video games, web browsers and more. There is much opportunity for developers to write new applications for mobile devices.

While opportunity abounds, there are also quite a few challenges. Mobile applications have less resources than are typically found in other development environments. The screen on mobile devices is typically smaller, there is usually not a keyboard and mouse (user inputs are reduced) [5]. CPU resources are generally less than those found in the typical environment [7]. Power usage is also limited because a battery is typically used, so reducing power use by the application is an important goal [7]. Connections are typically expensive and are often prone to loss of signals [6].

Another problem is that there is a high demand for applications to be developed quickly [7]. The mobile environment is changing rapidly [2]. Some of the lower level programming languages were useful because they produced fast applications, but they took too long to develop with[22 http://www.umsl.edu/~subramaniana/concepts1.html]. Now, with the increased demand for applications quickly, Object Oriented Programming (OOP) is used more. While this causes a greater usage of resources, this is outweighed by the much quicker development cycle and the re-use of code. In particular, good solutions may be re-used in OOP [7].

In the mobile environment, applications are often written on different operating systems [http://en.wikipedia.org/wiki/Mobile_operating_system] on different mobile systems. There is increased interaction between mobile systems, especially for cell phones. The Service Oriented Architecture design pattern is especially well suited for this situation. This is a fairly new field, and methods are currently being developed to aid developers.

== Ways to Adapt Using Design Patterns ==

Several principles and patterns have been understood and developed in developing for mobile applications. Many of these methods are still undergoing change and experimentation. There are new methods being developed and others left behind. A design pattern can be defined as a repeatable solution to a common problem in software. It is a template for how to solve the problem, not actual code [7].

Ease of navigation is a particularly important principle, because of the reduced number of user inputs (for example, buttons from 0 to 9 instead of a mouse and keyboard). Everything in an application should be no more than three clicks away. If a program is too "deep", requiring many clicks, this will be a problem because it takes longer to navigate on a mobile device. If the application is to "broad" as in too many links on one page, the data may not all fit on the screen. One way to mitigate this problem is to reduce functionality, to keep the application as simple as possible [5].

Service Oriented Architectures are well suited for the mobile environment [3]. Within this architecture, applications can make use of various services by sending messages to them via a protocol. Applications may interact with services on operating systems and written in different languages, as long as the protocol is followed. Services may be located on different mobile devices. This protocol is a good fit, allowing applications to reach out to services on other mobile devices, even though they may be on very different devices.

*'''''Service Oriented Architecture Example''''' [3]

[[Image:SOA_Example.jpg]]

The Energy Conscious (EC) Factory model [7]!!!!

The [http://www.javaworld.com/javaworld/jw-10-2005/jw-1003-mvc.html Model View Controller] pattern [1] fits the mobile environment well. Models may be set up so that optimum data structures are used, as was discussed for the EC Factory pattern [7]. Effecient designs may be built into the controllers. Views may be standardized for the application to handle the small screens.

The meeting pattern is especially useful in mobile environments. One device or application serves as the meeting manager. The meeting manager coordinates and tracks the other agents (programs or applications). These agents communicate with the oversight of the meeting manager. Agents may be located on different devices, even on computers with more resources. This is especially well suited for the mobile environment because it is a good way to manage the communications and relatively small applications. A further benefit of the meeting pattern is that mobile applications may be combined (somewhat in the fashion of parallel computing) to do more and provide more resources [6].

*'''''Meeting pattern Example''''' [6]

[[Image:MCFigure3.jpg]]

The master slave pattern is simmilar to the meeting pattern. Instead of a meeting manager and agents, there is a master that creates, uses, and destroys slave objects. The master assigns the slaves tasks to complete. Like agents in the meeting pattern, slaves may be located on different mobile devices, or even on computers that have more resources. The master / slave pattern is very useful for performing actions in parallel on different mobile devices [6].

== Conclusion ==
In conclusion, certain design patterns are especially useful in the mobile design environment. These patterns help developers to produce applications quickly and applications which make efficient use of the limited resources in the mobile environment. Most design patterns can be of benefit to mobile applications, but certain patterns have features that are especially well suited. The EC factory pattern was designed for the mobile environment to reduce energy use [7]. A few other patterns show much promise with mobile devices, including the meeting pattern, master / slave pattern, and service oriented architectures.

== References ==

1. http://www.javaworld.com/javaworld/jw-10-2005/jw-1003-mvc.html - Model View Controller Architecture

2. http://patterns.littlespringsdesign.com/index.php/The_mobile_challenge - Challenges of the Mobile Environment

3. http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki2_17_va - Service Oriented Architecture

4. http://wiki.forum.nokia.com/index.php/Understading_Desing_Patterns - Understanding Design Patterns

5. http://dev.opera.com/articles/view/designing-and-developing-mobile-web-site/ - Designing and Developing mobile web sites in the real world

6. Emerson F.A Lima, Patrícia D. L. Machado, Fláavio R. Sampaio, and Jorge C. A. Figueiredo. ACM SIGSOFT Software Engineering Notes. Volume 29, issue 3 ISSN: 0163-5948 http://portal.acm.org/citation.cfm?id=986710.986726 Universidade Federal de Campina Grande, Paraíba, Brazil, May, 2004.

7. Kayun Chantarasathaporn, Chonawat Srisa-an. ACM International Conference Proceeding Series; Vol. 270 Proceedings of the 3rd international conference on Mobile technology, applications & systems SESSION: Mobile applications, article 29. ISBN:1-59593-519-3 http://portal.acm.org/citation.cfm?id=1292331.1292364 Bangkok, Thailand, 2006

8. WIM Workshop,Uppsala, 17.9.2004

9. Mobile Application Development, Sam Nasr , www.CleavelandDotNet.info

10. Energy Conscious Factory Method Design Pattern for Mobile Devices with C# and Intermediate Language, by Kayun Chantarasathaporn and Chonawat Srisa-an, Ph.D. at Faculty of Information Technology, Rangsit University, Thailand.

11. http://www.codeproject.com/csharp/structs_in_csharp.asp
== Working Notes ==

Two major design patterns that have come up to help in mobile softwares and to address the above discussed issues in a mobile device are : Energy Conscious design pattern and Mobile agent design pattern

=== Energy Conscious Factory Design ===

Power consumption has not been much of a concern to developers in the past, but this is important in the mobile environment. Battery power on cell phones is limited. [7]
- Use registers instead of memory whenever possible (registers use less energy)
- Use structs instead of classes
- Use static instead of dynamic

Some strategies and their experimental results are discussed in [10]: 
[[Image:ECFactory_Fig8.jpg| General Strategies]]

'''''Factory Method pattern''''' is a pattern that returns an object from one of various possible classes. Which class is chosen to be an object generator is depended on data provided to it.
Factory Method Pattern is a good pattern to build upon for energy conscious pattern.
Lets look at both versions.
Class Diagram of sample Factory Method pattern::
[[Image:ECFactory_Fig1.jpg|Class Diagram of sample Factory Method pattern ]]

Sequence Diagram (with Activations) of sample Factory Method pattern ::
[[Image:ECFactory_Fig2.jpg|Sequence Diagram (with Activations) of sample Factory Method pattern ]]

'''''Modified Factory Method pattern'''''
As regular Factory Method pattern was not designed for being energy concerned, so, it is slightly modified. Some of the critical tweaks are:
*Factory Method Pattern that mixes usage of struct and class in several manners.
*Factory Method Pattern that uses static factory method in Factory struct
*Factory Method Pattern that applies generics principle which is parametered type
*Factory Method Pattern That Uses ConcreteProduct Class, ConcreteCreator Struct with Non-Static FactoryMethod()

Modified Factory Method pattern applies both struct and class recommendations.

''Factory Method Pattern That Uses ConcreteProduct Class, ConcreteCreator Struct with Non-Static FactoryMethod()''
[[Image:ECFactory_Fig3.jpg|Class Diagram of Factory Method pattern]]

In this case, we use VehicleChooser which is a ConcreteCreator as struct while Car, Plane and Ship which are ConcreteProduct as class. Method ChooseVehicle(...) which is as FactoryMethod() is non-static.

''Factory Method Pattern That Uses ConcreteProduct Struct, ConcreteCreator Struct with Static FactoryMethod()''
[[Image:ECFactory_Fig4.jpg|Class Diagram of Factory Method pattern]]
If we use static method appropriately, CPU workload will be reduced. This affects directly in lessening power consumption as a whole.

'''''Experimental Result:'''''
For various combination shown in figure, the tests were run, and the result obtained are shown in the graph below.
Characteristic of components in each combination
[[Image:ECFactory_Fig5.jpg|Characteristic of components in each combination ]]
CPU Usage Comparison
[[Image:ECFactory_Fig6.jpg|CPU Usage Comparison ]]
Energy Usage Comparison
[[Image:ECFactory_Fig7.jpg]|Energy Usage Comparison]

It is observed that Energy Concerned Factory Method Pattern can be obtained from the combination of ConcreteProduct classes and ConcreteCreator struct with static FactoryMethod(). The ECFactory Method Pattern consumes less CPU time than regular Factory Method Pattern around 11% while it is better than the worst case around 80%. The bigger the ConcreteProduct type size is, the more range between the best and the worst case in term of energy consumption will be.
So it is clearly proven how this pattern can save energy.

CSC/ECE 517 Fall 2009/wiki3 21 MobileDesignPattern

2009-11-19T14:40:31Z

Wolverine: /* Energy Conscious Factory Design */

== Design Pattern for Mobile Applications ==

The popularity of mobile applications is rising. Design patterns are useful in almost any coding tasks. While almost any design pattern could be used within mobile applications, certain patterns are well suited for the unique environment of mobile applications. This wiki explains the mobile application environment, then focuses on design patterns that work well within this new emerging environment.

__TOC__

== The Mobile Application Environment ==

The mobile application environment is new and presents many unique opportunities and challenges for developers. It seems almost everyone now has a cellphone, blackberry, or other small portable device. These devices are "getting smarter" in that many people are developing new applications for them. Cell phones no longer are just used to call people, they often have features like text messaging, cameras, video games, web browsers and more. There is much opportunity for developers to write new applications for mobile devices.

While opportunity abounds, there are also quite a few challenges. Mobile applications have less resources than are typically found in other development environments. The screen on mobile devices is typically smaller, there is usually not a keyboard and mouse (user inputs are reduced) [5]. CPU resources are generally less than those found in the typical environment [7]. Power usage is also limited because a battery is typically used, so reducing power use by the application is an important goal [7]. Connections are typically expensive and are often prone to loss of signals [6].

Another problem is that there is a high demand for applications to be developed quickly [7]. The mobile environment is changing rapidly [2]. Some of the lower level programming languages were useful because they produced fast applications, but they took too long to develop with[22 http://www.umsl.edu/~subramaniana/concepts1.html]. Now, with the increased demand for applications quickly, Object Oriented Programming (OOP) is used more. While this causes a greater usage of resources, this is outweighed by the much quicker development cycle and the re-use of code. In particular, good solutions may be re-used in OOP [7].

In the mobile environment, applications are often written on different operating systems [http://en.wikipedia.org/wiki/Mobile_operating_system] on different mobile systems. There is increased interaction between mobile systems, especially for cell phones. The Service Oriented Architecture design pattern is especially well suited for this situation. This is a fairly new field, and methods are currently being developed to aid developers.

== Ways to Adapt Using Design Patterns ==

Several principles and patterns have been understood and developed in developing for mobile applications. Many of these methods are still undergoing change and experimentation. There are new methods being developed and others left behind. A design pattern can be defined as a repeatable solution to a common problem in software. It is a template for how to solve the problem, not actual code [7].

Ease of navigation is a particularly important principle, because of the reduced number of user inputs (for example, buttons from 0 to 9 instead of a mouse and keyboard). Everything in an application should be no more than three clicks away. If a program is too "deep", requiring many clicks, this will be a problem because it takes longer to navigate on a mobile device. If the application is to "broad" as in too many links on one page, the data may not all fit on the screen. One way to mitigate this problem is to reduce functionality, to keep the application as simple as possible [5].

Service Oriented Architectures are well suited for the mobile environment [3]. Within this architecture, applications can make use of various services by sending messages to them via a protocol. Applications may interact with services on operating systems and written in different languages, as long as the protocol is followed. Services may be located on different mobile devices. This protocol is a good fit, allowing applications to reach out to services on other mobile devices, even though they may be on very different devices.

*'''''Service Oriented Architecture Example''''' [3]

[[Image:SOA_Example.jpg]]

The Energy Conscious (EC) Factory model [7]!!!!

The [http://www.javaworld.com/javaworld/jw-10-2005/jw-1003-mvc.html Model View Controller] pattern [1] fits the mobile environment well. Models may be set up so that optimum data structures are used, as was discussed for the EC Factory pattern [7]. Effecient designs may be built into the controllers. Views may be standardized for the application to handle the small screens.

The meeting pattern is especially useful in mobile environments. One device or application serves as the meeting manager. The meeting manager coordinates and tracks the other agents (programs or applications). These agents communicate with the oversight of the meeting manager. Agents may be located on different devices, even on computers with more resources. This is especially well suited for the mobile environment because it is a good way to manage the communications and relatively small applications. A further benefit of the meeting pattern is that mobile applications may be combined (somewhat in the fashion of parallel computing) to do more and provide more resources [6].

*'''''Meeting pattern Example''''' [6]

[[Image:MCFigure3.jpg]]

The master slave pattern is simmilar to the meeting pattern. Instead of a meeting manager and agents, there is a master that creates, uses, and destroys slave objects. The master assigns the slaves tasks to complete. Like agents in the meeting pattern, slaves may be located on different mobile devices, or even on computers that have more resources. The master / slave pattern is very useful for performing actions in parallel on different mobile devices [6].

== Conclusion ==
In conclusion, certain design patterns are especially useful in the mobile design environment. These patterns help developers to produce applications quickly and applications which make efficient use of the limited resources in the mobile environment. Most design patterns can be of benefit to mobile applications, but certain patterns have features that are especially well suited. The EC factory pattern was designed for the mobile environment to reduce energy use [7]. A few other patterns show much promise with mobile devices, including the meeting pattern, master / slave pattern, and service oriented architectures.

== References ==

1. http://www.javaworld.com/javaworld/jw-10-2005/jw-1003-mvc.html - Model View Controller Architecture

2. http://patterns.littlespringsdesign.com/index.php/The_mobile_challenge - Challenges of the Mobile Environment

3. http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki2_17_va - Service Oriented Architecture

4. http://wiki.forum.nokia.com/index.php/Understading_Desing_Patterns - Understanding Design Patterns

5. http://dev.opera.com/articles/view/designing-and-developing-mobile-web-site/ - Designing and Developing mobile web sites in the real world

6. Emerson F.A Lima, Patrícia D. L. Machado, Fláavio R. Sampaio, and Jorge C. A. Figueiredo. ACM SIGSOFT Software Engineering Notes. Volume 29, issue 3 ISSN: 0163-5948 http://portal.acm.org/citation.cfm?id=986710.986726 Universidade Federal de Campina Grande, Paraíba, Brazil, May, 2004.

7. Kayun Chantarasathaporn, Chonawat Srisa-an. ACM International Conference Proceeding Series; Vol. 270 Proceedings of the 3rd international conference on Mobile technology, applications & systems SESSION: Mobile applications, article 29. ISBN:1-59593-519-3 http://portal.acm.org/citation.cfm?id=1292331.1292364 Bangkok, Thailand, 2006

8. WIM Workshop,Uppsala, 17.9.2004

9. Mobile Application Development, Sam Nasr , www.CleavelandDotNet.info

10. Energy Conscious Factory Method Design Pattern for Mobile Devices with C# and Intermediate Language, by Kayun Chantarasathaporn and Chonawat Srisa-an, Ph.D. at Faculty of Information Technology, Rangsit University, Thailand.

11. http://www.codeproject.com/csharp/structs_in_csharp.asp
== Working Notes ==

Two major design patterns that have come up to help in mobile softwares and to address the above discussed issues in a mobile device are : Energy Conscious design pattern and Mobile agent design pattern

=== Energy Conscious Factory Design ===

Power consumption has not been much of a concern to developers in the past, but this is important in the mobile environment. Battery power on cell phones is limited. [7]
- Use registers instead of memory whenever possible (registers use less energy)
- Use structs instead of classes
- Use static instead of dynamic

Some strategies and their experimental results are discussed in [10]: 
[[Image:ECFactory_Fig8.jpg| General Strategies]]

'''''Factory Method pattern''''' is a pattern that returns an object from one of various possible classes. Which class is chosen to be an object generator is depended on data provided to it.
Factory Method Pattern is a good pattern to build upon for energy conscious pattern.
Lets look at both versions.

[[Image:ECFactory_Fig1.jpg|Class Diagram of sample Factory Method pattern ]]

[[Image:ECFactory_Fig2.jpg|Sequence Diagram (with Activations) of sample Factory Method pattern ]]

'''''Modified Factory Method pattern'''''
As regular Factory Method pattern was not designed for being energy concerned, so, it is slightly modified. Some of the critical tweaks are:
*Factory Method Pattern that mixes usage of struct and class in several manners.
*Factory Method Pattern that uses static factory method in Factory struct
*Factory Method Pattern that applies generics principle which is parametered type
*Factory Method Pattern That Uses ConcreteProduct Class, ConcreteCreator Struct with Non-Static FactoryMethod()

Modified Factory Method pattern applies both struct and class recommendations.

''Factory Method Pattern That Uses ConcreteProduct Class, ConcreteCreator Struct with Non-Static FactoryMethod()''
[[Image:ECFactory_Fig3.jpg|Class Diagram of Factory Method pattern]]

In this case, we use VehicleChooser which is a ConcreteCreator as struct while Car, Plane and Ship which are ConcreteProduct as class. Method ChooseVehicle(...) which is as FactoryMethod() is non-static.

''Factory Method Pattern That Uses ConcreteProduct Struct, ConcreteCreator Struct with Static FactoryMethod()''
[[Image:ECFactory_Fig4.jpg|Class Diagram of Factory Method pattern]]
If we use static method appropriately, CPU workload will be reduced. This affects directly in lessening power consumption as a whole.

'''''Experimental Result:'''''
For various combination shown in figure, the tests were run, and the result obtained are shown in the graph below.

[[Image:ECFactory_Fig5.jpg|Characteristic of components in each combination ]]

[[Image:ECFactory_Fig6.jpg|CPU Usage Comparison ]]

[[Image:ECFactory_Fig7.jpg]|Energy Usage Comparison]

It is observed that Energy Concerned Factory Method Pattern can be obtained from the combination of ConcreteProduct classes and ConcreteCreator struct with static FactoryMethod(). The ECFactory Method Pattern consumes less CPU time than regular Factory Method Pattern around 11% while it is better than the worst case around 80%. The bigger the ConcreteProduct type size is, the more range between the best and the worst case in term of energy consumption will be.
So it is clearly proven how this pattern can save energy.

CSC/ECE 517 Fall 2009/wiki3 21 MobileDesignPattern

2009-11-19T14:39:31Z

Wolverine: /* Energy Conscious Factory Design */

== Design Pattern for Mobile Applications ==

The popularity of mobile applications is rising. Design patterns are useful in almost any coding tasks. While almost any design pattern could be used within mobile applications, certain patterns are well suited for the unique environment of mobile applications. This wiki explains the mobile application environment, then focuses on design patterns that work well within this new emerging environment.

__TOC__

== The Mobile Application Environment ==

The mobile application environment is new and presents many unique opportunities and challenges for developers. It seems almost everyone now has a cellphone, blackberry, or other small portable device. These devices are "getting smarter" in that many people are developing new applications for them. Cell phones no longer are just used to call people, they often have features like text messaging, cameras, video games, web browsers and more. There is much opportunity for developers to write new applications for mobile devices.

While opportunity abounds, there are also quite a few challenges. Mobile applications have less resources than are typically found in other development environments. The screen on mobile devices is typically smaller, there is usually not a keyboard and mouse (user inputs are reduced) [5]. CPU resources are generally less than those found in the typical environment [7]. Power usage is also limited because a battery is typically used, so reducing power use by the application is an important goal [7]. Connections are typically expensive and are often prone to loss of signals [6].

Another problem is that there is a high demand for applications to be developed quickly [7]. The mobile environment is changing rapidly [2]. Some of the lower level programming languages were useful because they produced fast applications, but they took too long to develop with[22 http://www.umsl.edu/~subramaniana/concepts1.html]. Now, with the increased demand for applications quickly, Object Oriented Programming (OOP) is used more. While this causes a greater usage of resources, this is outweighed by the much quicker development cycle and the re-use of code. In particular, good solutions may be re-used in OOP [7].

In the mobile environment, applications are often written on different operating systems [http://en.wikipedia.org/wiki/Mobile_operating_system] on different mobile systems. There is increased interaction between mobile systems, especially for cell phones. The Service Oriented Architecture design pattern is especially well suited for this situation. This is a fairly new field, and methods are currently being developed to aid developers.

== Ways to Adapt Using Design Patterns ==

Several principles and patterns have been understood and developed in developing for mobile applications. Many of these methods are still undergoing change and experimentation. There are new methods being developed and others left behind. A design pattern can be defined as a repeatable solution to a common problem in software. It is a template for how to solve the problem, not actual code [7].

Ease of navigation is a particularly important principle, because of the reduced number of user inputs (for example, buttons from 0 to 9 instead of a mouse and keyboard). Everything in an application should be no more than three clicks away. If a program is too "deep", requiring many clicks, this will be a problem because it takes longer to navigate on a mobile device. If the application is to "broad" as in too many links on one page, the data may not all fit on the screen. One way to mitigate this problem is to reduce functionality, to keep the application as simple as possible [5].

Service Oriented Architectures are well suited for the mobile environment [3]. Within this architecture, applications can make use of various services by sending messages to them via a protocol. Applications may interact with services on operating systems and written in different languages, as long as the protocol is followed. Services may be located on different mobile devices. This protocol is a good fit, allowing applications to reach out to services on other mobile devices, even though they may be on very different devices.

*'''''Service Oriented Architecture Example''''' [3]

[[Image:SOA_Example.jpg]]

The Energy Conscious (EC) Factory model [7]!!!!

The [http://www.javaworld.com/javaworld/jw-10-2005/jw-1003-mvc.html Model View Controller] pattern [1] fits the mobile environment well. Models may be set up so that optimum data structures are used, as was discussed for the EC Factory pattern [7]. Effecient designs may be built into the controllers. Views may be standardized for the application to handle the small screens.

The meeting pattern is especially useful in mobile environments. One device or application serves as the meeting manager. The meeting manager coordinates and tracks the other agents (programs or applications). These agents communicate with the oversight of the meeting manager. Agents may be located on different devices, even on computers with more resources. This is especially well suited for the mobile environment because it is a good way to manage the communications and relatively small applications. A further benefit of the meeting pattern is that mobile applications may be combined (somewhat in the fashion of parallel computing) to do more and provide more resources [6].

*'''''Meeting pattern Example''''' [6]

[[Image:MCFigure3.jpg]]

The master slave pattern is simmilar to the meeting pattern. Instead of a meeting manager and agents, there is a master that creates, uses, and destroys slave objects. The master assigns the slaves tasks to complete. Like agents in the meeting pattern, slaves may be located on different mobile devices, or even on computers that have more resources. The master / slave pattern is very useful for performing actions in parallel on different mobile devices [6].

== Conclusion ==
In conclusion, certain design patterns are especially useful in the mobile design environment. These patterns help developers to produce applications quickly and applications which make efficient use of the limited resources in the mobile environment. Most design patterns can be of benefit to mobile applications, but certain patterns have features that are especially well suited. The EC factory pattern was designed for the mobile environment to reduce energy use [7]. A few other patterns show much promise with mobile devices, including the meeting pattern, master / slave pattern, and service oriented architectures.

== References ==

1. http://www.javaworld.com/javaworld/jw-10-2005/jw-1003-mvc.html - Model View Controller Architecture

2. http://patterns.littlespringsdesign.com/index.php/The_mobile_challenge - Challenges of the Mobile Environment

3. http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki2_17_va - Service Oriented Architecture

4. http://wiki.forum.nokia.com/index.php/Understading_Desing_Patterns - Understanding Design Patterns

5. http://dev.opera.com/articles/view/designing-and-developing-mobile-web-site/ - Designing and Developing mobile web sites in the real world

6. Emerson F.A Lima, Patrícia D. L. Machado, Fláavio R. Sampaio, and Jorge C. A. Figueiredo. ACM SIGSOFT Software Engineering Notes. Volume 29, issue 3 ISSN: 0163-5948 http://portal.acm.org/citation.cfm?id=986710.986726 Universidade Federal de Campina Grande, Paraíba, Brazil, May, 2004.

7. Kayun Chantarasathaporn, Chonawat Srisa-an. ACM International Conference Proceeding Series; Vol. 270 Proceedings of the 3rd international conference on Mobile technology, applications & systems SESSION: Mobile applications, article 29. ISBN:1-59593-519-3 http://portal.acm.org/citation.cfm?id=1292331.1292364 Bangkok, Thailand, 2006

8. WIM Workshop,Uppsala, 17.9.2004

9. Mobile Application Development, Sam Nasr , www.CleavelandDotNet.info

10. Energy Conscious Factory Method Design Pattern for Mobile Devices with C# and Intermediate Language, by Kayun Chantarasathaporn and Chonawat Srisa-an, Ph.D. at Faculty of Information Technology, Rangsit University, Thailand.

11. http://www.codeproject.com/csharp/structs_in_csharp.asp
== Working Notes ==

Two major design patterns that have come up to help in mobile softwares and to address the above discussed issues in a mobile device are : Energy Conscious design pattern and Mobile agent design pattern

=== Energy Conscious Factory Design ===

Power consumption has not been much of a concern to developers in the past, but this is important in the mobile environment. Battery power on cell phones is limited. [7]
- Use registers instead of memory whenever possible (registers use less energy)
- Use structs instead of classes
- Use static instead of dynamic

Some strategies and their experimental results are discussed in [10]: 
[[Image:ECFactory_Fig8.jpg| General Strategies]]

'''''Factory Method pattern''''' is a pattern that returns an object from one of various possible classes. Which class is chosen to be an object generator is depended on data provided to it.
Factory Method Pattern is a good pattern to build upon for energy conscious pattern.
Lets look at both versions.

[[Image:ECFactory_Fig1.jpg]|Class Diagram of sample Factory Method pattern ]

[[Image:ECFactory_Fig2.jpg]|Sequence Diagram (with Activations) of sample Factory Method pattern ]

'''''Modified Factory Method pattern'''''
As regular Factory Method pattern was not designed for being energy concerned, so, it is slightly modified. Some of the critical tweaks are:
*Factory Method Pattern that mixes usage of struct and class in several manners.
*Factory Method Pattern that uses static factory method in Factory struct
*Factory Method Pattern that applies generics principle which is parametered type
*Factory Method Pattern That Uses ConcreteProduct Class, ConcreteCreator Struct with Non-Static FactoryMethod()

Modified Factory Method pattern applies both struct and class recommendations.

''Factory Method Pattern That Uses ConcreteProduct Class, ConcreteCreator Struct with Non-Static FactoryMethod()''
[[Image:ECFactory_Fig3.jpg]|Class Diagram of Factory Method pattern]

In this case, we use VehicleChooser which is a ConcreteCreator as struct while Car, Plane and Ship which are ConcreteProduct as class. Method ChooseVehicle(...) which is as FactoryMethod() is non-static.

''Factory Method Pattern That Uses ConcreteProduct Struct, ConcreteCreator Struct with Static FactoryMethod()''
[[Image:ECFactory_Fig4.jpg]|Class Diagram of Factory Method pattern]
If we use static method appropriately, CPU workload will be reduced. This affects directly in lessening power consumption as a whole.

'''''Experimental Result:'''''
For various combination shown in figure, the tests were run, and the result obtained are shown in the graph below.

[[Image:ECFactory_Fig5.jpg]|Characteristic of components in each combination ]

[[Image:ECFactory_Fig6.jpg]|CPU Usage Comparison ]

[[Image:ECFactory_Fig7.jpg]|Energy Usage Comparison]

It is observed that Energy Concerned Factory Method Pattern can be obtained from the combination of ConcreteProduct classes and ConcreteCreator struct with static FactoryMethod(). The ECFactory Method Pattern consumes less CPU time than regular Factory Method Pattern around 11% while it is better than the worst case around 80%. The bigger the ConcreteProduct type size is, the more range between the best and the worst case in term of energy consumption will be.
So it is clearly proven how this pattern can save energy.

File:ECFactory Fig8.jpg

2009-11-19T14:21:40Z

Wolverine:

CSC/ECE 517 Fall 2009/wiki3 21 MobileDesignPattern

2009-11-19T14:21:19Z

Wolverine: /* Working Notes */

== Design Pattern for Mobile Applications ==

The popularity of mobile applications is rising. Design patterns are useful in almost any coding tasks. While almost any design pattern could be used within mobile applications, certain patterns are well suited for the unique environment of mobile applications. This wiki explains the mobile application environment, then focuses on design patterns that work well within this new emerging environment.

__TOC__

== The Mobile Application Environment ==

The mobile application environment is new and presents many unique opportunities and challenges for developers. It seems almost everyone now has a cellphone, blackberry, or other small portable device. These devices are "getting smarter" in that many people are developing new applications for them. Cell phones no longer are just used to call people, they often have features like text messaging, cameras, video games, web browsers and more. There is much opportunity for developers to write new applications for mobile devices.

While opportunity abounds, there are also quite a few challenges. Mobile applications have less resources than are typically found in other development environments. The screen on mobile devices is typically smaller, there is usually not a keyboard and mouse (user inputs are reduced) [5]. CPU resources are generally less than those found in the typical environment [7]. Power usage is also limited because a battery is typically used, so reducing power use by the application is an important goal [7]. Connections are typically expensive and are often prone to loss of signals [6].

Another problem is that there is a high demand for applications to be developed quickly [7]. The mobile environment is changing rapidly [2]. Some of the lower level programming languages were useful because they produced fast applications, but they took too long to develop with[22 http://www.umsl.edu/~subramaniana/concepts1.html]. Now, with the increased demand for applications quickly, Object Oriented Programming (OOP) is used more. While this causes a greater usage of resources, this is outweighed by the much quicker development cycle and the re-use of code. In particular, good solutions may be re-used in OOP [7].

In the mobile environment, applications are often written on different operating systems [http://en.wikipedia.org/wiki/Mobile_operating_system] on different mobile systems. There is increased interaction between mobile systems, especially for cell phones. The Service Oriented Architecture design pattern is especially well suited for this situation. This is a fairly new field, and methods are currently being developed to aid developers.

== Ways to Adapt Using Design Patterns ==

Several principles and patterns have been understood and developed in developing for mobile applications. Many of these methods are still undergoing change and experimentation. There are new methods being developed and others left behind. A design pattern can be defined as a repeatable solution to a common problem in software. It is a template for how to solve the problem, not actual code [7].

Ease of navigation is a particularly important principle, because of the reduced number of user inputs (for example, buttons from 0 to 9 instead of a mouse and keyboard). Everything in an application should be no more than three clicks away. If a program is too "deep", requiring many clicks, this will be a problem because it takes longer to navigate on a mobile device. If the application is to "broad" as in too many links on one page, the data may not all fit on the screen. One way to mitigate this problem is to reduce functionality, to keep the application as simple as possible [5].

Service Oriented Architectures are well suited for the mobile environment [3]. Within this architecture, applications can make use of various services by sending messages to them via a protocol. Applications may interact with services on operating systems and written in different languages, as long as the protocol is followed. Services may be located on different mobile devices. This protocol is a good fit, allowing applications to reach out to services on other mobile devices, even though they may be on very different devices.

*'''''Service Oriented Architecture Example''''' [3]

[[Image:SOA_Example.jpg]]

The Energy Conscious (EC) Factory model [7]!!!!

The [http://www.javaworld.com/javaworld/jw-10-2005/jw-1003-mvc.html Model View Controller] pattern [1] fits the mobile environment well. Models may be set up so that optimum data structures are used, as was discussed for the EC Factory pattern [7]. Effecient designs may be built into the controllers. Views may be standardized for the application to handle the small screens.

The meeting pattern is especially useful in mobile environments. One device or application serves as the meeting manager. The meeting manager coordinates and tracks the other agents (programs or applications). These agents communicate with the oversight of the meeting manager. Agents may be located on different devices, even on computers with more resources. This is especially well suited for the mobile environment because it is a good way to manage the communications and relatively small applications. A further benefit of the meeting pattern is that mobile applications may be combined (somewhat in the fashion of parallel computing) to do more and provide more resources [6].

*'''''Meeting pattern Example''''' [6]

[[Image:MCFigure3.jpg]]

The master slave pattern is simmilar to the meeting pattern. Instead of a meeting manager and agents, there is a master that creates, uses, and destroys slave objects. The master assigns the slaves tasks to complete. Like agents in the meeting pattern, slaves may be located on different mobile devices, or even on computers that have more resources. The master / slave pattern is very useful for performing actions in parallel on different mobile devices [6].

== Conclusion ==
In conclusion, certain design patterns are especially useful in the mobile design environment. These patterns help developers to produce applications quickly and applications which make efficient use of the limited resources in the mobile environment. Most design patterns can be of benefit to mobile applications, but certain patterns have features that are especially well suited. The EC factory pattern was designed for the mobile environment to reduce energy use [7]. A few other patterns show much promise with mobile devices, including the meeting pattern, master / slave pattern, and service oriented architectures.

== References ==

1. http://www.javaworld.com/javaworld/jw-10-2005/jw-1003-mvc.html - Model View Controller Architecture

2. http://patterns.littlespringsdesign.com/index.php/The_mobile_challenge - Challenges of the Mobile Environment

3. http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki2_17_va - Service Oriented Architecture

4. http://wiki.forum.nokia.com/index.php/Understading_Desing_Patterns - Understanding Design Patterns

5. http://dev.opera.com/articles/view/designing-and-developing-mobile-web-site/ - Designing and Developing mobile web sites in the real world

6. Emerson F.A Lima, Patrícia D. L. Machado, Fláavio R. Sampaio, and Jorge C. A. Figueiredo. ACM SIGSOFT Software Engineering Notes. Volume 29, issue 3 ISSN: 0163-5948 http://portal.acm.org/citation.cfm?id=986710.986726 Universidade Federal de Campina Grande, Paraíba, Brazil, May, 2004.

7. Kayun Chantarasathaporn, Chonawat Srisa-an. ACM International Conference Proceeding Series; Vol. 270 Proceedings of the 3rd international conference on Mobile technology, applications & systems SESSION: Mobile applications, article 29. ISBN:1-59593-519-3 http://portal.acm.org/citation.cfm?id=1292331.1292364 Bangkok, Thailand, 2006

8. WIM Workshop,Uppsala, 17.9.2004

9. Mobile Application Development, Sam Nasr , www.CleavelandDotNet.info

10. Energy Conscious Factory Method Design Pattern for Mobile Devices with C# and Intermediate Language, by Kayun Chantarasathaporn and Chonawat Srisa-an, Ph.D. at Faculty of Information Technology, Rangsit University, Thailand.

11. http://www.codeproject.com/csharp/structs_in_csharp.asp
== Working Notes ==

Two major design patterns that have come up to help in mobile softwares and to address the above discussed issues in a mobile device are : Energy Conscious design pattern and Mobile agent design pattern

=== Energy Conscious Factory Design ===

Power consumption has not been much of a concern to developers in the past, but this is important in the mobile environment. Battery power on cell phones is limited. [7]
- Use registers instead of memory whenever possible (registers use less energy)
- Use structs instead of classes
- Use static instead of dynamic

Some strategies and their experimental results are discussed in [10]:
[[Image:ECFactory_Fig8.jpg| General Strategies]]

'''''Factory Method pattern''''' is a pattern that returns an object from one of various possible classes. Which class is chosen to be an object generator is depended on data provided to it.
Factory Method Pattern is a good pattern to build upon for energy conscious pattern.
Lets look at both versions.

[[Image:ECFactory_Fig1.jpg]|Class Diagram of sample Factory Method pattern ]

[[Image:ECFactory_Fig2.jpg]|Sequence Diagram (with Activations) of sample Factory Method pattern ]

'''''Modified Factory Method pattern'''''
As regular Factory Method pattern was not designed for being energy concerned, so, it is slightly modified. Some of the critical tweaks are:
*Factory Method Pattern that mixes usage of struct and class in several manners.
*Factory Method Pattern that uses static factory method in Factory struct
*Factory Method Pattern that applies generics principle which is parametered type
*Factory Method Pattern That Uses ConcreteProduct Class, ConcreteCreator Struct with Non-Static FactoryMethod()

Modified Factory Method pattern applies both struct and class recommendations.

''Factory Method Pattern That Uses ConcreteProduct Class, ConcreteCreator Struct with Non-Static FactoryMethod()''
[[Image:ECFactory_Fig3.jpg]|Class Diagram of Factory Method pattern]

In this case, we use VehicleChooser which is a ConcreteCreator as struct while Car, Plane and Ship which are ConcreteProduct as class. Method ChooseVehicle(...) which is as FactoryMethod() is non-static.

''Factory Method Pattern That Uses ConcreteProduct Struct, ConcreteCreator Struct with Static FactoryMethod()''
[[Image:ECFactory_Fig4.jpg]|Class Diagram of Factory Method pattern]
If we use static method appropriately, CPU workload will be reduced. This affects directly in lessening power consumption as a whole.

'''''Experimental Result:'''''
For various combination shown in figure, the tests were run, and the result obtained are shown in the graph below.

[[Image:ECFactory_Fig5.jpg]|Characteristic of components in each combination ]

[[Image:ECFactory_Fig6.jpg]|CPU Usage Comparison ]

[[Image:ECFactory_Fig7.jpg]|Energy Usage Comparison]

It is observed that Energy Concerned Factory Method Pattern can be obtained from the combination of ConcreteProduct classes and ConcreteCreator struct with static FactoryMethod(). The ECFactory Method Pattern consumes less CPU time than regular Factory Method Pattern around 11% while it is better than the worst case around 80%. The bigger the ConcreteProduct type size is, the more range between the best and the worst case in term of energy consumption will be.
So it is clearly proven how this pattern can save energy.

CSC/ECE 517 Fall 2009/wiki3 21 MobileDesignPattern

2009-11-19T14:19:45Z

Wolverine:

== Design Pattern for Mobile Applications ==

The popularity of mobile applications is rising. Design patterns are useful in almost any coding tasks. While almost any design pattern could be used within mobile applications, certain patterns are well suited for the unique environment of mobile applications. This wiki explains the mobile application environment, then focuses on design patterns that work well within this new emerging environment.

__TOC__

== The Mobile Application Environment ==

The mobile application environment is new and presents many unique opportunities and challenges for developers. It seems almost everyone now has a cellphone, blackberry, or other small portable device. These devices are "getting smarter" in that many people are developing new applications for them. Cell phones no longer are just used to call people, they often have features like text messaging, cameras, video games, web browsers and more. There is much opportunity for developers to write new applications for mobile devices.

While opportunity abounds, there are also quite a few challenges. Mobile applications have less resources than are typically found in other development environments. The screen on mobile devices is typically smaller, there is usually not a keyboard and mouse (user inputs are reduced) [5]. CPU resources are generally less than those found in the typical environment [7]. Power usage is also limited because a battery is typically used, so reducing power use by the application is an important goal [7]. Connections are typically expensive and are often prone to loss of signals [6].

Another problem is that there is a high demand for applications to be developed quickly [7]. The mobile environment is changing rapidly [2]. Some of the lower level programming languages were useful because they produced fast applications, but they took too long to develop with[22 http://www.umsl.edu/~subramaniana/concepts1.html]. Now, with the increased demand for applications quickly, Object Oriented Programming (OOP) is used more. While this causes a greater usage of resources, this is outweighed by the much quicker development cycle and the re-use of code. In particular, good solutions may be re-used in OOP [7].

In the mobile environment, applications are often written on different operating systems [http://en.wikipedia.org/wiki/Mobile_operating_system] on different mobile systems. There is increased interaction between mobile systems, especially for cell phones. The Service Oriented Architecture design pattern is especially well suited for this situation. This is a fairly new field, and methods are currently being developed to aid developers.

== Ways to Adapt Using Design Patterns ==

Several principles and patterns have been understood and developed in developing for mobile applications. Many of these methods are still undergoing change and experimentation. There are new methods being developed and others left behind. A design pattern can be defined as a repeatable solution to a common problem in software. It is a template for how to solve the problem, not actual code [7].

Ease of navigation is a particularly important principle, because of the reduced number of user inputs (for example, buttons from 0 to 9 instead of a mouse and keyboard). Everything in an application should be no more than three clicks away. If a program is too "deep", requiring many clicks, this will be a problem because it takes longer to navigate on a mobile device. If the application is to "broad" as in too many links on one page, the data may not all fit on the screen. One way to mitigate this problem is to reduce functionality, to keep the application as simple as possible [5].

Service Oriented Architectures are well suited for the mobile environment [3]. Within this architecture, applications can make use of various services by sending messages to them via a protocol. Applications may interact with services on operating systems and written in different languages, as long as the protocol is followed. Services may be located on different mobile devices. This protocol is a good fit, allowing applications to reach out to services on other mobile devices, even though they may be on very different devices.

*'''''Service Oriented Architecture Example''''' [3]

[[Image:SOA_Example.jpg]]

The Energy Conscious (EC) Factory model [7]!!!!

The [http://www.javaworld.com/javaworld/jw-10-2005/jw-1003-mvc.html Model View Controller] pattern [1] fits the mobile environment well. Models may be set up so that optimum data structures are used, as was discussed for the EC Factory pattern [7]. Effecient designs may be built into the controllers. Views may be standardized for the application to handle the small screens.

The meeting pattern is especially useful in mobile environments. One device or application serves as the meeting manager. The meeting manager coordinates and tracks the other agents (programs or applications). These agents communicate with the oversight of the meeting manager. Agents may be located on different devices, even on computers with more resources. This is especially well suited for the mobile environment because it is a good way to manage the communications and relatively small applications. A further benefit of the meeting pattern is that mobile applications may be combined (somewhat in the fashion of parallel computing) to do more and provide more resources [6].

*'''''Meeting pattern Example''''' [6]

[[Image:MCFigure3.jpg]]

The master slave pattern is simmilar to the meeting pattern. Instead of a meeting manager and agents, there is a master that creates, uses, and destroys slave objects. The master assigns the slaves tasks to complete. Like agents in the meeting pattern, slaves may be located on different mobile devices, or even on computers that have more resources. The master / slave pattern is very useful for performing actions in parallel on different mobile devices [6].

== Conclusion ==
In conclusion, certain design patterns are especially useful in the mobile design environment. These patterns help developers to produce applications quickly and applications which make efficient use of the limited resources in the mobile environment. Most design patterns can be of benefit to mobile applications, but certain patterns have features that are especially well suited. The EC factory pattern was designed for the mobile environment to reduce energy use [7]. A few other patterns show much promise with mobile devices, including the meeting pattern, master / slave pattern, and service oriented architectures.

== References ==

1. http://www.javaworld.com/javaworld/jw-10-2005/jw-1003-mvc.html - Model View Controller Architecture

2. http://patterns.littlespringsdesign.com/index.php/The_mobile_challenge - Challenges of the Mobile Environment

3. http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki2_17_va - Service Oriented Architecture

4. http://wiki.forum.nokia.com/index.php/Understading_Desing_Patterns - Understanding Design Patterns

5. http://dev.opera.com/articles/view/designing-and-developing-mobile-web-site/ - Designing and Developing mobile web sites in the real world

6. Emerson F.A Lima, Patrícia D. L. Machado, Fláavio R. Sampaio, and Jorge C. A. Figueiredo. ACM SIGSOFT Software Engineering Notes. Volume 29, issue 3 ISSN: 0163-5948 http://portal.acm.org/citation.cfm?id=986710.986726 Universidade Federal de Campina Grande, Paraíba, Brazil, May, 2004.

7. Kayun Chantarasathaporn, Chonawat Srisa-an. ACM International Conference Proceeding Series; Vol. 270 Proceedings of the 3rd international conference on Mobile technology, applications & systems SESSION: Mobile applications, article 29. ISBN:1-59593-519-3 http://portal.acm.org/citation.cfm?id=1292331.1292364 Bangkok, Thailand, 2006

8. WIM Workshop,Uppsala, 17.9.2004

9. Mobile Application Development, Sam Nasr , www.CleavelandDotNet.info

10. Energy Conscious Factory Method Design Pattern for Mobile Devices with C# and Intermediate Language, by Kayun Chantarasathaporn and Chonawat Srisa-an, Ph.D. at Faculty of Information Technology, Rangsit University, Thailand.

11. http://www.codeproject.com/csharp/structs_in_csharp.asp
== Working Notes ==

[7]
[[Image:ECFactory_Fig1.jpg]]
[[Image:ECFactory_Fig2.jpg]]
[[Image:ECFactory_Fig3.jpg]]
[[Image:ECFactory_Fig5.jpg]]
[[Image:ECFactory_Fig6.jpg]]

Ref: Energy Conscious Factory Method Design Pattern for Mobile Devices with C# and Intermediate Language,
by Kayun Chantarasathaporn and Chonawat Srisa-an, Ph.D. at Faculty of Information Technology, Rangsit University, Thailand.
-----------------------------------

Two major design patterns that have come up to help in mobile softwares and to address the above discussed issues in a mobile device are : Energy Conscious design pattern and Mobile agent design pattern

=== Energy Conscious Factory Design ===

Power consumption has not been much of a concern to developers in the past, but this is important in the mobile environment. Battery power on cell phones is limited. [7]
- Use registers instead of memory whenever possible (registers use less energy)
- Use structs instead of classes
- Use static instead of dynamic

Some strategies and their experimental results are discussed in [10]:
[[Image:ECFactory_Fig8.jpg]| General Strategies]

'''''Factory Method pattern''''' is a pattern that returns an object from one of various possible classes. Which class is chosen to be an object generator is depended on data provided to it.
Factory Method Pattern is a good pattern to build upon for energy conscious pattern.
Lets look at both versions.

[[Image:ECFactory_Fig1.jpg]|Class Diagram of sample Factory Method pattern ]

[[Image:ECFactory_Fig2.jpg]|Sequence Diagram (with Activations) of sample Factory Method pattern ]

'''''Modified Factory Method pattern'''''
As regular Factory Method pattern was not designed for being energy concerned, so, it is slightly modified. Some of the critical tweaks are:
*Factory Method Pattern that mixes usage of struct and class in several manners.
*Factory Method Pattern that uses static factory method in Factory struct
*Factory Method Pattern that applies generics principle which is parametered type
*Factory Method Pattern That Uses ConcreteProduct Class, ConcreteCreator Struct with Non-Static FactoryMethod()

Modified Factory Method pattern applies both struct and class recommendations.

''Factory Method Pattern That Uses ConcreteProduct Class, ConcreteCreator Struct with Non-Static FactoryMethod()''
[[Image:ECFactory_Fig3.jpg]|Class Diagram of Factory Method pattern]

In this case, we use VehicleChooser which is a ConcreteCreator as struct while Car, Plane and Ship which are ConcreteProduct as class. Method ChooseVehicle(...) which is as FactoryMethod() is non-static.

''Factory Method Pattern That Uses ConcreteProduct Struct, ConcreteCreator Struct with Static FactoryMethod()''
[[Image:ECFactory_Fig4.jpg]|Class Diagram of Factory Method pattern]
If we use static method appropriately, CPU workload will be reduced. This affects directly in lessening power consumption as a whole.

'''''Experimental Result:'''''
For various combination shown in figure, the tests were run, and the result obtained are shown in the graph below.

[[Image:ECFactory_Fig5.jpg]|Characteristic of components in each combination ]

[[Image:ECFactory_Fig6.jpg]|CPU Usage Comparison ]

[[Image:ECFactory_Fig7.jpg]|Energy Usage Comparison]

It is observed that Energy Concerned Factory Method Pattern can be obtained from the combination of ConcreteProduct classes and ConcreteCreator struct with static FactoryMethod(). The ECFactory Method Pattern consumes less CPU time than regular Factory Method Pattern around 11% while it is better than the worst case around 80%. The bigger the ConcreteProduct type size is, the more range between the best and the worst case in term of energy consumption will be.
So it is clearly proven how this pattern can save energy.

File:ECFactory Fig7.jpg

2009-11-19T14:00:49Z

Wolverine: from Kayun Chantarasathaporn, Chonawat Srisa-an. ACM International Conference Proceeding Series; Vol. 270 Proceedings of the 3rd international conference on Mobile technology, applications & systems SESSION: Mobile applications, article 29. ISBN:1-59593-5

from Kayun Chantarasathaporn, Chonawat Srisa-an. ACM International Conference Proceeding Series; Vol. 270 Proceedings of the 3rd international conference on Mobile technology, applications & systems SESSION: Mobile applications, article 29. ISBN:1-59593-519-3 http://portal.acm.org/citation.cfm?id=1292331.1292364 Bangkok, Thailand, 2006

File:ECFactory Fig4.jpg

2009-11-19T14:00:28Z

File:ECFactory Fig3.jpg

2009-11-19T13:59:39Z

CSC/ECE 517 Fall 2009/wiki3 21 MobileDesignPattern

2009-11-19T13:57:30Z

Wolverine:

== Design Pattern for Mobile Applications ==

The popularity of mobile applications is rising. Design patterns are useful in almost any coding tasks. While almost any design pattern could be used within mobile applications, certain patterns are well suited for the unique environment of mobile applications. This wiki explains the mobile application environment, then focuses on design patterns that work well within this new emerging environment.

__TOC__

== The Mobile Application Environment ==

The mobile application environment is new and presents many unique opportunities and challenges for developers. It seems almost everyone now has a cellphone, blackberry, or other small portable device. These devices are "getting smarter" in that many people are developing new applications for them. Cell phones no longer are just used to call people, they often have features like text messaging, cameras, video games, web browsers and more. There is much opportunity for developers to write new applications for mobile devices.

While opportunity abounds, there are also quite a few challenges. Mobile applications have less resources than are typically found in other development environments. The screen on mobile devices is typically smaller, there is usually not a keyboard and mouse (user inputs are reduced) [5]. CPU resources are generally less than those found in the typical environment [7]. Power usage is also limited because a battery is typically used, so reducing power use by the application is an important goal [7]. Connections are typically expensive and are often prone to loss of signals [6].

Another problem is that there is a high demand for applications to be developed quickly [7]. The mobile environment is changing rapidly [2]. Some of the lower level programming languages were useful because they produced fast applications, but they took too long to develop with[22 http://www.umsl.edu/~subramaniana/concepts1.html]. Now, with the increased demand for applications quickly, Object Oriented Programming (OOP) is used more. While this causes a greater usage of resources, this is outweighed by the much quicker development cycle and the re-use of code. In particular, good solutions may be re-used in OOP [7].

In the mobile environment, applications are often written on different operating systems [http://en.wikipedia.org/wiki/Mobile_operating_system] on different mobile systems. There is increased interaction between mobile systems, especially for cell phones. The Service Oriented Architecture design pattern is especially well suited for this situation. This is a fairly new field, and methods are currently being developed to aid developers.

== Ways to Adapt Using Design Patterns ==

Several principles and patterns have been understood and developed in developing for mobile applications. Many of these methods are still undergoing change and experimentation. There are new methods being developed and others left behind. A design pattern can be defined as a repeatable solution to a common problem in software. It is a template for how to solve the problem, not actual code [7].

Ease of navigation is a particularly important principle, because of the reduced number of user inputs (for example, buttons from 0 to 9 instead of a mouse and keyboard). Everything in an application should be no more than three clicks away. If a program is too "deep", requiring many clicks, this will be a problem because it takes longer to navigate on a mobile device. If the application is to "broad" as in too many links on one page, the data may not all fit on the screen. One way to mitigate this problem is to reduce functionality, to keep the application as simple as possible [5].

Service Oriented Architectures are well suited for the mobile environment [3]. Within this architecture, applications can make use of various services by sending messages to them via a protocol. Applications may interact with services on operating systems and written in different languages, as long as the protocol is followed. Services may be located on different mobile devices. This protocol is a good fit, allowing applications to reach out to services on other mobile devices, even though they may be on very different devices.

*'''''Service Oriented Architecture Example''''' [3]

[[Image:SOA_Example.jpg]]

The Energy Conscious (EC) Factory model [7]!!!!

The [http://www.javaworld.com/javaworld/jw-10-2005/jw-1003-mvc.html Model View Controller] pattern [1] fits the mobile environment well. Models may be set up so that optimum data structures are used, as was discussed for the EC Factory pattern [7]. Effecient designs may be built into the controllers. Views may be standardized for the application to handle the small screens.

The meeting pattern is especially useful in mobile environments. One device or application serves as the meeting manager. The meeting manager coordinates and tracks the other agents (programs or applications). These agents communicate with the oversight of the meeting manager. Agents may be located on different devices, even on computers with more resources. This is especially well suited for the mobile environment because it is a good way to manage the communications and relatively small applications. A further benefit of the meeting pattern is that mobile applications may be combined (somewhat in the fashion of parallel computing) to do more and provide more resources [6].

*'''''Meeting pattern Example''''' [6]

[[Image:MCFigure3.jpg]]

The master slave pattern is simmilar to the meeting pattern. Instead of a meeting manager and agents, there is a master that creates, uses, and destroys slave objects. The master assigns the slaves tasks to complete. Like agents in the meeting pattern, slaves may be located on different mobile devices, or even on computers that have more resources. The master / slave pattern is very useful for performing actions in parallel on different mobile devices [6].

== Conclusion ==
In conclusion, certain design patterns are especially useful in the mobile design environment. These patterns help developers to produce applications quickly and applications which make efficient use of the limited resources in the mobile environment. Most design patterns can be of benefit to mobile applications, but certain patterns have features that are especially well suited. The EC factory pattern was designed for the mobile environment to reduce energy use [7]. A few other patterns show much promise with mobile devices, including the meeting pattern, master / slave pattern, and service oriented architectures.

== References ==

1. http://www.javaworld.com/javaworld/jw-10-2005/jw-1003-mvc.html - Model View Controller Architecture

2. http://patterns.littlespringsdesign.com/index.php/The_mobile_challenge - Challenges of the Mobile Environment

3. http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki2_17_va - Service Oriented Architecture

4. http://wiki.forum.nokia.com/index.php/Understading_Desing_Patterns - Understanding Design Patterns

5. http://dev.opera.com/articles/view/designing-and-developing-mobile-web-site/ - Designing and Developing mobile web sites in the real world

6. Emerson F.A Lima, Patrícia D. L. Machado, Fláavio R. Sampaio, and Jorge C. A. Figueiredo. ACM SIGSOFT Software Engineering Notes. Volume 29, issue 3 ISSN: 0163-5948 http://portal.acm.org/citation.cfm?id=986710.986726 Universidade Federal de Campina Grande, Paraíba, Brazil, May, 2004.

7. Kayun Chantarasathaporn, Chonawat Srisa-an. ACM International Conference Proceeding Series; Vol. 270 Proceedings of the 3rd international conference on Mobile technology, applications & systems SESSION: Mobile applications, article 29. ISBN:1-59593-519-3 http://portal.acm.org/citation.cfm?id=1292331.1292364 Bangkok, Thailand, 2006

8. WIM Workshop,Uppsala, 17.9.2004

9. Mobile Application Development, Sam Nasr , www.CleavelandDotNet.info

10. Energy Conscious Factory Method Design Pattern for Mobile Devices with C# and Intermediate Language, by Kayun Chantarasathaporn and Chonawat Srisa-an, Ph.D. at Faculty of Information Technology, Rangsit University, Thailand.

11. http://www.codeproject.com/csharp/structs_in_csharp.asp
== Working Notes ==

[7]
[[Image:ECFactory_Fig1.jpg]]
[[Image:ECFactory_Fig2.jpg]]
[[Image:ECFactory_Fig3.jpg]]
[[Image:ECFactory_Fig5.jpg]]
[[Image:ECFactory_Fig6.jpg]]

Ref: Energy Conscious Factory Method Design Pattern for Mobile Devices with C# and Intermediate Language,
by Kayun Chantarasathaporn and Chonawat Srisa-an, Ph.D. at Faculty of Information Technology, Rangsit University, Thailand.
-----------------------------------

Two major design patterns that have come up to help in mobile softwares and to address the above discussed issues in a mobile device are : Energy Conscious design pattern and Mobile agent design pattern

=== Energy Conscious Factory Design ===

Power consumption has not been much of a concern to developers in the past, but this is important in the mobile environment. Battery power on cell phones is limited. [7]
- Use registers instead of memory whenever possible (registers use less energy)
- Use structs instead of classes
- Use static instead of dynamic

Factory Method pattern is a pattern that returns an object from one of various possible classes. Which class is chosen to be an object generator is depended on data provided to it.

Figure 1. Class Diagram of sample Factory Method pattern

Figure 2. Sequence Diagram (with Activations) of sample Factory Method pattern

Modified Factory Method pattern applies both struct and class recommendations.

Factory Method Pattern That Uses ConcreteProduct Class, ConcreteCreator Struct with Non-Static FactoryMethod()
Figure 3. Class Diagram of Factory Method pattern :
In this case, we use VehicleChooser which is a ConcreteCreator as struct while Car, Plane and Ship which are ConcreteProduct as class. Method ChooseVehicle(...) which is as FactoryMethod() is non-static.

Factory Method Pattern That Uses ConcreteProduct Struct, ConcreteCreator Struct with Static FactoryMethod()
Figure 4. Class Diagram of Factory Method pattern
If we use static method appropriately, CPU workload will be reduced. This affects directly in lessening power consumption as a whole.

Experimental Result:
For various combination shown in figure, the tests were run, and the result obtained are shown in the graph below.
Characteristic of components in each combination
Fig5

CPU Usage Comparison
fig6

Energy Usage Comparison
fig 7

Conclusion(this can be put in the main conclusion) :: It is observed that Energy Concerned Factory Method Pattern can be obtained from the combination of ConcreteProduct classes and ConcreteCreator struct with static FactoryMethod(). The ECFactory Method Pattern consumes less CPU time than regular Factory Method Pattern around 11% while it is better than the worst case around 80%. The bigger the ConcreteProduct type size is, the more range between the best and the worst case in term of energy consumption will be.

CSC/ECE 517 Fall 2009/wiki3 21 MobileDesignPattern

2009-11-19T13:50:04Z

Wolverine: /* References */

== Design Pattern for Mobile Applications ==

The popularity of mobile applications is rising. Design patterns are useful in almost any coding tasks. While almost any design pattern could be used within mobile applications, certain patterns are well suited for the unique environment of mobile applications. This wiki explains the mobile application environment, then focuses on design patterns that work well within this new emerging environment.

__TOC__

== The Mobile Application Environment ==

The mobile application environment is new and presents many unique opportunities and challenges for developers. It seems almost everyone now has a cellphone, blackberry, or other small portable device. These devices are "getting smarter" in that many people are developing new applications for them. Cell phones no longer are just used to call people, they often have features like text messaging, cameras, video games, web browsers and more. There is much opportunity for developers to write new applications for mobile devices.

While opportunity abounds, there are also quite a few challenges. Mobile applications have less resources than are typically found in other development environments. The screen on mobile devices is typically smaller, there is usually not a keyboard and mouse (user inputs are reduced) [5]. CPU resources are generally less than those found in the typical environment [7]. Power usage is also limited because a battery is typically used, so reducing power use by the application is an important goal [7]. Connections are typically expensive and are often prone to loss of signals [6].

Another problem is that there is a high demand for applications to be developed quickly [7]. The mobile environment is changing rapidly [2]. Some of the lower level programming languages were useful because they produced fast applications, but they took too long to develop with[22 http://www.umsl.edu/~subramaniana/concepts1.html]. Now, with the increased demand for applications quickly, Object Oriented Programming (OOP) is used more. While this causes a greater usage of resources, this is outweighed by the much quicker development cycle and the re-use of code. In particular, good solutions may be re-used in OOP [7].

In the mobile environment, applications are often written on different operating systems [http://en.wikipedia.org/wiki/Mobile_operating_system] on different mobile systems. There is increased interaction between mobile systems, especially for cell phones. The Service Oriented Architecture design pattern is especially well suited for this situation. This is a fairly new field, and methods are currently being developed to aid developers.

== Ways to Adapt Using Design Patterns ==

Several principles and patterns have been understood and developed in developing for mobile applications. Many of these methods are still undergoing change and experimentation. There are new methods being developed and others left behind. A design pattern can be defined as a repeatable solution to a common problem in software. It is a template for how to solve the problem, not actual code [7].

Ease of navigation is a particularly important principle, because of the reduced number of user inputs (for example, buttons from 0 to 9 instead of a mouse and keyboard). Everything in an application should be no more than three clicks away. If a program is too "deep", requiring many clicks, this will be a problem because it takes longer to navigate on a mobile device. If the application is to "broad" as in too many links on one page, the data may not all fit on the screen. One way to mitigate this problem is to reduce functionality, to keep the application as simple as possible [5].

Service Oriented Architectures are well suited for the mobile environment [3]. Within this architecture, applications can make use of various services by sending messages to them via a protocol. Applications may interact with services on operating systems and written in different languages, as long as the protocol is followed. Services may be located on different mobile devices. This protocol is a good fit, allowing applications to reach out to services on other mobile devices, even though they may be on very different devices.

*'''''Service Oriented Architecture Example''''' [3]

[[Image:SOA_Example.jpg]]

The Energy Conscious (EC) Factory model [7]!!!!

The [http://www.javaworld.com/javaworld/jw-10-2005/jw-1003-mvc.html Model View Controller] pattern [1] fits the mobile environment well. Models may be set up so that optimum data structures are used, as was discussed for the EC Factory pattern [7]. Effecient designs may be built into the controllers. Views may be standardized for the application to handle the small screens.

The meeting pattern is especially useful in mobile environments. One device or application serves as the meeting manager. The meeting manager coordinates and tracks the other agents (programs or applications). These agents communicate with the oversight of the meeting manager. Agents may be located on different devices, even on computers with more resources. This is especially well suited for the mobile environment because it is a good way to manage the communications and relatively small applications. A further benefit of the meeting pattern is that mobile applications may be combined (somewhat in the fashion of parallel computing) to do more and provide more resources [6].

*'''''Meeting pattern Example''''' [6]

[[Image:MCFigure3.jpg]]

The master slave pattern is simmilar to the meeting pattern. Instead of a meeting manager and agents, there is a master that creates, uses, and destroys slave objects. The master assigns the slaves tasks to complete. Like agents in the meeting pattern, slaves may be located on different mobile devices, or even on computers that have more resources. The master / slave pattern is very useful for performing actions in parallel on different mobile devices [6].

== Conclusion ==
In conclusion, certain design patterns are especially useful in the mobile design environment. These patterns help developers to produce applications quickly and applications which make efficient use of the limited resources in the mobile environment. Most design patterns can be of benefit to mobile applications, but certain patterns have features that are especially well suited. The EC factory pattern was designed for the mobile environment to reduce energy use [7]. A few other patterns show much promise with mobile devices, including the meeting pattern, master / slave pattern, and service oriented architectures.

== References ==

1. http://www.javaworld.com/javaworld/jw-10-2005/jw-1003-mvc.html - Model View Controller Architecture

2. http://patterns.littlespringsdesign.com/index.php/The_mobile_challenge - Challenges of the Mobile Environment

3. http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki2_17_va - Service Oriented Architecture

4. http://wiki.forum.nokia.com/index.php/Understading_Desing_Patterns - Understanding Design Patterns

5. http://dev.opera.com/articles/view/designing-and-developing-mobile-web-site/ - Designing and Developing mobile web sites in the real world

6. Emerson F.A Lima, Patrícia D. L. Machado, Fláavio R. Sampaio, and Jorge C. A. Figueiredo. ACM SIGSOFT Software Engineering Notes. Volume 29, issue 3 ISSN: 0163-5948 http://portal.acm.org/citation.cfm?id=986710.986726 Universidade Federal de Campina Grande, Paraíba, Brazil, May, 2004.

7. Kayun Chantarasathaporn, Chonawat Srisa-an. ACM International Conference Proceeding Series; Vol. 270 Proceedings of the 3rd international conference on Mobile technology, applications & systems SESSION: Mobile applications, article 29. ISBN:1-59593-519-3 http://portal.acm.org/citation.cfm?id=1292331.1292364 Bangkok, Thailand, 2006

8. WIM Workshop,Uppsala, 17.9.2004

9. Mobile Application Development, Sam Nasr , www.CleavelandDotNet.info

10. Energy Conscious Factory Method Design Pattern for Mobile Devices with C# and Intermediate Language, by Kayun Chantarasathaporn and Chonawat Srisa-an, Ph.D. at Faculty of Information Technology, Rangsit University, Thailand.

== Working Notes ==

[7]
[[Image:ECFactory_Fig1.jpg]]
[[Image:ECFactory_Fig2.jpg]]
[[Image:ECFactory_Fig5.jpg]]
[[Image:ECFactory_Fig6.jpg]]

Ref: Energy Conscious Factory Method Design Pattern for Mobile Devices with C# and Intermediate Language,
by Kayun Chantarasathaporn and Chonawat Srisa-an, Ph.D. at Faculty of Information Technology, Rangsit University, Thailand.
-----------------------------------

Two major design patterns that have come up to help in mobile softwares and to address the above discussed issues in a mobile device are :

1. Energy Conscious design pattern
2. Mobile agent design pattern

Energy Conscious Factory Design
Power consumption has not been much of a concern to developers in the past, but this is important in the mobile environment. Battery power on cell phones is limited.

[7]
- Use registers instead of memory whenever possible (registers use less energy)
- Use structs instead of classes
- Use static instead of dynamic

Factory Method pattern is a pattern that returns an object from one of various possible classes. Which class is chosen to be an object generator is depended on data provided to it.

Figure 1. Class Diagram of sample Factory Method pattern

Figure 2. Sequence Diagram (with Activations) of sample Factory Method pattern

Modified Factory Method pattern applies both struct and class recommendations.

Factory Method Pattern That Uses ConcreteProduct Class, ConcreteCreator Struct with Non-Static FactoryMethod()
Figure 3. Class Diagram of Factory Method pattern :
In this case, we use VehicleChooser which is a ConcreteCreator as struct while Car, Plane and Ship which are ConcreteProduct as class. Method ChooseVehicle(...) which is as FactoryMethod() is non-static.

Factory Method Pattern That Uses ConcreteProduct Struct, ConcreteCreator Struct with Static FactoryMethod()
Figure 4. Class Diagram of Factory Method pattern
If we use static method appropriately, CPU workload will be reduced. This affects directly in lessening power consumption as a whole.

Experimental Result:
For various combination shown in figure, the tests were run, and the result obtained are shown in the graph below.
Characteristic of components in each combination
Fig5

CPU Usage Comparison
fig6

Energy Usage Comparison
fig 7

Conclusion(this can be put in the main conclusion) :: It is observed that Energy Concerned Factory Method Pattern can be obtained from the combination of ConcreteProduct classes and ConcreteCreator struct with static FactoryMethod(). The ECFactory Method Pattern consumes less CPU time than regular Factory Method Pattern around 11% while it is better than the worst case around 80%. The bigger the ConcreteProduct type size is, the more range between the best and the worst case in term of energy consumption will be.

CSC/ECE 517 Fall 2009/wiki3 21 MobileDesignPattern

2009-11-19T13:49:29Z

Wolverine: /* References */

== Design Pattern for Mobile Applications ==

The popularity of mobile applications is rising. Design patterns are useful in almost any coding tasks. While almost any design pattern could be used within mobile applications, certain patterns are well suited for the unique environment of mobile applications. This wiki explains the mobile application environment, then focuses on design patterns that work well within this new emerging environment.

__TOC__

== The Mobile Application Environment ==

The mobile application environment is new and presents many unique opportunities and challenges for developers. It seems almost everyone now has a cellphone, blackberry, or other small portable device. These devices are "getting smarter" in that many people are developing new applications for them. Cell phones no longer are just used to call people, they often have features like text messaging, cameras, video games, web browsers and more. There is much opportunity for developers to write new applications for mobile devices.

While opportunity abounds, there are also quite a few challenges. Mobile applications have less resources than are typically found in other development environments. The screen on mobile devices is typically smaller, there is usually not a keyboard and mouse (user inputs are reduced) [5]. CPU resources are generally less than those found in the typical environment [7]. Power usage is also limited because a battery is typically used, so reducing power use by the application is an important goal [7]. Connections are typically expensive and are often prone to loss of signals [6].

Another problem is that there is a high demand for applications to be developed quickly [7]. The mobile environment is changing rapidly [2]. Some of the lower level programming languages were useful because they produced fast applications, but they took too long to develop with[22 http://www.umsl.edu/~subramaniana/concepts1.html]. Now, with the increased demand for applications quickly, Object Oriented Programming (OOP) is used more. While this causes a greater usage of resources, this is outweighed by the much quicker development cycle and the re-use of code. In particular, good solutions may be re-used in OOP [7].

In the mobile environment, applications are often written on different operating systems [http://en.wikipedia.org/wiki/Mobile_operating_system] on different mobile systems. There is increased interaction between mobile systems, especially for cell phones. The Service Oriented Architecture design pattern is especially well suited for this situation. This is a fairly new field, and methods are currently being developed to aid developers.

== Ways to Adapt Using Design Patterns ==

Several principles and patterns have been understood and developed in developing for mobile applications. Many of these methods are still undergoing change and experimentation. There are new methods being developed and others left behind. A design pattern can be defined as a repeatable solution to a common problem in software. It is a template for how to solve the problem, not actual code [7].

Ease of navigation is a particularly important principle, because of the reduced number of user inputs (for example, buttons from 0 to 9 instead of a mouse and keyboard). Everything in an application should be no more than three clicks away. If a program is too "deep", requiring many clicks, this will be a problem because it takes longer to navigate on a mobile device. If the application is to "broad" as in too many links on one page, the data may not all fit on the screen. One way to mitigate this problem is to reduce functionality, to keep the application as simple as possible [5].

Service Oriented Architectures are well suited for the mobile environment [3]. Within this architecture, applications can make use of various services by sending messages to them via a protocol. Applications may interact with services on operating systems and written in different languages, as long as the protocol is followed. Services may be located on different mobile devices. This protocol is a good fit, allowing applications to reach out to services on other mobile devices, even though they may be on very different devices.

*'''''Service Oriented Architecture Example''''' [3]

[[Image:SOA_Example.jpg]]

The Energy Conscious (EC) Factory model [7]!!!!

The [http://www.javaworld.com/javaworld/jw-10-2005/jw-1003-mvc.html Model View Controller] pattern [1] fits the mobile environment well. Models may be set up so that optimum data structures are used, as was discussed for the EC Factory pattern [7]. Effecient designs may be built into the controllers. Views may be standardized for the application to handle the small screens.

The meeting pattern is especially useful in mobile environments. One device or application serves as the meeting manager. The meeting manager coordinates and tracks the other agents (programs or applications). These agents communicate with the oversight of the meeting manager. Agents may be located on different devices, even on computers with more resources. This is especially well suited for the mobile environment because it is a good way to manage the communications and relatively small applications. A further benefit of the meeting pattern is that mobile applications may be combined (somewhat in the fashion of parallel computing) to do more and provide more resources [6].

*'''''Meeting pattern Example''''' [6]

[[Image:MCFigure3.jpg]]

The master slave pattern is simmilar to the meeting pattern. Instead of a meeting manager and agents, there is a master that creates, uses, and destroys slave objects. The master assigns the slaves tasks to complete. Like agents in the meeting pattern, slaves may be located on different mobile devices, or even on computers that have more resources. The master / slave pattern is very useful for performing actions in parallel on different mobile devices [6].

== Conclusion ==
In conclusion, certain design patterns are especially useful in the mobile design environment. These patterns help developers to produce applications quickly and applications which make efficient use of the limited resources in the mobile environment. Most design patterns can be of benefit to mobile applications, but certain patterns have features that are especially well suited. The EC factory pattern was designed for the mobile environment to reduce energy use [7]. A few other patterns show much promise with mobile devices, including the meeting pattern, master / slave pattern, and service oriented architectures.

== References ==

1. http://www.javaworld.com/javaworld/jw-10-2005/jw-1003-mvc.html - Model View Controller Architecture

2. http://patterns.littlespringsdesign.com/index.php/The_mobile_challenge - Challenges of the Mobile Environment

3. http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki2_17_va - Service Oriented Architecture

4. http://wiki.forum.nokia.com/index.php/Understading_Desing_Patterns - Understanding Design Patterns

5. http://dev.opera.com/articles/view/designing-and-developing-mobile-web-site/ - Designing and Developing mobile web sites in the real world

6. Emerson F.A Lima, Patrícia D. L. Machado, Fláavio R. Sampaio, and Jorge C. A. Figueiredo. ACM SIGSOFT Software Engineering Notes. Volume 29, issue 3 ISSN: 0163-5948 http://portal.acm.org/citation.cfm?id=986710.986726 Universidade Federal de Campina Grande, Paraíba, Brazil, May, 2004.

7. Kayun Chantarasathaporn, Chonawat Srisa-an. ACM International Conference Proceeding Series; Vol. 270 Proceedings of the 3rd international conference on Mobile technology, applications & systems SESSION: Mobile applications, article 29. ISBN:1-59593-519-3 http://portal.acm.org/citation.cfm?id=1292331.1292364 Bangkok, Thailand, 2006

8. WIM Workshop,Uppsala, 17.9.2004

9.Mobile Application Development, Sam Nasr , www.CleavelandDotNet.info

10.Energy Conscious Factory Method Design Pattern for Mobile Devices with C# and Intermediate Language,
by Kayun Chantarasathaporn and Chonawat Srisa-an, Ph.D. at Faculty of Information Technology, Rangsit University, Thailand.

== Working Notes ==

[7]
[[Image:ECFactory_Fig1.jpg]]
[[Image:ECFactory_Fig2.jpg]]
[[Image:ECFactory_Fig5.jpg]]
[[Image:ECFactory_Fig6.jpg]]

Ref: Energy Conscious Factory Method Design Pattern for Mobile Devices with C# and Intermediate Language,
by Kayun Chantarasathaporn and Chonawat Srisa-an, Ph.D. at Faculty of Information Technology, Rangsit University, Thailand.
-----------------------------------

Two major design patterns that have come up to help in mobile softwares and to address the above discussed issues in a mobile device are :

1. Energy Conscious design pattern
2. Mobile agent design pattern

Energy Conscious Factory Design
Power consumption has not been much of a concern to developers in the past, but this is important in the mobile environment. Battery power on cell phones is limited.

[7]
- Use registers instead of memory whenever possible (registers use less energy)
- Use structs instead of classes
- Use static instead of dynamic

Factory Method pattern is a pattern that returns an object from one of various possible classes. Which class is chosen to be an object generator is depended on data provided to it.

Figure 1. Class Diagram of sample Factory Method pattern

Figure 2. Sequence Diagram (with Activations) of sample Factory Method pattern

Modified Factory Method pattern applies both struct and class recommendations.

Factory Method Pattern That Uses ConcreteProduct Class, ConcreteCreator Struct with Non-Static FactoryMethod()
Figure 3. Class Diagram of Factory Method pattern :
In this case, we use VehicleChooser which is a ConcreteCreator as struct while Car, Plane and Ship which are ConcreteProduct as class. Method ChooseVehicle(...) which is as FactoryMethod() is non-static.

Factory Method Pattern That Uses ConcreteProduct Struct, ConcreteCreator Struct with Static FactoryMethod()
Figure 4. Class Diagram of Factory Method pattern
If we use static method appropriately, CPU workload will be reduced. This affects directly in lessening power consumption as a whole.

Experimental Result:
For various combination shown in figure, the tests were run, and the result obtained are shown in the graph below.
Characteristic of components in each combination
Fig5

CPU Usage Comparison
fig6

Energy Usage Comparison
fig 7

Conclusion(this can be put in the main conclusion) :: It is observed that Energy Concerned Factory Method Pattern can be obtained from the combination of ConcreteProduct classes and ConcreteCreator struct with static FactoryMethod(). The ECFactory Method Pattern consumes less CPU time than regular Factory Method Pattern around 11% while it is better than the worst case around 80%. The bigger the ConcreteProduct type size is, the more range between the best and the worst case in term of energy consumption will be.

CSC/ECE 517 Fall 2009/wiki3 21 MobileDesignPattern

2009-11-19T05:01:42Z

Wolverine: /* The Mobile Application Environment */

== Design Pattern for Mobile Applications ==

The popularity of mobile applications is rising. Design patterns are useful in almost any coding tasks. While almost any design pattern could be used within mobile applications, certain patterns are well suited for the unique environment of mobile applications. This wiki explains the mobile application environment, then focuses on design patterns that work well within this new emerging environment.

__TOC__

== The Mobile Application Environment ==

The mobile application environment is new and presents many unique opportunities and challenges for developers. It seems almost everyone now has a cellphone, blackberry, or other small portable device. These devices are "getting smarter" in that many people are developing new applications for them. Cell phones no longer are just used to call people, they often have features like text messaging, cameras, video games, web browsers and more. There is much opportunity for developers to write new applications for mobile devices.

While opportunity abounds, there are also quite a few challenges. Mobile applications have less resources than are typically found in other development environments. The screen on mobile devices is typically smaller, there is usually not a keyboard and mouse (user inputs are reduced) [5]. CPU resources are generally less than those found in the typical environment [7]. Power usage is also limited because a battery is typically used, so reducing power use by the application is an important goal [7]. Connections are typically expensive and are often prone to loss of signals [6].

Another problem is that there is a high demand for applications to be developed quickly [7]. The mobile environment is changing rapidly [2]. Some of the lower level programming languages were useful because they produced fast applications, but they took too long to develop with[22 http://www.umsl.edu/~subramaniana/concepts1.html]. Now, with the increased demand for applications quickly, Object Oriented Programming (OOP) is used more. While this causes a greater usage of resources, this is outweighed by the much quicker development cycle and the re-use of code. In particular, good solutions may be re-used in OOP [7].

In the mobile environment, applications are often written on different operating systems [http://en.wikipedia.org/wiki/Mobile_operating_system] on different mobile systems. There is increased interaction between mobile systems, especially for cell phones. The Service Oriented Architecture design pattern is especially well suited for this situation. This is a fairly new field, and methods are currently being developed to aid developers.

== Ways to Adapt Using Design Patterns ==

Several principles and patterns have been understood and developed in developing for mobile applications. Many of these methods are still undergoing change and experimentation. There are new methods being developed and others left behind. A design pattern can be defined as a repeatable solution to a common problem in software. It is a template for how to solve the problem, not actual code [7].

Ease of navigation is a particularly important principle, because of the reduced number of user inputs (for example, buttons from 0 to 9 instead of a mouse and keyboard). Everything in an application should be no more than three clicks away. If a program is too "deep", requiring many clicks, this will be a problem because it takes longer to navigate on a mobile device. If the application is to "broad" as in too many links on one page, the data may not all fit on the screen. One way to mitigate this problem is to reduce functionality, to keep the application as simple as possible [5].

Service Oriented Architectures are well suited for the mobile environment [3]. Within this architecture, applications can make use of various services by sending messages to them via a protocol. Applications may interact with services on operating systems and written in different languages, as long as the protocol is followed. Services may be located on different mobile devices. This protocol is a good fit, allowing applications to reach out to services on other mobile devices, even though they may be on very different devices.

*'''''Service Oriented Architecture Example''''' [3]

[[Image:SOA_Example.jpg]]

The Energy Conscious (EC) Factory model [7]!!!!

The [http://www.javaworld.com/javaworld/jw-10-2005/jw-1003-mvc.html Model View Controller] pattern [1] fits the mobile environment well. Models may be set up so that optimum data structures are used, as was discussed for the EC Factory pattern [7]. Effecient designs may be built into the controllers. Views may be standardized for the application to handle the small screens.

The meeting pattern is especially useful in mobile environments. One device or application serves as the meeting manager. The meeting manager coordinates and tracks the other agents (programs or applications). These agents communicate with the oversight of the meeting manager. Agents may be located on different devices, even on computers with more resources. This is especially well suited for the mobile environment because it is a good way to manage the communications and relatively small applications. A further benefit of the meeting pattern is that mobile applications may be combined (somewhat in the fashion of parallel computing) to do more and provide more resources [6].

*'''''Meeting pattern Example''''' [6]

[[Image:MCFigure3.jpg]]

The master slave pattern is simmilar to the meeting pattern. Instead of a meeting manager and agents, there is a master that creates, uses, and destroys slave objects. The master assigns the slaves tasks to complete. Like agents in the meeting pattern, slaves may be located on different mobile devices, or even on computers that have more resources. The master / slave pattern is very useful for performing actions in parallel on different mobile devices [6].

== Conclusion ==
In conclusion, certain design patterns are especially useful in the mobile design environment. These patterns help developers to produce applications quickly and applications which make efficient use of the limited resources in the mobile environment. Most design patterns can be of benefit to mobile applications, but certain patterns have features that are especially well suited. The EC factory pattern was designed for the mobile environment to reduce energy use [7]. A few other patterns show much promise with mobile devices, including the meeting pattern, master / slave pattern, and service oriented architectures.

== References ==

1. http://www.javaworld.com/javaworld/jw-10-2005/jw-1003-mvc.html - Model View Controller Architecture

2. http://patterns.littlespringsdesign.com/index.php/The_mobile_challenge - Challenges of the Mobile Environment

3. http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki2_17_va - Service Oriented Architecture

4. http://wiki.forum.nokia.com/index.php/Understading_Desing_Patterns - Understanding Design Patterns

5. http://dev.opera.com/articles/view/designing-and-developing-mobile-web-site/ - Designing and Developing mobile web sites in the real world

6. Emerson F.A Lima, Patrícia D. L. Machado, Fláavio R. Sampaio, and Jorge C. A. Figueiredo. ACM SIGSOFT Software Engineering Notes. Volume 29, issue 3 ISSN: 0163-5948 http://portal.acm.org/citation.cfm?id=986710.986726 Universidade Federal de Campina Grande, Paraíba, Brazil, May, 2004.

7. Kayun Chantarasathaporn, Chonawat Srisa-an. ACM International Conference Proceeding Series; Vol. 270 Proceedings of the 3rd international conference on Mobile technology, applications & systems SESSION: Mobile applications, article 29. ISBN:1-59593-519-3 http://portal.acm.org/citation.cfm?id=1292331.1292364 Bangkok, Thailand, 2006

== Working Notes ==

[7]
[[Image:ECFactory_Fig1.jpg]]
[[Image:ECFactory_Fig2.jpg]]
[[Image:ECFactory_Fig5.jpg]]
[[Image:ECFactory_Fig6.jpg]]

Ref: Energy Conscious Factory Method Design Pattern for Mobile Devices with C# and Intermediate Language,
by Kayun Chantarasathaporn and Chonawat Srisa-an, Ph.D. at Faculty of Information Technology, Rangsit University, Thailand.
-----------------------------------

Two major design patterns that have come up to help in mobile softwares and to address the above discussed issues in a mobile device are :

1. Energy Conscious design pattern
2. Mobile agent design pattern

Energy Conscious Factory Design
Power consumption has not been much of a concern to developers in the past, but this is important in the mobile environment. Battery power on cell phones is limited.

[7]
- Use registers instead of memory whenever possible (registers use less energy)
- Use structs instead of classes
- Use static instead of dynamic

Factory Method pattern is a pattern that returns an object from one of various possible classes. Which class is chosen to be an object generator is depended on data provided to it.

Figure 1. Class Diagram of sample Factory Method pattern

Figure 2. Sequence Diagram (with Activations) of sample Factory Method pattern

Modified Factory Method pattern applies both struct and class recommendations.

Factory Method Pattern That Uses ConcreteProduct Class, ConcreteCreator Struct with Non-Static FactoryMethod()
Figure 3. Class Diagram of Factory Method pattern :
In this case, we use VehicleChooser which is a ConcreteCreator as struct while Car, Plane and Ship which are ConcreteProduct as class. Method ChooseVehicle(...) which is as FactoryMethod() is non-static.

Factory Method Pattern That Uses ConcreteProduct Struct, ConcreteCreator Struct with Static FactoryMethod()
Figure 4. Class Diagram of Factory Method pattern
If we use static method appropriately, CPU workload will be reduced. This affects directly in lessening power consumption as a whole.

Experimental Result:
For various combination shown in figure, the tests were run, and the result obtained are shown in the graph below.
Characteristic of components in each combination
Fig5

CPU Usage Comparison
fig6

Energy Usage Comparison
fig 7

Conclusion(this can be put in the main conclusion) :: It is observed that Energy Concerned Factory Method Pattern can be obtained from the combination of ConcreteProduct classes and ConcreteCreator struct with static FactoryMethod(). The ECFactory Method Pattern consumes less CPU time than regular Factory Method Pattern around 11% while it is better than the worst case around 80%. The bigger the ConcreteProduct type size is, the more range between the best and the worst case in term of energy consumption will be.

CSC/ECE 517 Fall 2009/wiki3 21 MobileDesignPattern

2009-11-19T04:57:55Z

Wolverine: /* The Mobile Application Environment */

== Design Pattern for Mobile Applications ==

The popularity of mobile applications is rising. Design patterns are useful in almost any coding tasks. While almost any design pattern could be used within mobile applications, certain patterns are well suited for the unique environment of mobile applications. This wiki explains the mobile application environment, then focuses on design patterns that work well within this new emerging environment.

__TOC__

== The Mobile Application Environment ==

The mobile application environment is new and presents many unique opportunities and challenges for developers. It seems almost everyone now has a cellphone, blackberry, or other small portable device. These devices are "getting smarter" in that many people are developing new applications for them. Cell phones no longer are just used to call people, they often have features like text messaging, cameras, video games, web browsers and more. There is much opportunity for developers to write new applications for mobile devices.

While opportunity abounds, there are also quite a few challenges. Mobile applications have less resources than are typically found in other development environments. The screen on mobile devices is typically smaller, there is usually not a keyboard and mouse (user inputs are reduced) [5]. CPU resources are generally less than those found in the typical environment [7]. Power usage is also limited because a battery is typically used, so reducing power use by the application is an important goal [7]. Connections are typically expensive and are often prone to loss of signals [6].

Another problem is that there is a high demand for applications to be developed quickly [7]. The mobile environment is changing rapidly [2]. Some of the lower level programming languages were useful because they produced fast applications, but they took too long to develop with[http://www.umsl.edu/~subramaniana/concepts1.html]. Now, with the increased demand for applications quickly, Object Oriented Programming (OOP) is used more. While this causes a greater usage of resources, this is outweighed by the much quicker development cycle and the re-use of code. In particular, good solutions may be re-used in OOP [7].

In the mobile environment, applications are often written on different operating systems [http://en.wikipedia.org/wiki/Mobile_operating_system] on different mobile systems. There is increased interaction between mobile systems, especially for cell phones. The Service Oriented Architecture design pattern is especially well suited for this situation. This is a fairly new field, and methods are currently being developed to aid developers.

== Ways to Adapt Using Design Patterns ==

Several principles and patterns have been understood and developed in developing for mobile applications. Many of these methods are still undergoing change and experimentation. There are new methods being developed and others left behind. A design pattern can be defined as a repeatable solution to a common problem in software. It is a template for how to solve the problem, not actual code [7].

Ease of navigation is a particularly important principle, because of the reduced number of user inputs (for example, buttons from 0 to 9 instead of a mouse and keyboard). Everything in an application should be no more than three clicks away. If a program is too "deep", requiring many clicks, this will be a problem because it takes longer to navigate on a mobile device. If the application is to "broad" as in too many links on one page, the data may not all fit on the screen. One way to mitigate this problem is to reduce functionality, to keep the application as simple as possible [5].

Service Oriented Architectures are well suited for the mobile environment [3]. Within this architecture, applications can make use of various services by sending messages to them via a protocol. Applications may interact with services on operating systems and written in different languages, as long as the protocol is followed. Services may be located on different mobile devices. This protocol is a good fit, allowing applications to reach out to services on other mobile devices, even though they may be on very different devices.

*'''''Service Oriented Architecture Example''''' [3]

[[Image:SOA_Example.jpg]]

The Energy Conscious (EC) Factory model [7]!!!!

The [http://www.javaworld.com/javaworld/jw-10-2005/jw-1003-mvc.html Model View Controller] pattern [1] fits the mobile environment well. Models may be set up so that optimum data structures are used, as was discussed for the EC Factory pattern [7]. Effecient designs may be built into the controllers. Views may be standardized for the application to handle the small screens.

The meeting pattern is especially useful in mobile environments. One device or application serves as the meeting manager. The meeting manager coordinates and tracks the other agents (programs or applications). These agents communicate with the oversight of the meeting manager. Agents may be located on different devices, even on computers with more resources. This is especially well suited for the mobile environment because it is a good way to manage the communications and relatively small applications. A further benefit of the meeting pattern is that mobile applications may be combined (somewhat in the fashion of parallel computing) to do more and provide more resources [6].

*'''''Meeting pattern Example''''' [6]

[[Image:MCFigure3.jpg]]

The master slave pattern is simmilar to the meeting pattern. Instead of a meeting manager and agents, there is a master that creates, uses, and destroys slave objects. The master assigns the slaves tasks to complete. Like agents in the meeting pattern, slaves may be located on different mobile devices, or even on computers that have more resources. The master / slave pattern is very useful for performing actions in parallel on different mobile devices [6].

== Conclusion ==
In conclusion, certain design patterns are especially useful in the mobile design environment. These patterns help developers to produce applications quickly and applications which make efficient use of the limited resources in the mobile environment. Most design patterns can be of benefit to mobile applications, but certain patterns have features that are especially well suited. The EC factory pattern was designed for the mobile environment to reduce energy use [7]. A few other patterns show much promise with mobile devices, including the meeting pattern, master / slave pattern, and service oriented architectures.

== References ==

1. http://www.javaworld.com/javaworld/jw-10-2005/jw-1003-mvc.html - Model View Controller Architecture

2. http://patterns.littlespringsdesign.com/index.php/The_mobile_challenge - Challenges of the Mobile Environment

3. http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki2_17_va - Service Oriented Architecture

4. http://wiki.forum.nokia.com/index.php/Understading_Desing_Patterns - Understanding Design Patterns

5. http://dev.opera.com/articles/view/designing-and-developing-mobile-web-site/ - Designing and Developing mobile web sites in the real world

6. Emerson F.A Lima, Patrícia D. L. Machado, Fláavio R. Sampaio, and Jorge C. A. Figueiredo. ACM SIGSOFT Software Engineering Notes. Volume 29, issue 3 ISSN: 0163-5948 http://portal.acm.org/citation.cfm?id=986710.986726 Universidade Federal de Campina Grande, Paraíba, Brazil, May, 2004.

7. Kayun Chantarasathaporn, Chonawat Srisa-an. ACM International Conference Proceeding Series; Vol. 270 Proceedings of the 3rd international conference on Mobile technology, applications & systems SESSION: Mobile applications, article 29. ISBN:1-59593-519-3 http://portal.acm.org/citation.cfm?id=1292331.1292364 Bangkok, Thailand, 2006

== Working Notes ==

[7]
[[Image:ECFactory_Fig1.jpg]]
[[Image:ECFactory_Fig2.jpg]]
[[Image:ECFactory_Fig5.jpg]]
[[Image:ECFactory_Fig6.jpg]]

Ref: Energy Conscious Factory Method Design Pattern for Mobile Devices with C# and Intermediate Language,
by Kayun Chantarasathaporn and Chonawat Srisa-an, Ph.D. at Faculty of Information Technology, Rangsit University, Thailand.
-----------------------------------

Two major design patterns that have come up to help in mobile softwares and to address the above discussed issues in a mobile device are :

1. Energy Conscious design pattern
2. Mobile agent design pattern

Energy Conscious Factory Design
Power consumption has not been much of a concern to developers in the past, but this is important in the mobile environment. Battery power on cell phones is limited.

[7]
- Use registers instead of memory whenever possible (registers use less energy)
- Use structs instead of classes
- Use static instead of dynamic

Factory Method pattern is a pattern that returns an object from one of various possible classes. Which class is chosen to be an object generator is depended on data provided to it.

Figure 1. Class Diagram of sample Factory Method pattern

Figure 2. Sequence Diagram (with Activations) of sample Factory Method pattern

Modified Factory Method pattern applies both struct and class recommendations.

Factory Method Pattern That Uses ConcreteProduct Class, ConcreteCreator Struct with Non-Static FactoryMethod()
Figure 3. Class Diagram of Factory Method pattern :
In this case, we use VehicleChooser which is a ConcreteCreator as struct while Car, Plane and Ship which are ConcreteProduct as class. Method ChooseVehicle(...) which is as FactoryMethod() is non-static.

Factory Method Pattern That Uses ConcreteProduct Struct, ConcreteCreator Struct with Static FactoryMethod()
Figure 4. Class Diagram of Factory Method pattern
If we use static method appropriately, CPU workload will be reduced. This affects directly in lessening power consumption as a whole.

Experimental Result:
For various combination shown in figure, the tests were run, and the result obtained are shown in the graph below.
Characteristic of components in each combination
Fig5

CPU Usage Comparison
fig6

Energy Usage Comparison
fig 7

Conclusion(this can be put in the main conclusion) :: It is observed that Energy Concerned Factory Method Pattern can be obtained from the combination of ConcreteProduct classes and ConcreteCreator struct with static FactoryMethod(). The ECFactory Method Pattern consumes less CPU time than regular Factory Method Pattern around 11% while it is better than the worst case around 80%. The bigger the ConcreteProduct type size is, the more range between the best and the worst case in term of energy consumption will be.

CSC/ECE 517 Fall 2009/wiki3 21 MobileDesignPattern

2009-11-19T04:21:57Z

Wolverine: /* Design Pattern for Mobile Applications */

CSC/ECE 517 Fall 2009/wiki3 21 MobileDesignPattern

2009-11-11T20:21:58Z

Wolverine: /* Design Pattern for Mobile Application */

== Design Pattern for Mobile Applications ==

CSC/ECE 517 Fall 2009/wiki3 21 MobileDesignPattern

2009-11-09T16:55:08Z

Wolverine:

== Design Pattern for Mobile Application ==

CSC/ECE 517 Fall 2009/wiki2 2 AJAXandMVC

2009-10-11T03:56:13Z

Wolverine: /* References */

'''AJAX AND MVC'''
----

''There are several MVC frameworks that can take advantage of the client-side processing facilities of AJAX. Our aim in writing this wiki page is to consider what parts of the MVC framework (views, controllers?) can migrate part of their functionality to AJAX. In analyzing this problem, we would be considering some server-side languages such as Java, PHP, and Ruby, as well as the .NET framework.''

__TOC__

=== What is MVC ? ===

[http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller '''Model–View–Controller (MVC)'''] is an architectural pattern used in software engineering. The pattern isolates business logic from input and presentation, permitting independent development, testing and maintenance of each.MVC is often seen in web applications where the view is the [http://en.wikipedia.org/wiki/Html HTML] or [http://en.wikipedia.org/wiki/Xhtml XHTML] generated by the app. The controller receives [http://en.wikipedia.org/wiki/HTTP#Request_methods GET] or [http://en.wikipedia.org/wiki/HTTP#Request_methods POST] input and decides what to do with it, handing over to domain objects (ie the model) which contain the business rules and know how to carry out specific tasks such as processing a new subscription.MVC helps to reduce the complexity in architectural design and to increase flexibility and reuse of code.

[[Image:ajaxandmvc.gif]]

=== What is AJAX ? ===
[http://en.wikipedia.org/wiki/AJAX AJAX] stands for Asynchronous JavaScript and [http://en.wikipedia.org/wiki/XML XML].It is a Web development technique for creating web applications. It Makes web pages more responsive by exchanging small amounts of data. It allows the web page to change its content without refreshing the whole page. A web browser technology is independent of web server software. It gives desktop application a feel good factor,by doing behind the scene server communication. A famous example: [http://www.google.com/support/websearch/bin/answer.py?hl=en&answer=106230 Google's suggest] uses Ajax, and it also helped in making it popular.

Advantages:

Improves the user experience in,

# Analyzing information typed into browser in real time
# Provide a richer experience
# Increases responsiveness of web pages

Improve bandwidth utilization

# Only data which is required is retrieved from the server

How does the magic work??
[[Image:Ajax_fig1.png|left]] [[Image:ajax_fig2.png|none]]
AJAX runs in your browser.
Works with asynchronous data transfers(HTTP requests) between the browser and the web server.
HTTP requests are sent by [http://en.wikipedia.org/wiki/JavaScript JavaScript] calls without having to submit a form.
XML is commonly used as the format for receiving server data but plain text and some other format may be used as well.
 
Instead of loading a web page, at the start of the session, the browser loads an Ajax engine — written in JavaScript and usually tucked away in a hidden frame. This engine is responsible for both rendering the interface the user sees and communicating with the server on the user’s behalf.
 The Ajax engine allows the user’s interaction with the application to happen asynchronously — independent of communication with the server. So the user is never staring at a blank browser window and an hourglass icon, waiting around for the server to do something. 
Every user action that normally would generate an HTTP request takes the form of a JavaScript call to the Ajax engine instead. Any response to a user action that doesn’t require a trip back to the server — such as simple data validation, editing data in memory, and even some navigation — the engine handles on its own. If the engine needs something from the server in order to respond — if it’s submitting data for processing, loading additional interface code, or retrieving new data — the engine makes those requests asynchronously, usually using XML, without stalling a user’s interaction with the application

 
Technologies used in AJAX.
# JavaScript - JavaScript is a loosely typed object based scripting language supported by all major browsers and essential for AJAX interactions. JavaScript functions in a page are invoked as event handlers when an event in a page occurs such as a page load, a mouse click, or a key press in a form element.
# DOM - is API for accessing and manipulating structured documents. In most cases DOM represent the structure of XML or HTML documents.
# CSS - Allows you to define the presentation of a page such as fonts, colors, sizes, and positioning. CSS allow for a clear separation of the style from the content and may be changed pragmatically by JavaScript.
# HTTP - Understanding the basic request/response interaction model of HTTP is important for a developer using AJAX. You will be
exposed to the GET and PUT method when configuring an [http://en.wikipedia.org/wiki/XMLHttpRequest XMLHttpRequest] and HTTP response codes when processing callback.

Some of the drawbacks:[http://en.wikipedia.org/wiki/Ajax_%28programming%29]
# AJAX interfaces are substantially harder to develop properly than static pages. 
# Pages dynamically created using successive AJAX requests do not automatically register themselves with the browser's history engine, so clicking the browser's "back" button may not return the user to an earlier state of the AJAX-enabled page, but may instead return them to the last full page visited before it. Workarounds include the use of invisible IFrames to trigger changes in the browser's history and changing the anchor portion of the URL (following a #) when AJAX is run and monitoring it for changes. 
# Dynamic web page updates also make it difficult for a user to bookmark a particular state of the application. Solutions to this problem exist, many of which use the URL fragment identifier (the portion of a URL after the '#') to keep track of, and allow users to return to, the application in a given state. 
# Because most web crawlers do not execute JavaScript code, publicly indexable web applications should provide an alternative means of accessing the content that would normally be retrieved with AJAX, to allow search engines to index it. 
# Any user whose browser does not support JavaScript or XMLHttpRequest, or simply has this functionality disabled, will not be able to properly use pages which depend on AJAX. Similarly, devices such as mobile phones, PDAs, and screen readers may not have support for the required technologies. Screen readers that are able to use AJAX may still not be able to properly read the dynamically generated content. The only way to let the user carry out functionality is to fall back to non-JavaScript methods. This can be achieved by making sure links and forms can be resolved properly and do not rely solely on AJAX. In JavaScript, form submission could then be halted with "return false". 
# The same origin policy prevents some AJAX techniques from being used across domains, although the W3C has a draft of the XMLHttpRequest object that would enable this functionality. 
# AJAX opens up another attack vector for malicious code that web developers might not fully test for. 
# AJAX-powered interfaces may dramatically increase the number of user-generated requests to web servers and their back-ends (databases, or other). This can lead to longer response times and/or additional hardware needs. 
# User interfaces can be confusing or behave inconsistently when normal web patterns are not followed. 
# Due to multiple dependent asynchronous requests, you can’t rely on any order of operations in classical AJAX models. 

=== How does AJAX fit with MVC ? ===
Ajax functionality needs to be implemented first in the view in terms of the call made and then in controller for handling the call . The view should have the call to the Ajax action which is implemented in controller.
MVC Controller needs to have a ajax-action class to take whatever action is required on the business model in model. Action methods can do things like render different views, render a portion of the user interface defined within a partial view as opposed to the full page. It can be consider that any behavioral JavaScript as part of the Controller, including attaching events as well as sending HTTP requests.
AJAX tag libraries [http://ajaxtags.sourceforge.net/] can be to fit ajax into any framework.
 
Moreover, there has been AJAX MVC[http://ajax-mvc.sourceforge.net/] used for much smoother integration of ajax into mvc framework.

=== AJAX IN RAILS ===

[http://en.wikipedia.org/wiki/Ruby_on_Rails Rails] provide support for AJAX in the form of helper methods. There is no need to add [http://en.wikipedia.org/wiki/JavaScript JavaScript] code in the view templates. Instead, the helper methods create the JavaScript code in the HTML page derived from the view templates. One of the ways this could be understood is through an example [http://onlamp.com/pub/a/onlamp/2005/06/09/rails_ajax.html] of link_to_remote() method which can be used to get the latest time from a server and display it on a web page.Here is a sample view template.

''' SERVER SIDE CODE '''
<pre>
<html>
<head>
<title>Ajax Demo</title>
<%= javascript_include_tag "prototype" %>
</head>
<body>
<h1>What time is it?</h1>
<div id="time_div">
I don't have the time, but
<%= link_to_remote( "click here",
:update => "time_div",
:url =>{ :action => :say_when }) %>
and I will look it up.
</div>
</body>
</html>

</pre>

What this view does this is that it gives a link to display the current time. The current time would be fetched in the background without refreshing the browser. Now, there are two main helper methods to do this job. One of them is javascript_include_tag() that includes the [http://en.wikipedia.org/wiki/Prototype_JavaScript_Framework Prototype JavaScript library]. This is included with Rails package and is a basic requirement to make use of AJAX functionality. The other is link_to_remote() call that talks to the remote server when a request for current time is made.
Here is a brief explanation of the parameters used in this method:

#'''click_here''' : this is the text for displaying the link
#'''time_div''' : it is the id of the HTML DOM element that would have the current time content
#'''url''' : refers to the server side action and it is say_when in this case

[[Image:ajaxinrails_fig1.png]] [[Image:ajaxinrails_fig2.png]]

The role of the index action is to render the index.html file which displays the ‘before’ view. The controller is named demo and is coded as,

''' SERVER SIDE CODE '''
<pre>
class DemoController < ApplicationController
def index
end

def say_when
render_text "The time is " + DateTime.now.to_s + ""
end
end
</pre>

When “click here” is clicked on we would see the ‘after’ view which is shown above. What happens over here is that when a user clicks on “click me” an [http://en.wikipedia.org/wiki/XMLHttpRequest XMLHttpRequest] is created by the browser and sent to the server where in the server invokes the say_when action and renders the HTML response fragment containing the current time. When the client side JavaScript receives the response it replaces the contents of the div with an id of time_div.Besides the above example, there are other AJAX helper methods like the form method, i.e., form_remote_tag(). Here, is a prototype for it.

<pre>
<%= form_remote_tag :url => { :action => 'create' },
:update => ‘ajax_result’ %>
<%= render :partial => ‘form’ %>
<%= submit_tag "Create" %>
<%= end_form_tag %>

<div id="ajax_result"></div>
</pre>

Ajax in Ruby has immense potential in its application and can add to the efficiency as well as to the looks of a web template. In order to get a more in depth foot in Ajax on Rails , there is a very popular book [http://oreilly.com/catalog/9780596527440 “Ajax on Rails”] by Scott Raymond and published by O’Reilly.

=== AJAX IN PHP ===

[http://en.wikipedia.org/wiki/PHP PHP] supports [http://en.wikipedia.org/wiki/JSON JSON] encoding by default, this allows you to pass complex data types back and forth between PHP and Javascript fairly easily.Consider this simple example.[http://www.ajaxf1.com/tutorial/ajax-php.html?page=2]

To demonstrate the AJAX PHP connection we will create a very simple form with 2 input fields. In the first field you can type any text and we will send this text to our PHP script which will convert it to uppercase and sends it back to us. 
[[Image:Ajax-mvc-php.PNG ]]

''' CLIENT SIDE CODE '''
<pre>
<script>
// Get the HTTP Object
function getHTTPObject(){
if (window.ActiveXObject)
return new ActiveXObject("Microsoft.XMLHTTP");
else if (window.XMLHttpRequest)//catches the response from the server
return new XMLHttpRequest();//this object is for AJAX PHP communication
else {
alert("Your browser does not support AJAX.");
return null;
}
}

// Change the value of the outputText field
function setOutput(){
if(httpObject.readyState == 4){
document.getElementById('outputText').value = httpObject.responseText;
}

}

// Implement business logic
function doWork(){
httpObject = getHTTPObject();
if (httpObject != null) {
httpObject.open("GET", "upperCase.php?inputText="
+document.getElementById('inputText').value, true);
httpObject.send(null);
httpObject.onreadystatechange = setOutput;
}
}
</script>

<form name="testForm">
Input text: <input type="text" onkeyup="doWork();" name="inputText" id="inputText" />
Output text: <input type="text" name="outputText" id="outputText" />
</form>
</pre>

''' SERVER SIDE CODE '''

Server side functionality is very simple compared to the client side. In the PHP code we just need to check the $_GET super-global array. Afterwards convert it to uppercase and echo the result.

<pre>
<?php
if (isset($_GET['inputText']))
echo strtoupper($_GET['inputText']);
?>
</pre>

=== AJAX IN .NET Framework ===

[http://en.wikipedia.org/wiki/ASP.NET ASP.NET] AJAX is the free Microsoft AJAX framework for building highly interactive and responsive web applications that work across all popular browsers. The ASP.NET AJAX framework includes Server-Side ASP.NET AJAX, Client-Side ASP.NET AJAX, the AJAX Control Toolkit, and the [http://en.wikipedia.org/wiki/JQuery jQuery] library. ASP.NET AJAX enables developers to choose their preferred method of AJAX development, whether it is server-side programming, client-side programming, or a combination of both.ASP.NET AJAX server-side controls such as the ScriptManager, UpdatePanel, and the UpdateProgress control to add AJAX functionality to an ASP.NET application without writing any JavaScript. For example, the UpdatePanel control enables you to update a portion of an ASP.NET page without requiring you to reload the entire page. The ScriptManager control enables you to manage browser history in an AJAX application by updating the browser back button after an AJAX request.

If you prefer to work directly with JavaScript then you can take advantage of client-side ASP.NET AJAX. The client-side ASP.NET AJAX Library provides a foundation for building rich client-side applications. The library simplifies cross-browser development of client-side applications. For example, the library enables you to call web services and create components and controls -- all through pure client-side JavaScript code.

One cool thing: AJAX Extensions for .NET
No need to modify server-side code
No javascript functions need to be added
AJAX can be enabled/disabled by changing one line of code (“Script Manager”)
Its as simple as 1 2 3 :)
# “Drag and Drop” Script Manager Control onto your form
# Place “Update Panels” around content you wish to have async updates for
# Add triggers to the update panels to tell them which events to update on.

=== AJAX IN JAVA ===

[http://en.wikipedia.org/wiki/Java Java] technology and AJAX work well together. Java technology provides the server-side processing for AJAX interactions. It can provide this through servlets, [http://en.wikipedia.org/wiki/JavaServer_Pages JavaServer Pages (JSP)] technology, [http://en.wikipedia.org/wiki/JavaServer_Faces JavaServer Faces (JSF)] technology, and web services. The programming model for handling AJAX requests uses the same APIs that you would use for conventional web applications. JSF technology can be used to create reusable components that generate the client-side JavaScript and corresponding server-side AJAX processing code.

Consider a simple example [http://java.sun.com/developer/technicalArticles/J2EE/AJAX/index.html] where AJAX and java servlets interact.HTML page generated in JSP technology contains an HTML form that requires server-side logic to validate form data without refreshing the page. A server-side web component (servlet) named ValidateServlet will provide the validation logic.

[[Image:railsinjava_fig1.png]]

Ajax interaction as they appear in Figure:
# A client event occurs.[http://java.sun.com/developer/technicalArticles/J2EE/AJAX/index.html#event_occurs]
# An XMLHttpRequest object is created and configured. [http://java.sun.com/developer/technicalArticles/J2EE/AJAX/index.html#configure_xmlhttprequest]
# The XMLHttpRequest object makes a call.[http://java.sun.com/developer/technicalArticles/J2EE/AJAX/index.html#make_call]
# The request is processed by the ValidateServlet.[http://java.sun.com/developer/technicalArticles/J2EE/AJAX/index.html#serverside_processing]
# The ValidateServlet returns an XML document containing the result.[http://java.sun.com/developer/technicalArticles/J2EE/AJAX/index.html#xml_returned]
# The XMLHttpRequest object calls the callback() function and processes the result.[http://java.sun.com/developer/technicalArticles/J2EE/AJAX/index.html#post_process]
# The HTML DOM is updated.[http://java.sun.com/developer/technicalArticles/J2EE/AJAX/index.html#update_dom]

=== Conclusion ===

[http://en.wikipedia.org/wiki/Rich_Internet_application Rich Internet applications (RIA)] are web application that approximate the look and feel and usability of desktop application. It adds performance and rich GUI. AJAX enables RIA, which uses client-side scripting to make web applications more responsive. Ajax application separates client-side user interaction and server communication, and run them in parallel, reducing the delays of server-side processing normally experienced by user.

MVC frameworks in various languages like PHP, Rails, .NET etc provides well defined support to implement AJAX functionality. This article provided a brief overview of this support in Java, .NET, Rails and PHP.

=== References ===

* http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller

* http://en.wikipedia.org/wiki/Ajax_%28programming%29

* http://www.ajaxf1.com/tutorial/ajax-php.html?page=2

* http://www.asp.net/ajax/

* http://java.sun.com/developer/technicalArticles/J2EE/AJAX/index.html

* http://www.phpied.com/ajax-mvc/

* http://www.php.net/

CSC/ECE 517 Fall 2009/wiki1a 1 JunitTest

2009-09-08T19:05:21Z

Wolverine: /* For Overview */

'''Writing Effective JUnit Test Cases''' 
----

''JUnit is a testing framework aimed at making unit testing easy by simplifying the writing of test cases and by providing automated running of tests and test suites.''

The objective of this document is to provide a repository of rules that can be used in-order to write an effective Junit test.
This doc also discusses various sites and suggest which are the best sites to read for an overview of the topic and to understand the different philosophies of test-case design.

==Introduction==

=== Unit Testing Overview ===

The primary goal of unit testing is to take the smallest piece of testable software in the application, isolate it from the remainder of the code, and determine whether it behaves exactly as you expect.

'''Test Case''' 
It describes a scenario that can be exercised through the application. 
Each test case is divided into two parts: input and expected output. 
The input part lists all the test case statements that create variables or assign values to variables. 
The expected output part indicates the expected results; it shows either assertions or the message 'no exception' (when no assertions exist). 

The main issue in constructing a unit test is deciding the scope of test cases. 
If the scope is too narrow, then the tests will be trivial and the objects might pass the tests, but there will be no design of their interactions and interactions of objects are important for object oriented design. 
On the other hand if the scope is too broad, then there is a high chance that not every component of the new code will get tested. 
The programmer is then reduced to testing-by-poking-around, which is not an effective test strategy. 

=== JUnit Overview ===
Non-automated testing is usually like this: 
* An expression is used in a debugger, you can change debug expressions without recompiling, and you can wait to decide what to write until you have seen the running objects. 
* Expressions are tested as statements which print to the standard output stream. 
But its not preferred because: 
* They require human judgment to analyze their results. 
* They are cumbersome, non repeatable - you can only execute one debug expression at a time and a program with too many print statements causes the dreaded "Scroll Blindness". 
On the upper hand, JUnit tests, which uses the automated framework does not require human judgment to interpret, and it is easy to run many of them at the same time.
 
When you need to test something, here is what you do: 
* Annotate a method with @org.junit.Test 
* When you want to check a value, import org.junit.Assert.* statically, call assertTrue() and pass a boolean that is true if the test succeeds 
'''So what exactly is JUnit ?? ''' 
It is a open-source unit testing framework for Java and provides a way to organize test data and perform repeatable test execution. 
In JUnit, one has to write Java code, called a test class, that describes test data, invokes the methods to be tested, and determines test results. 
JUnit was originally written by Erich Gamma and Kent Beck. 
The official JUnit home page is http://junit.org. 
JUnit is Open Source Software, released under IBM's Common Public License Version 0.5 and hosted on SourceForge. 
It is an instance of the xUnit architecture for unit testing frameworks. JUnit features include: 
* Assertions for testing expected results 
* Test fixtures for sharing common test data 
* Test runners for running tests 
'''JUnit mailing lists and forums''' 
[http://groups.yahoo.com/group/junit/ JUnit user list] 
[http://lists.sourceforge.net/lists/listinfo/junit-announce JUnit announcements] 
[http://lists.sourceforge.net/lists/listinfo/junit-devel JUnit developer list] 
'''JUnit official documentation''' 
[http://junit.sourceforge.net/doc/testinfected/testing.htm JUnit Test Infected: Programmers Love Writing Tests] 
[http://junit.sourceforge.net/doc/cookbook/cookbook.htm JUnit Cookbook] 
[http://junit.sourceforge.net/doc/cookstour/cookstour.htm JUnit - A Cook's Tour] 
[http://junit.sourceforge.net/doc/faq/faq.htm JUnit FAQ] 
Although JUnit testing costs some time and money, but unit testing provides some crucial advantages, viz: 
Automation of the testing process 
Reduces difficulties of discovering errors contained in more complex pieces of the application 
Test coverage is often enhanced because attention is given to each unit. 
For example, 
if you have two units and decide it would be more cost effective to glue them together and initially test them as an integrated unit, an error could occur in a variety of places, now: 
* Is the error due to a defect in unit 1? 
* Is the error due to a defect in unit 2? 
* Is the error due to defects in both units? 
* Is the error due to a defect in the interface between the units? 
* Is the error due to a defect in the test? 
Finding the error (or errors) in the integrated module is much more complicated than first isolating the units, testing each, then integrating them and testing the whole. 
 

== Websites to lookout ==
These are some of the best webpages which will help you in getting more description as well as details about Junit.
 Also it will help you understand the test case design philosophy. 
=== For Overview ===
* Junit testing basics: 
http://articles.techrepublic.com.com/5100-10878_11-1027676.html

* Basics of Junit: 
http://junit.sourceforge.net/doc/cookbook/cookbook.htm
http://junit.sourceforge.net/doc/faq/faq.htm#overview
 

=== For Ideas on test case design ===
* For successful test automation: 
http://www.io.com/~wazmo/papers/seven_steps.html

* Unit testing principles: 
http://www.acm.org/ubiquity/views/t_burns_1.html

* For test suite effectiveness: 
http://java.sys-con.com/node/299945
 
 

== How to get started ==
=== Step 1: Installing JUnit ===

* Download latest version of JUnit from "http://sourceforge.net/projects/junit/files/". 
* Then install JUnit on your platform of choice: 
Windows 
To install JUnit on Windows, follow these steps: 
* Unzip the junit.zip distribution file to a directory referred to as %JUNIT_HOME%. 
* Add JUnit to the classpath: 
<pre>set CLASSPATH=%JUNIT_HOME%\junit.jar</pre>
'''Unix (bash)''' 
To install JUnit on Unix, follow these steps: 
* Unzip the junit.zip distribution file to a directory referred to as $JUNIT_HOME. 
* Add JUnit to the classpath: 
<pre>export CLASSPATH=$JUNIT_HOME/junit.jar</pre>
 

=== Step 2: Writing a Test Case ===
To write a test case, follow these steps: 

* Implement a class derived from TestCase, a base class provided by JUnit. 
public class BooksCartTest extends TestCase
* Be sure the test class belongs to the same package as that of the unit you wish to test 
* Override the setUp() method to initialize object(s) under test. 
* Optionally override the tearDown() method to release object(s) under test. 
* Define one or more public testXXX() methods that exercise the object(s) under test and assert expected results. 
The following is an example test case: 
<pre>
import junit.framework.TestCase;

public class BooksCartTest extends TestCase {

private BooksCart cart1;
private BooksCart cart2;

/**
* Sets up the test fixture.
*
* Called before every test case method.
*/
protected void setUp() {

cart1 = new BooksCart(6,8);
cart2 = new BooksCart(7,10);
}

/**
* Tears down the test fixture.
*
* Called after every test case method.
*/
protected void tearDown() {
// release objects under test here, if necessary
}

/**
* Tests emptying the cart.
*/
public void testEmpty() {

cart1.empty();
cart2.empty();
assertEquals(cart1, new BooksCart(3, 9));
assertTrue(!cart2.equals(cart1));
}
}
</pre>
Methods used in JUnit: 
* An assert method is a JUnit method that performs a test, and throws an AssertionFailedError if the test fails 
* static void assertTrue(boolean test) 
static void assertTrue(String message, boolean test)
- Throws an AssertionFailedError if the test fails 
- The optional message is included in the Error 
* static void assertFalse(boolean test) 
static void assertFalse(String message, boolean test)
- Throws an AssertionFailedError if the test fails 
 

=== Step 3: Writing a Test Suite ===
Next, we'll write a test suite that includes several test cases. The test suite will allow us to run all of its test cases in one fell swoop. 
'''To write a test suite, follow these steps:''' 
* Write a Java class that defines a static suite() factory method that creates a TestSuite containing all the tests. 
* Optionally define a main() method that runs the TestSuite in batch mode. 

The following is an example test suite: 
<pre>
import junit.framework.Test;
import junit.framework.TestSuite;

public class BooksCartTestSuite {

public static Test suite() {

TestSuite suite = new TestSuite();

//
// The BooksCartTest we created above.
//
suite.addTestSuite(BooksCartTest.class);

//
// Another example test suite of tests.
//
suite.addTest(CreditCardTestSuite.suite());

//
// Add more tests here
//

return suite;
}

/**
* Runs the test suite using the textual runner.
*/
public static void main(String[] args) {
junit.textui.TestRunner.run(suite());
}
}
</pre>
 

=== Step 4: Running the Test ===
Now that we've written a test suite containing a collection of test cases and other test suites, we can run either the test suite or any of its test cases individually. Running a TestSuite will automatically run all of its subordinate TestCase instances and TestSuite instances. Running a TestCase will automatically invoke all of its public testXXX() methods.
JUnit provides both a textual and a graphical user interface. Both user interfaces indicate how many tests were run, any errors or failures, and a simple completion status. The simplicity of the user interfaces is the key to running tests quickly. You should be able to run your tests and know the test status with a glance, much like you do with a compiler.
To run our test case using the textual user interface, use: 
<pre>java junit.textui.TestRunner BooksCartTest </pre>
The textual user interface displays "OK" if all the tests passed and failure messages if any of the tests failed. 
To run the test case using the graphical user interface, use: 
<pre>java junit.swingui.TestRunner BooksCartTest </pre>
The graphical user interface displays a Swing window with a green progress bar if all the tests passed or a red progress bar if any of the tests failed. 
The BooksCartTest Suite can be run similarly: 
<pre>java junit.swingui.TestRunner BooksCartTestSuite</pre>
 

== Rules for designing effective JUnit Test cases ==
* Identify and assemble a list of all the actions that your program should be able to perform. use cases,nonfunctional requirements specifications, test case specifications, user interface design documents, mockups, user profiles, and various additional artifacts.
* Identify the code's entry points - central pieces of code that exercise the functionality that the code as a whole is designed to undertake.
* Pair entry points with the use cases that they implement.
* Create test cases by applying the initialize/work/check procedure.
** Initialize: Create the environment that the test expects to run in. The initialization code can either be in the beginning of the test or in the setUp() method.
** Work: Call the code that is being tested, capturing any interesting output and recording any interesting statistics.
** Check: Use assert statements to ensure that the code worked as expected.
* Develop runtime event diagrams and use them to facilitate testing.
* Follow KISS rule:It's a bad idea to keep the input source name and expression in the test case. Some items (server names, usernames and passwords, etc.) should not live in the test files, which should be configurable for the specific deployment. Rather, design the test cases to facilitate separation of test drivers and test data, test driver reuse over a larger set of data, and test data reuse over a larger set of test drivers. On the other hand, don't over-architect a simple test case implementation. Typically, the test case specification already defines most of the system states and allows parameter descriptions for a scenario, so there's no point in making everything parameterizable in the test implementation.
 

==Rules for coding effective JUnit Tests==

=== Using Test Fixture for a common set of objects ===
Using a test fixture avoids duplicating the code necessary to initialize (and cleanup) the common objects.
Tests can use the objects (variables) in a test fixture, with each test invoking different methods on objects in the fixture and asserting different expected results. Each test runs in its own test fixture to isolate tests from the changes made by other tests. That is, tests don't share the state of objects in the test fixture. Because the tests are isolated, they can be run in any order.
To create a test fixture, declare instance variables for the common objects. Initialize these objects in a public void method annotated with @Before. The JUnit framework automatically invokes any @Before methods before each test is run.
The following example shows a test fixture with a common Collection object.
<pre>
package junitfaq;

import org.junit.*;
import static org.junit.Assert.*;
import java.util.*;

public class SimpleTest {

private Collection<Object> collection;

@Before
public void setUp() {
collection = new ArrayList<Object>();
}

@Test
public void testEmptyCollection() {
assertTrue(collection.isEmpty());
}

@Test
public void testOneItemCollection() {
collection.add("itemA");
assertEquals(1, collection.size());
}
}
</pre>
Given this test, the methods might execute in the following order: 
setUp() 
testEmptyCollection() 
setUp() 
testOneItemCollection() 
The ordering of test-method invocations is not guaranteed, so testOneItemCollection() might be executed before testEmptyCollection(). But it doesn't matter, because each method gets its own instance of the collection.
Although JUnit provides a new instance of the fixture objects for each test method, if you allocate any external resources in a @Before method, you should release them after the test runs by annotating a method with @After. The JUnit framework automatically invokes any @After methods after each test is run. For example:
<pre>
package junitfaq;

import org.junit.*;
import static org.junit.Assert.*;
import java.io.*;

public class OutputTest {

private File output;

@Before
public void createOutputFile() {
output = new File(...);
}

@After
public void deleteOutputFile() {
output.delete();
}

@Test
public void testSomethingWithFile() {
...
}
}
</pre>
With this test, the methods will execute in the following order:

* createOutputFile()
* testSomethingWithFile()
* deleteOutputFile()
 

=== To Test a method that doesnot return anything ===
If a method doesn't return a value, it might have some side effect. Actually, if it doesn't return a value AND doesn't have a side effect, it isn't doing anything.
There may be a way to verify that the side effect actually occurred as expected. For example, consider the add() method in the Collection classes. There are ways of verifying that the side effect happened (i.e. the object was added). You can check the size and assert that it is what is expected:

<pre>
public void testCollectionAdd() {
Collection collection = new ArrayList();
assertEquals(0, collection.size());
collection.add("itemA");
assertEquals(1, collection.size());
collection.add("itemB");
assertEquals(2, collection.size());
}
</pre>
 

=== To test an expected/unexpected exception ===
* Case of expected exception
Add the optional expected attribute to the @Test annotation. The following is an example test that passes when the expected IndexOutOfBoundsException is raised:
<pre>
@Test(expected=IndexOutOfBoundsException.class)
public void testIndexOutOfBoundsException() {
ArrayList emptyList = new ArrayList();
Object o = emptyList.get(0);
}
</pre>
* Case of unexpected exception
Declare the exception in the throws clause of the test method and don't catch the exception within the test method. Uncaught exceptions will cause the test to fail with an error.
The following is an example test that fails when the IndexOutOfBoundsException is raised:
<pre>
@Test
public void testIndexOutOfBoundsExceptionNotRaised()
throws IndexOutOfBoundsException {

ArrayList emptyList = new ArrayList();
Object o = emptyList.get(0);
}
</pre>
 

=== To Test protected/private methods ===
* Case for protected methods
Place your tests in the same package as the classes under test.
* Case for private methods
Testing private methods may be an indication that those methods should be moved into another class to promote reusability.
 

=== Conditions to test get() and set() methods ===
Unit tests are intended to alleviate fear that something might break. If you think a get() or set() method could reasonably break, or has in fact contributed to a defect, then by all means write a test.
In short, test until you're confident. What you choose to test is subjective, based on your experiences and confidence level. Remember to be practical and maximize your testing investment.
 

=== To run setUp() and tearDown() code once for all tests ===

You can add a @BeforeClass annotation to a method to be run before all the tests in a class, and a @AfterClass annotation to a method to be run after all the tests in a class. Here's an example:

<pre>
package junitfaq;

import org.junit.*;
import static org.junit.Assert.*;
import java.util.*;

public class SimpleTest {

private Collection collection;

@BeforeClass
public static void oneTimeSetUp() {
// one-time initialization code
}

@AfterClass
public static void oneTimeTearDown() {
// one-time cleanup code
}

@Before
public void setUp() {
collection = new ArrayList();
}

@After
public void tearDown() {
collection.clear();
}

@Test
public void testEmptyCollection() {
assertTrue(collection.isEmpty());
}

@Test
public void testOneItemCollection() {
collection.add("itemA");
assertEquals(1, collection.size());
}
}
</pre>
Given this test, the methods will execute in the following order:

*oneTimeSetUp()
*setUp()
*testEmptyCollection()
*tearDown()
*setUp()
*testOneItemCollection()
*tearDown()
*oneTimeTearDown()
 

==Conclusion==
By following the guidelines given in this articles, one can write a good unit test using junit, which is as important as writing good quality code. 
A good quality unit test will take care of all classes, boundary conditions, domain data and functionality. 
A good test can be creative to explore all possibilities, thinking out of box. 
Finally automating the test using tool like junit which is in the native java language itself helps in saving manual intervention and time/money. 

==References==

* http://articles.techrepublic.com.com/5100-10878_11-1027676.html
* http://msdn.microsoft.com/en-us/library/aa292197%28VS.71%29.asp
* http://junit.sourceforge.net/doc/cookbook/cookbook.htm
* http://junit.sourceforge.net/doc/faq/faq.htm#overview
* http://clarkware.com/articles/JUnitPrimer.html#usage
* http://users.csc.calpoly.edu/~jdalbey/205/Resources/junitQuickStart.html
* http://www.cis.upenn.edu/~matuszek/cit591-2004/Lectures/
* http://en.wikipedia.org/wiki/JUnit
* http://www.laliluna.de/eclipse-junit-testing-tutorial.html
* http://junit.sourceforge.net/doc/faq/faq.htm

-------------------------------------------------------

CSC/ECE 517 Fall 2009/wiki1a 1 JunitTest

2009-09-08T19:05:12Z

Wolverine: /* For Ideas on test case design */

'''Writing Effective JUnit Test Cases''' 
----

''JUnit is a testing framework aimed at making unit testing easy by simplifying the writing of test cases and by providing automated running of tests and test suites.''

The objective of this document is to provide a repository of rules that can be used in-order to write an effective Junit test.
This doc also discusses various sites and suggest which are the best sites to read for an overview of the topic and to understand the different philosophies of test-case design.

==Introduction==

=== Unit Testing Overview ===

The primary goal of unit testing is to take the smallest piece of testable software in the application, isolate it from the remainder of the code, and determine whether it behaves exactly as you expect.

'''Test Case''' 
It describes a scenario that can be exercised through the application. 
Each test case is divided into two parts: input and expected output. 
The input part lists all the test case statements that create variables or assign values to variables. 
The expected output part indicates the expected results; it shows either assertions or the message 'no exception' (when no assertions exist). 

The main issue in constructing a unit test is deciding the scope of test cases. 
If the scope is too narrow, then the tests will be trivial and the objects might pass the tests, but there will be no design of their interactions and interactions of objects are important for object oriented design. 
On the other hand if the scope is too broad, then there is a high chance that not every component of the new code will get tested. 
The programmer is then reduced to testing-by-poking-around, which is not an effective test strategy. 

=== JUnit Overview ===
Non-automated testing is usually like this: 
* An expression is used in a debugger, you can change debug expressions without recompiling, and you can wait to decide what to write until you have seen the running objects. 
* Expressions are tested as statements which print to the standard output stream. 
But its not preferred because: 
* They require human judgment to analyze their results. 
* They are cumbersome, non repeatable - you can only execute one debug expression at a time and a program with too many print statements causes the dreaded "Scroll Blindness". 
On the upper hand, JUnit tests, which uses the automated framework does not require human judgment to interpret, and it is easy to run many of them at the same time.
 
When you need to test something, here is what you do: 
* Annotate a method with @org.junit.Test 
* When you want to check a value, import org.junit.Assert.* statically, call assertTrue() and pass a boolean that is true if the test succeeds 
'''So what exactly is JUnit ?? ''' 
It is a open-source unit testing framework for Java and provides a way to organize test data and perform repeatable test execution. 
In JUnit, one has to write Java code, called a test class, that describes test data, invokes the methods to be tested, and determines test results. 
JUnit was originally written by Erich Gamma and Kent Beck. 
The official JUnit home page is http://junit.org. 
JUnit is Open Source Software, released under IBM's Common Public License Version 0.5 and hosted on SourceForge. 
It is an instance of the xUnit architecture for unit testing frameworks. JUnit features include: 
* Assertions for testing expected results 
* Test fixtures for sharing common test data 
* Test runners for running tests 
'''JUnit mailing lists and forums''' 
[http://groups.yahoo.com/group/junit/ JUnit user list] 
[http://lists.sourceforge.net/lists/listinfo/junit-announce JUnit announcements] 
[http://lists.sourceforge.net/lists/listinfo/junit-devel JUnit developer list] 
'''JUnit official documentation''' 
[http://junit.sourceforge.net/doc/testinfected/testing.htm JUnit Test Infected: Programmers Love Writing Tests] 
[http://junit.sourceforge.net/doc/cookbook/cookbook.htm JUnit Cookbook] 
[http://junit.sourceforge.net/doc/cookstour/cookstour.htm JUnit - A Cook's Tour] 
[http://junit.sourceforge.net/doc/faq/faq.htm JUnit FAQ] 
Although JUnit testing costs some time and money, but unit testing provides some crucial advantages, viz: 
Automation of the testing process 
Reduces difficulties of discovering errors contained in more complex pieces of the application 
Test coverage is often enhanced because attention is given to each unit. 
For example, 
if you have two units and decide it would be more cost effective to glue them together and initially test them as an integrated unit, an error could occur in a variety of places, now: 
* Is the error due to a defect in unit 1? 
* Is the error due to a defect in unit 2? 
* Is the error due to defects in both units? 
* Is the error due to a defect in the interface between the units? 
* Is the error due to a defect in the test? 
Finding the error (or errors) in the integrated module is much more complicated than first isolating the units, testing each, then integrating them and testing the whole. 
 

== Websites to lookout ==
These are some of the best webpages which will help you in getting more description as well as details about Junit.
 Also it will help you understand the test case design philosophy. 
=== For Overview ===
* Junit testing basics: 
http://articles.techrepublic.com.com/5100-10878_11-1027676.html

* Basics of Junit: 
http://junit.sourceforge.net/doc/cookbook/cookbook.htm
http://junit.sourceforge.net/doc/faq/faq.htm#overview

=== For Ideas on test case design ===
* For successful test automation: 
http://www.io.com/~wazmo/papers/seven_steps.html

* Unit testing principles: 
http://www.acm.org/ubiquity/views/t_burns_1.html

* For test suite effectiveness: 
http://java.sys-con.com/node/299945
 
 

== How to get started ==
=== Step 1: Installing JUnit ===

* Download latest version of JUnit from "http://sourceforge.net/projects/junit/files/". 
* Then install JUnit on your platform of choice: 
Windows 
To install JUnit on Windows, follow these steps: 
* Unzip the junit.zip distribution file to a directory referred to as %JUNIT_HOME%. 
* Add JUnit to the classpath: 
<pre>set CLASSPATH=%JUNIT_HOME%\junit.jar</pre>
'''Unix (bash)''' 
To install JUnit on Unix, follow these steps: 
* Unzip the junit.zip distribution file to a directory referred to as $JUNIT_HOME. 
* Add JUnit to the classpath: 
<pre>export CLASSPATH=$JUNIT_HOME/junit.jar</pre>
 

=== Step 2: Writing a Test Case ===
To write a test case, follow these steps: 

* Implement a class derived from TestCase, a base class provided by JUnit. 
public class BooksCartTest extends TestCase
* Be sure the test class belongs to the same package as that of the unit you wish to test 
* Override the setUp() method to initialize object(s) under test. 
* Optionally override the tearDown() method to release object(s) under test. 
* Define one or more public testXXX() methods that exercise the object(s) under test and assert expected results. 
The following is an example test case: 
<pre>
import junit.framework.TestCase;

public class BooksCartTest extends TestCase {

private BooksCart cart1;
private BooksCart cart2;

/**
* Sets up the test fixture.
*
* Called before every test case method.
*/
protected void setUp() {

cart1 = new BooksCart(6,8);
cart2 = new BooksCart(7,10);
}

/**
* Tears down the test fixture.
*
* Called after every test case method.
*/
protected void tearDown() {
// release objects under test here, if necessary
}

/**
* Tests emptying the cart.
*/
public void testEmpty() {

cart1.empty();
cart2.empty();
assertEquals(cart1, new BooksCart(3, 9));
assertTrue(!cart2.equals(cart1));
}
}
</pre>
Methods used in JUnit: 
* An assert method is a JUnit method that performs a test, and throws an AssertionFailedError if the test fails 
* static void assertTrue(boolean test) 
static void assertTrue(String message, boolean test)
- Throws an AssertionFailedError if the test fails 
- The optional message is included in the Error 
* static void assertFalse(boolean test) 
static void assertFalse(String message, boolean test)
- Throws an AssertionFailedError if the test fails 
 

=== Step 3: Writing a Test Suite ===
Next, we'll write a test suite that includes several test cases. The test suite will allow us to run all of its test cases in one fell swoop. 
'''To write a test suite, follow these steps:''' 
* Write a Java class that defines a static suite() factory method that creates a TestSuite containing all the tests. 
* Optionally define a main() method that runs the TestSuite in batch mode. 

The following is an example test suite: 
<pre>
import junit.framework.Test;
import junit.framework.TestSuite;

public class BooksCartTestSuite {

public static Test suite() {

TestSuite suite = new TestSuite();

//
// The BooksCartTest we created above.
//
suite.addTestSuite(BooksCartTest.class);

//
// Another example test suite of tests.
//
suite.addTest(CreditCardTestSuite.suite());

//
// Add more tests here
//

return suite;
}

/**
* Runs the test suite using the textual runner.
*/
public static void main(String[] args) {
junit.textui.TestRunner.run(suite());
}
}
</pre>
 

=== Step 4: Running the Test ===
Now that we've written a test suite containing a collection of test cases and other test suites, we can run either the test suite or any of its test cases individually. Running a TestSuite will automatically run all of its subordinate TestCase instances and TestSuite instances. Running a TestCase will automatically invoke all of its public testXXX() methods.
JUnit provides both a textual and a graphical user interface. Both user interfaces indicate how many tests were run, any errors or failures, and a simple completion status. The simplicity of the user interfaces is the key to running tests quickly. You should be able to run your tests and know the test status with a glance, much like you do with a compiler.
To run our test case using the textual user interface, use: 
<pre>java junit.textui.TestRunner BooksCartTest </pre>
The textual user interface displays "OK" if all the tests passed and failure messages if any of the tests failed. 
To run the test case using the graphical user interface, use: 
<pre>java junit.swingui.TestRunner BooksCartTest </pre>
The graphical user interface displays a Swing window with a green progress bar if all the tests passed or a red progress bar if any of the tests failed. 
The BooksCartTest Suite can be run similarly: 
<pre>java junit.swingui.TestRunner BooksCartTestSuite</pre>
 

== Rules for designing effective JUnit Test cases ==
* Identify and assemble a list of all the actions that your program should be able to perform. use cases,nonfunctional requirements specifications, test case specifications, user interface design documents, mockups, user profiles, and various additional artifacts.
* Identify the code's entry points - central pieces of code that exercise the functionality that the code as a whole is designed to undertake.
* Pair entry points with the use cases that they implement.
* Create test cases by applying the initialize/work/check procedure.
** Initialize: Create the environment that the test expects to run in. The initialization code can either be in the beginning of the test or in the setUp() method.
** Work: Call the code that is being tested, capturing any interesting output and recording any interesting statistics.
** Check: Use assert statements to ensure that the code worked as expected.
* Develop runtime event diagrams and use them to facilitate testing.
* Follow KISS rule:It's a bad idea to keep the input source name and expression in the test case. Some items (server names, usernames and passwords, etc.) should not live in the test files, which should be configurable for the specific deployment. Rather, design the test cases to facilitate separation of test drivers and test data, test driver reuse over a larger set of data, and test data reuse over a larger set of test drivers. On the other hand, don't over-architect a simple test case implementation. Typically, the test case specification already defines most of the system states and allows parameter descriptions for a scenario, so there's no point in making everything parameterizable in the test implementation.
 

==Rules for coding effective JUnit Tests==

=== Using Test Fixture for a common set of objects ===
Using a test fixture avoids duplicating the code necessary to initialize (and cleanup) the common objects.
Tests can use the objects (variables) in a test fixture, with each test invoking different methods on objects in the fixture and asserting different expected results. Each test runs in its own test fixture to isolate tests from the changes made by other tests. That is, tests don't share the state of objects in the test fixture. Because the tests are isolated, they can be run in any order.
To create a test fixture, declare instance variables for the common objects. Initialize these objects in a public void method annotated with @Before. The JUnit framework automatically invokes any @Before methods before each test is run.
The following example shows a test fixture with a common Collection object.
<pre>
package junitfaq;

import org.junit.*;
import static org.junit.Assert.*;
import java.util.*;

public class SimpleTest {

private Collection<Object> collection;

@Before
public void setUp() {
collection = new ArrayList<Object>();
}

@Test
public void testEmptyCollection() {
assertTrue(collection.isEmpty());
}

@Test
public void testOneItemCollection() {
collection.add("itemA");
assertEquals(1, collection.size());
}
}
</pre>
Given this test, the methods might execute in the following order: 
setUp() 
testEmptyCollection() 
setUp() 
testOneItemCollection() 
The ordering of test-method invocations is not guaranteed, so testOneItemCollection() might be executed before testEmptyCollection(). But it doesn't matter, because each method gets its own instance of the collection.
Although JUnit provides a new instance of the fixture objects for each test method, if you allocate any external resources in a @Before method, you should release them after the test runs by annotating a method with @After. The JUnit framework automatically invokes any @After methods after each test is run. For example:
<pre>
package junitfaq;

import org.junit.*;
import static org.junit.Assert.*;
import java.io.*;

public class OutputTest {

private File output;

@Before
public void createOutputFile() {
output = new File(...);
}

@After
public void deleteOutputFile() {
output.delete();
}

@Test
public void testSomethingWithFile() {
...
}
}
</pre>
With this test, the methods will execute in the following order:

* createOutputFile()
* testSomethingWithFile()
* deleteOutputFile()
 

=== To Test a method that doesnot return anything ===
If a method doesn't return a value, it might have some side effect. Actually, if it doesn't return a value AND doesn't have a side effect, it isn't doing anything.
There may be a way to verify that the side effect actually occurred as expected. For example, consider the add() method in the Collection classes. There are ways of verifying that the side effect happened (i.e. the object was added). You can check the size and assert that it is what is expected:

<pre>
public void testCollectionAdd() {
Collection collection = new ArrayList();
assertEquals(0, collection.size());
collection.add("itemA");
assertEquals(1, collection.size());
collection.add("itemB");
assertEquals(2, collection.size());
}
</pre>
 

=== To test an expected/unexpected exception ===
* Case of expected exception
Add the optional expected attribute to the @Test annotation. The following is an example test that passes when the expected IndexOutOfBoundsException is raised:
<pre>
@Test(expected=IndexOutOfBoundsException.class)
public void testIndexOutOfBoundsException() {
ArrayList emptyList = new ArrayList();
Object o = emptyList.get(0);
}
</pre>
* Case of unexpected exception
Declare the exception in the throws clause of the test method and don't catch the exception within the test method. Uncaught exceptions will cause the test to fail with an error.
The following is an example test that fails when the IndexOutOfBoundsException is raised:
<pre>
@Test
public void testIndexOutOfBoundsExceptionNotRaised()
throws IndexOutOfBoundsException {

ArrayList emptyList = new ArrayList();
Object o = emptyList.get(0);
}
</pre>
 

=== To Test protected/private methods ===
* Case for protected methods
Place your tests in the same package as the classes under test.
* Case for private methods
Testing private methods may be an indication that those methods should be moved into another class to promote reusability.
 

=== Conditions to test get() and set() methods ===
Unit tests are intended to alleviate fear that something might break. If you think a get() or set() method could reasonably break, or has in fact contributed to a defect, then by all means write a test.
In short, test until you're confident. What you choose to test is subjective, based on your experiences and confidence level. Remember to be practical and maximize your testing investment.
 

=== To run setUp() and tearDown() code once for all tests ===

You can add a @BeforeClass annotation to a method to be run before all the tests in a class, and a @AfterClass annotation to a method to be run after all the tests in a class. Here's an example:

<pre>
package junitfaq;

import org.junit.*;
import static org.junit.Assert.*;
import java.util.*;

public class SimpleTest {

private Collection collection;

@BeforeClass
public static void oneTimeSetUp() {
// one-time initialization code
}

@AfterClass
public static void oneTimeTearDown() {
// one-time cleanup code
}

@Before
public void setUp() {
collection = new ArrayList();
}

@After
public void tearDown() {
collection.clear();
}

@Test
public void testEmptyCollection() {
assertTrue(collection.isEmpty());
}

@Test
public void testOneItemCollection() {
collection.add("itemA");
assertEquals(1, collection.size());
}
}
</pre>
Given this test, the methods will execute in the following order:

*oneTimeSetUp()
*setUp()
*testEmptyCollection()
*tearDown()
*setUp()
*testOneItemCollection()
*tearDown()
*oneTimeTearDown()
 

==Conclusion==
By following the guidelines given in this articles, one can write a good unit test using junit, which is as important as writing good quality code. 
A good quality unit test will take care of all classes, boundary conditions, domain data and functionality. 
A good test can be creative to explore all possibilities, thinking out of box. 
Finally automating the test using tool like junit which is in the native java language itself helps in saving manual intervention and time/money. 

==References==

* http://articles.techrepublic.com.com/5100-10878_11-1027676.html
* http://msdn.microsoft.com/en-us/library/aa292197%28VS.71%29.asp
* http://junit.sourceforge.net/doc/cookbook/cookbook.htm
* http://junit.sourceforge.net/doc/faq/faq.htm#overview
* http://clarkware.com/articles/JUnitPrimer.html#usage
* http://users.csc.calpoly.edu/~jdalbey/205/Resources/junitQuickStart.html
* http://www.cis.upenn.edu/~matuszek/cit591-2004/Lectures/
* http://en.wikipedia.org/wiki/JUnit
* http://www.laliluna.de/eclipse-junit-testing-tutorial.html
* http://junit.sourceforge.net/doc/faq/faq.htm

-------------------------------------------------------

CSC/ECE 517 Fall 2009/wiki1a 1 JunitTest

2009-09-08T19:05:02Z

Wolverine: /* Step 1: Installing JUnit */

'''Writing Effective JUnit Test Cases''' 
----

''JUnit is a testing framework aimed at making unit testing easy by simplifying the writing of test cases and by providing automated running of tests and test suites.''

The objective of this document is to provide a repository of rules that can be used in-order to write an effective Junit test.
This doc also discusses various sites and suggest which are the best sites to read for an overview of the topic and to understand the different philosophies of test-case design.

==Introduction==

=== Unit Testing Overview ===

The primary goal of unit testing is to take the smallest piece of testable software in the application, isolate it from the remainder of the code, and determine whether it behaves exactly as you expect.

'''Test Case''' 
It describes a scenario that can be exercised through the application. 
Each test case is divided into two parts: input and expected output. 
The input part lists all the test case statements that create variables or assign values to variables. 
The expected output part indicates the expected results; it shows either assertions or the message 'no exception' (when no assertions exist). 

The main issue in constructing a unit test is deciding the scope of test cases. 
If the scope is too narrow, then the tests will be trivial and the objects might pass the tests, but there will be no design of their interactions and interactions of objects are important for object oriented design. 
On the other hand if the scope is too broad, then there is a high chance that not every component of the new code will get tested. 
The programmer is then reduced to testing-by-poking-around, which is not an effective test strategy. 

=== JUnit Overview ===
Non-automated testing is usually like this: 
* An expression is used in a debugger, you can change debug expressions without recompiling, and you can wait to decide what to write until you have seen the running objects. 
* Expressions are tested as statements which print to the standard output stream. 
But its not preferred because: 
* They require human judgment to analyze their results. 
* They are cumbersome, non repeatable - you can only execute one debug expression at a time and a program with too many print statements causes the dreaded "Scroll Blindness". 
On the upper hand, JUnit tests, which uses the automated framework does not require human judgment to interpret, and it is easy to run many of them at the same time.
 
When you need to test something, here is what you do: 
* Annotate a method with @org.junit.Test 
* When you want to check a value, import org.junit.Assert.* statically, call assertTrue() and pass a boolean that is true if the test succeeds 
'''So what exactly is JUnit ?? ''' 
It is a open-source unit testing framework for Java and provides a way to organize test data and perform repeatable test execution. 
In JUnit, one has to write Java code, called a test class, that describes test data, invokes the methods to be tested, and determines test results. 
JUnit was originally written by Erich Gamma and Kent Beck. 
The official JUnit home page is http://junit.org. 
JUnit is Open Source Software, released under IBM's Common Public License Version 0.5 and hosted on SourceForge. 
It is an instance of the xUnit architecture for unit testing frameworks. JUnit features include: 
* Assertions for testing expected results 
* Test fixtures for sharing common test data 
* Test runners for running tests 
'''JUnit mailing lists and forums''' 
[http://groups.yahoo.com/group/junit/ JUnit user list] 
[http://lists.sourceforge.net/lists/listinfo/junit-announce JUnit announcements] 
[http://lists.sourceforge.net/lists/listinfo/junit-devel JUnit developer list] 
'''JUnit official documentation''' 
[http://junit.sourceforge.net/doc/testinfected/testing.htm JUnit Test Infected: Programmers Love Writing Tests] 
[http://junit.sourceforge.net/doc/cookbook/cookbook.htm JUnit Cookbook] 
[http://junit.sourceforge.net/doc/cookstour/cookstour.htm JUnit - A Cook's Tour] 
[http://junit.sourceforge.net/doc/faq/faq.htm JUnit FAQ] 
Although JUnit testing costs some time and money, but unit testing provides some crucial advantages, viz: 
Automation of the testing process 
Reduces difficulties of discovering errors contained in more complex pieces of the application 
Test coverage is often enhanced because attention is given to each unit. 
For example, 
if you have two units and decide it would be more cost effective to glue them together and initially test them as an integrated unit, an error could occur in a variety of places, now: 
* Is the error due to a defect in unit 1? 
* Is the error due to a defect in unit 2? 
* Is the error due to defects in both units? 
* Is the error due to a defect in the interface between the units? 
* Is the error due to a defect in the test? 
Finding the error (or errors) in the integrated module is much more complicated than first isolating the units, testing each, then integrating them and testing the whole. 
 

== Websites to lookout ==
These are some of the best webpages which will help you in getting more description as well as details about Junit.
 Also it will help you understand the test case design philosophy. 
=== For Overview ===
* Junit testing basics: 
http://articles.techrepublic.com.com/5100-10878_11-1027676.html

* Basics of Junit: 
http://junit.sourceforge.net/doc/cookbook/cookbook.htm
http://junit.sourceforge.net/doc/faq/faq.htm#overview

=== For Ideas on test case design ===
* For successful test automation: 
http://www.io.com/~wazmo/papers/seven_steps.html

* Unit testing principles: 
http://www.acm.org/ubiquity/views/t_burns_1.html

* For test suite effectiveness: 
http://java.sys-con.com/node/299945
 

== How to get started ==
=== Step 1: Installing JUnit ===

* Download latest version of JUnit from "http://sourceforge.net/projects/junit/files/". 
* Then install JUnit on your platform of choice: 
Windows 
To install JUnit on Windows, follow these steps: 
* Unzip the junit.zip distribution file to a directory referred to as %JUNIT_HOME%. 
* Add JUnit to the classpath: 
<pre>set CLASSPATH=%JUNIT_HOME%\junit.jar</pre>
'''Unix (bash)''' 
To install JUnit on Unix, follow these steps: 
* Unzip the junit.zip distribution file to a directory referred to as $JUNIT_HOME. 
* Add JUnit to the classpath: 
<pre>export CLASSPATH=$JUNIT_HOME/junit.jar</pre>
 

=== Step 2: Writing a Test Case ===
To write a test case, follow these steps: 

* Implement a class derived from TestCase, a base class provided by JUnit. 
public class BooksCartTest extends TestCase
* Be sure the test class belongs to the same package as that of the unit you wish to test 
* Override the setUp() method to initialize object(s) under test. 
* Optionally override the tearDown() method to release object(s) under test. 
* Define one or more public testXXX() methods that exercise the object(s) under test and assert expected results. 
The following is an example test case: 
<pre>
import junit.framework.TestCase;

public class BooksCartTest extends TestCase {

private BooksCart cart1;
private BooksCart cart2;

/**
* Sets up the test fixture.
*
* Called before every test case method.
*/
protected void setUp() {

cart1 = new BooksCart(6,8);
cart2 = new BooksCart(7,10);
}

/**
* Tears down the test fixture.
*
* Called after every test case method.
*/
protected void tearDown() {
// release objects under test here, if necessary
}

/**
* Tests emptying the cart.
*/
public void testEmpty() {

cart1.empty();
cart2.empty();
assertEquals(cart1, new BooksCart(3, 9));
assertTrue(!cart2.equals(cart1));
}
}
</pre>
Methods used in JUnit: 
* An assert method is a JUnit method that performs a test, and throws an AssertionFailedError if the test fails 
* static void assertTrue(boolean test) 
static void assertTrue(String message, boolean test)
- Throws an AssertionFailedError if the test fails 
- The optional message is included in the Error 
* static void assertFalse(boolean test) 
static void assertFalse(String message, boolean test)
- Throws an AssertionFailedError if the test fails 
 

=== Step 3: Writing a Test Suite ===
Next, we'll write a test suite that includes several test cases. The test suite will allow us to run all of its test cases in one fell swoop. 
'''To write a test suite, follow these steps:''' 
* Write a Java class that defines a static suite() factory method that creates a TestSuite containing all the tests. 
* Optionally define a main() method that runs the TestSuite in batch mode. 

The following is an example test suite: 
<pre>
import junit.framework.Test;
import junit.framework.TestSuite;

public class BooksCartTestSuite {

public static Test suite() {

TestSuite suite = new TestSuite();

//
// The BooksCartTest we created above.
//
suite.addTestSuite(BooksCartTest.class);

//
// Another example test suite of tests.
//
suite.addTest(CreditCardTestSuite.suite());

//
// Add more tests here
//

return suite;
}

/**
* Runs the test suite using the textual runner.
*/
public static void main(String[] args) {
junit.textui.TestRunner.run(suite());
}
}
</pre>
 

=== Step 4: Running the Test ===
Now that we've written a test suite containing a collection of test cases and other test suites, we can run either the test suite or any of its test cases individually. Running a TestSuite will automatically run all of its subordinate TestCase instances and TestSuite instances. Running a TestCase will automatically invoke all of its public testXXX() methods.
JUnit provides both a textual and a graphical user interface. Both user interfaces indicate how many tests were run, any errors or failures, and a simple completion status. The simplicity of the user interfaces is the key to running tests quickly. You should be able to run your tests and know the test status with a glance, much like you do with a compiler.
To run our test case using the textual user interface, use: 
<pre>java junit.textui.TestRunner BooksCartTest </pre>
The textual user interface displays "OK" if all the tests passed and failure messages if any of the tests failed. 
To run the test case using the graphical user interface, use: 
<pre>java junit.swingui.TestRunner BooksCartTest </pre>
The graphical user interface displays a Swing window with a green progress bar if all the tests passed or a red progress bar if any of the tests failed. 
The BooksCartTest Suite can be run similarly: 
<pre>java junit.swingui.TestRunner BooksCartTestSuite</pre>
 

== Rules for designing effective JUnit Test cases ==
* Identify and assemble a list of all the actions that your program should be able to perform. use cases,nonfunctional requirements specifications, test case specifications, user interface design documents, mockups, user profiles, and various additional artifacts.
* Identify the code's entry points - central pieces of code that exercise the functionality that the code as a whole is designed to undertake.
* Pair entry points with the use cases that they implement.
* Create test cases by applying the initialize/work/check procedure.
** Initialize: Create the environment that the test expects to run in. The initialization code can either be in the beginning of the test or in the setUp() method.
** Work: Call the code that is being tested, capturing any interesting output and recording any interesting statistics.
** Check: Use assert statements to ensure that the code worked as expected.
* Develop runtime event diagrams and use them to facilitate testing.
* Follow KISS rule:It's a bad idea to keep the input source name and expression in the test case. Some items (server names, usernames and passwords, etc.) should not live in the test files, which should be configurable for the specific deployment. Rather, design the test cases to facilitate separation of test drivers and test data, test driver reuse over a larger set of data, and test data reuse over a larger set of test drivers. On the other hand, don't over-architect a simple test case implementation. Typically, the test case specification already defines most of the system states and allows parameter descriptions for a scenario, so there's no point in making everything parameterizable in the test implementation.
 

==Rules for coding effective JUnit Tests==

=== Using Test Fixture for a common set of objects ===
Using a test fixture avoids duplicating the code necessary to initialize (and cleanup) the common objects.
Tests can use the objects (variables) in a test fixture, with each test invoking different methods on objects in the fixture and asserting different expected results. Each test runs in its own test fixture to isolate tests from the changes made by other tests. That is, tests don't share the state of objects in the test fixture. Because the tests are isolated, they can be run in any order.
To create a test fixture, declare instance variables for the common objects. Initialize these objects in a public void method annotated with @Before. The JUnit framework automatically invokes any @Before methods before each test is run.
The following example shows a test fixture with a common Collection object.
<pre>
package junitfaq;

import org.junit.*;
import static org.junit.Assert.*;
import java.util.*;

public class SimpleTest {

private Collection<Object> collection;

@Before
public void setUp() {
collection = new ArrayList<Object>();
}

@Test
public void testEmptyCollection() {
assertTrue(collection.isEmpty());
}

@Test
public void testOneItemCollection() {
collection.add("itemA");
assertEquals(1, collection.size());
}
}
</pre>
Given this test, the methods might execute in the following order: 
setUp() 
testEmptyCollection() 
setUp() 
testOneItemCollection() 
The ordering of test-method invocations is not guaranteed, so testOneItemCollection() might be executed before testEmptyCollection(). But it doesn't matter, because each method gets its own instance of the collection.
Although JUnit provides a new instance of the fixture objects for each test method, if you allocate any external resources in a @Before method, you should release them after the test runs by annotating a method with @After. The JUnit framework automatically invokes any @After methods after each test is run. For example:
<pre>
package junitfaq;

import org.junit.*;
import static org.junit.Assert.*;
import java.io.*;

public class OutputTest {

private File output;

@Before
public void createOutputFile() {
output = new File(...);
}

@After
public void deleteOutputFile() {
output.delete();
}

@Test
public void testSomethingWithFile() {
...
}
}
</pre>
With this test, the methods will execute in the following order:

* createOutputFile()
* testSomethingWithFile()
* deleteOutputFile()
 

=== To Test a method that doesnot return anything ===
If a method doesn't return a value, it might have some side effect. Actually, if it doesn't return a value AND doesn't have a side effect, it isn't doing anything.
There may be a way to verify that the side effect actually occurred as expected. For example, consider the add() method in the Collection classes. There are ways of verifying that the side effect happened (i.e. the object was added). You can check the size and assert that it is what is expected:

<pre>
public void testCollectionAdd() {
Collection collection = new ArrayList();
assertEquals(0, collection.size());
collection.add("itemA");
assertEquals(1, collection.size());
collection.add("itemB");
assertEquals(2, collection.size());
}
</pre>
 

=== To test an expected/unexpected exception ===
* Case of expected exception
Add the optional expected attribute to the @Test annotation. The following is an example test that passes when the expected IndexOutOfBoundsException is raised:
<pre>
@Test(expected=IndexOutOfBoundsException.class)
public void testIndexOutOfBoundsException() {
ArrayList emptyList = new ArrayList();
Object o = emptyList.get(0);
}
</pre>
* Case of unexpected exception
Declare the exception in the throws clause of the test method and don't catch the exception within the test method. Uncaught exceptions will cause the test to fail with an error.
The following is an example test that fails when the IndexOutOfBoundsException is raised:
<pre>
@Test
public void testIndexOutOfBoundsExceptionNotRaised()
throws IndexOutOfBoundsException {

ArrayList emptyList = new ArrayList();
Object o = emptyList.get(0);
}
</pre>
 

=== To Test protected/private methods ===
* Case for protected methods
Place your tests in the same package as the classes under test.
* Case for private methods
Testing private methods may be an indication that those methods should be moved into another class to promote reusability.
 

=== Conditions to test get() and set() methods ===
Unit tests are intended to alleviate fear that something might break. If you think a get() or set() method could reasonably break, or has in fact contributed to a defect, then by all means write a test.
In short, test until you're confident. What you choose to test is subjective, based on your experiences and confidence level. Remember to be practical and maximize your testing investment.
 

=== To run setUp() and tearDown() code once for all tests ===

You can add a @BeforeClass annotation to a method to be run before all the tests in a class, and a @AfterClass annotation to a method to be run after all the tests in a class. Here's an example:

<pre>
package junitfaq;

import org.junit.*;
import static org.junit.Assert.*;
import java.util.*;

public class SimpleTest {

private Collection collection;

@BeforeClass
public static void oneTimeSetUp() {
// one-time initialization code
}

@AfterClass
public static void oneTimeTearDown() {
// one-time cleanup code
}

@Before
public void setUp() {
collection = new ArrayList();
}

@After
public void tearDown() {
collection.clear();
}

@Test
public void testEmptyCollection() {
assertTrue(collection.isEmpty());
}

@Test
public void testOneItemCollection() {
collection.add("itemA");
assertEquals(1, collection.size());
}
}
</pre>
Given this test, the methods will execute in the following order:

*oneTimeSetUp()
*setUp()
*testEmptyCollection()
*tearDown()
*setUp()
*testOneItemCollection()
*tearDown()
*oneTimeTearDown()
 

==Conclusion==
By following the guidelines given in this articles, one can write a good unit test using junit, which is as important as writing good quality code. 
A good quality unit test will take care of all classes, boundary conditions, domain data and functionality. 
A good test can be creative to explore all possibilities, thinking out of box. 
Finally automating the test using tool like junit which is in the native java language itself helps in saving manual intervention and time/money. 

==References==

* http://articles.techrepublic.com.com/5100-10878_11-1027676.html
* http://msdn.microsoft.com/en-us/library/aa292197%28VS.71%29.asp
* http://junit.sourceforge.net/doc/cookbook/cookbook.htm
* http://junit.sourceforge.net/doc/faq/faq.htm#overview
* http://clarkware.com/articles/JUnitPrimer.html#usage
* http://users.csc.calpoly.edu/~jdalbey/205/Resources/junitQuickStart.html
* http://www.cis.upenn.edu/~matuszek/cit591-2004/Lectures/
* http://en.wikipedia.org/wiki/JUnit
* http://www.laliluna.de/eclipse-junit-testing-tutorial.html
* http://junit.sourceforge.net/doc/faq/faq.htm

-------------------------------------------------------

CSC/ECE 517 Fall 2009/wiki1a 1 JunitTest

2009-09-08T19:04:42Z

Wolverine: /* Step 2: Writing a Test Case */

'''Writing Effective JUnit Test Cases''' 
----

''JUnit is a testing framework aimed at making unit testing easy by simplifying the writing of test cases and by providing automated running of tests and test suites.''

The objective of this document is to provide a repository of rules that can be used in-order to write an effective Junit test.
This doc also discusses various sites and suggest which are the best sites to read for an overview of the topic and to understand the different philosophies of test-case design.

==Introduction==

=== Unit Testing Overview ===

The primary goal of unit testing is to take the smallest piece of testable software in the application, isolate it from the remainder of the code, and determine whether it behaves exactly as you expect.

'''Test Case''' 
It describes a scenario that can be exercised through the application. 
Each test case is divided into two parts: input and expected output. 
The input part lists all the test case statements that create variables or assign values to variables. 
The expected output part indicates the expected results; it shows either assertions or the message 'no exception' (when no assertions exist). 

The main issue in constructing a unit test is deciding the scope of test cases. 
If the scope is too narrow, then the tests will be trivial and the objects might pass the tests, but there will be no design of their interactions and interactions of objects are important for object oriented design. 
On the other hand if the scope is too broad, then there is a high chance that not every component of the new code will get tested. 
The programmer is then reduced to testing-by-poking-around, which is not an effective test strategy. 

=== JUnit Overview ===
Non-automated testing is usually like this: 
* An expression is used in a debugger, you can change debug expressions without recompiling, and you can wait to decide what to write until you have seen the running objects. 
* Expressions are tested as statements which print to the standard output stream. 
But its not preferred because: 
* They require human judgment to analyze their results. 
* They are cumbersome, non repeatable - you can only execute one debug expression at a time and a program with too many print statements causes the dreaded "Scroll Blindness". 
On the upper hand, JUnit tests, which uses the automated framework does not require human judgment to interpret, and it is easy to run many of them at the same time.
 
When you need to test something, here is what you do: 
* Annotate a method with @org.junit.Test 
* When you want to check a value, import org.junit.Assert.* statically, call assertTrue() and pass a boolean that is true if the test succeeds 
'''So what exactly is JUnit ?? ''' 
It is a open-source unit testing framework for Java and provides a way to organize test data and perform repeatable test execution. 
In JUnit, one has to write Java code, called a test class, that describes test data, invokes the methods to be tested, and determines test results. 
JUnit was originally written by Erich Gamma and Kent Beck. 
The official JUnit home page is http://junit.org. 
JUnit is Open Source Software, released under IBM's Common Public License Version 0.5 and hosted on SourceForge. 
It is an instance of the xUnit architecture for unit testing frameworks. JUnit features include: 
* Assertions for testing expected results 
* Test fixtures for sharing common test data 
* Test runners for running tests 
'''JUnit mailing lists and forums''' 
[http://groups.yahoo.com/group/junit/ JUnit user list] 
[http://lists.sourceforge.net/lists/listinfo/junit-announce JUnit announcements] 
[http://lists.sourceforge.net/lists/listinfo/junit-devel JUnit developer list] 
'''JUnit official documentation''' 
[http://junit.sourceforge.net/doc/testinfected/testing.htm JUnit Test Infected: Programmers Love Writing Tests] 
[http://junit.sourceforge.net/doc/cookbook/cookbook.htm JUnit Cookbook] 
[http://junit.sourceforge.net/doc/cookstour/cookstour.htm JUnit - A Cook's Tour] 
[http://junit.sourceforge.net/doc/faq/faq.htm JUnit FAQ] 
Although JUnit testing costs some time and money, but unit testing provides some crucial advantages, viz: 
Automation of the testing process 
Reduces difficulties of discovering errors contained in more complex pieces of the application 
Test coverage is often enhanced because attention is given to each unit. 
For example, 
if you have two units and decide it would be more cost effective to glue them together and initially test them as an integrated unit, an error could occur in a variety of places, now: 
* Is the error due to a defect in unit 1? 
* Is the error due to a defect in unit 2? 
* Is the error due to defects in both units? 
* Is the error due to a defect in the interface between the units? 
* Is the error due to a defect in the test? 
Finding the error (or errors) in the integrated module is much more complicated than first isolating the units, testing each, then integrating them and testing the whole. 
 

== Websites to lookout ==
These are some of the best webpages which will help you in getting more description as well as details about Junit.
 Also it will help you understand the test case design philosophy. 
=== For Overview ===
* Junit testing basics: 
http://articles.techrepublic.com.com/5100-10878_11-1027676.html

* Basics of Junit: 
http://junit.sourceforge.net/doc/cookbook/cookbook.htm
http://junit.sourceforge.net/doc/faq/faq.htm#overview

=== For Ideas on test case design ===
* For successful test automation: 
http://www.io.com/~wazmo/papers/seven_steps.html

* Unit testing principles: 
http://www.acm.org/ubiquity/views/t_burns_1.html

* For test suite effectiveness: 
http://java.sys-con.com/node/299945
 

== How to get started ==
=== Step 1: Installing JUnit ===

* Download latest version of JUnit from "http://sourceforge.net/projects/junit/files/". 
* Then install JUnit on your platform of choice: 
Windows 
To install JUnit on Windows, follow these steps: 
* Unzip the junit.zip distribution file to a directory referred to as %JUNIT_HOME%. 
* Add JUnit to the classpath: 
<pre>set CLASSPATH=%JUNIT_HOME%\junit.jar</pre>
'''Unix (bash)''' 
To install JUnit on Unix, follow these steps: 
* Unzip the junit.zip distribution file to a directory referred to as $JUNIT_HOME. 
* Add JUnit to the classpath: 
<pre>export CLASSPATH=$JUNIT_HOME/junit.jar</pre>

=== Step 2: Writing a Test Case ===
To write a test case, follow these steps: 

* Implement a class derived from TestCase, a base class provided by JUnit. 
public class BooksCartTest extends TestCase
* Be sure the test class belongs to the same package as that of the unit you wish to test 
* Override the setUp() method to initialize object(s) under test. 
* Optionally override the tearDown() method to release object(s) under test. 
* Define one or more public testXXX() methods that exercise the object(s) under test and assert expected results. 
The following is an example test case: 
<pre>
import junit.framework.TestCase;

public class BooksCartTest extends TestCase {

private BooksCart cart1;
private BooksCart cart2;

/**
* Sets up the test fixture.
*
* Called before every test case method.
*/
protected void setUp() {

cart1 = new BooksCart(6,8);
cart2 = new BooksCart(7,10);
}

/**
* Tears down the test fixture.
*
* Called after every test case method.
*/
protected void tearDown() {
// release objects under test here, if necessary
}

/**
* Tests emptying the cart.
*/
public void testEmpty() {

cart1.empty();
cart2.empty();
assertEquals(cart1, new BooksCart(3, 9));
assertTrue(!cart2.equals(cart1));
}
}
</pre>
Methods used in JUnit: 
* An assert method is a JUnit method that performs a test, and throws an AssertionFailedError if the test fails 
* static void assertTrue(boolean test) 
static void assertTrue(String message, boolean test)
- Throws an AssertionFailedError if the test fails 
- The optional message is included in the Error 
* static void assertFalse(boolean test) 
static void assertFalse(String message, boolean test)
- Throws an AssertionFailedError if the test fails 
 

=== Step 3: Writing a Test Suite ===
Next, we'll write a test suite that includes several test cases. The test suite will allow us to run all of its test cases in one fell swoop. 
'''To write a test suite, follow these steps:''' 
* Write a Java class that defines a static suite() factory method that creates a TestSuite containing all the tests. 
* Optionally define a main() method that runs the TestSuite in batch mode. 

The following is an example test suite: 
<pre>
import junit.framework.Test;
import junit.framework.TestSuite;

public class BooksCartTestSuite {

public static Test suite() {

TestSuite suite = new TestSuite();

//
// The BooksCartTest we created above.
//
suite.addTestSuite(BooksCartTest.class);

//
// Another example test suite of tests.
//
suite.addTest(CreditCardTestSuite.suite());

//
// Add more tests here
//

return suite;
}

/**
* Runs the test suite using the textual runner.
*/
public static void main(String[] args) {
junit.textui.TestRunner.run(suite());
}
}
</pre>
 

=== Step 4: Running the Test ===
Now that we've written a test suite containing a collection of test cases and other test suites, we can run either the test suite or any of its test cases individually. Running a TestSuite will automatically run all of its subordinate TestCase instances and TestSuite instances. Running a TestCase will automatically invoke all of its public testXXX() methods.
JUnit provides both a textual and a graphical user interface. Both user interfaces indicate how many tests were run, any errors or failures, and a simple completion status. The simplicity of the user interfaces is the key to running tests quickly. You should be able to run your tests and know the test status with a glance, much like you do with a compiler.
To run our test case using the textual user interface, use: 
<pre>java junit.textui.TestRunner BooksCartTest </pre>
The textual user interface displays "OK" if all the tests passed and failure messages if any of the tests failed. 
To run the test case using the graphical user interface, use: 
<pre>java junit.swingui.TestRunner BooksCartTest </pre>
The graphical user interface displays a Swing window with a green progress bar if all the tests passed or a red progress bar if any of the tests failed. 
The BooksCartTest Suite can be run similarly: 
<pre>java junit.swingui.TestRunner BooksCartTestSuite</pre>
 

== Rules for designing effective JUnit Test cases ==
* Identify and assemble a list of all the actions that your program should be able to perform. use cases,nonfunctional requirements specifications, test case specifications, user interface design documents, mockups, user profiles, and various additional artifacts.
* Identify the code's entry points - central pieces of code that exercise the functionality that the code as a whole is designed to undertake.
* Pair entry points with the use cases that they implement.
* Create test cases by applying the initialize/work/check procedure.
** Initialize: Create the environment that the test expects to run in. The initialization code can either be in the beginning of the test or in the setUp() method.
** Work: Call the code that is being tested, capturing any interesting output and recording any interesting statistics.
** Check: Use assert statements to ensure that the code worked as expected.
* Develop runtime event diagrams and use them to facilitate testing.
* Follow KISS rule:It's a bad idea to keep the input source name and expression in the test case. Some items (server names, usernames and passwords, etc.) should not live in the test files, which should be configurable for the specific deployment. Rather, design the test cases to facilitate separation of test drivers and test data, test driver reuse over a larger set of data, and test data reuse over a larger set of test drivers. On the other hand, don't over-architect a simple test case implementation. Typically, the test case specification already defines most of the system states and allows parameter descriptions for a scenario, so there's no point in making everything parameterizable in the test implementation.
 

==Rules for coding effective JUnit Tests==

=== Using Test Fixture for a common set of objects ===
Using a test fixture avoids duplicating the code necessary to initialize (and cleanup) the common objects.
Tests can use the objects (variables) in a test fixture, with each test invoking different methods on objects in the fixture and asserting different expected results. Each test runs in its own test fixture to isolate tests from the changes made by other tests. That is, tests don't share the state of objects in the test fixture. Because the tests are isolated, they can be run in any order.
To create a test fixture, declare instance variables for the common objects. Initialize these objects in a public void method annotated with @Before. The JUnit framework automatically invokes any @Before methods before each test is run.
The following example shows a test fixture with a common Collection object.
<pre>
package junitfaq;

import org.junit.*;
import static org.junit.Assert.*;
import java.util.*;

public class SimpleTest {

private Collection<Object> collection;

@Before
public void setUp() {
collection = new ArrayList<Object>();
}

@Test
public void testEmptyCollection() {
assertTrue(collection.isEmpty());
}

@Test
public void testOneItemCollection() {
collection.add("itemA");
assertEquals(1, collection.size());
}
}
</pre>
Given this test, the methods might execute in the following order: 
setUp() 
testEmptyCollection() 
setUp() 
testOneItemCollection() 
The ordering of test-method invocations is not guaranteed, so testOneItemCollection() might be executed before testEmptyCollection(). But it doesn't matter, because each method gets its own instance of the collection.
Although JUnit provides a new instance of the fixture objects for each test method, if you allocate any external resources in a @Before method, you should release them after the test runs by annotating a method with @After. The JUnit framework automatically invokes any @After methods after each test is run. For example:
<pre>
package junitfaq;

import org.junit.*;
import static org.junit.Assert.*;
import java.io.*;

public class OutputTest {

private File output;

@Before
public void createOutputFile() {
output = new File(...);
}

@After
public void deleteOutputFile() {
output.delete();
}

@Test
public void testSomethingWithFile() {
...
}
}
</pre>
With this test, the methods will execute in the following order:

* createOutputFile()
* testSomethingWithFile()
* deleteOutputFile()
 

=== To Test a method that doesnot return anything ===
If a method doesn't return a value, it might have some side effect. Actually, if it doesn't return a value AND doesn't have a side effect, it isn't doing anything.
There may be a way to verify that the side effect actually occurred as expected. For example, consider the add() method in the Collection classes. There are ways of verifying that the side effect happened (i.e. the object was added). You can check the size and assert that it is what is expected:

<pre>
public void testCollectionAdd() {
Collection collection = new ArrayList();
assertEquals(0, collection.size());
collection.add("itemA");
assertEquals(1, collection.size());
collection.add("itemB");
assertEquals(2, collection.size());
}
</pre>
 

=== To test an expected/unexpected exception ===
* Case of expected exception
Add the optional expected attribute to the @Test annotation. The following is an example test that passes when the expected IndexOutOfBoundsException is raised:
<pre>
@Test(expected=IndexOutOfBoundsException.class)
public void testIndexOutOfBoundsException() {
ArrayList emptyList = new ArrayList();
Object o = emptyList.get(0);
}
</pre>
* Case of unexpected exception
Declare the exception in the throws clause of the test method and don't catch the exception within the test method. Uncaught exceptions will cause the test to fail with an error.
The following is an example test that fails when the IndexOutOfBoundsException is raised:
<pre>
@Test
public void testIndexOutOfBoundsExceptionNotRaised()
throws IndexOutOfBoundsException {

ArrayList emptyList = new ArrayList();
Object o = emptyList.get(0);
}
</pre>
 

=== To Test protected/private methods ===
* Case for protected methods
Place your tests in the same package as the classes under test.
* Case for private methods
Testing private methods may be an indication that those methods should be moved into another class to promote reusability.
 

=== Conditions to test get() and set() methods ===
Unit tests are intended to alleviate fear that something might break. If you think a get() or set() method could reasonably break, or has in fact contributed to a defect, then by all means write a test.
In short, test until you're confident. What you choose to test is subjective, based on your experiences and confidence level. Remember to be practical and maximize your testing investment.
 

=== To run setUp() and tearDown() code once for all tests ===

You can add a @BeforeClass annotation to a method to be run before all the tests in a class, and a @AfterClass annotation to a method to be run after all the tests in a class. Here's an example:

<pre>
package junitfaq;

import org.junit.*;
import static org.junit.Assert.*;
import java.util.*;

public class SimpleTest {

private Collection collection;

@BeforeClass
public static void oneTimeSetUp() {
// one-time initialization code
}

@AfterClass
public static void oneTimeTearDown() {
// one-time cleanup code
}

@Before
public void setUp() {
collection = new ArrayList();
}

@After
public void tearDown() {
collection.clear();
}

@Test
public void testEmptyCollection() {
assertTrue(collection.isEmpty());
}

@Test
public void testOneItemCollection() {
collection.add("itemA");
assertEquals(1, collection.size());
}
}
</pre>
Given this test, the methods will execute in the following order:

*oneTimeSetUp()
*setUp()
*testEmptyCollection()
*tearDown()
*setUp()
*testOneItemCollection()
*tearDown()
*oneTimeTearDown()
 

==Conclusion==
By following the guidelines given in this articles, one can write a good unit test using junit, which is as important as writing good quality code. 
A good quality unit test will take care of all classes, boundary conditions, domain data and functionality. 
A good test can be creative to explore all possibilities, thinking out of box. 
Finally automating the test using tool like junit which is in the native java language itself helps in saving manual intervention and time/money. 

==References==

* http://articles.techrepublic.com.com/5100-10878_11-1027676.html
* http://msdn.microsoft.com/en-us/library/aa292197%28VS.71%29.asp
* http://junit.sourceforge.net/doc/cookbook/cookbook.htm
* http://junit.sourceforge.net/doc/faq/faq.htm#overview
* http://clarkware.com/articles/JUnitPrimer.html#usage
* http://users.csc.calpoly.edu/~jdalbey/205/Resources/junitQuickStart.html
* http://www.cis.upenn.edu/~matuszek/cit591-2004/Lectures/
* http://en.wikipedia.org/wiki/JUnit
* http://www.laliluna.de/eclipse-junit-testing-tutorial.html
* http://junit.sourceforge.net/doc/faq/faq.htm

-------------------------------------------------------

CSC/ECE 517 Fall 2009/wiki1a 1 JunitTest

2009-09-08T19:04:22Z

Wolverine: /* Step 3: Writing a Test Suite */

'''Writing Effective JUnit Test Cases''' 
----

''JUnit is a testing framework aimed at making unit testing easy by simplifying the writing of test cases and by providing automated running of tests and test suites.''

The objective of this document is to provide a repository of rules that can be used in-order to write an effective Junit test.
This doc also discusses various sites and suggest which are the best sites to read for an overview of the topic and to understand the different philosophies of test-case design.

==Introduction==

=== Unit Testing Overview ===

The primary goal of unit testing is to take the smallest piece of testable software in the application, isolate it from the remainder of the code, and determine whether it behaves exactly as you expect.

'''Test Case''' 
It describes a scenario that can be exercised through the application. 
Each test case is divided into two parts: input and expected output. 
The input part lists all the test case statements that create variables or assign values to variables. 
The expected output part indicates the expected results; it shows either assertions or the message 'no exception' (when no assertions exist). 

The main issue in constructing a unit test is deciding the scope of test cases. 
If the scope is too narrow, then the tests will be trivial and the objects might pass the tests, but there will be no design of their interactions and interactions of objects are important for object oriented design. 
On the other hand if the scope is too broad, then there is a high chance that not every component of the new code will get tested. 
The programmer is then reduced to testing-by-poking-around, which is not an effective test strategy. 

=== JUnit Overview ===
Non-automated testing is usually like this: 
* An expression is used in a debugger, you can change debug expressions without recompiling, and you can wait to decide what to write until you have seen the running objects. 
* Expressions are tested as statements which print to the standard output stream. 
But its not preferred because: 
* They require human judgment to analyze their results. 
* They are cumbersome, non repeatable - you can only execute one debug expression at a time and a program with too many print statements causes the dreaded "Scroll Blindness". 
On the upper hand, JUnit tests, which uses the automated framework does not require human judgment to interpret, and it is easy to run many of them at the same time.
 
When you need to test something, here is what you do: 
* Annotate a method with @org.junit.Test 
* When you want to check a value, import org.junit.Assert.* statically, call assertTrue() and pass a boolean that is true if the test succeeds 
'''So what exactly is JUnit ?? ''' 
It is a open-source unit testing framework for Java and provides a way to organize test data and perform repeatable test execution. 
In JUnit, one has to write Java code, called a test class, that describes test data, invokes the methods to be tested, and determines test results. 
JUnit was originally written by Erich Gamma and Kent Beck. 
The official JUnit home page is http://junit.org. 
JUnit is Open Source Software, released under IBM's Common Public License Version 0.5 and hosted on SourceForge. 
It is an instance of the xUnit architecture for unit testing frameworks. JUnit features include: 
* Assertions for testing expected results 
* Test fixtures for sharing common test data 
* Test runners for running tests 
'''JUnit mailing lists and forums''' 
[http://groups.yahoo.com/group/junit/ JUnit user list] 
[http://lists.sourceforge.net/lists/listinfo/junit-announce JUnit announcements] 
[http://lists.sourceforge.net/lists/listinfo/junit-devel JUnit developer list] 
'''JUnit official documentation''' 
[http://junit.sourceforge.net/doc/testinfected/testing.htm JUnit Test Infected: Programmers Love Writing Tests] 
[http://junit.sourceforge.net/doc/cookbook/cookbook.htm JUnit Cookbook] 
[http://junit.sourceforge.net/doc/cookstour/cookstour.htm JUnit - A Cook's Tour] 
[http://junit.sourceforge.net/doc/faq/faq.htm JUnit FAQ] 
Although JUnit testing costs some time and money, but unit testing provides some crucial advantages, viz: 
Automation of the testing process 
Reduces difficulties of discovering errors contained in more complex pieces of the application 
Test coverage is often enhanced because attention is given to each unit. 
For example, 
if you have two units and decide it would be more cost effective to glue them together and initially test them as an integrated unit, an error could occur in a variety of places, now: 
* Is the error due to a defect in unit 1? 
* Is the error due to a defect in unit 2? 
* Is the error due to defects in both units? 
* Is the error due to a defect in the interface between the units? 
* Is the error due to a defect in the test? 
Finding the error (or errors) in the integrated module is much more complicated than first isolating the units, testing each, then integrating them and testing the whole. 
 

== Websites to lookout ==
These are some of the best webpages which will help you in getting more description as well as details about Junit.
 Also it will help you understand the test case design philosophy. 
=== For Overview ===
* Junit testing basics: 
http://articles.techrepublic.com.com/5100-10878_11-1027676.html

* Basics of Junit: 
http://junit.sourceforge.net/doc/cookbook/cookbook.htm
http://junit.sourceforge.net/doc/faq/faq.htm#overview

=== For Ideas on test case design ===
* For successful test automation: 
http://www.io.com/~wazmo/papers/seven_steps.html

* Unit testing principles: 
http://www.acm.org/ubiquity/views/t_burns_1.html

* For test suite effectiveness: 
http://java.sys-con.com/node/299945
 

== How to get started ==
=== Step 1: Installing JUnit ===

* Download latest version of JUnit from "http://sourceforge.net/projects/junit/files/". 
* Then install JUnit on your platform of choice: 
Windows 
To install JUnit on Windows, follow these steps: 
* Unzip the junit.zip distribution file to a directory referred to as %JUNIT_HOME%. 
* Add JUnit to the classpath: 
<pre>set CLASSPATH=%JUNIT_HOME%\junit.jar</pre>
'''Unix (bash)''' 
To install JUnit on Unix, follow these steps: 
* Unzip the junit.zip distribution file to a directory referred to as $JUNIT_HOME. 
* Add JUnit to the classpath: 
<pre>export CLASSPATH=$JUNIT_HOME/junit.jar</pre>

=== Step 2: Writing a Test Case ===
To write a test case, follow these steps: 

* Implement a class derived from TestCase, a base class provided by JUnit. 
public class BooksCartTest extends TestCase
* Be sure the test class belongs to the same package as that of the unit you wish to test 
* Override the setUp() method to initialize object(s) under test. 
* Optionally override the tearDown() method to release object(s) under test. 
* Define one or more public testXXX() methods that exercise the object(s) under test and assert expected results. 
The following is an example test case: 
<pre>
import junit.framework.TestCase;

public class BooksCartTest extends TestCase {

private BooksCart cart1;
private BooksCart cart2;

/**
* Sets up the test fixture.
*
* Called before every test case method.
*/
protected void setUp() {

cart1 = new BooksCart(6,8);
cart2 = new BooksCart(7,10);
}

/**
* Tears down the test fixture.
*
* Called after every test case method.
*/
protected void tearDown() {
// release objects under test here, if necessary
}

/**
* Tests emptying the cart.
*/
public void testEmpty() {

cart1.empty();
cart2.empty();
assertEquals(cart1, new BooksCart(3, 9));
assertTrue(!cart2.equals(cart1));
}
}
</pre>
Methods used in JUnit: 
* An assert method is a JUnit method that performs a test, and throws an AssertionFailedError if the test fails 
* static void assertTrue(boolean test) 
static void assertTrue(String message, boolean test)
- Throws an AssertionFailedError if the test fails 
- The optional message is included in the Error 
* static void assertFalse(boolean test) 
static void assertFalse(String message, boolean test)
- Throws an AssertionFailedError if the test fails 

=== Step 3: Writing a Test Suite ===
Next, we'll write a test suite that includes several test cases. The test suite will allow us to run all of its test cases in one fell swoop. 
'''To write a test suite, follow these steps:''' 
* Write a Java class that defines a static suite() factory method that creates a TestSuite containing all the tests. 
* Optionally define a main() method that runs the TestSuite in batch mode. 

The following is an example test suite: 
<pre>
import junit.framework.Test;
import junit.framework.TestSuite;

public class BooksCartTestSuite {

public static Test suite() {

TestSuite suite = new TestSuite();

//
// The BooksCartTest we created above.
//
suite.addTestSuite(BooksCartTest.class);

//
// Another example test suite of tests.
//
suite.addTest(CreditCardTestSuite.suite());

//
// Add more tests here
//

return suite;
}

/**
* Runs the test suite using the textual runner.
*/
public static void main(String[] args) {
junit.textui.TestRunner.run(suite());
}
}
</pre>
 

=== Step 4: Running the Test ===
Now that we've written a test suite containing a collection of test cases and other test suites, we can run either the test suite or any of its test cases individually. Running a TestSuite will automatically run all of its subordinate TestCase instances and TestSuite instances. Running a TestCase will automatically invoke all of its public testXXX() methods.
JUnit provides both a textual and a graphical user interface. Both user interfaces indicate how many tests were run, any errors or failures, and a simple completion status. The simplicity of the user interfaces is the key to running tests quickly. You should be able to run your tests and know the test status with a glance, much like you do with a compiler.
To run our test case using the textual user interface, use: 
<pre>java junit.textui.TestRunner BooksCartTest </pre>
The textual user interface displays "OK" if all the tests passed and failure messages if any of the tests failed. 
To run the test case using the graphical user interface, use: 
<pre>java junit.swingui.TestRunner BooksCartTest </pre>
The graphical user interface displays a Swing window with a green progress bar if all the tests passed or a red progress bar if any of the tests failed. 
The BooksCartTest Suite can be run similarly: 
<pre>java junit.swingui.TestRunner BooksCartTestSuite</pre>
 

== Rules for designing effective JUnit Test cases ==
* Identify and assemble a list of all the actions that your program should be able to perform. use cases,nonfunctional requirements specifications, test case specifications, user interface design documents, mockups, user profiles, and various additional artifacts.
* Identify the code's entry points - central pieces of code that exercise the functionality that the code as a whole is designed to undertake.
* Pair entry points with the use cases that they implement.
* Create test cases by applying the initialize/work/check procedure.
** Initialize: Create the environment that the test expects to run in. The initialization code can either be in the beginning of the test or in the setUp() method.
** Work: Call the code that is being tested, capturing any interesting output and recording any interesting statistics.
** Check: Use assert statements to ensure that the code worked as expected.
* Develop runtime event diagrams and use them to facilitate testing.
* Follow KISS rule:It's a bad idea to keep the input source name and expression in the test case. Some items (server names, usernames and passwords, etc.) should not live in the test files, which should be configurable for the specific deployment. Rather, design the test cases to facilitate separation of test drivers and test data, test driver reuse over a larger set of data, and test data reuse over a larger set of test drivers. On the other hand, don't over-architect a simple test case implementation. Typically, the test case specification already defines most of the system states and allows parameter descriptions for a scenario, so there's no point in making everything parameterizable in the test implementation.
 

==Rules for coding effective JUnit Tests==

=== Using Test Fixture for a common set of objects ===
Using a test fixture avoids duplicating the code necessary to initialize (and cleanup) the common objects.
Tests can use the objects (variables) in a test fixture, with each test invoking different methods on objects in the fixture and asserting different expected results. Each test runs in its own test fixture to isolate tests from the changes made by other tests. That is, tests don't share the state of objects in the test fixture. Because the tests are isolated, they can be run in any order.
To create a test fixture, declare instance variables for the common objects. Initialize these objects in a public void method annotated with @Before. The JUnit framework automatically invokes any @Before methods before each test is run.
The following example shows a test fixture with a common Collection object.
<pre>
package junitfaq;

import org.junit.*;
import static org.junit.Assert.*;
import java.util.*;

public class SimpleTest {

private Collection<Object> collection;

@Before
public void setUp() {
collection = new ArrayList<Object>();
}

@Test
public void testEmptyCollection() {
assertTrue(collection.isEmpty());
}

@Test
public void testOneItemCollection() {
collection.add("itemA");
assertEquals(1, collection.size());
}
}
</pre>
Given this test, the methods might execute in the following order: 
setUp() 
testEmptyCollection() 
setUp() 
testOneItemCollection() 
The ordering of test-method invocations is not guaranteed, so testOneItemCollection() might be executed before testEmptyCollection(). But it doesn't matter, because each method gets its own instance of the collection.
Although JUnit provides a new instance of the fixture objects for each test method, if you allocate any external resources in a @Before method, you should release them after the test runs by annotating a method with @After. The JUnit framework automatically invokes any @After methods after each test is run. For example:
<pre>
package junitfaq;

import org.junit.*;
import static org.junit.Assert.*;
import java.io.*;

public class OutputTest {

private File output;

@Before
public void createOutputFile() {
output = new File(...);
}

@After
public void deleteOutputFile() {
output.delete();
}

@Test
public void testSomethingWithFile() {
...
}
}
</pre>
With this test, the methods will execute in the following order:

* createOutputFile()
* testSomethingWithFile()
* deleteOutputFile()
 

=== To Test a method that doesnot return anything ===
If a method doesn't return a value, it might have some side effect. Actually, if it doesn't return a value AND doesn't have a side effect, it isn't doing anything.
There may be a way to verify that the side effect actually occurred as expected. For example, consider the add() method in the Collection classes. There are ways of verifying that the side effect happened (i.e. the object was added). You can check the size and assert that it is what is expected:

<pre>
public void testCollectionAdd() {
Collection collection = new ArrayList();
assertEquals(0, collection.size());
collection.add("itemA");
assertEquals(1, collection.size());
collection.add("itemB");
assertEquals(2, collection.size());
}
</pre>
 

=== To test an expected/unexpected exception ===
* Case of expected exception
Add the optional expected attribute to the @Test annotation. The following is an example test that passes when the expected IndexOutOfBoundsException is raised:
<pre>
@Test(expected=IndexOutOfBoundsException.class)
public void testIndexOutOfBoundsException() {
ArrayList emptyList = new ArrayList();
Object o = emptyList.get(0);
}
</pre>
* Case of unexpected exception
Declare the exception in the throws clause of the test method and don't catch the exception within the test method. Uncaught exceptions will cause the test to fail with an error.
The following is an example test that fails when the IndexOutOfBoundsException is raised:
<pre>
@Test
public void testIndexOutOfBoundsExceptionNotRaised()
throws IndexOutOfBoundsException {

ArrayList emptyList = new ArrayList();
Object o = emptyList.get(0);
}
</pre>
 

=== To Test protected/private methods ===
* Case for protected methods
Place your tests in the same package as the classes under test.
* Case for private methods
Testing private methods may be an indication that those methods should be moved into another class to promote reusability.
 

=== Conditions to test get() and set() methods ===
Unit tests are intended to alleviate fear that something might break. If you think a get() or set() method could reasonably break, or has in fact contributed to a defect, then by all means write a test.
In short, test until you're confident. What you choose to test is subjective, based on your experiences and confidence level. Remember to be practical and maximize your testing investment.
 

=== To run setUp() and tearDown() code once for all tests ===

You can add a @BeforeClass annotation to a method to be run before all the tests in a class, and a @AfterClass annotation to a method to be run after all the tests in a class. Here's an example:

<pre>
package junitfaq;

import org.junit.*;
import static org.junit.Assert.*;
import java.util.*;

public class SimpleTest {

private Collection collection;

@BeforeClass
public static void oneTimeSetUp() {
// one-time initialization code
}

@AfterClass
public static void oneTimeTearDown() {
// one-time cleanup code
}

@Before
public void setUp() {
collection = new ArrayList();
}

@After
public void tearDown() {
collection.clear();
}

@Test
public void testEmptyCollection() {
assertTrue(collection.isEmpty());
}

@Test
public void testOneItemCollection() {
collection.add("itemA");
assertEquals(1, collection.size());
}
}
</pre>
Given this test, the methods will execute in the following order:

*oneTimeSetUp()
*setUp()
*testEmptyCollection()
*tearDown()
*setUp()
*testOneItemCollection()
*tearDown()
*oneTimeTearDown()
 

==Conclusion==
By following the guidelines given in this articles, one can write a good unit test using junit, which is as important as writing good quality code. 
A good quality unit test will take care of all classes, boundary conditions, domain data and functionality. 
A good test can be creative to explore all possibilities, thinking out of box. 
Finally automating the test using tool like junit which is in the native java language itself helps in saving manual intervention and time/money. 

==References==

* http://articles.techrepublic.com.com/5100-10878_11-1027676.html
* http://msdn.microsoft.com/en-us/library/aa292197%28VS.71%29.asp
* http://junit.sourceforge.net/doc/cookbook/cookbook.htm
* http://junit.sourceforge.net/doc/faq/faq.htm#overview
* http://clarkware.com/articles/JUnitPrimer.html#usage
* http://users.csc.calpoly.edu/~jdalbey/205/Resources/junitQuickStart.html
* http://www.cis.upenn.edu/~matuszek/cit591-2004/Lectures/
* http://en.wikipedia.org/wiki/JUnit
* http://www.laliluna.de/eclipse-junit-testing-tutorial.html
* http://junit.sourceforge.net/doc/faq/faq.htm

-------------------------------------------------------

CSC/ECE 517 Fall 2009/wiki1a 1 JunitTest

2009-09-08T19:04:10Z

Wolverine: /* Step 4: Running the Test */

'''Writing Effective JUnit Test Cases''' 
----

''JUnit is a testing framework aimed at making unit testing easy by simplifying the writing of test cases and by providing automated running of tests and test suites.''

The objective of this document is to provide a repository of rules that can be used in-order to write an effective Junit test.
This doc also discusses various sites and suggest which are the best sites to read for an overview of the topic and to understand the different philosophies of test-case design.

==Introduction==

=== Unit Testing Overview ===

The primary goal of unit testing is to take the smallest piece of testable software in the application, isolate it from the remainder of the code, and determine whether it behaves exactly as you expect.

'''Test Case''' 
It describes a scenario that can be exercised through the application. 
Each test case is divided into two parts: input and expected output. 
The input part lists all the test case statements that create variables or assign values to variables. 
The expected output part indicates the expected results; it shows either assertions or the message 'no exception' (when no assertions exist). 

The main issue in constructing a unit test is deciding the scope of test cases. 
If the scope is too narrow, then the tests will be trivial and the objects might pass the tests, but there will be no design of their interactions and interactions of objects are important for object oriented design. 
On the other hand if the scope is too broad, then there is a high chance that not every component of the new code will get tested. 
The programmer is then reduced to testing-by-poking-around, which is not an effective test strategy. 

=== JUnit Overview ===
Non-automated testing is usually like this: 
* An expression is used in a debugger, you can change debug expressions without recompiling, and you can wait to decide what to write until you have seen the running objects. 
* Expressions are tested as statements which print to the standard output stream. 
But its not preferred because: 
* They require human judgment to analyze their results. 
* They are cumbersome, non repeatable - you can only execute one debug expression at a time and a program with too many print statements causes the dreaded "Scroll Blindness". 
On the upper hand, JUnit tests, which uses the automated framework does not require human judgment to interpret, and it is easy to run many of them at the same time.
 
When you need to test something, here is what you do: 
* Annotate a method with @org.junit.Test 
* When you want to check a value, import org.junit.Assert.* statically, call assertTrue() and pass a boolean that is true if the test succeeds 
'''So what exactly is JUnit ?? ''' 
It is a open-source unit testing framework for Java and provides a way to organize test data and perform repeatable test execution. 
In JUnit, one has to write Java code, called a test class, that describes test data, invokes the methods to be tested, and determines test results. 
JUnit was originally written by Erich Gamma and Kent Beck. 
The official JUnit home page is http://junit.org. 
JUnit is Open Source Software, released under IBM's Common Public License Version 0.5 and hosted on SourceForge. 
It is an instance of the xUnit architecture for unit testing frameworks. JUnit features include: 
* Assertions for testing expected results 
* Test fixtures for sharing common test data 
* Test runners for running tests 
'''JUnit mailing lists and forums''' 
[http://groups.yahoo.com/group/junit/ JUnit user list] 
[http://lists.sourceforge.net/lists/listinfo/junit-announce JUnit announcements] 
[http://lists.sourceforge.net/lists/listinfo/junit-devel JUnit developer list] 
'''JUnit official documentation''' 
[http://junit.sourceforge.net/doc/testinfected/testing.htm JUnit Test Infected: Programmers Love Writing Tests] 
[http://junit.sourceforge.net/doc/cookbook/cookbook.htm JUnit Cookbook] 
[http://junit.sourceforge.net/doc/cookstour/cookstour.htm JUnit - A Cook's Tour] 
[http://junit.sourceforge.net/doc/faq/faq.htm JUnit FAQ] 
Although JUnit testing costs some time and money, but unit testing provides some crucial advantages, viz: 
Automation of the testing process 
Reduces difficulties of discovering errors contained in more complex pieces of the application 
Test coverage is often enhanced because attention is given to each unit. 
For example, 
if you have two units and decide it would be more cost effective to glue them together and initially test them as an integrated unit, an error could occur in a variety of places, now: 
* Is the error due to a defect in unit 1? 
* Is the error due to a defect in unit 2? 
* Is the error due to defects in both units? 
* Is the error due to a defect in the interface between the units? 
* Is the error due to a defect in the test? 
Finding the error (or errors) in the integrated module is much more complicated than first isolating the units, testing each, then integrating them and testing the whole. 
 

== Websites to lookout ==
These are some of the best webpages which will help you in getting more description as well as details about Junit.
 Also it will help you understand the test case design philosophy. 
=== For Overview ===
* Junit testing basics: 
http://articles.techrepublic.com.com/5100-10878_11-1027676.html

* Basics of Junit: 
http://junit.sourceforge.net/doc/cookbook/cookbook.htm
http://junit.sourceforge.net/doc/faq/faq.htm#overview

=== For Ideas on test case design ===
* For successful test automation: 
http://www.io.com/~wazmo/papers/seven_steps.html

* Unit testing principles: 
http://www.acm.org/ubiquity/views/t_burns_1.html

* For test suite effectiveness: 
http://java.sys-con.com/node/299945
 

== How to get started ==
=== Step 1: Installing JUnit ===

* Download latest version of JUnit from "http://sourceforge.net/projects/junit/files/". 
* Then install JUnit on your platform of choice: 
Windows 
To install JUnit on Windows, follow these steps: 
* Unzip the junit.zip distribution file to a directory referred to as %JUNIT_HOME%. 
* Add JUnit to the classpath: 
<pre>set CLASSPATH=%JUNIT_HOME%\junit.jar</pre>
'''Unix (bash)''' 
To install JUnit on Unix, follow these steps: 
* Unzip the junit.zip distribution file to a directory referred to as $JUNIT_HOME. 
* Add JUnit to the classpath: 
<pre>export CLASSPATH=$JUNIT_HOME/junit.jar</pre>

=== Step 2: Writing a Test Case ===
To write a test case, follow these steps: 

* Implement a class derived from TestCase, a base class provided by JUnit. 
public class BooksCartTest extends TestCase
* Be sure the test class belongs to the same package as that of the unit you wish to test 
* Override the setUp() method to initialize object(s) under test. 
* Optionally override the tearDown() method to release object(s) under test. 
* Define one or more public testXXX() methods that exercise the object(s) under test and assert expected results. 
The following is an example test case: 
<pre>
import junit.framework.TestCase;

public class BooksCartTest extends TestCase {

private BooksCart cart1;
private BooksCart cart2;

/**
* Sets up the test fixture.
*
* Called before every test case method.
*/
protected void setUp() {

cart1 = new BooksCart(6,8);
cart2 = new BooksCart(7,10);
}

/**
* Tears down the test fixture.
*
* Called after every test case method.
*/
protected void tearDown() {
// release objects under test here, if necessary
}

/**
* Tests emptying the cart.
*/
public void testEmpty() {

cart1.empty();
cart2.empty();
assertEquals(cart1, new BooksCart(3, 9));
assertTrue(!cart2.equals(cart1));
}
}
</pre>
Methods used in JUnit: 
* An assert method is a JUnit method that performs a test, and throws an AssertionFailedError if the test fails 
* static void assertTrue(boolean test) 
static void assertTrue(String message, boolean test)
- Throws an AssertionFailedError if the test fails 
- The optional message is included in the Error 
* static void assertFalse(boolean test) 
static void assertFalse(String message, boolean test)
- Throws an AssertionFailedError if the test fails 

=== Step 3: Writing a Test Suite ===
Next, we'll write a test suite that includes several test cases. The test suite will allow us to run all of its test cases in one fell swoop. 
'''To write a test suite, follow these steps:''' 
* Write a Java class that defines a static suite() factory method that creates a TestSuite containing all the tests. 
* Optionally define a main() method that runs the TestSuite in batch mode. 

The following is an example test suite: 
<pre>
import junit.framework.Test;
import junit.framework.TestSuite;

public class BooksCartTestSuite {

public static Test suite() {

TestSuite suite = new TestSuite();

//
// The BooksCartTest we created above.
//
suite.addTestSuite(BooksCartTest.class);

//
// Another example test suite of tests.
//
suite.addTest(CreditCardTestSuite.suite());

//
// Add more tests here
//

return suite;
}

/**
* Runs the test suite using the textual runner.
*/
public static void main(String[] args) {
junit.textui.TestRunner.run(suite());
}
}
</pre>

=== Step 4: Running the Test ===
Now that we've written a test suite containing a collection of test cases and other test suites, we can run either the test suite or any of its test cases individually. Running a TestSuite will automatically run all of its subordinate TestCase instances and TestSuite instances. Running a TestCase will automatically invoke all of its public testXXX() methods.
JUnit provides both a textual and a graphical user interface. Both user interfaces indicate how many tests were run, any errors or failures, and a simple completion status. The simplicity of the user interfaces is the key to running tests quickly. You should be able to run your tests and know the test status with a glance, much like you do with a compiler.
To run our test case using the textual user interface, use: 
<pre>java junit.textui.TestRunner BooksCartTest </pre>
The textual user interface displays "OK" if all the tests passed and failure messages if any of the tests failed. 
To run the test case using the graphical user interface, use: 
<pre>java junit.swingui.TestRunner BooksCartTest </pre>
The graphical user interface displays a Swing window with a green progress bar if all the tests passed or a red progress bar if any of the tests failed. 
The BooksCartTest Suite can be run similarly: 
<pre>java junit.swingui.TestRunner BooksCartTestSuite</pre>
 

== Rules for designing effective JUnit Test cases ==
* Identify and assemble a list of all the actions that your program should be able to perform. use cases,nonfunctional requirements specifications, test case specifications, user interface design documents, mockups, user profiles, and various additional artifacts.
* Identify the code's entry points - central pieces of code that exercise the functionality that the code as a whole is designed to undertake.
* Pair entry points with the use cases that they implement.
* Create test cases by applying the initialize/work/check procedure.
** Initialize: Create the environment that the test expects to run in. The initialization code can either be in the beginning of the test or in the setUp() method.
** Work: Call the code that is being tested, capturing any interesting output and recording any interesting statistics.
** Check: Use assert statements to ensure that the code worked as expected.
* Develop runtime event diagrams and use them to facilitate testing.
* Follow KISS rule:It's a bad idea to keep the input source name and expression in the test case. Some items (server names, usernames and passwords, etc.) should not live in the test files, which should be configurable for the specific deployment. Rather, design the test cases to facilitate separation of test drivers and test data, test driver reuse over a larger set of data, and test data reuse over a larger set of test drivers. On the other hand, don't over-architect a simple test case implementation. Typically, the test case specification already defines most of the system states and allows parameter descriptions for a scenario, so there's no point in making everything parameterizable in the test implementation.
 

==Rules for coding effective JUnit Tests==

=== Using Test Fixture for a common set of objects ===
Using a test fixture avoids duplicating the code necessary to initialize (and cleanup) the common objects.
Tests can use the objects (variables) in a test fixture, with each test invoking different methods on objects in the fixture and asserting different expected results. Each test runs in its own test fixture to isolate tests from the changes made by other tests. That is, tests don't share the state of objects in the test fixture. Because the tests are isolated, they can be run in any order.
To create a test fixture, declare instance variables for the common objects. Initialize these objects in a public void method annotated with @Before. The JUnit framework automatically invokes any @Before methods before each test is run.
The following example shows a test fixture with a common Collection object.
<pre>
package junitfaq;

import org.junit.*;
import static org.junit.Assert.*;
import java.util.*;

public class SimpleTest {

private Collection<Object> collection;

@Before
public void setUp() {
collection = new ArrayList<Object>();
}

@Test
public void testEmptyCollection() {
assertTrue(collection.isEmpty());
}

@Test
public void testOneItemCollection() {
collection.add("itemA");
assertEquals(1, collection.size());
}
}
</pre>
Given this test, the methods might execute in the following order: 
setUp() 
testEmptyCollection() 
setUp() 
testOneItemCollection() 
The ordering of test-method invocations is not guaranteed, so testOneItemCollection() might be executed before testEmptyCollection(). But it doesn't matter, because each method gets its own instance of the collection.
Although JUnit provides a new instance of the fixture objects for each test method, if you allocate any external resources in a @Before method, you should release them after the test runs by annotating a method with @After. The JUnit framework automatically invokes any @After methods after each test is run. For example:
<pre>
package junitfaq;

import org.junit.*;
import static org.junit.Assert.*;
import java.io.*;

public class OutputTest {

private File output;

@Before
public void createOutputFile() {
output = new File(...);
}

@After
public void deleteOutputFile() {
output.delete();
}

@Test
public void testSomethingWithFile() {
...
}
}
</pre>
With this test, the methods will execute in the following order:

* createOutputFile()
* testSomethingWithFile()
* deleteOutputFile()
 

=== To Test a method that doesnot return anything ===
If a method doesn't return a value, it might have some side effect. Actually, if it doesn't return a value AND doesn't have a side effect, it isn't doing anything.
There may be a way to verify that the side effect actually occurred as expected. For example, consider the add() method in the Collection classes. There are ways of verifying that the side effect happened (i.e. the object was added). You can check the size and assert that it is what is expected:

<pre>
public void testCollectionAdd() {
Collection collection = new ArrayList();
assertEquals(0, collection.size());
collection.add("itemA");
assertEquals(1, collection.size());
collection.add("itemB");
assertEquals(2, collection.size());
}
</pre>
 

=== To test an expected/unexpected exception ===
* Case of expected exception
Add the optional expected attribute to the @Test annotation. The following is an example test that passes when the expected IndexOutOfBoundsException is raised:
<pre>
@Test(expected=IndexOutOfBoundsException.class)
public void testIndexOutOfBoundsException() {
ArrayList emptyList = new ArrayList();
Object o = emptyList.get(0);
}
</pre>
* Case of unexpected exception
Declare the exception in the throws clause of the test method and don't catch the exception within the test method. Uncaught exceptions will cause the test to fail with an error.
The following is an example test that fails when the IndexOutOfBoundsException is raised:
<pre>
@Test
public void testIndexOutOfBoundsExceptionNotRaised()
throws IndexOutOfBoundsException {

ArrayList emptyList = new ArrayList();
Object o = emptyList.get(0);
}
</pre>
 

=== To Test protected/private methods ===
* Case for protected methods
Place your tests in the same package as the classes under test.
* Case for private methods
Testing private methods may be an indication that those methods should be moved into another class to promote reusability.
 

=== Conditions to test get() and set() methods ===
Unit tests are intended to alleviate fear that something might break. If you think a get() or set() method could reasonably break, or has in fact contributed to a defect, then by all means write a test.
In short, test until you're confident. What you choose to test is subjective, based on your experiences and confidence level. Remember to be practical and maximize your testing investment.
 

=== To run setUp() and tearDown() code once for all tests ===

You can add a @BeforeClass annotation to a method to be run before all the tests in a class, and a @AfterClass annotation to a method to be run after all the tests in a class. Here's an example:

<pre>
package junitfaq;

import org.junit.*;
import static org.junit.Assert.*;
import java.util.*;

public class SimpleTest {

private Collection collection;

@BeforeClass
public static void oneTimeSetUp() {
// one-time initialization code
}

@AfterClass
public static void oneTimeTearDown() {
// one-time cleanup code
}

@Before
public void setUp() {
collection = new ArrayList();
}

@After
public void tearDown() {
collection.clear();
}

@Test
public void testEmptyCollection() {
assertTrue(collection.isEmpty());
}

@Test
public void testOneItemCollection() {
collection.add("itemA");
assertEquals(1, collection.size());
}
}
</pre>
Given this test, the methods will execute in the following order:

*oneTimeSetUp()
*setUp()
*testEmptyCollection()
*tearDown()
*setUp()
*testOneItemCollection()
*tearDown()
*oneTimeTearDown()
 

==Conclusion==
By following the guidelines given in this articles, one can write a good unit test using junit, which is as important as writing good quality code. 
A good quality unit test will take care of all classes, boundary conditions, domain data and functionality. 
A good test can be creative to explore all possibilities, thinking out of box. 
Finally automating the test using tool like junit which is in the native java language itself helps in saving manual intervention and time/money. 

==References==

* http://articles.techrepublic.com.com/5100-10878_11-1027676.html
* http://msdn.microsoft.com/en-us/library/aa292197%28VS.71%29.asp
* http://junit.sourceforge.net/doc/cookbook/cookbook.htm
* http://junit.sourceforge.net/doc/faq/faq.htm#overview
* http://clarkware.com/articles/JUnitPrimer.html#usage
* http://users.csc.calpoly.edu/~jdalbey/205/Resources/junitQuickStart.html
* http://www.cis.upenn.edu/~matuszek/cit591-2004/Lectures/
* http://en.wikipedia.org/wiki/JUnit
* http://www.laliluna.de/eclipse-junit-testing-tutorial.html
* http://junit.sourceforge.net/doc/faq/faq.htm

-------------------------------------------------------

CSC/ECE 517 Fall 2009/wiki1a 1 JunitTest

2009-09-08T19:03:54Z

Wolverine: /* Step 4: Running the Test */

'''Writing Effective JUnit Test Cases''' 
----

''JUnit is a testing framework aimed at making unit testing easy by simplifying the writing of test cases and by providing automated running of tests and test suites.''

The objective of this document is to provide a repository of rules that can be used in-order to write an effective Junit test.
This doc also discusses various sites and suggest which are the best sites to read for an overview of the topic and to understand the different philosophies of test-case design.

==Introduction==

=== Unit Testing Overview ===

The primary goal of unit testing is to take the smallest piece of testable software in the application, isolate it from the remainder of the code, and determine whether it behaves exactly as you expect.

'''Test Case''' 
It describes a scenario that can be exercised through the application. 
Each test case is divided into two parts: input and expected output. 
The input part lists all the test case statements that create variables or assign values to variables. 
The expected output part indicates the expected results; it shows either assertions or the message 'no exception' (when no assertions exist). 

The main issue in constructing a unit test is deciding the scope of test cases. 
If the scope is too narrow, then the tests will be trivial and the objects might pass the tests, but there will be no design of their interactions and interactions of objects are important for object oriented design. 
On the other hand if the scope is too broad, then there is a high chance that not every component of the new code will get tested. 
The programmer is then reduced to testing-by-poking-around, which is not an effective test strategy. 

=== JUnit Overview ===
Non-automated testing is usually like this: 
* An expression is used in a debugger, you can change debug expressions without recompiling, and you can wait to decide what to write until you have seen the running objects. 
* Expressions are tested as statements which print to the standard output stream. 
But its not preferred because: 
* They require human judgment to analyze their results. 
* They are cumbersome, non repeatable - you can only execute one debug expression at a time and a program with too many print statements causes the dreaded "Scroll Blindness". 
On the upper hand, JUnit tests, which uses the automated framework does not require human judgment to interpret, and it is easy to run many of them at the same time.
 
When you need to test something, here is what you do: 
* Annotate a method with @org.junit.Test 
* When you want to check a value, import org.junit.Assert.* statically, call assertTrue() and pass a boolean that is true if the test succeeds 
'''So what exactly is JUnit ?? ''' 
It is a open-source unit testing framework for Java and provides a way to organize test data and perform repeatable test execution. 
In JUnit, one has to write Java code, called a test class, that describes test data, invokes the methods to be tested, and determines test results. 
JUnit was originally written by Erich Gamma and Kent Beck. 
The official JUnit home page is http://junit.org. 
JUnit is Open Source Software, released under IBM's Common Public License Version 0.5 and hosted on SourceForge. 
It is an instance of the xUnit architecture for unit testing frameworks. JUnit features include: 
* Assertions for testing expected results 
* Test fixtures for sharing common test data 
* Test runners for running tests 
'''JUnit mailing lists and forums''' 
[http://groups.yahoo.com/group/junit/ JUnit user list] 
[http://lists.sourceforge.net/lists/listinfo/junit-announce JUnit announcements] 
[http://lists.sourceforge.net/lists/listinfo/junit-devel JUnit developer list] 
'''JUnit official documentation''' 
[http://junit.sourceforge.net/doc/testinfected/testing.htm JUnit Test Infected: Programmers Love Writing Tests] 
[http://junit.sourceforge.net/doc/cookbook/cookbook.htm JUnit Cookbook] 
[http://junit.sourceforge.net/doc/cookstour/cookstour.htm JUnit - A Cook's Tour] 
[http://junit.sourceforge.net/doc/faq/faq.htm JUnit FAQ] 
Although JUnit testing costs some time and money, but unit testing provides some crucial advantages, viz: 
Automation of the testing process 
Reduces difficulties of discovering errors contained in more complex pieces of the application 
Test coverage is often enhanced because attention is given to each unit. 
For example, 
if you have two units and decide it would be more cost effective to glue them together and initially test them as an integrated unit, an error could occur in a variety of places, now: 
* Is the error due to a defect in unit 1? 
* Is the error due to a defect in unit 2? 
* Is the error due to defects in both units? 
* Is the error due to a defect in the interface between the units? 
* Is the error due to a defect in the test? 
Finding the error (or errors) in the integrated module is much more complicated than first isolating the units, testing each, then integrating them and testing the whole. 
 

== Websites to lookout ==
These are some of the best webpages which will help you in getting more description as well as details about Junit.
 Also it will help you understand the test case design philosophy. 
=== For Overview ===
* Junit testing basics: 
http://articles.techrepublic.com.com/5100-10878_11-1027676.html

* Basics of Junit: 
http://junit.sourceforge.net/doc/cookbook/cookbook.htm
http://junit.sourceforge.net/doc/faq/faq.htm#overview

=== For Ideas on test case design ===
* For successful test automation: 
http://www.io.com/~wazmo/papers/seven_steps.html

* Unit testing principles: 
http://www.acm.org/ubiquity/views/t_burns_1.html

* For test suite effectiveness: 
http://java.sys-con.com/node/299945
 

== How to get started ==
=== Step 1: Installing JUnit ===

* Download latest version of JUnit from "http://sourceforge.net/projects/junit/files/". 
* Then install JUnit on your platform of choice: 
Windows 
To install JUnit on Windows, follow these steps: 
* Unzip the junit.zip distribution file to a directory referred to as %JUNIT_HOME%. 
* Add JUnit to the classpath: 
<pre>set CLASSPATH=%JUNIT_HOME%\junit.jar</pre>
'''Unix (bash)''' 
To install JUnit on Unix, follow these steps: 
* Unzip the junit.zip distribution file to a directory referred to as $JUNIT_HOME. 
* Add JUnit to the classpath: 
<pre>export CLASSPATH=$JUNIT_HOME/junit.jar</pre>

=== Step 2: Writing a Test Case ===
To write a test case, follow these steps: 

* Implement a class derived from TestCase, a base class provided by JUnit. 
public class BooksCartTest extends TestCase
* Be sure the test class belongs to the same package as that of the unit you wish to test 
* Override the setUp() method to initialize object(s) under test. 
* Optionally override the tearDown() method to release object(s) under test. 
* Define one or more public testXXX() methods that exercise the object(s) under test and assert expected results. 
The following is an example test case: 
<pre>
import junit.framework.TestCase;

public class BooksCartTest extends TestCase {

private BooksCart cart1;
private BooksCart cart2;

/**
* Sets up the test fixture.
*
* Called before every test case method.
*/
protected void setUp() {

cart1 = new BooksCart(6,8);
cart2 = new BooksCart(7,10);
}

/**
* Tears down the test fixture.
*
* Called after every test case method.
*/
protected void tearDown() {
// release objects under test here, if necessary
}

/**
* Tests emptying the cart.
*/
public void testEmpty() {

cart1.empty();
cart2.empty();
assertEquals(cart1, new BooksCart(3, 9));
assertTrue(!cart2.equals(cart1));
}
}
</pre>
Methods used in JUnit: 
* An assert method is a JUnit method that performs a test, and throws an AssertionFailedError if the test fails 
* static void assertTrue(boolean test) 
static void assertTrue(String message, boolean test)
- Throws an AssertionFailedError if the test fails 
- The optional message is included in the Error 
* static void assertFalse(boolean test) 
static void assertFalse(String message, boolean test)
- Throws an AssertionFailedError if the test fails 

=== Step 3: Writing a Test Suite ===
Next, we'll write a test suite that includes several test cases. The test suite will allow us to run all of its test cases in one fell swoop. 
'''To write a test suite, follow these steps:''' 
* Write a Java class that defines a static suite() factory method that creates a TestSuite containing all the tests. 
* Optionally define a main() method that runs the TestSuite in batch mode. 

The following is an example test suite: 
<pre>
import junit.framework.Test;
import junit.framework.TestSuite;

public class BooksCartTestSuite {

public static Test suite() {

TestSuite suite = new TestSuite();

//
// The BooksCartTest we created above.
//
suite.addTestSuite(BooksCartTest.class);

//
// Another example test suite of tests.
//
suite.addTest(CreditCardTestSuite.suite());

//
// Add more tests here
//

return suite;
}

/**
* Runs the test suite using the textual runner.
*/
public static void main(String[] args) {
junit.textui.TestRunner.run(suite());
}
}
</pre>

=== Step 4: Running the Test ===
Now that we've written a test suite containing a collection of test cases and other test suites, we can run either the test suite or any of its test cases individually. Running a TestSuite will automatically run all of its subordinate TestCase instances and TestSuite instances. Running a TestCase will automatically invoke all of its public testXXX() methods.
JUnit provides both a textual and a graphical user interface. Both user interfaces indicate how many tests were run, any errors or failures, and a simple completion status. The simplicity of the user interfaces is the key to running tests quickly. You should be able to run your tests and know the test status with a glance, much like you do with a compiler.
To run our test case using the textual user interface, use: 
<pre>java junit.textui.TestRunner BooksCartTest </pre>
The textual user interface displays "OK" if all the tests passed and failure messages if any of the tests failed. 
To run the test case using the graphical user interface, use: 
<pre>java junit.swingui.TestRunner BooksCartTest </pre> 
The graphical user interface displays a Swing window with a green progress bar if all the tests passed or a red progress bar if any of the tests failed. 
The BooksCartTest Suite can be run similarly: 
<pre>java junit.swingui.TestRunner BooksCartTestSuite</pre>
 

== Rules for designing effective JUnit Test cases ==
* Identify and assemble a list of all the actions that your program should be able to perform. use cases,nonfunctional requirements specifications, test case specifications, user interface design documents, mockups, user profiles, and various additional artifacts.
* Identify the code's entry points - central pieces of code that exercise the functionality that the code as a whole is designed to undertake.
* Pair entry points with the use cases that they implement.
* Create test cases by applying the initialize/work/check procedure.
** Initialize: Create the environment that the test expects to run in. The initialization code can either be in the beginning of the test or in the setUp() method.
** Work: Call the code that is being tested, capturing any interesting output and recording any interesting statistics.
** Check: Use assert statements to ensure that the code worked as expected.
* Develop runtime event diagrams and use them to facilitate testing.
* Follow KISS rule:It's a bad idea to keep the input source name and expression in the test case. Some items (server names, usernames and passwords, etc.) should not live in the test files, which should be configurable for the specific deployment. Rather, design the test cases to facilitate separation of test drivers and test data, test driver reuse over a larger set of data, and test data reuse over a larger set of test drivers. On the other hand, don't over-architect a simple test case implementation. Typically, the test case specification already defines most of the system states and allows parameter descriptions for a scenario, so there's no point in making everything parameterizable in the test implementation.
 

==Rules for coding effective JUnit Tests==

=== Using Test Fixture for a common set of objects ===
Using a test fixture avoids duplicating the code necessary to initialize (and cleanup) the common objects.
Tests can use the objects (variables) in a test fixture, with each test invoking different methods on objects in the fixture and asserting different expected results. Each test runs in its own test fixture to isolate tests from the changes made by other tests. That is, tests don't share the state of objects in the test fixture. Because the tests are isolated, they can be run in any order.
To create a test fixture, declare instance variables for the common objects. Initialize these objects in a public void method annotated with @Before. The JUnit framework automatically invokes any @Before methods before each test is run.
The following example shows a test fixture with a common Collection object.
<pre>
package junitfaq;

import org.junit.*;
import static org.junit.Assert.*;
import java.util.*;

public class SimpleTest {

private Collection<Object> collection;

@Before
public void setUp() {
collection = new ArrayList<Object>();
}

@Test
public void testEmptyCollection() {
assertTrue(collection.isEmpty());
}

@Test
public void testOneItemCollection() {
collection.add("itemA");
assertEquals(1, collection.size());
}
}
</pre>
Given this test, the methods might execute in the following order: 
setUp() 
testEmptyCollection() 
setUp() 
testOneItemCollection() 
The ordering of test-method invocations is not guaranteed, so testOneItemCollection() might be executed before testEmptyCollection(). But it doesn't matter, because each method gets its own instance of the collection.
Although JUnit provides a new instance of the fixture objects for each test method, if you allocate any external resources in a @Before method, you should release them after the test runs by annotating a method with @After. The JUnit framework automatically invokes any @After methods after each test is run. For example:
<pre>
package junitfaq;

import org.junit.*;
import static org.junit.Assert.*;
import java.io.*;

public class OutputTest {

private File output;

@Before
public void createOutputFile() {
output = new File(...);
}

@After
public void deleteOutputFile() {
output.delete();
}

@Test
public void testSomethingWithFile() {
...
}
}
</pre>
With this test, the methods will execute in the following order:

* createOutputFile()
* testSomethingWithFile()
* deleteOutputFile()
 

=== To Test a method that doesnot return anything ===
If a method doesn't return a value, it might have some side effect. Actually, if it doesn't return a value AND doesn't have a side effect, it isn't doing anything.
There may be a way to verify that the side effect actually occurred as expected. For example, consider the add() method in the Collection classes. There are ways of verifying that the side effect happened (i.e. the object was added). You can check the size and assert that it is what is expected:

<pre>
public void testCollectionAdd() {
Collection collection = new ArrayList();
assertEquals(0, collection.size());
collection.add("itemA");
assertEquals(1, collection.size());
collection.add("itemB");
assertEquals(2, collection.size());
}
</pre>
 

=== To test an expected/unexpected exception ===
* Case of expected exception
Add the optional expected attribute to the @Test annotation. The following is an example test that passes when the expected IndexOutOfBoundsException is raised:
<pre>
@Test(expected=IndexOutOfBoundsException.class)
public void testIndexOutOfBoundsException() {
ArrayList emptyList = new ArrayList();
Object o = emptyList.get(0);
}
</pre>
* Case of unexpected exception
Declare the exception in the throws clause of the test method and don't catch the exception within the test method. Uncaught exceptions will cause the test to fail with an error.
The following is an example test that fails when the IndexOutOfBoundsException is raised:
<pre>
@Test
public void testIndexOutOfBoundsExceptionNotRaised()
throws IndexOutOfBoundsException {

ArrayList emptyList = new ArrayList();
Object o = emptyList.get(0);
}
</pre>
 

=== To Test protected/private methods ===
* Case for protected methods
Place your tests in the same package as the classes under test.
* Case for private methods
Testing private methods may be an indication that those methods should be moved into another class to promote reusability.
 

=== Conditions to test get() and set() methods ===
Unit tests are intended to alleviate fear that something might break. If you think a get() or set() method could reasonably break, or has in fact contributed to a defect, then by all means write a test.
In short, test until you're confident. What you choose to test is subjective, based on your experiences and confidence level. Remember to be practical and maximize your testing investment.
 

=== To run setUp() and tearDown() code once for all tests ===

You can add a @BeforeClass annotation to a method to be run before all the tests in a class, and a @AfterClass annotation to a method to be run after all the tests in a class. Here's an example:

<pre>
package junitfaq;

import org.junit.*;
import static org.junit.Assert.*;
import java.util.*;

public class SimpleTest {

private Collection collection;

@BeforeClass
public static void oneTimeSetUp() {
// one-time initialization code
}

@AfterClass
public static void oneTimeTearDown() {
// one-time cleanup code
}

@Before
public void setUp() {
collection = new ArrayList();
}

@After
public void tearDown() {
collection.clear();
}

@Test
public void testEmptyCollection() {
assertTrue(collection.isEmpty());
}

@Test
public void testOneItemCollection() {
collection.add("itemA");
assertEquals(1, collection.size());
}
}
</pre>
Given this test, the methods will execute in the following order:

*oneTimeSetUp()
*setUp()
*testEmptyCollection()
*tearDown()
*setUp()
*testOneItemCollection()
*tearDown()
*oneTimeTearDown()
 

==Conclusion==
By following the guidelines given in this articles, one can write a good unit test using junit, which is as important as writing good quality code. 
A good quality unit test will take care of all classes, boundary conditions, domain data and functionality. 
A good test can be creative to explore all possibilities, thinking out of box. 
Finally automating the test using tool like junit which is in the native java language itself helps in saving manual intervention and time/money. 

==References==

* http://articles.techrepublic.com.com/5100-10878_11-1027676.html
* http://msdn.microsoft.com/en-us/library/aa292197%28VS.71%29.asp
* http://junit.sourceforge.net/doc/cookbook/cookbook.htm
* http://junit.sourceforge.net/doc/faq/faq.htm#overview
* http://clarkware.com/articles/JUnitPrimer.html#usage
* http://users.csc.calpoly.edu/~jdalbey/205/Resources/junitQuickStart.html
* http://www.cis.upenn.edu/~matuszek/cit591-2004/Lectures/
* http://en.wikipedia.org/wiki/JUnit
* http://www.laliluna.de/eclipse-junit-testing-tutorial.html
* http://junit.sourceforge.net/doc/faq/faq.htm

-------------------------------------------------------

CSC/ECE 517 Fall 2009/wiki1a 1 JunitTest

2009-09-08T19:03:37Z

Wolverine: /* Step 4: Running the Test */

'''Writing Effective JUnit Test Cases''' 
----

''JUnit is a testing framework aimed at making unit testing easy by simplifying the writing of test cases and by providing automated running of tests and test suites.''

The objective of this document is to provide a repository of rules that can be used in-order to write an effective Junit test.
This doc also discusses various sites and suggest which are the best sites to read for an overview of the topic and to understand the different philosophies of test-case design.

==Introduction==

=== Unit Testing Overview ===

The primary goal of unit testing is to take the smallest piece of testable software in the application, isolate it from the remainder of the code, and determine whether it behaves exactly as you expect.

'''Test Case''' 
It describes a scenario that can be exercised through the application. 
Each test case is divided into two parts: input and expected output. 
The input part lists all the test case statements that create variables or assign values to variables. 
The expected output part indicates the expected results; it shows either assertions or the message 'no exception' (when no assertions exist). 

The main issue in constructing a unit test is deciding the scope of test cases. 
If the scope is too narrow, then the tests will be trivial and the objects might pass the tests, but there will be no design of their interactions and interactions of objects are important for object oriented design. 
On the other hand if the scope is too broad, then there is a high chance that not every component of the new code will get tested. 
The programmer is then reduced to testing-by-poking-around, which is not an effective test strategy. 

=== JUnit Overview ===
Non-automated testing is usually like this: 
* An expression is used in a debugger, you can change debug expressions without recompiling, and you can wait to decide what to write until you have seen the running objects. 
* Expressions are tested as statements which print to the standard output stream. 
But its not preferred because: 
* They require human judgment to analyze their results. 
* They are cumbersome, non repeatable - you can only execute one debug expression at a time and a program with too many print statements causes the dreaded "Scroll Blindness". 
On the upper hand, JUnit tests, which uses the automated framework does not require human judgment to interpret, and it is easy to run many of them at the same time.
 
When you need to test something, here is what you do: 
* Annotate a method with @org.junit.Test 
* When you want to check a value, import org.junit.Assert.* statically, call assertTrue() and pass a boolean that is true if the test succeeds 
'''So what exactly is JUnit ?? ''' 
It is a open-source unit testing framework for Java and provides a way to organize test data and perform repeatable test execution. 
In JUnit, one has to write Java code, called a test class, that describes test data, invokes the methods to be tested, and determines test results. 
JUnit was originally written by Erich Gamma and Kent Beck. 
The official JUnit home page is http://junit.org. 
JUnit is Open Source Software, released under IBM's Common Public License Version 0.5 and hosted on SourceForge. 
It is an instance of the xUnit architecture for unit testing frameworks. JUnit features include: 
* Assertions for testing expected results 
* Test fixtures for sharing common test data 
* Test runners for running tests 
'''JUnit mailing lists and forums''' 
[http://groups.yahoo.com/group/junit/ JUnit user list] 
[http://lists.sourceforge.net/lists/listinfo/junit-announce JUnit announcements] 
[http://lists.sourceforge.net/lists/listinfo/junit-devel JUnit developer list] 
'''JUnit official documentation''' 
[http://junit.sourceforge.net/doc/testinfected/testing.htm JUnit Test Infected: Programmers Love Writing Tests] 
[http://junit.sourceforge.net/doc/cookbook/cookbook.htm JUnit Cookbook] 
[http://junit.sourceforge.net/doc/cookstour/cookstour.htm JUnit - A Cook's Tour] 
[http://junit.sourceforge.net/doc/faq/faq.htm JUnit FAQ] 
Although JUnit testing costs some time and money, but unit testing provides some crucial advantages, viz: 
Automation of the testing process 
Reduces difficulties of discovering errors contained in more complex pieces of the application 
Test coverage is often enhanced because attention is given to each unit. 
For example, 
if you have two units and decide it would be more cost effective to glue them together and initially test them as an integrated unit, an error could occur in a variety of places, now: 
* Is the error due to a defect in unit 1? 
* Is the error due to a defect in unit 2? 
* Is the error due to defects in both units? 
* Is the error due to a defect in the interface between the units? 
* Is the error due to a defect in the test? 
Finding the error (or errors) in the integrated module is much more complicated than first isolating the units, testing each, then integrating them and testing the whole. 
 

== Websites to lookout ==
These are some of the best webpages which will help you in getting more description as well as details about Junit.
 Also it will help you understand the test case design philosophy. 
=== For Overview ===
* Junit testing basics: 
http://articles.techrepublic.com.com/5100-10878_11-1027676.html

* Basics of Junit: 
http://junit.sourceforge.net/doc/cookbook/cookbook.htm
http://junit.sourceforge.net/doc/faq/faq.htm#overview

=== For Ideas on test case design ===
* For successful test automation: 
http://www.io.com/~wazmo/papers/seven_steps.html

* Unit testing principles: 
http://www.acm.org/ubiquity/views/t_burns_1.html

* For test suite effectiveness: 
http://java.sys-con.com/node/299945
 

== How to get started ==
=== Step 1: Installing JUnit ===

* Download latest version of JUnit from "http://sourceforge.net/projects/junit/files/". 
* Then install JUnit on your platform of choice: 
Windows 
To install JUnit on Windows, follow these steps: 
* Unzip the junit.zip distribution file to a directory referred to as %JUNIT_HOME%. 
* Add JUnit to the classpath: 
<pre>set CLASSPATH=%JUNIT_HOME%\junit.jar</pre>
'''Unix (bash)''' 
To install JUnit on Unix, follow these steps: 
* Unzip the junit.zip distribution file to a directory referred to as $JUNIT_HOME. 
* Add JUnit to the classpath: 
<pre>export CLASSPATH=$JUNIT_HOME/junit.jar</pre>

=== Step 2: Writing a Test Case ===
To write a test case, follow these steps: 

* Implement a class derived from TestCase, a base class provided by JUnit. 
public class BooksCartTest extends TestCase
* Be sure the test class belongs to the same package as that of the unit you wish to test 
* Override the setUp() method to initialize object(s) under test. 
* Optionally override the tearDown() method to release object(s) under test. 
* Define one or more public testXXX() methods that exercise the object(s) under test and assert expected results. 
The following is an example test case: 
<pre>
import junit.framework.TestCase;

public class BooksCartTest extends TestCase {

private BooksCart cart1;
private BooksCart cart2;

/**
* Sets up the test fixture.
*
* Called before every test case method.
*/
protected void setUp() {

cart1 = new BooksCart(6,8);
cart2 = new BooksCart(7,10);
}

/**
* Tears down the test fixture.
*
* Called after every test case method.
*/
protected void tearDown() {
// release objects under test here, if necessary
}

/**
* Tests emptying the cart.
*/
public void testEmpty() {

cart1.empty();
cart2.empty();
assertEquals(cart1, new BooksCart(3, 9));
assertTrue(!cart2.equals(cart1));
}
}
</pre>
Methods used in JUnit: 
* An assert method is a JUnit method that performs a test, and throws an AssertionFailedError if the test fails 
* static void assertTrue(boolean test) 
static void assertTrue(String message, boolean test)
- Throws an AssertionFailedError if the test fails 
- The optional message is included in the Error 
* static void assertFalse(boolean test) 
static void assertFalse(String message, boolean test)
- Throws an AssertionFailedError if the test fails 

=== Step 3: Writing a Test Suite ===
Next, we'll write a test suite that includes several test cases. The test suite will allow us to run all of its test cases in one fell swoop. 
'''To write a test suite, follow these steps:''' 
* Write a Java class that defines a static suite() factory method that creates a TestSuite containing all the tests. 
* Optionally define a main() method that runs the TestSuite in batch mode. 

The following is an example test suite: 
<pre>
import junit.framework.Test;
import junit.framework.TestSuite;

public class BooksCartTestSuite {

public static Test suite() {

TestSuite suite = new TestSuite();

//
// The BooksCartTest we created above.
//
suite.addTestSuite(BooksCartTest.class);

//
// Another example test suite of tests.
//
suite.addTest(CreditCardTestSuite.suite());

//
// Add more tests here
//

return suite;
}

/**
* Runs the test suite using the textual runner.
*/
public static void main(String[] args) {
junit.textui.TestRunner.run(suite());
}
}
</pre>

=== Step 4: Running the Test ===
Now that we've written a test suite containing a collection of test cases and other test suites, we can run either the test suite or any of its test cases individually. Running a TestSuite will automatically run all of its subordinate TestCase instances and TestSuite instances. Running a TestCase will automatically invoke all of its public testXXX() methods.
JUnit provides both a textual and a graphical user interface. Both user interfaces indicate how many tests were run, any errors or failures, and a simple completion status. The simplicity of the user interfaces is the key to running tests quickly. You should be able to run your tests and know the test status with a glance, much like you do with a compiler.

To run our test case using the textual user interface, use: 
<pre>java junit.textui.TestRunner BooksCartTest </pre>
The textual user interface displays "OK" if all the tests passed and failure messages if any of the tests failed. 
To run the test case using the graphical user interface, use: 
<pre>java junit.swingui.TestRunner BooksCartTest </pre> 
The graphical user interface displays a Swing window with a green progress bar if all the tests passed or a red progress bar if any of the tests failed. 
The BooksCartTest Suite can be run similarly: 
<pre>java junit.swingui.TestRunner BooksCartTestSuite</pre>
 

== Rules for designing effective JUnit Test cases ==
* Identify and assemble a list of all the actions that your program should be able to perform. use cases,nonfunctional requirements specifications, test case specifications, user interface design documents, mockups, user profiles, and various additional artifacts.
* Identify the code's entry points - central pieces of code that exercise the functionality that the code as a whole is designed to undertake.
* Pair entry points with the use cases that they implement.
* Create test cases by applying the initialize/work/check procedure.
** Initialize: Create the environment that the test expects to run in. The initialization code can either be in the beginning of the test or in the setUp() method.
** Work: Call the code that is being tested, capturing any interesting output and recording any interesting statistics.
** Check: Use assert statements to ensure that the code worked as expected.
* Develop runtime event diagrams and use them to facilitate testing.
* Follow KISS rule:It's a bad idea to keep the input source name and expression in the test case. Some items (server names, usernames and passwords, etc.) should not live in the test files, which should be configurable for the specific deployment. Rather, design the test cases to facilitate separation of test drivers and test data, test driver reuse over a larger set of data, and test data reuse over a larger set of test drivers. On the other hand, don't over-architect a simple test case implementation. Typically, the test case specification already defines most of the system states and allows parameter descriptions for a scenario, so there's no point in making everything parameterizable in the test implementation.
 

==Rules for coding effective JUnit Tests==

=== Using Test Fixture for a common set of objects ===
Using a test fixture avoids duplicating the code necessary to initialize (and cleanup) the common objects.
Tests can use the objects (variables) in a test fixture, with each test invoking different methods on objects in the fixture and asserting different expected results. Each test runs in its own test fixture to isolate tests from the changes made by other tests. That is, tests don't share the state of objects in the test fixture. Because the tests are isolated, they can be run in any order.
To create a test fixture, declare instance variables for the common objects. Initialize these objects in a public void method annotated with @Before. The JUnit framework automatically invokes any @Before methods before each test is run.
The following example shows a test fixture with a common Collection object.
<pre>
package junitfaq;

import org.junit.*;
import static org.junit.Assert.*;
import java.util.*;

public class SimpleTest {

private Collection<Object> collection;

@Before
public void setUp() {
collection = new ArrayList<Object>();
}

@Test
public void testEmptyCollection() {
assertTrue(collection.isEmpty());
}

@Test
public void testOneItemCollection() {
collection.add("itemA");
assertEquals(1, collection.size());
}
}
</pre>
Given this test, the methods might execute in the following order: 
setUp() 
testEmptyCollection() 
setUp() 
testOneItemCollection() 
The ordering of test-method invocations is not guaranteed, so testOneItemCollection() might be executed before testEmptyCollection(). But it doesn't matter, because each method gets its own instance of the collection.
Although JUnit provides a new instance of the fixture objects for each test method, if you allocate any external resources in a @Before method, you should release them after the test runs by annotating a method with @After. The JUnit framework automatically invokes any @After methods after each test is run. For example:
<pre>
package junitfaq;

import org.junit.*;
import static org.junit.Assert.*;
import java.io.*;

public class OutputTest {

private File output;

@Before
public void createOutputFile() {
output = new File(...);
}

@After
public void deleteOutputFile() {
output.delete();
}

@Test
public void testSomethingWithFile() {
...
}
}
</pre>
With this test, the methods will execute in the following order:

* createOutputFile()
* testSomethingWithFile()
* deleteOutputFile()
 

=== To Test a method that doesnot return anything ===
If a method doesn't return a value, it might have some side effect. Actually, if it doesn't return a value AND doesn't have a side effect, it isn't doing anything.
There may be a way to verify that the side effect actually occurred as expected. For example, consider the add() method in the Collection classes. There are ways of verifying that the side effect happened (i.e. the object was added). You can check the size and assert that it is what is expected:

<pre>
public void testCollectionAdd() {
Collection collection = new ArrayList();
assertEquals(0, collection.size());
collection.add("itemA");
assertEquals(1, collection.size());
collection.add("itemB");
assertEquals(2, collection.size());
}
</pre>
 

=== To test an expected/unexpected exception ===
* Case of expected exception
Add the optional expected attribute to the @Test annotation. The following is an example test that passes when the expected IndexOutOfBoundsException is raised:
<pre>
@Test(expected=IndexOutOfBoundsException.class)
public void testIndexOutOfBoundsException() {
ArrayList emptyList = new ArrayList();
Object o = emptyList.get(0);
}
</pre>
* Case of unexpected exception
Declare the exception in the throws clause of the test method and don't catch the exception within the test method. Uncaught exceptions will cause the test to fail with an error.
The following is an example test that fails when the IndexOutOfBoundsException is raised:
<pre>
@Test
public void testIndexOutOfBoundsExceptionNotRaised()
throws IndexOutOfBoundsException {

ArrayList emptyList = new ArrayList();
Object o = emptyList.get(0);
}
</pre>
 

=== To Test protected/private methods ===
* Case for protected methods
Place your tests in the same package as the classes under test.
* Case for private methods
Testing private methods may be an indication that those methods should be moved into another class to promote reusability.
 

=== Conditions to test get() and set() methods ===
Unit tests are intended to alleviate fear that something might break. If you think a get() or set() method could reasonably break, or has in fact contributed to a defect, then by all means write a test.
In short, test until you're confident. What you choose to test is subjective, based on your experiences and confidence level. Remember to be practical and maximize your testing investment.
 

=== To run setUp() and tearDown() code once for all tests ===

You can add a @BeforeClass annotation to a method to be run before all the tests in a class, and a @AfterClass annotation to a method to be run after all the tests in a class. Here's an example:

<pre>
package junitfaq;

import org.junit.*;
import static org.junit.Assert.*;
import java.util.*;

public class SimpleTest {

private Collection collection;

@BeforeClass
public static void oneTimeSetUp() {
// one-time initialization code
}

@AfterClass
public static void oneTimeTearDown() {
// one-time cleanup code
}

@Before
public void setUp() {
collection = new ArrayList();
}

@After
public void tearDown() {
collection.clear();
}

@Test
public void testEmptyCollection() {
assertTrue(collection.isEmpty());
}

@Test
public void testOneItemCollection() {
collection.add("itemA");
assertEquals(1, collection.size());
}
}
</pre>
Given this test, the methods will execute in the following order:

*oneTimeSetUp()
*setUp()
*testEmptyCollection()
*tearDown()
*setUp()
*testOneItemCollection()
*tearDown()
*oneTimeTearDown()
 

==Conclusion==
By following the guidelines given in this articles, one can write a good unit test using junit, which is as important as writing good quality code. 
A good quality unit test will take care of all classes, boundary conditions, domain data and functionality. 
A good test can be creative to explore all possibilities, thinking out of box. 
Finally automating the test using tool like junit which is in the native java language itself helps in saving manual intervention and time/money. 

==References==

* http://articles.techrepublic.com.com/5100-10878_11-1027676.html
* http://msdn.microsoft.com/en-us/library/aa292197%28VS.71%29.asp
* http://junit.sourceforge.net/doc/cookbook/cookbook.htm
* http://junit.sourceforge.net/doc/faq/faq.htm#overview
* http://clarkware.com/articles/JUnitPrimer.html#usage
* http://users.csc.calpoly.edu/~jdalbey/205/Resources/junitQuickStart.html
* http://www.cis.upenn.edu/~matuszek/cit591-2004/Lectures/
* http://en.wikipedia.org/wiki/JUnit
* http://www.laliluna.de/eclipse-junit-testing-tutorial.html
* http://junit.sourceforge.net/doc/faq/faq.htm

-------------------------------------------------------

CSC/ECE 517 Fall 2009/wiki1a 1 JunitTest

2009-09-08T19:03:28Z

Wolverine: /* Rules for designing effective JUnit Test cases */

'''Writing Effective JUnit Test Cases''' 
----

''JUnit is a testing framework aimed at making unit testing easy by simplifying the writing of test cases and by providing automated running of tests and test suites.''

The objective of this document is to provide a repository of rules that can be used in-order to write an effective Junit test.
This doc also discusses various sites and suggest which are the best sites to read for an overview of the topic and to understand the different philosophies of test-case design.

==Introduction==

=== Unit Testing Overview ===

The primary goal of unit testing is to take the smallest piece of testable software in the application, isolate it from the remainder of the code, and determine whether it behaves exactly as you expect.

'''Test Case''' 
It describes a scenario that can be exercised through the application. 
Each test case is divided into two parts: input and expected output. 
The input part lists all the test case statements that create variables or assign values to variables. 
The expected output part indicates the expected results; it shows either assertions or the message 'no exception' (when no assertions exist). 

The main issue in constructing a unit test is deciding the scope of test cases. 
If the scope is too narrow, then the tests will be trivial and the objects might pass the tests, but there will be no design of their interactions and interactions of objects are important for object oriented design. 
On the other hand if the scope is too broad, then there is a high chance that not every component of the new code will get tested. 
The programmer is then reduced to testing-by-poking-around, which is not an effective test strategy. 

=== JUnit Overview ===
Non-automated testing is usually like this: 
* An expression is used in a debugger, you can change debug expressions without recompiling, and you can wait to decide what to write until you have seen the running objects. 
* Expressions are tested as statements which print to the standard output stream. 
But its not preferred because: 
* They require human judgment to analyze their results. 
* They are cumbersome, non repeatable - you can only execute one debug expression at a time and a program with too many print statements causes the dreaded "Scroll Blindness". 
On the upper hand, JUnit tests, which uses the automated framework does not require human judgment to interpret, and it is easy to run many of them at the same time.
 
When you need to test something, here is what you do: 
* Annotate a method with @org.junit.Test 
* When you want to check a value, import org.junit.Assert.* statically, call assertTrue() and pass a boolean that is true if the test succeeds 
'''So what exactly is JUnit ?? ''' 
It is a open-source unit testing framework for Java and provides a way to organize test data and perform repeatable test execution. 
In JUnit, one has to write Java code, called a test class, that describes test data, invokes the methods to be tested, and determines test results. 
JUnit was originally written by Erich Gamma and Kent Beck. 
The official JUnit home page is http://junit.org. 
JUnit is Open Source Software, released under IBM's Common Public License Version 0.5 and hosted on SourceForge. 
It is an instance of the xUnit architecture for unit testing frameworks. JUnit features include: 
* Assertions for testing expected results 
* Test fixtures for sharing common test data 
* Test runners for running tests 
'''JUnit mailing lists and forums''' 
[http://groups.yahoo.com/group/junit/ JUnit user list] 
[http://lists.sourceforge.net/lists/listinfo/junit-announce JUnit announcements] 
[http://lists.sourceforge.net/lists/listinfo/junit-devel JUnit developer list] 
'''JUnit official documentation''' 
[http://junit.sourceforge.net/doc/testinfected/testing.htm JUnit Test Infected: Programmers Love Writing Tests] 
[http://junit.sourceforge.net/doc/cookbook/cookbook.htm JUnit Cookbook] 
[http://junit.sourceforge.net/doc/cookstour/cookstour.htm JUnit - A Cook's Tour] 
[http://junit.sourceforge.net/doc/faq/faq.htm JUnit FAQ] 
Although JUnit testing costs some time and money, but unit testing provides some crucial advantages, viz: 
Automation of the testing process 
Reduces difficulties of discovering errors contained in more complex pieces of the application 
Test coverage is often enhanced because attention is given to each unit. 
For example, 
if you have two units and decide it would be more cost effective to glue them together and initially test them as an integrated unit, an error could occur in a variety of places, now: 
* Is the error due to a defect in unit 1? 
* Is the error due to a defect in unit 2? 
* Is the error due to defects in both units? 
* Is the error due to a defect in the interface between the units? 
* Is the error due to a defect in the test? 
Finding the error (or errors) in the integrated module is much more complicated than first isolating the units, testing each, then integrating them and testing the whole. 
 

== Websites to lookout ==
These are some of the best webpages which will help you in getting more description as well as details about Junit.
 Also it will help you understand the test case design philosophy. 
=== For Overview ===
* Junit testing basics: 
http://articles.techrepublic.com.com/5100-10878_11-1027676.html

* Basics of Junit: 
http://junit.sourceforge.net/doc/cookbook/cookbook.htm
http://junit.sourceforge.net/doc/faq/faq.htm#overview

=== For Ideas on test case design ===
* For successful test automation: 
http://www.io.com/~wazmo/papers/seven_steps.html

* Unit testing principles: 
http://www.acm.org/ubiquity/views/t_burns_1.html

* For test suite effectiveness: 
http://java.sys-con.com/node/299945
 

== How to get started ==
=== Step 1: Installing JUnit ===

* Download latest version of JUnit from "http://sourceforge.net/projects/junit/files/". 
* Then install JUnit on your platform of choice: 
Windows 
To install JUnit on Windows, follow these steps: 
* Unzip the junit.zip distribution file to a directory referred to as %JUNIT_HOME%. 
* Add JUnit to the classpath: 
<pre>set CLASSPATH=%JUNIT_HOME%\junit.jar</pre>
'''Unix (bash)''' 
To install JUnit on Unix, follow these steps: 
* Unzip the junit.zip distribution file to a directory referred to as $JUNIT_HOME. 
* Add JUnit to the classpath: 
<pre>export CLASSPATH=$JUNIT_HOME/junit.jar</pre>

=== Step 2: Writing a Test Case ===
To write a test case, follow these steps: 

* Implement a class derived from TestCase, a base class provided by JUnit. 
public class BooksCartTest extends TestCase
* Be sure the test class belongs to the same package as that of the unit you wish to test 
* Override the setUp() method to initialize object(s) under test. 
* Optionally override the tearDown() method to release object(s) under test. 
* Define one or more public testXXX() methods that exercise the object(s) under test and assert expected results. 
The following is an example test case: 
<pre>
import junit.framework.TestCase;

public class BooksCartTest extends TestCase {

private BooksCart cart1;
private BooksCart cart2;

/**
* Sets up the test fixture.
*
* Called before every test case method.
*/
protected void setUp() {

cart1 = new BooksCart(6,8);
cart2 = new BooksCart(7,10);
}

/**
* Tears down the test fixture.
*
* Called after every test case method.
*/
protected void tearDown() {
// release objects under test here, if necessary
}

/**
* Tests emptying the cart.
*/
public void testEmpty() {

cart1.empty();
cart2.empty();
assertEquals(cart1, new BooksCart(3, 9));
assertTrue(!cart2.equals(cart1));
}
}
</pre>
Methods used in JUnit: 
* An assert method is a JUnit method that performs a test, and throws an AssertionFailedError if the test fails 
* static void assertTrue(boolean test) 
static void assertTrue(String message, boolean test)
- Throws an AssertionFailedError if the test fails 
- The optional message is included in the Error 
* static void assertFalse(boolean test) 
static void assertFalse(String message, boolean test)
- Throws an AssertionFailedError if the test fails 

=== Step 3: Writing a Test Suite ===
Next, we'll write a test suite that includes several test cases. The test suite will allow us to run all of its test cases in one fell swoop. 
'''To write a test suite, follow these steps:''' 
* Write a Java class that defines a static suite() factory method that creates a TestSuite containing all the tests. 
* Optionally define a main() method that runs the TestSuite in batch mode. 

The following is an example test suite: 
<pre>
import junit.framework.Test;
import junit.framework.TestSuite;

public class BooksCartTestSuite {

public static Test suite() {

TestSuite suite = new TestSuite();

//
// The BooksCartTest we created above.
//
suite.addTestSuite(BooksCartTest.class);

//
// Another example test suite of tests.
//
suite.addTest(CreditCardTestSuite.suite());

//
// Add more tests here
//

return suite;
}

/**
* Runs the test suite using the textual runner.
*/
public static void main(String[] args) {
junit.textui.TestRunner.run(suite());
}
}
</pre>

=== Step 4: Running the Test ===
Now that we've written a test suite containing a collection of test cases and other test suites, we can run either the test suite or any of its test cases individually. Running a TestSuite will automatically run all of its subordinate TestCase instances and TestSuite instances. Running a TestCase will automatically invoke all of its public testXXX() methods.
JUnit provides both a textual and a graphical user interface. Both user interfaces indicate how many tests were run, any errors or failures, and a simple completion status. The simplicity of the user interfaces is the key to running tests quickly. You should be able to run your tests and know the test status with a glance, much like you do with a compiler.

To run our test case using the textual user interface, use: 
<pre>java junit.textui.TestRunner BooksCartTest </pre>
The textual user interface displays "OK" if all the tests passed and failure messages if any of the tests failed. 
To run the test case using the graphical user interface, use: 
<pre>java junit.swingui.TestRunner BooksCartTest </pre> 
The graphical user interface displays a Swing window with a green progress bar if all the tests passed or a red progress bar if any of the tests failed. 
The BooksCartTest Suite can be run similarly: 
<pre>java junit.swingui.TestRunner BooksCartTestSuite</pre>

== Rules for designing effective JUnit Test cases ==
* Identify and assemble a list of all the actions that your program should be able to perform. use cases,nonfunctional requirements specifications, test case specifications, user interface design documents, mockups, user profiles, and various additional artifacts.
* Identify the code's entry points - central pieces of code that exercise the functionality that the code as a whole is designed to undertake.
* Pair entry points with the use cases that they implement.
* Create test cases by applying the initialize/work/check procedure.
** Initialize: Create the environment that the test expects to run in. The initialization code can either be in the beginning of the test or in the setUp() method.
** Work: Call the code that is being tested, capturing any interesting output and recording any interesting statistics.
** Check: Use assert statements to ensure that the code worked as expected.
* Develop runtime event diagrams and use them to facilitate testing.
* Follow KISS rule:It's a bad idea to keep the input source name and expression in the test case. Some items (server names, usernames and passwords, etc.) should not live in the test files, which should be configurable for the specific deployment. Rather, design the test cases to facilitate separation of test drivers and test data, test driver reuse over a larger set of data, and test data reuse over a larger set of test drivers. On the other hand, don't over-architect a simple test case implementation. Typically, the test case specification already defines most of the system states and allows parameter descriptions for a scenario, so there's no point in making everything parameterizable in the test implementation.
 

==Rules for coding effective JUnit Tests==

=== Using Test Fixture for a common set of objects ===
Using a test fixture avoids duplicating the code necessary to initialize (and cleanup) the common objects.
Tests can use the objects (variables) in a test fixture, with each test invoking different methods on objects in the fixture and asserting different expected results. Each test runs in its own test fixture to isolate tests from the changes made by other tests. That is, tests don't share the state of objects in the test fixture. Because the tests are isolated, they can be run in any order.
To create a test fixture, declare instance variables for the common objects. Initialize these objects in a public void method annotated with @Before. The JUnit framework automatically invokes any @Before methods before each test is run.
The following example shows a test fixture with a common Collection object.
<pre>
package junitfaq;

import org.junit.*;
import static org.junit.Assert.*;
import java.util.*;

public class SimpleTest {

private Collection<Object> collection;

@Before
public void setUp() {
collection = new ArrayList<Object>();
}

@Test
public void testEmptyCollection() {
assertTrue(collection.isEmpty());
}

@Test
public void testOneItemCollection() {
collection.add("itemA");
assertEquals(1, collection.size());
}
}
</pre>
Given this test, the methods might execute in the following order: 
setUp() 
testEmptyCollection() 
setUp() 
testOneItemCollection() 
The ordering of test-method invocations is not guaranteed, so testOneItemCollection() might be executed before testEmptyCollection(). But it doesn't matter, because each method gets its own instance of the collection.
Although JUnit provides a new instance of the fixture objects for each test method, if you allocate any external resources in a @Before method, you should release them after the test runs by annotating a method with @After. The JUnit framework automatically invokes any @After methods after each test is run. For example:
<pre>
package junitfaq;

import org.junit.*;
import static org.junit.Assert.*;
import java.io.*;

public class OutputTest {

private File output;

@Before
public void createOutputFile() {
output = new File(...);
}

@After
public void deleteOutputFile() {
output.delete();
}

@Test
public void testSomethingWithFile() {
...
}
}
</pre>
With this test, the methods will execute in the following order:

* createOutputFile()
* testSomethingWithFile()
* deleteOutputFile()
 

=== To Test a method that doesnot return anything ===
If a method doesn't return a value, it might have some side effect. Actually, if it doesn't return a value AND doesn't have a side effect, it isn't doing anything.
There may be a way to verify that the side effect actually occurred as expected. For example, consider the add() method in the Collection classes. There are ways of verifying that the side effect happened (i.e. the object was added). You can check the size and assert that it is what is expected:

<pre>
public void testCollectionAdd() {
Collection collection = new ArrayList();
assertEquals(0, collection.size());
collection.add("itemA");
assertEquals(1, collection.size());
collection.add("itemB");
assertEquals(2, collection.size());
}
</pre>
 

=== To test an expected/unexpected exception ===
* Case of expected exception
Add the optional expected attribute to the @Test annotation. The following is an example test that passes when the expected IndexOutOfBoundsException is raised:
<pre>
@Test(expected=IndexOutOfBoundsException.class)
public void testIndexOutOfBoundsException() {
ArrayList emptyList = new ArrayList();
Object o = emptyList.get(0);
}
</pre>
* Case of unexpected exception
Declare the exception in the throws clause of the test method and don't catch the exception within the test method. Uncaught exceptions will cause the test to fail with an error.
The following is an example test that fails when the IndexOutOfBoundsException is raised:
<pre>
@Test
public void testIndexOutOfBoundsExceptionNotRaised()
throws IndexOutOfBoundsException {

ArrayList emptyList = new ArrayList();
Object o = emptyList.get(0);
}
</pre>
 

=== To Test protected/private methods ===
* Case for protected methods
Place your tests in the same package as the classes under test.
* Case for private methods
Testing private methods may be an indication that those methods should be moved into another class to promote reusability.
 

=== Conditions to test get() and set() methods ===
Unit tests are intended to alleviate fear that something might break. If you think a get() or set() method could reasonably break, or has in fact contributed to a defect, then by all means write a test.
In short, test until you're confident. What you choose to test is subjective, based on your experiences and confidence level. Remember to be practical and maximize your testing investment.
 

=== To run setUp() and tearDown() code once for all tests ===

You can add a @BeforeClass annotation to a method to be run before all the tests in a class, and a @AfterClass annotation to a method to be run after all the tests in a class. Here's an example:

<pre>
package junitfaq;

import org.junit.*;
import static org.junit.Assert.*;
import java.util.*;

public class SimpleTest {

private Collection collection;

@BeforeClass
public static void oneTimeSetUp() {
// one-time initialization code
}

@AfterClass
public static void oneTimeTearDown() {
// one-time cleanup code
}

@Before
public void setUp() {
collection = new ArrayList();
}

@After
public void tearDown() {
collection.clear();
}

@Test
public void testEmptyCollection() {
assertTrue(collection.isEmpty());
}

@Test
public void testOneItemCollection() {
collection.add("itemA");
assertEquals(1, collection.size());
}
}
</pre>
Given this test, the methods will execute in the following order:

*oneTimeSetUp()
*setUp()
*testEmptyCollection()
*tearDown()
*setUp()
*testOneItemCollection()
*tearDown()
*oneTimeTearDown()
 

==Conclusion==
By following the guidelines given in this articles, one can write a good unit test using junit, which is as important as writing good quality code. 
A good quality unit test will take care of all classes, boundary conditions, domain data and functionality. 
A good test can be creative to explore all possibilities, thinking out of box. 
Finally automating the test using tool like junit which is in the native java language itself helps in saving manual intervention and time/money. 

==References==

* http://articles.techrepublic.com.com/5100-10878_11-1027676.html
* http://msdn.microsoft.com/en-us/library/aa292197%28VS.71%29.asp
* http://junit.sourceforge.net/doc/cookbook/cookbook.htm
* http://junit.sourceforge.net/doc/faq/faq.htm#overview
* http://clarkware.com/articles/JUnitPrimer.html#usage
* http://users.csc.calpoly.edu/~jdalbey/205/Resources/junitQuickStart.html
* http://www.cis.upenn.edu/~matuszek/cit591-2004/Lectures/
* http://en.wikipedia.org/wiki/JUnit
* http://www.laliluna.de/eclipse-junit-testing-tutorial.html
* http://junit.sourceforge.net/doc/faq/faq.htm

-------------------------------------------------------

CSC/ECE 517 Fall 2009/wiki1a 1 JunitTest

2009-09-08T19:03:11Z

Wolverine: /* Using Test Fixture for a common set of objects */

'''Writing Effective JUnit Test Cases''' 
----

''JUnit is a testing framework aimed at making unit testing easy by simplifying the writing of test cases and by providing automated running of tests and test suites.''

The objective of this document is to provide a repository of rules that can be used in-order to write an effective Junit test.
This doc also discusses various sites and suggest which are the best sites to read for an overview of the topic and to understand the different philosophies of test-case design.

==Introduction==

=== Unit Testing Overview ===

The primary goal of unit testing is to take the smallest piece of testable software in the application, isolate it from the remainder of the code, and determine whether it behaves exactly as you expect.

'''Test Case''' 
It describes a scenario that can be exercised through the application. 
Each test case is divided into two parts: input and expected output. 
The input part lists all the test case statements that create variables or assign values to variables. 
The expected output part indicates the expected results; it shows either assertions or the message 'no exception' (when no assertions exist). 

The main issue in constructing a unit test is deciding the scope of test cases. 
If the scope is too narrow, then the tests will be trivial and the objects might pass the tests, but there will be no design of their interactions and interactions of objects are important for object oriented design. 
On the other hand if the scope is too broad, then there is a high chance that not every component of the new code will get tested. 
The programmer is then reduced to testing-by-poking-around, which is not an effective test strategy. 

=== JUnit Overview ===
Non-automated testing is usually like this: 
* An expression is used in a debugger, you can change debug expressions without recompiling, and you can wait to decide what to write until you have seen the running objects. 
* Expressions are tested as statements which print to the standard output stream. 
But its not preferred because: 
* They require human judgment to analyze their results. 
* They are cumbersome, non repeatable - you can only execute one debug expression at a time and a program with too many print statements causes the dreaded "Scroll Blindness". 
On the upper hand, JUnit tests, which uses the automated framework does not require human judgment to interpret, and it is easy to run many of them at the same time.
 
When you need to test something, here is what you do: 
* Annotate a method with @org.junit.Test 
* When you want to check a value, import org.junit.Assert.* statically, call assertTrue() and pass a boolean that is true if the test succeeds 
'''So what exactly is JUnit ?? ''' 
It is a open-source unit testing framework for Java and provides a way to organize test data and perform repeatable test execution. 
In JUnit, one has to write Java code, called a test class, that describes test data, invokes the methods to be tested, and determines test results. 
JUnit was originally written by Erich Gamma and Kent Beck. 
The official JUnit home page is http://junit.org. 
JUnit is Open Source Software, released under IBM's Common Public License Version 0.5 and hosted on SourceForge. 
It is an instance of the xUnit architecture for unit testing frameworks. JUnit features include: 
* Assertions for testing expected results 
* Test fixtures for sharing common test data 
* Test runners for running tests 
'''JUnit mailing lists and forums''' 
[http://groups.yahoo.com/group/junit/ JUnit user list] 
[http://lists.sourceforge.net/lists/listinfo/junit-announce JUnit announcements] 
[http://lists.sourceforge.net/lists/listinfo/junit-devel JUnit developer list] 
'''JUnit official documentation''' 
[http://junit.sourceforge.net/doc/testinfected/testing.htm JUnit Test Infected: Programmers Love Writing Tests] 
[http://junit.sourceforge.net/doc/cookbook/cookbook.htm JUnit Cookbook] 
[http://junit.sourceforge.net/doc/cookstour/cookstour.htm JUnit - A Cook's Tour] 
[http://junit.sourceforge.net/doc/faq/faq.htm JUnit FAQ] 
Although JUnit testing costs some time and money, but unit testing provides some crucial advantages, viz: 
Automation of the testing process 
Reduces difficulties of discovering errors contained in more complex pieces of the application 
Test coverage is often enhanced because attention is given to each unit. 
For example, 
if you have two units and decide it would be more cost effective to glue them together and initially test them as an integrated unit, an error could occur in a variety of places, now: 
* Is the error due to a defect in unit 1? 
* Is the error due to a defect in unit 2? 
* Is the error due to defects in both units? 
* Is the error due to a defect in the interface between the units? 
* Is the error due to a defect in the test? 
Finding the error (or errors) in the integrated module is much more complicated than first isolating the units, testing each, then integrating them and testing the whole. 
 

== Websites to lookout ==
These are some of the best webpages which will help you in getting more description as well as details about Junit.
 Also it will help you understand the test case design philosophy. 
=== For Overview ===
* Junit testing basics: 
http://articles.techrepublic.com.com/5100-10878_11-1027676.html

* Basics of Junit: 
http://junit.sourceforge.net/doc/cookbook/cookbook.htm
http://junit.sourceforge.net/doc/faq/faq.htm#overview

=== For Ideas on test case design ===
* For successful test automation: 
http://www.io.com/~wazmo/papers/seven_steps.html

* Unit testing principles: 
http://www.acm.org/ubiquity/views/t_burns_1.html

* For test suite effectiveness: 
http://java.sys-con.com/node/299945
 

== How to get started ==
=== Step 1: Installing JUnit ===

* Download latest version of JUnit from "http://sourceforge.net/projects/junit/files/". 
* Then install JUnit on your platform of choice: 
Windows 
To install JUnit on Windows, follow these steps: 
* Unzip the junit.zip distribution file to a directory referred to as %JUNIT_HOME%. 
* Add JUnit to the classpath: 
<pre>set CLASSPATH=%JUNIT_HOME%\junit.jar</pre>
'''Unix (bash)''' 
To install JUnit on Unix, follow these steps: 
* Unzip the junit.zip distribution file to a directory referred to as $JUNIT_HOME. 
* Add JUnit to the classpath: 
<pre>export CLASSPATH=$JUNIT_HOME/junit.jar</pre>

=== Step 2: Writing a Test Case ===
To write a test case, follow these steps: 

* Implement a class derived from TestCase, a base class provided by JUnit. 
public class BooksCartTest extends TestCase
* Be sure the test class belongs to the same package as that of the unit you wish to test 
* Override the setUp() method to initialize object(s) under test. 
* Optionally override the tearDown() method to release object(s) under test. 
* Define one or more public testXXX() methods that exercise the object(s) under test and assert expected results. 
The following is an example test case: 
<pre>
import junit.framework.TestCase;

public class BooksCartTest extends TestCase {

private BooksCart cart1;
private BooksCart cart2;

/**
* Sets up the test fixture.
*
* Called before every test case method.
*/
protected void setUp() {

cart1 = new BooksCart(6,8);
cart2 = new BooksCart(7,10);
}

/**
* Tears down the test fixture.
*
* Called after every test case method.
*/
protected void tearDown() {
// release objects under test here, if necessary
}

/**
* Tests emptying the cart.
*/
public void testEmpty() {

cart1.empty();
cart2.empty();
assertEquals(cart1, new BooksCart(3, 9));
assertTrue(!cart2.equals(cart1));
}
}
</pre>
Methods used in JUnit: 
* An assert method is a JUnit method that performs a test, and throws an AssertionFailedError if the test fails 
* static void assertTrue(boolean test) 
static void assertTrue(String message, boolean test)
- Throws an AssertionFailedError if the test fails 
- The optional message is included in the Error 
* static void assertFalse(boolean test) 
static void assertFalse(String message, boolean test)
- Throws an AssertionFailedError if the test fails 

=== Step 3: Writing a Test Suite ===
Next, we'll write a test suite that includes several test cases. The test suite will allow us to run all of its test cases in one fell swoop. 
'''To write a test suite, follow these steps:''' 
* Write a Java class that defines a static suite() factory method that creates a TestSuite containing all the tests. 
* Optionally define a main() method that runs the TestSuite in batch mode. 

The following is an example test suite: 
<pre>
import junit.framework.Test;
import junit.framework.TestSuite;

public class BooksCartTestSuite {

public static Test suite() {

TestSuite suite = new TestSuite();

//
// The BooksCartTest we created above.
//
suite.addTestSuite(BooksCartTest.class);

//
// Another example test suite of tests.
//
suite.addTest(CreditCardTestSuite.suite());

//
// Add more tests here
//

return suite;
}

/**
* Runs the test suite using the textual runner.
*/
public static void main(String[] args) {
junit.textui.TestRunner.run(suite());
}
}
</pre>

=== Step 4: Running the Test ===
Now that we've written a test suite containing a collection of test cases and other test suites, we can run either the test suite or any of its test cases individually. Running a TestSuite will automatically run all of its subordinate TestCase instances and TestSuite instances. Running a TestCase will automatically invoke all of its public testXXX() methods.
JUnit provides both a textual and a graphical user interface. Both user interfaces indicate how many tests were run, any errors or failures, and a simple completion status. The simplicity of the user interfaces is the key to running tests quickly. You should be able to run your tests and know the test status with a glance, much like you do with a compiler.

To run our test case using the textual user interface, use: 
<pre>java junit.textui.TestRunner BooksCartTest </pre>
The textual user interface displays "OK" if all the tests passed and failure messages if any of the tests failed. 
To run the test case using the graphical user interface, use: 
<pre>java junit.swingui.TestRunner BooksCartTest </pre> 
The graphical user interface displays a Swing window with a green progress bar if all the tests passed or a red progress bar if any of the tests failed. 
The BooksCartTest Suite can be run similarly: 
<pre>java junit.swingui.TestRunner BooksCartTestSuite</pre>

== Rules for designing effective JUnit Test cases ==
* Identify and assemble a list of all the actions that your program should be able to perform. use cases,nonfunctional requirements specifications, test case specifications, user interface design documents, mockups, user profiles, and various additional artifacts.
* Identify the code's entry points - central pieces of code that exercise the functionality that the code as a whole is designed to undertake.
* Pair entry points with the use cases that they implement.
* Create test cases by applying the initialize/work/check procedure.
** Initialize: Create the environment that the test expects to run in. The initialization code can either be in the beginning of the test or in the setUp() method.
** Work: Call the code that is being tested, capturing any interesting output and recording any interesting statistics.
** Check: Use assert statements to ensure that the code worked as expected.
* Develop runtime event diagrams and use them to facilitate testing.
* Follow KISS rule:It's a bad idea to keep the input source name and expression in the test case. Some items (server names, usernames and passwords, etc.) should not live in the test files, which should be configurable for the specific deployment. Rather, design the test cases to facilitate separation of test drivers and test data, test driver reuse over a larger set of data, and test data reuse over a larger set of test drivers. On the other hand, don't over-architect a simple test case implementation. Typically, the test case specification already defines most of the system states and allows parameter descriptions for a scenario, so there's no point in making everything parameterizable in the test implementation.

==Rules for coding effective JUnit Tests==

=== Using Test Fixture for a common set of objects ===
Using a test fixture avoids duplicating the code necessary to initialize (and cleanup) the common objects.
Tests can use the objects (variables) in a test fixture, with each test invoking different methods on objects in the fixture and asserting different expected results. Each test runs in its own test fixture to isolate tests from the changes made by other tests. That is, tests don't share the state of objects in the test fixture. Because the tests are isolated, they can be run in any order.
To create a test fixture, declare instance variables for the common objects. Initialize these objects in a public void method annotated with @Before. The JUnit framework automatically invokes any @Before methods before each test is run.
The following example shows a test fixture with a common Collection object.
<pre>
package junitfaq;

import org.junit.*;
import static org.junit.Assert.*;
import java.util.*;

public class SimpleTest {

private Collection<Object> collection;

@Before
public void setUp() {
collection = new ArrayList<Object>();
}

@Test
public void testEmptyCollection() {
assertTrue(collection.isEmpty());
}

@Test
public void testOneItemCollection() {
collection.add("itemA");
assertEquals(1, collection.size());
}
}
</pre>
Given this test, the methods might execute in the following order: 
setUp() 
testEmptyCollection() 
setUp() 
testOneItemCollection() 
The ordering of test-method invocations is not guaranteed, so testOneItemCollection() might be executed before testEmptyCollection(). But it doesn't matter, because each method gets its own instance of the collection.
Although JUnit provides a new instance of the fixture objects for each test method, if you allocate any external resources in a @Before method, you should release them after the test runs by annotating a method with @After. The JUnit framework automatically invokes any @After methods after each test is run. For example:
<pre>
package junitfaq;

import org.junit.*;
import static org.junit.Assert.*;
import java.io.*;

public class OutputTest {

private File output;

@Before
public void createOutputFile() {
output = new File(...);
}

@After
public void deleteOutputFile() {
output.delete();
}

@Test
public void testSomethingWithFile() {
...
}
}
</pre>
With this test, the methods will execute in the following order:

* createOutputFile()
* testSomethingWithFile()
* deleteOutputFile()
 

=== To Test a method that doesnot return anything ===
If a method doesn't return a value, it might have some side effect. Actually, if it doesn't return a value AND doesn't have a side effect, it isn't doing anything.
There may be a way to verify that the side effect actually occurred as expected. For example, consider the add() method in the Collection classes. There are ways of verifying that the side effect happened (i.e. the object was added). You can check the size and assert that it is what is expected:

<pre>
public void testCollectionAdd() {
Collection collection = new ArrayList();
assertEquals(0, collection.size());
collection.add("itemA");
assertEquals(1, collection.size());
collection.add("itemB");
assertEquals(2, collection.size());
}
</pre>
 

=== To test an expected/unexpected exception ===
* Case of expected exception
Add the optional expected attribute to the @Test annotation. The following is an example test that passes when the expected IndexOutOfBoundsException is raised:
<pre>
@Test(expected=IndexOutOfBoundsException.class)
public void testIndexOutOfBoundsException() {
ArrayList emptyList = new ArrayList();
Object o = emptyList.get(0);
}
</pre>
* Case of unexpected exception
Declare the exception in the throws clause of the test method and don't catch the exception within the test method. Uncaught exceptions will cause the test to fail with an error.
The following is an example test that fails when the IndexOutOfBoundsException is raised:
<pre>
@Test
public void testIndexOutOfBoundsExceptionNotRaised()
throws IndexOutOfBoundsException {

ArrayList emptyList = new ArrayList();
Object o = emptyList.get(0);
}
</pre>
 

=== To Test protected/private methods ===
* Case for protected methods
Place your tests in the same package as the classes under test.
* Case for private methods
Testing private methods may be an indication that those methods should be moved into another class to promote reusability.
 

=== Conditions to test get() and set() methods ===
Unit tests are intended to alleviate fear that something might break. If you think a get() or set() method could reasonably break, or has in fact contributed to a defect, then by all means write a test.
In short, test until you're confident. What you choose to test is subjective, based on your experiences and confidence level. Remember to be practical and maximize your testing investment.
 

=== To run setUp() and tearDown() code once for all tests ===

You can add a @BeforeClass annotation to a method to be run before all the tests in a class, and a @AfterClass annotation to a method to be run after all the tests in a class. Here's an example:

<pre>
package junitfaq;

import org.junit.*;
import static org.junit.Assert.*;
import java.util.*;

public class SimpleTest {

private Collection collection;

@BeforeClass
public static void oneTimeSetUp() {
// one-time initialization code
}

@AfterClass
public static void oneTimeTearDown() {
// one-time cleanup code
}

@Before
public void setUp() {
collection = new ArrayList();
}

@After
public void tearDown() {
collection.clear();
}

@Test
public void testEmptyCollection() {
assertTrue(collection.isEmpty());
}

@Test
public void testOneItemCollection() {
collection.add("itemA");
assertEquals(1, collection.size());
}
}
</pre>
Given this test, the methods will execute in the following order:

*oneTimeSetUp()
*setUp()
*testEmptyCollection()
*tearDown()
*setUp()
*testOneItemCollection()
*tearDown()
*oneTimeTearDown()
 

==Conclusion==
By following the guidelines given in this articles, one can write a good unit test using junit, which is as important as writing good quality code. 
A good quality unit test will take care of all classes, boundary conditions, domain data and functionality. 
A good test can be creative to explore all possibilities, thinking out of box. 
Finally automating the test using tool like junit which is in the native java language itself helps in saving manual intervention and time/money. 

==References==

* http://articles.techrepublic.com.com/5100-10878_11-1027676.html
* http://msdn.microsoft.com/en-us/library/aa292197%28VS.71%29.asp
* http://junit.sourceforge.net/doc/cookbook/cookbook.htm
* http://junit.sourceforge.net/doc/faq/faq.htm#overview
* http://clarkware.com/articles/JUnitPrimer.html#usage
* http://users.csc.calpoly.edu/~jdalbey/205/Resources/junitQuickStart.html
* http://www.cis.upenn.edu/~matuszek/cit591-2004/Lectures/
* http://en.wikipedia.org/wiki/JUnit
* http://www.laliluna.de/eclipse-junit-testing-tutorial.html
* http://junit.sourceforge.net/doc/faq/faq.htm

-------------------------------------------------------

CSC/ECE 517 Fall 2009/wiki1a 1 JunitTest

2009-09-08T19:02:57Z

Wolverine: /* To Test a method that doesnot return anything */

'''Writing Effective JUnit Test Cases''' 
----

''JUnit is a testing framework aimed at making unit testing easy by simplifying the writing of test cases and by providing automated running of tests and test suites.''

The objective of this document is to provide a repository of rules that can be used in-order to write an effective Junit test.
This doc also discusses various sites and suggest which are the best sites to read for an overview of the topic and to understand the different philosophies of test-case design.

==Introduction==

=== Unit Testing Overview ===

The primary goal of unit testing is to take the smallest piece of testable software in the application, isolate it from the remainder of the code, and determine whether it behaves exactly as you expect.

'''Test Case''' 
It describes a scenario that can be exercised through the application. 
Each test case is divided into two parts: input and expected output. 
The input part lists all the test case statements that create variables or assign values to variables. 
The expected output part indicates the expected results; it shows either assertions or the message 'no exception' (when no assertions exist). 

The main issue in constructing a unit test is deciding the scope of test cases. 
If the scope is too narrow, then the tests will be trivial and the objects might pass the tests, but there will be no design of their interactions and interactions of objects are important for object oriented design. 
On the other hand if the scope is too broad, then there is a high chance that not every component of the new code will get tested. 
The programmer is then reduced to testing-by-poking-around, which is not an effective test strategy. 

=== JUnit Overview ===
Non-automated testing is usually like this: 
* An expression is used in a debugger, you can change debug expressions without recompiling, and you can wait to decide what to write until you have seen the running objects. 
* Expressions are tested as statements which print to the standard output stream. 
But its not preferred because: 
* They require human judgment to analyze their results. 
* They are cumbersome, non repeatable - you can only execute one debug expression at a time and a program with too many print statements causes the dreaded "Scroll Blindness". 
On the upper hand, JUnit tests, which uses the automated framework does not require human judgment to interpret, and it is easy to run many of them at the same time.
 
When you need to test something, here is what you do: 
* Annotate a method with @org.junit.Test 
* When you want to check a value, import org.junit.Assert.* statically, call assertTrue() and pass a boolean that is true if the test succeeds 
'''So what exactly is JUnit ?? ''' 
It is a open-source unit testing framework for Java and provides a way to organize test data and perform repeatable test execution. 
In JUnit, one has to write Java code, called a test class, that describes test data, invokes the methods to be tested, and determines test results. 
JUnit was originally written by Erich Gamma and Kent Beck. 
The official JUnit home page is http://junit.org. 
JUnit is Open Source Software, released under IBM's Common Public License Version 0.5 and hosted on SourceForge. 
It is an instance of the xUnit architecture for unit testing frameworks. JUnit features include: 
* Assertions for testing expected results 
* Test fixtures for sharing common test data 
* Test runners for running tests 
'''JUnit mailing lists and forums''' 
[http://groups.yahoo.com/group/junit/ JUnit user list] 
[http://lists.sourceforge.net/lists/listinfo/junit-announce JUnit announcements] 
[http://lists.sourceforge.net/lists/listinfo/junit-devel JUnit developer list] 
'''JUnit official documentation''' 
[http://junit.sourceforge.net/doc/testinfected/testing.htm JUnit Test Infected: Programmers Love Writing Tests] 
[http://junit.sourceforge.net/doc/cookbook/cookbook.htm JUnit Cookbook] 
[http://junit.sourceforge.net/doc/cookstour/cookstour.htm JUnit - A Cook's Tour] 
[http://junit.sourceforge.net/doc/faq/faq.htm JUnit FAQ] 
Although JUnit testing costs some time and money, but unit testing provides some crucial advantages, viz: 
Automation of the testing process 
Reduces difficulties of discovering errors contained in more complex pieces of the application 
Test coverage is often enhanced because attention is given to each unit. 
For example, 
if you have two units and decide it would be more cost effective to glue them together and initially test them as an integrated unit, an error could occur in a variety of places, now: 
* Is the error due to a defect in unit 1? 
* Is the error due to a defect in unit 2? 
* Is the error due to defects in both units? 
* Is the error due to a defect in the interface between the units? 
* Is the error due to a defect in the test? 
Finding the error (or errors) in the integrated module is much more complicated than first isolating the units, testing each, then integrating them and testing the whole. 
 

== Websites to lookout ==
These are some of the best webpages which will help you in getting more description as well as details about Junit.
 Also it will help you understand the test case design philosophy. 
=== For Overview ===
* Junit testing basics: 
http://articles.techrepublic.com.com/5100-10878_11-1027676.html

* Basics of Junit: 
http://junit.sourceforge.net/doc/cookbook/cookbook.htm
http://junit.sourceforge.net/doc/faq/faq.htm#overview

=== For Ideas on test case design ===
* For successful test automation: 
http://www.io.com/~wazmo/papers/seven_steps.html

* Unit testing principles: 
http://www.acm.org/ubiquity/views/t_burns_1.html

* For test suite effectiveness: 
http://java.sys-con.com/node/299945
 

== How to get started ==
=== Step 1: Installing JUnit ===

* Download latest version of JUnit from "http://sourceforge.net/projects/junit/files/". 
* Then install JUnit on your platform of choice: 
Windows 
To install JUnit on Windows, follow these steps: 
* Unzip the junit.zip distribution file to a directory referred to as %JUNIT_HOME%. 
* Add JUnit to the classpath: 
<pre>set CLASSPATH=%JUNIT_HOME%\junit.jar</pre>
'''Unix (bash)''' 
To install JUnit on Unix, follow these steps: 
* Unzip the junit.zip distribution file to a directory referred to as $JUNIT_HOME. 
* Add JUnit to the classpath: 
<pre>export CLASSPATH=$JUNIT_HOME/junit.jar</pre>

=== Step 2: Writing a Test Case ===
To write a test case, follow these steps: 

* Implement a class derived from TestCase, a base class provided by JUnit. 
public class BooksCartTest extends TestCase
* Be sure the test class belongs to the same package as that of the unit you wish to test 
* Override the setUp() method to initialize object(s) under test. 
* Optionally override the tearDown() method to release object(s) under test. 
* Define one or more public testXXX() methods that exercise the object(s) under test and assert expected results. 
The following is an example test case: 
<pre>
import junit.framework.TestCase;

public class BooksCartTest extends TestCase {

private BooksCart cart1;
private BooksCart cart2;

/**
* Sets up the test fixture.
*
* Called before every test case method.
*/
protected void setUp() {

cart1 = new BooksCart(6,8);
cart2 = new BooksCart(7,10);
}

/**
* Tears down the test fixture.
*
* Called after every test case method.
*/
protected void tearDown() {
// release objects under test here, if necessary
}

/**
* Tests emptying the cart.
*/
public void testEmpty() {

cart1.empty();
cart2.empty();
assertEquals(cart1, new BooksCart(3, 9));
assertTrue(!cart2.equals(cart1));
}
}
</pre>
Methods used in JUnit: 
* An assert method is a JUnit method that performs a test, and throws an AssertionFailedError if the test fails 
* static void assertTrue(boolean test) 
static void assertTrue(String message, boolean test)
- Throws an AssertionFailedError if the test fails 
- The optional message is included in the Error 
* static void assertFalse(boolean test) 
static void assertFalse(String message, boolean test)
- Throws an AssertionFailedError if the test fails 

=== Step 3: Writing a Test Suite ===
Next, we'll write a test suite that includes several test cases. The test suite will allow us to run all of its test cases in one fell swoop. 
'''To write a test suite, follow these steps:''' 
* Write a Java class that defines a static suite() factory method that creates a TestSuite containing all the tests. 
* Optionally define a main() method that runs the TestSuite in batch mode. 

The following is an example test suite: 
<pre>
import junit.framework.Test;
import junit.framework.TestSuite;

public class BooksCartTestSuite {

public static Test suite() {

TestSuite suite = new TestSuite();

//
// The BooksCartTest we created above.
//
suite.addTestSuite(BooksCartTest.class);

//
// Another example test suite of tests.
//
suite.addTest(CreditCardTestSuite.suite());

//
// Add more tests here
//

return suite;
}

/**
* Runs the test suite using the textual runner.
*/
public static void main(String[] args) {
junit.textui.TestRunner.run(suite());
}
}
</pre>

=== Step 4: Running the Test ===
Now that we've written a test suite containing a collection of test cases and other test suites, we can run either the test suite or any of its test cases individually. Running a TestSuite will automatically run all of its subordinate TestCase instances and TestSuite instances. Running a TestCase will automatically invoke all of its public testXXX() methods.
JUnit provides both a textual and a graphical user interface. Both user interfaces indicate how many tests were run, any errors or failures, and a simple completion status. The simplicity of the user interfaces is the key to running tests quickly. You should be able to run your tests and know the test status with a glance, much like you do with a compiler.

To run our test case using the textual user interface, use: 
<pre>java junit.textui.TestRunner BooksCartTest </pre>
The textual user interface displays "OK" if all the tests passed and failure messages if any of the tests failed. 
To run the test case using the graphical user interface, use: 
<pre>java junit.swingui.TestRunner BooksCartTest </pre> 
The graphical user interface displays a Swing window with a green progress bar if all the tests passed or a red progress bar if any of the tests failed. 
The BooksCartTest Suite can be run similarly: 
<pre>java junit.swingui.TestRunner BooksCartTestSuite</pre>

== Rules for designing effective JUnit Test cases ==
* Identify and assemble a list of all the actions that your program should be able to perform. use cases,nonfunctional requirements specifications, test case specifications, user interface design documents, mockups, user profiles, and various additional artifacts.
* Identify the code's entry points - central pieces of code that exercise the functionality that the code as a whole is designed to undertake.
* Pair entry points with the use cases that they implement.
* Create test cases by applying the initialize/work/check procedure.
** Initialize: Create the environment that the test expects to run in. The initialization code can either be in the beginning of the test or in the setUp() method.
** Work: Call the code that is being tested, capturing any interesting output and recording any interesting statistics.
** Check: Use assert statements to ensure that the code worked as expected.
* Develop runtime event diagrams and use them to facilitate testing.
* Follow KISS rule:It's a bad idea to keep the input source name and expression in the test case. Some items (server names, usernames and passwords, etc.) should not live in the test files, which should be configurable for the specific deployment. Rather, design the test cases to facilitate separation of test drivers and test data, test driver reuse over a larger set of data, and test data reuse over a larger set of test drivers. On the other hand, don't over-architect a simple test case implementation. Typically, the test case specification already defines most of the system states and allows parameter descriptions for a scenario, so there's no point in making everything parameterizable in the test implementation.

==Rules for coding effective JUnit Tests==

=== Using Test Fixture for a common set of objects ===
Using a test fixture avoids duplicating the code necessary to initialize (and cleanup) the common objects.
Tests can use the objects (variables) in a test fixture, with each test invoking different methods on objects in the fixture and asserting different expected results. Each test runs in its own test fixture to isolate tests from the changes made by other tests. That is, tests don't share the state of objects in the test fixture. Because the tests are isolated, they can be run in any order.
To create a test fixture, declare instance variables for the common objects. Initialize these objects in a public void method annotated with @Before. The JUnit framework automatically invokes any @Before methods before each test is run.
The following example shows a test fixture with a common Collection object.
<pre>
package junitfaq;

import org.junit.*;
import static org.junit.Assert.*;
import java.util.*;

public class SimpleTest {

private Collection<Object> collection;

@Before
public void setUp() {
collection = new ArrayList<Object>();
}

@Test
public void testEmptyCollection() {
assertTrue(collection.isEmpty());
}

@Test
public void testOneItemCollection() {
collection.add("itemA");
assertEquals(1, collection.size());
}
}
</pre>
Given this test, the methods might execute in the following order: 
setUp() 
testEmptyCollection() 
setUp() 
testOneItemCollection() 
The ordering of test-method invocations is not guaranteed, so testOneItemCollection() might be executed before testEmptyCollection(). But it doesn't matter, because each method gets its own instance of the collection.
Although JUnit provides a new instance of the fixture objects for each test method, if you allocate any external resources in a @Before method, you should release them after the test runs by annotating a method with @After. The JUnit framework automatically invokes any @After methods after each test is run. For example:
<pre>
package junitfaq;

import org.junit.*;
import static org.junit.Assert.*;
import java.io.*;

public class OutputTest {

private File output;

@Before
public void createOutputFile() {
output = new File(...);
}

@After
public void deleteOutputFile() {
output.delete();
}

@Test
public void testSomethingWithFile() {
...
}
}
</pre>
With this test, the methods will execute in the following order:

* createOutputFile()
* testSomethingWithFile()
* deleteOutputFile()

=== To Test a method that doesnot return anything ===
If a method doesn't return a value, it might have some side effect. Actually, if it doesn't return a value AND doesn't have a side effect, it isn't doing anything.
There may be a way to verify that the side effect actually occurred as expected. For example, consider the add() method in the Collection classes. There are ways of verifying that the side effect happened (i.e. the object was added). You can check the size and assert that it is what is expected:

<pre>
public void testCollectionAdd() {
Collection collection = new ArrayList();
assertEquals(0, collection.size());
collection.add("itemA");
assertEquals(1, collection.size());
collection.add("itemB");
assertEquals(2, collection.size());
}
</pre>
 

=== To test an expected/unexpected exception ===
* Case of expected exception
Add the optional expected attribute to the @Test annotation. The following is an example test that passes when the expected IndexOutOfBoundsException is raised:
<pre>
@Test(expected=IndexOutOfBoundsException.class)
public void testIndexOutOfBoundsException() {
ArrayList emptyList = new ArrayList();
Object o = emptyList.get(0);
}
</pre>
* Case of unexpected exception
Declare the exception in the throws clause of the test method and don't catch the exception within the test method. Uncaught exceptions will cause the test to fail with an error.
The following is an example test that fails when the IndexOutOfBoundsException is raised:
<pre>
@Test
public void testIndexOutOfBoundsExceptionNotRaised()
throws IndexOutOfBoundsException {

ArrayList emptyList = new ArrayList();
Object o = emptyList.get(0);
}
</pre>
 

=== To Test protected/private methods ===
* Case for protected methods
Place your tests in the same package as the classes under test.
* Case for private methods
Testing private methods may be an indication that those methods should be moved into another class to promote reusability.
 

=== Conditions to test get() and set() methods ===
Unit tests are intended to alleviate fear that something might break. If you think a get() or set() method could reasonably break, or has in fact contributed to a defect, then by all means write a test.
In short, test until you're confident. What you choose to test is subjective, based on your experiences and confidence level. Remember to be practical and maximize your testing investment.
 

=== To run setUp() and tearDown() code once for all tests ===

You can add a @BeforeClass annotation to a method to be run before all the tests in a class, and a @AfterClass annotation to a method to be run after all the tests in a class. Here's an example:

<pre>
package junitfaq;

import org.junit.*;
import static org.junit.Assert.*;
import java.util.*;

public class SimpleTest {

private Collection collection;

@BeforeClass
public static void oneTimeSetUp() {
// one-time initialization code
}

@AfterClass
public static void oneTimeTearDown() {
// one-time cleanup code
}

@Before
public void setUp() {
collection = new ArrayList();
}

@After
public void tearDown() {
collection.clear();
}

@Test
public void testEmptyCollection() {
assertTrue(collection.isEmpty());
}

@Test
public void testOneItemCollection() {
collection.add("itemA");
assertEquals(1, collection.size());
}
}
</pre>
Given this test, the methods will execute in the following order:

*oneTimeSetUp()
*setUp()
*testEmptyCollection()
*tearDown()
*setUp()
*testOneItemCollection()
*tearDown()
*oneTimeTearDown()
 

==Conclusion==
By following the guidelines given in this articles, one can write a good unit test using junit, which is as important as writing good quality code. 
A good quality unit test will take care of all classes, boundary conditions, domain data and functionality. 
A good test can be creative to explore all possibilities, thinking out of box. 
Finally automating the test using tool like junit which is in the native java language itself helps in saving manual intervention and time/money. 

==References==

* http://articles.techrepublic.com.com/5100-10878_11-1027676.html
* http://msdn.microsoft.com/en-us/library/aa292197%28VS.71%29.asp
* http://junit.sourceforge.net/doc/cookbook/cookbook.htm
* http://junit.sourceforge.net/doc/faq/faq.htm#overview
* http://clarkware.com/articles/JUnitPrimer.html#usage
* http://users.csc.calpoly.edu/~jdalbey/205/Resources/junitQuickStart.html
* http://www.cis.upenn.edu/~matuszek/cit591-2004/Lectures/
* http://en.wikipedia.org/wiki/JUnit
* http://www.laliluna.de/eclipse-junit-testing-tutorial.html
* http://junit.sourceforge.net/doc/faq/faq.htm

-------------------------------------------------------

CSC/ECE 517 Fall 2009/wiki1a 1 JunitTest

2009-09-08T19:02:47Z

Wolverine: /* To test an expected/unexpected exception */

'''Writing Effective JUnit Test Cases''' 
----

''JUnit is a testing framework aimed at making unit testing easy by simplifying the writing of test cases and by providing automated running of tests and test suites.''

The objective of this document is to provide a repository of rules that can be used in-order to write an effective Junit test.
This doc also discusses various sites and suggest which are the best sites to read for an overview of the topic and to understand the different philosophies of test-case design.

==Introduction==

=== Unit Testing Overview ===

The primary goal of unit testing is to take the smallest piece of testable software in the application, isolate it from the remainder of the code, and determine whether it behaves exactly as you expect.

'''Test Case''' 
It describes a scenario that can be exercised through the application. 
Each test case is divided into two parts: input and expected output. 
The input part lists all the test case statements that create variables or assign values to variables. 
The expected output part indicates the expected results; it shows either assertions or the message 'no exception' (when no assertions exist). 

The main issue in constructing a unit test is deciding the scope of test cases. 
If the scope is too narrow, then the tests will be trivial and the objects might pass the tests, but there will be no design of their interactions and interactions of objects are important for object oriented design. 
On the other hand if the scope is too broad, then there is a high chance that not every component of the new code will get tested. 
The programmer is then reduced to testing-by-poking-around, which is not an effective test strategy. 

=== JUnit Overview ===
Non-automated testing is usually like this: 
* An expression is used in a debugger, you can change debug expressions without recompiling, and you can wait to decide what to write until you have seen the running objects. 
* Expressions are tested as statements which print to the standard output stream. 
But its not preferred because: 
* They require human judgment to analyze their results. 
* They are cumbersome, non repeatable - you can only execute one debug expression at a time and a program with too many print statements causes the dreaded "Scroll Blindness". 
On the upper hand, JUnit tests, which uses the automated framework does not require human judgment to interpret, and it is easy to run many of them at the same time.
 
When you need to test something, here is what you do: 
* Annotate a method with @org.junit.Test 
* When you want to check a value, import org.junit.Assert.* statically, call assertTrue() and pass a boolean that is true if the test succeeds 
'''So what exactly is JUnit ?? ''' 
It is a open-source unit testing framework for Java and provides a way to organize test data and perform repeatable test execution. 
In JUnit, one has to write Java code, called a test class, that describes test data, invokes the methods to be tested, and determines test results. 
JUnit was originally written by Erich Gamma and Kent Beck. 
The official JUnit home page is http://junit.org. 
JUnit is Open Source Software, released under IBM's Common Public License Version 0.5 and hosted on SourceForge. 
It is an instance of the xUnit architecture for unit testing frameworks. JUnit features include: 
* Assertions for testing expected results 
* Test fixtures for sharing common test data 
* Test runners for running tests 
'''JUnit mailing lists and forums''' 
[http://groups.yahoo.com/group/junit/ JUnit user list] 
[http://lists.sourceforge.net/lists/listinfo/junit-announce JUnit announcements] 
[http://lists.sourceforge.net/lists/listinfo/junit-devel JUnit developer list] 
'''JUnit official documentation''' 
[http://junit.sourceforge.net/doc/testinfected/testing.htm JUnit Test Infected: Programmers Love Writing Tests] 
[http://junit.sourceforge.net/doc/cookbook/cookbook.htm JUnit Cookbook] 
[http://junit.sourceforge.net/doc/cookstour/cookstour.htm JUnit - A Cook's Tour] 
[http://junit.sourceforge.net/doc/faq/faq.htm JUnit FAQ] 
Although JUnit testing costs some time and money, but unit testing provides some crucial advantages, viz: 
Automation of the testing process 
Reduces difficulties of discovering errors contained in more complex pieces of the application 
Test coverage is often enhanced because attention is given to each unit. 
For example, 
if you have two units and decide it would be more cost effective to glue them together and initially test them as an integrated unit, an error could occur in a variety of places, now: 
* Is the error due to a defect in unit 1? 
* Is the error due to a defect in unit 2? 
* Is the error due to defects in both units? 
* Is the error due to a defect in the interface between the units? 
* Is the error due to a defect in the test? 
Finding the error (or errors) in the integrated module is much more complicated than first isolating the units, testing each, then integrating them and testing the whole. 
 

== Websites to lookout ==
These are some of the best webpages which will help you in getting more description as well as details about Junit.
 Also it will help you understand the test case design philosophy. 
=== For Overview ===
* Junit testing basics: 
http://articles.techrepublic.com.com/5100-10878_11-1027676.html

* Basics of Junit: 
http://junit.sourceforge.net/doc/cookbook/cookbook.htm
http://junit.sourceforge.net/doc/faq/faq.htm#overview

=== For Ideas on test case design ===
* For successful test automation: 
http://www.io.com/~wazmo/papers/seven_steps.html

* Unit testing principles: 
http://www.acm.org/ubiquity/views/t_burns_1.html

* For test suite effectiveness: 
http://java.sys-con.com/node/299945
 

== How to get started ==
=== Step 1: Installing JUnit ===

* Download latest version of JUnit from "http://sourceforge.net/projects/junit/files/". 
* Then install JUnit on your platform of choice: 
Windows 
To install JUnit on Windows, follow these steps: 
* Unzip the junit.zip distribution file to a directory referred to as %JUNIT_HOME%. 
* Add JUnit to the classpath: 
<pre>set CLASSPATH=%JUNIT_HOME%\junit.jar</pre>
'''Unix (bash)''' 
To install JUnit on Unix, follow these steps: 
* Unzip the junit.zip distribution file to a directory referred to as $JUNIT_HOME. 
* Add JUnit to the classpath: 
<pre>export CLASSPATH=$JUNIT_HOME/junit.jar</pre>

=== Step 2: Writing a Test Case ===
To write a test case, follow these steps: 

* Implement a class derived from TestCase, a base class provided by JUnit. 
public class BooksCartTest extends TestCase
* Be sure the test class belongs to the same package as that of the unit you wish to test 
* Override the setUp() method to initialize object(s) under test. 
* Optionally override the tearDown() method to release object(s) under test. 
* Define one or more public testXXX() methods that exercise the object(s) under test and assert expected results. 
The following is an example test case: 
<pre>
import junit.framework.TestCase;

public class BooksCartTest extends TestCase {

private BooksCart cart1;
private BooksCart cart2;

/**
* Sets up the test fixture.
*
* Called before every test case method.
*/
protected void setUp() {

cart1 = new BooksCart(6,8);
cart2 = new BooksCart(7,10);
}

/**
* Tears down the test fixture.
*
* Called after every test case method.
*/
protected void tearDown() {
// release objects under test here, if necessary
}

/**
* Tests emptying the cart.
*/
public void testEmpty() {

cart1.empty();
cart2.empty();
assertEquals(cart1, new BooksCart(3, 9));
assertTrue(!cart2.equals(cart1));
}
}
</pre>
Methods used in JUnit: 
* An assert method is a JUnit method that performs a test, and throws an AssertionFailedError if the test fails 
* static void assertTrue(boolean test) 
static void assertTrue(String message, boolean test)
- Throws an AssertionFailedError if the test fails 
- The optional message is included in the Error 
* static void assertFalse(boolean test) 
static void assertFalse(String message, boolean test)
- Throws an AssertionFailedError if the test fails 

=== Step 3: Writing a Test Suite ===
Next, we'll write a test suite that includes several test cases. The test suite will allow us to run all of its test cases in one fell swoop. 
'''To write a test suite, follow these steps:''' 
* Write a Java class that defines a static suite() factory method that creates a TestSuite containing all the tests. 
* Optionally define a main() method that runs the TestSuite in batch mode. 

The following is an example test suite: 
<pre>
import junit.framework.Test;
import junit.framework.TestSuite;

public class BooksCartTestSuite {

public static Test suite() {

TestSuite suite = new TestSuite();

//
// The BooksCartTest we created above.
//
suite.addTestSuite(BooksCartTest.class);

//
// Another example test suite of tests.
//
suite.addTest(CreditCardTestSuite.suite());

//
// Add more tests here
//

return suite;
}

/**
* Runs the test suite using the textual runner.
*/
public static void main(String[] args) {
junit.textui.TestRunner.run(suite());
}
}
</pre>

=== Step 4: Running the Test ===
Now that we've written a test suite containing a collection of test cases and other test suites, we can run either the test suite or any of its test cases individually. Running a TestSuite will automatically run all of its subordinate TestCase instances and TestSuite instances. Running a TestCase will automatically invoke all of its public testXXX() methods.
JUnit provides both a textual and a graphical user interface. Both user interfaces indicate how many tests were run, any errors or failures, and a simple completion status. The simplicity of the user interfaces is the key to running tests quickly. You should be able to run your tests and know the test status with a glance, much like you do with a compiler.

To run our test case using the textual user interface, use: 
<pre>java junit.textui.TestRunner BooksCartTest </pre>
The textual user interface displays "OK" if all the tests passed and failure messages if any of the tests failed. 
To run the test case using the graphical user interface, use: 
<pre>java junit.swingui.TestRunner BooksCartTest </pre> 
The graphical user interface displays a Swing window with a green progress bar if all the tests passed or a red progress bar if any of the tests failed. 
The BooksCartTest Suite can be run similarly: 
<pre>java junit.swingui.TestRunner BooksCartTestSuite</pre>

== Rules for designing effective JUnit Test cases ==
* Identify and assemble a list of all the actions that your program should be able to perform. use cases,nonfunctional requirements specifications, test case specifications, user interface design documents, mockups, user profiles, and various additional artifacts.
* Identify the code's entry points - central pieces of code that exercise the functionality that the code as a whole is designed to undertake.
* Pair entry points with the use cases that they implement.
* Create test cases by applying the initialize/work/check procedure.
** Initialize: Create the environment that the test expects to run in. The initialization code can either be in the beginning of the test or in the setUp() method.
** Work: Call the code that is being tested, capturing any interesting output and recording any interesting statistics.
** Check: Use assert statements to ensure that the code worked as expected.
* Develop runtime event diagrams and use them to facilitate testing.
* Follow KISS rule:It's a bad idea to keep the input source name and expression in the test case. Some items (server names, usernames and passwords, etc.) should not live in the test files, which should be configurable for the specific deployment. Rather, design the test cases to facilitate separation of test drivers and test data, test driver reuse over a larger set of data, and test data reuse over a larger set of test drivers. On the other hand, don't over-architect a simple test case implementation. Typically, the test case specification already defines most of the system states and allows parameter descriptions for a scenario, so there's no point in making everything parameterizable in the test implementation.

==Rules for coding effective JUnit Tests==

=== Using Test Fixture for a common set of objects ===
Using a test fixture avoids duplicating the code necessary to initialize (and cleanup) the common objects.
Tests can use the objects (variables) in a test fixture, with each test invoking different methods on objects in the fixture and asserting different expected results. Each test runs in its own test fixture to isolate tests from the changes made by other tests. That is, tests don't share the state of objects in the test fixture. Because the tests are isolated, they can be run in any order.
To create a test fixture, declare instance variables for the common objects. Initialize these objects in a public void method annotated with @Before. The JUnit framework automatically invokes any @Before methods before each test is run.
The following example shows a test fixture with a common Collection object.
<pre>
package junitfaq;

import org.junit.*;
import static org.junit.Assert.*;
import java.util.*;

public class SimpleTest {

private Collection<Object> collection;

@Before
public void setUp() {
collection = new ArrayList<Object>();
}

@Test
public void testEmptyCollection() {
assertTrue(collection.isEmpty());
}

@Test
public void testOneItemCollection() {
collection.add("itemA");
assertEquals(1, collection.size());
}
}
</pre>
Given this test, the methods might execute in the following order: 
setUp() 
testEmptyCollection() 
setUp() 
testOneItemCollection() 
The ordering of test-method invocations is not guaranteed, so testOneItemCollection() might be executed before testEmptyCollection(). But it doesn't matter, because each method gets its own instance of the collection.
Although JUnit provides a new instance of the fixture objects for each test method, if you allocate any external resources in a @Before method, you should release them after the test runs by annotating a method with @After. The JUnit framework automatically invokes any @After methods after each test is run. For example:
<pre>
package junitfaq;

import org.junit.*;
import static org.junit.Assert.*;
import java.io.*;

public class OutputTest {

private File output;

@Before
public void createOutputFile() {
output = new File(...);
}

@After
public void deleteOutputFile() {
output.delete();
}

@Test
public void testSomethingWithFile() {
...
}
}
</pre>
With this test, the methods will execute in the following order:

* createOutputFile()
* testSomethingWithFile()
* deleteOutputFile()

=== To Test a method that doesnot return anything ===
If a method doesn't return a value, it might have some side effect. Actually, if it doesn't return a value AND doesn't have a side effect, it isn't doing anything.
There may be a way to verify that the side effect actually occurred as expected. For example, consider the add() method in the Collection classes. There are ways of verifying that the side effect happened (i.e. the object was added). You can check the size and assert that it is what is expected:

<pre>
public void testCollectionAdd() {
Collection collection = new ArrayList();
assertEquals(0, collection.size());
collection.add("itemA");
assertEquals(1, collection.size());
collection.add("itemB");
assertEquals(2, collection.size());
}
</pre>
=== To test an expected/unexpected exception ===
* Case of expected exception
Add the optional expected attribute to the @Test annotation. The following is an example test that passes when the expected IndexOutOfBoundsException is raised:
<pre>
@Test(expected=IndexOutOfBoundsException.class)
public void testIndexOutOfBoundsException() {
ArrayList emptyList = new ArrayList();
Object o = emptyList.get(0);
}
</pre>
* Case of unexpected exception
Declare the exception in the throws clause of the test method and don't catch the exception within the test method. Uncaught exceptions will cause the test to fail with an error.
The following is an example test that fails when the IndexOutOfBoundsException is raised:
<pre>
@Test
public void testIndexOutOfBoundsExceptionNotRaised()
throws IndexOutOfBoundsException {

ArrayList emptyList = new ArrayList();
Object o = emptyList.get(0);
}
</pre>
 

=== To Test protected/private methods ===
* Case for protected methods
Place your tests in the same package as the classes under test.
* Case for private methods
Testing private methods may be an indication that those methods should be moved into another class to promote reusability.
 

=== Conditions to test get() and set() methods ===
Unit tests are intended to alleviate fear that something might break. If you think a get() or set() method could reasonably break, or has in fact contributed to a defect, then by all means write a test.
In short, test until you're confident. What you choose to test is subjective, based on your experiences and confidence level. Remember to be practical and maximize your testing investment.
 

=== To run setUp() and tearDown() code once for all tests ===

You can add a @BeforeClass annotation to a method to be run before all the tests in a class, and a @AfterClass annotation to a method to be run after all the tests in a class. Here's an example:

<pre>
package junitfaq;

import org.junit.*;
import static org.junit.Assert.*;
import java.util.*;

public class SimpleTest {

private Collection collection;

@BeforeClass
public static void oneTimeSetUp() {
// one-time initialization code
}

@AfterClass
public static void oneTimeTearDown() {
// one-time cleanup code
}

@Before
public void setUp() {
collection = new ArrayList();
}

@After
public void tearDown() {
collection.clear();
}

@Test
public void testEmptyCollection() {
assertTrue(collection.isEmpty());
}

@Test
public void testOneItemCollection() {
collection.add("itemA");
assertEquals(1, collection.size());
}
}
</pre>
Given this test, the methods will execute in the following order:

*oneTimeSetUp()
*setUp()
*testEmptyCollection()
*tearDown()
*setUp()
*testOneItemCollection()
*tearDown()
*oneTimeTearDown()
 

==Conclusion==
By following the guidelines given in this articles, one can write a good unit test using junit, which is as important as writing good quality code. 
A good quality unit test will take care of all classes, boundary conditions, domain data and functionality. 
A good test can be creative to explore all possibilities, thinking out of box. 
Finally automating the test using tool like junit which is in the native java language itself helps in saving manual intervention and time/money. 

==References==

* http://articles.techrepublic.com.com/5100-10878_11-1027676.html
* http://msdn.microsoft.com/en-us/library/aa292197%28VS.71%29.asp
* http://junit.sourceforge.net/doc/cookbook/cookbook.htm
* http://junit.sourceforge.net/doc/faq/faq.htm#overview
* http://clarkware.com/articles/JUnitPrimer.html#usage
* http://users.csc.calpoly.edu/~jdalbey/205/Resources/junitQuickStart.html
* http://www.cis.upenn.edu/~matuszek/cit591-2004/Lectures/
* http://en.wikipedia.org/wiki/JUnit
* http://www.laliluna.de/eclipse-junit-testing-tutorial.html
* http://junit.sourceforge.net/doc/faq/faq.htm

-------------------------------------------------------

CSC/ECE 517 Fall 2009/wiki1a 1 JunitTest

2009-09-08T19:02:32Z

Wolverine: /* To Test protected/private methods */

'''Writing Effective JUnit Test Cases''' 
----

''JUnit is a testing framework aimed at making unit testing easy by simplifying the writing of test cases and by providing automated running of tests and test suites.''

The objective of this document is to provide a repository of rules that can be used in-order to write an effective Junit test.
This doc also discusses various sites and suggest which are the best sites to read for an overview of the topic and to understand the different philosophies of test-case design.

==Introduction==

=== Unit Testing Overview ===

The primary goal of unit testing is to take the smallest piece of testable software in the application, isolate it from the remainder of the code, and determine whether it behaves exactly as you expect.

'''Test Case''' 
It describes a scenario that can be exercised through the application. 
Each test case is divided into two parts: input and expected output. 
The input part lists all the test case statements that create variables or assign values to variables. 
The expected output part indicates the expected results; it shows either assertions or the message 'no exception' (when no assertions exist). 

The main issue in constructing a unit test is deciding the scope of test cases. 
If the scope is too narrow, then the tests will be trivial and the objects might pass the tests, but there will be no design of their interactions and interactions of objects are important for object oriented design. 
On the other hand if the scope is too broad, then there is a high chance that not every component of the new code will get tested. 
The programmer is then reduced to testing-by-poking-around, which is not an effective test strategy. 

=== JUnit Overview ===
Non-automated testing is usually like this: 
* An expression is used in a debugger, you can change debug expressions without recompiling, and you can wait to decide what to write until you have seen the running objects. 
* Expressions are tested as statements which print to the standard output stream. 
But its not preferred because: 
* They require human judgment to analyze their results. 
* They are cumbersome, non repeatable - you can only execute one debug expression at a time and a program with too many print statements causes the dreaded "Scroll Blindness". 
On the upper hand, JUnit tests, which uses the automated framework does not require human judgment to interpret, and it is easy to run many of them at the same time.
 
When you need to test something, here is what you do: 
* Annotate a method with @org.junit.Test 
* When you want to check a value, import org.junit.Assert.* statically, call assertTrue() and pass a boolean that is true if the test succeeds 
'''So what exactly is JUnit ?? ''' 
It is a open-source unit testing framework for Java and provides a way to organize test data and perform repeatable test execution. 
In JUnit, one has to write Java code, called a test class, that describes test data, invokes the methods to be tested, and determines test results. 
JUnit was originally written by Erich Gamma and Kent Beck. 
The official JUnit home page is http://junit.org. 
JUnit is Open Source Software, released under IBM's Common Public License Version 0.5 and hosted on SourceForge. 
It is an instance of the xUnit architecture for unit testing frameworks. JUnit features include: 
* Assertions for testing expected results 
* Test fixtures for sharing common test data 
* Test runners for running tests 
'''JUnit mailing lists and forums''' 
[http://groups.yahoo.com/group/junit/ JUnit user list] 
[http://lists.sourceforge.net/lists/listinfo/junit-announce JUnit announcements] 
[http://lists.sourceforge.net/lists/listinfo/junit-devel JUnit developer list] 
'''JUnit official documentation''' 
[http://junit.sourceforge.net/doc/testinfected/testing.htm JUnit Test Infected: Programmers Love Writing Tests] 
[http://junit.sourceforge.net/doc/cookbook/cookbook.htm JUnit Cookbook] 
[http://junit.sourceforge.net/doc/cookstour/cookstour.htm JUnit - A Cook's Tour] 
[http://junit.sourceforge.net/doc/faq/faq.htm JUnit FAQ] 
Although JUnit testing costs some time and money, but unit testing provides some crucial advantages, viz: 
Automation of the testing process 
Reduces difficulties of discovering errors contained in more complex pieces of the application 
Test coverage is often enhanced because attention is given to each unit. 
For example, 
if you have two units and decide it would be more cost effective to glue them together and initially test them as an integrated unit, an error could occur in a variety of places, now: 
* Is the error due to a defect in unit 1? 
* Is the error due to a defect in unit 2? 
* Is the error due to defects in both units? 
* Is the error due to a defect in the interface between the units? 
* Is the error due to a defect in the test? 
Finding the error (or errors) in the integrated module is much more complicated than first isolating the units, testing each, then integrating them and testing the whole. 
 

== Websites to lookout ==
These are some of the best webpages which will help you in getting more description as well as details about Junit.
 Also it will help you understand the test case design philosophy. 
=== For Overview ===
* Junit testing basics: 
http://articles.techrepublic.com.com/5100-10878_11-1027676.html

* Basics of Junit: 
http://junit.sourceforge.net/doc/cookbook/cookbook.htm
http://junit.sourceforge.net/doc/faq/faq.htm#overview

=== For Ideas on test case design ===
* For successful test automation: 
http://www.io.com/~wazmo/papers/seven_steps.html

* Unit testing principles: 
http://www.acm.org/ubiquity/views/t_burns_1.html

* For test suite effectiveness: 
http://java.sys-con.com/node/299945
 

== How to get started ==
=== Step 1: Installing JUnit ===

* Download latest version of JUnit from "http://sourceforge.net/projects/junit/files/". 
* Then install JUnit on your platform of choice: 
Windows 
To install JUnit on Windows, follow these steps: 
* Unzip the junit.zip distribution file to a directory referred to as %JUNIT_HOME%. 
* Add JUnit to the classpath: 
<pre>set CLASSPATH=%JUNIT_HOME%\junit.jar</pre>
'''Unix (bash)''' 
To install JUnit on Unix, follow these steps: 
* Unzip the junit.zip distribution file to a directory referred to as $JUNIT_HOME. 
* Add JUnit to the classpath: 
<pre>export CLASSPATH=$JUNIT_HOME/junit.jar</pre>

=== Step 2: Writing a Test Case ===
To write a test case, follow these steps: 

* Implement a class derived from TestCase, a base class provided by JUnit. 
public class BooksCartTest extends TestCase
* Be sure the test class belongs to the same package as that of the unit you wish to test 
* Override the setUp() method to initialize object(s) under test. 
* Optionally override the tearDown() method to release object(s) under test. 
* Define one or more public testXXX() methods that exercise the object(s) under test and assert expected results. 
The following is an example test case: 
<pre>
import junit.framework.TestCase;

public class BooksCartTest extends TestCase {

private BooksCart cart1;
private BooksCart cart2;

/**
* Sets up the test fixture.
*
* Called before every test case method.
*/
protected void setUp() {

cart1 = new BooksCart(6,8);
cart2 = new BooksCart(7,10);
}

/**
* Tears down the test fixture.
*
* Called after every test case method.
*/
protected void tearDown() {
// release objects under test here, if necessary
}

/**
* Tests emptying the cart.
*/
public void testEmpty() {

cart1.empty();
cart2.empty();
assertEquals(cart1, new BooksCart(3, 9));
assertTrue(!cart2.equals(cart1));
}
}
</pre>
Methods used in JUnit: 
* An assert method is a JUnit method that performs a test, and throws an AssertionFailedError if the test fails 
* static void assertTrue(boolean test) 
static void assertTrue(String message, boolean test)
- Throws an AssertionFailedError if the test fails 
- The optional message is included in the Error 
* static void assertFalse(boolean test) 
static void assertFalse(String message, boolean test)
- Throws an AssertionFailedError if the test fails 

=== Step 3: Writing a Test Suite ===
Next, we'll write a test suite that includes several test cases. The test suite will allow us to run all of its test cases in one fell swoop. 
'''To write a test suite, follow these steps:''' 
* Write a Java class that defines a static suite() factory method that creates a TestSuite containing all the tests. 
* Optionally define a main() method that runs the TestSuite in batch mode. 

The following is an example test suite: 
<pre>
import junit.framework.Test;
import junit.framework.TestSuite;

public class BooksCartTestSuite {

public static Test suite() {

TestSuite suite = new TestSuite();

//
// The BooksCartTest we created above.
//
suite.addTestSuite(BooksCartTest.class);

//
// Another example test suite of tests.
//
suite.addTest(CreditCardTestSuite.suite());

//
// Add more tests here
//

return suite;
}

/**
* Runs the test suite using the textual runner.
*/
public static void main(String[] args) {
junit.textui.TestRunner.run(suite());
}
}
</pre>

=== Step 4: Running the Test ===
Now that we've written a test suite containing a collection of test cases and other test suites, we can run either the test suite or any of its test cases individually. Running a TestSuite will automatically run all of its subordinate TestCase instances and TestSuite instances. Running a TestCase will automatically invoke all of its public testXXX() methods.
JUnit provides both a textual and a graphical user interface. Both user interfaces indicate how many tests were run, any errors or failures, and a simple completion status. The simplicity of the user interfaces is the key to running tests quickly. You should be able to run your tests and know the test status with a glance, much like you do with a compiler.

To run our test case using the textual user interface, use: 
<pre>java junit.textui.TestRunner BooksCartTest </pre>
The textual user interface displays "OK" if all the tests passed and failure messages if any of the tests failed. 
To run the test case using the graphical user interface, use: 
<pre>java junit.swingui.TestRunner BooksCartTest </pre> 
The graphical user interface displays a Swing window with a green progress bar if all the tests passed or a red progress bar if any of the tests failed. 
The BooksCartTest Suite can be run similarly: 
<pre>java junit.swingui.TestRunner BooksCartTestSuite</pre>

== Rules for designing effective JUnit Test cases ==
* Identify and assemble a list of all the actions that your program should be able to perform. use cases,nonfunctional requirements specifications, test case specifications, user interface design documents, mockups, user profiles, and various additional artifacts.
* Identify the code's entry points - central pieces of code that exercise the functionality that the code as a whole is designed to undertake.
* Pair entry points with the use cases that they implement.
* Create test cases by applying the initialize/work/check procedure.
** Initialize: Create the environment that the test expects to run in. The initialization code can either be in the beginning of the test or in the setUp() method.
** Work: Call the code that is being tested, capturing any interesting output and recording any interesting statistics.
** Check: Use assert statements to ensure that the code worked as expected.
* Develop runtime event diagrams and use them to facilitate testing.
* Follow KISS rule:It's a bad idea to keep the input source name and expression in the test case. Some items (server names, usernames and passwords, etc.) should not live in the test files, which should be configurable for the specific deployment. Rather, design the test cases to facilitate separation of test drivers and test data, test driver reuse over a larger set of data, and test data reuse over a larger set of test drivers. On the other hand, don't over-architect a simple test case implementation. Typically, the test case specification already defines most of the system states and allows parameter descriptions for a scenario, so there's no point in making everything parameterizable in the test implementation.

==Rules for coding effective JUnit Tests==

=== Using Test Fixture for a common set of objects ===
Using a test fixture avoids duplicating the code necessary to initialize (and cleanup) the common objects.
Tests can use the objects (variables) in a test fixture, with each test invoking different methods on objects in the fixture and asserting different expected results. Each test runs in its own test fixture to isolate tests from the changes made by other tests. That is, tests don't share the state of objects in the test fixture. Because the tests are isolated, they can be run in any order.
To create a test fixture, declare instance variables for the common objects. Initialize these objects in a public void method annotated with @Before. The JUnit framework automatically invokes any @Before methods before each test is run.
The following example shows a test fixture with a common Collection object.
<pre>
package junitfaq;

import org.junit.*;
import static org.junit.Assert.*;
import java.util.*;

public class SimpleTest {

private Collection<Object> collection;

@Before
public void setUp() {
collection = new ArrayList<Object>();
}

@Test
public void testEmptyCollection() {
assertTrue(collection.isEmpty());
}

@Test
public void testOneItemCollection() {
collection.add("itemA");
assertEquals(1, collection.size());
}
}
</pre>
Given this test, the methods might execute in the following order: 
setUp() 
testEmptyCollection() 
setUp() 
testOneItemCollection() 
The ordering of test-method invocations is not guaranteed, so testOneItemCollection() might be executed before testEmptyCollection(). But it doesn't matter, because each method gets its own instance of the collection.
Although JUnit provides a new instance of the fixture objects for each test method, if you allocate any external resources in a @Before method, you should release them after the test runs by annotating a method with @After. The JUnit framework automatically invokes any @After methods after each test is run. For example:
<pre>
package junitfaq;

import org.junit.*;
import static org.junit.Assert.*;
import java.io.*;

public class OutputTest {

private File output;

@Before
public void createOutputFile() {
output = new File(...);
}

@After
public void deleteOutputFile() {
output.delete();
}

@Test
public void testSomethingWithFile() {
...
}
}
</pre>
With this test, the methods will execute in the following order:

* createOutputFile()
* testSomethingWithFile()
* deleteOutputFile()

=== To Test a method that doesnot return anything ===
If a method doesn't return a value, it might have some side effect. Actually, if it doesn't return a value AND doesn't have a side effect, it isn't doing anything.
There may be a way to verify that the side effect actually occurred as expected. For example, consider the add() method in the Collection classes. There are ways of verifying that the side effect happened (i.e. the object was added). You can check the size and assert that it is what is expected:

<pre>
public void testCollectionAdd() {
Collection collection = new ArrayList();
assertEquals(0, collection.size());
collection.add("itemA");
assertEquals(1, collection.size());
collection.add("itemB");
assertEquals(2, collection.size());
}
</pre>
=== To test an expected/unexpected exception ===
* Case of expected exception
Add the optional expected attribute to the @Test annotation. The following is an example test that passes when the expected IndexOutOfBoundsException is raised:
<pre>
@Test(expected=IndexOutOfBoundsException.class)
public void testIndexOutOfBoundsException() {
ArrayList emptyList = new ArrayList();
Object o = emptyList.get(0);
}
</pre>
* Case of unexpected exception
Declare the exception in the throws clause of the test method and don't catch the exception within the test method. Uncaught exceptions will cause the test to fail with an error.
The following is an example test that fails when the IndexOutOfBoundsException is raised:
<pre>
@Test
public void testIndexOutOfBoundsExceptionNotRaised()
throws IndexOutOfBoundsException {

ArrayList emptyList = new ArrayList();
Object o = emptyList.get(0);
}
</pre>

=== To Test protected/private methods ===
* Case for protected methods
Place your tests in the same package as the classes under test.
* Case for private methods
Testing private methods may be an indication that those methods should be moved into another class to promote reusability.
 

=== Conditions to test get() and set() methods ===
Unit tests are intended to alleviate fear that something might break. If you think a get() or set() method could reasonably break, or has in fact contributed to a defect, then by all means write a test.
In short, test until you're confident. What you choose to test is subjective, based on your experiences and confidence level. Remember to be practical and maximize your testing investment.
 

=== To run setUp() and tearDown() code once for all tests ===

You can add a @BeforeClass annotation to a method to be run before all the tests in a class, and a @AfterClass annotation to a method to be run after all the tests in a class. Here's an example:

<pre>
package junitfaq;

import org.junit.*;
import static org.junit.Assert.*;
import java.util.*;

public class SimpleTest {

private Collection collection;

@BeforeClass
public static void oneTimeSetUp() {
// one-time initialization code
}

@AfterClass
public static void oneTimeTearDown() {
// one-time cleanup code
}

@Before
public void setUp() {
collection = new ArrayList();
}

@After
public void tearDown() {
collection.clear();
}

@Test
public void testEmptyCollection() {
assertTrue(collection.isEmpty());
}

@Test
public void testOneItemCollection() {
collection.add("itemA");
assertEquals(1, collection.size());
}
}
</pre>
Given this test, the methods will execute in the following order:

*oneTimeSetUp()
*setUp()
*testEmptyCollection()
*tearDown()
*setUp()
*testOneItemCollection()
*tearDown()
*oneTimeTearDown()
 

==Conclusion==
By following the guidelines given in this articles, one can write a good unit test using junit, which is as important as writing good quality code. 
A good quality unit test will take care of all classes, boundary conditions, domain data and functionality. 
A good test can be creative to explore all possibilities, thinking out of box. 
Finally automating the test using tool like junit which is in the native java language itself helps in saving manual intervention and time/money. 

==References==

* http://articles.techrepublic.com.com/5100-10878_11-1027676.html
* http://msdn.microsoft.com/en-us/library/aa292197%28VS.71%29.asp
* http://junit.sourceforge.net/doc/cookbook/cookbook.htm
* http://junit.sourceforge.net/doc/faq/faq.htm#overview
* http://clarkware.com/articles/JUnitPrimer.html#usage
* http://users.csc.calpoly.edu/~jdalbey/205/Resources/junitQuickStart.html
* http://www.cis.upenn.edu/~matuszek/cit591-2004/Lectures/
* http://en.wikipedia.org/wiki/JUnit
* http://www.laliluna.de/eclipse-junit-testing-tutorial.html
* http://junit.sourceforge.net/doc/faq/faq.htm

-------------------------------------------------------

CSC/ECE 517 Fall 2009/wiki1a 1 JunitTest

2009-09-08T19:02:15Z

Wolverine: /* Conditions to test get() and set() methods */

'''Writing Effective JUnit Test Cases''' 
----

''JUnit is a testing framework aimed at making unit testing easy by simplifying the writing of test cases and by providing automated running of tests and test suites.''

The objective of this document is to provide a repository of rules that can be used in-order to write an effective Junit test.
This doc also discusses various sites and suggest which are the best sites to read for an overview of the topic and to understand the different philosophies of test-case design.

==Introduction==

=== Unit Testing Overview ===

The primary goal of unit testing is to take the smallest piece of testable software in the application, isolate it from the remainder of the code, and determine whether it behaves exactly as you expect.

'''Test Case''' 
It describes a scenario that can be exercised through the application. 
Each test case is divided into two parts: input and expected output. 
The input part lists all the test case statements that create variables or assign values to variables. 
The expected output part indicates the expected results; it shows either assertions or the message 'no exception' (when no assertions exist). 

The main issue in constructing a unit test is deciding the scope of test cases. 
If the scope is too narrow, then the tests will be trivial and the objects might pass the tests, but there will be no design of their interactions and interactions of objects are important for object oriented design. 
On the other hand if the scope is too broad, then there is a high chance that not every component of the new code will get tested. 
The programmer is then reduced to testing-by-poking-around, which is not an effective test strategy. 

=== JUnit Overview ===
Non-automated testing is usually like this: 
* An expression is used in a debugger, you can change debug expressions without recompiling, and you can wait to decide what to write until you have seen the running objects. 
* Expressions are tested as statements which print to the standard output stream. 
But its not preferred because: 
* They require human judgment to analyze their results. 
* They are cumbersome, non repeatable - you can only execute one debug expression at a time and a program with too many print statements causes the dreaded "Scroll Blindness". 
On the upper hand, JUnit tests, which uses the automated framework does not require human judgment to interpret, and it is easy to run many of them at the same time.
 
When you need to test something, here is what you do: 
* Annotate a method with @org.junit.Test 
* When you want to check a value, import org.junit.Assert.* statically, call assertTrue() and pass a boolean that is true if the test succeeds 
'''So what exactly is JUnit ?? ''' 
It is a open-source unit testing framework for Java and provides a way to organize test data and perform repeatable test execution. 
In JUnit, one has to write Java code, called a test class, that describes test data, invokes the methods to be tested, and determines test results. 
JUnit was originally written by Erich Gamma and Kent Beck. 
The official JUnit home page is http://junit.org. 
JUnit is Open Source Software, released under IBM's Common Public License Version 0.5 and hosted on SourceForge. 
It is an instance of the xUnit architecture for unit testing frameworks. JUnit features include: 
* Assertions for testing expected results 
* Test fixtures for sharing common test data 
* Test runners for running tests 
'''JUnit mailing lists and forums''' 
[http://groups.yahoo.com/group/junit/ JUnit user list] 
[http://lists.sourceforge.net/lists/listinfo/junit-announce JUnit announcements] 
[http://lists.sourceforge.net/lists/listinfo/junit-devel JUnit developer list] 
'''JUnit official documentation''' 
[http://junit.sourceforge.net/doc/testinfected/testing.htm JUnit Test Infected: Programmers Love Writing Tests] 
[http://junit.sourceforge.net/doc/cookbook/cookbook.htm JUnit Cookbook] 
[http://junit.sourceforge.net/doc/cookstour/cookstour.htm JUnit - A Cook's Tour] 
[http://junit.sourceforge.net/doc/faq/faq.htm JUnit FAQ] 
Although JUnit testing costs some time and money, but unit testing provides some crucial advantages, viz: 
Automation of the testing process 
Reduces difficulties of discovering errors contained in more complex pieces of the application 
Test coverage is often enhanced because attention is given to each unit. 
For example, 
if you have two units and decide it would be more cost effective to glue them together and initially test them as an integrated unit, an error could occur in a variety of places, now: 
* Is the error due to a defect in unit 1? 
* Is the error due to a defect in unit 2? 
* Is the error due to defects in both units? 
* Is the error due to a defect in the interface between the units? 
* Is the error due to a defect in the test? 
Finding the error (or errors) in the integrated module is much more complicated than first isolating the units, testing each, then integrating them and testing the whole. 
 

== Websites to lookout ==
These are some of the best webpages which will help you in getting more description as well as details about Junit.
 Also it will help you understand the test case design philosophy. 
=== For Overview ===
* Junit testing basics: 
http://articles.techrepublic.com.com/5100-10878_11-1027676.html

* Basics of Junit: 
http://junit.sourceforge.net/doc/cookbook/cookbook.htm
http://junit.sourceforge.net/doc/faq/faq.htm#overview

=== For Ideas on test case design ===
* For successful test automation: 
http://www.io.com/~wazmo/papers/seven_steps.html

* Unit testing principles: 
http://www.acm.org/ubiquity/views/t_burns_1.html

* For test suite effectiveness: 
http://java.sys-con.com/node/299945
 

== How to get started ==
=== Step 1: Installing JUnit ===

* Download latest version of JUnit from "http://sourceforge.net/projects/junit/files/". 
* Then install JUnit on your platform of choice: 
Windows 
To install JUnit on Windows, follow these steps: 
* Unzip the junit.zip distribution file to a directory referred to as %JUNIT_HOME%. 
* Add JUnit to the classpath: 
<pre>set CLASSPATH=%JUNIT_HOME%\junit.jar</pre>
'''Unix (bash)''' 
To install JUnit on Unix, follow these steps: 
* Unzip the junit.zip distribution file to a directory referred to as $JUNIT_HOME. 
* Add JUnit to the classpath: 
<pre>export CLASSPATH=$JUNIT_HOME/junit.jar</pre>

=== Step 2: Writing a Test Case ===
To write a test case, follow these steps: 

* Implement a class derived from TestCase, a base class provided by JUnit. 
public class BooksCartTest extends TestCase
* Be sure the test class belongs to the same package as that of the unit you wish to test 
* Override the setUp() method to initialize object(s) under test. 
* Optionally override the tearDown() method to release object(s) under test. 
* Define one or more public testXXX() methods that exercise the object(s) under test and assert expected results. 
The following is an example test case: 
<pre>
import junit.framework.TestCase;

public class BooksCartTest extends TestCase {

private BooksCart cart1;
private BooksCart cart2;

/**
* Sets up the test fixture.
*
* Called before every test case method.
*/
protected void setUp() {

cart1 = new BooksCart(6,8);
cart2 = new BooksCart(7,10);
}

/**
* Tears down the test fixture.
*
* Called after every test case method.
*/
protected void tearDown() {
// release objects under test here, if necessary
}

/**
* Tests emptying the cart.
*/
public void testEmpty() {

cart1.empty();
cart2.empty();
assertEquals(cart1, new BooksCart(3, 9));
assertTrue(!cart2.equals(cart1));
}
}
</pre>
Methods used in JUnit: 
* An assert method is a JUnit method that performs a test, and throws an AssertionFailedError if the test fails 
* static void assertTrue(boolean test) 
static void assertTrue(String message, boolean test)
- Throws an AssertionFailedError if the test fails 
- The optional message is included in the Error 
* static void assertFalse(boolean test) 
static void assertFalse(String message, boolean test)
- Throws an AssertionFailedError if the test fails 

=== Step 3: Writing a Test Suite ===
Next, we'll write a test suite that includes several test cases. The test suite will allow us to run all of its test cases in one fell swoop. 
'''To write a test suite, follow these steps:''' 
* Write a Java class that defines a static suite() factory method that creates a TestSuite containing all the tests. 
* Optionally define a main() method that runs the TestSuite in batch mode. 

The following is an example test suite: 
<pre>
import junit.framework.Test;
import junit.framework.TestSuite;

public class BooksCartTestSuite {

public static Test suite() {

TestSuite suite = new TestSuite();

//
// The BooksCartTest we created above.
//
suite.addTestSuite(BooksCartTest.class);

//
// Another example test suite of tests.
//
suite.addTest(CreditCardTestSuite.suite());

//
// Add more tests here
//

return suite;
}

/**
* Runs the test suite using the textual runner.
*/
public static void main(String[] args) {
junit.textui.TestRunner.run(suite());
}
}
</pre>

=== Step 4: Running the Test ===
Now that we've written a test suite containing a collection of test cases and other test suites, we can run either the test suite or any of its test cases individually. Running a TestSuite will automatically run all of its subordinate TestCase instances and TestSuite instances. Running a TestCase will automatically invoke all of its public testXXX() methods.
JUnit provides both a textual and a graphical user interface. Both user interfaces indicate how many tests were run, any errors or failures, and a simple completion status. The simplicity of the user interfaces is the key to running tests quickly. You should be able to run your tests and know the test status with a glance, much like you do with a compiler.

To run our test case using the textual user interface, use: 
<pre>java junit.textui.TestRunner BooksCartTest </pre>
The textual user interface displays "OK" if all the tests passed and failure messages if any of the tests failed. 
To run the test case using the graphical user interface, use: 
<pre>java junit.swingui.TestRunner BooksCartTest </pre> 
The graphical user interface displays a Swing window with a green progress bar if all the tests passed or a red progress bar if any of the tests failed. 
The BooksCartTest Suite can be run similarly: 
<pre>java junit.swingui.TestRunner BooksCartTestSuite</pre>

== Rules for designing effective JUnit Test cases ==
* Identify and assemble a list of all the actions that your program should be able to perform. use cases,nonfunctional requirements specifications, test case specifications, user interface design documents, mockups, user profiles, and various additional artifacts.
* Identify the code's entry points - central pieces of code that exercise the functionality that the code as a whole is designed to undertake.
* Pair entry points with the use cases that they implement.
* Create test cases by applying the initialize/work/check procedure.
** Initialize: Create the environment that the test expects to run in. The initialization code can either be in the beginning of the test or in the setUp() method.
** Work: Call the code that is being tested, capturing any interesting output and recording any interesting statistics.
** Check: Use assert statements to ensure that the code worked as expected.
* Develop runtime event diagrams and use them to facilitate testing.
* Follow KISS rule:It's a bad idea to keep the input source name and expression in the test case. Some items (server names, usernames and passwords, etc.) should not live in the test files, which should be configurable for the specific deployment. Rather, design the test cases to facilitate separation of test drivers and test data, test driver reuse over a larger set of data, and test data reuse over a larger set of test drivers. On the other hand, don't over-architect a simple test case implementation. Typically, the test case specification already defines most of the system states and allows parameter descriptions for a scenario, so there's no point in making everything parameterizable in the test implementation.

==Rules for coding effective JUnit Tests==

=== Using Test Fixture for a common set of objects ===
Using a test fixture avoids duplicating the code necessary to initialize (and cleanup) the common objects.
Tests can use the objects (variables) in a test fixture, with each test invoking different methods on objects in the fixture and asserting different expected results. Each test runs in its own test fixture to isolate tests from the changes made by other tests. That is, tests don't share the state of objects in the test fixture. Because the tests are isolated, they can be run in any order.
To create a test fixture, declare instance variables for the common objects. Initialize these objects in a public void method annotated with @Before. The JUnit framework automatically invokes any @Before methods before each test is run.
The following example shows a test fixture with a common Collection object.
<pre>
package junitfaq;

import org.junit.*;
import static org.junit.Assert.*;
import java.util.*;

public class SimpleTest {

private Collection<Object> collection;

@Before
public void setUp() {
collection = new ArrayList<Object>();
}

@Test
public void testEmptyCollection() {
assertTrue(collection.isEmpty());
}

@Test
public void testOneItemCollection() {
collection.add("itemA");
assertEquals(1, collection.size());
}
}
</pre>
Given this test, the methods might execute in the following order: 
setUp() 
testEmptyCollection() 
setUp() 
testOneItemCollection() 
The ordering of test-method invocations is not guaranteed, so testOneItemCollection() might be executed before testEmptyCollection(). But it doesn't matter, because each method gets its own instance of the collection.
Although JUnit provides a new instance of the fixture objects for each test method, if you allocate any external resources in a @Before method, you should release them after the test runs by annotating a method with @After. The JUnit framework automatically invokes any @After methods after each test is run. For example:
<pre>
package junitfaq;

import org.junit.*;
import static org.junit.Assert.*;
import java.io.*;

public class OutputTest {

private File output;

@Before
public void createOutputFile() {
output = new File(...);
}

@After
public void deleteOutputFile() {
output.delete();
}

@Test
public void testSomethingWithFile() {
...
}
}
</pre>
With this test, the methods will execute in the following order:

* createOutputFile()
* testSomethingWithFile()
* deleteOutputFile()

=== To Test a method that doesnot return anything ===
If a method doesn't return a value, it might have some side effect. Actually, if it doesn't return a value AND doesn't have a side effect, it isn't doing anything.
There may be a way to verify that the side effect actually occurred as expected. For example, consider the add() method in the Collection classes. There are ways of verifying that the side effect happened (i.e. the object was added). You can check the size and assert that it is what is expected:

<pre>
public void testCollectionAdd() {
Collection collection = new ArrayList();
assertEquals(0, collection.size());
collection.add("itemA");
assertEquals(1, collection.size());
collection.add("itemB");
assertEquals(2, collection.size());
}
</pre>
=== To test an expected/unexpected exception ===
* Case of expected exception
Add the optional expected attribute to the @Test annotation. The following is an example test that passes when the expected IndexOutOfBoundsException is raised:
<pre>
@Test(expected=IndexOutOfBoundsException.class)
public void testIndexOutOfBoundsException() {
ArrayList emptyList = new ArrayList();
Object o = emptyList.get(0);
}
</pre>
* Case of unexpected exception
Declare the exception in the throws clause of the test method and don't catch the exception within the test method. Uncaught exceptions will cause the test to fail with an error.
The following is an example test that fails when the IndexOutOfBoundsException is raised:
<pre>
@Test
public void testIndexOutOfBoundsExceptionNotRaised()
throws IndexOutOfBoundsException {

ArrayList emptyList = new ArrayList();
Object o = emptyList.get(0);
}
</pre>

=== To Test protected/private methods ===
* Case for protected methods
Place your tests in the same package as the classes under test.
* Case for private methods
Testing private methods may be an indication that those methods should be moved into another class to promote reusability.
=== Conditions to test get() and set() methods ===
Unit tests are intended to alleviate fear that something might break. If you think a get() or set() method could reasonably break, or has in fact contributed to a defect, then by all means write a test.
In short, test until you're confident. What you choose to test is subjective, based on your experiences and confidence level. Remember to be practical and maximize your testing investment.
 

=== To run setUp() and tearDown() code once for all tests ===

You can add a @BeforeClass annotation to a method to be run before all the tests in a class, and a @AfterClass annotation to a method to be run after all the tests in a class. Here's an example:

<pre>
package junitfaq;

import org.junit.*;
import static org.junit.Assert.*;
import java.util.*;

public class SimpleTest {

private Collection collection;

@BeforeClass
public static void oneTimeSetUp() {
// one-time initialization code
}

@AfterClass
public static void oneTimeTearDown() {
// one-time cleanup code
}

@Before
public void setUp() {
collection = new ArrayList();
}

@After
public void tearDown() {
collection.clear();
}

@Test
public void testEmptyCollection() {
assertTrue(collection.isEmpty());
}

@Test
public void testOneItemCollection() {
collection.add("itemA");
assertEquals(1, collection.size());
}
}
</pre>
Given this test, the methods will execute in the following order:

*oneTimeSetUp()
*setUp()
*testEmptyCollection()
*tearDown()
*setUp()
*testOneItemCollection()
*tearDown()
*oneTimeTearDown()
 

==Conclusion==
By following the guidelines given in this articles, one can write a good unit test using junit, which is as important as writing good quality code. 
A good quality unit test will take care of all classes, boundary conditions, domain data and functionality. 
A good test can be creative to explore all possibilities, thinking out of box. 
Finally automating the test using tool like junit which is in the native java language itself helps in saving manual intervention and time/money. 

==References==

* http://articles.techrepublic.com.com/5100-10878_11-1027676.html
* http://msdn.microsoft.com/en-us/library/aa292197%28VS.71%29.asp
* http://junit.sourceforge.net/doc/cookbook/cookbook.htm
* http://junit.sourceforge.net/doc/faq/faq.htm#overview
* http://clarkware.com/articles/JUnitPrimer.html#usage
* http://users.csc.calpoly.edu/~jdalbey/205/Resources/junitQuickStart.html
* http://www.cis.upenn.edu/~matuszek/cit591-2004/Lectures/
* http://en.wikipedia.org/wiki/JUnit
* http://www.laliluna.de/eclipse-junit-testing-tutorial.html
* http://junit.sourceforge.net/doc/faq/faq.htm

-------------------------------------------------------

CSC/ECE 517 Fall 2009/wiki1a 1 JunitTest

2009-09-08T19:01:57Z

Wolverine: /* To run setUp() and tearDown() code once for all tests */

'''Writing Effective JUnit Test Cases''' 
----

''JUnit is a testing framework aimed at making unit testing easy by simplifying the writing of test cases and by providing automated running of tests and test suites.''

The objective of this document is to provide a repository of rules that can be used in-order to write an effective Junit test.
This doc also discusses various sites and suggest which are the best sites to read for an overview of the topic and to understand the different philosophies of test-case design.

==Introduction==

=== Unit Testing Overview ===

The primary goal of unit testing is to take the smallest piece of testable software in the application, isolate it from the remainder of the code, and determine whether it behaves exactly as you expect.

'''Test Case''' 
It describes a scenario that can be exercised through the application. 
Each test case is divided into two parts: input and expected output. 
The input part lists all the test case statements that create variables or assign values to variables. 
The expected output part indicates the expected results; it shows either assertions or the message 'no exception' (when no assertions exist). 

The main issue in constructing a unit test is deciding the scope of test cases. 
If the scope is too narrow, then the tests will be trivial and the objects might pass the tests, but there will be no design of their interactions and interactions of objects are important for object oriented design. 
On the other hand if the scope is too broad, then there is a high chance that not every component of the new code will get tested. 
The programmer is then reduced to testing-by-poking-around, which is not an effective test strategy. 

=== JUnit Overview ===
Non-automated testing is usually like this: 
* An expression is used in a debugger, you can change debug expressions without recompiling, and you can wait to decide what to write until you have seen the running objects. 
* Expressions are tested as statements which print to the standard output stream. 
But its not preferred because: 
* They require human judgment to analyze their results. 
* They are cumbersome, non repeatable - you can only execute one debug expression at a time and a program with too many print statements causes the dreaded "Scroll Blindness". 
On the upper hand, JUnit tests, which uses the automated framework does not require human judgment to interpret, and it is easy to run many of them at the same time.
 
When you need to test something, here is what you do: 
* Annotate a method with @org.junit.Test 
* When you want to check a value, import org.junit.Assert.* statically, call assertTrue() and pass a boolean that is true if the test succeeds 
'''So what exactly is JUnit ?? ''' 
It is a open-source unit testing framework for Java and provides a way to organize test data and perform repeatable test execution. 
In JUnit, one has to write Java code, called a test class, that describes test data, invokes the methods to be tested, and determines test results. 
JUnit was originally written by Erich Gamma and Kent Beck. 
The official JUnit home page is http://junit.org. 
JUnit is Open Source Software, released under IBM's Common Public License Version 0.5 and hosted on SourceForge. 
It is an instance of the xUnit architecture for unit testing frameworks. JUnit features include: 
* Assertions for testing expected results 
* Test fixtures for sharing common test data 
* Test runners for running tests 
'''JUnit mailing lists and forums''' 
[http://groups.yahoo.com/group/junit/ JUnit user list] 
[http://lists.sourceforge.net/lists/listinfo/junit-announce JUnit announcements] 
[http://lists.sourceforge.net/lists/listinfo/junit-devel JUnit developer list] 
'''JUnit official documentation''' 
[http://junit.sourceforge.net/doc/testinfected/testing.htm JUnit Test Infected: Programmers Love Writing Tests] 
[http://junit.sourceforge.net/doc/cookbook/cookbook.htm JUnit Cookbook] 
[http://junit.sourceforge.net/doc/cookstour/cookstour.htm JUnit - A Cook's Tour] 
[http://junit.sourceforge.net/doc/faq/faq.htm JUnit FAQ] 
Although JUnit testing costs some time and money, but unit testing provides some crucial advantages, viz: 
Automation of the testing process 
Reduces difficulties of discovering errors contained in more complex pieces of the application 
Test coverage is often enhanced because attention is given to each unit. 
For example, 
if you have two units and decide it would be more cost effective to glue them together and initially test them as an integrated unit, an error could occur in a variety of places, now: 
* Is the error due to a defect in unit 1? 
* Is the error due to a defect in unit 2? 
* Is the error due to defects in both units? 
* Is the error due to a defect in the interface between the units? 
* Is the error due to a defect in the test? 
Finding the error (or errors) in the integrated module is much more complicated than first isolating the units, testing each, then integrating them and testing the whole. 
 

== Websites to lookout ==
These are some of the best webpages which will help you in getting more description as well as details about Junit.
 Also it will help you understand the test case design philosophy. 
=== For Overview ===
* Junit testing basics: 
http://articles.techrepublic.com.com/5100-10878_11-1027676.html

* Basics of Junit: 
http://junit.sourceforge.net/doc/cookbook/cookbook.htm
http://junit.sourceforge.net/doc/faq/faq.htm#overview

=== For Ideas on test case design ===
* For successful test automation: 
http://www.io.com/~wazmo/papers/seven_steps.html

* Unit testing principles: 
http://www.acm.org/ubiquity/views/t_burns_1.html

* For test suite effectiveness: 
http://java.sys-con.com/node/299945
 

== How to get started ==
=== Step 1: Installing JUnit ===

* Download latest version of JUnit from "http://sourceforge.net/projects/junit/files/". 
* Then install JUnit on your platform of choice: 
Windows 
To install JUnit on Windows, follow these steps: 
* Unzip the junit.zip distribution file to a directory referred to as %JUNIT_HOME%. 
* Add JUnit to the classpath: 
<pre>set CLASSPATH=%JUNIT_HOME%\junit.jar</pre>
'''Unix (bash)''' 
To install JUnit on Unix, follow these steps: 
* Unzip the junit.zip distribution file to a directory referred to as $JUNIT_HOME. 
* Add JUnit to the classpath: 
<pre>export CLASSPATH=$JUNIT_HOME/junit.jar</pre>

=== Step 2: Writing a Test Case ===
To write a test case, follow these steps: 

* Implement a class derived from TestCase, a base class provided by JUnit. 
public class BooksCartTest extends TestCase
* Be sure the test class belongs to the same package as that of the unit you wish to test 
* Override the setUp() method to initialize object(s) under test. 
* Optionally override the tearDown() method to release object(s) under test. 
* Define one or more public testXXX() methods that exercise the object(s) under test and assert expected results. 
The following is an example test case: 
<pre>
import junit.framework.TestCase;

public class BooksCartTest extends TestCase {

private BooksCart cart1;
private BooksCart cart2;

/**
* Sets up the test fixture.
*
* Called before every test case method.
*/
protected void setUp() {

cart1 = new BooksCart(6,8);
cart2 = new BooksCart(7,10);
}

/**
* Tears down the test fixture.
*
* Called after every test case method.
*/
protected void tearDown() {
// release objects under test here, if necessary
}

/**
* Tests emptying the cart.
*/
public void testEmpty() {

cart1.empty();
cart2.empty();
assertEquals(cart1, new BooksCart(3, 9));
assertTrue(!cart2.equals(cart1));
}
}
</pre>
Methods used in JUnit: 
* An assert method is a JUnit method that performs a test, and throws an AssertionFailedError if the test fails 
* static void assertTrue(boolean test) 
static void assertTrue(String message, boolean test)
- Throws an AssertionFailedError if the test fails 
- The optional message is included in the Error 
* static void assertFalse(boolean test) 
static void assertFalse(String message, boolean test)
- Throws an AssertionFailedError if the test fails 

=== Step 3: Writing a Test Suite ===
Next, we'll write a test suite that includes several test cases. The test suite will allow us to run all of its test cases in one fell swoop. 
'''To write a test suite, follow these steps:''' 
* Write a Java class that defines a static suite() factory method that creates a TestSuite containing all the tests. 
* Optionally define a main() method that runs the TestSuite in batch mode. 

The following is an example test suite: 
<pre>
import junit.framework.Test;
import junit.framework.TestSuite;

public class BooksCartTestSuite {

public static Test suite() {

TestSuite suite = new TestSuite();

//
// The BooksCartTest we created above.
//
suite.addTestSuite(BooksCartTest.class);

//
// Another example test suite of tests.
//
suite.addTest(CreditCardTestSuite.suite());

//
// Add more tests here
//

return suite;
}

/**
* Runs the test suite using the textual runner.
*/
public static void main(String[] args) {
junit.textui.TestRunner.run(suite());
}
}
</pre>

=== Step 4: Running the Test ===
Now that we've written a test suite containing a collection of test cases and other test suites, we can run either the test suite or any of its test cases individually. Running a TestSuite will automatically run all of its subordinate TestCase instances and TestSuite instances. Running a TestCase will automatically invoke all of its public testXXX() methods.
JUnit provides both a textual and a graphical user interface. Both user interfaces indicate how many tests were run, any errors or failures, and a simple completion status. The simplicity of the user interfaces is the key to running tests quickly. You should be able to run your tests and know the test status with a glance, much like you do with a compiler.

To run our test case using the textual user interface, use: 
<pre>java junit.textui.TestRunner BooksCartTest </pre>
The textual user interface displays "OK" if all the tests passed and failure messages if any of the tests failed. 
To run the test case using the graphical user interface, use: 
<pre>java junit.swingui.TestRunner BooksCartTest </pre> 
The graphical user interface displays a Swing window with a green progress bar if all the tests passed or a red progress bar if any of the tests failed. 
The BooksCartTest Suite can be run similarly: 
<pre>java junit.swingui.TestRunner BooksCartTestSuite</pre>

== Rules for designing effective JUnit Test cases ==
* Identify and assemble a list of all the actions that your program should be able to perform. use cases,nonfunctional requirements specifications, test case specifications, user interface design documents, mockups, user profiles, and various additional artifacts.
* Identify the code's entry points - central pieces of code that exercise the functionality that the code as a whole is designed to undertake.
* Pair entry points with the use cases that they implement.
* Create test cases by applying the initialize/work/check procedure.
** Initialize: Create the environment that the test expects to run in. The initialization code can either be in the beginning of the test or in the setUp() method.
** Work: Call the code that is being tested, capturing any interesting output and recording any interesting statistics.
** Check: Use assert statements to ensure that the code worked as expected.
* Develop runtime event diagrams and use them to facilitate testing.
* Follow KISS rule:It's a bad idea to keep the input source name and expression in the test case. Some items (server names, usernames and passwords, etc.) should not live in the test files, which should be configurable for the specific deployment. Rather, design the test cases to facilitate separation of test drivers and test data, test driver reuse over a larger set of data, and test data reuse over a larger set of test drivers. On the other hand, don't over-architect a simple test case implementation. Typically, the test case specification already defines most of the system states and allows parameter descriptions for a scenario, so there's no point in making everything parameterizable in the test implementation.

==Rules for coding effective JUnit Tests==

=== Using Test Fixture for a common set of objects ===
Using a test fixture avoids duplicating the code necessary to initialize (and cleanup) the common objects.
Tests can use the objects (variables) in a test fixture, with each test invoking different methods on objects in the fixture and asserting different expected results. Each test runs in its own test fixture to isolate tests from the changes made by other tests. That is, tests don't share the state of objects in the test fixture. Because the tests are isolated, they can be run in any order.
To create a test fixture, declare instance variables for the common objects. Initialize these objects in a public void method annotated with @Before. The JUnit framework automatically invokes any @Before methods before each test is run.
The following example shows a test fixture with a common Collection object.
<pre>
package junitfaq;

import org.junit.*;
import static org.junit.Assert.*;
import java.util.*;

public class SimpleTest {

private Collection<Object> collection;

@Before
public void setUp() {
collection = new ArrayList<Object>();
}

@Test
public void testEmptyCollection() {
assertTrue(collection.isEmpty());
}

@Test
public void testOneItemCollection() {
collection.add("itemA");
assertEquals(1, collection.size());
}
}
</pre>
Given this test, the methods might execute in the following order: 
setUp() 
testEmptyCollection() 
setUp() 
testOneItemCollection() 
The ordering of test-method invocations is not guaranteed, so testOneItemCollection() might be executed before testEmptyCollection(). But it doesn't matter, because each method gets its own instance of the collection.
Although JUnit provides a new instance of the fixture objects for each test method, if you allocate any external resources in a @Before method, you should release them after the test runs by annotating a method with @After. The JUnit framework automatically invokes any @After methods after each test is run. For example:
<pre>
package junitfaq;

import org.junit.*;
import static org.junit.Assert.*;
import java.io.*;

public class OutputTest {

private File output;

@Before
public void createOutputFile() {
output = new File(...);
}

@After
public void deleteOutputFile() {
output.delete();
}

@Test
public void testSomethingWithFile() {
...
}
}
</pre>
With this test, the methods will execute in the following order:

* createOutputFile()
* testSomethingWithFile()
* deleteOutputFile()

=== To Test a method that doesnot return anything ===
If a method doesn't return a value, it might have some side effect. Actually, if it doesn't return a value AND doesn't have a side effect, it isn't doing anything.
There may be a way to verify that the side effect actually occurred as expected. For example, consider the add() method in the Collection classes. There are ways of verifying that the side effect happened (i.e. the object was added). You can check the size and assert that it is what is expected:

<pre>
public void testCollectionAdd() {
Collection collection = new ArrayList();
assertEquals(0, collection.size());
collection.add("itemA");
assertEquals(1, collection.size());
collection.add("itemB");
assertEquals(2, collection.size());
}
</pre>
=== To test an expected/unexpected exception ===
* Case of expected exception
Add the optional expected attribute to the @Test annotation. The following is an example test that passes when the expected IndexOutOfBoundsException is raised:
<pre>
@Test(expected=IndexOutOfBoundsException.class)
public void testIndexOutOfBoundsException() {
ArrayList emptyList = new ArrayList();
Object o = emptyList.get(0);
}
</pre>
* Case of unexpected exception
Declare the exception in the throws clause of the test method and don't catch the exception within the test method. Uncaught exceptions will cause the test to fail with an error.
The following is an example test that fails when the IndexOutOfBoundsException is raised:
<pre>
@Test
public void testIndexOutOfBoundsExceptionNotRaised()
throws IndexOutOfBoundsException {

ArrayList emptyList = new ArrayList();
Object o = emptyList.get(0);
}
</pre>

=== To Test protected/private methods ===
* Case for protected methods
Place your tests in the same package as the classes under test.
* Case for private methods
Testing private methods may be an indication that those methods should be moved into another class to promote reusability.
=== Conditions to test get() and set() methods ===
Unit tests are intended to alleviate fear that something might break. If you think a get() or set() method could reasonably break, or has in fact contributed to a defect, then by all means write a test.
In short, test until you're confident. What you choose to test is subjective, based on your experiences and confidence level. Remember to be practical and maximize your testing investment.

=== To run setUp() and tearDown() code once for all tests ===

You can add a @BeforeClass annotation to a method to be run before all the tests in a class, and a @AfterClass annotation to a method to be run after all the tests in a class. Here's an example:

<pre>
package junitfaq;

import org.junit.*;
import static org.junit.Assert.*;
import java.util.*;

public class SimpleTest {

private Collection collection;

@BeforeClass
public static void oneTimeSetUp() {
// one-time initialization code
}

@AfterClass
public static void oneTimeTearDown() {
// one-time cleanup code
}

@Before
public void setUp() {
collection = new ArrayList();
}

@After
public void tearDown() {
collection.clear();
}

@Test
public void testEmptyCollection() {
assertTrue(collection.isEmpty());
}

@Test
public void testOneItemCollection() {
collection.add("itemA");
assertEquals(1, collection.size());
}
}
</pre>
Given this test, the methods will execute in the following order:

*oneTimeSetUp()
*setUp()
*testEmptyCollection()
*tearDown()
*setUp()
*testOneItemCollection()
*tearDown()
*oneTimeTearDown()
 

==Conclusion==
By following the guidelines given in this articles, one can write a good unit test using junit, which is as important as writing good quality code. 
A good quality unit test will take care of all classes, boundary conditions, domain data and functionality. 
A good test can be creative to explore all possibilities, thinking out of box. 
Finally automating the test using tool like junit which is in the native java language itself helps in saving manual intervention and time/money. 

==References==

* http://articles.techrepublic.com.com/5100-10878_11-1027676.html
* http://msdn.microsoft.com/en-us/library/aa292197%28VS.71%29.asp
* http://junit.sourceforge.net/doc/cookbook/cookbook.htm
* http://junit.sourceforge.net/doc/faq/faq.htm#overview
* http://clarkware.com/articles/JUnitPrimer.html#usage
* http://users.csc.calpoly.edu/~jdalbey/205/Resources/junitQuickStart.html
* http://www.cis.upenn.edu/~matuszek/cit591-2004/Lectures/
* http://en.wikipedia.org/wiki/JUnit
* http://www.laliluna.de/eclipse-junit-testing-tutorial.html
* http://junit.sourceforge.net/doc/faq/faq.htm

-------------------------------------------------------

CSC/ECE 517 Fall 2009/wiki1a 1 JunitTest

2009-09-08T19:01:42Z

Wolverine: /* Conclusion */

'''Writing Effective JUnit Test Cases''' 
----

''JUnit is a testing framework aimed at making unit testing easy by simplifying the writing of test cases and by providing automated running of tests and test suites.''

The objective of this document is to provide a repository of rules that can be used in-order to write an effective Junit test.
This doc also discusses various sites and suggest which are the best sites to read for an overview of the topic and to understand the different philosophies of test-case design.

==Introduction==

=== Unit Testing Overview ===

The primary goal of unit testing is to take the smallest piece of testable software in the application, isolate it from the remainder of the code, and determine whether it behaves exactly as you expect.

'''Test Case''' 
It describes a scenario that can be exercised through the application. 
Each test case is divided into two parts: input and expected output. 
The input part lists all the test case statements that create variables or assign values to variables. 
The expected output part indicates the expected results; it shows either assertions or the message 'no exception' (when no assertions exist). 

The main issue in constructing a unit test is deciding the scope of test cases. 
If the scope is too narrow, then the tests will be trivial and the objects might pass the tests, but there will be no design of their interactions and interactions of objects are important for object oriented design. 
On the other hand if the scope is too broad, then there is a high chance that not every component of the new code will get tested. 
The programmer is then reduced to testing-by-poking-around, which is not an effective test strategy. 

=== JUnit Overview ===
Non-automated testing is usually like this: 
* An expression is used in a debugger, you can change debug expressions without recompiling, and you can wait to decide what to write until you have seen the running objects. 
* Expressions are tested as statements which print to the standard output stream. 
But its not preferred because: 
* They require human judgment to analyze their results. 
* They are cumbersome, non repeatable - you can only execute one debug expression at a time and a program with too many print statements causes the dreaded "Scroll Blindness". 
On the upper hand, JUnit tests, which uses the automated framework does not require human judgment to interpret, and it is easy to run many of them at the same time.
 
When you need to test something, here is what you do: 
* Annotate a method with @org.junit.Test 
* When you want to check a value, import org.junit.Assert.* statically, call assertTrue() and pass a boolean that is true if the test succeeds 
'''So what exactly is JUnit ?? ''' 
It is a open-source unit testing framework for Java and provides a way to organize test data and perform repeatable test execution. 
In JUnit, one has to write Java code, called a test class, that describes test data, invokes the methods to be tested, and determines test results. 
JUnit was originally written by Erich Gamma and Kent Beck. 
The official JUnit home page is http://junit.org. 
JUnit is Open Source Software, released under IBM's Common Public License Version 0.5 and hosted on SourceForge. 
It is an instance of the xUnit architecture for unit testing frameworks. JUnit features include: 
* Assertions for testing expected results 
* Test fixtures for sharing common test data 
* Test runners for running tests 
'''JUnit mailing lists and forums''' 
[http://groups.yahoo.com/group/junit/ JUnit user list] 
[http://lists.sourceforge.net/lists/listinfo/junit-announce JUnit announcements] 
[http://lists.sourceforge.net/lists/listinfo/junit-devel JUnit developer list] 
'''JUnit official documentation''' 
[http://junit.sourceforge.net/doc/testinfected/testing.htm JUnit Test Infected: Programmers Love Writing Tests] 
[http://junit.sourceforge.net/doc/cookbook/cookbook.htm JUnit Cookbook] 
[http://junit.sourceforge.net/doc/cookstour/cookstour.htm JUnit - A Cook's Tour] 
[http://junit.sourceforge.net/doc/faq/faq.htm JUnit FAQ] 
Although JUnit testing costs some time and money, but unit testing provides some crucial advantages, viz: 
Automation of the testing process 
Reduces difficulties of discovering errors contained in more complex pieces of the application 
Test coverage is often enhanced because attention is given to each unit. 
For example, 
if you have two units and decide it would be more cost effective to glue them together and initially test them as an integrated unit, an error could occur in a variety of places, now: 
* Is the error due to a defect in unit 1? 
* Is the error due to a defect in unit 2? 
* Is the error due to defects in both units? 
* Is the error due to a defect in the interface between the units? 
* Is the error due to a defect in the test? 
Finding the error (or errors) in the integrated module is much more complicated than first isolating the units, testing each, then integrating them and testing the whole. 
 

== Websites to lookout ==
These are some of the best webpages which will help you in getting more description as well as details about Junit.
 Also it will help you understand the test case design philosophy. 
=== For Overview ===
* Junit testing basics: 
http://articles.techrepublic.com.com/5100-10878_11-1027676.html

* Basics of Junit: 
http://junit.sourceforge.net/doc/cookbook/cookbook.htm
http://junit.sourceforge.net/doc/faq/faq.htm#overview

=== For Ideas on test case design ===
* For successful test automation: 
http://www.io.com/~wazmo/papers/seven_steps.html

* Unit testing principles: 
http://www.acm.org/ubiquity/views/t_burns_1.html

* For test suite effectiveness: 
http://java.sys-con.com/node/299945
 

== How to get started ==
=== Step 1: Installing JUnit ===

* Download latest version of JUnit from "http://sourceforge.net/projects/junit/files/". 
* Then install JUnit on your platform of choice: 
Windows 
To install JUnit on Windows, follow these steps: 
* Unzip the junit.zip distribution file to a directory referred to as %JUNIT_HOME%. 
* Add JUnit to the classpath: 
<pre>set CLASSPATH=%JUNIT_HOME%\junit.jar</pre>
'''Unix (bash)''' 
To install JUnit on Unix, follow these steps: 
* Unzip the junit.zip distribution file to a directory referred to as $JUNIT_HOME. 
* Add JUnit to the classpath: 
<pre>export CLASSPATH=$JUNIT_HOME/junit.jar</pre>

=== Step 2: Writing a Test Case ===
To write a test case, follow these steps: 

* Implement a class derived from TestCase, a base class provided by JUnit. 
public class BooksCartTest extends TestCase
* Be sure the test class belongs to the same package as that of the unit you wish to test 
* Override the setUp() method to initialize object(s) under test. 
* Optionally override the tearDown() method to release object(s) under test. 
* Define one or more public testXXX() methods that exercise the object(s) under test and assert expected results. 
The following is an example test case: 
<pre>
import junit.framework.TestCase;

public class BooksCartTest extends TestCase {

private BooksCart cart1;
private BooksCart cart2;

/**
* Sets up the test fixture.
*
* Called before every test case method.
*/
protected void setUp() {

cart1 = new BooksCart(6,8);
cart2 = new BooksCart(7,10);
}

/**
* Tears down the test fixture.
*
* Called after every test case method.
*/
protected void tearDown() {
// release objects under test here, if necessary
}

/**
* Tests emptying the cart.
*/
public void testEmpty() {

cart1.empty();
cart2.empty();
assertEquals(cart1, new BooksCart(3, 9));
assertTrue(!cart2.equals(cart1));
}
}
</pre>
Methods used in JUnit: 
* An assert method is a JUnit method that performs a test, and throws an AssertionFailedError if the test fails 
* static void assertTrue(boolean test) 
static void assertTrue(String message, boolean test)
- Throws an AssertionFailedError if the test fails 
- The optional message is included in the Error 
* static void assertFalse(boolean test) 
static void assertFalse(String message, boolean test)
- Throws an AssertionFailedError if the test fails 

=== Step 3: Writing a Test Suite ===
Next, we'll write a test suite that includes several test cases. The test suite will allow us to run all of its test cases in one fell swoop. 
'''To write a test suite, follow these steps:''' 
* Write a Java class that defines a static suite() factory method that creates a TestSuite containing all the tests. 
* Optionally define a main() method that runs the TestSuite in batch mode. 

The following is an example test suite: 
<pre>
import junit.framework.Test;
import junit.framework.TestSuite;

public class BooksCartTestSuite {

public static Test suite() {

TestSuite suite = new TestSuite();

//
// The BooksCartTest we created above.
//
suite.addTestSuite(BooksCartTest.class);

//
// Another example test suite of tests.
//
suite.addTest(CreditCardTestSuite.suite());

//
// Add more tests here
//

return suite;
}

/**
* Runs the test suite using the textual runner.
*/
public static void main(String[] args) {
junit.textui.TestRunner.run(suite());
}
}
</pre>

=== Step 4: Running the Test ===
Now that we've written a test suite containing a collection of test cases and other test suites, we can run either the test suite or any of its test cases individually. Running a TestSuite will automatically run all of its subordinate TestCase instances and TestSuite instances. Running a TestCase will automatically invoke all of its public testXXX() methods.
JUnit provides both a textual and a graphical user interface. Both user interfaces indicate how many tests were run, any errors or failures, and a simple completion status. The simplicity of the user interfaces is the key to running tests quickly. You should be able to run your tests and know the test status with a glance, much like you do with a compiler.

To run our test case using the textual user interface, use: 
<pre>java junit.textui.TestRunner BooksCartTest </pre>
The textual user interface displays "OK" if all the tests passed and failure messages if any of the tests failed. 
To run the test case using the graphical user interface, use: 
<pre>java junit.swingui.TestRunner BooksCartTest </pre> 
The graphical user interface displays a Swing window with a green progress bar if all the tests passed or a red progress bar if any of the tests failed. 
The BooksCartTest Suite can be run similarly: 
<pre>java junit.swingui.TestRunner BooksCartTestSuite</pre>

== Rules for designing effective JUnit Test cases ==
* Identify and assemble a list of all the actions that your program should be able to perform. use cases,nonfunctional requirements specifications, test case specifications, user interface design documents, mockups, user profiles, and various additional artifacts.
* Identify the code's entry points - central pieces of code that exercise the functionality that the code as a whole is designed to undertake.
* Pair entry points with the use cases that they implement.
* Create test cases by applying the initialize/work/check procedure.
** Initialize: Create the environment that the test expects to run in. The initialization code can either be in the beginning of the test or in the setUp() method.
** Work: Call the code that is being tested, capturing any interesting output and recording any interesting statistics.
** Check: Use assert statements to ensure that the code worked as expected.
* Develop runtime event diagrams and use them to facilitate testing.
* Follow KISS rule:It's a bad idea to keep the input source name and expression in the test case. Some items (server names, usernames and passwords, etc.) should not live in the test files, which should be configurable for the specific deployment. Rather, design the test cases to facilitate separation of test drivers and test data, test driver reuse over a larger set of data, and test data reuse over a larger set of test drivers. On the other hand, don't over-architect a simple test case implementation. Typically, the test case specification already defines most of the system states and allows parameter descriptions for a scenario, so there's no point in making everything parameterizable in the test implementation.

==Rules for coding effective JUnit Tests==

=== Using Test Fixture for a common set of objects ===
Using a test fixture avoids duplicating the code necessary to initialize (and cleanup) the common objects.
Tests can use the objects (variables) in a test fixture, with each test invoking different methods on objects in the fixture and asserting different expected results. Each test runs in its own test fixture to isolate tests from the changes made by other tests. That is, tests don't share the state of objects in the test fixture. Because the tests are isolated, they can be run in any order.
To create a test fixture, declare instance variables for the common objects. Initialize these objects in a public void method annotated with @Before. The JUnit framework automatically invokes any @Before methods before each test is run.
The following example shows a test fixture with a common Collection object.
<pre>
package junitfaq;

import org.junit.*;
import static org.junit.Assert.*;
import java.util.*;

public class SimpleTest {

private Collection<Object> collection;

@Before
public void setUp() {
collection = new ArrayList<Object>();
}

@Test
public void testEmptyCollection() {
assertTrue(collection.isEmpty());
}

@Test
public void testOneItemCollection() {
collection.add("itemA");
assertEquals(1, collection.size());
}
}
</pre>
Given this test, the methods might execute in the following order: 
setUp() 
testEmptyCollection() 
setUp() 
testOneItemCollection() 
The ordering of test-method invocations is not guaranteed, so testOneItemCollection() might be executed before testEmptyCollection(). But it doesn't matter, because each method gets its own instance of the collection.
Although JUnit provides a new instance of the fixture objects for each test method, if you allocate any external resources in a @Before method, you should release them after the test runs by annotating a method with @After. The JUnit framework automatically invokes any @After methods after each test is run. For example:
<pre>
package junitfaq;

import org.junit.*;
import static org.junit.Assert.*;
import java.io.*;

public class OutputTest {

private File output;

@Before
public void createOutputFile() {
output = new File(...);
}

@After
public void deleteOutputFile() {
output.delete();
}

@Test
public void testSomethingWithFile() {
...
}
}
</pre>
With this test, the methods will execute in the following order:

* createOutputFile()
* testSomethingWithFile()
* deleteOutputFile()

=== To Test a method that doesnot return anything ===
If a method doesn't return a value, it might have some side effect. Actually, if it doesn't return a value AND doesn't have a side effect, it isn't doing anything.
There may be a way to verify that the side effect actually occurred as expected. For example, consider the add() method in the Collection classes. There are ways of verifying that the side effect happened (i.e. the object was added). You can check the size and assert that it is what is expected:

<pre>
public void testCollectionAdd() {
Collection collection = new ArrayList();
assertEquals(0, collection.size());
collection.add("itemA");
assertEquals(1, collection.size());
collection.add("itemB");
assertEquals(2, collection.size());
}
</pre>
=== To test an expected/unexpected exception ===
* Case of expected exception
Add the optional expected attribute to the @Test annotation. The following is an example test that passes when the expected IndexOutOfBoundsException is raised:
<pre>
@Test(expected=IndexOutOfBoundsException.class)
public void testIndexOutOfBoundsException() {
ArrayList emptyList = new ArrayList();
Object o = emptyList.get(0);
}
</pre>
* Case of unexpected exception
Declare the exception in the throws clause of the test method and don't catch the exception within the test method. Uncaught exceptions will cause the test to fail with an error.
The following is an example test that fails when the IndexOutOfBoundsException is raised:
<pre>
@Test
public void testIndexOutOfBoundsExceptionNotRaised()
throws IndexOutOfBoundsException {

ArrayList emptyList = new ArrayList();
Object o = emptyList.get(0);
}
</pre>

=== To Test protected/private methods ===
* Case for protected methods
Place your tests in the same package as the classes under test.
* Case for private methods
Testing private methods may be an indication that those methods should be moved into another class to promote reusability.
=== Conditions to test get() and set() methods ===
Unit tests are intended to alleviate fear that something might break. If you think a get() or set() method could reasonably break, or has in fact contributed to a defect, then by all means write a test.
In short, test until you're confident. What you choose to test is subjective, based on your experiences and confidence level. Remember to be practical and maximize your testing investment.

=== To run setUp() and tearDown() code once for all tests ===

You can add a @BeforeClass annotation to a method to be run before all the tests in a class, and a @AfterClass annotation to a method to be run after all the tests in a class. Here's an example:

<pre>
package junitfaq;

import org.junit.*;
import static org.junit.Assert.*;
import java.util.*;

public class SimpleTest {

private Collection collection;

@BeforeClass
public static void oneTimeSetUp() {
// one-time initialization code
}

@AfterClass
public static void oneTimeTearDown() {
// one-time cleanup code
}

@Before
public void setUp() {
collection = new ArrayList();
}

@After
public void tearDown() {
collection.clear();
}

@Test
public void testEmptyCollection() {
assertTrue(collection.isEmpty());
}

@Test
public void testOneItemCollection() {
collection.add("itemA");
assertEquals(1, collection.size());
}
}
</pre>
Given this test, the methods will execute in the following order:

*oneTimeSetUp()
*setUp()
*testEmptyCollection()
*tearDown()
*setUp()
*testOneItemCollection()
*tearDown()
*oneTimeTearDown()

==Conclusion==
By following the guidelines given in this articles, one can write a good unit test using junit, which is as important as writing good quality code. 
A good quality unit test will take care of all classes, boundary conditions, domain data and functionality. 
A good test can be creative to explore all possibilities, thinking out of box. 
Finally automating the test using tool like junit which is in the native java language itself helps in saving manual intervention and time/money. 

==References==

* http://articles.techrepublic.com.com/5100-10878_11-1027676.html
* http://msdn.microsoft.com/en-us/library/aa292197%28VS.71%29.asp
* http://junit.sourceforge.net/doc/cookbook/cookbook.htm
* http://junit.sourceforge.net/doc/faq/faq.htm#overview
* http://clarkware.com/articles/JUnitPrimer.html#usage
* http://users.csc.calpoly.edu/~jdalbey/205/Resources/junitQuickStart.html
* http://www.cis.upenn.edu/~matuszek/cit591-2004/Lectures/
* http://en.wikipedia.org/wiki/JUnit
* http://www.laliluna.de/eclipse-junit-testing-tutorial.html
* http://junit.sourceforge.net/doc/faq/faq.htm

-------------------------------------------------------

CSC/ECE 517 Fall 2009/wiki1a 1 JunitTest

2009-09-08T19:00:51Z

Wolverine: /* Conclusion */

'''Writing Effective JUnit Test Cases''' 
----

''JUnit is a testing framework aimed at making unit testing easy by simplifying the writing of test cases and by providing automated running of tests and test suites.''

The objective of this document is to provide a repository of rules that can be used in-order to write an effective Junit test.
This doc also discusses various sites and suggest which are the best sites to read for an overview of the topic and to understand the different philosophies of test-case design.

==Introduction==

=== Unit Testing Overview ===

The primary goal of unit testing is to take the smallest piece of testable software in the application, isolate it from the remainder of the code, and determine whether it behaves exactly as you expect.

'''Test Case''' 
It describes a scenario that can be exercised through the application. 
Each test case is divided into two parts: input and expected output. 
The input part lists all the test case statements that create variables or assign values to variables. 
The expected output part indicates the expected results; it shows either assertions or the message 'no exception' (when no assertions exist). 

The main issue in constructing a unit test is deciding the scope of test cases. 
If the scope is too narrow, then the tests will be trivial and the objects might pass the tests, but there will be no design of their interactions and interactions of objects are important for object oriented design. 
On the other hand if the scope is too broad, then there is a high chance that not every component of the new code will get tested. 
The programmer is then reduced to testing-by-poking-around, which is not an effective test strategy. 

=== JUnit Overview ===
Non-automated testing is usually like this: 
* An expression is used in a debugger, you can change debug expressions without recompiling, and you can wait to decide what to write until you have seen the running objects. 
* Expressions are tested as statements which print to the standard output stream. 
But its not preferred because: 
* They require human judgment to analyze their results. 
* They are cumbersome, non repeatable - you can only execute one debug expression at a time and a program with too many print statements causes the dreaded "Scroll Blindness". 
On the upper hand, JUnit tests, which uses the automated framework does not require human judgment to interpret, and it is easy to run many of them at the same time.
 
When you need to test something, here is what you do: 
* Annotate a method with @org.junit.Test 
* When you want to check a value, import org.junit.Assert.* statically, call assertTrue() and pass a boolean that is true if the test succeeds 
'''So what exactly is JUnit ?? ''' 
It is a open-source unit testing framework for Java and provides a way to organize test data and perform repeatable test execution. 
In JUnit, one has to write Java code, called a test class, that describes test data, invokes the methods to be tested, and determines test results. 
JUnit was originally written by Erich Gamma and Kent Beck. 
The official JUnit home page is http://junit.org. 
JUnit is Open Source Software, released under IBM's Common Public License Version 0.5 and hosted on SourceForge. 
It is an instance of the xUnit architecture for unit testing frameworks. JUnit features include: 
* Assertions for testing expected results 
* Test fixtures for sharing common test data 
* Test runners for running tests 
'''JUnit mailing lists and forums''' 
[http://groups.yahoo.com/group/junit/ JUnit user list] 
[http://lists.sourceforge.net/lists/listinfo/junit-announce JUnit announcements] 
[http://lists.sourceforge.net/lists/listinfo/junit-devel JUnit developer list] 
'''JUnit official documentation''' 
[http://junit.sourceforge.net/doc/testinfected/testing.htm JUnit Test Infected: Programmers Love Writing Tests] 
[http://junit.sourceforge.net/doc/cookbook/cookbook.htm JUnit Cookbook] 
[http://junit.sourceforge.net/doc/cookstour/cookstour.htm JUnit - A Cook's Tour] 
[http://junit.sourceforge.net/doc/faq/faq.htm JUnit FAQ] 
Although JUnit testing costs some time and money, but unit testing provides some crucial advantages, viz: 
Automation of the testing process 
Reduces difficulties of discovering errors contained in more complex pieces of the application 
Test coverage is often enhanced because attention is given to each unit. 
For example, 
if you have two units and decide it would be more cost effective to glue them together and initially test them as an integrated unit, an error could occur in a variety of places, now: 
* Is the error due to a defect in unit 1? 
* Is the error due to a defect in unit 2? 
* Is the error due to defects in both units? 
* Is the error due to a defect in the interface between the units? 
* Is the error due to a defect in the test? 
Finding the error (or errors) in the integrated module is much more complicated than first isolating the units, testing each, then integrating them and testing the whole. 
 

== Websites to lookout ==
These are some of the best webpages which will help you in getting more description as well as details about Junit.
 Also it will help you understand the test case design philosophy. 
=== For Overview ===
* Junit testing basics: 
http://articles.techrepublic.com.com/5100-10878_11-1027676.html

* Basics of Junit: 
http://junit.sourceforge.net/doc/cookbook/cookbook.htm
http://junit.sourceforge.net/doc/faq/faq.htm#overview

=== For Ideas on test case design ===
* For successful test automation: 
http://www.io.com/~wazmo/papers/seven_steps.html

* Unit testing principles: 
http://www.acm.org/ubiquity/views/t_burns_1.html

* For test suite effectiveness: 
http://java.sys-con.com/node/299945
 

== How to get started ==
=== Step 1: Installing JUnit ===

* Download latest version of JUnit from "http://sourceforge.net/projects/junit/files/". 
* Then install JUnit on your platform of choice: 
Windows 
To install JUnit on Windows, follow these steps: 
* Unzip the junit.zip distribution file to a directory referred to as %JUNIT_HOME%. 
* Add JUnit to the classpath: 
<pre>set CLASSPATH=%JUNIT_HOME%\junit.jar</pre>
'''Unix (bash)''' 
To install JUnit on Unix, follow these steps: 
* Unzip the junit.zip distribution file to a directory referred to as $JUNIT_HOME. 
* Add JUnit to the classpath: 
<pre>export CLASSPATH=$JUNIT_HOME/junit.jar</pre>

=== Step 2: Writing a Test Case ===
To write a test case, follow these steps: 

* Implement a class derived from TestCase, a base class provided by JUnit. 
public class BooksCartTest extends TestCase
* Be sure the test class belongs to the same package as that of the unit you wish to test 
* Override the setUp() method to initialize object(s) under test. 
* Optionally override the tearDown() method to release object(s) under test. 
* Define one or more public testXXX() methods that exercise the object(s) under test and assert expected results. 
The following is an example test case: 
<pre>
import junit.framework.TestCase;

public class BooksCartTest extends TestCase {

private BooksCart cart1;
private BooksCart cart2;

/**
* Sets up the test fixture.
*
* Called before every test case method.
*/
protected void setUp() {

cart1 = new BooksCart(6,8);
cart2 = new BooksCart(7,10);
}

/**
* Tears down the test fixture.
*
* Called after every test case method.
*/
protected void tearDown() {
// release objects under test here, if necessary
}

/**
* Tests emptying the cart.
*/
public void testEmpty() {

cart1.empty();
cart2.empty();
assertEquals(cart1, new BooksCart(3, 9));
assertTrue(!cart2.equals(cart1));
}
}
</pre>
Methods used in JUnit: 
* An assert method is a JUnit method that performs a test, and throws an AssertionFailedError if the test fails 
* static void assertTrue(boolean test) 
static void assertTrue(String message, boolean test)
- Throws an AssertionFailedError if the test fails 
- The optional message is included in the Error 
* static void assertFalse(boolean test) 
static void assertFalse(String message, boolean test)
- Throws an AssertionFailedError if the test fails 

=== Step 3: Writing a Test Suite ===
Next, we'll write a test suite that includes several test cases. The test suite will allow us to run all of its test cases in one fell swoop. 
'''To write a test suite, follow these steps:''' 
* Write a Java class that defines a static suite() factory method that creates a TestSuite containing all the tests. 
* Optionally define a main() method that runs the TestSuite in batch mode. 

The following is an example test suite: 
<pre>
import junit.framework.Test;
import junit.framework.TestSuite;

public class BooksCartTestSuite {

public static Test suite() {

TestSuite suite = new TestSuite();

//
// The BooksCartTest we created above.
//
suite.addTestSuite(BooksCartTest.class);

//
// Another example test suite of tests.
//
suite.addTest(CreditCardTestSuite.suite());

//
// Add more tests here
//

return suite;
}

/**
* Runs the test suite using the textual runner.
*/
public static void main(String[] args) {
junit.textui.TestRunner.run(suite());
}
}
</pre>

=== Step 4: Running the Test ===
Now that we've written a test suite containing a collection of test cases and other test suites, we can run either the test suite or any of its test cases individually. Running a TestSuite will automatically run all of its subordinate TestCase instances and TestSuite instances. Running a TestCase will automatically invoke all of its public testXXX() methods.
JUnit provides both a textual and a graphical user interface. Both user interfaces indicate how many tests were run, any errors or failures, and a simple completion status. The simplicity of the user interfaces is the key to running tests quickly. You should be able to run your tests and know the test status with a glance, much like you do with a compiler.

To run our test case using the textual user interface, use: 
<pre>java junit.textui.TestRunner BooksCartTest </pre>
The textual user interface displays "OK" if all the tests passed and failure messages if any of the tests failed. 
To run the test case using the graphical user interface, use: 
<pre>java junit.swingui.TestRunner BooksCartTest </pre> 
The graphical user interface displays a Swing window with a green progress bar if all the tests passed or a red progress bar if any of the tests failed. 
The BooksCartTest Suite can be run similarly: 
<pre>java junit.swingui.TestRunner BooksCartTestSuite</pre>

== Rules for designing effective JUnit Test cases ==
* Identify and assemble a list of all the actions that your program should be able to perform. use cases,nonfunctional requirements specifications, test case specifications, user interface design documents, mockups, user profiles, and various additional artifacts.
* Identify the code's entry points - central pieces of code that exercise the functionality that the code as a whole is designed to undertake.
* Pair entry points with the use cases that they implement.
* Create test cases by applying the initialize/work/check procedure.
** Initialize: Create the environment that the test expects to run in. The initialization code can either be in the beginning of the test or in the setUp() method.
** Work: Call the code that is being tested, capturing any interesting output and recording any interesting statistics.
** Check: Use assert statements to ensure that the code worked as expected.
* Develop runtime event diagrams and use them to facilitate testing.
* Follow KISS rule:It's a bad idea to keep the input source name and expression in the test case. Some items (server names, usernames and passwords, etc.) should not live in the test files, which should be configurable for the specific deployment. Rather, design the test cases to facilitate separation of test drivers and test data, test driver reuse over a larger set of data, and test data reuse over a larger set of test drivers. On the other hand, don't over-architect a simple test case implementation. Typically, the test case specification already defines most of the system states and allows parameter descriptions for a scenario, so there's no point in making everything parameterizable in the test implementation.

==Rules for coding effective JUnit Tests==

=== Using Test Fixture for a common set of objects ===
Using a test fixture avoids duplicating the code necessary to initialize (and cleanup) the common objects.
Tests can use the objects (variables) in a test fixture, with each test invoking different methods on objects in the fixture and asserting different expected results. Each test runs in its own test fixture to isolate tests from the changes made by other tests. That is, tests don't share the state of objects in the test fixture. Because the tests are isolated, they can be run in any order.
To create a test fixture, declare instance variables for the common objects. Initialize these objects in a public void method annotated with @Before. The JUnit framework automatically invokes any @Before methods before each test is run.
The following example shows a test fixture with a common Collection object.
<pre>
package junitfaq;

import org.junit.*;
import static org.junit.Assert.*;
import java.util.*;

public class SimpleTest {

private Collection<Object> collection;

@Before
public void setUp() {
collection = new ArrayList<Object>();
}

@Test
public void testEmptyCollection() {
assertTrue(collection.isEmpty());
}

@Test
public void testOneItemCollection() {
collection.add("itemA");
assertEquals(1, collection.size());
}
}
</pre>
Given this test, the methods might execute in the following order: 
setUp() 
testEmptyCollection() 
setUp() 
testOneItemCollection() 
The ordering of test-method invocations is not guaranteed, so testOneItemCollection() might be executed before testEmptyCollection(). But it doesn't matter, because each method gets its own instance of the collection.
Although JUnit provides a new instance of the fixture objects for each test method, if you allocate any external resources in a @Before method, you should release them after the test runs by annotating a method with @After. The JUnit framework automatically invokes any @After methods after each test is run. For example:
<pre>
package junitfaq;

import org.junit.*;
import static org.junit.Assert.*;
import java.io.*;

public class OutputTest {

private File output;

@Before
public void createOutputFile() {
output = new File(...);
}

@After
public void deleteOutputFile() {
output.delete();
}

@Test
public void testSomethingWithFile() {
...
}
}
</pre>
With this test, the methods will execute in the following order:

* createOutputFile()
* testSomethingWithFile()
* deleteOutputFile()

=== To Test a method that doesnot return anything ===
If a method doesn't return a value, it might have some side effect. Actually, if it doesn't return a value AND doesn't have a side effect, it isn't doing anything.
There may be a way to verify that the side effect actually occurred as expected. For example, consider the add() method in the Collection classes. There are ways of verifying that the side effect happened (i.e. the object was added). You can check the size and assert that it is what is expected:

<pre>
public void testCollectionAdd() {
Collection collection = new ArrayList();
assertEquals(0, collection.size());
collection.add("itemA");
assertEquals(1, collection.size());
collection.add("itemB");
assertEquals(2, collection.size());
}
</pre>
=== To test an expected/unexpected exception ===
* Case of expected exception
Add the optional expected attribute to the @Test annotation. The following is an example test that passes when the expected IndexOutOfBoundsException is raised:
<pre>
@Test(expected=IndexOutOfBoundsException.class)
public void testIndexOutOfBoundsException() {
ArrayList emptyList = new ArrayList();
Object o = emptyList.get(0);
}
</pre>
* Case of unexpected exception
Declare the exception in the throws clause of the test method and don't catch the exception within the test method. Uncaught exceptions will cause the test to fail with an error.
The following is an example test that fails when the IndexOutOfBoundsException is raised:
<pre>
@Test
public void testIndexOutOfBoundsExceptionNotRaised()
throws IndexOutOfBoundsException {

ArrayList emptyList = new ArrayList();
Object o = emptyList.get(0);
}
</pre>

=== To Test protected/private methods ===
* Case for protected methods
Place your tests in the same package as the classes under test.
* Case for private methods
Testing private methods may be an indication that those methods should be moved into another class to promote reusability.
=== Conditions to test get() and set() methods ===
Unit tests are intended to alleviate fear that something might break. If you think a get() or set() method could reasonably break, or has in fact contributed to a defect, then by all means write a test.
In short, test until you're confident. What you choose to test is subjective, based on your experiences and confidence level. Remember to be practical and maximize your testing investment.

=== To run setUp() and tearDown() code once for all tests ===

You can add a @BeforeClass annotation to a method to be run before all the tests in a class, and a @AfterClass annotation to a method to be run after all the tests in a class. Here's an example:

<pre>
package junitfaq;

import org.junit.*;
import static org.junit.Assert.*;
import java.util.*;

public class SimpleTest {

private Collection collection;

@BeforeClass
public static void oneTimeSetUp() {
// one-time initialization code
}

@AfterClass
public static void oneTimeTearDown() {
// one-time cleanup code
}

@Before
public void setUp() {
collection = new ArrayList();
}

@After
public void tearDown() {
collection.clear();
}

@Test
public void testEmptyCollection() {
assertTrue(collection.isEmpty());
}

@Test
public void testOneItemCollection() {
collection.add("itemA");
assertEquals(1, collection.size());
}
}
</pre>
Given this test, the methods will execute in the following order:

*oneTimeSetUp()
*setUp()
*testEmptyCollection()
*tearDown()
*setUp()
*testOneItemCollection()
*tearDown()
*oneTimeTearDown()

==Conclusion==
By following the guidelines given in this articles, one can write a good unit test using junit, which is as important as writing good quality code. 
A good quality unit test will take care of all classes, boundary conditions, domain data and functionality. 
A good test can be creative to explore all possibilities, thinking out of box. 
Finally automating the test using tool like junit which is in the native java language itself helps in saving manual intervention and time/money. 

==References==

* http://articles.techrepublic.com.com/5100-10878_11-1027676.html
* http://msdn.microsoft.com/en-us/library/aa292197%28VS.71%29.asp
* http://junit.sourceforge.net/doc/cookbook/cookbook.htm
* http://junit.sourceforge.net/doc/faq/faq.htm#overview
* http://clarkware.com/articles/JUnitPrimer.html#usage
* http://users.csc.calpoly.edu/~jdalbey/205/Resources/junitQuickStart.html
* http://www.cis.upenn.edu/~matuszek/cit591-2004/Lectures/
* http://en.wikipedia.org/wiki/JUnit
* http://www.laliluna.de/eclipse-junit-testing-tutorial.html
* http://junit.sourceforge.net/doc/faq/faq.htm

-------------------------------------------------------

CSC/ECE 517 Fall 2009/wiki1a 1 JunitTest

2009-09-08T18:30:30Z

Wolverine:

'''Writing Effective JUnit Test Cases''' 
----

''JUnit is a testing framework aimed at making unit testing easy by simplifying the writing of test cases and by providing automated running of tests and test suites.''

The objective of this document is to provide a repository of rules that can be used in-order to write an effective Junit test.
This doc also discusses various sites and suggest which are the best sites to read for an overview of the topic and to understand the different philosophies of test-case design.

==Introduction==

=== Unit Testing Overview ===

The primary goal of unit testing is to take the smallest piece of testable software in the application, isolate it from the remainder of the code, and determine whether it behaves exactly as you expect.

'''Test Case''' 
It describes a scenario that can be exercised through the application. 
Each test case is divided into two parts: input and expected output. 
The input part lists all the test case statements that create variables or assign values to variables. 
The expected output part indicates the expected results; it shows either assertions or the message 'no exception' (when no assertions exist). 

The main issue in constructing a unit test is deciding the scope of test cases. 
If the scope is too narrow, then the tests will be trivial and the objects might pass the tests, but there will be no design of their interactions and interactions of objects are important for object oriented design. 
On the other hand if the scope is too broad, then there is a high chance that not every component of the new code will get tested. 
The programmer is then reduced to testing-by-poking-around, which is not an effective test strategy. 

=== JUnit Overview ===
Non-automated testing is usually like this: 
* An expression is used in a debugger, you can change debug expressions without recompiling, and you can wait to decide what to write until you have seen the running objects. 
* Expressions are tested as statements which print to the standard output stream. 
But its not preferred because: 
* They require human judgment to analyze their results. 
* They are cumbersome, non repeatable - you can only execute one debug expression at a time and a program with too many print statements causes the dreaded "Scroll Blindness". 
On the upper hand, JUnit tests, which uses the automated framework does not require human judgment to interpret, and it is easy to run many of them at the same time.
 
When you need to test something, here is what you do: 
* Annotate a method with @org.junit.Test 
* When you want to check a value, import org.junit.Assert.* statically, call assertTrue() and pass a boolean that is true if the test succeeds 
'''So what exactly is JUnit ?? ''' 
It is a open-source unit testing framework for Java and provides a way to organize test data and perform repeatable test execution. 
In JUnit, one has to write Java code, called a test class, that describes test data, invokes the methods to be tested, and determines test results. 
JUnit was originally written by Erich Gamma and Kent Beck. 
The official JUnit home page is http://junit.org. 
JUnit is Open Source Software, released under IBM's Common Public License Version 0.5 and hosted on SourceForge. 
It is an instance of the xUnit architecture for unit testing frameworks. JUnit features include: 
* Assertions for testing expected results 
* Test fixtures for sharing common test data 
* Test runners for running tests 
'''JUnit mailing lists and forums''' 
[http://groups.yahoo.com/group/junit/ JUnit user list] 
[http://lists.sourceforge.net/lists/listinfo/junit-announce JUnit announcements] 
[http://lists.sourceforge.net/lists/listinfo/junit-devel JUnit developer list] 
'''JUnit official documentation''' 
[http://junit.sourceforge.net/doc/testinfected/testing.htm JUnit Test Infected: Programmers Love Writing Tests] 
[http://junit.sourceforge.net/doc/cookbook/cookbook.htm JUnit Cookbook] 
[http://junit.sourceforge.net/doc/cookstour/cookstour.htm JUnit - A Cook's Tour] 
[http://junit.sourceforge.net/doc/faq/faq.htm JUnit FAQ] 
Although JUnit testing costs some time and money, but unit testing provides some crucial advantages, viz: 
Automation of the testing process 
Reduces difficulties of discovering errors contained in more complex pieces of the application 
Test coverage is often enhanced because attention is given to each unit. 
For example, 
if you have two units and decide it would be more cost effective to glue them together and initially test them as an integrated unit, an error could occur in a variety of places, now: 
* Is the error due to a defect in unit 1? 
* Is the error due to a defect in unit 2? 
* Is the error due to defects in both units? 
* Is the error due to a defect in the interface between the units? 
* Is the error due to a defect in the test? 
Finding the error (or errors) in the integrated module is much more complicated than first isolating the units, testing each, then integrating them and testing the whole. 
 

== Websites to lookout ==
These are some of the best webpages which will help you in getting more description as well as details about Junit.
 Also it will help you understand the test case design philosophy. 
=== For Overview ===
* Junit testing basics: 
http://articles.techrepublic.com.com/5100-10878_11-1027676.html

* Basics of Junit: 
http://junit.sourceforge.net/doc/cookbook/cookbook.htm
http://junit.sourceforge.net/doc/faq/faq.htm#overview

=== For Ideas on test case design ===
* For successful test automation: 
http://www.io.com/~wazmo/papers/seven_steps.html

* Unit testing principles: 
http://www.acm.org/ubiquity/views/t_burns_1.html

* For test suite effectiveness: 
http://java.sys-con.com/node/299945
 

== How to get started ==
=== Step 1: Installing JUnit ===

* Download latest version of JUnit from "http://sourceforge.net/projects/junit/files/". 
* Then install JUnit on your platform of choice: 
Windows 
To install JUnit on Windows, follow these steps: 
* Unzip the junit.zip distribution file to a directory referred to as %JUNIT_HOME%. 
* Add JUnit to the classpath: 
<pre>set CLASSPATH=%JUNIT_HOME%\junit.jar</pre>
'''Unix (bash)''' 
To install JUnit on Unix, follow these steps: 
* Unzip the junit.zip distribution file to a directory referred to as $JUNIT_HOME. 
* Add JUnit to the classpath: 
<pre>export CLASSPATH=$JUNIT_HOME/junit.jar</pre>

=== Step 2: Writing a Test Case ===
To write a test case, follow these steps: 

* Implement a class derived from TestCase, a base class provided by JUnit. 
public class BooksCartTest extends TestCase
* Be sure the test class belongs to the same package as that of the unit you wish to test 
* Override the setUp() method to initialize object(s) under test. 
* Optionally override the tearDown() method to release object(s) under test. 
* Define one or more public testXXX() methods that exercise the object(s) under test and assert expected results. 
The following is an example test case: 
<pre>
import junit.framework.TestCase;

public class BooksCartTest extends TestCase {

private BooksCart cart1;
private BooksCart cart2;

/**
* Sets up the test fixture.
*
* Called before every test case method.
*/
protected void setUp() {

cart1 = new BooksCart(6,8);
cart2 = new BooksCart(7,10);
}

/**
* Tears down the test fixture.
*
* Called after every test case method.
*/
protected void tearDown() {
// release objects under test here, if necessary
}

/**
* Tests emptying the cart.
*/
public void testEmpty() {

cart1.empty();
cart2.empty();
assertEquals(cart1, new BooksCart(3, 9));
assertTrue(!cart2.equals(cart1));
}
}
</pre>
Methods used in JUnit: 
* An assert method is a JUnit method that performs a test, and throws an AssertionFailedError if the test fails 
* static void assertTrue(boolean test) 
static void assertTrue(String message, boolean test)
- Throws an AssertionFailedError if the test fails 
- The optional message is included in the Error 
* static void assertFalse(boolean test) 
static void assertFalse(String message, boolean test)
- Throws an AssertionFailedError if the test fails 

=== Step 3: Writing a Test Suite ===
Next, we'll write a test suite that includes several test cases. The test suite will allow us to run all of its test cases in one fell swoop. 
'''To write a test suite, follow these steps:''' 
* Write a Java class that defines a static suite() factory method that creates a TestSuite containing all the tests. 
* Optionally define a main() method that runs the TestSuite in batch mode. 

The following is an example test suite: 
<pre>
import junit.framework.Test;
import junit.framework.TestSuite;

public class BooksCartTestSuite {

public static Test suite() {

TestSuite suite = new TestSuite();

//
// The BooksCartTest we created above.
//
suite.addTestSuite(BooksCartTest.class);

//
// Another example test suite of tests.
//
suite.addTest(CreditCardTestSuite.suite());

//
// Add more tests here
//

return suite;
}

/**
* Runs the test suite using the textual runner.
*/
public static void main(String[] args) {
junit.textui.TestRunner.run(suite());
}
}
</pre>

=== Step 4: Running the Test ===
Now that we've written a test suite containing a collection of test cases and other test suites, we can run either the test suite or any of its test cases individually. Running a TestSuite will automatically run all of its subordinate TestCase instances and TestSuite instances. Running a TestCase will automatically invoke all of its public testXXX() methods.
JUnit provides both a textual and a graphical user interface. Both user interfaces indicate how many tests were run, any errors or failures, and a simple completion status. The simplicity of the user interfaces is the key to running tests quickly. You should be able to run your tests and know the test status with a glance, much like you do with a compiler.

To run our test case using the textual user interface, use: 
<pre>java junit.textui.TestRunner BooksCartTest </pre>
The textual user interface displays "OK" if all the tests passed and failure messages if any of the tests failed. 
To run the test case using the graphical user interface, use: 
<pre>java junit.swingui.TestRunner BooksCartTest </pre> 
The graphical user interface displays a Swing window with a green progress bar if all the tests passed or a red progress bar if any of the tests failed. 
The BooksCartTest Suite can be run similarly: 
<pre>java junit.swingui.TestRunner BooksCartTestSuite</pre>

== Rules for designing effective JUnit Test cases ==
* Identify and assemble a list of all the actions that your program should be able to perform. use cases,nonfunctional requirements specifications, test case specifications, user interface design documents, mockups, user profiles, and various additional artifacts.
* Identify the code's entry points - central pieces of code that exercise the functionality that the code as a whole is designed to undertake.
* Pair entry points with the use cases that they implement.
* Create test cases by applying the initialize/work/check procedure.
** Initialize: Create the environment that the test expects to run in. The initialization code can either be in the beginning of the test or in the setUp() method.
** Work: Call the code that is being tested, capturing any interesting output and recording any interesting statistics.
** Check: Use assert statements to ensure that the code worked as expected.
* Develop runtime event diagrams and use them to facilitate testing.
* Follow KISS rule:It's a bad idea to keep the input source name and expression in the test case. Some items (server names, usernames and passwords, etc.) should not live in the test files, which should be configurable for the specific deployment. Rather, design the test cases to facilitate separation of test drivers and test data, test driver reuse over a larger set of data, and test data reuse over a larger set of test drivers. On the other hand, don't over-architect a simple test case implementation. Typically, the test case specification already defines most of the system states and allows parameter descriptions for a scenario, so there's no point in making everything parameterizable in the test implementation.

==Rules for coding effective JUnit Tests==

=== Using Test Fixture for a common set of objects ===
Using a test fixture avoids duplicating the code necessary to initialize (and cleanup) the common objects.
Tests can use the objects (variables) in a test fixture, with each test invoking different methods on objects in the fixture and asserting different expected results. Each test runs in its own test fixture to isolate tests from the changes made by other tests. That is, tests don't share the state of objects in the test fixture. Because the tests are isolated, they can be run in any order.
To create a test fixture, declare instance variables for the common objects. Initialize these objects in a public void method annotated with @Before. The JUnit framework automatically invokes any @Before methods before each test is run.
The following example shows a test fixture with a common Collection object.
<pre>
package junitfaq;

import org.junit.*;
import static org.junit.Assert.*;
import java.util.*;

public class SimpleTest {

private Collection<Object> collection;

@Before
public void setUp() {
collection = new ArrayList<Object>();
}

@Test
public void testEmptyCollection() {
assertTrue(collection.isEmpty());
}

@Test
public void testOneItemCollection() {
collection.add("itemA");
assertEquals(1, collection.size());
}
}
</pre>
Given this test, the methods might execute in the following order: 
setUp() 
testEmptyCollection() 
setUp() 
testOneItemCollection() 
The ordering of test-method invocations is not guaranteed, so testOneItemCollection() might be executed before testEmptyCollection(). But it doesn't matter, because each method gets its own instance of the collection.
Although JUnit provides a new instance of the fixture objects for each test method, if you allocate any external resources in a @Before method, you should release them after the test runs by annotating a method with @After. The JUnit framework automatically invokes any @After methods after each test is run. For example:
<pre>
package junitfaq;

import org.junit.*;
import static org.junit.Assert.*;
import java.io.*;

public class OutputTest {

private File output;

@Before
public void createOutputFile() {
output = new File(...);
}

@After
public void deleteOutputFile() {
output.delete();
}

@Test
public void testSomethingWithFile() {
...
}
}
</pre>
With this test, the methods will execute in the following order:

* createOutputFile()
* testSomethingWithFile()
* deleteOutputFile()

=== To Test a method that doesnot return anything ===
If a method doesn't return a value, it might have some side effect. Actually, if it doesn't return a value AND doesn't have a side effect, it isn't doing anything.
There may be a way to verify that the side effect actually occurred as expected. For example, consider the add() method in the Collection classes. There are ways of verifying that the side effect happened (i.e. the object was added). You can check the size and assert that it is what is expected:

<pre>
public void testCollectionAdd() {
Collection collection = new ArrayList();
assertEquals(0, collection.size());
collection.add("itemA");
assertEquals(1, collection.size());
collection.add("itemB");
assertEquals(2, collection.size());
}
</pre>
=== To test an expected/unexpected exception ===
* Case of expected exception
Add the optional expected attribute to the @Test annotation. The following is an example test that passes when the expected IndexOutOfBoundsException is raised:
<pre>
@Test(expected=IndexOutOfBoundsException.class)
public void testIndexOutOfBoundsException() {
ArrayList emptyList = new ArrayList();
Object o = emptyList.get(0);
}
</pre>
* Case of unexpected exception
Declare the exception in the throws clause of the test method and don't catch the exception within the test method. Uncaught exceptions will cause the test to fail with an error.
The following is an example test that fails when the IndexOutOfBoundsException is raised:
<pre>
@Test
public void testIndexOutOfBoundsExceptionNotRaised()
throws IndexOutOfBoundsException {

ArrayList emptyList = new ArrayList();
Object o = emptyList.get(0);
}
</pre>

=== To Test protected/private methods ===
* Case for protected methods
Place your tests in the same package as the classes under test.
* Case for private methods
Testing private methods may be an indication that those methods should be moved into another class to promote reusability.
=== Conditions to test get() and set() methods ===
Unit tests are intended to alleviate fear that something might break. If you think a get() or set() method could reasonably break, or has in fact contributed to a defect, then by all means write a test.
In short, test until you're confident. What you choose to test is subjective, based on your experiences and confidence level. Remember to be practical and maximize your testing investment.

=== To run setUp() and tearDown() code once for all tests ===

You can add a @BeforeClass annotation to a method to be run before all the tests in a class, and a @AfterClass annotation to a method to be run after all the tests in a class. Here's an example:

<pre>
package junitfaq;

import org.junit.*;
import static org.junit.Assert.*;
import java.util.*;

public class SimpleTest {

private Collection collection;

@BeforeClass
public static void oneTimeSetUp() {
// one-time initialization code
}

@AfterClass
public static void oneTimeTearDown() {
// one-time cleanup code
}

@Before
public void setUp() {
collection = new ArrayList();
}

@After
public void tearDown() {
collection.clear();
}

@Test
public void testEmptyCollection() {
assertTrue(collection.isEmpty());
}

@Test
public void testOneItemCollection() {
collection.add("itemA");
assertEquals(1, collection.size());
}
}
</pre>
Given this test, the methods will execute in the following order:

*oneTimeSetUp()
*setUp()
*testEmptyCollection()
*tearDown()
*setUp()
*testOneItemCollection()
*tearDown()
*oneTimeTearDown()

==Conclusion==
==References==

* http://articles.techrepublic.com.com/5100-10878_11-1027676.html
* http://msdn.microsoft.com/en-us/library/aa292197%28VS.71%29.asp
* http://junit.sourceforge.net/doc/cookbook/cookbook.htm
* http://junit.sourceforge.net/doc/faq/faq.htm#overview
* http://clarkware.com/articles/JUnitPrimer.html#usage
* http://users.csc.calpoly.edu/~jdalbey/205/Resources/junitQuickStart.html
* http://www.cis.upenn.edu/~matuszek/cit591-2004/Lectures/
* http://en.wikipedia.org/wiki/JUnit
* http://www.laliluna.de/eclipse-junit-testing-tutorial.html
* http://junit.sourceforge.net/doc/faq/faq.htm

-------------------------------------------------------

CSC/ECE 517 Fall 2009/wiki1a 1 JunitTest

2009-09-08T02:14:22Z

Wolverine:

'''Writing Effective JUnit Test Cases''' 
----

''JUnit is a testing framework aimed at making unit testing easy by simplifying the writing of test cases and by providing automated running of tests and test suites.''

The objective of this document is to provide a repository of rules that can be used in-order to write an effective Junit test.
This doc also discusses various sites and suggest which are the best sites to read for an overview of the topic and to understand the different philosophies of test-case design.

==Introduction==

=== Unit Testing Overview ===

The primary goal of unit testing is to take the smallest piece of testable software in the application, isolate it from the remainder of the code, and determine whether it behaves exactly as you expect.

'''Test Case''' 
It describes a scenario that can be exercised through the application. 
Each test case is divided into two parts: input and expected output. 
The input part lists all the test case statements that create variables or assign values to variables. 
The expected output part indicates the expected results; it shows either assertions or the message 'no exception' (when no assertions exist). 

The main issue in constructing a unit test is deciding the scope of test cases. 
If the scope is too narrow, then the tests will be trivial and the objects might pass the tests, but there will be no design of their interactions and interactions of objects are important for object oriented design. 
On the other hand if the scope is too broad, then there is a high chance that not every component of the new code will get tested. 
The programmer is then reduced to testing-by-poking-around, which is not an effective test strategy. 

=== JUnit Overview ===
Non-automated testing is usually like this: 
* An expression is used in a debugger, you can change debug expressions without recompiling, and you can wait to decide what to write until you have seen the running objects. 
* Expressions are tested as statements which print to the standard output stream. 
 
But its not preferred because: 
* They require human judgment to analyze their results. 
* They are cumbersome, non repeatable - you can only execute one debug expression at a time and a program with too many print statements causes the dreaded "Scroll Blindness".
 
On the upper hand, JUnit tests, which uses the automated framework does not require human judgment to interpret, and it is easy to run many of them at the same time.
 
When you need to test something, here is what you do: 
* Annotate a method with @org.junit.Test 
* When you want to check a value, import org.junit.Assert.* statically, call assertTrue() and pass a boolean that is true if the test succeeds 
 
'''So what exactly is JUnit ?? ''' 
It is a open-source unit testing framework for Java and provides a way to organize test data and perform repeatable test execution. 
In JUnit, one has to write Java code, called a test class, that describes test data, invokes the methods to be tested, and determines test results. 
 
JUnit was originally written by Erich Gamma and Kent Beck. 
The official JUnit home page is http://junit.org. 
JUnit is Open Source Software, released under IBM's Common Public License Version 0.5 and hosted on SourceForge. 
 
It is an instance of the xUnit architecture for unit testing frameworks. JUnit features include: 
* Assertions for testing expected results 
* Test fixtures for sharing common test data 
* Test runners for running tests 
 
'''JUnit mailing lists and forums''' 
[http://groups.yahoo.com/group/junit/ JUnit user list] 
[http://lists.sourceforge.net/lists/listinfo/junit-announce JUnit announcements] 
[http://lists.sourceforge.net/lists/listinfo/junit-devel JUnit developer list] 
 
'''JUnit official documentation''' 
[http://junit.sourceforge.net/doc/testinfected/testing.htm JUnit Test Infected: Programmers Love Writing Tests] 
[http://junit.sourceforge.net/doc/cookbook/cookbook.htm JUnit Cookbook] 
[http://junit.sourceforge.net/doc/cookstour/cookstour.htm JUnit - A Cook's Tour] 
[http://junit.sourceforge.net/doc/faq/faq.htm JUnit FAQ] 
 
Although JUnit testing costs some time and money, but unit testing provides some crucial advantages, viz: 
Automation of the testing process 
Reduces difficulties of discovering errors contained in more complex pieces of the application 
Test coverage is often enhanced because attention is given to each unit. 
 
For example, 
if you have two units and decide it would be more cost effective to glue them together and initially test them as an integrated unit, an error could occur in a variety of places, now: 
* Is the error due to a defect in unit 1? 
* Is the error due to a defect in unit 2? 
* Is the error due to defects in both units? 
* Is the error due to a defect in the interface between the units? 
* Is the error due to a defect in the test? 
 
Finding the error (or errors) in the integrated module is much more complicated than first isolating the units, testing each, then integrating them and testing the whole. 
 

== Websites to lookout ==
These are some of the best webpages which will help you in getting more description as well as details about Junit.
 Also it will help you understand the test case design philosophy. 
=== For Overview ===
* Junit testing basics: 
http://articles.techrepublic.com.com/5100-10878_11-1027676.html

* Basics of Junit: 
http://junit.sourceforge.net/doc/cookbook/cookbook.htm
http://junit.sourceforge.net/doc/faq/faq.htm#overview

=== For Ideas on test case design ===
* For successful test automation: 
http://www.io.com/~wazmo/papers/seven_steps.html

* Unit testing principles: 
http://www.acm.org/ubiquity/views/t_burns_1.html

* For test suite effectiveness: 
http://java.sys-con.com/node/299945
 

== How to get started ==
=== Step 1: Installing JUnit ===

* Download latest version of JUnit from "http://sourceforge.net/projects/junit/files/". 
* Then install JUnit on your platform of choice: 
Windows 
To install JUnit on Windows, follow these steps: 
* Unzip the junit.zip distribution file to a directory referred to as %JUNIT_HOME%. 
* Add JUnit to the classpath: 
<pre>set CLASSPATH=%JUNIT_HOME%\junit.jar</pre>
'''Unix (bash)''' 
To install JUnit on Unix, follow these steps: 
* Unzip the junit.zip distribution file to a directory referred to as $JUNIT_HOME. 
* Add JUnit to the classpath: 
<pre>export CLASSPATH=$JUNIT_HOME/junit.jar</pre>

=== Step 2: Writing a Test Case ===
To write a test case, follow these steps: 

* Implement a class derived from TestCase, a base class provided by JUnit. 
public class ShoppingCartTest extends TestCase
* Be sure the test class belongs to the same package as that of the unit you wish to test 
* Override the setUp() method to initialize object(s) under test. 
* Optionally override the tearDown() method to release object(s) under test. 
* Define one or more public testXXX() methods that exercise the object(s) under test and assert expected results. 
The following is an example test case: 
<pre>
import junit.framework.TestCase;

public class ShoppingCartTest extends TestCase {

private ShoppingCart cart1;
private ShoppingCart cart2;

/**
* Sets up the test fixture.
*
* Called before every test case method.
*/
protected void setUp() {

cart1 = new ShoppingCart(6,8);
cart2 = new ShoppingCart(3,9);
}

/**
* Tears down the test fixture.
*
* Called after every test case method.
*/
protected void tearDown() {
// release objects under test here, if necessary
}

/**
* Tests emptying the cart.
*/
public void testEmpty() {

cart1.empty();
cart2.empty();
assertEquals(cart1, new ShoppingCart(3, 9));
assertTrue(!cart2.equals(cart1));
}
}
</pre>
Methods used in JUnit: 
1. An assert method is a JUnit method that performs a test, and throws an AssertionFailedError if the test fails 
2. static void assertTrue(boolean test) 
static void assertTrue(String message, boolean test) 
* Throws an AssertionFailedError if the test fails 
* The optional message is included in the Error 
3. static void assertFalse(boolean test) 
static void assertFalse(String message, boolean test) 
* Throws an AssertionFailedError if the test fails 

=== Step 3: Writing a Test Suite ===
Next, we'll write a test suite that includes several test cases. The test suite will allow us to run all of its test cases in one fell swoop. 
To write a test suite, follow these steps: 
1. Write a Java class that defines a static suite() factory method that creates a TestSuite containing all the tests. 
2. Optionally define a main() method that runs the TestSuite in batch mode. 

The following is an example test suite: 
<pre>
import junit.framework.Test;
import junit.framework.TestSuite;

public class ShoppingCartTestSuite {

public static Test suite() {

TestSuite suite = new TestSuite();

//
// The ShoppingCartTest we created above.
//
suite.addTestSuite(ShoppingCartTest.class);

//
// Another example test suite of tests.
//
suite.addTest(CreditCardTestSuite.suite());

//
// Add more tests here
//

return suite;
}

/**
* Runs the test suite using the textual runner.
*/
public static void main(String[] args) {
junit.textui.TestRunner.run(suite());
}
}
</pre>

=== Step 4: Running the Test ===
Now that we've written a test suite containing a collection of test cases and other test suites, we can run either the test suite or any of its test cases individually. Running a TestSuite will automatically run all of its subordinate TestCase instances and TestSuite instances. Running a TestCase will automatically invoke all of its public testXXX() methods.
JUnit provides both a textual and a graphical user interface. Both user interfaces indicate how many tests were run, any errors or failures, and a simple completion status. The simplicity of the user interfaces is the key to running tests quickly. You should be able to run your tests and know the test status with a glance, much like you do with a compiler.

To run our test case using the textual user interface, use: 
<pre>java junit.textui.TestRunner ShoppingCartTest </pre>
The textual user interface displays "OK" if all the tests passed and failure messages if any of the tests failed. 
To run the test case using the graphical user interface, use: 
<pre>java junit.swingui.TestRunner ShoppingCartTest </pre> 
The graphical user interface displays a Swing window with a green progress bar if all the tests passed or a red progress bar if any of the tests failed. 
The ShoppingCartTest Suite can be run similarly: 
<pre>java junit.swingui.TestRunner ShoppingCartTestSuite</pre>

== Rules for designing effective JUnit Test cases ==
* Identify and assemble a list of all the actions that your program should be able to perform. use cases,nonfunctional requirements specifications, test case specifications, user interface design documents, mockups, user profiles, and various additional artifacts.
* Identify the code's entry points - central pieces of code that exercise the functionality that the code as a whole is designed to undertake.
* Pair entry points with the use cases that they implement.
* Create test cases by applying the initialize/work/check procedure.
** Initialize: Create the environment that the test expects to run in. The initialization code can either be in the beginning of the test or in the setUp() method.
** Work: Call the code that is being tested, capturing any interesting output and recording any interesting statistics.
** Check: Use assert statements to ensure that the code worked as expected.
* Develop runtime event diagrams and use them to facilitate testing.
* Follow KISS rule:It's a bad idea to keep the input source name and expression in the test case. Some items (server names, usernames and passwords, etc.) should not live in the test files, which should be configurable for the specific deployment. Rather, design the test cases to facilitate separation of test drivers and test data, test driver reuse over a larger set of data, and test data reuse over a larger set of test drivers. On the other hand, don't over-architect a simple test case implementation. Typically, the test case specification already defines most of the system states and allows parameter descriptions for a scenario, so there's no point in making everything parameterizable in the test implementation.

==Rules for writing effective Junit Test cases==

=== Using Test Fixture for a common set of objects ===
Using a test fixture avoids duplicating the code necessary to initialize (and cleanup) the common objects.
Tests can use the objects (variables) in a test fixture, with each test invoking different methods on objects in the fixture and asserting different expected results. Each test runs in its own test fixture to isolate tests from the changes made by other tests. That is, tests don't share the state of objects in the test fixture. Because the tests are isolated, they can be run in any order.
To create a test fixture, declare instance variables for the common objects. Initialize these objects in a public void method annotated with @Before. The JUnit framework automatically invokes any @Before methods before each test is run.
The following example shows a test fixture with a common Collection object.
<pre>
package junitfaq;

import org.junit.*;
import static org.junit.Assert.*;
import java.util.*;

public class SimpleTest {

private Collection<Object> collection;

@Before
public void setUp() {
collection = new ArrayList<Object>();
}

@Test
public void testEmptyCollection() {
assertTrue(collection.isEmpty());
}

@Test
public void testOneItemCollection() {
collection.add("itemA");
assertEquals(1, collection.size());
}
}
</pre>
Given this test, the methods might execute in the following order:
setUp()
testEmptyCollection()
setUp()
testOneItemCollection()
The ordering of test-method invocations is not guaranteed, so testOneItemCollection() might be executed before testEmptyCollection(). But it doesn't matter, because each method gets its own instance of the collection.
Although JUnit provides a new instance of the fixture objects for each test method, if you allocate any external resources in a @Before method, you should release them after the test runs by annotating a method with @After. The JUnit framework automatically invokes any @After methods after each test is run. For example:
<pre>
package junitfaq;

import org.junit.*;
import static org.junit.Assert.*;
import java.io.*;

public class OutputTest {

private File output;

@Before
public void createOutputFile() {
output = new File(...);
}

@After
public void deleteOutputFile() {
output.delete();
}

@Test
public void testSomethingWithFile() {
...
}
}
</pre>
With this test, the methods will execute in the following order:

* createOutputFile()
* testSomethingWithFile()
* deleteOutputFile()

=== To Test a method that doesnot return anything ===
If a method doesn't return a value, it might have some side effect. Actually, if it doesn't return a value AND doesn't have a side effect, it isn't doing anything.
There may be a way to verify that the side effect actually occurred as expected. For example, consider the add() method in the Collection classes. There are ways of verifying that the side effect happened (i.e. the object was added). You can check the size and assert that it is what is expected:

<pre>
public void testCollectionAdd() {
Collection collection = new ArrayList();
assertEquals(0, collection.size());
collection.add("itemA");
assertEquals(1, collection.size());
collection.add("itemB");
assertEquals(2, collection.size());
}
</pre>
=== To test an expected/unexpected exception ===
* Case of expected exception
Add the optional expected attribute to the @Test annotation. The following is an example test that passes when the expected IndexOutOfBoundsException is raised:
<pre>
@Test(expected=IndexOutOfBoundsException.class)
public void testIndexOutOfBoundsException() {
ArrayList emptyList = new ArrayList();
Object o = emptyList.get(0);
}
</pre>
* Case of unexpected exception
Declare the exception in the throws clause of the test method and don't catch the exception within the test method. Uncaught exceptions will cause the test to fail with an error.
The following is an example test that fails when the IndexOutOfBoundsException is raised:
<pre>
@Test
public void testIndexOutOfBoundsExceptionNotRaised()
throws IndexOutOfBoundsException {

ArrayList emptyList = new ArrayList();
Object o = emptyList.get(0);
}
</pre>
=== To Test protected/private methods ===
* Case for protected methods
Place your tests in the same package as the classes under test.
* Case for private methods
Testing private methods may be an indication that those methods should be moved into another class to promote reusability.
=== Conditions to test get() and set() methods ===
Unit tests are intended to alleviate fear that something might break. If you think a get() or set() method could reasonably break, or has in fact contributed to a defect, then by all means write a test.
In short, test until you're confident. What you choose to test is subjective, based on your experiences and confidence level. Remember to be practical and maximize your testing investment.

=== To run setUp() and tearDown() code once for all tests ===

You can add a @BeforeClass annotation to a method to be run before all the tests in a class, and a @AfterClass annotation to a method to be run after all the tests in a class. Here's an example:

<pre>
package junitfaq;

import org.junit.*;
import static org.junit.Assert.*;
import java.util.*;

public class SimpleTest {

private Collection collection;

@BeforeClass
public static void oneTimeSetUp() {
// one-time initialization code
}

@AfterClass
public static void oneTimeTearDown() {
// one-time cleanup code
}

@Before
public void setUp() {
collection = new ArrayList();
}

@After
public void tearDown() {
collection.clear();
}

@Test
public void testEmptyCollection() {
assertTrue(collection.isEmpty());
}

@Test
public void testOneItemCollection() {
collection.add("itemA");
assertEquals(1, collection.size());
}
}
</pre>
Given this test, the methods will execute in the following order:

*oneTimeSetUp()
*setUp()
*testEmptyCollection()
*tearDown()
*setUp()
*testOneItemCollection()
*tearDown()
*oneTimeTearDown()

==Conclusion==
==References==

-------------------------------------------------------

CSC/ECE 517 Fall 2009/wiki1a 1 JunitTest

2009-09-08T01:18:23Z

Wolverine:

'''Writing Effective JUnit Test Cases''' 
----

JUnit is a testing framework aimed at making unit testing easy by simplifying the writing of test cases and by providing automated running of tests and test suites.

The main aim of this document is to provide a repository of rules that can be used in-order to write an effective Junit test.
This doc also discusses various sites and suggest which are the best sites to read for an overview of the topic and to understand the different philosophies of test-case design.

==Introduction==

===Unit Testing Overview===

The primary goal of unit testing is to take the smallest piece of testable software in the application, isolate it from the remainder of the code, and determine whether it behaves exactly as you expect.

''Test Case'' 
It describes a scenario that can be exercised through the application. 
Each test case is divided into two parts: input and expected output. 
The input part lists all the test case statements that create variables or assign values to variables. 
The expected output part indicates the expected results; it shows either assertions or the message 'no exception' (when no assertions exist). 

The main issue in constructing a unit test is deciding the scope of test cases. 
If the scope is too narrow, then the tests will be trivial and the objects might pass the tests, but there will be no design of their interactions and interactions of objects are important for object oriented design. 
On the other hand if the scope is too broad, then there is a high chance that not every component of the new code will get tested. 
The programmer is then reduced to testing-by-poking-around, which is not an effective test strategy. 

===Junit Overview===
Non-automated testing is usually like this: 
1. An expression is used in a debugger, you can change debug expressions without recompiling, and you can wait to decide what to write until you have seen the running objects. 
2. Expressions are tested as statements which print to the standard output stream. 
 
But its not preferred because: 
1. They require human judgment to analyze their results. 
2. They are cumbersome, non repeatable - you can only execute one debug expression at a time and a program with too many print statements causes the dreaded "Scroll Blindness".
 
On the upper hand, JUnit tests, which uses the automated framework does not require human judgment to interpret, and it is easy to run many of them at the same time.
 
When you need to test something, here is what you do: 
1. Annotate a method with @org.junit.Test 
2. When you want to check a value, import org.junit.Assert.* statically, call assertTrue() and pass a boolean that is true if the test succeeds 
 

''So what exactly is JUnit ?? '' 
It is a open-source unit testing framework for Java and provides a way to organize test data and perform repeatable test execution. 
In JUnit, one has to write Java code, called a test class, that describes test data, invokes the methods to be tested, and determines test results. 
 
JUnit was originally written by Erich Gamma and Kent Beck. 
The official JUnit home page is http://junit.org. 
JUnit is Open Source Software, released under IBM's Common Public License Version 0.5 and hosted on SourceForge. 
 

It is an instance of the xUnit architecture for unit testing frameworks. JUnit features include: 
1. Assertions for testing expected results 
2. Test fixtures for sharing common test data 
3. Test runners for running tests 
 

JUnit mailing lists and forums 
[http://groups.yahoo.com/group/junit/ JUnit user list] 
[http://lists.sourceforge.net/lists/listinfo/junit-announce JUnit announcements] 
[http://lists.sourceforge.net/lists/listinfo/junit-devel JUnit developer list] 

 
JUnit official documentation 
[http://junit.sourceforge.net/doc/testinfected/testing.htm JUnit Test Infected: Programmers Love Writing Tests] 
[http://junit.sourceforge.net/doc/cookbook/cookbook.htm JUnit Cookbook] 
[http://junit.sourceforge.net/doc/cookstour/cookstour.htm JUnit - A Cook's Tour] 
[http://junit.sourceforge.net/doc/faq/faq.htm JUnit FAQ] 

 
Although JUnit testing costs some time and money, but unit testing provides some crucial advantages, viz: 
Automation of the testing process 
Reduces difficulties of discovering errors contained in more complex pieces of the application 
Test coverage is often enhanced because attention is given to each unit. 
 
For example, 
if you have two units and decide it would be more cost effective to glue them together and initially test them as an integrated unit, an error could occur in a variety of places, now: 
Is the error due to a defect in unit 1? 
Is the error due to a defect in unit 2? 
Is the error due to defects in both units? 
Is the error due to a defect in the interface between the units? 
Is the error due to a defect in the test? 
 
Finding the error (or errors) in the integrated module is much more complicated than first isolating the units, testing each, then integrating them and testing the whole. 
 

==Websites to lookout==
These are some of the best webpages which will help you in getting more description as well as details about Junit.
 Also it will help you understand the test case design philosophy. 
===For Overview===
Junit testing basics: 
http://articles.techrepublic.com.com/5100-10878_11-1027676.html

Basics of Junit: 
http://junit.sourceforge.net/doc/cookbook/cookbook.htm
http://junit.sourceforge.net/doc/faq/faq.htm#overview

===For Ideas on test case design===
For successful test automation: 
http://www.io.com/~wazmo/papers/seven_steps.html

Unit testing principles: 
http://www.acm.org/ubiquity/views/t_burns_1.html

For test suite effectiveness: 
http://java.sys-con.com/node/299945

==How to get started==
===Setup===
===Simple testing example===

==Rules for writing effective Junit test cases==
==Conclusion==
==References==

Talk:CSC/ECE 517 Fall 2009/wiki1a 1 JunitTest

2009-09-08T01:08:05Z

Wolverine: /* To run setUp() and tearDown() code once for all tests */

==Introduction==

=== Writing Effective JUnit Test Cases ===

JUnit is a testing framework aimed at making unit testing easy by simplifying the writing of test cases and by providing automated running of tests and test suites.

The main aim of this document is to provide a repository of rules that can be used in-order to write an effective Junit test.
This doc also discusses various sites and suggest which are the best sites to read for an overview of the topic and to understand the different philosophies of test-case design.

=== Unit Testing Overview ===

The primary goal of unit testing is to take the smallest piece of testable software in the application, isolate it from the remainder of the code, and determine whether it behaves exactly as you expect.

'''Test Case''' 
It describes a scenario that can be exercised through the application. 
Each test case is divided into two parts: input and expected output. 
The input part lists all the test case statements that create variables or assign values to variables. 
The expected output part indicates the expected results; it shows either assertions or the message 'no exception' (when no assertions exist). 

The main issue in constructing a unit test is deciding the scope of test cases. 
If the scope is too narrow, then the tests will be trivial and the objects might pass the tests, but there will be no design of their interactions and interactions of objects are important for object oriented design. 
On the other hand if the scope is too broad, then there is a high chance that not every component of the new code will get tested. 
The programmer is then reduced to testing-by-poking-around, which is not an effective test strategy. 

=== Junit Overview ===
Non-automated testing is usually like this: 
* An expression is used in a debugger, you can change debug expressions without recompiling, and you can wait to decide what to write until you have seen the running objects. 
* Expressions are tested as statements which print to the standard output stream. 
 
But its not preferred because: 
* They require human judgment to analyze their results. 
* They are cumbersome, non repeatable - you can only execute one debug expression at a time and a program with too many print statements causes the dreaded "Scroll Blindness".
 
On the upper hand, JUnit tests, which uses the automated framework does not require human judgment to interpret, and it is easy to run many of them at the same time.
 
When you need to test something, here is what you do: 
* Annotate a method with @org.junit.Test 
* When you want to check a value, import org.junit.Assert.* statically, call assertTrue() and pass a boolean that is true if the test succeeds 
 
'''So what exactly is JUnit ?? ''' 
It is a open-source unit testing framework for Java and provides a way to organize test data and perform repeatable test execution. 
In JUnit, one has to write Java code, called a test class, that describes test data, invokes the methods to be tested, and determines test results. 
 
JUnit was originally written by Erich Gamma and Kent Beck. 
The official JUnit home page is http://junit.org. 
JUnit is Open Source Software, released under IBM's Common Public License Version 0.5 and hosted on SourceForge. 
 
It is an instance of the xUnit architecture for unit testing frameworks. JUnit features include: 
* Assertions for testing expected results 
* Test fixtures for sharing common test data 
* Test runners for running tests 
 
'''JUnit mailing lists and forums''' 
[http://groups.yahoo.com/group/junit/ JUnit user list] 
[http://lists.sourceforge.net/lists/listinfo/junit-announce JUnit announcements] 
[http://lists.sourceforge.net/lists/listinfo/junit-devel JUnit developer list] 
 
'''JUnit official documentation''' 
[http://junit.sourceforge.net/doc/testinfected/testing.htm JUnit Test Infected: Programmers Love Writing Tests] 
[http://junit.sourceforge.net/doc/cookbook/cookbook.htm JUnit Cookbook] 
[http://junit.sourceforge.net/doc/cookstour/cookstour.htm JUnit - A Cook's Tour] 
[http://junit.sourceforge.net/doc/faq/faq.htm JUnit FAQ] 
 
Although JUnit testing costs some time and money, but unit testing provides some crucial advantages, viz: 
Automation of the testing process 
Reduces difficulties of discovering errors contained in more complex pieces of the application 
Test coverage is often enhanced because attention is given to each unit. 
 
For example, 
if you have two units and decide it would be more cost effective to glue them together and initially test them as an integrated unit, an error could occur in a variety of places, now: 
* Is the error due to a defect in unit 1? 
* Is the error due to a defect in unit 2? 
* Is the error due to defects in both units? 
* Is the error due to a defect in the interface between the units? 
* Is the error due to a defect in the test? 
 
Finding the error (or errors) in the integrated module is much more complicated than first isolating the units, testing each, then integrating them and testing the whole. 
 

== Websites to lookout ==
These are some of the best webpages which will help you in getting more description as well as details about Junit.
 Also it will help you understand the test case design philosophy. 
=== For Overview ===
* Junit testing basics: 
http://articles.techrepublic.com.com/5100-10878_11-1027676.html

* Basics of Junit: 
http://junit.sourceforge.net/doc/cookbook/cookbook.htm
http://junit.sourceforge.net/doc/faq/faq.htm#overview

=== For Ideas on test case design ===
* For successful test automation: 
http://www.io.com/~wazmo/papers/seven_steps.html

* Unit testing principles: 
http://www.acm.org/ubiquity/views/t_burns_1.html

* For test suite effectiveness: 
http://java.sys-con.com/node/299945
 

== How to get started ==
=== Step 1: Installing JUnit ===

* Download latest version of JUnit from "http://sourceforge.net/projects/junit/files/". 
* Then install JUnit on your platform of choice: 
Windows 
To install JUnit on Windows, follow these steps: 
* Unzip the junit.zip distribution file to a directory referred to as %JUNIT_HOME%. 
* Add JUnit to the classpath: 
set CLASSPATH=%JUNIT_HOME%\junit.jar 
'''Unix (bash)''' 
To install JUnit on Unix, follow these steps: 
* Unzip the junit.zip distribution file to a directory referred to as $JUNIT_HOME. 
* Add JUnit to the classpath: 
export CLASSPATH=$JUNIT_HOME/junit.jar

=== Step 2: Writing a Test Case ===
To write a test case, follow these steps: 

* Implement a class derived from TestCase, a base class provided by JUnit. 
public class ShoppingCartTest extends TestCase 
* Be sure the test class belongs to the same package as that of the unit you wish to test 
* Override the setUp() method to initialize object(s) under test. 
* Optionally override the tearDown() method to release object(s) under test. 
* Define one or more public testXXX() methods that exercise the object(s) under test and assert expected results. 
The following is an example test case: 
<pre>
import junit.framework.TestCase;

public class ShoppingCartTest extends TestCase {

private ShoppingCart cart1;
private ShoppingCart cart2;

/**
* Sets up the test fixture.
*
* Called before every test case method.
*/
protected void setUp() {

cart1 = new ShoppingCart(6,8);
cart2 = new ShoppingCart(3,9);
}

/**
* Tears down the test fixture.
*
* Called after every test case method.
*/
protected void tearDown() {
// release objects under test here, if necessary
}

/**
* Tests emptying the cart.
*/
public void testEmpty() {

cart1.empty();
cart2.empty();
assertEquals(cart1, new ShoppingCart(3, 9));
assertTrue(!cart2.equals(cart1));
}
}
</pre>
Methods used in JUnit: 
1. An assert method is a JUnit method that performs a test, and throws an AssertionFailedError if the test fails 
2. static void assertTrue(boolean test) 
static void assertTrue(String message, boolean test) 
* Throws an AssertionFailedError if the test fails 
* The optional message is included in the Error 
3. static void assertFalse(boolean test) 
static void assertFalse(String message, boolean test) 
* Throws an AssertionFailedError if the test fails 

=== Step 3: Writing a Test Suite ===
Next, we'll write a test suite that includes several test cases. The test suite will allow us to run all of its test cases in one fell swoop. 
To write a test suite, follow these steps: 
1. Write a Java class that defines a static suite() factory method that creates a TestSuite containing all the tests. 
2. Optionally define a main() method that runs the TestSuite in batch mode. 

The following is an example test suite: 
<pre>
import junit.framework.Test;
import junit.framework.TestSuite;

public class ShoppingCartTestSuite {

public static Test suite() {

TestSuite suite = new TestSuite();

//
// The ShoppingCartTest we created above.
//
suite.addTestSuite(ShoppingCartTest.class);

//
// Another example test suite of tests.
//
suite.addTest(CreditCardTestSuite.suite());

//
// Add more tests here
//

return suite;
}

/**
* Runs the test suite using the textual runner.
*/
public static void main(String[] args) {
junit.textui.TestRunner.run(suite());
}
}
</pre>

=== Step 4: Running the Test ===
Now that we've written a test suite containing a collection of test cases and other test suites, we can run either the test suite or any of its test cases individually. Running a TestSuite will automatically run all of its subordinate TestCase instances and TestSuite instances. Running a TestCase will automatically invoke all of its public testXXX() methods.
JUnit provides both a textual and a graphical user interface. Both user interfaces indicate how many tests were run, any errors or failures, and a simple completion status. The simplicity of the user interfaces is the key to running tests quickly. You should be able to run your tests and know the test status with a glance, much like you do with a compiler.

To run our test case using the textual user interface, use: 
<pre>java junit.textui.TestRunner ShoppingCartTest </pre>
The textual user interface displays "OK" if all the tests passed and failure messages if any of the tests failed. 
To run the test case using the graphical user interface, use: 
<pre>java junit.swingui.TestRunner ShoppingCartTest </pre> 
The graphical user interface displays a Swing window with a green progress bar if all the tests passed or a red progress bar if any of the tests failed. 
The ShoppingCartTest Suite can be run similarly: 
<pre>java junit.swingui.TestRunner ShoppingCartTestSuite</pre>

== Rules for designing effective test cases that is easy to comprehend ==
* Identify and assemble a list of all the actions that your program should be able to perform. use cases,nonfunctional requirements specifications, test case specifications, user interface design documents, mockups, user profiles, and various additional artifacts.
* Identify the code's entry points - central pieces of code that exercise the functionality that the code as a whole is designed to undertake.
* Pair entry points with the use cases that they implement.
* Create test cases by applying the initialize/work/check procedure.
** Initialize: Create the environment that the test expects to run in. The initialization code can either be in the beginning of the test or in the setUp() method.
** Work: Call the code that is being tested, capturing any interesting output and recording any interesting statistics.
** Check: Use assert statements to ensure that the code worked as expected.
* Develop runtime event diagrams and use them to facilitate testing.
* Follow KISS rule:It's a bad idea to keep the input source name and expression in the test case. Some items (server names, usernames and passwords, etc.) should not live in the test files, which should be configurable for the specific deployment. Rather, design the test cases to facilitate separation of test drivers and test data, test driver reuse over a larger set of data, and test data reuse over a larger set of test drivers. On the other hand, don't over-architect a simple test case implementation. Typically, the test case specification already defines most of the system states and allows parameter descriptions for a scenario, so there's no point in making everything parameterizable in the test implementation.

==Rules for writing effective Junit test cases==
=== To Test a method that doesnot return anything ===
If a method doesn't return a value, it might have some side effect. Actually, if it doesn't return a value AND doesn't have a side effect, it isn't doing anything.
There may be a way to verify that the side effect actually occurred as expected. For example, consider the add() method in the Collection classes. There are ways of verifying that the side effect happened (i.e. the object was added). You can check the size and assert that it is what is expected:

<pre>
public void testCollectionAdd() {
Collection collection = new ArrayList();
assertEquals(0, collection.size());
collection.add("itemA");
assertEquals(1, collection.size());
collection.add("itemB");
assertEquals(2, collection.size());
}
</pre>

=== Conditions to test get() and set() methods ===
Unit tests are intended to alleviate fear that something might break. If you think a get() or set() method could reasonably break, or has in fact contributed to a defect, then by all means write a test.
In short, test until you're confident. What you choose to test is subjective, based on your experiences and confidence level. Remember to be practical and maximize your testing investment.

=== To run setUp() and tearDown() code once for all tests ===

You can add a @BeforeClass annotation to a method to be run before all the tests in a class, and a @AfterClass annotation to a method to be run after all the tests in a class. Here's an example:

<pre>
package junitfaq;

import org.junit.*;
import static org.junit.Assert.*;
import java.util.*;

public class SimpleTest {

private Collection collection;

@BeforeClass
public static void oneTimeSetUp() {
// one-time initialization code
}

@AfterClass
public static void oneTimeTearDown() {
// one-time cleanup code
}

@Before
public void setUp() {
collection = new ArrayList();
}

@After
public void tearDown() {
collection.clear();
}

@Test
public void testEmptyCollection() {
assertTrue(collection.isEmpty());
}

@Test
public void testOneItemCollection() {
collection.add("itemA");
assertEquals(1, collection.size());
}
}
</pre>
Given this test, the methods will execute in the following order:

*oneTimeSetUp()
*setUp()
*testEmptyCollection()
*tearDown()
*setUp()
*testOneItemCollection()
*tearDown()
*oneTimeTearDown()

==Conclusion==
==References==

-------------------------------------------------------

User:Wolverine

2009-09-07T20:57:32Z

Wolverine:

I am a Graduate Student at NC State University. 
Currently I am pursuing my MS in Computer Engineering and hoping to graduate in May 2010.