Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2012/ch2b 2w53 iv

2012-11-20T02:11:40Z

Annice:

=Singleton, Directory of Sites=
This article is presented in the form of directory of a number of sites explaining the use of Singleton pattern.Each of the link to the site is accompanied with the topics covered, a brief summary and a highlight of major points covered in the corresponding web page.
== [http://en.wikipedia.org/wiki/Singleton_pattern Singleton on the Wikipedia] ==

'''Topics Covered''' :
Common uses, UML, Implementation, Example, Prototype based singleton, Example of use with factory method pattern

'''Summary''' :
This link firstly provides the basic definition of the singleton pattern as a design pattern that restricts the instantiation of a class to one object. Singleton patters are mostly used in Abstract Factory, Builder, and Prototype, and Facade patterns.

Both the UML representation of singleton where the same single instance is always returned and the implementation concerning the mechanism to access the singleton class member without creating a class object and a mechanism to persist the value of class members among the class objects. The link also points out that if a class has to realize a contract expressed by an interface, it really has to be a singleton.

Lazy initialization uses double-checking and eager initialization which always creates an instance.
For instance, Lazy initialization and Eager Initialization example codes are:
'''Lazy Initialization''':
public class SingletonDemo {
private static volatile SingletonDemo instance = null;
private SingletonDemo() {}
public static SingletonDemo getInstance() {
if (instance == null) {
synchronized (SingletonDemo .class){
if (instance == null) {
instance = new SingletonDemo ();
}
}
}
return instance;
}
}

'''Eager Initialization''':
public class Singleton {
private static final Singleton instance = new Singleton();
private Singleton() {}
public static Singleton getInstance() {
return instance;
}
}

It also talks about Prototype-based programming in which objects but not classes are used, a 'singleton' simply refers to an object without copies or that is not used as the prototype for any other object. Eg :->
Foo := Object clone
Foo clone := Foo

'''Drawbacks''' :
The pattern makes unit testing far more difficult as it introduces global state into an application. It should also be noted that this pattern reduces the potential for parallelism within a program, because access to the singleton in a multi-threaded context must be serialized.

== [http://www.c-sharpcorner.com/UploadFile/SukeshMarla/learn-design-pattern-singleton-pattern/ Learn Singleton-design-Pattern]==

'''Topics Covered''' :
Definition, When to use, how to create, Sharing across all users, Sharing across a request, Sharing across a single user

'''Summary''' :
This article explains what Singleton pattern is, what kind of problem it generally solves and how should it be implemented in ASP.NET. The Singleton pattern which ensures that only one instance of a given object can exist at a context solves problems related to object creation and hence is a type of creational pattern.

{|
|[[File:3.jpg|x300px]]
|}

It can be used in a class that wraps the settings related to an application. In other words, whenever we want something to be shared across multiple locations, we use a singleton pattern. In order to create a Singleton pattern, we can render the constructor private so that no user can create a new instance outside the class, that way ensuring only one instance of the objects always exists. In that case, we also need to create a static method that returns the single object.

Singleton patterns in ASP.NET are implemented by using static objects which maintain their values and reside in the memory as long as the application which contains it does. The sharing can occur across users, or requests or across a single user.

== [http://www.c-sharpcorner.com/UploadFile/faraz.rasheed/SingletonPattern12052005063955AM/SingletonPattern.aspx Singleton - Creational Design Pattern]==

'''Topics Covered''' :
Intent, Description, An Example, Implementation, Benefits

'''Summary''' :
It firstly talks about the intent behind singleton design pattern, in that there is a need to have a class that can be instantiated only once.
Then, it describes two solutions for implementing the singleton class.
In the first, there should be only one shared object and reference to that shared object should be available through a static method GetInstance() while the constructor is private.
The second solution expects the constructor to be public but once an object has been instantiated, an exception should be thrown for each successive constructor call.

{|
|[[File:1.gif|x300px]]
|}

The code for each case is given as follows:

'''Case 1''' :
class Singleton
{
private static Singleton instance;
private static int numOfReference;
private string code;
private Singleton()
{
numOfReference = 0;
code = "Maasoom Faraz";
}
public static Singleton GetInstance()
{
if(instance == null)
{
instance = new Singleton();
}
numOfReference++;
return instance;
}
public static int Reference
{
get { return numOfReference; }
}
public string Code
{
get { return code; }
set { code = value;}
}
}

The constructor is made private and used to initialize the numOfReference and default value of code. GetInstance() method checks the instance, if it is null then it assign it an instance of Singleton otherwise return the old reference.

'''Case 2''' :
class Singleton2
{
private static int numOfInstance = 0;
public Singleton2()
{
if(numOfInstance == 0)
{
Console.WriteLine("\r\nCreating First Object of Singleton2 class...");
numOfInstance++;
}
else
{
throw new Exception("This class is Singleton,
+ so only one object of it can be instantiated.");
}
}
}

Here we make the constructor public and use a private field numOfInstance which is incremented for each constructor call. If numOfInstance is zero (no object is yet instantiated), a new object is allowed to made. But, if this value is not zero (there is already an object of Singleton2 class, an exception is thrown.

== [http://www.javaworld.com/javaworld/jw-04-2003/jw-0425-designpatterns.html Simply Singleton] ==

'''Topics Covered''':
Capabilities of Singleton pattern,Singleton design pattern class diagram, Example, use of protected constructors.

'''Summary''':
The Singleton design pattern addresses all of the previous paragraph's concerns. With the Singleton design pattern you can:
* Ensure that only one instance of a class is created.
* Provide a global point of access to the object.
* Allow multiple instances in the future without affecting a singleton class's clients.

As in , [http://www.javaworld.com/javaworld/jw-04-2003/jw-0425-designpatterns.html#resources Design Patterns], "Ensure a class has a single instance, and provide a global point of access to it"

{|
|[[File:4.jpg|x300px]]
|}

Other than the lazy initialization process, a classicSingleton class can also implement a protected constructor so client cannot instantiate ClassicSingleton instances; however, you may be surprised to discover that the following code is perfectly legal:

public class SingletonInstantiator {
public SingletonInstantiator() {
ClassicSingleton instance = ClassicSingleton.getInstance();
ClassicSingleton anotherInstance =
new ClassicSingleton();
...
}
}

Protected constructors can be called by subclasses and by other classes in the same package. Because ClassicSingleton and SingletonInstantiator are in the same package (the default package), SingletonInstantiator() methods can create ClassicSingleton instances. This dilemma has two solutions: You can make the ClassicSingleton constructor private so that only ClassicSingleton() methods call it; however, that means ClassicSingleton cannot be subclassed. Sometimes, that is a desirable solution; if so, it's a good idea to declare your singleton class final, which makes that intention explicit and allows the compiler to apply performance optimizations. The other solution is to put your singleton class in an explicit package, so classes in other packages (including the default package) cannot instantiate singleton instances.

== [http://javapapers.com/design-patterns/singleton-pattern/ JavaPaper on Singleton]==

'''Topics Covered''':
Strategy for Singleton instance creation, Early and lazy instantiation in singleton pattern, Singleton and Serialization

'''Summary''':
There are only two points in the definition of a singleton design pattern,
* There should be only one instance allowed for a class and
* We should allow global point of access to that single instance.

The key is not the problem and definition. In singleton pattern, trickier part is implementation and management of that single instance.

We suppress the constructor and don’t allow even a single instance for the class. But we declare an attribute for that same class inside and create instance for that and return it. [http://javapapers.com/design-patterns/abstract-factory-pattern/ Factory design pattern] can be used to create the singleton instance.

You need to be careful with multiple threads. If you don’t synchronize the method which is going to return the instance then, there is a possibility of allowing multiple instances in a multi-threaded scenario. Do the synchronization at block level considering the performance issues. In the below example for singleton pattern, you can see that it is threadsafe.

package com.javapapers.sample.designpattern;
public class Singleton {
private static Singleton singleInstance;
private Singleton() {}
public static Singleton getSingleInstance() {
if (singleInstance == null) {
synchronized (Singleton.class) {
if (singleInstance == null) {
singleInstance = new Singleton();
}
}
}
return singleInstance;
}

'''Singleton and Serialization''' : Using [http://javapapers.com/core-java/java-serialization/ serialization], single instance contract of the singleton pattern can be violated. You can serialize and de-serialize and get a new instance of the same singleton class. Using java api, you can implement the below method and override the instance read from the stream. So that you can always ensure that you have single instance.

ANY-ACCESS-MODIFIER Object readResolve() throws ObjectStreamException;

'''Usage of Singleton Pattern in Java API''':

java.lang.Runtime#getRuntime()
java.awt.Desktop#getDesktop()

== [http://www.codeproject.com/Articles/307233/Singleton-Pattern-Positive-and-Negative-Aspects Positive and Negative aspects of Singleton] ==

'''Topics Covered''':
Introduction, Positive sides of Singleton, Lazy and Static initialization, Negative sides of Singleton, When to use a Singleton class.

'''Summary''':
positive sides: The anatomy of a singleton class is very simple to understand. The class typically has a private constructor which will prohibit you to make any instance of the singleton class; instead you will access a static property or static function of the singleton class to get the reference of a preconfigured instance. These properties/methods ensure that there will be only one instance of the singleton class throughout the lifetime of the application.

The one and only instance of a singleton class is created within the singleton class and its reference is consumed by the callers. The creation process of the instance can be done using any of the following methods:

'''Lazy Initialization'''
If you opt for the lazy instantiation paradigm, then the singleton variable will not get memory until the property or function designated to return the reference is first called. This type of instantiation is very helpful if your singleton class is resource intense.

{|
|[[File:5.gif]]
|}

In order to make it thread-safe, One way is the use of double-checked locking. In double-checked locking, synchronization is only effective when the singleton variable is null, i.e., only for the first time call to Instance.

{|
|[[File:6.gif]]
|}

'''Static Initialization'''
In static initialization, memory is allocated to the variable at the time it is declared. The instance creation takes place behind the scenes when any of the member singleton classes is accessed for the first time. The main advantage of this type of implementation is that the CLR automatically takes care of race conditions I explained in lazy instantiation. We don't have to use any special synchronization constructs here.

{|
|[[File:7.gif]]
|}

* Inheriting a singleton class should be prohibited.
* Singleton takes over static classes on the following shortcomings:
- Static classes don’t promote inheritance. If your class has some interface to derive from, static classes makes it impossible.
- You cannot specify any creation logic with static methods.
- Static methods are procedural code.

'''Negative sides of Singleton''':
* They deviate from the Single Responsibility Principle. A singleton class has the responsibility to create an instance of itself along with other business responsibilities. However, this issue can be solved by delegating the creation part to a factory object.
* Singleton classes cannot be sub classed.
* Singletons can hide dependencies. One of the features of an efficient system architecture is minimizing dependencies between classes. This will in turn help you while conducting unit tests and while isolating any part of the program to a separate assembly.

However, it is commonly accepted that the singleton can yield best results in a situation where various parts of an application concurrently try to access a shared resource. An example of a shared resource would be Logger, Print Spooler, etc. When designing a singleton, consider the following points:
* Singleton classes must be memory-leak free. The instance of the singleton class is to be created once and it remains for the lifetime of the application.
* A real singleton class is not easily extensible.
* Derive the singleton class from an interface. This helps while doing unit testing (using Dependency Injection).

== [http://sourcemaking.com/design_patterns/singleton The Design pattern called Singleton]==

'''Topics Covered''' :
Intent, Problem, Discussion, Structure, Example, Check List, Rules of Thumb

'''Summary''':
Application needs one, and only one, instance of an object. Additionally, lazy initialization and global access are necessary.
Singleton should be considered only if all three of the following criteria are satisfied:
* Ownership of the single instance cannot be reasonably assigned
* Lazy initialization is desirable
* Global access is not otherwise provided for

If ownership of the single instance, when and how initialization occurs, and global access are not issues, Singleton is not sufficiently interesting.The Singleton pattern can be extended to support access to an application-specific number of instances. Make the class of the single instance responsible for access and “initialization on first use”. The single instance is a private static attribute. The accessor function is a public static method.

'''Example''':
The Singleton pattern ensures that a class has only one instance and provides a global point of access to that instance. It is named after the singleton set, which is defined to be a set containing one element. The office of the President of the United States is a Singleton. The United States Constitution specifies the means by which a president is elected, limits the term of office, and defines the order of succession. As a result, there can be at most one active president at any given time. Regardless of the personal identity of the active president, the title, “The President of the United States” is a global point of access that identifies the person in the office.

{|
|[[File:8.gif]]
|}

'''Check List''':
* Define a private static attribute in the “single instance” class.
* Define a public static accessor function in the class.
* Do “lazy initialization” (creation on first use) in the accessor function.
* Define all constructors to be protected or private.
* Clients may only use the accessor function to manipulate the Singleton.

'''Rules of thumb''':
* Abstract Factory, Builder, and Prototype can use Singleton in their implementation.
* Facade objects are often Singletons because only one Facade object is required.
* State objects are often Singletons.
* The advantage of Singleton over global variables is that you are absolutely sure of the number of instances when you use Singleton, and,
you can change your mind and manage any number of instances.
* The Singleton design pattern is one of the most inappropriately used patterns. Singletons are intended to be used when a class must have exactly one instance, no more, no less. Designers frequently use Singletons in a misguided attempt to replace global variables. A Singleton is, for intents and purposes, a global variable. The Singleton does not do away with the global; it merely renames it.
* When is Singleton unnecessary? Short answer: most of the time. Long answer: when it’s simpler to pass an object resource as a reference to the objects that need it, rather than letting objects access the resource globally.

== [http://c2.com/cgi/wiki?SingletonPattern Singleton explained on c2.com]==

'''Topics Covered''' :
Simulation of global variables, Appropriate Use of Singleton, Singleton in threaded environment

'''Summary''' :
This link firstly explains aspects like testing, creational logic,polymorphism involved in singleton pattern.It explains situations when singleton pattern can be used.It goes on to explain the anti-pattern of singletons simulating global variables and appropriate use of singleton in mutithreaded environment.

'''Problem of using Singleton in Multithreaded Environment''' :

static private synchronized Singleton instance_helper(){
_instance = new Singleton();
return _instance;
}

"_instance" can be null in the logic for multiple threads before instance_helper is called, leading to multiple instances being created

'''Solution for Singleton in Multithreaded Environment''' :

static private synchronized Singleton instance_helper()
{
if(flag)
{
_instance = new Singleton();
}
flag = false;
return _instance;
}

== [http://www.oodesign.com/singleton-pattern.html Singleton Applications]==

'''Topics Covered''' :
Motivation, Intent, Implementation, Applicability and Examples

'''Summary''' :
This link gives some extra information about applicability of Singleton in logger classes,configuration classes, accessing resources in shared environment,factories implemented as Singleton,Implementations and problems involved

'''Serialization''' :

If the Singleton class implements the java.io.Serializable interface, when a singleton is serialized and then deserialized more than once, there will be multiple instances of Singleton created. In order to avoid this the readResolve method should be implemented.

public class Singleton implements Serializable {
...
// This method is called immediately after an object of this class is deserialized.
// This method returns the singleton instance.
protected Object readResolve() {
return getInstance();
}
}

==[http://msdn.microsoft.com/en-us/library/ff650316.aspx Singleton Implementation in C#]==

'''Topics Covered''' :
Implementation in C#

'''Summary''' :
This link explains how to implement a singleton in C# both in static and threaded environment.

'''Static Initialization''':

One of the reasons Design Patterns [Gamma95] avoided static initialization is because the C++ specification left some ambiguity around the initialization order of static variables. Fortunately, the .NET Framework resolves this ambiguity through its handling of variable initialization:

public sealed class Singleton
{
private static readonly Singleton instance = new Singleton();
private Singleton(){}
public static Singleton Instance
{
get
{
return instance;
}
}
}

Implementing Singleton in C# results in the following benefits and liabilities:

'''Benefits''':
*The static initialization approach is possible because the .NET Framework explicitly defines how and when static variable initialization occurs.
*The Double-Check Locking idiom described earlier in "Multithreaded Singleton" is implemented correctly in the common language runtime.

'''Liabilities''':
If your multithreaded application requires explicit initialization, you have to take precautions to avoid threading issues.

== [http://bosy.dailydev.org/2007/08/refactor-singleton-out-of-your-code.html Refactor Singleton Out Of Your Code]==

'''Topics Covered''' :
Solution to refactor singleton

'''Summary''' :
Gang of Four mentions Singleton as an anti-pattern and not as a pattern. This Link provides a solution to refactor Singleton out of the code

'''Steps to refactor Singleton:'''
* Create simple interface for Registry with two simple methods - getter and setter for instance of class which is currently implemented as singleton.
public interface ISingletonRegistry {
SingletonClass getSingletonClass();
void setSingletonClass(SingletonClass singleton);
}

* Make SingletonClass's constructor public

* Then implement the interface as a simplest Registry design pattern implementation - SingletonRegistry.

public class SingletonRegistry implements ISingletonRegistry {
private static final SingletonRegistry INSTANCE = new SingletonRegistry();
private SingletonClass singleton;
public static ISingletonRegistry getInstance() {
return INSTANCE;
}
private SingletonRegistry() {
//this is the reason why the constructor should be public
singleton = new SingletonClass();
}
public SingletonClass getSingletonClass() {
return singleton;
}
public void setSingletonClass(SingletonClass singleton) {
this.singleton = singleton;
}
}

* Change getInstance method of SingletonClass to get instance from SingletonRegistry.
public static SingletonClass getInstance() {
return SingletonRegistry.getInstance().getSingletonClass();
}

* The method getInstance from SingletonClass disappears and all it's client classes uses SingletonRegistry to access SingletonClass.
public class Client {
public void clientMethod() {
SingletonRegistry.getInstance() .getSingletonClass().voidMethod("param");
Object object = SingletonRegistry.getInstance() .getSingletonClass().objectMethod("param");
}
}

* Delete INSTANCE constant from SingletonClass class.

* You can Extract Interface (Alt+Shift+T, E) from SingletonClass. Write just new interface name, select all methods from SingletonClass which you can extract into new interface and press OK. All references to SingletonClass will be refactored to references to your newly created interface.

And that is all. Now you have SingletonClass with totally same functionality but you are able to mock it, extend or replace by different implementation setting up your instance of SingletonClass to SingletonRegistry.

== [http://www.e-pedro.com/2010/05/refactoring-extracting-the-singleton-pattern/ Refactoring:Extracting the Singleton Pattern]==

'''Topics Covered''' :
Extracting the Singleton Pattern

'''Summary''' :
Here, the author demonstrates the refactoring of Singleton Pattern by means of an example of a Device Manger class. So the main class that will be changing is the DeviceManager. This class manages a collection of Devices (or a dictionary, to be more precise) and allows to set which is the active device and to get a device by id. Note that this last feature could be handled by the Devices collection, but we are taking advantage of the dictionary to make that look-up more efficient.

== [http://www.roseindia.net/designpattern/singleton_pattern.shtml Singleton Pattern Usage and Benefits]==

'''Topics Covered''' :
Usage, Benefits, Example

'''Summary''' :
This link describes about the benefits like instance control and usage in multithreaded environment.Singleton patterns are often used as global variables because the global variables permit allocation and initialization whenever required. They don't permit to pollute the global namespace with unnecessary variables.

'''Example''':
package singleton;
public class Logger {
private String fileName;
private Properties properties;
private Priority priority;
private Logger() {
logger = this;
}
public int getRegisteredLevel() {
int i = 0;
try {
InputStream inputstream = getClass().getResourceAsStream("Logger.properties");
properties.load(inputstream);
inputstream.close();
i = Integer.parseInt(properties.getProperty("logger.registeredlevel"));
if(i < 0 || i > 3)
i = 0;
}
catch(Exception exception) {
System.out.println("Logger: Failed in the getRegisteredLevel method");
exception.printStackTrace();
}
return i;
}
public static void initialize() {
logger = new Logger();
}
// singleton - pattern
private static Logger logger;
public static Logger getLogger() {
return logger;
}
}

== [http://www.dotnetobject.com/Thread-Benefits-of-Singleton-Pattern-and-Drawbacks-of-Singleton-Pattern Critique of the Singleton Pattern]==
'''Topics Covered''' :
Critique of the Singleton Pattern

'''Summary''' :
This link describes about the benefits like instance control and flexibility and drawbacks like overhead, development confusion and Object lifetime while using the singleton pattern.

==[http://www.ibm.com/developerworks/webservices/library/co-single/index.html Use Singletons Wisely]==

'''Topics Covered''' :
When to use, Moving away from Singletons, Aggregating Singletons

'''Summary''' :
The programming community discourages using global data and objects. Still, there are times when an application needs a single instance of a given class and a global point of access to that class. The general solution is the design pattern known as singletons. However, singletons are unnecessarily difficult to test and may make strong assumptions about the applications that will use them. In this article the author discusses strategies for avoiding the singleton pattern for that majority of cases where it is not appropriate. He also describes the properties of some classes that are truly singletons.

'''Aggregating Singletons: The Toolbox''':
Singleton abuse can be avoided by looking at the problem from a different angle. Suppose an application needs only one instance of a class and the application configures that class at startup: Why should the class itself be responsible for being a singleton? It seems quite logical for the application to take on this responsibility, since the application requires this kind of behavior. The application, not the component, should be the singleton. The application then makes an instance of the component available for any application-specific code to use. When an application uses several such components, it can aggregate them into what we have called a toolbox.
Put simply, the application's toolbox is a singleton that is responsible either for configuring itself or for allowing the application's startup mechanism to configure it. The general pattern of the Toolbox singleton is as shown in the example provided in this article
The Toolbox is itself a singleton, and it manages the lifetime of the various component instances. Either the application configures it, or it asks the application for configuration information in method initialize. Now the application can decide how many instances of which classes it requires. Changes in those decisions may affect application-specific code, but not reusable, infrastructure-level code. Moreover, testing infrastructure code is much easier, as those classes do not rely on the way in which any application may choose to use them.

== [http://stackoverflow.com/questions/4074154/when-should-the-singleton-pattern-not-be-used-besides-the-obvious When Not to Use Singleton]==

'''Topics Covered''' :
Appropriate Use of the Singleton Pattern

'''Summary''' :
The Gang of Four states that you'll want to use Singleton there must be exactly one instance of a class, and it must be accessible to clients from a well-known access point or when the sole instance should be extensible by subclassing, and clients should be able to use an extended instance without modifying their code.

=References=
http://en.wikipedia.org/wiki/Singleton_pattern

http://www.c-sharpcorner.com/UploadFile/SukeshMarla/learn-design-pattern-singleton-pattern/

http://www.c-sharpcorner.com/UploadFile/faraz.rasheed/SingletonPattern12052005063955AM/SingletonPattern.aspx

http://www.javaworld.com/javaworld/jw-04-2003/jw-0425-designpatterns.html

http://javapapers.com/design-patterns/singleton-pattern/

http://www.codeproject.com/Articles/307233/Singleton-Pattern-Positive-and-Negative-Aspects

http://sourcemaking.com/design_patterns/singleton

http://c2.com/cgi/wiki?SingletonPattern

http://www.oodesign.com/singleton-pattern.html

http://msdn.microsoft.com/en-us/library/ff650316.aspx

http://bosy.dailydev.org/2007/08/refactor-singleton-out-of-your-code.html

http://www.e-pedro.com/2010/05/refactoring-extracting-the-singleton-pattern

http://www.dotnetobject.com/Thread-Benefits-of-Singleton-Pattern-and-Drawbacks-of-Singleton-Pattern

http://www.roseindia.net/designpattern/singleton_pattern.shtml

http://www.ibm.com/developerworks/webservices/library/co-single/index.html

http://stackoverflow.com/questions/4074154/when-should-the-singleton-pattern-not-be-used-besides-the-obvious

CSC/ECE 517 Fall 2012/ch2b 2w53 iv

2012-11-19T20:59:11Z

Annice:

=Singleton, Directory of Sites=
== [http://en.wikipedia.org/wiki/Singleton_pattern Singleton on the Wikipedia] ==

'''Topics Covered''' :
Common uses, UML, Implementation, Example, Prototype based singleton, Example of use with factory method pattern

'''Summary''' :
This link firstly provides the basic definition of the singleton pattern as a design pattern that restricts the instantiation of a class to one object. Singleton patters are mostly used in Abstract Factory, Builder, and Prototype, and Facade patterns.

Both the UML representation of singleton where the same single instance is always returned and the implementation concerning the mechanism to access the singleton class member without creating a class object and a mechanism to persist the value of class members among the class objects. The link also points out that if a class has to realize a contract expressed by an interface, it really has to be a singleton.

Lazy initialization uses double-checking and eager initialization which always creates an instance.
For instance, Lazy initialization and Eager Initialization example codes are:
'''Lazy Initialization''':
public class SingletonDemo {
private static volatile SingletonDemo instance = null;
private SingletonDemo() {}
public static SingletonDemo getInstance() {
if (instance == null) {
synchronized (SingletonDemo .class){
if (instance == null) {
instance = new SingletonDemo ();
}
}
}
return instance;
}
}

'''Eager Initialization''':
public class Singleton {
private static final Singleton instance = new Singleton();
private Singleton() {}
public static Singleton getInstance() {
return instance;
}
}

It also talks about Prototype-based programming in which objects but not classes are used, a 'singleton' simply refers to an object without copies or that is not used as the prototype for any other object. Eg :->
Foo := Object clone
Foo clone := Foo

'''Drawbacks''' :
The pattern makes unit testing far more difficult as it introduces global state into an application. It should also be noted that this pattern reduces the potential for parallelism within a program, because access to the singleton in a multi-threaded context must be serialized.

== [http://www.c-sharpcorner.com/UploadFile/SukeshMarla/learn-design-pattern-singleton-pattern/ Learn Singleton-design-Pattern]==

'''Topics Covered''' :
Definition, When to use, how to create, Sharing across all users, Sharing across a request, Sharing across a single user

'''Summary''' :
This article explains what Singleton pattern is, what kind of problem it generally solves and how should it be implemented in ASP.NET. The Singleton pattern which ensures that only one instance of a given object can exist at a context solves problems related to object creation and hence is a type of creational pattern.

{|
|[[File:3.jpg|x300px]]
|}

It can be used in a class that wraps the settings related to an application. In other words, whenever we want something to be shared across multiple locations, we use a singleton pattern. In order to create a Singleton pattern, we can render the constructor private so that no user can create a new instance outside the class, that way ensuring only one instance of the objects always exists. In that case, we also need to create a static method that returns the single object.

Singleton patterns in ASP.NET are implemented by using static objects which maintain their values and reside in the memory as long as the application which contains it does. The sharing can occur across users, or requests or across a single user.

== [http://www.c-sharpcorner.com/UploadFile/faraz.rasheed/SingletonPattern12052005063955AM/SingletonPattern.aspx Singleton - Creational Design Pattern]==

'''Topics Covered''' :
Intent, Description, An Example, Implementation, Benefits

'''Summary''' :
It firstly talks about the intent behind singleton design pattern, in that there is a need to have a class that can be instantiated only once.
Then, it describes two solutions for implementing the singleton class.
In the first, there should be only one shared object and reference to that shared object should be available through a static method GetInstance() while the constructor is private.
The second solution expects the constructor to be public but once an object has been instantiated, an exception should be thrown for each successive constructor call.

{|
|[[File:1.gif|x300px]]
|}

The code for each case is given as follows:

'''Case 1''' :
class Singleton
{
private static Singleton instance;
private static int numOfReference;
private string code;
private Singleton()
{
numOfReference = 0;
code = "Maasoom Faraz";
}
public static Singleton GetInstance()
{
if(instance == null)
{
instance = new Singleton();
}
numOfReference++;
return instance;
}
public static int Reference
{
get { return numOfReference; }
}
public string Code
{
get { return code; }
set { code = value;}
}
}

The constructor is made private and used to initialize the numOfReference and default value of code. GetInstance() method checks the instance, if it is null then it assign it an instance of Singleton otherwise return the old reference.

'''Case 2''' :
class Singleton2
{
private static int numOfInstance = 0;
public Singleton2()
{
if(numOfInstance == 0)
{
Console.WriteLine("\r\nCreating First Object of Singleton2 class...");
numOfInstance++;
}
else
{
throw new Exception("This class is Singleton,
+ so only one object of it can be instantiated.");
}
}
}

Here we make the constructor public and use a private field numOfInstance which is incremented for each constructor call. If numOfInstance is zero (no object is yet instantiated), a new object is allowed to made. But, if this value is not zero (there is already an object of Singleton2 class, an exception is thrown.

\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

== [http://c2.com/cgi/wiki?SingletonPattern Singleton explained on c2.com]==

'''Topics Covered''' :
Simulation of global variables, Appropriate Use of Singleton, Singleton in threaded environment

'''Summary''' :
This link firstly explains aspects like testing, creational logic,polymorphism involved in singleton pattern.It explains situations when singleton pattern can be used.It goes on to explain the anti-pattern of singletons simulating global variables and appropriate use of singleton in mutithreaded environment.

'''Problem of using Singleton in Multithreaded Environment''' :

static private synchronized Singleton instance_helper(){
_instance = new Singleton();
return _instance;
}

"_instance" can be null in the logic for multiple threads before instance_helper is called, leading to multiple instances being created

'''Solution for Singleton in Multithreaded Environment''' :

static private synchronized Singleton instance_helper()
{
if(flag)
{
_instance = new Singleton();
}
flag = false;
return _instance;
}

== [http://www.oodesign.com/singleton-pattern.html Singleton Applications]==

'''Topics Covered''' :
Motivation, Intent, Implementation, Applicability and Examples

'''Summary''' :
This link gives some extra information about applicability of Singleton in logger classes,configuration classes, accessing resources in shared environment,factories implemented as Singleton,Implementations and problems involved

'''Serialization''' :

If the Singleton class implements the java.io.Serializable interface, when a singleton is serialized and then deserialized more than once, there will be multiple instances of Singleton created. In order to avoid this the readResolve method should be implemented.

public class Singleton implements Serializable {
...
// This method is called immediately after an object of this class is deserialized.
// This method returns the singleton instance.
protected Object readResolve() {
return getInstance();
}
}

==[http://msdn.microsoft.com/en-us/library/ff650316.aspx Singleton Implementation in C#]==

'''Topics Covered''' :
Implementation in C#

'''Summary''' :
This link explains how to implement a singleton in C# both in static and threaded environment.

'''Static Initialization''':

One of the reasons Design Patterns [Gamma95] avoided static initialization is because the C++ specification left some ambiguity around the initialization order of static variables. Fortunately, the .NET Framework resolves this ambiguity through its handling of variable initialization:

public sealed class Singleton
{
private static readonly Singleton instance = new Singleton();
private Singleton(){}
public static Singleton Instance
{
get
{
return instance;
}
}
}

Implementing Singleton in C# results in the following benefits and liabilities:

'''Benefits''':
*The static initialization approach is possible because the .NET Framework explicitly defines how and when static variable initialization occurs.
*The Double-Check Locking idiom described earlier in "Multithreaded Singleton" is implemented correctly in the common language runtime.

'''Liabilities''':
If your multithreaded application requires explicit initialization, you have to take precautions to avoid threading issues.

== [http://bosy.dailydev.org/2007/08/refactor-singleton-out-of-your-code.html Refactor Singleton Out Of Your Code]==

'''Topics Covered''' :
Solution to refactor singleton

'''Summary''' :
Gang of Four mentions Singleton as an anti-pattern and not as a pattern. This Link provides a solution to refactor Singleton out of the code

'''Steps to refactor Singleton:'''
* Create simple interface for Registry with two simple methods - getter and setter for instance of class which is currently implemented as singleton.
public interface ISingletonRegistry {
SingletonClass getSingletonClass();
void setSingletonClass(SingletonClass singleton);
}

* Make SingletonClass's constructor public

* Then implement the interface as a simplest Registry design pattern implementation - SingletonRegistry.

public class SingletonRegistry implements ISingletonRegistry {
private static final SingletonRegistry INSTANCE = new SingletonRegistry();
private SingletonClass singleton;
public static ISingletonRegistry getInstance() {
return INSTANCE;
}
private SingletonRegistry() {
//this is the reason why the constructor should be public
singleton = new SingletonClass();
}
public SingletonClass getSingletonClass() {
return singleton;
}
public void setSingletonClass(SingletonClass singleton) {
this.singleton = singleton;
}
}

* Change getInstance method of SingletonClass to get instance from SingletonRegistry.
public static SingletonClass getInstance() {
return SingletonRegistry.getInstance().getSingletonClass();
}

* The method getInstance from SingletonClass disappears and all it's client classes uses SingletonRegistry to access SingletonClass.
public class Client {
public void clientMethod() {
SingletonRegistry.getInstance() .getSingletonClass().voidMethod("param");
Object object = SingletonRegistry.getInstance() .getSingletonClass().objectMethod("param");
}
}

* Delete INSTANCE constant from SingletonClass class.

* You can Extract Interface (Alt+Shift+T, E) from SingletonClass. Write just new interface name, select all methods from SingletonClass which you can extract into new interface and press OK. All references to SingletonClass will be refactored to references to your newly created interface.

And that is all. Now you have SingletonClass with totally same functionality but you are able to mock it, extend or replace by different implementation setting up your instance of SingletonClass to SingletonRegistry.

== [http://www.e-pedro.com/2010/05/refactoring-extracting-the-singleton-pattern/ Refactoring:Extracting the Singleton Pattern]==

'''Topics Covered''' :
Extracting the Singleton Pattern

'''Summary''' :
Here, the author demonstrates the refactoring of Singleton Pattern by means of an example of a Device Manger class. So the main class that will be changing is the DeviceManager. This class manages a collection of Devices (or a dictionary, to be more precise) and allows to set which is the active device and to get a device by id. Note that this last feature could be handled by the Devices collection, but we are taking advantage of the dictionary to make that look-up more efficient.

== [http://www.roseindia.net/designpattern/singleton_pattern.shtml Singleton Pattern Usage and Benefits]==

'''Topics Covered''' :
Usage, Benefits, Example

'''Summary''' :
This link describes about the benefits like instance control and usage in multithreaded environment.Singleton patterns are often used as global variables because the global variables permit allocation and initialization whenever required. They don't permit to pollute the global namespace with unnecessary variables.

'''Example''':
package singleton;
public class Logger {
private String fileName;
private Properties properties;
private Priority priority;
private Logger() {
logger = this;
}
public int getRegisteredLevel() {
int i = 0;
try {
InputStream inputstream = getClass().getResourceAsStream("Logger.properties");
properties.load(inputstream);
inputstream.close();
i = Integer.parseInt(properties.getProperty("logger.registeredlevel"));
if(i < 0 || i > 3)
i = 0;
}
catch(Exception exception) {
System.out.println("Logger: Failed in the getRegisteredLevel method");
exception.printStackTrace();
}
return i;
}
public static void initialize() {
logger = new Logger();
}
// singleton - pattern
private static Logger logger;
public static Logger getLogger() {
return logger;
}
}

== [http://www.dotnetobject.com/Thread-Benefits-of-Singleton-Pattern-and-Drawbacks-of-Singleton-Pattern Critique of the Singleton Pattern]==
'''Topics Covered''' :
Critique of the Singleton Pattern

'''Summary''' :
This link describes about the benefits like instance control and flexibility and drawbacks like overhead, development confusion and Object lifetime while using the singleton pattern.

==[http://www.ibm.com/developerworks/webservices/library/co-single/index.html Use Singletons Wisely]==

'''Topics Covered''' :
When to use, Moving away from Singletons, Aggregating Singletons

'''Summary''' :
The programming community discourages using global data and objects. Still, there are times when an application needs a single instance of a given class and a global point of access to that class. The general solution is the design pattern known as singletons. However, singletons are unnecessarily difficult to test and may make strong assumptions about the applications that will use them. In this article the author discusses strategies for avoiding the singleton pattern for that majority of cases where it is not appropriate. He also describes the properties of some classes that are truly singletons.

'''Aggregating Singletons: The Toolbox''':
Singleton abuse can be avoided by looking at the problem from a different angle. Suppose an application needs only one instance of a class and the application configures that class at startup: Why should the class itself be responsible for being a singleton? It seems quite logical for the application to take on this responsibility, since the application requires this kind of behavior. The application, not the component, should be the singleton. The application then makes an instance of the component available for any application-specific code to use. When an application uses several such components, it can aggregate them into what we have called a toolbox.
Put simply, the application's toolbox is a singleton that is responsible either for configuring itself or for allowing the application's startup mechanism to configure it. The general pattern of the Toolbox singleton is as shown in the example provided in this article
The Toolbox is itself a singleton, and it manages the lifetime of the various component instances. Either the application configures it, or it asks the application for configuration information in method initialize. Now the application can decide how many instances of which classes it requires. Changes in those decisions may affect application-specific code, but not reusable, infrastructure-level code. Moreover, testing infrastructure code is much easier, as those classes do not rely on the way in which any application may choose to use them.

== [http://stackoverflow.com/questions/4074154/when-should-the-singleton-pattern-not-be-used-besides-the-obvious When Not to Use Singleton]==

'''Topics Covered''' :
Appropriate Use of the Singleton Pattern

'''Summary''' :
The Gang of Four states that you'll want to use Singleton there must be exactly one instance of a class, and it must be accessible to clients from a well-known access point or when the sole instance should be extensible by subclassing, and clients should be able to use an extended instance without modifying their code.

=References=
http://en.wikipedia.org/wiki/Singleton_pattern

http://www.c-sharpcorner.com/UploadFile/SukeshMarla/learn-design-pattern-singleton-pattern/

http://www.c-sharpcorner.com/UploadFile/faraz.rasheed/SingletonPattern12052005063955AM/SingletonPattern.aspx

http://www.javaworld.com/javaworld/jw-04-2003/jw-0425-designpatterns.html

http://javapapers.com/design-patterns/singleton-pattern/

http://www.codeproject.com/Articles/307233/Singleton-Pattern-Positive-and-Negative-Aspects

http://sourcemaking.com/design_patterns/singleton

http://c2.com/cgi/wiki?SingletonPattern

http://www.oodesign.com/singleton-pattern.html

http://msdn.microsoft.com/en-us/library/ff650316.aspx

http://bosy.dailydev.org/2007/08/refactor-singleton-out-of-your-code.html

http://www.e-pedro.com/2010/05/refactoring-extracting-the-singleton-pattern

http://www.dotnetobject.com/Thread-Benefits-of-Singleton-Pattern-and-Drawbacks-of-Singleton-Pattern

http://www.roseindia.net/designpattern/singleton_pattern.shtml

http://www.ibm.com/developerworks/webservices/library/co-single/index.html

http://stackoverflow.com/questions/4074154/when-should-the-singleton-pattern-not-be-used-besides-the-obvious

CSC/ECE 517 Fall 2012/ch2b 2w53 iv

2012-11-19T20:57:34Z

Annice:

=Singleton, Directory of Sites=
== [http://en.wikipedia.org/wiki/Singleton_pattern Singleton on the Wikipedia] ==

'''Topics Covered''' :
Common uses, UML, Implementation, Example, Prototype based singleton, Example of use with factory method pattern

'''Summary''' :
This link firstly provides the basic definition of the singleton pattern as a design pattern that restricts the instantiation of a class to one object. Singleton patters are mostly used in Abstract Factory, Builder, and Prototype, and Facade patterns.

Both the UML representation of singleton where the same single instance is always returned and the implementation concerning the mechanism to access the singleton class member without creating a class object and a mechanism to persist the value of class members among the class objects. The link also points out that if a class has to realize a contract expressed by an interface, it really has to be a singleton.

Lazy initialization uses double-checking and eager initialization which always creates an instance.
For instance, Lazy initialization and Eager Initialization example codes are:
'''Lazy Initialization''':
public class SingletonDemo {
private static volatile SingletonDemo instance = null;
private SingletonDemo() {}
public static SingletonDemo getInstance() {
if (instance == null) {
synchronized (SingletonDemo .class){
if (instance == null) {
instance = new SingletonDemo ();
}
}
}
return instance;
}
}

'''Eager Initialization''':
public class Singleton {
private static final Singleton instance = new Singleton();
private Singleton() {}
public static Singleton getInstance() {
return instance;
}
}

It also talks about Prototype-based programming in which objects but not classes are used, a 'singleton' simply refers to an object without copies or that is not used as the prototype for any other object. Eg :->
Foo := Object clone
Foo clone := Foo

'''Drawbacks''' :
The pattern makes unit testing far more difficult as it introduces global state into an application. It should also be noted that this pattern reduces the potential for parallelism within a program, because access to the singleton in a multi-threaded context must be serialized.

== [http://www.c-sharpcorner.com/UploadFile/SukeshMarla/learn-design-pattern-singleton-pattern/ Learn Singleton-design-Pattern]==

'''Topics Covered''' :
Definition, When to use, how to create, Sharing across all users, Sharing across a request, Sharing across a single user

'''Summary''' :
This article explains what Singleton pattern is, what kind of problem it generally solves and how should it be implemented in ASP.NET. The Singleton pattern which ensures that only one instance of a given object can exist at a context solves problems related to object creation and hence is a type of creational pattern.

{|
|[[File:3.jpg|x300px]]
|}

It can be used in a class that wraps the settings related to an application. In other words, whenever we want something to be shared across multiple locations, we use a singleton pattern. In order to create a Singleton pattern, we can render the constructor private so that no user can create a new instance outside the class, that way ensuring only one instance of the objects always exists. In that case, we also need to create a static method that returns the single object.

Singleton patterns in ASP.NET are implemented by using static objects which maintain their values and reside in the memory as long as the application which contains it does. The sharing can occur across users, or requests or across a single user.

== [http://www.c-sharpcorner.com/UploadFile/faraz.rasheed/SingletonPattern12052005063955AM/SingletonPattern.aspx Singleton - Creational Design Pattern]==

'''Topics Covered''' :
Intent, Description, An Example, Implementation, Benefits

'''Summary''' :
It firstly talks about the intent behind singleton design pattern, in that there is a need to have a class that can be instantiated only once.
Then, it describes two solutions for implementing the singleton class.
In the first, there should be only one shared object and reference to that shared object should be available through a static method GetInstance() while the constructor is private.
The second solution expects the constructor to be public but once an object has been instantiated, an exception should be thrown for each successive constructor call.

{|
|[[File:1.gif|x300px]]
|}

The code for each case is given as follows:

'''Case 1''' :
class Singleton
{
private static Singleton instance;
private static int numOfReference;
private string code;
private Singleton()
{
numOfReference = 0;
code = "Maasoom Faraz";
}
public static Singleton GetInstance()
{
if(instance == null)
{
instance = new Singleton();
}
numOfReference++;
return instance;
}
public static int Reference
{
get { return numOfReference; }
}
public string Code
{
get { return code; }
set { code = value;}
}
}

The constructor is made private and used to initialize the numOfReference and default value of code. GetInstance() method checks the instance, if it is null then it assign it an instance of Singleton otherwise return the old reference.

'''Case 2''' :
class Singleton2
{
private static int numOfInstance = 0;
public Singleton2()
{
if(numOfInstance == 0)
{
Console.WriteLine("\r\nCreating First Object of Singleton2 class...");
numOfInstance++;
}
else
{
throw new Exception("This class is Singleton,
+ so only one object of it can be instantiated.");
}
}
}

Here we make the constructor public and use a private field numOfInstance which is incremented for each constructor call. If numOfInstance is zero (no object is yet instantiated), a new object is allowed to made. But, if this value is not zero (there is already an object of Singleton2 class, an exception is thrown.

\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

== [http://c2.com/cgi/wiki?SingletonPattern Singleton explained on c2.com]==

'''Topics Covered''' :
Simulation of global variables, Appropriate Use of Singleton, Singleton in threaded environment

'''Summary''' :
This link firstly explains aspects like testing, creational logic,polymorphism involved in singleton pattern.It explains situations when singleton pattern can be used.It goes on to explain the anti-pattern of singletons simulating global variables and appropriate use of singleton in mutithreaded environment.

'''Problem of using Singleton in Multithreaded Environment''' :

static private synchronized Singleton instance_helper(){
_instance = new Singleton();
return _instance;
}

"_instance" can be null in the logic for multiple threads before instance_helper is called, leading to multiple instances being created

'''Solution for Singleton in Multithreaded Environment''' :

static private synchronized Singleton instance_helper()
{
if(flag)
{
_instance = new Singleton();
}
flag = false;
return _instance;
}

== [http://www.oodesign.com/singleton-pattern.html Singleton Applications]==

'''Topics Covered''' :
Motivation, Intent, Implementation, Applicability and Examples

'''Summary''' :
This link gives some extra information about applicability of Singleton in logger classes,configuration classes, accessing resources in shared environment,factories implemented as Singleton,Implementations and problems involved

'''Serialization''' :

If the Singleton class implements the java.io.Serializable interface, when a singleton is serialized and then deserialized more than once, there will be multiple instances of Singleton created. In order to avoid this the readResolve method should be implemented.

public class Singleton implements Serializable {
...
// This method is called immediately after an object of this class is deserialized.
// This method returns the singleton instance.
protected Object readResolve() {
return getInstance();
}
}

==[http://msdn.microsoft.com/en-us/library/ff650316.aspx Singleton Implementation in C#]==

'''Topics Covered''' :
Implementation in C#

'''Summary''' :
This link explains how to implement a singleton in C# both in static and threaded environment.

'''Static Initialization''':

One of the reasons Design Patterns [Gamma95] avoided static initialization is because the C++ specification left some ambiguity around the initialization order of static variables. Fortunately, the .NET Framework resolves this ambiguity through its handling of variable initialization:

public sealed class Singleton
{
private static readonly Singleton instance = new Singleton();
private Singleton(){}
public static Singleton Instance
{
get
{
return instance;
}
}
}

Implementing Singleton in C# results in the following benefits and liabilities:

'''Benefits''':
*The static initialization approach is possible because the .NET Framework explicitly defines how and when static variable initialization occurs.
*The Double-Check Locking idiom described earlier in "Multithreaded Singleton" is implemented correctly in the common language runtime.

'''Liabilities''':
If your multithreaded application requires explicit initialization, you have to take precautions to avoid threading issues.

== [http://bosy.dailydev.org/2007/08/refactor-singleton-out-of-your-code.html Refactor Singleton Out Of Your Code]==

'''Topics Covered''' :
Solution to refactor singleton

'''Summary''' :
Gang of Four mentions Singleton as an anti-pattern and not as a pattern. This Link provides a solution to refactor Singleton out of the code

'''Steps to refactor Singleton:'''
* Create simple interface for Registry with two simple methods - getter and setter for instance of class which is currently implemented as singleton.
public interface ISingletonRegistry {
SingletonClass getSingletonClass();
void setSingletonClass(SingletonClass singleton);
}

* Make SingletonClass's constructor public

* Then implement the interface as a simplest Registry design pattern implementation - SingletonRegistry.

public class SingletonRegistry implements ISingletonRegistry {
private static final SingletonRegistry INSTANCE = new SingletonRegistry();
private SingletonClass singleton;
public static ISingletonRegistry getInstance() {
return INSTANCE;
}
private SingletonRegistry() {
//this is the reason why the constructor should be public
singleton = new SingletonClass();
}
public SingletonClass getSingletonClass() {
return singleton;
}
public void setSingletonClass(SingletonClass singleton) {
this.singleton = singleton;
}
}

* Change getInstance method of SingletonClass to get instance from SingletonRegistry.
public static SingletonClass getInstance() {
return SingletonRegistry.getInstance().getSingletonClass();
}

* The method getInstance from SingletonClass disappears and all it's client classes uses SingletonRegistry to access SingletonClass.
public class Client {
public void clientMethod() {
SingletonRegistry.getInstance() .getSingletonClass().voidMethod("param");
Object object = SingletonRegistry.getInstance() .getSingletonClass().objectMethod("param");
}
}

* Delete INSTANCE constant from SingletonClass class.

* You can Extract Interface (Alt+Shift+T, E) from SingletonClass. Write just new interface name, select all methods from SingletonClass which you can extract into new interface and press OK. All references to SingletonClass will be refactored to references to your newly created interface.

And that is all. Now you have SingletonClass with totally same functionality but you are able to mock it, extend or replace by different implementation setting up your instance of SingletonClass to SingletonRegistry.

== [http://www.e-pedro.com/2010/05/refactoring-extracting-the-singleton-pattern/ Refactoring:Extracting the Singleton Pattern]==

'''Topics Covered''' :
Extracting the Singleton Pattern

'''Summary''' :
Here, the author demonstrates the refactoring of Singleton Pattern by means of an example of a Device Manger class. So the main class that will be changing is the DeviceManager. This class manages a collection of Devices (or a dictionary, to be more precise) and allows to set which is the active device and to get a device by id. Note that this last feature could be handled by the Devices collection, but we are taking advantage of the dictionary to make that look-up more efficient.

== [http://www.roseindia.net/designpattern/singleton_pattern.shtml Singleton Pattern Usage and Benefits]==

'''Topics Covered''' :
Usage, Benefits, Example

'''Summary''' :
This link describes about the benefits like instance control and usage in multithreaded environment.Singleton patterns are often used as global variables because the global variables permit allocation and initialization whenever required. They don't permit to pollute the global namespace with unnecessary variables.

'''Example''':
package singleton;
public class Logger {
private String fileName;
private Properties properties;
private Priority priority;
private Logger() {
logger = this;
}
public int getRegisteredLevel() {
int i = 0;
try {
InputStream inputstream = getClass().getResourceAsStream("Logger.properties");
properties.load(inputstream);
inputstream.close();
i = Integer.parseInt(properties.getProperty("logger.registeredlevel"));
if(i < 0 || i > 3)
i = 0;
}
catch(Exception exception) {
System.out.println("Logger: Failed in the getRegisteredLevel method");
exception.printStackTrace();
}
return i;
}
public static void initialize() {
logger = new Logger();
}
// singleton - pattern
private static Logger logger;
public static Logger getLogger() {
return logger;
}
}

== [http://www.dotnetobject.com/Thread-Benefits-of-Singleton-Pattern-and-Drawbacks-of-Singleton-Pattern Critique of the Singleton Pattern]==
'''Topics Covered''' :
Critique of the Singleton Pattern

'''Summary''' :
This link describes about the benefits like instance control and flexibility and drawbacks like overhead, development confusion and Object lifetime while using the singleton pattern.

==[http://www.ibm.com/developerworks/webservices/library/co-single/index.html Use Singletons Wisely]==

'''Topics Covered''' :
When to use, Moving away from Singletons, Aggregating Singletons

'''Summary''' :
The programming community discourages using global data and objects. Still, there are times when an application needs a single instance of a given class and a global point of access to that class. The general solution is the design pattern known as singletons. However, singletons are unnecessarily difficult to test and may make strong assumptions about the applications that will use them. In this article the author discusses strategies for avoiding the singleton pattern for that majority of cases where it is not appropriate. He also describes the properties of some classes that are truly singletons.

'''Aggregating Singletons: The Toolbox''':
Singleton abuse can be avoided by looking at the problem from a different angle. Suppose an application needs only one instance of a class and the application configures that class at startup: Why should the class itself be responsible for being a singleton? It seems quite logical for the application to take on this responsibility, since the application requires this kind of behavior. The application, not the component, should be the singleton. The application then makes an instance of the component available for any application-specific code to use. When an application uses several such components, it can aggregate them into what we have called a toolbox.
Put simply, the application's toolbox is a singleton that is responsible either for configuring itself or for allowing the application's startup mechanism to configure it. The general pattern of the Toolbox singleton is as shown in the example provided in this article
The Toolbox is itself a singleton, and it manages the lifetime of the various component instances. Either the application configures it, or it asks the application for configuration information in method initialize. Now the application can decide how many instances of which classes it requires. Changes in those decisions may affect application-specific code, but not reusable, infrastructure-level code. Moreover, testing infrastructure code is much easier, as those classes do not rely on the way in which any application may choose to use them.

== [http://stackoverflow.com/questions/4074154/when-should-the-singleton-pattern-not-be-used-besides-the-obvious When Not to Use Singleton]==

'''Topics Covered''' :
Appropriate Use of the Singleton Pattern

'''Summary''' :
The Gang of Four states that you'll want to use Singleton there must be exactly one instance of a class, and it must be accessible to clients from a well-known access point or when the sole instance should be extensible by subclassing, and clients should be able to use an extended instance without modifying their code.

=References=
http://en.wikipedia.org/wiki/Singleton_pattern
http://www.c-sharpcorner.com/UploadFile/SukeshMarla/learn-design-pattern-singleton-pattern/
http://www.c-sharpcorner.com/UploadFile/faraz.rasheed/SingletonPattern12052005063955AM/SingletonPattern.aspx
http://www.javaworld.com/javaworld/jw-04-2003/jw-0425-designpatterns.html
http://javapapers.com/design-patterns/singleton-pattern/
http://www.codeproject.com/Articles/307233/Singleton-Pattern-Positive-and-Negative-Aspects
http://sourcemaking.com/design_patterns/singleton
http://c2.com/cgi/wiki?SingletonPattern
http://www.oodesign.com/singleton-pattern.html
http://msdn.microsoft.com/en-us/library/ff650316.aspx
http://bosy.dailydev.org/2007/08/refactor-singleton-out-of-your-code.html
http://www.e-pedro.com/2010/05/refactoring-extracting-the-singleton-pattern/
http://www.dotnetobject.com/Thread-Benefits-of-Singleton-Pattern-and-Drawbacks-of-Singleton-Pattern
http://www.roseindia.net/designpattern/singleton_pattern.shtml
http://www.ibm.com/developerworks/webservices/library/co-single/index.html
http://stackoverflow.com/questions/4074154/when-should-the-singleton-pattern-not-be-used-besides-the-obvious

CSC/ECE 517 Fall 2012/ch2b 2w53 iv

2012-11-19T20:53:05Z

Annice:

= [http://en.wikipedia.org/wiki/Singleton_pattern Singleton on the Wikipedia] =

'''Topics Covered''' :
Common uses, UML, Implementation, Example, Prototype based singleton, Example of use with factory method pattern

'''Summary''' :
This link firstly provides the basic definition of the singleton pattern as a design pattern that restricts the instantiation of a class to one object. Singleton patters are mostly used in Abstract Factory, Builder, and Prototype, and Facade patterns.

Both the UML representation of singleton where the same single instance is always returned and the implementation concerning the mechanism to access the singleton class member without creating a class object and a mechanism to persist the value of class members among the class objects. The link also points out that if a class has to realize a contract expressed by an interface, it really has to be a singleton.

Lazy initialization uses double-checking and eager initialization which always creates an instance.
For instance, Lazy initialization and Eager Initialization example codes are:
'''Lazy Initialization''':
public class SingletonDemo {
private static volatile SingletonDemo instance = null;
private SingletonDemo() {}
public static SingletonDemo getInstance() {
if (instance == null) {
synchronized (SingletonDemo .class){
if (instance == null) {
instance = new SingletonDemo ();
}
}
}
return instance;
}
}

'''Eager Initialization''':
public class Singleton {
private static final Singleton instance = new Singleton();
private Singleton() {}
public static Singleton getInstance() {
return instance;
}
}

It also talks about Prototype-based programming in which objects but not classes are used, a 'singleton' simply refers to an object without copies or that is not used as the prototype for any other object. Eg :->
Foo := Object clone
Foo clone := Foo

'''Drawbacks''' :
The pattern makes unit testing far more difficult as it introduces global state into an application. It should also be noted that this pattern reduces the potential for parallelism within a program, because access to the singleton in a multi-threaded context must be serialized.

= [http://www.c-sharpcorner.com/UploadFile/SukeshMarla/learn-design-pattern-singleton-pattern/ Learn Singleton-design-Pattern]=

'''Topics Covered''' :
Definition, When to use, how to create, Sharing across all users, Sharing across a request, Sharing across a single user

'''Summary''' :
This article explains what Singleton pattern is, what kind of problem it generally solves and how should it be implemented in ASP.NET. The Singleton pattern which ensures that only one instance of a given object can exist at a context solves problems related to object creation and hence is a type of creational pattern.

{|
|[[File:3.jpg|x300px]]
|}

It can be used in a class that wraps the settings related to an application. In other words, whenever we want something to be shared across multiple locations, we use a singleton pattern. In order to create a Singleton pattern, we can render the constructor private so that no user can create a new instance outside the class, that way ensuring only one instance of the objects always exists. In that case, we also need to create a static method that returns the single object.

Singleton patterns in ASP.NET are implemented by using static objects which maintain their values and reside in the memory as long as the application which contains it does. The sharing can occur across users, or requests or across a single user.

= [http://www.c-sharpcorner.com/UploadFile/faraz.rasheed/SingletonPattern12052005063955AM/SingletonPattern.aspx Singleton - Creational Design Pattern]=

'''Topics Covered''' :
Intent, Description, An Example, Implementation, Benefits

'''Summary''' :
It firstly talks about the intent behind singleton design pattern, in that there is a need to have a class that can be instantiated only once.
Then, it describes two solutions for implementing the singleton class.
In the first, there should be only one shared object and reference to that shared object should be available through a static method GetInstance() while the constructor is private.
The second solution expects the constructor to be public but once an object has been instantiated, an exception should be thrown for each successive constructor call.

{|
|[[File:1.gif|x300px]]
|}

The code for each case is given as follows:

'''Case 1''' :
class Singleton
{
private static Singleton instance;
private static int numOfReference;
private string code;
private Singleton()
{
numOfReference = 0;
code = "Maasoom Faraz";
}
public static Singleton GetInstance()
{
if(instance == null)
{
instance = new Singleton();
}
numOfReference++;
return instance;
}
public static int Reference
{
get { return numOfReference; }
}
public string Code
{
get { return code; }
set { code = value;}
}
}

The constructor is made private and used to initialize the numOfReference and default value of code. GetInstance() method checks the instance, if it is null then it assign it an instance of Singleton otherwise return the old reference.

'''Case 2''' :
class Singleton2
{
private static int numOfInstance = 0;
public Singleton2()
{
if(numOfInstance == 0)
{
Console.WriteLine("\r\nCreating First Object of Singleton2 class...");
numOfInstance++;
}
else
{
throw new Exception("This class is Singleton,
+ so only one object of it can be instantiated.");
}
}
}

Here we make the constructor public and use a private field numOfInstance which is incremented for each constructor call. If numOfInstance is zero (no object is yet instantiated), a new object is allowed to made. But, if this value is not zero (there is already an object of Singleton2 class, an exception is thrown.

\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

= [http://c2.com/cgi/wiki?SingletonPattern Singleton explained on c2.com]=

'''Topics Covered''' :
Simulation of global variables, Appropriate Use of Singleton, Singleton in threaded environment

'''Summary''' :
This link firstly explains aspects like testing, creational logic,polymorphism involved in singleton pattern.It explains situations when singleton pattern can be used.It goes on to explain the anti-pattern of singletons simulating global variables and appropriate use of singleton in mutithreaded environment.

'''Problem of using Singleton in Multithreaded Environment''' :

static private synchronized Singleton instance_helper(){
_instance = new Singleton();
return _instance;
}

"_instance" can be null in the logic for multiple threads before instance_helper is called, leading to multiple instances being created

'''Solution for Singleton in Multithreaded Environment''' :

static private synchronized Singleton instance_helper()
{
if(flag)
{
_instance = new Singleton();
}
flag = false;
return _instance;
}

= [http://www.oodesign.com/singleton-pattern.html Singleton Applications]=

'''Topics Covered''' :
Motivation, Intent, Implementation, Applicability and Examples

'''Summary''' :
This link gives some extra information about applicability of Singleton in logger classes,configuration classes, accessing resources in shared environment,factories implemented as Singleton,Implementations and problems involved

'''Serialization''' :

If the Singleton class implements the java.io.Serializable interface, when a singleton is serialized and then deserialized more than once, there will be multiple instances of Singleton created. In order to avoid this the readResolve method should be implemented.

public class Singleton implements Serializable {
...
// This method is called immediately after an object of this class is deserialized.
// This method returns the singleton instance.
protected Object readResolve() {
return getInstance();
}
}

=[http://msdn.microsoft.com/en-us/library/ff650316.aspx Singleton Implementation in C#]=

'''Topics Covered''' :
Implementation in C#

'''Summary''' :
This link explains how to implement a singleton in C# both in static and threaded environment.

'''Static Initialization''':

One of the reasons Design Patterns [Gamma95] avoided static initialization is because the C++ specification left some ambiguity around the initialization order of static variables. Fortunately, the .NET Framework resolves this ambiguity through its handling of variable initialization:

public sealed class Singleton
{
private static readonly Singleton instance = new Singleton();
private Singleton(){}
public static Singleton Instance
{
get
{
return instance;
}
}
}

Implementing Singleton in C# results in the following benefits and liabilities:

'''Benefits''':
*The static initialization approach is possible because the .NET Framework explicitly defines how and when static variable initialization occurs.
*The Double-Check Locking idiom described earlier in "Multithreaded Singleton" is implemented correctly in the common language runtime.

'''Liabilities''':
If your multithreaded application requires explicit initialization, you have to take precautions to avoid threading issues.

= [http://bosy.dailydev.org/2007/08/refactor-singleton-out-of-your-code.html Refactor Singleton Out Of Your Code]=

'''Topics Covered''' :
Solution to refactor singleton

'''Summary''' :
Gang of Four mentions Singleton as an anti-pattern and not as a pattern. This Link provides a solution to refactor Singleton out of the code

'''Steps to refactor Singleton:'''
* Create simple interface for Registry with two simple methods - getter and setter for instance of class which is currently implemented as singleton.
public interface ISingletonRegistry {
SingletonClass getSingletonClass();
void setSingletonClass(SingletonClass singleton);
}

* Make SingletonClass's constructor public

* Then implement the interface as a simplest Registry design pattern implementation - SingletonRegistry.

public class SingletonRegistry implements ISingletonRegistry {
private static final SingletonRegistry INSTANCE = new SingletonRegistry();
private SingletonClass singleton;
public static ISingletonRegistry getInstance() {
return INSTANCE;
}
private SingletonRegistry() {
//this is the reason why the constructor should be public
singleton = new SingletonClass();
}
public SingletonClass getSingletonClass() {
return singleton;
}
public void setSingletonClass(SingletonClass singleton) {
this.singleton = singleton;
}
}

* Change getInstance method of SingletonClass to get instance from SingletonRegistry.
public static SingletonClass getInstance() {
return SingletonRegistry.getInstance().getSingletonClass();
}

* The method getInstance from SingletonClass disappears and all it's client classes uses SingletonRegistry to access SingletonClass.
public class Client {
public void clientMethod() {
SingletonRegistry.getInstance() .getSingletonClass().voidMethod("param");
Object object = SingletonRegistry.getInstance() .getSingletonClass().objectMethod("param");
}
}

* Delete INSTANCE constant from SingletonClass class.

* You can Extract Interface (Alt+Shift+T, E) from SingletonClass. Write just new interface name, select all methods from SingletonClass which you can extract into new interface and press OK. All references to SingletonClass will be refactored to references to your newly created interface.

And that is all. Now you have SingletonClass with totally same functionality but you are able to mock it, extend or replace by different implementation setting up your instance of SingletonClass to SingletonRegistry.

= [http://www.e-pedro.com/2010/05/refactoring-extracting-the-singleton-pattern/ Refactoring:Extracting the Singleton Pattern]=

'''Topics Covered''' :
Extracting the Singleton Pattern

'''Summary''' :
Here, the author demonstrates the refactoring of Singleton Pattern by means of an example of a Device Manger class. So the main class that will be changing is the DeviceManager. This class manages a collection of Devices (or a dictionary, to be more precise) and allows to set which is the active device and to get a device by id. Note that this last feature could be handled by the Devices collection, but we are taking advantage of the dictionary to make that look-up more efficient.

= [http://www.roseindia.net/designpattern/singleton_pattern.shtml Singleton Pattern Usage and Benefits]=

'''Topics Covered''' :
Usage, Benefits, Example

'''Summary''' :
This link describes about the benefits like instance control and usage in multithreaded environment.Singleton patterns are often used as global variables because the global variables permit allocation and initialization whenever required. They don't permit to pollute the global namespace with unnecessary variables.

'''Example''':
package singleton;
public class Logger {
private String fileName;
private Properties properties;
private Priority priority;
private Logger() {
logger = this;
}
public int getRegisteredLevel() {
int i = 0;
try {
InputStream inputstream = getClass().getResourceAsStream("Logger.properties");
properties.load(inputstream);
inputstream.close();
i = Integer.parseInt(properties.getProperty("logger.registeredlevel"));
if(i < 0 || i > 3)
i = 0;
}
catch(Exception exception) {
System.out.println("Logger: Failed in the getRegisteredLevel method");
exception.printStackTrace();
}
return i;
}
public static void initialize() {
logger = new Logger();
}
// singleton - pattern
private static Logger logger;
public static Logger getLogger() {
return logger;
}
}

= [http://www.dotnetobject.com/Thread-Benefits-of-Singleton-Pattern-and-Drawbacks-of-Singleton-Pattern Critique of the Singleton Pattern]=
'''Topics Covered''' :
Critique of the Singleton Pattern

'''Summary''' :
This link describes about the benefits like instance control and flexibility and drawbacks like overhead, development confusion and Object lifetime while using the singleton pattern.

=[http://www.ibm.com/developerworks/webservices/library/co-single/index.html Use Singletons Wisely]=

'''Topics Covered''' :
When to use, Moving away from Singletons, Aggregating Singletons

'''Summary''' :
The programming community discourages using global data and objects. Still, there are times when an application needs a single instance of a given class and a global point of access to that class. The general solution is the design pattern known as singletons. However, singletons are unnecessarily difficult to test and may make strong assumptions about the applications that will use them. In this article the author discusses strategies for avoiding the singleton pattern for that majority of cases where it is not appropriate. He also describes the properties of some classes that are truly singletons.

'''Aggregating Singletons: The Toolbox''':
Singleton abuse can be avoided by looking at the problem from a different angle. Suppose an application needs only one instance of a class and the application configures that class at startup: Why should the class itself be responsible for being a singleton? It seems quite logical for the application to take on this responsibility, since the application requires this kind of behavior. The application, not the component, should be the singleton. The application then makes an instance of the component available for any application-specific code to use. When an application uses several such components, it can aggregate them into what we have called a toolbox.
Put simply, the application's toolbox is a singleton that is responsible either for configuring itself or for allowing the application's startup mechanism to configure it. The general pattern of the Toolbox singleton is as shown in the example provided in this article
The Toolbox is itself a singleton, and it manages the lifetime of the various component instances. Either the application configures it, or it asks the application for configuration information in method initialize. Now the application can decide how many instances of which classes it requires. Changes in those decisions may affect application-specific code, but not reusable, infrastructure-level code. Moreover, testing infrastructure code is much easier, as those classes do not rely on the way in which any application may choose to use them.

= [http://stackoverflow.com/questions/4074154/when-should-the-singleton-pattern-not-be-used-besides-the-obvious When Not to Use Singleton]=

'''Topics Covered''' :
Appropriate Use of the Singleton Pattern

'''Summary''' :
The Gang of Four states that you'll want to use Singleton there must be exactly one instance of a class, and it must be accessible to clients from a well-known access point or when the sole instance should be extensible by subclassing, and clients should be able to use an extended instance without modifying their code.

CSC/ECE 517 Fall 2012/ch2b 2w53 iv

2012-11-19T06:10:16Z

Annice:

= Singleton, directory of sites =
===1.[http://en.wikipedia.org/wiki/Singleton_pattern Singleton on the Wikipedia]===

'''Topics Covered''' :
Common uses, UML, Implementation, Example, Prototype based singleton, Example of use with factory method pattern

'''Summary''' :
This link firstly provides the basic definition of the singleton pattern as a design pattern that restricts the instantiation of a class to one object. Singleton patters are mostly used in Abstract Factory, Builder, and Prototype, and Facade patterns.

Both the UML representation of singleton where the same single instance is always returned and the implementation concerning the mechanism to access the singleton class member without creating a class object and a mechanism to persist the value of class members among the class objects. The link also points out that if a class has to realize a contract expressed by an interface, it really has to be a singleton.

Lazy initialization uses double-checking and eager initialization which always creates an instance.
For instance, Lazy initialization and Eager Initialization example codes are:
'''Lazy Initialization''':
public class SingletonDemo {
private static volatile SingletonDemo instance = null;
private SingletonDemo() {}
public static SingletonDemo getInstance() {
if (instance == null) {
synchronized (SingletonDemo .class){
if (instance == null) {
instance = new SingletonDemo ();
}
}
}
return instance;
}
}

'''Eager Initialization''':
public class Singleton {
private static final Singleton instance = new Singleton();
private Singleton() {}
public static Singleton getInstance() {
return instance;
}
}

It also talks about Prototype-based programming in which objects but not classes are used, a 'singleton' simply refers to an object without copies or that is not used as the prototype for any other object. Eg :->
Foo := Object clone
Foo clone := Foo

'''Drawbacks''' :
The pattern makes unit testing far more difficult as it introduces global state into an application. It should also be noted that this pattern reduces the potential for parallelism within a program, because access to the singleton in a multi-threaded context must be serialized.

2. [http://www.c-sharpcorner.com/UploadFile/SukeshMarla/learn-design-pattern-singleton-pattern/ Learn Singleton-design-Pattern]

'''Topics Covered''' :
Definition, When to use, how to create, Sharing across all users, Sharing across a request, Sharing across a single user

'''Summary''' :
This article explains what Singleton pattern is, what kind of problem it generally solves and how should it be implemented in ASP.NET. The Singleton pattern which ensures that only one instance of a given object can exist at a context solves problems related to object creation and hence is a type of creational pattern.

{|
|[[File:3.jpg|x300px]]
|}

It can be used in a class that wraps the settings related to an application. In other words, whenever we want something to be shared across multiple locations, we use a singleton pattern. In order to create a Singleton pattern, we can render the constructor private so that no user can create a new instance outside the class, that way ensuring only one instance of the objects always exists. In that case, we also need to create a static method that returns the single object.

Singleton patterns in ASP.NET are implemented by using static objects which maintain their values and reside in the memory as long as the application which contains it does. The sharing can occur across users, or requests or across a single user.

3. [http://www.c-sharpcorner.com/UploadFile/faraz.rasheed/SingletonPattern12052005063955AM/SingletonPattern.aspx Singleton - Creational Design Pattern]

'''Topics Covered''' :
Intent, Description, An Example, Implementation, Benefits

'''Summary''' :
It firstly talks about the intent behind singleton design pattern, in that there is a need to have a class that can be instantiated only once.
Then, it describes two solutions for implementing the singleton class.
In the first, there should be only one shared object and reference to that shared object should be available through a static method GetInstance() while the constructor is private.
The second solution expects the constructor to be public but once an object has been instantiated, an exception should be thrown for each successive constructor call.

{|
|[[File:1.gif|x300px]]
|}

The code for each case is given as follows:

'''Case 1''' :
class Singleton
{
private static Singleton instance;
private static int numOfReference;
private string code;
private Singleton()
{
numOfReference = 0;
code = "Maasoom Faraz";
}
public static Singleton GetInstance()
{
if(instance == null)
{
instance = new Singleton();
}
numOfReference++;
return instance;
}
public static int Reference
{
get { return numOfReference; }
}
public string Code
{
get { return code; }
set { code = value;}
}
}

The constructor is made private and used to initialize the numOfReference and default value of code. GetInstance() method checks the instance, if it is null then it assign it an instance of Singleton otherwise return the old reference.

'''Case 2''' :
class Singleton2
{
private static int numOfInstance = 0;
public Singleton2()
{
if(numOfInstance == 0)
{
Console.WriteLine("\r\nCreating First Object of Singleton2 class...");
numOfInstance++;
}
else
{
throw new Exception("This class is Singleton,
+ so only one object of it can be instantiated.");
}
}
}

Here we make the constructor public and use a private field numOfInstance which is incremented for each constructor call. If numOfInstance is zero (no object is yet instantiated), a new object is allowed to made. But, if this value is not zero (there is already an object of Singleton2 class, an exception is thrown.

\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

7. [http://c2.com/cgi/wiki?SingletonPattern Singleton explained on c2.com]

'''Topics Covered''' :
Simulation of global variables, Appropriate Use of Singleton, Singleton in threaded environment

'''Summary''' :
This link firstly explains aspects like testing, creational logic,polymorphism involved in singleton pattern.It explains situations when singleton pattern can be used.It goes on to explain the anti-pattern of singletons simulating global variables and appropriate use of singleton in mutithreaded environment.

'''Problem of using Singleton in Multithreaded Environment''' :

static private synchronized Singleton instance_helper(){
_instance = new Singleton();
return _instance;
}

"_instance" can be null in the logic for multiple threads before instance_helper is called, leading to multiple instances being created

'''Solution for Singleton in Multithreaded Environment''' :

static private synchronized Singleton instance_helper()
{
if(flag)
{
_instance = new Singleton();
}
flag = false;
return _instance;
}

8. [http://www.oodesign.com/singleton-pattern.html Singleton Applications]

'''Topics Covered''' :
Motivation, Intent, Implementation, Applicability and Examples

'''Summary''' :
This link gives some extra information about applicability of Singleton in logger classes,configuration classes, accessing resources in shared environment,factories implemented as Singleton,Implementations and problems involved

'''Serialization''' :

If the Singleton class implements the java.io.Serializable interface, when a singleton is serialized and then deserialized more than once, there will be multiple instances of Singleton created. In order to avoid this the readResolve method should be implemented.

public class Singleton implements Serializable {
...
// This method is called immediately after an object of this class is deserialized.
// This method returns the singleton instance.
protected Object readResolve() {
return getInstance();
}
}

9. [http://msdn.microsoft.com/en-us/library/ff650316.aspx Singleton Implementation in C#]

'''Topics Covered''' :
Implementation in C#

'''Summary''' :
This link explains how to implement a singleton in C# both in static and threaded environment.

'''Static Initialization''':

One of the reasons Design Patterns [Gamma95] avoided static initialization is because the C++ specification left some ambiguity around the initialization order of static variables. Fortunately, the .NET Framework resolves this ambiguity through its handling of variable initialization:

public sealed class Singleton
{
private static readonly Singleton instance = new Singleton();
private Singleton(){}
public static Singleton Instance
{
get
{
return instance;
}
}
}

Implementing Singleton in C# results in the following benefits and liabilities:

'''Benefits''':
*The static initialization approach is possible because the .NET Framework explicitly defines how and when static variable initialization occurs.
*The Double-Check Locking idiom described earlier in "Multithreaded Singleton" is implemented correctly in the common language runtime.

'''Liabilities''':
If your multithreaded application requires explicit initialization, you have to take precautions to avoid threading issues.

10. [http://bosy.dailydev.org/2007/08/refactor-singleton-out-of-your-code.html Refactor Singleton Out Of Your Code]

'''Topics Covered''' :
Solution to refactor singleton

'''Summary''' :
Gang of Four mentions Singleton as an anti-pattern and not as a pattern. This Link provides a solution to refactor Singleton out of the code

'''Steps to refactor Singleton:'''
* Create simple interface for Registry with two simple methods - getter and setter for instance of class which is currently implemented as singleton.
public interface ISingletonRegistry {
SingletonClass getSingletonClass();
void setSingletonClass(SingletonClass singleton);
}

* Make SingletonClass's constructor public

* Then implement the interface as a simplest Registry design pattern implementation - SingletonRegistry.

public class SingletonRegistry implements ISingletonRegistry {
private static final SingletonRegistry INSTANCE = new SingletonRegistry();
private SingletonClass singleton;
public static ISingletonRegistry getInstance() {
return INSTANCE;
}
private SingletonRegistry() {
//this is the reason why the constructor should be public
singleton = new SingletonClass();
}
public SingletonClass getSingletonClass() {
return singleton;
}
public void setSingletonClass(SingletonClass singleton) {
this.singleton = singleton;
}
}

* Change getInstance method of SingletonClass to get instance from SingletonRegistry.
public static SingletonClass getInstance() {
return SingletonRegistry.getInstance().getSingletonClass();
}

* The method getInstance from SingletonClass disappears and all it's client classes uses SingletonRegistry to access SingletonClass.
public class Client {
public void clientMethod() {
SingletonRegistry.getInstance() .getSingletonClass().voidMethod("param");
Object object = SingletonRegistry.getInstance() .getSingletonClass().objectMethod("param");
}
}

* Delete INSTANCE constant from SingletonClass class.

* You can Extract Interface (Alt+Shift+T, E) from SingletonClass. Write just new interface name, select all methods from SingletonClass which you can extract into new interface and press OK. All references to SingletonClass will be refactored to references to your newly created interface.

And that is all. Now you have SingletonClass with totally same functionality but you are able to mock it, extend or replace by different implementation setting up your instance of SingletonClass to SingletonRegistry.

11. [http://www.e-pedro.com/2010/05/refactoring-extracting-the-singleton-pattern/ Refactoring:Extracting the Singleton Pattern]

'''Topics Covered''' :
Extracting the Singleton Pattern

'''Summary''' :
Here, the author demonstrates the refactoring of Singleton Pattern by means of an example of a Device Manger class. So the main class that will be changing is the DeviceManager. This class manages a collection of Devices (or a dictionary, to be more precise) and allows to set which is the active device and to get a device by id. Note that this last feature could be handled by the Devices collection, but we are taking advantage of the dictionary to make that look-up more efficient.

12. [http://www.roseindia.net/designpattern/singleton_pattern.shtml Singleton Pattern Usage and Benefits]

'''Topics Covered''' :
Usage, Benefits, Example

'''Summary''' :
This link describes about the benefits like instance control and usage in multithreaded environment.Singleton patterns are often used as global variables because the global variables permit allocation and initialization whenever required. They don't permit to pollute the global namespace with unnecessary variables.

'''Example''':
package singleton;
public class Logger {
private String fileName;
private Properties properties;
private Priority priority;
private Logger() {
logger = this;
}
public int getRegisteredLevel() {
int i = 0;
try {
InputStream inputstream = getClass().getResourceAsStream("Logger.properties");
properties.load(inputstream);
inputstream.close();
i = Integer.parseInt(properties.getProperty("logger.registeredlevel"));
if(i < 0 || i > 3)
i = 0;
}
catch(Exception exception) {
System.out.println("Logger: Failed in the getRegisteredLevel method");
exception.printStackTrace();
}
return i;
}
public static void initialize() {
logger = new Logger();
}
// singleton - pattern
private static Logger logger;
public static Logger getLogger() {
return logger;
}
}

13. [http://www.dotnetobject.com/Thread-Benefits-of-Singleton-Pattern-and-Drawbacks-of-Singleton-Pattern Critique of the Singleton Pattern]

'''Topics Covered''' :
Critique of the Singleton Pattern

'''Summary''' :
This link describes about the benefits like instance control and flexibility and drawbacks like overhead, development confusion and Object lifetime while using the singleton pattern.

14.[http://www.ibm.com/developerworks/webservices/library/co-single/index.html Use Singletons Wisely]

'''Topics Covered''' :
When to use, Moving away from Singletons, Aggregating Singletons

'''Summary''' :
The programming community discourages using global data and objects. Still, there are times when an application needs a single instance of a given class and a global point of access to that class. The general solution is the design pattern known as singletons. However, singletons are unnecessarily difficult to test and may make strong assumptions about the applications that will use them. In this article the author discusses strategies for avoiding the singleton pattern for that majority of cases where it is not appropriate. He also describes the properties of some classes that are truly singletons.

'''Aggregating Singletons: The Toolbox''':
Singleton abuse can be avoided by looking at the problem from a different angle. Suppose an application needs only one instance of a class and the application configures that class at startup: Why should the class itself be responsible for being a singleton? It seems quite logical for the application to take on this responsibility, since the application requires this kind of behavior. The application, not the component, should be the singleton. The application then makes an instance of the component available for any application-specific code to use. When an application uses several such components, it can aggregate them into what we have called a toolbox.
Put simply, the application's toolbox is a singleton that is responsible either for configuring itself or for allowing the application's startup mechanism to configure it. The general pattern of the Toolbox singleton is as shown in the example provided in this article
The Toolbox is itself a singleton, and it manages the lifetime of the various component instances. Either the application configures it, or it asks the application for configuration information in method initialize. Now the application can decide how many instances of which classes it requires. Changes in those decisions may affect application-specific code, but not reusable, infrastructure-level code. Moreover, testing infrastructure code is much easier, as those classes do not rely on the way in which any application may choose to use them.

15. [http://stackoverflow.com/questions/4074154/when-should-the-singleton-pattern-not-be-used-besides-the-obvious When Not to Use Singleton]

'''Topics Covered''' :
Appropriate Use of the Singleton Pattern

'''Summary''' :
The Gang of Four states that you'll want to use Singleton there must be exactly one instance of a class, and it must be accessible to clients from a well-known access point or when the sole instance should be extensible by subclassing, and clients should be able to use an extended instance without modifying their code.

CSC/ECE 517 Fall 2012/ch2b 2w53 iv

2012-11-19T05:20:11Z

Annice:

CSC/ECE 517 Fall 2012/ch2b 2w53 iv

2012-11-19T04:48:21Z

Annice:

= Singleton, directory of sites =
===1.[http://en.wikipedia.org/wiki/Singleton_pattern Singleton on the Wikipedia]===

'''Topics Covered''' :
Common uses, UML, Implementation, Example, Prototype based singleton, Example of use with factory method pattern

'''Summary''' :
This link firstly provides the basic definition of the singleton pattern as a design pattern that restricts the instantiation of a class to one object. Singleton patters are mostly used in Abstract Factory, Builder, and Prototype, and Facade patterns.

Both the UML representation of singleton where the same single instance is always returned and the implementation concerning the mechanism to access the singleton class member without creating a class object and a mechanism to persist the value of class members among the class objects. The link also points out that if a class has to realize a contract expressed by an interface, it really has to be a singleton.

Lazy initialization uses double-checking and eager initialization which always creates an instance.
For instance, Lazy initialization and Eager Initialization example codes are:
'''Lazy Initialization''':
public class SingletonDemo {
private static volatile SingletonDemo instance = null;
private SingletonDemo() {}
public static SingletonDemo getInstance() {
if (instance == null) {
synchronized (SingletonDemo .class){
if (instance == null) {
instance = new SingletonDemo ();
}
}
}
return instance;
}
}

'''Eager Initialization''':
public class Singleton {
private static final Singleton instance = new Singleton();
private Singleton() {}
public static Singleton getInstance() {
return instance;
}
}

It also talks about Prototype-based programming in which objects but not classes are used, a 'singleton' simply refers to an object without copies or that is not used as the prototype for any other object. Eg :->
Foo := Object clone
Foo clone := Foo

'''Drawbacks''' :
The pattern makes unit testing far more difficult as it introduces global state into an application. It should also be noted that this pattern reduces the potential for parallelism within a program, because access to the singleton in a multi-threaded context must be serialized.

2. [http://www.c-sharpcorner.com/UploadFile/SukeshMarla/learn-design-pattern-singleton-pattern/ Learn Singleton-design-Pattern]

'''Topics Covered''' :
Definition, When to use, how to create, Sharing across all users, Sharing across a request, Sharing across a single user

'''Summary''' :
This article explains what Singleton pattern is, what kind of problem it generally solves and how should it be implemented in ASP.NET. The Singleton pattern which ensures that only one instance of a given object can exist at a context solves problems related to object creation and hence is a type of creational pattern.

{|
|[[File:3.jpg|x300px]]
|}

It can be used in a class that wraps the settings related to an application. In other words, whenever we want something to be shared across multiple locations, we use a singleton pattern. In order to create a Singleton pattern, we can render the constructor private so that no user can create a new instance outside the class, that way ensuring only one instance of the objects always exists. In that case, we also need to create a static method that returns the single object.

Singleton patterns in ASP.NET are implemented by using static objects which maintain their values and reside in the memory as long as the application which contains it does. The sharing can occur across users, or requests or across a single user.

3. [http://www.c-sharpcorner.com/UploadFile/faraz.rasheed/SingletonPattern12052005063955AM/SingletonPattern.aspx Singleton - Creational Design Pattern]

'''Topics Covered''' :
Intent, Description, An Example, Implementation, Benefits

'''Summary''' :
It firstly talks about the intent behind singleton design pattern, in that there is a need to have a class that can be instantiated only once.
Then, it describes two solutions for implementing the singleton class.
In the first, there should be only one shared object and reference to that shared object should be available through a static method GetInstance() while the constructor is private.
The second solution expects the constructor to be public but once an object has been instantiated, an exception should be thrown for each successive constructor call.

{|
|[[File:1.gif|x300px]]
|}

The code for each case is given as follows:

'''Case 1''' :
class Singleton
{
private static Singleton instance;
private static int numOfReference;
private string code;
private Singleton()
{
numOfReference = 0;
code = "Maasoom Faraz";
}
public static Singleton GetInstance()
{
if(instance == null)
{
instance = new Singleton();
}
numOfReference++;
return instance;
}
public static int Reference
{
get { return numOfReference; }
}
public string Code
{
get { return code; }
set { code = value;}
}
}

The constructor is made private and used to initialize the numOfReference and default value of code. GetInstance() method checks the instance, if it is null then it assign it an instance of Singleton otherwise return the old reference.

'''Case 2''' :
class Singleton2
{
private static int numOfInstance = 0;
public Singleton2()
{
if(numOfInstance == 0)
{
Console.WriteLine("\r\nCreating First Object of Singleton2 class...");
numOfInstance++;
}
else
{
throw new Exception("This class is Singleton,
+ so only one object of it can be instantiated.");
}
}
}

Here we make the constructor public and use a private field numOfInstance which is incremented for each constructor call. If numOfInstance is zero (no object is yet instantiated), a new object is allowed to made. But, if this value is not zero (there is already an object of Singleton2 class, an exception is thrown.

\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

7. [http://c2.com/cgi/wiki?SingletonPattern Singleton explained on c2.com]

'''Topics Covered''' :
Simulation of global variables, Appropriate Use of Singleton, Singleton in threaded environment

'''Summary''' :
This link firstly explains aspects like testing, creational logic,polymorphism involved in singleton pattern.It explains situations when singleton pattern can be used.It goes on to explain the anti-pattern of singletons simulating global variables and appropriate use of singleton in mutithreaded environment.

'''Problem of using Singleton in Multithreaded Environment''' :

static private synchronized Singleton instance_helper(){
_instance = new Singleton();
return _instance;
}

"_instance" can be null in the logic for multiple threads before instance_helper is called, leading to multiple instances being created

'''Solution for Singleton in Multithreaded Environment''' :

static private synchronized Singleton instance_helper()
{
if(flag)
{
_instance = new Singleton();
}
flag = false;
return _instance;
}

8. [http://www.oodesign.com/singleton-pattern.html Singleton Applications]

'''Topics Covered''' :
Motivation, Intent, Implementation, Applicability and Examples

'''Summary''' :
This link gives some extra information about applicability of Singleton in logger classes,configuration classes, accessing resources in shared environment,factories implemented as Singleton,Implementations and problems involved

'''Serialization''' :

If the Singleton class implements the java.io.Serializable interface, when a singleton is serialized and then deserialized more than once, there will be multiple instances of Singleton created. In order to avoid this the readResolve method should be implemented.

public class Singleton implements Serializable {
...
// This method is called immediately after an object of this class is deserialized.
// This method returns the singleton instance.
protected Object readResolve() {
return getInstance();
}
}

9. [http://msdn.microsoft.com/en-us/library/ff650316.aspx Singleton Implementation in C#]

'''Topics Covered''' :
Implementation in C#

'''Summary''' :
This link explains how to implement a singleton in C# both in static and threaded environment.

'''Static Initialization''':

One of the reasons Design Patterns [Gamma95] avoided static initialization is because the C++ specification left some ambiguity around the initialization order of static variables. Fortunately, the .NET Framework resolves this ambiguity through its handling of variable initialization:

public sealed class Singleton
{
private static readonly Singleton instance = new Singleton();
private Singleton(){}
public static Singleton Instance
{
get
{
return instance;
}
}
}

Implementing Singleton in C# results in the following benefits and liabilities:

'''Benefits''':
*The static initialization approach is possible because the .NET Framework explicitly defines how and when static variable initialization occurs.
*The Double-Check Locking idiom described earlier in "Multithreaded Singleton" is implemented correctly in the common language runtime.

'''Liabilities''':
If your multithreaded application requires explicit initialization, you have to take precautions to avoid threading issues.

10. [http://bosy.dailydev.org/2007/08/refactor-singleton-out-of-your-code.html Refactor Singleton Out Of Your Code]

'''Topics Covered''' :
Solution to refactor singleton

'''Summary''' :
Gang of Four mentions Singleton as an anti-pattern and not as a pattern. This Link provides a solution to refactor Singleton out of the code

'''Steps to refactor Singleton:'''
* Create simple interface for Registry with two simple methods - getter and setter for instance of class which is currently implemented as singleton.
public interface ISingletonRegistry {
SingletonClass getSingletonClass();
void setSingletonClass(SingletonClass singleton);
}

* Make SingletonClass's constructor public

* Then implement the interface as a simplest Registry design pattern implementation - SingletonRegistry.

public class SingletonRegistry implements ISingletonRegistry {
private static final SingletonRegistry INSTANCE = new SingletonRegistry();
private SingletonClass singleton;
public static ISingletonRegistry getInstance() {
return INSTANCE;
}
private SingletonRegistry() {
//this is the reason why the constructor should be public
singleton = new SingletonClass();
}
public SingletonClass getSingletonClass() {
return singleton;
}
public void setSingletonClass(SingletonClass singleton) {
this.singleton = singleton;
}
}

* Change getInstance method of SingletonClass to get instance from SingletonRegistry.
public static SingletonClass getInstance() {
return SingletonRegistry.getInstance().getSingletonClass();
}

* The method getInstance from SingletonClass disappears and all it's client classes uses SingletonRegistry to access SingletonClass.
public class Client {
public void clientMethod() {
SingletonRegistry.getInstance() .getSingletonClass().voidMethod("param");
Object object = SingletonRegistry.getInstance() .getSingletonClass().objectMethod("param");
}
}

* Delete INSTANCE constant from SingletonClass class.

* You can Extract Interface (Alt+Shift+T, E) from SingletonClass. Write just new interface name, select all methods from SingletonClass which you can extract into new interface and press OK. All references to SingletonClass will be refactored to references to your newly created interface.

And that is all. Now you have SingletonClass with totally same functionality but you are able to mock it, extend or replace by different implementation setting up your instance of SingletonClass to SingletonRegistry.

11. [http://www.e-pedro.com/2010/05/refactoring-extracting-the-singleton-pattern/ Refactoring:Extracting the Singleton Pattern]

'''Topics Covered''' :
Extracting the Singleton Pattern

'''Summary''' :
Here, the author demonstrates the refactoring of Singleton Pattern by means of an example of a Device Manger class. So the main class that will be changing is the DeviceManager. This class manages a collection of Devices (or a dictionary, to be more precise) and allows to set which is the active device and to get a device by id. Note that this last feature could be handled by the Devices collection, but we are taking advantage of the dictionary to make that look-up more efficient.

12. [http://www.dotnetobject.com/Thread-Benefits-of-Singleton-Pattern-and-Drawbacks-of-Singleton-Pattern Critique of the Singleton Pattern]

'''Topics Covered''' :
Critique of the Singleton Pattern

'''Summary''' :
This link describes about the benefits like instance control and flexibility and drawbacks like overhead, development confusion and Object lifetime while using the singleton pattern.

CSC/ECE 517 Fall 2012/ch2b 2w53 iv

2012-11-19T04:17:08Z

Annice:

= Singleton, directory of sites =
===1.[http://en.wikipedia.org/wiki/Singleton_pattern Singleton on the Wikipedia]===

'''Topics Covered''' :
Common uses, UML, Implementation, Example, Prototype based singleton, Example of use with factory method pattern

'''Summary''' :
This link firstly provides the basic definition of the singleton pattern as a design pattern that restricts the instantiation of a class to one object. Singleton patters are mostly used in Abstract Factory, Builder, and Prototype, and Facade patterns.

Both the UML representation of singleton where the same single instance is always returned and the implementation concerning the mechanism to access the singleton class member without creating a class object and a mechanism to persist the value of class members among the class objects. The link also points out that if a class has to realize a contract expressed by an interface, it really has to be a singleton.

Lazy initialization uses double-checking and eager initialization which always creates an instance.
For instance, Lazy initialization and Eager Initialization example codes are:
'''Lazy Initialization''':
public class SingletonDemo {
private static volatile SingletonDemo instance = null;
private SingletonDemo() {}
public static SingletonDemo getInstance() {
if (instance == null) {
synchronized (SingletonDemo .class){
if (instance == null) {
instance = new SingletonDemo ();
}
}
}
return instance;
}
}

'''Eager Initialization''':
public class Singleton {
private static final Singleton instance = new Singleton();
private Singleton() {}
public static Singleton getInstance() {
return instance;
}
}

It also talks about Prototype-based programming in which objects but not classes are used, a 'singleton' simply refers to an object without copies or that is not used as the prototype for any other object. Eg :->
Foo := Object clone
Foo clone := Foo

'''Drawbacks''' :
The pattern makes unit testing far more difficult as it introduces global state into an application. It should also be noted that this pattern reduces the potential for parallelism within a program, because access to the singleton in a multi-threaded context must be serialized.

2. [http://www.c-sharpcorner.com/UploadFile/SukeshMarla/learn-design-pattern-singleton-pattern/ Learn Singleton-design-Pattern]

'''Topics Covered''' :
Definition, When to use, how to create, Sharing across all users, Sharing across a request, Sharing across a single user

'''Summary''' :
This article explains what Singleton pattern is, what kind of problem it generally solves and how should it be implemented in ASP.NET. The Singleton pattern which ensures that only one instance of a given object can exist at a context solves problems related to object creation and hence is a type of creational pattern.

{|
|[[File:3.jpg|x300px]]
|}

It can be used in a class that wraps the settings related to an application. In other words, whenever we want something to be shared across multiple locations, we use a singleton pattern. In order to create a Singleton pattern, we can render the constructor private so that no user can create a new instance outside the class, that way ensuring only one instance of the objects always exists. In that case, we also need to create a static method that returns the single object.

Singleton patterns in ASP.NET are implemented by using static objects which maintain their values and reside in the memory as long as the application which contains it does. The sharing can occur across users, or requests or across a single user.

3. [http://www.c-sharpcorner.com/UploadFile/faraz.rasheed/SingletonPattern12052005063955AM/SingletonPattern.aspx Singleton - Creational Design Pattern]

'''Topics Covered''' :
Intent, Description, An Example, Implementation, Benefits

'''Summary''' :
It firstly talks about the intent behind singleton design pattern, in that there is a need to have a class that can be instantiated only once.
Then, it describes two solutions for implementing the singleton class.
In the first, there should be only one shared object and reference to that shared object should be available through a static method GetInstance() while the constructor is private.
The second solution expects the constructor to be public but once an object has been instantiated, an exception should be thrown for each successive constructor call.

{|
|[[File:1.gif|x300px]]
|}

The code for each case is given as follows:

'''Case 1''' :
class Singleton
{
private static Singleton instance;
private static int numOfReference;
private string code;
private Singleton()
{
numOfReference = 0;
code = "Maasoom Faraz";
}
public static Singleton GetInstance()
{
if(instance == null)
{
instance = new Singleton();
}
numOfReference++;
return instance;
}
public static int Reference
{
get { return numOfReference; }
}
public string Code
{
get { return code; }
set { code = value;}
}
}

The constructor is made private and used to initialize the numOfReference and default value of code. GetInstance() method checks the instance, if it is null then it assign it an instance of Singleton otherwise return the old reference.

'''Case 2''' :
class Singleton2
{
private static int numOfInstance = 0;
public Singleton2()
{
if(numOfInstance == 0)
{
Console.WriteLine("\r\nCreating First Object of Singleton2 class...");
numOfInstance++;
}
else
{
throw new Exception("This class is Singleton,
+ so only one object of it can be instantiated.");
}
}
}

Here we make the constructor public and use a private field numOfInstance which is incremented for each constructor call. If numOfInstance is zero (no object is yet instantiated), a new object is allowed to made. But, if this value is not zero (there is already an object of Singleton2 class, an exception is thrown.

\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

1. [http://c2.com/cgi/wiki?SingletonPattern Singleton explained on c2.com]

'''Topics Covered''' :
Simulation of global variables, Appropriate Use of Singleton, Singleton in threaded environment

'''Summary''' :
This link firstly explains aspects like testing, creational logic,polymorphism involved in singleton pattern.It explains situations when singleton pattern can be used.It goes on to explain the anti-pattern of singletons simulating global variables and appropriate use of singleton in mutithreaded environment.

'''Problem of using Singleton in Multithreaded Environment''' :

static private synchronized Singleton instance_helper(){
_instance = new Singleton();
return _instance;
}

"_instance" can be null in the logic for multiple threads before instance_helper is called, leading to multiple instances being created

'''Solution for Singleton in Multithreaded Environment''' :

static private synchronized Singleton instance_helper()
{
if(flag)
{
_instance = new Singleton();
}
flag = false;
return _instance;
}

8. [http://www.oodesign.com/singleton-pattern.html Singleton Applications]

'''Topics Covered''' :
Motivation, Intent, Implementation, Applicability and Examples

'''Summary''' :
This link gives some extra information about applicability of Singleton in logger classes,configuration classes, accessing resources in shared environment,factories implemented as Singleton,Implementations and problems involved

'''Serialization''' :

If the Singleton class implements the java.io.Serializable interface, when a singleton is serialized and then deserialized more than once, there will be multiple instances of Singleton created. In order to avoid this the readResolve method should be implemented.

public class Singleton implements Serializable {
...
// This method is called immediately after an object of this class is deserialized.
// This method returns the singleton instance.
protected Object readResolve() {
return getInstance();
}
}

9. [http://msdn.microsoft.com/en-us/library/ff650316.aspx Singleton Implementation in C#]

'''Topics Covered''' :
Implementation in C#

'''Summary''' :
This link explains how to implement a singleton in C# both in static and threaded environment.

'''Static Initialization''':

One of the reasons Design Patterns [Gamma95] avoided static initialization is because the C++ specification left some ambiguity around the initialization order of static variables. Fortunately, the .NET Framework resolves this ambiguity through its handling of variable initialization:

public sealed class Singleton
{
private static readonly Singleton instance = new Singleton();
private Singleton(){}
public static Singleton Instance
{
get
{
return instance;
}
}
}

Implementing Singleton in C# results in the following benefits and liabilities:

'''Benefits''':
*The static initialization approach is possible because the .NET Framework explicitly defines how and when static variable initialization occurs.
*The Double-Check Locking idiom described earlier in "Multithreaded Singleton" is implemented correctly in the common language runtime.

'''Liabilities''':
If your multithreaded application requires explicit initialization, you have to take precautions to avoid threading issues.

10. [http://bosy.dailydev.org/2007/08/refactor-singleton-out-of-your-code.html Refactor Singleton Out Of Your Code]

'''Topics Covered''' :
Solution to refactor singleton

'''Summary''' :
Gang of Four mentions Singleton as an anti-pattern and not as a pattern. This Link provides a solution to refactor Singleton out of the code

'''Steps to refactor Singleton:'''
1. Create simple interface for Registry with two simple methods - getter and setter for instance of class which is currently implemented as singleton.
public interface ISingletonRegistry {
SingletonClass getSingletonClass();
void setSingletonClass(SingletonClass singleton);
}

2. Make SingletonClass's constructor public

3. Then implement the interface as a simplest Registry design pattern implementation - SingletonRegistry.

public class SingletonRegistry implements ISingletonRegistry {
private static final SingletonRegistry INSTANCE = new SingletonRegistry();
private SingletonClass singleton;
public static ISingletonRegistry getInstance() {
return INSTANCE;
}
private SingletonRegistry() {
//this is the reason why the constructor should be public
singleton = new SingletonClass();
}
public SingletonClass getSingletonClass() {
return singleton;
}
public void setSingletonClass(SingletonClass singleton) {
this.singleton = singleton;
}
}

4. Change getInstance method of SingletonClass to get instance from SingletonRegistry.
public static SingletonClass getInstance() {
return SingletonRegistry.getInstance().getSingletonClass();
}

5.The method getInstance from SingletonClass disappears and all it's client classes uses SingletonRegistry to access SingletonClass.
public class Client {
public void clientMethod() {
SingletonRegistry.getInstance() .getSingletonClass().voidMethod("param");
Object object = SingletonRegistry.getInstance() .getSingletonClass().objectMethod("param");
}
}

6. Delete INSTANCE constant from SingletonClass class.

7. You can Extract Interface (Alt+Shift+T, E) from SingletonClass. Write just new interface name, select all methods from SingletonClass which you can extract into new interface and press OK. All references to SingletonClass will be refactored to references to your newly created interface.

And that is all. Now you have SingletonClass with totally same functionality but you are able to mock it, extend or replace by different implementation setting up your instance of SingletonClass to SingletonRegistry.

11. [http://www.e-pedro.com/2010/05/refactoring-extracting-the-singleton-pattern/ Refactoring:Extracting the Singleton Pattern]

'''Topics Covered''' :
Extracting the Singleton Pattern

'''Summary''' :
Here, the author demonstrates the refactoring of Singleton Pattern by means of an example of a Device Manger class. So the main class that will be changing is the DeviceManager. This class manages a collection of Devices (or a dictionary, to be more precise) and allows to set which is the active device and to get a device by id. Note that this last feature could be handled by the Devices collection, but we are taking advantage of the dictionary to make that look-up more efficient.

12. [http://www.dotnetobject.com/Thread-Benefits-of-Singleton-Pattern-and-Drawbacks-of-Singleton-Pattern Critique of the Singleton Pattern]

'''Topics Covered''' :
Critique of the Singleton Pattern

'''Summary''' :
This link describes about the benefits like instance control and flexibility and drawbacks like overhead, development confusion and Object lifetime while using the singleton pattern.

CSC/ECE 517 Fall 2012/ch2b 2w53 iv

2012-11-19T00:26:27Z

Annice:

= Singleton, directory of sites =
===1.[http://en.wikipedia.org/wiki/Singleton_pattern Singleton on the Wikipedia]===

'''Topics Covered''' :
Common uses, UML, Implementation, Example, Prototype based singleton, Example of use with factory method pattern

'''Summary''' :
This link firstly provides the basic definition of the singleton pattern as a design pattern that restricts the instantiation of a class to one object. Singleton patters are mostly used in Abstract Factory, Builder, and Prototype, and Facade patterns.

Both the UML representation of singleton where the same single instance is always returned and the implementation concerning the mechanism to access the singleton class member without creating a class object and a mechanism to persist the value of class members among the class objects. The link also points out that if a class has to realize a contract expressed by an interface, it really has to be a singleton.

Lazy initialization uses double-checking and eager initialization which always creates an instance.
For instance, Lazy initialization and Eager Initialization example codes are:
'''Lazy Initialization''':
public class SingletonDemo {
private static volatile SingletonDemo instance = null;
private SingletonDemo() {}
public static SingletonDemo getInstance() {
if (instance == null) {
synchronized (SingletonDemo .class){
if (instance == null) {
instance = new SingletonDemo ();
}
}
}
return instance;
}
}

'''Eager Initialization''':
public class Singleton {
private static final Singleton instance = new Singleton();
private Singleton() {}
public static Singleton getInstance() {
return instance;
}
}

It also talks about Prototype-based programming in which objects but not classes are used, a 'singleton' simply refers to an object without copies or that is not used as the prototype for any other object. Eg :->
Foo := Object clone
Foo clone := Foo

'''Drawbacks''' :
The pattern makes unit testing far more difficult as it introduces global state into an application. It should also be noted that this pattern reduces the potential for parallelism within a program, because access to the singleton in a multi-threaded context must be serialized.

2. [http://www.c-sharpcorner.com/UploadFile/SukeshMarla/learn-design-pattern-singleton-pattern/ Learn Singleton-design-Pattern]

'''Topics Covered''' :
Definition, When to use, how to create, Sharing across all users, Sharing across a request, Sharing across a single user

'''Summary''' :
This article explains what Singleton pattern is, what kind of problem it generally solves and how should it be implemented in ASP.NET. The Singleton pattern which ensures that only one instance of a given object can exist at a context solves problems related to object creation and hence is a type of creational pattern.

{|
|[[File:3.jpg|x300px]]
|}

It can be used in a class that wraps the settings related to an application. In other words, whenever we want something to be shared across multiple locations, we use a singleton pattern. In order to create a Singleton pattern, we can render the constructor private so that no user can create a new instance outside the class, that way ensuring only one instance of the objects always exists. In that case, we also need to create a static method that returns the single object.

Singleton patterns in ASP.NET are implemented by using static objects which maintain their values and reside in the memory as long as the application which contains it does. The sharing can occur across users, or requests or across a single user.

3. [http://www.c-sharpcorner.com/UploadFile/faraz.rasheed/SingletonPattern12052005063955AM/SingletonPattern.aspx Singleton - Creational Design Pattern]

'''Topics Covered''' :
Intent, Description, An Example, Implementation, Benefits

'''Summary''' :
It firstly talks about the intent behind singleton design pattern, in that there is a need to have a class that can be instantiated only once.
Then, it describes two solutions for implementing the singleton class.
In the first, there should be only one shared object and reference to that shared object should be available through a static method GetInstance() while the constructor is private.
The second solution expects the constructor to be public but once an object has been instantiated, an exception should be thrown for each successive constructor call.

{|
|[[File:1.gif|x300px]]
|}

The code for each case is given as follows:

'''Case 1''' :
class Singleton
{
private static Singleton instance;
private static int numOfReference;
private string code;
private Singleton()
{
numOfReference = 0;
code = "Maasoom Faraz";
}
public static Singleton GetInstance()
{
if(instance == null)
{
instance = new Singleton();
}
numOfReference++;
return instance;
}
public static int Reference
{
get { return numOfReference; }
}
public string Code
{
get { return code; }
set { code = value;}
}
}

The constructor is made private and used to initialize the numOfReference and default value of code. GetInstance() method checks the instance, if it is null then it assign it an instance of Singleton otherwise return the old reference.

'''Case 2''' :
class Singleton2
{
private static int numOfInstance = 0;
public Singleton2()
{
if(numOfInstance == 0)
{
Console.WriteLine("\r\nCreating First Object of Singleton2 class...");
numOfInstance++;
}
else
{
throw new Exception("This class is Singleton,
+ so only one object of it can be instantiated.");
}
}
}

Here we make the constructor public and use a private field numOfInstance which is incremented for each constructor call. If numOfInstance is zero (no object is yet instantiated), a new object is allowed to made. But, if this value is not zero (there is already an object of Singleton2 class, an exception is thrown.

\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

1. [http://c2.com/cgi/wiki?SingletonPattern Singleton explained on c2.com]

'''Topics Covered''' :
Simulation of global variables, Appropriate Use of Singleton, Singleton in threaded environment

'''Summary''' :
This link firstly explains aspects like testing, creational logic,polymorphism involved in singleton pattern.It explains situations when singleton pattern can be used.It goes on to explain the anti-pattern of singletons simulating global variables and appropriate use of singleton in mutithreaded environment.

'''Problem of using Singleton in Multithreaded Environment''' :

static private synchronized Singleton instance_helper(){
_instance = new Singleton();
return _instance;
}

"_instance" can be null in the logic for multiple threads before instance_helper is called, leading to multiple instances being created

'''Solution for Singleton in Multithreaded Environment''' :

static private synchronized Singleton instance_helper()
{
if(flag)
{
_instance = new Singleton();
}
flag = false;
return _instance;
}

8. [http://www.oodesign.com/singleton-pattern.html Singleton Applications]

'''Topics Covered''' :
Motivation, Intent, Implementation, Applicability and Examples

'''Summary''' :
This link gives some extra information about applicability of Singleton in logger classes,configuration classes, accessing resources in shared environment,factories implemented as Singleton,Implementations and problems involved

'''Serialization''' :

If the Singleton class implements the java.io.Serializable interface, when a singleton is serialized and then deserialized more than once, there will be multiple instances of Singleton created. In order to avoid this the readResolve method should be implemented.

public class Singleton implements Serializable {
...
// This method is called immediately after an object of this class is deserialized.
// This method returns the singleton instance.
protected Object readResolve() {
return getInstance();
}
}

9. [http://msdn.microsoft.com/en-us/library/ff650316.aspx Singleton Implementation in C#]

'''Topics Covered''' :
Implementation in C#

'''Summary''' :
This link explains how to implement a singleton in C# both in static and threaded environment.

'''Static Initialization''':

One of the reasons Design Patterns [Gamma95] avoided static initialization is because the C++ specification left some ambiguity around the initialization order of static variables. Fortunately, the .NET Framework resolves this ambiguity through its handling of variable initialization:

public sealed class Singleton
{
private static readonly Singleton instance = new Singleton();
private Singleton(){}
public static Singleton Instance
{
get
{
return instance;
}
}
}

Implementing Singleton in C# results in the following benefits and liabilities:

'''Benefits''':
*The static initialization approach is possible because the .NET Framework explicitly defines how and when static variable initialization occurs.
*The Double-Check Locking idiom described earlier in "Multithreaded Singleton" is implemented correctly in the common language runtime.

'''Liabilities''':
If your multithreaded application requires explicit initialization, you have to take precautions to avoid threading issues.

10. [http://bosy.dailydev.org/2007/08/refactor-singleton-out-of-your-code.html Refactor Singleton Out Of Your Code]

'''Topics Covered''' :
Solution to refactor singleton

'''Summary''' :
Gang of Four mentions Singleton as an anti-pattern and not as a pattern. This Link provides a solution to refactor Singleton out of the code

'''Steps to refactor Singleton:'''
1. Create simple interface for Registry with two simple methods - getter and setter for instance of class which is currently implemented as singleton.
public interface ISingletonRegistry {
SingletonClass getSingletonClass();
void setSingletonClass(SingletonClass singleton);
}

2. Make SingletonClass's constructor public

3. Then implement the interface as a simplest Registry design pattern implementation - SingletonRegistry.

public class SingletonRegistry implements ISingletonRegistry {
private static final SingletonRegistry INSTANCE = new SingletonRegistry();
private SingletonClass singleton;
public static ISingletonRegistry getInstance() {
return INSTANCE;
}
private SingletonRegistry() {
//this is the reason why the constructor should be public
singleton = new SingletonClass();
}
public SingletonClass getSingletonClass() {
return singleton;
}
public void setSingletonClass(SingletonClass singleton) {
this.singleton = singleton;
}
}

4. Change getInstance method of SingletonClass to get instance from SingletonRegistry.
public static SingletonClass getInstance() {
return SingletonRegistry.getInstance().getSingletonClass();
}

5.The method getInstance from SingletonClass disappears and all it's client classes uses SingletonRegistry to access SingletonClass.
public class Client {
public void clientMethod() {
SingletonRegistry.getInstance() .getSingletonClass().voidMethod("param");
Object object = SingletonRegistry.getInstance() .getSingletonClass().objectMethod("param");
}
}

6. Delete INSTANCE constant from SingletonClass class.

7. You can Extract Interface (Alt+Shift+T, E) from SingletonClass. Write just new interface name, select all methods from SingletonClass which you can extract into new interface and press OK. All references to SingletonClass will be refactored to references to your newly created interface.

And that is all. Now you have SingletonClass with totally same functionality but you are able to mock it, extend or replace by different implementation setting up your instance of SingletonClass to SingletonRegistry.

11. [http://www.e-pedro.com/2010/05/refactoring-extracting-the-singleton-pattern/ Refactoring:Extracting the Singleton Pattern]

'''Topics Covered''' :
Extracting the Singleton Pattern

'''Summary''' :
Here, the author demonstrates the refactoring of Singleton Pattern by means of an example of a Device Manger class. So the main class that will be changing is the DeviceManager. This class manages a collection of Devices (or a dictionary, to be more precise) and allows to set which is the active device and to get a device by id. Note that this last feature could be handled by the Devices collection, but we are taking advantage of the dictionary to make that look-up more efficient.

11. [http://www.dotnetobject.com/Thread-Benefits-of-Singleton-Pattern-and-Drawbacks-of-Singleton-Pattern Critique of the Singleton Pattern]

'''Topics Covered''' :
Critique of the Singleton Pattern

'''Summary''' :
This link describes about the benefits like instance control and flexibility and drawbacks like overhead, development confusion and Object lifetime while using the singleton pattern.

CSC/ECE 517 Fall 2012/ch2b 2w53 iv

2012-11-19T00:21:37Z

Annice:

= Singleton, directory of sites =
===1.[http://en.wikipedia.org/wiki/Singleton_pattern Singleton on the Wikipedia]===

'''Topics Covered''' :
Common uses, UML, Implementation, Example, Prototype based singleton, Example of use with factory method pattern

'''Summary''' :
This link firstly provides the basic definition of the singleton pattern as a design pattern that restricts the instantiation of a class to one object. Singleton patters are mostly used in Abstract Factory, Builder, and Prototype, and Facade patterns.

Both the UML representation of singleton where the same single instance is always returned and the implementation concerning the mechanism to access the singleton class member without creating a class object and a mechanism to persist the value of class members among the class objects. The link also points out that if a class has to realize a contract expressed by an interface, it really has to be a singleton.

Lazy initialization uses double-checking and eager initialization which always creates an instance.
For instance, Lazy initialization and Eager Initialization example codes are:
'''Lazy Initialization''':
public class SingletonDemo {
private static volatile SingletonDemo instance = null;
private SingletonDemo() {}
public static SingletonDemo getInstance() {
if (instance == null) {
synchronized (SingletonDemo .class){
if (instance == null) {
instance = new SingletonDemo ();
}
}
}
return instance;
}
}

'''Eager Initialization''':
public class Singleton {
private static final Singleton instance = new Singleton();
private Singleton() {}
public static Singleton getInstance() {
return instance;
}
}

It also talks about Prototype-based programming in which objects but not classes are used, a 'singleton' simply refers to an object without copies or that is not used as the prototype for any other object. Eg :->
Foo := Object clone
Foo clone := Foo

'''Drawbacks''' :
The pattern makes unit testing far more difficult as it introduces global state into an application. It should also be noted that this pattern reduces the potential for parallelism within a program, because access to the singleton in a multi-threaded context must be serialized.

2. [http://www.c-sharpcorner.com/UploadFile/SukeshMarla/learn-design-pattern-singleton-pattern/ Learn Singleton-design-Pattern]

'''Topics Covered''' :
Definition, When to use, how to create, Sharing across all users, Sharing across a request, Sharing across a single user

'''Summary''' :
This article explains what Singleton pattern is, what kind of problem it generally solves and how should it be implemented in ASP.NET. The Singleton pattern which ensures that only one instance of a given object can exist at a context solves problems related to object creation and hence is a type of creational pattern.

{|
|[[File:3.jpg|x300px]]
|}

It can be used in a class that wraps the settings related to an application. In other words, whenever we want something to be shared across multiple locations, we use a singleton pattern. In order to create a Singleton pattern, we can render the constructor private so that no user can create a new instance outside the class, that way ensuring only one instance of the objects always exists. In that case, we also need to create a static method that returns the single object.

Singleton patterns in ASP.NET are implemented by using static objects which maintain their values and reside in the memory as long as the application which contains it does. The sharing can occur across users, or requests or across a single user.

3. [http://www.c-sharpcorner.com/UploadFile/faraz.rasheed/SingletonPattern12052005063955AM/SingletonPattern.aspx Singleton - Creational Design Pattern]

'''Topics Covered''' :
Intent, Description, An Example, Implementation, Benefits

'''Summary''' :
It firstly talks about the intent behind singleton design pattern, in that there is a need to have a class that can be instantiated only once.
Then, it describes two solutions for implementing the singleton class.
In the first, there should be only one shared object and reference to that shared object should be available through a static method GetInstance() while the constructor is private.
The second solution expects the constructor to be public but once an object has been instantiated, an exception should be thrown for each successive constructor call.

{|
|[[File:1.gif|x300px]]
|}

The code for each case is given as follows:

'''Case 1''' :
class Singleton
{
private static Singleton instance;
private static int numOfReference;
private string code;
private Singleton()
{
numOfReference = 0;
code = "Maasoom Faraz";
}
public static Singleton GetInstance()
{
if(instance == null)
{
instance = new Singleton();
}
numOfReference++;
return instance;
}
public static int Reference
{
get { return numOfReference; }
}
public string Code
{
get { return code; }
set { code = value;}
}
}

The constructor is made private and used to initialize the numOfReference and default value of code. GetInstance() method checks the instance, if it is null then it assign it an instance of Singleton otherwise return the old reference.

'''Case 2''' :
class Singleton2
{
private static int numOfInstance = 0;
public Singleton2()
{
if(numOfInstance == 0)
{
Console.WriteLine("\r\nCreating First Object of Singleton2 class...");
numOfInstance++;
}
else
{
throw new Exception("This class is Singleton,
+ so only one object of it can be instantiated.");
}
}
}

Here we make the constructor public and use a private field numOfInstance which is incremented for each constructor call. If numOfInstance is zero (no object is yet instantiated), a new object is allowed to made. But, if this value is not zero (there is already an object of Singleton2 class, an exception is thrown.

\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

1. [http://c2.com/cgi/wiki?SingletonPattern Singleton explained on c2.com]

'''Topics Covered''' :
Simulation of global variables, Appropriate Use of Singleton, Singleton in threaded environment

'''Summary''' :
This link firstly explains aspects like testing, creational logic,polymorphism involved in singleton pattern.It explains situations when singleton pattern can be used.It goes on to explain the anti-pattern of singletons simulating global variables and appropriate use of singleton in mutithreaded environment.

'''Problem of using Singleton in Multithreaded Environment''' :

static private synchronized Singleton instance_helper(){
_instance = new Singleton();
return _instance;
}

"_instance" can be null in the logic for multiple threads before instance_helper is called, leading to multiple instances being created

'''Solution for Singleton in Multithreaded Environment''' :

static private synchronized Singleton instance_helper()
{
if(flag)
{
_instance = new Singleton();
}
flag = false;
return _instance;
}

8. [http://www.oodesign.com/singleton-pattern.html Singleton Applications]

'''Topics Covered''' :
Motivation, Intent, Implementation, Applicability and Examples

'''Summary''' :
This link gives some extra information about applicability of Singleton in logger classes,configuration classes, accessing resources in shared environment,factories implemented as Singleton,Implementations and problems involved

'''Serialization''' :

If the Singleton class implements the java.io.Serializable interface, when a singleton is serialized and then deserialized more than once, there will be multiple instances of Singleton created. In order to avoid this the readResolve method should be implemented.

public class Singleton implements Serializable {
...
// This method is called immediately after an object of this class is deserialized.
// This method returns the singleton instance.
protected Object readResolve() {
return getInstance();
}
}

9. [http://msdn.microsoft.com/en-us/library/ff650316.aspx Singleton Implementation in C#]

'''Topics Covered''' :
Implementation in C#

'''Summary''' :
This link explains how to implement a singleton in C# both in static and threaded environment.

'''Static Initialization''':

One of the reasons Design Patterns [Gamma95] avoided static initialization is because the C++ specification left some ambiguity around the initialization order of static variables. Fortunately, the .NET Framework resolves this ambiguity through its handling of variable initialization:

public sealed class Singleton
{
private static readonly Singleton instance = new Singleton();
private Singleton(){}
public static Singleton Instance
{
get
{
return instance;
}
}
}

Implementing Singleton in C# results in the following benefits and liabilities:

'''Benefits''':
*The static initialization approach is possible because the .NET Framework explicitly defines how and when static variable initialization occurs.
*The Double-Check Locking idiom described earlier in "Multithreaded Singleton" is implemented correctly in the common language runtime.

'''Liabilities''':
If your multithreaded application requires explicit initialization, you have to take precautions to avoid threading issues.

10. [http://bosy.dailydev.org/2007/08/refactor-singleton-out-of-your-code.html Refactor Singleton Out Of Your Code]

'''Topics Covered''' :
Solution to refactor singleton

'''Summary''' :
Gang of Four mentions Singleton as an anti-pattern and not as a pattern. This Link provides a solution to refactor Singleton out of the code

'''Steps to refactor Singleton:'''
1. Create simple interface for Registry with two simple methods - getter and setter for instance of class which is currently implemented as singleton.
public interface ISingletonRegistry {
SingletonClass getSingletonClass();
void setSingletonClass(SingletonClass singleton);
}

2. Make SingletonClass's constructor public

3. Then implement the interface as a simplest Registry design pattern implementation - SingletonRegistry.

public class SingletonRegistry implements ISingletonRegistry {
private static final SingletonRegistry INSTANCE = new SingletonRegistry();
private SingletonClass singleton;
public static ISingletonRegistry getInstance() {
return INSTANCE;
}
private SingletonRegistry() {
//this is the reason why the constructor should be public
singleton = new SingletonClass();
}
public SingletonClass getSingletonClass() {
return singleton;
}
public void setSingletonClass(SingletonClass singleton) {
this.singleton = singleton;
}
}

4. Change getInstance method of SingletonClass to get instance from SingletonRegistry.
public static SingletonClass getInstance() {
return SingletonRegistry.getInstance().getSingletonClass();
}

5.The method getInstance from SingletonClass disappears and all it's client classes uses SingletonRegistry to access SingletonClass.
public class Client {
public void clientMethod() {
SingletonRegistry.getInstance() .getSingletonClass().voidMethod("param");
Object object = SingletonRegistry.getInstance() .getSingletonClass().objectMethod("param");
}
}

6. Delete INSTANCE constant from SingletonClass class.

7. You can Extract Interface (Alt+Shift+T, E) from SingletonClass. Write just new interface name, select all methods from SingletonClass which you can extract into new interface and press OK. All references to SingletonClass will be refactored to references to your newly created interface.

And that is all. Now you have SingletonClass with totally same functionality but you are able to mock it, extend or replace by different implementation setting up your instance of SingletonClass to SingletonRegistry.

11. [http://www.e-pedro.com/2010/05/refactoring-extracting-the-singleton-pattern/ Refactoring:Extracting the Singleton Pattern]

'''Topics Covered''' :
Extracting the Singleton Pattern

'''Summary''' :
Here, the author demonstrates the refactoring of Singleton Pattern by means of an example of a Device Manger class. So the main class that will be changing is the DeviceManager. This class manages a collection of Devices (or a dictionary, to be more precise) and allows to set which is the active device and to get a device by id. Note that this last feature could be handled by the Devices collection, but we are taking advantage of the dictionary to make that look-up more efficient.

<references />
*[http://catalog.lib.ncsu.edu/record/NCSU1994709 Head First Design Patterns]

CSC/ECE 517 Fall 2012/ch2b 2w53 iv

2012-11-19T00:17:03Z

Annice:

CSC/ECE 517 Fall 2012/ch2b 2w53 iv

2012-11-19T00:10:57Z

Annice:

CSC/ECE 517 Fall 2012/ch2b 2w53 iv

2012-11-19T00:09:27Z

Annice:

CSC/ECE 517 Fall 2012/ch2b 2w53 iv

2012-11-19T00:05:17Z

Annice:

=Singleton, directory of sites=
==Singleton, directory of sites Pattern==

1. [http://en.wikipedia.org/wiki/Singleton_pattern Singleton on the Wikipedia]

'''Topics Covered''' :
Common uses, UML, Implementation, Example, Prototype based singleton, Example of use with factory method pattern

'''Summary''' :
This link firstly provides the basic definition of the singleton pattern as a design pattern that restricts the instantiation of a class to one object. Singleton patters are mostly used in Abstract Factory, Builder, and Prototype, and Facade patterns.

Both the UML representation of singleton where the same single instance is always returned and the implementation concerning the mechanism to access the singleton class member without creating a class object and a mechanism to persist the value of class members among the class objects. The link also points out that if a class has to realize a contract expressed by an interface, it really has to be a singleton.

Lazy initialization uses double-checking and eager initialization which always creates an instance.
For instance, Lazy initialization and Eager Initialization example codes are:
'''Lazy Initialization''':
public class SingletonDemo {
private static volatile SingletonDemo instance = null;
private SingletonDemo() {}
public static SingletonDemo getInstance() {
if (instance == null) {
synchronized (SingletonDemo .class){
if (instance == null) {
instance = new SingletonDemo ();
}
}
}
return instance;
}
}

'''Eager Initialization''':
public class Singleton {
private static final Singleton instance = new Singleton();
private Singleton() {}
public static Singleton getInstance() {
return instance;
}
}

It also talks about Prototype-based programming in which objects but not classes are used, a 'singleton' simply refers to an object without copies or that is not used as the prototype for any other object. Eg :->
Foo := Object clone
Foo clone := Foo

'''Drawbacks''' :
The pattern makes unit testing far more difficult as it introduces global state into an application. It should also be noted that this pattern reduces the potential for parallelism within a program, because access to the singleton in a multi-threaded context must be serialized.

2. [http://www.c-sharpcorner.com/UploadFile/SukeshMarla/learn-design-pattern-singleton-pattern/ Learn Singleton-design-Pattern]

'''Topics Covered''' :
Definition, When to use, how to create, Sharing across all users, Sharing across a request, Sharing across a single user

'''Summary''' :
This article explains what Singleton pattern is, what kind of problem it generally solves and how should it be implemented in ASP.NET. The Singleton pattern which ensures that only one instance of a given object can exist at a context solves problems related to object creation and hence is a type of creational pattern.

{|
|[[File:3.jpg|x300px]]
|}

It can be used in a class that wraps the settings related to an application. In other words, whenever we want something to be shared across multiple locations, we use a singleton pattern. In order to create a Singleton pattern, we can render the constructor private so that no user can create a new instance outside the class, that way ensuring only one instance of the objects always exists. In that case, we also need to create a static method that returns the single object.

Singleton patterns in ASP.NET are implemented by using static objects which maintain their values and reside in the memory as long as the application which contains it does. The sharing can occur across users, or requests or across a single user.

3. [http://www.c-sharpcorner.com/UploadFile/faraz.rasheed/SingletonPattern12052005063955AM/SingletonPattern.aspx Singleton - Creational Design Pattern]

'''Topics Covered''' :
Intent, Description, An Example, Implementation, Benefits

'''Summary''' :
It firstly talks about the intent behind singleton design pattern, in that there is a need to have a class that can be instantiated only once.
Then, it describes two solutions for implementing the singleton class.
In the first, there should be only one shared object and reference to that shared object should be available through a static method GetInstance() while the constructor is private.
The second solution expects the constructor to be public but once an object has been instantiated, an exception should be thrown for each successive constructor call.

{|
|[[File:1.gif|x300px]]
|}

The code for each case is given as follows:

'''Case 1''' :
class Singleton
{
private static Singleton instance;
private static int numOfReference;
private string code;
private Singleton()
{
numOfReference = 0;
code = "Maasoom Faraz";
}
public static Singleton GetInstance()
{
if(instance == null)
{
instance = new Singleton();
}
numOfReference++;
return instance;
}
public static int Reference
{
get { return numOfReference; }
}
public string Code
{
get { return code; }
set { code = value;}
}
}

The constructor is made private and used to initialize the numOfReference and default value of code. GetInstance() method checks the instance, if it is null then it assign it an instance of Singleton otherwise return the old reference.

'''Case 2''' :
class Singleton2
{
private static int numOfInstance = 0;
public Singleton2()
{
if(numOfInstance == 0)
{
Console.WriteLine("\r\nCreating First Object of Singleton2 class...");
numOfInstance++;
}
else
{
throw new Exception("This class is Singleton,
+ so only one object of it can be instantiated.");
}
}
}

Here we make the constructor public and use a private field numOfInstance which is incremented for each constructor call. If numOfInstance is zero (no object is yet instantiated), a new object is allowed to made. But, if this value is not zero (there is already an object of Singleton2 class, an exception is thrown.

\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

1. [http://c2.com/cgi/wiki?SingletonPattern Singleton explained on c2.com]

'''Topics Covered''' :
Simulation of global variables, Appropriate Use of Singleton, Singleton in threaded environment

'''Summary''' :
This link firstly explains aspects like testing, creational logic,polymorphism involved in singleton pattern.It explains situations when singleton pattern can be used.It goes on to explain the anti-pattern of singletons simulating global variables and appropriate use of singleton in mutithreaded environment.

'''Problem of using Singleton in Multithreaded Environment''' :

static private synchronized Singleton instance_helper(){
_instance = new Singleton();
return _instance;
}

"_instance" can be null in the logic for multiple threads before instance_helper is called, leading to multiple instances being created

'''Solution for Singleton in Multithreaded Environment''' :

static private synchronized Singleton instance_helper()
{
if(flag)
{
_instance = new Singleton();
}
flag = false;
return _instance;
}

8. [http://www.oodesign.com/singleton-pattern.html Singleton Applications]

'''Topics Covered''' :
Motivation, Intent, Implementation, Applicability and Examples

'''Summary''' :
This link gives some extra information about applicability of Singleton in logger classes,configuration classes, accessing resources in shared environment,factories implemented as Singleton,Implementations and problems involved

'''Serialization''' :

If the Singleton class implements the java.io.Serializable interface, when a singleton is serialized and then deserialized more than once, there will be multiple instances of Singleton created. In order to avoid this the readResolve method should be implemented.

public class Singleton implements Serializable {
...
// This method is called immediately after an object of this class is deserialized.
// This method returns the singleton instance.
protected Object readResolve() {
return getInstance();
}
}

9. [http://msdn.microsoft.com/en-us/library/ff650316.aspx Singleton Implementation in C#]

'''Topics Covered''' :
Implementation in C#

'''Summary''' :
This link explains how to implement a singleton in C# both in static and threaded environment.

'''Static Initialization''':

One of the reasons Design Patterns [Gamma95] avoided static initialization is because the C++ specification left some ambiguity around the initialization order of static variables. Fortunately, the .NET Framework resolves this ambiguity through its handling of variable initialization:

public sealed class Singleton
{
private static readonly Singleton instance = new Singleton();
private Singleton(){}
public static Singleton Instance
{
get
{
return instance;
}
}
}

Implementing Singleton in C# results in the following benefits and liabilities:

'''Benefits''':
*The static initialization approach is possible because the .NET Framework explicitly defines how and when static variable initialization occurs.
*The Double-Check Locking idiom described earlier in "Multithreaded Singleton" is implemented correctly in the common language runtime.

'''Liabilities''':
If your multithreaded application requires explicit initialization, you have to take precautions to avoid threading issues.

10. [http://bosy.dailydev.org/2007/08/refactor-singleton-out-of-your-code.html Refactor Singleton Out Of Your Code]

'''Topics Covered''' :
Solution to refactor singleton

'''Summary''' :
Gang of Four mentions Singleton as an anti-pattern and not as a pattern. This Link provides a solution to refactor Singleton out of the code

'''Steps to refactor Singleton:'''
1. Create simple interface for Registry with two simple methods - getter and setter for instance of class which is currently implemented as singleton.
public interface ISingletonRegistry {
SingletonClass getSingletonClass();
void setSingletonClass(SingletonClass singleton);
}

2. Make SingletonClass's constructor public

3. Then implement the interface as a simplest Registry design pattern implementation - SingletonRegistry.

public class SingletonRegistry implements ISingletonRegistry {
private static final SingletonRegistry INSTANCE = new SingletonRegistry();
private SingletonClass singleton;
public static ISingletonRegistry getInstance() {
return INSTANCE;
}
private SingletonRegistry() {
//this is the reason why the constructor should be public
singleton = new SingletonClass();
}
public SingletonClass getSingletonClass() {
return singleton;
}
public void setSingletonClass(SingletonClass singleton) {
this.singleton = singleton;
}
}

4. Change getInstance method of SingletonClass to get instance from SingletonRegistry.
public static SingletonClass getInstance() {
return SingletonRegistry.getInstance().getSingletonClass();
}

5.The method getInstance from SingletonClass disappears and all it's client classes uses SingletonRegistry to access SingletonClass.
public class Client {
public void clientMethod() {
SingletonRegistry.getInstance() .getSingletonClass().voidMethod("param");
Object object = SingletonRegistry.getInstance() .getSingletonClass().objectMethod("param");
}
}

6. Delete INSTANCE constant from SingletonClass class.

7. You can Extract Interface (Alt+Shift+T, E) from SingletonClass. Write just new interface name, select all methods from SingletonClass which you can extract into new interface and press OK. All references to SingletonClass will be refactored to references to your newly created interface.

And that is all. Now you have SingletonClass with totally same functionality but you are able to mock it, extend or replace by different implementation setting up your instance of SingletonClass to SingletonRegistry.

<references />
*[http://catalog.lib.ncsu.edu/record/NCSU1994709 Head First Design Patterns]

CSC/ECE 517 Fall 2012/ch2b 2w53 iv

2012-11-19T00:04:20Z

Annice:

=Singleton, directory of sites=
==Singleton, directory of sites Pattern==

1. [http://en.wikipedia.org/wiki/Singleton_pattern Singleton on the Wikipedia]

'''Topics Covered''' :
Common uses, UML, Implementation, Example, Prototype based singleton, Example of use with factory method pattern

'''Summary''' :
This link firstly provides the basic definition of the singleton pattern as a design pattern that restricts the instantiation of a class to one object. Singleton patters are mostly used in Abstract Factory, Builder, and Prototype, and Facade patterns.

Both the UML representation of singleton where the same single instance is always returned and the implementation concerning the mechanism to access the singleton class member without creating a class object and a mechanism to persist the value of class members among the class objects. The link also points out that if a class has to realize a contract expressed by an interface, it really has to be a singleton.

Lazy initialization uses double-checking and eager initialization which always creates an instance.
For instance, Lazy initialization and Eager Initialization example codes are:
'''Lazy Initialization''':
public class SingletonDemo {
private static volatile SingletonDemo instance = null;
private SingletonDemo() {}
public static SingletonDemo getInstance() {
if (instance == null) {
synchronized (SingletonDemo .class){
if (instance == null) {
instance = new SingletonDemo ();
}
}
}
return instance;
}
}

'''Eager Initialization''':
public class Singleton {
private static final Singleton instance = new Singleton();
private Singleton() {}
public static Singleton getInstance() {
return instance;
}
}

It also talks about Prototype-based programming in which objects but not classes are used, a 'singleton' simply refers to an object without copies or that is not used as the prototype for any other object. Eg :->
Foo := Object clone
Foo clone := Foo

'''Drawbacks''' :
The pattern makes unit testing far more difficult as it introduces global state into an application. It should also be noted that this pattern reduces the potential for parallelism within a program, because access to the singleton in a multi-threaded context must be serialized.

2. [http://www.c-sharpcorner.com/UploadFile/SukeshMarla/learn-design-pattern-singleton-pattern/ Learn Singleton-design-Pattern]

'''Topics Covered''' :
Definition, When to use, how to create, Sharing across all users, Sharing across a request, Sharing across a single user

'''Summary''' :
This article explains what Singleton pattern is, what kind of problem it generally solves and how should it be implemented in ASP.NET. The Singleton pattern which ensures that only one instance of a given object can exist at a context solves problems related to object creation and hence is a type of creational pattern.

{|
|[[File:3.jpg|x300px]]
|}

It can be used in a class that wraps the settings related to an application. In other words, whenever we want something to be shared across multiple locations, we use a singleton pattern. In order to create a Singleton pattern, we can render the constructor private so that no user can create a new instance outside the class, that way ensuring only one instance of the objects always exists. In that case, we also need to create a static method that returns the single object.

Singleton patterns in ASP.NET are implemented by using static objects which maintain their values and reside in the memory as long as the application which contains it does. The sharing can occur across users, or requests or across a single user.

3. [http://www.c-sharpcorner.com/UploadFile/faraz.rasheed/SingletonPattern12052005063955AM/SingletonPattern.aspx Singleton - Creational Design Pattern]

'''Topics Covered''' :
Intent, Description, An Example, Implementation, Benefits

'''Summary''' :
It firstly talks about the intent behind singleton design pattern, in that there is a need to have a class that can be instantiated only once.
Then, it describes two solutions for implementing the singleton class.
In the first, there should be only one shared object and reference to that shared object should be available through a static method GetInstance() while the constructor is private.
The second solution expects the constructor to be public but once an object has been instantiated, an exception should be thrown for each successive constructor call.

{|
|[[File:1.gif|x300px]]
|}

The code for each case is given as follows:

'''Case 1''' :
class Singleton
{
private static Singleton instance;
private static int numOfReference;
private string code;
private Singleton()
{
numOfReference = 0;
code = "Maasoom Faraz";
}
public static Singleton GetInstance()
{
if(instance == null)
{
instance = new Singleton();
}
numOfReference++;
return instance;
}
public static int Reference
{
get { return numOfReference; }
}
public string Code
{
get { return code; }
set { code = value;}
}
}

The constructor is made private and used to initialize the numOfReference and default value of code. GetInstance() method checks the instance, if it is null then it assign it an instance of Singleton otherwise return the old reference.

'''Case 2''' :
class Singleton2
{
private static int numOfInstance = 0;
public Singleton2()
{
if(numOfInstance == 0)
{
Console.WriteLine("\r\nCreating First Object of Singleton2 class...");
numOfInstance++;
}
else
{
throw new Exception("This class is Singleton,
+ so only one object of it can be instantiated.");
}
}
}

Here we make the constructor public and use a private field numOfInstance which is incremented for each constructor call. If numOfInstance is zero (no object is yet instantiated), a new object is allowed to made. But, if this value is not zero (there is already an object of Singleton2 class, an exception is thrown.

\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

1. [http://c2.com/cgi/wiki?SingletonPattern Singleton explained on c2.com]

'''Topics Covered''' :
Simulation of global variables, Appropriate Use of Singleton, Singleton in threaded environment

'''Summary''' :
This link firstly explains aspects like testing, creational logic,polymorphism involved in singleton pattern.It explains situations when singleton pattern can be used.It goes on to explain the anti-pattern of singletons simulating global variables and appropriate use of singleton in mutithreaded environment.

'''Problem of using Singleton in Multithreaded Environment''' :

static private synchronized Singleton instance_helper(){
_instance = new Singleton();
return _instance;
}

"_instance" can be null in the logic for multiple threads before instance_helper is called, leading to multiple instances being created

'''Solution for Singleton in Multithreaded Environment''' :

static private synchronized Singleton instance_helper()
{
if(flag)
{
_instance = new Singleton();
}
flag = false;
return _instance;
}

8. [http://www.oodesign.com/singleton-pattern.html Singleton Applications]

'''Topics Covered''' :
Motivation, Intent, Implementation, Applicability and Examples

'''Summary''' :
This link gives some extra information about applicability of Singleton in logger classes,configuration classes, accessing resources in shared environment,factories implemented as Singleton,Implementations and problems involved

'''Serialization''' :

If the Singleton class implements the java.io.Serializable interface, when a singleton is serialized and then deserialized more than once, there will be multiple instances of Singleton created. In order to avoid this the readResolve method should be implemented.

public class Singleton implements Serializable {
...
// This method is called immediately after an object of this class is deserialized.
// This method returns the singleton instance.
protected Object readResolve() {
return getInstance();
}
}

9. [http://msdn.microsoft.com/en-us/library/ff650316.aspx Singleton Implementation in C#]

'''Topics Covered''' :
Implementation in C#

'''Summary''' :
This link explains how to implement a singleton in C# both in static and threaded environment.

'''Static Initialization''':

One of the reasons Design Patterns [Gamma95] avoided static initialization is because the C++ specification left some ambiguity around the initialization order of static variables. Fortunately, the .NET Framework resolves this ambiguity through its handling of variable initialization:

public sealed class Singleton
{
private static readonly Singleton instance = new Singleton();
private Singleton(){}
public static Singleton Instance
{
get
{
return instance;
}
}
}

Implementing Singleton in C# results in the following benefits and liabilities:

'''Benefits''':
*The static initialization approach is possible because the .NET Framework explicitly defines how and when static variable initialization occurs.
*The Double-Check Locking idiom described earlier in "Multithreaded Singleton" is implemented correctly in the common language runtime.

'''Liabilities''':
If your multithreaded application requires explicit initialization, you have to take precautions to avoid threading issues.

10. [bosy.dailydev.org/2007/08/refactor-singleton-out-of-your-code.html Refactor Singleton Out Of Your Code]

'''Topics Covered''' :
Solution to refactor singleton

'''Summary''' :
Gang of Four mentions Singleton as an anti-pattern and not as a pattern. This Link provides a solution to refactor Singleton out of the code

'''Steps to refactor Singleton:'''
1. Create simple interface for Registry with two simple methods - getter and setter for instance of class which is currently implemented as singleton.
public interface ISingletonRegistry {
SingletonClass getSingletonClass();
void setSingletonClass(SingletonClass singleton);
}

2. Make SingletonClass's constructor public

3. Then implement the interface as a simplest Registry design pattern implementation - SingletonRegistry.

public class SingletonRegistry implements ISingletonRegistry {
private static final SingletonRegistry INSTANCE = new SingletonRegistry();
private SingletonClass singleton;
public static ISingletonRegistry getInstance() {
return INSTANCE;
}
private SingletonRegistry() {
//this is the reason why the constructor should be public
singleton = new SingletonClass();
}
public SingletonClass getSingletonClass() {
return singleton;
}
public void setSingletonClass(SingletonClass singleton) {
this.singleton = singleton;
}
}

4. Change getInstance method of SingletonClass to get instance from SingletonRegistry.
public static SingletonClass getInstance() {
return SingletonRegistry.getInstance().getSingletonClass();
}

5.The method getInstance from SingletonClass disappears and all it's client classes uses SingletonRegistry to access SingletonClass.
public class Client {
public void clientMethod() {
SingletonRegistry.getInstance() .getSingletonClass().voidMethod("param");
Object object = SingletonRegistry.getInstance() .getSingletonClass().objectMethod("param");
}
}

6. Delete INSTANCE constant from SingletonClass class.

7. You can Extract Interface (Alt+Shift+T, E) from SingletonClass. Write just new interface name, select all methods from SingletonClass which you can extract into new interface and press OK. All references to SingletonClass will be refactored to references to your newly created interface.

And that is all. Now you have SingletonClass with totally same functionality but you are able to mock it, extend or replace by different implementation setting up your instance of SingletonClass to SingletonRegistry.

<references />
*[http://catalog.lib.ncsu.edu/record/NCSU1994709 Head First Design Patterns]

CSC/ECE 517 Fall 2012/ch2b 2w53 iv

2012-11-18T22:57:25Z

Annice:

=Singleton, directory of sites=
==Singleton, directory of sites Pattern==

1. [http://en.wikipedia.org/wiki/Singleton_pattern Singleton on the Wikipedia]

'''Topics Covered''' :
Common uses, UML, Implementation, Example, Prototype based singleton, Example of use with factory method pattern

'''Summary''' :
This link firstly provides the basic definition of the singleton pattern as a design pattern that restricts the instantiation of a class to one object. Singleton patters are mostly used in Abstract Factory, Builder, and Prototype, and Facade patterns.

Both the UML representation of singleton where the same single instance is always returned and the implementation concerning the mechanism to access the singleton class member without creating a class object and a mechanism to persist the value of class members among the class objects. The link also points out that if a class has to realize a contract expressed by an interface, it really has to be a singleton.

Lazy initialization uses double-checking and eager initialization which always creates an instance.
For instance, Lazy initialization and Eager Initialization example codes are:
'''Lazy Initialization''':
public class SingletonDemo {
private static volatile SingletonDemo instance = null;
private SingletonDemo() {}
public static SingletonDemo getInstance() {
if (instance == null) {
synchronized (SingletonDemo .class){
if (instance == null) {
instance = new SingletonDemo ();
}
}
}
return instance;
}
}

'''Eager Initialization''':
public class Singleton {
private static final Singleton instance = new Singleton();
private Singleton() {}
public static Singleton getInstance() {
return instance;
}
}

It also talks about Prototype-based programming in which objects but not classes are used, a 'singleton' simply refers to an object without copies or that is not used as the prototype for any other object. Eg :->
Foo := Object clone
Foo clone := Foo

'''Drawbacks''' :
The pattern makes unit testing far more difficult as it introduces global state into an application. It should also be noted that this pattern reduces the potential for parallelism within a program, because access to the singleton in a multi-threaded context must be serialized.

2. [http://www.c-sharpcorner.com/UploadFile/SukeshMarla/learn-design-pattern-singleton-pattern/ Learn Singleton-design-Pattern]

'''Topics Covered''' :
Definition, When to use, how to create, Sharing across all users, Sharing across a request, Sharing across a single user

'''Summary''' :
This article explains what Singleton pattern is, what kind of problem it generally solves and how should it be implemented in ASP.NET. The Singleton pattern which ensures that only one instance of a given object can exist at a context solves problems related to object creation and hence is a type of creational pattern.

{|
|[[File:3.jpg|x300px]]
|}

It can be used in a class that wraps the settings related to an application. In other words, whenever we want something to be shared across multiple locations, we use a singleton pattern. In order to create a Singleton pattern, we can render the constructor private so that no user can create a new instance outside the class, that way ensuring only one instance of the objects always exists. In that case, we also need to create a static method that returns the single object.

Singleton patterns in ASP.NET are implemented by using static objects which maintain their values and reside in the memory as long as the application which contains it does. The sharing can occur across users, or requests or across a single user.

3. [http://www.c-sharpcorner.com/UploadFile/faraz.rasheed/SingletonPattern12052005063955AM/SingletonPattern.aspx Singleton - Creational Design Pattern]

'''Topics Covered''' :
Intent, Description, An Example, Implementation, Benefits

'''Summary''' :
It firstly talks about the intent behind singleton design pattern, in that there is a need to have a class that can be instantiated only once.
Then, it describes two solutions for implementing the singleton class.
In the first, there should be only one shared object and reference to that shared object should be available through a static method GetInstance() while the constructor is private.
The second solution expects the constructor to be public but once an object has been instantiated, an exception should be thrown for each successive constructor call.

{|
|[[File:1.gif|x300px]]
|}

The code for each case is given as follows:

'''Case 1''' :
class Singleton
{
private static Singleton instance;
private static int numOfReference;
private string code;
private Singleton()
{
numOfReference = 0;
code = "Maasoom Faraz";
}
public static Singleton GetInstance()
{
if(instance == null)
{
instance = new Singleton();
}
numOfReference++;
return instance;
}
public static int Reference
{
get { return numOfReference; }
}
public string Code
{
get { return code; }
set { code = value;}
}
}

The constructor is made private and used to initialize the numOfReference and default value of code. GetInstance() method checks the instance, if it is null then it assign it an instance of Singleton otherwise return the old reference.

'''Case 2''' :
class Singleton2
{
private static int numOfInstance = 0;
public Singleton2()
{
if(numOfInstance == 0)
{
Console.WriteLine("\r\nCreating First Object of Singleton2 class...");
numOfInstance++;
}
else
{
throw new Exception("This class is Singleton,
+ so only one object of it can be instantiated.");
}
}
}

Here we make the constructor public and use a private field numOfInstance which is incremented for each constructor call. If numOfInstance is zero (no object is yet instantiated), a new object is allowed to made. But, if this value is not zero (there is already an object of Singleton2 class, an exception is thrown.

\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

1. [http://c2.com/cgi/wiki?SingletonPattern Singleton explained on c2.com]

'''Topics Covered''' :
Simulation of global variables, Appropriate Use of Singleton, Singleton in threaded environment

'''Summary''' :
This link firstly explains aspects like testing, creational logic,polymorphism involved in singleton pattern.It explains situations when singleton pattern can be used.It goes on to explain the anti-pattern of singletons simulating global variables and appropriate use of singleton in mutithreaded environment.

'''Problem of using Singleton in Multithreaded Environment''' :

static private synchronized Singleton instance_helper(){
_instance = new Singleton();
return _instance;
}

"_instance" can be null in the logic for multiple threads before instance_helper is called, leading to multiple instances being created

'''Solution for Singleton in Multithreaded Environment''' :

static private synchronized Singleton instance_helper()
{
if(flag)
{
_instance = new Singleton();
}
flag = false;
return _instance;
}

8. [http://www.oodesign.com/singleton-pattern.html Singleton Applications]

'''Topics Covered''' :
Motivation, Intent, Implementation, Applicability and Examples

'''Summary''' :
This link gives some extra information about applicability of Singleton in logger classes,configuration classes, accessing resources in shared environment,factories implemented as Singleton,Implementations and problems involved

'''Serialization''' :

If the Singleton class implements the java.io.Serializable interface, when a singleton is serialized and then deserialized more than once, there will be multiple instances of Singleton created. In order to avoid this the readResolve method should be implemented.

public class Singleton implements Serializable {
...
// This method is called immediately after an object of this class is deserialized.
// This method returns the singleton instance.
protected Object readResolve() {
return getInstance();
}
}

9. [http://msdn.microsoft.com/en-us/library/ff650316.aspx Singleton Implementation in C#]

'''Topics Covered''' :
Implementation in C#

'''Summary''' :
This link explains how to implement a singleton in C# both in static and threaded environment.

'''Static Initialization''':

One of the reasons Design Patterns [Gamma95] avoided static initialization is because the C++ specification left some ambiguity around the initialization order of static variables. Fortunately, the .NET Framework resolves this ambiguity through its handling of variable initialization:

public sealed class Singleton
{
private static readonly Singleton instance = new Singleton();
private Singleton(){}
public static Singleton Instance
{
get
{
return instance;
}
}
}

Implementing Singleton in C# results in the following benefits and liabilities:

'''Benefits''':
*The static initialization approach is possible because the .NET Framework explicitly defines how and when static variable initialization occurs.
*The Double-Check Locking idiom described earlier in "Multithreaded Singleton" is implemented correctly in the common language runtime.

'''Liabilities''':
If your multithreaded application requires explicit initialization, you have to take precautions to avoid threading issues.

<references />
*[http://catalog.lib.ncsu.edu/record/NCSU1994709 Head First Design Patterns]

CSC/ECE 517 Fall 2012/ch2b 2w53 iv

2012-11-18T22:33:26Z

Annice:

CSC/ECE 517 Fall 2012/ch2b 2w53 iv

2012-11-18T14:26:06Z

Annice:

CSC/ECE 517 Fall 2012/ch2b 2w53 iv

2012-11-18T14:24:36Z

Annice:

CSC/ECE 517 Fall 2012/ch2b 2w53 iv

2012-11-18T14:18:06Z

Annice:

CSC/ECE 517 Fall 2012/ch2b 2w53 iv

2012-11-17T19:31:54Z

Annice: Replaced content with "=Singleton, directory of sites= ==Singleton, directory of sites Pattern== ===Introduction=== ===Principle=== ===Advantages of Singleton, directory of sites Pattern=== ..."

=Singleton, directory of sites=
==Singleton, directory of sites Pattern==

===Introduction===

===Principle===

===Advantages of Singleton, directory of sites Pattern===

===Examples===

==References==

<references />
*[http://catalog.lib.ncsu.edu/record/NCSU1994709 Head First Design Patterns]

CSC/ECE 517 Fall 2012/ch2b 2w53 iv

2012-11-17T19:26:05Z

Annice: Created page with "=Mediator and related patterns= ==Mediator Pattern== ===Introduction=== Mediator pattern comes under the category of behavioral pattern<ref name="wikibehav">http://en.wikipedia...."

=Mediator and related patterns=
==Mediator Pattern==
===Introduction===

Mediator pattern comes under the category of behavioral pattern<ref name="wikibehav">http://en.wikipedia.org/wiki/Behavioral_pattern </ref>. It specifies an object that includes the encapsulation about the interaction among various objects.

It prevents objects to interact with each other explicitly and thus it facilitates loose coupling<ref name="wikiloosecoupling">http://en.wikipedia.org/wiki/Loose_coupling </ref>. In other words it handles complex communication among related objects. All the objects communicate with the mediator when they want to interact with each other. Thus it improves maintainability.

All the classes which interact with the mediator are called colleagues. These colleagues know who their mediator is and the mediator also knows which colleagues can interact with it. The colleagues send messages to the mediator object. The mediator sends message to other classes. Thus the object which initiated this communication does not need to have knowledge about other objects. All they need to know is about their mediator who is responsible to carry out this communication.

Following classes/objects take part in this process:

'''Mediator''': Provides interface for communication among colleagues.

'''Concrete Mediator''': It coordinates the colleagues and implements cooperative behavior. It also holds information about the colleagues.

'''Colleague Classes''': Colleague classes know about their mediator.

A real life example of mediator pattern can be of an airport control tower. It is the job of this tower to control all the planes. It decides which plane will take-off and land at what time rather than plane to plane communication.

===Case1: Without the use of Mediator Pattern===
[[File:Image1_womediator1.png|650 px|thumb|right|Example: Without using Mediator Pattern]]

In this example, there are four departments of a hospital, namely :Pathology, Radiology, Surgery and Physiology. When one department needs some data from another department, they need to explicitly contact the other department for that data. Since these departments directly interact with each other, the communication between these parties is very complex and results in high coupling.

For Example: When the Pathology department needs X-Ray report from the Sonography department it calls the 'getXRay()' method. Similarly, there are other methods which are often required by other departments.

===Case2: With the use of Mediator Pattern===
[[File:Image2_withmediator.png|650 px|thumb|right|Example: Using Mediator Pattern]]

To reduce coupling in the above example we add a Hospital Management Mediator which sits in between all the departments and all the communication among them is handled by the mediator. The control logic of the entire system is included in the mediator.

Whenever a new department is added or some functionality of an existing department needs to be changed, only the mediator control logic needs to be modified.
This facilitates loose coupling as the departments do not need to communicate with each other explicitly. They also do not need to know about internal details of other departments.

For example: the 'getXRay()' method of the Pathology department is now inside the Hospital Management Mediator and is called only of the patient is of type 'Pathology Patient'.

===Advantages of Mediator Pattern===
* It facilitates re-usability of objects. It is possible due to the fact that objects are decoupled from the system.
* Overall maintenance of the system gets simplified because the control logic is encapsulated in the mediator.

==Facade Pattern==
A Facade design pattern provides a unified interface to a larger body of code. It is a structural pattern<ref name="wikistructural">http://en.wikipedia.org/wiki/Structural_pattern </ref>. This makes the use of subsystem easy. This pattern wraps the complicated subsystem with a simple interface. A facade pattern shields users from the complex inner details of the subsystem. Example of facade pattern could be of a web service where users can get access to the small services without knowing anything about their internal structures. They just need an interface which facade pattern provides.

===Example===
For the same example as discussed above let us see how a facade pattern looks.

[[File:image3_facadepattern.png|650 px|thumb|right|Example: Using Facade Pattern]]

In this case a facade pattern provides an interface to the patients through which he can interact with the departments. The internal details of the departments are hidden from the patient. So whenever he needs to get any service from any of the department he only communicates with the interface. The patient may not be provided with all the functionality and he is exposed to only certain functionality.

In this example, the patient has access to the facade interface and can only call the 'getFullReport()' method to obtain the checkup reports. The 'getFullReport()' method in turn calls various methods of various departments. Thus the patient is unaware of the implementation of these methods.

==Comparison of mediator pattern with facade pattern==
*Mediator pattern is a behavioral pattern whereas facade pattern is a structural pattern.

*Mediator pattern adds extra functionality whereas facade pattern doesn’t add any extra functionality. It only provides an interface to an existing subsystem.

*The components of a subsystem do not have any knowledge about the facade whereas the colleagues have the knowledge of the mediator.

So if we see the above examples we can clearly understand that mediator pattern avoids coupling within a sub-system whereas facade pattern avoids coupling between sub-system and between sub-system and an external entity.

==Observer Pattern==

In an observer pattern an object maintains a list of all its dependents. Thus if any state changes occurs the object notifies all the dependents. The state of an object is an important concern. Whenever state change occurs the objects are updated automatically. All the common components are maintained in an abstraction called ‘subject’ whereas all the variable components are maintained in an abstraction called ‘object’. It is also known as publish-subscribe pattern. One example of observer pattern can be an event management process. Whenever an event takes place it should be notified to all other objects so that their state gets updated.

===Example===

[[File:image3_observer.png|650 px|thumb|right|Example: Using Observer Pattern]]

In this case there is one subject and three dependent objects. The Hospital Management Subject implements the Subject interface. The three dependents/observers are Radiology, Physiology, and Surgery and they implement the Observer interface. The Hospital Management Subject includes a method 'getBloodCount()' which sets the value of blood count variable.

Whenever the value of this variable for a particular patient changes the observers get notified of the change because they are registered with the subject. The 'notify()' method calls the 'update()' method on the observer which sets the value in the observer objects.

==Comparison of mediator pattern with observer pattern==
*The mediator pattern differs from observer pattern in terms of usage. In order to avoid explicit communication between two or more objects mediator is used. Whereas observer pattern is used in situations where an object changes its state all its dependents are notified and updated automatically to reflect this change.

==References==

<references />
*[http://catalog.lib.ncsu.edu/record/NCSU1994709 Head First Design Patterns]
*[http://en.wikipedia.org/wiki/Mediator_pattern Mediator Pattern]
*[http://www.blackwasp.co.uk/Mediator.aspx Mediator Design Pattern]
*[http://en.wikipedia.org/wiki/Facade_pattern Facade Pattern]
*[http://en.wikipedia.org/wiki/Observer_pattern Observer Pattern]

CSC/ECE 517 Fall 2012

2012-11-17T19:25:09Z

Annice:

*[[CSC/ECE_517_Fall_2012/Table_Of_Contents]]
*[[CSC/ECE 517 Fall 2012/ch1 n xx]]
*[[CSC/ECE 517 Fall 2012/ch1 1w1 rk]]
*[[CSC/ECE 517 Fall 2012/ch1 1w20 pp]]
*[[CSC/ECE 517 Fall 2012/ch1 1w5 su]]
*[[CSC/ECE 517 Fall 2012/ch1 1w6 pp]]
*[[CSC/ECE 517 Fall 2012/ch1 1w4 aj]]
*[[CSC/ECE 517 Fall 2012/ch1 1w7 am]]
*[[CSC/ECE 517 Fall 2012/ch1 1w8 aa]]
*[[CSC/ECE 517 Fall 2012/ch1 1w9 av]]
*[[CSC/ECE 517 Fall 2012/ch1 1w10 pk]]
*[[CSC/ECE 517 Fall 2012/ch1 1w11 ap]]
*[[CSC/ECE 517 Fall 2012/ch1a 1w12 mv]]
*[[CSC/ECE 517 Fall 2012/ch1 1w14 gv]]
*[[CSC/ECE 517 Fall 2012/ch1 1w17 ir]]
*[[CSC/ECE 517 Fall 2012/ch1 1w18 as]]
*[[CSC/ECE 517 Fall 2012/ch1 1w22 an]]
*[[CSC/ECE 517 Fall 2012/ch1 1w21 aa]]
*[[CSC/ECE 517 Fall 2012/ch1 1w21 wi]]
*[[CSC/ECE 517 Fall 2012/ch1 1w31 sa]]
*[[CSC/ECE 517 Fall 2012/ch1a 1w16 br]]
*[[CSC/ECE 517 Fall 2012/ch1a 1w23 as]]
*[[CSC/ECE 517 Fall 2012/ch1 1w24 nr]]
*[[CSC/ECE 517 Fall 2012/ch1 1w15 rt]]
*[[CSC/ECE 517 Fall 2012/ch1 1w3 pl]]
*[[CSC/ECE 517 Fall 2012/ch1 1w32 cm]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w5 dp]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w37 ss]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w67 ks]]

*[[CSC/ECE 517 Fall 2012/ch1 1w27 ms]]
*[[CSC/ECE 517 Fall 2012/ch1 1w29 sa]]
*[[CSC/ECE 517 Fall 2012/ch1 1w33 op]]
*[[CSC/ECE 517 Fall 2012/ch1 1w19 sa]]
*[[CSC/ECE 517 Fall 2012/ch1 1w34 vd]]
*[[CSC/ECE 517 Fall 2012/ch1 1w35 sa]]
*[[CSC/ECE 517 Fall 2012/ch1 1w30 rp]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w58 am]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w47 sk]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w69 mv]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w44 as]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w45 is]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w53 kc]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w40 ar]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w39 sn]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w54 go]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w56 ms]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w64 nn]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w66 as]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w40 as]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w42 js]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w46 sm]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w71 gs]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w63 dv]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w55 ms]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w57 mp]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w52 an]]
*[[CSC/ECE_517_Fall_2012/ch1b 1w38 nm]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w60 ac]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w62 rb]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w29 st]]
*[[CSC/ECE_517_Fall_2012/ch2a_2w3_sm]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w30 an]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w17 pt]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w31 up]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w9 ms]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w19 is]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w26 aj]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w5 dp]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w16 dp]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w8 vp]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w18 as]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w3 jm]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w23 sr]]
*[[CSC/ECE_517_Fall_2012/ch2a_2w11_aa]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w15 rr]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w33 pv]]
*[[CSC/ECE_517_Fall_2012/ch2a_2w20_aa]]
*[[CSC/ECE_517_Fall_2012/ch2a_2w14_bb]]
*[[CSC/ECE_517_Fall_2012/ch2a_2w21_ap]]
*[[CSC/ECE_517_Fall_2012/ch2a_2w13_sm]]
*[[CSC/ECE_517_Fall_2012/ch2a_2w4_sa]]
*[[CSC/ECE_517_Fall_2012/ch2a_2w25_nr]]
*[[CSC/ECE_517_Fall_2012/ch2a_2w12_sv]]
*[[CSC/ECE_517_Fall_2012/ch2a_2w7_ma]]
*[[CSC/ECE_517_Fall_2012/ch2a_2w6_ar]]
*[[CSC/ECE_517_Fall_2012/ch2a_2w32_mk]]
*[[CSC/ECE_517_Fall_2012/ch2a_2w10_rc]]
*[[CSC/ECE 517 Fall 2012/ch2b_2w70_sm]]
*[[CSC/ECE 517 Fall 2012/ch2b_2w67_sk]]
*[[CSC/ECE 517 Fall 2012/ch2b_2w40_sn]]
*[[CSC/ECE 517 Fall 2012/ch2b_2w22_sk]]
*[[CSC/ECE 517 Fall 2012/ch2b_2w-1w65_am]]
*[[CSC/ECE 517 Fall 2012/ch2b_2w59_bc]]
*[[CSC/ECE 517 Fall 2012/ch2b_2w60_ns]]
*[[CSC/ECE 517 Fall 2012/ch2b_2w69_as]]
*[[CSC/ECE 517 Fall 2012/ch2b_2w39_ka]]
*[[CSC/ECE 517 Fall 2012/ch2b_2w36_av]]
*[[CSC/ECE 517 Fall 2012/ch2b_2w37_ms]]
*[[CSC/ECE 517 Fall 2012/ch2b_2w43_iv]]
*[[CSC/ECE 517 Fall 2012/ch2b_2w53_iv]]

CSC/ECE 517 Fall 2012/ch2a 2w11 aa

2012-10-25T18:29:01Z

Annice: /* Steps */

=Introduction=
Test driven development (TDD) is a process that tries to create the minimal amount of code to meet customer's expectations. The idea is to test first, code second, then improve (or refactor) last. This process forces the software developers to focus on customer specifications and validation first. Since at each step of the way the programmer proves to himself that the code meets specifications, TDD gives the programmer confidence. The rest of this chapter gives the motivation for TDD, shows the steps for TDD, outlines the principles of TDD, provides examples using TDD, and compares the pros and cons of TDD.

=Motivation for TDD=

There are two main motivations for TDD.

[[File:CostofChange.png|550px|Thumb:Figure 1: Traditional "Cost of Change" curve with the waterfall model superimposed]]

*Testing is the one activity that improves the quality of code. In various design scenarios, like waterfall model, testing occurs towards the end of the project development activity. As shown in the figure 1, introducing testing as a latter phase increases the cost incurred for implementing the changes. From this we infer that there is a high chance of reducing the costs by moving the Test phase to the initial part.
*The client can also be well informed about the design and can suggest changes which can be incorporated well in advance. This approach also known as TDD helps achieve flexibility to achieve the client’s ever-changing requirements

=Principles=

TDD follows several principles:

*Tests serve as examples of how to use a class or method. Once used to having tests that show how things work (and that they work), developers start inquiring if a test was already there for the piece of code to be developed
*Developer tests are distinctly different from QA (Quality Analysis) tests and should be kept separate. QA tests target features and treat the system as a black box. Unit tests created by the developer operate at a lower level and test different things.
*Name the tests carefully. For Example, name test packages like the package being tested with a suffix. For example, the "DataAccess" project/package is tested by "DataAccess.Test". Also, name test classes the same as the class under test with the suffix "Test". For example, the class "PrintManager" is tested by the test class "PrintManagerTest". This convention makes it easy to find the related class and keeps the class name a noun. You should also name test methods the same as the method being tested with the prefix "Test". For example, the method "PrintProductOrder()" is tested by the method "TestPrintProductOrder()". This convention keeps the method name a verb that reads as an english phrase.
*Write each test before writing the method under test. It encourages the developer to think as a user of the target method before thinking about implementation, which usually results in a cleaner, easier-to-use interface.
*Follow the "3-As" pattern for test methods: Arrange, Act, Assert. Specifically, use separate code paragraphs (groups of lines of code separated by a blank line) for each of the As. Arrange is variable declaration and initialization. Act is invoking the code under test. Assert is using the Assert.* methods to verify that expectations were met.
*When writing application code, only write enough code to make a test work. This technique prevents gold-plating and ensures that you always have a test for the code you write.
*When you find you need to refractor working code, refractor and re-test prior to writing new code. This technique ensures your refractoring is correct prior to adding new functionality and applies to creating new methods, introducing inheritance, everything.

=Steps=
[[File:TDD_Steps.png|550px|Thumb:Figure 1: Traditional "Cost of Change" curve with the waterfall model superimposed]]

Follow these steps:
*Understand the requirements of the story, work item, or feature that you are working on.
*Red:Create a test and make it fail.
Imagine how the new code should be called and write the test as if the code already existed.
Create the new production code stub. Write just enough code so that it compiles.
Run the test. It should fail. This is a calibration measure to ensure that your test is calling the correct code and that the code is not working by accident. This is a meaningful failure, and you expect it to fail.
*Green: Make the test pass by any means necessary.
Write the production code to make the test pass. Keep it simple.
Some advocate the hard-coding of the expected return value first to verify that the test correctly detects success. This varies from practitioner to practitioner.If you've written the code so that the test passes as intended, you are finished. You do not have to write more code speculatively. If new functionality is still needed, then another test is needed. Make this one test pass and continue.
When the test passes, you might want to run all tests up to this point to build confidence that everything else is still working.
*Refractor: Change the code to remove duplication in your project and to improve the design while ensuring that all tests still pass.
Remove duplication caused by the addition of the new functionality.
Make design changes to improve the overall solution.
After each refactoring, rerun all the tests to ensure that they all still pass.
*Repeat the cycle. Each cycle should be very short, and a typical hour should contain many Red/Green/ Refractor cycles.

=Examples=

==Homework Grades Program==

===Setup===
As a simple example, we are creating a program that keeps track of our homework grades. We envision that we would be able to get the average of these homework grades. Step one: write a test . Let's test an average function

<pre>
myHomework = new Homework();
myHomework.grades = [100, 50];
assert(myHomework.average(myHomework.grades) == 75);
</pre>

We will get multiple errors - this test won't even compile (but, that's ok for now). Let's take a look at what will generate error messages:

* class <code>Homework</code> not declared
* <code>Homework</code> constructor not declared
* field <code>grades</code> not declared
* method <code>average</code> not declared

Now, we fix the first error:

<pre>
class Homework {

}
</pre>

Second error:

<pre>
Homework(void) {

}
</pre>

Third error:

<pre>
int * grades;
</pre>

Fourth error:

<pre>
int average(int * grades) {
return 0; // default return value
}
</pre>

Finally, the test compiles! The code now looks like this:

<pre>
class Homework {

int * grades;

Homework(void) {

}

int average(int * grades) {

return 0; // default return value

}

}
</pre>

===Red===
Now, we run the test, and the familar red bar of failure greets us (remember the mantra red-green-refactor). The assert fails. The average function needs to actually average something (not just return 0). As we think about averaging the grades, we realize we need to know how many grades are in the int array <code>grades</code>. So, we add to the code:

<pre>
class Homework {

int * grades;
int numGrades; // new

Homework(void) {

}

int average(int * grades) {

int avg = 0; // new

for(int i = 0; i < numGrades; i++) { // new
avg += grades[i]; // new
} // new

return avg/numGrades; // new

}

}
</pre>

Of course, we must remember to change the test to:

<pre>
myHomework = new Homework();
myHomework.grades = [100, 50];
myHomework.numGrades = 2;
assert(myHomework.average(myHomework.grades) == 75);
</pre>

===Green===
Success! We have a green bar when we run it.

===Refactor===
The last step is refactoring. Perhaps we don't want a grade to be an <code>int</code>? Should it be an <code>unsigned int</code>? For this simple example, there isn't much refactoring to do, but in a larger example there may be multiple areas for improvement.

==Refactoring Example==
The following example is take from Test-Driven Development by Example by Kent Beck.

Using the TDD process the author created an object with the following structure:

<pre>
class Dollar {

Dollar(int amount) {
this.amount = amount;
}

void times(int mulitplier) {
amount *= multiplier;
}

}
</pre>

What's wrong with the code above? Look at the following test:

<pre>
public void testMultiplication() {

Dollar five = new Dollar(5);
five.times(2);
assertEquals(10, five.amount);
five.times(3);
assertEquals(15, five.amount);

}
</pre>

Whenever we perform an operation on a <code>Dollar</code> the value of the <code>Dollar</code> changes. In the test above <code>five</code> isn't 5 after we multiply it by 2, and thus the name <code>five</code> doesn't make sense anymore. How do we change this?

===Red===

First, we change the test.

<pre>
public void testMultiplication() {
Dollar five = new Dollar(5);
Dollar product = five.times(2);
assertEquals(10, product.amount);
product = five.times(3);
assertEquals(15, product.amount);
}
</pre>

The new test won't compile until we change the code:

<pre>
Dollar times(int multiplier) {
amount *= multiplier;
return null;
}
</pre>

Now the test compiles, but fails. Once again, we change the code:

<pre>
Dollar times(int multiplier) {
return new Dollar(amount * multiplier);
}
</pre>

===Green===

The test succeeds. So we see that even when we are refactoring we change the test first, then the code. This way we know our refactoring is an improvement.

==More Examples==
See Test-Driven Development by Example by Kent Beck for more examples.

=Characteristics Of A Good Unit Test=
A good unit test has the following characteristics.
*It is important that the test executes fast. If the tests are slow, they will not be run often.
*Environmental dependencies such as databases, file systems, networks, queues, and so on which will slow down the tests are either separated or simulated. Tests that exercise these will not run fast, and a failure does not give meaningful feedback about what the problem actually is.
*The scope of testing is very limited. If the test fails, it's obvious where to look for the problem. It's important to only test one aspect in a single test.
*The test should run and pass in isolation (on any machine). If the tests require special environmental setup or fail unexpectedly, then they are not good unit tests.
*Such a test often uses stubs and mock objects. If the code being tested typically calls out to a database or file system, these dependencies must be simulated, or mocked. These dependencies will ordinarily be abstracted away by using interfaces.
*The intention of testing is clearly revealed. Another developer can look at the test and understand what is expected of the production code.

=Benefits Of TDD=

Using TDD has many benefits.

*Automated testing: Automated system makes the testing much more easier and faster. Manual testing is slower and needs human interaction which is error-prone. Automated testing makes sure any particular test is not missing every time we test the system, whereas humans may leave a test out mistakenly during testing process.
*Better to test New/Modified Functionality: With manual testing whenever you add new functionality or modify existing functionality, QA personal needs to test all systems that may be affected due to the modification which may be time-consuming. This may also leave a hidden bug in the system after modification. With TDD whenever a new functionality is added or existing functionality is modified, the whole set of tests in the system is run to make sure existing tests are passed. This makes sure that existing functionality is not broken.
*Developer’s confidence: With TDD, developers are more safe to change the system as any inappropriate changes will make some tests to fail. With non-TDD system developers needs to take more care to change existing system as the new change may fail other functionality. But with TDD developers can do so easily as after modification if developer runs the test he/she will find immediately that the change has failed some other tests (i.e. some other part of the system).
*Manual testing stage is shortened: In non-TDD development, as soon as developers prepare a build, QA personal starts testing. This manual testing takes a reasonable amount of time and increases the time to deliver the product from the build time. With TDD, a major part of the system is tested during development and needs lesser QA involvement in the time between build and final delivery of the product.
*Alternative Documentation: Unit tests are kind of documentation to system. Each unit test tells about an individual requirement to the module or system. For example, the following test ensures that only a logged in user with proper balance can buy an item when the item exists in stock. This test reflects a user aspect scenario of the system.

public void CheckUserCanNotPurchaseItemWithoutBalance(){
LoginToTheSystem();
SelectAnItemToBuy();
MakeSureItemExsitsInStock();
MakeSureUserHasBalanceToBuy();
RunTheTransaction();
}
*Better way to fix bugs: In TDD approach when QA finds a bug, developer first writes a test that generates the bug (that is the test will fail due to this bug). Then developer modifies code to make sure that the test is passed (i.e., the bug is fixed). This approach makes sure that next time the bug will not appear in the system as a test is written in the system to take care of the bug.
*Repetition of the same bug reduced: With TDD once a bug is found, it's put under test. So every time you run the whole test in the system, the tests associated with the bug are run and make sure the bugs are not generated again.

=Shortcomings Of TDD=

TDD has a few shortcomings:

*The actual database or external file is never tested directly by TDD (only production code can test it)
*If not used carefully, it can add to the total project costs and complexity of the project
*TDD is unable to test UI.
*TDD is highly reliant on Refactoring and Programmer Skills.

=Conclusion=

TDD fundamentaly changes how a developer approaches a programming project. It forces him to focus on the design requirements first by mandating that the developer must write a test for anything before he writes code to do it. It has many benefits including ensuring that the project is well tested and, in some cases, reducing development time. However, it is limited in that it can't test user interfaces or databases directly. TDD is a component of [http://en.wikipedia.org/wiki/Extreme_programming Extreme Programming] and often used in conjunction with integration tests. Overall, it is a very effective tool for quickly writing well tested code.

=References=
*[http://catalog.lib.ncsu.edu/record/NCSU1601963 Beck, K. (2002). Test-driven development by example. Addison-Wesley.]
*[http://en.wikipedia.org/wiki/Test_driven_development (n.d.). Test-driven development. website: http://en.wikipedia.org/wiki/Test_driven_development]
*[http://c2.com/cgi/wiki?TestDrivenDevelopment (2012, January 11). Test driven development. website: http://c2.com/cgi/wiki?TestDrivenDevelopment]
*[http://www.agiledata.org/essays/tdd.html Ambler, S. W. (2002). Introduction to test driven development (tdd). Retrieved from Agile Data website: http://www.agiledata.org/essays/tdd.html]
*[http://www.methodsandtools.com/archive/archive.php?id=20. Methods and Tools Archives]
*[http://www.martinfowler.com/bliki/TestDrivenDevelopment.html www.martinfowler.com/bliki/TestDrivenDevelopment]
*[http://www.codeproject.com/Articles/47747/Test-Driven-Development-TDD-Step-by-Step-Part-1-In TDD Step by Step Code Project]
*[http://integralpath.blogs.com/thinkingoutloud/2005/09/principles_of_t.html Principles of Testing]

CSC/ECE 517 Fall 2012/ch2a 2w11 aa

2012-10-25T18:28:06Z

Annice: /* Steps */

=Introduction=
Test driven development (TDD) is a process that tries to create the minimal amount of code to meet customer's expectations. The idea is to test first, code second, then improve (or refactor) last. This process forces the software developers to focus on customer specifications and validation first. Since at each step of the way the programmer proves to himself that the code meets specifications, TDD gives the programmer confidence. The rest of this chapter gives the motivation for TDD, shows the steps for TDD, outlines the principles of TDD, provides examples using TDD, and compares the pros and cons of TDD.

=Motivation for TDD=

There are two main motivations for TDD.

[[File:CostofChange.png|550px|Thumb:Figure 1: Traditional "Cost of Change" curve with the waterfall model superimposed]]

*Testing is the one activity that improves the quality of code. In various design scenarios, like waterfall model, testing occurs towards the end of the project development activity. As shown in the figure 1, introducing testing as a latter phase increases the cost incurred for implementing the changes. From this we infer that there is a high chance of reducing the costs by moving the Test phase to the initial part.
*The client can also be well informed about the design and can suggest changes which can be incorporated well in advance. This approach also known as TDD helps achieve flexibility to achieve the client’s ever-changing requirements

=Principles=

TDD follows several principles:

*Tests serve as examples of how to use a class or method. Once used to having tests that show how things work (and that they work), developers start inquiring if a test was already there for the piece of code to be developed
*Developer tests are distinctly different from QA (Quality Analysis) tests and should be kept separate. QA tests target features and treat the system as a black box. Unit tests created by the developer operate at a lower level and test different things.
*Name the tests carefully. For Example, name test packages like the package being tested with a suffix. For example, the "DataAccess" project/package is tested by "DataAccess.Test". Also, name test classes the same as the class under test with the suffix "Test". For example, the class "PrintManager" is tested by the test class "PrintManagerTest". This convention makes it easy to find the related class and keeps the class name a noun. You should also name test methods the same as the method being tested with the prefix "Test". For example, the method "PrintProductOrder()" is tested by the method "TestPrintProductOrder()". This convention keeps the method name a verb that reads as an english phrase.
*Write each test before writing the method under test. It encourages the developer to think as a user of the target method before thinking about implementation, which usually results in a cleaner, easier-to-use interface.
*Follow the "3-As" pattern for test methods: Arrange, Act, Assert. Specifically, use separate code paragraphs (groups of lines of code separated by a blank line) for each of the As. Arrange is variable declaration and initialization. Act is invoking the code under test. Assert is using the Assert.* methods to verify that expectations were met.
*When writing application code, only write enough code to make a test work. This technique prevents gold-plating and ensures that you always have a test for the code you write.
*When you find you need to refractor working code, refractor and re-test prior to writing new code. This technique ensures your refractoring is correct prior to adding new functionality and applies to creating new methods, introducing inheritance, everything.

=Steps=

[[File:TDD_Steps.png]

Follow these steps:
*Understand the requirements of the story, work item, or feature that you are working on.
*Red:Create a test and make it fail.
Imagine how the new code should be called and write the test as if the code already existed.
Create the new production code stub. Write just enough code so that it compiles.
Run the test. It should fail. This is a calibration measure to ensure that your test is calling the correct code and that the code is not working by accident. This is a meaningful failure, and you expect it to fail.
*Green: Make the test pass by any means necessary.
Write the production code to make the test pass. Keep it simple.
Some advocate the hard-coding of the expected return value first to verify that the test correctly detects success. This varies from practitioner to practitioner.If you've written the code so that the test passes as intended, you are finished. You do not have to write more code speculatively. If new functionality is still needed, then another test is needed. Make this one test pass and continue.
When the test passes, you might want to run all tests up to this point to build confidence that everything else is still working.
*Refractor: Change the code to remove duplication in your project and to improve the design while ensuring that all tests still pass.
Remove duplication caused by the addition of the new functionality.
Make design changes to improve the overall solution.
After each refactoring, rerun all the tests to ensure that they all still pass.
*Repeat the cycle. Each cycle should be very short, and a typical hour should contain many Red/Green/ Refractor cycles.

=Examples=

==Homework Grades Program==

===Setup===
As a simple example, we are creating a program that keeps track of our homework grades. We envision that we would be able to get the average of these homework grades. Step one: write a test . Let's test an average function

<pre>
myHomework = new Homework();
myHomework.grades = [100, 50];
assert(myHomework.average(myHomework.grades) == 75);
</pre>

We will get multiple errors - this test won't even compile (but, that's ok for now). Let's take a look at what will generate error messages:

* class <code>Homework</code> not declared
* <code>Homework</code> constructor not declared
* field <code>grades</code> not declared
* method <code>average</code> not declared

Now, we fix the first error:

<pre>
class Homework {

}
</pre>

Second error:

<pre>
Homework(void) {

}
</pre>

Third error:

<pre>
int * grades;
</pre>

Fourth error:

<pre>
int average(int * grades) {
return 0; // default return value
}
</pre>

Finally, the test compiles! The code now looks like this:

<pre>
class Homework {

int * grades;

Homework(void) {

}

int average(int * grades) {

return 0; // default return value

}

}
</pre>

===Red===
Now, we run the test, and the familar red bar of failure greets us (remember the mantra red-green-refactor). The assert fails. The average function needs to actually average something (not just return 0). As we think about averaging the grades, we realize we need to know how many grades are in the int array <code>grades</code>. So, we add to the code:

<pre>
class Homework {

int * grades;
int numGrades; // new

Homework(void) {

}

int average(int * grades) {

int avg = 0; // new

for(int i = 0; i < numGrades; i++) { // new
avg += grades[i]; // new
} // new

return avg/numGrades; // new

}

}
</pre>

Of course, we must remember to change the test to:

<pre>
myHomework = new Homework();
myHomework.grades = [100, 50];
myHomework.numGrades = 2;
assert(myHomework.average(myHomework.grades) == 75);
</pre>

===Green===
Success! We have a green bar when we run it.

===Refactor===
The last step is refactoring. Perhaps we don't want a grade to be an <code>int</code>? Should it be an <code>unsigned int</code>? For this simple example, there isn't much refactoring to do, but in a larger example there may be multiple areas for improvement.

==Refactoring Example==
The following example is take from Test-Driven Development by Example by Kent Beck.

Using the TDD process the author created an object with the following structure:

<pre>
class Dollar {

Dollar(int amount) {
this.amount = amount;
}

void times(int mulitplier) {
amount *= multiplier;
}

}
</pre>

What's wrong with the code above? Look at the following test:

<pre>
public void testMultiplication() {

Dollar five = new Dollar(5);
five.times(2);
assertEquals(10, five.amount);
five.times(3);
assertEquals(15, five.amount);

}
</pre>

Whenever we perform an operation on a <code>Dollar</code> the value of the <code>Dollar</code> changes. In the test above <code>five</code> isn't 5 after we multiply it by 2, and thus the name <code>five</code> doesn't make sense anymore. How do we change this?

===Red===

First, we change the test.

<pre>
public void testMultiplication() {
Dollar five = new Dollar(5);
Dollar product = five.times(2);
assertEquals(10, product.amount);
product = five.times(3);
assertEquals(15, product.amount);
}
</pre>

The new test won't compile until we change the code:

<pre>
Dollar times(int multiplier) {
amount *= multiplier;
return null;
}
</pre>

Now the test compiles, but fails. Once again, we change the code:

<pre>
Dollar times(int multiplier) {
return new Dollar(amount * multiplier);
}
</pre>

===Green===

The test succeeds. So we see that even when we are refactoring we change the test first, then the code. This way we know our refactoring is an improvement.

==More Examples==
See Test-Driven Development by Example by Kent Beck for more examples.

=Characteristics Of A Good Unit Test=
A good unit test has the following characteristics.
*It is important that the test executes fast. If the tests are slow, they will not be run often.
*Environmental dependencies such as databases, file systems, networks, queues, and so on which will slow down the tests are either separated or simulated. Tests that exercise these will not run fast, and a failure does not give meaningful feedback about what the problem actually is.
*The scope of testing is very limited. If the test fails, it's obvious where to look for the problem. It's important to only test one aspect in a single test.
*The test should run and pass in isolation (on any machine). If the tests require special environmental setup or fail unexpectedly, then they are not good unit tests.
*Such a test often uses stubs and mock objects. If the code being tested typically calls out to a database or file system, these dependencies must be simulated, or mocked. These dependencies will ordinarily be abstracted away by using interfaces.
*The intention of testing is clearly revealed. Another developer can look at the test and understand what is expected of the production code.

=Benefits Of TDD=

Using TDD has many benefits.

*Automated testing: Automated system makes the testing much more easier and faster. Manual testing is slower and needs human interaction which is error-prone. Automated testing makes sure any particular test is not missing every time we test the system, whereas humans may leave a test out mistakenly during testing process.
*Better to test New/Modified Functionality: With manual testing whenever you add new functionality or modify existing functionality, QA personal needs to test all systems that may be affected due to the modification which may be time-consuming. This may also leave a hidden bug in the system after modification. With TDD whenever a new functionality is added or existing functionality is modified, the whole set of tests in the system is run to make sure existing tests are passed. This makes sure that existing functionality is not broken.
*Developer’s confidence: With TDD, developers are more safe to change the system as any inappropriate changes will make some tests to fail. With non-TDD system developers needs to take more care to change existing system as the new change may fail other functionality. But with TDD developers can do so easily as after modification if developer runs the test he/she will find immediately that the change has failed some other tests (i.e. some other part of the system).
*Manual testing stage is shortened: In non-TDD development, as soon as developers prepare a build, QA personal starts testing. This manual testing takes a reasonable amount of time and increases the time to deliver the product from the build time. With TDD, a major part of the system is tested during development and needs lesser QA involvement in the time between build and final delivery of the product.
*Alternative Documentation: Unit tests are kind of documentation to system. Each unit test tells about an individual requirement to the module or system. For example, the following test ensures that only a logged in user with proper balance can buy an item when the item exists in stock. This test reflects a user aspect scenario of the system.

public void CheckUserCanNotPurchaseItemWithoutBalance(){
LoginToTheSystem();
SelectAnItemToBuy();
MakeSureItemExsitsInStock();
MakeSureUserHasBalanceToBuy();
RunTheTransaction();
}
*Better way to fix bugs: In TDD approach when QA finds a bug, developer first writes a test that generates the bug (that is the test will fail due to this bug). Then developer modifies code to make sure that the test is passed (i.e., the bug is fixed). This approach makes sure that next time the bug will not appear in the system as a test is written in the system to take care of the bug.
*Repetition of the same bug reduced: With TDD once a bug is found, it's put under test. So every time you run the whole test in the system, the tests associated with the bug are run and make sure the bugs are not generated again.

=Shortcomings Of TDD=

TDD has a few shortcomings:

*The actual database or external file is never tested directly by TDD (only production code can test it)
*If not used carefully, it can add to the total project costs and complexity of the project
*TDD is unable to test UI.
*TDD is highly reliant on Refactoring and Programmer Skills.

=Conclusion=

TDD fundamentaly changes how a developer approaches a programming project. It forces him to focus on the design requirements first by mandating that the developer must write a test for anything before he writes code to do it. It has many benefits including ensuring that the project is well tested and, in some cases, reducing development time. However, it is limited in that it can't test user interfaces or databases directly. TDD is a component of [http://en.wikipedia.org/wiki/Extreme_programming Extreme Programming] and often used in conjunction with integration tests. Overall, it is a very effective tool for quickly writing well tested code.

=References=
*[http://catalog.lib.ncsu.edu/record/NCSU1601963 Beck, K. (2002). Test-driven development by example. Addison-Wesley.]
*[http://en.wikipedia.org/wiki/Test_driven_development (n.d.). Test-driven development. website: http://en.wikipedia.org/wiki/Test_driven_development]
*[http://c2.com/cgi/wiki?TestDrivenDevelopment (2012, January 11). Test driven development. website: http://c2.com/cgi/wiki?TestDrivenDevelopment]
*[http://www.agiledata.org/essays/tdd.html Ambler, S. W. (2002). Introduction to test driven development (tdd). Retrieved from Agile Data website: http://www.agiledata.org/essays/tdd.html]
*[http://www.methodsandtools.com/archive/archive.php?id=20. Methods and Tools Archives]
*[http://www.martinfowler.com/bliki/TestDrivenDevelopment.html www.martinfowler.com/bliki/TestDrivenDevelopment]
*[http://www.codeproject.com/Articles/47747/Test-Driven-Development-TDD-Step-by-Step-Part-1-In TDD Step by Step Code Project]
*[http://integralpath.blogs.com/thinkingoutloud/2005/09/principles_of_t.html Principles of Testing]

File:TDD Steps.png

2012-10-25T18:27:31Z

Annice:

CSC/ECE 517 Fall 2012/ch2a 2w11 aa

2012-10-25T18:26:56Z

Annice: /* Motivation for TDD */

=Introduction=
Test driven development (TDD) is a process that tries to create the minimal amount of code to meet customer's expectations. The idea is to test first, code second, then improve (or refactor) last. This process forces the software developers to focus on customer specifications and validation first. Since at each step of the way the programmer proves to himself that the code meets specifications, TDD gives the programmer confidence. The rest of this chapter gives the motivation for TDD, shows the steps for TDD, outlines the principles of TDD, provides examples using TDD, and compares the pros and cons of TDD.

=Motivation for TDD=

There are two main motivations for TDD.

[[File:CostofChange.png|550px|Thumb:Figure 1: Traditional "Cost of Change" curve with the waterfall model superimposed]]

*Testing is the one activity that improves the quality of code. In various design scenarios, like waterfall model, testing occurs towards the end of the project development activity. As shown in the figure 1, introducing testing as a latter phase increases the cost incurred for implementing the changes. From this we infer that there is a high chance of reducing the costs by moving the Test phase to the initial part.
*The client can also be well informed about the design and can suggest changes which can be incorporated well in advance. This approach also known as TDD helps achieve flexibility to achieve the client’s ever-changing requirements

=Principles=

TDD follows several principles:

*Tests serve as examples of how to use a class or method. Once used to having tests that show how things work (and that they work), developers start inquiring if a test was already there for the piece of code to be developed
*Developer tests are distinctly different from QA (Quality Analysis) tests and should be kept separate. QA tests target features and treat the system as a black box. Unit tests created by the developer operate at a lower level and test different things.
*Name the tests carefully. For Example, name test packages like the package being tested with a suffix. For example, the "DataAccess" project/package is tested by "DataAccess.Test". Also, name test classes the same as the class under test with the suffix "Test". For example, the class "PrintManager" is tested by the test class "PrintManagerTest". This convention makes it easy to find the related class and keeps the class name a noun. You should also name test methods the same as the method being tested with the prefix "Test". For example, the method "PrintProductOrder()" is tested by the method "TestPrintProductOrder()". This convention keeps the method name a verb that reads as an english phrase.
*Write each test before writing the method under test. It encourages the developer to think as a user of the target method before thinking about implementation, which usually results in a cleaner, easier-to-use interface.
*Follow the "3-As" pattern for test methods: Arrange, Act, Assert. Specifically, use separate code paragraphs (groups of lines of code separated by a blank line) for each of the As. Arrange is variable declaration and initialization. Act is invoking the code under test. Assert is using the Assert.* methods to verify that expectations were met.
*When writing application code, only write enough code to make a test work. This technique prevents gold-plating and ensures that you always have a test for the code you write.
*When you find you need to refractor working code, refractor and re-test prior to writing new code. This technique ensures your refractoring is correct prior to adding new functionality and applies to creating new methods, introducing inheritance, everything.

=Steps=

[[Image:PureFab.gif]]

Follow these steps:
*Understand the requirements of the story, work item, or feature that you are working on.
*Red:Create a test and make it fail.
Imagine how the new code should be called and write the test as if the code already existed.
Create the new production code stub. Write just enough code so that it compiles.
Run the test. It should fail. This is a calibration measure to ensure that your test is calling the correct code and that the code is not working by accident. This is a meaningful failure, and you expect it to fail.
*Green: Make the test pass by any means necessary.
Write the production code to make the test pass. Keep it simple.
Some advocate the hard-coding of the expected return value first to verify that the test correctly detects success. This varies from practitioner to practitioner.If you've written the code so that the test passes as intended, you are finished. You do not have to write more code speculatively. If new functionality is still needed, then another test is needed. Make this one test pass and continue.
When the test passes, you might want to run all tests up to this point to build confidence that everything else is still working.
*Refractor: Change the code to remove duplication in your project and to improve the design while ensuring that all tests still pass.
Remove duplication caused by the addition of the new functionality.
Make design changes to improve the overall solution.
After each refactoring, rerun all the tests to ensure that they all still pass.
*Repeat the cycle. Each cycle should be very short, and a typical hour should contain many Red/Green/ Refractor cycles.

=Examples=

==Homework Grades Program==

===Setup===
As a simple example, we are creating a program that keeps track of our homework grades. We envision that we would be able to get the average of these homework grades. Step one: write a test . Let's test an average function

<pre>
myHomework = new Homework();
myHomework.grades = [100, 50];
assert(myHomework.average(myHomework.grades) == 75);
</pre>

We will get multiple errors - this test won't even compile (but, that's ok for now). Let's take a look at what will generate error messages:

* class <code>Homework</code> not declared
* <code>Homework</code> constructor not declared
* field <code>grades</code> not declared
* method <code>average</code> not declared

Now, we fix the first error:

<pre>
class Homework {

}
</pre>

Second error:

<pre>
Homework(void) {

}
</pre>

Third error:

<pre>
int * grades;
</pre>

Fourth error:

<pre>
int average(int * grades) {
return 0; // default return value
}
</pre>

Finally, the test compiles! The code now looks like this:

<pre>
class Homework {

int * grades;

Homework(void) {

}

int average(int * grades) {

return 0; // default return value

}

}
</pre>

===Red===
Now, we run the test, and the familar red bar of failure greets us (remember the mantra red-green-refactor). The assert fails. The average function needs to actually average something (not just return 0). As we think about averaging the grades, we realize we need to know how many grades are in the int array <code>grades</code>. So, we add to the code:

<pre>
class Homework {

int * grades;
int numGrades; // new

Homework(void) {

}

int average(int * grades) {

int avg = 0; // new

for(int i = 0; i < numGrades; i++) { // new
avg += grades[i]; // new
} // new

return avg/numGrades; // new

}

}
</pre>

Of course, we must remember to change the test to:

<pre>
myHomework = new Homework();
myHomework.grades = [100, 50];
myHomework.numGrades = 2;
assert(myHomework.average(myHomework.grades) == 75);
</pre>

===Green===
Success! We have a green bar when we run it.

===Refactor===
The last step is refactoring. Perhaps we don't want a grade to be an <code>int</code>? Should it be an <code>unsigned int</code>? For this simple example, there isn't much refactoring to do, but in a larger example there may be multiple areas for improvement.

==Refactoring Example==
The following example is take from Test-Driven Development by Example by Kent Beck.

Using the TDD process the author created an object with the following structure:

<pre>
class Dollar {

Dollar(int amount) {
this.amount = amount;
}

void times(int mulitplier) {
amount *= multiplier;
}

}
</pre>

What's wrong with the code above? Look at the following test:

<pre>
public void testMultiplication() {

Dollar five = new Dollar(5);
five.times(2);
assertEquals(10, five.amount);
five.times(3);
assertEquals(15, five.amount);

}
</pre>

Whenever we perform an operation on a <code>Dollar</code> the value of the <code>Dollar</code> changes. In the test above <code>five</code> isn't 5 after we multiply it by 2, and thus the name <code>five</code> doesn't make sense anymore. How do we change this?

===Red===

First, we change the test.

<pre>
public void testMultiplication() {
Dollar five = new Dollar(5);
Dollar product = five.times(2);
assertEquals(10, product.amount);
product = five.times(3);
assertEquals(15, product.amount);
}
</pre>

The new test won't compile until we change the code:

<pre>
Dollar times(int multiplier) {
amount *= multiplier;
return null;
}
</pre>

Now the test compiles, but fails. Once again, we change the code:

<pre>
Dollar times(int multiplier) {
return new Dollar(amount * multiplier);
}
</pre>

===Green===

The test succeeds. So we see that even when we are refactoring we change the test first, then the code. This way we know our refactoring is an improvement.

==More Examples==
See Test-Driven Development by Example by Kent Beck for more examples.

=Characteristics Of A Good Unit Test=
A good unit test has the following characteristics.
*It is important that the test executes fast. If the tests are slow, they will not be run often.
*Environmental dependencies such as databases, file systems, networks, queues, and so on which will slow down the tests are either separated or simulated. Tests that exercise these will not run fast, and a failure does not give meaningful feedback about what the problem actually is.
*The scope of testing is very limited. If the test fails, it's obvious where to look for the problem. It's important to only test one aspect in a single test.
*The test should run and pass in isolation (on any machine). If the tests require special environmental setup or fail unexpectedly, then they are not good unit tests.
*Such a test often uses stubs and mock objects. If the code being tested typically calls out to a database or file system, these dependencies must be simulated, or mocked. These dependencies will ordinarily be abstracted away by using interfaces.
*The intention of testing is clearly revealed. Another developer can look at the test and understand what is expected of the production code.

=Benefits Of TDD=

Using TDD has many benefits.

*Automated testing: Automated system makes the testing much more easier and faster. Manual testing is slower and needs human interaction which is error-prone. Automated testing makes sure any particular test is not missing every time we test the system, whereas humans may leave a test out mistakenly during testing process.
*Better to test New/Modified Functionality: With manual testing whenever you add new functionality or modify existing functionality, QA personal needs to test all systems that may be affected due to the modification which may be time-consuming. This may also leave a hidden bug in the system after modification. With TDD whenever a new functionality is added or existing functionality is modified, the whole set of tests in the system is run to make sure existing tests are passed. This makes sure that existing functionality is not broken.
*Developer’s confidence: With TDD, developers are more safe to change the system as any inappropriate changes will make some tests to fail. With non-TDD system developers needs to take more care to change existing system as the new change may fail other functionality. But with TDD developers can do so easily as after modification if developer runs the test he/she will find immediately that the change has failed some other tests (i.e. some other part of the system).
*Manual testing stage is shortened: In non-TDD development, as soon as developers prepare a build, QA personal starts testing. This manual testing takes a reasonable amount of time and increases the time to deliver the product from the build time. With TDD, a major part of the system is tested during development and needs lesser QA involvement in the time between build and final delivery of the product.
*Alternative Documentation: Unit tests are kind of documentation to system. Each unit test tells about an individual requirement to the module or system. For example, the following test ensures that only a logged in user with proper balance can buy an item when the item exists in stock. This test reflects a user aspect scenario of the system.

public void CheckUserCanNotPurchaseItemWithoutBalance(){
LoginToTheSystem();
SelectAnItemToBuy();
MakeSureItemExsitsInStock();
MakeSureUserHasBalanceToBuy();
RunTheTransaction();
}
*Better way to fix bugs: In TDD approach when QA finds a bug, developer first writes a test that generates the bug (that is the test will fail due to this bug). Then developer modifies code to make sure that the test is passed (i.e., the bug is fixed). This approach makes sure that next time the bug will not appear in the system as a test is written in the system to take care of the bug.
*Repetition of the same bug reduced: With TDD once a bug is found, it's put under test. So every time you run the whole test in the system, the tests associated with the bug are run and make sure the bugs are not generated again.

=Shortcomings Of TDD=

TDD has a few shortcomings:

*The actual database or external file is never tested directly by TDD (only production code can test it)
*If not used carefully, it can add to the total project costs and complexity of the project
*TDD is unable to test UI.
*TDD is highly reliant on Refactoring and Programmer Skills.

=Conclusion=

TDD fundamentaly changes how a developer approaches a programming project. It forces him to focus on the design requirements first by mandating that the developer must write a test for anything before he writes code to do it. It has many benefits including ensuring that the project is well tested and, in some cases, reducing development time. However, it is limited in that it can't test user interfaces or databases directly. TDD is a component of [http://en.wikipedia.org/wiki/Extreme_programming Extreme Programming] and often used in conjunction with integration tests. Overall, it is a very effective tool for quickly writing well tested code.

=References=
*[http://catalog.lib.ncsu.edu/record/NCSU1601963 Beck, K. (2002). Test-driven development by example. Addison-Wesley.]
*[http://en.wikipedia.org/wiki/Test_driven_development (n.d.). Test-driven development. website: http://en.wikipedia.org/wiki/Test_driven_development]
*[http://c2.com/cgi/wiki?TestDrivenDevelopment (2012, January 11). Test driven development. website: http://c2.com/cgi/wiki?TestDrivenDevelopment]
*[http://www.agiledata.org/essays/tdd.html Ambler, S. W. (2002). Introduction to test driven development (tdd). Retrieved from Agile Data website: http://www.agiledata.org/essays/tdd.html]
*[http://www.methodsandtools.com/archive/archive.php?id=20. Methods and Tools Archives]
*[http://www.martinfowler.com/bliki/TestDrivenDevelopment.html www.martinfowler.com/bliki/TestDrivenDevelopment]
*[http://www.codeproject.com/Articles/47747/Test-Driven-Development-TDD-Step-by-Step-Part-1-In TDD Step by Step Code Project]
*[http://integralpath.blogs.com/thinkingoutloud/2005/09/principles_of_t.html Principles of Testing]

CSC/ECE 517 Fall 2012/ch2a 2w11 aa

2012-10-25T18:26:37Z

Annice: /* Motivation for TDD */

=Introduction=
Test driven development (TDD) is a process that tries to create the minimal amount of code to meet customer's expectations. The idea is to test first, code second, then improve (or refactor) last. This process forces the software developers to focus on customer specifications and validation first. Since at each step of the way the programmer proves to himself that the code meets specifications, TDD gives the programmer confidence. The rest of this chapter gives the motivation for TDD, shows the steps for TDD, outlines the principles of TDD, provides examples using TDD, and compares the pros and cons of TDD.

=Motivation for TDD=

There are two main motivations for TDD.

[[File:CostofChange.png|350px|Thumb:Figure 1: Traditional "Cost of Change" curve with the waterfall model superimposed]]

*Testing is the one activity that improves the quality of code. In various design scenarios, like waterfall model, testing occurs towards the end of the project development activity. As shown in the figure 1, introducing testing as a latter phase increases the cost incurred for implementing the changes. From this we infer that there is a high chance of reducing the costs by moving the Test phase to the initial part.
*The client can also be well informed about the design and can suggest changes which can be incorporated well in advance. This approach also known as TDD helps achieve flexibility to achieve the client’s ever-changing requirements

=Principles=

TDD follows several principles:

*Tests serve as examples of how to use a class or method. Once used to having tests that show how things work (and that they work), developers start inquiring if a test was already there for the piece of code to be developed
*Developer tests are distinctly different from QA (Quality Analysis) tests and should be kept separate. QA tests target features and treat the system as a black box. Unit tests created by the developer operate at a lower level and test different things.
*Name the tests carefully. For Example, name test packages like the package being tested with a suffix. For example, the "DataAccess" project/package is tested by "DataAccess.Test". Also, name test classes the same as the class under test with the suffix "Test". For example, the class "PrintManager" is tested by the test class "PrintManagerTest". This convention makes it easy to find the related class and keeps the class name a noun. You should also name test methods the same as the method being tested with the prefix "Test". For example, the method "PrintProductOrder()" is tested by the method "TestPrintProductOrder()". This convention keeps the method name a verb that reads as an english phrase.
*Write each test before writing the method under test. It encourages the developer to think as a user of the target method before thinking about implementation, which usually results in a cleaner, easier-to-use interface.
*Follow the "3-As" pattern for test methods: Arrange, Act, Assert. Specifically, use separate code paragraphs (groups of lines of code separated by a blank line) for each of the As. Arrange is variable declaration and initialization. Act is invoking the code under test. Assert is using the Assert.* methods to verify that expectations were met.
*When writing application code, only write enough code to make a test work. This technique prevents gold-plating and ensures that you always have a test for the code you write.
*When you find you need to refractor working code, refractor and re-test prior to writing new code. This technique ensures your refractoring is correct prior to adding new functionality and applies to creating new methods, introducing inheritance, everything.

=Steps=

[[Image:PureFab.gif]]

Follow these steps:
*Understand the requirements of the story, work item, or feature that you are working on.
*Red:Create a test and make it fail.
Imagine how the new code should be called and write the test as if the code already existed.
Create the new production code stub. Write just enough code so that it compiles.
Run the test. It should fail. This is a calibration measure to ensure that your test is calling the correct code and that the code is not working by accident. This is a meaningful failure, and you expect it to fail.
*Green: Make the test pass by any means necessary.
Write the production code to make the test pass. Keep it simple.
Some advocate the hard-coding of the expected return value first to verify that the test correctly detects success. This varies from practitioner to practitioner.If you've written the code so that the test passes as intended, you are finished. You do not have to write more code speculatively. If new functionality is still needed, then another test is needed. Make this one test pass and continue.
When the test passes, you might want to run all tests up to this point to build confidence that everything else is still working.
*Refractor: Change the code to remove duplication in your project and to improve the design while ensuring that all tests still pass.
Remove duplication caused by the addition of the new functionality.
Make design changes to improve the overall solution.
After each refactoring, rerun all the tests to ensure that they all still pass.
*Repeat the cycle. Each cycle should be very short, and a typical hour should contain many Red/Green/ Refractor cycles.

=Examples=

==Homework Grades Program==

===Setup===
As a simple example, we are creating a program that keeps track of our homework grades. We envision that we would be able to get the average of these homework grades. Step one: write a test . Let's test an average function

<pre>
myHomework = new Homework();
myHomework.grades = [100, 50];
assert(myHomework.average(myHomework.grades) == 75);
</pre>

We will get multiple errors - this test won't even compile (but, that's ok for now). Let's take a look at what will generate error messages:

* class <code>Homework</code> not declared
* <code>Homework</code> constructor not declared
* field <code>grades</code> not declared
* method <code>average</code> not declared

Now, we fix the first error:

<pre>
class Homework {

}
</pre>

Second error:

<pre>
Homework(void) {

}
</pre>

Third error:

<pre>
int * grades;
</pre>

Fourth error:

<pre>
int average(int * grades) {
return 0; // default return value
}
</pre>

Finally, the test compiles! The code now looks like this:

<pre>
class Homework {

int * grades;

Homework(void) {

}

int average(int * grades) {

return 0; // default return value

}

}
</pre>

===Red===
Now, we run the test, and the familar red bar of failure greets us (remember the mantra red-green-refactor). The assert fails. The average function needs to actually average something (not just return 0). As we think about averaging the grades, we realize we need to know how many grades are in the int array <code>grades</code>. So, we add to the code:

<pre>
class Homework {

int * grades;
int numGrades; // new

Homework(void) {

}

int average(int * grades) {

int avg = 0; // new

for(int i = 0; i < numGrades; i++) { // new
avg += grades[i]; // new
} // new

return avg/numGrades; // new

}

}
</pre>

Of course, we must remember to change the test to:

<pre>
myHomework = new Homework();
myHomework.grades = [100, 50];
myHomework.numGrades = 2;
assert(myHomework.average(myHomework.grades) == 75);
</pre>

===Green===
Success! We have a green bar when we run it.

===Refactor===
The last step is refactoring. Perhaps we don't want a grade to be an <code>int</code>? Should it be an <code>unsigned int</code>? For this simple example, there isn't much refactoring to do, but in a larger example there may be multiple areas for improvement.

==Refactoring Example==
The following example is take from Test-Driven Development by Example by Kent Beck.

Using the TDD process the author created an object with the following structure:

<pre>
class Dollar {

Dollar(int amount) {
this.amount = amount;
}

void times(int mulitplier) {
amount *= multiplier;
}

}
</pre>

What's wrong with the code above? Look at the following test:

<pre>
public void testMultiplication() {

Dollar five = new Dollar(5);
five.times(2);
assertEquals(10, five.amount);
five.times(3);
assertEquals(15, five.amount);

}
</pre>

Whenever we perform an operation on a <code>Dollar</code> the value of the <code>Dollar</code> changes. In the test above <code>five</code> isn't 5 after we multiply it by 2, and thus the name <code>five</code> doesn't make sense anymore. How do we change this?

===Red===

First, we change the test.

<pre>
public void testMultiplication() {
Dollar five = new Dollar(5);
Dollar product = five.times(2);
assertEquals(10, product.amount);
product = five.times(3);
assertEquals(15, product.amount);
}
</pre>

The new test won't compile until we change the code:

<pre>
Dollar times(int multiplier) {
amount *= multiplier;
return null;
}
</pre>

Now the test compiles, but fails. Once again, we change the code:

<pre>
Dollar times(int multiplier) {
return new Dollar(amount * multiplier);
}
</pre>

===Green===

The test succeeds. So we see that even when we are refactoring we change the test first, then the code. This way we know our refactoring is an improvement.

==More Examples==
See Test-Driven Development by Example by Kent Beck for more examples.

=Characteristics Of A Good Unit Test=
A good unit test has the following characteristics.
*It is important that the test executes fast. If the tests are slow, they will not be run often.
*Environmental dependencies such as databases, file systems, networks, queues, and so on which will slow down the tests are either separated or simulated. Tests that exercise these will not run fast, and a failure does not give meaningful feedback about what the problem actually is.
*The scope of testing is very limited. If the test fails, it's obvious where to look for the problem. It's important to only test one aspect in a single test.
*The test should run and pass in isolation (on any machine). If the tests require special environmental setup or fail unexpectedly, then they are not good unit tests.
*Such a test often uses stubs and mock objects. If the code being tested typically calls out to a database or file system, these dependencies must be simulated, or mocked. These dependencies will ordinarily be abstracted away by using interfaces.
*The intention of testing is clearly revealed. Another developer can look at the test and understand what is expected of the production code.

=Benefits Of TDD=

Using TDD has many benefits.

*Automated testing: Automated system makes the testing much more easier and faster. Manual testing is slower and needs human interaction which is error-prone. Automated testing makes sure any particular test is not missing every time we test the system, whereas humans may leave a test out mistakenly during testing process.
*Better to test New/Modified Functionality: With manual testing whenever you add new functionality or modify existing functionality, QA personal needs to test all systems that may be affected due to the modification which may be time-consuming. This may also leave a hidden bug in the system after modification. With TDD whenever a new functionality is added or existing functionality is modified, the whole set of tests in the system is run to make sure existing tests are passed. This makes sure that existing functionality is not broken.
*Developer’s confidence: With TDD, developers are more safe to change the system as any inappropriate changes will make some tests to fail. With non-TDD system developers needs to take more care to change existing system as the new change may fail other functionality. But with TDD developers can do so easily as after modification if developer runs the test he/she will find immediately that the change has failed some other tests (i.e. some other part of the system).
*Manual testing stage is shortened: In non-TDD development, as soon as developers prepare a build, QA personal starts testing. This manual testing takes a reasonable amount of time and increases the time to deliver the product from the build time. With TDD, a major part of the system is tested during development and needs lesser QA involvement in the time between build and final delivery of the product.
*Alternative Documentation: Unit tests are kind of documentation to system. Each unit test tells about an individual requirement to the module or system. For example, the following test ensures that only a logged in user with proper balance can buy an item when the item exists in stock. This test reflects a user aspect scenario of the system.

public void CheckUserCanNotPurchaseItemWithoutBalance(){
LoginToTheSystem();
SelectAnItemToBuy();
MakeSureItemExsitsInStock();
MakeSureUserHasBalanceToBuy();
RunTheTransaction();
}
*Better way to fix bugs: In TDD approach when QA finds a bug, developer first writes a test that generates the bug (that is the test will fail due to this bug). Then developer modifies code to make sure that the test is passed (i.e., the bug is fixed). This approach makes sure that next time the bug will not appear in the system as a test is written in the system to take care of the bug.
*Repetition of the same bug reduced: With TDD once a bug is found, it's put under test. So every time you run the whole test in the system, the tests associated with the bug are run and make sure the bugs are not generated again.

=Shortcomings Of TDD=

TDD has a few shortcomings:

*The actual database or external file is never tested directly by TDD (only production code can test it)
*If not used carefully, it can add to the total project costs and complexity of the project
*TDD is unable to test UI.
*TDD is highly reliant on Refactoring and Programmer Skills.

=Conclusion=

TDD fundamentaly changes how a developer approaches a programming project. It forces him to focus on the design requirements first by mandating that the developer must write a test for anything before he writes code to do it. It has many benefits including ensuring that the project is well tested and, in some cases, reducing development time. However, it is limited in that it can't test user interfaces or databases directly. TDD is a component of [http://en.wikipedia.org/wiki/Extreme_programming Extreme Programming] and often used in conjunction with integration tests. Overall, it is a very effective tool for quickly writing well tested code.

=References=
*[http://catalog.lib.ncsu.edu/record/NCSU1601963 Beck, K. (2002). Test-driven development by example. Addison-Wesley.]
*[http://en.wikipedia.org/wiki/Test_driven_development (n.d.). Test-driven development. website: http://en.wikipedia.org/wiki/Test_driven_development]
*[http://c2.com/cgi/wiki?TestDrivenDevelopment (2012, January 11). Test driven development. website: http://c2.com/cgi/wiki?TestDrivenDevelopment]
*[http://www.agiledata.org/essays/tdd.html Ambler, S. W. (2002). Introduction to test driven development (tdd). Retrieved from Agile Data website: http://www.agiledata.org/essays/tdd.html]
*[http://www.methodsandtools.com/archive/archive.php?id=20. Methods and Tools Archives]
*[http://www.martinfowler.com/bliki/TestDrivenDevelopment.html www.martinfowler.com/bliki/TestDrivenDevelopment]
*[http://www.codeproject.com/Articles/47747/Test-Driven-Development-TDD-Step-by-Step-Part-1-In TDD Step by Step Code Project]
*[http://integralpath.blogs.com/thinkingoutloud/2005/09/principles_of_t.html Principles of Testing]

File:CostofChange.png

2012-10-25T18:25:55Z

Annice:

CSC/ECE 517 Fall 2012/ch2a 2w11 aa

2012-10-24T22:09:46Z

Annice: /* Motivation for TDD */

=Introduction=
Test driven development (TDD) is a process that tries to create the minimal amount of code to meet customer's expectations. The idea is to test first, code second, then improve (or refactor) last. This process forces the software developers to focus on customer specifications and validation first. Since at each step of the way the programmer proves to himself that the code meets specifications, TDD gives the programmer confidence. The rest of this chapter gives the motivation for TDD, shows the steps for TDD, outlines the principles of TDD, and provides examples using TDD.

=Motivation for TDD=
[[File:TimevsCostDev.png|350px|Thumb:Figure 1: Traditional "Cost of Change" curve with the waterfall model superimposed]]

*Testing is the one activity that improves the quality of code. In various design scenarios, like waterfall model, testing occurs towards the end of the project development activity. As shown in the figure 1, introducing testing as a latter phase increases the cost incurred for implementing the changes. From this we infer that there is a high chance of reducing the costs by moving the Test phase to the initial part.
*The client can also be well informed about the design and can suggest changes which can be incorporated well in advance. This approach also known as TDD helps achieve flexibility to achieve the client’s ever-changing requirements

=Principles=
*Tests serve as examples of how to use a class or method. Once used to having tests that show how things work (and that they work), developers start inquiring if a test was already there for the piece of code to be developed
*Developer tests are distinctly different from QA (Quality Analysis) tests and should be kept separate. QA tests target features and treat the system as a black box. Unit tests created by the developer operate at a lower level and test different things.
*Name the tests carefully. For Example, name test packages like the package being tested with a suffix. For example, the "DataAccess" project/package is tested by "DataAccess.Test". Also, name test classes the same as the class under test with the suffix "Test". For example, the class "PrintManager" is tested by the test class "PrintManagerTest". This convention makes it easy to find the related class and keeps the class name a noun. You should also name test methods the same as the method being tested with the prefix "Test". For example, the method "PrintProductOrder()" is tested by the method "TestPrintProductOrder()". This convention keeps the method name a verb that reads as an english phrase.
*Write each test before writing the method under test. It encourages the developer to think as a user of the target method before thinking about implementation, which usually results in a cleaner, easier-to-use interface.
*Follow the "3-As" pattern for test methods: Arrange, Act, Assert. Specifically, use separate code paragraphs (groups of lines of code separated by a blank line) for each of the As. Arrange is variable declaration and initialization. Act is invoking the code under test. Assert is using the Assert.* methods to verify that expectations were met.
*When writing application code, only write enough code to make a test work. This technique prevents gold-plating and ensures that you always have a test for the code you write.
*When you find you need to refractor working code, refractor and re-test prior to writing new code. This technique ensures your refractoring is correct prior to adding new functionality and applies to creating new methods, introducing inheritance, everything.
=Steps=

[[Image:PureFab.gif]]

Follow these steps:
*Understand the requirements of the story, work item, or feature that you are working on.
*Red:Create a test and make it fail.
Imagine how the new code should be called and write the test as if the code already existed.
Create the new production code stub. Write just enough code so that it compiles.
Run the test. It should fail. This is a calibration measure to ensure that your test is calling the correct code and that the code is not working by accident. This is a meaningful failure, and you expect it to fail.
*Green: Make the test pass by any means necessary.
Write the production code to make the test pass. Keep it simple.
Some advocate the hard-coding of the expected return value first to verify that the test correctly detects success. This varies from practitioner to practitioner.If you've written the code so that the test passes as intended, you are finished. You do not have to write more code speculatively. If new functionality is still needed, then another test is needed. Make this one test pass and continue.
When the test passes, you might want to run all tests up to this point to build confidence that everything else is still working.
*Refractor: Change the code to remove duplication in your project and to improve the design while ensuring that all tests still pass.
Remove duplication caused by the addition of the new functionality.
Make design changes to improve the overall solution.
After each refactoring, rerun all the tests to ensure that they all still pass.
*Repeat the cycle. Each cycle should be very short, and a typical hour should contain many Red/Green/ Refractor cycles.

=Examples=

==Homework Grades Program==

===Setup===
As a simple example, we are creating a program that keeps track of our homework grades. We envision that we would be able to get the average of these homework grades. Step one: write a test . Let's test an average function

<pre>
myHomework = new Homework();
myHomework.grades = [100, 50];
assert(myHomework.average(myHomework.grades) == 75);
</pre>

We will get multiple errors - this test won't even compile (but, that's ok for now). Let's take a look at what will generate error messages:

* class <code>Homework</code> not declared
* <code>Homework</code> constructor not declared
* field <code>grades</code> not declared
* method <code>average</code> not declared

Now, we fix the first error:

<pre>
class Homework {

}
</pre>

Second error:

<pre>
Homework(void) {

}
</pre>

Third error:

<pre>
int * grades;
</pre>

Fourth error:

<pre>
int average(int * grades) {
return 0; // default return value
}
</pre>

Finally, the test compiles! The code now looks like this:

<pre>
class Homework {

int * grades;

Homework(void) {

}

int average(int * grades) {

return 0; // default return value

}

}
</pre>

===Red===
Now, we run the test, and the familar red bar of failure greets us (remember the mantra red-green-refactor). The assert fails. The average function needs to actually average something (not just return 0). As we think about averaging the grades, we realize we need to know how many grades are in the int array <code>grades</code>. So, we add to the code:

<pre>
class Homework {

int * grades;
int numGrades; // new

Homework(void) {

}

int average(int * grades) {

int avg = 0; // new

for(int i = 0; i < numGrades; i++) { // new
avg += grades[i]; // new
} // new

return avg/numGrades; // new

}

}
</pre>

Of course, we must remember to change the test to:

<pre>
myHomework = new Homework();
myHomework.grades = [100, 50];
myHomework.numGrades = 2;
assert(myHomework.average(myHomework.grades) == 75);
</pre>

===Green===
Success! We have a green bar when we run it.

===Refactor===
The last step is refactoring. Perhaps we don't want a grade to be an <code>int</code>? Should it be an <code>unsigned int</code>? For this simple example, there isn't much refactoring to do, but in a larger example there may be multiple areas for improvement.

==More Examples==
See Test-Driven Development by Example by Kent Beck for more examples.

=Characteristics Of A Good Unit Test=
A good unit test has the following characteristics.
*It is important that the test executes fast. If the tests are slow, they will not be run often.
*Environmental dependencies such as databases, file systems, networks, queues, and so on which will slow down the tests are either separated or simulated. Tests that exercise these will not run fast, and a failure does not give meaningful feedback about what the problem actually is.
*The scope of testing is very limited. If the test fails, it's obvious where to look for the problem. It's important to only test one aspect in a single test.
*The test should run and pass in isolation (on any machine). If the tests require special environmental setup or fail unexpectedly, then they are not good unit tests.
*Such a test often uses stubs and mock objects. If the code being tested typically calls out to a database or file system, these dependencies must be simulated, or mocked. These dependencies will ordinarily be abstracted away by using interfaces.
*The intention of testing is clearly revealed. Another developer can look at the test and understand what is expected of the production code.

=Benefits Of TDD=
*Automated testing: Automated system makes the testing much more easier and faster. Manual testing is slower and needs human interaction which is error-prone. Automated testing makes sure any particular test is not missing every time we test the system, whereas humans may leave a test out mistakenly during testing process.
*Better to test New/Modified Functionality: With manual testing whenever you add new functionality or modify existing functionality, QA personal needs to test all systems that may be affected due to the modification which may be time-consuming. This may also leave a hidden bug in the system after modification. With TDD whenever a new functionality is added or existing functionality is modified, the whole set of tests in the system is run to make sure existing tests are passed. This makes sure that existing functionality is not broken.
*Developer’s confidence: With TDD, developers are more safe to change the system as any inappropriate changes will make some tests to fail. With non-TDD system developers needs to take more care to change existing system as the new change may fail other functionality. But with TDD developers can do so easily as after modification if developer runs the test he/she will find immediately that the change has failed some other tests (i.e. some other part of the system).
*Manual testing stage is shortened: In non-TDD development, as soon as developers prepare a build, QA personal starts testing. This manual testing takes a reasonable amount of time and increases the time to deliver the product from the build time. With TDD, a major part of the system is tested during development and needs lesser QA involvement in the time between build and final delivery of the product.
*Alternative Documentation: Unit tests are kind of documentation to system. Each unit test tells about an individual requirement to the module or system. For example, the following test ensures that only a logged in user with proper balance can buy an item when the item exists in stock. This test reflects a user aspect scenario of the system.

public void CheckUserCanNotPurchaseItemWithoutBalance(){
LoginToTheSystem();
SelectAnItemToBuy();
MakeSureItemExsitsInStock();
MakeSureUserHasBalanceToBuy();
RunTheTransaction();
}
*Better way to fix bugs: In TDD approach when QA finds a bug, developer first writes a test that generates the bug (that is the test will fail due to this bug). Then developer modifies code to make sure that the test is passed (i.e., the bug is fixed). This approach makes sure that next time the bug will not appear in the system as a test is written in the system to take care of the bug.
*Repetition of the same bug reduced: With TDD once a bug is found, it's put under test. So every time you run the whole test in the system, the tests associated with the bug are run and make sure the bugs are not generated again.

=Shortcomings Of TDD=
*The actual database or external file is never tested directly by TDD (only production code can test it)
*If not used carefully, it can add to the total project costs and complexity of the project
*TDD is unable to test UI.
*TDD is highly reliant on Refactoring and Programmer Skills.

=Conclusion=
Danielle
=References=
*[http://catalog.lib.ncsu.edu/record/NCSU1601963 Beck, K. (2002). Test-driven development by example. Addison-Wesley.]
*[http://en.wikipedia.org/wiki/Test_driven_development (n.d.). Test-driven development. website: http://en.wikipedia.org/wiki/Test_driven_development]
*[http://c2.com/cgi/wiki?TestDrivenDevelopment (2012, January 11). Test driven development. website: http://c2.com/cgi/wiki?TestDrivenDevelopment]
*[http://www.agiledata.org/essays/tdd.html Ambler, S. W. (2002). Introduction to test driven development (tdd). Retrieved from Agile Data website: http://www.agiledata.org/essays/tdd.html]
*[http://www.methodsandtools.com/archive/archive.php?id=20. Methods and Tools Archives]
*[http://www.martinfowler.com/bliki/TestDrivenDevelopment.html www.martinfowler.com/bliki/TestDrivenDevelopment]
*[http://www.codeproject.com/Articles/47747/Test-Driven-Development-TDD-Step-by-Step-Part-1-In TDD Step by Step Code Project]
*[http://integralpath.blogs.com/thinkingoutloud/2005/09/principles_of_t.html Principles of Testing]
*http://www.testdriven.com/ ?

CSC/ECE 517 Fall 2012/ch2a 2w11 aa

2012-10-24T22:09:06Z

Annice: /* Motivation for TDD */

=Introduction=
Test driven development (TDD) is a process that tries to create the minimal amount of code to meet customer's expectations. The idea is to test first, code second, then improve (or refactor) last. This process forces the software developers to focus on customer specifications and validation first. Since at each step of the way the programmer proves to himself that the code meets specifications, TDD gives the programmer confidence. The rest of this chapter gives the motivation for TDD, shows the steps for TDD, outlines the principles of TDD, and provides examples using TDD.

=Motivation for TDD=
[[File:TimevsCostDev.png|350px|Figure 1: Traditional "Cost of Change" curve with the waterfall model superimposed]]
s
*Testing is the one activity that improves the quality of code. In various design scenarios, like waterfall model, testing occurs towards the end of the project development activity. As shown in the figure 1, introducing testing as a latter phase increases the cost incurred for implementing the changes. From this we infer that there is a high chance of reducing the costs by moving the Test phase to the initial part.
*The client can also be well informed about the design and can suggest changes which can be incorporated well in advance. This approach also known as TDD helps achieve flexibility to achieve the client’s ever-changing requirements

=Principles=
*Tests serve as examples of how to use a class or method. Once used to having tests that show how things work (and that they work), developers start inquiring if a test was already there for the piece of code to be developed
*Developer tests are distinctly different from QA (Quality Analysis) tests and should be kept separate. QA tests target features and treat the system as a black box. Unit tests created by the developer operate at a lower level and test different things.
*Name the tests carefully. For Example, name test packages like the package being tested with a suffix. For example, the "DataAccess" project/package is tested by "DataAccess.Test". Also, name test classes the same as the class under test with the suffix "Test". For example, the class "PrintManager" is tested by the test class "PrintManagerTest". This convention makes it easy to find the related class and keeps the class name a noun. You should also name test methods the same as the method being tested with the prefix "Test". For example, the method "PrintProductOrder()" is tested by the method "TestPrintProductOrder()". This convention keeps the method name a verb that reads as an english phrase.
*Write each test before writing the method under test. It encourages the developer to think as a user of the target method before thinking about implementation, which usually results in a cleaner, easier-to-use interface.
*Follow the "3-As" pattern for test methods: Arrange, Act, Assert. Specifically, use separate code paragraphs (groups of lines of code separated by a blank line) for each of the As. Arrange is variable declaration and initialization. Act is invoking the code under test. Assert is using the Assert.* methods to verify that expectations were met.
*When writing application code, only write enough code to make a test work. This technique prevents gold-plating and ensures that you always have a test for the code you write.
*When you find you need to refractor working code, refractor and re-test prior to writing new code. This technique ensures your refractoring is correct prior to adding new functionality and applies to creating new methods, introducing inheritance, everything.
=Steps=

[[Image:PureFab.gif]]

Follow these steps:
*Understand the requirements of the story, work item, or feature that you are working on.
*Red:Create a test and make it fail.
Imagine how the new code should be called and write the test as if the code already existed.
Create the new production code stub. Write just enough code so that it compiles.
Run the test. It should fail. This is a calibration measure to ensure that your test is calling the correct code and that the code is not working by accident. This is a meaningful failure, and you expect it to fail.
*Green: Make the test pass by any means necessary.
Write the production code to make the test pass. Keep it simple.
Some advocate the hard-coding of the expected return value first to verify that the test correctly detects success. This varies from practitioner to practitioner.If you've written the code so that the test passes as intended, you are finished. You do not have to write more code speculatively. If new functionality is still needed, then another test is needed. Make this one test pass and continue.
When the test passes, you might want to run all tests up to this point to build confidence that everything else is still working.
*Refractor: Change the code to remove duplication in your project and to improve the design while ensuring that all tests still pass.
Remove duplication caused by the addition of the new functionality.
Make design changes to improve the overall solution.
After each refactoring, rerun all the tests to ensure that they all still pass.
*Repeat the cycle. Each cycle should be very short, and a typical hour should contain many Red/Green/ Refractor cycles.

=Examples=

==Homework Grades Program==

===Setup===
As a simple example, we are creating a program that keeps track of our homework grades. We envision that we would be able to get the average of these homework grades. Step one: write a test . Let's test an average function

<pre>
myHomework = new Homework();
myHomework.grades = [100, 50];
assert(myHomework.average(myHomework.grades) == 75);
</pre>

We will get multiple errors - this test won't even compile (but, that's ok for now). Let's take a look at what will generate error messages:

* class <code>Homework</code> not declared
* <code>Homework</code> constructor not declared
* field <code>grades</code> not declared
* method <code>average</code> not declared

Now, we fix the first error:

<pre>
class Homework {

}
</pre>

Second error:

<pre>
Homework(void) {

}
</pre>

Third error:

<pre>
int * grades;
</pre>

Fourth error:

<pre>
int average(int * grades) {
return 0; // default return value
}
</pre>

Finally, the test compiles! The code now looks like this:

<pre>
class Homework {

int * grades;

Homework(void) {

}

int average(int * grades) {

return 0; // default return value

}

}
</pre>

===Red===
Now, we run the test, and the familar red bar of failure greets us (remember the mantra red-green-refactor). The assert fails. The average function needs to actually average something (not just return 0). As we think about averaging the grades, we realize we need to know how many grades are in the int array <code>grades</code>. So, we add to the code:

<pre>
class Homework {

int * grades;
int numGrades; // new

Homework(void) {

}

int average(int * grades) {

int avg = 0; // new

for(int i = 0; i < numGrades; i++) { // new
avg += grades[i]; // new
} // new

return avg/numGrades; // new

}

}
</pre>

Of course, we must remember to change the test to:

<pre>
myHomework = new Homework();
myHomework.grades = [100, 50];
myHomework.numGrades = 2;
assert(myHomework.average(myHomework.grades) == 75);
</pre>

===Green===
Success! We have a green bar when we run it.

===Refactor===
The last step is refactoring. Perhaps we don't want a grade to be an <code>int</code>? Should it be an <code>unsigned int</code>? For this simple example, there isn't much refactoring to do, but in a larger example there may be multiple areas for improvement.

==More Examples==
See Test-Driven Development by Example by Kent Beck for more examples.

=Characteristics Of A Good Unit Test=
A good unit test has the following characteristics.
*It is important that the test executes fast. If the tests are slow, they will not be run often.
*Environmental dependencies such as databases, file systems, networks, queues, and so on which will slow down the tests are either separated or simulated. Tests that exercise these will not run fast, and a failure does not give meaningful feedback about what the problem actually is.
*The scope of testing is very limited. If the test fails, it's obvious where to look for the problem. It's important to only test one aspect in a single test.
*The test should run and pass in isolation (on any machine). If the tests require special environmental setup or fail unexpectedly, then they are not good unit tests.
*Such a test often uses stubs and mock objects. If the code being tested typically calls out to a database or file system, these dependencies must be simulated, or mocked. These dependencies will ordinarily be abstracted away by using interfaces.
*The intention of testing is clearly revealed. Another developer can look at the test and understand what is expected of the production code.

=Benefits Of TDD=
*Automated testing: Automated system makes the testing much more easier and faster. Manual testing is slower and needs human interaction which is error-prone. Automated testing makes sure any particular test is not missing every time we test the system, whereas humans may leave a test out mistakenly during testing process.
*Better to test New/Modified Functionality: With manual testing whenever you add new functionality or modify existing functionality, QA personal needs to test all systems that may be affected due to the modification which may be time-consuming. This may also leave a hidden bug in the system after modification. With TDD whenever a new functionality is added or existing functionality is modified, the whole set of tests in the system is run to make sure existing tests are passed. This makes sure that existing functionality is not broken.
*Developer’s confidence: With TDD, developers are more safe to change the system as any inappropriate changes will make some tests to fail. With non-TDD system developers needs to take more care to change existing system as the new change may fail other functionality. But with TDD developers can do so easily as after modification if developer runs the test he/she will find immediately that the change has failed some other tests (i.e. some other part of the system).
*Manual testing stage is shortened: In non-TDD development, as soon as developers prepare a build, QA personal starts testing. This manual testing takes a reasonable amount of time and increases the time to deliver the product from the build time. With TDD, a major part of the system is tested during development and needs lesser QA involvement in the time between build and final delivery of the product.
*Alternative Documentation: Unit tests are kind of documentation to system. Each unit test tells about an individual requirement to the module or system. For example, the following test ensures that only a logged in user with proper balance can buy an item when the item exists in stock. This test reflects a user aspect scenario of the system.

public void CheckUserCanNotPurchaseItemWithoutBalance(){
LoginToTheSystem();
SelectAnItemToBuy();
MakeSureItemExsitsInStock();
MakeSureUserHasBalanceToBuy();
RunTheTransaction();
}
*Better way to fix bugs: In TDD approach when QA finds a bug, developer first writes a test that generates the bug (that is the test will fail due to this bug). Then developer modifies code to make sure that the test is passed (i.e., the bug is fixed). This approach makes sure that next time the bug will not appear in the system as a test is written in the system to take care of the bug.
*Repetition of the same bug reduced: With TDD once a bug is found, it's put under test. So every time you run the whole test in the system, the tests associated with the bug are run and make sure the bugs are not generated again.

=Shortcomings Of TDD=
*The actual database or external file is never tested directly by TDD (only production code can test it)
*If not used carefully, it can add to the total project costs and complexity of the project
*TDD is unable to test UI.
*TDD is highly reliant on Refactoring and Programmer Skills.

=Conclusion=
Danielle
=References=
*[http://catalog.lib.ncsu.edu/record/NCSU1601963 Beck, K. (2002). Test-driven development by example. Addison-Wesley.]
*[http://en.wikipedia.org/wiki/Test_driven_development (n.d.). Test-driven development. website: http://en.wikipedia.org/wiki/Test_driven_development]
*[http://c2.com/cgi/wiki?TestDrivenDevelopment (2012, January 11). Test driven development. website: http://c2.com/cgi/wiki?TestDrivenDevelopment]
*[http://www.agiledata.org/essays/tdd.html Ambler, S. W. (2002). Introduction to test driven development (tdd). Retrieved from Agile Data website: http://www.agiledata.org/essays/tdd.html]
*[http://www.methodsandtools.com/archive/archive.php?id=20. Methods and Tools Archives]
*[http://www.martinfowler.com/bliki/TestDrivenDevelopment.html www.martinfowler.com/bliki/TestDrivenDevelopment]
*[http://www.codeproject.com/Articles/47747/Test-Driven-Development-TDD-Step-by-Step-Part-1-In TDD Step by Step Code Project]
*[http://integralpath.blogs.com/thinkingoutloud/2005/09/principles_of_t.html Principles of Testing]
*http://www.testdriven.com/ ?

CSC/ECE 517 Fall 2012/ch2a 2w11 aa

2012-10-23T21:15:08Z

Annice: /* Motivation for TDD */

=Introduction=
Test driven development (TDD) is a process that tries to create the minimal amount of code to meet customer's expectations. The idea is to test first, code second, then improve (or refactor) last. This process forces the software developers to focus on customer specifications and validation first. Since at each step of the way the programmer proves to himself that the code meets specifications, TDD gives the programmer confidence. The rest of this chapter gives the motivation for TDD, shows the steps for TDD, outlines the principles of TDD, and provides examples using TDD.

=Motivation for TDD=
[[File:TimevsCostDev.png|350px|Figure 1: Traditional "Cost of Change" curve with the waterfall model superimposed]]
The following sequence is based on the book ''[[Test-Driven Development by Example]]''.<ref name=Beck>Beck, K. Test-Driven Development by Example, Addison Wesley - Vaseem, 2003</ref>]]
*Testing is the one activity that improves the quality of code. In various design scenarios, like waterfall model, testing occurs towards the end of the project development activity. As shown in the figure 1, introducing testing as a latter phase increases the cost incurred for implementing the changes. From this we infer that there is a high chance of reducing the costs by moving the Test phase to the initial part.
*The client can also be well informed about the design and can suggest changes which can be incorporated well in advance. This approach also known as TDD helps achieve flexibility to achieve the client’s ever-changing requirements

=Principles=
*Tests serve as examples of how to use a class or method. Once used to having tests that show how things work (and that they work), developers start inquiring if a test was already there for the piece of code to be developed
*Developer tests are distinctly different from QA (Quality Analysis) tests and should be kept separate. QA tests target features and treat the system as a black box. Unit tests created by the developer operate at a lower level and test different things.
*Name the tests carefully. For Example, name test packages like the package being tested with a suffix. For example, the "DataAccess" project/package is tested by "DataAccess.Test". Also, name test classes the same as the class under test with the suffix "Test". For example, the class "PrintManager" is tested by the test class "PrintManagerTest". This convention makes it easy to find the related class and keeps the class name a noun. You should also name test methods the same as the method being tested with the prefix "Test". For example, the method "PrintProductOrder()" is tested by the method "TestPrintProductOrder()". This convention keeps the method name a verb that reads as an english phrase.
*Write each test before writing the method under test. It encourages the developer to think as a user of the target method before thinking about implementation, which usually results in a cleaner, easier-to-use interface.
*Follow the "3-As" pattern for test methods: Arrange, Act, Assert. Specifically, use separate code paragraphs (groups of lines of code separated by a blank line) for each of the As. Arrange is variable declaration and initialization. Act is invoking the code under test. Assert is using the Assert.* methods to verify that expectations were met.
*When writing application code, only write enough code to make a test work. This technique prevents gold-plating and ensures that you always have a test for the code you write.
*When you find you need to refractor working code, refractor and re-test prior to writing new code. This technique ensures your refractoring is correct prior to adding new functionality and applies to creating new methods, introducing inheritance, everything.
=Steps=

[[Image:PureFab.gif]]

Follow these steps:
*Understand the requirements of the story, work item, or feature that you are working on.
*Red:Create a test and make it fail.
Imagine how the new code should be called and write the test as if the code already existed.
Create the new production code stub. Write just enough code so that it compiles.
Run the test. It should fail. This is a calibration measure to ensure that your test is calling the correct code and that the code is not working by accident. This is a meaningful failure, and you expect it to fail.
*Green: Make the test pass by any means necessary.
Write the production code to make the test pass. Keep it simple.
Some advocate the hard-coding of the expected return value first to verify that the test correctly detects success. This varies from practitioner to practitioner.If you've written the code so that the test passes as intended, you are finished. You do not have to write more code speculatively. If new functionality is still needed, then another test is needed. Make this one test pass and continue.
When the test passes, you might want to run all tests up to this point to build confidence that everything else is still working.
*Refractor: Change the code to remove duplication in your project and to improve the design while ensuring that all tests still pass.
Remove duplication caused by the addition of the new functionality.
Make design changes to improve the overall solution.
After each refactoring, rerun all the tests to ensure that they all still pass.
*Repeat the cycle. Each cycle should be very short, and a typical hour should contain many Red/Green/ Refractor cycles.

=Examples=

==Homework Grades Program==

===Setup===
As a simple example, we are creating a program that keeps track of our homework grades. We envision that we would be able to get the average of these homework grades. Step one: write a test . Let's test an average function

<pre>
myHomework = new Homework();
myHomework.grades = [100, 50];
assert(myHomework.average(myHomework.grades) == 75);
</pre>

We will get multiple errors - this test won't even compile (but, that's ok for now). Let's take a look at what will generate error messages:

* class <code>Homework</code> not declared
* <code>Homework</code> constructor not declared
* field <code>grades</code> not declared
* method <code>average</code> not declared

Now, we fix the first error:

<pre>
class Homework {

}
</pre>

Second error:

<pre>
Homework(void) {

}
</pre>

Third error:

<pre>
int * grades;
</pre>

Fourth error:

<pre>
int average(int * grades) {
return 0; // default return value
}
</pre>

Finally, the test compiles! The code now looks like this:

<pre>
class Homework {

int * grades;

Homework(void) {

}

int average(int * grades) {

return 0; // default return value

}

}
</pre>

===Red===
Now, we run the test, and the familar red bar of failure greets us (remember the mantra red-green-refactor). The assert fails. The average function needs to actually average something (not just return 0). As we think about averaging the grades, we realize we need to know how many grades are in the int array <code>grades</code>. So, we add to the code:

<pre>
class Homework {

int * grades;
int numGrades; // new

Homework(void) {

}

int average(int * grades) {

int avg = 0; // new

for(int i = 0; i < numGrades; i++) { // new
avg += grades[i]; // new
} // new

return avg/numGrades; // new

}

}
</pre>

Of course, we must remember to change the test to:

<pre>
myHomework = new Homework();
myHomework.grades = [100, 50];
myHomework.numGrades = 2;
assert(myHomework.average(myHomework.grades) == 75);
</pre>

===Green===
Success! We have a green bar when we run it.

===Refactor===
The last step is refactoring. Perhaps we don't want a grade to be an <code>int</code>? Should it be an <code>unsigned int</code>? For this simple example, there isn't much refactoring to do, but in a larger example there may be multiple areas for improvement.

==More Examples==
See Test-Driven Development by Example by Kent Beck for more examples.

=Characteristics Of A Good Unit Test=
A good unit test has the following characteristics.
*It is important that the test executes fast. If the tests are slow, they will not be run often.
*Environmental dependencies such as databases, file systems, networks, queues, and so on which will slow down the tests are either separated or simulated. Tests that exercise these will not run fast, and a failure does not give meaningful feedback about what the problem actually is.
*The scope of testing is very limited. If the test fails, it's obvious where to look for the problem. It's important to only test one aspect in a single test.
*The test should run and pass in isolation (on any machine). If the tests require special environmental setup or fail unexpectedly, then they are not good unit tests.
*Such a test often uses stubs and mock objects. If the code being tested typically calls out to a database or file system, these dependencies must be simulated, or mocked. These dependencies will ordinarily be abstracted away by using interfaces.
*The intention of testing is clearly revealed. Another developer can look at the test and understand what is expected of the production code.

=Benefits Of TDD=
*Automated testing: Automated system makes the testing much more easier and faster. Manual testing is slower and needs human interaction which is error-prone. Automated testing makes sure any particular test is not missing every time we test the system, whereas humans may leave a test out mistakenly during testing process.
*Better to test New/Modified Functionality: With manual testing whenever you add new functionality or modify existing functionality, QA personal needs to test all systems that may be affected due to the modification which may be time-consuming. This may also leave a hidden bug in the system after modification. With TDD whenever a new functionality is added or existing functionality is modified, the whole set of tests in the system is run to make sure existing tests are passed. This makes sure that existing functionality is not broken.
*Developer’s confidence: With TDD, developers are more safe to change the system as any inappropriate changes will make some tests to fail. With non-TDD system developers needs to take more care to change existing system as the new change may fail other functionality. But with TDD developers can do so easily as after modification if developer runs the test he/she will find immediately that the change has failed some other tests (i.e. some other part of the system).
*Manual testing stage is shortened: In non-TDD development, as soon as developers prepare a build, QA personal starts testing. This manual testing takes a reasonable amount of time and increases the time to deliver the product from the build time. With TDD, a major part of the system is tested during development and needs lesser QA involvement in the time between build and final delivery of the product.
*Alternative Documentation: Unit tests are kind of documentation to system. Each unit test tells about an individual requirement to the module or system. For example, the following test ensures that only a logged in user with proper balance can buy an item when the item exists in stock. This test reflects a user aspect scenario of the system.

public void CheckUserCanNotPurchaseItemWithoutBalance(){
LoginToTheSystem();
SelectAnItemToBuy();
MakeSureItemExsitsInStock();
MakeSureUserHasBalanceToBuy();
RunTheTransaction();
}
*Better way to fix bugs: In TDD approach when QA finds a bug, developer first writes a test that generates the bug (that is the test will fail due to this bug). Then developer modifies code to make sure that the test is passed (i.e., the bug is fixed). This approach makes sure that next time the bug will not appear in the system as a test is written in the system to take care of the bug.
*Repetition of the same bug reduced: With TDD once a bug is found, it's put under test. So every time you run the whole test in the system, the tests associated with the bug are run and make sure the bugs are not generated again.

=Shortcomings Of TDD=
*The actual database or external file is never tested directly by TDD (only production code can test it)
*If not used carefully, it can add to the total project costs and complexity of the project
*TDD is unable to test UI.
*TDD is highly reliant on Refactoring and Programmer Skills.

=Conclusion=
Danielle
=References=
*[http://catalog.lib.ncsu.edu/record/NCSU1601963 Beck, K. (2002). Test-driven development by example. Addison-Wesley.]
*[http://en.wikipedia.org/wiki/Test_driven_development (n.d.). Test-driven development. website: http://en.wikipedia.org/wiki/Test_driven_development]
*[http://c2.com/cgi/wiki?TestDrivenDevelopment (2012, January 11). Test driven development. website: http://c2.com/cgi/wiki?TestDrivenDevelopment]
*[http://www.agiledata.org/essays/tdd.html Ambler, S. W. (2002). Introduction to test driven development (tdd). Retrieved from Agile Data website: http://www.agiledata.org/essays/tdd.html]
*[http://www.methodsandtools.com/archive/archive.php?id=20. Methods and Tools Archives]
*[http://www.martinfowler.com/bliki/TestDrivenDevelopment.html www.martinfowler.com/bliki/TestDrivenDevelopment]
*[http://www.codeproject.com/Articles/47747/Test-Driven-Development-TDD-Step-by-Step-Part-1-In TDD Step by Step Code Project]
*[http://integralpath.blogs.com/thinkingoutloud/2005/09/principles_of_t.html Principles of Testing]
*http://www.testdriven.com/ ?

CSC/ECE 517 Fall 2012/ch2a 2w11 aa

2012-10-23T21:13:26Z

Annice: /* Motivation for TDD */

=Introduction=
Test driven development (TDD) is a process that tries to create the minimal amount of code to meet customer's expectations. The idea is to test first, code second, then improve (or refactor) last. This process forces the software developers to focus on customer specifications and validation first. Since at each step of the way the programmer proves to himself that the code meets specifications, TDD gives the programmer confidence. The rest of this chapter gives the motivation for TDD, shows the steps for TDD, outlines the principles of TDD, and provides examples using TDD.

=Motivation for TDD=
[[File:TimevsCostDev.png|350px|thumb|right|A graphical representation of the development cycle, using a basic [[flowchart]]]]
The following sequence is based on the book ''[[Test-Driven Development by Example]]''.<ref name=Beck>Beck, K. Test-Driven Development by Example, Addison Wesley - Vaseem, 2003</ref>]]
*Testing is the one activity that improves the quality of code. In various design scenarios, like waterfall model, testing occurs towards the end of the project development activity. As shown in the figure 1, introducing testing as a latter phase increases the cost incurred for implementing the changes. From this we infer that there is a high chance of reducing the costs by moving the Test phase to the initial part.
*The client can also be well informed about the design and can suggest changes which can be incorporated well in advance. This approach also known as TDD helps achieve flexibility to achieve the client’s ever-changing requirements

=Principles=
*Tests serve as examples of how to use a class or method. Once used to having tests that show how things work (and that they work), developers start inquiring if a test was already there for the piece of code to be developed
*Developer tests are distinctly different from QA (Quality Analysis) tests and should be kept separate. QA tests target features and treat the system as a black box. Unit tests created by the developer operate at a lower level and test different things.
*Name the tests carefully. For Example, name test packages like the package being tested with a suffix. For example, the "DataAccess" project/package is tested by "DataAccess.Test". Also, name test classes the same as the class under test with the suffix "Test". For example, the class "PrintManager" is tested by the test class "PrintManagerTest". This convention makes it easy to find the related class and keeps the class name a noun. You should also name test methods the same as the method being tested with the prefix "Test". For example, the method "PrintProductOrder()" is tested by the method "TestPrintProductOrder()". This convention keeps the method name a verb that reads as an english phrase.
*Write each test before writing the method under test. It encourages the developer to think as a user of the target method before thinking about implementation, which usually results in a cleaner, easier-to-use interface.
*Follow the "3-As" pattern for test methods: Arrange, Act, Assert. Specifically, use separate code paragraphs (groups of lines of code separated by a blank line) for each of the As. Arrange is variable declaration and initialization. Act is invoking the code under test. Assert is using the Assert.* methods to verify that expectations were met.
*When writing application code, only write enough code to make a test work. This technique prevents gold-plating and ensures that you always have a test for the code you write.
*When you find you need to refractor working code, refractor and re-test prior to writing new code. This technique ensures your refractoring is correct prior to adding new functionality and applies to creating new methods, introducing inheritance, everything.
=Steps=

[[Image:PureFab.gif]]

Follow these steps:
*Understand the requirements of the story, work item, or feature that you are working on.
*Red:Create a test and make it fail.
Imagine how the new code should be called and write the test as if the code already existed.
Create the new production code stub. Write just enough code so that it compiles.
Run the test. It should fail. This is a calibration measure to ensure that your test is calling the correct code and that the code is not working by accident. This is a meaningful failure, and you expect it to fail.
*Green: Make the test pass by any means necessary.
Write the production code to make the test pass. Keep it simple.
Some advocate the hard-coding of the expected return value first to verify that the test correctly detects success. This varies from practitioner to practitioner.If you've written the code so that the test passes as intended, you are finished. You do not have to write more code speculatively. If new functionality is still needed, then another test is needed. Make this one test pass and continue.
When the test passes, you might want to run all tests up to this point to build confidence that everything else is still working.
*Refractor: Change the code to remove duplication in your project and to improve the design while ensuring that all tests still pass.
Remove duplication caused by the addition of the new functionality.
Make design changes to improve the overall solution.
After each refactoring, rerun all the tests to ensure that they all still pass.
*Repeat the cycle. Each cycle should be very short, and a typical hour should contain many Red/Green/ Refractor cycles.

=Examples=

==Homework Grades Program==

===Setup===
As a simple example, we are creating a program that keeps track of our homework grades. We envision that we would be able to get the average of these homework grades. Step one: write a test . Let's test an average function

<pre>
myHomework = new Homework();
myHomework.grades = [100, 50];
assert(myHomework.average(myHomework.grades) == 75);
</pre>

We will get multiple errors - this test won't even compile (but, that's ok for now). Let's take a look at what will generate error messages:

* class <code>Homework</code> not declared
* <code>Homework</code> constructor not declared
* field <code>grades</code> not declared
* method <code>average</code> not declared

Now, we fix the first error:

<pre>
class Homework {

}
</pre>

Second error:

<pre>
Homework(void) {

}
</pre>

Third error:

<pre>
int * grades;
</pre>

Fourth error:

<pre>
int average(int * grades) {
return 0; // default return value
}
</pre>

Finally, the test compiles! The code now looks like this:

<pre>
class Homework {

int * grades;

Homework(void) {

}

int average(int * grades) {

return 0; // default return value

}

}
</pre>

===Red===
Now, we run the test, and the familar red bar of failure greets us (remember the mantra red-green-refactor). The assert fails. The average function needs to actually average something (not just return 0). As we think about averaging the grades, we realize we need to know how many grades are in the int array <code>grades</code>. So, we add to the code:

<pre>
class Homework {

int * grades;
int numGrades; // new

Homework(void) {

}

int average(int * grades) {

int avg = 0; // new

for(int i = 0; i < numGrades; i++) { // new
avg += grades[i]; // new
} // new

return avg/numGrades; // new

}

}
</pre>

Of course, we must remember to change the test to:

<pre>
myHomework = new Homework();
myHomework.grades = [100, 50];
myHomework.numGrades = 2;
assert(myHomework.average(myHomework.grades) == 75);
</pre>

===Green===
Success! We have a green bar when we run it.

===Refactor===
The last step is refactoring. Perhaps we don't want a grade to be an <code>int</code>? Should it be an <code>unsigned int</code>? For this simple example, there isn't much refactoring to do, but in a larger example there may be multiple areas for improvement.

==More Examples==
See Test-Driven Development by Example by Kent Beck for more examples.

=Characteristics Of A Good Unit Test=
A good unit test has the following characteristics.
*It is important that the test executes fast. If the tests are slow, they will not be run often.
*Environmental dependencies such as databases, file systems, networks, queues, and so on which will slow down the tests are either separated or simulated. Tests that exercise these will not run fast, and a failure does not give meaningful feedback about what the problem actually is.
*The scope of testing is very limited. If the test fails, it's obvious where to look for the problem. It's important to only test one aspect in a single test.
*The test should run and pass in isolation (on any machine). If the tests require special environmental setup or fail unexpectedly, then they are not good unit tests.
*Such a test often uses stubs and mock objects. If the code being tested typically calls out to a database or file system, these dependencies must be simulated, or mocked. These dependencies will ordinarily be abstracted away by using interfaces.
*The intention of testing is clearly revealed. Another developer can look at the test and understand what is expected of the production code.

=Benefits Of TDD=
*Automated testing: Automated system makes the testing much more easier and faster. Manual testing is slower and needs human interaction which is error-prone. Automated testing makes sure any particular test is not missing every time we test the system, whereas humans may leave a test out mistakenly during testing process.
*Better to test New/Modified Functionality: With manual testing whenever you add new functionality or modify existing functionality, QA personal needs to test all systems that may be affected due to the modification which may be time-consuming. This may also leave a hidden bug in the system after modification. With TDD whenever a new functionality is added or existing functionality is modified, the whole set of tests in the system is run to make sure existing tests are passed. This makes sure that existing functionality is not broken.
*Developer’s confidence: With TDD, developers are more safe to change the system as any inappropriate changes will make some tests to fail. With non-TDD system developers needs to take more care to change existing system as the new change may fail other functionality. But with TDD developers can do so easily as after modification if developer runs the test he/she will find immediately that the change has failed some other tests (i.e. some other part of the system).
*Manual testing stage is shortened: In non-TDD development, as soon as developers prepare a build, QA personal starts testing. This manual testing takes a reasonable amount of time and increases the time to deliver the product from the build time. With TDD, a major part of the system is tested during development and needs lesser QA involvement in the time between build and final delivery of the product.
*Alternative Documentation: Unit tests are kind of documentation to system. Each unit test tells about an individual requirement to the module or system. For example, the following test ensures that only a logged in user with proper balance can buy an item when the item exists in stock. This test reflects a user aspect scenario of the system.

public void CheckUserCanNotPurchaseItemWithoutBalance(){
LoginToTheSystem();
SelectAnItemToBuy();
MakeSureItemExsitsInStock();
MakeSureUserHasBalanceToBuy();
RunTheTransaction();
}
*Better way to fix bugs: In TDD approach when QA finds a bug, developer first writes a test that generates the bug (that is the test will fail due to this bug). Then developer modifies code to make sure that the test is passed (i.e., the bug is fixed). This approach makes sure that next time the bug will not appear in the system as a test is written in the system to take care of the bug.
*Repetition of the same bug reduced: With TDD once a bug is found, it's put under test. So every time you run the whole test in the system, the tests associated with the bug are run and make sure the bugs are not generated again.

=Shortcomings Of TDD=
*The actual database or external file is never tested directly by TDD (only production code can test it)
*If not used carefully, it can add to the total project costs and complexity of the project
*TDD is unable to test UI.
*TDD is highly reliant on Refactoring and Programmer Skills.

=Conclusion=
Danielle
=References=
*[http://catalog.lib.ncsu.edu/record/NCSU1601963 Beck, K. (2002). Test-driven development by example. Addison-Wesley.]
*[http://en.wikipedia.org/wiki/Test_driven_development (n.d.). Test-driven development. website: http://en.wikipedia.org/wiki/Test_driven_development]
*[http://c2.com/cgi/wiki?TestDrivenDevelopment (2012, January 11). Test driven development. website: http://c2.com/cgi/wiki?TestDrivenDevelopment]
*[http://www.agiledata.org/essays/tdd.html Ambler, S. W. (2002). Introduction to test driven development (tdd). Retrieved from Agile Data website: http://www.agiledata.org/essays/tdd.html]
*[http://www.methodsandtools.com/archive/archive.php?id=20. Methods and Tools Archives]
*[http://www.martinfowler.com/bliki/TestDrivenDevelopment.html www.martinfowler.com/bliki/TestDrivenDevelopment]
*[http://www.codeproject.com/Articles/47747/Test-Driven-Development-TDD-Step-by-Step-Part-1-In TDD Step by Step Code Project]
*[http://integralpath.blogs.com/thinkingoutloud/2005/09/principles_of_t.html Principles of Testing]
*http://www.testdriven.com/ ?

CSC/ECE 517 Fall 2012/ch2a 2w11 aa

2012-10-23T21:11:35Z

Annice: /* Motivation for TDD */

=Introduction=
Test driven development (TDD) is a process that tries to create the minimal amount of code to meet customer's expectations. The idea is to test first, code second, then improve (or refactor) last. This process forces the software developers to focus on customer specifications and validation first. Since at each step of the way the programmer proves to himself that the code meets specifications, TDD gives the programmer confidence. The rest of this chapter gives the motivation for TDD, shows the steps for TDD, outlines the principles of TDD, and provides examples using TDD.

=Motivation for TDD=
[[File:TimevsCostDev.png]]
*Testing is the one activity that improves the quality of code. In various design scenarios, like waterfall model, testing occurs towards the end of the project development activity. As shown in the figure 1, introducing testing as a latter phase increases the cost incurred for implementing the changes. From this we infer that there is a high chance of reducing the costs by moving the Test phase to the initial part.
*The client can also be well informed about the design and can suggest changes which can be incorporated well in advance. This approach also known as TDD helps achieve flexibility to achieve the client’s ever-changing requirements

=Principles=
*Tests serve as examples of how to use a class or method. Once used to having tests that show how things work (and that they work), developers start inquiring if a test was already there for the piece of code to be developed
*Developer tests are distinctly different from QA (Quality Analysis) tests and should be kept separate. QA tests target features and treat the system as a black box. Unit tests created by the developer operate at a lower level and test different things.
*Name the tests carefully. For Example, name test packages like the package being tested with a suffix. For example, the "DataAccess" project/package is tested by "DataAccess.Test". Also, name test classes the same as the class under test with the suffix "Test". For example, the class "PrintManager" is tested by the test class "PrintManagerTest". This convention makes it easy to find the related class and keeps the class name a noun. You should also name test methods the same as the method being tested with the prefix "Test". For example, the method "PrintProductOrder()" is tested by the method "TestPrintProductOrder()". This convention keeps the method name a verb that reads as an english phrase.
*Write each test before writing the method under test. It encourages the developer to think as a user of the target method before thinking about implementation, which usually results in a cleaner, easier-to-use interface.
*Follow the "3-As" pattern for test methods: Arrange, Act, Assert. Specifically, use separate code paragraphs (groups of lines of code separated by a blank line) for each of the As. Arrange is variable declaration and initialization. Act is invoking the code under test. Assert is using the Assert.* methods to verify that expectations were met.
*When writing application code, only write enough code to make a test work. This technique prevents gold-plating and ensures that you always have a test for the code you write.
*When you find you need to refractor working code, refractor and re-test prior to writing new code. This technique ensures your refractoring is correct prior to adding new functionality and applies to creating new methods, introducing inheritance, everything.
=Steps=

[[Image:PureFab.gif]]

Follow these steps:
*Understand the requirements of the story, work item, or feature that you are working on.
*Red:Create a test and make it fail.
Imagine how the new code should be called and write the test as if the code already existed.
Create the new production code stub. Write just enough code so that it compiles.
Run the test. It should fail. This is a calibration measure to ensure that your test is calling the correct code and that the code is not working by accident. This is a meaningful failure, and you expect it to fail.
*Green: Make the test pass by any means necessary.
Write the production code to make the test pass. Keep it simple.
Some advocate the hard-coding of the expected return value first to verify that the test correctly detects success. This varies from practitioner to practitioner.If you've written the code so that the test passes as intended, you are finished. You do not have to write more code speculatively. If new functionality is still needed, then another test is needed. Make this one test pass and continue.
When the test passes, you might want to run all tests up to this point to build confidence that everything else is still working.
*Refractor: Change the code to remove duplication in your project and to improve the design while ensuring that all tests still pass.
Remove duplication caused by the addition of the new functionality.
Make design changes to improve the overall solution.
After each refactoring, rerun all the tests to ensure that they all still pass.
*Repeat the cycle. Each cycle should be very short, and a typical hour should contain many Red/Green/ Refractor cycles.

=Examples=

==Homework Grades Program==

===Setup===
As a simple example, we are creating a program that keeps track of our homework grades. We envision that we would be able to get the average of these homework grades. Step one: write a test . Let's test an average function

<pre>
myHomework = new Homework();
myHomework.grades = [100, 50];
assert(myHomework.average(myHomework.grades) == 75);
</pre>

We will get multiple errors - this test won't even compile (but, that's ok for now). Let's take a look at what will generate error messages:

* class <code>Homework</code> not declared
* <code>Homework</code> constructor not declared
* field <code>grades</code> not declared
* method <code>average</code> not declared

Now, we fix the first error:

<pre>
class Homework {

}
</pre>

Second error:

<pre>
Homework(void) {

}
</pre>

Third error:

<pre>
int * grades;
</pre>

Fourth error:

<pre>
int average(int * grades) {
return 0; // default return value
}
</pre>

Finally, the test compiles! The code now looks like this:

<pre>
class Homework {

int * grades;

Homework(void) {

}

int average(int * grades) {

return 0; // default return value

}

}
</pre>

===Red===
Now, we run the test, and the familar red bar of failure greets us (remember the mantra red-green-refactor). The assert fails. The average function needs to actually average something (not just return 0). As we think about averaging the grades, we realize we need to know how many grades are in the int array <code>grades</code>. So, we add to the code:

<pre>
class Homework {

int * grades;
int numGrades; // new

Homework(void) {

}

int average(int * grades) {

int avg = 0; // new

for(int i = 0; i < numGrades; i++) { // new
avg += grades[i]; // new
} // new

return avg/numGrades; // new

}

}
</pre>

Of course, we must remember to change the test to:

<pre>
myHomework = new Homework();
myHomework.grades = [100, 50];
myHomework.numGrades = 2;
assert(myHomework.average(myHomework.grades) == 75);
</pre>

===Green===
Success! We have a green bar when we run it.

===Refactor===
The last step is refactoring. Perhaps we don't want a grade to be an <code>int</code>? Should it be an <code>unsigned int</code>? For this simple example, there isn't much refactoring to do, but in a larger example there may be multiple areas for improvement.

==More Examples==
See Test-Driven Development by Example by Kent Beck for more examples.

=Characteristics Of A Good Unit Test=
A good unit test has the following characteristics.
*It is important that the test executes fast. If the tests are slow, they will not be run often.
*Environmental dependencies such as databases, file systems, networks, queues, and so on which will slow down the tests are either separated or simulated. Tests that exercise these will not run fast, and a failure does not give meaningful feedback about what the problem actually is.
*The scope of testing is very limited. If the test fails, it's obvious where to look for the problem. It's important to only test one aspect in a single test.
*The test should run and pass in isolation (on any machine). If the tests require special environmental setup or fail unexpectedly, then they are not good unit tests.
*Such a test often uses stubs and mock objects. If the code being tested typically calls out to a database or file system, these dependencies must be simulated, or mocked. These dependencies will ordinarily be abstracted away by using interfaces.
*The intention of testing is clearly revealed. Another developer can look at the test and understand what is expected of the production code.

=Benefits Of TDD=
*Automated testing: Automated system makes the testing much more easier and faster. Manual testing is slower and needs human interaction which is error-prone. Automated testing makes sure any particular test is not missing every time we test the system, whereas humans may leave a test out mistakenly during testing process.
*Better to test New/Modified Functionality: With manual testing whenever you add new functionality or modify existing functionality, QA personal needs to test all systems that may be affected due to the modification which may be time-consuming. This may also leave a hidden bug in the system after modification. With TDD whenever a new functionality is added or existing functionality is modified, the whole set of tests in the system is run to make sure existing tests are passed. This makes sure that existing functionality is not broken.
*Developer’s confidence: With TDD, developers are more safe to change the system as any inappropriate changes will make some tests to fail. With non-TDD system developers needs to take more care to change existing system as the new change may fail other functionality. But with TDD developers can do so easily as after modification if developer runs the test he/she will find immediately that the change has failed some other tests (i.e. some other part of the system).
*Manual testing stage is shortened: In non-TDD development, as soon as developers prepare a build, QA personal starts testing. This manual testing takes a reasonable amount of time and increases the time to deliver the product from the build time. With TDD, a major part of the system is tested during development and needs lesser QA involvement in the time between build and final delivery of the product.
*Alternative Documentation: Unit tests are kind of documentation to system. Each unit test tells about an individual requirement to the module or system. For example, the following test ensures that only a logged in user with proper balance can buy an item when the item exists in stock. This test reflects a user aspect scenario of the system.

public void CheckUserCanNotPurchaseItemWithoutBalance(){
LoginToTheSystem();
SelectAnItemToBuy();
MakeSureItemExsitsInStock();
MakeSureUserHasBalanceToBuy();
RunTheTransaction();
}
*Better way to fix bugs: In TDD approach when QA finds a bug, developer first writes a test that generates the bug (that is the test will fail due to this bug). Then developer modifies code to make sure that the test is passed (i.e., the bug is fixed). This approach makes sure that next time the bug will not appear in the system as a test is written in the system to take care of the bug.
*Repetition of the same bug reduced: With TDD once a bug is found, it's put under test. So every time you run the whole test in the system, the tests associated with the bug are run and make sure the bugs are not generated again.

=Shortcomings Of TDD=
*The actual database or external file is never tested directly by TDD (only production code can test it)
*If not used carefully, it can add to the total project costs and complexity of the project
*TDD is unable to test UI.
*TDD is highly reliant on Refactoring and Programmer Skills.

=Conclusion=
Danielle
=References=
*[http://catalog.lib.ncsu.edu/record/NCSU1601963 Beck, K. (2002). Test-driven development by example. Addison-Wesley.]
*[http://en.wikipedia.org/wiki/Test_driven_development (n.d.). Test-driven development. website: http://en.wikipedia.org/wiki/Test_driven_development]
*[http://c2.com/cgi/wiki?TestDrivenDevelopment (2012, January 11). Test driven development. website: http://c2.com/cgi/wiki?TestDrivenDevelopment]
*[http://www.agiledata.org/essays/tdd.html Ambler, S. W. (2002). Introduction to test driven development (tdd). Retrieved from Agile Data website: http://www.agiledata.org/essays/tdd.html]
*[http://www.methodsandtools.com/archive/archive.php?id=20. Methods and Tools Archives]
*[http://www.martinfowler.com/bliki/TestDrivenDevelopment.html www.martinfowler.com/bliki/TestDrivenDevelopment]
*[http://www.codeproject.com/Articles/47747/Test-Driven-Development-TDD-Step-by-Step-Part-1-In TDD Step by Step Code Project]
*[http://integralpath.blogs.com/thinkingoutloud/2005/09/principles_of_t.html Principles of Testing]
*http://www.testdriven.com/ ?

File:TimevsCostDev.png

2012-10-23T21:10:04Z

Annice: Time Vs Cost of change involved in development cycle

Time Vs Cost of change involved in development cycle

CSC/ECE 517 Fall 2012/ch2a 2w11 aa

2012-10-23T21:01:44Z

Annice: /* Steps */

=Introduction=
Test driven development (TDD) is a process that tries to create the minimal amount of code to meet customer's expectations. The idea is to test first, code second, then improve (or refactor) last. This process forces the software developers to focus on customer specifications and validation first. Since at each step of the way the programmer proves to himself that the code meets specifications, TDD gives the programmer confidence. The rest of this chapter gives the motivation for TDD, shows the steps for TDD, outlines the principles of TDD, and provides examples using TDD.

=Motivation for TDD=
*Testing is the one activity that improves the quality of code. In various design scenarios, like waterfall model, testing occurs towards the end of the project development activity. As shown in the figure 1, introducing testing as a latter phase increases the cost incurred for implementing the changes. From this we infer that there is a high chance of reducing the costs by moving the Test phase to the initial part.
*The client can also be well informed about the design and can suggest changes which can be incorporated well in advance. This approach also known as TDD helps achieve flexibility to achieve the client’s ever-changing requirements
=Principles=
*Tests serve as examples of how to use a class or method. Once used to having tests that show how things work (and that they work), developers start inquiring if a test was already there for the piece of code to be developed
*Developer tests are distinctly different from QA (Quality Analysis) tests and should be kept separate. QA tests target features and treat the system as a black box. Unit tests created by the developer operate at a lower level and test different things.
*Name the tests carefully. For Example, name test packages like the package being tested with a suffix. For example, the "DataAccess" project/package is tested by "DataAccess.Test". Also, name test classes the same as the class under test with the suffix "Test". For example, the class "PrintManager" is tested by the test class "PrintManagerTest". This convention makes it easy to find the related class and keeps the class name a noun. You should also name test methods the same as the method being tested with the prefix "Test". For example, the method "PrintProductOrder()" is tested by the method "TestPrintProductOrder()". This convention keeps the method name a verb that reads as an english phrase.
*Write each test before writing the method under test. It encourages the developer to think as a user of the target method before thinking about implementation, which usually results in a cleaner, easier-to-use interface.
*Follow the "3-As" pattern for test methods: Arrange, Act, Assert. Specifically, use separate code paragraphs (groups of lines of code separated by a blank line) for each of the As. Arrange is variable declaration and initialization. Act is invoking the code under test. Assert is using the Assert.* methods to verify that expectations were met.
*When writing application code, only write enough code to make a test work. This technique prevents gold-plating and ensures that you always have a test for the code you write.
*When you find you need to refractor working code, refractor and re-test prior to writing new code. This technique ensures your refractoring is correct prior to adding new functionality and applies to creating new methods, introducing inheritance, everything.
=Steps=

[[Image:PureFab.gif]]

Follow these steps:
*Understand the requirements of the story, work item, or feature that you are working on.
*Red:Create a test and make it fail.
Imagine how the new code should be called and write the test as if the code already existed.
Create the new production code stub. Write just enough code so that it compiles.
Run the test. It should fail. This is a calibration measure to ensure that your test is calling the correct code and that the code is not working by accident. This is a meaningful failure, and you expect it to fail.
*Green: Make the test pass by any means necessary.
Write the production code to make the test pass. Keep it simple.
Some advocate the hard-coding of the expected return value first to verify that the test correctly detects success. This varies from practitioner to practitioner.If you've written the code so that the test passes as intended, you are finished. You do not have to write more code speculatively. If new functionality is still needed, then another test is needed. Make this one test pass and continue.
When the test passes, you might want to run all tests up to this point to build confidence that everything else is still working.
*Refractor: Change the code to remove duplication in your project and to improve the design while ensuring that all tests still pass.
Remove duplication caused by the addition of the new functionality.
Make design changes to improve the overall solution.
After each refactoring, rerun all the tests to ensure that they all still pass.
*Repeat the cycle. Each cycle should be very short, and a typical hour should contain many Red/Green/ Refractor cycles.

=Examples=

==Homework Grades Program==

===Setup===
As a simple example, we are creating a program that keeps track of our homework grades. We envision that we would be able to get the average of these homework grades. Step one: write a test . Let's test an average function

<pre>
myHomework = new Homework();
myHomework.grades = [100, 50];
assert(myHomework.average(myHomework.grades) == 75);
</pre>

We will get multiple errors - this test won't even compile (but, that's ok for now). Let's take a look at what will generate error messages:

* class <code>Homework</code> not declared
* <code>Homework</code> constructor not declared
* field <code>grades</code> not declared
* method <code>average</code> not declared

Now, we fix the first error:

<pre>
class Homework {

}
</pre>

Second error:

<pre>
Homework(void) {

}
</pre>

Third error:

<pre>
int * grades;
</pre>

Fourth error:

<pre>
int average(int * grades) {
return 0; // default return value
}
</pre>

Finally, the test compiles! The code now looks like this:

<pre>
class Homework {

int * grades;

Homework(void) {

}

int average(int * grades) {

return 0; // default return value

}

}
</pre>

===Red===
Now, we run the test, and the familar red bar of failure greets us (remember the mantra red-green-refactor). The assert fails. The average function needs to actually average something (not just return 0). As we think about averaging the grades, we realize we need to know how many grades are in the int array <code>grades</code>. So, we add to the code:

<pre>
class Homework {

int * grades;
int numGrades; // new

Homework(void) {

}

int average(int * grades) {

int avg = 0; // new

for(int i = 0; i < numGrades; i++) { // new
avg += grades[i]; // new
} // new

return avg/numGrades; // new

}

}
</pre>

Of course, we must remember to change the test to:

<pre>
myHomework = new Homework();
myHomework.grades = [100, 50];
myHomework.numGrades = 2;
assert(myHomework.average(myHomework.grades) == 75);
</pre>

===Green===
Success! We have a green bar when we run it.

===Refactor===
The last step is refactoring. Perhaps we don't want a grade to be an <code>int</code>? Should it be an <code>unsigned int</code>? For this simple example, there isn't much refactoring to do, but in a larger example there may be multiple areas for improvement.

==More Examples==
See Test-Driven Development by Example by Kent Beck for more examples.

=Characteristics Of A Good Unit Test=
A good unit test has the following characteristics.
*It is important that the test executes fast. If the tests are slow, they will not be run often.
*Environmental dependencies such as databases, file systems, networks, queues, and so on which will slow down the tests are either separated or simulated. Tests that exercise these will not run fast, and a failure does not give meaningful feedback about what the problem actually is.
*The scope of testing is very limited. If the test fails, it's obvious where to look for the problem. It's important to only test one aspect in a single test.
*The test should run and pass in isolation (on any machine). If the tests require special environmental setup or fail unexpectedly, then they are not good unit tests.
*Such a test often uses stubs and mock objects. If the code being tested typically calls out to a database or file system, these dependencies must be simulated, or mocked. These dependencies will ordinarily be abstracted away by using interfaces.
*The intention of testing is clearly revealed. Another developer can look at the test and understand what is expected of the production code.

=Benefits Of TDD=
*Automated testing: Automated system makes the testing much more easier and faster. Manual testing is slower and needs human interaction which is error-prone. Automated testing makes sure any particular test is not missing every time we test the system, whereas humans may leave a test out mistakenly during testing process.
*Better to test New/Modified Functionality: With manual testing whenever you add new functionality or modify existing functionality, QA personal needs to test all systems that may be affected due to the modification which may be time-consuming. This may also leave a hidden bug in the system after modification. With TDD whenever a new functionality is added or existing functionality is modified, the whole set of tests in the system is run to make sure existing tests are passed. This makes sure that existing functionality is not broken.
*Developer’s confidence: With TDD, developers are more safe to change the system as any inappropriate changes will make some tests to fail. With non-TDD system developers needs to take more care to change existing system as the new change may fail other functionality. But with TDD developers can do so easily as after modification if developer runs the test he/she will find immediately that the change has failed some other tests (i.e. some other part of the system).
*Manual testing stage is shortened: In non-TDD development, as soon as developers prepare a build, QA personal starts testing. This manual testing takes a reasonable amount of time and increases the time to deliver the product from the build time. With TDD, a major part of the system is tested during development and needs lesser QA involvement in the time between build and final delivery of the product.
*Alternative Documentation: Unit tests are kind of documentation to system. Each unit test tells about an individual requirement to the module or system. For example, the following test ensures that only a logged in user with proper balance can buy an item when the item exists in stock. This test reflects a user aspect scenario of the system.

public void CheckUserCanNotPurchaseItemWithoutBalance(){
LoginToTheSystem();
SelectAnItemToBuy();
MakeSureItemExsitsInStock();
MakeSureUserHasBalanceToBuy();
RunTheTransaction();
}
*Better way to fix bugs: In TDD approach when QA finds a bug, developer first writes a test that generates the bug (that is the test will fail due to this bug). Then developer modifies code to make sure that the test is passed (i.e., the bug is fixed). This approach makes sure that next time the bug will not appear in the system as a test is written in the system to take care of the bug.
*Repetition of the same bug reduced: With TDD once a bug is found, it's put under test. So every time you run the whole test in the system, the tests associated with the bug are run and make sure the bugs are not generated again.

=Shortcomings Of TDD=
*The actual database or external file is never tested directly by TDD (only production code can test it)
*If not used carefully, it can add to the total project costs and complexity of the project
*TDD is unable to test UI.
*TDD is highly reliant on Refactoring and Programmer Skills.

=Conclusion=
Danielle
=References=
*[http://catalog.lib.ncsu.edu/record/NCSU1601963 Beck, K. (2002). Test-driven development by example. Addison-Wesley.]
*[http://en.wikipedia.org/wiki/Test_driven_development (n.d.). Test-driven development. website: http://en.wikipedia.org/wiki/Test_driven_development]
*[http://c2.com/cgi/wiki?TestDrivenDevelopment (2012, January 11). Test driven development. website: http://c2.com/cgi/wiki?TestDrivenDevelopment]
*[http://www.agiledata.org/essays/tdd.html Ambler, S. W. (2002). Introduction to test driven development (tdd). Retrieved from Agile Data website: http://www.agiledata.org/essays/tdd.html]
*[http://www.methodsandtools.com/archive/archive.php?id=20. Methods and Tools Archives]
*[http://www.martinfowler.com/bliki/TestDrivenDevelopment.html www.martinfowler.com/bliki/TestDrivenDevelopment]
*[http://www.codeproject.com/Articles/47747/Test-Driven-Development-TDD-Step-by-Step-Part-1-In TDD Step by Step Code Project]
*[http://integralpath.blogs.com/thinkingoutloud/2005/09/principles_of_t.html Principles of Testing]
*http://www.testdriven.com/ ?

CSC/ECE 517 Fall 2012/ch2a 2w11 aa

2012-10-23T20:21:28Z

Annice: /* References */

=Introduction=
Test driven development (TDD) is a process that tries to create the minimal amount of code to meet customer's expectations. The idea is to test first, code second, then improve (or refactor) last. This process forces the software developers to focus on customer specifications and validation first. Since at each step of the way the programmer proves to himself that the code meets specifications, TDD gives the programmer confidence. The rest of this chapter gives the motivation for TDD, shows the steps for TDD, outlines the principles of TDD, and provides examples using TDD.

=Motivation for TDD=
*Testing is the one activity that improves the quality of code. In various design scenarios, like waterfall model, testing occurs towards the end of the project development activity. As shown in the figure 1, introducing testing as a latter phase increases the cost incurred for implementing the changes. From this we infer that there is a high chance of reducing the costs by moving the Test phase to the initial part.
*The client can also be well informed about the design and can suggest changes which can be incorporated well in advance. This approach also known as TDD helps achieve flexibility to achieve the client’s ever-changing requirements
=Principles=
*Tests serve as examples of how to use a class or method. Once used to having tests that show how things work (and that they work), developers start inquiring if a test was already there for the piece of code to be developed
*Developer tests are distinctly different from QA (Quality Analysis) tests and should be kept separate. QA tests target features and treat the system as a black box. Unit tests created by the developer operate at a lower level and test different things.
*Name the tests carefully. For Example, name test packages like the package being tested with a suffix. For example, the "DataAccess" project/package is tested by "DataAccess.Test". Also, name test classes the same as the class under test with the suffix "Test". For example, the class "PrintManager" is tested by the test class "PrintManagerTest". This convention makes it easy to find the related class and keeps the class name a noun. You should also name test methods the same as the method being tested with the prefix "Test". For example, the method "PrintProductOrder()" is tested by the method "TestPrintProductOrder()". This convention keeps the method name a verb that reads as an english phrase.
*Write each test before writing the method under test. It encourages the developer to think as a user of the target method before thinking about implementation, which usually results in a cleaner, easier-to-use interface.
*Follow the "3-As" pattern for test methods: Arrange, Act, Assert. Specifically, use separate code paragraphs (groups of lines of code separated by a blank line) for each of the As. Arrange is variable declaration and initialization. Act is invoking the code under test. Assert is using the Assert.* methods to verify that expectations were met.
*When writing application code, only write enough code to make a test work. This technique prevents gold-plating and ensures that you always have a test for the code you write.
*When you find you need to refractor working code, refractor and re-test prior to writing new code. This technique ensures your refractoring is correct prior to adding new functionality and applies to creating new methods, introducing inheritance, everything.
=Steps=

Follow these steps:
*Understand the requirements of the story, work item, or feature that you are working on.
*Red:Create a test and make it fail.
Imagine how the new code should be called and write the test as if the code already existed.
Create the new production code stub. Write just enough code so that it compiles.
Run the test. It should fail. This is a calibration measure to ensure that your test is calling the correct code and that the code is not working by accident. This is a meaningful failure, and you expect it to fail.
*Green: Make the test pass by any means necessary.
Write the production code to make the test pass. Keep it simple.
Some advocate the hard-coding of the expected return value first to verify that the test correctly detects success. This varies from practitioner to practitioner.If you've written the code so that the test passes as intended, you are finished. You do not have to write more code speculatively. If new functionality is still needed, then another test is needed. Make this one test pass and continue.
When the test passes, you might want to run all tests up to this point to build confidence that everything else is still working.
*Refractor: Change the code to remove duplication in your project and to improve the design while ensuring that all tests still pass.
Remove duplication caused by the addition of the new functionality.
Make design changes to improve the overall solution.
After each refactoring, rerun all the tests to ensure that they all still pass.
*Repeat the cycle. Each cycle should be very short, and a typical hour should contain many Red/Green/ Refractor cycles.

=Examples=

==Homework Grades Program==

===Setup===
As a simple example, we are creating a program that keeps track of our homework grades. We envision that we would be able to get the average of these homework grades. Step one: write a test . Let's test an average function

<pre>
myHomework = new Homework();
myHomework.grades = [100, 50];
assert(myHomework.average(myHomework.grades) == 75);
</pre>

We will get multiple errors - this test won't even compile (but, that's ok for now). Let's take a look at what will generate error messages:

* class <code>Homework</code> not declared
* <code>Homework</code> constructor not declared
* field <code>grades</code> not declared
* method <code>average</code> not declared

Now, we fix the first error:

<pre>
class Homework {

}
</pre>

Second error:

<pre>
Homework(void) {

}
</pre>

Third error:

<pre>
int * grades;
</pre>

Fourth error:

<pre>
int average(int * grades) {
return 0; // default return value
}
</pre>

Finally, the test compiles! The code now looks like this:

<pre>
class Homework {

int * grades;

Homework(void) {

}

int average(int * grades) {

return 0; // default return value

}

}
</pre>

===Red===
Now, we run the test, and the familar red bar of failure greets us (remember the mantra red-green-refactor). The assert fails. The average function needs to actually average something (not just return 0). As we think about averaging the grades, we realize we need to know how many grades are in the int array <code>grades</code>. So, we add to the code:

<pre>
class Homework {

int * grades;
int numGrades; // new

Homework(void) {

}

int average(int * grades) {

int avg = 0; // new

for(int i = 0; i < numGrades; i++) { // new
avg += grades[i]; // new
} // new

return avg/numGrades; // new

}

}
</pre>

Of course, we must remember to change the test to:

<pre>
myHomework = new Homework();
myHomework.grades = [100, 50];
myHomework.numGrades = 2;
assert(myHomework.average(myHomework.grades) == 75);
</pre>

===Green===
Success! We have a green bar when we run it.

===Refactor===
The last step is refactoring. Perhaps we don't want a grade to be an <code>int</code>? Should it be an <code>unsigned int</code>? For this simple example, there isn't much refactoring to do, but in a larger example there may be multiple areas for improvement.

==More Examples==
See Test-Driven Development by Example by Kent Beck for more examples.

=Characteristics Of A Good Unit Test=
A good unit test has the following characteristics.
*It is important that the test executes fast. If the tests are slow, they will not be run often.
*Environmental dependencies such as databases, file systems, networks, queues, and so on which will slow down the tests are either separated or simulated. Tests that exercise these will not run fast, and a failure does not give meaningful feedback about what the problem actually is.
*The scope of testing is very limited. If the test fails, it's obvious where to look for the problem. It's important to only test one aspect in a single test.
*The test should run and pass in isolation (on any machine). If the tests require special environmental setup or fail unexpectedly, then they are not good unit tests.
*Such a test often uses stubs and mock objects. If the code being tested typically calls out to a database or file system, these dependencies must be simulated, or mocked. These dependencies will ordinarily be abstracted away by using interfaces.
*The intention of testing is clearly revealed. Another developer can look at the test and understand what is expected of the production code.

=Benefits Of TDD=
*Automated testing: Automated system makes the testing much more easier and faster. Manual testing is slower and needs human interaction which is error-prone. Automated testing makes sure any particular test is not missing every time we test the system, whereas humans may leave a test out mistakenly during testing process.
*Better to test New/Modified Functionality: With manual testing whenever you add new functionality or modify existing functionality, QA personal needs to test all systems that may be affected due to the modification which may be time-consuming. This may also leave a hidden bug in the system after modification. With TDD whenever a new functionality is added or existing functionality is modified, the whole set of tests in the system is run to make sure existing tests are passed. This makes sure that existing functionality is not broken.
*Developer’s confidence: With TDD, developers are more safe to change the system as any inappropriate changes will make some tests to fail. With non-TDD system developers needs to take more care to change existing system as the new change may fail other functionality. But with TDD developers can do so easily as after modification if developer runs the test he/she will find immediately that the change has failed some other tests (i.e. some other part of the system).
*Manual testing stage is shortened: In non-TDD development, as soon as developers prepare a build, QA personal starts testing. This manual testing takes a reasonable amount of time and increases the time to deliver the product from the build time. With TDD, a major part of the system is tested during development and needs lesser QA involvement in the time between build and final delivery of the product.
*Alternative Documentation: Unit tests are kind of documentation to system. Each unit test tells about an individual requirement to the module or system. For example, the following test ensures that only a logged in user with proper balance can buy an item when the item exists in stock. This test reflects a user aspect scenario of the system.

public void CheckUserCanNotPurchaseItemWithoutBalance(){
LoginToTheSystem();
SelectAnItemToBuy();
MakeSureItemExsitsInStock();
MakeSureUserHasBalanceToBuy();
RunTheTransaction();
}
*Better way to fix bugs: In TDD approach when QA finds a bug, developer first writes a test that generates the bug (that is the test will fail due to this bug). Then developer modifies code to make sure that the test is passed (i.e., the bug is fixed). This approach makes sure that next time the bug will not appear in the system as a test is written in the system to take care of the bug.
*Repetition of the same bug reduced: With TDD once a bug is found, it's put under test. So every time you run the whole test in the system, the tests associated with the bug are run and make sure the bugs are not generated again.

=Shortcomings Of TDD=
*The actual database or external file is never tested directly by TDD (only production code can test it)
*If not used carefully, it can add to the total project costs and complexity of the project
*TDD is unable to test UI.
*TDD is highly reliant on Refactoring and Programmer Skills.

=Conclusion=
Danielle
=References=
*[http://catalog.lib.ncsu.edu/record/NCSU1601963 Beck, K. (2002). Test-driven development by example. Addison-Wesley.]
*[http://en.wikipedia.org/wiki/Test_driven_development (n.d.). Test-driven development. website: http://en.wikipedia.org/wiki/Test_driven_development]
*[http://c2.com/cgi/wiki?TestDrivenDevelopment (2012, January 11). Test driven development. website: http://c2.com/cgi/wiki?TestDrivenDevelopment]
*[http://www.agiledata.org/essays/tdd.html Ambler, S. W. (2002). Introduction to test driven development (tdd). Retrieved from Agile Data website: http://www.agiledata.org/essays/tdd.html]
*[http://www.methodsandtools.com/archive/archive.php?id=20. Methods and Tools Archives]
*[http://www.martinfowler.com/bliki/TestDrivenDevelopment.html www.martinfowler.com/bliki/TestDrivenDevelopment]
*[http://www.codeproject.com/Articles/47747/Test-Driven-Development-TDD-Step-by-Step-Part-1-In TDD Step by Step Code Project]
*[http://integralpath.blogs.com/thinkingoutloud/2005/09/principles_of_t.html Principles of Testing]
*http://www.testdriven.com/ ?

CSC/ECE 517 Fall 2012/ch2a 2w11 aa

2012-10-23T20:20:05Z

Annice: /* References */

=Introduction=
Test driven development (TDD) is a process that tries to create the minimal amount of code to meet customer's expectations. The idea is to test first, code second, then improve (or refactor) last. This process forces the software developers to focus on customer specifications and validation first. Since at each step of the way the programmer proves to himself that the code meets specifications, TDD gives the programmer confidence. The rest of this chapter gives the motivation for TDD, shows the steps for TDD, outlines the principles of TDD, and provides examples using TDD.

=Motivation for TDD=
*Testing is the one activity that improves the quality of code. In various design scenarios, like waterfall model, testing occurs towards the end of the project development activity. As shown in the figure 1, introducing testing as a latter phase increases the cost incurred for implementing the changes. From this we infer that there is a high chance of reducing the costs by moving the Test phase to the initial part.
*The client can also be well informed about the design and can suggest changes which can be incorporated well in advance. This approach also known as TDD helps achieve flexibility to achieve the client’s ever-changing requirements
=Principles=
*Tests serve as examples of how to use a class or method. Once used to having tests that show how things work (and that they work), developers start inquiring if a test was already there for the piece of code to be developed
*Developer tests are distinctly different from QA (Quality Analysis) tests and should be kept separate. QA tests target features and treat the system as a black box. Unit tests created by the developer operate at a lower level and test different things.
*Name the tests carefully. For Example, name test packages like the package being tested with a suffix. For example, the "DataAccess" project/package is tested by "DataAccess.Test". Also, name test classes the same as the class under test with the suffix "Test". For example, the class "PrintManager" is tested by the test class "PrintManagerTest". This convention makes it easy to find the related class and keeps the class name a noun. You should also name test methods the same as the method being tested with the prefix "Test". For example, the method "PrintProductOrder()" is tested by the method "TestPrintProductOrder()". This convention keeps the method name a verb that reads as an english phrase.
*Write each test before writing the method under test. It encourages the developer to think as a user of the target method before thinking about implementation, which usually results in a cleaner, easier-to-use interface.
*Follow the "3-As" pattern for test methods: Arrange, Act, Assert. Specifically, use separate code paragraphs (groups of lines of code separated by a blank line) for each of the As. Arrange is variable declaration and initialization. Act is invoking the code under test. Assert is using the Assert.* methods to verify that expectations were met.
*When writing application code, only write enough code to make a test work. This technique prevents gold-plating and ensures that you always have a test for the code you write.
*When you find you need to refractor working code, refractor and re-test prior to writing new code. This technique ensures your refractoring is correct prior to adding new functionality and applies to creating new methods, introducing inheritance, everything.
=Steps=

Follow these steps:
*Understand the requirements of the story, work item, or feature that you are working on.
*Red:Create a test and make it fail.
Imagine how the new code should be called and write the test as if the code already existed.
Create the new production code stub. Write just enough code so that it compiles.
Run the test. It should fail. This is a calibration measure to ensure that your test is calling the correct code and that the code is not working by accident. This is a meaningful failure, and you expect it to fail.
*Green: Make the test pass by any means necessary.
Write the production code to make the test pass. Keep it simple.
Some advocate the hard-coding of the expected return value first to verify that the test correctly detects success. This varies from practitioner to practitioner.If you've written the code so that the test passes as intended, you are finished. You do not have to write more code speculatively. If new functionality is still needed, then another test is needed. Make this one test pass and continue.
When the test passes, you might want to run all tests up to this point to build confidence that everything else is still working.
*Refractor: Change the code to remove duplication in your project and to improve the design while ensuring that all tests still pass.
Remove duplication caused by the addition of the new functionality.
Make design changes to improve the overall solution.
After each refactoring, rerun all the tests to ensure that they all still pass.
*Repeat the cycle. Each cycle should be very short, and a typical hour should contain many Red/Green/ Refractor cycles.

=Examples=

==Homework Grades Program==

===Setup===
As a simple example, we are creating a program that keeps track of our homework grades. We envision that we would be able to get the average of these homework grades. Step one: write a test . Let's test an average function

<pre>
myHomework = new Homework();
myHomework.grades = [100, 50];
assert(myHomework.average(myHomework.grades) == 75);
</pre>

We will get multiple errors - this test won't even compile (but, that's ok for now). Let's take a look at what will generate error messages:

* class <code>Homework</code> not declared
* <code>Homework</code> constructor not declared
* field <code>grades</code> not declared
* method <code>average</code> not declared

Now, we fix the first error:

<pre>
class Homework {

}
</pre>

Second error:

<pre>
Homework(void) {

}
</pre>

Third error:

<pre>
int * grades;
</pre>

Fourth error:

<pre>
int average(int * grades) {
return 0; // default return value
}
</pre>

Finally, the test compiles! The code now looks like this:

<pre>
class Homework {

int * grades;

Homework(void) {

}

int average(int * grades) {

return 0; // default return value

}

}
</pre>

===Red===
Now, we run the test, and the familar red bar of failure greets us (remember the mantra red-green-refactor). The assert fails. The average function needs to actually average something (not just return 0). As we think about averaging the grades, we realize we need to know how many grades are in the int array <code>grades</code>. So, we add to the code:

<pre>
class Homework {

int * grades;
int numGrades; // new

Homework(void) {

}

int average(int * grades) {

int avg = 0; // new

for(int i = 0; i < numGrades; i++) { // new
avg += grades[i]; // new
} // new

return avg/numGrades; // new

}

}
</pre>

Of course, we must remember to change the test to:

<pre>
myHomework = new Homework();
myHomework.grades = [100, 50];
myHomework.numGrades = 2;
assert(myHomework.average(myHomework.grades) == 75);
</pre>

===Green===
Success! We have a green bar when we run it.

===Refactor===
The last step is refactoring. Perhaps we don't want a grade to be an <code>int</code>? Should it be an <code>unsigned int</code>? For this simple example, there isn't much refactoring to do, but in a larger example there may be multiple areas for improvement.

==More Examples==
See Test-Driven Development by Example by Kent Beck for more examples.

=Characteristics Of A Good Unit Test=
A good unit test has the following characteristics.
*It is important that the test executes fast. If the tests are slow, they will not be run often.
*Environmental dependencies such as databases, file systems, networks, queues, and so on which will slow down the tests are either separated or simulated. Tests that exercise these will not run fast, and a failure does not give meaningful feedback about what the problem actually is.
*The scope of testing is very limited. If the test fails, it's obvious where to look for the problem. It's important to only test one aspect in a single test.
*The test should run and pass in isolation (on any machine). If the tests require special environmental setup or fail unexpectedly, then they are not good unit tests.
*Such a test often uses stubs and mock objects. If the code being tested typically calls out to a database or file system, these dependencies must be simulated, or mocked. These dependencies will ordinarily be abstracted away by using interfaces.
*The intention of testing is clearly revealed. Another developer can look at the test and understand what is expected of the production code.

=Benefits Of TDD=
*Automated testing: Automated system makes the testing much more easier and faster. Manual testing is slower and needs human interaction which is error-prone. Automated testing makes sure any particular test is not missing every time we test the system, whereas humans may leave a test out mistakenly during testing process.
*Better to test New/Modified Functionality: With manual testing whenever you add new functionality or modify existing functionality, QA personal needs to test all systems that may be affected due to the modification which may be time-consuming. This may also leave a hidden bug in the system after modification. With TDD whenever a new functionality is added or existing functionality is modified, the whole set of tests in the system is run to make sure existing tests are passed. This makes sure that existing functionality is not broken.
*Developer’s confidence: With TDD, developers are more safe to change the system as any inappropriate changes will make some tests to fail. With non-TDD system developers needs to take more care to change existing system as the new change may fail other functionality. But with TDD developers can do so easily as after modification if developer runs the test he/she will find immediately that the change has failed some other tests (i.e. some other part of the system).
*Manual testing stage is shortened: In non-TDD development, as soon as developers prepare a build, QA personal starts testing. This manual testing takes a reasonable amount of time and increases the time to deliver the product from the build time. With TDD, a major part of the system is tested during development and needs lesser QA involvement in the time between build and final delivery of the product.
*Alternative Documentation: Unit tests are kind of documentation to system. Each unit test tells about an individual requirement to the module or system. For example, the following test ensures that only a logged in user with proper balance can buy an item when the item exists in stock. This test reflects a user aspect scenario of the system.

public void CheckUserCanNotPurchaseItemWithoutBalance(){
LoginToTheSystem();
SelectAnItemToBuy();
MakeSureItemExsitsInStock();
MakeSureUserHasBalanceToBuy();
RunTheTransaction();
}
*Better way to fix bugs: In TDD approach when QA finds a bug, developer first writes a test that generates the bug (that is the test will fail due to this bug). Then developer modifies code to make sure that the test is passed (i.e., the bug is fixed). This approach makes sure that next time the bug will not appear in the system as a test is written in the system to take care of the bug.
*Repetition of the same bug reduced: With TDD once a bug is found, it's put under test. So every time you run the whole test in the system, the tests associated with the bug are run and make sure the bugs are not generated again.

=Shortcomings Of TDD=
*The actual database or external file is never tested directly by TDD (only production code can test it)
*If not used carefully, it can add to the total project costs and complexity of the project
*TDD is unable to test UI.
*TDD is highly reliant on Refactoring and Programmer Skills.

=Conclusion=
Danielle
=References=
*[http://catalog.lib.ncsu.edu/record/NCSU1601963 Beck, K. (2002). Test-driven development by example. Addison-Wesley.]
*[http://en.wikipedia.org/wiki/Test_driven_development (n.d.). Test-driven development. website: http://en.wikipedia.org/wiki/Test_driven_development]
*[http://c2.com/cgi/wiki?TestDrivenDevelopment (2012, January 11). Test driven development. website: http://c2.com/cgi/wiki?TestDrivenDevelopment]
*[http://www.agiledata.org/essays/tdd.html Ambler, S. W. (2002). Introduction to test driven development (tdd). Retrieved from Agile Data website: http://www.agiledata.org/essays/tdd.html]
*[http://www.methodsandtools.com/archive/archive.php?id=20. Methods and Tools Archives]
*[http://www.martinfowler.com/bliki/TestDrivenDevelopment.html www.martinfowler.com/bliki/TestDrivenDevelopment]
*http://www.testdriven.com/ ?

CSC/ECE 517 Fall 2012/ch2a 2w11 aa

2012-10-23T20:18:53Z

Annice: /* References */

=Introduction=
Test driven development (TDD) is a process that tries to create the minimal amount of code to meet customer's expectations. The idea is to test first, code second, then improve (or refactor) last. This process forces the software developers to focus on customer specifications and validation first. Since at each step of the way the programmer proves to himself that the code meets specifications, TDD gives the programmer confidence. The rest of this chapter gives the motivation for TDD, shows the steps for TDD, outlines the principles of TDD, and provides examples using TDD.

=Motivation for TDD=
*Testing is the one activity that improves the quality of code. In various design scenarios, like waterfall model, testing occurs towards the end of the project development activity. As shown in the figure 1, introducing testing as a latter phase increases the cost incurred for implementing the changes. From this we infer that there is a high chance of reducing the costs by moving the Test phase to the initial part.
*The client can also be well informed about the design and can suggest changes which can be incorporated well in advance. This approach also known as TDD helps achieve flexibility to achieve the client’s ever-changing requirements
=Principles=
*Tests serve as examples of how to use a class or method. Once used to having tests that show how things work (and that they work), developers start inquiring if a test was already there for the piece of code to be developed
*Developer tests are distinctly different from QA (Quality Analysis) tests and should be kept separate. QA tests target features and treat the system as a black box. Unit tests created by the developer operate at a lower level and test different things.
*Name the tests carefully. For Example, name test packages like the package being tested with a suffix. For example, the "DataAccess" project/package is tested by "DataAccess.Test". Also, name test classes the same as the class under test with the suffix "Test". For example, the class "PrintManager" is tested by the test class "PrintManagerTest". This convention makes it easy to find the related class and keeps the class name a noun. You should also name test methods the same as the method being tested with the prefix "Test". For example, the method "PrintProductOrder()" is tested by the method "TestPrintProductOrder()". This convention keeps the method name a verb that reads as an english phrase.
*Write each test before writing the method under test. It encourages the developer to think as a user of the target method before thinking about implementation, which usually results in a cleaner, easier-to-use interface.
*Follow the "3-As" pattern for test methods: Arrange, Act, Assert. Specifically, use separate code paragraphs (groups of lines of code separated by a blank line) for each of the As. Arrange is variable declaration and initialization. Act is invoking the code under test. Assert is using the Assert.* methods to verify that expectations were met.
*When writing application code, only write enough code to make a test work. This technique prevents gold-plating and ensures that you always have a test for the code you write.
*When you find you need to refractor working code, refractor and re-test prior to writing new code. This technique ensures your refractoring is correct prior to adding new functionality and applies to creating new methods, introducing inheritance, everything.
=Steps=

Follow these steps:
*Understand the requirements of the story, work item, or feature that you are working on.
*Red:Create a test and make it fail.
Imagine how the new code should be called and write the test as if the code already existed.
Create the new production code stub. Write just enough code so that it compiles.
Run the test. It should fail. This is a calibration measure to ensure that your test is calling the correct code and that the code is not working by accident. This is a meaningful failure, and you expect it to fail.
*Green: Make the test pass by any means necessary.
Write the production code to make the test pass. Keep it simple.
Some advocate the hard-coding of the expected return value first to verify that the test correctly detects success. This varies from practitioner to practitioner.If you've written the code so that the test passes as intended, you are finished. You do not have to write more code speculatively. If new functionality is still needed, then another test is needed. Make this one test pass and continue.
When the test passes, you might want to run all tests up to this point to build confidence that everything else is still working.
*Refractor: Change the code to remove duplication in your project and to improve the design while ensuring that all tests still pass.
Remove duplication caused by the addition of the new functionality.
Make design changes to improve the overall solution.
After each refactoring, rerun all the tests to ensure that they all still pass.
*Repeat the cycle. Each cycle should be very short, and a typical hour should contain many Red/Green/ Refractor cycles.

=Examples=

==Homework Grades Program==

===Setup===
As a simple example, we are creating a program that keeps track of our homework grades. We envision that we would be able to get the average of these homework grades. Step one: write a test . Let's test an average function

<pre>
myHomework = new Homework();
myHomework.grades = [100, 50];
assert(myHomework.average(myHomework.grades) == 75);
</pre>

We will get multiple errors - this test won't even compile (but, that's ok for now). Let's take a look at what will generate error messages:

* class <code>Homework</code> not declared
* <code>Homework</code> constructor not declared
* field <code>grades</code> not declared
* method <code>average</code> not declared

Now, we fix the first error:

<pre>
class Homework {

}
</pre>

Second error:

<pre>
Homework(void) {

}
</pre>

Third error:

<pre>
int * grades;
</pre>

Fourth error:

<pre>
int average(int * grades) {
return 0; // default return value
}
</pre>

Finally, the test compiles! The code now looks like this:

<pre>
class Homework {

int * grades;

Homework(void) {

}

int average(int * grades) {

return 0; // default return value

}

}
</pre>

===Red===
Now, we run the test, and the familar red bar of failure greets us (remember the mantra red-green-refactor). The assert fails. The average function needs to actually average something (not just return 0). As we think about averaging the grades, we realize we need to know how many grades are in the int array <code>grades</code>. So, we add to the code:

<pre>
class Homework {

int * grades;
int numGrades; // new

Homework(void) {

}

int average(int * grades) {

int avg = 0; // new

for(int i = 0; i < numGrades; i++) { // new
avg += grades[i]; // new
} // new

return avg/numGrades; // new

}

}
</pre>

Of course, we must remember to change the test to:

<pre>
myHomework = new Homework();
myHomework.grades = [100, 50];
myHomework.numGrades = 2;
assert(myHomework.average(myHomework.grades) == 75);
</pre>

===Green===
Success! We have a green bar when we run it.

===Refactor===
The last step is refactoring. Perhaps we don't want a grade to be an <code>int</code>? Should it be an <code>unsigned int</code>? For this simple example, there isn't much refactoring to do, but in a larger example there may be multiple areas for improvement.

==More Examples==
See Test-Driven Development by Example by Kent Beck for more examples.

=Characteristics Of A Good Unit Test=
A good unit test has the following characteristics.
*It is important that the test executes fast. If the tests are slow, they will not be run often.
*Environmental dependencies such as databases, file systems, networks, queues, and so on which will slow down the tests are either separated or simulated. Tests that exercise these will not run fast, and a failure does not give meaningful feedback about what the problem actually is.
*The scope of testing is very limited. If the test fails, it's obvious where to look for the problem. It's important to only test one aspect in a single test.
*The test should run and pass in isolation (on any machine). If the tests require special environmental setup or fail unexpectedly, then they are not good unit tests.
*Such a test often uses stubs and mock objects. If the code being tested typically calls out to a database or file system, these dependencies must be simulated, or mocked. These dependencies will ordinarily be abstracted away by using interfaces.
*The intention of testing is clearly revealed. Another developer can look at the test and understand what is expected of the production code.

=Benefits Of TDD=
*Automated testing: Automated system makes the testing much more easier and faster. Manual testing is slower and needs human interaction which is error-prone. Automated testing makes sure any particular test is not missing every time we test the system, whereas humans may leave a test out mistakenly during testing process.
*Better to test New/Modified Functionality: With manual testing whenever you add new functionality or modify existing functionality, QA personal needs to test all systems that may be affected due to the modification which may be time-consuming. This may also leave a hidden bug in the system after modification. With TDD whenever a new functionality is added or existing functionality is modified, the whole set of tests in the system is run to make sure existing tests are passed. This makes sure that existing functionality is not broken.
*Developer’s confidence: With TDD, developers are more safe to change the system as any inappropriate changes will make some tests to fail. With non-TDD system developers needs to take more care to change existing system as the new change may fail other functionality. But with TDD developers can do so easily as after modification if developer runs the test he/she will find immediately that the change has failed some other tests (i.e. some other part of the system).
*Manual testing stage is shortened: In non-TDD development, as soon as developers prepare a build, QA personal starts testing. This manual testing takes a reasonable amount of time and increases the time to deliver the product from the build time. With TDD, a major part of the system is tested during development and needs lesser QA involvement in the time between build and final delivery of the product.
*Alternative Documentation: Unit tests are kind of documentation to system. Each unit test tells about an individual requirement to the module or system. For example, the following test ensures that only a logged in user with proper balance can buy an item when the item exists in stock. This test reflects a user aspect scenario of the system.

public void CheckUserCanNotPurchaseItemWithoutBalance(){
LoginToTheSystem();
SelectAnItemToBuy();
MakeSureItemExsitsInStock();
MakeSureUserHasBalanceToBuy();
RunTheTransaction();
}
*Better way to fix bugs: In TDD approach when QA finds a bug, developer first writes a test that generates the bug (that is the test will fail due to this bug). Then developer modifies code to make sure that the test is passed (i.e., the bug is fixed). This approach makes sure that next time the bug will not appear in the system as a test is written in the system to take care of the bug.
*Repetition of the same bug reduced: With TDD once a bug is found, it's put under test. So every time you run the whole test in the system, the tests associated with the bug are run and make sure the bugs are not generated again.

=Shortcomings Of TDD=
*The actual database or external file is never tested directly by TDD (only production code can test it)
*If not used carefully, it can add to the total project costs and complexity of the project
*TDD is unable to test UI.
*TDD is highly reliant on Refactoring and Programmer Skills.

=Conclusion=
Danielle
=References=
*[http://catalog.lib.ncsu.edu/record/NCSU1601963 Beck, K. (2002). Test-driven development by example. Addison-Wesley.]
*[http://en.wikipedia.org/wiki/Test_driven_development (n.d.). Test-driven development. website: http://en.wikipedia.org/wiki/Test_driven_development]
*[http://c2.com/cgi/wiki?TestDrivenDevelopment (2012, January 11). Test driven development. website: http://c2.com/cgi/wiki?TestDrivenDevelopment]
*[http://www.agiledata.org/essays/tdd.html Ambler, S. W. (2002). Introduction to test driven development (tdd). Retrieved from Agile Data website: http://www.agiledata.org/essays/tdd.html]
*[http://www.methodsandtools.com/archive/archive.php?id=20. Methods and Tools Archives]
*http://www.testdriven.com/ ?

CSC/ECE 517 Fall 2012/ch2a 2w11 aa

2012-10-23T20:18:37Z

Annice: /* References */

=Introduction=
Test driven development (TDD) is a process that tries to create the minimal amount of code to meet customer's expectations. The idea is to test first, code second, then improve (or refactor) last. This process forces the software developers to focus on customer specifications and validation first. Since at each step of the way the programmer proves to himself that the code meets specifications, TDD gives the programmer confidence. The rest of this chapter gives the motivation for TDD, shows the steps for TDD, outlines the principles of TDD, and provides examples using TDD.

=Motivation for TDD=
*Testing is the one activity that improves the quality of code. In various design scenarios, like waterfall model, testing occurs towards the end of the project development activity. As shown in the figure 1, introducing testing as a latter phase increases the cost incurred for implementing the changes. From this we infer that there is a high chance of reducing the costs by moving the Test phase to the initial part.
*The client can also be well informed about the design and can suggest changes which can be incorporated well in advance. This approach also known as TDD helps achieve flexibility to achieve the client’s ever-changing requirements
=Principles=
*Tests serve as examples of how to use a class or method. Once used to having tests that show how things work (and that they work), developers start inquiring if a test was already there for the piece of code to be developed
*Developer tests are distinctly different from QA (Quality Analysis) tests and should be kept separate. QA tests target features and treat the system as a black box. Unit tests created by the developer operate at a lower level and test different things.
*Name the tests carefully. For Example, name test packages like the package being tested with a suffix. For example, the "DataAccess" project/package is tested by "DataAccess.Test". Also, name test classes the same as the class under test with the suffix "Test". For example, the class "PrintManager" is tested by the test class "PrintManagerTest". This convention makes it easy to find the related class and keeps the class name a noun. You should also name test methods the same as the method being tested with the prefix "Test". For example, the method "PrintProductOrder()" is tested by the method "TestPrintProductOrder()". This convention keeps the method name a verb that reads as an english phrase.
*Write each test before writing the method under test. It encourages the developer to think as a user of the target method before thinking about implementation, which usually results in a cleaner, easier-to-use interface.
*Follow the "3-As" pattern for test methods: Arrange, Act, Assert. Specifically, use separate code paragraphs (groups of lines of code separated by a blank line) for each of the As. Arrange is variable declaration and initialization. Act is invoking the code under test. Assert is using the Assert.* methods to verify that expectations were met.
*When writing application code, only write enough code to make a test work. This technique prevents gold-plating and ensures that you always have a test for the code you write.
*When you find you need to refractor working code, refractor and re-test prior to writing new code. This technique ensures your refractoring is correct prior to adding new functionality and applies to creating new methods, introducing inheritance, everything.
=Steps=

Follow these steps:
*Understand the requirements of the story, work item, or feature that you are working on.
*Red:Create a test and make it fail.
Imagine how the new code should be called and write the test as if the code already existed.
Create the new production code stub. Write just enough code so that it compiles.
Run the test. It should fail. This is a calibration measure to ensure that your test is calling the correct code and that the code is not working by accident. This is a meaningful failure, and you expect it to fail.
*Green: Make the test pass by any means necessary.
Write the production code to make the test pass. Keep it simple.
Some advocate the hard-coding of the expected return value first to verify that the test correctly detects success. This varies from practitioner to practitioner.If you've written the code so that the test passes as intended, you are finished. You do not have to write more code speculatively. If new functionality is still needed, then another test is needed. Make this one test pass and continue.
When the test passes, you might want to run all tests up to this point to build confidence that everything else is still working.
*Refractor: Change the code to remove duplication in your project and to improve the design while ensuring that all tests still pass.
Remove duplication caused by the addition of the new functionality.
Make design changes to improve the overall solution.
After each refactoring, rerun all the tests to ensure that they all still pass.
*Repeat the cycle. Each cycle should be very short, and a typical hour should contain many Red/Green/ Refractor cycles.

=Examples=

==Homework Grades Program==

===Setup===
As a simple example, we are creating a program that keeps track of our homework grades. We envision that we would be able to get the average of these homework grades. Step one: write a test . Let's test an average function

<pre>
myHomework = new Homework();
myHomework.grades = [100, 50];
assert(myHomework.average(myHomework.grades) == 75);
</pre>

We will get multiple errors - this test won't even compile (but, that's ok for now). Let's take a look at what will generate error messages:

* class <code>Homework</code> not declared
* <code>Homework</code> constructor not declared
* field <code>grades</code> not declared
* method <code>average</code> not declared

Now, we fix the first error:

<pre>
class Homework {

}
</pre>

Second error:

<pre>
Homework(void) {

}
</pre>

Third error:

<pre>
int * grades;
</pre>

Fourth error:

<pre>
int average(int * grades) {
return 0; // default return value
}
</pre>

Finally, the test compiles! The code now looks like this:

<pre>
class Homework {

int * grades;

Homework(void) {

}

int average(int * grades) {

return 0; // default return value

}

}
</pre>

===Red===
Now, we run the test, and the familar red bar of failure greets us (remember the mantra red-green-refactor). The assert fails. The average function needs to actually average something (not just return 0). As we think about averaging the grades, we realize we need to know how many grades are in the int array <code>grades</code>. So, we add to the code:

<pre>
class Homework {

int * grades;
int numGrades; // new

Homework(void) {

}

int average(int * grades) {

int avg = 0; // new

for(int i = 0; i < numGrades; i++) { // new
avg += grades[i]; // new
} // new

return avg/numGrades; // new

}

}
</pre>

Of course, we must remember to change the test to:

<pre>
myHomework = new Homework();
myHomework.grades = [100, 50];
myHomework.numGrades = 2;
assert(myHomework.average(myHomework.grades) == 75);
</pre>

===Green===
Success! We have a green bar when we run it.

===Refactor===
The last step is refactoring. Perhaps we don't want a grade to be an <code>int</code>? Should it be an <code>unsigned int</code>? For this simple example, there isn't much refactoring to do, but in a larger example there may be multiple areas for improvement.

==More Examples==
See Test-Driven Development by Example by Kent Beck for more examples.

=Characteristics Of A Good Unit Test=
A good unit test has the following characteristics.
*It is important that the test executes fast. If the tests are slow, they will not be run often.
*Environmental dependencies such as databases, file systems, networks, queues, and so on which will slow down the tests are either separated or simulated. Tests that exercise these will not run fast, and a failure does not give meaningful feedback about what the problem actually is.
*The scope of testing is very limited. If the test fails, it's obvious where to look for the problem. It's important to only test one aspect in a single test.
*The test should run and pass in isolation (on any machine). If the tests require special environmental setup or fail unexpectedly, then they are not good unit tests.
*Such a test often uses stubs and mock objects. If the code being tested typically calls out to a database or file system, these dependencies must be simulated, or mocked. These dependencies will ordinarily be abstracted away by using interfaces.
*The intention of testing is clearly revealed. Another developer can look at the test and understand what is expected of the production code.

=Benefits Of TDD=
*Automated testing: Automated system makes the testing much more easier and faster. Manual testing is slower and needs human interaction which is error-prone. Automated testing makes sure any particular test is not missing every time we test the system, whereas humans may leave a test out mistakenly during testing process.
*Better to test New/Modified Functionality: With manual testing whenever you add new functionality or modify existing functionality, QA personal needs to test all systems that may be affected due to the modification which may be time-consuming. This may also leave a hidden bug in the system after modification. With TDD whenever a new functionality is added or existing functionality is modified, the whole set of tests in the system is run to make sure existing tests are passed. This makes sure that existing functionality is not broken.
*Developer’s confidence: With TDD, developers are more safe to change the system as any inappropriate changes will make some tests to fail. With non-TDD system developers needs to take more care to change existing system as the new change may fail other functionality. But with TDD developers can do so easily as after modification if developer runs the test he/she will find immediately that the change has failed some other tests (i.e. some other part of the system).
*Manual testing stage is shortened: In non-TDD development, as soon as developers prepare a build, QA personal starts testing. This manual testing takes a reasonable amount of time and increases the time to deliver the product from the build time. With TDD, a major part of the system is tested during development and needs lesser QA involvement in the time between build and final delivery of the product.
*Alternative Documentation: Unit tests are kind of documentation to system. Each unit test tells about an individual requirement to the module or system. For example, the following test ensures that only a logged in user with proper balance can buy an item when the item exists in stock. This test reflects a user aspect scenario of the system.

public void CheckUserCanNotPurchaseItemWithoutBalance(){
LoginToTheSystem();
SelectAnItemToBuy();
MakeSureItemExsitsInStock();
MakeSureUserHasBalanceToBuy();
RunTheTransaction();
}
*Better way to fix bugs: In TDD approach when QA finds a bug, developer first writes a test that generates the bug (that is the test will fail due to this bug). Then developer modifies code to make sure that the test is passed (i.e., the bug is fixed). This approach makes sure that next time the bug will not appear in the system as a test is written in the system to take care of the bug.
*Repetition of the same bug reduced: With TDD once a bug is found, it's put under test. So every time you run the whole test in the system, the tests associated with the bug are run and make sure the bugs are not generated again.

=Shortcomings Of TDD=
*The actual database or external file is never tested directly by TDD (only production code can test it)
*If not used carefully, it can add to the total project costs and complexity of the project
*TDD is unable to test UI.
*TDD is highly reliant on Refactoring and Programmer Skills.

=Conclusion=
Danielle
=References=
*[http://catalog.lib.ncsu.edu/record/NCSU1601963 Beck, K. (2002). Test-driven development by example. Addison-Wesley.]
*[http://en.wikipedia.org/wiki/Test_driven_development (n.d.). Test-driven development. website: http://en.wikipedia.org/wiki/Test_driven_development]
*[http://c2.com/cgi/wiki?TestDrivenDevelopment (2012, January 11). Test driven development. website: http://c2.com/cgi/wiki?TestDrivenDevelopment]
*[http://www.agiledata.org/essays/tdd.html Ambler, S. W. (2002). Introduction to test driven development (tdd). Retrieved from Agile Data website: http://www.agiledata.org/essays/tdd.html]
*[www.methodsandtools.com/archive/archive.php?id=20. Methods and Tools Archives]
*http://www.testdriven.com/ ?

CSC/ECE 517 Fall 2012/ch2a 2w11 aa

2012-10-23T20:16:22Z

Annice: /* References */

=Introduction=
Test driven development (TDD) is a process that tries to create the minimal amount of code to meet customer's expectations. The idea is to test first, code second, then improve (or refactor) last. This process forces the software developers to focus on customer specifications and validation first. Since at each step of the way the programmer proves to himself that the code meets specifications, TDD gives the programmer confidence. The rest of this chapter gives the motivation for TDD, shows the steps for TDD, outlines the principles of TDD, and provides examples using TDD.

=Motivation for TDD=
*Testing is the one activity that improves the quality of code. In various design scenarios, like waterfall model, testing occurs towards the end of the project development activity. As shown in the figure 1, introducing testing as a latter phase increases the cost incurred for implementing the changes. From this we infer that there is a high chance of reducing the costs by moving the Test phase to the initial part.
*The client can also be well informed about the design and can suggest changes which can be incorporated well in advance. This approach also known as TDD helps achieve flexibility to achieve the client’s ever-changing requirements
=Principles=
*Tests serve as examples of how to use a class or method. Once used to having tests that show how things work (and that they work), developers start inquiring if a test was already there for the piece of code to be developed
*Developer tests are distinctly different from QA (Quality Analysis) tests and should be kept separate. QA tests target features and treat the system as a black box. Unit tests created by the developer operate at a lower level and test different things.
*Name the tests carefully. For Example, name test packages like the package being tested with a suffix. For example, the "DataAccess" project/package is tested by "DataAccess.Test". Also, name test classes the same as the class under test with the suffix "Test". For example, the class "PrintManager" is tested by the test class "PrintManagerTest". This convention makes it easy to find the related class and keeps the class name a noun. You should also name test methods the same as the method being tested with the prefix "Test". For example, the method "PrintProductOrder()" is tested by the method "TestPrintProductOrder()". This convention keeps the method name a verb that reads as an english phrase.
*Write each test before writing the method under test. It encourages the developer to think as a user of the target method before thinking about implementation, which usually results in a cleaner, easier-to-use interface.
*Follow the "3-As" pattern for test methods: Arrange, Act, Assert. Specifically, use separate code paragraphs (groups of lines of code separated by a blank line) for each of the As. Arrange is variable declaration and initialization. Act is invoking the code under test. Assert is using the Assert.* methods to verify that expectations were met.
*When writing application code, only write enough code to make a test work. This technique prevents gold-plating and ensures that you always have a test for the code you write.
*When you find you need to refractor working code, refractor and re-test prior to writing new code. This technique ensures your refractoring is correct prior to adding new functionality and applies to creating new methods, introducing inheritance, everything.
=Steps=

Follow these steps:
*Understand the requirements of the story, work item, or feature that you are working on.
*Red:Create a test and make it fail.
Imagine how the new code should be called and write the test as if the code already existed.
Create the new production code stub. Write just enough code so that it compiles.
Run the test. It should fail. This is a calibration measure to ensure that your test is calling the correct code and that the code is not working by accident. This is a meaningful failure, and you expect it to fail.
*Green: Make the test pass by any means necessary.
Write the production code to make the test pass. Keep it simple.
Some advocate the hard-coding of the expected return value first to verify that the test correctly detects success. This varies from practitioner to practitioner.If you've written the code so that the test passes as intended, you are finished. You do not have to write more code speculatively. If new functionality is still needed, then another test is needed. Make this one test pass and continue.
When the test passes, you might want to run all tests up to this point to build confidence that everything else is still working.
*Refractor: Change the code to remove duplication in your project and to improve the design while ensuring that all tests still pass.
Remove duplication caused by the addition of the new functionality.
Make design changes to improve the overall solution.
After each refactoring, rerun all the tests to ensure that they all still pass.
*Repeat the cycle. Each cycle should be very short, and a typical hour should contain many Red/Green/ Refractor cycles.

=Examples=

==Homework Grades Program==

===Setup===
As a simple example, we are creating a program that keeps track of our homework grades. We envision that we would be able to get the average of these homework grades. Step one: write a test . Let's test an average function

<pre>
myHomework = new Homework();
myHomework.grades = [100, 50];
assert(myHomework.average(myHomework.grades) == 75);
</pre>

We will get multiple errors - this test won't even compile (but, that's ok for now). Let's take a look at what will generate error messages:

* class <code>Homework</code> not declared
* <code>Homework</code> constructor not declared
* field <code>grades</code> not declared
* method <code>average</code> not declared

Now, we fix the first error:

<pre>
class Homework {

}
</pre>

Second error:

<pre>
Homework(void) {

}
</pre>

Third error:

<pre>
int * grades;
</pre>

Fourth error:

<pre>
int average(int * grades) {
return 0; // default return value
}
</pre>

Finally, the test compiles! The code now looks like this:

<pre>
class Homework {

int * grades;

Homework(void) {

}

int average(int * grades) {

return 0; // default return value

}

}
</pre>

===Red===
Now, we run the test, and the familar red bar of failure greets us (remember the mantra red-green-refactor). The assert fails. The average function needs to actually average something (not just return 0). As we think about averaging the grades, we realize we need to know how many grades are in the int array <code>grades</code>. So, we add to the code:

<pre>
class Homework {

int * grades;
int numGrades; // new

Homework(void) {

}

int average(int * grades) {

int avg = 0; // new

for(int i = 0; i < numGrades; i++) { // new
avg += grades[i]; // new
} // new

return avg/numGrades; // new

}

}
</pre>

Of course, we must remember to change the test to:

<pre>
myHomework = new Homework();
myHomework.grades = [100, 50];
myHomework.numGrades = 2;
assert(myHomework.average(myHomework.grades) == 75);
</pre>

===Green===
Success! We have a green bar when we run it.

===Refactor===
The last step is refactoring. Perhaps we don't want a grade to be an <code>int</code>? Should it be an <code>unsigned int</code>? For this simple example, there isn't much refactoring to do, but in a larger example there may be multiple areas for improvement.

==More Examples==
See Test-Driven Development by Example by Kent Beck for more examples.

=Characteristics Of A Good Unit Test=
A good unit test has the following characteristics.
*It is important that the test executes fast. If the tests are slow, they will not be run often.
*Environmental dependencies such as databases, file systems, networks, queues, and so on which will slow down the tests are either separated or simulated. Tests that exercise these will not run fast, and a failure does not give meaningful feedback about what the problem actually is.
*The scope of testing is very limited. If the test fails, it's obvious where to look for the problem. It's important to only test one aspect in a single test.
*The test should run and pass in isolation (on any machine). If the tests require special environmental setup or fail unexpectedly, then they are not good unit tests.
*Such a test often uses stubs and mock objects. If the code being tested typically calls out to a database or file system, these dependencies must be simulated, or mocked. These dependencies will ordinarily be abstracted away by using interfaces.
*The intention of testing is clearly revealed. Another developer can look at the test and understand what is expected of the production code.

=Benefits Of TDD=
*Automated testing: Automated system makes the testing much more easier and faster. Manual testing is slower and needs human interaction which is error-prone. Automated testing makes sure any particular test is not missing every time we test the system, whereas humans may leave a test out mistakenly during testing process.
*Better to test New/Modified Functionality: With manual testing whenever you add new functionality or modify existing functionality, QA personal needs to test all systems that may be affected due to the modification which may be time-consuming. This may also leave a hidden bug in the system after modification. With TDD whenever a new functionality is added or existing functionality is modified, the whole set of tests in the system is run to make sure existing tests are passed. This makes sure that existing functionality is not broken.
*Developer’s confidence: With TDD, developers are more safe to change the system as any inappropriate changes will make some tests to fail. With non-TDD system developers needs to take more care to change existing system as the new change may fail other functionality. But with TDD developers can do so easily as after modification if developer runs the test he/she will find immediately that the change has failed some other tests (i.e. some other part of the system).
*Manual testing stage is shortened: In non-TDD development, as soon as developers prepare a build, QA personal starts testing. This manual testing takes a reasonable amount of time and increases the time to deliver the product from the build time. With TDD, a major part of the system is tested during development and needs lesser QA involvement in the time between build and final delivery of the product.
*Alternative Documentation: Unit tests are kind of documentation to system. Each unit test tells about an individual requirement to the module or system. For example, the following test ensures that only a logged in user with proper balance can buy an item when the item exists in stock. This test reflects a user aspect scenario of the system.

public void CheckUserCanNotPurchaseItemWithoutBalance(){
LoginToTheSystem();
SelectAnItemToBuy();
MakeSureItemExsitsInStock();
MakeSureUserHasBalanceToBuy();
RunTheTransaction();
}
*Better way to fix bugs: In TDD approach when QA finds a bug, developer first writes a test that generates the bug (that is the test will fail due to this bug). Then developer modifies code to make sure that the test is passed (i.e., the bug is fixed). This approach makes sure that next time the bug will not appear in the system as a test is written in the system to take care of the bug.
*Repetition of the same bug reduced: With TDD once a bug is found, it's put under test. So every time you run the whole test in the system, the tests associated with the bug are run and make sure the bugs are not generated again.

=Shortcomings Of TDD=
*The actual database or external file is never tested directly by TDD (only production code can test it)
*If not used carefully, it can add to the total project costs and complexity of the project
*TDD is unable to test UI.
*TDD is highly reliant on Refactoring and Programmer Skills.

=Conclusion=
Danielle
=References=
*[http://catalog.lib.ncsu.edu/record/NCSU1601963 Beck, K. (2002). Test-driven development by example. Addison-Wesley.]
*[http://en.wikipedia.org/wiki/Test_driven_development (n.d.). Test-driven development. website: http://en.wikipedia.org/wiki/Test_driven_development]
*[http://c2.com/cgi/wiki?TestDrivenDevelopment (2012, January 11). Test driven development. website: http://c2.com/cgi/wiki?TestDrivenDevelopment]
*[http://www.agiledata.org/essays/tdd.html Ambler, S. W. (2002). Introduction to test driven development (tdd). Retrieved from Agile Data website: http://www.agiledata.org/essays/tdd.html]
*[http://www.methodsandtools.com/archive/archive.php?id=20. Methods and Tools Archives]
*http://www.testdriven.com/ ?

CSC/ECE 517 Fall 2012/ch2a 2w11 aa

2012-10-23T20:15:28Z

Annice: /* References */

=Introduction=
Test driven development (TDD) is a process that tries to create the minimal amount of code to meet customer's expectations. The idea is to test first, code second, then improve (or refactor) last. This process forces the software developers to focus on customer specifications and validation first. Since at each step of the way the programmer proves to himself that the code meets specifications, TDD gives the programmer confidence. The rest of this chapter gives the motivation for TDD, shows the steps for TDD, outlines the principles of TDD, and provides examples using TDD.

=Motivation for TDD=
*Testing is the one activity that improves the quality of code. In various design scenarios, like waterfall model, testing occurs towards the end of the project development activity. As shown in the figure 1, introducing testing as a latter phase increases the cost incurred for implementing the changes. From this we infer that there is a high chance of reducing the costs by moving the Test phase to the initial part.
*The client can also be well informed about the design and can suggest changes which can be incorporated well in advance. This approach also known as TDD helps achieve flexibility to achieve the client’s ever-changing requirements
=Principles=
*Tests serve as examples of how to use a class or method. Once used to having tests that show how things work (and that they work), developers start inquiring if a test was already there for the piece of code to be developed
*Developer tests are distinctly different from QA (Quality Analysis) tests and should be kept separate. QA tests target features and treat the system as a black box. Unit tests created by the developer operate at a lower level and test different things.
*Name the tests carefully. For Example, name test packages like the package being tested with a suffix. For example, the "DataAccess" project/package is tested by "DataAccess.Test". Also, name test classes the same as the class under test with the suffix "Test". For example, the class "PrintManager" is tested by the test class "PrintManagerTest". This convention makes it easy to find the related class and keeps the class name a noun. You should also name test methods the same as the method being tested with the prefix "Test". For example, the method "PrintProductOrder()" is tested by the method "TestPrintProductOrder()". This convention keeps the method name a verb that reads as an english phrase.
*Write each test before writing the method under test. It encourages the developer to think as a user of the target method before thinking about implementation, which usually results in a cleaner, easier-to-use interface.
*Follow the "3-As" pattern for test methods: Arrange, Act, Assert. Specifically, use separate code paragraphs (groups of lines of code separated by a blank line) for each of the As. Arrange is variable declaration and initialization. Act is invoking the code under test. Assert is using the Assert.* methods to verify that expectations were met.
*When writing application code, only write enough code to make a test work. This technique prevents gold-plating and ensures that you always have a test for the code you write.
*When you find you need to refractor working code, refractor and re-test prior to writing new code. This technique ensures your refractoring is correct prior to adding new functionality and applies to creating new methods, introducing inheritance, everything.
=Steps=

Follow these steps:
*Understand the requirements of the story, work item, or feature that you are working on.
*Red:Create a test and make it fail.
Imagine how the new code should be called and write the test as if the code already existed.
Create the new production code stub. Write just enough code so that it compiles.
Run the test. It should fail. This is a calibration measure to ensure that your test is calling the correct code and that the code is not working by accident. This is a meaningful failure, and you expect it to fail.
*Green: Make the test pass by any means necessary.
Write the production code to make the test pass. Keep it simple.
Some advocate the hard-coding of the expected return value first to verify that the test correctly detects success. This varies from practitioner to practitioner.If you've written the code so that the test passes as intended, you are finished. You do not have to write more code speculatively. If new functionality is still needed, then another test is needed. Make this one test pass and continue.
When the test passes, you might want to run all tests up to this point to build confidence that everything else is still working.
*Refractor: Change the code to remove duplication in your project and to improve the design while ensuring that all tests still pass.
Remove duplication caused by the addition of the new functionality.
Make design changes to improve the overall solution.
After each refactoring, rerun all the tests to ensure that they all still pass.
*Repeat the cycle. Each cycle should be very short, and a typical hour should contain many Red/Green/ Refractor cycles.

=Examples=

==Homework Grades Program==

===Setup===
As a simple example, we are creating a program that keeps track of our homework grades. We envision that we would be able to get the average of these homework grades. Step one: write a test . Let's test an average function

<pre>
myHomework = new Homework();
myHomework.grades = [100, 50];
assert(myHomework.average(myHomework.grades) == 75);
</pre>

We will get multiple errors - this test won't even compile (but, that's ok for now). Let's take a look at what will generate error messages:

* class <code>Homework</code> not declared
* <code>Homework</code> constructor not declared
* field <code>grades</code> not declared
* method <code>average</code> not declared

Now, we fix the first error:

<pre>
class Homework {

}
</pre>

Second error:

<pre>
Homework(void) {

}
</pre>

Third error:

<pre>
int * grades;
</pre>

Fourth error:

<pre>
int average(int * grades) {
return 0; // default return value
}
</pre>

Finally, the test compiles! The code now looks like this:

<pre>
class Homework {

int * grades;

Homework(void) {

}

int average(int * grades) {

return 0; // default return value

}

}
</pre>

===Red===
Now, we run the test, and the familar red bar of failure greets us (remember the mantra red-green-refactor). The assert fails. The average function needs to actually average something (not just return 0). As we think about averaging the grades, we realize we need to know how many grades are in the int array <code>grades</code>. So, we add to the code:

<pre>
class Homework {

int * grades;
int numGrades; // new

Homework(void) {

}

int average(int * grades) {

int avg = 0; // new

for(int i = 0; i < numGrades; i++) { // new
avg += grades[i]; // new
} // new

return avg/numGrades; // new

}

}
</pre>

Of course, we must remember to change the test to:

<pre>
myHomework = new Homework();
myHomework.grades = [100, 50];
myHomework.numGrades = 2;
assert(myHomework.average(myHomework.grades) == 75);
</pre>

===Green===
Success! We have a green bar when we run it.

===Refactor===
The last step is refactoring. Perhaps we don't want a grade to be an <code>int</code>? Should it be an <code>unsigned int</code>? For this simple example, there isn't much refactoring to do, but in a larger example there may be multiple areas for improvement.

==More Examples==
See Test-Driven Development by Example by Kent Beck for more examples.

=Characteristics Of A Good Unit Test=
A good unit test has the following characteristics.
*It is important that the test executes fast. If the tests are slow, they will not be run often.
*Environmental dependencies such as databases, file systems, networks, queues, and so on which will slow down the tests are either separated or simulated. Tests that exercise these will not run fast, and a failure does not give meaningful feedback about what the problem actually is.
*The scope of testing is very limited. If the test fails, it's obvious where to look for the problem. It's important to only test one aspect in a single test.
*The test should run and pass in isolation (on any machine). If the tests require special environmental setup or fail unexpectedly, then they are not good unit tests.
*Such a test often uses stubs and mock objects. If the code being tested typically calls out to a database or file system, these dependencies must be simulated, or mocked. These dependencies will ordinarily be abstracted away by using interfaces.
*The intention of testing is clearly revealed. Another developer can look at the test and understand what is expected of the production code.

=Benefits Of TDD=
*Automated testing: Automated system makes the testing much more easier and faster. Manual testing is slower and needs human interaction which is error-prone. Automated testing makes sure any particular test is not missing every time we test the system, whereas humans may leave a test out mistakenly during testing process.
*Better to test New/Modified Functionality: With manual testing whenever you add new functionality or modify existing functionality, QA personal needs to test all systems that may be affected due to the modification which may be time-consuming. This may also leave a hidden bug in the system after modification. With TDD whenever a new functionality is added or existing functionality is modified, the whole set of tests in the system is run to make sure existing tests are passed. This makes sure that existing functionality is not broken.
*Developer’s confidence: With TDD, developers are more safe to change the system as any inappropriate changes will make some tests to fail. With non-TDD system developers needs to take more care to change existing system as the new change may fail other functionality. But with TDD developers can do so easily as after modification if developer runs the test he/she will find immediately that the change has failed some other tests (i.e. some other part of the system).
*Manual testing stage is shortened: In non-TDD development, as soon as developers prepare a build, QA personal starts testing. This manual testing takes a reasonable amount of time and increases the time to deliver the product from the build time. With TDD, a major part of the system is tested during development and needs lesser QA involvement in the time between build and final delivery of the product.
*Alternative Documentation: Unit tests are kind of documentation to system. Each unit test tells about an individual requirement to the module or system. For example, the following test ensures that only a logged in user with proper balance can buy an item when the item exists in stock. This test reflects a user aspect scenario of the system.

public void CheckUserCanNotPurchaseItemWithoutBalance(){
LoginToTheSystem();
SelectAnItemToBuy();
MakeSureItemExsitsInStock();
MakeSureUserHasBalanceToBuy();
RunTheTransaction();
}
*Better way to fix bugs: In TDD approach when QA finds a bug, developer first writes a test that generates the bug (that is the test will fail due to this bug). Then developer modifies code to make sure that the test is passed (i.e., the bug is fixed). This approach makes sure that next time the bug will not appear in the system as a test is written in the system to take care of the bug.
*Repetition of the same bug reduced: With TDD once a bug is found, it's put under test. So every time you run the whole test in the system, the tests associated with the bug are run and make sure the bugs are not generated again.

=Shortcomings Of TDD=
*The actual database or external file is never tested directly by TDD (only production code can test it)
*If not used carefully, it can add to the total project costs and complexity of the project
*TDD is unable to test UI.
*TDD is highly reliant on Refactoring and Programmer Skills.

=Conclusion=
Danielle
=References=
*[http://catalog.lib.ncsu.edu/record/NCSU1601963 Beck, K. (2002). Test-driven development by example. Addison-Wesley.]
*[http://en.wikipedia.org/wiki/Test_driven_development (n.d.). Test-driven development. website: http://en.wikipedia.org/wiki/Test_driven_development]
*[http://c2.com/cgi/wiki?TestDrivenDevelopment (2012, January 11). Test driven development. website: http://c2.com/cgi/wiki?TestDrivenDevelopment]
*[http://www.agiledata.org/essays/tdd.html Ambler, S. W. (2002). Introduction to test driven development (tdd). Retrieved from Agile Data website: http://www.agiledata.org/essays/tdd.html]
*[www.methodsandtools.com/archive/archive.php?id=20 Methods and Tools Archives]
*http://www.testdriven.com/ ?

CSC/ECE 517 Fall 2012/ch2a 2w11 aa

2012-10-23T20:13:46Z

Annice: /* Benefits of TDD */

=Introduction=
Test driven development (TDD) is a process that tries to create the minimal amount of code to meet customer's expectations. The idea is to test first, code second, then improve (or refactor) last. This process forces the software developers to focus on customer specifications and validation first. Since at each step of the way the programmer proves to himself that the code meets specifications, TDD gives the programmer confidence. The rest of this chapter gives the motivation for TDD, shows the steps for TDD, outlines the principles of TDD, and provides examples using TDD.

=Motivation for TDD=
*Testing is the one activity that improves the quality of code. In various design scenarios, like waterfall model, testing occurs towards the end of the project development activity. As shown in the figure 1, introducing testing as a latter phase increases the cost incurred for implementing the changes. From this we infer that there is a high chance of reducing the costs by moving the Test phase to the initial part.
*The client can also be well informed about the design and can suggest changes which can be incorporated well in advance. This approach also known as TDD helps achieve flexibility to achieve the client’s ever-changing requirements
=Principles=
*Tests serve as examples of how to use a class or method. Once used to having tests that show how things work (and that they work), developers start inquiring if a test was already there for the piece of code to be developed
*Developer tests are distinctly different from QA (Quality Analysis) tests and should be kept separate. QA tests target features and treat the system as a black box. Unit tests created by the developer operate at a lower level and test different things.
*Name the tests carefully. For Example, name test packages like the package being tested with a suffix. For example, the "DataAccess" project/package is tested by "DataAccess.Test". Also, name test classes the same as the class under test with the suffix "Test". For example, the class "PrintManager" is tested by the test class "PrintManagerTest". This convention makes it easy to find the related class and keeps the class name a noun. You should also name test methods the same as the method being tested with the prefix "Test". For example, the method "PrintProductOrder()" is tested by the method "TestPrintProductOrder()". This convention keeps the method name a verb that reads as an english phrase.
*Write each test before writing the method under test. It encourages the developer to think as a user of the target method before thinking about implementation, which usually results in a cleaner, easier-to-use interface.
*Follow the "3-As" pattern for test methods: Arrange, Act, Assert. Specifically, use separate code paragraphs (groups of lines of code separated by a blank line) for each of the As. Arrange is variable declaration and initialization. Act is invoking the code under test. Assert is using the Assert.* methods to verify that expectations were met.
*When writing application code, only write enough code to make a test work. This technique prevents gold-plating and ensures that you always have a test for the code you write.
*When you find you need to refractor working code, refractor and re-test prior to writing new code. This technique ensures your refractoring is correct prior to adding new functionality and applies to creating new methods, introducing inheritance, everything.
=Steps=

Follow these steps:
*Understand the requirements of the story, work item, or feature that you are working on.
*Red:Create a test and make it fail.
Imagine how the new code should be called and write the test as if the code already existed.
Create the new production code stub. Write just enough code so that it compiles.
Run the test. It should fail. This is a calibration measure to ensure that your test is calling the correct code and that the code is not working by accident. This is a meaningful failure, and you expect it to fail.
*Green: Make the test pass by any means necessary.
Write the production code to make the test pass. Keep it simple.
Some advocate the hard-coding of the expected return value first to verify that the test correctly detects success. This varies from practitioner to practitioner.If you've written the code so that the test passes as intended, you are finished. You do not have to write more code speculatively. If new functionality is still needed, then another test is needed. Make this one test pass and continue.
When the test passes, you might want to run all tests up to this point to build confidence that everything else is still working.
*Refractor: Change the code to remove duplication in your project and to improve the design while ensuring that all tests still pass.
Remove duplication caused by the addition of the new functionality.
Make design changes to improve the overall solution.
After each refactoring, rerun all the tests to ensure that they all still pass.
*Repeat the cycle. Each cycle should be very short, and a typical hour should contain many Red/Green/ Refractor cycles.

=Examples=

==Homework Grades Program==

===Setup===
As a simple example, we are creating a program that keeps track of our homework grades. We envision that we would be able to get the average of these homework grades. Step one: write a test . Let's test an average function

<pre>
myHomework = new Homework();
myHomework.grades = [100, 50];
assert(myHomework.average(myHomework.grades) == 75);
</pre>

We will get multiple errors - this test won't even compile (but, that's ok for now). Let's take a look at what will generate error messages:

* class <code>Homework</code> not declared
* <code>Homework</code> constructor not declared
* field <code>grades</code> not declared
* method <code>average</code> not declared

Now, we fix the first error:

<pre>
class Homework {

}
</pre>

Second error:

<pre>
Homework(void) {

}
</pre>

Third error:

<pre>
int * grades;
</pre>

Fourth error:

<pre>
int average(int * grades) {
return 0; // default return value
}
</pre>

Finally, the test compiles! The code now looks like this:

<pre>
class Homework {

int * grades;

Homework(void) {

}

int average(int * grades) {

return 0; // default return value

}

}
</pre>

===Red===
Now, we run the test, and the familar red bar of failure greets us (remember the mantra red-green-refactor). The assert fails. The average function needs to actually average something (not just return 0). As we think about averaging the grades, we realize we need to know how many grades are in the int array <code>grades</code>. So, we add to the code:

<pre>
class Homework {

int * grades;
int numGrades; // new

Homework(void) {

}

int average(int * grades) {

int avg = 0; // new

for(int i = 0; i < numGrades; i++) { // new
avg += grades[i]; // new
} // new

return avg/numGrades; // new

}

}
</pre>

Of course, we must remember to change the test to:

<pre>
myHomework = new Homework();
myHomework.grades = [100, 50];
myHomework.numGrades = 2;
assert(myHomework.average(myHomework.grades) == 75);
</pre>

===Green===
Success! We have a green bar when we run it.

===Refactor===
The last step is refactoring. Perhaps we don't want a grade to be an <code>int</code>? Should it be an <code>unsigned int</code>? For this simple example, there isn't much refactoring to do, but in a larger example there may be multiple areas for improvement.

==More Examples==
See Test-Driven Development by Example by Kent Beck for more examples.

=Characteristics Of A Good Unit Test=
A good unit test has the following characteristics.
*It is important that the test executes fast. If the tests are slow, they will not be run often.
*Environmental dependencies such as databases, file systems, networks, queues, and so on which will slow down the tests are either separated or simulated. Tests that exercise these will not run fast, and a failure does not give meaningful feedback about what the problem actually is.
*The scope of testing is very limited. If the test fails, it's obvious where to look for the problem. It's important to only test one aspect in a single test.
*The test should run and pass in isolation (on any machine). If the tests require special environmental setup or fail unexpectedly, then they are not good unit tests.
*Such a test often uses stubs and mock objects. If the code being tested typically calls out to a database or file system, these dependencies must be simulated, or mocked. These dependencies will ordinarily be abstracted away by using interfaces.
*The intention of testing is clearly revealed. Another developer can look at the test and understand what is expected of the production code.

=Benefits Of TDD=
*Automated testing: Automated system makes the testing much more easier and faster. Manual testing is slower and needs human interaction which is error-prone. Automated testing makes sure any particular test is not missing every time we test the system, whereas humans may leave a test out mistakenly during testing process.
*Better to test New/Modified Functionality: With manual testing whenever you add new functionality or modify existing functionality, QA personal needs to test all systems that may be affected due to the modification which may be time-consuming. This may also leave a hidden bug in the system after modification. With TDD whenever a new functionality is added or existing functionality is modified, the whole set of tests in the system is run to make sure existing tests are passed. This makes sure that existing functionality is not broken.
*Developer’s confidence: With TDD, developers are more safe to change the system as any inappropriate changes will make some tests to fail. With non-TDD system developers needs to take more care to change existing system as the new change may fail other functionality. But with TDD developers can do so easily as after modification if developer runs the test he/she will find immediately that the change has failed some other tests (i.e. some other part of the system).
*Manual testing stage is shortened: In non-TDD development, as soon as developers prepare a build, QA personal starts testing. This manual testing takes a reasonable amount of time and increases the time to deliver the product from the build time. With TDD, a major part of the system is tested during development and needs lesser QA involvement in the time between build and final delivery of the product.
*Alternative Documentation: Unit tests are kind of documentation to system. Each unit test tells about an individual requirement to the module or system. For example, the following test ensures that only a logged in user with proper balance can buy an item when the item exists in stock. This test reflects a user aspect scenario of the system.

public void CheckUserCanNotPurchaseItemWithoutBalance(){
LoginToTheSystem();
SelectAnItemToBuy();
MakeSureItemExsitsInStock();
MakeSureUserHasBalanceToBuy();
RunTheTransaction();
}
*Better way to fix bugs: In TDD approach when QA finds a bug, developer first writes a test that generates the bug (that is the test will fail due to this bug). Then developer modifies code to make sure that the test is passed (i.e., the bug is fixed). This approach makes sure that next time the bug will not appear in the system as a test is written in the system to take care of the bug.
*Repetition of the same bug reduced: With TDD once a bug is found, it's put under test. So every time you run the whole test in the system, the tests associated with the bug are run and make sure the bugs are not generated again.

=Shortcomings Of TDD=
*The actual database or external file is never tested directly by TDD (only production code can test it)
*If not used carefully, it can add to the total project costs and complexity of the project
*TDD is unable to test UI.
*TDD is highly reliant on Refactoring and Programmer Skills.

=Conclusion=
Danielle
=References=
*[http://catalog.lib.ncsu.edu/record/NCSU1601963 Beck, K. (2002). Test-driven development by example. Addison-Wesley.]
*[http://en.wikipedia.org/wiki/Test_driven_development (n.d.). Test-driven development. website: http://en.wikipedia.org/wiki/Test_driven_development]
*[http://c2.com/cgi/wiki?TestDrivenDevelopment (2012, January 11). Test driven development. website: http://c2.com/cgi/wiki?TestDrivenDevelopment]
*[http://www.agiledata.org/essays/tdd.html Ambler, S. W. (2002). Introduction to test driven development (tdd). Retrieved from Agile Data website: http://www.agiledata.org/essays/tdd.html]
*http://www.testdriven.com/ ?

CSC/ECE 517 Fall 2012/ch2a 2w11 aa

2012-10-23T20:13:33Z

Annice: /* Shortcomings of TDD */

=Introduction=
Test driven development (TDD) is a process that tries to create the minimal amount of code to meet customer's expectations. The idea is to test first, code second, then improve (or refactor) last. This process forces the software developers to focus on customer specifications and validation first. Since at each step of the way the programmer proves to himself that the code meets specifications, TDD gives the programmer confidence. The rest of this chapter gives the motivation for TDD, shows the steps for TDD, outlines the principles of TDD, and provides examples using TDD.

=Motivation for TDD=
*Testing is the one activity that improves the quality of code. In various design scenarios, like waterfall model, testing occurs towards the end of the project development activity. As shown in the figure 1, introducing testing as a latter phase increases the cost incurred for implementing the changes. From this we infer that there is a high chance of reducing the costs by moving the Test phase to the initial part.
*The client can also be well informed about the design and can suggest changes which can be incorporated well in advance. This approach also known as TDD helps achieve flexibility to achieve the client’s ever-changing requirements
=Principles=
*Tests serve as examples of how to use a class or method. Once used to having tests that show how things work (and that they work), developers start inquiring if a test was already there for the piece of code to be developed
*Developer tests are distinctly different from QA (Quality Analysis) tests and should be kept separate. QA tests target features and treat the system as a black box. Unit tests created by the developer operate at a lower level and test different things.
*Name the tests carefully. For Example, name test packages like the package being tested with a suffix. For example, the "DataAccess" project/package is tested by "DataAccess.Test". Also, name test classes the same as the class under test with the suffix "Test". For example, the class "PrintManager" is tested by the test class "PrintManagerTest". This convention makes it easy to find the related class and keeps the class name a noun. You should also name test methods the same as the method being tested with the prefix "Test". For example, the method "PrintProductOrder()" is tested by the method "TestPrintProductOrder()". This convention keeps the method name a verb that reads as an english phrase.
*Write each test before writing the method under test. It encourages the developer to think as a user of the target method before thinking about implementation, which usually results in a cleaner, easier-to-use interface.
*Follow the "3-As" pattern for test methods: Arrange, Act, Assert. Specifically, use separate code paragraphs (groups of lines of code separated by a blank line) for each of the As. Arrange is variable declaration and initialization. Act is invoking the code under test. Assert is using the Assert.* methods to verify that expectations were met.
*When writing application code, only write enough code to make a test work. This technique prevents gold-plating and ensures that you always have a test for the code you write.
*When you find you need to refractor working code, refractor and re-test prior to writing new code. This technique ensures your refractoring is correct prior to adding new functionality and applies to creating new methods, introducing inheritance, everything.
=Steps=

Follow these steps:
*Understand the requirements of the story, work item, or feature that you are working on.
*Red:Create a test and make it fail.
Imagine how the new code should be called and write the test as if the code already existed.
Create the new production code stub. Write just enough code so that it compiles.
Run the test. It should fail. This is a calibration measure to ensure that your test is calling the correct code and that the code is not working by accident. This is a meaningful failure, and you expect it to fail.
*Green: Make the test pass by any means necessary.
Write the production code to make the test pass. Keep it simple.
Some advocate the hard-coding of the expected return value first to verify that the test correctly detects success. This varies from practitioner to practitioner.If you've written the code so that the test passes as intended, you are finished. You do not have to write more code speculatively. If new functionality is still needed, then another test is needed. Make this one test pass and continue.
When the test passes, you might want to run all tests up to this point to build confidence that everything else is still working.
*Refractor: Change the code to remove duplication in your project and to improve the design while ensuring that all tests still pass.
Remove duplication caused by the addition of the new functionality.
Make design changes to improve the overall solution.
After each refactoring, rerun all the tests to ensure that they all still pass.
*Repeat the cycle. Each cycle should be very short, and a typical hour should contain many Red/Green/ Refractor cycles.

=Examples=

==Homework Grades Program==

===Setup===
As a simple example, we are creating a program that keeps track of our homework grades. We envision that we would be able to get the average of these homework grades. Step one: write a test . Let's test an average function

<pre>
myHomework = new Homework();
myHomework.grades = [100, 50];
assert(myHomework.average(myHomework.grades) == 75);
</pre>

We will get multiple errors - this test won't even compile (but, that's ok for now). Let's take a look at what will generate error messages:

* class <code>Homework</code> not declared
* <code>Homework</code> constructor not declared
* field <code>grades</code> not declared
* method <code>average</code> not declared

Now, we fix the first error:

<pre>
class Homework {

}
</pre>

Second error:

<pre>
Homework(void) {

}
</pre>

Third error:

<pre>
int * grades;
</pre>

Fourth error:

<pre>
int average(int * grades) {
return 0; // default return value
}
</pre>

Finally, the test compiles! The code now looks like this:

<pre>
class Homework {

int * grades;

Homework(void) {

}

int average(int * grades) {

return 0; // default return value

}

}
</pre>

===Red===
Now, we run the test, and the familar red bar of failure greets us (remember the mantra red-green-refactor). The assert fails. The average function needs to actually average something (not just return 0). As we think about averaging the grades, we realize we need to know how many grades are in the int array <code>grades</code>. So, we add to the code:

<pre>
class Homework {

int * grades;
int numGrades; // new

Homework(void) {

}

int average(int * grades) {

int avg = 0; // new

for(int i = 0; i < numGrades; i++) { // new
avg += grades[i]; // new
} // new

return avg/numGrades; // new

}

}
</pre>

Of course, we must remember to change the test to:

<pre>
myHomework = new Homework();
myHomework.grades = [100, 50];
myHomework.numGrades = 2;
assert(myHomework.average(myHomework.grades) == 75);
</pre>

===Green===
Success! We have a green bar when we run it.

===Refactor===
The last step is refactoring. Perhaps we don't want a grade to be an <code>int</code>? Should it be an <code>unsigned int</code>? For this simple example, there isn't much refactoring to do, but in a larger example there may be multiple areas for improvement.

==More Examples==
See Test-Driven Development by Example by Kent Beck for more examples.

=Characteristics Of A Good Unit Test=
A good unit test has the following characteristics.
*It is important that the test executes fast. If the tests are slow, they will not be run often.
*Environmental dependencies such as databases, file systems, networks, queues, and so on which will slow down the tests are either separated or simulated. Tests that exercise these will not run fast, and a failure does not give meaningful feedback about what the problem actually is.
*The scope of testing is very limited. If the test fails, it's obvious where to look for the problem. It's important to only test one aspect in a single test.
*The test should run and pass in isolation (on any machine). If the tests require special environmental setup or fail unexpectedly, then they are not good unit tests.
*Such a test often uses stubs and mock objects. If the code being tested typically calls out to a database or file system, these dependencies must be simulated, or mocked. These dependencies will ordinarily be abstracted away by using interfaces.
*The intention of testing is clearly revealed. Another developer can look at the test and understand what is expected of the production code.

=Benefits of TDD=
*Automated testing: Automated system makes the testing much more easier and faster. Manual testing is slower and needs human interaction which is error-prone. Automated testing makes sure any particular test is not missing every time we test the system, whereas humans may leave a test out mistakenly during testing process.
*Better to test New/Modified Functionality: With manual testing whenever you add new functionality or modify existing functionality, QA personal needs to test all systems that may be affected due to the modification which may be time-consuming. This may also leave a hidden bug in the system after modification. With TDD whenever a new functionality is added or existing functionality is modified, the whole set of tests in the system is run to make sure existing tests are passed. This makes sure that existing functionality is not broken.
*Developer’s confidence: With TDD, developers are more safe to change the system as any inappropriate changes will make some tests to fail. With non-TDD system developers needs to take more care to change existing system as the new change may fail other functionality. But with TDD developers can do so easily as after modification if developer runs the test he/she will find immediately that the change has failed some other tests (i.e. some other part of the system).
*Manual testing stage is shortened: In non-TDD development, as soon as developers prepare a build, QA personal starts testing. This manual testing takes a reasonable amount of time and increases the time to deliver the product from the build time. With TDD, a major part of the system is tested during development and needs lesser QA involvement in the time between build and final delivery of the product.
*Alternative Documentation: Unit tests are kind of documentation to system. Each unit test tells about an individual requirement to the module or system. For example, the following test ensures that only a logged in user with proper balance can buy an item when the item exists in stock. This test reflects a user aspect scenario of the system.

public void CheckUserCanNotPurchaseItemWithoutBalance(){
LoginToTheSystem();
SelectAnItemToBuy();
MakeSureItemExsitsInStock();
MakeSureUserHasBalanceToBuy();
RunTheTransaction();
}
*Better way to fix bugs: In TDD approach when QA finds a bug, developer first writes a test that generates the bug (that is the test will fail due to this bug). Then developer modifies code to make sure that the test is passed (i.e., the bug is fixed). This approach makes sure that next time the bug will not appear in the system as a test is written in the system to take care of the bug.
*Repetition of the same bug reduced: With TDD once a bug is found, it's put under test. So every time you run the whole test in the system, the tests associated with the bug are run and make sure the bugs are not generated again.

=Shortcomings Of TDD=
*The actual database or external file is never tested directly by TDD (only production code can test it)
*If not used carefully, it can add to the total project costs and complexity of the project
*TDD is unable to test UI.
*TDD is highly reliant on Refactoring and Programmer Skills.

=Conclusion=
Danielle
=References=
*[http://catalog.lib.ncsu.edu/record/NCSU1601963 Beck, K. (2002). Test-driven development by example. Addison-Wesley.]
*[http://en.wikipedia.org/wiki/Test_driven_development (n.d.). Test-driven development. website: http://en.wikipedia.org/wiki/Test_driven_development]
*[http://c2.com/cgi/wiki?TestDrivenDevelopment (2012, January 11). Test driven development. website: http://c2.com/cgi/wiki?TestDrivenDevelopment]
*[http://www.agiledata.org/essays/tdd.html Ambler, S. W. (2002). Introduction to test driven development (tdd). Retrieved from Agile Data website: http://www.agiledata.org/essays/tdd.html]
*http://www.testdriven.com/ ?

CSC/ECE 517 Fall 2012/ch2a 2w11 aa

2012-10-23T20:13:15Z

Annice: /* Characteristics of a Good Unit Test */

=Introduction=
Test driven development (TDD) is a process that tries to create the minimal amount of code to meet customer's expectations. The idea is to test first, code second, then improve (or refactor) last. This process forces the software developers to focus on customer specifications and validation first. Since at each step of the way the programmer proves to himself that the code meets specifications, TDD gives the programmer confidence. The rest of this chapter gives the motivation for TDD, shows the steps for TDD, outlines the principles of TDD, and provides examples using TDD.

=Motivation for TDD=
*Testing is the one activity that improves the quality of code. In various design scenarios, like waterfall model, testing occurs towards the end of the project development activity. As shown in the figure 1, introducing testing as a latter phase increases the cost incurred for implementing the changes. From this we infer that there is a high chance of reducing the costs by moving the Test phase to the initial part.
*The client can also be well informed about the design and can suggest changes which can be incorporated well in advance. This approach also known as TDD helps achieve flexibility to achieve the client’s ever-changing requirements
=Principles=
*Tests serve as examples of how to use a class or method. Once used to having tests that show how things work (and that they work), developers start inquiring if a test was already there for the piece of code to be developed
*Developer tests are distinctly different from QA (Quality Analysis) tests and should be kept separate. QA tests target features and treat the system as a black box. Unit tests created by the developer operate at a lower level and test different things.
*Name the tests carefully. For Example, name test packages like the package being tested with a suffix. For example, the "DataAccess" project/package is tested by "DataAccess.Test". Also, name test classes the same as the class under test with the suffix "Test". For example, the class "PrintManager" is tested by the test class "PrintManagerTest". This convention makes it easy to find the related class and keeps the class name a noun. You should also name test methods the same as the method being tested with the prefix "Test". For example, the method "PrintProductOrder()" is tested by the method "TestPrintProductOrder()". This convention keeps the method name a verb that reads as an english phrase.
*Write each test before writing the method under test. It encourages the developer to think as a user of the target method before thinking about implementation, which usually results in a cleaner, easier-to-use interface.
*Follow the "3-As" pattern for test methods: Arrange, Act, Assert. Specifically, use separate code paragraphs (groups of lines of code separated by a blank line) for each of the As. Arrange is variable declaration and initialization. Act is invoking the code under test. Assert is using the Assert.* methods to verify that expectations were met.
*When writing application code, only write enough code to make a test work. This technique prevents gold-plating and ensures that you always have a test for the code you write.
*When you find you need to refractor working code, refractor and re-test prior to writing new code. This technique ensures your refractoring is correct prior to adding new functionality and applies to creating new methods, introducing inheritance, everything.
=Steps=

Follow these steps:
*Understand the requirements of the story, work item, or feature that you are working on.
*Red:Create a test and make it fail.
Imagine how the new code should be called and write the test as if the code already existed.
Create the new production code stub. Write just enough code so that it compiles.
Run the test. It should fail. This is a calibration measure to ensure that your test is calling the correct code and that the code is not working by accident. This is a meaningful failure, and you expect it to fail.
*Green: Make the test pass by any means necessary.
Write the production code to make the test pass. Keep it simple.
Some advocate the hard-coding of the expected return value first to verify that the test correctly detects success. This varies from practitioner to practitioner.If you've written the code so that the test passes as intended, you are finished. You do not have to write more code speculatively. If new functionality is still needed, then another test is needed. Make this one test pass and continue.
When the test passes, you might want to run all tests up to this point to build confidence that everything else is still working.
*Refractor: Change the code to remove duplication in your project and to improve the design while ensuring that all tests still pass.
Remove duplication caused by the addition of the new functionality.
Make design changes to improve the overall solution.
After each refactoring, rerun all the tests to ensure that they all still pass.
*Repeat the cycle. Each cycle should be very short, and a typical hour should contain many Red/Green/ Refractor cycles.

=Examples=

==Homework Grades Program==

===Setup===
As a simple example, we are creating a program that keeps track of our homework grades. We envision that we would be able to get the average of these homework grades. Step one: write a test . Let's test an average function

<pre>
myHomework = new Homework();
myHomework.grades = [100, 50];
assert(myHomework.average(myHomework.grades) == 75);
</pre>

We will get multiple errors - this test won't even compile (but, that's ok for now). Let's take a look at what will generate error messages:

* class <code>Homework</code> not declared
* <code>Homework</code> constructor not declared
* field <code>grades</code> not declared
* method <code>average</code> not declared

Now, we fix the first error:

<pre>
class Homework {

}
</pre>

Second error:

<pre>
Homework(void) {

}
</pre>

Third error:

<pre>
int * grades;
</pre>

Fourth error:

<pre>
int average(int * grades) {
return 0; // default return value
}
</pre>

Finally, the test compiles! The code now looks like this:

<pre>
class Homework {

int * grades;

Homework(void) {

}

int average(int * grades) {

return 0; // default return value

}

}
</pre>

===Red===
Now, we run the test, and the familar red bar of failure greets us (remember the mantra red-green-refactor). The assert fails. The average function needs to actually average something (not just return 0). As we think about averaging the grades, we realize we need to know how many grades are in the int array <code>grades</code>. So, we add to the code:

<pre>
class Homework {

int * grades;
int numGrades; // new

Homework(void) {

}

int average(int * grades) {

int avg = 0; // new

for(int i = 0; i < numGrades; i++) { // new
avg += grades[i]; // new
} // new

return avg/numGrades; // new

}

}
</pre>

Of course, we must remember to change the test to:

<pre>
myHomework = new Homework();
myHomework.grades = [100, 50];
myHomework.numGrades = 2;
assert(myHomework.average(myHomework.grades) == 75);
</pre>

===Green===
Success! We have a green bar when we run it.

===Refactor===
The last step is refactoring. Perhaps we don't want a grade to be an <code>int</code>? Should it be an <code>unsigned int</code>? For this simple example, there isn't much refactoring to do, but in a larger example there may be multiple areas for improvement.

==More Examples==
See Test-Driven Development by Example by Kent Beck for more examples.

=Characteristics Of A Good Unit Test=
A good unit test has the following characteristics.
*It is important that the test executes fast. If the tests are slow, they will not be run often.
*Environmental dependencies such as databases, file systems, networks, queues, and so on which will slow down the tests are either separated or simulated. Tests that exercise these will not run fast, and a failure does not give meaningful feedback about what the problem actually is.
*The scope of testing is very limited. If the test fails, it's obvious where to look for the problem. It's important to only test one aspect in a single test.
*The test should run and pass in isolation (on any machine). If the tests require special environmental setup or fail unexpectedly, then they are not good unit tests.
*Such a test often uses stubs and mock objects. If the code being tested typically calls out to a database or file system, these dependencies must be simulated, or mocked. These dependencies will ordinarily be abstracted away by using interfaces.
*The intention of testing is clearly revealed. Another developer can look at the test and understand what is expected of the production code.

=Benefits of TDD=
*Automated testing: Automated system makes the testing much more easier and faster. Manual testing is slower and needs human interaction which is error-prone. Automated testing makes sure any particular test is not missing every time we test the system, whereas humans may leave a test out mistakenly during testing process.
*Better to test New/Modified Functionality: With manual testing whenever you add new functionality or modify existing functionality, QA personal needs to test all systems that may be affected due to the modification which may be time-consuming. This may also leave a hidden bug in the system after modification. With TDD whenever a new functionality is added or existing functionality is modified, the whole set of tests in the system is run to make sure existing tests are passed. This makes sure that existing functionality is not broken.
*Developer’s confidence: With TDD, developers are more safe to change the system as any inappropriate changes will make some tests to fail. With non-TDD system developers needs to take more care to change existing system as the new change may fail other functionality. But with TDD developers can do so easily as after modification if developer runs the test he/she will find immediately that the change has failed some other tests (i.e. some other part of the system).
*Manual testing stage is shortened: In non-TDD development, as soon as developers prepare a build, QA personal starts testing. This manual testing takes a reasonable amount of time and increases the time to deliver the product from the build time. With TDD, a major part of the system is tested during development and needs lesser QA involvement in the time between build and final delivery of the product.
*Alternative Documentation: Unit tests are kind of documentation to system. Each unit test tells about an individual requirement to the module or system. For example, the following test ensures that only a logged in user with proper balance can buy an item when the item exists in stock. This test reflects a user aspect scenario of the system.

public void CheckUserCanNotPurchaseItemWithoutBalance(){
LoginToTheSystem();
SelectAnItemToBuy();
MakeSureItemExsitsInStock();
MakeSureUserHasBalanceToBuy();
RunTheTransaction();
}
*Better way to fix bugs: In TDD approach when QA finds a bug, developer first writes a test that generates the bug (that is the test will fail due to this bug). Then developer modifies code to make sure that the test is passed (i.e., the bug is fixed). This approach makes sure that next time the bug will not appear in the system as a test is written in the system to take care of the bug.
*Repetition of the same bug reduced: With TDD once a bug is found, it's put under test. So every time you run the whole test in the system, the tests associated with the bug are run and make sure the bugs are not generated again.

=Shortcomings of TDD=
*The actual database or external file is never tested directly by TDD (only production code can test it)
*If not used carefully, it can add to the total project costs and complexity of the project
*TDD is unable to test UI.
*TDD is highly reliant on Refactoring and Programmer Skills.

=Conclusion=
Danielle
=References=
*[http://catalog.lib.ncsu.edu/record/NCSU1601963 Beck, K. (2002). Test-driven development by example. Addison-Wesley.]
*[http://en.wikipedia.org/wiki/Test_driven_development (n.d.). Test-driven development. website: http://en.wikipedia.org/wiki/Test_driven_development]
*[http://c2.com/cgi/wiki?TestDrivenDevelopment (2012, January 11). Test driven development. website: http://c2.com/cgi/wiki?TestDrivenDevelopment]
*[http://www.agiledata.org/essays/tdd.html Ambler, S. W. (2002). Introduction to test driven development (tdd). Retrieved from Agile Data website: http://www.agiledata.org/essays/tdd.html]
*http://www.testdriven.com/ ?

CSC/ECE 517 Fall 2012/ch2a 2w11 aa

2012-10-23T20:12:56Z

Annice: /* Characteristics of a good unit test */

=Introduction=
Test driven development (TDD) is a process that tries to create the minimal amount of code to meet customer's expectations. The idea is to test first, code second, then improve (or refactor) last. This process forces the software developers to focus on customer specifications and validation first. Since at each step of the way the programmer proves to himself that the code meets specifications, TDD gives the programmer confidence. The rest of this chapter gives the motivation for TDD, shows the steps for TDD, outlines the principles of TDD, and provides examples using TDD.

=Motivation for TDD=
*Testing is the one activity that improves the quality of code. In various design scenarios, like waterfall model, testing occurs towards the end of the project development activity. As shown in the figure 1, introducing testing as a latter phase increases the cost incurred for implementing the changes. From this we infer that there is a high chance of reducing the costs by moving the Test phase to the initial part.
*The client can also be well informed about the design and can suggest changes which can be incorporated well in advance. This approach also known as TDD helps achieve flexibility to achieve the client’s ever-changing requirements
=Principles=
*Tests serve as examples of how to use a class or method. Once used to having tests that show how things work (and that they work), developers start inquiring if a test was already there for the piece of code to be developed
*Developer tests are distinctly different from QA (Quality Analysis) tests and should be kept separate. QA tests target features and treat the system as a black box. Unit tests created by the developer operate at a lower level and test different things.
*Name the tests carefully. For Example, name test packages like the package being tested with a suffix. For example, the "DataAccess" project/package is tested by "DataAccess.Test". Also, name test classes the same as the class under test with the suffix "Test". For example, the class "PrintManager" is tested by the test class "PrintManagerTest". This convention makes it easy to find the related class and keeps the class name a noun. You should also name test methods the same as the method being tested with the prefix "Test". For example, the method "PrintProductOrder()" is tested by the method "TestPrintProductOrder()". This convention keeps the method name a verb that reads as an english phrase.
*Write each test before writing the method under test. It encourages the developer to think as a user of the target method before thinking about implementation, which usually results in a cleaner, easier-to-use interface.
*Follow the "3-As" pattern for test methods: Arrange, Act, Assert. Specifically, use separate code paragraphs (groups of lines of code separated by a blank line) for each of the As. Arrange is variable declaration and initialization. Act is invoking the code under test. Assert is using the Assert.* methods to verify that expectations were met.
*When writing application code, only write enough code to make a test work. This technique prevents gold-plating and ensures that you always have a test for the code you write.
*When you find you need to refractor working code, refractor and re-test prior to writing new code. This technique ensures your refractoring is correct prior to adding new functionality and applies to creating new methods, introducing inheritance, everything.
=Steps=

Follow these steps:
*Understand the requirements of the story, work item, or feature that you are working on.
*Red:Create a test and make it fail.
Imagine how the new code should be called and write the test as if the code already existed.
Create the new production code stub. Write just enough code so that it compiles.
Run the test. It should fail. This is a calibration measure to ensure that your test is calling the correct code and that the code is not working by accident. This is a meaningful failure, and you expect it to fail.
*Green: Make the test pass by any means necessary.
Write the production code to make the test pass. Keep it simple.
Some advocate the hard-coding of the expected return value first to verify that the test correctly detects success. This varies from practitioner to practitioner.If you've written the code so that the test passes as intended, you are finished. You do not have to write more code speculatively. If new functionality is still needed, then another test is needed. Make this one test pass and continue.
When the test passes, you might want to run all tests up to this point to build confidence that everything else is still working.
*Refractor: Change the code to remove duplication in your project and to improve the design while ensuring that all tests still pass.
Remove duplication caused by the addition of the new functionality.
Make design changes to improve the overall solution.
After each refactoring, rerun all the tests to ensure that they all still pass.
*Repeat the cycle. Each cycle should be very short, and a typical hour should contain many Red/Green/ Refractor cycles.

=Examples=

==Homework Grades Program==

===Setup===
As a simple example, we are creating a program that keeps track of our homework grades. We envision that we would be able to get the average of these homework grades. Step one: write a test . Let's test an average function

<pre>
myHomework = new Homework();
myHomework.grades = [100, 50];
assert(myHomework.average(myHomework.grades) == 75);
</pre>

We will get multiple errors - this test won't even compile (but, that's ok for now). Let's take a look at what will generate error messages:

* class <code>Homework</code> not declared
* <code>Homework</code> constructor not declared
* field <code>grades</code> not declared
* method <code>average</code> not declared

Now, we fix the first error:

<pre>
class Homework {

}
</pre>

Second error:

<pre>
Homework(void) {

}
</pre>

Third error:

<pre>
int * grades;
</pre>

Fourth error:

<pre>
int average(int * grades) {
return 0; // default return value
}
</pre>

Finally, the test compiles! The code now looks like this:

<pre>
class Homework {

int * grades;

Homework(void) {

}

int average(int * grades) {

return 0; // default return value

}

}
</pre>

===Red===
Now, we run the test, and the familar red bar of failure greets us (remember the mantra red-green-refactor). The assert fails. The average function needs to actually average something (not just return 0). As we think about averaging the grades, we realize we need to know how many grades are in the int array <code>grades</code>. So, we add to the code:

<pre>
class Homework {

int * grades;
int numGrades; // new

Homework(void) {

}

int average(int * grades) {

int avg = 0; // new

for(int i = 0; i < numGrades; i++) { // new
avg += grades[i]; // new
} // new

return avg/numGrades; // new

}

}
</pre>

Of course, we must remember to change the test to:

<pre>
myHomework = new Homework();
myHomework.grades = [100, 50];
myHomework.numGrades = 2;
assert(myHomework.average(myHomework.grades) == 75);
</pre>

===Green===
Success! We have a green bar when we run it.

===Refactor===
The last step is refactoring. Perhaps we don't want a grade to be an <code>int</code>? Should it be an <code>unsigned int</code>? For this simple example, there isn't much refactoring to do, but in a larger example there may be multiple areas for improvement.

==More Examples==
See Test-Driven Development by Example by Kent Beck for more examples.

=Characteristics of a Good Unit Test=
A good unit test has the following characteristics.
*It is important that the test executes fast. If the tests are slow, they will not be run often.
*Environmental dependencies such as databases, file systems, networks, queues, and so on which will slow down the tests are either separated or simulated. Tests that exercise these will not run fast, and a failure does not give meaningful feedback about what the problem actually is.
*The scope of testing is very limited. If the test fails, it's obvious where to look for the problem. It's important to only test one aspect in a single test.
*The test should run and pass in isolation (on any machine). If the tests require special environmental setup or fail unexpectedly, then they are not good unit tests.
*Such a test often uses stubs and mock objects. If the code being tested typically calls out to a database or file system, these dependencies must be simulated, or mocked. These dependencies will ordinarily be abstracted away by using interfaces.
*The intention of testing is clearly revealed. Another developer can look at the test and understand what is expected of the production code.

=Benefits of TDD=
*Automated testing: Automated system makes the testing much more easier and faster. Manual testing is slower and needs human interaction which is error-prone. Automated testing makes sure any particular test is not missing every time we test the system, whereas humans may leave a test out mistakenly during testing process.
*Better to test New/Modified Functionality: With manual testing whenever you add new functionality or modify existing functionality, QA personal needs to test all systems that may be affected due to the modification which may be time-consuming. This may also leave a hidden bug in the system after modification. With TDD whenever a new functionality is added or existing functionality is modified, the whole set of tests in the system is run to make sure existing tests are passed. This makes sure that existing functionality is not broken.
*Developer’s confidence: With TDD, developers are more safe to change the system as any inappropriate changes will make some tests to fail. With non-TDD system developers needs to take more care to change existing system as the new change may fail other functionality. But with TDD developers can do so easily as after modification if developer runs the test he/she will find immediately that the change has failed some other tests (i.e. some other part of the system).
*Manual testing stage is shortened: In non-TDD development, as soon as developers prepare a build, QA personal starts testing. This manual testing takes a reasonable amount of time and increases the time to deliver the product from the build time. With TDD, a major part of the system is tested during development and needs lesser QA involvement in the time between build and final delivery of the product.
*Alternative Documentation: Unit tests are kind of documentation to system. Each unit test tells about an individual requirement to the module or system. For example, the following test ensures that only a logged in user with proper balance can buy an item when the item exists in stock. This test reflects a user aspect scenario of the system.

public void CheckUserCanNotPurchaseItemWithoutBalance(){
LoginToTheSystem();
SelectAnItemToBuy();
MakeSureItemExsitsInStock();
MakeSureUserHasBalanceToBuy();
RunTheTransaction();
}
*Better way to fix bugs: In TDD approach when QA finds a bug, developer first writes a test that generates the bug (that is the test will fail due to this bug). Then developer modifies code to make sure that the test is passed (i.e., the bug is fixed). This approach makes sure that next time the bug will not appear in the system as a test is written in the system to take care of the bug.
*Repetition of the same bug reduced: With TDD once a bug is found, it's put under test. So every time you run the whole test in the system, the tests associated with the bug are run and make sure the bugs are not generated again.

=Shortcomings of TDD=
*The actual database or external file is never tested directly by TDD (only production code can test it)
*If not used carefully, it can add to the total project costs and complexity of the project
*TDD is unable to test UI.
*TDD is highly reliant on Refactoring and Programmer Skills.

=Conclusion=
Danielle
=References=
*[http://catalog.lib.ncsu.edu/record/NCSU1601963 Beck, K. (2002). Test-driven development by example. Addison-Wesley.]
*[http://en.wikipedia.org/wiki/Test_driven_development (n.d.). Test-driven development. website: http://en.wikipedia.org/wiki/Test_driven_development]
*[http://c2.com/cgi/wiki?TestDrivenDevelopment (2012, January 11). Test driven development. website: http://c2.com/cgi/wiki?TestDrivenDevelopment]
*[http://www.agiledata.org/essays/tdd.html Ambler, S. W. (2002). Introduction to test driven development (tdd). Retrieved from Agile Data website: http://www.agiledata.org/essays/tdd.html]
*http://www.testdriven.com/ ?

CSC/ECE 517 Fall 2012/ch2a 2w11 aa

2012-10-23T20:12:16Z

Annice:

=Introduction=
Test driven development (TDD) is a process that tries to create the minimal amount of code to meet customer's expectations. The idea is to test first, code second, then improve (or refactor) last. This process forces the software developers to focus on customer specifications and validation first. Since at each step of the way the programmer proves to himself that the code meets specifications, TDD gives the programmer confidence. The rest of this chapter gives the motivation for TDD, shows the steps for TDD, outlines the principles of TDD, and provides examples using TDD.

=Motivation for TDD=
*Testing is the one activity that improves the quality of code. In various design scenarios, like waterfall model, testing occurs towards the end of the project development activity. As shown in the figure 1, introducing testing as a latter phase increases the cost incurred for implementing the changes. From this we infer that there is a high chance of reducing the costs by moving the Test phase to the initial part.
*The client can also be well informed about the design and can suggest changes which can be incorporated well in advance. This approach also known as TDD helps achieve flexibility to achieve the client’s ever-changing requirements
=Principles=
*Tests serve as examples of how to use a class or method. Once used to having tests that show how things work (and that they work), developers start inquiring if a test was already there for the piece of code to be developed
*Developer tests are distinctly different from QA (Quality Analysis) tests and should be kept separate. QA tests target features and treat the system as a black box. Unit tests created by the developer operate at a lower level and test different things.
*Name the tests carefully. For Example, name test packages like the package being tested with a suffix. For example, the "DataAccess" project/package is tested by "DataAccess.Test". Also, name test classes the same as the class under test with the suffix "Test". For example, the class "PrintManager" is tested by the test class "PrintManagerTest". This convention makes it easy to find the related class and keeps the class name a noun. You should also name test methods the same as the method being tested with the prefix "Test". For example, the method "PrintProductOrder()" is tested by the method "TestPrintProductOrder()". This convention keeps the method name a verb that reads as an english phrase.
*Write each test before writing the method under test. It encourages the developer to think as a user of the target method before thinking about implementation, which usually results in a cleaner, easier-to-use interface.
*Follow the "3-As" pattern for test methods: Arrange, Act, Assert. Specifically, use separate code paragraphs (groups of lines of code separated by a blank line) for each of the As. Arrange is variable declaration and initialization. Act is invoking the code under test. Assert is using the Assert.* methods to verify that expectations were met.
*When writing application code, only write enough code to make a test work. This technique prevents gold-plating and ensures that you always have a test for the code you write.
*When you find you need to refractor working code, refractor and re-test prior to writing new code. This technique ensures your refractoring is correct prior to adding new functionality and applies to creating new methods, introducing inheritance, everything.
=Steps=

Follow these steps:
*Understand the requirements of the story, work item, or feature that you are working on.
*Red:Create a test and make it fail.
Imagine how the new code should be called and write the test as if the code already existed.
Create the new production code stub. Write just enough code so that it compiles.
Run the test. It should fail. This is a calibration measure to ensure that your test is calling the correct code and that the code is not working by accident. This is a meaningful failure, and you expect it to fail.
*Green: Make the test pass by any means necessary.
Write the production code to make the test pass. Keep it simple.
Some advocate the hard-coding of the expected return value first to verify that the test correctly detects success. This varies from practitioner to practitioner.If you've written the code so that the test passes as intended, you are finished. You do not have to write more code speculatively. If new functionality is still needed, then another test is needed. Make this one test pass and continue.
When the test passes, you might want to run all tests up to this point to build confidence that everything else is still working.
*Refractor: Change the code to remove duplication in your project and to improve the design while ensuring that all tests still pass.
Remove duplication caused by the addition of the new functionality.
Make design changes to improve the overall solution.
After each refactoring, rerun all the tests to ensure that they all still pass.
*Repeat the cycle. Each cycle should be very short, and a typical hour should contain many Red/Green/ Refractor cycles.

=Examples=

==Homework Grades Program==

===Setup===
As a simple example, we are creating a program that keeps track of our homework grades. We envision that we would be able to get the average of these homework grades. Step one: write a test . Let's test an average function

<pre>
myHomework = new Homework();
myHomework.grades = [100, 50];
assert(myHomework.average(myHomework.grades) == 75);
</pre>

We will get multiple errors - this test won't even compile (but, that's ok for now). Let's take a look at what will generate error messages:

* class <code>Homework</code> not declared
* <code>Homework</code> constructor not declared
* field <code>grades</code> not declared
* method <code>average</code> not declared

Now, we fix the first error:

<pre>
class Homework {

}
</pre>

Second error:

<pre>
Homework(void) {

}
</pre>

Third error:

<pre>
int * grades;
</pre>

Fourth error:

<pre>
int average(int * grades) {
return 0; // default return value
}
</pre>

Finally, the test compiles! The code now looks like this:

<pre>
class Homework {

int * grades;

Homework(void) {

}

int average(int * grades) {

return 0; // default return value

}

}
</pre>

===Red===
Now, we run the test, and the familar red bar of failure greets us (remember the mantra red-green-refactor). The assert fails. The average function needs to actually average something (not just return 0). As we think about averaging the grades, we realize we need to know how many grades are in the int array <code>grades</code>. So, we add to the code:

<pre>
class Homework {

int * grades;
int numGrades; // new

Homework(void) {

}

int average(int * grades) {

int avg = 0; // new

for(int i = 0; i < numGrades; i++) { // new
avg += grades[i]; // new
} // new

return avg/numGrades; // new

}

}
</pre>

Of course, we must remember to change the test to:

<pre>
myHomework = new Homework();
myHomework.grades = [100, 50];
myHomework.numGrades = 2;
assert(myHomework.average(myHomework.grades) == 75);
</pre>

===Green===
Success! We have a green bar when we run it.

===Refactor===
The last step is refactoring. Perhaps we don't want a grade to be an <code>int</code>? Should it be an <code>unsigned int</code>? For this simple example, there isn't much refactoring to do, but in a larger example there may be multiple areas for improvement.

==More Examples==
See Test-Driven Development by Example by Kent Beck for more examples.

=Characteristics of a good unit test=
A good unit test has the following characteristics.
*It is important that the test executes fast. If the tests are slow, they will not be run often.
*Environmental dependencies such as databases, file systems, networks, queues, and so on which will slow down the tests are either separated or simulated. Tests that exercise these will not run fast, and a failure does not give meaningful feedback about what the problem actually is.
*The scope of testing is very limited. If the test fails, it's obvious where to look for the problem. It's important to only test one aspect in a single test.
*The test should run and pass in isolation (on any machine). If the tests require special environmental setup or fail unexpectedly, then they are not good unit tests.
*Such a test often uses stubs and mock objects. If the code being tested typically calls out to a database or file system, these dependencies must be simulated, or mocked. These dependencies will ordinarily be abstracted away by using interfaces.
*The intention of testing is clearly revealed. Another developer can look at the test and understand what is expected of the production code.

=Benefits of TDD=
*Automated testing: Automated system makes the testing much more easier and faster. Manual testing is slower and needs human interaction which is error-prone. Automated testing makes sure any particular test is not missing every time we test the system, whereas humans may leave a test out mistakenly during testing process.
*Better to test New/Modified Functionality: With manual testing whenever you add new functionality or modify existing functionality, QA personal needs to test all systems that may be affected due to the modification which may be time-consuming. This may also leave a hidden bug in the system after modification. With TDD whenever a new functionality is added or existing functionality is modified, the whole set of tests in the system is run to make sure existing tests are passed. This makes sure that existing functionality is not broken.
*Developer’s confidence: With TDD, developers are more safe to change the system as any inappropriate changes will make some tests to fail. With non-TDD system developers needs to take more care to change existing system as the new change may fail other functionality. But with TDD developers can do so easily as after modification if developer runs the test he/she will find immediately that the change has failed some other tests (i.e. some other part of the system).
*Manual testing stage is shortened: In non-TDD development, as soon as developers prepare a build, QA personal starts testing. This manual testing takes a reasonable amount of time and increases the time to deliver the product from the build time. With TDD, a major part of the system is tested during development and needs lesser QA involvement in the time between build and final delivery of the product.
*Alternative Documentation: Unit tests are kind of documentation to system. Each unit test tells about an individual requirement to the module or system. For example, the following test ensures that only a logged in user with proper balance can buy an item when the item exists in stock. This test reflects a user aspect scenario of the system.

public void CheckUserCanNotPurchaseItemWithoutBalance(){
LoginToTheSystem();
SelectAnItemToBuy();
MakeSureItemExsitsInStock();
MakeSureUserHasBalanceToBuy();
RunTheTransaction();
}
*Better way to fix bugs: In TDD approach when QA finds a bug, developer first writes a test that generates the bug (that is the test will fail due to this bug). Then developer modifies code to make sure that the test is passed (i.e., the bug is fixed). This approach makes sure that next time the bug will not appear in the system as a test is written in the system to take care of the bug.
*Repetition of the same bug reduced: With TDD once a bug is found, it's put under test. So every time you run the whole test in the system, the tests associated with the bug are run and make sure the bugs are not generated again.

=Shortcomings of TDD=
*The actual database or external file is never tested directly by TDD (only production code can test it)
*If not used carefully, it can add to the total project costs and complexity of the project
*TDD is unable to test UI.
*TDD is highly reliant on Refactoring and Programmer Skills.

=Conclusion=
Danielle
=References=
*[http://catalog.lib.ncsu.edu/record/NCSU1601963 Beck, K. (2002). Test-driven development by example. Addison-Wesley.]
*[http://en.wikipedia.org/wiki/Test_driven_development (n.d.). Test-driven development. website: http://en.wikipedia.org/wiki/Test_driven_development]
*[http://c2.com/cgi/wiki?TestDrivenDevelopment (2012, January 11). Test driven development. website: http://c2.com/cgi/wiki?TestDrivenDevelopment]
*[http://www.agiledata.org/essays/tdd.html Ambler, S. W. (2002). Introduction to test driven development (tdd). Retrieved from Agile Data website: http://www.agiledata.org/essays/tdd.html]
*http://www.testdriven.com/ ?

CSC/ECE 517 Fall 2012/ch2a 2w11 aa

2012-10-23T20:09:14Z

Annice:

=Introduction=
Test driven development (TDD) is a process that tries to create the minimal amount of code to meet customer's expectations. The idea is to test first, code second, then improve (or refactor) last. This process forces the software developers to focus on customer specifications and validation first. Since at each step of the way the programmer proves to himself that the code meets specifications, TDD gives the programmer confidence. The rest of this chapter gives the motivation for TDD, shows the steps for TDD, outlines the principles of TDD, and provides examples using TDD.

=Motivation for TDD=
*Testing is the one activity that improves the quality of code. In various design scenarios, like waterfall model, testing occurs towards the end of the project development activity. As shown in the figure 1, introducing testing as a latter phase increases the cost incurred for implementing the changes. From this we infer that there is a high chance of reducing the costs by moving the Test phase to the initial part.
*The client can also be well informed about the design and can suggest changes which can be incorporated well in advance. This approach also known as TDD helps achieve flexibility to achieve the client’s ever-changing requirements
=Principles=
*Tests serve as examples of how to use a class or method. Once used to having tests that show how things work (and that they work), developers start inquiring if a test was already there for the piece of code to be developed
*Developer tests are distinctly different from QA (Quality Analysis) tests and should be kept separate. QA tests target features and treat the system as a black box. Unit tests created by the developer operate at a lower level and test different things.
*Name the tests carefully. For Example, name test packages like the package being tested with a suffix. For example, the "DataAccess" project/package is tested by "DataAccess.Test". Also, name test classes the same as the class under test with the suffix "Test". For example, the class "PrintManager" is tested by the test class "PrintManagerTest". This convention makes it easy to find the related class and keeps the class name a noun. You should also name test methods the same as the method being tested with the prefix "Test". For example, the method "PrintProductOrder()" is tested by the method "TestPrintProductOrder()". This convention keeps the method name a verb that reads as an english phrase.
*Write each test before writing the method under test. It encourages the developer to think as a user of the target method before thinking about implementation, which usually results in a cleaner, easier-to-use interface.
*Follow the "3-As" pattern for test methods: Arrange, Act, Assert. Specifically, use separate code paragraphs (groups of lines of code separated by a blank line) for each of the As. Arrange is variable declaration and initialization. Act is invoking the code under test. Assert is using the Assert.* methods to verify that expectations were met.
*When writing application code, only write enough code to make a test work. This technique prevents gold-plating and ensures that you always have a test for the code you write.
*When you find you need to refractor working code, refractor and re-test prior to writing new code. This technique ensures your refractoring is correct prior to adding new functionality and applies to creating new methods, introducing inheritance, everything.
=Steps=

Follow these steps:
*Understand the requirements of the story, work item, or feature that you are working on.
*Red:Create a test and make it fail.
Imagine how the new code should be called and write the test as if the code already existed.
Create the new production code stub. Write just enough code so that it compiles.
Run the test. It should fail. This is a calibration measure to ensure that your test is calling the correct code and that the code is not working by accident. This is a meaningful failure, and you expect it to fail.
*Green: Make the test pass by any means necessary.
Write the production code to make the test pass. Keep it simple.
Some advocate the hard-coding of the expected return value first to verify that the test correctly detects success. This varies from practitioner to practitioner.If you've written the code so that the test passes as intended, you are finished. You do not have to write more code speculatively. If new functionality is still needed, then another test is needed. Make this one test pass and continue.
When the test passes, you might want to run all tests up to this point to build confidence that everything else is still working.
*Refractor: Change the code to remove duplication in your project and to improve the design while ensuring that all tests still pass.
Remove duplication caused by the addition of the new functionality.
Make design changes to improve the overall solution.
After each refactoring, rerun all the tests to ensure that they all still pass.
*Repeat the cycle. Each cycle should be very short, and a typical hour should contain many Red/Green/ Refractor cycles.

=Examples=

==Homework Grades Program==

===Setup===
As a simple example, we are creating a program that keeps track of our homework grades. We envision that we would be able to get the average of these homework grades. Step one: write a test . Let's test an average function

<pre>
myHomework = new Homework();
myHomework.grades = [100, 50];
assert(myHomework.average(myHomework.grades) == 75);
</pre>

We will get multiple errors - this test won't even compile (but, that's ok for now). Let's take a look at what will generate error messages:

* class <code>Homework</code> not declared
* <code>Homework</code> constructor not declared
* field <code>grades</code> not declared
* method <code>average</code> not declared

Now, we fix the first error:

<pre>
class Homework {

}
</pre>

Second error:

<pre>
Homework(void) {

}
</pre>

Third error:

<pre>
int * grades;
</pre>

Fourth error:

<pre>
int average(int * grades) {
return 0; // default return value
}
</pre>

Finally, the test compiles! The code now looks like this:

<pre>
class Homework {

int * grades;

Homework(void) {

}

int average(int * grades) {

return 0; // default return value

}

}
</pre>

===Red===
Now, we run the test, and the familar red bar of failure greets us (remember the mantra red-green-refactor). The assert fails. The average function needs to actually average something (not just return 0). As we think about averaging the grades, we realize we need to know how many grades are in the int array <code>grades</code>. So, we add to the code:

<pre>
class Homework {

int * grades;
int numGrades; // new

Homework(void) {

}

int average(int * grades) {

int avg = 0; // new

for(int i = 0; i < numGrades; i++) { // new
avg += grades[i]; // new
} // new

return avg/numGrades; // new

}

}
</pre>

Of course, we must remember to change the test to:

<pre>
myHomework = new Homework();
myHomework.grades = [100, 50];
myHomework.numGrades = 2;
assert(myHomework.average(myHomework.grades) == 75);
</pre>

===Green===
Success! We have a green bar when we run it.

===Refactor===
The last step is refactoring. Perhaps we don't want a grade to be an <code>int</code>? Should it be an <code>unsigned int</code>? For this simple example, there isn't much refactoring to do, but in a larger example there may be multiple areas for improvement.

==More Examples==
See Test-Driven Development by Example by Kent Beck for more examples.

=Benefits of TDD=
*Automated testing: Automated system makes the testing much more easier and faster. Manual testing is slower and needs human interaction which is error-prone. Automated testing makes sure any particular test is not missing every time we test the system, whereas humans may leave a test out mistakenly during testing process.
*Better to test New/Modified Functionality: With manual testing whenever you add new functionality or modify existing functionality, QA personal needs to test all systems that may be affected due to the modification which may be time-consuming. This may also leave a hidden bug in the system after modification. With TDD whenever a new functionality is added or existing functionality is modified, the whole set of tests in the system is run to make sure existing tests are passed. This makes sure that existing functionality is not broken.
*Developer’s confidence: With TDD, developers are more safe to change the system as any inappropriate changes will make some tests to fail. With non-TDD system developers needs to take more care to change existing system as the new change may fail other functionality. But with TDD developers can do so easily as after modification if developer runs the test he/she will find immediately that the change has failed some other tests (i.e. some other part of the system).
*Manual testing stage is shortened: In non-TDD development, as soon as developers prepare a build, QA personal starts testing. This manual testing takes a reasonable amount of time and increases the time to deliver the product from the build time. With TDD, a major part of the system is tested during development and needs lesser QA involvement in the time between build and final delivery of the product.
*Alternative Documentation: Unit tests are kind of documentation to system. Each unit test tells about an individual requirement to the module or system. For example, the following test ensures that only a logged in user with proper balance can buy an item when the item exists in stock. This test reflects a user aspect scenario of the system.

public void CheckUserCanNotPurchaseItemWithoutBalance(){
LoginToTheSystem();
SelectAnItemToBuy();
MakeSureItemExsitsInStock();
MakeSureUserHasBalanceToBuy();
RunTheTransaction();
}
*Better way to fix bugs: In TDD approach when QA finds a bug, developer first writes a test that generates the bug (that is the test will fail due to this bug). Then developer modifies code to make sure that the test is passed (i.e., the bug is fixed). This approach makes sure that next time the bug will not appear in the system as a test is written in the system to take care of the bug.
*Repetition of the same bug reduced: With TDD once a bug is found, it's put under test. So every time you run the whole test in the system, the tests associated with the bug are run and make sure the bugs are not generated again.

=Shortcomings of TDD=
*The actual database or external file is never tested directly by TDD (only production code can test it)
*If not used carefully, it can add to the total project costs and complexity of the project
*TDD is unable to test UI.
*TDD is highly reliant on Refactoring and Programmer Skills.

=Conclusion=
Danielle
=References=
*[http://catalog.lib.ncsu.edu/record/NCSU1601963 Beck, K. (2002). Test-driven development by example. Addison-Wesley.]
*[http://en.wikipedia.org/wiki/Test_driven_development (n.d.). Test-driven development. website: http://en.wikipedia.org/wiki/Test_driven_development]
*[http://c2.com/cgi/wiki?TestDrivenDevelopment (2012, January 11). Test driven development. website: http://c2.com/cgi/wiki?TestDrivenDevelopment]
*[http://www.agiledata.org/essays/tdd.html Ambler, S. W. (2002). Introduction to test driven development (tdd). Retrieved from Agile Data website: http://www.agiledata.org/essays/tdd.html]
*http://www.testdriven.com/ ?

CSC/ECE 517 Fall 2012/ch2a 2w11 aa

2012-10-23T20:08:04Z

Annice: /* Characteristics of a good unit test */

=Introduction=
Test driven development (TDD) is a process that tries to create the minimal amount of code to meet customer's expectations. The idea is to test first, code second, then improve (or refactor) last. This process forces the software developers to focus on customer specifications and validation first. Since at each step of the way the programmer proves to himself that the code meets specifications, TDD gives the programmer confidence. The rest of this chapter gives the motivation for TDD, shows the steps for TDD, outlines the principles of TDD, and provides examples using TDD.

=Motivation for TDD=
*Testing is the one activity that improves the quality of code. In various design scenarios, like waterfall model, testing occurs towards the end of the project development activity. As shown in the figure 1, introducing testing as a latter phase increases the cost incurred for implementing the changes. From this we infer that there is a high chance of reducing the costs by moving the Test phase to the initial part.
*The client can also be well informed about the design and can suggest changes which can be incorporated well in advance. This approach also known as TDD helps achieve flexibility to achieve the client’s ever-changing requirements
=Principles=
*Tests serve as examples of how to use a class or method. Once used to having tests that show how things work (and that they work), developers start inquiring if a test was already there for the piece of code to be developed
*Developer tests are distinctly different from QA (Quality Analysis) tests and should be kept separate. QA tests target features and treat the system as a black box. Unit tests created by the developer operate at a lower level and test different things.
*Name the tests carefully. For Example, name test packages like the package being tested with a suffix. For example, the "DataAccess" project/package is tested by "DataAccess.Test". Also, name test classes the same as the class under test with the suffix "Test". For example, the class "PrintManager" is tested by the test class "PrintManagerTest". This convention makes it easy to find the related class and keeps the class name a noun. You should also name test methods the same as the method being tested with the prefix "Test". For example, the method "PrintProductOrder()" is tested by the method "TestPrintProductOrder()". This convention keeps the method name a verb that reads as an english phrase.
*Write each test before writing the method under test. It encourages the developer to think as a user of the target method before thinking about implementation, which usually results in a cleaner, easier-to-use interface.
*Follow the "3-As" pattern for test methods: Arrange, Act, Assert. Specifically, use separate code paragraphs (groups of lines of code separated by a blank line) for each of the As. Arrange is variable declaration and initialization. Act is invoking the code under test. Assert is using the Assert.* methods to verify that expectations were met.
*When writing application code, only write enough code to make a test work. This technique prevents gold-plating and ensures that you always have a test for the code you write.
*When you find you need to refractor working code, refractor and re-test prior to writing new code. This technique ensures your refractoring is correct prior to adding new functionality and applies to creating new methods, introducing inheritance, everything.
=Steps=

Follow these steps:
*Understand the requirements of the story, work item, or feature that you are working on.
*Red:Create a test and make it fail.
Imagine how the new code should be called and write the test as if the code already existed.
Create the new production code stub. Write just enough code so that it compiles.
Run the test. It should fail. This is a calibration measure to ensure that your test is calling the correct code and that the code is not working by accident. This is a meaningful failure, and you expect it to fail.
*Green: Make the test pass by any means necessary.
Write the production code to make the test pass. Keep it simple.
Some advocate the hard-coding of the expected return value first to verify that the test correctly detects success. This varies from practitioner to practitioner.If you've written the code so that the test passes as intended, you are finished. You do not have to write more code speculatively. If new functionality is still needed, then another test is needed. Make this one test pass and continue.
When the test passes, you might want to run all tests up to this point to build confidence that everything else is still working.
*Refractor: Change the code to remove duplication in your project and to improve the design while ensuring that all tests still pass.
Remove duplication caused by the addition of the new functionality.
Make design changes to improve the overall solution.
After each refactoring, rerun all the tests to ensure that they all still pass.
*Repeat the cycle. Each cycle should be very short, and a typical hour should contain many Red/Green/ Refractor cycles.

=Examples=

==Homework Grades Program==

===Setup===
As a simple example, we are creating a program that keeps track of our homework grades. We envision that we would be able to get the average of these homework grades. Step one: write a test . Let's test an average function

<pre>
myHomework = new Homework();
myHomework.grades = [100, 50];
assert(myHomework.average(myHomework.grades) == 75);
</pre>

We will get multiple errors - this test won't even compile (but, that's ok for now). Let's take a look at what will generate error messages:

* class <code>Homework</code> not declared
* <code>Homework</code> constructor not declared
* field <code>grades</code> not declared
* method <code>average</code> not declared

Now, we fix the first error:

<pre>
class Homework {

}
</pre>

Second error:

<pre>
Homework(void) {

}
</pre>

Third error:

<pre>
int * grades;
</pre>

Fourth error:

<pre>
int average(int * grades) {
return 0; // default return value
}
</pre>

Finally, the test compiles! The code now looks like this:

<pre>
class Homework {

int * grades;

Homework(void) {

}

int average(int * grades) {

return 0; // default return value

}

}
</pre>

===Red===
Now, we run the test, and the familar red bar of failure greets us (remember the mantra red-green-refactor). The assert fails. The average function needs to actually average something (not just return 0). As we think about averaging the grades, we realize we need to know how many grades are in the int array <code>grades</code>. So, we add to the code:

<pre>
class Homework {

int * grades;
int numGrades; // new

Homework(void) {

}

int average(int * grades) {

int avg = 0; // new

for(int i = 0; i < numGrades; i++) { // new
avg += grades[i]; // new
} // new

return avg/numGrades; // new

}

}
</pre>

Of course, we must remember to change the test to:

<pre>
myHomework = new Homework();
myHomework.grades = [100, 50];
myHomework.numGrades = 2;
assert(myHomework.average(myHomework.grades) == 75);
</pre>

===Green===
Success! We have a green bar when we run it.

===Refactor===
The last step is refactoring. Perhaps we don't want a grade to be an <code>int</code>? Should it be an <code>unsigned int</code>? For this simple example, there isn't much refactoring to do, but in a larger example there may be multiple areas for improvement.

==More Examples==
See Test-Driven Development by Example by Kent Beck for more examples.

=Benefits of TDD=
*Automated testing: Automated system makes the testing much more easier and faster. Manual testing is slower and needs human interaction which is error-prone. Automated testing makes sure any particular test is not missing every time we test the system, whereas humans may leave a test out mistakenly during testing process.
*Better to test New/Modified Functionality: With manual testing whenever you add new functionality or modify existing functionality, QA personal needs to test all systems that may be affected due to the modification which may be time-consuming. This may also leave a hidden bug in the system after modification. With TDD whenever a new functionality is added or existing functionality is modified, the whole set of tests in the system is run to make sure existing tests are passed. This makes sure that existing functionality is not broken.
*Developer’s confidence: With TDD, developers are more safe to change the system as any inappropriate changes will make some tests to fail. With non-TDD system developers needs to take more care to change existing system as the new change may fail other functionality. But with TDD developers can do so easily as after modification if developer runs the test he/she will find immediately that the change has failed some other tests (i.e. some other part of the system).
*Manual testing stage is shortened: In non-TDD development, as soon as developers prepare a build, QA personal starts testing. This manual testing takes a reasonable amount of time and increases the time to deliver the product from the build time. With TDD, a major part of the system is tested during development and needs lesser QA involvement in the time between build and final delivery of the product.
*Alternative Documentation: Unit tests are kind of documentation to system. Each unit test tells about an individual requirement to the module or system. For example, the following test ensures that only a logged in user with proper balance can buy an item when the item exists in stock. This test reflects a user aspect scenario of the system.

public void CheckUserCanNotPurchaseItemWithoutBalance(){
LoginToTheSystem();
SelectAnItemToBuy();
MakeSureItemExsitsInStock();
MakeSureUserHasBalanceToBuy();
RunTheTransaction();
}
*Better way to fix bugs: In TDD approach when QA finds a bug, developer first writes a test that generates the bug (that is the test will fail due to this bug). Then developer modifies code to make sure that the test is passed (i.e., the bug is fixed). This approach makes sure that next time the bug will not appear in the system as a test is written in the system to take care of the bug.
*Repetition of the same bug reduced: With TDD once a bug is found, it's put under test. So every time you run the whole test in the system, the tests associated with the bug are run and make sure the bugs are not generated again.

=Conclusion=
Danielle
=References=
*[http://catalog.lib.ncsu.edu/record/NCSU1601963 Beck, K. (2002). Test-driven development by example. Addison-Wesley.]
*[http://en.wikipedia.org/wiki/Test_driven_development (n.d.). Test-driven development. website: http://en.wikipedia.org/wiki/Test_driven_development]
*[http://c2.com/cgi/wiki?TestDrivenDevelopment (2012, January 11). Test driven development. website: http://c2.com/cgi/wiki?TestDrivenDevelopment]
*[http://www.agiledata.org/essays/tdd.html Ambler, S. W. (2002). Introduction to test driven development (tdd). Retrieved from Agile Data website: http://www.agiledata.org/essays/tdd.html]
*http://www.testdriven.com/ ?

CSC/ECE 517 Fall 2012/ch2a 2w11 aa

2012-10-23T20:07:00Z

Annice: /* Characteristics of a good unit test */

=Introduction=
Test driven development (TDD) is a process that tries to create the minimal amount of code to meet customer's expectations. The idea is to test first, code second, then improve (or refactor) last. This process forces the software developers to focus on customer specifications and validation first. Since at each step of the way the programmer proves to himself that the code meets specifications, TDD gives the programmer confidence. The rest of this chapter gives the motivation for TDD, shows the steps for TDD, outlines the principles of TDD, and provides examples using TDD.

=Motivation for TDD=
*Testing is the one activity that improves the quality of code. In various design scenarios, like waterfall model, testing occurs towards the end of the project development activity. As shown in the figure 1, introducing testing as a latter phase increases the cost incurred for implementing the changes. From this we infer that there is a high chance of reducing the costs by moving the Test phase to the initial part.
*The client can also be well informed about the design and can suggest changes which can be incorporated well in advance. This approach also known as TDD helps achieve flexibility to achieve the client’s ever-changing requirements
=Principles=
*Tests serve as examples of how to use a class or method. Once used to having tests that show how things work (and that they work), developers start inquiring if a test was already there for the piece of code to be developed
*Developer tests are distinctly different from QA (Quality Analysis) tests and should be kept separate. QA tests target features and treat the system as a black box. Unit tests created by the developer operate at a lower level and test different things.
*Name the tests carefully. For Example, name test packages like the package being tested with a suffix. For example, the "DataAccess" project/package is tested by "DataAccess.Test". Also, name test classes the same as the class under test with the suffix "Test". For example, the class "PrintManager" is tested by the test class "PrintManagerTest". This convention makes it easy to find the related class and keeps the class name a noun. You should also name test methods the same as the method being tested with the prefix "Test". For example, the method "PrintProductOrder()" is tested by the method "TestPrintProductOrder()". This convention keeps the method name a verb that reads as an english phrase.
*Write each test before writing the method under test. It encourages the developer to think as a user of the target method before thinking about implementation, which usually results in a cleaner, easier-to-use interface.
*Follow the "3-As" pattern for test methods: Arrange, Act, Assert. Specifically, use separate code paragraphs (groups of lines of code separated by a blank line) for each of the As. Arrange is variable declaration and initialization. Act is invoking the code under test. Assert is using the Assert.* methods to verify that expectations were met.
*When writing application code, only write enough code to make a test work. This technique prevents gold-plating and ensures that you always have a test for the code you write.
*When you find you need to refractor working code, refractor and re-test prior to writing new code. This technique ensures your refractoring is correct prior to adding new functionality and applies to creating new methods, introducing inheritance, everything.
=Steps=

Follow these steps:
*Understand the requirements of the story, work item, or feature that you are working on.
*Red:Create a test and make it fail.
Imagine how the new code should be called and write the test as if the code already existed.
Create the new production code stub. Write just enough code so that it compiles.
Run the test. It should fail. This is a calibration measure to ensure that your test is calling the correct code and that the code is not working by accident. This is a meaningful failure, and you expect it to fail.
*Green: Make the test pass by any means necessary.
Write the production code to make the test pass. Keep it simple.
Some advocate the hard-coding of the expected return value first to verify that the test correctly detects success. This varies from practitioner to practitioner.If you've written the code so that the test passes as intended, you are finished. You do not have to write more code speculatively. If new functionality is still needed, then another test is needed. Make this one test pass and continue.
When the test passes, you might want to run all tests up to this point to build confidence that everything else is still working.
*Refractor: Change the code to remove duplication in your project and to improve the design while ensuring that all tests still pass.
Remove duplication caused by the addition of the new functionality.
Make design changes to improve the overall solution.
After each refactoring, rerun all the tests to ensure that they all still pass.
*Repeat the cycle. Each cycle should be very short, and a typical hour should contain many Red/Green/ Refractor cycles.

=Examples=

==Homework Grades Program==

===Setup===
As a simple example, we are creating a program that keeps track of our homework grades. We envision that we would be able to get the average of these homework grades. Step one: write a test . Let's test an average function

<pre>
myHomework = new Homework();
myHomework.grades = [100, 50];
assert(myHomework.average(myHomework.grades) == 75);
</pre>

We will get multiple errors - this test won't even compile (but, that's ok for now). Let's take a look at what will generate error messages:

* class <code>Homework</code> not declared
* <code>Homework</code> constructor not declared
* field <code>grades</code> not declared
* method <code>average</code> not declared

Now, we fix the first error:

<pre>
class Homework {

}
</pre>

Second error:

<pre>
Homework(void) {

}
</pre>

Third error:

<pre>
int * grades;
</pre>

Fourth error:

<pre>
int average(int * grades) {
return 0; // default return value
}
</pre>

Finally, the test compiles! The code now looks like this:

<pre>
class Homework {

int * grades;

Homework(void) {

}

int average(int * grades) {

return 0; // default return value

}

}
</pre>

===Red===
Now, we run the test, and the familar red bar of failure greets us (remember the mantra red-green-refactor). The assert fails. The average function needs to actually average something (not just return 0). As we think about averaging the grades, we realize we need to know how many grades are in the int array <code>grades</code>. So, we add to the code:

<pre>
class Homework {

int * grades;
int numGrades; // new

Homework(void) {

}

int average(int * grades) {

int avg = 0; // new

for(int i = 0; i < numGrades; i++) { // new
avg += grades[i]; // new
} // new

return avg/numGrades; // new

}

}
</pre>

Of course, we must remember to change the test to:

<pre>
myHomework = new Homework();
myHomework.grades = [100, 50];
myHomework.numGrades = 2;
assert(myHomework.average(myHomework.grades) == 75);
</pre>

===Green===
Success! We have a green bar when we run it.

===Refactor===
The last step is refactoring. Perhaps we don't want a grade to be an <code>int</code>? Should it be an <code>unsigned int</code>? For this simple example, there isn't much refactoring to do, but in a larger example there may be multiple areas for improvement.

==More Examples==
See Test-Driven Development by Example by Kent Beck for more examples.

=Characteristics of a good unit test=
*Automated testing: Automated system makes the testing much more easier and faster. Manual testing is slower and needs human interaction which is error-prone. Automated testing makes sure any particular test is not missing every time we test the system, whereas humans may leave a test out mistakenly during testing process.
*Better to test New/Modified Functionality: With manual testing whenever you add new functionality or modify existing functionality, QA personal needs to test all systems that may be affected due to the modification which may be time-consuming. This may also leave a hidden bug in the system after modification. With TDD whenever a new functionality is added or existing functionality is modified, the whole set of tests in the system is run to make sure existing tests are passed. This makes sure that existing functionality is not broken.
*Developer’s confidence: With TDD, developers are more safe to change the system as any inappropriate changes will make some tests to fail. With non-TDD system developers needs to take more care to change existing system as the new change may fail other functionality. But with TDD developers can do so easily as after modification if developer runs the test he/she will find immediately that the change has failed some other tests (i.e. some other part of the system).
*Manual testing stage is shortened: In non-TDD development, as soon as developers prepare a build, QA personal starts testing. This manual testing takes a reasonable amount of time and increases the time to deliver the product from the build time. With TDD, a major part of the system is tested during development and needs lesser QA involvement in the time between build and final delivery of the product.
*Alternative Documentation: Unit tests are kind of documentation to system. Each unit test tells about an individual requirement to the module or system. For example, the following test ensures that only a logged in user with proper balance can buy an item when the item exists in stock. This test reflects a user aspect scenario of the system.

public void CheckUserCanNotPurchaseItemWithoutBalance(){
LoginToTheSystem();
SelectAnItemToBuy();
MakeSureItemExsitsInStock();
MakeSureUserHasBalanceToBuy();
RunTheTransaction();
}
*Better way to fix bugs: In TDD approach when QA finds a bug, developer first writes a test that generates the bug (that is the test will fail due to this bug). Then developer modifies code to make sure that the test is passed (i.e., the bug is fixed). This approach makes sure that next time the bug will not appear in the system as a test is written in the system to take care of the bug.
*Repetition of the same bug reduced: With TDD once a bug is found, it's put under test. So every time you run the whole test in the system, the tests associated with the bug are run and make sure the bugs are not generated again.

=Conclusion=
Danielle
=References=
*[http://catalog.lib.ncsu.edu/record/NCSU1601963 Beck, K. (2002). Test-driven development by example. Addison-Wesley.]
*[http://en.wikipedia.org/wiki/Test_driven_development (n.d.). Test-driven development. website: http://en.wikipedia.org/wiki/Test_driven_development]
*[http://c2.com/cgi/wiki?TestDrivenDevelopment (2012, January 11). Test driven development. website: http://c2.com/cgi/wiki?TestDrivenDevelopment]
*[http://www.agiledata.org/essays/tdd.html Ambler, S. W. (2002). Introduction to test driven development (tdd). Retrieved from Agile Data website: http://www.agiledata.org/essays/tdd.html]
*http://www.testdriven.com/ ?