Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2012/ch2b 2w62 pv

2012-11-20T03:27:46Z

Pvasude: /* Implementation */

=Memento, directory of sites=
The objective of this wiki is to provide a directory of sites that one would refer to while learning about the Memento pattern. This wiki will be giving an overview of the different features of the Memento pattern along with links to useful websites that explain each of these features in more detail.

__TOC__

== Introduction ==
The memento pattern is a pattern that provides the ability to restore an object to its previous state(via rollback). The memento pattern is implemented with two objects: the originator and a caretaker. The originator is some object that has an internal state. The caretaker is going to do something to the originator, but wants to be able to undo the change. The caretaker first asks the originator for a memento object. Then it does whatever operation it was going to do. To roll back to the state before the operations, it returns the memento object to the originator.

== Motivation ==
It is sometimes necessary to capture the internal state of an object at some point and have the ability to restore the object to that state later in time. Such a case is useful in case of error or failure. Consider the case of a calculator object with an undo operation such a calculator could simply maintain a list of all previous operation that it has performed and thus would be able to restore a previous calculation it has performed. This would cause the calculator object to become larger, more complex, and heavyweight, as the calculator object would have to provide additional undo functionality and should maintain a list of all previous operations. This functionality can be moved out of the calculator class, so that an external (let's call it undo manager class) can collect the internal state of the calculator and save it. However providing the explicit access to every state variable of the calculator to the restore manager would be impractical and would violate the encapsulation principle.

== Implementation ==
<ref name="implementation"> http://www.oodesign.com/memento-pattern.html </ref>
Memento
Stores internal state of the Originator object. The state can include any number of state variables.
The Memento must have two interfaces, an interface to the caretaker. This interface must not allow any operations or any access to internal state stored by the memento and thus honors encapsulation. The other interface is to the originator and allows the originator to access any state variables necessary to for the originator to restore previous state. 
Originator
Creates a memento object capturing the originators internal state.
Use the memento object to restore its previous state. 
Caretaker
Responsible for keeping the memento.
The memento is opaque to the caretaker, and the caretaker must not operate on it. 

[[File:Momento.JPG]]

=== Example ===
The given example <ref name="ex">http://en.wikipedia.org/wiki/Memento_pattern</ref> shows the three parts of the pattern: the Originator, the Memento
and the Caretaker. The Caretaker is the repository for the Memento. You can also see that once the Memento object is created you can’t change the saved state and in order
to save a new Memento you need to create it again.
Implementation of the pattern in C#.

region Originator
public class Originator<T>
{
#region Properties
public T State { get; set; }
#endregion
#region Methods
/// <summary>
/// Creates a new memento to hold the current
/// state
/// </summary>
/// <returns>The created memento</returns>
public Memento<T> SaveMemento()
{
return (new Memento<T>(State));
}
/// <summary>
/// Restores the state which is saved in the given memento
/// </summary>
/// <param name="memento">The given memento</param>
public void RestoreMemento(Memento<T> memento)
{
State = memento.State;
}
#endregion
}
#endregion
#region Memento
public class Memento<T>
{
#region Properties
public T State { get; private set; }
#endregion
#region Ctor
/// <summary>
/// Construct a new memento object with the
/// given state
/// </summary>
/// <param name="state">The given state</param>
public Memento(T state)
{
State = state;
}
#endregion
}
#endregion
#region Caretaker
public class Caretaker<T>
{
#region Properties
public Memento<T> Memento { get; set; }
#endregion
}
#endregion

=== Usage ===
he saved state is inserted to the Caretaker object and than
you can change the state of the Originator to whatever you need. In order to
restore the Originator state you use the restore method and pass it the Caretaker’s
saved Memento.

Originator<string> org = new Originator<string>();
org.State = "Old State"; 
// Store internal state in the caretaker object
Caretaker<string> caretaker = new Caretaker<string>();
caretaker.Memento = org.SaveMemento();
Console.WriteLine("This is the old state: {0}", org.State);
org.State = "New state";
Console.WriteLine("This is the new state: {0}", org.State); 
// Restore saved state from the caretaker
org.RestoreMemento(caretaker.Memento);
Console.WriteLine("Old state was restored: {0}", org.State); 
// Wait for user
Console.Read();

==External links==
*[http://dofactory.com/Patterns/PatternMemento.aspx Example] Memento Pattern Example
*[http://stackoverflow.com/questions/8994433/how-is-the-memento-pattern-implemented-in-c4 Implementation] Memento Pattern Discussion
*[http://adapower.com/index.php?Command=Class&ClassID=Patterns&CID=271 Description of Memento Pattern] in [[Ada (programming language)|Ada]]
*[http://dofactory.com/Patterns/PatternMemento.aspx Memento UML Class Diagram] with C# and .NET code samples
*[http://sourcemaking.com/design_patterns/memento SourceMaking Tutorial]
*[http://www.nileshgule.com/2012/08/memento-design-pattern.html Memento Design Pattern using C# ] by Nilesh Gule

== Summary ==
To sum up the post, the memento pattern is is used for saving encapsulated object state
in an external object. The state can then be restored by demand.
As I wrote the places that you’ll want to use the pattern are in scientific
computing or in computer games but it can be helpful also in other places.
The next post in the series will explain the state pattern.

=References=

<references />

CSC/ECE 517 Fall 2012/ch2b 2w62 pv

2012-11-20T03:25:40Z

Pvasude:

=Memento, directory of sites=
The objective of this wiki is to provide a directory of sites that one would refer to while learning about the Memento pattern. This wiki will be giving an overview of the different features of the Memento pattern along with links to useful websites that explain each of these features in more detail.

__TOC__

== Introduction ==
The memento pattern is a pattern that provides the ability to restore an object to its previous state(via rollback). The memento pattern is implemented with two objects: the originator and a caretaker. The originator is some object that has an internal state. The caretaker is going to do something to the originator, but wants to be able to undo the change. The caretaker first asks the originator for a memento object. Then it does whatever operation it was going to do. To roll back to the state before the operations, it returns the memento object to the originator.

== Motivation ==
It is sometimes necessary to capture the internal state of an object at some point and have the ability to restore the object to that state later in time. Such a case is useful in case of error or failure. Consider the case of a calculator object with an undo operation such a calculator could simply maintain a list of all previous operation that it has performed and thus would be able to restore a previous calculation it has performed. This would cause the calculator object to become larger, more complex, and heavyweight, as the calculator object would have to provide additional undo functionality and should maintain a list of all previous operations. This functionality can be moved out of the calculator class, so that an external (let's call it undo manager class) can collect the internal state of the calculator and save it. However providing the explicit access to every state variable of the calculator to the restore manager would be impractical and would violate the encapsulation principle.

== Implementation ==

Memento
Stores internal state of the Originator object. The state can include any number of state variables.
The Memento must have two interfaces, an interface to the caretaker. This interface must not allow any operations or any access to internal state stored by the memento and thus honors encapsulation. The other interface is to the originator and allows the originator to access any state variables necessary to for the originator to restore previous state. 
Originator
Creates a memento object capturing the originators internal state.
Use the memento object to restore its previous state. 
Caretaker
Responsible for keeping the memento.
The memento is opaque to the caretaker, and the caretaker must not operate on it. 

[[File:Momento.JPG]]

=== Example ===
The given example <ref name="adapter">http://en.wikipedia.org/wiki/Memento_pattern</ref> shows the three parts of the pattern: the Originator, the Memento
and the Caretaker. The Caretaker is the repository for the Memento. You can also see that once the Memento object is created you can’t change the saved state and in order
to save a new Memento you need to create it again.
Implementation of the pattern in C#.

region Originator
public class Originator<T>
{
#region Properties
public T State { get; set; }
#endregion
#region Methods
/// <summary>
/// Creates a new memento to hold the current
/// state
/// </summary>
/// <returns>The created memento</returns>
public Memento<T> SaveMemento()
{
return (new Memento<T>(State));
}
/// <summary>
/// Restores the state which is saved in the given memento
/// </summary>
/// <param name="memento">The given memento</param>
public void RestoreMemento(Memento<T> memento)
{
State = memento.State;
}
#endregion
}
#endregion
#region Memento
public class Memento<T>
{
#region Properties
public T State { get; private set; }
#endregion
#region Ctor
/// <summary>
/// Construct a new memento object with the
/// given state
/// </summary>
/// <param name="state">The given state</param>
public Memento(T state)
{
State = state;
}
#endregion
}
#endregion
#region Caretaker
public class Caretaker<T>
{
#region Properties
public Memento<T> Memento { get; set; }
#endregion
}
#endregion

=== Usage ===
he saved state is inserted to the Caretaker object and than
you can change the state of the Originator to whatever you need. In order to
restore the Originator state you use the restore method and pass it the Caretaker’s
saved Memento.

Originator<string> org = new Originator<string>();
org.State = "Old State"; 
// Store internal state in the caretaker object
Caretaker<string> caretaker = new Caretaker<string>();
caretaker.Memento = org.SaveMemento();
Console.WriteLine("This is the old state: {0}", org.State);
org.State = "New state";
Console.WriteLine("This is the new state: {0}", org.State); 
// Restore saved state from the caretaker
org.RestoreMemento(caretaker.Memento);
Console.WriteLine("Old state was restored: {0}", org.State); 
// Wait for user
Console.Read();

==External links==
*[http://dofactory.com/Patterns/PatternMemento.aspx Example] Memento Pattern Example
*[http://stackoverflow.com/questions/8994433/how-is-the-memento-pattern-implemented-in-c4 Implementation] Memento Pattern Discussion
*[http://adapower.com/index.php?Command=Class&ClassID=Patterns&CID=271 Description of Memento Pattern] in [[Ada (programming language)|Ada]]
*[http://dofactory.com/Patterns/PatternMemento.aspx Memento UML Class Diagram] with C# and .NET code samples
*[http://sourcemaking.com/design_patterns/memento SourceMaking Tutorial]
*[http://www.nileshgule.com/2012/08/memento-design-pattern.html Memento Design Pattern using C# ] by Nilesh Gule

== Summary ==
To sum up the post, the memento pattern is is used for saving encapsulated object state
in an external object. The state can then be restored by demand.
As I wrote the places that you’ll want to use the pattern are in scientific
computing or in computer games but it can be helpful also in other places.
The next post in the series will explain the state pattern.

=References=

<references />

CSC/ECE 517 Fall 2012/ch2b 2w62 pv

2012-11-20T03:22:08Z

Pvasude:

=Memento, directory of sites=
The objective of this wiki is to provide a directory of sites that one would refer to while learning about the Memento pattern. This wiki will be giving an overview of the different features of the Memento pattern along with links to useful websites that explain each of these features in more detail.

__TOC__

== Introduction ==
The memento pattern is a pattern that provides the ability to restore an object to its previous state(via rollback). The memento pattern is implemented with two objects: the originator and a caretaker. The originator is some object that has an internal state. The caretaker is going to do something to the originator, but wants to be able to undo the change. The caretaker first asks the originator for a memento object. Then it does whatever operation it was going to do. To roll back to the state before the operations, it returns the memento object to the originator.

== Motivation ==
It is sometimes necessary to capture the internal state of an object at some point and have the ability to restore the object to that state later in time. Such a case is useful in case of error or failure. Consider the case of a calculator object with an undo operation such a calculator could simply maintain a list of all previous operation that it has performed and thus would be able to restore a previous calculation it has performed. This would cause the calculator object to become larger, more complex, and heavyweight, as the calculator object would have to provide additional undo functionality and should maintain a list of all previous operations. This functionality can be moved out of the calculator class, so that an external (let's call it undo manager class) can collect the internal state of the calculator and save it. However providing the explicit access to every state variable of the calculator to the restore manager would be impractical and would violate the encapsulation principle.

== Implementation ==

Memento
Stores internal state of the Originator object. The state can include any number of state variables.
The Memento must have two interfaces, an interface to the caretaker. This interface must not allow any operations or any access to internal state stored by the memento and thus honors encapsulation. The other interface is to the originator and allows the originator to access any state variables necessary to for the originator to restore previous state. 
Originator
Creates a memento object capturing the originators internal state.
Use the memento object to restore its previous state. 
Caretaker
Responsible for keeping the memento.
The memento is opaque to the caretaker, and the caretaker must not operate on it. 

[[File:Momento.JPG]]

=== Example ===
The given example shows the three parts of the pattern: the Originator, the Memento
and the Caretaker. The Caretaker is the repository for the Memento. You can also see that once the Memento object is created you can’t change the saved state and in order
to save a new Memento you need to create it again.
Implementation of the pattern in C#.

region Originator
public class Originator<T>
{
#region Properties
public T State { get; set; }
#endregion
#region Methods
/// <summary>
/// Creates a new memento to hold the current
/// state
/// </summary>
/// <returns>The created memento</returns>
public Memento<T> SaveMemento()
{
return (new Memento<T>(State));
}
/// <summary>
/// Restores the state which is saved in the given memento
/// </summary>
/// <param name="memento">The given memento</param>
public void RestoreMemento(Memento<T> memento)
{
State = memento.State;
}
#endregion
}
#endregion
#region Memento
public class Memento<T>
{
#region Properties
public T State { get; private set; }
#endregion
#region Ctor
/// <summary>
/// Construct a new memento object with the
/// given state
/// </summary>
/// <param name="state">The given state</param>
public Memento(T state)
{
State = state;
}
#endregion
}
#endregion
#region Caretaker
public class Caretaker<T>
{
#region Properties
public Memento<T> Memento { get; set; }
#endregion
}
#endregion

=== Usage ===
he saved state is inserted to the Caretaker object and than
you can change the state of the Originator to whatever you need. In order to
restore the Originator state you use the restore method and pass it the Caretaker’s
saved Memento.

Originator<string> org = new Originator<string>();
org.State = "Old State"; 
// Store internal state in the caretaker object
Caretaker<string> caretaker = new Caretaker<string>();
caretaker.Memento = org.SaveMemento();
Console.WriteLine("This is the old state: {0}", org.State);
org.State = "New state";
Console.WriteLine("This is the new state: {0}", org.State); 
// Restore saved state from the caretaker
org.RestoreMemento(caretaker.Memento);
Console.WriteLine("Old state was restored: {0}", org.State); 
// Wait for user
Console.Read();

==External links==
*[http://dofactory.com/Patterns/PatternMemento.aspx Example] Memento Pattern Example
*[http://stackoverflow.com/questions/8994433/how-is-the-memento-pattern-implemented-in-c4 Implementation] Memento Pattern Discussion
*[http://adapower.com/index.php?Command=Class&ClassID=Patterns&CID=271 Description of Memento Pattern] in [[Ada (programming language)|Ada]]
*[http://dofactory.com/Patterns/PatternMemento.aspx Memento UML Class Diagram] with C# and .NET code samples
*[http://sourcemaking.com/design_patterns/memento SourceMaking Tutorial]
*[http://www.nileshgule.com/2012/08/memento-design-pattern.html Memento Design Pattern using C# ] by Nilesh Gule

== Summary ==
To sum up the post, the memento pattern is is used for saving encapsulated object state
in an external object. The state can then be restored by demand.
As I wrote the places that you’ll want to use the pattern are in scientific
computing or in computer games but it can be helpful also in other places.
The next post in the series will explain the state pattern.

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

CSC/ECE 517 Fall 2012/ch2b 2w62 pv

2012-11-20T03:21:38Z

Pvasude:

=Memento, directory of sites=
The objective of this wiki is to provide a directory of sites that one would refer to while learning about the Memento pattern. This wiki will be giving an overview of the different features of the Memento pattern along with links to useful websites that explain each of these features in more detail.

__TOC__

== Introduction ==
The memento pattern is a pattern that provides the ability to restore an object to its previous state(via rollback). The memento pattern is implemented with two objects: the originator and a caretaker. The originator is some object that has an internal state. The caretaker is going to do something to the originator, but wants to be able to undo the change. The caretaker first asks the originator for a memento object. Then it does whatever operation it was going to do. To roll back to the state before the operations, it returns the memento object to the originator.

== Motivation ==
It is sometimes necessary to capture the internal state of an object at some point and have the ability to restore the object to that state later in time. Such a case is useful in case of error or failure. Consider the case of a calculator object with an undo operation such a calculator could simply maintain a list of all previous operation that it has performed and thus would be able to restore a previous calculation it has performed. This would cause the calculator object to become larger, more complex, and heavyweight, as the calculator object would have to provide additional undo functionality and should maintain a list of all previous operations. This functionality can be moved out of the calculator class, so that an external (let's call it undo manager class) can collect the internal state of the calculator and save it. However providing the explicit access to every state variable of the calculator to the restore manager would be impractical and would violate the encapsulation principle.

== Implementation ==

Memento
Stores internal state of the Originator object. The state can include any number of state variables.
The Memento must have two interfaces, an interface to the caretaker. This interface must not allow any operations or any access to internal state stored by the memento and thus honors encapsulation. The other interface is to the originator and allows the originator to access any state variables necessary to for the originator to restore previous state. 
Originator
Creates a memento object capturing the originators internal state.
Use the memento object to restore its previous state. 
Caretaker
Responsible for keeping the memento.
The memento is opaque to the caretaker, and the caretaker must not operate on it. 

[[File:Momento.JPG]]

=== Example ===
The given example shows the three parts of the pattern: the Originator, the Memento
and the Caretaker. The Caretaker is the repository for the Memento. You can also see that once the Memento object is created you can’t change the saved state and in order
to save a new Memento you need to create it again.
Implementation of the pattern in C#.

region Originator
public class Originator<T>
{
#region Properties
public T State { get; set; }
#endregion
#region Methods
/// <summary>
/// Creates a new memento to hold the current
/// state
/// </summary>
/// <returns>The created memento</returns>
public Memento<T> SaveMemento()
{
return (new Memento<T>(State));
}
/// <summary>
/// Restores the state which is saved in the given memento
/// </summary>
/// <param name="memento">The given memento</param>
public void RestoreMemento(Memento<T> memento)
{
State = memento.State;
}
#endregion
}
#endregion
#region Memento
public class Memento<T>
{
#region Properties
public T State { get; private set; }
#endregion
#region Ctor
/// <summary>
/// Construct a new memento object with the
/// given state
/// </summary>
/// <param name="state">The given state</param>
public Memento(T state)
{
State = state;
}
#endregion
}
#endregion
#region Caretaker
public class Caretaker<T>
{
#region Properties
public Memento<T> Memento { get; set; }
#endregion
}
#endregion

=== Usage ===
he saved state is inserted to the Caretaker object and than
you can change the state of the Originator to whatever you need. In order to
restore the Originator state you use the restore method and pass it the Caretaker’s
saved Memento.

Originator<string> org = new Originator<string>();
org.State = "Old State"; 
// Store internal state in the caretaker object
Caretaker<string> caretaker = new Caretaker<string>();
caretaker.Memento = org.SaveMemento();
Console.WriteLine("This is the old state: {0}", org.State);
org.State = "New state";
Console.WriteLine("This is the new state: {0}", org.State); 
// Restore saved state from the caretaker
org.RestoreMemento(caretaker.Memento);
Console.WriteLine("Old state was restored: {0}", org.State); 
// Wait for user
Console.Read();

== External Links ==
==External links==
*[http://dofactory.com/Patterns/PatternMemento.aspx Example] Memento Pattern Example
*[http://stackoverflow.com/questions/8994433/how-is-the-memento-pattern-implemented-in-c4 Implementation] Memento Pattern Discussion
*[http://adapower.com/index.php?Command=Class&ClassID=Patterns&CID=271 Description of Memento Pattern] in [[Ada (programming language)|Ada]]
*[http://dofactory.com/Patterns/PatternMemento.aspx Memento UML Class Diagram] with C# and .NET code samples
*[http://sourcemaking.com/design_patterns/memento SourceMaking Tutorial]
*[http://www.nileshgule.com/2012/08/memento-design-pattern.html Memento Design Pattern using C# ] by Nilesh Gule

== Summary ==
To sum up the post, the memento pattern is is used for saving encapsulated object state
in an external object. The state can then be restored by demand.
As I wrote the places that you’ll want to use the pattern are in scientific
computing or in computer games but it can be helpful also in other places.
The next post in the series will explain the state pattern.

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

CSC/ECE 517 Fall 2012/ch2b 2w62 pv

2012-11-20T03:14:30Z

Pvasude:

=Memento, directory of sites=
The objective of this wiki is to provide a directory of sites that one would refer to while learning about the Memento pattern. This wiki will be giving an overview of the different features of the Memento pattern along with links to useful websites that explain each of these features in more detail.

__TOC__

== Introduction ==
The memento pattern is a pattern that provides the ability to restore an object to its previous state(via rollback). The memento pattern is implemented with two objects: the originator and a caretaker. The originator is some object that has an internal state. The caretaker is going to do something to the originator, but wants to be able to undo the change. The caretaker first asks the originator for a memento object. Then it does whatever operation it was going to do. To roll back to the state before the operations, it returns the memento object to the originator.

== Motivation ==
It is sometimes necessary to capture the internal state of an object at some point and have the ability to restore the object to that state later in time. Such a case is useful in case of error or failure. Consider the case of a calculator object with an undo operation such a calculator could simply maintain a list of all previous operation that it has performed and thus would be able to restore a previous calculation it has performed. This would cause the calculator object to become larger, more complex, and heavyweight, as the calculator object would have to provide additional undo functionality and should maintain a list of all previous operations. This functionality can be moved out of the calculator class, so that an external (let's call it undo manager class) can collect the internal state of the calculator and save it. However providing the explicit access to every state variable of the calculator to the restore manager would be impractical and would violate the encapsulation principle.

== Implementation ==

Memento
Stores internal state of the Originator object. The state can include any number of state variables.
The Memento must have two interfaces, an interface to the caretaker. This interface must not allow any operations or any access to internal state stored by the memento and thus honors encapsulation. The other interface is to the originator and allows the originator to access any state variables necessary to for the originator to restore previous state. 
Originator
Creates a memento object capturing the originators internal state.
Use the memento object to restore its previous state. 
Caretaker
Responsible for keeping the memento.
The memento is opaque to the caretaker, and the caretaker must not operate on it. 

[[File:Momento.JPG]]

=== Example ===
The given example shows the three parts of the pattern: the Originator, the Memento
and the Caretaker. The Caretaker is the repository for the Memento. You can also see that once the Memento object is created you can’t change the saved state and in order
to save a new Memento you need to create it again.
Implementation of the pattern in C#.

region Originator
public class Originator<T>
{
#region Properties
public T State { get; set; }
#endregion
#region Methods
/// <summary>
/// Creates a new memento to hold the current
/// state
/// </summary>
/// <returns>The created memento</returns>
public Memento<T> SaveMemento()
{
return (new Memento<T>(State));
}
/// <summary>
/// Restores the state which is saved in the given memento
/// </summary>
/// <param name="memento">The given memento</param>
public void RestoreMemento(Memento<T> memento)
{
State = memento.State;
}
#endregion
}
#endregion
#region Memento
public class Memento<T>
{
#region Properties
public T State { get; private set; }
#endregion
#region Ctor
/// <summary>
/// Construct a new memento object with the
/// given state
/// </summary>
/// <param name="state">The given state</param>
public Memento(T state)
{
State = state;
}
#endregion
}
#endregion
#region Caretaker
public class Caretaker<T>
{
#region Properties
public Memento<T> Memento { get; set; }
#endregion
}
#endregion

=== Usage ===
he saved state is inserted to the Caretaker object and than
you can change the state of the Originator to whatever you need. In order to
restore the Originator state you use the restore method and pass it the Caretaker’s
saved Memento.

Originator<string> org = new Originator<string>();
org.State = "Old State"; 
// Store internal state in the caretaker object
Caretaker<string> caretaker = new Caretaker<string>();
caretaker.Memento = org.SaveMemento();
Console.WriteLine("This is the old state: {0}", org.State);
org.State = "New state";
Console.WriteLine("This is the new state: {0}", org.State); 
// Restore saved state from the caretaker
org.RestoreMemento(caretaker.Memento);
Console.WriteLine("Old state was restored: {0}", org.State); 
// Wait for user
Console.Read();

== Summary ==
To sum up the post, the memento pattern is is used for saving encapsulated object state
in an external object. The state can then be restored by demand.
As I wrote the places that you’ll want to use the pattern are in scientific
computing or in computer games but it can be helpful also in other places.
The next post in the series will explain the state pattern.

CSC/ECE 517 Fall 2012/ch2b 2w62 pv

2012-11-20T03:13:52Z

Pvasude:

=Memento, directory of sites=
The objective of this wiki is to provide a directory of sites that one would refer to while learning about the Memento pattern. This wiki will be giving an overview of the different features of the Memento pattern along with links to useful websites that explain each of these features in more detail.

== Introduction ==
The memento pattern is a pattern that provides the ability to restore an object to its previous state(via rollback). The memento pattern is implemented with two objects: the originator and a caretaker. The originator is some object that has an internal state. The caretaker is going to do something to the originator, but wants to be able to undo the change. The caretaker first asks the originator for a memento object. Then it does whatever operation it was going to do. To roll back to the state before the operations, it returns the memento object to the originator.

== Motivation ==
It is sometimes necessary to capture the internal state of an object at some point and have the ability to restore the object to that state later in time. Such a case is useful in case of error or failure. Consider the case of a calculator object with an undo operation such a calculator could simply maintain a list of all previous operation that it has performed and thus would be able to restore a previous calculation it has performed. This would cause the calculator object to become larger, more complex, and heavyweight, as the calculator object would have to provide additional undo functionality and should maintain a list of all previous operations. This functionality can be moved out of the calculator class, so that an external (let's call it undo manager class) can collect the internal state of the calculator and save it. However providing the explicit access to every state variable of the calculator to the restore manager would be impractical and would violate the encapsulation principle.

== Implementation ==

Memento
Stores internal state of the Originator object. The state can include any number of state variables.
The Memento must have two interfaces, an interface to the caretaker. This interface must not allow any operations or any access to internal state stored by the memento and thus honors encapsulation. The other interface is to the originator and allows the originator to access any state variables necessary to for the originator to restore previous state. 
Originator
Creates a memento object capturing the originators internal state.
Use the memento object to restore its previous state. 
Caretaker
Responsible for keeping the memento.
The memento is opaque to the caretaker, and the caretaker must not operate on it. 

[[File:Momento.JPG]]

=== Example ===
The given example shows the three parts of the pattern: the Originator, the Memento
and the Caretaker. The Caretaker is the repository for the Memento. You can also see that once the Memento object is created you can’t change the saved state and in order
to save a new Memento you need to create it again.
Implementation of the pattern in C#.

region Originator
public class Originator<T>
{
#region Properties
public T State { get; set; }
#endregion
#region Methods
/// <summary>
/// Creates a new memento to hold the current
/// state
/// </summary>
/// <returns>The created memento</returns>
public Memento<T> SaveMemento()
{
return (new Memento<T>(State));
}
/// <summary>
/// Restores the state which is saved in the given memento
/// </summary>
/// <param name="memento">The given memento</param>
public void RestoreMemento(Memento<T> memento)
{
State = memento.State;
}
#endregion
}
#endregion
#region Memento
public class Memento<T>
{
#region Properties
public T State { get; private set; }
#endregion
#region Ctor
/// <summary>
/// Construct a new memento object with the
/// given state
/// </summary>
/// <param name="state">The given state</param>
public Memento(T state)
{
State = state;
}
#endregion
}
#endregion
#region Caretaker
public class Caretaker<T>
{
#region Properties
public Memento<T> Memento { get; set; }
#endregion
}
#endregion

=== Usage ===
he saved state is inserted to the Caretaker object and than
you can change the state of the Originator to whatever you need. In order to
restore the Originator state you use the restore method and pass it the Caretaker’s
saved Memento.

Originator<string> org = new Originator<string>();
org.State = "Old State"; 
// Store internal state in the caretaker object
Caretaker<string> caretaker = new Caretaker<string>();
caretaker.Memento = org.SaveMemento();
Console.WriteLine("This is the old state: {0}", org.State);
org.State = "New state";
Console.WriteLine("This is the new state: {0}", org.State); 
// Restore saved state from the caretaker
org.RestoreMemento(caretaker.Memento);
Console.WriteLine("Old state was restored: {0}", org.State); 
// Wait for user
Console.Read();

== Summary ==
To sum up the post, the memento pattern is is used for saving encapsulated object state
in an external object. The state can then be restored by demand.
As I wrote the places that you’ll want to use the pattern are in scientific
computing or in computer games but it can be helpful also in other places.
The next post in the series will explain the state pattern.

CSC/ECE 517 Fall 2012/ch2b 2w62 pv

2012-11-20T03:11:04Z

Pvasude: /* Usage */

== Introduction ==
The memento pattern is a pattern that provides the ability to restore an object to its previous state(via rollback). The memento pattern is implemented with two objects: the originator and a caretaker. The originator is some object that has an internal state. The caretaker is going to do something to the originator, but wants to be able to undo the change. The caretaker first asks the originator for a memento object. Then it does whatever operation it was going to do. To roll back to the state before the operations, it returns the memento object to the originator.

== Motivation ==
It is sometimes necessary to capture the internal state of an object at some point and have the ability to restore the object to that state later in time. Such a case is useful in case of error or failure. Consider the case of a calculator object with an undo operation such a calculator could simply maintain a list of all previous operation that it has performed and thus would be able to restore a previous calculation it has performed. This would cause the calculator object to become larger, more complex, and heavyweight, as the calculator object would have to provide additional undo functionality and should maintain a list of all previous operations. This functionality can be moved out of the calculator class, so that an external (let's call it undo manager class) can collect the internal state of the calculator and save it. However providing the explicit access to every state variable of the calculator to the restore manager would be impractical and would violate the encapsulation principle.

== Implementation ==

Memento
Stores internal state of the Originator object. The state can include any number of state variables.
The Memento must have two interfaces, an interface to the caretaker. This interface must not allow any operations or any access to internal state stored by the memento and thus honors encapsulation. The other interface is to the originator and allows the originator to access any state variables necessary to for the originator to restore previous state. 
Originator
Creates a memento object capturing the originators internal state.
Use the memento object to restore its previous state. 
Caretaker
Responsible for keeping the memento.
The memento is opaque to the caretaker, and the caretaker must not operate on it. 

[[File:Momento.JPG]]

=== Example ===
The given example shows the three parts of the pattern: the Originator, the Memento
and the Caretaker. The Caretaker is the repository for the Memento. You can also see that once the Memento object is created you can’t change the saved state and in order
to save a new Memento you need to create it again.
Implementation of the pattern in C#.

region Originator
public class Originator<T>
{
#region Properties
public T State { get; set; }
#endregion
#region Methods
/// <summary>
/// Creates a new memento to hold the current
/// state
/// </summary>
/// <returns>The created memento</returns>
public Memento<T> SaveMemento()
{
return (new Memento<T>(State));
}
/// <summary>
/// Restores the state which is saved in the given memento
/// </summary>
/// <param name="memento">The given memento</param>
public void RestoreMemento(Memento<T> memento)
{
State = memento.State;
}
#endregion
}
#endregion
#region Memento
public class Memento<T>
{
#region Properties
public T State { get; private set; }
#endregion
#region Ctor
/// <summary>
/// Construct a new memento object with the
/// given state
/// </summary>
/// <param name="state">The given state</param>
public Memento(T state)
{
State = state;
}
#endregion
}
#endregion
#region Caretaker
public class Caretaker<T>
{
#region Properties
public Memento<T> Memento { get; set; }
#endregion
}
#endregion

=== Usage ===
he saved state is inserted to the Caretaker object and than
you can change the state of the Originator to whatever you need. In order to
restore the Originator state you use the restore method and pass it the Caretaker’s
saved Memento.

Originator<string> org = new Originator<string>();
org.State = "Old State"; 
// Store internal state in the caretaker object
Caretaker<string> caretaker = new Caretaker<string>();
caretaker.Memento = org.SaveMemento();
Console.WriteLine("This is the old state: {0}", org.State);
org.State = "New state";
Console.WriteLine("This is the new state: {0}", org.State); 
// Restore saved state from the caretaker
org.RestoreMemento(caretaker.Memento);
Console.WriteLine("Old state was restored: {0}", org.State); 
// Wait for user
Console.Read();

== Summary ==
To sum up the post, the memento pattern is is used for saving encapsulated object state
in an external object. The state can then be restored by demand.
As I wrote the places that you’ll want to use the pattern are in scientific
computing or in computer games but it can be helpful also in other places.
The next post in the series will explain the state pattern.

CSC/ECE 517 Fall 2012/ch2b 2w62 pv

2012-11-20T03:10:26Z

Pvasude:

== Introduction ==
The memento pattern is a pattern that provides the ability to restore an object to its previous state(via rollback). The memento pattern is implemented with two objects: the originator and a caretaker. The originator is some object that has an internal state. The caretaker is going to do something to the originator, but wants to be able to undo the change. The caretaker first asks the originator for a memento object. Then it does whatever operation it was going to do. To roll back to the state before the operations, it returns the memento object to the originator.

== Motivation ==
It is sometimes necessary to capture the internal state of an object at some point and have the ability to restore the object to that state later in time. Such a case is useful in case of error or failure. Consider the case of a calculator object with an undo operation such a calculator could simply maintain a list of all previous operation that it has performed and thus would be able to restore a previous calculation it has performed. This would cause the calculator object to become larger, more complex, and heavyweight, as the calculator object would have to provide additional undo functionality and should maintain a list of all previous operations. This functionality can be moved out of the calculator class, so that an external (let's call it undo manager class) can collect the internal state of the calculator and save it. However providing the explicit access to every state variable of the calculator to the restore manager would be impractical and would violate the encapsulation principle.

== Implementation ==

Memento
Stores internal state of the Originator object. The state can include any number of state variables.
The Memento must have two interfaces, an interface to the caretaker. This interface must not allow any operations or any access to internal state stored by the memento and thus honors encapsulation. The other interface is to the originator and allows the originator to access any state variables necessary to for the originator to restore previous state. 
Originator
Creates a memento object capturing the originators internal state.
Use the memento object to restore its previous state. 
Caretaker
Responsible for keeping the memento.
The memento is opaque to the caretaker, and the caretaker must not operate on it. 

[[File:Momento.JPG]]

=== Example ===
The given example shows the three parts of the pattern: the Originator, the Memento
and the Caretaker. The Caretaker is the repository for the Memento. You can also see that once the Memento object is created you can’t change the saved state and in order
to save a new Memento you need to create it again.
Implementation of the pattern in C#.

region Originator
public class Originator<T>
{
#region Properties
public T State { get; set; }
#endregion
#region Methods
/// <summary>
/// Creates a new memento to hold the current
/// state
/// </summary>
/// <returns>The created memento</returns>
public Memento<T> SaveMemento()
{
return (new Memento<T>(State));
}
/// <summary>
/// Restores the state which is saved in the given memento
/// </summary>
/// <param name="memento">The given memento</param>
public void RestoreMemento(Memento<T> memento)
{
State = memento.State;
}
#endregion
}
#endregion
#region Memento
public class Memento<T>
{
#region Properties
public T State { get; private set; }
#endregion
#region Ctor
/// <summary>
/// Construct a new memento object with the
/// given state
/// </summary>
/// <param name="state">The given state</param>
public Memento(T state)
{
State = state;
}
#endregion
}
#endregion
#region Caretaker
public class Caretaker<T>
{
#region Properties
public Memento<T> Memento { get; set; }
#endregion
}
#endregion

=== Usage ===

Originator<string> org = new Originator<string>();
org.State = "Old State"; 
// Store internal state in the caretaker object
Caretaker<string> caretaker = new Caretaker<string>();
caretaker.Memento = org.SaveMemento();
Console.WriteLine("This is the old state: {0}", org.State);
org.State = "New state";
Console.WriteLine("This is the new state: {0}", org.State); 
// Restore saved state from the caretaker
org.RestoreMemento(caretaker.Memento);
Console.WriteLine("Old state was restored: {0}", org.State); 
// Wait for user
Console.Read();

== Summary ==
To sum up the post, the memento pattern is is used for saving encapsulated object state
in an external object. The state can then be restored by demand.
As I wrote the places that you’ll want to use the pattern are in scientific
computing or in computer games but it can be helpful also in other places.
The next post in the series will explain the state pattern.

CSC/ECE 517 Fall 2012/ch2b 2w62 pv

2012-11-20T03:07:45Z

Pvasude: /* Example */

== Introduction ==
The memento pattern is a pattern that provides the ability to restore an object to its previous state(via rollback). The memento pattern is implemented with two objects: the originator and a caretaker. The originator is some object that has an internal state. The caretaker is going to do something to the originator, but wants to be able to undo the change. The caretaker first asks the originator for a memento object. Then it does whatever operation it was going to do. To roll back to the state before the operations, it returns the memento object to the originator.

== Motivation ==
It is sometimes necessary to capture the internal state of an object at some point and have the ability to restore the object to that state later in time. Such a case is useful in case of error or failure. Consider the case of a calculator object with an undo operation such a calculator could simply maintain a list of all previous operation that it has performed and thus would be able to restore a previous calculation it has performed. This would cause the calculator object to become larger, more complex, and heavyweight, as the calculator object would have to provide additional undo functionality and should maintain a list of all previous operations. This functionality can be moved out of the calculator class, so that an external (let's call it undo manager class) can collect the internal state of the calculator and save it. However providing the explicit access to every state variable of the calculator to the restore manager would be impractical and would violate the encapsulation principle.

== Implementation ==

Memento
Stores internal state of the Originator object. The state can include any number of state variables.
The Memento must have two interfaces, an interface to the caretaker. This interface must not allow any operations or any access to internal state stored by the memento and thus honors encapsulation. The other interface is to the originator and allows the originator to access any state variables necessary to for the originator to restore previous state. 
Originator
Creates a memento object capturing the originators internal state.
Use the memento object to restore its previous state. 
Caretaker
Responsible for keeping the memento.
The memento is opaque to the caretaker, and the caretaker must not operate on it. 

[[File:Momento.JPG]]

=== Example ===
The given example shows the three parts of the pattern: the Originator, the Memento
and the Caretaker. The Caretaker is the repository for the Memento. You can also see that once the Memento object is created you can’t change the saved state and in order
to save a new Memento you need to create it again.
Implementation of the pattern in C#.

region Originator
public class Originator<T>
{
#region Properties
public T State { get; set; }
#endregion
#region Methods
/// <summary>
/// Creates a new memento to hold the current
/// state
/// </summary>
/// <returns>The created memento</returns>
public Memento<T> SaveMemento()
{
return (new Memento<T>(State));
}
/// <summary>
/// Restores the state which is saved in the given memento
/// </summary>
/// <param name="memento">The given memento</param>
public void RestoreMemento(Memento<T> memento)
{
State = memento.State;
}
#endregion
}
#endregion
#region Memento
public class Memento<T>
{
#region Properties
public T State { get; private set; }
#endregion
#region Ctor
/// <summary>
/// Construct a new memento object with the
/// given state
/// </summary>
/// <param name="state">The given state</param>
public Memento(T state)
{
State = state;
}
#endregion
}
#endregion
#region Caretaker
public class Caretaker<T>
{
#region Properties
public Memento<T> Memento { get; set; }
#endregion
}
#endregion

=== Usage ===

Originator<string> org = new Originator<string>();
org.State = "Old State"; 
// Store internal state in the caretaker object
Caretaker<string> caretaker = new Caretaker<string>();
caretaker.Memento = org.SaveMemento();
Console.WriteLine("This is the old state: {0}", org.State);
org.State = "New state";
Console.WriteLine("This is the new state: {0}", org.State); 
// Restore saved state from the caretaker
org.RestoreMemento(caretaker.Memento);
Console.WriteLine("Old state was restored: {0}", org.State); 
// Wait for user
Console.Read();

CSC/ECE 517 Fall 2012/ch2b 2w62 pv

2012-11-20T03:06:07Z

Pvasude: /* Example */

== Introduction ==
The memento pattern is a pattern that provides the ability to restore an object to its previous state(via rollback). The memento pattern is implemented with two objects: the originator and a caretaker. The originator is some object that has an internal state. The caretaker is going to do something to the originator, but wants to be able to undo the change. The caretaker first asks the originator for a memento object. Then it does whatever operation it was going to do. To roll back to the state before the operations, it returns the memento object to the originator.

== Motivation ==
It is sometimes necessary to capture the internal state of an object at some point and have the ability to restore the object to that state later in time. Such a case is useful in case of error or failure. Consider the case of a calculator object with an undo operation such a calculator could simply maintain a list of all previous operation that it has performed and thus would be able to restore a previous calculation it has performed. This would cause the calculator object to become larger, more complex, and heavyweight, as the calculator object would have to provide additional undo functionality and should maintain a list of all previous operations. This functionality can be moved out of the calculator class, so that an external (let's call it undo manager class) can collect the internal state of the calculator and save it. However providing the explicit access to every state variable of the calculator to the restore manager would be impractical and would violate the encapsulation principle.

== Implementation ==

Memento
Stores internal state of the Originator object. The state can include any number of state variables.
The Memento must have two interfaces, an interface to the caretaker. This interface must not allow any operations or any access to internal state stored by the memento and thus honors encapsulation. The other interface is to the originator and allows the originator to access any state variables necessary to for the originator to restore previous state. 
Originator
Creates a memento object capturing the originators internal state.
Use the memento object to restore its previous state. 
Caretaker
Responsible for keeping the memento.
The memento is opaque to the caretaker, and the caretaker must not operate on it. 

[[File:Momento.JPG]]

=== Example ===
The given example shows the three parts of the pattern: the Originator, the Memento
and the Caretaker. The Caretaker is the repository for the Memento. You can also see that once the Memento object is created you can’t change the saved state and in order
to save a new Memento you need to create it again.
Implementation of the pattern in C#.

region Originator
public class Originator<T>
{
#region Properties
public T State { get; set; }
#endregion
#region Methods
/// <summary>
/// Creates a new memento to hold the current
/// state
/// </summary>
/// <returns>The created memento</returns>
public Memento<T> SaveMemento()
{
return (new Memento<T>(State));
}
/// <summary>
/// Restores the state which is saved in the given memento
/// </summary>
/// <param name="memento">The given memento</param>
public void RestoreMemento(Memento<T> memento)
{
State = memento.State;
}
#endregion
}
#endregion
#region Memento
public class Memento<T>
{
#region Properties
public T State { get; private set; }
#endregion
#region Ctor
/// <summary>
/// Construct a new memento object with the
/// given state
/// </summary>
/// <param name="state">The given state</param>
public Memento(T state)
{
State = state;
}
#endregion
}
#endregion
#region Caretaker
public class Caretaker<T>
{
#region Properties
public Memento<T> Memento { get; set; }
#endregion
}
#endregion

=== Usage ===

Originator<string> org = new Originator<string>();
org.State = "Old State";
// Store internal state in the caretaker object
Caretaker<string> caretaker = new Caretaker<string>();
caretaker.Memento = org.SaveMemento();
Console.WriteLine("This is the old state: {0}", org.State);
org.State = "New state";
Console.WriteLine("This is the new state: {0}", org.State);
// Restore saved state from the caretaker
org.RestoreMemento(caretaker.Memento);
Console.WriteLine("Old state was restored: {0}", org.State);
// Wait for user
Console.Read();

CSC/ECE 517 Fall 2012/ch2b 2w62 pv

2012-11-20T03:05:07Z

Pvasude: /* Example */

CSC/ECE 517 Fall 2012/ch2b 2w62 pv

2012-11-20T03:03:03Z

Pvasude: /* Implementation */

CSC/ECE 517 Fall 2012/ch2b 2w62 pv

2012-11-20T02:54:57Z

Pvasude:

File:Momento.JPG

2012-11-20T02:54:11Z

Pvasude: uploaded a new version of "File:Momento.JPG"

CSC/ECE 517 Fall 2012/ch2b 2w62 pv

2012-11-20T02:50:37Z

Pvasude:

File:Momento.JPG

2012-11-20T02:50:03Z

Pvasude:

CSC/ECE 517 Fall 2012/ch2b 2w62 pv

2012-11-20T02:47:50Z

Pvasude: /* Implementation */

CSC/ECE 517 Fall 2012/ch2b 2w62 pv

2012-11-20T02:47:30Z

Pvasude:

CSC/ECE 517 Fall 2012/ch2b 2w62 pv

2012-11-20T02:45:24Z

Pvasude:

CSC/ECE 517 Fall 2012/ch2b 2w62 pv

2012-11-20T01:17:11Z

Pvasude: Created page with "Test"

Test

CSC/ECE 517 Fall 2012

2012-11-20T01:16:32Z

Pvasude:

*[[CSC/ECE_517_Fall_2012/Table_Of_Contents]]
*[[CSC/ECE 517 Fall 2012/ch1 n xx]]
*[[CSC/ECE 517 Fall 2012/ch1 1w1 rk]]
*[[CSC/ECE 517 Fall 2012/ch1 1w20 pp]]
*[[CSC/ECE 517 Fall 2012/ch1 1w5 su]]
*[[CSC/ECE 517 Fall 2012/ch1 1w6 pp]]
*[[CSC/ECE 517 Fall 2012/ch1 1w4 aj]]
*[[CSC/ECE 517 Fall 2012/ch1 1w7 am]]
*[[CSC/ECE 517 Fall 2012/ch1 1w8 aa]]
*[[CSC/ECE 517 Fall 2012/ch1 1w9 av]]
*[[CSC/ECE 517 Fall 2012/ch1 1w10 pk]]
*[[CSC/ECE 517 Fall 2012/ch1 1w11 ap]]
*[[CSC/ECE 517 Fall 2012/ch1a 1w12 mv]]
*[[CSC/ECE 517 Fall 2012/ch1 1w14 gv]]
*[[CSC/ECE 517 Fall 2012/ch1 1w17 ir]]
*[[CSC/ECE 517 Fall 2012/ch1 1w18 as]]
*[[CSC/ECE 517 Fall 2012/ch1 1w22 an]]
*[[CSC/ECE 517 Fall 2012/ch1 1w21 aa]]
*[[CSC/ECE 517 Fall 2012/ch1 1w21 wi]]
*[[CSC/ECE 517 Fall 2012/ch1 1w31 sa]]
*[[CSC/ECE 517 Fall 2012/ch1a 1w16 br]]
*[[CSC/ECE 517 Fall 2012/ch1a 1w23 as]]
*[[CSC/ECE 517 Fall 2012/ch1 1w24 nr]]
*[[CSC/ECE 517 Fall 2012/ch1 1w15 rt]]
*[[CSC/ECE 517 Fall 2012/ch1 1w3 pl]]
*[[CSC/ECE 517 Fall 2012/ch1 1w32 cm]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w5 dp]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w37 ss]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w67 ks]]

*[[CSC/ECE 517 Fall 2012/ch1 1w27 ms]]
*[[CSC/ECE 517 Fall 2012/ch1 1w29 sa]]
*[[CSC/ECE 517 Fall 2012/ch1 1w33 op]]
*[[CSC/ECE 517 Fall 2012/ch1 1w19 sa]]
*[[CSC/ECE 517 Fall 2012/ch1 1w34 vd]]
*[[CSC/ECE 517 Fall 2012/ch1 1w35 sa]]
*[[CSC/ECE 517 Fall 2012/ch1 1w30 rp]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w58 am]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w47 sk]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w69 mv]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w44 as]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w45 is]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w53 kc]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w40 ar]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w39 sn]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w54 go]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w56 ms]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w64 nn]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w66 as]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w40 as]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w42 js]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w46 sm]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w71 gs]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w63 dv]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w55 ms]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w57 mp]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w52 an]]
*[[CSC/ECE_517_Fall_2012/ch1b 1w38 nm]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w60 ac]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w62 rb]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w29 st]]
*[[CSC/ECE_517_Fall_2012/ch2a_2w3_sm]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w30 an]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w17 pt]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w31 up]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w9 ms]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w19 is]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w26 aj]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w5 dp]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w16 dp]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w8 vp]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w18 as]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w3 jm]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w23 sr]]
*[[CSC/ECE_517_Fall_2012/ch2a_2w11_aa]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w15 rr]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w33 pv]]
*[[CSC/ECE_517_Fall_2012/ch2a_2w20_aa]]
*[[CSC/ECE_517_Fall_2012/ch2a_2w14_bb]]
*[[CSC/ECE_517_Fall_2012/ch2a_2w21_ap]]
*[[CSC/ECE_517_Fall_2012/ch2a_2w13_sm]]
*[[CSC/ECE_517_Fall_2012/ch2a_2w4_sa]]
*[[CSC/ECE_517_Fall_2012/ch2a_2w25_nr]]
*[[CSC/ECE_517_Fall_2012/ch2a_2w12_sv]]
*[[CSC/ECE_517_Fall_2012/ch2a_2w7_ma]]
*[[CSC/ECE_517_Fall_2012/ch2a_2w6_ar]]
*[[CSC/ECE_517_Fall_2012/ch2a_2w32_mk]]
*[[CSC/ECE_517_Fall_2012/ch2a_2w10_rc]]
*[[CSC/ECE 517 Fall 2012/ch2b_2w70_sm]]
*[[CSC/ECE 517 Fall 2012/ch2b_2w67_sk]]
*[[CSC/ECE 517 Fall 2012/ch2b_2w40_sn]]
*[[CSC/ECE 517 Fall 2012/ch2b_2w22_sk]]
*[[CSC/ECE 517 Fall 2012/ch2b_2w-1w65_am]]
*[[CSC/ECE 517 Fall 2012/ch2b_2w59_bc]]
*[[CSC/ECE 517 Fall 2012/ch2b_2w60_ns]]
*[[CSC/ECE 517 Fall 2012/ch2b 2w47 am]]
*[[CSC/ECE 517 Fall 2012/ch2b_2w69_as]]
*[[CSC/ECE 517 Fall 2012/ch2b_2w39_ka]]
*[[CSC/ECE 517 Fall 2012/ch2b_2w36_av]]
*[[CSC/ECE 517 Fall 2012/ch2b_2w37_ms]]
*[[CSC/ECE 517 Fall 2012/ch2b_2w43_iv]]
*[[CSC/ECE 517 Fall 2012/ch2b_2w53_iv]]
*[[CSC/ECE 517 Fall 2012/ch2b_2w63_sp]]
*[[CSC/ECE 517 Fall 2012/ch2b_2w49_ps]]
*[[CSC/ECE 517 Fall 2012/ch2b_2w52_sj]]
*[[CSC/ECE 517 Fall 2012/ch2b_2w28_dh]]
*[[CSC/ECE 517 Fall 2012/ch1b 2w41 dc]]
*[[CSC/ECE_517_Fall_2012/ch2b_1w59_nm]]
*[[CSC/ECE_517_Fall_2012/ch2b_1w61_ps]]
*[[CSC/ECE_517_Fall_2012/ch2b_2w57]]
*[[CSC/ECE_517_Fall_2012/ch2b_2w42_aa]]
*[[CSC/ECE_517_Fall_2012/ch2b_1w61_ns]]
*[[CSC/ECE_517_Fall_2012/ch2b_2w51_aa]]
*[[CSC/ECE_517_Fall_2012/ch2b_2w45_pg]]
*[[CSC/ECE 517 Fall 2012/ch2b_2w48_aa]]
*[[CSC/ECE 517 Fall 2012/ch2b_1w70_nl]]
*[[CSC/ECE 517 Fall 2012/ch2b 2w64 bg]]
*[[CSC/ECE 517 Fall 2012/ch2b 2w62 pv]]

CSC/ECE 517 Fall 2012/ch1 1w3 pl

2012-09-15T02:12:36Z

Pvasude: /* Testing a Sample Ruby Application using Cucumber */

='''Unit-Testing Frameworks for Ruby: Cucumber'''=

This wiki-page serves as a knowledge source for understanding Unit-Testing Frameworks available for Ruby particularly Cucumber . 

__TOC__

=Introduction=

Unit testing <ref>[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2010/ch1_1f_vn Unit Testing in Ruby]</ref> is a software development process for testing individual units of source code independently for proper operation <ref>[http://en.wikipedia.org/wiki/Unit_testing Unit Testing]</ref>. An unit testing framework helps the process of unit testing by automating the test cases written to ensure the correctness of the system. They are often third-party products that are not offered as part of the suite. Ruby provides a framework in its standard library for setting up, organizing, and running tests called Test::Unit <ref>[http://en.wikibooks.org/wiki/Ruby_Programming/Unit_testing Ruby Unit Testing Framework]</ref>. Other testing frameworks available for Ruby are Shoulda, RSpec and Cucumber.

=Cucumber=
Cucumber is one of the latest unit test frameworks to have come for Ruby as part of the RSpec family of tools. Cucumber itself is written in the Ruby programming language and adheres to Behaviour Driven Development(BDD). Behaviour Driven Development is an Agile Development process that comprises aspects of Acceptance Test Driven Planning , Domain Driven Design and Test Driven Development (TDD). Cucumber is designed specifically to ensure that the acceptance tests can easily be read and written by anyone.

==Behaviour Driven Development(BDD)==

Behaviour Driven Development<ref>[http://en.wikipedia.org/wiki/Behavior-driven_development BDD]</ref> preserves the basic iterative (fail-pass) workflow of TDD, but stresses on specifying behaviors that are understandable to people (say from non-programming background). In this approach we write tests in a natural language that even a non-programmer can understand.

==Acceptance Test==

Acceptance Test<ref>[http://en.wikipedia.org/wiki/Acceptance_testing Acceptance Test]</ref><ref>[http://pragprog.com/book/hwcuc/the-cucumber-book Cucumber Book]</ref> Drive Planning is a practice that stresses on the importance of identifying the functions and requirements of the software beforehand so that we exactly know when the development phase ends. This practice results in fewer bugs , shorter delivery times and greater customer satisfaction.

===Cucumber Acceptance Test===

Feature: Sign up
Sign up should be quick and friendly. 
Scenario: Successful sign up
New users should get a confirmation email and be greeted personally by the site once signed in.
Given I have chosen to sign up
When I sign up with valid details
Then I should receive a confirmation email
And I should see a personalized greeting message 
Scenario: Duplicate email
Where someone tries to create an account for an email address that already exists.
Given I have chosen to sign up
But I enter an email address that has already registered
Then I should be told that the email is already registered
And I should be offered the option to recover my password

Acceptance tests written in this style are more than just tests; they are executable specifications. As of January 2012, Cucumber was the second most popular testing framework after RSpec for Ruby

==How Cucumber works==

Cucumber is a command-line tool. It reads in specifications from plain-language text files called features, examines them for scenarios to test, and runs the scenarios against the system. The feature files should be written according to specific syntax rules called Gherkin. Along with the features, you give Cucumber a set of step definitions, which map the business-readable language of each step into Ruby code to carry out whatever action is being described by the step. Cucumber takes customer understandable user stories as input and does integration and acceptance tests on the system with those as its input.

===Feature===
A Feature is a high level statement of the what the test case does and there is only one feature per user story. For every feature that is supported by the system , a separate feature file has to be written and included in the features directory. The feature files has .feature file extension.

===Scenario===
A Scenario consists of one or more steps which describe about the various actions performed by the user with respect to this particular feature. There can be one or more scenarios per feature in a user story. A feature usually contains 3 to 8 steps in it. The steps of the scenario always begin with one of the below mentioned key words :

1. Given : Steps that begin with given represent the state of the world before an event.(preconditions) 
2. When : Steps that represent the event. 
3. Then : Steps that represent the expected outcome. 
4. And and But : Steps that extend the previous step. 

===Step and Step Definitions===
When testing with Cucumber , The user stories are all kept in one set of files called Steps.The Steps are compared with Step Definitions which are files written in ruby which gives the rules based on which the steps are executed. Step definitions are analogous to method definitions and steps of scenarios are analogous to method calls. Cucumber uses regular expressions to match the English phrases in the steps of scenarios to step definitions.

When the cucumber test framework is run , The steps present in the feature file can be classified as follows based on the result of regex matching with the step definitions.<ref>[https://github.com/cucumber/cucumber/wiki/Step-Definitions Step Definitions in Ruby]</ref>

====Successful steps====
When Cucumber finds a matching Step Definition it will execute it. If the block in the step definition doesn’t raise an Exception, the step is marked as successful (green). What you return from a Step Definition has no significance what so ever.

====Undefined steps====
When Cucumber can’t find a matching Step Definition the step gets marked as yellow, and all subsequent steps in the scenario are skipped. If you use --strict this will cause Cucumber to exit with 1.

====Pending steps====
When a Step Definition’s Proc invokes the #pending method, the step is marked as yellow (as with undefined ones), reminding you that you have work to do. If you use --strict this will cause Cucumber to exit with 1.

====Failed steps====
When a Step Definition’s Proc is executed and raises an error, the step is marked as red. Returning nil or false will not cause a step definition to fail.

Cucumber tries to run the steps based on the definitions and thus colors steps based on the execution of the steps. The colors for the steps assigned are as follows : 
 
1. Green : for passing. 
2. Yellow : for not yet implemented. 
3. Red : for failing. 
4. Blue : Once a step fails all the successive steps are marked in blue. 

[[File:Cucumber.JPG|500px|thumb|center|Cucumber Testing Stack]]

==Advantages of Cucumber==
*Specifications can be written in more than forty different spoken languages.
*Cucumber helps reduce the gap between technical and non-technical members of a software team.
*Cucumber tests can be easily read and written by business stakeholders.
*Writing Cucumber tests are quick, easy, efficient and understandable.

=Cucumber Installation=

To install cucumber<ref>[http://cuke4ninja.com/sec_ruby_install_cucumber.html Installing Cucumber]</ref> we should make sure that the Environment path is set to “..../Ruby/bin”. Then open the command prompt and run

gem install cucumber

Once cucumber gem is installed then we would be able to check whether it is installed by issuing the following command:

cucumber --version

this should give a version number like “1.2.1”

Cucumber uses Rspec for assertions and hence we need Rspec installed to use Cucumber. Use the following command to install rspec

gem install rspec

=Testing a Sample Ruby Application using Cucumber=
Lets walk through a example for creating a Hello World Ruby application and testing it using cucumber<ref>[http://pragprog.com/book/hwcuc/the-cucumber-book Sample Cucumber Application]</ref>.

Step 1 : Create a new directory

mkdir HelloCucumber

Step 2 : Install Cucumber and Rspec

gem install cucumber
gem instal rspec

Step 3 : Create a directory features and create a file basic.feature in the features directory

mkdir features

Content of features/basic.feature

Feature: Hello World Feature 
Scenario: Hello World Scenario
Given The Action is Hello
When The Subject is World
Then The Greeting is Hello, World

Step 4: Create step_definitions directory inside features directory. Create basic_step.rb file inside step_definitions.

mkdir features/step_definitions

The directory structure looks like this
[[File:Dirstructure.JPG|400px|thumb|center|Directory structure]]
 
Content of features/step_definitions/basic_step.rb

require 'rspec/expectations' 
Given /The Action is ([A-z]*)/ do |action|
@action = action
end 
When /The Subject is ([A-z]*)/ do |subject|
@subject = subject
end 
Then /The Greeting is (.*)/ do |greeting|
greeting.should == "#{@action}, #{@subject}"
end
Cucumber uses regular expression after the keywords Given, When and Then to map lines in a feature file to step definitions.

Step 5: Running cucumber command you will see the following output

Feature: Hello World Feature 
Scenario: Hello World Scenario # features\basic.feature:3
Given The Action is Hello # features/step_definitions/basic_steps.rb:3
When The Subject is World # features/step_definitions/basic_steps.rb:7
Then The Greeting is Hello, World # features/step_definitions/basic_steps.rb:11 

1 scenario (1 passed)
3 steps (3 passed)
0m0.016s
Step 6 : Modify the basic.features file to include 2 scenario

Step 6 : Modify the basic.features file to include 2 scenarios

Feature: Hello World Feature 
Scenario: Hello World Scenario
Given The Action is Hello
When The Subject is World
Then The Greeting is Hello, World 
Scenario: Bye World Scenario
Given The Action is Bye
When The Subject is World
Then The Greeting is Hello, World

Step 7 : Running the cucumber command you will see the following output

Scenario: Hello World Scenario # features\basic.feature:3
Given The Action is Hello # features/step_definitions/basic_steps.rb:3
When The Subject is World # features/step_definitions/basic_steps.rb:7
Then The Greeting is Hello, World # features/step_definitions/basic_steps.rb:11 
Scenario: Bye World Scenario # features\basic.feature:8
Given The Action is Bye # features/step_definitions/basic_steps.rb:3
When The Subject is World # features/step_definitions/basic_steps.rb:7
Then The Greeting is Hello, World # features/step_definitions/basic_steps.rb:11
expected: "Bye, World"
got: "Hello, World" (using ==) (RSpec::Expectations::ExpectationNotMetError)
./features/step_definitions/basic_steps.rb:12:in `/The Greeting is (.*)/'
features\basic.feature:11:in `Then The Greeting is Hello, World' 
Failing Scenarios:
cucumber features\basic.feature:8 # Scenario: Bye World Scenario 
2 scenarios (1 failed, 1 passed)
6 steps (1 failed, 5 passed)
0m0.033s

The Bye Scenario fails since the expected output is “Hello, World” but the received output is “Bye,World”.

=Testing a Sample Rails Application using Cucumber=

Cucumber<ref>[http://railscasts.com/episodes/155-beginning-with-cucumber Sample Cucumber Application on Rails]</ref> easily integrates with Rails and hence can be used with Ruby applications which run on Rails. But there are few steps which have to be followed before you will be able to run cucumber with Rails. Lets walk through the steps by creating a new rails application.

rails new cucumber_app

Install the required cucumber gems
 
gem install cucumber
gem install cucumber cucumber-rails

Add the following lines to your gemfile. These gems should be added only to the test environment. The gems database_cleaner , rspec-rails and webrat are required for cucumber to function properly.
 
group :test do
gem 'database_cleaner'
gem 'cucumber'
gem "rspec-rails", "~> 2.0", :require => false
gem "cucumber-rails", "1.0.6"
gem 'webrat'
end

After modifying the gem file, run bundle update

bundle update

The required cucumber files are generated using the following command. The output below the command shows the folders and files that gets created for the cucumber test framework.

rails generate cucumber:install
 
identical script/cucumber
chmod script/cucumber
exist features/step_definitions
identical features/step_definitions/web_steps.rb
exist features/support
identical features/support/paths.rb
identical features/support/selectors.rb
identical features/support/env.rb
exist lib/tasks
identical lib/tasks/cucumber.rake
 
The step_definitions folder contains ruby files which test the steps which are mentioned in feature file of the cucumber.
 
The paths.rb file is created in the support folder will contain the rules based on which the step definitions will be compared to the steps and matched. In case we come across any steps whose execution fails while running cucumber we would have to update the paths.rb file to resolve the issue.
 
env.rb is only loaded when the application is first started up and it sets up the environment required by Cucumber to execute.
 
rails generate model article title:string content:text
rake db:migrate
rake db:test:clone
rails generate controller articles index
 
The above four commands generate models with the name article and with two fields title and content
and the next two commands migrate the db to production and the last command creates controllers for article and index objects.
 
We have to go to the home directory of our rails application and then run Cucumber with the following command.The result would then be shown to the user on how many and which steps succeeded and failed.

=> cucumber
===Capybara===
<ref>[http://net.tutsplus.com/tutorials/ruby/ruby-for-newbies-testing-web-apps-with-capybara-and-cucumber Web-app with Cucumber and Capybara]</ref>

We need a tool that acts out the user stories that are part of the feature that is to be tested with Cucumber. Capybara can be used as that tool. Capybara is an integration testing tool for rack based web based applications. It simulates how a user would interact with a website. It can simulate the actions of a web browser and hence can interact with the application to receive web pages. It can also parse the HTML content and submits forms as the user would. One of the restrictions that Capybara has is that it cannot handle JavaScript. There are other tools like webdriver which can handle JavaScript but it runs a lot slower compared to Capybara.

=Comparison of Unit Test Frameworks : Rspec, Shoulda and Cucumber=

{|border="2" cellpadding="5" cellspacing="0" align="center"
|-
! scope="col" | Rspec
! scope="col" | Shoulda
! scope="col" | Cucumber

|-
|RSpec is based on the Behaviour driven development model provided by Ruby. It has its origins in Test Driven Development and Domain Driven Design.
|Shoulda is based on the Test:Unit which is another Ruby Test Framework. It is based on Test Driven Development.
|Cucumber is a combination of Test Driven Development and Behaviour driven development.
|-
|RSpec provides a Domain Specific Language that can express code functionality and behaviour.
|Shoulda provides macros, helpers and matchers.
|Cucumber allows the test cases to be written in native languages.
|-
|RSpec too allows nested describe structure.
|Shoulda has nested contexts which helps create different environment for different set of tests.
|Cucumber is similar to RSpec and provides nested structures.
|-
|RSpec is expressive when it comes to understanding functionalities since it was designed with the human readability in mind.
|Shoulda has more descriptive names compared to its predecessor Test::Unit but its less expressive.
|Cucumber is more descriptive and allows business stakeholder to read and write test specification.

|}

=Summary=

Cucumber<ref>[http://pragprog.com/book/hwcuc/the-cucumber-book Advantage of Cucumber]</ref> helps facilitate the discovery and use of a ubiquitous language within the team. Cucumber tests interact directly with the developers’ code, but they’re written in a high level language that business stakeholders can understand. When the team uses this language consistently in their conversations, documentation, and code, the friction of translating between everyone’s different little dialects is
gone, and the chances of misunderstandings are greatly reduced. What makes Cucumber stand out from the crowd of other testing tools is that it has been designed specifically to ensure the acceptance tests can easily be read—and written—by anyone on the team.In practice, this means that your documentation, rather than being something that’s written once and then gradually goes out of date, becomes a living thing that reflects the true state of the project

=Reference=
<references/>

CSC/ECE 517 Fall 2012/ch1 1w3 pl

2012-09-15T02:11:36Z

Pvasude: /* Testing a Sample Ruby Application using Cucumber */

='''Unit-Testing Frameworks for Ruby: Cucumber'''=

This wiki-page serves as a knowledge source for understanding Unit-Testing Frameworks available for Ruby particularly Cucumber . 

__TOC__

=Introduction=

Unit testing <ref>[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2010/ch1_1f_vn Unit Testing in Ruby]</ref> is a software development process for testing individual units of source code independently for proper operation <ref>[http://en.wikipedia.org/wiki/Unit_testing Unit Testing]</ref>. An unit testing framework helps the process of unit testing by automating the test cases written to ensure the correctness of the system. They are often third-party products that are not offered as part of the suite. Ruby provides a framework in its standard library for setting up, organizing, and running tests called Test::Unit <ref>[http://en.wikibooks.org/wiki/Ruby_Programming/Unit_testing Ruby Unit Testing Framework]</ref>. Other testing frameworks available for Ruby are Shoulda, RSpec and Cucumber.

=Cucumber=
Cucumber is one of the latest unit test frameworks to have come for Ruby as part of the RSpec family of tools. Cucumber itself is written in the Ruby programming language and adheres to Behaviour Driven Development(BDD). Behaviour Driven Development is an Agile Development process that comprises aspects of Acceptance Test Driven Planning , Domain Driven Design and Test Driven Development (TDD). Cucumber is designed specifically to ensure that the acceptance tests can easily be read and written by anyone.

==Behaviour Driven Development(BDD)==

Behaviour Driven Development<ref>[http://en.wikipedia.org/wiki/Behavior-driven_development BDD]</ref> preserves the basic iterative (fail-pass) workflow of TDD, but stresses on specifying behaviors that are understandable to people (say from non-programming background). In this approach we write tests in a natural language that even a non-programmer can understand.

==Acceptance Test==

Acceptance Test<ref>[http://en.wikipedia.org/wiki/Acceptance_testing Acceptance Test]</ref><ref>[http://pragprog.com/book/hwcuc/the-cucumber-book Cucumber Book]</ref> Drive Planning is a practice that stresses on the importance of identifying the functions and requirements of the software beforehand so that we exactly know when the development phase ends. This practice results in fewer bugs , shorter delivery times and greater customer satisfaction.

===Cucumber Acceptance Test===

Feature: Sign up
Sign up should be quick and friendly. 
Scenario: Successful sign up
New users should get a confirmation email and be greeted personally by the site once signed in.
Given I have chosen to sign up
When I sign up with valid details
Then I should receive a confirmation email
And I should see a personalized greeting message 
Scenario: Duplicate email
Where someone tries to create an account for an email address that already exists.
Given I have chosen to sign up
But I enter an email address that has already registered
Then I should be told that the email is already registered
And I should be offered the option to recover my password

Acceptance tests written in this style are more than just tests; they are executable specifications. As of January 2012, Cucumber was the second most popular testing framework after RSpec for Ruby

==How Cucumber works==

Cucumber is a command-line tool. It reads in specifications from plain-language text files called features, examines them for scenarios to test, and runs the scenarios against the system. The feature files should be written according to specific syntax rules called Gherkin. Along with the features, you give Cucumber a set of step definitions, which map the business-readable language of each step into Ruby code to carry out whatever action is being described by the step. Cucumber takes customer understandable user stories as input and does integration and acceptance tests on the system with those as its input.

===Feature===
A Feature is a high level statement of the what the test case does and there is only one feature per user story. For every feature that is supported by the system , a separate feature file has to be written and included in the features directory. The feature files has .feature file extension.

===Scenario===
A Scenario consists of one or more steps which describe about the various actions performed by the user with respect to this particular feature. There can be one or more scenarios per feature in a user story. A feature usually contains 3 to 8 steps in it. The steps of the scenario always begin with one of the below mentioned key words :

1. Given : Steps that begin with given represent the state of the world before an event.(preconditions) 
2. When : Steps that represent the event. 
3. Then : Steps that represent the expected outcome. 
4. And and But : Steps that extend the previous step. 

===Step and Step Definitions===
When testing with Cucumber , The user stories are all kept in one set of files called Steps.The Steps are compared with Step Definitions which are files written in ruby which gives the rules based on which the steps are executed. Step definitions are analogous to method definitions and steps of scenarios are analogous to method calls. Cucumber uses regular expressions to match the English phrases in the steps of scenarios to step definitions.

When the cucumber test framework is run , The steps present in the feature file can be classified as follows based on the result of regex matching with the step definitions.<ref>[https://github.com/cucumber/cucumber/wiki/Step-Definitions Step Definitions in Ruby]</ref>

====Successful steps====
When Cucumber finds a matching Step Definition it will execute it. If the block in the step definition doesn’t raise an Exception, the step is marked as successful (green). What you return from a Step Definition has no significance what so ever.

====Undefined steps====
When Cucumber can’t find a matching Step Definition the step gets marked as yellow, and all subsequent steps in the scenario are skipped. If you use --strict this will cause Cucumber to exit with 1.

====Pending steps====
When a Step Definition’s Proc invokes the #pending method, the step is marked as yellow (as with undefined ones), reminding you that you have work to do. If you use --strict this will cause Cucumber to exit with 1.

====Failed steps====
When a Step Definition’s Proc is executed and raises an error, the step is marked as red. Returning nil or false will not cause a step definition to fail.

Cucumber tries to run the steps based on the definitions and thus colors steps based on the execution of the steps. The colors for the steps assigned are as follows : 
 
1. Green : for passing. 
2. Yellow : for not yet implemented. 
3. Red : for failing. 
4. Blue : Once a step fails all the successive steps are marked in blue. 

[[File:Cucumber.JPG|500px|thumb|center|Cucumber Testing Stack]]

==Advantages of Cucumber==
*Specifications can be written in more than forty different spoken languages.
*Cucumber helps reduce the gap between technical and non-technical members of a software team.
*Cucumber tests can be easily read and written by business stakeholders.
*Writing Cucumber tests are quick, easy, efficient and understandable.

=Cucumber Installation=

To install cucumber<ref>[http://cuke4ninja.com/sec_ruby_install_cucumber.html Installing Cucumber]</ref> we should make sure that the Environment path is set to “..../Ruby/bin”. Then open the command prompt and run

gem install cucumber

Once cucumber gem is installed then we would be able to check whether it is installed by issuing the following command:

cucumber --version

this should give a version number like “1.2.1”

Cucumber uses Rspec for assertions and hence we need Rspec installed to use Cucumber. Use the following command to install rspec

gem install rspec

=Testing a Sample Ruby Application using Cucumber=
Lets walk through a example for creating a Hello World Ruby application and testing it using cucumber<ref>[http://pragprog.com/book/hwcuc/the-cucumber-book Sample Cucumber Application]</ref>.

Step 1 : Create a new directory

mkdir HelloCucumber

Step 2 : Install Cucumber and Rspec

gem install cucumber
gem instal rspec

Step 3 : Create a directory features and create a file basic.feature in the features directory

mkdir features

Content of features/basic.feature

Feature: Hello World Feature 
Scenario: Hello World Scenario
Given The Action is Hello
When The Subject is World
Then The Greeting is Hello, World

Step 4: Create step_definitions directory inside features directory. Create basic_step.rb file inside step_definitions.

mkdir features/step_definitions

The directory structure looks like this
[[File:Dirstructure.JPG|400px|thumb|left|Directory structure]]
 
Content of features/step_definitions/basic_step.rb

require 'rspec/expectations' 
Given /The Action is ([A-z]*)/ do |action|
@action = action
end 
When /The Subject is ([A-z]*)/ do |subject|
@subject = subject
end 
Then /The Greeting is (.*)/ do |greeting|
greeting.should == "#{@action}, #{@subject}"
end
Cucumber uses regular expression after the keywords Given, When and Then to map lines in a feature file to step definitions.

Step 5: Running cucumber command you will see the following output

Feature: Hello World Feature 
Scenario: Hello World Scenario # features\basic.feature:3
Given The Action is Hello # features/step_definitions/basic_steps.rb:3
When The Subject is World # features/step_definitions/basic_steps.rb:7
Then The Greeting is Hello, World # features/step_definitions/basic_steps.rb:11 

1 scenario (1 passed)
3 steps (3 passed)
0m0.016s
Step 6 : Modify the basic.features file to include 2 scenario

Step 6 : Modify the basic.features file to include 2 scenarios

Feature: Hello World Feature 
Scenario: Hello World Scenario
Given The Action is Hello
When The Subject is World
Then The Greeting is Hello, World 
Scenario: Bye World Scenario
Given The Action is Bye
When The Subject is World
Then The Greeting is Hello, World

Step 7 : Running the cucumber command you will see the following output

Scenario: Hello World Scenario # features\basic.feature:3
Given The Action is Hello # features/step_definitions/basic_steps.rb:3
When The Subject is World # features/step_definitions/basic_steps.rb:7
Then The Greeting is Hello, World # features/step_definitions/basic_steps.rb:11 
Scenario: Bye World Scenario # features\basic.feature:8
Given The Action is Bye # features/step_definitions/basic_steps.rb:3
When The Subject is World # features/step_definitions/basic_steps.rb:7
Then The Greeting is Hello, World # features/step_definitions/basic_steps.rb:11
expected: "Bye, World"
got: "Hello, World" (using ==) (RSpec::Expectations::ExpectationNotMetError)
./features/step_definitions/basic_steps.rb:12:in `/The Greeting is (.*)/'
features\basic.feature:11:in `Then The Greeting is Hello, World' 
Failing Scenarios:
cucumber features\basic.feature:8 # Scenario: Bye World Scenario 
2 scenarios (1 failed, 1 passed)
6 steps (1 failed, 5 passed)
0m0.033s

The Bye Scenario fails since the expected output is “Hello, World” but the received output is “Bye,World”.

=Testing a Sample Rails Application using Cucumber=

Cucumber<ref>[http://railscasts.com/episodes/155-beginning-with-cucumber Sample Cucumber Application on Rails]</ref> easily integrates with Rails and hence can be used with Ruby applications which run on Rails. But there are few steps which have to be followed before you will be able to run cucumber with Rails. Lets walk through the steps by creating a new rails application.

rails new cucumber_app

Install the required cucumber gems
 
gem install cucumber
gem install cucumber cucumber-rails

Add the following lines to your gemfile. These gems should be added only to the test environment. The gems database_cleaner , rspec-rails and webrat are required for cucumber to function properly.
 
group :test do
gem 'database_cleaner'
gem 'cucumber'
gem "rspec-rails", "~> 2.0", :require => false
gem "cucumber-rails", "1.0.6"
gem 'webrat'
end

After modifying the gem file, run bundle update

bundle update

The required cucumber files are generated using the following command. The output below the command shows the folders and files that gets created for the cucumber test framework.

rails generate cucumber:install
 
identical script/cucumber
chmod script/cucumber
exist features/step_definitions
identical features/step_definitions/web_steps.rb
exist features/support
identical features/support/paths.rb
identical features/support/selectors.rb
identical features/support/env.rb
exist lib/tasks
identical lib/tasks/cucumber.rake
 
The step_definitions folder contains ruby files which test the steps which are mentioned in feature file of the cucumber.
 
The paths.rb file is created in the support folder will contain the rules based on which the step definitions will be compared to the steps and matched. In case we come across any steps whose execution fails while running cucumber we would have to update the paths.rb file to resolve the issue.
 
env.rb is only loaded when the application is first started up and it sets up the environment required by Cucumber to execute.
 
rails generate model article title:string content:text
rake db:migrate
rake db:test:clone
rails generate controller articles index
 
The above four commands generate models with the name article and with two fields title and content
and the next two commands migrate the db to production and the last command creates controllers for article and index objects.
 
We have to go to the home directory of our rails application and then run Cucumber with the following command.The result would then be shown to the user on how many and which steps succeeded and failed.

=> cucumber
===Capybara===
<ref>[http://net.tutsplus.com/tutorials/ruby/ruby-for-newbies-testing-web-apps-with-capybara-and-cucumber Web-app with Cucumber and Capybara]</ref>

We need a tool that acts out the user stories that are part of the feature that is to be tested with Cucumber. Capybara can be used as that tool. Capybara is an integration testing tool for rack based web based applications. It simulates how a user would interact with a website. It can simulate the actions of a web browser and hence can interact with the application to receive web pages. It can also parse the HTML content and submits forms as the user would. One of the restrictions that Capybara has is that it cannot handle JavaScript. There are other tools like webdriver which can handle JavaScript but it runs a lot slower compared to Capybara.

=Comparison of Unit Test Frameworks : Rspec, Shoulda and Cucumber=

{|border="2" cellpadding="5" cellspacing="0" align="center"
|-
! scope="col" | Rspec
! scope="col" | Shoulda
! scope="col" | Cucumber

|-
|RSpec is based on the Behaviour driven development model provided by Ruby. It has its origins in Test Driven Development and Domain Driven Design.
|Shoulda is based on the Test:Unit which is another Ruby Test Framework. It is based on Test Driven Development.
|Cucumber is a combination of Test Driven Development and Behaviour driven development.
|-
|RSpec provides a Domain Specific Language that can express code functionality and behaviour.
|Shoulda provides macros, helpers and matchers.
|Cucumber allows the test cases to be written in native languages.
|-
|RSpec too allows nested describe structure.
|Shoulda has nested contexts which helps create different environment for different set of tests.
|Cucumber is similar to RSpec and provides nested structures.
|-
|RSpec is expressive when it comes to understanding functionalities since it was designed with the human readability in mind.
|Shoulda has more descriptive names compared to its predecessor Test::Unit but its less expressive.
|Cucumber is more descriptive and allows business stakeholder to read and write test specification.

|}

=Summary=

Cucumber<ref>[http://pragprog.com/book/hwcuc/the-cucumber-book Advantage of Cucumber]</ref> helps facilitate the discovery and use of a ubiquitous language within the team. Cucumber tests interact directly with the developers’ code, but they’re written in a high level language that business stakeholders can understand. When the team uses this language consistently in their conversations, documentation, and code, the friction of translating between everyone’s different little dialects is
gone, and the chances of misunderstandings are greatly reduced. What makes Cucumber stand out from the crowd of other testing tools is that it has been designed specifically to ensure the acceptance tests can easily be read—and written—by anyone on the team.In practice, this means that your documentation, rather than being something that’s written once and then gradually goes out of date, becomes a living thing that reflects the true state of the project

=Reference=
<references/>

CSC/ECE 517 Fall 2012/ch1 1w3 pl

2012-09-15T02:10:30Z

Pvasude: /* Testing a Sample Ruby Application using Cucumber */

='''Unit-Testing Frameworks for Ruby: Cucumber'''=

This wiki-page serves as a knowledge source for understanding Unit-Testing Frameworks available for Ruby particularly Cucumber . 

__TOC__

=Introduction=

Unit testing <ref>[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2010/ch1_1f_vn Unit Testing in Ruby]</ref> is a software development process for testing individual units of source code independently for proper operation <ref>[http://en.wikipedia.org/wiki/Unit_testing Unit Testing]</ref>. An unit testing framework helps the process of unit testing by automating the test cases written to ensure the correctness of the system. They are often third-party products that are not offered as part of the suite. Ruby provides a framework in its standard library for setting up, organizing, and running tests called Test::Unit <ref>[http://en.wikibooks.org/wiki/Ruby_Programming/Unit_testing Ruby Unit Testing Framework]</ref>. Other testing frameworks available for Ruby are Shoulda, RSpec and Cucumber.

=Cucumber=
Cucumber is one of the latest unit test frameworks to have come for Ruby as part of the RSpec family of tools. Cucumber itself is written in the Ruby programming language and adheres to Behaviour Driven Development(BDD). Behaviour Driven Development is an Agile Development process that comprises aspects of Acceptance Test Driven Planning , Domain Driven Design and Test Driven Development (TDD). Cucumber is designed specifically to ensure that the acceptance tests can easily be read and written by anyone.

==Behaviour Driven Development(BDD)==

Behaviour Driven Development<ref>[http://en.wikipedia.org/wiki/Behavior-driven_development BDD]</ref> preserves the basic iterative (fail-pass) workflow of TDD, but stresses on specifying behaviors that are understandable to people (say from non programming background). In this approach we write tests in a natural language that even a non-programmer can understand.

==Acceptance Test==

Acceptance Test<ref>[http://en.wikipedia.org/wiki/Acceptance_testing Acceptance Test]</ref><ref>[http://pragprog.com/book/hwcuc/the-cucumber-book Cucumber Book]</ref> Drive Planning is a practice that stresses on the importance of identifying the functions and requirements of the software beforehand so that we exactly know when the development phase ends. This practice results in fewer bugs , shorter delivery times and greater customer satisfaction.

===Cucumber Acceptance Test===

Feature: Sign up
Sign up should be quick and friendly. 
Scenario: Successful sign up
New users should get a confirmation email and be greeted personally by the site once signed in.
Given I have chosen to sign up
When I sign up with valid details
Then I should receive a confirmation email
And I should see a personalized greeting message 
Scenario: Duplicate email
Where someone tries to create an account for an email address that already exists.
Given I have chosen to sign up
But I enter an email address that has already registered
Then I should be told that the email is already registered
And I should be offered the option to recover my password

Acceptance tests written in this style are more than just tests; they are executable specifications. As of January 2012, Cucumber was the second most popular testing framework after RSpec for Ruby

==How Cucumber works==

Cucumber is a command-line tool. It reads in specifications from plain-language text files called features, examines them for scenarios to test, and runs the scenarios against the system. The feature files should be written according to specific syntax rules called Gherkin. Along with the features, you give Cucumber a set of step definitions, which map the business-readable language of each step into Ruby code to carry out whatever action is being described by the step. Cucumber takes customer understandable user stories as input and does integration and acceptance tests on the system with those as its input.

===Feature===
A Feature is a high level statement of the what the test case does and there is only one feature per user story. For every feature that is supported by the system , a separate feature file has to be written and included in the features directory. The feature files has .feature file extension.

===Scenario===
A Scenario consists of one or more steps which describe about the various actions performed by the user with respect to this particular feature. There can be one or more scenarios per feature in a user story. A feature usually contains 3 to 8 steps in it. The steps of the scenario always begin with one of the below mentioned key words :

1. Given : Steps that begin with given represent the state of the world before an event.(preconditions) 
2. When : Steps that represent the event. 
3. Then : Steps that represent the expected outcome. 
4. And and But : Steps that extend the previous step. 

===Step and Step Definitions===
When testing with Cucumber , The user stories are all kept in one set of files called Steps.The Steps are compared with Step Definitions which are files written in ruby which gives the rules based on which the steps are executed. Step definitions are analogous to method definitions and steps of scenarios are analogous to method calls. Cucumber uses regular expressions to match the English phrases in the steps of scenarios to step definitions.

When the cucumber test framework is run , The steps present in the feature file can be classified as follows based on the result of regex matching with the step definitions.<ref>[https://github.com/cucumber/cucumber/wiki/Step-Definitions Step Definitions in Ruby]</ref>

====Successful steps====
When Cucumber finds a matching Step Definition it will execute it. If the block in the step definition doesn’t raise an Exception, the step is marked as successful (green). What you return from a Step Definition has no significance what so ever.

====Undefined steps====
When Cucumber can’t find a matching Step Definition the step gets marked as yellow, and all subsequent steps in the scenario are skipped. If you use --strict this will cause Cucumber to exit with 1.

====Pending steps====
When a Step Definition’s Proc invokes the #pending method, the step is marked as yellow (as with undefined ones), reminding you that you have work to do. If you use --strict this will cause Cucumber to exit with 1.

====Failed steps====
When a Step Definition’s Proc is executed and raises an error, the step is marked as red. Returning nil or false will not cause a step definition to fail.

Cucumber tries to run the steps based on the definitions and thus colors steps based on the execution of the steps. The colors for the steps assigned are as follows : 
 
1. Green : for passing. 
2. Yellow : for not yet implemented. 
3. Red : for failing. 
4. Blue : Once a step fails all the successive steps are marked in blue. 

[[File:Cucumber.JPG|500px|thumb|center|Cucumber Testing Stack]]

==Advantages of Cucumber==
*Specifications can be written in more than forty different spoken languages.
*Cucumber helps reduce the gap between technical and non-technical members of a software team.
*Cucumber tests can be easily read and written by business stakeholders.
*Writing Cucumber tests are quick, easy, efficient and understandable.

=Cucumber Installation=

To install cucumber<ref>[http://cuke4ninja.com/sec_ruby_install_cucumber.html Installing Cucumber]</ref> we should make sure that the Environment path is set to “..../Ruby/bin”. Then open the command prompt and run

gem install cucumber

Once cucumber gem is installed then we would be able to check whether it is installed by issuing the following command:

cucumber --version

this should give a version number like “1.2.1”

Cucumber uses Rspec for assertions and hence we need Rspec installed to use Cucumber. Use the following command to install rspec

gem install rspec

=Testing a Sample Ruby Application using Cucumber=
Lets walk through a example for creating a Hello World Ruby application and testing it using cucumber<ref>[http://pragprog.com/book/hwcuc/the-cucumber-book Sample Cucumber Application]</ref>.

Step 1 : Create a new directory

mkdir HelloCucumber

Step 2 : Install Cucumber and Rspec

gem install cucumber
gem instal rspec

Step 3 : Create a directory features and create a file basic.feature in the features directory

mkdir features

Content of features/basic.feature

Feature: Hello World Feature 
Scenario: Hello World Scenario
Given The Action is Hello
When The Subject is World
Then The Greeting is Hello, World

Step 4: Create step_definitions directory inside features directory. Create basic_step.rb file inside step_definitions.

mkdir features/step_definitions

The directory structure looks like this
[[File:Dirstructure.JPG|400px|thumb|left|Directory structure]]

Content of features/step_definitions/basic_step.rb

require 'rspec/expectations' 
Given /The Action is ([A-z]*)/ do |action|
@action = action
end 
When /The Subject is ([A-z]*)/ do |subject|
@subject = subject
end 
Then /The Greeting is (.*)/ do |greeting|
greeting.should == "#{@action}, #{@subject}"
end
Cucumber uses regular expression after the keywords Given, When and Then to map lines in a feature file to step definitions.

Step 5: Running cucumber command you will see the following output

Feature: Hello World Feature 
Scenario: Hello World Scenario # features\basic.feature:3
Given The Action is Hello # features/step_definitions/basic_steps.rb:3
When The Subject is World # features/step_definitions/basic_steps.rb:7
Then The Greeting is Hello, World # features/step_definitions/basic_steps.rb:11 

1 scenario (1 passed)
3 steps (3 passed)
0m0.016s
Step 6 : Modify the basic.features file to include 2 scenario

Step 6 : Modify the basic.features file to include 2 scenarios

Feature: Hello World Feature 
Scenario: Hello World Scenario
Given The Action is Hello
When The Subject is World
Then The Greeting is Hello, World 
Scenario: Bye World Scenario
Given The Action is Bye
When The Subject is World
Then The Greeting is Hello, World

Step 7 : Running the cucumber command you will see the following output

Scenario: Hello World Scenario # features\basic.feature:3
Given The Action is Hello # features/step_definitions/basic_steps.rb:3
When The Subject is World # features/step_definitions/basic_steps.rb:7
Then The Greeting is Hello, World # features/step_definitions/basic_steps.rb:11 
Scenario: Bye World Scenario # features\basic.feature:8
Given The Action is Bye # features/step_definitions/basic_steps.rb:3
When The Subject is World # features/step_definitions/basic_steps.rb:7
Then The Greeting is Hello, World # features/step_definitions/basic_steps.rb:11
expected: "Bye, World"
got: "Hello, World" (using ==) (RSpec::Expectations::ExpectationNotMetError)
./features/step_definitions/basic_steps.rb:12:in `/The Greeting is (.*)/'
features\basic.feature:11:in `Then The Greeting is Hello, World' 
Failing Scenarios:
cucumber features\basic.feature:8 # Scenario: Bye World Scenario 
2 scenarios (1 failed, 1 passed)
6 steps (1 failed, 5 passed)
0m0.033s

The Bye Scenario fails since the expected output is “Hello, World” but the received output is “Bye,World”.

=Testing a Sample Rails Application using Cucumber=

Cucumber<ref>[http://railscasts.com/episodes/155-beginning-with-cucumber Sample Cucumber Application on Rails]</ref> easily integrates with Rails and hence can be used with Ruby applications which run on Rails. But there are few steps which have to be followed before you will be able to run cucumber with Rails. Lets walk through the steps by creating a new rails application.

rails new cucumber_app

Install the required cucumber gems
 
gem install cucumber
gem install cucumber cucumber-rails

Add the following lines to your gemfile. These gems should be added only to the test environment. The gems database_cleaner , rspec-rails and webrat are required for cucumber to function properly.
 
group :test do
gem 'database_cleaner'
gem 'cucumber'
gem "rspec-rails", "~> 2.0", :require => false
gem "cucumber-rails", "1.0.6"
gem 'webrat'
end

After modifying the gem file, run bundle update

bundle update

The required cucumber files are generated using the following command. The output below the command shows the folders and files that gets created for the cucumber test framework.

rails generate cucumber:install
 
identical script/cucumber
chmod script/cucumber
exist features/step_definitions
identical features/step_definitions/web_steps.rb
exist features/support
identical features/support/paths.rb
identical features/support/selectors.rb
identical features/support/env.rb
exist lib/tasks
identical lib/tasks/cucumber.rake
 
The step_definitions folder contains ruby files which test the steps which are mentioned in feature file of the cucumber.
 
The paths.rb file is created in the support folder will contain the rules based on which the step definitions will be compared to the steps and matched. In case we come across any steps whose execution fails while running cucumber we would have to update the paths.rb file to resolve the issue.
 
env.rb is only loaded when the application is first started up and it sets up the environment required by Cucumber to execute.
 
rails generate model article title:string content:text
rake db:migrate
rake db:test:clone
rails generate controller articles index
 
The above four commands generate models with the name article and with two fields title and content
and the next two commands migrate the db to production and the last command creates controllers for article and index objects.
 
We have to go to the home directory of our rails application and then run Cucumber with the following command.The result would then be shown to the user on how many and which steps succeeded and failed.

=> cucumber
===Capybara===
<ref>[http://net.tutsplus.com/tutorials/ruby/ruby-for-newbies-testing-web-apps-with-capybara-and-cucumber Web-app with Cucumber and Capybara]</ref>

We need a tool that acts out the user stories that are part of the feature that is to be tested with Cucumber. Capybara can be used as that tool. Capybara is an integration testing tool for rack based web based applications. It simulates how a user would interact with a website. It can simulate the actions of a web browser and hence can interact with the application to receive web pages. It can also parse the HTML content and submits forms as the user would. One of the restrictions that Capybara has is that it cannot handle JavaScript. There are other tools like webdriver which can handle JavaScript but it runs a lot slower compared to Capybara.

=Comparison of Unit Test Frameworks : Rspec, Shoulda and Cucumber=

{|border="2" cellpadding="5" cellspacing="0" align="center"
|-
! scope="col" | Rspec
! scope="col" | Shoulda
! scope="col" | Cucumber

|-
|RSpec is based on the Behaviour driven development model provided by Ruby. It has its origins in Test Driven Development and Domain Driven Design.
|Shoulda is based on the Test:Unit which is another Ruby Test Framework. It is based on Test Driven Development.
|Cucumber is a combination of Test Driven Development and Behaviour driven development.
|-
|RSpec provides a Domain Specific Language that can express code functionality and behaviour.
|Shoulda provides macros, helpers and matchers.
|Cucumber allows the test cases to be written in native languages.
|-
|RSpec too allows nested describe structure.
|Shoulda has nested contexts which helps create different environment for different set of tests.
|Cucumber is similar to RSpec and provides nested structures.
|-
|RSpec is expressive when it comes to understanding functionalities since it was designed with the human readability in mind.
|Shoulda has more descriptive names compared to its predecessor Test::Unit but its less expressive.
|Cucumber is more descriptive and allows business stakeholder to read and write test specification.

|}

=Summary=

Cucumber<ref>[http://pragprog.com/book/hwcuc/the-cucumber-book Advantage of Cucumber]</ref> helps facilitate the discovery and use of a ubiquitous language within the team. Cucumber tests interact directly with the developers’ code, but they’re written in a high level language that business stakeholders can understand. When the team uses this language consistently in their conversations, documentation, and code, the friction of translating between everyone’s different little dialects is
gone, and the chances of misunderstandings are greatly reduced. What makes Cucumber stand out from the crowd of other testing tools is that it has been designed specifically to ensure the acceptance tests can easily be read—and written—by anyone on the team.In practice, this means that your documentation, rather than being something that’s written once and then gradually goes out of date, becomes a living thing that reflects the true state of the project

=Reference=
<references/>

CSC/ECE 517 Fall 2012/ch1 1w3 pl

2012-09-15T02:09:56Z

Pvasude: /* Testing a Sample Ruby Application using Cucumber */

='''Unit-Testing Frameworks for Ruby: Cucumber'''=

This wiki-page serves as a knowledge source for understanding Unit-Testing Frameworks available for Ruby particularly Cucumber . 

__TOC__

=Introduction=

Unit testing <ref>[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2010/ch1_1f_vn Unit Testing in Ruby]</ref> is a software development process for testing individual units of source code independently for proper operation <ref>[http://en.wikipedia.org/wiki/Unit_testing Unit Testing]</ref>. An unit testing framework helps the process of unit testing by automating the test cases written to ensure the correctness of the system. They are often third-party products that are not offered as part of the suite. Ruby provides a framework in its standard library for setting up, organizing, and running tests called Test::Unit <ref>[http://en.wikibooks.org/wiki/Ruby_Programming/Unit_testing Ruby Unit Testing Framework]</ref>. Other testing frameworks available for ruby are Shoulda, RSpec and Cucumber.

=Cucumber=
Cucumber is one of the latest unit test frameworks to have come for Ruby as part of the RSpec family of tools. Cucumber itself is written in the Ruby programming language and adheres to Behaviour Driven Development(BDD). Behaviour Driven Development is an Agile Development process that comprises aspects of Acceptance Test Driven Planning , Domain Driven Design and Test Driven Development (TDD). Cucumber is designed specifically to ensure that the acceptance tests can easily be read and written by anyone.

==Behaviour Driven Development(BDD)==

Behaviour Driven Development<ref>[http://en.wikipedia.org/wiki/Behavior-driven_development BDD]</ref> preserves the basic iterative (fail-pass) workflow of TDD, but stresses on specifying behaviors that are understandable to people (say from non programming background). In this approach we write tests in a natural language that even a non-programmer can understand.

==Acceptance Test==

Acceptance Test<ref>[http://en.wikipedia.org/wiki/Acceptance_testing Acceptance Test]</ref><ref>[http://pragprog.com/book/hwcuc/the-cucumber-book Cucumber Book]</ref> Drive Planning is a practice that stresses on the importance of identifying the functions and requirements of the software beforehand so that we exactly know when the development phase ends. This practice results in fewer bugs , shorter delivery times and greater customer satisfaction.

===Cucumber Acceptance Test===

Feature: Sign up
Sign up should be quick and friendly. 
Scenario: Successful sign up
New users should get a confirmation email and be greeted personally by the site once signed in.
Given I have chosen to sign up
When I sign up with valid details
Then I should receive a confirmation email
And I should see a personalized greeting message 
Scenario: Duplicate email
Where someone tries to create an account for an email address that already exists.
Given I have chosen to sign up
But I enter an email address that has already registered
Then I should be told that the email is already registered
And I should be offered the option to recover my password

Acceptance tests written in this style are more than just tests; they are executable specifications. As of January 2012, Cucumber was the second most popular testing framework after RSpec for Ruby

==How Cucumber works==

Cucumber is a command-line tool. It reads in specifications from plain-language text files called features, examines them for scenarios to test, and runs the scenarios against the system. The feature files should be written according to specific syntax rules called Gherkin. Along with the features, you give Cucumber a set of step definitions, which map the business-readable language of each step into Ruby code to carry out whatever action is being described by the step. Cucumber takes customer understandable user stories as input and does integration and acceptance tests on the system with those as its input.

===Feature===
A Feature is a high level statement of the what the test case does and there is only one feature per user story. For every feature that is supported by the system , a separate feature file has to be written and included in the features directory. The feature files has .feature file extension.

===Scenario===
A Scenario consists of one or more steps which describe about the various actions performed by the user with respect to this particular feature. There can be one or more scenarios per feature in a user story. A feature usually contains 3 to 8 steps in it. The steps of the scenario always begin with one of the below mentioned key words :

1. Given : Steps that begin with given represent the state of the world before an event.(preconditions) 
2. When : Steps that represent the event. 
3. Then : Steps that represent the expected outcome. 
4. And and But : Steps that extend the previous step. 

===Step and Step Definitions===
When testing with Cucumber , The user stories are all kept in one set of files called Steps.The Steps are compared with Step Definitions which are files written in ruby which gives the rules based on which the steps are executed. Step definitions are analogous to method definitions and steps of scenarios are analogous to method calls. Cucumber uses regular expressions to match the English phrases in the steps of scenarios to step definitions.

When the cucumber test framework is run , The steps present in the feature file can be classified as follows based on the result of regex matching with the step definitions.<ref>[https://github.com/cucumber/cucumber/wiki/Step-Definitions Step Definitions in Ruby]</ref>

====Successful steps====
When Cucumber finds a matching Step Definition it will execute it. If the block in the step definition doesn’t raise an Exception, the step is marked as successful (green). What you return from a Step Definition has no significance what so ever.

====Undefined steps====
When Cucumber can’t find a matching Step Definition the step gets marked as yellow, and all subsequent steps in the scenario are skipped. If you use --strict this will cause Cucumber to exit with 1.

====Pending steps====
When a Step Definition’s Proc invokes the #pending method, the step is marked as yellow (as with undefined ones), reminding you that you have work to do. If you use --strict this will cause Cucumber to exit with 1.

====Failed steps====
When a Step Definition’s Proc is executed and raises an error, the step is marked as red. Returning nil or false will not cause a step definition to fail.

Cucumber tries to run the steps based on the definitions and thus colors steps based on the execution of the steps. The colors for the steps assigned are as follows : 
 
1. Green : for passing. 
2. Yellow : for not yet implemented. 
3. Red : for failing. 
4. Blue : Once a step fails all the successive steps are marked in blue. 

[[File:Cucumber.JPG|500px|thumb|center|Cucumber Testing Stack]]

==Advantages of Cucumber==
*Specifications can be written in more than forty different spoken languages.
*Cucumber helps reduce the gap between technical and non-technical members of a software team.
*Cucumber tests can be easily read and written by business stakeholders.
*Writing Cucumber tests are quick, easy, efficient and understandable.

=Cucumber Installation=

To install cucumber<ref>[http://cuke4ninja.com/sec_ruby_install_cucumber.html Installing Cucumber]</ref> we should make sure that the Environment path is set to “..../Ruby/bin”. Then open the command prompt and run

gem install cucumber

Once cucumber gem is installed then we would be able to check whether it is installed by issuing the following command:

cucumber --version

this should give a version number like “1.2.1”

Cucumber uses Rspec for assertions and hence we need Rspec installed to use Cucumber. Use the following command to install rspec

gem install rspec

=Testing a Sample Ruby Application using Cucumber=
Lets walk through a example for creating a Hello World Ruby application and testing it using cucumber<ref>[http://pragprog.com/book/hwcuc/the-cucumber-book Sample Cucumber Application]</ref>.

Step 1 : Create a new directory

mkdir HelloCucumber

Step 2 : Install Cucumber and Rspec

gem install cucumber
gem instal rspec

Step 3 : Create a directory features and create a file basic.feature in the features directory

mkdir features

Content of features/basic.feature

Feature: Hello World Feature 
Scenario: Hello World Scenario
Given The Action is Hello
When The Subject is World
Then The Greeting is Hello, World

Step 4: Create step_definitions directory inside features directory. Create basic_step.rb file inside step_definitions.

mkdir features/step_definitions

The directory structure looks like this
[[File:Dirstructure.JPG|200px|thumb|center|Directory structure]]

Content of features/step_definitions/basic_step.rb

require 'rspec/expectations' 
Given /The Action is ([A-z]*)/ do |action|
@action = action
end 
When /The Subject is ([A-z]*)/ do |subject|
@subject = subject
end 
Then /The Greeting is (.*)/ do |greeting|
greeting.should == "#{@action}, #{@subject}"
end
Cucumber uses regular expression after the keywords Given, When and Then to map lines in a feature file to step definitions.

Step 5: Running cucumber command you will see the following output

Feature: Hello World Feature 
Scenario: Hello World Scenario # features\basic.feature:3
Given The Action is Hello # features/step_definitions/basic_steps.rb:3
When The Subject is World # features/step_definitions/basic_steps.rb:7
Then The Greeting is Hello, World # features/step_definitions/basic_steps.rb:11 

1 scenario (1 passed)
3 steps (3 passed)
0m0.016s
Step 6 : Modify the basic.features file to include 2 scenario

Step 6 : Modify the basic.features file to include 2 scenarios

Feature: Hello World Feature 
Scenario: Hello World Scenario
Given The Action is Hello
When The Subject is World
Then The Greeting is Hello, World 
Scenario: Bye World Scenario
Given The Action is Bye
When The Subject is World
Then The Greeting is Hello, World

Step 7 : Running the cucumber command you will see the following output

Scenario: Hello World Scenario # features\basic.feature:3
Given The Action is Hello # features/step_definitions/basic_steps.rb:3
When The Subject is World # features/step_definitions/basic_steps.rb:7
Then The Greeting is Hello, World # features/step_definitions/basic_steps.rb:11 
Scenario: Bye World Scenario # features\basic.feature:8
Given The Action is Bye # features/step_definitions/basic_steps.rb:3
When The Subject is World # features/step_definitions/basic_steps.rb:7
Then The Greeting is Hello, World # features/step_definitions/basic_steps.rb:11
expected: "Bye, World"
got: "Hello, World" (using ==) (RSpec::Expectations::ExpectationNotMetError)
./features/step_definitions/basic_steps.rb:12:in `/The Greeting is (.*)/'
features\basic.feature:11:in `Then The Greeting is Hello, World' 
Failing Scenarios:
cucumber features\basic.feature:8 # Scenario: Bye World Scenario 
2 scenarios (1 failed, 1 passed)
6 steps (1 failed, 5 passed)
0m0.033s

The Bye Scenario fails since the expected output is “Hello, World” but the received output is “Bye,World”.

=Testing a Sample Rails Application using Cucumber=

Cucumber<ref>[http://railscasts.com/episodes/155-beginning-with-cucumber Sample Cucumber Application on Rails]</ref> easily integrates with Rails and hence can be used with Ruby applications which run on Rails. But there are few steps which have to be followed before you will be able to run cucumber with Rails. Lets walk through the steps by creating a new rails application.

rails new cucumber_app

Install the required cucumber gems
 
gem install cucumber
gem install cucumber cucumber-rails

Add the following lines to your gemfile. These gems should be added only to the test environment. The gems database_cleaner , rspec-rails and webrat are required for cucumber to function properly.
 
group :test do
gem 'database_cleaner'
gem 'cucumber'
gem "rspec-rails", "~> 2.0", :require => false
gem "cucumber-rails", "1.0.6"
gem 'webrat'
end

After modifying the gem file, run bundle update

bundle update

The required cucumber files are generated using the following command. The output below the command shows the folders and files that gets created for the cucumber test framework.

rails generate cucumber:install
 
identical script/cucumber
chmod script/cucumber
exist features/step_definitions
identical features/step_definitions/web_steps.rb
exist features/support
identical features/support/paths.rb
identical features/support/selectors.rb
identical features/support/env.rb
exist lib/tasks
identical lib/tasks/cucumber.rake
 
The step_definitions folder contains ruby files which test the steps which are mentioned in feature file of the cucumber.
 
The paths.rb file is created in the support folder will contain the rules based on which the step definitions will be compared to the steps and matched. In case we come across any steps whose execution fails while running cucumber we would have to update the paths.rb file to resolve the issue.
 
env.rb is only loaded when the application is first started up and it sets up the environment required by Cucumber to execute.
 
rails generate model article title:string content:text
rake db:migrate
rake db:test:clone
rails generate controller articles index
 
The above four commands generate models with the name article and with two fields title and content
and the next two commands migrate the db to production and the last command creates controllers for article and index objects.
 
We have to go to the home directory of our rails application and then run Cucumber with the following command.The result would then be shown to the user on how many and which steps succeeded and failed.

=> cucumber
===Capybara===
<ref>[http://net.tutsplus.com/tutorials/ruby/ruby-for-newbies-testing-web-apps-with-capybara-and-cucumber Web-app with Cucumber and Capybara]</ref>

We need a tool that acts out the user stories that are part of the feature that is to be tested with Cucumber. Capybara can be used as that tool. Capybara is an integration testing tool for rack based web based applications. It simulates how a user would interact with a website. It can simulate the actions of a web browser and hence can interact with the application to receive web pages. It can also parse the HTML content and submits forms as the user would. One of the restrictions that Capybara has is that it cannot handle JavaScript. There are other tools like webdriver which can handle JavaScript but it runs a lot slower compared to Capybara.

=Comparison of Unit Test Frameworks : Rspec, Shoulda and Cucumber=

{|border="2" cellpadding="5" cellspacing="0" align="center"
|-
! scope="col" | Rspec
! scope="col" | Shoulda
! scope="col" | Cucumber

|-
|RSpec is based on the Behaviour driven development model provided by Ruby. It has its origins in Test Driven Development and Domain Driven Design.
|Shoulda is based on the Test:Unit which is another Ruby Test Framework. It is based on Test Driven Development.
|Cucumber is a combination of Test Driven Development and Behaviour driven development.
|-
|RSpec provides a Domain Specific Language that can express code functionality and behaviour.
|Shoulda provides macros, helpers and matchers.
|Cucumber allows the test cases to be written in native languages.
|-
|RSpec too allows nested describe structure.
|Shoulda has nested contexts which helps create different environment for different set of tests.
|Cucumber is similar to RSpec and provides nested structures.
|-
|RSpec is expressive when it comes to understanding functionalities since it was designed with the human readability in mind.
|Shoulda has more descriptive names compared to its predecessor Test::Unit but its less expressive.
|Cucumber is more descriptive and allows business stakeholder to read and write test specification.

|}

=Summary=

Cucumber<ref>[http://pragprog.com/book/hwcuc/the-cucumber-book Advantage of Cucumber]</ref> helps facilitate the discovery and use of a ubiquitous language within the team. Cucumber tests interact directly with the developers’ code, but they’re written in a high level language that business stakeholders can understand. When the team uses this language consistently in their conversations, documentation, and code, the friction of translating between everyone’s different little dialects is
gone, and the chances of misunderstandings are greatly reduced. What makes Cucumber stand out from the crowd of other testing tools is that it has been designed specifically to ensure the acceptance tests can easily be read—and written—by anyone on the team.In practice, this means that your documentation, rather than being something that’s written once and then gradually goes out of date, becomes a living thing that reflects the true state of the project

=Reference=
<references/>

CSC/ECE 517 Fall 2012/ch1 1w3 pl

2012-09-15T02:09:32Z

Pvasude: /* Testing a Sample Ruby Application using Cucumber */

='''Unit-Testing Frameworks for Ruby: Cucumber'''=

This wiki-page serves as a knowledge source for understanding Unit-Testing Frameworks available for Ruby particularly Cucumber . 

__TOC__

=Introduction=

Unit testing <ref>[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2010/ch1_1f_vn Unit Testing in Ruby]</ref> is a software development process for testing individual units of source code independently for proper operation <ref>[http://en.wikipedia.org/wiki/Unit_testing Unit Testing]</ref>. An unit testing framework helps the process of unit testing by automating the test cases written to ensure the correctness of the system. They are often third-party products that are not offered as part of the suite. Ruby provides a framework in its standard library for setting up, organizing, and running tests called Test::Unit <ref>[http://en.wikibooks.org/wiki/Ruby_Programming/Unit_testing Ruby Unit Testing Framework]</ref>. Other testing frameworks available for ruby are Shoulda, RSpec and Cucumber.

=Cucumber=
Cucumber is one of the latest unit test frameworks to have come for Ruby as part of the RSpec family of tools. Cucumber itself is written in the Ruby programming language and adheres to Behaviour Driven Development(BDD). Behaviour Driven Development is an Agile Development process that comprises aspects of Acceptance Test Driven Planning , Domain Driven Design and Test Driven Development (TDD). Cucumber is designed specifically to ensure that the acceptance tests can easily be read and written by anyone.

==Behaviour Driven Development(BDD)==

Behaviour Driven Development<ref>[http://en.wikipedia.org/wiki/Behavior-driven_development BDD]</ref> preserves the basic iterative (fail-pass) workflow of TDD, but stresses on specifying behaviors that are understandable to people (say from non programming background). In this approach we write tests in a natural language that even a non-programmer can understand.

==Acceptance Test==

Acceptance Test<ref>[http://en.wikipedia.org/wiki/Acceptance_testing Acceptance Test]</ref><ref>[http://pragprog.com/book/hwcuc/the-cucumber-book Cucumber Book]</ref> Drive Planning is a practice that stresses on the importance of identifying the functions and requirements of the software beforehand so that we exactly know when the development phase ends. This practice results in fewer bugs , shorter delivery times and greater customer satisfaction.

===Cucumber Acceptance Test===

Feature: Sign up
Sign up should be quick and friendly. 
Scenario: Successful sign up
New users should get a confirmation email and be greeted personally by the site once signed in.
Given I have chosen to sign up
When I sign up with valid details
Then I should receive a confirmation email
And I should see a personalized greeting message 
Scenario: Duplicate email
Where someone tries to create an account for an email address that already exists.
Given I have chosen to sign up
But I enter an email address that has already registered
Then I should be told that the email is already registered
And I should be offered the option to recover my password

Acceptance tests written in this style are more than just tests; they are executable specifications. As of January 2012, Cucumber was the second most popular testing framework after RSpec for Ruby

==How Cucumber works==

Cucumber is a command-line tool. It reads in specifications from plain-language text files called features, examines them for scenarios to test, and runs the scenarios against the system. The feature files should be written according to specific syntax rules called Gherkin. Along with the features, you give Cucumber a set of step definitions, which map the business-readable language of each step into Ruby code to carry out whatever action is being described by the step. Cucumber takes customer understandable user stories as input and does integration and acceptance tests on the system with those as its input.

===Feature===
A Feature is a high level statement of the what the test case does and there is only one feature per user story. For every feature that is supported by the system , a separate feature file has to be written and included in the features directory. The feature files has .feature file extension.

===Scenario===
A Scenario consists of one or more steps which describe about the various actions performed by the user with respect to this particular feature. There can be one or more scenarios per feature in a user story. A feature usually contains 3 to 8 steps in it. The steps of the scenario always begin with one of the below mentioned key words :

1. Given : Steps that begin with given represent the state of the world before an event.(preconditions) 
2. When : Steps that represent the event. 
3. Then : Steps that represent the expected outcome. 
4. And and But : Steps that extend the previous step. 

===Step and Step Definitions===
When testing with Cucumber , The user stories are all kept in one set of files called Steps.The Steps are compared with Step Definitions which are files written in ruby which gives the rules based on which the steps are executed. Step definitions are analogous to method definitions and steps of scenarios are analogous to method calls. Cucumber uses regular expressions to match the English phrases in the steps of scenarios to step definitions.

When the cucumber test framework is run , The steps present in the feature file can be classified as follows based on the result of regex matching with the step definitions.<ref>[https://github.com/cucumber/cucumber/wiki/Step-Definitions Step Definitions in Ruby]</ref>

====Successful steps====
When Cucumber finds a matching Step Definition it will execute it. If the block in the step definition doesn’t raise an Exception, the step is marked as successful (green). What you return from a Step Definition has no significance what so ever.

====Undefined steps====
When Cucumber can’t find a matching Step Definition the step gets marked as yellow, and all subsequent steps in the scenario are skipped. If you use --strict this will cause Cucumber to exit with 1.

====Pending steps====
When a Step Definition’s Proc invokes the #pending method, the step is marked as yellow (as with undefined ones), reminding you that you have work to do. If you use --strict this will cause Cucumber to exit with 1.

====Failed steps====
When a Step Definition’s Proc is executed and raises an error, the step is marked as red. Returning nil or false will not cause a step definition to fail.

Cucumber tries to run the steps based on the definitions and thus colors steps based on the execution of the steps. The colors for the steps assigned are as follows : 
 
1. Green : for passing. 
2. Yellow : for not yet implemented. 
3. Red : for failing. 
4. Blue : Once a step fails all the successive steps are marked in blue. 

[[File:Cucumber.JPG|500px|thumb|center|Cucumber Testing Stack]]

==Advantages of Cucumber==
*Specifications can be written in more than forty different spoken languages.
*Cucumber helps reduce the gap between technical and non-technical members of a software team.
*Cucumber tests can be easily read and written by business stakeholders.
*Writing Cucumber tests are quick, easy, efficient and understandable.

=Cucumber Installation=

To install cucumber<ref>[http://cuke4ninja.com/sec_ruby_install_cucumber.html Installing Cucumber]</ref> we should make sure that the Environment path is set to “..../Ruby/bin”. Then open the command prompt and run

gem install cucumber

Once cucumber gem is installed then we would be able to check whether it is installed by issuing the following command:

cucumber --version

this should give a version number like “1.2.1”

Cucumber uses Rspec for assertions and hence we need Rspec installed to use Cucumber. Use the following command to install rspec

gem install rspec

=Testing a Sample Ruby Application using Cucumber=
Lets walk through a example for creating a Hello World Ruby application and testing it using cucumber<ref>[http://pragprog.com/book/hwcuc/the-cucumber-book Sample Cucumber Application]</ref>.

Step 1 : Create a new directory

mkdir HelloCucumber

Step 2 : Install Cucumber and Rspec

gem install cucumber
gem instal rspec

Step 3 : Create a directory features and create a file basic.feature in the features directory

mkdir features

Content of features/basic.feature

Feature: Hello World Feature 
Scenario: Hello World Scenario
Given The Action is Hello
When The Subject is World
Then The Greeting is Hello, World

Step 4: Create step_definitions directory inside features directory. Create basic_step.rb file inside step_definitions.

mkdir features/step_definitions

The directory structure looks like this
[[File:File.png|200px|thumb|center|Directory structure]]

Content of features/step_definitions/basic_step.rb

require 'rspec/expectations' 
Given /The Action is ([A-z]*)/ do |action|
@action = action
end 
When /The Subject is ([A-z]*)/ do |subject|
@subject = subject
end 
Then /The Greeting is (.*)/ do |greeting|
greeting.should == "#{@action}, #{@subject}"
end
Cucumber uses regular expression after the keywords Given, When and Then to map lines in a feature file to step definitions.

Step 5: Running cucumber command you will see the following output

Feature: Hello World Feature 
Scenario: Hello World Scenario # features\basic.feature:3
Given The Action is Hello # features/step_definitions/basic_steps.rb:3
When The Subject is World # features/step_definitions/basic_steps.rb:7
Then The Greeting is Hello, World # features/step_definitions/basic_steps.rb:11 

1 scenario (1 passed)
3 steps (3 passed)
0m0.016s
Step 6 : Modify the basic.features file to include 2 scenario

Step 6 : Modify the basic.features file to include 2 scenarios

Feature: Hello World Feature 
Scenario: Hello World Scenario
Given The Action is Hello
When The Subject is World
Then The Greeting is Hello, World 
Scenario: Bye World Scenario
Given The Action is Bye
When The Subject is World
Then The Greeting is Hello, World

Step 7 : Running the cucumber command you will see the following output

Scenario: Hello World Scenario # features\basic.feature:3
Given The Action is Hello # features/step_definitions/basic_steps.rb:3
When The Subject is World # features/step_definitions/basic_steps.rb:7
Then The Greeting is Hello, World # features/step_definitions/basic_steps.rb:11 
Scenario: Bye World Scenario # features\basic.feature:8
Given The Action is Bye # features/step_definitions/basic_steps.rb:3
When The Subject is World # features/step_definitions/basic_steps.rb:7
Then The Greeting is Hello, World # features/step_definitions/basic_steps.rb:11
expected: "Bye, World"
got: "Hello, World" (using ==) (RSpec::Expectations::ExpectationNotMetError)
./features/step_definitions/basic_steps.rb:12:in `/The Greeting is (.*)/'
features\basic.feature:11:in `Then The Greeting is Hello, World' 
Failing Scenarios:
cucumber features\basic.feature:8 # Scenario: Bye World Scenario 
2 scenarios (1 failed, 1 passed)
6 steps (1 failed, 5 passed)
0m0.033s

The Bye Scenario fails since the expected output is “Hello, World” but the received output is “Bye,World”.

=Testing a Sample Rails Application using Cucumber=

Cucumber<ref>[http://railscasts.com/episodes/155-beginning-with-cucumber Sample Cucumber Application on Rails]</ref> easily integrates with Rails and hence can be used with Ruby applications which run on Rails. But there are few steps which have to be followed before you will be able to run cucumber with Rails. Lets walk through the steps by creating a new rails application.

rails new cucumber_app

Install the required cucumber gems
 
gem install cucumber
gem install cucumber cucumber-rails

Add the following lines to your gemfile. These gems should be added only to the test environment. The gems database_cleaner , rspec-rails and webrat are required for cucumber to function properly.
 
group :test do
gem 'database_cleaner'
gem 'cucumber'
gem "rspec-rails", "~> 2.0", :require => false
gem "cucumber-rails", "1.0.6"
gem 'webrat'
end

After modifying the gem file, run bundle update

bundle update

The required cucumber files are generated using the following command. The output below the command shows the folders and files that gets created for the cucumber test framework.

rails generate cucumber:install
 
identical script/cucumber
chmod script/cucumber
exist features/step_definitions
identical features/step_definitions/web_steps.rb
exist features/support
identical features/support/paths.rb
identical features/support/selectors.rb
identical features/support/env.rb
exist lib/tasks
identical lib/tasks/cucumber.rake
 
The step_definitions folder contains ruby files which test the steps which are mentioned in feature file of the cucumber.
 
The paths.rb file is created in the support folder will contain the rules based on which the step definitions will be compared to the steps and matched. In case we come across any steps whose execution fails while running cucumber we would have to update the paths.rb file to resolve the issue.
 
env.rb is only loaded when the application is first started up and it sets up the environment required by Cucumber to execute.
 
rails generate model article title:string content:text
rake db:migrate
rake db:test:clone
rails generate controller articles index
 
The above four commands generate models with the name article and with two fields title and content
and the next two commands migrate the db to production and the last command creates controllers for article and index objects.
 
We have to go to the home directory of our rails application and then run Cucumber with the following command.The result would then be shown to the user on how many and which steps succeeded and failed.

=> cucumber
===Capybara===
<ref>[http://net.tutsplus.com/tutorials/ruby/ruby-for-newbies-testing-web-apps-with-capybara-and-cucumber Web-app with Cucumber and Capybara]</ref>

We need a tool that acts out the user stories that are part of the feature that is to be tested with Cucumber. Capybara can be used as that tool. Capybara is an integration testing tool for rack based web based applications. It simulates how a user would interact with a website. It can simulate the actions of a web browser and hence can interact with the application to receive web pages. It can also parse the HTML content and submits forms as the user would. One of the restrictions that Capybara has is that it cannot handle JavaScript. There are other tools like webdriver which can handle JavaScript but it runs a lot slower compared to Capybara.

=Comparison of Unit Test Frameworks : Rspec, Shoulda and Cucumber=

{|border="2" cellpadding="5" cellspacing="0" align="center"
|-
! scope="col" | Rspec
! scope="col" | Shoulda
! scope="col" | Cucumber

|-
|RSpec is based on the Behaviour driven development model provided by Ruby. It has its origins in Test Driven Development and Domain Driven Design.
|Shoulda is based on the Test:Unit which is another Ruby Test Framework. It is based on Test Driven Development.
|Cucumber is a combination of Test Driven Development and Behaviour driven development.
|-
|RSpec provides a Domain Specific Language that can express code functionality and behaviour.
|Shoulda provides macros, helpers and matchers.
|Cucumber allows the test cases to be written in native languages.
|-
|RSpec too allows nested describe structure.
|Shoulda has nested contexts which helps create different environment for different set of tests.
|Cucumber is similar to RSpec and provides nested structures.
|-
|RSpec is expressive when it comes to understanding functionalities since it was designed with the human readability in mind.
|Shoulda has more descriptive names compared to its predecessor Test::Unit but its less expressive.
|Cucumber is more descriptive and allows business stakeholder to read and write test specification.

|}

=Summary=

Cucumber<ref>[http://pragprog.com/book/hwcuc/the-cucumber-book Advantage of Cucumber]</ref> helps facilitate the discovery and use of a ubiquitous language within the team. Cucumber tests interact directly with the developers’ code, but they’re written in a high level language that business stakeholders can understand. When the team uses this language consistently in their conversations, documentation, and code, the friction of translating between everyone’s different little dialects is
gone, and the chances of misunderstandings are greatly reduced. What makes Cucumber stand out from the crowd of other testing tools is that it has been designed specifically to ensure the acceptance tests can easily be read—and written—by anyone on the team.In practice, this means that your documentation, rather than being something that’s written once and then gradually goes out of date, becomes a living thing that reflects the true state of the project

=Reference=
<references/>

File:Dirstructure.JPG

2012-09-15T02:07:25Z

Pvasude:

CSC/ECE 517 Fall 2012/ch1 1w3 pl

2012-09-14T21:56:44Z

Pvasude: /* Summary */

='''Unit-Testing Frameworks for Ruby: Cucumber'''=

This wiki-page serves as a knowledge source for understanding Unit-Testing Frameworks available for Ruby particularly Cucumber . 

__TOC__

=Introduction=

Unit testing <ref>[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2010/ch1_1f_vn Unit Testing in Ruby]</ref> is a software development process for testing individual units of source code independently for proper operation <ref>[http://en.wikipedia.org/wiki/Unit_testing Unit Testing]</ref>. An unit testing framework helps the process of unit testing by automating the test cases written to ensure the correctness of the system. They are often third-party products that are not offered as part of the suite.Ruby provides a framework in its standard library for setting up, organizing, and running tests called Test::Unit <ref>[http://en.wikibooks.org/wiki/Ruby_Programming/Unit_testing Ruby Unit Testing Framework]</ref>. Other testing frameworks available for ruby are Shoulda, RSpec and Cucumber.

=Cucumber=
Cucumber is one of the latest unit test frameworks to have come for Ruby as part of the RSpec family of tools. Cucumber itself is written in the Ruby programming language and adheres to Behaviour Driven Development(BDD). Behaviour Driven Development is an Agile Development process that comprises aspects of Acceptance Test Driven Planning , Domain Driven Design and Test Driven Development (TDD). Cucumber is designed specifically to ensure that the acceptance tests can easily be read and written by anyone.

==Behaviour Driven Development(BDD)==

Behaviour Driven Development<ref>[http://en.wikipedia.org/wiki/Behavior-driven_development BDD]</ref> preserves the basic iterative (fail-pass) workflow of TDD, but stresses on specifying behaviors that are understandable to people (say from non programming background). In this approach we write tests in a natural language that even a non-programmer can understand.

==Acceptance Test==

Acceptance Test<ref>[http://en.wikipedia.org/wiki/Acceptance_testing Acceptance Test]</ref><ref>[http://pragprog.com/book/hwcuc/the-cucumber-book Cucumber Book]</ref> Drive Planning is a practice that stresses on the importance of identifying the functions and requirements of the software beforehand so that we exactly know when the development phase ends. This practice results in fewer bugs , shorter delivery times and greater customer satisfaction.

===Cucumber Acceptance Test===

Feature: Sign up
Sign up should be quick and friendly. 
Scenario: Successful sign up
New users should get a confirmation email and be greeted personally by the site once signed in.
Given I have chosen to sign up
When I sign up with valid details
Then I should receive a confirmation email
And I should see a personalized greeting message 
Scenario: Duplicate email
Where someone tries to create an account for an email address that already exists.
Given I have chosen to sign up
But I enter an email address that has already registered
Then I should be told that the email is already registered
And I should be offered the option to recover my password

Acceptance tests written in this style are more than just tests; they are executable specifications. As of January 2012, Cucumber was the second most popular testing framework after RSpec for Ruby

==How Cucumber works==

Cucumber is a command-line tool. It reads in specifications from plain-language text files called features, examines them for scenarios to test, and runs the scenarios against the system. The feature files should be written according to specific syntax rules called Gherkin. Along with the features, you give Cucumber a set of step definitions, which map the business-readable language of each step into Ruby code to carry out whatever action is being described by the step. Cucumber takes customer understandable user stories as input and does integration and acceptance tests on the system with those as its input.

===Feature===
A Feature is a high level statement of the what the test case does and there is only one feature per user story. For every feature that is supported by the system , a separate feature file has to be written and included in the features directory. The feature files has .feature file extension.

===Scenario===
A Scenario consists of one or more steps which describe about the various actions performed by the user with respect to this particular feature. There can be one or more scenarios per feature in a user story. A feature usually contains 3 to 8 steps in it. The steps of the scenario always begin with one of the below mentioned key words :

1. Given : Steps that begin with given represent the state of the world before an event.(preconditions) 
2. When : Steps that represent the event. 
3. Then : Steps that represent the expected outcome. 
4. And and But : Steps that extend the previous step. 

===Step and Step Definitions===
When testing with Cucumber , The user stories are all kept in one set of files called Steps.The Steps are compared with Step Definitions which are files written in ruby which gives the rules based on which the steps are executed. Step definitions are analogous to method definitions and steps of scenarios are analogous to method calls. Cucumber uses regular expressions to match the English phrases in the steps of scenarios to step definitions.

When the cucumber test framework is run , The steps present in the feature file can be classified as follows based on the result of regex matching with the step definitions.<ref>[https://github.com/cucumber/cucumber/wiki/Step-Definitions Step Definitions in Ruby]</ref>

====Successful steps====
When Cucumber finds a matching Step Definition it will execute it. If the block in the step definition doesn’t raise an Exception, the step is marked as successful (green). What you return from a Step Definition has no significance what so ever.

====Undefined steps====
When Cucumber can’t find a matching Step Definition the step gets marked as yellow, and all subsequent steps in the scenario are skipped. If you use --strict this will cause Cucumber to exit with 1.

====Pending steps====
When a Step Definition’s Proc invokes the #pending method, the step is marked as yellow (as with undefined ones), reminding you that you have work to do. If you use --strict this will cause Cucumber to exit with 1.

====Failed steps====
When a Step Definition’s Proc is executed and raises an error, the step is marked as red. Returning nil or false will not cause a step definition to fail.

Cucumber tries to run the steps based on the definitions and thus colors steps based on the execution of the steps. The colors for the steps assigned are as follows : 
 
1. Green : for passing. 
2. Yellow : for not yet implemented. 
3. Red : for failing. 
4. Blue : Once a step fails all the successive steps are marked in blue. 

[[File:Cucumber.JPG|500px|thumb|center|Cucumber Testing Stack]]

==Advantages of Cucumber==
*Specifications can be written in more than forty different spoken languages.
*Cucumber helps reduce the gap between technical and non-technical members of a software team.
*Cucumber tests can be easily read and written by business stakeholders.
*Writing Cucumber tests are quick, easy, efficient and understandable.

=Cucumber Installation=

To install cucumber<ref>[http://cuke4ninja.com/sec_ruby_install_cucumber.html Installing Cucumber]</ref> we should make sure that the Environment path is set to “..../Ruby/bin”. Then open the command prompt and run

gem install cucumber

Once cucumber gem is installed then we would be able to check whether it is installed by issuing the following command:

cucumber --version

this should give a version number like “1.2.1”

Cucumber uses Rspec for assertions and hence we need Rspec installed to use Cucumber. Use the following command to install rspec

gem install rspec

=Testing a Sample Ruby Application using Cucumber=
Lets walk through a example for creating a Hello World Ruby application and testing it using cucumber<ref>[http://pragprog.com/book/hwcuc/the-cucumber-book Sample Cucumber Application]</ref>.

Step 1 : Create a new directory

mkdir HelloCucumber

Step 2 : Install Cucumber and Rspec

gem install cucumber
gem instal rspec

Step 3 : Create a directory features and create a file basic.feature in the features directory

mkdir features

Content of features/basic.feature

Feature: Hello World Feature 
Scenario: Hello World Scenario
Given The Action is Hello
When The Subject is World
Then The Greeting is Hello, World

Step 4: Create step_definitions directory inside features directory. Create basic_step.rb file inside step_definitions.

mkdir features/step_definitions

Content of features/step_definitions/basic_step.rb

require 'rspec/expectations' 
Given /The Action is ([A-z]*)/ do |action|
@action = action
end 
When /The Subject is ([A-z]*)/ do |subject|
@subject = subject
end 
Then /The Greeting is (.*)/ do |greeting|
greeting.should == "#{@action}, #{@subject}"
end
Cucumber uses regular expression after the keywords Given, When and Then to map lines in a feature file to step definitions.

Step 5: Running cucumber command you will see the following output

Feature: Hello World Feature 
Scenario: Hello World Scenario # features\basic.feature:3
Given The Action is Hello # features/step_definitions/basic_steps.rb:3
When The Subject is World # features/step_definitions/basic_steps.rb:7
Then The Greeting is Hello, World # features/step_definitions/basic_steps.rb:11 

1 scenario (1 passed)
3 steps (3 passed)
0m0.016s
Step 6 : Modify the basic.features file to include 2 scenario

Step 6 : Modify the basic.features file to include 2 scenarios

Feature: Hello World Feature 
Scenario: Hello World Scenario
Given The Action is Hello
When The Subject is World
Then The Greeting is Hello, World 
Scenario: Bye World Scenario
Given The Action is Bye
When The Subject is World
Then The Greeting is Hello, World

Step 7 : Running the cucumber command you will see the following output

Scenario: Hello World Scenario # features\basic.feature:3
Given The Action is Hello # features/step_definitions/basic_steps.rb:3
When The Subject is World # features/step_definitions/basic_steps.rb:7
Then The Greeting is Hello, World # features/step_definitions/basic_steps.rb:11 
Scenario: Bye World Scenario # features\basic.feature:8
Given The Action is Bye # features/step_definitions/basic_steps.rb:3
When The Subject is World # features/step_definitions/basic_steps.rb:7
Then The Greeting is Hello, World # features/step_definitions/basic_steps.rb:11
expected: "Bye, World"
got: "Hello, World" (using ==) (RSpec::Expectations::ExpectationNotMetError)
./features/step_definitions/basic_steps.rb:12:in `/The Greeting is (.*)/'
features\basic.feature:11:in `Then The Greeting is Hello, World' 
Failing Scenarios:
cucumber features\basic.feature:8 # Scenario: Bye World Scenario 
2 scenarios (1 failed, 1 passed)
6 steps (1 failed, 5 passed)
0m0.033s

The Bye Scenario fails since the expected output is “Hello, World” but the received output is “Bye,World”.

=Testing a Sample Rails Application using Cucumber=

Cucumber<ref>[http://railscasts.com/episodes/155-beginning-with-cucumber Sample Cucumber Application on Rails]</ref> easily integrates with Rails and hence can be used with Ruby applications which run on Rails. But there are a few steps which have to be followed before integrating cucumber with Rails. Lets walk through it by creating a new rails application.

rails new cucumber_app

Install the required cucumber gems
 
gem install cucumber
gem install cucumber cucumber-rails

Add the following lines to your gemfile. These gems are required only for the test environment. The gems database_cleaner , rspec-rails and webrat are required for cucumber to function properly.
 
group :test do
gem 'database_cleaner'
gem 'cucumber'
gem "rspec-rails", "~> 2.0", :require => false
gem "cucumber-rails", "1.0.6"
gem 'webrat'
end

After modifying the gem file, run bundle update

bundle update

The required cucumber files are generated using the following command. The output below the command shows the folders and files that gets created for the cucumber test framework.

rails generate cucumber:install
 
identical script/cucumber
chmod script/cucumber
exist features/step_definitions
identical features/step_definitions/web_steps.rb
exist features/support
identical features/support/paths.rb
identical features/support/selectors.rb
identical features/support/env.rb
exist lib/tasks
identical lib/tasks/cucumber.rake
 
The Step definitions folder contains ruby files which test the steps which are mentioned in feature file of the cucumber.
 
The paths.rb file is created in the support folder will contain the rules based on which the step definitions will be compared to the steps and matched. In case we come across any steps whose execution fails while running cucumber we would have to update the paths.rb file to resolve the issue.
 
env.rb is only loaded when the application is first started up and it sets up the environment required by Cucumber to execute.
 
rails generate model article title:string content:text
rake db:migrate
rake db:test:clone
rails generate controller articles index
 
The above four commands generate models with the name article and with two fields title and content
and the next two commands migrate the db to production and the last commands creates controller for article and index objects.
 
We have to go the home directory of our rails application and then run Cucumber with the following command.The result would then be shown to the user on how many and which steps succeeded and failed.

=> cucumber
===Capybara===
<ref>[http://net.tutsplus.com/tutorials/ruby/ruby-for-newbies-testing-web-apps-with-capybara-and-cucumber Web-app with Cucumber and Capybara]</ref>

We need a tool that acts out the user stories that are part of the feature that is to be tested with Cucumber. Capybara can be used as that tool. Capybara is an integration testing tool for rack based web based applications. It simulates how a user would interact with a website. It can simulate the actions of a web browser and hence can interact with the application to receive web pages. It can also parse the HTML content and submits forms as the user would. One of the restrictions that Capybara has is that it cannot handle JavaScript. There are other tools like webdriver which can handle JavaScript but it runs a lot slower compared to Capybara.

=Comparison of Unit Test Frameworks : Rspec, Shoulda and Cucumber=

{|border="2" cellpadding="5" cellspacing="0" align="center"
|-
! scope="col" | Rspec
! scope="col" | Shoulda
! scope="col" | Cucumber

|-
|RSpec is based on the Behaviour driven development model provided by Ruby. It has its origins in Test Driven Development and Domain Driven Design.
|Shoulda is based on the Test:Unit which is another Ruby Test Framework. It is based on Test Driven Development.
|Cucumber is a combination of Test Driven Development and Behaviour driven development.
|-
|RSpec provides a Domain Specific Language that can express code functionality and behaviour.
|Shoulda provides macros, helpers and matchers.
|Cucumber allows the test cases to be written in native languages.
|-
|RSpec too allows nested describe structure.
|Shoulda has nested contexts which helps create different environment for different set of tests.
|Cucumber is similar to RSpec and provides nested structures.
|-
|RSpec is expressive when it comes to understanding functionalities since it was designed with the human readability in mind.
|Shoulda has more descriptive names compared to its predecessor Test::Unit but its less expressive.
|Cucumber is more descriptive and allows business stakeholder to read and write test specification.

|}

=Summary=

Cucumber<ref>[http://pragprog.com/book/hwcuc/the-cucumber-book Advantage of Cucumber]</ref> helps facilitate the discovery and use of a ubiquitous language within the team. Cucumber tests interact directly with the developers’ code, but they’re written in a high level language that business stakeholders can understand. When the team uses this language consistently in their conversations, documentation, and code, the friction of translating between everyone’s different little dialects is
gone, and the chances of misunderstandings are greatly reduced. What makes Cucumber stand out from the crowd of other testing tools is that it has been designed specifically to ensure the acceptance tests can easily be read—and written—by anyone on the team.In practice, this means that your documentation, rather than being something that’s written once and then gradually goes out of date, becomes a living thing that reflects the true state of the project

=Reference=
<references/>

CSC/ECE 517 Fall 2012/ch1 1w3 pl

2012-09-14T21:55:42Z

Pvasude: /* Reference */

='''Unit-Testing Frameworks for Ruby: Cucumber'''=

This wiki-page serves as a knowledge source for understanding Unit-Testing Frameworks available for Ruby particularly Cucumber . 

__TOC__

=Introduction=

Unit testing <ref>[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2010/ch1_1f_vn Unit Testing in Ruby]</ref> is a software development process for testing individual units of source code independently for proper operation <ref>[http://en.wikipedia.org/wiki/Unit_testing Unit Testing]</ref>. An unit testing framework helps the process of unit testing by automating the test cases written to ensure the correctness of the system. They are often third-party products that are not offered as part of the suite.Ruby provides a framework in its standard library for setting up, organizing, and running tests called Test::Unit <ref>[http://en.wikibooks.org/wiki/Ruby_Programming/Unit_testing Ruby Unit Testing Framework]</ref>. Other testing frameworks available for ruby are Shoulda, RSpec and Cucumber.

=Cucumber=
Cucumber is one of the latest unit test frameworks to have come for Ruby as part of the RSpec family of tools. Cucumber itself is written in the Ruby programming language and adheres to Behaviour Driven Development(BDD). Behaviour Driven Development is an Agile Development process that comprises aspects of Acceptance Test Driven Planning , Domain Driven Design and Test Driven Development (TDD). Cucumber is designed specifically to ensure that the acceptance tests can easily be read and written by anyone.

==Behaviour Driven Development(BDD)==

Behaviour Driven Development<ref>[http://en.wikipedia.org/wiki/Behavior-driven_development BDD]</ref> preserves the basic iterative (fail-pass) workflow of TDD, but stresses on specifying behaviors that are understandable to people (say from non programming background). In this approach we write tests in a natural language that even a non-programmer can understand.

==Acceptance Test==

Acceptance Test<ref>[http://en.wikipedia.org/wiki/Acceptance_testing Acceptance Test]</ref><ref>[http://pragprog.com/book/hwcuc/the-cucumber-book Cucumber Book]</ref> Drive Planning is a practice that stresses on the importance of identifying the functions and requirements of the software beforehand so that we exactly know when the development phase ends. This practice results in fewer bugs , shorter delivery times and greater customer satisfaction.

===Cucumber Acceptance Test===

Feature: Sign up
Sign up should be quick and friendly. 
Scenario: Successful sign up
New users should get a confirmation email and be greeted personally by the site once signed in.
Given I have chosen to sign up
When I sign up with valid details
Then I should receive a confirmation email
And I should see a personalized greeting message 
Scenario: Duplicate email
Where someone tries to create an account for an email address that already exists.
Given I have chosen to sign up
But I enter an email address that has already registered
Then I should be told that the email is already registered
And I should be offered the option to recover my password

Acceptance tests written in this style are more than just tests; they are executable specifications. As of January 2012, Cucumber was the second most popular testing framework after RSpec for Ruby

==How Cucumber works==

Cucumber is a command-line tool. It reads in specifications from plain-language text files called features, examines them for scenarios to test, and runs the scenarios against the system. The feature files should be written according to specific syntax rules called Gherkin. Along with the features, you give Cucumber a set of step definitions, which map the business-readable language of each step into Ruby code to carry out whatever action is being described by the step. Cucumber takes customer understandable user stories as input and does integration and acceptance tests on the system with those as its input.

===Feature===
A Feature is a high level statement of the what the test case does and there is only one feature per user story. For every feature that is supported by the system , a separate feature file has to be written and included in the features directory. The feature files has .feature file extension.

===Scenario===
A Scenario consists of one or more steps which describe about the various actions performed by the user with respect to this particular feature. There can be one or more scenarios per feature in a user story. A feature usually contains 3 to 8 steps in it. The steps of the scenario always begin with one of the below mentioned key words :

1. Given : Steps that begin with given represent the state of the world before an event.(preconditions) 
2. When : Steps that represent the event. 
3. Then : Steps that represent the expected outcome. 
4. And and But : Steps that extend the previous step. 

===Step and Step Definitions===
When testing with Cucumber , The user stories are all kept in one set of files called Steps.The Steps are compared with Step Definitions which are files written in ruby which gives the rules based on which the steps are executed. Step definitions are analogous to method definitions and steps of scenarios are analogous to method calls. Cucumber uses regular expressions to match the English phrases in the steps of scenarios to step definitions.

When the cucumber test framework is run , The steps present in the feature file can be classified as follows based on the result of regex matching with the step definitions.<ref>[https://github.com/cucumber/cucumber/wiki/Step-Definitions Step Definitions in Ruby]</ref>

====Successful steps====
When Cucumber finds a matching Step Definition it will execute it. If the block in the step definition doesn’t raise an Exception, the step is marked as successful (green). What you return from a Step Definition has no significance what so ever.

====Undefined steps====
When Cucumber can’t find a matching Step Definition the step gets marked as yellow, and all subsequent steps in the scenario are skipped. If you use --strict this will cause Cucumber to exit with 1.

====Pending steps====
When a Step Definition’s Proc invokes the #pending method, the step is marked as yellow (as with undefined ones), reminding you that you have work to do. If you use --strict this will cause Cucumber to exit with 1.

====Failed steps====
When a Step Definition’s Proc is executed and raises an error, the step is marked as red. Returning nil or false will not cause a step definition to fail.

Cucumber tries to run the steps based on the definitions and thus colors steps based on the execution of the steps. The colors for the steps assigned are as follows : 
 
1. Green : for passing. 
2. Yellow : for not yet implemented. 
3. Red : for failing. 
4. Blue : Once a step fails all the successive steps are marked in blue. 

[[File:Cucumber.JPG|500px|thumb|center|Cucumber Testing Stack]]

==Advantages of Cucumber==
*Specifications can be written in more than forty different spoken languages.
*Cucumber helps reduce the gap between technical and non-technical members of a software team.
*Cucumber tests can be easily read and written by business stakeholders.
*Writing Cucumber tests are quick, easy, efficient and understandable.

=Cucumber Installation=

To install cucumber<ref>[http://cuke4ninja.com/sec_ruby_install_cucumber.html Installing Cucumber]</ref> we should make sure that the Environment path is set to “..../Ruby/bin”. Then open the command prompt and run

gem install cucumber

Once cucumber gem is installed then we would be able to check whether it is installed by issuing the following command:

cucumber --version

this should give a version number like “1.2.1”

Cucumber uses Rspec for assertions and hence we need Rspec installed to use Cucumber. Use the following command to install rspec

gem install rspec

=Testing a Sample Ruby Application using Cucumber=
Lets walk through a example for creating a Hello World Ruby application and testing it using cucumber<ref>[http://pragprog.com/book/hwcuc/the-cucumber-book Sample Cucumber Application]</ref>.

Step 1 : Create a new directory

mkdir HelloCucumber

Step 2 : Install Cucumber and Rspec

gem install cucumber
gem instal rspec

Step 3 : Create a directory features and create a file basic.feature in the features directory

mkdir features

Content of features/basic.feature

Feature: Hello World Feature 
Scenario: Hello World Scenario
Given The Action is Hello
When The Subject is World
Then The Greeting is Hello, World

Step 4: Create step_definitions directory inside features directory. Create basic_step.rb file inside step_definitions.

mkdir features/step_definitions

Content of features/step_definitions/basic_step.rb

require 'rspec/expectations' 
Given /The Action is ([A-z]*)/ do |action|
@action = action
end 
When /The Subject is ([A-z]*)/ do |subject|
@subject = subject
end 
Then /The Greeting is (.*)/ do |greeting|
greeting.should == "#{@action}, #{@subject}"
end
Cucumber uses regular expression after the keywords Given, When and Then to map lines in a feature file to step definitions.

Step 5: Running cucumber command you will see the following output

Feature: Hello World Feature 
Scenario: Hello World Scenario # features\basic.feature:3
Given The Action is Hello # features/step_definitions/basic_steps.rb:3
When The Subject is World # features/step_definitions/basic_steps.rb:7
Then The Greeting is Hello, World # features/step_definitions/basic_steps.rb:11 

1 scenario (1 passed)
3 steps (3 passed)
0m0.016s
Step 6 : Modify the basic.features file to include 2 scenario

Step 6 : Modify the basic.features file to include 2 scenarios

Feature: Hello World Feature 
Scenario: Hello World Scenario
Given The Action is Hello
When The Subject is World
Then The Greeting is Hello, World 
Scenario: Bye World Scenario
Given The Action is Bye
When The Subject is World
Then The Greeting is Hello, World

Step 7 : Running the cucumber command you will see the following output

Scenario: Hello World Scenario # features\basic.feature:3
Given The Action is Hello # features/step_definitions/basic_steps.rb:3
When The Subject is World # features/step_definitions/basic_steps.rb:7
Then The Greeting is Hello, World # features/step_definitions/basic_steps.rb:11 
Scenario: Bye World Scenario # features\basic.feature:8
Given The Action is Bye # features/step_definitions/basic_steps.rb:3
When The Subject is World # features/step_definitions/basic_steps.rb:7
Then The Greeting is Hello, World # features/step_definitions/basic_steps.rb:11
expected: "Bye, World"
got: "Hello, World" (using ==) (RSpec::Expectations::ExpectationNotMetError)
./features/step_definitions/basic_steps.rb:12:in `/The Greeting is (.*)/'
features\basic.feature:11:in `Then The Greeting is Hello, World' 
Failing Scenarios:
cucumber features\basic.feature:8 # Scenario: Bye World Scenario 
2 scenarios (1 failed, 1 passed)
6 steps (1 failed, 5 passed)
0m0.033s

The Bye Scenario fails since the expected output is “Hello, World” but the received output is “Bye,World”.

=Testing a Sample Rails Application using Cucumber=

Cucumber<ref>[http://railscasts.com/episodes/155-beginning-with-cucumber Sample Cucumber Application on Rails]</ref> easily integrates with Rails and hence can be used with Ruby applications which run on Rails. But there are a few steps which have to be followed before integrating cucumber with Rails. Lets walk through it by creating a new rails application.

rails new cucumber_app

Install the required cucumber gems
 
gem install cucumber
gem install cucumber cucumber-rails

Add the following lines to your gemfile. These gems are required only for the test environment. The gems database_cleaner , rspec-rails and webrat are required for cucumber to function properly.
 
group :test do
gem 'database_cleaner'
gem 'cucumber'
gem "rspec-rails", "~> 2.0", :require => false
gem "cucumber-rails", "1.0.6"
gem 'webrat'
end

After modifying the gem file, run bundle update

bundle update

The required cucumber files are generated using the following command. The output below the command shows the folders and files that gets created for the cucumber test framework.

rails generate cucumber:install
 
identical script/cucumber
chmod script/cucumber
exist features/step_definitions
identical features/step_definitions/web_steps.rb
exist features/support
identical features/support/paths.rb
identical features/support/selectors.rb
identical features/support/env.rb
exist lib/tasks
identical lib/tasks/cucumber.rake
 
The Step definitions folder contains ruby files which test the steps which are mentioned in feature file of the cucumber.
 
The paths.rb file is created in the support folder will contain the rules based on which the step definitions will be compared to the steps and matched. In case we come across any steps whose execution fails while running cucumber we would have to update the paths.rb file to resolve the issue.
 
env.rb is only loaded when the application is first started up and it sets up the environment required by Cucumber to execute.
 
rails generate model article title:string content:text
rake db:migrate
rake db:test:clone
rails generate controller articles index
 
The above four commands generate models with the name article and with two fields title and content
and the next two commands migrate the db to production and the last commands creates controller for article and index objects.
 
We have to go the home directory of our rails application and then run Cucumber with the following command.The result would then be shown to the user on how many and which steps succeeded and failed.

=> cucumber
===Capybara===
<ref>[http://net.tutsplus.com/tutorials/ruby/ruby-for-newbies-testing-web-apps-with-capybara-and-cucumber Web-app with Cucumber and Capybara]</ref>

We need a tool that acts out the user stories that are part of the feature that is to be tested with Cucumber. Capybara can be used as that tool. Capybara is an integration testing tool for rack based web based applications. It simulates how a user would interact with a website. It can simulate the actions of a web browser and hence can interact with the application to receive web pages. It can also parse the HTML content and submits forms as the user would. One of the restrictions that Capybara has is that it cannot handle JavaScript. There are other tools like webdriver which can handle JavaScript but it runs a lot slower compared to Capybara.

=Comparison of Unit Test Frameworks : Rspec, Shoulda and Cucumber=

{|border="2" cellpadding="5" cellspacing="0" align="center"
|-
! scope="col" | Rspec
! scope="col" | Shoulda
! scope="col" | Cucumber

|-
|RSpec is based on the Behaviour driven development model provided by Ruby. It has its origins in Test Driven Development and Domain Driven Design.
|Shoulda is based on the Test:Unit which is another Ruby Test Framework. It is based on Test Driven Development.
|Cucumber is a combination of Test Driven Development and Behaviour driven development.
|-
|RSpec provides a Domain Specific Language that can express code functionality and behaviour.
|Shoulda provides macros, helpers and matchers.
|Cucumber allows the test cases to be written in native languages.
|-
|RSpec too allows nested describe structure.
|Shoulda has nested contexts which helps create different environment for different set of tests.
|Cucumber is similar to RSpec and provides nested structures.
|-
|RSpec is expressive when it comes to understanding functionalities since it was designed with the human readability in mind.
|Shoulda has more descriptive names compared to its predecessor Test::Unit but its less expressive.
|Cucumber is more descriptive and allows business stakeholder to read and write test specification.

|}

=Summary=

Cucumber helps facilitate the discovery and use of a ubiquitous language within the team. Cucumber tests interact directly with the developers’ code, but they’re written in a high level language that business stakeholders can understand. When the team uses this language consistently in their conversations, documentation, and code, the friction of translating between everyone’s different little dialects is
gone, and the chances of misunderstandings are greatly reduced. What makes Cucumber stand out from the crowd of other testing tools is that it has been designed specifically to ensure the acceptance tests can easily be read—and written—by anyone on the team.In practice, this means that your documentation, rather than being something that’s written once and then gradually goes out of date, becomes a living thing that reflects the true state of the project

=Reference=
<references/>

CSC/ECE 517 Fall 2012/ch1 1w3 pl

2012-09-14T21:46:11Z

Pvasude: /* Introduction */

='''Unit-Testing Frameworks for Ruby: Cucumber'''=

This wiki-page serves as a knowledge source for understanding Unit-Testing Frameworks available for Ruby particularly Cucumber . 

__TOC__

=Introduction=

Unit testing <ref>[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2010/ch1_1f_vn Unit Testing in Ruby]</ref> is a software development process for testing individual units of source code independently for proper operation <ref>[http://en.wikipedia.org/wiki/Unit_testing Unit Testing]</ref>. An unit testing framework helps the process of unit testing by automating the test cases written to ensure the correctness of the system. They are often third-party products that are not offered as part of the suite.Ruby provides a framework in its standard library for setting up, organizing, and running tests called Test::Unit <ref>[http://en.wikibooks.org/wiki/Ruby_Programming/Unit_testing Ruby Unit Testing Framework]</ref>. Other testing frameworks available for ruby are Shoulda, RSpec and Cucumber.

=Cucumber=
Cucumber is one of the latest unit test frameworks to have come for Ruby as part of the RSpec family of tools. Cucumber itself is written in the Ruby programming language and adheres to Behaviour Driven Development(BDD). Behaviour Driven Development is an Agile Development process that comprises aspects of Acceptance Test Driven Planning , Domain Driven Design and Test Driven Development (TDD). Cucumber is designed specifically to ensure that the acceptance tests can easily be read and written by anyone.

==Behaviour Driven Development(BDD)==

Behaviour Driven Development<ref>[http://en.wikipedia.org/wiki/Behavior-driven_development BDD]</ref> preserves the basic iterative (fail-pass) workflow of TDD, but stresses on specifying behaviors that are understandable to people (say from non programming background). In this approach we write tests in a natural language that even a non-programmer can understand.

==Acceptance Test==

Acceptance Test<ref>[http://en.wikipedia.org/wiki/Acceptance_testing Acceptance Test]</ref><ref>[http://pragprog.com/book/hwcuc/the-cucumber-book Cucumber Book]</ref> Drive Planning is a practice that stresses on the importance of identifying the functions and requirements of the software beforehand so that we exactly know when the development phase ends. This practice results in fewer bugs , shorter delivery times and greater customer satisfaction.

===Cucumber Acceptance Test===

Feature: Sign up
Sign up should be quick and friendly. 
Scenario: Successful sign up
New users should get a confirmation email and be greeted personally by the site once signed in.
Given I have chosen to sign up
When I sign up with valid details
Then I should receive a confirmation email
And I should see a personalized greeting message 
Scenario: Duplicate email
Where someone tries to create an account for an email address that already exists.
Given I have chosen to sign up
But I enter an email address that has already registered
Then I should be told that the email is already registered
And I should be offered the option to recover my password

Acceptance tests written in this style are more than just tests; they are executable specifications. As of January 2012, Cucumber was the second most popular testing framework after RSpec for Ruby

==How Cucumber works==

Cucumber is a command-line tool. It reads in specifications from plain-language text files called features, examines them for scenarios to test, and runs the scenarios against the system. The feature files should be written according to specific syntax rules called Gherkin. Along with the features, you give Cucumber a set of step definitions, which map the business-readable language of each step into Ruby code to carry out whatever action is being described by the step. Cucumber takes customer understandable user stories as input and does integration and acceptance tests on the system with those as its input.

===Feature===
A Feature is a high level statement of the what the test case does and there is only one feature per user story. For every feature that is supported by the system , a separate feature file has to be written and included in the features directory. The feature files has .feature file extension.

===Scenario===
A Scenario consists of one or more steps which describe about the various actions performed by the user with respect to this particular feature. There can be one or more scenarios per feature in a user story. A feature usually contains 3 to 8 steps in it. The steps of the scenario always begin with one of the below mentioned key words :

1. Given : Steps that begin with given represent the state of the world before an event.(preconditions) 
2. When : Steps that represent the event. 
3. Then : Steps that represent the expected outcome. 
4. And and But : Steps that extend the previous step. 

===Step and Step Definitions===
When testing with Cucumber , The user stories are all kept in one set of files called Steps.The Steps are compared with Step Definitions which are files written in ruby which gives the rules based on which the steps are executed. Step definitions are analogous to method definitions and steps of scenarios are analogous to method calls. Cucumber uses regular expressions to match the English phrases in the steps of scenarios to step definitions.

When the cucumber test framework is run , The steps present in the feature file can be classified as follows based on the result of regex matching with the step definitions.<ref>[https://github.com/cucumber/cucumber/wiki/Step-Definitions Step Definitions in Ruby]</ref>

====Successful steps====
When Cucumber finds a matching Step Definition it will execute it. If the block in the step definition doesn’t raise an Exception, the step is marked as successful (green). What you return from a Step Definition has no significance what so ever.

====Undefined steps====
When Cucumber can’t find a matching Step Definition the step gets marked as yellow, and all subsequent steps in the scenario are skipped. If you use --strict this will cause Cucumber to exit with 1.

====Pending steps====
When a Step Definition’s Proc invokes the #pending method, the step is marked as yellow (as with undefined ones), reminding you that you have work to do. If you use --strict this will cause Cucumber to exit with 1.

====Failed steps====
When a Step Definition’s Proc is executed and raises an error, the step is marked as red. Returning nil or false will not cause a step definition to fail.

Cucumber tries to run the steps based on the definitions and thus colors steps based on the execution of the steps. The colors for the steps assigned are as follows : 
 
1. Green : for passing. 
2. Yellow : for not yet implemented. 
3. Red : for failing. 
4. Blue : Once a step fails all the successive steps are marked in blue. 

[[File:Cucumber.JPG|500px|thumb|center|Cucumber Testing Stack]]

==Advantages of Cucumber==
*Specifications can be written in more than forty different spoken languages.
*Cucumber helps reduce the gap between technical and non-technical members of a software team.
*Cucumber tests can be easily read and written by business stakeholders.
*Writing Cucumber tests are quick, easy, efficient and understandable.

=Cucumber Installation=

To install cucumber<ref>[http://cuke4ninja.com/sec_ruby_install_cucumber.html Installing Cucumber]</ref> we should make sure that the Environment path is set to “..../Ruby/bin”. Then open the command prompt and run

gem install cucumber

Once cucumber gem is installed then we would be able to check whether it is installed by issuing the following command:

cucumber --version

this should give a version number like “1.2.1”

Cucumber uses Rspec for assertions and hence we need Rspec installed to use Cucumber. Use the following command to install rspec

gem install rspec

=Testing a Sample Ruby Application using Cucumber=
Lets walk through a example for creating a Hello World Ruby application and testing it using cucumber<ref>[http://pragprog.com/book/hwcuc/the-cucumber-book Sample Cucumber Application]</ref>.

Step 1 : Create a new directory

mkdir HelloCucumber

Step 2 : Install Cucumber and Rspec

gem install cucumber
gem instal rspec

Step 3 : Create a directory features and create a file basic.feature in the features directory

mkdir features

Content of features/basic.feature

Feature: Hello World Feature 
Scenario: Hello World Scenario
Given The Action is Hello
When The Subject is World
Then The Greeting is Hello, World

Step 4: Create step_definitions directory inside features directory. Create basic_step.rb file inside step_definitions.

mkdir features/step_definitions

Content of features/step_definitions/basic_step.rb

require 'rspec/expectations' 
Given /The Action is ([A-z]*)/ do |action|
@action = action
end 
When /The Subject is ([A-z]*)/ do |subject|
@subject = subject
end 
Then /The Greeting is (.*)/ do |greeting|
greeting.should == "#{@action}, #{@subject}"
end
Cucumber uses regular expression after the keywords Given, When and Then to map lines in a feature file to step definitions.

Step 5: Running cucumber command you will see the following output

Feature: Hello World Feature 
Scenario: Hello World Scenario # features\basic.feature:3
Given The Action is Hello # features/step_definitions/basic_steps.rb:3
When The Subject is World # features/step_definitions/basic_steps.rb:7
Then The Greeting is Hello, World # features/step_definitions/basic_steps.rb:11 

1 scenario (1 passed)
3 steps (3 passed)
0m0.016s
Step 6 : Modify the basic.features file to include 2 scenario

Step 6 : Modify the basic.features file to include 2 scenarios

Feature: Hello World Feature 
Scenario: Hello World Scenario
Given The Action is Hello
When The Subject is World
Then The Greeting is Hello, World 
Scenario: Bye World Scenario
Given The Action is Bye
When The Subject is World
Then The Greeting is Hello, World

Step 7 : Running the cucumber command you will see the following output

Scenario: Hello World Scenario # features\basic.feature:3
Given The Action is Hello # features/step_definitions/basic_steps.rb:3
When The Subject is World # features/step_definitions/basic_steps.rb:7
Then The Greeting is Hello, World # features/step_definitions/basic_steps.rb:11 
Scenario: Bye World Scenario # features\basic.feature:8
Given The Action is Bye # features/step_definitions/basic_steps.rb:3
When The Subject is World # features/step_definitions/basic_steps.rb:7
Then The Greeting is Hello, World # features/step_definitions/basic_steps.rb:11
expected: "Bye, World"
got: "Hello, World" (using ==) (RSpec::Expectations::ExpectationNotMetError)
./features/step_definitions/basic_steps.rb:12:in `/The Greeting is (.*)/'
features\basic.feature:11:in `Then The Greeting is Hello, World' 
Failing Scenarios:
cucumber features\basic.feature:8 # Scenario: Bye World Scenario 
2 scenarios (1 failed, 1 passed)
6 steps (1 failed, 5 passed)
0m0.033s

The Bye Scenario fails since the expected output is “Hello, World” but the received output is “Bye,World”.

=Testing a Sample Rails Application using Cucumber=

Cucumber<ref>[http://railscasts.com/episodes/155-beginning-with-cucumber Sample Cucumber Application on Rails]</ref> easily integrates with Rails and hence can be used with Ruby applications which run on Rails. But there are a few steps which have to be followed before integrating cucumber with Rails. Lets walk through it by creating a new rails application.

rails new cucumber_app

Install the required cucumber gems
 
gem install cucumber
gem install cucumber cucumber-rails

Add the following lines to your gemfile. These gems are required only for the test environment. The gems database_cleaner , rspec-rails and webrat are required for cucumber to function properly.
 
group :test do
gem 'database_cleaner'
gem 'cucumber'
gem "rspec-rails", "~> 2.0", :require => false
gem "cucumber-rails", "1.0.6"
gem 'webrat'
end

After modifying the gem file, run bundle update

bundle update

The required cucumber files are generated using the following command. The output below the command shows the folders and files that gets created for the cucumber test framework.

rails generate cucumber:install
 
identical script/cucumber
chmod script/cucumber
exist features/step_definitions
identical features/step_definitions/web_steps.rb
exist features/support
identical features/support/paths.rb
identical features/support/selectors.rb
identical features/support/env.rb
exist lib/tasks
identical lib/tasks/cucumber.rake
 
The Step definitions folder contains ruby files which test the steps which are mentioned in feature file of the cucumber.
 
The paths.rb file is created in the support folder will contain the rules based on which the step definitions will be compared to the steps and matched. In case we come across any steps whose execution fails while running cucumber we would have to update the paths.rb file to resolve the issue.
 
env.rb is only loaded when the application is first started up and it sets up the environment required by Cucumber to execute.
 
rails generate model article title:string content:text
rake db:migrate
rake db:test:clone
rails generate controller articles index
 
The above four commands generate models with the name article and with two fields title and content
and the next two commands migrate the db to production and the last commands creates controller for article and index objects.
 
We have to go the home directory of our rails application and then run Cucumber with the following command.The result would then be shown to the user on how many and which steps succeeded and failed.

=> cucumber
===Capybara===
<ref>[http://net.tutsplus.com/tutorials/ruby/ruby-for-newbies-testing-web-apps-with-capybara-and-cucumber Web-app with Cucumber and Capybara]</ref>

We need a tool that acts out the user stories that are part of the feature that is to be tested with Cucumber. Capybara can be used as that tool. Capybara is an integration testing tool for rack based web based applications. It simulates how a user would interact with a website. It can simulate the actions of a web browser and hence can interact with the application to receive web pages. It can also parse the HTML content and submits forms as the user would. One of the restrictions that Capybara has is that it cannot handle JavaScript. There are other tools like webdriver which can handle JavaScript but it runs a lot slower compared to Capybara.

=Comparison of Unit Test Frameworks : Rspec, Shoulda and Cucumber=

{|border="2" cellpadding="5" cellspacing="0" align="center"
|-
! scope="col" | Rspec
! scope="col" | Shoulda
! scope="col" | Cucumber

|-
|RSpec is based on the Behaviour driven development model provided by Ruby. It has its origins in Test Driven Development and Domain Driven Design.
|Shoulda is based on the Test:Unit which is another Ruby Test Framework. It is based on Test Driven Development.
|Cucumber is a combination of Test Driven Development and Behaviour driven development.
|-
|RSpec provides a Domain Specific Language that can express code functionality and behaviour.
|Shoulda provides macros, helpers and matchers.
|Cucumber allows the test cases to be written in native languages.
|-
|RSpec too allows nested describe structure.
|Shoulda has nested contexts which helps create different environment for different set of tests.
|Cucumber is similar to RSpec and provides nested structures.
|-
|RSpec is expressive when it comes to understanding functionalities since it was designed with the human readability in mind.
|Shoulda has more descriptive names compared to its predecessor Test::Unit but its less expressive.
|Cucumber is more descriptive and allows business stakeholder to read and write test specification.

|}

=Reference=
<references/>

CSC/ECE 517 Fall 2012/ch1 1w3 pl

2012-09-14T21:44:54Z

Pvasude: /* Testing a Sample Rails Application using Cucumber */

='''Unit-Testing Frameworks for Ruby: Cucumber'''=

This wiki-page serves as a knowledge source for understanding Unit-Testing Frameworks available for Ruby particularly Cucumber . 

__TOC__

=Introduction=

Unit testing is a software development process for testing individual units of source code independently for proper operation <ref>[http://en.wikipedia.org/wiki/Unit_testing Unit Testing]</ref>. An unit testing framework helps the process of unit testing by automating the test cases written to ensure the correctness of the system. They are often third-party products that are not offered as part of the suite.Ruby provides a framework in its standard library for setting up, organizing, and running tests called Test::Unit <ref>[http://en.wikibooks.org/wiki/Ruby_Programming/Unit_testing Ruby Unit Testing Framework]</ref>. Other testing frameworks available for ruby are Shoulda, RSpec and Cucumber.

=Cucumber=
Cucumber is one of the latest unit test frameworks to have come for Ruby as part of the RSpec family of tools. Cucumber itself is written in the Ruby programming language and adheres to Behaviour Driven Development(BDD). Behaviour Driven Development is an Agile Development process that comprises aspects of Acceptance Test Driven Planning , Domain Driven Design and Test Driven Development (TDD). Cucumber is designed specifically to ensure that the acceptance tests can easily be read and written by anyone.

==Behaviour Driven Development(BDD)==

Behaviour Driven Development<ref>[http://en.wikipedia.org/wiki/Behavior-driven_development BDD]</ref> preserves the basic iterative (fail-pass) workflow of TDD, but stresses on specifying behaviors that are understandable to people (say from non programming background). In this approach we write tests in a natural language that even a non-programmer can understand.

==Acceptance Test==

Acceptance Test<ref>[http://en.wikipedia.org/wiki/Acceptance_testing Acceptance Test]</ref><ref>[http://pragprog.com/book/hwcuc/the-cucumber-book Cucumber Book]</ref> Drive Planning is a practice that stresses on the importance of identifying the functions and requirements of the software beforehand so that we exactly know when the development phase ends. This practice results in fewer bugs , shorter delivery times and greater customer satisfaction.

===Cucumber Acceptance Test===

Feature: Sign up
Sign up should be quick and friendly. 
Scenario: Successful sign up
New users should get a confirmation email and be greeted personally by the site once signed in.
Given I have chosen to sign up
When I sign up with valid details
Then I should receive a confirmation email
And I should see a personalized greeting message 
Scenario: Duplicate email
Where someone tries to create an account for an email address that already exists.
Given I have chosen to sign up
But I enter an email address that has already registered
Then I should be told that the email is already registered
And I should be offered the option to recover my password

Acceptance tests written in this style are more than just tests; they are executable specifications. As of January 2012, Cucumber was the second most popular testing framework after RSpec for Ruby

==How Cucumber works==

Cucumber is a command-line tool. It reads in specifications from plain-language text files called features, examines them for scenarios to test, and runs the scenarios against the system. The feature files should be written according to specific syntax rules called Gherkin. Along with the features, you give Cucumber a set of step definitions, which map the business-readable language of each step into Ruby code to carry out whatever action is being described by the step. Cucumber takes customer understandable user stories as input and does integration and acceptance tests on the system with those as its input.

===Feature===
A Feature is a high level statement of the what the test case does and there is only one feature per user story. For every feature that is supported by the system , a separate feature file has to be written and included in the features directory. The feature files has .feature file extension.

===Scenario===
A Scenario consists of one or more steps which describe about the various actions performed by the user with respect to this particular feature. There can be one or more scenarios per feature in a user story. A feature usually contains 3 to 8 steps in it. The steps of the scenario always begin with one of the below mentioned key words :

1. Given : Steps that begin with given represent the state of the world before an event.(preconditions) 
2. When : Steps that represent the event. 
3. Then : Steps that represent the expected outcome. 
4. And and But : Steps that extend the previous step. 

===Step and Step Definitions===
When testing with Cucumber , The user stories are all kept in one set of files called Steps.The Steps are compared with Step Definitions which are files written in ruby which gives the rules based on which the steps are executed. Step definitions are analogous to method definitions and steps of scenarios are analogous to method calls. Cucumber uses regular expressions to match the English phrases in the steps of scenarios to step definitions.

When the cucumber test framework is run , The steps present in the feature file can be classified as follows based on the result of regex matching with the step definitions.<ref>[https://github.com/cucumber/cucumber/wiki/Step-Definitions Step Definitions in Ruby]</ref>

====Successful steps====
When Cucumber finds a matching Step Definition it will execute it. If the block in the step definition doesn’t raise an Exception, the step is marked as successful (green). What you return from a Step Definition has no significance what so ever.

====Undefined steps====
When Cucumber can’t find a matching Step Definition the step gets marked as yellow, and all subsequent steps in the scenario are skipped. If you use --strict this will cause Cucumber to exit with 1.

====Pending steps====
When a Step Definition’s Proc invokes the #pending method, the step is marked as yellow (as with undefined ones), reminding you that you have work to do. If you use --strict this will cause Cucumber to exit with 1.

====Failed steps====
When a Step Definition’s Proc is executed and raises an error, the step is marked as red. Returning nil or false will not cause a step definition to fail.

Cucumber tries to run the steps based on the definitions and thus colors steps based on the execution of the steps. The colors for the steps assigned are as follows : 
 
1. Green : for passing. 
2. Yellow : for not yet implemented. 
3. Red : for failing. 
4. Blue : Once a step fails all the successive steps are marked in blue. 

[[File:Cucumber.JPG|500px|thumb|center|Cucumber Testing Stack]]

==Advantages of Cucumber==
*Specifications can be written in more than forty different spoken languages.
*Cucumber helps reduce the gap between technical and non-technical members of a software team.
*Cucumber tests can be easily read and written by business stakeholders.
*Writing Cucumber tests are quick, easy, efficient and understandable.

=Cucumber Installation=

To install cucumber<ref>[http://cuke4ninja.com/sec_ruby_install_cucumber.html Installing Cucumber]</ref> we should make sure that the Environment path is set to “..../Ruby/bin”. Then open the command prompt and run

gem install cucumber

Once cucumber gem is installed then we would be able to check whether it is installed by issuing the following command:

cucumber --version

this should give a version number like “1.2.1”

Cucumber uses Rspec for assertions and hence we need Rspec installed to use Cucumber. Use the following command to install rspec

gem install rspec

=Testing a Sample Ruby Application using Cucumber=
Lets walk through a example for creating a Hello World Ruby application and testing it using cucumber<ref>[http://pragprog.com/book/hwcuc/the-cucumber-book Sample Cucumber Application]</ref>.

Step 1 : Create a new directory

mkdir HelloCucumber

Step 2 : Install Cucumber and Rspec

gem install cucumber
gem instal rspec

Step 3 : Create a directory features and create a file basic.feature in the features directory

mkdir features

Content of features/basic.feature

Feature: Hello World Feature 
Scenario: Hello World Scenario
Given The Action is Hello
When The Subject is World
Then The Greeting is Hello, World

Step 4: Create step_definitions directory inside features directory. Create basic_step.rb file inside step_definitions.

mkdir features/step_definitions

Content of features/step_definitions/basic_step.rb

require 'rspec/expectations' 
Given /The Action is ([A-z]*)/ do |action|
@action = action
end 
When /The Subject is ([A-z]*)/ do |subject|
@subject = subject
end 
Then /The Greeting is (.*)/ do |greeting|
greeting.should == "#{@action}, #{@subject}"
end
Cucumber uses regular expression after the keywords Given, When and Then to map lines in a feature file to step definitions.

Step 5: Running cucumber command you will see the following output

Feature: Hello World Feature 
Scenario: Hello World Scenario # features\basic.feature:3
Given The Action is Hello # features/step_definitions/basic_steps.rb:3
When The Subject is World # features/step_definitions/basic_steps.rb:7
Then The Greeting is Hello, World # features/step_definitions/basic_steps.rb:11 

1 scenario (1 passed)
3 steps (3 passed)
0m0.016s
Step 6 : Modify the basic.features file to include 2 scenario

Step 6 : Modify the basic.features file to include 2 scenarios

Feature: Hello World Feature 
Scenario: Hello World Scenario
Given The Action is Hello
When The Subject is World
Then The Greeting is Hello, World 
Scenario: Bye World Scenario
Given The Action is Bye
When The Subject is World
Then The Greeting is Hello, World

Step 7 : Running the cucumber command you will see the following output

Scenario: Hello World Scenario # features\basic.feature:3
Given The Action is Hello # features/step_definitions/basic_steps.rb:3
When The Subject is World # features/step_definitions/basic_steps.rb:7
Then The Greeting is Hello, World # features/step_definitions/basic_steps.rb:11 
Scenario: Bye World Scenario # features\basic.feature:8
Given The Action is Bye # features/step_definitions/basic_steps.rb:3
When The Subject is World # features/step_definitions/basic_steps.rb:7
Then The Greeting is Hello, World # features/step_definitions/basic_steps.rb:11
expected: "Bye, World"
got: "Hello, World" (using ==) (RSpec::Expectations::ExpectationNotMetError)
./features/step_definitions/basic_steps.rb:12:in `/The Greeting is (.*)/'
features\basic.feature:11:in `Then The Greeting is Hello, World' 
Failing Scenarios:
cucumber features\basic.feature:8 # Scenario: Bye World Scenario 
2 scenarios (1 failed, 1 passed)
6 steps (1 failed, 5 passed)
0m0.033s

The Bye Scenario fails since the expected output is “Hello, World” but the received output is “Bye,World”.

=Testing a Sample Rails Application using Cucumber=

Cucumber<ref>[http://railscasts.com/episodes/155-beginning-with-cucumber Sample Cucumber Application on Rails]</ref> easily integrates with Rails and hence can be used with Ruby applications which run on Rails. But there are a few steps which have to be followed before integrating cucumber with Rails. Lets walk through it by creating a new rails application.

rails new cucumber_app

Install the required cucumber gems
 
gem install cucumber
gem install cucumber cucumber-rails

Add the following lines to your gemfile. These gems are required only for the test environment. The gems database_cleaner , rspec-rails and webrat are required for cucumber to function properly.
 
group :test do
gem 'database_cleaner'
gem 'cucumber'
gem "rspec-rails", "~> 2.0", :require => false
gem "cucumber-rails", "1.0.6"
gem 'webrat'
end

After modifying the gem file, run bundle update

bundle update

The required cucumber files are generated using the following command. The output below the command shows the folders and files that gets created for the cucumber test framework.

rails generate cucumber:install
 
identical script/cucumber
chmod script/cucumber
exist features/step_definitions
identical features/step_definitions/web_steps.rb
exist features/support
identical features/support/paths.rb
identical features/support/selectors.rb
identical features/support/env.rb
exist lib/tasks
identical lib/tasks/cucumber.rake
 
The Step definitions folder contains ruby files which test the steps which are mentioned in feature file of the cucumber.
 
The paths.rb file is created in the support folder will contain the rules based on which the step definitions will be compared to the steps and matched. In case we come across any steps whose execution fails while running cucumber we would have to update the paths.rb file to resolve the issue.
 
env.rb is only loaded when the application is first started up and it sets up the environment required by Cucumber to execute.
 
rails generate model article title:string content:text
rake db:migrate
rake db:test:clone
rails generate controller articles index
 
The above four commands generate models with the name article and with two fields title and content
and the next two commands migrate the db to production and the last commands creates controller for article and index objects.
 
We have to go the home directory of our rails application and then run Cucumber with the following command.The result would then be shown to the user on how many and which steps succeeded and failed.

=> cucumber
===Capybara===
<ref>[http://net.tutsplus.com/tutorials/ruby/ruby-for-newbies-testing-web-apps-with-capybara-and-cucumber Web-app with Cucumber and Capybara]</ref>

We need a tool that acts out the user stories that are part of the feature that is to be tested with Cucumber. Capybara can be used as that tool. Capybara is an integration testing tool for rack based web based applications. It simulates how a user would interact with a website. It can simulate the actions of a web browser and hence can interact with the application to receive web pages. It can also parse the HTML content and submits forms as the user would. One of the restrictions that Capybara has is that it cannot handle JavaScript. There are other tools like webdriver which can handle JavaScript but it runs a lot slower compared to Capybara.

=Comparison of Unit Test Frameworks : Rspec, Shoulda and Cucumber=

{|border="2" cellpadding="5" cellspacing="0" align="center"
|-
! scope="col" | Rspec
! scope="col" | Shoulda
! scope="col" | Cucumber

|-
|RSpec is based on the Behaviour driven development model provided by Ruby. It has its origins in Test Driven Development and Domain Driven Design.
|Shoulda is based on the Test:Unit which is another Ruby Test Framework. It is based on Test Driven Development.
|Cucumber is a combination of Test Driven Development and Behaviour driven development.
|-
|RSpec provides a Domain Specific Language that can express code functionality and behaviour.
|Shoulda provides macros, helpers and matchers.
|Cucumber allows the test cases to be written in native languages.
|-
|RSpec too allows nested describe structure.
|Shoulda has nested contexts which helps create different environment for different set of tests.
|Cucumber is similar to RSpec and provides nested structures.
|-
|RSpec is expressive when it comes to understanding functionalities since it was designed with the human readability in mind.
|Shoulda has more descriptive names compared to its predecessor Test::Unit but its less expressive.
|Cucumber is more descriptive and allows business stakeholder to read and write test specification.

|}

=Reference=
<references/>

CSC/ECE 517 Fall 2012/ch1 1w3 pl

2012-09-14T21:44:02Z

Pvasude: /* Comparison of Unit Test Frameworks : Rspec, Shoulda and Cucumber */

='''Unit-Testing Frameworks for Ruby: Cucumber'''=

This wiki-page serves as a knowledge source for understanding Unit-Testing Frameworks available for Ruby particularly Cucumber . 

__TOC__

=Introduction=

Unit testing is a software development process for testing individual units of source code independently for proper operation <ref>[http://en.wikipedia.org/wiki/Unit_testing Unit Testing]</ref>. An unit testing framework helps the process of unit testing by automating the test cases written to ensure the correctness of the system. They are often third-party products that are not offered as part of the suite.Ruby provides a framework in its standard library for setting up, organizing, and running tests called Test::Unit <ref>[http://en.wikibooks.org/wiki/Ruby_Programming/Unit_testing Ruby Unit Testing Framework]</ref>. Other testing frameworks available for ruby are Shoulda, RSpec and Cucumber.

=Cucumber=
Cucumber is one of the latest unit test frameworks to have come for Ruby as part of the RSpec family of tools. Cucumber itself is written in the Ruby programming language and adheres to Behaviour Driven Development(BDD). Behaviour Driven Development is an Agile Development process that comprises aspects of Acceptance Test Driven Planning , Domain Driven Design and Test Driven Development (TDD). Cucumber is designed specifically to ensure that the acceptance tests can easily be read and written by anyone.

==Behaviour Driven Development(BDD)==

Behaviour Driven Development<ref>[http://en.wikipedia.org/wiki/Behavior-driven_development BDD]</ref> preserves the basic iterative (fail-pass) workflow of TDD, but stresses on specifying behaviors that are understandable to people (say from non programming background). In this approach we write tests in a natural language that even a non-programmer can understand.

==Acceptance Test==

Acceptance Test<ref>[http://en.wikipedia.org/wiki/Acceptance_testing Acceptance Test]</ref><ref>[http://pragprog.com/book/hwcuc/the-cucumber-book Cucumber Book]</ref> Drive Planning is a practice that stresses on the importance of identifying the functions and requirements of the software beforehand so that we exactly know when the development phase ends. This practice results in fewer bugs , shorter delivery times and greater customer satisfaction.

===Cucumber Acceptance Test===

Feature: Sign up
Sign up should be quick and friendly. 
Scenario: Successful sign up
New users should get a confirmation email and be greeted personally by the site once signed in.
Given I have chosen to sign up
When I sign up with valid details
Then I should receive a confirmation email
And I should see a personalized greeting message 
Scenario: Duplicate email
Where someone tries to create an account for an email address that already exists.
Given I have chosen to sign up
But I enter an email address that has already registered
Then I should be told that the email is already registered
And I should be offered the option to recover my password

Acceptance tests written in this style are more than just tests; they are executable specifications. As of January 2012, Cucumber was the second most popular testing framework after RSpec for Ruby

==How Cucumber works==

Cucumber is a command-line tool. It reads in specifications from plain-language text files called features, examines them for scenarios to test, and runs the scenarios against the system. The feature files should be written according to specific syntax rules called Gherkin. Along with the features, you give Cucumber a set of step definitions, which map the business-readable language of each step into Ruby code to carry out whatever action is being described by the step. Cucumber takes customer understandable user stories as input and does integration and acceptance tests on the system with those as its input.

===Feature===
A Feature is a high level statement of the what the test case does and there is only one feature per user story. For every feature that is supported by the system , a separate feature file has to be written and included in the features directory. The feature files has .feature file extension.

===Scenario===
A Scenario consists of one or more steps which describe about the various actions performed by the user with respect to this particular feature. There can be one or more scenarios per feature in a user story. A feature usually contains 3 to 8 steps in it. The steps of the scenario always begin with one of the below mentioned key words :

1. Given : Steps that begin with given represent the state of the world before an event.(preconditions) 
2. When : Steps that represent the event. 
3. Then : Steps that represent the expected outcome. 
4. And and But : Steps that extend the previous step. 

===Step and Step Definitions===
When testing with Cucumber , The user stories are all kept in one set of files called Steps.The Steps are compared with Step Definitions which are files written in ruby which gives the rules based on which the steps are executed. Step definitions are analogous to method definitions and steps of scenarios are analogous to method calls. Cucumber uses regular expressions to match the English phrases in the steps of scenarios to step definitions.

When the cucumber test framework is run , The steps present in the feature file can be classified as follows based on the result of regex matching with the step definitions.<ref>[https://github.com/cucumber/cucumber/wiki/Step-Definitions Step Definitions in Ruby]</ref>

====Successful steps====
When Cucumber finds a matching Step Definition it will execute it. If the block in the step definition doesn’t raise an Exception, the step is marked as successful (green). What you return from a Step Definition has no significance what so ever.

====Undefined steps====
When Cucumber can’t find a matching Step Definition the step gets marked as yellow, and all subsequent steps in the scenario are skipped. If you use --strict this will cause Cucumber to exit with 1.

====Pending steps====
When a Step Definition’s Proc invokes the #pending method, the step is marked as yellow (as with undefined ones), reminding you that you have work to do. If you use --strict this will cause Cucumber to exit with 1.

====Failed steps====
When a Step Definition’s Proc is executed and raises an error, the step is marked as red. Returning nil or false will not cause a step definition to fail.

Cucumber tries to run the steps based on the definitions and thus colors steps based on the execution of the steps. The colors for the steps assigned are as follows : 
 
1. Green : for passing. 
2. Yellow : for not yet implemented. 
3. Red : for failing. 
4. Blue : Once a step fails all the successive steps are marked in blue. 

[[File:Cucumber.JPG|500px|thumb|center|Cucumber Testing Stack]]

==Advantages of Cucumber==
*Specifications can be written in more than forty different spoken languages.
*Cucumber helps reduce the gap between technical and non-technical members of a software team.
*Cucumber tests can be easily read and written by business stakeholders.
*Writing Cucumber tests are quick, easy, efficient and understandable.

=Cucumber Installation=

To install cucumber<ref>[http://cuke4ninja.com/sec_ruby_install_cucumber.html Installing Cucumber]</ref> we should make sure that the Environment path is set to “..../Ruby/bin”. Then open the command prompt and run

gem install cucumber

Once cucumber gem is installed then we would be able to check whether it is installed by issuing the following command:

cucumber --version

this should give a version number like “1.2.1”

Cucumber uses Rspec for assertions and hence we need Rspec installed to use Cucumber. Use the following command to install rspec

gem install rspec

=Testing a Sample Ruby Application using Cucumber=
Lets walk through a example for creating a Hello World Ruby application and testing it using cucumber<ref>[http://pragprog.com/book/hwcuc/the-cucumber-book Sample Cucumber Application]</ref>.

Step 1 : Create a new directory

mkdir HelloCucumber

Step 2 : Install Cucumber and Rspec

gem install cucumber
gem instal rspec

Step 3 : Create a directory features and create a file basic.feature in the features directory

mkdir features

Content of features/basic.feature

Feature: Hello World Feature 
Scenario: Hello World Scenario
Given The Action is Hello
When The Subject is World
Then The Greeting is Hello, World

Step 4: Create step_definitions directory inside features directory. Create basic_step.rb file inside step_definitions.

mkdir features/step_definitions

Content of features/step_definitions/basic_step.rb

require 'rspec/expectations' 
Given /The Action is ([A-z]*)/ do |action|
@action = action
end 
When /The Subject is ([A-z]*)/ do |subject|
@subject = subject
end 
Then /The Greeting is (.*)/ do |greeting|
greeting.should == "#{@action}, #{@subject}"
end
Cucumber uses regular expression after the keywords Given, When and Then to map lines in a feature file to step definitions.

Step 5: Running cucumber command you will see the following output

Feature: Hello World Feature 
Scenario: Hello World Scenario # features\basic.feature:3
Given The Action is Hello # features/step_definitions/basic_steps.rb:3
When The Subject is World # features/step_definitions/basic_steps.rb:7
Then The Greeting is Hello, World # features/step_definitions/basic_steps.rb:11 

1 scenario (1 passed)
3 steps (3 passed)
0m0.016s
Step 6 : Modify the basic.features file to include 2 scenario

Step 6 : Modify the basic.features file to include 2 scenarios

Feature: Hello World Feature 
Scenario: Hello World Scenario
Given The Action is Hello
When The Subject is World
Then The Greeting is Hello, World 
Scenario: Bye World Scenario
Given The Action is Bye
When The Subject is World
Then The Greeting is Hello, World

Step 7 : Running the cucumber command you will see the following output

Scenario: Hello World Scenario # features\basic.feature:3
Given The Action is Hello # features/step_definitions/basic_steps.rb:3
When The Subject is World # features/step_definitions/basic_steps.rb:7
Then The Greeting is Hello, World # features/step_definitions/basic_steps.rb:11 
Scenario: Bye World Scenario # features\basic.feature:8
Given The Action is Bye # features/step_definitions/basic_steps.rb:3
When The Subject is World # features/step_definitions/basic_steps.rb:7
Then The Greeting is Hello, World # features/step_definitions/basic_steps.rb:11
expected: "Bye, World"
got: "Hello, World" (using ==) (RSpec::Expectations::ExpectationNotMetError)
./features/step_definitions/basic_steps.rb:12:in `/The Greeting is (.*)/'
features\basic.feature:11:in `Then The Greeting is Hello, World' 
Failing Scenarios:
cucumber features\basic.feature:8 # Scenario: Bye World Scenario 
2 scenarios (1 failed, 1 passed)
6 steps (1 failed, 5 passed)
0m0.033s

The Bye Scenario fails since the expected output is “Hello, World” but the received output is “Bye,World”.

=Testing a Sample Rails Application using Cucumber=
<ref>[http://railscasts.com/episodes/155-beginning-with-cucumber Sample Cucumber Application on Rails]</ref>

Cucumber easily integrates with Rails and hence can be used with Ruby applications which run on Rails. But there are a few steps which have to be followed before integrating cucumber with Rails. Lets walk through it by creating a new rails application.

rails new cucumber_app

Install the required cucumber gems
 
gem install cucumber
gem install cucumber cucumber-rails

Add the following lines to your gemfile. These gems are required only for the test environment. The gems database_cleaner , rspec-rails and webrat are required for cucumber to function properly.
 
group :test do
gem 'database_cleaner'
gem 'cucumber'
gem "rspec-rails", "~> 2.0", :require => false
gem "cucumber-rails", "1.0.6"
gem 'webrat'
end

After modifying the gem file, run bundle update

bundle update

The required cucumber files are generated using the following command. The output below the command shows the folders and files that gets created for the cucumber test framework.

rails generate cucumber:install
 
identical script/cucumber
chmod script/cucumber
exist features/step_definitions
identical features/step_definitions/web_steps.rb
exist features/support
identical features/support/paths.rb
identical features/support/selectors.rb
identical features/support/env.rb
exist lib/tasks
identical lib/tasks/cucumber.rake
 
The Step definitions folder contains ruby files which test the steps which are mentioned in feature file of the cucumber.
 
The paths.rb file is created in the support folder will contain the rules based on which the step definitions will be compared to the steps and matched. In case we come across any steps whose execution fails while running cucumber we would have to update the paths.rb file to resolve the issue.
 
env.rb is only loaded when the application is first started up and it sets up the environment required by Cucumber to execute.
 
rails generate model article title:string content:text
rake db:migrate
rake db:test:clone
rails generate controller articles index
 
The above four commands generate models with the name article and with two fields title and content
and the next two commands migrate the db to production and the last commands creates controller for article and index objects.
 
We have to go the home directory of our rails application and then run Cucumber with the following command.The result would then be shown to the user on how many and which steps succeeded and failed.

=> cucumber
===Capybara===
<ref>[http://net.tutsplus.com/tutorials/ruby/ruby-for-newbies-testing-web-apps-with-capybara-and-cucumber Web-app with Cucumber and Capybara]</ref>

We need a tool that acts out the user stories that are part of the feature that is to be tested with Cucumber. Capybara can be used as that tool. Capybara is an integration testing tool for rack based web based applications. It simulates how a user would interact with a website. It can simulate the actions of a web browser and hence can interact with the application to receive web pages. It can also parse the HTML content and submits forms as the user would. One of the restrictions that Capybara has is that it cannot handle JavaScript. There are other tools like webdriver which can handle JavaScript but it runs a lot slower compared to Capybara.

=Comparison of Unit Test Frameworks : Rspec, Shoulda and Cucumber=

{|border="2" cellpadding="5" cellspacing="0" align="center"
|-
! scope="col" | Rspec
! scope="col" | Shoulda
! scope="col" | Cucumber

|-
|RSpec is based on the Behaviour driven development model provided by Ruby. It has its origins in Test Driven Development and Domain Driven Design.
|Shoulda is based on the Test:Unit which is another Ruby Test Framework. It is based on Test Driven Development.
|Cucumber is a combination of Test Driven Development and Behaviour driven development.
|-
|RSpec provides a Domain Specific Language that can express code functionality and behaviour.
|Shoulda provides macros, helpers and matchers.
|Cucumber allows the test cases to be written in native languages.
|-
|RSpec too allows nested describe structure.
|Shoulda has nested contexts which helps create different environment for different set of tests.
|Cucumber is similar to RSpec and provides nested structures.
|-
|RSpec is expressive when it comes to understanding functionalities since it was designed with the human readability in mind.
|Shoulda has more descriptive names compared to its predecessor Test::Unit but its less expressive.
|Cucumber is more descriptive and allows business stakeholder to read and write test specification.

|}

=Reference=
<references/>

CSC/ECE 517 Fall 2012/ch1 1w3 pl

2012-09-14T21:41:33Z

Pvasude: /* Failed steps */

='''Unit-Testing Frameworks for Ruby: Cucumber'''=

This wiki-page serves as a knowledge source for understanding Unit-Testing Frameworks available for Ruby particularly Cucumber . 

__TOC__

=Introduction=

Unit testing is a software development process for testing individual units of source code independently for proper operation <ref>[http://en.wikipedia.org/wiki/Unit_testing Unit Testing]</ref>. An unit testing framework helps the process of unit testing by automating the test cases written to ensure the correctness of the system. They are often third-party products that are not offered as part of the suite.Ruby provides a framework in its standard library for setting up, organizing, and running tests called Test::Unit <ref>[http://en.wikibooks.org/wiki/Ruby_Programming/Unit_testing Ruby Unit Testing Framework]</ref>. Other testing frameworks available for ruby are Shoulda, RSpec and Cucumber.

=Cucumber=
Cucumber is one of the latest unit test frameworks to have come for Ruby as part of the RSpec family of tools. Cucumber itself is written in the Ruby programming language and adheres to Behaviour Driven Development(BDD). Behaviour Driven Development is an Agile Development process that comprises aspects of Acceptance Test Driven Planning , Domain Driven Design and Test Driven Development (TDD). Cucumber is designed specifically to ensure that the acceptance tests can easily be read and written by anyone.

==Behaviour Driven Development(BDD)==

Behaviour Driven Development<ref>[http://en.wikipedia.org/wiki/Behavior-driven_development BDD]</ref> preserves the basic iterative (fail-pass) workflow of TDD, but stresses on specifying behaviors that are understandable to people (say from non programming background). In this approach we write tests in a natural language that even a non-programmer can understand.

==Acceptance Test==

Acceptance Test<ref>[http://en.wikipedia.org/wiki/Acceptance_testing Acceptance Test]</ref><ref>[http://pragprog.com/book/hwcuc/the-cucumber-book Cucumber Book]</ref> Drive Planning is a practice that stresses on the importance of identifying the functions and requirements of the software beforehand so that we exactly know when the development phase ends. This practice results in fewer bugs , shorter delivery times and greater customer satisfaction.

===Cucumber Acceptance Test===

Feature: Sign up
Sign up should be quick and friendly. 
Scenario: Successful sign up
New users should get a confirmation email and be greeted personally by the site once signed in.
Given I have chosen to sign up
When I sign up with valid details
Then I should receive a confirmation email
And I should see a personalized greeting message 
Scenario: Duplicate email
Where someone tries to create an account for an email address that already exists.
Given I have chosen to sign up
But I enter an email address that has already registered
Then I should be told that the email is already registered
And I should be offered the option to recover my password

Acceptance tests written in this style are more than just tests; they are executable specifications. As of January 2012, Cucumber was the second most popular testing framework after RSpec for Ruby

==How Cucumber works==

Cucumber is a command-line tool. It reads in specifications from plain-language text files called features, examines them for scenarios to test, and runs the scenarios against the system. The feature files should be written according to specific syntax rules called Gherkin. Along with the features, you give Cucumber a set of step definitions, which map the business-readable language of each step into Ruby code to carry out whatever action is being described by the step. Cucumber takes customer understandable user stories as input and does integration and acceptance tests on the system with those as its input.

===Feature===
A Feature is a high level statement of the what the test case does and there is only one feature per user story. For every feature that is supported by the system , a separate feature file has to be written and included in the features directory. The feature files has .feature file extension.

===Scenario===
A Scenario consists of one or more steps which describe about the various actions performed by the user with respect to this particular feature. There can be one or more scenarios per feature in a user story. A feature usually contains 3 to 8 steps in it. The steps of the scenario always begin with one of the below mentioned key words :

1. Given : Steps that begin with given represent the state of the world before an event.(preconditions) 
2. When : Steps that represent the event. 
3. Then : Steps that represent the expected outcome. 
4. And and But : Steps that extend the previous step. 

===Step and Step Definitions===
When testing with Cucumber , The user stories are all kept in one set of files called Steps.The Steps are compared with Step Definitions which are files written in ruby which gives the rules based on which the steps are executed. Step definitions are analogous to method definitions and steps of scenarios are analogous to method calls. Cucumber uses regular expressions to match the English phrases in the steps of scenarios to step definitions.

When the cucumber test framework is run , The steps present in the feature file can be classified as follows based on the result of regex matching with the step definitions.<ref>[https://github.com/cucumber/cucumber/wiki/Step-Definitions Step Definitions in Ruby]</ref>

====Successful steps====
When Cucumber finds a matching Step Definition it will execute it. If the block in the step definition doesn’t raise an Exception, the step is marked as successful (green). What you return from a Step Definition has no significance what so ever.

====Undefined steps====
When Cucumber can’t find a matching Step Definition the step gets marked as yellow, and all subsequent steps in the scenario are skipped. If you use --strict this will cause Cucumber to exit with 1.

====Pending steps====
When a Step Definition’s Proc invokes the #pending method, the step is marked as yellow (as with undefined ones), reminding you that you have work to do. If you use --strict this will cause Cucumber to exit with 1.

====Failed steps====
When a Step Definition’s Proc is executed and raises an error, the step is marked as red. Returning nil or false will not cause a step definition to fail.

Cucumber tries to run the steps based on the definitions and thus colors steps based on the execution of the steps. The colors for the steps assigned are as follows : 
 
1. Green : for passing. 
2. Yellow : for not yet implemented. 
3. Red : for failing. 
4. Blue : Once a step fails all the successive steps are marked in blue. 

[[File:Cucumber.JPG|500px|thumb|center|Cucumber Testing Stack]]

==Advantages of Cucumber==
*Specifications can be written in more than forty different spoken languages.
*Cucumber helps reduce the gap between technical and non-technical members of a software team.
*Cucumber tests can be easily read and written by business stakeholders.
*Writing Cucumber tests are quick, easy, efficient and understandable.

=Cucumber Installation=

To install cucumber<ref>[http://cuke4ninja.com/sec_ruby_install_cucumber.html Installing Cucumber]</ref> we should make sure that the Environment path is set to “..../Ruby/bin”. Then open the command prompt and run

gem install cucumber

Once cucumber gem is installed then we would be able to check whether it is installed by issuing the following command:

cucumber --version

this should give a version number like “1.2.1”

Cucumber uses Rspec for assertions and hence we need Rspec installed to use Cucumber. Use the following command to install rspec

gem install rspec

=Testing a Sample Ruby Application using Cucumber=
Lets walk through a example for creating a Hello World Ruby application and testing it using cucumber<ref>[http://pragprog.com/book/hwcuc/the-cucumber-book Sample Cucumber Application]</ref>.

Step 1 : Create a new directory

mkdir HelloCucumber

Step 2 : Install Cucumber and Rspec

gem install cucumber
gem instal rspec

Step 3 : Create a directory features and create a file basic.feature in the features directory

mkdir features

Content of features/basic.feature

Feature: Hello World Feature 
Scenario: Hello World Scenario
Given The Action is Hello
When The Subject is World
Then The Greeting is Hello, World

Step 4: Create step_definitions directory inside features directory. Create basic_step.rb file inside step_definitions.

mkdir features/step_definitions

Content of features/step_definitions/basic_step.rb

require 'rspec/expectations' 
Given /The Action is ([A-z]*)/ do |action|
@action = action
end 
When /The Subject is ([A-z]*)/ do |subject|
@subject = subject
end 
Then /The Greeting is (.*)/ do |greeting|
greeting.should == "#{@action}, #{@subject}"
end
Cucumber uses regular expression after the keywords Given, When and Then to map lines in a feature file to step definitions.

Step 5: Running cucumber command you will see the following output

Feature: Hello World Feature 
Scenario: Hello World Scenario # features\basic.feature:3
Given The Action is Hello # features/step_definitions/basic_steps.rb:3
When The Subject is World # features/step_definitions/basic_steps.rb:7
Then The Greeting is Hello, World # features/step_definitions/basic_steps.rb:11 

1 scenario (1 passed)
3 steps (3 passed)
0m0.016s
Step 6 : Modify the basic.features file to include 2 scenario

Step 6 : Modify the basic.features file to include 2 scenarios

Feature: Hello World Feature 
Scenario: Hello World Scenario
Given The Action is Hello
When The Subject is World
Then The Greeting is Hello, World 
Scenario: Bye World Scenario
Given The Action is Bye
When The Subject is World
Then The Greeting is Hello, World

Step 7 : Running the cucumber command you will see the following output

Scenario: Hello World Scenario # features\basic.feature:3
Given The Action is Hello # features/step_definitions/basic_steps.rb:3
When The Subject is World # features/step_definitions/basic_steps.rb:7
Then The Greeting is Hello, World # features/step_definitions/basic_steps.rb:11 
Scenario: Bye World Scenario # features\basic.feature:8
Given The Action is Bye # features/step_definitions/basic_steps.rb:3
When The Subject is World # features/step_definitions/basic_steps.rb:7
Then The Greeting is Hello, World # features/step_definitions/basic_steps.rb:11
expected: "Bye, World"
got: "Hello, World" (using ==) (RSpec::Expectations::ExpectationNotMetError)
./features/step_definitions/basic_steps.rb:12:in `/The Greeting is (.*)/'
features\basic.feature:11:in `Then The Greeting is Hello, World' 
Failing Scenarios:
cucumber features\basic.feature:8 # Scenario: Bye World Scenario 
2 scenarios (1 failed, 1 passed)
6 steps (1 failed, 5 passed)
0m0.033s

The Bye Scenario fails since the expected output is “Hello, World” but the received output is “Bye,World”.

=Testing a Sample Rails Application using Cucumber=
<ref>[http://railscasts.com/episodes/155-beginning-with-cucumber Sample Cucumber Application on Rails]</ref>

Cucumber easily integrates with Rails and hence can be used with Ruby applications which run on Rails. But there are a few steps which have to be followed before integrating cucumber with Rails. Lets walk through it by creating a new rails application.

rails new cucumber_app

Install the required cucumber gems
 
gem install cucumber
gem install cucumber cucumber-rails

Add the following lines to your gemfile. These gems are required only for the test environment. The gems database_cleaner , rspec-rails and webrat are required for cucumber to function properly.
 
group :test do
gem 'database_cleaner'
gem 'cucumber'
gem "rspec-rails", "~> 2.0", :require => false
gem "cucumber-rails", "1.0.6"
gem 'webrat'
end

After modifying the gem file, run bundle update

bundle update

The required cucumber files are generated using the following command. The output below the command shows the folders and files that gets created for the cucumber test framework.

rails generate cucumber:install
 
identical script/cucumber
chmod script/cucumber
exist features/step_definitions
identical features/step_definitions/web_steps.rb
exist features/support
identical features/support/paths.rb
identical features/support/selectors.rb
identical features/support/env.rb
exist lib/tasks
identical lib/tasks/cucumber.rake
 
The Step definitions folder contains ruby files which test the steps which are mentioned in feature file of the cucumber.
 
The paths.rb file is created in the support folder will contain the rules based on which the step definitions will be compared to the steps and matched. In case we come across any steps whose execution fails while running cucumber we would have to update the paths.rb file to resolve the issue.
 
env.rb is only loaded when the application is first started up and it sets up the environment required by Cucumber to execute.
 
rails generate model article title:string content:text
rake db:migrate
rake db:test:clone
rails generate controller articles index
 
The above four commands generate models with the name article and with two fields title and content
and the next two commands migrate the db to production and the last commands creates controller for article and index objects.
 
We have to go the home directory of our rails application and then run Cucumber with the following command.The result would then be shown to the user on how many and which steps succeeded and failed.

=> cucumber
===Capybara===
<ref>[http://net.tutsplus.com/tutorials/ruby/ruby-for-newbies-testing-web-apps-with-capybara-and-cucumber Web-app with Cucumber and Capybara]</ref>

We need a tool that acts out the user stories that are part of the feature that is to be tested with Cucumber. Capybara can be used as that tool. Capybara is an integration testing tool for rack based web based applications. It simulates how a user would interact with a website. It can simulate the actions of a web browser and hence can interact with the application to receive web pages. It can also parse the HTML content and submits forms as the user would. One of the restrictions that Capybara has is that it cannot handle JavaScript. There are other tools like webdriver which can handle JavaScript but it runs a lot slower compared to Capybara.

=Comparison of Unit Test Frameworks : Rspec, Shoulda and Cucumber=

{|border="2" cellpadding="5" cellspacing="0" align="center"
|-
! scope="col" | Rspec
! scope="col" | Shoulda
! scope="col" | Cucumber

|-
|RSpec is based on the Behaviour driven development model provided by Ruby. It has its origins in Test Driven Development and Domain Driven Design.
|Shoulda is based on the Test:Unit which is another Ruby Test Framework. It is based on Test Driven Development.
|Cucumber is a combination of Test Driven Development and Behaviour driven development.
|-
|RSpec provides a Domain Specific Language that can express code functionality and behaviour.
|Shoulda provides macros, helpers and matchers.
|Cucumber allows the test cases to be written in native languages
|-
|RSpec too allows nested describe structure.
|Shoulda has nested contexts which helps create different environment for different set of tests.
|Cucumber is similar to RSpec and provides nested structures
|-
|RSpec is expressive when it comes to understanding functionalities since it was designed with the human readability in mind.
|Shoulda has more descriptive names compared to its predecessor Test::Unit but its less expressive.
|Cucumber is more descriptive and allows business stakeholder to read and write test specification.

|}

=Reference=
<references/>

CSC/ECE 517 Fall 2012/ch1 1w3 pl

2012-09-14T21:41:13Z

Pvasude: /* Cucumber Testing Stack */

='''Unit-Testing Frameworks for Ruby: Cucumber'''=

This wiki-page serves as a knowledge source for understanding Unit-Testing Frameworks available for Ruby particularly Cucumber . 

__TOC__

=Introduction=

Unit testing is a software development process for testing individual units of source code independently for proper operation <ref>[http://en.wikipedia.org/wiki/Unit_testing Unit Testing]</ref>. An unit testing framework helps the process of unit testing by automating the test cases written to ensure the correctness of the system. They are often third-party products that are not offered as part of the suite.Ruby provides a framework in its standard library for setting up, organizing, and running tests called Test::Unit <ref>[http://en.wikibooks.org/wiki/Ruby_Programming/Unit_testing Ruby Unit Testing Framework]</ref>. Other testing frameworks available for ruby are Shoulda, RSpec and Cucumber.

=Cucumber=
Cucumber is one of the latest unit test frameworks to have come for Ruby as part of the RSpec family of tools. Cucumber itself is written in the Ruby programming language and adheres to Behaviour Driven Development(BDD). Behaviour Driven Development is an Agile Development process that comprises aspects of Acceptance Test Driven Planning , Domain Driven Design and Test Driven Development (TDD). Cucumber is designed specifically to ensure that the acceptance tests can easily be read and written by anyone.

==Behaviour Driven Development(BDD)==

Behaviour Driven Development<ref>[http://en.wikipedia.org/wiki/Behavior-driven_development BDD]</ref> preserves the basic iterative (fail-pass) workflow of TDD, but stresses on specifying behaviors that are understandable to people (say from non programming background). In this approach we write tests in a natural language that even a non-programmer can understand.

==Acceptance Test==

Acceptance Test<ref>[http://en.wikipedia.org/wiki/Acceptance_testing Acceptance Test]</ref><ref>[http://pragprog.com/book/hwcuc/the-cucumber-book Cucumber Book]</ref> Drive Planning is a practice that stresses on the importance of identifying the functions and requirements of the software beforehand so that we exactly know when the development phase ends. This practice results in fewer bugs , shorter delivery times and greater customer satisfaction.

===Cucumber Acceptance Test===

Feature: Sign up
Sign up should be quick and friendly. 
Scenario: Successful sign up
New users should get a confirmation email and be greeted personally by the site once signed in.
Given I have chosen to sign up
When I sign up with valid details
Then I should receive a confirmation email
And I should see a personalized greeting message 
Scenario: Duplicate email
Where someone tries to create an account for an email address that already exists.
Given I have chosen to sign up
But I enter an email address that has already registered
Then I should be told that the email is already registered
And I should be offered the option to recover my password

Acceptance tests written in this style are more than just tests; they are executable specifications. As of January 2012, Cucumber was the second most popular testing framework after RSpec for Ruby

==How Cucumber works==

Cucumber is a command-line tool. It reads in specifications from plain-language text files called features, examines them for scenarios to test, and runs the scenarios against the system. The feature files should be written according to specific syntax rules called Gherkin. Along with the features, you give Cucumber a set of step definitions, which map the business-readable language of each step into Ruby code to carry out whatever action is being described by the step. Cucumber takes customer understandable user stories as input and does integration and acceptance tests on the system with those as its input.

===Feature===
A Feature is a high level statement of the what the test case does and there is only one feature per user story. For every feature that is supported by the system , a separate feature file has to be written and included in the features directory. The feature files has .feature file extension.

===Scenario===
A Scenario consists of one or more steps which describe about the various actions performed by the user with respect to this particular feature. There can be one or more scenarios per feature in a user story. A feature usually contains 3 to 8 steps in it. The steps of the scenario always begin with one of the below mentioned key words :

1. Given : Steps that begin with given represent the state of the world before an event.(preconditions) 
2. When : Steps that represent the event. 
3. Then : Steps that represent the expected outcome. 
4. And and But : Steps that extend the previous step. 

===Step and Step Definitions===
When testing with Cucumber , The user stories are all kept in one set of files called Steps.The Steps are compared with Step Definitions which are files written in ruby which gives the rules based on which the steps are executed. Step definitions are analogous to method definitions and steps of scenarios are analogous to method calls. Cucumber uses regular expressions to match the English phrases in the steps of scenarios to step definitions.

When the cucumber test framework is run , The steps present in the feature file can be classified as follows based on the result of regex matching with the step definitions.<ref>[https://github.com/cucumber/cucumber/wiki/Step-Definitions Step Definitions in Ruby]</ref>

====Successful steps====
When Cucumber finds a matching Step Definition it will execute it. If the block in the step definition doesn’t raise an Exception, the step is marked as successful (green). What you return from a Step Definition has no significance what so ever.

====Undefined steps====
When Cucumber can’t find a matching Step Definition the step gets marked as yellow, and all subsequent steps in the scenario are skipped. If you use --strict this will cause Cucumber to exit with 1.

====Pending steps====
When a Step Definition’s Proc invokes the #pending method, the step is marked as yellow (as with undefined ones), reminding you that you have work to do. If you use --strict this will cause Cucumber to exit with 1.

====Failed steps====
When a Step Definition’s Proc is executed and raises an error, the step is marked as red. Returning nil or false will not cause a step definition to fail.

Cucumber tries to run the steps based on the definitions and thus colors steps based on the execution of the steps. The colors for the steps assigned are as follows : 
 
1. Green : for passing. 
2. Yellow : for not yet implemented. 
3. Red : for failing. 
4. Blue : Once a step fails all the successive steps are marked in blue. 

==Advantages of Cucumber==
*Specifications can be written in more than forty different spoken languages.
*Cucumber helps reduce the gap between technical and non-technical members of a software team.
*Cucumber tests can be easily read and written by business stakeholders.
*Writing Cucumber tests are quick, easy, efficient and understandable.

=Cucumber Installation=

To install cucumber<ref>[http://cuke4ninja.com/sec_ruby_install_cucumber.html Installing Cucumber]</ref> we should make sure that the Environment path is set to “..../Ruby/bin”. Then open the command prompt and run

gem install cucumber

Once cucumber gem is installed then we would be able to check whether it is installed by issuing the following command:

cucumber --version

this should give a version number like “1.2.1”

Cucumber uses Rspec for assertions and hence we need Rspec installed to use Cucumber. Use the following command to install rspec

gem install rspec

=Testing a Sample Ruby Application using Cucumber=
Lets walk through a example for creating a Hello World Ruby application and testing it using cucumber<ref>[http://pragprog.com/book/hwcuc/the-cucumber-book Sample Cucumber Application]</ref>.

Step 1 : Create a new directory

mkdir HelloCucumber

Step 2 : Install Cucumber and Rspec

gem install cucumber
gem instal rspec

Step 3 : Create a directory features and create a file basic.feature in the features directory

mkdir features

Content of features/basic.feature

Feature: Hello World Feature 
Scenario: Hello World Scenario
Given The Action is Hello
When The Subject is World
Then The Greeting is Hello, World

Step 4: Create step_definitions directory inside features directory. Create basic_step.rb file inside step_definitions.

mkdir features/step_definitions

Content of features/step_definitions/basic_step.rb

require 'rspec/expectations' 
Given /The Action is ([A-z]*)/ do |action|
@action = action
end 
When /The Subject is ([A-z]*)/ do |subject|
@subject = subject
end 
Then /The Greeting is (.*)/ do |greeting|
greeting.should == "#{@action}, #{@subject}"
end
Cucumber uses regular expression after the keywords Given, When and Then to map lines in a feature file to step definitions.

Step 5: Running cucumber command you will see the following output

Feature: Hello World Feature 
Scenario: Hello World Scenario # features\basic.feature:3
Given The Action is Hello # features/step_definitions/basic_steps.rb:3
When The Subject is World # features/step_definitions/basic_steps.rb:7
Then The Greeting is Hello, World # features/step_definitions/basic_steps.rb:11 

1 scenario (1 passed)
3 steps (3 passed)
0m0.016s
Step 6 : Modify the basic.features file to include 2 scenario

Step 6 : Modify the basic.features file to include 2 scenarios

Feature: Hello World Feature 
Scenario: Hello World Scenario
Given The Action is Hello
When The Subject is World
Then The Greeting is Hello, World 
Scenario: Bye World Scenario
Given The Action is Bye
When The Subject is World
Then The Greeting is Hello, World

Step 7 : Running the cucumber command you will see the following output

Scenario: Hello World Scenario # features\basic.feature:3
Given The Action is Hello # features/step_definitions/basic_steps.rb:3
When The Subject is World # features/step_definitions/basic_steps.rb:7
Then The Greeting is Hello, World # features/step_definitions/basic_steps.rb:11 
Scenario: Bye World Scenario # features\basic.feature:8
Given The Action is Bye # features/step_definitions/basic_steps.rb:3
When The Subject is World # features/step_definitions/basic_steps.rb:7
Then The Greeting is Hello, World # features/step_definitions/basic_steps.rb:11
expected: "Bye, World"
got: "Hello, World" (using ==) (RSpec::Expectations::ExpectationNotMetError)
./features/step_definitions/basic_steps.rb:12:in `/The Greeting is (.*)/'
features\basic.feature:11:in `Then The Greeting is Hello, World' 
Failing Scenarios:
cucumber features\basic.feature:8 # Scenario: Bye World Scenario 
2 scenarios (1 failed, 1 passed)
6 steps (1 failed, 5 passed)
0m0.033s

The Bye Scenario fails since the expected output is “Hello, World” but the received output is “Bye,World”.

=Testing a Sample Rails Application using Cucumber=
<ref>[http://railscasts.com/episodes/155-beginning-with-cucumber Sample Cucumber Application on Rails]</ref>

Cucumber easily integrates with Rails and hence can be used with Ruby applications which run on Rails. But there are a few steps which have to be followed before integrating cucumber with Rails. Lets walk through it by creating a new rails application.

rails new cucumber_app

Install the required cucumber gems
 
gem install cucumber
gem install cucumber cucumber-rails

Add the following lines to your gemfile. These gems are required only for the test environment. The gems database_cleaner , rspec-rails and webrat are required for cucumber to function properly.
 
group :test do
gem 'database_cleaner'
gem 'cucumber'
gem "rspec-rails", "~> 2.0", :require => false
gem "cucumber-rails", "1.0.6"
gem 'webrat'
end

After modifying the gem file, run bundle update

bundle update

The required cucumber files are generated using the following command. The output below the command shows the folders and files that gets created for the cucumber test framework.

rails generate cucumber:install
 
identical script/cucumber
chmod script/cucumber
exist features/step_definitions
identical features/step_definitions/web_steps.rb
exist features/support
identical features/support/paths.rb
identical features/support/selectors.rb
identical features/support/env.rb
exist lib/tasks
identical lib/tasks/cucumber.rake
 
The Step definitions folder contains ruby files which test the steps which are mentioned in feature file of the cucumber.
 
The paths.rb file is created in the support folder will contain the rules based on which the step definitions will be compared to the steps and matched. In case we come across any steps whose execution fails while running cucumber we would have to update the paths.rb file to resolve the issue.
 
env.rb is only loaded when the application is first started up and it sets up the environment required by Cucumber to execute.
 
rails generate model article title:string content:text
rake db:migrate
rake db:test:clone
rails generate controller articles index
 
The above four commands generate models with the name article and with two fields title and content
and the next two commands migrate the db to production and the last commands creates controller for article and index objects.
 
We have to go the home directory of our rails application and then run Cucumber with the following command.The result would then be shown to the user on how many and which steps succeeded and failed.

=> cucumber
===Capybara===
<ref>[http://net.tutsplus.com/tutorials/ruby/ruby-for-newbies-testing-web-apps-with-capybara-and-cucumber Web-app with Cucumber and Capybara]</ref>

We need a tool that acts out the user stories that are part of the feature that is to be tested with Cucumber. Capybara can be used as that tool. Capybara is an integration testing tool for rack based web based applications. It simulates how a user would interact with a website. It can simulate the actions of a web browser and hence can interact with the application to receive web pages. It can also parse the HTML content and submits forms as the user would. One of the restrictions that Capybara has is that it cannot handle JavaScript. There are other tools like webdriver which can handle JavaScript but it runs a lot slower compared to Capybara.

=Comparison of Unit Test Frameworks : Rspec, Shoulda and Cucumber=

{|border="2" cellpadding="5" cellspacing="0" align="center"
|-
! scope="col" | Rspec
! scope="col" | Shoulda
! scope="col" | Cucumber

|-
|RSpec is based on the Behaviour driven development model provided by Ruby. It has its origins in Test Driven Development and Domain Driven Design.
|Shoulda is based on the Test:Unit which is another Ruby Test Framework. It is based on Test Driven Development.
|Cucumber is a combination of Test Driven Development and Behaviour driven development.
|-
|RSpec provides a Domain Specific Language that can express code functionality and behaviour.
|Shoulda provides macros, helpers and matchers.
|Cucumber allows the test cases to be written in native languages
|-
|RSpec too allows nested describe structure.
|Shoulda has nested contexts which helps create different environment for different set of tests.
|Cucumber is similar to RSpec and provides nested structures
|-
|RSpec is expressive when it comes to understanding functionalities since it was designed with the human readability in mind.
|Shoulda has more descriptive names compared to its predecessor Test::Unit but its less expressive.
|Cucumber is more descriptive and allows business stakeholder to read and write test specification.

|}

=Reference=
<references/>

CSC/ECE 517 Fall 2012/ch1 1w3 pl

2012-09-14T21:23:56Z

Pvasude: /* Testing a Sample Ruby Application using Cucumber */

='''Unit-Testing Frameworks for Ruby: Cucumber'''=

This wiki-page serves as a knowledge source for understanding Unit-Testing Frameworks available for Ruby particularly Cucumber . 

__TOC__

=Introduction=

Unit testing is a software development process for testing individual units of source code independently for proper operation <ref>[http://en.wikipedia.org/wiki/Unit_testing Unit Testing]</ref>. An unit testing framework helps the process of unit testing by automating the test cases written to ensure the correctness of the system. They are often third-party products that are not offered as part of the suite.Ruby provides a framework in its standard library for setting up, organizing, and running tests called Test::Unit <ref>[http://en.wikibooks.org/wiki/Ruby_Programming/Unit_testing Ruby Unit Testing Framework]</ref>. Other testing frameworks available for ruby are Shoulda, RSpec and Cucumber.

=Cucumber=
Cucumber is one of the latest unit test frameworks to have come for Ruby as part of the RSpec family of tools. Cucumber itself is written in the Ruby programming language and adheres to Behaviour Driven Development(BDD). Behaviour Driven Development is an Agile Development process that comprises aspects of Acceptance Test Driven Planning , Domain Driven Design and Test Driven Development (TDD). Cucumber is designed specifically to ensure that the acceptance tests can easily be read and written by anyone.

==Behaviour Driven Development(BDD)==

Behaviour Driven Development<ref>[http://en.wikipedia.org/wiki/Behavior-driven_development BDD]</ref> preserves the basic iterative (fail-pass) workflow of TDD, but stresses on specifying behaviors that are understandable to people (say from non programming background). In this approach we write tests in a natural language that even a non-programmer can understand.

==Acceptance Test==

Acceptance Test<ref>[http://en.wikipedia.org/wiki/Acceptance_testing Acceptance Test]</ref><ref>[http://pragprog.com/book/hwcuc/the-cucumber-book Cucumber Book]</ref> Drive Planning is a practice that stresses on the importance of identifying the functions and requirements of the software beforehand so that we exactly know when the development phase ends. This practice results in fewer bugs , shorter delivery times and greater customer satisfaction.

===Cucumber Acceptance Test===

Feature: Sign up
Sign up should be quick and friendly. 
Scenario: Successful sign up
New users should get a confirmation email and be greeted personally by the site once signed in.
Given I have chosen to sign up
When I sign up with valid details
Then I should receive a confirmation email
And I should see a personalized greeting message 
Scenario: Duplicate email
Where someone tries to create an account for an email address that already exists.
Given I have chosen to sign up
But I enter an email address that has already registered
Then I should be told that the email is already registered
And I should be offered the option to recover my password

Acceptance tests written in this style are more than just tests; they are executable specifications. As of January 2012, Cucumber was the second most popular testing framework after RSpec for Ruby

==How Cucumber works==

Cucumber is a command-line tool. It reads in specifications from plain-language text files called features, examines them for scenarios to test, and runs the scenarios against the system. The feature files should be written according to specific syntax rules called Gherkin. Along with the features, you give Cucumber a set of step definitions, which map the business-readable language of each step into Ruby code to carry out whatever action is being described by the step. Cucumber takes customer understandable user stories as input and does integration and acceptance tests on the system with those as its input.

===Feature===
A Feature is a high level statement of the what the test case does and there is only one feature per user story. For every feature that is supported by the system , a separate feature file has to be written and included in the features directory. The feature files has .feature file extension.

===Scenario===
A Scenario consists of one or more steps which describe about the various actions performed by the user with respect to this particular feature. There can be one or more scenarios per feature in a user story. A feature usually contains 3 to 8 steps in it. The steps of the scenario always begin with one of the below mentioned key words :

1. Given : Steps that begin with given represent the state of the world before an event.(preconditions) 
2. When : Steps that represent the event. 
3. Then : Steps that represent the expected outcome. 
4. And and But : Steps that extend the previous step. 

===Step and Step Definitions===
When testing with Cucumber , The user stories are all kept in one set of files called Steps.The Steps are compared with Step Definitions which are files written in ruby which gives the rules based on which the steps are executed. Step definitions are analogous to method definitions and steps of scenarios are analogous to method calls. Cucumber uses regular expressions to match the English phrases in the steps of scenarios to step definitions.

When the cucumber test framework is run , The steps present in the feature file can be classified as follows based on the result of regex matching with the step definitions.<ref>[https://github.com/cucumber/cucumber/wiki/Step-Definitions Step Definitions in Ruby]</ref>

====Successful steps====
When Cucumber finds a matching Step Definition it will execute it. If the block in the step definition doesn’t raise an Exception, the step is marked as successful (green). What you return from a Step Definition has no significance what so ever.

====Undefined steps====
When Cucumber can’t find a matching Step Definition the step gets marked as yellow, and all subsequent steps in the scenario are skipped. If you use --strict this will cause Cucumber to exit with 1.

====Pending steps====
When a Step Definition’s Proc invokes the #pending method, the step is marked as yellow (as with undefined ones), reminding you that you have work to do. If you use --strict this will cause Cucumber to exit with 1.

====Failed steps====
When a Step Definition’s Proc is executed and raises an error, the step is marked as red. Returning nil or false will not cause a step definition to fail.

Cucumber tries to run the steps based on the definitions and thus colors steps based on the execution of the steps. The colors for the steps assigned are as follows : 
 
1. Green : for passing. 
2. Yellow : for not yet implemented. 
3. Red : for failing. 
4. Blue : Once a step fails all the successive steps are marked in blue. 

==Cucumber Testing Stack==
/* Some Content */

[[File:Cucumber.JPG|500px|thumb|right|Cucumber Testing Stack]]

==Advantages of Cucumber==
*Specifications can be written in more than forty different spoken languages.
*Cucumber helps reduce the gap between technical and non-technical members of a software team.
*Cucumber tests can be easily read and written by business stakeholders.
*Writing Cucumber tests are quick, easy, efficient and understandable.

=Cucumber Installation=

To install cucumber<ref>[http://cuke4ninja.com/sec_ruby_install_cucumber.html Installing Cucumber]</ref> we should make sure that the Environment path is set to “..../Ruby/bin”. Then open the command prompt and run

gem install cucumber

Once cucumber gem is installed then we would be able to check whether it is installed by issuing the following command:

cucumber --version

this should give a version number like “1.2.1”

Cucumber uses Rspec for assertions and hence we need Rspec installed to use Cucumber. Use the following command to install rspec

gem install rspec

=Testing a Sample Ruby Application using Cucumber=
Lets walk through a example for creating a Hello World Ruby application and testing it using cucumber<ref>[http://pragprog.com/book/hwcuc/the-cucumber-book Sample Cucumber Application]</ref>.

Step 1 : Create a new directory

mkdir HelloCucumber

Step 2 : Install Cucumber and Rspec

gem install cucumber
gem instal rspec

Step 3 : Create a directory features and create a file basic.feature in the features directory

mkdir features

Content of features/basic.feature

Feature: Hello World Feature 
Scenario: Hello World Scenario
Given The Action is Hello
When The Subject is World
Then The Greeting is Hello, World

Step 4: Create step_definitions directory inside features directory. Create basic_step.rb file inside step_definitions.

mkdir features/step_definitions

Content of features/step_definitions/basic_step.rb

require 'rspec/expectations' 
Given /The Action is ([A-z]*)/ do |action|
@action = action
end 
When /The Subject is ([A-z]*)/ do |subject|
@subject = subject
end 
Then /The Greeting is (.*)/ do |greeting|
greeting.should == "#{@action}, #{@subject}"
end
Cucumber uses regular expression after the keywords Given, When and Then to map lines in a feature file to step definitions.

Step 5: Running cucumber command you will see the following output

Feature: Hello World Feature 
Scenario: Hello World Scenario # features\basic.feature:3
Given The Action is Hello # features/step_definitions/basic_steps.rb:3
When The Subject is World # features/step_definitions/basic_steps.rb:7
Then The Greeting is Hello, World # features/step_definitions/basic_steps.rb:11 

1 scenario (1 passed)
3 steps (3 passed)
0m0.016s
Step 6 : Modify the basic.features file to include 2 scenario

Step 6 : Modify the basic.features file to include 2 scenarios

Feature: Hello World Feature 
Scenario: Hello World Scenario
Given The Action is Hello
When The Subject is World
Then The Greeting is Hello, World 
Scenario: Bye World Scenario
Given The Action is Bye
When The Subject is World
Then The Greeting is Hello, World

Step 7 : Running the cucumber command you will see the following output

Scenario: Hello World Scenario # features\basic.feature:3
Given The Action is Hello # features/step_definitions/basic_steps.rb:3
When The Subject is World # features/step_definitions/basic_steps.rb:7
Then The Greeting is Hello, World # features/step_definitions/basic_steps.rb:11 
Scenario: Bye World Scenario # features\basic.feature:8
Given The Action is Bye # features/step_definitions/basic_steps.rb:3
When The Subject is World # features/step_definitions/basic_steps.rb:7
Then The Greeting is Hello, World # features/step_definitions/basic_steps.rb:11
expected: "Bye, World"
got: "Hello, World" (using ==) (RSpec::Expectations::ExpectationNotMetError)
./features/step_definitions/basic_steps.rb:12:in `/The Greeting is (.*)/'
features\basic.feature:11:in `Then The Greeting is Hello, World' 
Failing Scenarios:
cucumber features\basic.feature:8 # Scenario: Bye World Scenario 
2 scenarios (1 failed, 1 passed)
6 steps (1 failed, 5 passed)
0m0.033s

The Bye Scenario fails since the expected output is “Hello, World” but the received output is “Bye,World”.

=Testing a Sample Rails Application using Cucumber=
<ref>[http://railscasts.com/episodes/155-beginning-with-cucumber Sample Cucumber Application on Rails]</ref>

Cucumber easily integrates with Rails and hence can be used with Ruby applications which run on Rails. But there are a few steps which have to be followed before integrating cucumber with Rails. Lets walk through it by creating a new rails application.

rails new cucumber_app

Install the required cucumber gems
 
gem install cucumber
gem install cucumber cucumber-rails

Add the following lines to your gemfile. These gems are required only for the test environment. The gems database_cleaner , rspec-rails and webrat are required for cucumber to function properly.
 
group :test do
gem 'database_cleaner'
gem 'cucumber'
gem "rspec-rails", "~> 2.0", :require => false
gem "cucumber-rails", "1.0.6"
gem 'webrat'
end

After modifying the gem file, run bundle update

bundle update

The required cucumber files are generated using the following command. The output below the command shows the folders and files that gets created for the cucumber test framework.

rails generate cucumber:install
 
identical script/cucumber
chmod script/cucumber
exist features/step_definitions
identical features/step_definitions/web_steps.rb
exist features/support
identical features/support/paths.rb
identical features/support/selectors.rb
identical features/support/env.rb
exist lib/tasks
identical lib/tasks/cucumber.rake
 
The Step definitions folder contains ruby files which test the steps which are mentioned in feature file of the cucumber.
 
The paths.rb file is created in the support folder will contain the rules based on which the step definitions will be compared to the steps and matched. In case we come across any steps whose execution fails while running cucumber we would have to update the paths.rb file to resolve the issue.
 
env.rb is only loaded when the application is first started up and it sets up the environment required by Cucumber to execute.
 
rails generate model article title:string content:text
rake db:migrate
rake db:test:clone
rails generate controller articles index
 
The above four commands generate models with the name article and with two fields title and content
and the next two commands migrate the db to production and the last commands creates controller for article and index objects.
 
We have to go the home directory of our rails application and then run Cucumber with the following command.The result would then be shown to the user on how many and which steps succeeded and failed.

=> cucumber
===Capybara===
<ref>[http://net.tutsplus.com/tutorials/ruby/ruby-for-newbies-testing-web-apps-with-capybara-and-cucumber Web-app with Cucumber and Capybara]</ref>

We need a tool that acts out the user stories that are part of the feature that is to be tested with Cucumber. Capybara can be used as that tool. Capybara is an integration testing tool for rack based web based applications. It simulates how a user would interact with a website. It can simulate the actions of a web browser and hence can interact with the application to receive web pages. It can also parse the HTML content and submits forms as the user would. One of the restrictions that Capybara has is that it cannot handle JavaScript. There are other tools like webdriver which can handle JavaScript but it runs a lot slower compared to Capybara.

=Comparison of Unit Test Frameworks : Rspec, Shoulda and Cucumber=

{|border="2" cellpadding="5" cellspacing="0" align="center"
|-
! scope="col" | Rspec
! scope="col" | Shoulda
! scope="col" | Cucumber

|-
|RSpec is based on the Behaviour driven development model provided by Ruby. It has its origins in Test Driven Development and Domain Driven Design.
|Shoulda is based on the Test:Unit which is another Ruby Test Framework. It is based on Test Driven Development.
|Cucumber is a combination of Test Driven Development and Behaviour driven development.
|-
|RSpec provides a Domain Specific Language that can express code functionality and behaviour.
|Shoulda provides macros, helpers and matchers.
|Cucumber allows the test cases to be written in native languages
|-
|RSpec too allows nested describe structure.
|Shoulda has nested contexts which helps create different environment for different set of tests.
|Cucumber is similar to RSpec and provides nested structures
|-
|RSpec is expressive when it comes to understanding functionalities since it was designed with the human readability in mind.
|Shoulda has more descriptive names compared to its predecessor Test::Unit but its less expressive.
|Cucumber is more descriptive and allows business stakeholder to read and write test specification.

|}

=Reference=
<references/>

CSC/ECE 517 Fall 2012/ch1 1w3 pl

2012-09-14T21:23:37Z

Pvasude: /* Testing a Sample Ruby Application using Cucumber */

='''Unit-Testing Frameworks for Ruby: Cucumber'''=

This wiki-page serves as a knowledge source for understanding Unit-Testing Frameworks available for Ruby particularly Cucumber . 

__TOC__

=Introduction=

Unit testing is a software development process for testing individual units of source code independently for proper operation <ref>[http://en.wikipedia.org/wiki/Unit_testing Unit Testing]</ref>. An unit testing framework helps the process of unit testing by automating the test cases written to ensure the correctness of the system. They are often third-party products that are not offered as part of the suite.Ruby provides a framework in its standard library for setting up, organizing, and running tests called Test::Unit <ref>[http://en.wikibooks.org/wiki/Ruby_Programming/Unit_testing Ruby Unit Testing Framework]</ref>. Other testing frameworks available for ruby are Shoulda, RSpec and Cucumber.

=Cucumber=
Cucumber is one of the latest unit test frameworks to have come for Ruby as part of the RSpec family of tools. Cucumber itself is written in the Ruby programming language and adheres to Behaviour Driven Development(BDD). Behaviour Driven Development is an Agile Development process that comprises aspects of Acceptance Test Driven Planning , Domain Driven Design and Test Driven Development (TDD). Cucumber is designed specifically to ensure that the acceptance tests can easily be read and written by anyone.

==Behaviour Driven Development(BDD)==

Behaviour Driven Development<ref>[http://en.wikipedia.org/wiki/Behavior-driven_development BDD]</ref> preserves the basic iterative (fail-pass) workflow of TDD, but stresses on specifying behaviors that are understandable to people (say from non programming background). In this approach we write tests in a natural language that even a non-programmer can understand.

==Acceptance Test==

Acceptance Test<ref>[http://en.wikipedia.org/wiki/Acceptance_testing Acceptance Test]</ref><ref>[http://pragprog.com/book/hwcuc/the-cucumber-book Cucumber Book]</ref> Drive Planning is a practice that stresses on the importance of identifying the functions and requirements of the software beforehand so that we exactly know when the development phase ends. This practice results in fewer bugs , shorter delivery times and greater customer satisfaction.

===Cucumber Acceptance Test===

Feature: Sign up
Sign up should be quick and friendly. 
Scenario: Successful sign up
New users should get a confirmation email and be greeted personally by the site once signed in.
Given I have chosen to sign up
When I sign up with valid details
Then I should receive a confirmation email
And I should see a personalized greeting message 
Scenario: Duplicate email
Where someone tries to create an account for an email address that already exists.
Given I have chosen to sign up
But I enter an email address that has already registered
Then I should be told that the email is already registered
And I should be offered the option to recover my password

Acceptance tests written in this style are more than just tests; they are executable specifications. As of January 2012, Cucumber was the second most popular testing framework after RSpec for Ruby

==How Cucumber works==

Cucumber is a command-line tool. It reads in specifications from plain-language text files called features, examines them for scenarios to test, and runs the scenarios against the system. The feature files should be written according to specific syntax rules called Gherkin. Along with the features, you give Cucumber a set of step definitions, which map the business-readable language of each step into Ruby code to carry out whatever action is being described by the step. Cucumber takes customer understandable user stories as input and does integration and acceptance tests on the system with those as its input.

===Feature===
A Feature is a high level statement of the what the test case does and there is only one feature per user story. For every feature that is supported by the system , a separate feature file has to be written and included in the features directory. The feature files has .feature file extension.

===Scenario===
A Scenario consists of one or more steps which describe about the various actions performed by the user with respect to this particular feature. There can be one or more scenarios per feature in a user story. A feature usually contains 3 to 8 steps in it. The steps of the scenario always begin with one of the below mentioned key words :

1. Given : Steps that begin with given represent the state of the world before an event.(preconditions) 
2. When : Steps that represent the event. 
3. Then : Steps that represent the expected outcome. 
4. And and But : Steps that extend the previous step. 

===Step and Step Definitions===
When testing with Cucumber , The user stories are all kept in one set of files called Steps.The Steps are compared with Step Definitions which are files written in ruby which gives the rules based on which the steps are executed. Step definitions are analogous to method definitions and steps of scenarios are analogous to method calls. Cucumber uses regular expressions to match the English phrases in the steps of scenarios to step definitions.

When the cucumber test framework is run , The steps present in the feature file can be classified as follows based on the result of regex matching with the step definitions.<ref>[https://github.com/cucumber/cucumber/wiki/Step-Definitions Step Definitions in Ruby]</ref>

====Successful steps====
When Cucumber finds a matching Step Definition it will execute it. If the block in the step definition doesn’t raise an Exception, the step is marked as successful (green). What you return from a Step Definition has no significance what so ever.

====Undefined steps====
When Cucumber can’t find a matching Step Definition the step gets marked as yellow, and all subsequent steps in the scenario are skipped. If you use --strict this will cause Cucumber to exit with 1.

====Pending steps====
When a Step Definition’s Proc invokes the #pending method, the step is marked as yellow (as with undefined ones), reminding you that you have work to do. If you use --strict this will cause Cucumber to exit with 1.

====Failed steps====
When a Step Definition’s Proc is executed and raises an error, the step is marked as red. Returning nil or false will not cause a step definition to fail.

Cucumber tries to run the steps based on the definitions and thus colors steps based on the execution of the steps. The colors for the steps assigned are as follows : 
 
1. Green : for passing. 
2. Yellow : for not yet implemented. 
3. Red : for failing. 
4. Blue : Once a step fails all the successive steps are marked in blue. 

==Cucumber Testing Stack==
/* Some Content */

[[File:Cucumber.JPG|500px|thumb|right|Cucumber Testing Stack]]

==Advantages of Cucumber==
*Specifications can be written in more than forty different spoken languages.
*Cucumber helps reduce the gap between technical and non-technical members of a software team.
*Cucumber tests can be easily read and written by business stakeholders.
*Writing Cucumber tests are quick, easy, efficient and understandable.

=Cucumber Installation=

To install cucumber<ref>[http://cuke4ninja.com/sec_ruby_install_cucumber.html Installing Cucumber]</ref> we should make sure that the Environment path is set to “..../Ruby/bin”. Then open the command prompt and run

gem install cucumber

Once cucumber gem is installed then we would be able to check whether it is installed by issuing the following command:

cucumber --version

this should give a version number like “1.2.1”

Cucumber uses Rspec for assertions and hence we need Rspec installed to use Cucumber. Use the following command to install rspec

gem install rspec

=Testing a Sample Ruby Application using Cucumber=
Let walk through a example for creating a Hello World Ruby application and testing it using cucumber<ref>[http://pragprog.com/book/hwcuc/the-cucumber-book Sample Cucumber Application]</ref>.

Step 1 : Create a new directory

mkdir HelloCucumber

Step 2 : Install Cucumber and Rspec

gem install cucumber
gem instal rspec

Step 3 : Create a directory features and create a file basic.feature in the features directory

mkdir features

Content of features/basic.feature

Feature: Hello World Feature 
Scenario: Hello World Scenario
Given The Action is Hello
When The Subject is World
Then The Greeting is Hello, World

Step 4: Create step_definitions directory inside features directory. Create basic_step.rb file inside step_definitions.

mkdir features/step_definitions

Content of features/step_definitions/basic_step.rb

require 'rspec/expectations' 
Given /The Action is ([A-z]*)/ do |action|
@action = action
end 
When /The Subject is ([A-z]*)/ do |subject|
@subject = subject
end 
Then /The Greeting is (.*)/ do |greeting|
greeting.should == "#{@action}, #{@subject}"
end
Cucumber uses regular expression after the keywords Given, When and Then to map lines in a feature file to step definitions.

Step 5: Running cucumber command you will see the following output

Feature: Hello World Feature 
Scenario: Hello World Scenario # features\basic.feature:3
Given The Action is Hello # features/step_definitions/basic_steps.rb:3
When The Subject is World # features/step_definitions/basic_steps.rb:7
Then The Greeting is Hello, World # features/step_definitions/basic_steps.rb:11 

1 scenario (1 passed)
3 steps (3 passed)
0m0.016s
Step 6 : Modify the basic.features file to include 2 scenario

Step 6 : Modify the basic.features file to include 2 scenarios

Feature: Hello World Feature 
Scenario: Hello World Scenario
Given The Action is Hello
When The Subject is World
Then The Greeting is Hello, World 
Scenario: Bye World Scenario
Given The Action is Bye
When The Subject is World
Then The Greeting is Hello, World

Step 7 : Running the cucumber command you will see the following output

Scenario: Hello World Scenario # features\basic.feature:3
Given The Action is Hello # features/step_definitions/basic_steps.rb:3
When The Subject is World # features/step_definitions/basic_steps.rb:7
Then The Greeting is Hello, World # features/step_definitions/basic_steps.rb:11 
Scenario: Bye World Scenario # features\basic.feature:8
Given The Action is Bye # features/step_definitions/basic_steps.rb:3
When The Subject is World # features/step_definitions/basic_steps.rb:7
Then The Greeting is Hello, World # features/step_definitions/basic_steps.rb:11
expected: "Bye, World"
got: "Hello, World" (using ==) (RSpec::Expectations::ExpectationNotMetError)
./features/step_definitions/basic_steps.rb:12:in `/The Greeting is (.*)/'
features\basic.feature:11:in `Then The Greeting is Hello, World' 
Failing Scenarios:
cucumber features\basic.feature:8 # Scenario: Bye World Scenario 
2 scenarios (1 failed, 1 passed)
6 steps (1 failed, 5 passed)
0m0.033s

The Bye Scenario fails since the expected output is “Hello, World” but the received output is “Bye,World”.

=Testing a Sample Rails Application using Cucumber=
<ref>[http://railscasts.com/episodes/155-beginning-with-cucumber Sample Cucumber Application on Rails]</ref>

Cucumber easily integrates with Rails and hence can be used with Ruby applications which run on Rails. But there are a few steps which have to be followed before integrating cucumber with Rails. Lets walk through it by creating a new rails application.

rails new cucumber_app

Install the required cucumber gems
 
gem install cucumber
gem install cucumber cucumber-rails

Add the following lines to your gemfile. These gems are required only for the test environment. The gems database_cleaner , rspec-rails and webrat are required for cucumber to function properly.
 
group :test do
gem 'database_cleaner'
gem 'cucumber'
gem "rspec-rails", "~> 2.0", :require => false
gem "cucumber-rails", "1.0.6"
gem 'webrat'
end

After modifying the gem file, run bundle update

bundle update

The required cucumber files are generated using the following command. The output below the command shows the folders and files that gets created for the cucumber test framework.

rails generate cucumber:install
 
identical script/cucumber
chmod script/cucumber
exist features/step_definitions
identical features/step_definitions/web_steps.rb
exist features/support
identical features/support/paths.rb
identical features/support/selectors.rb
identical features/support/env.rb
exist lib/tasks
identical lib/tasks/cucumber.rake
 
The Step definitions folder contains ruby files which test the steps which are mentioned in feature file of the cucumber.
 
The paths.rb file is created in the support folder will contain the rules based on which the step definitions will be compared to the steps and matched. In case we come across any steps whose execution fails while running cucumber we would have to update the paths.rb file to resolve the issue.
 
env.rb is only loaded when the application is first started up and it sets up the environment required by Cucumber to execute.
 
rails generate model article title:string content:text
rake db:migrate
rake db:test:clone
rails generate controller articles index
 
The above four commands generate models with the name article and with two fields title and content
and the next two commands migrate the db to production and the last commands creates controller for article and index objects.
 
We have to go the home directory of our rails application and then run Cucumber with the following command.The result would then be shown to the user on how many and which steps succeeded and failed.

=> cucumber
===Capybara===
<ref>[http://net.tutsplus.com/tutorials/ruby/ruby-for-newbies-testing-web-apps-with-capybara-and-cucumber Web-app with Cucumber and Capybara]</ref>

We need a tool that acts out the user stories that are part of the feature that is to be tested with Cucumber. Capybara can be used as that tool. Capybara is an integration testing tool for rack based web based applications. It simulates how a user would interact with a website. It can simulate the actions of a web browser and hence can interact with the application to receive web pages. It can also parse the HTML content and submits forms as the user would. One of the restrictions that Capybara has is that it cannot handle JavaScript. There are other tools like webdriver which can handle JavaScript but it runs a lot slower compared to Capybara.

=Comparison of Unit Test Frameworks : Rspec, Shoulda and Cucumber=

{|border="2" cellpadding="5" cellspacing="0" align="center"
|-
! scope="col" | Rspec
! scope="col" | Shoulda
! scope="col" | Cucumber

|-
|RSpec is based on the Behaviour driven development model provided by Ruby. It has its origins in Test Driven Development and Domain Driven Design.
|Shoulda is based on the Test:Unit which is another Ruby Test Framework. It is based on Test Driven Development.
|Cucumber is a combination of Test Driven Development and Behaviour driven development.
|-
|RSpec provides a Domain Specific Language that can express code functionality and behaviour.
|Shoulda provides macros, helpers and matchers.
|Cucumber allows the test cases to be written in native languages
|-
|RSpec too allows nested describe structure.
|Shoulda has nested contexts which helps create different environment for different set of tests.
|Cucumber is similar to RSpec and provides nested structures
|-
|RSpec is expressive when it comes to understanding functionalities since it was designed with the human readability in mind.
|Shoulda has more descriptive names compared to its predecessor Test::Unit but its less expressive.
|Cucumber is more descriptive and allows business stakeholder to read and write test specification.

|}

=Reference=
<references/>

CSC/ECE 517 Fall 2012/ch1 1w3 pl

2012-09-14T21:22:22Z

Pvasude: /* Cucumber Installation */

='''Unit-Testing Frameworks for Ruby: Cucumber'''=

This wiki-page serves as a knowledge source for understanding Unit-Testing Frameworks available for Ruby particularly Cucumber . 

__TOC__

=Introduction=

Unit testing is a software development process for testing individual units of source code independently for proper operation <ref>[http://en.wikipedia.org/wiki/Unit_testing Unit Testing]</ref>. An unit testing framework helps the process of unit testing by automating the test cases written to ensure the correctness of the system. They are often third-party products that are not offered as part of the suite.Ruby provides a framework in its standard library for setting up, organizing, and running tests called Test::Unit <ref>[http://en.wikibooks.org/wiki/Ruby_Programming/Unit_testing Ruby Unit Testing Framework]</ref>. Other testing frameworks available for ruby are Shoulda, RSpec and Cucumber.

=Cucumber=
Cucumber is one of the latest unit test frameworks to have come for Ruby as part of the RSpec family of tools. Cucumber itself is written in the Ruby programming language and adheres to Behaviour Driven Development(BDD). Behaviour Driven Development is an Agile Development process that comprises aspects of Acceptance Test Driven Planning , Domain Driven Design and Test Driven Development (TDD). Cucumber is designed specifically to ensure that the acceptance tests can easily be read and written by anyone.

==Behaviour Driven Development(BDD)==

Behaviour Driven Development<ref>[http://en.wikipedia.org/wiki/Behavior-driven_development BDD]</ref> preserves the basic iterative (fail-pass) workflow of TDD, but stresses on specifying behaviors that are understandable to people (say from non programming background). In this approach we write tests in a natural language that even a non-programmer can understand.

==Acceptance Test==

Acceptance Test<ref>[http://en.wikipedia.org/wiki/Acceptance_testing Acceptance Test]</ref><ref>[http://pragprog.com/book/hwcuc/the-cucumber-book Cucumber Book]</ref> Drive Planning is a practice that stresses on the importance of identifying the functions and requirements of the software beforehand so that we exactly know when the development phase ends. This practice results in fewer bugs , shorter delivery times and greater customer satisfaction.

===Cucumber Acceptance Test===

Feature: Sign up
Sign up should be quick and friendly. 
Scenario: Successful sign up
New users should get a confirmation email and be greeted personally by the site once signed in.
Given I have chosen to sign up
When I sign up with valid details
Then I should receive a confirmation email
And I should see a personalized greeting message 
Scenario: Duplicate email
Where someone tries to create an account for an email address that already exists.
Given I have chosen to sign up
But I enter an email address that has already registered
Then I should be told that the email is already registered
And I should be offered the option to recover my password

Acceptance tests written in this style are more than just tests; they are executable specifications. As of January 2012, Cucumber was the second most popular testing framework after RSpec for Ruby

==How Cucumber works==

Cucumber is a command-line tool. It reads in specifications from plain-language text files called features, examines them for scenarios to test, and runs the scenarios against the system. The feature files should be written according to specific syntax rules called Gherkin. Along with the features, you give Cucumber a set of step definitions, which map the business-readable language of each step into Ruby code to carry out whatever action is being described by the step. Cucumber takes customer understandable user stories as input and does integration and acceptance tests on the system with those as its input.

===Feature===
A Feature is a high level statement of the what the test case does and there is only one feature per user story. For every feature that is supported by the system , a separate feature file has to be written and included in the features directory. The feature files has .feature file extension.

===Scenario===
A Scenario consists of one or more steps which describe about the various actions performed by the user with respect to this particular feature. There can be one or more scenarios per feature in a user story. A feature usually contains 3 to 8 steps in it. The steps of the scenario always begin with one of the below mentioned key words :

1. Given : Steps that begin with given represent the state of the world before an event.(preconditions) 
2. When : Steps that represent the event. 
3. Then : Steps that represent the expected outcome. 
4. And and But : Steps that extend the previous step. 

===Step and Step Definitions===
When testing with Cucumber , The user stories are all kept in one set of files called Steps.The Steps are compared with Step Definitions which are files written in ruby which gives the rules based on which the steps are executed. Step definitions are analogous to method definitions and steps of scenarios are analogous to method calls. Cucumber uses regular expressions to match the English phrases in the steps of scenarios to step definitions.

When the cucumber test framework is run , The steps present in the feature file can be classified as follows based on the result of regex matching with the step definitions.<ref>[https://github.com/cucumber/cucumber/wiki/Step-Definitions Step Definitions in Ruby]</ref>

====Successful steps====
When Cucumber finds a matching Step Definition it will execute it. If the block in the step definition doesn’t raise an Exception, the step is marked as successful (green). What you return from a Step Definition has no significance what so ever.

====Undefined steps====
When Cucumber can’t find a matching Step Definition the step gets marked as yellow, and all subsequent steps in the scenario are skipped. If you use --strict this will cause Cucumber to exit with 1.

====Pending steps====
When a Step Definition’s Proc invokes the #pending method, the step is marked as yellow (as with undefined ones), reminding you that you have work to do. If you use --strict this will cause Cucumber to exit with 1.

====Failed steps====
When a Step Definition’s Proc is executed and raises an error, the step is marked as red. Returning nil or false will not cause a step definition to fail.

Cucumber tries to run the steps based on the definitions and thus colors steps based on the execution of the steps. The colors for the steps assigned are as follows : 
 
1. Green : for passing. 
2. Yellow : for not yet implemented. 
3. Red : for failing. 
4. Blue : Once a step fails all the successive steps are marked in blue. 

==Cucumber Testing Stack==
/* Some Content */

[[File:Cucumber.JPG|500px|thumb|right|Cucumber Testing Stack]]

==Advantages of Cucumber==
*Specifications can be written in more than forty different spoken languages.
*Cucumber helps reduce the gap between technical and non-technical members of a software team.
*Cucumber tests can be easily read and written by business stakeholders.
*Writing Cucumber tests are quick, easy, efficient and understandable.

=Cucumber Installation=

To install cucumber<ref>[http://cuke4ninja.com/sec_ruby_install_cucumber.html Installing Cucumber]</ref> we should make sure that the Environment path is set to “..../Ruby/bin”. Then open the command prompt and run

gem install cucumber

Once cucumber gem is installed then we would be able to check whether it is installed by issuing the following command:

cucumber --version

this should give a version number like “1.2.1”

Cucumber uses Rspec for assertions and hence we need Rspec installed to use Cucumber. Use the following command to install rspec

gem install rspec

=Testing a Sample Ruby Application using Cucumber=
<ref>[http://pragprog.com/book/hwcuc/the-cucumber-book Sample Cucumber Application]</ref>

Step 1 : Create a new directory

mkdir HelloCucumber

Step 2 : Install Cucumber and Rspec

gem install cucumber
gem instal rspec

Step 3 : Create a directory features and create a file basic.feature in the features directory

mkdir features

Content of features/basic.feature

Feature: Hello World Feature 
Scenario: Hello World Scenario
Given The Action is Hello
When The Subject is World
Then The Greeting is Hello, World

Step 4: Create step_definitions directory inside features directory. Create basic_step.rb file inside step_definitions.

mkdir features/step_definitions

Content of features/step_definitions/basic_step.rb

require 'rspec/expectations' 
Given /The Action is ([A-z]*)/ do |action|
@action = action
end 
When /The Subject is ([A-z]*)/ do |subject|
@subject = subject
end 
Then /The Greeting is (.*)/ do |greeting|
greeting.should == "#{@action}, #{@subject}"
end
Cucumber uses regular expression after the keywords Given, When and Then to map lines in a feature file to step definitions.

Step 5: Running cucumber command you will see the following output

Feature: Hello World Feature 
Scenario: Hello World Scenario # features\basic.feature:3
Given The Action is Hello # features/step_definitions/basic_steps.rb:3
When The Subject is World # features/step_definitions/basic_steps.rb:7
Then The Greeting is Hello, World # features/step_definitions/basic_steps.rb:11 

1 scenario (1 passed)
3 steps (3 passed)
0m0.016s
Step 6 : Modify the basic.features file to include 2 scenario

Step 6 : Modify the basic.features file to include 2 scenarios

Feature: Hello World Feature 
Scenario: Hello World Scenario
Given The Action is Hello
When The Subject is World
Then The Greeting is Hello, World 
Scenario: Bye World Scenario
Given The Action is Bye
When The Subject is World
Then The Greeting is Hello, World

Step 7 : Running the cucumber command you will see the following output

Scenario: Hello World Scenario # features\basic.feature:3
Given The Action is Hello # features/step_definitions/basic_steps.rb:3
When The Subject is World # features/step_definitions/basic_steps.rb:7
Then The Greeting is Hello, World # features/step_definitions/basic_steps.rb:11 
Scenario: Bye World Scenario # features\basic.feature:8
Given The Action is Bye # features/step_definitions/basic_steps.rb:3
When The Subject is World # features/step_definitions/basic_steps.rb:7
Then The Greeting is Hello, World # features/step_definitions/basic_steps.rb:11
expected: "Bye, World"
got: "Hello, World" (using ==) (RSpec::Expectations::ExpectationNotMetError)
./features/step_definitions/basic_steps.rb:12:in `/The Greeting is (.*)/'
features\basic.feature:11:in `Then The Greeting is Hello, World' 
Failing Scenarios:
cucumber features\basic.feature:8 # Scenario: Bye World Scenario 
2 scenarios (1 failed, 1 passed)
6 steps (1 failed, 5 passed)
0m0.033s

The Bye Scenario fails since the expected output is “Hello, World” but the received output is “Bye,World”.

=Testing a Sample Rails Application using Cucumber=
<ref>[http://railscasts.com/episodes/155-beginning-with-cucumber Sample Cucumber Application on Rails]</ref>

Cucumber easily integrates with Rails and hence can be used with Ruby applications which run on Rails. But there are a few steps which have to be followed before integrating cucumber with Rails. Lets walk through it by creating a new rails application.

rails new cucumber_app

Install the required cucumber gems
 
gem install cucumber
gem install cucumber cucumber-rails

Add the following lines to your gemfile. These gems are required only for the test environment. The gems database_cleaner , rspec-rails and webrat are required for cucumber to function properly.
 
group :test do
gem 'database_cleaner'
gem 'cucumber'
gem "rspec-rails", "~> 2.0", :require => false
gem "cucumber-rails", "1.0.6"
gem 'webrat'
end

After modifying the gem file, run bundle update

bundle update

The required cucumber files are generated using the following command. The output below the command shows the folders and files that gets created for the cucumber test framework.

rails generate cucumber:install
 
identical script/cucumber
chmod script/cucumber
exist features/step_definitions
identical features/step_definitions/web_steps.rb
exist features/support
identical features/support/paths.rb
identical features/support/selectors.rb
identical features/support/env.rb
exist lib/tasks
identical lib/tasks/cucumber.rake
 
The Step definitions folder contains ruby files which test the steps which are mentioned in feature file of the cucumber.
 
The paths.rb file is created in the support folder will contain the rules based on which the step definitions will be compared to the steps and matched. In case we come across any steps whose execution fails while running cucumber we would have to update the paths.rb file to resolve the issue.
 
env.rb is only loaded when the application is first started up and it sets up the environment required by Cucumber to execute.
 
rails generate model article title:string content:text
rake db:migrate
rake db:test:clone
rails generate controller articles index
 
The above four commands generate models with the name article and with two fields title and content
and the next two commands migrate the db to production and the last commands creates controller for article and index objects.
 
We have to go the home directory of our rails application and then run Cucumber with the following command.The result would then be shown to the user on how many and which steps succeeded and failed.

=> cucumber
===Capybara===
<ref>[http://net.tutsplus.com/tutorials/ruby/ruby-for-newbies-testing-web-apps-with-capybara-and-cucumber Web-app with Cucumber and Capybara]</ref>

We need a tool that acts out the user stories that are part of the feature that is to be tested with Cucumber. Capybara can be used as that tool. Capybara is an integration testing tool for rack based web based applications. It simulates how a user would interact with a website. It can simulate the actions of a web browser and hence can interact with the application to receive web pages. It can also parse the HTML content and submits forms as the user would. One of the restrictions that Capybara has is that it cannot handle JavaScript. There are other tools like webdriver which can handle JavaScript but it runs a lot slower compared to Capybara.

=Comparison of Unit Test Frameworks : Rspec, Shoulda and Cucumber=

{|border="2" cellpadding="5" cellspacing="0" align="center"
|-
! scope="col" | Rspec
! scope="col" | Shoulda
! scope="col" | Cucumber

|-
|RSpec is based on the Behaviour driven development model provided by Ruby. It has its origins in Test Driven Development and Domain Driven Design.
|Shoulda is based on the Test:Unit which is another Ruby Test Framework. It is based on Test Driven Development.
|Cucumber is a combination of Test Driven Development and Behaviour driven development.
|-
|RSpec provides a Domain Specific Language that can express code functionality and behaviour.
|Shoulda provides macros, helpers and matchers.
|Cucumber allows the test cases to be written in native languages
|-
|RSpec too allows nested describe structure.
|Shoulda has nested contexts which helps create different environment for different set of tests.
|Cucumber is similar to RSpec and provides nested structures
|-
|RSpec is expressive when it comes to understanding functionalities since it was designed with the human readability in mind.
|Shoulda has more descriptive names compared to its predecessor Test::Unit but its less expressive.
|Cucumber is more descriptive and allows business stakeholder to read and write test specification.

|}

=Reference=
<references/>

CSC/ECE 517 Fall 2012/ch1 1w3 pl

2012-09-14T21:19:32Z

Pvasude: /* Comparison of Unit Test Frameworks : Rspec, Shoulda and Cucumber */

='''Unit-Testing Frameworks for Ruby: Cucumber'''=

This wiki-page serves as a knowledge source for understanding Unit-Testing Frameworks available for Ruby particularly Cucumber . 

__TOC__

=Introduction=

Unit testing is a software development process for testing individual units of source code independently for proper operation <ref>[http://en.wikipedia.org/wiki/Unit_testing Unit Testing]</ref>. An unit testing framework helps the process of unit testing by automating the test cases written to ensure the correctness of the system. They are often third-party products that are not offered as part of the suite.Ruby provides a framework in its standard library for setting up, organizing, and running tests called Test::Unit <ref>[http://en.wikibooks.org/wiki/Ruby_Programming/Unit_testing Ruby Unit Testing Framework]</ref>. Other testing frameworks available for ruby are Shoulda, RSpec and Cucumber.

=Cucumber=
Cucumber is one of the latest unit test frameworks to have come for Ruby as part of the RSpec family of tools. Cucumber itself is written in the Ruby programming language and adheres to Behaviour Driven Development(BDD). Behaviour Driven Development is an Agile Development process that comprises aspects of Acceptance Test Driven Planning , Domain Driven Design and Test Driven Development (TDD). Cucumber is designed specifically to ensure that the acceptance tests can easily be read and written by anyone.

==Behaviour Driven Development(BDD)==

Behaviour Driven Development<ref>[http://en.wikipedia.org/wiki/Behavior-driven_development BDD]</ref> preserves the basic iterative (fail-pass) workflow of TDD, but stresses on specifying behaviors that are understandable to people (say from non programming background). In this approach we write tests in a natural language that even a non-programmer can understand.

==Acceptance Test==

Acceptance Test<ref>[http://en.wikipedia.org/wiki/Acceptance_testing Acceptance Test]</ref><ref>[http://pragprog.com/book/hwcuc/the-cucumber-book Cucumber Book]</ref> Drive Planning is a practice that stresses on the importance of identifying the functions and requirements of the software beforehand so that we exactly know when the development phase ends. This practice results in fewer bugs , shorter delivery times and greater customer satisfaction.

===Cucumber Acceptance Test===

Feature: Sign up
Sign up should be quick and friendly. 
Scenario: Successful sign up
New users should get a confirmation email and be greeted personally by the site once signed in.
Given I have chosen to sign up
When I sign up with valid details
Then I should receive a confirmation email
And I should see a personalized greeting message 
Scenario: Duplicate email
Where someone tries to create an account for an email address that already exists.
Given I have chosen to sign up
But I enter an email address that has already registered
Then I should be told that the email is already registered
And I should be offered the option to recover my password

Acceptance tests written in this style are more than just tests; they are executable specifications. As of January 2012, Cucumber was the second most popular testing framework after RSpec for Ruby

==How Cucumber works==

Cucumber is a command-line tool. It reads in specifications from plain-language text files called features, examines them for scenarios to test, and runs the scenarios against the system. The feature files should be written according to specific syntax rules called Gherkin. Along with the features, you give Cucumber a set of step definitions, which map the business-readable language of each step into Ruby code to carry out whatever action is being described by the step. Cucumber takes customer understandable user stories as input and does integration and acceptance tests on the system with those as its input.

===Feature===
A Feature is a high level statement of the what the test case does and there is only one feature per user story. For every feature that is supported by the system , a separate feature file has to be written and included in the features directory. The feature files has .feature file extension.

===Scenario===
A Scenario consists of one or more steps which describe about the various actions performed by the user with respect to this particular feature. There can be one or more scenarios per feature in a user story. A feature usually contains 3 to 8 steps in it. The steps of the scenario always begin with one of the below mentioned key words :

1. Given : Steps that begin with given represent the state of the world before an event.(preconditions) 
2. When : Steps that represent the event. 
3. Then : Steps that represent the expected outcome. 
4. And and But : Steps that extend the previous step. 

===Step and Step Definitions===
When testing with Cucumber , The user stories are all kept in one set of files called Steps.The Steps are compared with Step Definitions which are files written in ruby which gives the rules based on which the steps are executed. Step definitions are analogous to method definitions and steps of scenarios are analogous to method calls. Cucumber uses regular expressions to match the English phrases in the steps of scenarios to step definitions.

When the cucumber test framework is run , The steps present in the feature file can be classified as follows based on the result of regex matching with the step definitions.<ref>[https://github.com/cucumber/cucumber/wiki/Step-Definitions Step Definitions in Ruby]</ref>

====Successful steps====
When Cucumber finds a matching Step Definition it will execute it. If the block in the step definition doesn’t raise an Exception, the step is marked as successful (green). What you return from a Step Definition has no significance what so ever.

====Undefined steps====
When Cucumber can’t find a matching Step Definition the step gets marked as yellow, and all subsequent steps in the scenario are skipped. If you use --strict this will cause Cucumber to exit with 1.

====Pending steps====
When a Step Definition’s Proc invokes the #pending method, the step is marked as yellow (as with undefined ones), reminding you that you have work to do. If you use --strict this will cause Cucumber to exit with 1.

====Failed steps====
When a Step Definition’s Proc is executed and raises an error, the step is marked as red. Returning nil or false will not cause a step definition to fail.

Cucumber tries to run the steps based on the definitions and thus colors steps based on the execution of the steps. The colors for the steps assigned are as follows : 
 
1. Green : for passing. 
2. Yellow : for not yet implemented. 
3. Red : for failing. 
4. Blue : Once a step fails all the successive steps are marked in blue. 

==Cucumber Testing Stack==
/* Some Content */

[[File:Cucumber.JPG|500px|thumb|right|Cucumber Testing Stack]]

==Advantages of Cucumber==
*Specifications can be written in more than forty different spoken languages.
*Cucumber helps reduce the gap between technical and non-technical members of a software team.
*Cucumber tests can be easily read and written by business stakeholders.
*Writing Cucumber tests are quick, easy, efficient and understandable.

=Cucumber Installation=
<ref>[http://cuke4ninja.com/sec_ruby_install_cucumber.html Installing Cucumber]</ref>

To install cucumber we should make sure that the Environment path is set to “..../Ruby/bin”. Then open the command prompt and run

gem install cucumber

Once cucumber gem is installed then we would be able to check whether it is installed by issuing the following command:

cucumber --version

this should give a version number like “1.2.1”

Cucumber uses Rspec for assertions and hence we need Rspec installed to use Cucumber. Use the following command to install rspec

gem install rspec

=Testing a Sample Ruby Application using Cucumber=
<ref>[http://pragprog.com/book/hwcuc/the-cucumber-book Sample Cucumber Application]</ref>

Step 1 : Create a new directory

mkdir HelloCucumber

Step 2 : Install Cucumber and Rspec

gem install cucumber
gem instal rspec

Step 3 : Create a directory features and create a file basic.feature in the features directory

mkdir features

Content of features/basic.feature

Feature: Hello World Feature 
Scenario: Hello World Scenario
Given The Action is Hello
When The Subject is World
Then The Greeting is Hello, World

Step 4: Create step_definitions directory inside features directory. Create basic_step.rb file inside step_definitions.

mkdir features/step_definitions

Content of features/step_definitions/basic_step.rb

require 'rspec/expectations' 
Given /The Action is ([A-z]*)/ do |action|
@action = action
end 
When /The Subject is ([A-z]*)/ do |subject|
@subject = subject
end 
Then /The Greeting is (.*)/ do |greeting|
greeting.should == "#{@action}, #{@subject}"
end
Cucumber uses regular expression after the keywords Given, When and Then to map lines in a feature file to step definitions.

Step 5: Running cucumber command you will see the following output

Feature: Hello World Feature 
Scenario: Hello World Scenario # features\basic.feature:3
Given The Action is Hello # features/step_definitions/basic_steps.rb:3
When The Subject is World # features/step_definitions/basic_steps.rb:7
Then The Greeting is Hello, World # features/step_definitions/basic_steps.rb:11 

1 scenario (1 passed)
3 steps (3 passed)
0m0.016s
Step 6 : Modify the basic.features file to include 2 scenario

Step 6 : Modify the basic.features file to include 2 scenarios

Feature: Hello World Feature 
Scenario: Hello World Scenario
Given The Action is Hello
When The Subject is World
Then The Greeting is Hello, World 
Scenario: Bye World Scenario
Given The Action is Bye
When The Subject is World
Then The Greeting is Hello, World

Step 7 : Running the cucumber command you will see the following output

Scenario: Hello World Scenario # features\basic.feature:3
Given The Action is Hello # features/step_definitions/basic_steps.rb:3
When The Subject is World # features/step_definitions/basic_steps.rb:7
Then The Greeting is Hello, World # features/step_definitions/basic_steps.rb:11 
Scenario: Bye World Scenario # features\basic.feature:8
Given The Action is Bye # features/step_definitions/basic_steps.rb:3
When The Subject is World # features/step_definitions/basic_steps.rb:7
Then The Greeting is Hello, World # features/step_definitions/basic_steps.rb:11
expected: "Bye, World"
got: "Hello, World" (using ==) (RSpec::Expectations::ExpectationNotMetError)
./features/step_definitions/basic_steps.rb:12:in `/The Greeting is (.*)/'
features\basic.feature:11:in `Then The Greeting is Hello, World' 
Failing Scenarios:
cucumber features\basic.feature:8 # Scenario: Bye World Scenario 
2 scenarios (1 failed, 1 passed)
6 steps (1 failed, 5 passed)
0m0.033s

The Bye Scenario fails since the expected output is “Hello, World” but the received output is “Bye,World”.

=Testing a Sample Rails Application using Cucumber=
<ref>[http://railscasts.com/episodes/155-beginning-with-cucumber Sample Cucumber Application on Rails]</ref>

Cucumber easily integrates with Rails and hence can be used with Ruby applications which run on Rails. But there are a few steps which have to be followed before integrating cucumber with Rails. Lets walk through it by creating a new rails application.

rails new cucumber_app

Install the required cucumber gems
 
gem install cucumber
gem install cucumber cucumber-rails

Add the following lines to your gemfile. These gems are required only for the test environment. The gems database_cleaner , rspec-rails and webrat are required for cucumber to function properly.
 
group :test do
gem 'database_cleaner'
gem 'cucumber'
gem "rspec-rails", "~> 2.0", :require => false
gem "cucumber-rails", "1.0.6"
gem 'webrat'
end

After modifying the gem file, run bundle update

bundle update

The required cucumber files are generated using the following command. The output below the command shows the folders and files that gets created for the cucumber test framework.

rails generate cucumber:install
 
identical script/cucumber
chmod script/cucumber
exist features/step_definitions
identical features/step_definitions/web_steps.rb
exist features/support
identical features/support/paths.rb
identical features/support/selectors.rb
identical features/support/env.rb
exist lib/tasks
identical lib/tasks/cucumber.rake
 
The Step definitions folder contains ruby files which test the steps which are mentioned in feature file of the cucumber.
 
The paths.rb file is created in the support folder will contain the rules based on which the step definitions will be compared to the steps and matched. In case we come across any steps whose execution fails while running cucumber we would have to update the paths.rb file to resolve the issue.
 
env.rb is only loaded when the application is first started up and it sets up the environment required by Cucumber to execute.
 
rails generate model article title:string content:text
rake db:migrate
rake db:test:clone
rails generate controller articles index
 
The above four commands generate models with the name article and with two fields title and content
and the next two commands migrate the db to production and the last commands creates controller for article and index objects.
 
We have to go the home directory of our rails application and then run Cucumber with the following command.The result would then be shown to the user on how many and which steps succeeded and failed.

=> cucumber
===Capybara===
<ref>[http://net.tutsplus.com/tutorials/ruby/ruby-for-newbies-testing-web-apps-with-capybara-and-cucumber Web-app with Cucumber and Capybara]</ref>

We need a tool that acts out the user stories that are part of the feature that is to be tested with Cucumber. Capybara can be used as that tool. Capybara is an integration testing tool for rack based web based applications. It simulates how a user would interact with a website. It can simulate the actions of a web browser and hence can interact with the application to receive web pages. It can also parse the HTML content and submits forms as the user would. One of the restrictions that Capybara has is that it cannot handle JavaScript. There are other tools like webdriver which can handle JavaScript but it runs a lot slower compared to Capybara.

=Comparison of Unit Test Frameworks : Rspec, Shoulda and Cucumber=

{|border="2" cellpadding="5" cellspacing="0" align="center"
|-
! scope="col" | Rspec
! scope="col" | Shoulda
! scope="col" | Cucumber

|-
|RSpec is based on the Behaviour driven development model provided by Ruby. It has its origins in Test Driven Development and Domain Driven Design.
|Shoulda is based on the Test:Unit which is another Ruby Test Framework. It is based on Test Driven Development.
|Cucumber is a combination of Test Driven Development and Behaviour driven development.
|-
|RSpec provides a Domain Specific Language that can express code functionality and behaviour.
|Shoulda provides macros, helpers and matchers.
|Cucumber allows the test cases to be written in native languages
|-
|RSpec too allows nested describe structure.
|Shoulda has nested contexts which helps create different environment for different set of tests.
|Cucumber is similar to RSpec and provides nested structures
|-
|RSpec is expressive when it comes to understanding functionalities since it was designed with the human readability in mind.
|Shoulda has more descriptive names compared to its predecessor Test::Unit but its less expressive.
|Cucumber is more descriptive and allows business stakeholder to read and write test specification.

|}

=Reference=
<references/>

CSC/ECE 517 Fall 2012/ch1 1w3 pl

2012-09-14T21:18:03Z

Pvasude: /* Comparison of Unit Test Frameworks : Rspec, Shoulda and Cucumber */

='''Unit-Testing Frameworks for Ruby: Cucumber'''=

This wiki-page serves as a knowledge source for understanding Unit-Testing Frameworks available for Ruby particularly Cucumber . 

__TOC__

=Introduction=

Unit testing is a software development process for testing individual units of source code independently for proper operation <ref>[http://en.wikipedia.org/wiki/Unit_testing Unit Testing]</ref>. An unit testing framework helps the process of unit testing by automating the test cases written to ensure the correctness of the system. They are often third-party products that are not offered as part of the suite.Ruby provides a framework in its standard library for setting up, organizing, and running tests called Test::Unit <ref>[http://en.wikibooks.org/wiki/Ruby_Programming/Unit_testing Ruby Unit Testing Framework]</ref>. Other testing frameworks available for ruby are Shoulda, RSpec and Cucumber.

=Cucumber=
Cucumber is one of the latest unit test frameworks to have come for Ruby as part of the RSpec family of tools. Cucumber itself is written in the Ruby programming language and adheres to Behaviour Driven Development(BDD). Behaviour Driven Development is an Agile Development process that comprises aspects of Acceptance Test Driven Planning , Domain Driven Design and Test Driven Development (TDD). Cucumber is designed specifically to ensure that the acceptance tests can easily be read and written by anyone.

==Behaviour Driven Development(BDD)==

Behaviour Driven Development<ref>[http://en.wikipedia.org/wiki/Behavior-driven_development BDD]</ref> preserves the basic iterative (fail-pass) workflow of TDD, but stresses on specifying behaviors that are understandable to people (say from non programming background). In this approach we write tests in a natural language that even a non-programmer can understand.

==Acceptance Test==

Acceptance Test<ref>[http://en.wikipedia.org/wiki/Acceptance_testing Acceptance Test]</ref><ref>[http://pragprog.com/book/hwcuc/the-cucumber-book Cucumber Book]</ref> Drive Planning is a practice that stresses on the importance of identifying the functions and requirements of the software beforehand so that we exactly know when the development phase ends. This practice results in fewer bugs , shorter delivery times and greater customer satisfaction.

===Cucumber Acceptance Test===

Feature: Sign up
Sign up should be quick and friendly. 
Scenario: Successful sign up
New users should get a confirmation email and be greeted personally by the site once signed in.
Given I have chosen to sign up
When I sign up with valid details
Then I should receive a confirmation email
And I should see a personalized greeting message 
Scenario: Duplicate email
Where someone tries to create an account for an email address that already exists.
Given I have chosen to sign up
But I enter an email address that has already registered
Then I should be told that the email is already registered
And I should be offered the option to recover my password

Acceptance tests written in this style are more than just tests; they are executable specifications. As of January 2012, Cucumber was the second most popular testing framework after RSpec for Ruby

==How Cucumber works==

Cucumber is a command-line tool. It reads in specifications from plain-language text files called features, examines them for scenarios to test, and runs the scenarios against the system. The feature files should be written according to specific syntax rules called Gherkin. Along with the features, you give Cucumber a set of step definitions, which map the business-readable language of each step into Ruby code to carry out whatever action is being described by the step. Cucumber takes customer understandable user stories as input and does integration and acceptance tests on the system with those as its input.

===Feature===
A Feature is a high level statement of the what the test case does and there is only one feature per user story. For every feature that is supported by the system , a separate feature file has to be written and included in the features directory. The feature files has .feature file extension.

===Scenario===
A Scenario consists of one or more steps which describe about the various actions performed by the user with respect to this particular feature. There can be one or more scenarios per feature in a user story. A feature usually contains 3 to 8 steps in it. The steps of the scenario always begin with one of the below mentioned key words :

1. Given : Steps that begin with given represent the state of the world before an event.(preconditions) 
2. When : Steps that represent the event. 
3. Then : Steps that represent the expected outcome. 
4. And and But : Steps that extend the previous step. 

===Step and Step Definitions===
When testing with Cucumber , The user stories are all kept in one set of files called Steps.The Steps are compared with Step Definitions which are files written in ruby which gives the rules based on which the steps are executed. Step definitions are analogous to method definitions and steps of scenarios are analogous to method calls. Cucumber uses regular expressions to match the English phrases in the steps of scenarios to step definitions.

When the cucumber test framework is run , The steps present in the feature file can be classified as follows based on the result of regex matching with the step definitions.<ref>[https://github.com/cucumber/cucumber/wiki/Step-Definitions Step Definitions in Ruby]</ref>

====Successful steps====
When Cucumber finds a matching Step Definition it will execute it. If the block in the step definition doesn’t raise an Exception, the step is marked as successful (green). What you return from a Step Definition has no significance what so ever.

====Undefined steps====
When Cucumber can’t find a matching Step Definition the step gets marked as yellow, and all subsequent steps in the scenario are skipped. If you use --strict this will cause Cucumber to exit with 1.

====Pending steps====
When a Step Definition’s Proc invokes the #pending method, the step is marked as yellow (as with undefined ones), reminding you that you have work to do. If you use --strict this will cause Cucumber to exit with 1.

====Failed steps====
When a Step Definition’s Proc is executed and raises an error, the step is marked as red. Returning nil or false will not cause a step definition to fail.

Cucumber tries to run the steps based on the definitions and thus colors steps based on the execution of the steps. The colors for the steps assigned are as follows : 
 
1. Green : for passing. 
2. Yellow : for not yet implemented. 
3. Red : for failing. 
4. Blue : Once a step fails all the successive steps are marked in blue. 

==Cucumber Testing Stack==
/* Some Content */

[[File:Cucumber.JPG|500px|thumb|right|Cucumber Testing Stack]]

==Advantages of Cucumber==
*Specifications can be written in more than forty different spoken languages.
*Cucumber helps reduce the gap between technical and non-technical members of a software team.
*Cucumber tests can be easily read and written by business stakeholders.
*Writing Cucumber tests are quick, easy, efficient and understandable.

=Cucumber Installation=
<ref>[http://cuke4ninja.com/sec_ruby_install_cucumber.html Installing Cucumber]</ref>

To install cucumber we should make sure that the Environment path is set to “..../Ruby/bin”. Then open the command prompt and run

gem install cucumber

Once cucumber gem is installed then we would be able to check whether it is installed by issuing the following command:

cucumber --version

this should give a version number like “1.2.1”

Cucumber uses Rspec for assertions and hence we need Rspec installed to use Cucumber. Use the following command to install rspec

gem install rspec

=Testing a Sample Ruby Application using Cucumber=
<ref>[http://pragprog.com/book/hwcuc/the-cucumber-book Sample Cucumber Application]</ref>

Step 1 : Create a new directory

mkdir HelloCucumber

Step 2 : Install Cucumber and Rspec

gem install cucumber
gem instal rspec

Step 3 : Create a directory features and create a file basic.feature in the features directory

mkdir features

Content of features/basic.feature

Feature: Hello World Feature 
Scenario: Hello World Scenario
Given The Action is Hello
When The Subject is World
Then The Greeting is Hello, World

Step 4: Create step_definitions directory inside features directory. Create basic_step.rb file inside step_definitions.

mkdir features/step_definitions

Content of features/step_definitions/basic_step.rb

require 'rspec/expectations' 
Given /The Action is ([A-z]*)/ do |action|
@action = action
end 
When /The Subject is ([A-z]*)/ do |subject|
@subject = subject
end 
Then /The Greeting is (.*)/ do |greeting|
greeting.should == "#{@action}, #{@subject}"
end
Cucumber uses regular expression after the keywords Given, When and Then to map lines in a feature file to step definitions.

Step 5: Running cucumber command you will see the following output

Feature: Hello World Feature 
Scenario: Hello World Scenario # features\basic.feature:3
Given The Action is Hello # features/step_definitions/basic_steps.rb:3
When The Subject is World # features/step_definitions/basic_steps.rb:7
Then The Greeting is Hello, World # features/step_definitions/basic_steps.rb:11 

1 scenario (1 passed)
3 steps (3 passed)
0m0.016s
Step 6 : Modify the basic.features file to include 2 scenario

Step 6 : Modify the basic.features file to include 2 scenarios

Feature: Hello World Feature 
Scenario: Hello World Scenario
Given The Action is Hello
When The Subject is World
Then The Greeting is Hello, World 
Scenario: Bye World Scenario
Given The Action is Bye
When The Subject is World
Then The Greeting is Hello, World

Step 7 : Running the cucumber command you will see the following output

Scenario: Hello World Scenario # features\basic.feature:3
Given The Action is Hello # features/step_definitions/basic_steps.rb:3
When The Subject is World # features/step_definitions/basic_steps.rb:7
Then The Greeting is Hello, World # features/step_definitions/basic_steps.rb:11 
Scenario: Bye World Scenario # features\basic.feature:8
Given The Action is Bye # features/step_definitions/basic_steps.rb:3
When The Subject is World # features/step_definitions/basic_steps.rb:7
Then The Greeting is Hello, World # features/step_definitions/basic_steps.rb:11
expected: "Bye, World"
got: "Hello, World" (using ==) (RSpec::Expectations::ExpectationNotMetError)
./features/step_definitions/basic_steps.rb:12:in `/The Greeting is (.*)/'
features\basic.feature:11:in `Then The Greeting is Hello, World' 
Failing Scenarios:
cucumber features\basic.feature:8 # Scenario: Bye World Scenario 
2 scenarios (1 failed, 1 passed)
6 steps (1 failed, 5 passed)
0m0.033s

The Bye Scenario fails since the expected output is “Hello, World” but the received output is “Bye,World”.

=Testing a Sample Rails Application using Cucumber=
<ref>[http://railscasts.com/episodes/155-beginning-with-cucumber Sample Cucumber Application on Rails]</ref>

Cucumber easily integrates with Rails and hence can be used with Ruby applications which run on Rails. But there are a few steps which have to be followed before integrating cucumber with Rails. Lets walk through it by creating a new rails application.

rails new cucumber_app

Install the required cucumber gems
 
gem install cucumber
gem install cucumber cucumber-rails

Add the following lines to your gemfile. These gems are required only for the test environment. The gems database_cleaner , rspec-rails and webrat are required for cucumber to function properly.
 
group :test do
gem 'database_cleaner'
gem 'cucumber'
gem "rspec-rails", "~> 2.0", :require => false
gem "cucumber-rails", "1.0.6"
gem 'webrat'
end

After modifying the gem file, run bundle update

bundle update

The required cucumber files are generated using the following command. The output below the command shows the folders and files that gets created for the cucumber test framework.

rails generate cucumber:install
 
identical script/cucumber
chmod script/cucumber
exist features/step_definitions
identical features/step_definitions/web_steps.rb
exist features/support
identical features/support/paths.rb
identical features/support/selectors.rb
identical features/support/env.rb
exist lib/tasks
identical lib/tasks/cucumber.rake
 
The Step definitions folder contains ruby files which test the steps which are mentioned in feature file of the cucumber.
 
The paths.rb file is created in the support folder will contain the rules based on which the step definitions will be compared to the steps and matched. In case we come across any steps whose execution fails while running cucumber we would have to update the paths.rb file to resolve the issue.
 
env.rb is only loaded when the application is first started up and it sets up the environment required by Cucumber to execute.
 
rails generate model article title:string content:text
rake db:migrate
rake db:test:clone
rails generate controller articles index
 
The above four commands generate models with the name article and with two fields title and content
and the next two commands migrate the db to production and the last commands creates controller for article and index objects.
 
We have to go the home directory of our rails application and then run Cucumber with the following command.The result would then be shown to the user on how many and which steps succeeded and failed.

=> cucumber
===Capybara===
<ref>[http://net.tutsplus.com/tutorials/ruby/ruby-for-newbies-testing-web-apps-with-capybara-and-cucumber Web-app with Cucumber and Capybara]</ref>

We need a tool that acts out the user stories that are part of the feature that is to be tested with Cucumber. Capybara can be used as that tool. Capybara is an integration testing tool for rack based web based applications. It simulates how a user would interact with a website. It can simulate the actions of a web browser and hence can interact with the application to receive web pages. It can also parse the HTML content and submits forms as the user would. One of the restrictions that Capybara has is that it cannot handle JavaScript. There are other tools like webdriver which can handle JavaScript but it runs a lot slower compared to Capybara.

=Comparison of Unit Test Frameworks : Rspec, Shoulda and Cucumber=

{|border="2" cellpadding="5" cellspacing="0" align="center"
|-
! scope="col" | Rspec
! scope="col" | Shoulda
! scope="col" | Cucumber

|-
|RSpec is based on the Behaviour driven development model provided by Ruby. It has its origins in Test Driven Development and Domain Driven Design.
|Shoulda is based on the Test:Unit which is another Ruby Test Framework. It is based on Test Driven Development.
|Cucumber is a combination of Test Driven Development and Behaviour driven development.
|-
|RSpec provides a Domain Specific Language that can express code functionality and behaviour.
|Shoulda provides macros, helpers and matchers.
|Cucumber allows the test cases to be written in native languages
|-
|RSpec too allows nested describe structure.
|Shoulda has nested contexts which helps create different environment for different set of tests.
|Cucumber is similar to RSpec and provides nested structures
|-
|RSpec is expressive when it comes to understanding functionalities since it was designed with the human readability in mind.
|Shoulda has more descriptive names compared to its predecessor Test::Unit but its less expressive.
|Cucumber test are even more descriptive and allows business stakeholder to write and read them.

|}

=Reference=
<references/>

CSC/ECE 517 Fall 2012/ch1 1w3 pl

2012-09-14T21:17:15Z

Pvasude: /* Comparison of Unit Test Frameworks : Rspec, Shoulda and Cucumber */

='''Unit-Testing Frameworks for Ruby: Cucumber'''=

This wiki-page serves as a knowledge source for understanding Unit-Testing Frameworks available for Ruby particularly Cucumber . 

__TOC__

=Introduction=

Unit testing is a software development process for testing individual units of source code independently for proper operation <ref>[http://en.wikipedia.org/wiki/Unit_testing Unit Testing]</ref>. An unit testing framework helps the process of unit testing by automating the test cases written to ensure the correctness of the system. They are often third-party products that are not offered as part of the suite.Ruby provides a framework in its standard library for setting up, organizing, and running tests called Test::Unit <ref>[http://en.wikibooks.org/wiki/Ruby_Programming/Unit_testing Ruby Unit Testing Framework]</ref>. Other testing frameworks available for ruby are Shoulda, RSpec and Cucumber.

=Cucumber=
Cucumber is one of the latest unit test frameworks to have come for Ruby as part of the RSpec family of tools. Cucumber itself is written in the Ruby programming language and adheres to Behaviour Driven Development(BDD). Behaviour Driven Development is an Agile Development process that comprises aspects of Acceptance Test Driven Planning , Domain Driven Design and Test Driven Development (TDD). Cucumber is designed specifically to ensure that the acceptance tests can easily be read and written by anyone.

==Behaviour Driven Development(BDD)==

Behaviour Driven Development<ref>[http://en.wikipedia.org/wiki/Behavior-driven_development BDD]</ref> preserves the basic iterative (fail-pass) workflow of TDD, but stresses on specifying behaviors that are understandable to people (say from non programming background). In this approach we write tests in a natural language that even a non-programmer can understand.

==Acceptance Test==

Acceptance Test<ref>[http://en.wikipedia.org/wiki/Acceptance_testing Acceptance Test]</ref><ref>[http://pragprog.com/book/hwcuc/the-cucumber-book Cucumber Book]</ref> Drive Planning is a practice that stresses on the importance of identifying the functions and requirements of the software beforehand so that we exactly know when the development phase ends. This practice results in fewer bugs , shorter delivery times and greater customer satisfaction.

===Cucumber Acceptance Test===

Feature: Sign up
Sign up should be quick and friendly. 
Scenario: Successful sign up
New users should get a confirmation email and be greeted personally by the site once signed in.
Given I have chosen to sign up
When I sign up with valid details
Then I should receive a confirmation email
And I should see a personalized greeting message 
Scenario: Duplicate email
Where someone tries to create an account for an email address that already exists.
Given I have chosen to sign up
But I enter an email address that has already registered
Then I should be told that the email is already registered
And I should be offered the option to recover my password

Acceptance tests written in this style are more than just tests; they are executable specifications. As of January 2012, Cucumber was the second most popular testing framework after RSpec for Ruby

==How Cucumber works==

Cucumber is a command-line tool. It reads in specifications from plain-language text files called features, examines them for scenarios to test, and runs the scenarios against the system. The feature files should be written according to specific syntax rules called Gherkin. Along with the features, you give Cucumber a set of step definitions, which map the business-readable language of each step into Ruby code to carry out whatever action is being described by the step. Cucumber takes customer understandable user stories as input and does integration and acceptance tests on the system with those as its input.

===Feature===
A Feature is a high level statement of the what the test case does and there is only one feature per user story. For every feature that is supported by the system , a separate feature file has to be written and included in the features directory. The feature files has .feature file extension.

===Scenario===
A Scenario consists of one or more steps which describe about the various actions performed by the user with respect to this particular feature. There can be one or more scenarios per feature in a user story. A feature usually contains 3 to 8 steps in it. The steps of the scenario always begin with one of the below mentioned key words :

1. Given : Steps that begin with given represent the state of the world before an event.(preconditions) 
2. When : Steps that represent the event. 
3. Then : Steps that represent the expected outcome. 
4. And and But : Steps that extend the previous step. 

===Step and Step Definitions===
When testing with Cucumber , The user stories are all kept in one set of files called Steps.The Steps are compared with Step Definitions which are files written in ruby which gives the rules based on which the steps are executed. Step definitions are analogous to method definitions and steps of scenarios are analogous to method calls. Cucumber uses regular expressions to match the English phrases in the steps of scenarios to step definitions.

When the cucumber test framework is run , The steps present in the feature file can be classified as follows based on the result of regex matching with the step definitions.<ref>[https://github.com/cucumber/cucumber/wiki/Step-Definitions Step Definitions in Ruby]</ref>

====Successful steps====
When Cucumber finds a matching Step Definition it will execute it. If the block in the step definition doesn’t raise an Exception, the step is marked as successful (green). What you return from a Step Definition has no significance what so ever.

====Undefined steps====
When Cucumber can’t find a matching Step Definition the step gets marked as yellow, and all subsequent steps in the scenario are skipped. If you use --strict this will cause Cucumber to exit with 1.

====Pending steps====
When a Step Definition’s Proc invokes the #pending method, the step is marked as yellow (as with undefined ones), reminding you that you have work to do. If you use --strict this will cause Cucumber to exit with 1.

====Failed steps====
When a Step Definition’s Proc is executed and raises an error, the step is marked as red. Returning nil or false will not cause a step definition to fail.

Cucumber tries to run the steps based on the definitions and thus colors steps based on the execution of the steps. The colors for the steps assigned are as follows : 
 
1. Green : for passing. 
2. Yellow : for not yet implemented. 
3. Red : for failing. 
4. Blue : Once a step fails all the successive steps are marked in blue. 

==Cucumber Testing Stack==
/* Some Content */

[[File:Cucumber.JPG|500px|thumb|right|Cucumber Testing Stack]]

==Advantages of Cucumber==
*Specifications can be written in more than forty different spoken languages.
*Cucumber helps reduce the gap between technical and non-technical members of a software team.
*Cucumber tests can be easily read and written by business stakeholders.
*Writing Cucumber tests are quick, easy, efficient and understandable.

=Cucumber Installation=
<ref>[http://cuke4ninja.com/sec_ruby_install_cucumber.html Installing Cucumber]</ref>

To install cucumber we should make sure that the Environment path is set to “..../Ruby/bin”. Then open the command prompt and run

gem install cucumber

Once cucumber gem is installed then we would be able to check whether it is installed by issuing the following command:

cucumber --version

this should give a version number like “1.2.1”

Cucumber uses Rspec for assertions and hence we need Rspec installed to use Cucumber. Use the following command to install rspec

gem install rspec

=Testing a Sample Ruby Application using Cucumber=
<ref>[http://pragprog.com/book/hwcuc/the-cucumber-book Sample Cucumber Application]</ref>

Step 1 : Create a new directory

mkdir HelloCucumber

Step 2 : Install Cucumber and Rspec

gem install cucumber
gem instal rspec

Step 3 : Create a directory features and create a file basic.feature in the features directory

mkdir features

Content of features/basic.feature

Feature: Hello World Feature 
Scenario: Hello World Scenario
Given The Action is Hello
When The Subject is World
Then The Greeting is Hello, World

Step 4: Create step_definitions directory inside features directory. Create basic_step.rb file inside step_definitions.

mkdir features/step_definitions

Content of features/step_definitions/basic_step.rb

require 'rspec/expectations' 
Given /The Action is ([A-z]*)/ do |action|
@action = action
end 
When /The Subject is ([A-z]*)/ do |subject|
@subject = subject
end 
Then /The Greeting is (.*)/ do |greeting|
greeting.should == "#{@action}, #{@subject}"
end
Cucumber uses regular expression after the keywords Given, When and Then to map lines in a feature file to step definitions.

Step 5: Running cucumber command you will see the following output

Feature: Hello World Feature 
Scenario: Hello World Scenario # features\basic.feature:3
Given The Action is Hello # features/step_definitions/basic_steps.rb:3
When The Subject is World # features/step_definitions/basic_steps.rb:7
Then The Greeting is Hello, World # features/step_definitions/basic_steps.rb:11 

1 scenario (1 passed)
3 steps (3 passed)
0m0.016s
Step 6 : Modify the basic.features file to include 2 scenario

Step 6 : Modify the basic.features file to include 2 scenarios

Feature: Hello World Feature 
Scenario: Hello World Scenario
Given The Action is Hello
When The Subject is World
Then The Greeting is Hello, World 
Scenario: Bye World Scenario
Given The Action is Bye
When The Subject is World
Then The Greeting is Hello, World

Step 7 : Running the cucumber command you will see the following output

Scenario: Hello World Scenario # features\basic.feature:3
Given The Action is Hello # features/step_definitions/basic_steps.rb:3
When The Subject is World # features/step_definitions/basic_steps.rb:7
Then The Greeting is Hello, World # features/step_definitions/basic_steps.rb:11 
Scenario: Bye World Scenario # features\basic.feature:8
Given The Action is Bye # features/step_definitions/basic_steps.rb:3
When The Subject is World # features/step_definitions/basic_steps.rb:7
Then The Greeting is Hello, World # features/step_definitions/basic_steps.rb:11
expected: "Bye, World"
got: "Hello, World" (using ==) (RSpec::Expectations::ExpectationNotMetError)
./features/step_definitions/basic_steps.rb:12:in `/The Greeting is (.*)/'
features\basic.feature:11:in `Then The Greeting is Hello, World' 
Failing Scenarios:
cucumber features\basic.feature:8 # Scenario: Bye World Scenario 
2 scenarios (1 failed, 1 passed)
6 steps (1 failed, 5 passed)
0m0.033s

The Bye Scenario fails since the expected output is “Hello, World” but the received output is “Bye,World”.

=Testing a Sample Rails Application using Cucumber=
<ref>[http://railscasts.com/episodes/155-beginning-with-cucumber Sample Cucumber Application on Rails]</ref>

Cucumber easily integrates with Rails and hence can be used with Ruby applications which run on Rails. But there are a few steps which have to be followed before integrating cucumber with Rails. Lets walk through it by creating a new rails application.

rails new cucumber_app

Install the required cucumber gems
 
gem install cucumber
gem install cucumber cucumber-rails

Add the following lines to your gemfile. These gems are required only for the test environment. The gems database_cleaner , rspec-rails and webrat are required for cucumber to function properly.
 
group :test do
gem 'database_cleaner'
gem 'cucumber'
gem "rspec-rails", "~> 2.0", :require => false
gem "cucumber-rails", "1.0.6"
gem 'webrat'
end

After modifying the gem file, run bundle update

bundle update

The required cucumber files are generated using the following command. The output below the command shows the folders and files that gets created for the cucumber test framework.

rails generate cucumber:install
 
identical script/cucumber
chmod script/cucumber
exist features/step_definitions
identical features/step_definitions/web_steps.rb
exist features/support
identical features/support/paths.rb
identical features/support/selectors.rb
identical features/support/env.rb
exist lib/tasks
identical lib/tasks/cucumber.rake
 
The Step definitions folder contains ruby files which test the steps which are mentioned in feature file of the cucumber.
 
The paths.rb file is created in the support folder will contain the rules based on which the step definitions will be compared to the steps and matched. In case we come across any steps whose execution fails while running cucumber we would have to update the paths.rb file to resolve the issue.
 
env.rb is only loaded when the application is first started up and it sets up the environment required by Cucumber to execute.
 
rails generate model article title:string content:text
rake db:migrate
rake db:test:clone
rails generate controller articles index
 
The above four commands generate models with the name article and with two fields title and content
and the next two commands migrate the db to production and the last commands creates controller for article and index objects.
 
We have to go the home directory of our rails application and then run Cucumber with the following command.The result would then be shown to the user on how many and which steps succeeded and failed.

=> cucumber
===Capybara===
<ref>[http://net.tutsplus.com/tutorials/ruby/ruby-for-newbies-testing-web-apps-with-capybara-and-cucumber Web-app with Cucumber and Capybara]</ref>

We need a tool that acts out the user stories that are part of the feature that is to be tested with Cucumber. Capybara can be used as that tool. Capybara is an integration testing tool for rack based web based applications. It simulates how a user would interact with a website. It can simulate the actions of a web browser and hence can interact with the application to receive web pages. It can also parse the HTML content and submits forms as the user would. One of the restrictions that Capybara has is that it cannot handle JavaScript. There are other tools like webdriver which can handle JavaScript but it runs a lot slower compared to Capybara.

=Comparison of Unit Test Frameworks : Rspec, Shoulda and Cucumber=

{|border="2" cellpadding="5" cellspacing="0" align="center"
|-
! scope="col" | Rspec
! scope="col" | Shoulda
! scope="col" | Cucumber

|-
|RSpec is based on the Behaviour driven development model provided by Ruby. It has its origins in Test Driven Development and Domain Driven Design.
|Shoulda is based on the Test:Unit which is another Ruby Test Framework. It is based on Test Driven Development.
|Cucumber is a combination of Test Driven Development and Behaviour driven development.
|-
|RSpec provides a Domain Specific Language that can express code functionality and behaviour.
|Shoulda provides macros, helpers and matchers.
|Cucumber allows the test cases to be written in native languages
|-
|RSpec too allows nested describe structure.
|Shoulda has nested contexts which helps create different environment for different set of tests.
|Cucumber is similar to RSpec and provides nested structures
|-
|RSpec is expressive when it comes to understanding functionalities since they were designed have the human readability in mind.
|Shoulda has more descriptive names compared to its predecessor Test::Unit but its less expressive.
|Cucumber test are even more descriptive and allows business stakeholder to write and read them.

|}

=Reference=
<references/>

CSC/ECE 517 Fall 2012/ch1 1w3 pl

2012-09-14T21:16:50Z

Pvasude: /* Comparison of Unit Test Frameworks : Rspec, Shoulda and Cucumber */

='''Unit-Testing Frameworks for Ruby: Cucumber'''=

This wiki-page serves as a knowledge source for understanding Unit-Testing Frameworks available for Ruby particularly Cucumber . 

__TOC__

=Introduction=

Unit testing is a software development process for testing individual units of source code independently for proper operation <ref>[http://en.wikipedia.org/wiki/Unit_testing Unit Testing]</ref>. An unit testing framework helps the process of unit testing by automating the test cases written to ensure the correctness of the system. They are often third-party products that are not offered as part of the suite.Ruby provides a framework in its standard library for setting up, organizing, and running tests called Test::Unit <ref>[http://en.wikibooks.org/wiki/Ruby_Programming/Unit_testing Ruby Unit Testing Framework]</ref>. Other testing frameworks available for ruby are Shoulda, RSpec and Cucumber.

=Cucumber=
Cucumber is one of the latest unit test frameworks to have come for Ruby as part of the RSpec family of tools. Cucumber itself is written in the Ruby programming language and adheres to Behaviour Driven Development(BDD). Behaviour Driven Development is an Agile Development process that comprises aspects of Acceptance Test Driven Planning , Domain Driven Design and Test Driven Development (TDD). Cucumber is designed specifically to ensure that the acceptance tests can easily be read and written by anyone.

==Behaviour Driven Development(BDD)==

Behaviour Driven Development<ref>[http://en.wikipedia.org/wiki/Behavior-driven_development BDD]</ref> preserves the basic iterative (fail-pass) workflow of TDD, but stresses on specifying behaviors that are understandable to people (say from non programming background). In this approach we write tests in a natural language that even a non-programmer can understand.

==Acceptance Test==

Acceptance Test<ref>[http://en.wikipedia.org/wiki/Acceptance_testing Acceptance Test]</ref><ref>[http://pragprog.com/book/hwcuc/the-cucumber-book Cucumber Book]</ref> Drive Planning is a practice that stresses on the importance of identifying the functions and requirements of the software beforehand so that we exactly know when the development phase ends. This practice results in fewer bugs , shorter delivery times and greater customer satisfaction.

===Cucumber Acceptance Test===

Feature: Sign up
Sign up should be quick and friendly. 
Scenario: Successful sign up
New users should get a confirmation email and be greeted personally by the site once signed in.
Given I have chosen to sign up
When I sign up with valid details
Then I should receive a confirmation email
And I should see a personalized greeting message 
Scenario: Duplicate email
Where someone tries to create an account for an email address that already exists.
Given I have chosen to sign up
But I enter an email address that has already registered
Then I should be told that the email is already registered
And I should be offered the option to recover my password

Acceptance tests written in this style are more than just tests; they are executable specifications. As of January 2012, Cucumber was the second most popular testing framework after RSpec for Ruby

==How Cucumber works==

Cucumber is a command-line tool. It reads in specifications from plain-language text files called features, examines them for scenarios to test, and runs the scenarios against the system. The feature files should be written according to specific syntax rules called Gherkin. Along with the features, you give Cucumber a set of step definitions, which map the business-readable language of each step into Ruby code to carry out whatever action is being described by the step. Cucumber takes customer understandable user stories as input and does integration and acceptance tests on the system with those as its input.

===Feature===
A Feature is a high level statement of the what the test case does and there is only one feature per user story. For every feature that is supported by the system , a separate feature file has to be written and included in the features directory. The feature files has .feature file extension.

===Scenario===
A Scenario consists of one or more steps which describe about the various actions performed by the user with respect to this particular feature. There can be one or more scenarios per feature in a user story. A feature usually contains 3 to 8 steps in it. The steps of the scenario always begin with one of the below mentioned key words :

1. Given : Steps that begin with given represent the state of the world before an event.(preconditions) 
2. When : Steps that represent the event. 
3. Then : Steps that represent the expected outcome. 
4. And and But : Steps that extend the previous step. 

===Step and Step Definitions===
When testing with Cucumber , The user stories are all kept in one set of files called Steps.The Steps are compared with Step Definitions which are files written in ruby which gives the rules based on which the steps are executed. Step definitions are analogous to method definitions and steps of scenarios are analogous to method calls. Cucumber uses regular expressions to match the English phrases in the steps of scenarios to step definitions.

When the cucumber test framework is run , The steps present in the feature file can be classified as follows based on the result of regex matching with the step definitions.<ref>[https://github.com/cucumber/cucumber/wiki/Step-Definitions Step Definitions in Ruby]</ref>

====Successful steps====
When Cucumber finds a matching Step Definition it will execute it. If the block in the step definition doesn’t raise an Exception, the step is marked as successful (green). What you return from a Step Definition has no significance what so ever.

====Undefined steps====
When Cucumber can’t find a matching Step Definition the step gets marked as yellow, and all subsequent steps in the scenario are skipped. If you use --strict this will cause Cucumber to exit with 1.

====Pending steps====
When a Step Definition’s Proc invokes the #pending method, the step is marked as yellow (as with undefined ones), reminding you that you have work to do. If you use --strict this will cause Cucumber to exit with 1.

====Failed steps====
When a Step Definition’s Proc is executed and raises an error, the step is marked as red. Returning nil or false will not cause a step definition to fail.

Cucumber tries to run the steps based on the definitions and thus colors steps based on the execution of the steps. The colors for the steps assigned are as follows : 
 
1. Green : for passing. 
2. Yellow : for not yet implemented. 
3. Red : for failing. 
4. Blue : Once a step fails all the successive steps are marked in blue. 

==Cucumber Testing Stack==
/* Some Content */

[[File:Cucumber.JPG|500px|thumb|right|Cucumber Testing Stack]]

==Advantages of Cucumber==
*Specifications can be written in more than forty different spoken languages.
*Cucumber helps reduce the gap between technical and non-technical members of a software team.
*Cucumber tests can be easily read and written by business stakeholders.
*Writing Cucumber tests are quick, easy, efficient and understandable.

=Cucumber Installation=
<ref>[http://cuke4ninja.com/sec_ruby_install_cucumber.html Installing Cucumber]</ref>

To install cucumber we should make sure that the Environment path is set to “..../Ruby/bin”. Then open the command prompt and run

gem install cucumber

Once cucumber gem is installed then we would be able to check whether it is installed by issuing the following command:

cucumber --version

this should give a version number like “1.2.1”

Cucumber uses Rspec for assertions and hence we need Rspec installed to use Cucumber. Use the following command to install rspec

gem install rspec

=Testing a Sample Ruby Application using Cucumber=
<ref>[http://pragprog.com/book/hwcuc/the-cucumber-book Sample Cucumber Application]</ref>

Step 1 : Create a new directory

mkdir HelloCucumber

Step 2 : Install Cucumber and Rspec

gem install cucumber
gem instal rspec

Step 3 : Create a directory features and create a file basic.feature in the features directory

mkdir features

Content of features/basic.feature

Feature: Hello World Feature 
Scenario: Hello World Scenario
Given The Action is Hello
When The Subject is World
Then The Greeting is Hello, World

Step 4: Create step_definitions directory inside features directory. Create basic_step.rb file inside step_definitions.

mkdir features/step_definitions

Content of features/step_definitions/basic_step.rb

require 'rspec/expectations' 
Given /The Action is ([A-z]*)/ do |action|
@action = action
end 
When /The Subject is ([A-z]*)/ do |subject|
@subject = subject
end 
Then /The Greeting is (.*)/ do |greeting|
greeting.should == "#{@action}, #{@subject}"
end
Cucumber uses regular expression after the keywords Given, When and Then to map lines in a feature file to step definitions.

Step 5: Running cucumber command you will see the following output

Feature: Hello World Feature 
Scenario: Hello World Scenario # features\basic.feature:3
Given The Action is Hello # features/step_definitions/basic_steps.rb:3
When The Subject is World # features/step_definitions/basic_steps.rb:7
Then The Greeting is Hello, World # features/step_definitions/basic_steps.rb:11 

1 scenario (1 passed)
3 steps (3 passed)
0m0.016s
Step 6 : Modify the basic.features file to include 2 scenario

Step 6 : Modify the basic.features file to include 2 scenarios

Feature: Hello World Feature 
Scenario: Hello World Scenario
Given The Action is Hello
When The Subject is World
Then The Greeting is Hello, World 
Scenario: Bye World Scenario
Given The Action is Bye
When The Subject is World
Then The Greeting is Hello, World

Step 7 : Running the cucumber command you will see the following output

Scenario: Hello World Scenario # features\basic.feature:3
Given The Action is Hello # features/step_definitions/basic_steps.rb:3
When The Subject is World # features/step_definitions/basic_steps.rb:7
Then The Greeting is Hello, World # features/step_definitions/basic_steps.rb:11 
Scenario: Bye World Scenario # features\basic.feature:8
Given The Action is Bye # features/step_definitions/basic_steps.rb:3
When The Subject is World # features/step_definitions/basic_steps.rb:7
Then The Greeting is Hello, World # features/step_definitions/basic_steps.rb:11
expected: "Bye, World"
got: "Hello, World" (using ==) (RSpec::Expectations::ExpectationNotMetError)
./features/step_definitions/basic_steps.rb:12:in `/The Greeting is (.*)/'
features\basic.feature:11:in `Then The Greeting is Hello, World' 
Failing Scenarios:
cucumber features\basic.feature:8 # Scenario: Bye World Scenario 
2 scenarios (1 failed, 1 passed)
6 steps (1 failed, 5 passed)
0m0.033s

The Bye Scenario fails since the expected output is “Hello, World” but the received output is “Bye,World”.

=Testing a Sample Rails Application using Cucumber=
<ref>[http://railscasts.com/episodes/155-beginning-with-cucumber Sample Cucumber Application on Rails]</ref>

Cucumber easily integrates with Rails and hence can be used with Ruby applications which run on Rails. But there are a few steps which have to be followed before integrating cucumber with Rails. Lets walk through it by creating a new rails application.

rails new cucumber_app

Install the required cucumber gems
 
gem install cucumber
gem install cucumber cucumber-rails

Add the following lines to your gemfile. These gems are required only for the test environment. The gems database_cleaner , rspec-rails and webrat are required for cucumber to function properly.
 
group :test do
gem 'database_cleaner'
gem 'cucumber'
gem "rspec-rails", "~> 2.0", :require => false
gem "cucumber-rails", "1.0.6"
gem 'webrat'
end

After modifying the gem file, run bundle update

bundle update

The required cucumber files are generated using the following command. The output below the command shows the folders and files that gets created for the cucumber test framework.

rails generate cucumber:install
 
identical script/cucumber
chmod script/cucumber
exist features/step_definitions
identical features/step_definitions/web_steps.rb
exist features/support
identical features/support/paths.rb
identical features/support/selectors.rb
identical features/support/env.rb
exist lib/tasks
identical lib/tasks/cucumber.rake
 
The Step definitions folder contains ruby files which test the steps which are mentioned in feature file of the cucumber.
 
The paths.rb file is created in the support folder will contain the rules based on which the step definitions will be compared to the steps and matched. In case we come across any steps whose execution fails while running cucumber we would have to update the paths.rb file to resolve the issue.
 
env.rb is only loaded when the application is first started up and it sets up the environment required by Cucumber to execute.
 
rails generate model article title:string content:text
rake db:migrate
rake db:test:clone
rails generate controller articles index
 
The above four commands generate models with the name article and with two fields title and content
and the next two commands migrate the db to production and the last commands creates controller for article and index objects.
 
We have to go the home directory of our rails application and then run Cucumber with the following command.The result would then be shown to the user on how many and which steps succeeded and failed.

=> cucumber
===Capybara===
<ref>[http://net.tutsplus.com/tutorials/ruby/ruby-for-newbies-testing-web-apps-with-capybara-and-cucumber Web-app with Cucumber and Capybara]</ref>

We need a tool that acts out the user stories that are part of the feature that is to be tested with Cucumber. Capybara can be used as that tool. Capybara is an integration testing tool for rack based web based applications. It simulates how a user would interact with a website. It can simulate the actions of a web browser and hence can interact with the application to receive web pages. It can also parse the HTML content and submits forms as the user would. One of the restrictions that Capybara has is that it cannot handle JavaScript. There are other tools like webdriver which can handle JavaScript but it runs a lot slower compared to Capybara.

=Comparison of Unit Test Frameworks : Rspec, Shoulda and Cucumber=

{|border="2" cellpadding="5" cellspacing="0" align="center"
|-
! scope="col" | Rspec
! scope="col" | Shoulda
! scope="col" | Cucumber

|-
|RSpec is based on the Behaviour driven development model provided by Ruby. It has its origins in Test Driven Development and Domain Driven Design.
|Shoulda is based on the Test:Unit which is another Ruby Test Framework. It is based on Test Driven Development.
|Cucumber is a combination of Test Driven Development and Behaviour driven development.
|-
|RSpec provides a Domain Specific Language that can express code functionality and behaviour.
|Shoulda provides macros, helpers and matchers.
|Cucumber allows the test cases to be written in native languages
|-
|RSpec too allows nested describe structure.
|Shoulda has nested contexts which helps create different environment for different set of tests.
|Cucumber is similar to RSpec also provides nested structures
|-
|RSpec is expressive when it comes to understanding functionalities since they were designed have the human readability in mind.
|Shoulda has more descriptive names compared to its predecessor Test::Unit but its less expressive.
|Cucumber test are even more descriptive and allows business stakeholder to write and read them.

|}

=Reference=
<references/>

CSC/ECE 517 Fall 2012/ch1 1w3 pl

2012-09-14T21:06:39Z

Pvasude: /* Testing a Sample Rails Application using Cucumber */

='''Unit-Testing Frameworks for Ruby: Cucumber'''=

This wiki-page serves as a knowledge source for understanding Unit-Testing Frameworks available for Ruby particularly Cucumber . 

__TOC__

=Introduction=

Unit testing is a software development process for testing individual units of source code independently for proper operation <ref>[http://en.wikipedia.org/wiki/Unit_testing Unit Testing]</ref>. An unit testing framework helps the process of unit testing by automating the test cases written to ensure the correctness of the system. They are often third-party products that are not offered as part of the suite.Ruby provides a framework in its standard library for setting up, organizing, and running tests called Test::Unit <ref>[http://en.wikibooks.org/wiki/Ruby_Programming/Unit_testing Ruby Unit Testing Framework]</ref>. Other testing frameworks available for ruby are Shoulda, RSpec and Cucumber.

=Cucumber=
Cucumber is one of the latest unit test frameworks to have come for Ruby as part of the RSpec family of tools. Cucumber itself is written in the Ruby programming language and adheres to Behaviour Driven Development(BDD). Behaviour Driven Development is an Agile Development process that comprises aspects of Acceptance Test Driven Planning , Domain Driven Design and Test Driven Development (TDD). Cucumber is designed specifically to ensure that the acceptance tests can easily be read and written by anyone.

==Behaviour Driven Development(BDD)==

Behaviour Driven Development<ref>[http://en.wikipedia.org/wiki/Behavior-driven_development BDD]</ref> preserves the basic iterative (fail-pass) workflow of TDD, but stresses on specifying behaviors that are understandable to people (say from non programming background). In this approach we write tests in a natural language that even a non-programmer can understand.

==Acceptance Test==

Acceptance Test<ref>[http://en.wikipedia.org/wiki/Acceptance_testing Acceptance Test]</ref><ref>[http://pragprog.com/book/hwcuc/the-cucumber-book Cucumber Book]</ref> Drive Planning is a practice that stresses on the importance of identifying the functions and requirements of the software beforehand so that we exactly know when the development phase ends. This practice results in fewer bugs , shorter delivery times and greater customer satisfaction.

===Cucumber Acceptance Test===

Feature: Sign up
Sign up should be quick and friendly. 
Scenario: Successful sign up
New users should get a confirmation email and be greeted personally by the site once signed in.
Given I have chosen to sign up
When I sign up with valid details
Then I should receive a confirmation email
And I should see a personalized greeting message 
Scenario: Duplicate email
Where someone tries to create an account for an email address that already exists.
Given I have chosen to sign up
But I enter an email address that has already registered
Then I should be told that the email is already registered
And I should be offered the option to recover my password

Acceptance tests written in this style are more than just tests; they are executable specifications. As of January 2012, Cucumber was the second most popular testing framework after RSpec for Ruby

==How Cucumber works==

Cucumber is a command-line tool. It reads in specifications from plain-language text files called features, examines them for scenarios to test, and runs the scenarios against the system. The feature files should be written according to specific syntax rules called Gherkin. Along with the features, you give Cucumber a set of step definitions, which map the business-readable language of each step into Ruby code to carry out whatever action is being described by the step. Cucumber takes customer understandable user stories as input and does integration and acceptance tests on the system with those as its input.

===Feature===
A Feature is a high level statement of the what the test case does and there is only one feature per user story. For every feature that is supported by the system , a separate feature file has to be written and included in the features directory. The feature files has .feature file extension.

===Scenario===
A Scenario consists of one or more steps which describe about the various actions performed by the user with respect to this particular feature. There can be one or more scenarios per feature in a user story. A feature usually contains 3 to 8 steps in it. The steps of the scenario always begin with one of the below mentioned key words :

1. Given : Steps that begin with given represent the state of the world before an event.(preconditions) 
2. When : Steps that represent the event. 
3. Then : Steps that represent the expected outcome. 
4. And and But : Steps that extend the previous step. 

===Step and Step Definitions===
When testing with Cucumber , The user stories are all kept in one set of files called Steps.The Steps are compared with Step Definitions which are files written in ruby which gives the rules based on which the steps are executed. Step definitions are analogous to method definitions and steps of scenarios are analogous to method calls. Cucumber uses regular expressions to match the English phrases in the steps of scenarios to step definitions.

When the cucumber test framework is run , The steps present in the feature file can be classified as follows based on the result of regex matching with the step definitions.<ref>[https://github.com/cucumber/cucumber/wiki/Step-Definitions Step Definitions in Ruby]</ref>

====Successful steps====
When Cucumber finds a matching Step Definition it will execute it. If the block in the step definition doesn’t raise an Exception, the step is marked as successful (green). What you return from a Step Definition has no significance what so ever.

====Undefined steps====
When Cucumber can’t find a matching Step Definition the step gets marked as yellow, and all subsequent steps in the scenario are skipped. If you use --strict this will cause Cucumber to exit with 1.

====Pending steps====
When a Step Definition’s Proc invokes the #pending method, the step is marked as yellow (as with undefined ones), reminding you that you have work to do. If you use --strict this will cause Cucumber to exit with 1.

====Failed steps====
When a Step Definition’s Proc is executed and raises an error, the step is marked as red. Returning nil or false will not cause a step definition to fail.

Cucumber tries to run the steps based on the definitions and thus colors steps based on the execution of the steps. The colors for the steps assigned are as follows : 
 
1. Green : for passing. 
2. Yellow : for not yet implemented. 
3. Red : for failing. 
4. Blue : Once a step fails all the successive steps are marked in blue. 

==Cucumber Testing Stack==
/* Some Content */

[[File:Cucumber.JPG|500px|thumb|right|Cucumber Testing Stack]]

==Advantages of Cucumber==
*Specifications can be written in more than forty different spoken languages.
*Cucumber helps reduce the gap between technical and non-technical members of a software team.
*Cucumber tests can be easily read and written by business stakeholders.
*Writing Cucumber tests are quick, easy, efficient and understandable.

=Cucumber Installation=
<ref>[http://cuke4ninja.com/sec_ruby_install_cucumber.html Installing Cucumber]</ref>

To install cucumber we should make sure that the Environment path is set to “..../Ruby/bin”. Then open the command prompt and run

gem install cucumber

Once cucumber gem is installed then we would be able to check whether it is installed by issuing the following command:

cucumber --version

this should give a version number like “1.2.1”

Cucumber uses Rspec for assertions and hence we need Rspec installed to use Cucumber. Use the following command to install rspec

gem install rspec

=Testing a Sample Ruby Application using Cucumber=
<ref>[http://pragprog.com/book/hwcuc/the-cucumber-book Sample Cucumber Application]</ref>

Step 1 : Create a new directory

mkdir HelloCucumber

Step 2 : Install Cucumber and Rspec

gem install cucumber
gem instal rspec

Step 3 : Create a directory features and create a file basic.feature in the features directory

mkdir features

Content of features/basic.feature

Feature: Hello World Feature 
Scenario: Hello World Scenario
Given The Action is Hello
When The Subject is World
Then The Greeting is Hello, World

Step 4: Create step_definitions directory inside features directory. Create basic_step.rb file inside step_definitions.

mkdir features/step_definitions

Content of features/step_definitions/basic_step.rb

require 'rspec/expectations' 
Given /The Action is ([A-z]*)/ do |action|
@action = action
end 
When /The Subject is ([A-z]*)/ do |subject|
@subject = subject
end 
Then /The Greeting is (.*)/ do |greeting|
greeting.should == "#{@action}, #{@subject}"
end
Cucumber uses regular expression after the keywords Given, When and Then to map lines in a feature file to step definitions.

Step 5: Running cucumber command you will see the following output

Feature: Hello World Feature 
Scenario: Hello World Scenario # features\basic.feature:3
Given The Action is Hello # features/step_definitions/basic_steps.rb:3
When The Subject is World # features/step_definitions/basic_steps.rb:7
Then The Greeting is Hello, World # features/step_definitions/basic_steps.rb:11 

1 scenario (1 passed)
3 steps (3 passed)
0m0.016s
Step 6 : Modify the basic.features file to include 2 scenario

Step 6 : Modify the basic.features file to include 2 scenarios

Feature: Hello World Feature 
Scenario: Hello World Scenario
Given The Action is Hello
When The Subject is World
Then The Greeting is Hello, World 
Scenario: Bye World Scenario
Given The Action is Bye
When The Subject is World
Then The Greeting is Hello, World

Step 7 : Running the cucumber command you will see the following output

Scenario: Hello World Scenario # features\basic.feature:3
Given The Action is Hello # features/step_definitions/basic_steps.rb:3
When The Subject is World # features/step_definitions/basic_steps.rb:7
Then The Greeting is Hello, World # features/step_definitions/basic_steps.rb:11 
Scenario: Bye World Scenario # features\basic.feature:8
Given The Action is Bye # features/step_definitions/basic_steps.rb:3
When The Subject is World # features/step_definitions/basic_steps.rb:7
Then The Greeting is Hello, World # features/step_definitions/basic_steps.rb:11
expected: "Bye, World"
got: "Hello, World" (using ==) (RSpec::Expectations::ExpectationNotMetError)
./features/step_definitions/basic_steps.rb:12:in `/The Greeting is (.*)/'
features\basic.feature:11:in `Then The Greeting is Hello, World' 
Failing Scenarios:
cucumber features\basic.feature:8 # Scenario: Bye World Scenario 
2 scenarios (1 failed, 1 passed)
6 steps (1 failed, 5 passed)
0m0.033s

The Bye Scenario fails since the expected output is “Hello, World” but the received output is “Bye,World”.

=Testing a Sample Rails Application using Cucumber=
<ref>[http://railscasts.com/episodes/155-beginning-with-cucumber Sample Cucumber Application on Rails]</ref>

Cucumber easily integrates with Rails and hence can be used with Ruby applications which run on Rails. But there are a few steps which have to be followed before integrating cucumber with Rails. Lets walk through it by creating a new rails application.

rails new cucumber_app

Install the required cucumber gems
 
gem install cucumber
gem install cucumber cucumber-rails

Add the following lines to your gemfile. These gems are required only for the test environment. The gems database_cleaner , rspec-rails and webrat are required for cucumber to function properly.
 
group :test do
gem 'database_cleaner'
gem 'cucumber'
gem "rspec-rails", "~> 2.0", :require => false
gem "cucumber-rails", "1.0.6"
gem 'webrat'
end

After modifying the gem file, run bundle update

bundle update

The required cucumber files are generated using the following command. The output below the command shows the folders and files that gets created for the cucumber test framework.

rails generate cucumber:install
 
identical script/cucumber
chmod script/cucumber
exist features/step_definitions
identical features/step_definitions/web_steps.rb
exist features/support
identical features/support/paths.rb
identical features/support/selectors.rb
identical features/support/env.rb
exist lib/tasks
identical lib/tasks/cucumber.rake
 
The Step definitions folder contains ruby files which test the steps which are mentioned in feature file of the cucumber.
 
The paths.rb file is created in the support folder will contain the rules based on which the step definitions will be compared to the steps and matched. In case we come across any steps whose execution fails while running cucumber we would have to update the paths.rb file to resolve the issue.
 
env.rb is only loaded when the application is first started up and it sets up the environment required by Cucumber to execute.
 
rails generate model article title:string content:text
rake db:migrate
rake db:test:clone
rails generate controller articles index
 
The above four commands generate models with the name article and with two fields title and content
and the next two commands migrate the db to production and the last commands creates controller for article and index objects.
 
We have to go the home directory of our rails application and then run Cucumber with the following command.The result would then be shown to the user on how many and which steps succeeded and failed.

=> cucumber
===Capybara===
<ref>[http://net.tutsplus.com/tutorials/ruby/ruby-for-newbies-testing-web-apps-with-capybara-and-cucumber Web-app with Cucumber and Capybara]</ref>

We need a tool that acts out the user stories that are part of the feature that is to be tested with Cucumber. Capybara can be used as that tool. Capybara is an integration testing tool for rack based web based applications. It simulates how a user would interact with a website. It can simulate the actions of a web browser and hence can interact with the application to receive web pages. It can also parse the HTML content and submits forms as the user would. One of the restrictions that Capybara has is that it cannot handle JavaScript. There are other tools like webdriver which can handle JavaScript but it runs a lot slower compared to Capybara.

=Comparison of Unit Test Frameworks : Rspec, Shoulda and Cucumber=

{|border="2" cellpadding="5" cellspacing="0" align="center"
|-
! scope="col" | Rspec
! scope="col" | Shoulda
! scope="col" | Cucumber

|-
|RSpec is based on the Behaviour driven development model provided by Ruby. It has its origins in Test Driven Development and Domain Driven Design.
|Shoulda is based on the Test:Unit which is another Ruby Test Framework. It is based on Test Driven Development.
|Cucumber is a combination of Test Driven Development and Behaviour driven development.
|-
|RSpec provides a Domain Specific Language that can express code functionality and behaviour.
|Shoulda provides macros, helpers and matchers.
|Cucumber allows the test cases to be written in native language of the system
|-
|RSpec too allows nested describe structure.
|Shoulda has nested contexts which helps create different environment for different set of tests.
|Cucumber is similar to RSpec also provides nested structures
|-
|RSpec is expressive when it comes to understanding functionalities since they were designed have the human readability in mind.
|Shoulda has more descriptive names compared to its predecessor Test::Unit but its less expressive.
|Cucumber test are even more descriptive and allows business stakeholder to write and read them.

|}

=Reference=
<references/>

CSC/ECE 517 Fall 2012/ch1 1w3 pl

2012-09-14T21:05:11Z

Pvasude: /* Testing a Sample Rails Application using Cucumber */

='''Unit-Testing Frameworks for Ruby: Cucumber'''=

This wiki-page serves as a knowledge source for understanding Unit-Testing Frameworks available for Ruby particularly Cucumber . 

__TOC__

=Introduction=

Unit testing is a software development process for testing individual units of source code independently for proper operation <ref>[http://en.wikipedia.org/wiki/Unit_testing Unit Testing]</ref>. An unit testing framework helps the process of unit testing by automating the test cases written to ensure the correctness of the system. They are often third-party products that are not offered as part of the suite.Ruby provides a framework in its standard library for setting up, organizing, and running tests called Test::Unit <ref>[http://en.wikibooks.org/wiki/Ruby_Programming/Unit_testing Ruby Unit Testing Framework]</ref>. Other testing frameworks available for ruby are Shoulda, RSpec and Cucumber.

=Cucumber=
Cucumber is one of the latest unit test frameworks to have come for Ruby as part of the RSpec family of tools. Cucumber itself is written in the Ruby programming language and adheres to Behaviour Driven Development(BDD). Behaviour Driven Development is an Agile Development process that comprises aspects of Acceptance Test Driven Planning , Domain Driven Design and Test Driven Development (TDD). Cucumber is designed specifically to ensure that the acceptance tests can easily be read and written by anyone.

==Behaviour Driven Development(BDD)==

Behaviour Driven Development<ref>[http://en.wikipedia.org/wiki/Behavior-driven_development BDD]</ref> preserves the basic iterative (fail-pass) workflow of TDD, but stresses on specifying behaviors that are understandable to people (say from non programming background). In this approach we write tests in a natural language that even a non-programmer can understand.

==Acceptance Test==

Acceptance Test<ref>[http://en.wikipedia.org/wiki/Acceptance_testing Acceptance Test]</ref><ref>[http://pragprog.com/book/hwcuc/the-cucumber-book Cucumber Book]</ref> Drive Planning is a practice that stresses on the importance of identifying the functions and requirements of the software beforehand so that we exactly know when the development phase ends. This practice results in fewer bugs , shorter delivery times and greater customer satisfaction.

===Cucumber Acceptance Test===

Feature: Sign up
Sign up should be quick and friendly. 
Scenario: Successful sign up
New users should get a confirmation email and be greeted personally by the site once signed in.
Given I have chosen to sign up
When I sign up with valid details
Then I should receive a confirmation email
And I should see a personalized greeting message 
Scenario: Duplicate email
Where someone tries to create an account for an email address that already exists.
Given I have chosen to sign up
But I enter an email address that has already registered
Then I should be told that the email is already registered
And I should be offered the option to recover my password

Acceptance tests written in this style are more than just tests; they are executable specifications. As of January 2012, Cucumber was the second most popular testing framework after RSpec for Ruby

==How Cucumber works==

Cucumber is a command-line tool. It reads in specifications from plain-language text files called features, examines them for scenarios to test, and runs the scenarios against the system. The feature files should be written according to specific syntax rules called Gherkin. Along with the features, you give Cucumber a set of step definitions, which map the business-readable language of each step into Ruby code to carry out whatever action is being described by the step. Cucumber takes customer understandable user stories as input and does integration and acceptance tests on the system with those as its input.

===Feature===
A Feature is a high level statement of the what the test case does and there is only one feature per user story. For every feature that is supported by the system , a separate feature file has to be written and included in the features directory. The feature files has .feature file extension.

===Scenario===
A Scenario consists of one or more steps which describe about the various actions performed by the user with respect to this particular feature. There can be one or more scenarios per feature in a user story. A feature usually contains 3 to 8 steps in it. The steps of the scenario always begin with one of the below mentioned key words :

1. Given : Steps that begin with given represent the state of the world before an event.(preconditions) 
2. When : Steps that represent the event. 
3. Then : Steps that represent the expected outcome. 
4. And and But : Steps that extend the previous step. 

===Step and Step Definitions===
When testing with Cucumber , The user stories are all kept in one set of files called Steps.The Steps are compared with Step Definitions which are files written in ruby which gives the rules based on which the steps are executed. Step definitions are analogous to method definitions and steps of scenarios are analogous to method calls. Cucumber uses regular expressions to match the English phrases in the steps of scenarios to step definitions.

When the cucumber test framework is run , The steps present in the feature file can be classified as follows based on the result of regex matching with the step definitions.<ref>[https://github.com/cucumber/cucumber/wiki/Step-Definitions Step Definitions in Ruby]</ref>

====Successful steps====
When Cucumber finds a matching Step Definition it will execute it. If the block in the step definition doesn’t raise an Exception, the step is marked as successful (green). What you return from a Step Definition has no significance what so ever.

====Undefined steps====
When Cucumber can’t find a matching Step Definition the step gets marked as yellow, and all subsequent steps in the scenario are skipped. If you use --strict this will cause Cucumber to exit with 1.

====Pending steps====
When a Step Definition’s Proc invokes the #pending method, the step is marked as yellow (as with undefined ones), reminding you that you have work to do. If you use --strict this will cause Cucumber to exit with 1.

====Failed steps====
When a Step Definition’s Proc is executed and raises an error, the step is marked as red. Returning nil or false will not cause a step definition to fail.

Cucumber tries to run the steps based on the definitions and thus colors steps based on the execution of the steps. The colors for the steps assigned are as follows : 
 
1. Green : for passing. 
2. Yellow : for not yet implemented. 
3. Red : for failing. 
4. Blue : Once a step fails all the successive steps are marked in blue. 

==Cucumber Testing Stack==
/* Some Content */

[[File:Cucumber.JPG|500px|thumb|right|Cucumber Testing Stack]]

==Advantages of Cucumber==
*Specifications can be written in more than forty different spoken languages.
*Cucumber helps reduce the gap between technical and non-technical members of a software team.
*Cucumber tests can be easily read and written by business stakeholders.
*Writing Cucumber tests are quick, easy, efficient and understandable.

=Cucumber Installation=
<ref>[http://cuke4ninja.com/sec_ruby_install_cucumber.html Installing Cucumber]</ref>

To install cucumber we should make sure that the Environment path is set to “..../Ruby/bin”. Then open the command prompt and run

gem install cucumber

Once cucumber gem is installed then we would be able to check whether it is installed by issuing the following command:

cucumber --version

this should give a version number like “1.2.1”

Cucumber uses Rspec for assertions and hence we need Rspec installed to use Cucumber. Use the following command to install rspec

gem install rspec

=Testing a Sample Ruby Application using Cucumber=
<ref>[http://pragprog.com/book/hwcuc/the-cucumber-book Sample Cucumber Application]</ref>

Step 1 : Create a new directory

mkdir HelloCucumber

Step 2 : Install Cucumber and Rspec

gem install cucumber
gem instal rspec

Step 3 : Create a directory features and create a file basic.feature in the features directory

mkdir features

Content of features/basic.feature

Feature: Hello World Feature 
Scenario: Hello World Scenario
Given The Action is Hello
When The Subject is World
Then The Greeting is Hello, World

Step 4: Create step_definitions directory inside features directory. Create basic_step.rb file inside step_definitions.

mkdir features/step_definitions

Content of features/step_definitions/basic_step.rb

require 'rspec/expectations' 
Given /The Action is ([A-z]*)/ do |action|
@action = action
end 
When /The Subject is ([A-z]*)/ do |subject|
@subject = subject
end 
Then /The Greeting is (.*)/ do |greeting|
greeting.should == "#{@action}, #{@subject}"
end
Cucumber uses regular expression after the keywords Given, When and Then to map lines in a feature file to step definitions.

Step 5: Running cucumber command you will see the following output

Feature: Hello World Feature 
Scenario: Hello World Scenario # features\basic.feature:3
Given The Action is Hello # features/step_definitions/basic_steps.rb:3
When The Subject is World # features/step_definitions/basic_steps.rb:7
Then The Greeting is Hello, World # features/step_definitions/basic_steps.rb:11 

1 scenario (1 passed)
3 steps (3 passed)
0m0.016s
Step 6 : Modify the basic.features file to include 2 scenario

Step 6 : Modify the basic.features file to include 2 scenarios

Feature: Hello World Feature 
Scenario: Hello World Scenario
Given The Action is Hello
When The Subject is World
Then The Greeting is Hello, World 
Scenario: Bye World Scenario
Given The Action is Bye
When The Subject is World
Then The Greeting is Hello, World

Step 7 : Running the cucumber command you will see the following output

Scenario: Hello World Scenario # features\basic.feature:3
Given The Action is Hello # features/step_definitions/basic_steps.rb:3
When The Subject is World # features/step_definitions/basic_steps.rb:7
Then The Greeting is Hello, World # features/step_definitions/basic_steps.rb:11 
Scenario: Bye World Scenario # features\basic.feature:8
Given The Action is Bye # features/step_definitions/basic_steps.rb:3
When The Subject is World # features/step_definitions/basic_steps.rb:7
Then The Greeting is Hello, World # features/step_definitions/basic_steps.rb:11
expected: "Bye, World"
got: "Hello, World" (using ==) (RSpec::Expectations::ExpectationNotMetError)
./features/step_definitions/basic_steps.rb:12:in `/The Greeting is (.*)/'
features\basic.feature:11:in `Then The Greeting is Hello, World' 
Failing Scenarios:
cucumber features\basic.feature:8 # Scenario: Bye World Scenario 
2 scenarios (1 failed, 1 passed)
6 steps (1 failed, 5 passed)
0m0.033s

The Bye Scenario fails since the expected output is “Hello, World” but the received output is “Bye,World”.

=Testing a Sample Rails Application using Cucumber=
<ref>[http://railscasts.com/episodes/155-beginning-with-cucumber Sample Cucumber Application on Rails]</ref>

Cucumber easily integrates with Rails and hence can be used with Ruby applications which run on Rails. But there are a few steps which have to be followed before integrating cucumber with Rails. Lets walk through it by creating a new rails application.

rails new cucumber_app

Install the required cucumber gems
 
gem install cucumber
gem install cucumber cucumber-rails

Add the following lines to your gemfile. These gems are required only for the test environment. The gems database_cleaner , rspec-rails and webrat are required for cucumber to function properly.
 
group :test do
gem 'database_cleaner'
gem 'cucumber'
gem "rspec-rails", "~> 2.0", :require => false
gem "cucumber-rails", "1.0.6"
gem 'webrat'
end

After modifying the gem file, run bundle update

bundle update

Cucumber required files can then be created by giving the following command. The output below the command shows the folders and files that get created for the cucumber test framework.

rails generate cucumber:install
 
identical script/cucumber
chmod script/cucumber
exist features/step_definitions
identical features/step_definitions/web_steps.rb
exist features/support
identical features/support/paths.rb
identical features/support/selectors.rb
identical features/support/env.rb
exist lib/tasks
identical lib/tasks/cucumber.rake
 
The Step definitions folder contains ruby files which test the steps which are mentioned in feature file of the cucumber.
 
The paths.rb file is created in the support folder will contain the rules based on which the step definitions will be compared to the steps and matched. In case we come across any steps whose execution fails while running cucumber we would have to update the paths.rb file to resolve the issue.
 
env.rb is only loaded when the application is first started up and it sets up the environment required by Cucumber to execute.
 
rails generate model article title:string content:text
rake db:migrate
rake db:test:clone
rails generate controller articles index
 
The above four commands generate models with the name article and with two fields title and content
and the next two commands migrate the db to production and the last commands creates controller for article and index objects.
 
We have to go the home directory of our rails application and then run Cucumber with the following command.The result would then be shown to the user on how many and which steps succeeded and failed.

=> cucumber
===Capybara===
<ref>[http://net.tutsplus.com/tutorials/ruby/ruby-for-newbies-testing-web-apps-with-capybara-and-cucumber Web-app with Cucumber and Capybara]</ref>

We need a tool that acts out the user stories that are part of the feature that is to be tested with Cucumber. Capybara can be used as that tool. Capybara is an integration testing tool for rack based web based applications. It simulates how a user would interact with a website. It can simulate the actions of a web browser and hence can interact with the application to receive web pages. It can also parse the HTML content and submits forms as the user would. One of the restrictions that Capybara has is that it cannot handle JavaScript. There are other tools like webdriver which can handle JavaScript but it runs a lot slower compared to Capybara.

=Comparison of Unit Test Frameworks : Rspec, Shoulda and Cucumber=

{|border="2" cellpadding="5" cellspacing="0" align="center"
|-
! scope="col" | Rspec
! scope="col" | Shoulda
! scope="col" | Cucumber

|-
|RSpec is based on the Behaviour driven development model provided by Ruby. It has its origins in Test Driven Development and Domain Driven Design.
|Shoulda is based on the Test:Unit which is another Ruby Test Framework. It is based on Test Driven Development.
|Cucumber is a combination of Test Driven Development and Behaviour driven development.
|-
|RSpec provides a Domain Specific Language that can express code functionality and behaviour.
|Shoulda provides macros, helpers and matchers.
|Cucumber allows the test cases to be written in native language of the system
|-
|RSpec too allows nested describe structure.
|Shoulda has nested contexts which helps create different environment for different set of tests.
|Cucumber is similar to RSpec also provides nested structures
|-
|RSpec is expressive when it comes to understanding functionalities since they were designed have the human readability in mind.
|Shoulda has more descriptive names compared to its predecessor Test::Unit but its less expressive.
|Cucumber test are even more descriptive and allows business stakeholder to write and read them.

|}

=Reference=
<references/>

CSC/ECE 517 Fall 2012/ch1 1w3 pl

2012-09-14T21:04:44Z

Pvasude: /* Testing a Sample Rails Application using Cucumber */

='''Unit-Testing Frameworks for Ruby: Cucumber'''=

This wiki-page serves as a knowledge source for understanding Unit-Testing Frameworks available for Ruby particularly Cucumber . 

__TOC__

=Introduction=

Unit testing is a software development process for testing individual units of source code independently for proper operation <ref>[http://en.wikipedia.org/wiki/Unit_testing Unit Testing]</ref>. An unit testing framework helps the process of unit testing by automating the test cases written to ensure the correctness of the system. They are often third-party products that are not offered as part of the suite.Ruby provides a framework in its standard library for setting up, organizing, and running tests called Test::Unit <ref>[http://en.wikibooks.org/wiki/Ruby_Programming/Unit_testing Ruby Unit Testing Framework]</ref>. Other testing frameworks available for ruby are Shoulda, RSpec and Cucumber.

=Cucumber=
Cucumber is one of the latest unit test frameworks to have come for Ruby as part of the RSpec family of tools. Cucumber itself is written in the Ruby programming language and adheres to Behaviour Driven Development(BDD). Behaviour Driven Development is an Agile Development process that comprises aspects of Acceptance Test Driven Planning , Domain Driven Design and Test Driven Development (TDD). Cucumber is designed specifically to ensure that the acceptance tests can easily be read and written by anyone.

==Behaviour Driven Development(BDD)==

Behaviour Driven Development<ref>[http://en.wikipedia.org/wiki/Behavior-driven_development BDD]</ref> preserves the basic iterative (fail-pass) workflow of TDD, but stresses on specifying behaviors that are understandable to people (say from non programming background). In this approach we write tests in a natural language that even a non-programmer can understand.

==Acceptance Test==

Acceptance Test<ref>[http://en.wikipedia.org/wiki/Acceptance_testing Acceptance Test]</ref><ref>[http://pragprog.com/book/hwcuc/the-cucumber-book Cucumber Book]</ref> Drive Planning is a practice that stresses on the importance of identifying the functions and requirements of the software beforehand so that we exactly know when the development phase ends. This practice results in fewer bugs , shorter delivery times and greater customer satisfaction.

===Cucumber Acceptance Test===

Feature: Sign up
Sign up should be quick and friendly. 
Scenario: Successful sign up
New users should get a confirmation email and be greeted personally by the site once signed in.
Given I have chosen to sign up
When I sign up with valid details
Then I should receive a confirmation email
And I should see a personalized greeting message 
Scenario: Duplicate email
Where someone tries to create an account for an email address that already exists.
Given I have chosen to sign up
But I enter an email address that has already registered
Then I should be told that the email is already registered
And I should be offered the option to recover my password

Acceptance tests written in this style are more than just tests; they are executable specifications. As of January 2012, Cucumber was the second most popular testing framework after RSpec for Ruby

==How Cucumber works==

Cucumber is a command-line tool. It reads in specifications from plain-language text files called features, examines them for scenarios to test, and runs the scenarios against the system. The feature files should be written according to specific syntax rules called Gherkin. Along with the features, you give Cucumber a set of step definitions, which map the business-readable language of each step into Ruby code to carry out whatever action is being described by the step. Cucumber takes customer understandable user stories as input and does integration and acceptance tests on the system with those as its input.

===Feature===
A Feature is a high level statement of the what the test case does and there is only one feature per user story. For every feature that is supported by the system , a separate feature file has to be written and included in the features directory. The feature files has .feature file extension.

===Scenario===
A Scenario consists of one or more steps which describe about the various actions performed by the user with respect to this particular feature. There can be one or more scenarios per feature in a user story. A feature usually contains 3 to 8 steps in it. The steps of the scenario always begin with one of the below mentioned key words :

1. Given : Steps that begin with given represent the state of the world before an event.(preconditions) 
2. When : Steps that represent the event. 
3. Then : Steps that represent the expected outcome. 
4. And and But : Steps that extend the previous step. 

===Step and Step Definitions===
When testing with Cucumber , The user stories are all kept in one set of files called Steps.The Steps are compared with Step Definitions which are files written in ruby which gives the rules based on which the steps are executed. Step definitions are analogous to method definitions and steps of scenarios are analogous to method calls. Cucumber uses regular expressions to match the English phrases in the steps of scenarios to step definitions.

When the cucumber test framework is run , The steps present in the feature file can be classified as follows based on the result of regex matching with the step definitions.<ref>[https://github.com/cucumber/cucumber/wiki/Step-Definitions Step Definitions in Ruby]</ref>

====Successful steps====
When Cucumber finds a matching Step Definition it will execute it. If the block in the step definition doesn’t raise an Exception, the step is marked as successful (green). What you return from a Step Definition has no significance what so ever.

====Undefined steps====
When Cucumber can’t find a matching Step Definition the step gets marked as yellow, and all subsequent steps in the scenario are skipped. If you use --strict this will cause Cucumber to exit with 1.

====Pending steps====
When a Step Definition’s Proc invokes the #pending method, the step is marked as yellow (as with undefined ones), reminding you that you have work to do. If you use --strict this will cause Cucumber to exit with 1.

====Failed steps====
When a Step Definition’s Proc is executed and raises an error, the step is marked as red. Returning nil or false will not cause a step definition to fail.

Cucumber tries to run the steps based on the definitions and thus colors steps based on the execution of the steps. The colors for the steps assigned are as follows : 
 
1. Green : for passing. 
2. Yellow : for not yet implemented. 
3. Red : for failing. 
4. Blue : Once a step fails all the successive steps are marked in blue. 

==Cucumber Testing Stack==
/* Some Content */

[[File:Cucumber.JPG|500px|thumb|right|Cucumber Testing Stack]]

==Advantages of Cucumber==
*Specifications can be written in more than forty different spoken languages.
*Cucumber helps reduce the gap between technical and non-technical members of a software team.
*Cucumber tests can be easily read and written by business stakeholders.
*Writing Cucumber tests are quick, easy, efficient and understandable.

=Cucumber Installation=
<ref>[http://cuke4ninja.com/sec_ruby_install_cucumber.html Installing Cucumber]</ref>

To install cucumber we should make sure that the Environment path is set to “..../Ruby/bin”. Then open the command prompt and run

gem install cucumber

Once cucumber gem is installed then we would be able to check whether it is installed by issuing the following command:

cucumber --version

this should give a version number like “1.2.1”

Cucumber uses Rspec for assertions and hence we need Rspec installed to use Cucumber. Use the following command to install rspec

gem install rspec

=Testing a Sample Ruby Application using Cucumber=
<ref>[http://pragprog.com/book/hwcuc/the-cucumber-book Sample Cucumber Application]</ref>

Step 1 : Create a new directory

mkdir HelloCucumber

Step 2 : Install Cucumber and Rspec

gem install cucumber
gem instal rspec

Step 3 : Create a directory features and create a file basic.feature in the features directory

mkdir features

Content of features/basic.feature

Feature: Hello World Feature 
Scenario: Hello World Scenario
Given The Action is Hello
When The Subject is World
Then The Greeting is Hello, World

Step 4: Create step_definitions directory inside features directory. Create basic_step.rb file inside step_definitions.

mkdir features/step_definitions

Content of features/step_definitions/basic_step.rb

require 'rspec/expectations' 
Given /The Action is ([A-z]*)/ do |action|
@action = action
end 
When /The Subject is ([A-z]*)/ do |subject|
@subject = subject
end 
Then /The Greeting is (.*)/ do |greeting|
greeting.should == "#{@action}, #{@subject}"
end
Cucumber uses regular expression after the keywords Given, When and Then to map lines in a feature file to step definitions.

Step 5: Running cucumber command you will see the following output

Feature: Hello World Feature 
Scenario: Hello World Scenario # features\basic.feature:3
Given The Action is Hello # features/step_definitions/basic_steps.rb:3
When The Subject is World # features/step_definitions/basic_steps.rb:7
Then The Greeting is Hello, World # features/step_definitions/basic_steps.rb:11 

1 scenario (1 passed)
3 steps (3 passed)
0m0.016s
Step 6 : Modify the basic.features file to include 2 scenario

Step 6 : Modify the basic.features file to include 2 scenarios

Feature: Hello World Feature 
Scenario: Hello World Scenario
Given The Action is Hello
When The Subject is World
Then The Greeting is Hello, World 
Scenario: Bye World Scenario
Given The Action is Bye
When The Subject is World
Then The Greeting is Hello, World

Step 7 : Running the cucumber command you will see the following output

Scenario: Hello World Scenario # features\basic.feature:3
Given The Action is Hello # features/step_definitions/basic_steps.rb:3
When The Subject is World # features/step_definitions/basic_steps.rb:7
Then The Greeting is Hello, World # features/step_definitions/basic_steps.rb:11 
Scenario: Bye World Scenario # features\basic.feature:8
Given The Action is Bye # features/step_definitions/basic_steps.rb:3
When The Subject is World # features/step_definitions/basic_steps.rb:7
Then The Greeting is Hello, World # features/step_definitions/basic_steps.rb:11
expected: "Bye, World"
got: "Hello, World" (using ==) (RSpec::Expectations::ExpectationNotMetError)
./features/step_definitions/basic_steps.rb:12:in `/The Greeting is (.*)/'
features\basic.feature:11:in `Then The Greeting is Hello, World' 
Failing Scenarios:
cucumber features\basic.feature:8 # Scenario: Bye World Scenario 
2 scenarios (1 failed, 1 passed)
6 steps (1 failed, 5 passed)
0m0.033s

The Bye Scenario fails since the expected output is “Hello, World” but the received output is “Bye,World”.

=Testing a Sample Rails Application using Cucumber=
<ref>[http://railscasts.com/episodes/155-beginning-with-cucumber Sample Cucumber Application on Rails]</ref>

Cucumber easily integrates with Rails and hence can be used with Ruby applications which run on Rails. But there are a few steps which have to be followed before integrating cucumber with Rails. Lets walk through it by creating a new rails application.

rails new cucumber_app

Install the required cucumber gems
 
gem install cucumber
gem install cucumber cucumber-rails
 
Add the following lines to your gemfile. These gems are required only for the test environment. The gems database_cleaner , rspec-rails and webrat are required for cucumber to function properly.
 
group :test do
gem 'database_cleaner'
gem 'cucumber'
gem "rspec-rails", "~> 2.0", :require => false
gem "cucumber-rails", "1.0.6"
gem 'webrat'
end

After modifying the gem file . Run bundle update

bundle update

Cucumber required files can then be created by giving the following command. The output below the command shows the folders and files that get created for the cucumber test framework.

rails generate cucumber:install
 
identical script/cucumber
chmod script/cucumber
exist features/step_definitions
identical features/step_definitions/web_steps.rb
exist features/support
identical features/support/paths.rb
identical features/support/selectors.rb
identical features/support/env.rb
exist lib/tasks
identical lib/tasks/cucumber.rake
 
The Step definitions folder contains ruby files which test the steps which are mentioned in feature file of the cucumber.
 
The paths.rb file is created in the support folder will contain the rules based on which the step definitions will be compared to the steps and matched. In case we come across any steps whose execution fails while running cucumber we would have to update the paths.rb file to resolve the issue.
 
env.rb is only loaded when the application is first started up and it sets up the environment required by Cucumber to execute.
 
rails generate model article title:string content:text
rake db:migrate
rake db:test:clone
rails generate controller articles index
 
The above four commands generate models with the name article and with two fields title and content
and the next two commands migrate the db to production and the last commands creates controller for article and index objects.
 
We have to go the home directory of our rails application and then run Cucumber with the following command.The result would then be shown to the user on how many and which steps succeeded and failed.

=> cucumber
===Capybara===
<ref>[http://net.tutsplus.com/tutorials/ruby/ruby-for-newbies-testing-web-apps-with-capybara-and-cucumber Web-app with Cucumber and Capybara]</ref>

We need a tool that acts out the user stories that are part of the feature that is to be tested with Cucumber. Capybara can be used as that tool. Capybara is an integration testing tool for rack based web based applications. It simulates how a user would interact with a website. It can simulate the actions of a web browser and hence can interact with the application to receive web pages. It can also parse the HTML content and submits forms as the user would. One of the restrictions that Capybara has is that it cannot handle JavaScript. There are other tools like webdriver which can handle JavaScript but it runs a lot slower compared to Capybara.

=Comparison of Unit Test Frameworks : Rspec, Shoulda and Cucumber=

{|border="2" cellpadding="5" cellspacing="0" align="center"
|-
! scope="col" | Rspec
! scope="col" | Shoulda
! scope="col" | Cucumber

|-
|RSpec is based on the Behaviour driven development model provided by Ruby. It has its origins in Test Driven Development and Domain Driven Design.
|Shoulda is based on the Test:Unit which is another Ruby Test Framework. It is based on Test Driven Development.
|Cucumber is a combination of Test Driven Development and Behaviour driven development.
|-
|RSpec provides a Domain Specific Language that can express code functionality and behaviour.
|Shoulda provides macros, helpers and matchers.
|Cucumber allows the test cases to be written in native language of the system
|-
|RSpec too allows nested describe structure.
|Shoulda has nested contexts which helps create different environment for different set of tests.
|Cucumber is similar to RSpec also provides nested structures
|-
|RSpec is expressive when it comes to understanding functionalities since they were designed have the human readability in mind.
|Shoulda has more descriptive names compared to its predecessor Test::Unit but its less expressive.
|Cucumber test are even more descriptive and allows business stakeholder to write and read them.

|}

=Reference=
<references/>

CSC/ECE 517 Fall 2012/ch1 1w3 pl

2012-09-14T21:03:42Z

Pvasude: /* Testing a Sample Rails Application using Cucumber */

='''Unit-Testing Frameworks for Ruby: Cucumber'''=

This wiki-page serves as a knowledge source for understanding Unit-Testing Frameworks available for Ruby particularly Cucumber . 

__TOC__

=Introduction=

Unit testing is a software development process for testing individual units of source code independently for proper operation <ref>[http://en.wikipedia.org/wiki/Unit_testing Unit Testing]</ref>. An unit testing framework helps the process of unit testing by automating the test cases written to ensure the correctness of the system. They are often third-party products that are not offered as part of the suite.Ruby provides a framework in its standard library for setting up, organizing, and running tests called Test::Unit <ref>[http://en.wikibooks.org/wiki/Ruby_Programming/Unit_testing Ruby Unit Testing Framework]</ref>. Other testing frameworks available for ruby are Shoulda, RSpec and Cucumber.

=Cucumber=
Cucumber is one of the latest unit test frameworks to have come for Ruby as part of the RSpec family of tools. Cucumber itself is written in the Ruby programming language and adheres to Behaviour Driven Development(BDD). Behaviour Driven Development is an Agile Development process that comprises aspects of Acceptance Test Driven Planning , Domain Driven Design and Test Driven Development (TDD). Cucumber is designed specifically to ensure that the acceptance tests can easily be read and written by anyone.

==Behaviour Driven Development(BDD)==

Behaviour Driven Development<ref>[http://en.wikipedia.org/wiki/Behavior-driven_development BDD]</ref> preserves the basic iterative (fail-pass) workflow of TDD, but stresses on specifying behaviors that are understandable to people (say from non programming background). In this approach we write tests in a natural language that even a non-programmer can understand.

==Acceptance Test==

Acceptance Test<ref>[http://en.wikipedia.org/wiki/Acceptance_testing Acceptance Test]</ref><ref>[http://pragprog.com/book/hwcuc/the-cucumber-book Cucumber Book]</ref> Drive Planning is a practice that stresses on the importance of identifying the functions and requirements of the software beforehand so that we exactly know when the development phase ends. This practice results in fewer bugs , shorter delivery times and greater customer satisfaction.

===Cucumber Acceptance Test===

Feature: Sign up
Sign up should be quick and friendly. 
Scenario: Successful sign up
New users should get a confirmation email and be greeted personally by the site once signed in.
Given I have chosen to sign up
When I sign up with valid details
Then I should receive a confirmation email
And I should see a personalized greeting message 
Scenario: Duplicate email
Where someone tries to create an account for an email address that already exists.
Given I have chosen to sign up
But I enter an email address that has already registered
Then I should be told that the email is already registered
And I should be offered the option to recover my password

Acceptance tests written in this style are more than just tests; they are executable specifications. As of January 2012, Cucumber was the second most popular testing framework after RSpec for Ruby

==How Cucumber works==

Cucumber is a command-line tool. It reads in specifications from plain-language text files called features, examines them for scenarios to test, and runs the scenarios against the system. The feature files should be written according to specific syntax rules called Gherkin. Along with the features, you give Cucumber a set of step definitions, which map the business-readable language of each step into Ruby code to carry out whatever action is being described by the step. Cucumber takes customer understandable user stories as input and does integration and acceptance tests on the system with those as its input.

===Feature===
A Feature is a high level statement of the what the test case does and there is only one feature per user story. For every feature that is supported by the system , a separate feature file has to be written and included in the features directory. The feature files has .feature file extension.

===Scenario===
A Scenario consists of one or more steps which describe about the various actions performed by the user with respect to this particular feature. There can be one or more scenarios per feature in a user story. A feature usually contains 3 to 8 steps in it. The steps of the scenario always begin with one of the below mentioned key words :

1. Given : Steps that begin with given represent the state of the world before an event.(preconditions) 
2. When : Steps that represent the event. 
3. Then : Steps that represent the expected outcome. 
4. And and But : Steps that extend the previous step. 

===Step and Step Definitions===
When testing with Cucumber , The user stories are all kept in one set of files called Steps.The Steps are compared with Step Definitions which are files written in ruby which gives the rules based on which the steps are executed. Step definitions are analogous to method definitions and steps of scenarios are analogous to method calls. Cucumber uses regular expressions to match the English phrases in the steps of scenarios to step definitions.

When the cucumber test framework is run , The steps present in the feature file can be classified as follows based on the result of regex matching with the step definitions.<ref>[https://github.com/cucumber/cucumber/wiki/Step-Definitions Step Definitions in Ruby]</ref>

====Successful steps====
When Cucumber finds a matching Step Definition it will execute it. If the block in the step definition doesn’t raise an Exception, the step is marked as successful (green). What you return from a Step Definition has no significance what so ever.

====Undefined steps====
When Cucumber can’t find a matching Step Definition the step gets marked as yellow, and all subsequent steps in the scenario are skipped. If you use --strict this will cause Cucumber to exit with 1.

====Pending steps====
When a Step Definition’s Proc invokes the #pending method, the step is marked as yellow (as with undefined ones), reminding you that you have work to do. If you use --strict this will cause Cucumber to exit with 1.

====Failed steps====
When a Step Definition’s Proc is executed and raises an error, the step is marked as red. Returning nil or false will not cause a step definition to fail.

Cucumber tries to run the steps based on the definitions and thus colors steps based on the execution of the steps. The colors for the steps assigned are as follows : 
 
1. Green : for passing. 
2. Yellow : for not yet implemented. 
3. Red : for failing. 
4. Blue : Once a step fails all the successive steps are marked in blue. 

==Cucumber Testing Stack==
/* Some Content */

[[File:Cucumber.JPG|500px|thumb|right|Cucumber Testing Stack]]

==Advantages of Cucumber==
*Specifications can be written in more than forty different spoken languages.
*Cucumber helps reduce the gap between technical and non-technical members of a software team.
*Cucumber tests can be easily read and written by business stakeholders.
*Writing Cucumber tests are quick, easy, efficient and understandable.

=Cucumber Installation=
<ref>[http://cuke4ninja.com/sec_ruby_install_cucumber.html Installing Cucumber]</ref>

To install cucumber we should make sure that the Environment path is set to “..../Ruby/bin”. Then open the command prompt and run

gem install cucumber

Once cucumber gem is installed then we would be able to check whether it is installed by issuing the following command:

cucumber --version

this should give a version number like “1.2.1”

Cucumber uses Rspec for assertions and hence we need Rspec installed to use Cucumber. Use the following command to install rspec

gem install rspec

=Testing a Sample Ruby Application using Cucumber=
<ref>[http://pragprog.com/book/hwcuc/the-cucumber-book Sample Cucumber Application]</ref>

Step 1 : Create a new directory

mkdir HelloCucumber

Step 2 : Install Cucumber and Rspec

gem install cucumber
gem instal rspec

Step 3 : Create a directory features and create a file basic.feature in the features directory

mkdir features

Content of features/basic.feature

Feature: Hello World Feature 
Scenario: Hello World Scenario
Given The Action is Hello
When The Subject is World
Then The Greeting is Hello, World

Step 4: Create step_definitions directory inside features directory. Create basic_step.rb file inside step_definitions.

mkdir features/step_definitions

Content of features/step_definitions/basic_step.rb

require 'rspec/expectations' 
Given /The Action is ([A-z]*)/ do |action|
@action = action
end 
When /The Subject is ([A-z]*)/ do |subject|
@subject = subject
end 
Then /The Greeting is (.*)/ do |greeting|
greeting.should == "#{@action}, #{@subject}"
end
Cucumber uses regular expression after the keywords Given, When and Then to map lines in a feature file to step definitions.

Step 5: Running cucumber command you will see the following output

Feature: Hello World Feature 
Scenario: Hello World Scenario # features\basic.feature:3
Given The Action is Hello # features/step_definitions/basic_steps.rb:3
When The Subject is World # features/step_definitions/basic_steps.rb:7
Then The Greeting is Hello, World # features/step_definitions/basic_steps.rb:11 

1 scenario (1 passed)
3 steps (3 passed)
0m0.016s
Step 6 : Modify the basic.features file to include 2 scenario

Step 6 : Modify the basic.features file to include 2 scenarios

Feature: Hello World Feature 
Scenario: Hello World Scenario
Given The Action is Hello
When The Subject is World
Then The Greeting is Hello, World 
Scenario: Bye World Scenario
Given The Action is Bye
When The Subject is World
Then The Greeting is Hello, World

Step 7 : Running the cucumber command you will see the following output

Scenario: Hello World Scenario # features\basic.feature:3
Given The Action is Hello # features/step_definitions/basic_steps.rb:3
When The Subject is World # features/step_definitions/basic_steps.rb:7
Then The Greeting is Hello, World # features/step_definitions/basic_steps.rb:11 
Scenario: Bye World Scenario # features\basic.feature:8
Given The Action is Bye # features/step_definitions/basic_steps.rb:3
When The Subject is World # features/step_definitions/basic_steps.rb:7
Then The Greeting is Hello, World # features/step_definitions/basic_steps.rb:11
expected: "Bye, World"
got: "Hello, World" (using ==) (RSpec::Expectations::ExpectationNotMetError)
./features/step_definitions/basic_steps.rb:12:in `/The Greeting is (.*)/'
features\basic.feature:11:in `Then The Greeting is Hello, World' 
Failing Scenarios:
cucumber features\basic.feature:8 # Scenario: Bye World Scenario 
2 scenarios (1 failed, 1 passed)
6 steps (1 failed, 5 passed)
0m0.033s

The Bye Scenario fails since the expected output is “Hello, World” but the received output is “Bye,World”.

=Testing a Sample Rails Application using Cucumber=
<ref>[http://railscasts.com/episodes/155-beginning-with-cucumber Sample Cucumber Application on Rails]</ref>

Cucumber easily integrates with Rails and hence can be used with Ruby applications which run on Rails. But there are a few steps which have to be followed before integrating cucumber with Rails. Lets walk through it by creating a new rails application.

rails new cucumber_app
 
Install the required cucumber gems
 
gem install cucumber
gem install cucumber cucumber-rails
 
Add the following lines to your gemfile. These gems are required only for the test environment. The gems database_cleaner , rspec-rails and webrat are required for cucumber to function properly.
 
group :test do
gem 'database_cleaner'
gem 'cucumber'
gem "rspec-rails", "~> 2.0", :require => false
gem "cucumber-rails", "1.0.6"
gem 'webrat'
end
 
Cucumber required files can then be created by giving the following command. The output below the command shows the folders and files that get created for the cucumber test framework.

rails generate cucumber:install
 
identical script/cucumber
chmod script/cucumber
exist features/step_definitions
identical features/step_definitions/web_steps.rb
exist features/support
identical features/support/paths.rb
identical features/support/selectors.rb
identical features/support/env.rb
exist lib/tasks
identical lib/tasks/cucumber.rake
 
The Step definitions folder contains ruby files which test the steps which are mentioned in feature file of the cucumber.
 
The paths.rb file is created in the support folder will contain the rules based on which the step definitions will be compared to the steps and matched. In case we come across any steps whose execution fails while running cucumber we would have to update the paths.rb file to resolve the issue.
 
env.rb is only loaded when the application is first started up and it sets up the environment required by Cucumber to execute.
 
rails generate model article title:string content:text
rake db:migrate
rake db:test:clone
rails generate controller articles index
 
The above four commands generate models with the name article and with two fields title and content
and the next two commands migrate the db to production and the last commands creates controller for article and index objects.
 
We have to go the home directory of our rails application and then run Cucumber with the following command.The result would then be shown to the user on how many and which steps succeeded and failed.

=> cucumber
===Capybara===
<ref>[http://net.tutsplus.com/tutorials/ruby/ruby-for-newbies-testing-web-apps-with-capybara-and-cucumber Web-app with Cucumber and Capybara]</ref>

We need a tool that acts out the user stories that are part of the feature that is to be tested with Cucumber. Capybara can be used as that tool. Capybara is an integration testing tool for rack based web based applications. It simulates how a user would interact with a website. It can simulate the actions of a web browser and hence can interact with the application to receive web pages. It can also parse the HTML content and submits forms as the user would. One of the restrictions that Capybara has is that it cannot handle JavaScript. There are other tools like webdriver which can handle JavaScript but it runs a lot slower compared to Capybara.

=Comparison of Unit Test Frameworks : Rspec, Shoulda and Cucumber=

{|border="2" cellpadding="5" cellspacing="0" align="center"
|-
! scope="col" | Rspec
! scope="col" | Shoulda
! scope="col" | Cucumber

|-
|RSpec is based on the Behaviour driven development model provided by Ruby. It has its origins in Test Driven Development and Domain Driven Design.
|Shoulda is based on the Test:Unit which is another Ruby Test Framework. It is based on Test Driven Development.
|Cucumber is a combination of Test Driven Development and Behaviour driven development.
|-
|RSpec provides a Domain Specific Language that can express code functionality and behaviour.
|Shoulda provides macros, helpers and matchers.
|Cucumber allows the test cases to be written in native language of the system
|-
|RSpec too allows nested describe structure.
|Shoulda has nested contexts which helps create different environment for different set of tests.
|Cucumber is similar to RSpec also provides nested structures
|-
|RSpec is expressive when it comes to understanding functionalities since they were designed have the human readability in mind.
|Shoulda has more descriptive names compared to its predecessor Test::Unit but its less expressive.
|Cucumber test are even more descriptive and allows business stakeholder to write and read them.

|}

=Reference=
<references/>

CSC/ECE 517 Fall 2012/ch1 1w3 pl

2012-09-14T20:59:49Z

Pvasude: /* Testing a Sample Rails Application using Cucumber */

='''Unit-Testing Frameworks for Ruby: Cucumber'''=

This wiki-page serves as a knowledge source for understanding Unit-Testing Frameworks available for Ruby particularly Cucumber . 

__TOC__

=Introduction=

Unit testing is a software development process for testing individual units of source code independently for proper operation <ref>[http://en.wikipedia.org/wiki/Unit_testing Unit Testing]</ref>. An unit testing framework helps the process of unit testing by automating the test cases written to ensure the correctness of the system. They are often third-party products that are not offered as part of the suite.Ruby provides a framework in its standard library for setting up, organizing, and running tests called Test::Unit <ref>[http://en.wikibooks.org/wiki/Ruby_Programming/Unit_testing Ruby Unit Testing Framework]</ref>. Other testing frameworks available for ruby are Shoulda, RSpec and Cucumber.

=Cucumber=
Cucumber is one of the latest unit test frameworks to have come for Ruby as part of the RSpec family of tools. Cucumber itself is written in the Ruby programming language and adheres to Behaviour Driven Development(BDD). Behaviour Driven Development is an Agile Development process that comprises aspects of Acceptance Test Driven Planning , Domain Driven Design and Test Driven Development (TDD). Cucumber is designed specifically to ensure that the acceptance tests can easily be read and written by anyone.

==Behaviour Driven Development(BDD)==

Behaviour Driven Development<ref>[http://en.wikipedia.org/wiki/Behavior-driven_development BDD]</ref> preserves the basic iterative (fail-pass) workflow of TDD, but stresses on specifying behaviors that are understandable to people (say from non programming background). In this approach we write tests in a natural language that even a non-programmer can understand.

==Acceptance Test==

Acceptance Test<ref>[http://en.wikipedia.org/wiki/Acceptance_testing Acceptance Test]</ref><ref>[http://pragprog.com/book/hwcuc/the-cucumber-book Cucumber Book]</ref> Drive Planning is a practice that stresses on the importance of identifying the functions and requirements of the software beforehand so that we exactly know when the development phase ends. This practice results in fewer bugs , shorter delivery times and greater customer satisfaction.

===Cucumber Acceptance Test===

Feature: Sign up
Sign up should be quick and friendly. 
Scenario: Successful sign up
New users should get a confirmation email and be greeted personally by the site once signed in.
Given I have chosen to sign up
When I sign up with valid details
Then I should receive a confirmation email
And I should see a personalized greeting message 
Scenario: Duplicate email
Where someone tries to create an account for an email address that already exists.
Given I have chosen to sign up
But I enter an email address that has already registered
Then I should be told that the email is already registered
And I should be offered the option to recover my password

Acceptance tests written in this style are more than just tests; they are executable specifications. As of January 2012, Cucumber was the second most popular testing framework after RSpec for Ruby

==How Cucumber works==

Cucumber is a command-line tool. It reads in specifications from plain-language text files called features, examines them for scenarios to test, and runs the scenarios against the system. The feature files should be written according to specific syntax rules called Gherkin. Along with the features, you give Cucumber a set of step definitions, which map the business-readable language of each step into Ruby code to carry out whatever action is being described by the step. Cucumber takes customer understandable user stories as input and does integration and acceptance tests on the system with those as its input.

===Feature===
A Feature is a high level statement of the what the test case does and there is only one feature per user story. For every feature that is supported by the system , a separate feature file has to be written and included in the features directory. The feature files has .feature file extension.

===Scenario===
A Scenario consists of one or more steps which describe about the various actions performed by the user with respect to this particular feature. There can be one or more scenarios per feature in a user story. A feature usually contains 3 to 8 steps in it. The steps of the scenario always begin with one of the below mentioned key words :

1. Given : Steps that begin with given represent the state of the world before an event.(preconditions) 
2. When : Steps that represent the event. 
3. Then : Steps that represent the expected outcome. 
4. And and But : Steps that extend the previous step. 

===Step and Step Definitions===
When testing with Cucumber , The user stories are all kept in one set of files called Steps.The Steps are compared with Step Definitions which are files written in ruby which gives the rules based on which the steps are executed. Step definitions are analogous to method definitions and steps of scenarios are analogous to method calls. Cucumber uses regular expressions to match the English phrases in the steps of scenarios to step definitions.

When the cucumber test framework is run , The steps present in the feature file can be classified as follows based on the result of regex matching with the step definitions.<ref>[https://github.com/cucumber/cucumber/wiki/Step-Definitions Step Definitions in Ruby]</ref>

====Successful steps====
When Cucumber finds a matching Step Definition it will execute it. If the block in the step definition doesn’t raise an Exception, the step is marked as successful (green). What you return from a Step Definition has no significance what so ever.

====Undefined steps====
When Cucumber can’t find a matching Step Definition the step gets marked as yellow, and all subsequent steps in the scenario are skipped. If you use --strict this will cause Cucumber to exit with 1.

====Pending steps====
When a Step Definition’s Proc invokes the #pending method, the step is marked as yellow (as with undefined ones), reminding you that you have work to do. If you use --strict this will cause Cucumber to exit with 1.

====Failed steps====
When a Step Definition’s Proc is executed and raises an error, the step is marked as red. Returning nil or false will not cause a step definition to fail.

Cucumber tries to run the steps based on the definitions and thus colors steps based on the execution of the steps. The colors for the steps assigned are as follows : 
 
1. Green : for passing. 
2. Yellow : for not yet implemented. 
3. Red : for failing. 
4. Blue : Once a step fails all the successive steps are marked in blue. 

==Cucumber Testing Stack==
/* Some Content */

[[File:Cucumber.JPG|500px|thumb|right|Cucumber Testing Stack]]

==Advantages of Cucumber==
*Specifications can be written in more than forty different spoken languages.
*Cucumber helps reduce the gap between technical and non-technical members of a software team.
*Cucumber tests can be easily read and written by business stakeholders.
*Writing Cucumber tests are quick, easy, efficient and understandable.

=Cucumber Installation=
<ref>[http://cuke4ninja.com/sec_ruby_install_cucumber.html Installing Cucumber]</ref>

To install cucumber we should make sure that the Environment path is set to “..../Ruby/bin”. Then open the command prompt and run

gem install cucumber

Once cucumber gem is installed then we would be able to check whether it is installed by issuing the following command:

cucumber --version

this should give a version number like “1.2.1”

Cucumber uses Rspec for assertions and hence we need Rspec installed to use Cucumber. Use the following command to install rspec

gem install rspec

=Testing a Sample Ruby Application using Cucumber=
<ref>[http://pragprog.com/book/hwcuc/the-cucumber-book Sample Cucumber Application]</ref>

Step 1 : Create a new directory

mkdir HelloCucumber

Step 2 : Install Cucumber and Rspec

gem install cucumber
gem instal rspec

Step 3 : Create a directory features and create a file basic.feature in the features directory

mkdir features

Content of features/basic.feature

Feature: Hello World Feature 
Scenario: Hello World Scenario
Given The Action is Hello
When The Subject is World
Then The Greeting is Hello, World

Step 4: Create step_definitions directory inside features directory. Create basic_step.rb file inside step_definitions.

mkdir features/step_definitions

Content of features/step_definitions/basic_step.rb

require 'rspec/expectations' 
Given /The Action is ([A-z]*)/ do |action|
@action = action
end 
When /The Subject is ([A-z]*)/ do |subject|
@subject = subject
end 
Then /The Greeting is (.*)/ do |greeting|
greeting.should == "#{@action}, #{@subject}"
end
Cucumber uses regular expression after the keywords Given, When and Then to map lines in a feature file to step definitions.

Step 5: Running cucumber command you will see the following output

Feature: Hello World Feature 
Scenario: Hello World Scenario # features\basic.feature:3
Given The Action is Hello # features/step_definitions/basic_steps.rb:3
When The Subject is World # features/step_definitions/basic_steps.rb:7
Then The Greeting is Hello, World # features/step_definitions/basic_steps.rb:11 

1 scenario (1 passed)
3 steps (3 passed)
0m0.016s
Step 6 : Modify the basic.features file to include 2 scenario

Step 6 : Modify the basic.features file to include 2 scenarios

Feature: Hello World Feature 
Scenario: Hello World Scenario
Given The Action is Hello
When The Subject is World
Then The Greeting is Hello, World 
Scenario: Bye World Scenario
Given The Action is Bye
When The Subject is World
Then The Greeting is Hello, World

Step 7 : Running the cucumber command you will see the following output

Scenario: Hello World Scenario # features\basic.feature:3
Given The Action is Hello # features/step_definitions/basic_steps.rb:3
When The Subject is World # features/step_definitions/basic_steps.rb:7
Then The Greeting is Hello, World # features/step_definitions/basic_steps.rb:11 
Scenario: Bye World Scenario # features\basic.feature:8
Given The Action is Bye # features/step_definitions/basic_steps.rb:3
When The Subject is World # features/step_definitions/basic_steps.rb:7
Then The Greeting is Hello, World # features/step_definitions/basic_steps.rb:11
expected: "Bye, World"
got: "Hello, World" (using ==) (RSpec::Expectations::ExpectationNotMetError)
./features/step_definitions/basic_steps.rb:12:in `/The Greeting is (.*)/'
features\basic.feature:11:in `Then The Greeting is Hello, World' 
Failing Scenarios:
cucumber features\basic.feature:8 # Scenario: Bye World Scenario 
2 scenarios (1 failed, 1 passed)
6 steps (1 failed, 5 passed)
0m0.033s

The Bye Scenario fails since the expected output is “Hello, World” but the received output is “Bye,World”.

=Testing a Sample Rails Application using Cucumber=
<ref>[http://railscasts.com/episodes/155-beginning-with-cucumber Sample Cucumber Application on Rails]</ref>

Cucumber easily integrates with Rails and hence can be used with Ruby applications which run on Rails. But there are a few steps which have to be followed before integrating cucumber with Rails. Lets walk through it by creating a new rails application.

rails new cucumber_app
 
Install the required cucumber gems
 
gem install cucumber
gem install cucumber cucumber-rails
 
We would have to then give “bundle install” command to install these new gems. We would then have to update the Gemfile to include these gems in the test group since they will be needed only in the test environment. There are a few other gems which are required for cucumber namely database_cleaner , rspec-rails and webrat.
 
group :test do
gem 'database_cleaner'
gem 'cucumber'
gem "rspec-rails", "~> 2.0", :require => false
gem "cucumber-rails", "1.0.6"
gem 'webrat'
end
 
Cucumber required files can then be created by giving the following command. The output below the command shows the folders and files that get created for the cucumber test framework.

rails generate cucumber:install
 
identical script/cucumber
chmod script/cucumber
exist features/step_definitions
identical features/step_definitions/web_steps.rb
exist features/support
identical features/support/paths.rb
identical features/support/selectors.rb
identical features/support/env.rb
exist lib/tasks
identical lib/tasks/cucumber.rake
 
The Step definitions folder contains ruby files which test the steps which are mentioned in feature file of the cucumber.
 
The paths.rb file is created in the support folder will contain the rules based on which the step definitions will be compared to the steps and matched. In case we come across any steps whose execution fails while running cucumber we would have to update the paths.rb file to resolve the issue.
 
env.rb is only loaded when the application is first started up and it sets up the environment required by Cucumber to execute.
 
rails generate model article title:string content:text
rake db:migrate
rake db:test:clone
rails generate controller articles index
 
The above four commands generate models with the name article and with two fields title and content
and the next two commands migrate the db to production and the last commands creates controller for article and index objects.
 
We have to go the home directory of our rails application and then run Cucumber with the following command.The result would then be shown to the user on how many and which steps succeeded and failed.

=> cucumber
===Capybara===
<ref>[http://net.tutsplus.com/tutorials/ruby/ruby-for-newbies-testing-web-apps-with-capybara-and-cucumber Web-app with Cucumber and Capybara]</ref>

We need a tool that acts out the user stories that are part of the feature that is to be tested with Cucumber. Capybara can be used as that tool. Capybara is an integration testing tool for rack based web based applications. It simulates how a user would interact with a website. It can simulate the actions of a web browser and hence can interact with the application to receive web pages. It can also parse the HTML content and submits forms as the user would. One of the restrictions that Capybara has is that it cannot handle JavaScript. There are other tools like webdriver which can handle JavaScript but it runs a lot slower compared to Capybara.

=Comparison of Unit Test Frameworks : Rspec, Shoulda and Cucumber=

{|border="2" cellpadding="5" cellspacing="0" align="center"
|-
! scope="col" | Rspec
! scope="col" | Shoulda
! scope="col" | Cucumber

|-
|RSpec is based on the Behaviour driven development model provided by Ruby. It has its origins in Test Driven Development and Domain Driven Design.
|Shoulda is based on the Test:Unit which is another Ruby Test Framework. It is based on Test Driven Development.
|Cucumber is a combination of Test Driven Development and Behaviour driven development.
|-
|RSpec provides a Domain Specific Language that can express code functionality and behaviour.
|Shoulda provides macros, helpers and matchers.
|Cucumber allows the test cases to be written in native language of the system
|-
|RSpec too allows nested describe structure.
|Shoulda has nested contexts which helps create different environment for different set of tests.
|Cucumber is similar to RSpec also provides nested structures
|-
|RSpec is expressive when it comes to understanding functionalities since they were designed have the human readability in mind.
|Shoulda has more descriptive names compared to its predecessor Test::Unit but its less expressive.
|Cucumber test are even more descriptive and allows business stakeholder to write and read them.

|}

=Reference=
<references/>

CSC/ECE 517 Fall 2012/ch1 1w3 pl

2012-09-14T20:58:49Z

Pvasude: /* Testing a Sample Rails Application using Cucumber */

='''Unit-Testing Frameworks for Ruby: Cucumber'''=

This wiki-page serves as a knowledge source for understanding Unit-Testing Frameworks available for Ruby particularly Cucumber . 

__TOC__

=Introduction=

Unit testing is a software development process for testing individual units of source code independently for proper operation <ref>[http://en.wikipedia.org/wiki/Unit_testing Unit Testing]</ref>. An unit testing framework helps the process of unit testing by automating the test cases written to ensure the correctness of the system. They are often third-party products that are not offered as part of the suite.Ruby provides a framework in its standard library for setting up, organizing, and running tests called Test::Unit <ref>[http://en.wikibooks.org/wiki/Ruby_Programming/Unit_testing Ruby Unit Testing Framework]</ref>. Other testing frameworks available for ruby are Shoulda, RSpec and Cucumber.

=Cucumber=
Cucumber is one of the latest unit test frameworks to have come for Ruby as part of the RSpec family of tools. Cucumber itself is written in the Ruby programming language and adheres to Behaviour Driven Development(BDD). Behaviour Driven Development is an Agile Development process that comprises aspects of Acceptance Test Driven Planning , Domain Driven Design and Test Driven Development (TDD). Cucumber is designed specifically to ensure that the acceptance tests can easily be read and written by anyone.

==Behaviour Driven Development(BDD)==

Behaviour Driven Development<ref>[http://en.wikipedia.org/wiki/Behavior-driven_development BDD]</ref> preserves the basic iterative (fail-pass) workflow of TDD, but stresses on specifying behaviors that are understandable to people (say from non programming background). In this approach we write tests in a natural language that even a non-programmer can understand.

==Acceptance Test==

Acceptance Test<ref>[http://en.wikipedia.org/wiki/Acceptance_testing Acceptance Test]</ref><ref>[http://pragprog.com/book/hwcuc/the-cucumber-book Cucumber Book]</ref> Drive Planning is a practice that stresses on the importance of identifying the functions and requirements of the software beforehand so that we exactly know when the development phase ends. This practice results in fewer bugs , shorter delivery times and greater customer satisfaction.

===Cucumber Acceptance Test===

Feature: Sign up
Sign up should be quick and friendly. 
Scenario: Successful sign up
New users should get a confirmation email and be greeted personally by the site once signed in.
Given I have chosen to sign up
When I sign up with valid details
Then I should receive a confirmation email
And I should see a personalized greeting message 
Scenario: Duplicate email
Where someone tries to create an account for an email address that already exists.
Given I have chosen to sign up
But I enter an email address that has already registered
Then I should be told that the email is already registered
And I should be offered the option to recover my password

Acceptance tests written in this style are more than just tests; they are executable specifications. As of January 2012, Cucumber was the second most popular testing framework after RSpec for Ruby

==How Cucumber works==

Cucumber is a command-line tool. It reads in specifications from plain-language text files called features, examines them for scenarios to test, and runs the scenarios against the system. The feature files should be written according to specific syntax rules called Gherkin. Along with the features, you give Cucumber a set of step definitions, which map the business-readable language of each step into Ruby code to carry out whatever action is being described by the step. Cucumber takes customer understandable user stories as input and does integration and acceptance tests on the system with those as its input.

===Feature===
A Feature is a high level statement of the what the test case does and there is only one feature per user story. For every feature that is supported by the system , a separate feature file has to be written and included in the features directory. The feature files has .feature file extension.

===Scenario===
A Scenario consists of one or more steps which describe about the various actions performed by the user with respect to this particular feature. There can be one or more scenarios per feature in a user story. A feature usually contains 3 to 8 steps in it. The steps of the scenario always begin with one of the below mentioned key words :

1. Given : Steps that begin with given represent the state of the world before an event.(preconditions) 
2. When : Steps that represent the event. 
3. Then : Steps that represent the expected outcome. 
4. And and But : Steps that extend the previous step. 

===Step and Step Definitions===
When testing with Cucumber , The user stories are all kept in one set of files called Steps.The Steps are compared with Step Definitions which are files written in ruby which gives the rules based on which the steps are executed. Step definitions are analogous to method definitions and steps of scenarios are analogous to method calls. Cucumber uses regular expressions to match the English phrases in the steps of scenarios to step definitions.

When the cucumber test framework is run , The steps present in the feature file can be classified as follows based on the result of regex matching with the step definitions.<ref>[https://github.com/cucumber/cucumber/wiki/Step-Definitions Step Definitions in Ruby]</ref>

====Successful steps====
When Cucumber finds a matching Step Definition it will execute it. If the block in the step definition doesn’t raise an Exception, the step is marked as successful (green). What you return from a Step Definition has no significance what so ever.

====Undefined steps====
When Cucumber can’t find a matching Step Definition the step gets marked as yellow, and all subsequent steps in the scenario are skipped. If you use --strict this will cause Cucumber to exit with 1.

====Pending steps====
When a Step Definition’s Proc invokes the #pending method, the step is marked as yellow (as with undefined ones), reminding you that you have work to do. If you use --strict this will cause Cucumber to exit with 1.

====Failed steps====
When a Step Definition’s Proc is executed and raises an error, the step is marked as red. Returning nil or false will not cause a step definition to fail.

Cucumber tries to run the steps based on the definitions and thus colors steps based on the execution of the steps. The colors for the steps assigned are as follows : 
 
1. Green : for passing. 
2. Yellow : for not yet implemented. 
3. Red : for failing. 
4. Blue : Once a step fails all the successive steps are marked in blue. 

==Cucumber Testing Stack==
/* Some Content */

[[File:Cucumber.JPG|500px|thumb|right|Cucumber Testing Stack]]

==Advantages of Cucumber==
*Specifications can be written in more than forty different spoken languages.
*Cucumber helps reduce the gap between technical and non-technical members of a software team.
*Cucumber tests can be easily read and written by business stakeholders.
*Writing Cucumber tests are quick, easy, efficient and understandable.

=Cucumber Installation=
<ref>[http://cuke4ninja.com/sec_ruby_install_cucumber.html Installing Cucumber]</ref>

To install cucumber we should make sure that the Environment path is set to “..../Ruby/bin”. Then open the command prompt and run

gem install cucumber

Once cucumber gem is installed then we would be able to check whether it is installed by issuing the following command:

cucumber --version

this should give a version number like “1.2.1”

Cucumber uses Rspec for assertions and hence we need Rspec installed to use Cucumber. Use the following command to install rspec

gem install rspec

=Testing a Sample Ruby Application using Cucumber=
<ref>[http://pragprog.com/book/hwcuc/the-cucumber-book Sample Cucumber Application]</ref>

Step 1 : Create a new directory

mkdir HelloCucumber

Step 2 : Install Cucumber and Rspec

gem install cucumber
gem instal rspec

Step 3 : Create a directory features and create a file basic.feature in the features directory

mkdir features

Content of features/basic.feature

Feature: Hello World Feature 
Scenario: Hello World Scenario
Given The Action is Hello
When The Subject is World
Then The Greeting is Hello, World

Step 4: Create step_definitions directory inside features directory. Create basic_step.rb file inside step_definitions.

mkdir features/step_definitions

Content of features/step_definitions/basic_step.rb

require 'rspec/expectations' 
Given /The Action is ([A-z]*)/ do |action|
@action = action
end 
When /The Subject is ([A-z]*)/ do |subject|
@subject = subject
end 
Then /The Greeting is (.*)/ do |greeting|
greeting.should == "#{@action}, #{@subject}"
end
Cucumber uses regular expression after the keywords Given, When and Then to map lines in a feature file to step definitions.

Step 5: Running cucumber command you will see the following output

Feature: Hello World Feature 
Scenario: Hello World Scenario # features\basic.feature:3
Given The Action is Hello # features/step_definitions/basic_steps.rb:3
When The Subject is World # features/step_definitions/basic_steps.rb:7
Then The Greeting is Hello, World # features/step_definitions/basic_steps.rb:11 

1 scenario (1 passed)
3 steps (3 passed)
0m0.016s
Step 6 : Modify the basic.features file to include 2 scenario

Step 6 : Modify the basic.features file to include 2 scenarios

Feature: Hello World Feature 
Scenario: Hello World Scenario
Given The Action is Hello
When The Subject is World
Then The Greeting is Hello, World 
Scenario: Bye World Scenario
Given The Action is Bye
When The Subject is World
Then The Greeting is Hello, World

Step 7 : Running the cucumber command you will see the following output

Scenario: Hello World Scenario # features\basic.feature:3
Given The Action is Hello # features/step_definitions/basic_steps.rb:3
When The Subject is World # features/step_definitions/basic_steps.rb:7
Then The Greeting is Hello, World # features/step_definitions/basic_steps.rb:11 
Scenario: Bye World Scenario # features\basic.feature:8
Given The Action is Bye # features/step_definitions/basic_steps.rb:3
When The Subject is World # features/step_definitions/basic_steps.rb:7
Then The Greeting is Hello, World # features/step_definitions/basic_steps.rb:11
expected: "Bye, World"
got: "Hello, World" (using ==) (RSpec::Expectations::ExpectationNotMetError)
./features/step_definitions/basic_steps.rb:12:in `/The Greeting is (.*)/'
features\basic.feature:11:in `Then The Greeting is Hello, World' 
Failing Scenarios:
cucumber features\basic.feature:8 # Scenario: Bye World Scenario 
2 scenarios (1 failed, 1 passed)
6 steps (1 failed, 5 passed)
0m0.033s

The Bye Scenario fails since the expected output is “Hello, World” but the received output is “Bye,World”.

=Testing a Sample Rails Application using Cucumber=
<ref>[http://railscasts.com/episodes/155-beginning-with-cucumber Sample Cucumber Application on Rails]</ref>

Cucumber easily integrates with Rails and hence can be used with Ruby applications which run on Rails. But there are a few steps which have to be followed before integrating cucumber with Rails. Lets walk through it by creating a new rails application.

rails new cucumber_app
 
Install the following gems required by Cucumber.
 
gem install cucumber
gem install cucumber cucumber-rails
 
We would have to then give “bundle install” command to install these new gems. We would then have to update the Gemfile to include these gems in the test group since they will be needed only in the test environment. There are a few other gems which are required for cucumber namely database_cleaner , rspec-rails and webrat.
 
group :test do
gem 'database_cleaner'
gem 'cucumber'
gem "rspec-rails", "~> 2.0", :require => false
gem "cucumber-rails", "1.0.6"
gem 'webrat'
end
 
Cucumber required files can then be created by giving the following command. The output below the command shows the folders and files that get created for the cucumber test framework.

rails generate cucumber:install
 
identical script/cucumber
chmod script/cucumber
exist features/step_definitions
identical features/step_definitions/web_steps.rb
exist features/support
identical features/support/paths.rb
identical features/support/selectors.rb
identical features/support/env.rb
exist lib/tasks
identical lib/tasks/cucumber.rake
 
The Step definitions folder contains ruby files which test the steps which are mentioned in feature file of the cucumber.
 
The paths.rb file is created in the support folder will contain the rules based on which the step definitions will be compared to the steps and matched. In case we come across any steps whose execution fails while running cucumber we would have to update the paths.rb file to resolve the issue.
 
env.rb is only loaded when the application is first started up and it sets up the environment required by Cucumber to execute.
 
rails generate model article title:string content:text
rake db:migrate
rake db:test:clone
rails generate controller articles index
 
The above four commands generate models with the name article and with two fields title and content
and the next two commands migrate the db to production and the last commands creates controller for article and index objects.
 
We have to go the home directory of our rails application and then run Cucumber with the following command.The result would then be shown to the user on how many and which steps succeeded and failed.

=> cucumber
===Capybara===
<ref>[http://net.tutsplus.com/tutorials/ruby/ruby-for-newbies-testing-web-apps-with-capybara-and-cucumber Web-app with Cucumber and Capybara]</ref>

We need a tool that acts out the user stories that are part of the feature that is to be tested with Cucumber. Capybara can be used as that tool. Capybara is an integration testing tool for rack based web based applications. It simulates how a user would interact with a website. It can simulate the actions of a web browser and hence can interact with the application to receive web pages. It can also parse the HTML content and submits forms as the user would. One of the restrictions that Capybara has is that it cannot handle JavaScript. There are other tools like webdriver which can handle JavaScript but it runs a lot slower compared to Capybara.

=Comparison of Unit Test Frameworks : Rspec, Shoulda and Cucumber=

{|border="2" cellpadding="5" cellspacing="0" align="center"
|-
! scope="col" | Rspec
! scope="col" | Shoulda
! scope="col" | Cucumber

|-
|RSpec is based on the Behaviour driven development model provided by Ruby. It has its origins in Test Driven Development and Domain Driven Design.
|Shoulda is based on the Test:Unit which is another Ruby Test Framework. It is based on Test Driven Development.
|Cucumber is a combination of Test Driven Development and Behaviour driven development.
|-
|RSpec provides a Domain Specific Language that can express code functionality and behaviour.
|Shoulda provides macros, helpers and matchers.
|Cucumber allows the test cases to be written in native language of the system
|-
|RSpec too allows nested describe structure.
|Shoulda has nested contexts which helps create different environment for different set of tests.
|Cucumber is similar to RSpec also provides nested structures
|-
|RSpec is expressive when it comes to understanding functionalities since they were designed have the human readability in mind.
|Shoulda has more descriptive names compared to its predecessor Test::Unit but its less expressive.
|Cucumber test are even more descriptive and allows business stakeholder to write and read them.

|}

=Reference=
<references/>

CSC/ECE 517 Fall 2012/ch1 1w3 pl

2012-09-14T20:56:50Z

Pvasude: /* Testing a Sample Rails Application using Cucumber */

='''Unit-Testing Frameworks for Ruby: Cucumber'''=

This wiki-page serves as a knowledge source for understanding Unit-Testing Frameworks available for Ruby particularly Cucumber . 

__TOC__

=Introduction=

Unit testing is a software development process for testing individual units of source code independently for proper operation <ref>[http://en.wikipedia.org/wiki/Unit_testing Unit Testing]</ref>. An unit testing framework helps the process of unit testing by automating the test cases written to ensure the correctness of the system. They are often third-party products that are not offered as part of the suite.Ruby provides a framework in its standard library for setting up, organizing, and running tests called Test::Unit <ref>[http://en.wikibooks.org/wiki/Ruby_Programming/Unit_testing Ruby Unit Testing Framework]</ref>. Other testing frameworks available for ruby are Shoulda, RSpec and Cucumber.

=Cucumber=
Cucumber is one of the latest unit test frameworks to have come for Ruby as part of the RSpec family of tools. Cucumber itself is written in the Ruby programming language and adheres to Behaviour Driven Development(BDD). Behaviour Driven Development is an Agile Development process that comprises aspects of Acceptance Test Driven Planning , Domain Driven Design and Test Driven Development (TDD). Cucumber is designed specifically to ensure that the acceptance tests can easily be read and written by anyone.

==Behaviour Driven Development(BDD)==

Behaviour Driven Development<ref>[http://en.wikipedia.org/wiki/Behavior-driven_development BDD]</ref> preserves the basic iterative (fail-pass) workflow of TDD, but stresses on specifying behaviors that are understandable to people (say from non programming background). In this approach we write tests in a natural language that even a non-programmer can understand.

==Acceptance Test==

Acceptance Test<ref>[http://en.wikipedia.org/wiki/Acceptance_testing Acceptance Test]</ref><ref>[http://pragprog.com/book/hwcuc/the-cucumber-book Cucumber Book]</ref> Drive Planning is a practice that stresses on the importance of identifying the functions and requirements of the software beforehand so that we exactly know when the development phase ends. This practice results in fewer bugs , shorter delivery times and greater customer satisfaction.

===Cucumber Acceptance Test===

Feature: Sign up
Sign up should be quick and friendly. 
Scenario: Successful sign up
New users should get a confirmation email and be greeted personally by the site once signed in.
Given I have chosen to sign up
When I sign up with valid details
Then I should receive a confirmation email
And I should see a personalized greeting message 
Scenario: Duplicate email
Where someone tries to create an account for an email address that already exists.
Given I have chosen to sign up
But I enter an email address that has already registered
Then I should be told that the email is already registered
And I should be offered the option to recover my password

Acceptance tests written in this style are more than just tests; they are executable specifications. As of January 2012, Cucumber was the second most popular testing framework after RSpec for Ruby

==How Cucumber works==

Cucumber is a command-line tool. It reads in specifications from plain-language text files called features, examines them for scenarios to test, and runs the scenarios against the system. The feature files should be written according to specific syntax rules called Gherkin. Along with the features, you give Cucumber a set of step definitions, which map the business-readable language of each step into Ruby code to carry out whatever action is being described by the step. Cucumber takes customer understandable user stories as input and does integration and acceptance tests on the system with those as its input.

===Feature===
A Feature is a high level statement of the what the test case does and there is only one feature per user story. For every feature that is supported by the system , a separate feature file has to be written and included in the features directory. The feature files has .feature file extension.

===Scenario===
A Scenario consists of one or more steps which describe about the various actions performed by the user with respect to this particular feature. There can be one or more scenarios per feature in a user story. A feature usually contains 3 to 8 steps in it. The steps of the scenario always begin with one of the below mentioned key words :

1. Given : Steps that begin with given represent the state of the world before an event.(preconditions) 
2. When : Steps that represent the event. 
3. Then : Steps that represent the expected outcome. 
4. And and But : Steps that extend the previous step. 

===Step and Step Definitions===
When testing with Cucumber , The user stories are all kept in one set of files called Steps.The Steps are compared with Step Definitions which are files written in ruby which gives the rules based on which the steps are executed. Step definitions are analogous to method definitions and steps of scenarios are analogous to method calls. Cucumber uses regular expressions to match the English phrases in the steps of scenarios to step definitions.

When the cucumber test framework is run , The steps present in the feature file can be classified as follows based on the result of regex matching with the step definitions.<ref>[https://github.com/cucumber/cucumber/wiki/Step-Definitions Step Definitions in Ruby]</ref>

====Successful steps====
When Cucumber finds a matching Step Definition it will execute it. If the block in the step definition doesn’t raise an Exception, the step is marked as successful (green). What you return from a Step Definition has no significance what so ever.

====Undefined steps====
When Cucumber can’t find a matching Step Definition the step gets marked as yellow, and all subsequent steps in the scenario are skipped. If you use --strict this will cause Cucumber to exit with 1.

====Pending steps====
When a Step Definition’s Proc invokes the #pending method, the step is marked as yellow (as with undefined ones), reminding you that you have work to do. If you use --strict this will cause Cucumber to exit with 1.

====Failed steps====
When a Step Definition’s Proc is executed and raises an error, the step is marked as red. Returning nil or false will not cause a step definition to fail.

Cucumber tries to run the steps based on the definitions and thus colors steps based on the execution of the steps. The colors for the steps assigned are as follows : 
 
1. Green : for passing. 
2. Yellow : for not yet implemented. 
3. Red : for failing. 
4. Blue : Once a step fails all the successive steps are marked in blue. 

==Cucumber Testing Stack==
/* Some Content */

[[File:Cucumber.JPG|500px|thumb|right|Cucumber Testing Stack]]

==Advantages of Cucumber==
*Specifications can be written in more than forty different spoken languages.
*Cucumber helps reduce the gap between technical and non-technical members of a software team.
*Cucumber tests can be easily read and written by business stakeholders.
*Writing Cucumber tests are quick, easy, efficient and understandable.

=Cucumber Installation=
<ref>[http://cuke4ninja.com/sec_ruby_install_cucumber.html Installing Cucumber]</ref>

To install cucumber we should make sure that the Environment path is set to “..../Ruby/bin”. Then open the command prompt and run

gem install cucumber

Once cucumber gem is installed then we would be able to check whether it is installed by issuing the following command:

cucumber --version

this should give a version number like “1.2.1”

Cucumber uses Rspec for assertions and hence we need Rspec installed to use Cucumber. Use the following command to install rspec

gem install rspec

=Testing a Sample Ruby Application using Cucumber=
<ref>[http://pragprog.com/book/hwcuc/the-cucumber-book Sample Cucumber Application]</ref>

Step 1 : Create a new directory

mkdir HelloCucumber

Step 2 : Install Cucumber and Rspec

gem install cucumber
gem instal rspec

Step 3 : Create a directory features and create a file basic.feature in the features directory

mkdir features

Content of features/basic.feature

Feature: Hello World Feature 
Scenario: Hello World Scenario
Given The Action is Hello
When The Subject is World
Then The Greeting is Hello, World

Step 4: Create step_definitions directory inside features directory. Create basic_step.rb file inside step_definitions.

mkdir features/step_definitions

Content of features/step_definitions/basic_step.rb

require 'rspec/expectations' 
Given /The Action is ([A-z]*)/ do |action|
@action = action
end 
When /The Subject is ([A-z]*)/ do |subject|
@subject = subject
end 
Then /The Greeting is (.*)/ do |greeting|
greeting.should == "#{@action}, #{@subject}"
end
Cucumber uses regular expression after the keywords Given, When and Then to map lines in a feature file to step definitions.

Step 5: Running cucumber command you will see the following output

Feature: Hello World Feature 
Scenario: Hello World Scenario # features\basic.feature:3
Given The Action is Hello # features/step_definitions/basic_steps.rb:3
When The Subject is World # features/step_definitions/basic_steps.rb:7
Then The Greeting is Hello, World # features/step_definitions/basic_steps.rb:11 

1 scenario (1 passed)
3 steps (3 passed)
0m0.016s
Step 6 : Modify the basic.features file to include 2 scenario

Step 6 : Modify the basic.features file to include 2 scenarios

Feature: Hello World Feature 
Scenario: Hello World Scenario
Given The Action is Hello
When The Subject is World
Then The Greeting is Hello, World 
Scenario: Bye World Scenario
Given The Action is Bye
When The Subject is World
Then The Greeting is Hello, World

Step 7 : Running the cucumber command you will see the following output

Scenario: Hello World Scenario # features\basic.feature:3
Given The Action is Hello # features/step_definitions/basic_steps.rb:3
When The Subject is World # features/step_definitions/basic_steps.rb:7
Then The Greeting is Hello, World # features/step_definitions/basic_steps.rb:11 
Scenario: Bye World Scenario # features\basic.feature:8
Given The Action is Bye # features/step_definitions/basic_steps.rb:3
When The Subject is World # features/step_definitions/basic_steps.rb:7
Then The Greeting is Hello, World # features/step_definitions/basic_steps.rb:11
expected: "Bye, World"
got: "Hello, World" (using ==) (RSpec::Expectations::ExpectationNotMetError)
./features/step_definitions/basic_steps.rb:12:in `/The Greeting is (.*)/'
features\basic.feature:11:in `Then The Greeting is Hello, World' 
Failing Scenarios:
cucumber features\basic.feature:8 # Scenario: Bye World Scenario 
2 scenarios (1 failed, 1 passed)
6 steps (1 failed, 5 passed)
0m0.033s

The Bye Scenario fails since the expected output is “Hello, World” but the received output is “Bye,World”.

=Testing a Sample Rails Application using Cucumber=
<ref>[http://railscasts.com/episodes/155-beginning-with-cucumber Sample Cucumber Application on Rails]</ref>

Cucumber easily integrates with Rails and hence can be used with Ruby applications which run on Rails. But there are a few steps which have to be followed before integrating cucumber with Rails. Lets walk through it by creating a new rails application.

rails new cucumber_app
 

For using cucumber we need to have the following gems
 
gem install cucumber
gem install cucumber cucumber-rails
 
We would have to then give “bundle install” command to install these new gems. We would then have to update the Gemfile to include these gems in the test group since they will be needed only in the test environment. There are a few other gems which are required for cucumber namely database_cleaner , rspec-rails and webrat.
 
group :test do
gem 'database_cleaner'
gem 'cucumber'
gem "rspec-rails", "~> 2.0", :require => false
gem "cucumber-rails", "1.0.6"
gem 'webrat'
end
 
Cucumber required files can then be created by giving the following command. The output below the command shows the folders and files that get created for the cucumber test framework.

rails generate cucumber:install
 
identical script/cucumber
chmod script/cucumber
exist features/step_definitions
identical features/step_definitions/web_steps.rb
exist features/support
identical features/support/paths.rb
identical features/support/selectors.rb
identical features/support/env.rb
exist lib/tasks
identical lib/tasks/cucumber.rake
 
The Step definitions folder contains ruby files which test the steps which are mentioned in feature file of the cucumber.
 
The paths.rb file is created in the support folder will contain the rules based on which the step definitions will be compared to the steps and matched. In case we come across any steps whose execution fails while running cucumber we would have to update the paths.rb file to resolve the issue.
 
env.rb is only loaded when the application is first started up and it sets up the environment required by Cucumber to execute.
 
rails generate model article title:string content:text
rake db:migrate
rake db:test:clone
rails generate controller articles index
 
The above four commands generate models with the name article and with two fields title and content
and the next two commands migrate the db to production and the last commands creates controller for article and index objects.
 
We have to go the home directory of our rails application and then run Cucumber with the following command.The result would then be shown to the user on how many and which steps succeeded and failed.

=> cucumber
===Capybara===
<ref>[http://net.tutsplus.com/tutorials/ruby/ruby-for-newbies-testing-web-apps-with-capybara-and-cucumber Web-app with Cucumber and Capybara]</ref>

We need a tool that acts out the user stories that are part of the feature that is to be tested with Cucumber. Capybara can be used as that tool. Capybara is an integration testing tool for rack based web based applications. It simulates how a user would interact with a website. It can simulate the actions of a web browser and hence can interact with the application to receive web pages. It can also parse the HTML content and submits forms as the user would. One of the restrictions that Capybara has is that it cannot handle JavaScript. There are other tools like webdriver which can handle JavaScript but it runs a lot slower compared to Capybara.

=Comparison of Unit Test Frameworks : Rspec, Shoulda and Cucumber=

{|border="2" cellpadding="5" cellspacing="0" align="center"
|-
! scope="col" | Rspec
! scope="col" | Shoulda
! scope="col" | Cucumber

|-
|RSpec is based on the Behaviour driven development model provided by Ruby. It has its origins in Test Driven Development and Domain Driven Design.
|Shoulda is based on the Test:Unit which is another Ruby Test Framework. It is based on Test Driven Development.
|Cucumber is a combination of Test Driven Development and Behaviour driven development.
|-
|RSpec provides a Domain Specific Language that can express code functionality and behaviour.
|Shoulda provides macros, helpers and matchers.
|Cucumber allows the test cases to be written in native language of the system
|-
|RSpec too allows nested describe structure.
|Shoulda has nested contexts which helps create different environment for different set of tests.
|Cucumber is similar to RSpec also provides nested structures
|-
|RSpec is expressive when it comes to understanding functionalities since they were designed have the human readability in mind.
|Shoulda has more descriptive names compared to its predecessor Test::Unit but its less expressive.
|Cucumber test are even more descriptive and allows business stakeholder to write and read them.

|}

=Reference=
<references/>

CSC/ECE 517 Fall 2012/ch1 1w3 pl

2012-09-14T20:55:22Z

Pvasude: /* Testing a Sample Rails Application using Cucumber */

='''Unit-Testing Frameworks for Ruby: Cucumber'''=

This wiki-page serves as a knowledge source for understanding Unit-Testing Frameworks available for Ruby particularly Cucumber . 

__TOC__

=Introduction=

Unit testing is a software development process for testing individual units of source code independently for proper operation <ref>[http://en.wikipedia.org/wiki/Unit_testing Unit Testing]</ref>. An unit testing framework helps the process of unit testing by automating the test cases written to ensure the correctness of the system. They are often third-party products that are not offered as part of the suite.Ruby provides a framework in its standard library for setting up, organizing, and running tests called Test::Unit <ref>[http://en.wikibooks.org/wiki/Ruby_Programming/Unit_testing Ruby Unit Testing Framework]</ref>. Other testing frameworks available for ruby are Shoulda, RSpec and Cucumber.

=Cucumber=
Cucumber is one of the latest unit test frameworks to have come for Ruby as part of the RSpec family of tools. Cucumber itself is written in the Ruby programming language and adheres to Behaviour Driven Development(BDD). Behaviour Driven Development is an Agile Development process that comprises aspects of Acceptance Test Driven Planning , Domain Driven Design and Test Driven Development (TDD). Cucumber is designed specifically to ensure that the acceptance tests can easily be read and written by anyone.

==Behaviour Driven Development(BDD)==

Behaviour Driven Development<ref>[http://en.wikipedia.org/wiki/Behavior-driven_development BDD]</ref> preserves the basic iterative (fail-pass) workflow of TDD, but stresses on specifying behaviors that are understandable to people (say from non programming background). In this approach we write tests in a natural language that even a non-programmer can understand.

==Acceptance Test==

Acceptance Test<ref>[http://en.wikipedia.org/wiki/Acceptance_testing Acceptance Test]</ref><ref>[http://pragprog.com/book/hwcuc/the-cucumber-book Cucumber Book]</ref> Drive Planning is a practice that stresses on the importance of identifying the functions and requirements of the software beforehand so that we exactly know when the development phase ends. This practice results in fewer bugs , shorter delivery times and greater customer satisfaction.

===Cucumber Acceptance Test===

Feature: Sign up
Sign up should be quick and friendly. 
Scenario: Successful sign up
New users should get a confirmation email and be greeted personally by the site once signed in.
Given I have chosen to sign up
When I sign up with valid details
Then I should receive a confirmation email
And I should see a personalized greeting message 
Scenario: Duplicate email
Where someone tries to create an account for an email address that already exists.
Given I have chosen to sign up
But I enter an email address that has already registered
Then I should be told that the email is already registered
And I should be offered the option to recover my password

Acceptance tests written in this style are more than just tests; they are executable specifications. As of January 2012, Cucumber was the second most popular testing framework after RSpec for Ruby

==How Cucumber works==

Cucumber is a command-line tool. It reads in specifications from plain-language text files called features, examines them for scenarios to test, and runs the scenarios against the system. The feature files should be written according to specific syntax rules called Gherkin. Along with the features, you give Cucumber a set of step definitions, which map the business-readable language of each step into Ruby code to carry out whatever action is being described by the step. Cucumber takes customer understandable user stories as input and does integration and acceptance tests on the system with those as its input.

===Feature===
A Feature is a high level statement of the what the test case does and there is only one feature per user story. For every feature that is supported by the system , a separate feature file has to be written and included in the features directory. The feature files has .feature file extension.

===Scenario===
A Scenario consists of one or more steps which describe about the various actions performed by the user with respect to this particular feature. There can be one or more scenarios per feature in a user story. A feature usually contains 3 to 8 steps in it. The steps of the scenario always begin with one of the below mentioned key words :

1. Given : Steps that begin with given represent the state of the world before an event.(preconditions) 
2. When : Steps that represent the event. 
3. Then : Steps that represent the expected outcome. 
4. And and But : Steps that extend the previous step. 

===Step and Step Definitions===
When testing with Cucumber , The user stories are all kept in one set of files called Steps.The Steps are compared with Step Definitions which are files written in ruby which gives the rules based on which the steps are executed. Step definitions are analogous to method definitions and steps of scenarios are analogous to method calls. Cucumber uses regular expressions to match the English phrases in the steps of scenarios to step definitions.

When the cucumber test framework is run , The steps present in the feature file can be classified as follows based on the result of regex matching with the step definitions.<ref>[https://github.com/cucumber/cucumber/wiki/Step-Definitions Step Definitions in Ruby]</ref>

====Successful steps====
When Cucumber finds a matching Step Definition it will execute it. If the block in the step definition doesn’t raise an Exception, the step is marked as successful (green). What you return from a Step Definition has no significance what so ever.

====Undefined steps====
When Cucumber can’t find a matching Step Definition the step gets marked as yellow, and all subsequent steps in the scenario are skipped. If you use --strict this will cause Cucumber to exit with 1.

====Pending steps====
When a Step Definition’s Proc invokes the #pending method, the step is marked as yellow (as with undefined ones), reminding you that you have work to do. If you use --strict this will cause Cucumber to exit with 1.

====Failed steps====
When a Step Definition’s Proc is executed and raises an error, the step is marked as red. Returning nil or false will not cause a step definition to fail.

Cucumber tries to run the steps based on the definitions and thus colors steps based on the execution of the steps. The colors for the steps assigned are as follows : 
 
1. Green : for passing. 
2. Yellow : for not yet implemented. 
3. Red : for failing. 
4. Blue : Once a step fails all the successive steps are marked in blue. 

==Cucumber Testing Stack==
/* Some Content */

[[File:Cucumber.JPG|500px|thumb|right|Cucumber Testing Stack]]

==Advantages of Cucumber==
*Specifications can be written in more than forty different spoken languages.
*Cucumber helps reduce the gap between technical and non-technical members of a software team.
*Cucumber tests can be easily read and written by business stakeholders.
*Writing Cucumber tests are quick, easy, efficient and understandable.

=Cucumber Installation=
<ref>[http://cuke4ninja.com/sec_ruby_install_cucumber.html Installing Cucumber]</ref>

To install cucumber we should make sure that the Environment path is set to “..../Ruby/bin”. Then open the command prompt and run

gem install cucumber

Once cucumber gem is installed then we would be able to check whether it is installed by issuing the following command:

cucumber --version

this should give a version number like “1.2.1”

Cucumber uses Rspec for assertions and hence we need Rspec installed to use Cucumber. Use the following command to install rspec

gem install rspec

=Testing a Sample Ruby Application using Cucumber=
<ref>[http://pragprog.com/book/hwcuc/the-cucumber-book Sample Cucumber Application]</ref>

Step 1 : Create a new directory

mkdir HelloCucumber

Step 2 : Install Cucumber and Rspec

gem install cucumber
gem instal rspec

Step 3 : Create a directory features and create a file basic.feature in the features directory

mkdir features

Content of features/basic.feature

Feature: Hello World Feature 
Scenario: Hello World Scenario
Given The Action is Hello
When The Subject is World
Then The Greeting is Hello, World

Step 4: Create step_definitions directory inside features directory. Create basic_step.rb file inside step_definitions.

mkdir features/step_definitions

Content of features/step_definitions/basic_step.rb

require 'rspec/expectations' 
Given /The Action is ([A-z]*)/ do |action|
@action = action
end 
When /The Subject is ([A-z]*)/ do |subject|
@subject = subject
end 
Then /The Greeting is (.*)/ do |greeting|
greeting.should == "#{@action}, #{@subject}"
end
Cucumber uses regular expression after the keywords Given, When and Then to map lines in a feature file to step definitions.

Step 5: Running cucumber command you will see the following output

Feature: Hello World Feature 
Scenario: Hello World Scenario # features\basic.feature:3
Given The Action is Hello # features/step_definitions/basic_steps.rb:3
When The Subject is World # features/step_definitions/basic_steps.rb:7
Then The Greeting is Hello, World # features/step_definitions/basic_steps.rb:11 

1 scenario (1 passed)
3 steps (3 passed)
0m0.016s
Step 6 : Modify the basic.features file to include 2 scenario

Step 6 : Modify the basic.features file to include 2 scenarios

Feature: Hello World Feature 
Scenario: Hello World Scenario
Given The Action is Hello
When The Subject is World
Then The Greeting is Hello, World 
Scenario: Bye World Scenario
Given The Action is Bye
When The Subject is World
Then The Greeting is Hello, World

Step 7 : Running the cucumber command you will see the following output

Scenario: Hello World Scenario # features\basic.feature:3
Given The Action is Hello # features/step_definitions/basic_steps.rb:3
When The Subject is World # features/step_definitions/basic_steps.rb:7
Then The Greeting is Hello, World # features/step_definitions/basic_steps.rb:11 
Scenario: Bye World Scenario # features\basic.feature:8
Given The Action is Bye # features/step_definitions/basic_steps.rb:3
When The Subject is World # features/step_definitions/basic_steps.rb:7
Then The Greeting is Hello, World # features/step_definitions/basic_steps.rb:11
expected: "Bye, World"
got: "Hello, World" (using ==) (RSpec::Expectations::ExpectationNotMetError)
./features/step_definitions/basic_steps.rb:12:in `/The Greeting is (.*)/'
features\basic.feature:11:in `Then The Greeting is Hello, World' 
Failing Scenarios:
cucumber features\basic.feature:8 # Scenario: Bye World Scenario 
2 scenarios (1 failed, 1 passed)
6 steps (1 failed, 5 passed)
0m0.033s

The Bye Scenario fails since the expected output is “Hello, World” but the received output is “Bye,World”.

=Testing a Sample Rails Application using Cucumber=
<ref>[http://railscasts.com/episodes/155-beginning-with-cucumber Sample Cucumber Application on Rails]</ref>

Cucumber easily integrates with Rails and hence can be used with Ruby applications which run on Rails. But there are a few steps which have to be followed before integrating cucumber with Rails. Lets walk through it by creating a new rails application.

rails new cucumber_app
 
and the new applications with its folders get created.

we would have to install the gems required for running Cucumber with Rails and there are couple of gems that are required and they can be installed with the following command :
 
gem install cucumber
gem install cucumber cucumber-rails
 
We would have to then give “bundle install” command to install these new gems. We would then have to update the Gemfile to include these gems in the test group since they will be needed only in the test environment. There are a few other gems which are required for cucumber namely database_cleaner , rspec-rails and webrat.
 
group :test do
gem 'database_cleaner'
gem 'cucumber'
gem "rspec-rails", "~> 2.0", :require => false
gem "cucumber-rails", "1.0.6"
gem 'webrat'
end
 
Cucumber required files can then be created by giving the following command. The output below the command shows the folders and files that get created for the cucumber test framework.

rails generate cucumber:install
 
identical script/cucumber
chmod script/cucumber
exist features/step_definitions
identical features/step_definitions/web_steps.rb
exist features/support
identical features/support/paths.rb
identical features/support/selectors.rb
identical features/support/env.rb
exist lib/tasks
identical lib/tasks/cucumber.rake
 
The Step definitions folder contains ruby files which test the steps which are mentioned in feature file of the cucumber.
 
The paths.rb file is created in the support folder will contain the rules based on which the step definitions will be compared to the steps and matched. In case we come across any steps whose execution fails while running cucumber we would have to update the paths.rb file to resolve the issue.
 
env.rb is only loaded when the application is first started up and it sets up the environment required by Cucumber to execute.
 
rails generate model article title:string content:text
rake db:migrate
rake db:test:clone
rails generate controller articles index
 
The above four commands generate models with the name article and with two fields title and content
and the next two commands migrate the db to production and the last commands creates controller for article and index objects.
 
We have to go the home directory of our rails application and then run Cucumber with the following command.The result would then be shown to the user on how many and which steps succeeded and failed.

=> cucumber
===Capybara===
<ref>[http://net.tutsplus.com/tutorials/ruby/ruby-for-newbies-testing-web-apps-with-capybara-and-cucumber Web-app with Cucumber and Capybara]</ref>

We need a tool that acts out the user stories that are part of the feature that is to be tested with Cucumber. Capybara can be used as that tool. Capybara is an integration testing tool for rack based web based applications. It simulates how a user would interact with a website. It can simulate the actions of a web browser and hence can interact with the application to receive web pages. It can also parse the HTML content and submits forms as the user would. One of the restrictions that Capybara has is that it cannot handle JavaScript. There are other tools like webdriver which can handle JavaScript but it runs a lot slower compared to Capybara.

=Comparison of Unit Test Frameworks : Rspec, Shoulda and Cucumber=

{|border="2" cellpadding="5" cellspacing="0" align="center"
|-
! scope="col" | Rspec
! scope="col" | Shoulda
! scope="col" | Cucumber

|-
|RSpec is based on the Behaviour driven development model provided by Ruby. It has its origins in Test Driven Development and Domain Driven Design.
|Shoulda is based on the Test:Unit which is another Ruby Test Framework. It is based on Test Driven Development.
|Cucumber is a combination of Test Driven Development and Behaviour driven development.
|-
|RSpec provides a Domain Specific Language that can express code functionality and behaviour.
|Shoulda provides macros, helpers and matchers.
|Cucumber allows the test cases to be written in native language of the system
|-
|RSpec too allows nested describe structure.
|Shoulda has nested contexts which helps create different environment for different set of tests.
|Cucumber is similar to RSpec also provides nested structures
|-
|RSpec is expressive when it comes to understanding functionalities since they were designed have the human readability in mind.
|Shoulda has more descriptive names compared to its predecessor Test::Unit but its less expressive.
|Cucumber test are even more descriptive and allows business stakeholder to write and read them.

|}

=Reference=
<references/>

CSC/ECE 517 Fall 2012/ch1 1w3 pl

2012-09-14T20:53:37Z

Pvasude: /* Testing a Sample Ruby Application using Cucumber */

='''Unit-Testing Frameworks for Ruby: Cucumber'''=

This wiki-page serves as a knowledge source for understanding Unit-Testing Frameworks available for Ruby particularly Cucumber . 

__TOC__

=Introduction=

Unit testing is a software development process for testing individual units of source code independently for proper operation <ref>[http://en.wikipedia.org/wiki/Unit_testing Unit Testing]</ref>. An unit testing framework helps the process of unit testing by automating the test cases written to ensure the correctness of the system. They are often third-party products that are not offered as part of the suite.Ruby provides a framework in its standard library for setting up, organizing, and running tests called Test::Unit <ref>[http://en.wikibooks.org/wiki/Ruby_Programming/Unit_testing Ruby Unit Testing Framework]</ref>. Other testing frameworks available for ruby are Shoulda, RSpec and Cucumber.

=Cucumber=
Cucumber is one of the latest unit test frameworks to have come for Ruby as part of the RSpec family of tools. Cucumber itself is written in the Ruby programming language and adheres to Behaviour Driven Development(BDD). Behaviour Driven Development is an Agile Development process that comprises aspects of Acceptance Test Driven Planning , Domain Driven Design and Test Driven Development (TDD). Cucumber is designed specifically to ensure that the acceptance tests can easily be read and written by anyone.

==Behaviour Driven Development(BDD)==

Behaviour Driven Development<ref>[http://en.wikipedia.org/wiki/Behavior-driven_development BDD]</ref> preserves the basic iterative (fail-pass) workflow of TDD, but stresses on specifying behaviors that are understandable to people (say from non programming background). In this approach we write tests in a natural language that even a non-programmer can understand.

==Acceptance Test==

Acceptance Test<ref>[http://en.wikipedia.org/wiki/Acceptance_testing Acceptance Test]</ref><ref>[http://pragprog.com/book/hwcuc/the-cucumber-book Cucumber Book]</ref> Drive Planning is a practice that stresses on the importance of identifying the functions and requirements of the software beforehand so that we exactly know when the development phase ends. This practice results in fewer bugs , shorter delivery times and greater customer satisfaction.

===Cucumber Acceptance Test===

Feature: Sign up
Sign up should be quick and friendly. 
Scenario: Successful sign up
New users should get a confirmation email and be greeted personally by the site once signed in.
Given I have chosen to sign up
When I sign up with valid details
Then I should receive a confirmation email
And I should see a personalized greeting message 
Scenario: Duplicate email
Where someone tries to create an account for an email address that already exists.
Given I have chosen to sign up
But I enter an email address that has already registered
Then I should be told that the email is already registered
And I should be offered the option to recover my password

Acceptance tests written in this style are more than just tests; they are executable specifications. As of January 2012, Cucumber was the second most popular testing framework after RSpec for Ruby

==How Cucumber works==

Cucumber is a command-line tool. It reads in specifications from plain-language text files called features, examines them for scenarios to test, and runs the scenarios against the system. The feature files should be written according to specific syntax rules called Gherkin. Along with the features, you give Cucumber a set of step definitions, which map the business-readable language of each step into Ruby code to carry out whatever action is being described by the step. Cucumber takes customer understandable user stories as input and does integration and acceptance tests on the system with those as its input.

===Feature===
A Feature is a high level statement of the what the test case does and there is only one feature per user story. For every feature that is supported by the system , a separate feature file has to be written and included in the features directory. The feature files has .feature file extension.

===Scenario===
A Scenario consists of one or more steps which describe about the various actions performed by the user with respect to this particular feature. There can be one or more scenarios per feature in a user story. A feature usually contains 3 to 8 steps in it. The steps of the scenario always begin with one of the below mentioned key words :

1. Given : Steps that begin with given represent the state of the world before an event.(preconditions) 
2. When : Steps that represent the event. 
3. Then : Steps that represent the expected outcome. 
4. And and But : Steps that extend the previous step. 

===Step and Step Definitions===
When testing with Cucumber , The user stories are all kept in one set of files called Steps.The Steps are compared with Step Definitions which are files written in ruby which gives the rules based on which the steps are executed. Step definitions are analogous to method definitions and steps of scenarios are analogous to method calls. Cucumber uses regular expressions to match the English phrases in the steps of scenarios to step definitions.

When the cucumber test framework is run , The steps present in the feature file can be classified as follows based on the result of regex matching with the step definitions.<ref>[https://github.com/cucumber/cucumber/wiki/Step-Definitions Step Definitions in Ruby]</ref>

====Successful steps====
When Cucumber finds a matching Step Definition it will execute it. If the block in the step definition doesn’t raise an Exception, the step is marked as successful (green). What you return from a Step Definition has no significance what so ever.

====Undefined steps====
When Cucumber can’t find a matching Step Definition the step gets marked as yellow, and all subsequent steps in the scenario are skipped. If you use --strict this will cause Cucumber to exit with 1.

====Pending steps====
When a Step Definition’s Proc invokes the #pending method, the step is marked as yellow (as with undefined ones), reminding you that you have work to do. If you use --strict this will cause Cucumber to exit with 1.

====Failed steps====
When a Step Definition’s Proc is executed and raises an error, the step is marked as red. Returning nil or false will not cause a step definition to fail.

Cucumber tries to run the steps based on the definitions and thus colors steps based on the execution of the steps. The colors for the steps assigned are as follows : 
 
1. Green : for passing. 
2. Yellow : for not yet implemented. 
3. Red : for failing. 
4. Blue : Once a step fails all the successive steps are marked in blue. 

==Cucumber Testing Stack==
/* Some Content */

[[File:Cucumber.JPG|500px|thumb|right|Cucumber Testing Stack]]

==Advantages of Cucumber==
*Specifications can be written in more than forty different spoken languages.
*Cucumber helps reduce the gap between technical and non-technical members of a software team.
*Cucumber tests can be easily read and written by business stakeholders.
*Writing Cucumber tests are quick, easy, efficient and understandable.

=Cucumber Installation=
<ref>[http://cuke4ninja.com/sec_ruby_install_cucumber.html Installing Cucumber]</ref>

To install cucumber we should make sure that the Environment path is set to “..../Ruby/bin”. Then open the command prompt and run

gem install cucumber

Once cucumber gem is installed then we would be able to check whether it is installed by issuing the following command:

cucumber --version

this should give a version number like “1.2.1”

Cucumber uses Rspec for assertions and hence we need Rspec installed to use Cucumber. Use the following command to install rspec

gem install rspec

=Testing a Sample Ruby Application using Cucumber=
<ref>[http://pragprog.com/book/hwcuc/the-cucumber-book Sample Cucumber Application]</ref>

Step 1 : Create a new directory

mkdir HelloCucumber

Step 2 : Install Cucumber and Rspec

gem install cucumber
gem instal rspec

Step 3 : Create a directory features and create a file basic.feature in the features directory

mkdir features

Content of features/basic.feature

Feature: Hello World Feature 
Scenario: Hello World Scenario
Given The Action is Hello
When The Subject is World
Then The Greeting is Hello, World

Step 4: Create step_definitions directory inside features directory. Create basic_step.rb file inside step_definitions.

mkdir features/step_definitions

Content of features/step_definitions/basic_step.rb

require 'rspec/expectations' 
Given /The Action is ([A-z]*)/ do |action|
@action = action
end 
When /The Subject is ([A-z]*)/ do |subject|
@subject = subject
end 
Then /The Greeting is (.*)/ do |greeting|
greeting.should == "#{@action}, #{@subject}"
end
Cucumber uses regular expression after the keywords Given, When and Then to map lines in a feature file to step definitions.

Step 5: Running cucumber command you will see the following output

Feature: Hello World Feature 
Scenario: Hello World Scenario # features\basic.feature:3
Given The Action is Hello # features/step_definitions/basic_steps.rb:3
When The Subject is World # features/step_definitions/basic_steps.rb:7
Then The Greeting is Hello, World # features/step_definitions/basic_steps.rb:11 

1 scenario (1 passed)
3 steps (3 passed)
0m0.016s
Step 6 : Modify the basic.features file to include 2 scenario

Step 6 : Modify the basic.features file to include 2 scenarios

Feature: Hello World Feature 
Scenario: Hello World Scenario
Given The Action is Hello
When The Subject is World
Then The Greeting is Hello, World 
Scenario: Bye World Scenario
Given The Action is Bye
When The Subject is World
Then The Greeting is Hello, World

Step 7 : Running the cucumber command you will see the following output

Scenario: Hello World Scenario # features\basic.feature:3
Given The Action is Hello # features/step_definitions/basic_steps.rb:3
When The Subject is World # features/step_definitions/basic_steps.rb:7
Then The Greeting is Hello, World # features/step_definitions/basic_steps.rb:11 
Scenario: Bye World Scenario # features\basic.feature:8
Given The Action is Bye # features/step_definitions/basic_steps.rb:3
When The Subject is World # features/step_definitions/basic_steps.rb:7
Then The Greeting is Hello, World # features/step_definitions/basic_steps.rb:11
expected: "Bye, World"
got: "Hello, World" (using ==) (RSpec::Expectations::ExpectationNotMetError)
./features/step_definitions/basic_steps.rb:12:in `/The Greeting is (.*)/'
features\basic.feature:11:in `Then The Greeting is Hello, World' 
Failing Scenarios:
cucumber features\basic.feature:8 # Scenario: Bye World Scenario 
2 scenarios (1 failed, 1 passed)
6 steps (1 failed, 5 passed)
0m0.033s

The Bye Scenario fails since the expected output is “Hello, World” but the received output is “Bye,World”.

=Testing a Sample Rails Application using Cucumber=
<ref>[http://railscasts.com/episodes/155-beginning-with-cucumber Sample Cucumber Application on Rails]</ref>

Cucumber easily integrates with Rails and hence can be used with Ruby applications which run on Rails. But there are a few steps which have to be followed before integrating cucumber with Rails. Let us consider we create a new applications using the following command :

rails new cucumber_app
 
and the new applications with its folders get created.

we would have to install the gems required for running Cucumber with Rails and there are couple of gems that are required and they can be installed with the following command :
 
gem install cucumber
gem install cucumber cucumber-rails
 
We would have to then give “bundle install” command to install these new gems. We would then have to update the Gemfile to include these gems in the test group since they will be needed only in the test environment. There are a few other gems which are required for cucumber namely database_cleaner , rspec-rails and webrat.
 
group :test do
gem 'database_cleaner'
gem 'cucumber'
gem "rspec-rails", "~> 2.0", :require => false
gem "cucumber-rails", "1.0.6"
gem 'webrat'
end
 
Cucumber required files can then be created by giving the following command. The output below the command shows the folders and files that get created for the cucumber test framework.

rails generate cucumber:install
 
identical script/cucumber
chmod script/cucumber
exist features/step_definitions
identical features/step_definitions/web_steps.rb
exist features/support
identical features/support/paths.rb
identical features/support/selectors.rb
identical features/support/env.rb
exist lib/tasks
identical lib/tasks/cucumber.rake
 
The Step definitions folder contains ruby files which test the steps which are mentioned in feature file of the cucumber.
 
The paths.rb file is created in the support folder will contain the rules based on which the step definitions will be compared to the steps and matched. In case we come across any steps whose execution fails while running cucumber we would have to update the paths.rb file to resolve the issue.
 
env.rb is only loaded when the application is first started up and it sets up the environment required by Cucumber to execute.
 
rails generate model article title:string content:text
rake db:migrate
rake db:test:clone
rails generate controller articles index
 
The above four commands generate models with the name article and with two fields title and content
and the next two commands migrate the db to production and the last commands creates controller for article and index objects.
 
We have to go the home directory of our rails application and then run Cucumber with the following command.The result would then be shown to the user on how many and which steps succeeded and failed.

=> cucumber
===Capybara===
<ref>[http://net.tutsplus.com/tutorials/ruby/ruby-for-newbies-testing-web-apps-with-capybara-and-cucumber Web-app with Cucumber and Capybara]</ref>

We need a tool that acts out the user stories that are part of the feature that is to be tested with Cucumber. Capybara can be used as that tool. Capybara is an integration testing tool for rack based web based applications. It simulates how a user would interact with a website. It can simulate the actions of a web browser and hence can interact with the application to receive web pages. It can also parse the HTML content and submits forms as the user would. One of the restrictions that Capybara has is that it cannot handle JavaScript. There are other tools like webdriver which can handle JavaScript but it runs a lot slower compared to Capybara.

=Comparison of Unit Test Frameworks : Rspec, Shoulda and Cucumber=

{|border="2" cellpadding="5" cellspacing="0" align="center"
|-
! scope="col" | Rspec
! scope="col" | Shoulda
! scope="col" | Cucumber

|-
|RSpec is based on the Behaviour driven development model provided by Ruby. It has its origins in Test Driven Development and Domain Driven Design.
|Shoulda is based on the Test:Unit which is another Ruby Test Framework. It is based on Test Driven Development.
|Cucumber is a combination of Test Driven Development and Behaviour driven development.
|-
|RSpec provides a Domain Specific Language that can express code functionality and behaviour.
|Shoulda provides macros, helpers and matchers.
|Cucumber allows the test cases to be written in native language of the system
|-
|RSpec too allows nested describe structure.
|Shoulda has nested contexts which helps create different environment for different set of tests.
|Cucumber is similar to RSpec also provides nested structures
|-
|RSpec is expressive when it comes to understanding functionalities since they were designed have the human readability in mind.
|Shoulda has more descriptive names compared to its predecessor Test::Unit but its less expressive.
|Cucumber test are even more descriptive and allows business stakeholder to write and read them.

|}

=Reference=
<references/>