Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2012/ch2b 2w40 sn

2012-11-20T05:16:05Z

Npatowa: /* Further Reading */

= Introduction to Command Pattern =
The command pattern is one of the most used behavioral design patterns. The main concept of the pattern is an object which can be used to represent and encapsulate all the information needed to call a method at a later time. This information includes the method name, the object that owns the method and values for the method parameters.

The command pattern has been often associated with these terms client, invoker and receiver. The client instantiates the command object and provides the information required to call the method at a later time. The invoker decides when the method should be called. The receiver is an instance of the class that contains the method's code.

The intent of the Command pattern can be listed as:
#encapsulate a request in an object
# allows the parametrization of clients with different requests
# allows saving the requests in a queue
== A Java Example ==
[[File:Command.jpg]]

As the figure above suggests the integral parts of the command pattern are the client,invoker and the receiver.The command part is split into two parts-the interface and the concrete command. The examples are explored more in the below example.
This is the command interface which contains the skeleton code of the command pattern containing exactly one method called execute.
<pre>
//Command
public interface Command
{
public void execute();
}
</pre>
<pre>
//Concrete Command
public class LightOnCommand implements Command
{
//reference to the light
Light light;

public LightOnCommand(Light light)
{
this.light = light;
}

public void execute()
{
light.switchOn();
}

}

</pre>
<pre>
//Concrete Command
public class LightOffCommand implementsCommand
{
//reference to the light
Light light;

public LightOffCommand(Light light)
{
this.light = light;
}

public void execute()
{
light.switchOff();
}

}

</pre>
LightOnCommand and LightOffCommand represents the concrete command classes that the client shall use.

Light is the receiver class which contains the commands to be executed.
<pre>
//Receiver
public class Light
{
private boolean on;

public void switchOn()
{
on = true;
}

public void switchOff()
{
on = false;
}

}
</pre>
The invoker is the one which actually which calls the execute method of the command class. This also has a accessor method which sets the current command to be executed.
<pre>
//Invoker
public class RemoteControl
{
private Command command;

public void setCommand(Command command)
{
this.command = command;
}

public void pressButton()
{
command.execute();
}

}
</pre>
And finally there is the Client class which will use the commands to switch the lights on and off.
<pre>
//Client
public class Client
{
public static void main(String[] args)
{
RemoteControl control = new RemoteControl();

Light light = new Light();

Command lightsOn = new LightsOnCommand(light);
Command lightsOff = new LightsOffCommand(light);

//switch on
control.setCommand(lightsOn);
control.pressButton();

//switch off
control.setCommand(lightsOff);
control.pressButton();

}

}
</pre>

== Real life applications ==
The command pattern can be used when the following things are desired:
# Specify,queue and execute requests at different times.
# To support operations like '''Undo''','''Redo'''.
# Support Logging changes so that they can be reapplied in case of a system crash.If the command interface is extended to include the load and store operations, a persistent history of changes can be kept.
# These can also be applied to transactions. They have a common interface so all the transactions can be invoked in the same way. It is also helpful to rollback transaction if something goes wrong.
# It is also used for implementing GUI objects. In addition to the ability to perform the desired command, an Action may have an associated icon, keyboard shortcut, tooltip text, and so on.
For an additional list of applications users can read this <ref>http://en.wikipedia.org/wiki/Command_pattern</ref>.

= Chain of Responsibility =
Chain-of-responsibility pattern is another behavioral design pattern consisting of a source of command objects and a series of processing objects. Processing objects contain logic that defines the types of command objects that it can handle; the rest are passed to the next processing object in the chain. The basic intent of this pattern is to chain the receiving objects and pass the request along the chain until an object handles it.
This pattern promotes decoupling between senders and receivers by giving multiple objects a chance to handle a request. The request gets passed along a chain of objects until one of them handles it. More information can be handled from here <ref>http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern</ref>.
== Example of Chain of Responsibility ==
[[File:COR.jpg]]

The above figure helps to understand the workings of Chain of Responsibility pattern.The example given in <ref>http://javapapers.com/design-patterns/chain-of-responsibility-design-pattern/</ref> has been described below.

<pre>
//Interface
public interface Chain {

public abstract void setNext(Chain nextInChain);
public abstract void process(Number request);
}
</pre>
<pre>
//Receiver
public class Number {
private int number;

public Number(int number) {
this.number = number;
}

public int getNumber() {
return number;
}

}
</pre>
<pre>
//Concrete Handler1
public class NegativeProcessor implements Chain {

private Chain nextInChain;

public void setNext(Chain c) {
nextInChain = c;
}

public void process(Number request) {
if (request.getNumber() < 0) {
System.out.println("NegativeProcessor : " + request.getNumber());
} else {
nextInChain.process(request);
}
}
}
</pre>
<pre>
//Concrete Handler2
public class ZeroProcessor implements Chain {

private Chain nextInChain;

public void setNext(Chain c) {
nextInChain = c;
}

public void process(Number request) {
if (request.getNumber() == 0) {
System.out.println("ZeroProcessor : " + request.getNumber());
} else {
nextInChain.process(request);
}
}
}
</pre>
<pre>
//Concrete Handler3
public class PositiveProcessor implements Chain {

private Chain nextInChain;

public void setNext(Chain c) {
nextInChain = c;
}

public void process(Number request) {
if (request.getNumber() > 0) {
System.out.println("PositiveProcessor : " + request.getNumber());
} else {
nextInChain.process(request);
}
}
}
</pre>
<pre>
//Client
public class TestChain {
public static void main(String[] args) {
//configure Chain of Responsibility
Chain c1 = new NegativeProcessor();
Chain c2 = new ZeroProcessor();
Chain c3 = new PositiveProcessor();
c1.setNext(c2);
c2.setNext(c3);

//calling chain of responsibility
c1.process(new Number(99));
c1.process(new Number(-30));
c1.process(new Number(0));
c1.process(new Number(100));
}
}
</pre>
In the above example the Chain interface is implemented by three handlers which handles 3 different types of numbers-positive numbers,negative numbers and the number zero. The first in the chain is the negative number handler which sets the next handler as the zero handler which in turn sets the positive handler as the last component in the chain.The Number class acts as the receiver which has been explained in the Command pattern.The TestChain is the client.
== Comparison with Command Pattern ==
# Both in Command and Chain of Responsibility pattern commands or actions are stored so that it can be later used.
# The Chain of Responsibility forwards requests along a chain of classes, but the Command pattern forwards a request only to a specific object.
# The main intent of both the patterns is to decouple senders and receivers.In case of Command pattern that is only one.
== Real life applications ==
Chain of Responsibility is used in many applications:
# It is used often to handle exceptions inside kernel.There will be a chain of interrupt handlers and the request is passed on until somebody handles it.
# The pattern is used in windows systems to handle events generated from the keyboard or mouse.
# Single sign on security solutions for web applications. You might have a handler to check if the user is already authenticated, another handler to check for windows authentication, and a last handler to transfer the request to a logon page<ref>http://codebetter.com/jeremymiller/2005/11/07/using-the-chain-of-responsibility-pattern/</ref>.

= Memento =
The memento pattern is a software design pattern that facilitates the restoration an object to its previous state. The memento pattern has three different components:<ref>http://www.colourcoding.net/blog/archive/2009/07/23/reversibility-patterns-memento-and-command.aspx</ref>
# Originator - the object that has an internal state and knows to save itself.
# Caretaker - the object that knows why and when the Originator needs to save and restore itself.
# Memento - the object (token) that is written and read by the Originator, and taken care by the Caretaker.

The communication between different components in memento pattern happens in the following way:
The caretaker first asks the originator for a memento object. Then it does the work it was slated to do. To roll back to the state before the operations, it returns the memento object to the originator. The memento object itself is an opaque object (one which the caretaker cannot change). When using this pattern, care should be taken if the originator may change other objects or resources - the memento pattern operates on a single object.In other words, the memento pattern can be viewed as maintaining a "checkpoint" so that the originator can easily rollback to the previous checkpoint.<ref>http://sourcemaking.com/design_patterns/memento</ref>

The following diagram illustrates the memento pattern:<br/>
[[File:Memento.jpg]]

== Example of Memento Pattern ==

The following program illustrates the "undo" usage of the Memento Pattern <ref>http://en.wikipedia.org/wiki/Memento_pattern</ref>.

<pre>
import java.util.List;
import java.util.ArrayList;
class Originator {
private String state;
// The class could also contain additional data that is not part of the
// state saved in the memento.

public void set(String state) {
System.out.println("Originator: Setting state to " + state);
this.state = state;
}

public Memento saveToMemento() {
System.out.println("Originator: Saving to Memento.");
return new Memento(state);
}

public void restoreFromMemento(Memento memento) {
state = memento.getSavedState();
System.out.println("Originator: State after restoring from Memento: " + state);
}

public static class Memento {
private final String state;

public Memento(String stateToSave) {
state = stateToSave;
}

public String getSavedState() {
return state;
}
}
}

class Caretaker {
public static void main(String[] args) {
List<Originator.Memento> savedStates = new ArrayList<Originator.Memento>();

Originator originator = new Originator();
originator.set("State1");
originator.set("State2");
savedStates.add(originator.saveToMemento());
originator.set("State3");
// We can request multiple mementos, and choose which one to roll back to.
savedStates.add(originator.saveToMemento());
originator.set("State4");

originator.restoreFromMemento(savedStates.get(1));
}
}
</pre>

The output is:
Originator: Setting state to State1
Originator: Setting state to State2
Originator: Saving to Memento.
Originator: Setting state to State3
Originator: Saving to Memento.
Originator: Setting state to State4
Originator: State after restoring from Memento: State3

== Comparison with Command Pattern ==

#The similarity between Command and Memento act as magic tokens to be passed around and invoked at a later time. In Command, the token represents a request; in Memento, it represents the internal state of an object at a particular time.
#Polymorphism is important to Command, but not to Memento because its interface is so narrow that a memento can only be passed as a value.
#Command can use Memento to maintain the state required for an undo operation.
#In practice, the Memento pattern is a little brittle. Changes in the behavior of related objects could lead to changes in what has to be stored. However since command pattern separates out the responsibility for reversibility into the relevant transitions, it proves to be less brittle. Furthermore, command objects can be extended in further directions, taking in permissions, interruptibility, batching, to name but a few.

== Real life applications ==
The following are the applications where memento pattern can be used:
#An interesting game in which memento pattern can be used is Prince of Persia: Sands of Time. In the game, you can hit a button that reverses time. By storing the state of every actor in recent frames, it can just as easily rewind them.
# Another simple application where memento pattern can be used is a calculator that finds the result of addition of two numbers, with the additional option to undo last operation and restore previous result.
# Memento pattern is useful when you need to find the seed of a pseudo random number generator and the state in a finite state machine.

In all the above applications the "undo" feature is common. Hence, An unlimited “undo” and “redo” capability can be readily implemented with a stack of Command objects and a stack of Memento objects.

= Strategy =
The unofficially accepted definition for the Strategy Pattern is: ''"Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it."''<ref>http://en.wikipedia.org/wiki/Strategy_pattern</ref>. In other words, the Strategy Pattern encapsulates a collection of functions that do more or less similar tasks but not identical tasks. Strategy pattern is used when we need to take a decision of which strategy to use based on the input parameters. An important feature of strategy pattern is that client is aware of all the available strategies and which strategy to adopt. It helps is design a system that is elegant, extensible, and powerful. The following diagram illustrates the strategy pattern: <br/>
[[File:Strategy.jpg]]

== Example ==
The following example is in Java.<ref>http://en.wikipedia.org/wiki/Strategy_pattern]</ref>
<pre>
// The classes that implement a concrete strategy should implement this.
// The Context class uses this to call the concrete strategy.
interface IStrategy {
int execute(int a, int b);
}

// Implements the algorithm using the strategy interface
class ConcreteStrategyAdd implements IStrategy {

public int execute(int a, int b) {
System.out.println("Called ConcreteStrategyAdd's execute()");
return a + b; // Do an addition with a and b
}
}

class ConcreteStrategySubtract implements IStrategy {

public int execute(int a, int b) {
System.out.println("Called ConcreteStrategySubtract's execute()");
return a - b; // Do a subtraction with a and b
}
}

class ConcreteStrategyMultiply implements IStrategy {

public int execute(int a, int b) {
System.out.println("Called ConcreteStrategyMultiply's execute()");
return a * b; // Do a multiplication with a and b
}
}

// Configured with a ConcreteStrategy object and maintains a reference to a Strategy object
class Context {

private IStrategy strategy;

// Constructor
public Context(IStrategy strategy) {
this.strategy = strategy;
}

public int executeStrategy(int a, int b) {
return strategy.execute(a, b);
}
}

// Test application
class StrategyExample {

public static void main(String[] args) {

Context context;

// Three contexts following different strategies
context = new Context(new ConcreteStrategyAdd());
int resultA = context.executeStrategy(3,4);

context = new Context(new ConcreteStrategySubtract());
int resultB = context.executeStrategy(3,4);

context = new Context(new ConcreteStrategyMultiply());
int resultC = context.executeStrategy(3,4);

System.out.println("Result A : " + resultA );
System.out.println("Result B : " + resultB );
System.out.println("Result C : " + resultC );
}
}
</pre>

== Comparison with Command Pattern ==
The difference between Strategy Pattern and Command pattern is in the purpose itself:
#Command encapsulates a single action. It therefore tends to have a single method with a rather generic signature. It often is intended to be stored for a longer time and to be executed later - or it is used to provide undo functionality as explained in the Command pattern section.Strategy, in contrast, is used to customize an algorithm. A strategy might have a number of methods specific to the algorithm. Most often strategies will be instantiated immediately before executing the algorithm, and discarded later.
#Strategies encapsulate algorithms. Commands separate the sender from the receiver of a request, they turn a request into an object. If it's an algorithm, how something will be done, use a Strategy. If you need to separate the call of a method from its execution use a Command.

== Real life applications ==
The applications where strategy pattern is useful are as follows:
#Strategy pattern is used in an system where we try to book the most inexpensive ticket from source to destination. Depending on the users preference of seats, time of transit and other preferences the system chooses the algorithm that will cater to all the user needs at an optimum fare.
#Strategy pattern can be used when we have to sort numbers. Depending on the type of input, we can make use of the best algorithm. For example, if we know that the numbers are almost sorted then we make use of insertion sort. If the numbers to be sorted are within a range, then we make use of counting sort. If the input sequence is random then our best bet is to use merge sort.
# A strategy pattern can be used when we want to read a file that has been transferred over a network. If the file is an XML File then use an XML parsing algorithm. If it is JSON file then use a JSON parser and so on.

= Conclusion =
Thus, we see that Command Pattern is quite useful. The Chain of Responsibility, Memento ad Strategy pattern adopt the concept of Command patterns and have their own variations which make them useful in different scenarios as mentioned in each of the sections. The main advantage of the command design pattern is that it decouples the object that invokes the operation from the one that knows how to perform it. The major disadvantage of the pattern is that it results in many Command classes that can clutter up a design. If the classes are not designed properly it may lead to bloating of the design and will increase the cost of maintaining such a design.

=References=
<references/>
== Further Reading ==
[http://www.oodesign.com/command-pattern.html]http://www.oodesign.com/command-pattern.html
[http://www.go4expert.com/forums/showthread.php?t=5127#command]http://www.go4expert.com/forums/showthread.php?t=5127#command
[http://www.mydeveloperconnection.com/html/gof_design_patterns.htm]http://www.mydeveloperconnection.com/html/gof_design_patterns.htm
[http://java.dzone.com/articles/design-patterns-command]http://java.dzone.com/articles/design-patterns-command

CSC/ECE 517 Fall 2012/ch2b 2w40 sn

2012-11-20T05:14:22Z

Npatowa:

= Introduction to Command Pattern =
The command pattern is one of the most used behavioral design patterns. The main concept of the pattern is an object which can be used to represent and encapsulate all the information needed to call a method at a later time. This information includes the method name, the object that owns the method and values for the method parameters.

The command pattern has been often associated with these terms client, invoker and receiver. The client instantiates the command object and provides the information required to call the method at a later time. The invoker decides when the method should be called. The receiver is an instance of the class that contains the method's code.

The intent of the Command pattern can be listed as:
#encapsulate a request in an object
# allows the parametrization of clients with different requests
# allows saving the requests in a queue
== A Java Example ==
[[File:Command.jpg]]

As the figure above suggests the integral parts of the command pattern are the client,invoker and the receiver.The command part is split into two parts-the interface and the concrete command. The examples are explored more in the below example.
This is the command interface which contains the skeleton code of the command pattern containing exactly one method called execute.
<pre>
//Command
public interface Command
{
public void execute();
}
</pre>
<pre>
//Concrete Command
public class LightOnCommand implements Command
{
//reference to the light
Light light;

public LightOnCommand(Light light)
{
this.light = light;
}

public void execute()
{
light.switchOn();
}

}

</pre>
<pre>
//Concrete Command
public class LightOffCommand implementsCommand
{
//reference to the light
Light light;

public LightOffCommand(Light light)
{
this.light = light;
}

public void execute()
{
light.switchOff();
}

}

</pre>
LightOnCommand and LightOffCommand represents the concrete command classes that the client shall use.

Light is the receiver class which contains the commands to be executed.
<pre>
//Receiver
public class Light
{
private boolean on;

public void switchOn()
{
on = true;
}

public void switchOff()
{
on = false;
}

}
</pre>
The invoker is the one which actually which calls the execute method of the command class. This also has a accessor method which sets the current command to be executed.
<pre>
//Invoker
public class RemoteControl
{
private Command command;

public void setCommand(Command command)
{
this.command = command;
}

public void pressButton()
{
command.execute();
}

}
</pre>
And finally there is the Client class which will use the commands to switch the lights on and off.
<pre>
//Client
public class Client
{
public static void main(String[] args)
{
RemoteControl control = new RemoteControl();

Light light = new Light();

Command lightsOn = new LightsOnCommand(light);
Command lightsOff = new LightsOffCommand(light);

//switch on
control.setCommand(lightsOn);
control.pressButton();

//switch off
control.setCommand(lightsOff);
control.pressButton();

}

}
</pre>

== Real life applications ==
The command pattern can be used when the following things are desired:
# Specify,queue and execute requests at different times.
# To support operations like '''Undo''','''Redo'''.
# Support Logging changes so that they can be reapplied in case of a system crash.If the command interface is extended to include the load and store operations, a persistent history of changes can be kept.
# These can also be applied to transactions. They have a common interface so all the transactions can be invoked in the same way. It is also helpful to rollback transaction if something goes wrong.
# It is also used for implementing GUI objects. In addition to the ability to perform the desired command, an Action may have an associated icon, keyboard shortcut, tooltip text, and so on.
For an additional list of applications users can read this <ref>http://en.wikipedia.org/wiki/Command_pattern</ref>.

= Chain of Responsibility =
Chain-of-responsibility pattern is another behavioral design pattern consisting of a source of command objects and a series of processing objects. Processing objects contain logic that defines the types of command objects that it can handle; the rest are passed to the next processing object in the chain. The basic intent of this pattern is to chain the receiving objects and pass the request along the chain until an object handles it.
This pattern promotes decoupling between senders and receivers by giving multiple objects a chance to handle a request. The request gets passed along a chain of objects until one of them handles it. More information can be handled from here <ref>http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern</ref>.
== Example of Chain of Responsibility ==
[[File:COR.jpg]]

The above figure helps to understand the workings of Chain of Responsibility pattern.The example given in <ref>http://javapapers.com/design-patterns/chain-of-responsibility-design-pattern/</ref> has been described below.

<pre>
//Interface
public interface Chain {

public abstract void setNext(Chain nextInChain);
public abstract void process(Number request);
}
</pre>
<pre>
//Receiver
public class Number {
private int number;

public Number(int number) {
this.number = number;
}

public int getNumber() {
return number;
}

}
</pre>
<pre>
//Concrete Handler1
public class NegativeProcessor implements Chain {

private Chain nextInChain;

public void setNext(Chain c) {
nextInChain = c;
}

public void process(Number request) {
if (request.getNumber() < 0) {
System.out.println("NegativeProcessor : " + request.getNumber());
} else {
nextInChain.process(request);
}
}
}
</pre>
<pre>
//Concrete Handler2
public class ZeroProcessor implements Chain {

private Chain nextInChain;

public void setNext(Chain c) {
nextInChain = c;
}

public void process(Number request) {
if (request.getNumber() == 0) {
System.out.println("ZeroProcessor : " + request.getNumber());
} else {
nextInChain.process(request);
}
}
}
</pre>
<pre>
//Concrete Handler3
public class PositiveProcessor implements Chain {

private Chain nextInChain;

public void setNext(Chain c) {
nextInChain = c;
}

public void process(Number request) {
if (request.getNumber() > 0) {
System.out.println("PositiveProcessor : " + request.getNumber());
} else {
nextInChain.process(request);
}
}
}
</pre>
<pre>
//Client
public class TestChain {
public static void main(String[] args) {
//configure Chain of Responsibility
Chain c1 = new NegativeProcessor();
Chain c2 = new ZeroProcessor();
Chain c3 = new PositiveProcessor();
c1.setNext(c2);
c2.setNext(c3);

//calling chain of responsibility
c1.process(new Number(99));
c1.process(new Number(-30));
c1.process(new Number(0));
c1.process(new Number(100));
}
}
</pre>
In the above example the Chain interface is implemented by three handlers which handles 3 different types of numbers-positive numbers,negative numbers and the number zero. The first in the chain is the negative number handler which sets the next handler as the zero handler which in turn sets the positive handler as the last component in the chain.The Number class acts as the receiver which has been explained in the Command pattern.The TestChain is the client.
== Comparison with Command Pattern ==
# Both in Command and Chain of Responsibility pattern commands or actions are stored so that it can be later used.
# The Chain of Responsibility forwards requests along a chain of classes, but the Command pattern forwards a request only to a specific object.
# The main intent of both the patterns is to decouple senders and receivers.In case of Command pattern that is only one.
== Real life applications ==
Chain of Responsibility is used in many applications:
# It is used often to handle exceptions inside kernel.There will be a chain of interrupt handlers and the request is passed on until somebody handles it.
# The pattern is used in windows systems to handle events generated from the keyboard or mouse.
# Single sign on security solutions for web applications. You might have a handler to check if the user is already authenticated, another handler to check for windows authentication, and a last handler to transfer the request to a logon page<ref>http://codebetter.com/jeremymiller/2005/11/07/using-the-chain-of-responsibility-pattern/</ref>.

= Memento =
The memento pattern is a software design pattern that facilitates the restoration an object to its previous state. The memento pattern has three different components:<ref>http://www.colourcoding.net/blog/archive/2009/07/23/reversibility-patterns-memento-and-command.aspx</ref>
# Originator - the object that has an internal state and knows to save itself.
# Caretaker - the object that knows why and when the Originator needs to save and restore itself.
# Memento - the object (token) that is written and read by the Originator, and taken care by the Caretaker.

The communication between different components in memento pattern happens in the following way:
The caretaker first asks the originator for a memento object. Then it does the work it was slated to do. To roll back to the state before the operations, it returns the memento object to the originator. The memento object itself is an opaque object (one which the caretaker cannot change). When using this pattern, care should be taken if the originator may change other objects or resources - the memento pattern operates on a single object.In other words, the memento pattern can be viewed as maintaining a "checkpoint" so that the originator can easily rollback to the previous checkpoint.<ref>http://sourcemaking.com/design_patterns/memento</ref>

The following diagram illustrates the memento pattern:<br/>
[[File:Memento.jpg]]

== Example of Memento Pattern ==

The following program illustrates the "undo" usage of the Memento Pattern <ref>http://en.wikipedia.org/wiki/Memento_pattern</ref>.

<pre>
import java.util.List;
import java.util.ArrayList;
class Originator {
private String state;
// The class could also contain additional data that is not part of the
// state saved in the memento.

public void set(String state) {
System.out.println("Originator: Setting state to " + state);
this.state = state;
}

public Memento saveToMemento() {
System.out.println("Originator: Saving to Memento.");
return new Memento(state);
}

public void restoreFromMemento(Memento memento) {
state = memento.getSavedState();
System.out.println("Originator: State after restoring from Memento: " + state);
}

public static class Memento {
private final String state;

public Memento(String stateToSave) {
state = stateToSave;
}

public String getSavedState() {
return state;
}
}
}

class Caretaker {
public static void main(String[] args) {
List<Originator.Memento> savedStates = new ArrayList<Originator.Memento>();

Originator originator = new Originator();
originator.set("State1");
originator.set("State2");
savedStates.add(originator.saveToMemento());
originator.set("State3");
// We can request multiple mementos, and choose which one to roll back to.
savedStates.add(originator.saveToMemento());
originator.set("State4");

originator.restoreFromMemento(savedStates.get(1));
}
}
</pre>

The output is:
Originator: Setting state to State1
Originator: Setting state to State2
Originator: Saving to Memento.
Originator: Setting state to State3
Originator: Saving to Memento.
Originator: Setting state to State4
Originator: State after restoring from Memento: State3

== Comparison with Command Pattern ==

#The similarity between Command and Memento act as magic tokens to be passed around and invoked at a later time. In Command, the token represents a request; in Memento, it represents the internal state of an object at a particular time.
#Polymorphism is important to Command, but not to Memento because its interface is so narrow that a memento can only be passed as a value.
#Command can use Memento to maintain the state required for an undo operation.
#In practice, the Memento pattern is a little brittle. Changes in the behavior of related objects could lead to changes in what has to be stored. However since command pattern separates out the responsibility for reversibility into the relevant transitions, it proves to be less brittle. Furthermore, command objects can be extended in further directions, taking in permissions, interruptibility, batching, to name but a few.

== Real life applications ==
The following are the applications where memento pattern can be used:
#An interesting game in which memento pattern can be used is Prince of Persia: Sands of Time. In the game, you can hit a button that reverses time. By storing the state of every actor in recent frames, it can just as easily rewind them.
# Another simple application where memento pattern can be used is a calculator that finds the result of addition of two numbers, with the additional option to undo last operation and restore previous result.
# Memento pattern is useful when you need to find the seed of a pseudo random number generator and the state in a finite state machine.

In all the above applications the "undo" feature is common. Hence, An unlimited “undo” and “redo” capability can be readily implemented with a stack of Command objects and a stack of Memento objects.

= Strategy =
The unofficially accepted definition for the Strategy Pattern is: ''"Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it."''<ref>http://en.wikipedia.org/wiki/Strategy_pattern</ref>. In other words, the Strategy Pattern encapsulates a collection of functions that do more or less similar tasks but not identical tasks. Strategy pattern is used when we need to take a decision of which strategy to use based on the input parameters. An important feature of strategy pattern is that client is aware of all the available strategies and which strategy to adopt. It helps is design a system that is elegant, extensible, and powerful. The following diagram illustrates the strategy pattern: <br/>
[[File:Strategy.jpg]]

== Example ==
The following example is in Java.<ref>http://en.wikipedia.org/wiki/Strategy_pattern]</ref>
<pre>
// The classes that implement a concrete strategy should implement this.
// The Context class uses this to call the concrete strategy.
interface IStrategy {
int execute(int a, int b);
}

// Implements the algorithm using the strategy interface
class ConcreteStrategyAdd implements IStrategy {

public int execute(int a, int b) {
System.out.println("Called ConcreteStrategyAdd's execute()");
return a + b; // Do an addition with a and b
}
}

class ConcreteStrategySubtract implements IStrategy {

public int execute(int a, int b) {
System.out.println("Called ConcreteStrategySubtract's execute()");
return a - b; // Do a subtraction with a and b
}
}

class ConcreteStrategyMultiply implements IStrategy {

public int execute(int a, int b) {
System.out.println("Called ConcreteStrategyMultiply's execute()");
return a * b; // Do a multiplication with a and b
}
}

// Configured with a ConcreteStrategy object and maintains a reference to a Strategy object
class Context {

private IStrategy strategy;

// Constructor
public Context(IStrategy strategy) {
this.strategy = strategy;
}

public int executeStrategy(int a, int b) {
return strategy.execute(a, b);
}
}

// Test application
class StrategyExample {

public static void main(String[] args) {

Context context;

// Three contexts following different strategies
context = new Context(new ConcreteStrategyAdd());
int resultA = context.executeStrategy(3,4);

context = new Context(new ConcreteStrategySubtract());
int resultB = context.executeStrategy(3,4);

context = new Context(new ConcreteStrategyMultiply());
int resultC = context.executeStrategy(3,4);

System.out.println("Result A : " + resultA );
System.out.println("Result B : " + resultB );
System.out.println("Result C : " + resultC );
}
}
</pre>

== Comparison with Command Pattern ==
The difference between Strategy Pattern and Command pattern is in the purpose itself:
#Command encapsulates a single action. It therefore tends to have a single method with a rather generic signature. It often is intended to be stored for a longer time and to be executed later - or it is used to provide undo functionality as explained in the Command pattern section.Strategy, in contrast, is used to customize an algorithm. A strategy might have a number of methods specific to the algorithm. Most often strategies will be instantiated immediately before executing the algorithm, and discarded later.
#Strategies encapsulate algorithms. Commands separate the sender from the receiver of a request, they turn a request into an object. If it's an algorithm, how something will be done, use a Strategy. If you need to separate the call of a method from its execution use a Command.

== Real life applications ==
The applications where strategy pattern is useful are as follows:
#Strategy pattern is used in an system where we try to book the most inexpensive ticket from source to destination. Depending on the users preference of seats, time of transit and other preferences the system chooses the algorithm that will cater to all the user needs at an optimum fare.
#Strategy pattern can be used when we have to sort numbers. Depending on the type of input, we can make use of the best algorithm. For example, if we know that the numbers are almost sorted then we make use of insertion sort. If the numbers to be sorted are within a range, then we make use of counting sort. If the input sequence is random then our best bet is to use merge sort.
# A strategy pattern can be used when we want to read a file that has been transferred over a network. If the file is an XML File then use an XML parsing algorithm. If it is JSON file then use a JSON parser and so on.

= Conclusion =
Thus, we see that Command Pattern is quite useful. The Chain of Responsibility, Memento ad Strategy pattern adopt the concept of Command patterns and have their own variations which make them useful in different scenarios as mentioned in each of the sections. The main advantage of the command design pattern is that it decouples the object that invokes the operation from the one that knows how to perform it. The major disadvantage of the pattern is that it results in many Command classes that can clutter up a design. If the classes are not designed properly it may lead to bloating of the design and will increase the cost of maintaining such a design.

=References=
<references/>
== Further Reading ==
# [http://www.oodesign.com/command-pattern.html]
# [http://www.go4expert.com/forums/showthread.php?t=5127#command]
# [http://www.mydeveloperconnection.com/html/gof_design_patterns.htm]
# [http://java.dzone.com/articles/design-patterns-command]

CSC/ECE 517 Fall 2012/ch2b 2w40 sn

2012-11-20T04:48:44Z

Npatowa:

CSC/ECE 517 Fall 2012/ch2b 2w40 sn

2012-11-20T04:45:46Z

Npatowa:

= Introduction to Command Pattern =
The command pattern is one of the most used behavioral design patterns. The main concept of the pattern is an object which can be used to represent and encapsulate all the information needed to call a method at a later time. This information includes the method name, the object that owns the method and values for the method parameters.

The command pattern has been often associated with these terms client, invoker and receiver. The client instantiates the command object and provides the information required to call the method at a later time. The invoker decides when the method should be called. The receiver is an instance of the class that contains the method's code.

The intent of the Command pattern can be listed as:
#encapsulate a request in an object
# allows the parametrization of clients with different requests
# allows saving the requests in a queue
== A Java Example ==
[[File:Command.jpg]]

As the figure above suggests the integral parts of the command pattern are the client,invoker and the receiver.The command part is split into two parts-the interface and the concrete command. The examples are explored more in the below example.
This is the command interface which contains the skeleton code of the command pattern containing exactly one method called execute.
<pre>
//Command
public interface Command
{
public void execute();
}
</pre>
<pre>
//Concrete Command
public class LightOnCommand implements Command
{
//reference to the light
Light light;

public LightOnCommand(Light light)
{
this.light = light;
}

public void execute()
{
light.switchOn();
}

}

</pre>
<pre>
//Concrete Command
public class LightOffCommand implementsCommand
{
//reference to the light
Light light;

public LightOffCommand(Light light)
{
this.light = light;
}

public void execute()
{
light.switchOff();
}

}

</pre>
LightOnCommand and LightOffCommand represents the concrete command classes that the client shall use.

Light is the receiver class which contains the commands to be executed.
<pre>
//Receiver
public class Light
{
private boolean on;

public void switchOn()
{
on = true;
}

public void switchOff()
{
on = false;
}

}
</pre>
The invoker is the one which actually which calls the execute method of the command class. This also has a accessor method which sets the current command to be executed.
<pre>
//Invoker
public class RemoteControl
{
private Command command;

public void setCommand(Command command)
{
this.command = command;
}

public void pressButton()
{
command.execute();
}

}
</pre>
And finally there is the Client class which will use the commands to switch the lights on and off.
<pre>
//Client
public class Client
{
public static void main(String[] args)
{
RemoteControl control = new RemoteControl();

Light light = new Light();

Command lightsOn = new LightsOnCommand(light);
Command lightsOff = new LightsOffCommand(light);

//switch on
control.setCommand(lightsOn);
control.pressButton();

//switch off
control.setCommand(lightsOff);
control.pressButton();

}

}
</pre>

== Real life applications ==
The command pattern can be used when the following things are desired:
# Specify,queue and execute requests at different times.
# To support operations like '''Undo''','''Redo'''.
# Support Logging changes so that they can be reapplied in case of a system crash.If the command interface is extended to include the load and store operations, a persistent history of changes can be kept.
# These can also be applied to transactions. They have a common interface so all the transactions can be invoked in the same way. It is also helpful to rollback transaction if something goes wrong.
# It is also used for implementing GUI objects. In addition to the ability to perform the desired command, an Action may have an associated icon, keyboard shortcut, tooltip text, and so on.
For an additional list of applications users can read this [http://en.wikipedia.org/wiki/Command_pattern].

= Chain of Responsibility =
Chain-of-responsibility pattern is another behavioral design pattern consisting of a source of command objects and a series of processing objects. Processing objects contain logic that defines the types of command objects that it can handle; the rest are passed to the next processing object in the chain. The basic intent of this pattern is to chain the receiving objects and pass the request along the chain until an object handles it.
This pattern promotes decoupling between senders and receivers by giving multiple objects a chance to handle a request. The request gets passed along a chain of objects until one of them handles it. More information can be handled from here [http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern].
== Example of Chain of Responsibility ==
[[File:COR.jpg]]

The above figure helps to understand the workings of Chain of Responsibility pattern.The example given in [http://javapapers.com/design-patterns/chain-of-responsibility-design-pattern/] has been described below.

<pre>
//Interface
public interface Chain {

public abstract void setNext(Chain nextInChain);
public abstract void process(Number request);
}
</pre>
<pre>
//Receiver
public class Number {
private int number;

public Number(int number) {
this.number = number;
}

public int getNumber() {
return number;
}

}
</pre>
<pre>
//Concrete Handler1
public class NegativeProcessor implements Chain {

private Chain nextInChain;

public void setNext(Chain c) {
nextInChain = c;
}

public void process(Number request) {
if (request.getNumber() < 0) {
System.out.println("NegativeProcessor : " + request.getNumber());
} else {
nextInChain.process(request);
}
}
}
</pre>
<pre>
//Concrete Handler2
public class ZeroProcessor implements Chain {

private Chain nextInChain;

public void setNext(Chain c) {
nextInChain = c;
}

public void process(Number request) {
if (request.getNumber() == 0) {
System.out.println("ZeroProcessor : " + request.getNumber());
} else {
nextInChain.process(request);
}
}
}
</pre>
<pre>
//Concrete Handler3
public class PositiveProcessor implements Chain {

private Chain nextInChain;

public void setNext(Chain c) {
nextInChain = c;
}

public void process(Number request) {
if (request.getNumber() > 0) {
System.out.println("PositiveProcessor : " + request.getNumber());
} else {
nextInChain.process(request);
}
}
}
</pre>
<pre>
//Client
public class TestChain {
public static void main(String[] args) {
//configure Chain of Responsibility
Chain c1 = new NegativeProcessor();
Chain c2 = new ZeroProcessor();
Chain c3 = new PositiveProcessor();
c1.setNext(c2);
c2.setNext(c3);

//calling chain of responsibility
c1.process(new Number(99));
c1.process(new Number(-30));
c1.process(new Number(0));
c1.process(new Number(100));
}
}
</pre>
In the above example the Chain interface is implemented by three handlers which handles 3 different types of numbers-positive numbers,negative numbers and the number zero. The first in the chain is the negative number handler which sets the next handler as the zero handler which in turn sets the positive handler as the last component in the chain.The Number class acts as the receiver which has been explained in the Command pattern.The TestChain is the client.
== Comparison with Command Pattern ==
# Both in Command and Chain of Responsibility pattern commands or actions are stored so that it can be later used.
# The Chain of Responsibility forwards requests along a chain of classes, but the Command pattern forwards a request only to a specific object.
# The main intent of both the patterns is to decouple senders and receivers.In case of Command pattern that is only one.
== Real life applications ==
Chain of Responsibility is used in many applications:
# It is used often to handle exceptions inside kernel.There will be a chain of interrupt handlers and the request is passed on until somebody handles it.
# The pattern is used in windows systems to handle events generated from the keyboard or mouse.
# Single sign on security solutions for web applications. You might have a handler to check if the user is already authenticated, another handler to check for windows authentication, and a last handler to transfer the request to a logon page[http://codebetter.com/jeremymiller/2005/11/07/using-the-chain-of-responsibility-pattern/].

= Memento =
The memento pattern is a software design pattern that facilitates the restoration an object to its previous state. The memento pattern has three different components:[http://www.colourcoding.net/blog/archive/2009/07/23/reversibility-patterns-memento-and-command.aspx]
# Originator - the object that has an internal state and knows to save itself.
# Caretaker - the object that knows why and when the Originator needs to save and restore itself.
# Memento - the object (token) that is written and read by the Originator, and taken care by the Caretaker.

The communication between different components in memento pattern happens in the following way:
The caretaker first asks the originator for a memento object. Then it does the work it was slated to do. To roll back to the state before the operations, it returns the memento object to the originator. The memento object itself is an opaque object (one which the caretaker cannot change). When using this pattern, care should be taken if the originator may change other objects or resources - the memento pattern operates on a single object.In other words, the memento pattern can be viewed as maintaining a "checkpoint" so that the originator can easily rollback to the previous checkpoint.[http://sourcemaking.com/design_patterns/memento]

The following diagram illustrates the memento pattern:<br/>
[[File:Memento.jpg]]

== Example of Memento Pattern ==

The following program illustrates the "undo" usage of the Memento Pattern [http://en.wikipedia.org/wiki/Memento_pattern].

<pre>
import java.util.List;
import java.util.ArrayList;
class Originator {
private String state;
// The class could also contain additional data that is not part of the
// state saved in the memento.

public void set(String state) {
System.out.println("Originator: Setting state to " + state);
this.state = state;
}

public Memento saveToMemento() {
System.out.println("Originator: Saving to Memento.");
return new Memento(state);
}

public void restoreFromMemento(Memento memento) {
state = memento.getSavedState();
System.out.println("Originator: State after restoring from Memento: " + state);
}

public static class Memento {
private final String state;

public Memento(String stateToSave) {
state = stateToSave;
}

public String getSavedState() {
return state;
}
}
}

class Caretaker {
public static void main(String[] args) {
List<Originator.Memento> savedStates = new ArrayList<Originator.Memento>();

Originator originator = new Originator();
originator.set("State1");
originator.set("State2");
savedStates.add(originator.saveToMemento());
originator.set("State3");
// We can request multiple mementos, and choose which one to roll back to.
savedStates.add(originator.saveToMemento());
originator.set("State4");

originator.restoreFromMemento(savedStates.get(1));
}
}
</pre>

The output is:
Originator: Setting state to State1
Originator: Setting state to State2
Originator: Saving to Memento.
Originator: Setting state to State3
Originator: Saving to Memento.
Originator: Setting state to State4
Originator: State after restoring from Memento: State3

== Comparison with Command Pattern ==

#The similarity between Command and Memento act as magic tokens to be passed around and invoked at a later time. In Command, the token represents a request; in Memento, it represents the internal state of an object at a particular time.
#Polymorphism is important to Command, but not to Memento because its interface is so narrow that a memento can only be passed as a value.
#Command can use Memento to maintain the state required for an undo operation.
#In practice, the Memento pattern is a little brittle. Changes in the behavior of related objects could lead to changes in what has to be stored. However since command pattern separates out the responsibility for reversibility into the relevant transitions, it proves to be less brittle. Furthermore, command objects can be extended in further directions, taking in permissions, interruptibility, batching, to name but a few.

== Real life applications ==
The following are the applications where memento pattern can be used:
#An interesting game in which memento pattern can be used is Prince of Persia: Sands of Time. In the game, you can hit a button that reverses time. By storing the state of every actor in recent frames, it can just as easily rewind them.
# Another simple application where memento pattern can be used is a calculator that finds the result of addition of two numbers, with the additional option to undo last operation and restore previous result.
# Memento pattern is useful when you need to find the seed of a pseudorandom number generator and the state in a finite state machine.

In all the above applications the "undo" feature is common. Hence, An unlimited “undo” and “redo” capability can be readily implemented with a stack of Command objects and a stack of Memento objects.

= Strategy =
The unofficially accepted definition for the Strategy Pattern is: ''"Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it."''[http://en.wikipedia.org/wiki/Strategy_pattern]. In other words, the Strategy Pattern encapsulates a collection of functions that do more or less similar tasks but not identical tasks. Strategy pattern is used when we need to take a decision of which strategy to use based on the input parameters. An important feature of strategy pattern is that client is aware of all the available strategies and which strategy to adopt. It helps is design a system that is elegant, extensible, and powerful. The following diagram illustrates the strategy pattern: <br/>
[[File:Strategy.jpg]]

== Example ==
The following example is in Java.<ref>http://en.wikipedia.org/wiki/Strategy_pattern]</ref>
<pre>
// The classes that implement a concrete strategy should implement this.
// The Context class uses this to call the concrete strategy.
interface IStrategy {
int execute(int a, int b);
}

// Implements the algorithm using the strategy interface
class ConcreteStrategyAdd implements IStrategy {

public int execute(int a, int b) {
System.out.println("Called ConcreteStrategyAdd's execute()");
return a + b; // Do an addition with a and b
}
}

class ConcreteStrategySubtract implements IStrategy {

public int execute(int a, int b) {
System.out.println("Called ConcreteStrategySubtract's execute()");
return a - b; // Do a subtraction with a and b
}
}

class ConcreteStrategyMultiply implements IStrategy {

public int execute(int a, int b) {
System.out.println("Called ConcreteStrategyMultiply's execute()");
return a * b; // Do a multiplication with a and b
}
}

// Configured with a ConcreteStrategy object and maintains a reference to a Strategy object
class Context {

private IStrategy strategy;

// Constructor
public Context(IStrategy strategy) {
this.strategy = strategy;
}

public int executeStrategy(int a, int b) {
return strategy.execute(a, b);
}
}

// Test application
class StrategyExample {

public static void main(String[] args) {

Context context;

// Three contexts following different strategies
context = new Context(new ConcreteStrategyAdd());
int resultA = context.executeStrategy(3,4);

context = new Context(new ConcreteStrategySubtract());
int resultB = context.executeStrategy(3,4);

context = new Context(new ConcreteStrategyMultiply());
int resultC = context.executeStrategy(3,4);

System.out.println("Result A : " + resultA );
System.out.println("Result B : " + resultB );
System.out.println("Result C : " + resultC );
}
}
</pre>

== Comparison with Command Pattern ==
The difference between Strategy Pattern and Command pattern is in the purpose itself:
#Command encapsulates a single action. It therefore tends to have a single method with a rather generic signature. It often is intended to be stored for a longer time and to be executed later - or it is used to provide undo functionality as explained in the Command pattern section.Strategy, in contrast, is used to customize an algorithm. A strategy might have a number of methods specific to the algorithm. Most often strategies will be instantiated immediately before executing the algorithm, and discarded later.
#Strategies encapsulate algorithms. Commands separate the sender from the receiver of a request, they turn a request into an object. If it's an algorithm, how something will be done, use a Strategy. If you need to separate the call of a method from its execution use a Command.

== Real life applications ==
The applications where strategy pattern is useful are as follows:
#Strategy pattern is used in an system where we try to book the most inexpensive ticket from source to destination. Depending on the users preference of seats, time of transit and other preferences the system chooses the algorithm that will cater to all the user needs at an optimum fare.
#Strategy pattern can be used when we have to sort numbers. Depending on the type of input, we can make use of the best algorithm. For example, if we know that the numbers are almost sorted then we make use of insertion sort. If the numbers to be sorted are within a range, then we make use of counting sort. If the input sequence is random then our best bet is to use merge sort.
# A strategy pattern can be used when we want to read a file that has been transferred over a network. If the file is an XML File then use an XML parsing algorithm. If it is JSON file then use a JSON parser and so on.

= Conclusion =
Thus, we see that Command Pattern is quite useful. The Chain of Responsibility, Memento ad Strategy pattern adopt the concept of Command patterns and have their own variations which make them useful in different scenarios as mentioned in each of the sections. The main advantage of the command design pattern is that it decouples the object that invokes the operation from the one that knows how to perform it. The major disadvantage of the pattern is that it results in many Command classes that can clutter up a design. If the classes are not designed properly it may lead to bloating of the design and will increase the cost of maintaining such a design.

=References=
<references/>

CSC/ECE 517 Fall 2012/ch2b 2w40 sn

2012-11-20T04:44:18Z

Npatowa:

= Introduction to Command Pattern =
The command pattern is one of the most used behavioral design patterns. The main concept of the pattern is an object which can be used to represent and encapsulate all the information needed to call a method at a later time. This information includes the method name, the object that owns the method and values for the method parameters.

The command pattern has been often associated with these terms client, invoker and receiver. The client instantiates the command object and provides the information required to call the method at a later time. The invoker decides when the method should be called. The receiver is an instance of the class that contains the method's code.

The intent of the Command pattern can be listed as:
#encapsulate a request in an object
# allows the parametrization of clients with different requests
# allows saving the requests in a queue
== A Java Example ==
[[File:Command.jpg]]

As the figure above suggests the integral parts of the command pattern are the client,invoker and the receiver.The command part is split into two parts-the interface and the concrete command. The examples are explored more in the below example.
This is the command interface which contains the skeleton code of the command pattern containing exactly one method called execute.
<pre>
//Command
public interface Command
{
public void execute();
}
</pre>
<pre>
//Concrete Command
public class LightOnCommand implements Command
{
//reference to the light
Light light;

public LightOnCommand(Light light)
{
this.light = light;
}

public void execute()
{
light.switchOn();
}

}

</pre>
<pre>
//Concrete Command
public class LightOffCommand implementsCommand
{
//reference to the light
Light light;

public LightOffCommand(Light light)
{
this.light = light;
}

public void execute()
{
light.switchOff();
}

}

</pre>
LightOnCommand and LightOffCommand represents the concrete command classes that the client shall use.

Light is the receiver class which contains the commands to be executed.
<pre>
//Receiver
public class Light
{
private boolean on;

public void switchOn()
{
on = true;
}

public void switchOff()
{
on = false;
}

}
</pre>
The invoker is the one which actually which calls the execute method of the command class. This also has a accessor method which sets the current command to be executed.
<pre>
//Invoker
public class RemoteControl
{
private Command command;

public void setCommand(Command command)
{
this.command = command;
}

public void pressButton()
{
command.execute();
}

}
</pre>
And finally there is the Client class which will use the commands to switch the lights on and off.
<pre>
//Client
public class Client
{
public static void main(String[] args)
{
RemoteControl control = new RemoteControl();

Light light = new Light();

Command lightsOn = new LightsOnCommand(light);
Command lightsOff = new LightsOffCommand(light);

//switch on
control.setCommand(lightsOn);
control.pressButton();

//switch off
control.setCommand(lightsOff);
control.pressButton();

}

}
</pre>

== Real life applications ==
The command pattern can be used when the following things are desired:
# Specify,queue and execute requests at different times.
# To support operations like '''Undo''','''Redo'''.
# Support Logging changes so that they can be reapplied in case of a system crash.If the command interface is extended to include the load and store operations, a persistent history of changes can be kept.
# These can also be applied to transactions. They have a common interface so all the transactions can be invoked in the same way. It is also helpful to rollback transaction if something goes wrong.
# It is also used for implementing GUI objects. In addition to the ability to perform the desired command, an Action may have an associated icon, keyboard shortcut, tooltip text, and so on.
For an additional list of applications users can read this [http://en.wikipedia.org/wiki/Command_pattern].

= Chain of Responsibility =
Chain-of-responsibility pattern is another behavioral design pattern consisting of a source of command objects and a series of processing objects. Processing objects contain logic that defines the types of command objects that it can handle; the rest are passed to the next processing object in the chain. The basic intent of this pattern is to chain the receiving objects and pass the request along the chain until an object handles it.
This pattern promotes decoupling between senders and receivers by giving multiple objects a chance to handle a request. The request gets passed along a chain of objects until one of them handles it. More information can be handled from here [http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern].
== Example of Chain of Responsibility ==
[[File:COR.jpg]]

The above figure helps to understand the workings of Chain of Responsibility pattern.The example given in [http://javapapers.com/design-patterns/chain-of-responsibility-design-pattern/] has been described below.

<pre>
//Interface
public interface Chain {

public abstract void setNext(Chain nextInChain);
public abstract void process(Number request);
}
</pre>
<pre>
//Receiver
public class Number {
private int number;

public Number(int number) {
this.number = number;
}

public int getNumber() {
return number;
}

}
</pre>
<pre>
//Concrete Handler1
public class NegativeProcessor implements Chain {

private Chain nextInChain;

public void setNext(Chain c) {
nextInChain = c;
}

public void process(Number request) {
if (request.getNumber() < 0) {
System.out.println("NegativeProcessor : " + request.getNumber());
} else {
nextInChain.process(request);
}
}
}
</pre>
<pre>
//Concrete Handler2
public class ZeroProcessor implements Chain {

private Chain nextInChain;

public void setNext(Chain c) {
nextInChain = c;
}

public void process(Number request) {
if (request.getNumber() == 0) {
System.out.println("ZeroProcessor : " + request.getNumber());
} else {
nextInChain.process(request);
}
}
}
</pre>
<pre>
//Concrete Handler3
public class PositiveProcessor implements Chain {

private Chain nextInChain;

public void setNext(Chain c) {
nextInChain = c;
}

public void process(Number request) {
if (request.getNumber() > 0) {
System.out.println("PositiveProcessor : " + request.getNumber());
} else {
nextInChain.process(request);
}
}
}
</pre>
<pre>
//Client
public class TestChain {
public static void main(String[] args) {
//configure Chain of Responsibility
Chain c1 = new NegativeProcessor();
Chain c2 = new ZeroProcessor();
Chain c3 = new PositiveProcessor();
c1.setNext(c2);
c2.setNext(c3);

//calling chain of responsibility
c1.process(new Number(99));
c1.process(new Number(-30));
c1.process(new Number(0));
c1.process(new Number(100));
}
}
</pre>
In the above example the Chain interface is implemented by three handlers which handles 3 different types of numbers-positive numbers,negative numbers and the number zero. The first in the chain is the negative number handler which sets the next handler as the zero handler which in turn sets the positive handler as the last component in the chain.The Number class acts as the receiver which has been explained in the Command pattern.The TestChain is the client.
== Comparison with Command Pattern ==
# Both in Command and Chain of Responsibility pattern commands or actions are stored so that it can be later used.
# The Chain of Responsibility forwards requests along a chain of classes, but the Command pattern forwards a request only to a specific object.
# The main intent of both the patterns is to decouple senders and receivers.In case of Command pattern that is only one.
== Real life applications ==
Chain of Responsibility is used in many applications:
# It is used often to handle exceptions inside kernel.There will be a chain of interrupt handlers and the request is passed on until somebody handles it.
# The pattern is used in windows systems to handle events generated from the keyboard or mouse.
# Single sign on security solutions for web applications. You might have a handler to check if the user is already authenticated, another handler to check for windows authentication, and a last handler to transfer the request to a logon page[http://codebetter.com/jeremymiller/2005/11/07/using-the-chain-of-responsibility-pattern/].

= Memento =
The memento pattern is a software design pattern that facilitates the restoration an object to its previous state. The memento pattern has three different components:[http://www.colourcoding.net/blog/archive/2009/07/23/reversibility-patterns-memento-and-command.aspx]
# Originator - the object that has an internal state and knows to save itself.
# Caretaker - the object that knows why and when the Originator needs to save and restore itself.
# Memento - the object (token) that is written and read by the Originator, and taken care by the Caretaker.

The communication between different components in memento pattern happens in the following way:
The caretaker first asks the originator for a memento object. Then it does the work it was slated to do. To roll back to the state before the operations, it returns the memento object to the originator. The memento object itself is an opaque object (one which the caretaker cannot change). When using this pattern, care should be taken if the originator may change other objects or resources - the memento pattern operates on a single object.In other words, the memento pattern can be viewed as maintaining a "checkpoint" so that the originator can easily rollback to the previous checkpoint.[http://sourcemaking.com/design_patterns/memento]

The following diagram illustrates the memento pattern:<br/>
[[File:Memento.jpg]]

== Example of Memento Pattern ==

The following program illustrates the "undo" usage of the Memento Pattern [http://en.wikipedia.org/wiki/Memento_pattern].

<pre>
import java.util.List;
import java.util.ArrayList;
class Originator {
private String state;
// The class could also contain additional data that is not part of the
// state saved in the memento.

public void set(String state) {
System.out.println("Originator: Setting state to " + state);
this.state = state;
}

public Memento saveToMemento() {
System.out.println("Originator: Saving to Memento.");
return new Memento(state);
}

public void restoreFromMemento(Memento memento) {
state = memento.getSavedState();
System.out.println("Originator: State after restoring from Memento: " + state);
}

public static class Memento {
private final String state;

public Memento(String stateToSave) {
state = stateToSave;
}

public String getSavedState() {
return state;
}
}
}

class Caretaker {
public static void main(String[] args) {
List<Originator.Memento> savedStates = new ArrayList<Originator.Memento>();

Originator originator = new Originator();
originator.set("State1");
originator.set("State2");
savedStates.add(originator.saveToMemento());
originator.set("State3");
// We can request multiple mementos, and choose which one to roll back to.
savedStates.add(originator.saveToMemento());
originator.set("State4");

originator.restoreFromMemento(savedStates.get(1));
}
}
</pre>

The output is:
Originator: Setting state to State1
Originator: Setting state to State2
Originator: Saving to Memento.
Originator: Setting state to State3
Originator: Saving to Memento.
Originator: Setting state to State4
Originator: State after restoring from Memento: State3

== Comparison with Command Pattern ==

#The similarity between Command and Memento act as magic tokens to be passed around and invoked at a later time. In Command, the token represents a request; in Memento, it represents the internal state of an object at a particular time.
#Polymorphism is important to Command, but not to Memento because its interface is so narrow that a memento can only be passed as a value.
#Command can use Memento to maintain the state required for an undo operation.
#In practice, the Memento pattern is a little brittle. Changes in the behavior of related objects could lead to changes in what has to be stored. However since command pattern separates out the responsibility for reversibility into the relevant transitions, it proves to be less brittle. Furthermore, command objects can be extended in further directions, taking in permissions, interruptibility, batching, to name but a few.

== Real life applications ==
The following are the applications where memento pattern can be used:
#An interesting game in which memento pattern can be used is Prince of Persia: Sands of Time. In the game, you can hit a button that reverses time. By storing the state of every actor in recent frames, it can just as easily rewind them.
# Another simple application where memento pattern can be used is a calculator that finds the result of addition of two numbers, with the additional option to undo last operation and restore previous result.
# Memento pattern is useful when you need to find the seed of a pseudorandom number generator and the state in a finite state machine.

In all the above applications the "undo" feature is common. Hence, An unlimited “undo” and “redo” capability can be readily implemented with a stack of Command objects and a stack of Memento objects.

= Strategy =
The unofficially accepted definition for the Strategy Pattern is: ''"Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it."''[http://en.wikipedia.org/wiki/Strategy_pattern]. In other words, the Strategy Pattern encapsulates a collection of functions that do more or less similar tasks but not identical tasks. Strategy pattern is used when we need to take a decision of which strategy to use based on the input parameters. An important feature of strategy pattern is that client is aware of all the available strategies and which strategy to adopt. It helps is design a system that is elegant, extensible, and powerful. The following diagram illustrates the strategy pattern: <br/>
[[File:Strategy.jpg]]

== Example ==
The following example is in Java.[http://en.wikipedia.org/wiki/Strategy_pattern]
<pre>
// The classes that implement a concrete strategy should implement this.
// The Context class uses this to call the concrete strategy.
interface IStrategy {
int execute(int a, int b);
}

// Implements the algorithm using the strategy interface
class ConcreteStrategyAdd implements IStrategy {

public int execute(int a, int b) {
System.out.println("Called ConcreteStrategyAdd's execute()");
return a + b; // Do an addition with a and b
}
}

class ConcreteStrategySubtract implements IStrategy {

public int execute(int a, int b) {
System.out.println("Called ConcreteStrategySubtract's execute()");
return a - b; // Do a subtraction with a and b
}
}

class ConcreteStrategyMultiply implements IStrategy {

public int execute(int a, int b) {
System.out.println("Called ConcreteStrategyMultiply's execute()");
return a * b; // Do a multiplication with a and b
}
}

// Configured with a ConcreteStrategy object and maintains a reference to a Strategy object
class Context {

private IStrategy strategy;

// Constructor
public Context(IStrategy strategy) {
this.strategy = strategy;
}

public int executeStrategy(int a, int b) {
return strategy.execute(a, b);
}
}

// Test application
class StrategyExample {

public static void main(String[] args) {

Context context;

// Three contexts following different strategies
context = new Context(new ConcreteStrategyAdd());
int resultA = context.executeStrategy(3,4);

context = new Context(new ConcreteStrategySubtract());
int resultB = context.executeStrategy(3,4);

context = new Context(new ConcreteStrategyMultiply());
int resultC = context.executeStrategy(3,4);

System.out.println("Result A : " + resultA );
System.out.println("Result B : " + resultB );
System.out.println("Result C : " + resultC );
}
}
</pre>

== Comparison with Command Pattern ==
The difference between Strategy Pattern and Command pattern is in the purpose itself:
#Command encapsulates a single action. It therefore tends to have a single method with a rather generic signature. It often is intended to be stored for a longer time and to be executed later - or it is used to provide undo functionality as explained in the Command pattern section.Strategy, in contrast, is used to customize an algorithm. A strategy might have a number of methods specific to the algorithm. Most often strategies will be instantiated immediately before executing the algorithm, and discarded later.
#Strategies encapsulate algorithms. Commands separate the sender from the receiver of a request, they turn a request into an object. If it's an algorithm, how something will be done, use a Strategy. If you need to separate the call of a method from its execution use a Command.

== Real life applications ==
The applications where strategy pattern is useful are as follows:
#Strategy pattern is used in an system where we try to book the most inexpensive ticket from source to destination. Depending on the users preference of seats, time of transit and other preferences the system chooses the algorithm that will cater to all the user needs at an optimum fare.
#Strategy pattern can be used when we have to sort numbers. Depending on the type of input, we can make use of the best algorithm. For example, if we know that the numbers are almost sorted then we make use of insertion sort. If the numbers to be sorted are within a range, then we make use of counting sort. If the input sequence is random then our best bet is to use merge sort.
# A strategy pattern can be used when we want to read a file that has been transferred over a network. If the file is an XML File then use an XML parsing algorithm. If it is JSON file then use a JSON parser and so on.

= Conclusion =
Thus, we see that Command Pattern is quite useful. The Chain of Responsibility, Memento ad Strategy pattern adopt the concept of Command patterns and have their own variations which make them useful in different scenarios as mentioned in each of the sections. The main advantage of the command design pattern is that it decouples the object that invokes the operation from the one that knows how to perform it. The major disadvantage of the pattern is that it results in many Command classes that can clutter up a design. If the classes are not designed properly it may lead to bloating of the design and will increase the cost of maintaining such a design.

==References==
<references/>

CSC/ECE 517 Fall 2012/ch2b 2w40 sn

2012-11-18T08:57:49Z

Npatowa:

CSC/ECE 517 Fall 2012/ch2b 2w40 sn

2012-11-18T08:48:31Z

Npatowa:

File:COR.jpg

2012-11-18T08:47:59Z

Npatowa:

CSC/ECE 517 Fall 2012/ch2b 2w40 sn

2012-11-18T08:31:18Z

Npatowa:

CSC/ECE 517 Fall 2012/ch2b 2w40 sn

2012-11-18T08:30:19Z

Npatowa:

CSC/ECE 517 Fall 2012/ch2b 2w40 sn

2012-11-17T09:14:58Z

Npatowa:

CSC/ECE 517 Fall 2012/ch2b 2w40 sn

2012-11-17T08:55:47Z

Npatowa:

CSC/ECE 517 Fall 2012/ch2b 2w40 sn

2012-11-17T07:41:22Z

Npatowa:

CSC/ECE 517 Fall 2012/ch2b 2w40 sn

2012-11-17T03:28:17Z

Npatowa:

CSC/ECE 517 Fall 2012/ch2b 2w40 sn

2012-11-17T03:27:47Z

Npatowa:

CSC/ECE 517 Fall 2012/ch2b 2w40 sn

2012-11-17T02:58:31Z

Npatowa:

File:Command.jpg

2012-11-17T02:57:22Z

Npatowa:

CSC/ECE 517 Fall 2012/ch2b 2w40 sn

2012-11-17T02:19:23Z

Npatowa:

CSC/ECE 517 Fall 2012/ch2b 2w40 sn

2012-11-17T02:16:19Z

Npatowa:

CSC/ECE 517 Fall 2012/ch2b 2w40 sn

2012-11-17T02:04:44Z

Npatowa:

CSC/ECE 517 Fall 2012/ch2b 2w40 sn

2012-11-17T02:03:04Z

Npatowa:

== Introduction to Command Pattern ==
The command pattern is one of the most used behavioral design patterns. The main concept of the pattern is an object which can be used to represent and encapsulate all the information needed to call a method at a later time. This information includes the method name, the object that owns the method and values for the method parameters.

The command pattern has been often associated with these terms client, invoker and receiver. The client instantiates the command object and provides the information required to call the method at a later time. The invoker decides when the method should be called. The receiver is an instance of the class that contains the method's code.

The intent of the Command pattern can be listed as:
#encapsulate a request in an object
# allows the parametrization of clients with different requests
# allows saving the requests in a queue
= A Java Example =

=== Real life applications ===

== Chain of Responsibility ==

=== Comparison with Command Pattern ===
=== Real life applications ===

== Memento ==

=== Comparison with Command Pattern ===
=== Real life applications ===

== Strategy ==

=== Comparison with Command Pattern ===
=== Real life applications ===

== Conclusion ==
=== Advantages and Disadvantages ===

CSC/ECE 517 Fall 2012/ch2b 2w40 sn

2012-11-17T01:48:34Z

Npatowa:

== Introduction to Command Pattern ==
The command pattern is one of the most used behavioral design patterns. The main concept of the pattern is an object which can be used to represent and encapsulate all the information needed to call a method at a later time. This information includes the method name, the object that owns the method and values for the method parameters.

The command pattern has been often associated with these terms client, invoker and receiver. The client instantiates the command object and provides the information required to call the method at a later time. The invoker decides when the method should be called. The receiver is an instance of the class that contains the method's code.

The intent of the Command pattern can be listed as:
#encapsulate a request in an object
# allows the parametrization of clients with different requests
# allows saving the requests in a queue

=== Real life applications ===

== Chain of Responsibility ==

=== Comparison with Command Pattern ===
=== Real life applications ===

== Memento ==

=== Comparison with Command Pattern ===
=== Real life applications ===

== Strategy ==

=== Comparison with Command Pattern ===
=== Real life applications ===

== Conclusion ==
=== Advantages and Disadvantages ===

CSC/ECE 517 Fall 2012/ch2b 2w40 sn

2012-11-16T09:09:09Z

Npatowa:

== Introduction to Command Pattern ==
The command pattern is one of the most used behavioral design patterns. The main concept of the pattern is an object which can be used to represent and encapsulate all the information needed to call a method at a later time. This information includes the method name, the object that owns the method and values for the method parameters.

The command pattern has been often associated with these terms client, invoker and receiver. The client instantiates the command object and provides the information required to call the method at a later time. The invoker decides when the method should be called. The receiver is an instance of the class that contains the method's code.

Using command objects makes it easier to construct general components that need to delegate, sequence or execute method calls at a time of their choosing without the need to know the owner of the method or the method parameters.

=== Real life applications ===

== Chain of Responsibility ==

=== Comparison with Command Pattern ===
=== Real life applications ===

== Memento ==

=== Comparison with Command Pattern ===
=== Real life applications ===

== Strategy ==

=== Comparison with Command Pattern ===
=== Real life applications ===

== Conclusion ==
=== Advantages and Disadvantages ===

CSC/ECE 517 Fall 2012/ch2b 2w40 sn

2012-11-15T17:30:53Z

Npatowa:

== Introduction to Command Pattern ==

=== Real life applications ===

== Chain of Responsibility ==

=== Comparison with Command Pattern ===
=== Real life applications ===

== Memento ==

=== Comparison with Command Pattern ===
=== Real life applications ===

== Strategy ==

=== Comparison with Command Pattern ===
=== Real life applications ===

== Conclusion ==
=== Advantages and Disadvantages ===

CSC/ECE 517 Fall 2012/ch2b 2w40 sn

2012-11-15T17:27:58Z

Npatowa:

== Introduction to Command Pattern ==

=== Example ===
== Chain of Responsibility ==

=== Comparison with Command Pattern ===
=== Real life applications ===

== Memento ==

=== Comparison with Command Pattern ===
=== Real life applications ===

== Strategy ==

=== Comparison with Command Pattern ===
=== Real life applications ===

CSC/ECE 517 Fall 2012/ch2b 2w40 sn

2012-11-15T17:27:14Z

Npatowa:

== Introduction to Command Pattern ==

=== Example ===
== Chain of Responsibility ==

=== Comparison with Command Pattern ===
=== Real life applications ===

CSC/ECE 517 Fall 2012/ch2b 2w40 sn

2012-11-15T17:24:39Z

Npatowa:

== Introduction to Command Pattern ==

=== Regular Expressions ===

CSC/ECE 517 Fall 2012/ch2b 2w40 sn

2012-11-15T17:24:05Z

Npatowa:

=== Introduction to Command Pattern ===

== Regular Expressions ==

CSC/ECE 517 Fall 2012/ch2b 2w40 sn

2012-11-15T17:23:19Z

Npatowa: Created page with "=== Introduction to Command Pattern=== == Regular Expressions =="

=== Introduction to Command Pattern===

== Regular Expressions ==

CSC/ECE 517 Fall 2012

2012-11-15T17:19:52Z

Npatowa:

*[[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/ch1b 1w39 sn

2012-10-04T00:25:22Z

Npatowa:

<h2>Lecture 10 - Testing in Rails</h2>
__TOC__
==Introduction==
This article is a summary of [http://mediasite.eos.ncsu.edu/Mediasite/Viewer/?peid=786d700dbc65460695f7f0abf9e8cfa71d Lecture 10] '''"Testing in Rails"'''<ref>http://guides.rubyonrails.org/testing.html</ref> and it basically describes in detail the various types of tests in rails which one might encounter while developing a typical rails application. There are five components central to testing in rails: '''Fixtures''', '''Unit tests''', '''Functional tests''', '''Integration tests''' and '''Performance tests'''. These have been described below.
==Software Testing==
In the simplest terms, software testing can be summarized as follows. We provide some test inputs to the software and we get some test outputs from the software. Then we check if the output is acceptable or not. If the output is acceptable then the test case has passed, otherwise it has failed and we have to debug it. The hard part of doing software testing is selecting a good set of test inputs and designing good acceptability tests.

But while testing the software, we have to keep the following things in mind. We have to find bugs as early as possible. The earlier we find the bug, the cheaper it is to fix it.
Also, more testing is not always better. We may write a lot of test cases but they still may not cover every functionality of our software.
==Setup test environment in Rails==
<h4>In-Memory Databases</h4>

Since all tests involve a high amount of database interaction, it is highly recommended to install the gem ''''memory_test_fix''''<ref>http://agilewebdevelopment.com/plugins/memory_test_fix</ref> which basically ([http://en.wikipedia.org/wiki/Monkey_patch monkey]) patches all tests in rails. This gem allows your tests to mock up a database within the memory, so that all reads/writes to the database executed by the test (when they run) are done to memory instead of the disk. This helps run all the unit tests a lot faster than what they would, if they were to read/write all their results to files (on the disk). It eliminates file locking issues on the test database when running on Windows. This is not a requirement, but it improves the speed of testing and development which is ultimately desirable. Most importantly it is good for testing because one usually does not need the data after the test is done, but only needs it during the lifetime of the test.

Make the following change to the ''''config/database.yml'''' file:
<pre>
test:
adapter: sqlite3
database: ":memory:"
</pre>
The change is that the ''''database:'''' field has been changed from:
<pre>db/development.sqlite3 to ":memory:"</pre>
This now ensures that for all the tests, the database used will be the one in memory and not in an actual Sqlite database.

<h4>Database Setup</h4>
Rails provides a basic boiler plate to create tests.There are three environments provided by Rails - production,development and testing.As the names suggest they are used for different purposes.This prevents developers from messing with their development environments.Inside the rails app directory there will be a directory called test.This directory contains folders-unit,functional,integration and fixtures.The unit folder holds tests for the models, the functional folder is meant to hold tests for your controllers, and the integration folder contains tests that involve any number of controllers interacting.Fixtures contain the sample test data.Rails has the Test::Unit included by default but there are other frameworks also available like RSpec<ref>http://rspec.info/</ref>,Cucumber(for behavior driven development),Shoulda <ref>https://github.com/thoughtbot/shoulda#readme</ref>.When we create the rails scaffold for a particular model then it creates the directories unit,functional,integration which contains the different tests for the respective models.After the test cases have been written we need to prepare the test db.
<pre>
rake db:migrate
rake db:test:load
</pre>
This two commands should suffice but a complete reference of rake commands for testing purpose is mentioned in <ref>http://guides.rubyonrails.org/testing.html#preparing-your-application-for-testing</ref>
After preparing everything we are now ready to run our test.If you are using a Integrated Development Environment(IDE) like RubyMine then you need not worry anything and just do right click on the unit test folder->Select Run->All tests in unit.The figure provided below presents a better picture[[File:RunningTest.png]].

If you are using command line then you can use the following options
<pre>
ruby -Itest test/unit/post_test.rb
Loaded suite unit/post_test
Started
.
Finished in 0.023513 seconds.

2 tests, 2 assertions, 0 failures, 0 errors
</pre>

==Fixtures==
Rails tests are data-driven, which means that all of its tests need some sort of sample data to run on. Fixtures<ref>http://ar.rubyonrails.org/classes/Fixtures.html</ref> allow the tester to populate the testing database before any of the tests in the test folder can run. Fixtures have a file format which describes data structures in a human readable format and can be found under the 'test/fixtures' directory. When the rails [http://guides.rubyonrails.org/getting_started.html#generating-a-model generate model] is executed to create a new model, fixture stubs are automatically created and placed in that directory. YAML fixtures are stored in a single file per model i.e. for every model there is a corresponding fixture. Each record is given a name and is followed by an indented list of key/value pairs in the '''"key: value"''' format. When you create a fixture, it generates an internal hash table. Fixtures are hash objects which can be accessed directly because it is automatically setup as a local variable for the test case. The good thing about this is that we can reference these objects using symbolic names. So if we were to declare a fixture called '''':cookie'''' (see example below), we could reference the entire cookie record simply by:
<pre>categories(:cookie)</pre>
This will return the hash for the fixture named cookie which corresponds to a row in the recipe table describing the recipe for that cookie.

On creating the model, the default fixtures generated are of the form:
<pre>
one:
title: MyString
description: MyString
instructions: MyText

two:
title: MyString
description: MyString
instructions: MyText
</pre>

We spoke of the :cookie fixture which would be defined as:
<pre>
cookie:
Title: Biscuit
Description: Round and Small
Instructions: Buy and bake them
</pre>
This allows us to access this entire record using the symbolic name ':cookie' which hashes to this particular fixture.

An important feature of YAML fixtures is that it supports Embedded Ruby i.e. we can embed ruby code into fixtures to generate a large set of sample data. For example:
<pre>
<% (1..1000).each do |i| %>
fix_<%= i %>:
name: category_<%= i %>
<% end %>
</pre>
This would create a thousand fixtures having symbolic names fix_1, fix_2 up to fix_1000, each one of them having a corresponding name attribute category_1, category_2 etc. This is a much better alternative than having to copy-paste the fixture fixture a thousand times.

A very important thing to remember about fixtures is that the ones which are generated by default by the scaffolds do not factor in for any foreign-key relationships that might be present in the models. Thus, such references have to be explicitly added to the fixture manually in order to reflect any 'has-many' or 'belongs-to' relationships across models.

==Unit Testing==
If the application was created using the scaffold command then it should create a stub in test/unit directory.The initial code would look something like this
<pre>
require 'test_helper'

class PostTest < ActiveSupport::TestCase
# Replace this with your real tests.
test "the truth" do
assert true
end
end
</pre>
Now if we wanted to add real tests to it then let us take two scenarios
1.Post with empty entries.
2.Post with actual entries
The code for these two test cases would look something like this
<pre>
require 'test_helper'

class PostTest < ActiveSupport::TestCase

test "Post new empty" do
p = Post.new
assert !p.save, "Saved post without title, content, user, or category"
assert p.invalid?
end

test "Post new correct" do
p = Post.new
#Post has following fields title,email,content
p.title = 'General title'
p.content = 'A new content'
p.email = 'Azrael@ncsu.edu'
#place an assert .so as to find out whether this statement is valid or not
assert p.valid?
end

end

</pre>
test_helper.rb contains the default configuration to run the tests,ActiveSupport::TestCase defines the basic methods for defining
a test case.The test cases must begin with the name "test". The statement that actually determines whether the test has passed or not is the assert statement.An assertion is a line of code that evaluates an object (or expression) for expected results.It can check a variety of things like is the expression true or false,is it valid etc. In this example, in the first test case we are checking whether p is an invalid object,if yes then the test has passed because that is the expected thing.Whereas the second test checks whether p is an valid object or not,if its not then the test fails as the expected output in this case is that p should be a valid object.

Here is another example where we try to test the functionality where a user tries to register with an already existing username
<pre>
test "username exists" do
user = User.new(:username => "abcdef", :password => "abcdef", :password_confirmation => "abcdef")
user.save
user1 =User.new(:username => "abcdef", :password => "abcdef", :password_confirmation => "abcdef")
assert_false user1.save
end
</pre>
Here, a user tries to add a post with a valid title but he leaves the content field blank.
<pre>
test "empty content test" do
post = Post.new( :title => "No content for this post",:content => nil )
post.User_id=1;
assert_false post.save
end
</pre>
==Functional Testing==
If unit tests covered models then functional tests took care of the controllers.The basic purpose of writing functional tests is to check if all the methods of a controller are working correctly. Since the controllers often influence the content of the web page (which is rendered by the corresponding method of a controller) functional tests are typically written to check if the controller’s method is rendering/redirecting to the correct page, whether or not the users are getting authenticated correctly, validating the correctness of the content displayed on the page,etc.Lets say we have a application where users are allowed to post and then comment on those posts.After the user has made a comment then he has to get redirected to that particular post page.Here is how the create method of the comment controller looks like
<pre>
def create
#@comment = Comment.new(params[:comment])
if(session[:email] == nil)
redirect_to :root
return
end
@comment = Comment.new
@comment.post_id = params[:id]
@comment.content = params[:content_new]
@comment.email = session[:email]
@comment.vote_count = 0

@post = Post.find(@comment.post_id)

dateTime = Time.new
timestamp = dateTime.to_time
@post.update_attributes(:updated_at => timestamp)

respond_to do |format|
if @comment.save
format.html { redirect_to :back }
format.json { render json: @comment, status: :created, location: @comment }
else
format.html { render action: "new" }
format.json { render json: @comment.errors, status: :unprocessable_entity }
end
end
end
</pre>
As it can be seen if no there is no session then no one can comment.If a user is successfully able to comment then he is redirected to the specific post page for which the comment was made.The functional test for this piece of code would look like this
<pre>
class CommentsControllerTest < ActionController::TestCase
setup do
@comment_new = Comment.new(:content => "Comment to create", :email => "test@gm.com", :post_id => 1)
@post = Post.find(@comment_new.post_id)
@comment = comments(:one)#The fixtures contain a row named one
end

test "should create comment" do
assert_difference('Comment.count') do
post :create, { content: @comment_new.content, email: @comment_new.email, post_id: @comment_new.post_id } #parameters that goes with the post request
end

assert_redirected_to post_path(assigns(:post))
end
end
</pre>
As we see from the code that it is important to set the session variable and also we need to know before hand for which post are we commenting so we set those variables in the setup method itself.Inside the test method we attempt to create a new comment and after that we check in the assert statement whether it has been redirected to the correct path which in this case is the post page for which the comment has been made.

Testing the response to your request by asserting the presence of key HTML elements and their content is a useful way to test the views of your application. The assert_select assertion allows you to do this by using a simple yet powerful syntax.

In the example below, we test the functionality upon deleting a user.
<pre>
test "should destroy user" do
assert_difference('User.count', -1) do
delete :destroy, id: @user
end
assert_redirected_to users_path
end
</pre>

==Integration Tests==
Typically in software development, different modules of a project are worked on by different teams/developers. Each team might ensure that the model works correctly in-itself, but this might not necessarily be the case when all the modules are coupled together as a single unit. This is where Integration tests come into play. They test the interaction between multiple controllers and all the components in a sequence, end-to-end. An example of it would be that of a shopping cart application. Even though different phases of the application may work correctly, while running integration tests, one might realize that the ''''add to cart'''' button is absent in the product-catalog, even though the add to cart functionality has been correctly implemented.

The default integration tests framework included in Test-Unit are very low level i.e. they deal with HTTP GET, POST requests responses, session objects, cookies, redirects etc. In ''Behavioral-Driven-Development'' we want to deal with the system on a higher level – similar to a user’s interaction with the system i.e. we want to deal only with clicks, with typing etc. Hence, we can use some of the popular Integration Testing frameworks like Capybara which is a GUI testing framework and allows one to specify - within a test - various actions like 'click' to click on a button, 'fill_in' to fill some text into a designated text-box etc. We can see that this is at a high level and somewhat analogous to actions an end-user might go through while using the application. So the rule of thumb while writing integration tests is to identify the end-users requirements and scope of interaction with the system, walk through the steps that they would take and mimic those in the form of tests. It is clearly evident how such [http://en.wikipedia.org/wiki/Behavior_Driven_Development Behavioral-Driven-Development] goes hand in hand with [http://en.wikipedia.org/wiki/Test-driven_development Test-Driven-Development] and helps in removing the ambiguities which are often associated with Customer Requirements.

The following example shows how the test framework '''CapyBara'''<ref>http://opinionated-programmer.com/2011/02/capybara-and-selenium-with-rspec-and-rails-3/</ref> is used for Integration Testing:
<pre>
test “create category from main page” do
visit categories_path
click_link “New category”
fill_in “category_name”, :with => “Sample Category”
click_button “Create Category”
end
</pre>
Here we have simulated a user-action (for the CookBook example) where the user would carry out the following steps:
# Visit the Categories Home Page (whose url is specified as categories_path by the routes.rb file)
# Click on the Link which says "New Category", which would lead to another page.
# On this new page, fill the text-box with some text, say "Sample Category"
# Click on the button that says "Create Category".
One can easily identify these actions from the code which is highly intuitive and self-explanatory. Capybara thus provides us with these convenient methods which greatly expedites the whole Integration Testing process.

To use the framework, simply include the corresponding gem in the Gemfile, and the following lines to the end of the ''test_helper.rb'' file.
<pre>
# Add more helper methods ...
require ‘capybara/rails’

class ActionDispatch::IntegrationTest
include Capybara::DSL
end
</pre>
The easy-to-use commands mentioned before are created by Capybara using a Domain Specific Language (DSL) and in order to be able to use it, every Integration test written must '''''require 'test_helper' '''''. This is basically a '''''mixin''''', so one still has the capability to access all the low-level GET/POST commands in Test-Unit in addition to all the methods offered by Capybara.

Another example of Integration Testing with Test-Framework '''RSpec Version 1.3.2'''<ref>https://github.com/rspec/rspec#readme</ref>:
<pre>
describe "Recipes" do

before(:all) do
@recipe = Recipe.new
end

it "should not accept empty recipe" do
@user.should_not_be_valid
@user.title = "Cookie"
@user.description = "Chocolate Chip Cookie"
@user.instructions = "Bake in Oven"
@user.category = 3
@user.should_be_valid
end

end
</pre>
In the above example we basically test that an empty recipe is invalid and that a recipe with fields filled out is valid. This is a very primitive example of using RSpec and it is just to showcase the difference between RSpec and Capybara, and is in no way a comprehensive example. A thing to note is the ''before(:all)'' method, which is similar to the setup() method in Java's JUnit Framework i.e. this method is called before every test in the ''describe'' block gets executed.

In sum, Integration tests are vital and are carried out in the final stages of testing to ensure that the system works as a cohesive and complete unit.

==Performance Tests==
Performance tests as the name indicates are used to gauge the performance of the system and play a very important role in software development for the simple reason that as a developer, one does not want the end user to have a poor experience while using the application. Users do not want to wait long for pages to load and elements on the page to respond. They are not - and should not - be concerned with the capability of the system to handle large loads, scale to accommodate increased volumes of traffic etc. Such details are abstracted away from the user, but they ''do'' have a significant impact on user's interaction with the system.

Rails Performance test can be categorized as a special type of integration tests, which are designed for bench-marking and profiling the test code<ref>http://guides.rubyonrails.org/performance_testing.html#modes</ref>. In these tests, one can mention how many connections are to be simulated to the server etc. at the outcome of which it would be possible to identify the performance bottlenecks and hopefully pinpoint the source of speed and/or memory problems.

Detailed examples can be found [http://guides.rubyonrails.org/performance_testing.html#examples Here].

==Conclusion==
Testing is an indispensable and an inevitable part of development in rails.It must be fully exploited to avail the benefits associated with Test-Driven-Development, for the simple reason that rails provides an excellent in-built framework upon which writing tests is a highly natural and intuitive process. There are many advantages to testing and many articles<ref>http://www.learn.geekinterview.com/programming/ruby/ruby-on-rails-application-testing.html</ref> have been written that emphasize this point.

==References==
<references/>

Most of the content for this article has been obtained from the Lecture taught in class which has been the primary resource. The video of the lecture can be found [http://mediasite.eos.ncsu.edu/Mediasite/Viewer/?peid=786d700dbc65460695f7f0abf9e8cfa71d here].

The old wiki can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch4_4e_gs here].

CSC/ECE 517 Fall 2012/ch1b 1w39 sn

2012-10-04T00:24:24Z

Npatowa:

<h2>Lecture 10 - Testing in Rails</h2>
__TOC__
==Introduction==
This article is a summary of [http://mediasite.eos.ncsu.edu/Mediasite/Viewer/?peid=786d700dbc65460695f7f0abf9e8cfa71d Lecture 10] '''"Testing in Rails"'''<ref>http://guides.rubyonrails.org/testing.html</ref> and it basically describes in detail the various types of tests in rails which one might encounter while developing a typical rails application. There are five components central to testing in rails: '''Fixtures''', '''Unit tests''', '''Functional tests''', '''Integration tests''' and '''Performance tests'''. These have been described below.
==Software Testing==
In the simplest terms, software testing can be summarized as follows. We provide some test inputs to the software and we get some test outputs from the software. Then we check if the output is acceptable or not. If the output is acceptable then the test case has passed, otherwise it has failed and we have to debug it. The hard part of doing software testing is selecting a good set of test inputs and designing good acceptability tests.

But while testing the software, we have to keep the following things in mind. We have to find bugs as early as possible. The earlier we find the bug, the cheaper it is to fix it.
Also, more testing is not always better. We may write a lot of test cases but they still may not cover every functionality of our software.
==Setup test environment in Rails==
<h4>In-Memory Databases</h4>

Since all tests involve a high amount of database interaction, it is highly recommended to install the gem ''''memory_test_fix''''<ref>http://agilewebdevelopment.com/plugins/memory_test_fix</ref> which basically ([http://en.wikipedia.org/wiki/Monkey_patch monkey]) patches all tests in rails. This gem allows your tests to mock up a database within the memory, so that all reads/writes to the database executed by the test (when they run) are done to memory instead of the disk. This helps run all the unit tests a lot faster than what they would, if they were to read/write all their results to files (on the disk). It eliminates file locking issues on the test database when running on Windows. This is not a requirement, but it improves the speed of testing and development which is ultimately desirable. Most importantly it is good for testing because one usually does not need the data after the test is done, but only needs it during the lifetime of the test.

Make the following change to the ''''config/database.yml'''' file:
<pre>
test:
adapter: sqlite3
database: ":memory:"
</pre>
The change is that the ''''database:'''' field has been changed from:
<pre>db/development.sqlite3 to ":memory:"</pre>
This now ensures that for all the tests, the database used will be the one in memory and not in an actual Sqlite database.

<h4>Database Setup</h4>
Rails provides a basic boiler plate to create tests.There are three environments provided by Rails - production,development and testing.As the names suggest they are used for different purposes.This prevents developers from messing with their development environments.Inside the rails app directory there will be a directory called test.This directory contains folders-unit,functional,integration and fixtures.The unit folder holds tests for the models, the functional folder is meant to hold tests for your controllers, and the integration folder contains tests that involve any number of controllers interacting.Fixtures contain the sample test data.Rails has the Test::Unit included by default but there are other frameworks also available like RSpec<ref>http://rspec.info/</ref>,Cucumber(for behavior driven development),Shoulda <ref>https://github.com/thoughtbot/shoulda#readme</ref>.When we create the rails scaffold for a particular model then it creates the directories unit,functional,integration which contains the different tests for the respective models.After the test cases have been written we need to prepare the test db.
<pre>
rake db:migrate
rake db:test:load
</pre>
This two commands should suffice but a complete reference of rake commands for testing purpose is mentioned in <ref>http://guides.rubyonrails.org/testing.html#preparing-your-application-for-testing</ref>
After preparing everything we are now ready to run our test.If you are using a Integrated Development Environment(IDE) like RubyMine then you need not worry anything and just do right click on the unit test folder->Select Run->All tests in unit.The figure provided below presents a better picture[[File:RunningTest.png]].

If you are using command line then you can use the following options
<pre>
ruby -Itest test/unit/post_test.rb
Loaded suite unit/post_test
Started
.
Finished in 0.023513 seconds.

2 tests, 2 assertions, 0 failures, 0 errors
</pre>

==Fixtures==
Rails tests are data-driven, which means that all of its tests need some sort of sample data to run on. Fixtures<ref>http://ar.rubyonrails.org/classes/Fixtures.html</ref> allow the tester to populate the testing database before any of the tests in the test folder can run. Fixtures have a file format which describes data structures in a human readable format and can be found under the 'test/fixtures' directory. When the rails [http://guides.rubyonrails.org/getting_started.html#generating-a-model generate model] is executed to create a new model, fixture stubs are automatically created and placed in that directory. YAML fixtures are stored in a single file per model i.e. for every model there is a corresponding fixture. Each record is given a name and is followed by an indented list of key/value pairs in the '''"key: value"''' format. When you create a fixture, it generates an internal hash table. Fixtures are hash objects which can be accessed directly because it is automatically setup as a local variable for the test case. The good thing about this is that we can reference these objects using symbolic names. So if we were to declare a fixture called '''':cookie'''' (see example below), we could reference the entire cookie record simply by:
<pre>categories(:cookie)</pre>
This will return the hash for the fixture named cookie which corresponds to a row in the recipe table describing the recipe for that cookie.

On creating the model, the default fixtures generated are of the form:
<pre>
one:
title: MyString
description: MyString
instructions: MyText

two:
title: MyString
description: MyString
instructions: MyText
</pre>

We spoke of the :cookie fixture which would be defined as:
<pre>
cookie:
Title: Biscuit
Description: Round and Small
Instructions: Buy and bake them
</pre>
This allows us to access this entire record using the symbolic name ':cookie' which hashes to this particular fixture.

An important feature of YAML fixtures is that it supports Embedded Ruby i.e. we can embed ruby code into fixtures to generate a large set of sample data. For example:
<pre>
<% (1..1000).each do |i| %>
fix_<%= i %>:
name: category_<%= i %>
<% end %>
</pre>
This would create a thousand fixtures having symbolic names fix_1, fix_2 up to fix_1000, each one of them having a corresponding name attribute category_1, category_2 etc. This is a much better alternative than having to copy-paste the fixture fixture a thousand times.

A very important thing to remember about fixtures is that the ones which are generated by default by the scaffolds do not factor in for any foreign-key relationships that might be present in the models. Thus, such references have to be explicitly added to the fixture manually in order to reflect any 'has-many' or 'belongs-to' relationships across models.

==Unit Testing==
If the application was created using the scaffold command then it should create a stub in test/unit directory.The initial code would look something like this
<pre>
require 'test_helper'

class PostTest < ActiveSupport::TestCase
# Replace this with your real tests.
test "the truth" do
assert true
end
end
</pre>
Now if we wanted to add real tests to it then let us take two scenarios
1.Post with empty entries.
2.Post with actual entries
The code for these two test cases would look something like this
<pre>
require 'test_helper'

class PostTest < ActiveSupport::TestCase

test "Post new empty" do
p = Post.new
assert !p.save, "Saved post without title, content, user, or category"
assert p.invalid?
end

test "Post new correct" do
p = Post.new
#Post has following fields title,email,content
p.title = 'General title'
p.content = 'A new content'
p.email = 'Azrael@ncsu.edu'
#place an assert .so as to find out whether this statement is valid or not
assert p.valid?
end

end

</pre>
test_helper.rb contains the default configuration to run the tests,ActiveSupport::TestCase defines the basic methods for defining
a test case.The test cases must begin with the name "test". The statement that actually determines whether the test has passed or not is the assert statement.An assertion is a line of code that evaluates an object (or expression) for expected results.It can check a variety of things like is the expression true or false,is it valid etc. In this example, in the first test case we are checking whether p is an invalid object,if yes then the test has passed because that is the expected thing.Whereas the second test checks whether p is an valid object or not,if its not then the test fails as the expected output in this case is that p should be a valid object.

Here is another example where we try to test the functionality where a user tries to register with an already existing username
<pre>
test "username exists" do
user = User.new(:username => "abcdef", :password => "abcdef", :password_confirmation => "abcdef")
user.save
user1 =User.new(:username => "abcdef", :password => "abcdef", :password_confirmation => "abcdef")
assert_false user1.save
end
</pre>
Here, a user tries to add a post with a valid title but he leaves the content field blank.
<pre>
test "empty content test" do
post = Post.new( :title => "No content for this post",:content => nil )
post.User_id=1;
assert_false post.save
end
</pre>
==Functional Testing==
If unit tests covered models then functional tests took care of the controllers.The basic purpose of writing functional tests is to check if all the methods of a controller are working correctly. Since the controllers often influence the content of the web page (which is rendered by the corresponding method of a controller) functional tests are typically written to check if the controller’s method is rendering/redirecting to the correct page, whether or not the users are getting authenticated correctly, validating the correctness of the content displayed on the page,etc.Lets say we have a application where users are allowed to post and then comment on those posts.After the user has made a comment then he has to get redirected to that particular post page.Here is how the create method of the comment controller looks like
<pre>
def create
#@comment = Comment.new(params[:comment])
if(session[:email] == nil)
redirect_to :root
return
end
@comment = Comment.new
@comment.post_id = params[:id]
@comment.content = params[:content_new]
@comment.email = session[:email]
@comment.vote_count = 0

@post = Post.find(@comment.post_id)

dateTime = Time.new
timestamp = dateTime.to_time
@post.update_attributes(:updated_at => timestamp)

respond_to do |format|
if @comment.save
format.html { redirect_to :back }
format.json { render json: @comment, status: :created, location: @comment }
else
format.html { render action: "new" }
format.json { render json: @comment.errors, status: :unprocessable_entity }
end
end
end
</pre>
As it can be seen if no there is no session then no one can comment.If a user is successfully able to comment then he is redirected to the specific post page for which the comment was made.The functional test for this piece of code would look like this
<pre>
class CommentsControllerTest < ActionController::TestCase
setup do
@comment_new = Comment.new(:content => "Comment to create", :email => "test@gm.com", :post_id => 1)
@post = Post.find(@comment_new.post_id)
@comment = comments(:one)#The fixtures contain a row named one
end

test "should create comment" do
assert_difference('Comment.count') do
post :create, { content: @comment_new.content, email: @comment_new.email, post_id: @comment_new.post_id } #parameters that goes with the post request
end

assert_redirected_to post_path(assigns(:post))
end
end
</pre>
As we see from the code that it is important to set the session variable and also we need to know before hand for which post are we commenting so we set those variables in the setup method itself.Inside the test method we attempt to create a new comment and after that we check in the assert statement whether it has been redirected to the correct path which in this case is the post page for which the comment has been made.

Testing the response to your request by asserting the presence of key HTML elements and their content is a useful way to test the views of your application. The assert_select assertion allows you to do this by using a simple yet powerful syntax.

In the example below, we test the functionality upon deleting a user.
<pre>
test "should destroy user" do
assert_difference('User.count', -1) do
delete :destroy, id: @user
end
assert_redirected_to users_path
end
</pre>

==Integration Tests==
Typically in software development, different modules of a project are worked on by different teams/developers. Each team might ensure that the model works correctly in-itself, but this might not necessarily be the case when all the modules are coupled together as a single unit. This is where Integration tests come into play. They test the interaction between multiple controllers and all the components in a sequence, end-to-end. An example of it would be that of a shopping cart application. Even though different phases of the application may work correctly, while running integration tests, one might realize that the ''''add to cart'''' button is absent in the product-catalog, even though the add to cart functionality has been correctly implemented.

The default integration tests framework included in Test-Unit are very low level i.e. they deal with HTTP GET, POST requests responses, session objects, cookies, redirects etc. In ''Behavioral-Driven-Development'' we want to deal with the system on a higher level – similar to a user’s interaction with the system i.e. we want to deal only with clicks, with typing etc. Hence, we can use some of the popular Integration Testing frameworks like Capybara which is a GUI testing framework and allows one to specify - within a test - various actions like 'click' to click on a button, 'fill_in' to fill some text into a designated text-box etc. We can see that this is at a high level and somewhat analogous to actions an end-user might go through while using the application. So the rule of thumb while writing integration tests is to identify the end-users requirements and scope of interaction with the system, walk through the steps that they would take and mimic those in the form of tests. It is clearly evident how such [http://en.wikipedia.org/wiki/Behavior_Driven_Development Behavioral-Driven-Development] goes hand in hand with [http://en.wikipedia.org/wiki/Test-driven_development Test-Driven-Development] and helps in removing the ambiguities which are often associated with Customer Requirements.

The following example shows how the test framework '''CapyBara'''<ref>http://opinionated-programmer.com/2011/02/capybara-and-selenium-with-rspec-and-rails-3/</ref> is used for Integration Testing:
<pre>
test “create category from main page” do
visit categories_path
click_link “New category”
fill_in “category_name”, :with => “Sample Category”
click_button “Create Category”
end
</pre>
Here we have simulated a user-action (for the CookBook example) where the user would carry out the following steps:
# Visit the Categories Home Page (whose url is specified as categories_path by the routes.rb file)
# Click on the Link which says "New Category", which would lead to another page.
# On this new page, fill the text-box with some text, say "Sample Category"
# Click on the button that says "Create Category".
One can easily identify these actions from the code which is highly intuitive and self-explanatory. Capybara thus provides us with these convenient methods which greatly expedites the whole Integration Testing process.

To use the framework, simply include the corresponding gem in the Gemfile, and the following lines to the end of the ''test_helper.rb'' file.
<pre>
# Add more helper methods ...
require ‘capybara/rails’

class ActionDispatch::IntegrationTest
include Capybara::DSL
end
</pre>
The easy-to-use commands mentioned before are created by Capybara using a Domain Specific Language (DSL) and in order to be able to use it, every Integration test written must '''''require 'test_helper' '''''. This is basically a '''''mixin''''', so one still has the capability to access all the low-level GET/POST commands in Test-Unit in addition to all the methods offered by Capybara.

Another example of Integration Testing with Test-Framework '''RSpec Version 1.3.2'''<ref>https://github.com/rspec/rspec#readme</ref>:
<pre>
describe "Recipes" do

before(:all) do
@recipe = Recipe.new
end

it "should not accept empty recipe" do
@user.should_not_be_valid
@user.title = "Cookie"
@user.description = "Chocolate Chip Cookie"
@user.instructions = "Bake in Oven"
@user.category = 3
@user.should_be_valid
end

end
</pre>
In the above example we basically test that an empty recipe is invalid and that a recipe with fields filled out is valid. This is a very primitive example of using RSpec and it is just to showcase the difference between RSpec and Capybara, and is in no way a comprehensive example. A thing to note is the ''before(:all)'' method, which is similar to the setup() method in Java's JUnit Framework i.e. this method is called before every test in the ''describe'' block gets executed.

In sum, Integration tests are vital and are carried out in the final stages of testing to ensure that the system works as a cohesive and complete unit.

==Performance Tests==
Performance tests as the name indicates are used to gauge the performance of the system and play a very important role in software development for the simple reason that as a developer, one does not want the end user to have a poor experience while using the application. Users do not want to wait long for pages to load and elements on the page to respond. They are not - and should not - be concerned with the capability of the system to handle large loads, scale to accommodate increased volumes of traffic etc. Such details are abstracted away from the user, but they ''do'' have a significant impact on user's interaction with the system.

Rails Performance test can be categorized as a special type of integration tests, which are designed for bench-marking and profiling the test code<ref>http://guides.rubyonrails.org/performance_testing.html#modes</ref>. In these tests, one can mention how many connections are to be simulated to the server etc. at the outcome of which it would be possible to identify the performance bottlenecks and hopefully pinpoint the source of speed and/or memory problems.

Detailed examples can be found [http://guides.rubyonrails.org/performance_testing.html#examples Here].

==Conclusion==
Testing is an indispensable and an inevitable part of development in rails.It must be fully exploited to avail the benefits associated with Test-Driven-Development, for the simple reason that rails provides an excellent in-built framework upon which writing tests is a highly natural and intuitive process. There are many advantages to testing and many articles<ref>http://www.learn.geekinterview.com/programming/ruby/ruby-on-rails-application-testing.html</ref> have been written that emphasize this point.

==References==
<references/>

Most of the content for this article has been obtained from the Lecture taught in class which has been the primary resource. The video of the lecture can be found [http://mediasite.eos.ncsu.edu/Mediasite/Viewer/?peid=786d700dbc65460695f7f0abf9e8cfa71d here]. The old wiki can be found [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch4_4e_gs here].

CSC/ECE 517 Fall 2012/ch1b 1w39 sn

2012-10-04T00:13:24Z

Npatowa:

CSC/ECE 517 Fall 2012/ch1b 1w39 sn

2012-10-04T00:06:31Z

Npatowa:

<h2>Lecture 10 - Testing in Rails</h2>
__TOC__
==Introduction==
This article is a summary of [http://mediasite.eos.ncsu.edu/Mediasite/Viewer/?peid=786d700dbc65460695f7f0abf9e8cfa71d Lecture 10] '''"Testing in Rails"'''<ref>http://guides.rubyonrails.org/testing.html</ref> and it basically describes in detail the various types of tests in rails which one might encounter while developing a typical rails application. There are five components central to testing in rails: '''Fixtures''', '''Unit tests''', '''Functional tests''', '''Integration tests''' and '''Performance tests'''. These have been described below.
==Software Testing==
In the simplest terms, software testing can be summarized as follows. We provide some test inputs to the software and we get some test outputs from the software. Then we check if the output is acceptable or not. If the output is acceptable then the test case has passed, otherwise it has failed and we have to debug it. The hard part of doing software testing is selecting a good set of test inputs and designing good acceptability tests.

But while testing the software, we have to keep the following things in mind. We have to find bugs as early as possible. The earlier we find the bug, the cheaper it is to fix it.
Also, more testing is not always better. We may write a lot of test cases but they still may not cover every functionality of our software.
==Setup test environment in Rails==
<h4>In-Memory Databases</h4>

Since all tests involve a high amount of database interaction, it is highly recommended to install the gem ''''memory_test_fix''''<ref>http://agilewebdevelopment.com/plugins/memory_test_fix</ref> which basically ([http://en.wikipedia.org/wiki/Monkey_patch monkey]) patches all tests in rails. This gem allows your tests to mock up a database within the memory, so that all reads/writes to the database executed by the test (when they run) are done to memory instead of the disk. This helps run all the unit tests a lot faster than what they would, if they were to read/write all their results to files (on the disk). It eliminates file locking issues on the test database when running on Windows. This is not a requirement, but it improves the speed of testing and development which is ultimately desirable. Most importantly it is good for testing because one usually does not need the data after the test is done, but only needs it during the lifetime of the test.

Make the following change to the ''''config/database.yml'''' file:
<pre>
test:
adapter: sqlite3
database: ":memory:"
</pre>
The change is that the ''''database:'''' field has been changed from:
<pre>db/development.sqlite3 to ":memory:"</pre>
This now ensures that for all the tests, the database used will be the one in memory and not in an actual Sqlite database.

<h4>Database Setup</h4>
Rails provides a basic boiler plate to create tests.There are three environments provided by Rails - production,development and testing.As the names suggest they are used for different purposes.This prevents developers from messing with their development environments.Inside the rails app directory there will be a directory called test.This directory contains folders-unit,functional,integration and fixtures.The unit folder holds tests for the models, the functional folder is meant to hold tests for your controllers, and the integration folder contains tests that involve any number of controllers interacting.Fixtures contain the sample test data.Rails has the Test::Unit included by default but there are other frameworks also available like RSpec<ref>http://rspec.info/</ref>,Cucumber(for behavior driven development),Shoulda <ref>https://github.com/thoughtbot/shoulda#readme</ref>.When we create the rails scaffold for a particular model then it creates the directories unit,functional,integration which contains the different tests for the respective models.After the test cases have been written we need to prepare the test db.
<pre>
rake db:migrate
rake db:test:load
</pre>
This two commands should suffice but a complete reference of rake commands for testing purpose is mentioned in <ref>http://guides.rubyonrails.org/testing.html#preparing-your-application-for-testing</ref>
After preparing everything we are now ready to run our test.If you are using a Integrated Development Environment(IDE) like RubyMine then you need not worry anything and just do right click on the unit test folder->Select Run->All tests in unit.The figure provided below presents a better picture[[File:RunningTest.png]].

If you are using command line then you can use the following options
<pre>
ruby -Itest test/unit/post_test.rb
Loaded suite unit/post_test
Started
.
Finished in 0.023513 seconds.

2 tests, 2 assertions, 0 failures, 0 errors
</pre>

==Fixtures==
Rails tests are data-driven, which means that all of its tests need some sort of sample data to run on. Fixtures<ref>http://ar.rubyonrails.org/classes/Fixtures.html</ref> allow the tester to populate the testing database before any of the tests in the test folder can run. Fixtures have a file format which describes data structures in a human readable format and can be found under the 'test/fixtures' directory. When the rails [http://guides.rubyonrails.org/getting_started.html#generating-a-model generate model] is executed to create a new model, fixture stubs are automatically created and placed in that directory. YAML fixtures are stored in a single file per model i.e. for every model there is a corresponding fixture. Each record is given a name and is followed by an indented list of key/value pairs in the '''"key: value"''' format. When you create a fixture, it generates an internal hash table. Fixtures are hash objects which can be accessed directly because it is automatically setup as a local variable for the test case. The good thing about this is that we can reference these objects using symbolic names. So if we were to declare a fixture called '''':cookie'''' (see example below), we could reference the entire cookie record simply by:
<pre>categories(:cookie)</pre>
This will return the hash for the fixture named cookie which corresponds to a row in the recipe table describing the recipe for that cookie.

On creating the model, the default fixtures generated are of the form:
<pre>
one:
title: MyString
description: MyString
instructions: MyText

two:
title: MyString
description: MyString
instructions: MyText
</pre>

We spoke of the :cookie fixture which would be defined as:
<pre>
cookie:
Title: Biscuit
Description: Round and Small
Instructions: Buy and bake them
</pre>
This allows us to access this entire record using the symbolic name ':cookie' which hashes to this particular fixture.

An important feature of YAML fixtures is that it supports Embedded Ruby i.e. we can embed ruby code into fixtures to generate a large set of sample data. For example:
<pre>
<% (1..1000).each do |i| %>
fix_<%= i %>:
name: category_<%= i %>
<% end %>
</pre>
This would create a thousand fixtures having symbolic names fix_1, fix_2 up to fix_1000, each one of them having a corresponding name attribute category_1, category_2 etc. This is a much better alternative than having to copy-paste the fixture fixture a thousand times.

A very important thing to remember about fixtures is that the ones which are generated by default by the scaffolds do not factor in for any foreign-key relationships that might be present in the models. Thus, such references have to be explicitly added to the fixture manually in order to reflect any 'has-many' or 'belongs-to' relationships across models.

==Unit Testing==
If the application was created using the scaffold command then it should create a stub in test/unit directory.The initial code would look something like this
<pre>
require 'test_helper'

class PostTest < ActiveSupport::TestCase
# Replace this with your real tests.
test "the truth" do
assert true
end
end
</pre>
Now if we wanted to add real tests to it then let us take two scenarios
1.Post with empty entries.
2.Post with actual entries
The code for these two test cases would look something like this
<pre>
require 'test_helper'

class PostTest < ActiveSupport::TestCase

test "Post new empty" do
p = Post.new
assert !p.save, "Saved post without title, content, user, or category"
assert p.invalid?
end

test "Post new correct" do
p = Post.new
#Post has following fields title,email,content
p.title = 'General title'
p.content = 'A new content'
p.email = 'Azrael@ncsu.edu'
#place an assert .so as to find out whether this statement is valid or not
assert p.valid?
end

end

</pre>
test_helper.rb contains the default configuration to run the tests,ActiveSupport::TestCase defines the basic methods for defining
a test case.The test cases must begin with the name "test". The statement that actually determines whether the test has passed or not is the assert statement.An assertion is a line of code that evaluates an object (or expression) for expected results.It can check a variety of things like is the expression true or false,is it valid etc. In this example, in the first test case we are checking whether p is an invalid object,if yes then the test has passed because that is the expected thing.Whereas the second test checks whether p is an valid object or not,if its not then the test fails as the expected output in this case is that p should be a valid object.

Here is another example where we try to test the functionality where a user tries to register with an already existing username
<pre>
test "username exists" do
user = User.new(:username => "abcdef", :password => "abcdef", :password_confirmation => "abcdef")
user.save
user1 =User.new(:username => "abcdef", :password => "abcdef", :password_confirmation => "abcdef")
assert_false user1.save
end
</pre>
Here, a user tries to add a post with a valid title but he leaves the content field blank.
<pre>
test "empty content test" do
post = Post.new( :title => "No content for this post",:content => nil )
post.User_id=1;
assert_false post.save
end
</pre>
==Functional Testing==
If unit tests covered models then functional tests took care of the controllers.The basic purpose of writing functional tests is to check if all the methods of a controller are working correctly. Since the controllers often influence the content of the web page (which is rendered by the corresponding method of a controller) functional tests are typically written to check if the controller’s method is rendering/redirecting to the correct page, whether or not the users are getting authenticated correctly, validating the correctness of the content displayed on the page,etc.Lets say we have a application where users are allowed to post and then comment on those posts.After the user has made a comment then he has to get redirected to that particular post page.Here is how the create method of the comment controller looks like
<pre>
def create
#@comment = Comment.new(params[:comment])
if(session[:email] == nil)
redirect_to :root
return
end
@comment = Comment.new
@comment.post_id = params[:id]
@comment.content = params[:content_new]
@comment.email = session[:email]
@comment.vote_count = 0

@post = Post.find(@comment.post_id)

dateTime = Time.new
timestamp = dateTime.to_time
@post.update_attributes(:updated_at => timestamp)

respond_to do |format|
if @comment.save
format.html { redirect_to :back }
format.json { render json: @comment, status: :created, location: @comment }
else
format.html { render action: "new" }
format.json { render json: @comment.errors, status: :unprocessable_entity }
end
end
end
</pre>
As it can be seen if no there is no session then no one can comment.If a user is successfully able to comment then he is redirected to the specific post page for which the comment was made.The functional test for this piece of code would look like this
<pre>
class CommentsControllerTest < ActionController::TestCase
setup do
@comment_new = Comment.new(:content => "Comment to create", :email => "test@gm.com", :post_id => 1)
@post = Post.find(@comment_new.post_id)
@comment = comments(:one)#The fixtures contain a row named one
end

test "should create comment" do
assert_difference('Comment.count') do
post :create, { content: @comment_new.content, email: @comment_new.email, post_id: @comment_new.post_id } #parameters that goes with the post request
end

assert_redirected_to post_path(assigns(:post))
end
end
</pre>
As we see from the code that it is important to set the session variable and also we need to know before hand for which post are we commenting so we set those variables in the setup method itself.Inside the test method we attempt to create a new comment and after that we check in the assert statement whether it has been redirected to the correct path which in this case is the post page for which the comment has been made.

Testing the response to your request by asserting the presence of key HTML elements and their content is a useful way to test the views of your application. The assert_select assertion allows you to do this by using a simple yet powerful syntax.

In the example below, we test the functionality upon deleting a user.
<pre>
test "should destroy user" do
assert_difference('User.count', -1) do
delete :destroy, id: @user
end
assert_redirected_to users_path
end
</pre>

==Integration Tests==
Typically in software development, different modules of a project are worked on by different teams/developers. Each team might ensure that the model works correctly in-itself, but this might not necessarily be the case when all the modules are coupled together as a single unit. This is where Integration tests come into play. They test the interaction between multiple controllers and all the components in a sequence, end-to-end. An example of it would be that of a shopping cart application. Even though different phases of the application may work correctly, while running integration tests, one might realize that the ''''add to cart'''' button is absent in the product-catalog, even though the add to cart functionality has been correctly implemented.

The default integration tests framework included in Test-Unit are very low level i.e. they deal with HTTP GET, POST requests responses, session objects, cookies, redirects etc. In ''Behavioral-Driven-Development'' we want to deal with the system on a higher level – similar to a user’s interaction with the system i.e. we want to deal only with clicks, with typing etc. Hence, we can use some of the popular Integration Testing frameworks like Capybara which is a GUI testing framework and allows one to specify - within a test - various actions like 'click' to click on a button, 'fill_in' to fill some text into a designated text-box etc. We can see that this is at a high level and somewhat analogous to actions an end-user might go through while using the application. So the rule of thumb while writing integration tests is to identify the end-users requirements and scope of interaction with the system, walk through the steps that they would take and mimic those in the form of tests. It is clearly evident how such [http://en.wikipedia.org/wiki/Behavior_Driven_Development Behavioral-Driven-Development] goes hand in hand with [http://en.wikipedia.org/wiki/Test-driven_development Test-Driven-Development] and helps in removing the ambiguities which are often associated with Customer Requirements.

The following example shows how the test framework '''CapyBara'''<ref>http://opinionated-programmer.com/2011/02/capybara-and-selenium-with-rspec-and-rails-3/</ref> is used for Integration Testing:
<pre>
test “create category from main page” do
visit categories_path
click_link “New category”
fill_in “category_name”, :with => “Sample Category”
click_button “Create Category”
end
</pre>
Here we have simulated a user-action (for the CookBook example) where the user would carry out the following steps:
# Visit the Categories Home Page (whose url is specified as categories_path by the routes.rb file)
# Click on the Link which says "New Category", which would lead to another page.
# On this new page, fill the text-box with some text, say "Sample Category"
# Click on the button that says "Create Category".
One can easily identify these actions from the code which is highly intuitive and self-explanatory. Capybara thus provides us with these convenient methods which greatly expedites the whole Integration Testing process.

To use the framework, simply include the corresponding gem in the Gemfile, and the following lines to the end of the ''test_helper.rb'' file.
<pre>
# Add more helper methods ...
require ‘capybara/rails’

class ActionDispatch::IntegrationTest
include Capybara::DSL
end
</pre>
The easy-to-use commands mentioned before are created by Capybara using a Domain Specific Language (DSL) and in order to be able to use it, every Integration test written must '''''require 'test_helper' '''''. This is basically a '''''mixin''''', so one still has the capability to access all the low-level GET/POST commands in Test-Unit in addition to all the methods offered by Capybara.

Another example of Integration Testing with Test-Framework '''RSpec Version 1.3.2'''<ref>http://rspec.info/documentation/</ref>:
<pre>
describe "Recipes" do

before(:all) do
@recipe = Recipe.new
end

it "should not accept empty recipe" do
@user.should_not_be_valid
@user.title = "Cookie"
@user.description = "Chocolate Chip Cookie"
@user.instructions = "Bake in Oven"
@user.category = 3
@user.should_be_valid
end

end
</pre>
In the above example we basically test that an empty recipe is invalid and that a recipe with fields filled out is valid. This is a very primitive example of using RSpec and it is just to showcase the difference between RSpec and Capybara, and is in no way a comprehensive example. A thing to note is the ''before(:all)'' method, which is similar to the setup() method in Java's JUnit Framework i.e. this method is called before every test in the ''describe'' block gets executed.

In sum, Integration tests are vital and are carried out in the final stages of testing to ensure that the system works as a cohesive and complete unit.

==Performance Tests==
Performance tests as the name indicates are used to gauge the performance of the system and play a very important role in software development for the simple reason that as a developer, one does not want the end user to have a poor experience while using the application. Users do not want to wait long for pages to load and elements on the page to respond. They are not - and should not - be concerned with the capability of the system to handle large loads, scale to accommodate increased volumes of traffic etc. Such details are abstracted away from the user, but they ''do'' have a significant impact on user's interaction with the system.

Rails Performance test can be categorized as a special type of integration tests, which are designed for bench-marking and profiling the test code<ref>http://guides.rubyonrails.org/performance_testing.html#modes</ref>. In these tests, one can mention how many connections are to be simulated to the server etc. at the outcome of which it would be possible to identify the performance bottlenecks and hopefully pinpoint the source of speed and/or memory problems.

Detailed examples can be found [http://guides.rubyonrails.org/performance_testing.html#examples Here].

==Conclusion==
Testing is an indispensable and an inevitable part of development in rails.It must be fully exploited to avail the benefits associated with Test-Driven-Development, for the simple reason that rails provides an excellent in-built framework upon which writing tests is a highly natural and intuitive process. There are many advantages to testing and many articles<ref>http://www.learn.geekinterview.com/programming/ruby/ruby-on-rails-application-testing.html</ref> have been written that emphasize this point.

==References==
<references/>

Most of the content for this article has been obtained from the Lecture taught in class which has been the primary resource. The video of the lecture can be found [http://mediasite.eos.ncsu.edu/Mediasite/Viewer/?peid=786d700dbc65460695f7f0abf9e8cfa71d here].

CSC/ECE 517 Fall 2012/ch1b 1w39 sn

2012-10-04T00:04:41Z

Npatowa:

<h2>Lecture 10 - Testing in Rails</h2>
__TOC__
==Introduction==
This article is a summary of [http://mediasite.eos.ncsu.edu/Mediasite/Viewer/?peid=786d700dbc65460695f7f0abf9e8cfa71d Lecture 10] '''"Testing in Rails"'''<ref>http://guides.rubyonrails.org/testing.html</ref> and it basically describes in detail the various types of tests in rails which one might encounter while developing a typical rails application. There are five components central to testing in rails: '''Fixtures''', '''Unit tests''', '''Functional tests''', '''Integration tests''' and '''Performance tests'''. These have been described below.
==Software Testing==
In the simplest terms, software testing can be summarized as follows. We provide some test inputs to the software and we get some test outputs from the software. Then we check if the output is acceptable or not. If the output is acceptable then the test case has passed, otherwise it has failed and we have to debug it. The hard part of doing software testing is selecting a good set of test inputs and designing good acceptability tests.

But while testing the software, we have to keep the following things in mind. We have to find bugs as early as possible. The earlier we find the bug, the cheaper it is to fix it.
Also, more testing is not always better. We may write a lot of test cases but they still may not cover every functionality of our software.
==Setup test environment in Rails==
<h4>In-Memory Databases:</h4>

Since all tests involve a high amount of database interaction, it is highly recommended to install the gem ''''memory_test_fix''''<ref>http://agilewebdevelopment.com/plugins/memory_test_fix</ref> which basically ([http://en.wikipedia.org/wiki/Monkey_patch monkey]) patches all tests in rails. This gem allows your tests to mock up a database within the memory, so that all reads/writes to the database executed by the test (when they run) are done to memory instead of the disk. This helps run all the unit tests a lot faster than what they would, if they were to read/write all their results to files (on the disk). It eliminates file locking issues on the test database when running on Windows. This is not a requirement, but it improves the speed of testing and development which is ultimately desirable. Most importantly it is good for testing because one usually does not need the data after the test is done, but only needs it during the lifetime of the test.

Make the following change to the ''''config/database.yml'''' file:
<pre>
test:
adapter: sqlite3
database: ":memory:"
</pre>
The change is that the ''''database:'''' field has been changed from:
<pre>db/development.sqlite3 to ":memory:"</pre>
This now ensures that for all the tests, the database used will be the one in memory and not in an actual Sqlite database.

<h4>Database Setup:</h4>
Rails provides a basic boiler plate to create tests.There are three environments provided by Rails - production,development and testing.As the names suggest they are used for different purposes.This prevents developers from messing with their development environments.Inside the rails app directory there will be a directory called test.This directory contains folders-unit,functional,integration and fixtures.The unit folder holds tests for the models, the functional folder is meant to hold tests for your controllers, and the integration folder contains tests that involve any number of controllers interacting.Fixtures contain the sample test data.Rails has the Test::Unit included by default but there are other frameworks also available like RSpec<ref>http://rspec.info/</ref>,Cucumber(for behavior driven development),Shoulda <ref>https://github.com/thoughtbot/shoulda#readme</ref>.When we create the rails scaffold for a particular model then it creates the directories unit,functional,integration which contains the different tests for the respective models.After the test cases have been written we need to prepare the test db.
<pre>
rake db:migrate
rake db:test:load
</pre>
This two commands should suffice but a complete reference of rake commands for testing purpose is mentioned in <ref>http://guides.rubyonrails.org/testing.html#preparing-your-application-for-testing</ref>
After preparing everything we are now ready to run our test.If you are using a Integrated Development Environment(IDE) like RubyMine then you need not worry anything and just do right click on the unit test folder->Select Run->All tests in unit.The figure provided below presents a better picture[[File:RunningTest.png]].

If you are using command line then you can use the following options
<pre>
ruby -Itest test/unit/post_test.rb
Loaded suite unit/post_test
Started
.
Finished in 0.023513 seconds.

2 tests, 2 assertions, 0 failures, 0 errors
</pre>

==Fixtures==
Rails tests are data-driven, which means that all of its tests need some sort of sample data to run on. Fixtures<ref>http://ar.rubyonrails.org/classes/Fixtures.html</ref> allow the tester to populate the testing database before any of the tests in the test folder can run. Fixtures have a file format which describes data structures in a human readable format and can be found under the 'test/fixtures' directory. When the rails [http://guides.rubyonrails.org/getting_started.html#generating-a-model generate model] is executed to create a new model, fixture stubs are automatically created and placed in that directory. YAML fixtures are stored in a single file per model i.e. for every model there is a corresponding fixture. Each record is given a name and is followed by an indented list of key/value pairs in the '''"key: value"''' format. When you create a fixture, it generates an internal hash table. Fixtures are hash objects which can be accessed directly because it is automatically setup as a local variable for the test case. The good thing about this is that we can reference these objects using symbolic names. So if we were to declare a fixture called '''':cookie'''' (see example below), we could reference the entire cookie record simply by:
<pre>categories(:cookie)</pre>
This will return the hash for the fixture named cookie which corresponds to a row in the recipe table describing the recipe for that cookie.

On creating the model, the default fixtures generated are of the form:
<pre>
one:
title: MyString
description: MyString
instructions: MyText

two:
title: MyString
description: MyString
instructions: MyText
</pre>

We spoke of the :cookie fixture which would be defined as:
<pre>
cookie:
Title: Biscuit
Description: Round and Small
Instructions: Buy and bake them
</pre>
This allows us to access this entire record using the symbolic name ':cookie' which hashes to this particular fixture.

An important feature of YAML fixtures is that it supports Embedded Ruby i.e. we can embed ruby code into fixtures to generate a large set of sample data. For example:
<pre>
<% (1..1000).each do |i| %>
fix_<%= i %>:
name: category_<%= i %>
<% end %>
</pre>
This would create a thousand fixtures having symbolic names fix_1, fix_2 up to fix_1000, each one of them having a corresponding name attribute category_1, category_2 etc. This is a much better alternative than having to copy-paste the fixture fixture a thousand times.

A very important thing to remember about fixtures is that the ones which are generated by default by the scaffolds do not factor in for any foreign-key relationships that might be present in the models. Thus, such references have to be explicitly added to the fixture manually in order to reflect any 'has-many' or 'belongs-to' relationships across models.

==Unit Testing==
If the application was created using the scaffold command then it should create a stub in test/unit directory.The initial code would look something like this
<pre>
require 'test_helper'

class PostTest < ActiveSupport::TestCase
# Replace this with your real tests.
test "the truth" do
assert true
end
end
</pre>
Now if we wanted to add real tests to it then let us take two scenarios
1.Post with empty entries.
2.Post with actual entries
The code for these two test cases would look something like this
<pre>
require 'test_helper'

class PostTest < ActiveSupport::TestCase

test "Post new empty" do
p = Post.new
assert !p.save, "Saved post without title, content, user, or category"
assert p.invalid?
end

test "Post new correct" do
p = Post.new
#Post has following fields title,email,content
p.title = 'General title'
p.content = 'A new content'
p.email = 'Azrael@ncsu.edu'
#place an assert .so as to find out whether this statement is valid or not
assert p.valid?
end

end

</pre>
test_helper.rb contains the default configuration to run the tests,ActiveSupport::TestCase defines the basic methods for defining
a test case.The test cases must begin with the name "test". The statement that actually determines whether the test has passed or not is the assert statement.An assertion is a line of code that evaluates an object (or expression) for expected results.It can check a variety of things like is the expression true or false,is it valid etc. In this example, in the first test case we are checking whether p is an invalid object,if yes then the test has passed because that is the expected thing.Whereas the second test checks whether p is an valid object or not,if its not then the test fails as the expected output in this case is that p should be a valid object.

Here is another example where we try to test the functionality where a user tries to register with an already existing username
<pre>
test "username exists" do
user = User.new(:username => "abcdef", :password => "abcdef", :password_confirmation => "abcdef")
user.save
user1 =User.new(:username => "abcdef", :password => "abcdef", :password_confirmation => "abcdef")
assert_false user1.save
end
</pre>
Here, a user tries to add a post with a valid title but he leaves the content field blank.
<pre>
test "empty content test" do
post = Post.new( :title => "No content for this post",:content => nil )
post.User_id=1;
assert_false post.save
end
</pre>
==Functional Testing==
If unit tests covered models then functional tests took care of the controllers.The basic purpose of writing functional tests is to check if all the methods of a controller are working correctly. Since the controllers often influence the content of the web page (which is rendered by the corresponding method of a controller) functional tests are typically written to check if the controller’s method is rendering/redirecting to the correct page, whether or not the users are getting authenticated correctly, validating the correctness of the content displayed on the page,etc.Lets say we have a application where users are allowed to post and then comment on those posts.After the user has made a comment then he has to get redirected to that particular post page.Here is how the create method of the comment controller looks like
<pre>
def create
#@comment = Comment.new(params[:comment])
if(session[:email] == nil)
redirect_to :root
return
end
@comment = Comment.new
@comment.post_id = params[:id]
@comment.content = params[:content_new]
@comment.email = session[:email]
@comment.vote_count = 0

@post = Post.find(@comment.post_id)

dateTime = Time.new
timestamp = dateTime.to_time
@post.update_attributes(:updated_at => timestamp)

respond_to do |format|
if @comment.save
format.html { redirect_to :back }
format.json { render json: @comment, status: :created, location: @comment }
else
format.html { render action: "new" }
format.json { render json: @comment.errors, status: :unprocessable_entity }
end
end
end
</pre>
As it can be seen if no there is no session then no one can comment.If a user is successfully able to comment then he is redirected to the specific post page for which the comment was made.The functional test for this piece of code would look like this
<pre>
class CommentsControllerTest < ActionController::TestCase
setup do
@comment_new = Comment.new(:content => "Comment to create", :email => "test@gm.com", :post_id => 1)
@post = Post.find(@comment_new.post_id)
@comment = comments(:one)#The fixtures contain a row named one
end

test "should create comment" do
assert_difference('Comment.count') do
post :create, { content: @comment_new.content, email: @comment_new.email, post_id: @comment_new.post_id } #parameters that goes with the post request
end

assert_redirected_to post_path(assigns(:post))
end
end
</pre>
As we see from the code that it is important to set the session variable and also we need to know before hand for which post are we commenting so we set those variables in the setup method itself.Inside the test method we attempt to create a new comment and after that we check in the assert statement whether it has been redirected to the correct path which in this case is the post page for which the comment has been made.

Testing the response to your request by asserting the presence of key HTML elements and their content is a useful way to test the views of your application. The assert_select assertion allows you to do this by using a simple yet powerful syntax.

In the example below, we test the functionality upon deleting a user.
<pre>
test "should destroy user" do
assert_difference('User.count', -1) do
delete :destroy, id: @user
end
assert_redirected_to users_path
end
</pre>

==Integration Tests==
Typically in software development, different modules of a project are worked on by different teams/developers. Each team might ensure that the model works correctly in-itself, but this might not necessarily be the case when all the modules are coupled together as a single unit. This is where Integration tests come into play. They test the interaction between multiple controllers and all the components in a sequence, end-to-end. An example of it would be that of a shopping cart application. Even though different phases of the application may work correctly, while running integration tests, one might realize that the ''''add to cart'''' button is absent in the product-catalog, even though the add to cart functionality has been correctly implemented.

The default integration tests framework included in Test-Unit are very low level i.e. they deal with HTTP GET, POST requests responses, session objects, cookies, redirects etc. In ''Behavioral-Driven-Development'' we want to deal with the system on a higher level – similar to a user’s interaction with the system i.e. we want to deal only with clicks, with typing etc. Hence, we can use some of the popular Integration Testing frameworks like Capybara which is a GUI testing framework and allows one to specify - within a test - various actions like 'click' to click on a button, 'fill_in' to fill some text into a designated text-box etc. We can see that this is at a high level and somewhat analogous to actions an end-user might go through while using the application. So the rule of thumb while writing integration tests is to identify the end-users requirements and scope of interaction with the system, walk through the steps that they would take and mimic those in the form of tests. It is clearly evident how such [http://en.wikipedia.org/wiki/Behavior_Driven_Development Behavioral-Driven-Development] goes hand in hand with [http://en.wikipedia.org/wiki/Test-driven_development Test-Driven-Development] and helps in removing the ambiguities which are often associated with Customer Requirements.

The following example shows how the test framework '''CapyBara'''<ref>http://opinionated-programmer.com/2011/02/capybara-and-selenium-with-rspec-and-rails-3/</ref> is used for Integration Testing:
<pre>
test “create category from main page” do
visit categories_path
click_link “New category”
fill_in “category_name”, :with => “Sample Category”
click_button “Create Category”
end
</pre>
Here we have simulated a user-action (for the CookBook example) where the user would carry out the following steps:
# Visit the Categories Home Page (whose url is specified as categories_path by the routes.rb file)
# Click on the Link which says "New Category", which would lead to another page.
# On this new page, fill the text-box with some text, say "Sample Category"
# Click on the button that says "Create Category".
One can easily identify these actions from the code which is highly intuitive and self-explanatory. Capybara thus provides us with these convenient methods which greatly expedites the whole Integration Testing process.

To use the framework, simply include the corresponding gem in the Gemfile, and the following lines to the end of the ''test_helper.rb'' file.
<pre>
# Add more helper methods ...
require ‘capybara/rails’

class ActionDispatch::IntegrationTest
include Capybara::DSL
end
</pre>
The easy-to-use commands mentioned before are created by Capybara using a Domain Specific Language (DSL) and in order to be able to use it, every Integration test written must '''''require 'test_helper' '''''. This is basically a '''''mixin''''', so one still has the capability to access all the low-level GET/POST commands in Test-Unit in addition to all the methods offered by Capybara.

Another example of Integration Testing with Test-Framework '''RSpec Version 1.3.2'''<ref>http://rspec.info/documentation/</ref>:
<pre>
describe "Recipes" do

before(:all) do
@recipe = Recipe.new
end

it "should not accept empty recipe" do
@user.should_not_be_valid
@user.title = "Cookie"
@user.description = "Chocolate Chip Cookie"
@user.instructions = "Bake in Oven"
@user.category = 3
@user.should_be_valid
end

end
</pre>
In the above example we basically test that an empty recipe is invalid and that a recipe with fields filled out is valid. This is a very primitive example of using RSpec and it is just to showcase the difference between RSpec and Capybara, and is in no way a comprehensive example. A thing to note is the ''before(:all)'' method, which is similar to the setup() method in Java's JUnit Framework i.e. this method is called before every test in the ''describe'' block gets executed.

In sum, Integration tests are vital and are carried out in the final stages of testing to ensure that the system works as a cohesive and complete unit.

==Performance Tests==
Performance tests as the name indicates are used to gauge the performance of the system and play a very important role in software development for the simple reason that as a developer, one does not want the end user to have a poor experience while using the application. Users do not want to wait long for pages to load and elements on the page to respond. They are not - and should not - be concerned with the capability of the system to handle large loads, scale to accommodate increased volumes of traffic etc. Such details are abstracted away from the user, but they ''do'' have a significant impact on user's interaction with the system.

Rails Performance test can be categorized as a special type of integration tests, which are designed for bench-marking and profiling the test code<ref>http://guides.rubyonrails.org/performance_testing.html#modes</ref>. In these tests, one can mention how many connections are to be simulated to the server etc. at the outcome of which it would be possible to identify the performance bottlenecks and hopefully pinpoint the source of speed and/or memory problems.

Detailed examples can be found [http://guides.rubyonrails.org/performance_testing.html#examples Here].

==Conclusion==
Testing is an indispensable and an inevitable part of development in rails.It must be fully exploited to avail the benefits associated with Test-Driven-Development, for the simple reason that rails provides an excellent in-built framework upon which writing tests is a highly natural and intuitive process. There are many advantages to testing and many articles<ref>http://www.learn.geekinterview.com/programming/ruby/ruby-on-rails-application-testing.html</ref> have been written that emphasize this point.

==References==
<references/>

Most of the content for this article has been obtained from the Lecture taught in class which has been the primary resource. The video of the lecture can be found [http://mediasite.eos.ncsu.edu/Mediasite/Viewer/?peid=786d700dbc65460695f7f0abf9e8cfa71d here].

CSC/ECE 517 Fall 2012/ch1b 1w39 sn

2012-10-04T00:03:26Z

Npatowa:

CSC/ECE 517 Fall 2012/ch1b 1w39 sn

2012-10-04T00:01:55Z

Npatowa:

CSC/ECE 517 Fall 2012/ch1b 1w39 sn

2012-10-01T06:42:06Z

Npatowa:

<h2>Lecture 10 - Testing in Rails</h2>

==Setup test environment in Rails==
Rails provides a basic boiler plate to create tests.There are three environments provided by Rails - production,development and testing.As the names suggest they are used for different purposes.This prevents developers from messing with their development environments.Inside the rails app directory there will be a directory called test.This directory contains folders-unit,functional,integration and fixtures.The unit folder holds tests for the models, the functional folder is meant to hold tests for your controllers, and the integration folder contains tests that involve any number of controllers interacting.Fixtures contain the sample test data.Rails has the Test::Unit included by default but there are other frameworks also available like RSpec<ref>http://rspec.info/</ref>,Cucumber(for behavior driven development),Shoulda <ref>https://github.com/thoughtbot/shoulda#readme</ref>.When we create the rails scaffold for a particular model then it creates the directories unit,functional,integration which contains the different tests for the respective models.After the test cases have been written we need to prepare the test db.
<pre>
rake db:migrate
rake db:test:load
</pre>
This two commands should suffice but a complete reference of rake commands for testing purpose is mentioned in <ref>http://guides.rubyonrails.org/testing.html#preparing-your-application-for-testing</ref>
After preparing everything we are now ready to run our test.If you are using a Integrated Development Environment(IDE) like RubyMine then you need not worry anything and just do right click on the unit test folder->Select Run->All tests in unit.The figure provided below presents a better picture[[File:RunningTest.png]].

If you are using command line then you can use the following options
<pre>
ruby -Itest test/unit/post_test.rb
Loaded suite unit/post_test
Started
.
Finished in 0.023513 seconds.

2 tests, 2 assertions, 0 failures, 0 errors
</pre>

<h4>Unit Testing:</h4>
If the application was created using the scaffold command then it should create a stub in test/unit directory.The initial code would look something like this
<pre>
require 'test_helper'

class PostTest < ActiveSupport::TestCase
# Replace this with your real tests.
test "the truth" do
assert true
end
end
</pre>
Now if we wanted to add real tests to it then let us take two scenarios
1.Post with empty entries.
2.Post with actual entries
The code for these two test cases would look something like this
<pre>
require 'test_helper'

class PostTest < ActiveSupport::TestCase

test "Post new empty" do
p = Post.new
assert !p.save, "Saved post without title, content, user, or category"
assert p.invalid?
end

test "Post new correct" do
p = Post.new
#Post has following fields title,email,content
p.title = 'General title'
p.content = 'A new content'
p.email = 'Azrael@ncsu.edu'
#place an assert .so as to find out whether this statement is valid or not
assert p.valid?
end

end

</pre>
test_helper.rb contains the default configuration to run the tests,ActiveSupport::TestCase defines the basic methods for defining
a test case.The test cases must begin with the name "test". The statement that actually determines whether the test has passed or not is the assert statement.An assertion is a line of code that evaluates an object (or expression) for expected results.It can check a variety of things like is the expression true or false,is it valid etc. In this example, in the first test case we are checking whether p is an invalid object,if yes then the test has passed because that is the expected thing.Whereas the second test checks whether p is an valid object or not,if its not then the test fails as the expected output in this case is that p should be a valid object.
<h4>Functional Testing</h4>
If unit tests covered models then functional tests took care of the controllers.The basic purpose of writing functional tests is to check if all the methods of a controller are working correctly. Since the controllers often influence the content of the web page (which is rendered by the corresponding method of a controller) functional tests are typically written to check if the controller’s method is rendering/redirecting to the correct page, whether or not the users are getting authenticated correctly, validating the correctness of the content displayed on the page,etc.Lets say we have a application where users are allowed to post and then comment on those posts.After the user has made a comment then he has to get redirected to that particular post page.Here is how the create method of the comment controller looks like
<pre>
def create
#@comment = Comment.new(params[:comment])
if(session[:email] == nil)
redirect_to :root
return
end
@comment = Comment.new
@comment.post_id = params[:id]
@comment.content = params[:content_new]
@comment.email = session[:email]
@comment.vote_count = 0

@post = Post.find(@comment.post_id)

dateTime = Time.new
timestamp = dateTime.to_time
@post.update_attributes(:updated_at => timestamp)

respond_to do |format|
if @comment.save
format.html { redirect_to :back }
format.json { render json: @comment, status: :created, location: @comment }
else
format.html { render action: "new" }
format.json { render json: @comment.errors, status: :unprocessable_entity }
end
end
end
</pre>
As it can be seen if no there is no session then no one can comment.If a user is successfully able to comment then he is redirected to the specific post page for which the comment was made.The functional test for this piece of code would look like this
<pre>
class CommentsControllerTest < ActionController::TestCase
setup do
@comment_new = Comment.new(:content => "Comment to create", :email => "test@gm.com", :post_id => 1)
@post = Post.find(@comment_new.post_id)
@comment = comments(:one)#The fixtures contain a row named one
end

test "should create comment" do
assert_difference('Comment.count') do
post :create, { content: @comment_new.content, email: @comment_new.email, post_id: @comment_new.post_id } #parameters that goes with the post request
end

assert_redirected_to post_path(assigns(:post))
end
end
</pre>
As we see from the code that it is important to set the session variable and also we need to know before hand for which post are we commenting so we set those variables in the setup method itself.Inside the test method we attempt to create a new comment and after that we check in the assert statement whether it has been redirected to the correct path which in this case is the post page for which the comment has been made.

Testing the response to your request by asserting the presence of key HTML elements and their content is a useful way to test the views of your application. The assert_select assertion allows you to do this by using a simple yet powerful syntax.

CSC/ECE 517 Fall 2012/ch1b 1w39 sn

2012-10-01T06:40:22Z

Npatowa:

<h2>Lecture 10 - Testing in Rails</h2>

==Setup test environment in Rails==
Rails provides a basic boiler plate to create tests.There are three environments provided by Rails - production,development and testing.As the names suggest they are used for different purposes.This prevents developers from messing with their development environments.Inside the rails app directory there will be a directory called test.This directory contains folders-unit,functional,integration and fixtures.The unit folder holds tests for the models, the functional folder is meant to hold tests for your controllers, and the integration folder contains tests that involve any number of controllers interacting.Fixtures contain the sample test data.Rails has the Test::Unit included by default but there are other frameworks also available like RSpec<ref>http://rspec.info/</ref>,Cucumber(for behavior driven development),Shoulda <ref>https://github.com/thoughtbot/shoulda#readme</ref>.When we create the rails scaffold for a particular model then it creates the directories unit,functional,integration which contains the different tests for the respective models.After the test cases have been written there are a few things we need to prepare the test db.
<pre>
rake db:migrate
rake db:test:load
</pre>
This two commands should suffice but a complete reference of rake commands for testing purpose is mentioned in <ref>http://guides.rubyonrails.org/testing.html#preparing-your-application-for-testing</ref>
After preparing everything we are now ready to run our test.If you are using a Integrated Development Environment(IDE) like RubyMine then you need not worry anything and just do right click on the unit test folder->Select Run->All tests in unit.The figure provided below presents a better picture[[File:RunningTest.png]].

If you are using command line then you can use the following options
<pre>
ruby -Itest test/unit/post_test.rb
Loaded suite unit/post_test
Started
.
Finished in 0.023513 seconds.

2 tests, 2 assertions, 0 failures, 0 errors
</pre>

<h4>Unit Testing:</h4>
If the application was created using the scaffold command then it should create a stub in test/unit directory.The initial code would look something like this
<pre>
require 'test_helper'

class PostTest < ActiveSupport::TestCase
# Replace this with your real tests.
test "the truth" do
assert true
end
end
</pre>
Now if we wanted to add real tests to it then let us take two scenarios
1.Post with empty entries.
2.Post with actual entries
The code for these two test cases would look something like this
<pre>
require 'test_helper'

class PostTest < ActiveSupport::TestCase

test "Post new empty" do
p = Post.new
assert !p.save, "Saved post without title, content, user, or category"
assert p.invalid?
end

test "Post new correct" do
p = Post.new
#Post has following fields title,email,content
p.title = 'General title'
p.content = 'A new content'
p.email = 'Azrael@ncsu.edu'
#place an assert .so as to find out whether this statement is valid or not
assert p.valid?
end

end

</pre>
test_helper.rb contains the default configuration to run the tests,ActiveSupport::TestCase defines the basic methods for defining
a test case.The test cases must begin with the name "test". The statement that actually determines whether the test has passed or not is the assert statement.An assertion is a line of code that evaluates an object (or expression) for expected results.It can check a variety of things like is the expression true or false,is it valid etc. In this example, in the first test case we are checking whether p is an invalid object,if yes then the test has passed because that is the expected thing.Whereas the second test checks whether p is an valid object or not,if its not then the test fails as the expected output in this case is that p should be a valid object.
<h4>Functional Testing</h4>
If unit tests covered models then functional tests took care of the controllers.The basic purpose of writing functional tests is to check if all the methods of a controller are working correctly. Since the controllers often influence the content of the web page (which is rendered by the corresponding method of a controller) functional tests are typically written to check if the controller’s method is rendering/redirecting to the correct page, whether or not the users are getting authenticated correctly, validating the correctness of the content displayed on the page,etc.Lets say we have a application where users are allowed to post and then comment on those posts.After the user has made a comment then he has to get redirected to that particular post page.Here is how the create method of the comment controller looks like
<pre>
def create
#@comment = Comment.new(params[:comment])
if(session[:email] == nil)
redirect_to :root
return
end
@comment = Comment.new
@comment.post_id = params[:id]
@comment.content = params[:content_new]
@comment.email = session[:email]
@comment.vote_count = 0

@post = Post.find(@comment.post_id)

dateTime = Time.new
timestamp = dateTime.to_time
@post.update_attributes(:updated_at => timestamp)

respond_to do |format|
if @comment.save
format.html { redirect_to :back }
format.json { render json: @comment, status: :created, location: @comment }
else
format.html { render action: "new" }
format.json { render json: @comment.errors, status: :unprocessable_entity }
end
end
end
</pre>
As it can be seen if no there is no session then no one can comment.If a user is successfully able to comment then he is redirected to the specific post page for which the comment was made.The functional test for this piece of code would look like this
<pre>
class CommentsControllerTest < ActionController::TestCase
setup do
@comment_new = Comment.new(:content => "Comment to create", :email => "test@gm.com", :post_id => 1)
@post = Post.find(@comment_new.post_id)
@comment = comments(:one)#The fixtures contain a row named one
end

test "should create comment" do
assert_difference('Comment.count') do
post :create, { content: @comment_new.content, email: @comment_new.email, post_id: @comment_new.post_id } #parameters that goes with the post request
end

assert_redirected_to post_path(assigns(:post))
end
end
</pre>
As we see from the code that it is important to set the session variable and also we need to know before hand for which post are we commenting so we set those variables in the setup method itself.Inside the test method we attempt to create a new comment and after that we check in the assert statement whether it has been redirected to the correct path which in this case is the post page for which the comment has been made.

Testing the response to your request by asserting the presence of key HTML elements and their content is a useful way to test the views of your application. The assert_select assertion allows you to do this by using a simple yet powerful syntax.

CSC/ECE 517 Fall 2012/ch1b 1w39 sn

2012-09-30T07:28:27Z

Npatowa:

<h2>Lecture 10 - Testing in Rails</h2>

==Setup test environment in Rails==
Rails provides a basic boiler plate to create tests.There are three environments provided by Rails - production,development and testing.As the names suggest they are used for different purposes.This prevents developers from messing with their development environments.Inside the rails app directory there will be a directory called test.This directory contains folders-unit,functional,integration and fixtures.The unit folder holds tests for the models, the functional folder is meant to hold tests for your controllers, and the integration folder contains tests that involve any number of controllers interacting.Fixtures contain the sample test data.Rails has the Test::Unit included by default but there are other frameworks also available like RSpec<ref>http://rspec.info/</ref>,Cucumber(for behavior driven development),Shoulda <ref>https://github.com/thoughtbot/shoulda#readme</ref>
<h4>Unit Testing:</h4>
If the application was created using the scaffold command then it should create a stub in test/unit directory.The initial code would look something like this
<pre>
require 'test_helper'

class PostTest < ActiveSupport::TestCase
# Replace this with your real tests.
test "the truth" do
assert true
end
end
</pre>
Now if we wanted to add real tests to it then let us take two scenarios
1.Post with empty entries.
2.Post with actual entries
The code for these two test cases would look something like this
<pre>
require 'test_helper'

class PostTest < ActiveSupport::TestCase

test "Post new empty" do
p = Post.new
assert !p.save, "Saved post without title, content, user, or category"
assert p.invalid?
end

test "Post new correct" do
p = Post.new
#Post has following fields title,email,content
p.title = 'General title'
p.content = 'A new content'
p.email = 'Azrael@ncsu.edu'
#place an assert .so as to find out whether this statement is valid or not
assert p.valid?
end

end

</pre>
test_helper.rb contains the default configuration to run the tests,ActiveSupport::TestCase defines the basic methods for defining
a test case.The test cases must begin with the name "test". The statement that actually determines whether the test has passed or not is the assert statement.An assertion is a line of code that evaluates an object (or expression) for expected results.It can check a variety of things like is the expression true or false,is it valid etc. In this example, in the first test case we are checking whether p is an invalid object,if yes then the test has passed because that is the expected thing.Whereas the second test checks whether p is an valid object or not,if its not then the test fails as the expected output in this case is that p should be a valid object. After the test cases have been written there are a few things we need to prepare the test db.
<pre>
rake db:migrate
rake db:test:load
</pre>
This two commands should suffice but a complete reference of rake commands for testing purpose is mentioned in <ref>http://guides.rubyonrails.org/testing.html#preparing-your-application-for-testing</ref>
After preparing everything we are now ready to run our test.If you are using a Integrated Development Environment(IDE) like RubyMine then you need not worry anything and just do right click on the unit test folder->Select Run->All tests in unit.The figure provided below presents a better picture[[File:RunningTest.png]].

If you are using command line then you can use the following options
<pre>
ruby -Itest test/unit/post_test.rb
Loaded suite unit/post_test
Started
.
Finished in 0.023513 seconds.

2 tests, 2 assertions, 0 failures, 0 errors
</pre>
<h4>Functional Testing</h4>
If unit tests covered models then functional tests took care of the controllers.The basic purpose of writing functional tests is to check if all the methods of a controller are working correctly. Since the controllers often influence the content of the web page (which is rendered by the corresponding method of a controller) functional tests are typically written to check if the controller’s method is rendering/redirecting to the correct page, whether or not the users are getting authenticated correctly, validating the correctness of the content displayed on the page,etc.Lets say we have a application where users are allowed to post and then comment on those posts.After the user has made a comment then he has to get redirected to that particular post page.Here is how the create method of the comment controller looks like
<pre>
def create
#@comment = Comment.new(params[:comment])
if(session[:email] == nil)
redirect_to :root
return
end
@comment = Comment.new
@comment.post_id = params[:id]
@comment.content = params[:content_new]
@comment.email = session[:email]
@comment.vote_count = 0

@post = Post.find(@comment.post_id)

dateTime = Time.new
timestamp = dateTime.to_time
@post.update_attributes(:updated_at => timestamp)

respond_to do |format|
if @comment.save
format.html { redirect_to :back }
format.json { render json: @comment, status: :created, location: @comment }
else
format.html { render action: "new" }
format.json { render json: @comment.errors, status: :unprocessable_entity }
end
end
end
</pre>
As it can be seen if no there is no session then no one can comment.If a user is successfully able to comment then he is redirected to the specific post page for which the comment was made.The functional test for this piece of code would look like this
<pre>
class CommentsControllerTest < ActionController::TestCase
setup do
@comment_new = Comment.new(:content => "Comment to create", :email => "test@gm.com", :post_id => 1)
@post = Post.find(@comment_new.post_id)
@comment = comments(:one)#The fixtures contain a row named one
end

test "should create comment" do
assert_difference('Comment.count') do
post :create, { content: @comment_new.content, email: @comment_new.email, post_id: @comment_new.post_id } #parameters that goes with the post request
end

assert_redirected_to post_path(assigns(:post))
end
end
</pre>
As we see from the code that it is important to set the session variable and also we need to know before hand for which post are we commenting so we set those variables in the setup method itself.Inside the test method we attempt to create a new comment and after that we check in the assert statement whether it has been redirected to the correct path which in this case is the post page for which the comment has been made.

Testing the response to your request by asserting the presence of key HTML elements and their content is a useful way to test the views of your application. The assert_select assertion allows you to do this by using a simple yet powerful syntax.

CSC/ECE 517 Fall 2012/ch1b 1w39 sn

2012-09-30T06:57:28Z

Npatowa:

<h2>Lecture 10 - Testing in Rails</h2>

==Setup test environment in Rails==
Rails provides a basic boiler plate to create tests.There are three environments provided by Rails - production,development and testing.As the names suggest they are used for different purposes.This prevents developers from messing with their development environments.Inside the rails app directory there will be a directory called test.This directory contains folders-unit,functional,integration and fixtures.The unit folder holds tests for the models, the functional folder is meant to hold tests for your controllers, and the integration folder contains tests that involve any number of controllers interacting.Fixtures contain the sample test data.Rails has the Test::Unit included by default but there are other frameworks also available like RSpec<ref>http://rspec.info/</ref>,Cucumber(for behavior driven development),Shoulda <ref>https://github.com/thoughtbot/shoulda#readme</ref>
<h4>Unit Testing:</h4>
If the application was created using the scaffold command then it should create a stub in test/unit directory.The initial code would look something like this
<pre>
require 'test_helper'

class PostTest < ActiveSupport::TestCase
# Replace this with your real tests.
test "the truth" do
assert true
end
end
</pre>
Now if we wanted to add real tests to it then let us take two scenarios
1.Post with empty entries.
2.Post with actual entries
The code for these two test cases would look something like this
<pre>
require 'test_helper'

class PostTest < ActiveSupport::TestCase

test "Post new empty" do
p = Post.new
assert !p.save, "Saved post without title, content, user, or category"
assert p.invalid?
end

test "Post new correct" do
p = Post.new
#Post has following fields title,email,content
p.title = 'General title'
p.content = 'A new content'
p.email = 'Azrael@ncsu.edu'
#place an assert .so as to find out whether this statement is valid or not
assert p.valid?
end

end

</pre>
test_helper.rb contains the default configuration to run the tests,ActiveSupport::TestCase defines the basic methods for defining
a test case.The test cases must begin with the name "test". The statement that actually determines whether the test has passed or not is the assert statement.An assertion is a line of code that evaluates an object (or expression) for expected results.It can check a variety of things like is the expression true or false,is it valid etc. In this example, in the first test case we are checking whether p is an invalid object,if yes then the test has passed because that is the expected thing.Whereas the second test checks whether p is an valid object or not,if its not then the test fails as the expected output in this case is that p should be a valid object. After the test cases have been written there are a few things we need to prepare the test db.
<pre>
rake db:migrate
rake db:test:load
</pre>
This two commands should suffice but a complete reference of rake commands for testing purpose is mentioned in <ref>http://guides.rubyonrails.org/testing.html#preparing-your-application-for-testing</ref>
After preparing everything we are now ready to run our test.If you are using a Integrated Development Environment(IDE) like RubyMine then you need not worry anything and just do right click on the unit test folder->Select Run->All tests in unit.The figure provided below presents a better picture[[File:RunningTest.png]].

If you are using command line then you can use the following options
<pre>
ruby -Itest test/unit/post_test.rb
Loaded suite unit/post_test
Started
.
Finished in 0.023513 seconds.

2 tests, 2 assertions, 0 failures, 0 errors
</pre>
<h4>Functional Testing</h4>
If unit tests covered models then functional tests took care of the controllers.The basic purpose of writing functional tests is to check if all the methods of a controller are working correctly. Since the controllers often influence the content of the web page (which is rendered by the corresponding method of a controller) functional tests are typically written to check if the controller’s method is rendering/redirecting to the correct page, whether or not the users are getting authenticated correctly, validating the correctness of the content displayed on the page,etc.Lets say we have a application where users are allowed to post and then comment on those posts.After the user has made a comment then he has to get redirected to that particular post page.Here is how the create method of the comment controller looks like
<pre>
def create
#@comment = Comment.new(params[:comment])
if(session[:email] == nil)
redirect_to :root
return
end
@comment = Comment.new
@comment.post_id = params[:id]
@comment.content = params[:content_new]
@comment.email = session[:email]
@comment.vote_count = 0

@post = Post.find(@comment.post_id)

dateTime = Time.new
timestamp = dateTime.to_time
@post.update_attributes(:updated_at => timestamp)

respond_to do |format|
if @comment.save
format.html { redirect_to :back }
format.json { render json: @comment, status: :created, location: @comment }
else
format.html { render action: "new" }
format.json { render json: @comment.errors, status: :unprocessable_entity }
end
end
end
</pre>
As it can be seen if no there is no session then no one can comment.If a user is successfully able to comment then he is redirected to the specific post page for which the comment was made.The functional test for this piece of code would look like this
<pre>
class CommentsControllerTest < ActionController::TestCase
setup do
@commentNew = Comment.new(:content => "Comment to create", :email => "test@gm.com", :post_id => 1)
@comment = comments(:one)
end

test "should create comment" do
assert_difference('Comment.count') do
post :create, comment: { content: @commentNew.content, email: @commentNew.email, post_id: @commentNew.post_id }
end

assert_redirected_to comment_path(assigns(:comment))
end
end
</pre>

CSC/ECE 517 Fall 2012/ch1b 1w39 sn

2012-09-30T06:30:12Z

Npatowa:

<h2>Lecture 10 - Testing in Rails</h2>

==Setup test environment in Rails==
Rails provides a basic boiler plate to create tests.There are three environments provided by Rails - production,development and testing.As the names suggest they are used for different purposes.This prevents developers from messing with their development environments.Inside the rails app directory there will be a directory called test.This directory contains folders-unit,functional,integration and fixtures.The unit folder holds tests for the models, the functional folder is meant to hold tests for your controllers, and the integration folder contains tests that involve any number of controllers interacting.Fixtures contain the sample test data.Rails has the Test::Unit included by default but there are other frameworks also available like RSpec<ref>http://rspec.info/</ref>,Cucumber(for behavior driven development),Shoulda <ref>https://github.com/thoughtbot/shoulda#readme</ref>
<h4>Unit Testing:</h4>
If the application was created using the scaffold command then it should create a stub in test/unit directory.The initial code would look something like this
<pre>
require 'test_helper'

class PostTest < ActiveSupport::TestCase
# Replace this with your real tests.
test "the truth" do
assert true
end
end
</pre>
Now if we wanted to add real tests to it then let us take two scenarios
1.Post with empty entries.
2.Post with actual entries
The code for these two test cases would look something like this
<pre>
require 'test_helper'

class PostTest < ActiveSupport::TestCase

test "Post new empty" do
p = Post.new
assert !p.save, "Saved post without title, content, user, or category"
assert p.invalid?
end

test "Post new correct" do
p = Post.new
#Post has following fields title,email,content
p.title = 'General title'
p.content = 'A new content'
p.email = 'Azrael@ncsu.edu'
#place an assert .so as to find out whether this statement is valid or not
assert p.valid?
end

end

</pre>
test_helper.rb contains the default configuration to run the tests,ActiveSupport::TestCase defines the basic methods for defining
a test case.The test cases must begin with the name "test". The statement that actually determines whether the test has passed or not is the assert statement.An assertion is a line of code that evaluates an object (or expression) for expected results.It can check a variety of things like is the expression true or false,is it valid etc. In this example, in the first test case we are checking whether p is an invalid object,if yes then the test has passed because that is the expected thing.Whereas the second test checks whether p is an valid object or not,if its not then the test fails as the expected output in this case is that p should be a valid object. After the test cases have been written there are a few things we need to prepare the test db.
<pre>
rake db:migrate
rake db:test:load
</pre>
This two commands should suffice but a complete reference of rake commands for testing purpose is mentioned in <ref>http://guides.rubyonrails.org/testing.html#preparing-your-application-for-testing</ref>
After preparing everything we are now ready to run our test.If you are using a Integrated Development Environment(IDE) like RubyMine then you need not worry anything and just do right click on the unit test folder->Select Run->All tests in unit.The figure provided below presents a better picture[[File:RunningTest.png]].

If you are using command line then you can use the following options
<pre>
ruby -Itest test/unit/post_test.rb
Loaded suite unit/post_test
Started
.
Finished in 0.023513 seconds.

2 tests, 2 assertions, 0 failures, 0 errors
</pre>
<h4>Functional Testing</h4>
If unit tests covered models then functional tests took care of the controllers.The basic purpose of writing functional tests is to check if all the methods of a controller are working correctly. Since the controllers often influence the content of the web page (which is rendered by the corresponding method of a controller) functional tests are typically written to check if the controller’s method is rendering/redirecting to the correct page, whether or not the users are getting authenticated correctly, validating the correctness of the content displayed on the page,etc.Lets say we have a application where users are allowed to post and then comment on those posts.After the user has made a comment then he has to get redirected to that particular post page.Here is how the create method of the comment controller looks like
<pre>
def create
#@comment = Comment.new(params[:comment])
if(session[:email] == nil)
redirect_to :root
return
end
@comment = Comment.new
@comment.post_id = params[:id]
@comment.content = params[:content_new]
@comment.email = session[:email]
@comment.vote_count = 0

@post = Post.find(@comment.post_id)

dateTime = Time.new
timestamp = dateTime.to_time
@post.update_attributes(:updated_at => timestamp)

respond_to do |format|
if @comment.save
format.html { redirect_to :back }
format.json { render json: @comment, status: :created, location: @comment }
else
format.html { render action: "new" }
format.json { render json: @comment.errors, status: :unprocessable_entity }
end
end
end
</pre>

CSC/ECE 517 Fall 2012/ch1b 1w39 sn

2012-09-30T05:59:34Z

Npatowa:

CSC/ECE 517 Fall 2012/ch1b 1w39 sn

2012-09-30T02:30:17Z

Npatowa:

CSC/ECE 517 Fall 2012/ch1b 1w39 sn

2012-09-30T02:27:53Z

Npatowa:

File:RunningTest.png

2012-09-30T02:22:59Z

Npatowa: uploaded a new version of "File:RunningTest.png"

CSC/ECE 517 Fall 2012/ch1b 1w39 sn

2012-09-30T02:12:43Z

Npatowa:

File:RunningTest.png

2012-09-30T02:12:01Z

Npatowa:

CSC/ECE 517 Fall 2012/ch1b 1w39 sn

2012-09-29T08:01:38Z

Npatowa:

CSC/ECE 517 Fall 2012/ch1b 1w39 sn

2012-09-29T07:03:48Z

Npatowa: