Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2009/wiki3 17 am

2009-12-01T06:12:53Z

Mjampal: /* Conclusions */

=='''Single Choice Principle'''==
===Introduction===

Single Choice Principle states that whenever a software system must support a set of alternatives, one and only one module in the system should know their exhaustive list. It is one of the five principles of software construction as stated by Bertrand Meyer, the other four being the [http://hebb.cis.uoguelph.ca/~dave/343/Lectures/swquality.html#linguistic Linguistic Modular Units Principle], the Self- Documentation Principle, the [http://en.wikipedia.org/wiki/Uniform_access_principle Uniform- Access Principle], and the [http://en.wikipedia.org/wiki/Open/closed_principle Open- Closed Principle]. The Single Choice Principle may be viewed as a consequence of both the Open-Closed and information Hiding rules. It was applied when designing [http://en.wikipedia.org/wiki/Eiffel_%28programming_language%29 Eiffel].This principle is a particular case of the [http://en.wikipedia.org/wiki/Don%27t_repeat_yourself Don't repeat yourself principle].

===Violation of SCP===

Consider a type used to manage a declared in Pascal-Ada syntax :
<pre>Type Publication=
record
author,title:STRING;
publication_year:INTEGER;
case pubtype: (book,journal,conference_proceedings)of
book: (publisher:STRING);
journal: (volume,issue:STRING);
proceedings: (editor, place:STRING) – Conference proceedings
end</pre>
Let B be a typical client of A. B will manipulate publications through a variable such as
p:PUBLICATION
and to do anything useful with p, will need to discriminate explicitly between the various cases, as in:
<pre> case p of
book:...Instructions which may access the field p.publisher
journal:...Instructions which may access fields p.volume,p.issue
proceedings:...Instructions which may access fields p.editor,p.place
end</pre>

Now, whenever there is a need for a new variant, say technical reports of companies in this case, there is a need to extend the definition of type PUBLICATION in module A to support the new case, as well as any client of A, such as B, will also require updating if it is used as a structure such as above, relying on an explicit list of cases for p.
What is observed is a violation of the SCP and is a disastrous situation for software change and evolution as a simple and natural addition may cause a chain reaction of changes across many client changes. This violation will occur whenever a certain notion admits a number of variants for ex. -

*In graphics system: the notion of figure, with such variants as polygon, circle, ellipse, and other basic figure types.
<pre>For example old style procedural code to print different "shape" objects might read:

if (type==CIRCLE)
print "Circle. r=" + radius;
else if (type==Square)
print "Square. sides=" + sideLength;
else if (type==Rectangle)
print "Rect. h=" + height + " w=" + width;
endif</pre>

This same list of alternatives would be used in computing the area, and it rendering to a GUI and in checking for overlap with another shape, etc., etc. So these lists of cases have to be modified in all locations whenever you add a new shape.

*In a text editor: the notion of user command, with such variants as line insertion, line deletion, character deletion.
*In a compiler for a programming language, the notion of language construct, with such variants as instruction, expression, procedure.

===Implementation of SCP===
Traditional methods do not provide a solution to the SCP violations. Inheritance related concepts of [http://en.wikipedia.org/wiki/Polymorphism polymorphism] and [http://en.wikipedia.org/wiki/Dynamic_binding_%28computer_science%29 Dynamic binding] provide the solution to this problem.

The graphics system given above can be reimplemented in the Object Oriented Manner as:

<pre>
class SHAPE
display_details
end
end

class CIRCLE < SHAPE
display_details
print "Circle. r=" + radius;
end
end

class SQUARE < SHAPE
display_details
print "Square. sides=" + sideLength;
end
end

class RECTANGLE < SHAPE
display_details
print "Rect. h=" + height + " w=" + width;
end
end
</pre>
Thus a new sub class of shape is created for each new type of shape. The function display_details to be called depends upon the type of the invoking object. Thus the list of switch case / if else statements would only be needed while creating the object. Further on no such statements have to be written for any of the other operations such as computing the area, rendering to a GUI or checking for overlap with another shape, etc., etc.

===Other Highlights===
# According to the Single Choice principle exactly one module should know the list of choices, which contrasts the modularity goal which suggests that at most one module should have this knowledge.
# The principle is about distribution of knowledge in a software system. The amount of information available to each module should be limited to the information that is required for its proper functioning. This can analogous to the "need-to-know" policy. That is, a module only knows that much as it needs to know.
# SCP is a direct consequence of the [http://en.wikipedia.org/wiki/Open/closed_principle Open Closed Principle].
# SCP is a strong form of [http://en.wikipedia.org/wiki/Information_hiding Information Hiding]. The module containing the list of choices tries to hide it from the the other modules.

===Conclusion===
The single choice principle is a principle of [http://en.wikipedia.org/wiki/Imperative_programming imperative] [http://en.wikipedia.org/wiki/Computer_programming computer programming].It directs us to limit the dissemination of exhaustive knowledge about variants of a certain notion. It is an impetus to [http://en.wikipedia.org/wiki/Polymorphism polymorphism] and aims at achieving high [http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 cohesion] and low [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 coupling], one of the most important aspects of [http://en.wikipedia.org/wiki/Modular_programming Modular Programming].

===References===
# Object-Oriented Software Construction Second Edition, Bertrand Meyer pg 62-64.
# [http://c2.com/cgi/wiki?SingleChoicePrinciple Single Choice Principle]

CSC/ECE 517 Fall 2009/wiki3 17 am

2009-12-01T06:12:21Z

Mjampal: /* Conclusion */

=='''Single Choice Principle'''==
===Introduction===

Single Choice Principle states that whenever a software system must support a set of alternatives, one and only one module in the system should know their exhaustive list. It is one of the five principles of software construction as stated by Bertrand Meyer, the other four being the [http://hebb.cis.uoguelph.ca/~dave/343/Lectures/swquality.html#linguistic Linguistic Modular Units Principle], the Self- Documentation Principle, the [http://en.wikipedia.org/wiki/Uniform_access_principle Uniform- Access Principle], and the [http://en.wikipedia.org/wiki/Open/closed_principle Open- Closed Principle]. The Single Choice Principle may be viewed as a consequence of both the Open-Closed and information Hiding rules. It was applied when designing [http://en.wikipedia.org/wiki/Eiffel_%28programming_language%29 Eiffel].This principle is a particular case of the [http://en.wikipedia.org/wiki/Don%27t_repeat_yourself Don't repeat yourself principle].

===Violation of SCP===

Consider a type used to manage a declared in Pascal-Ada syntax :
<pre>Type Publication=
record
author,title:STRING;
publication_year:INTEGER;
case pubtype: (book,journal,conference_proceedings)of
book: (publisher:STRING);
journal: (volume,issue:STRING);
proceedings: (editor, place:STRING) – Conference proceedings
end</pre>
Let B be a typical client of A. B will manipulate publications through a variable such as
p:PUBLICATION
and to do anything useful with p, will need to discriminate explicitly between the various cases, as in:
<pre> case p of
book:...Instructions which may access the field p.publisher
journal:...Instructions which may access fields p.volume,p.issue
proceedings:...Instructions which may access fields p.editor,p.place
end</pre>

Now, whenever there is a need for a new variant, say technical reports of companies in this case, there is a need to extend the definition of type PUBLICATION in module A to support the new case, as well as any client of A, such as B, will also require updating if it is used as a structure such as above, relying on an explicit list of cases for p.
What is observed is a violation of the SCP and is a disastrous situation for software change and evolution as a simple and natural addition may cause a chain reaction of changes across many client changes. This violation will occur whenever a certain notion admits a number of variants for ex. -

*In graphics system: the notion of figure, with such variants as polygon, circle, ellipse, and other basic figure types.
<pre>For example old style procedural code to print different "shape" objects might read:

if (type==CIRCLE)
print "Circle. r=" + radius;
else if (type==Square)
print "Square. sides=" + sideLength;
else if (type==Rectangle)
print "Rect. h=" + height + " w=" + width;
endif</pre>

This same list of alternatives would be used in computing the area, and it rendering to a GUI and in checking for overlap with another shape, etc., etc. So these lists of cases have to be modified in all locations whenever you add a new shape.

*In a text editor: the notion of user command, with such variants as line insertion, line deletion, character deletion.
*In a compiler for a programming language, the notion of language construct, with such variants as instruction, expression, procedure.

===Implementation of SCP===
Traditional methods do not provide a solution to the SCP violations. Inheritance related concepts of [http://en.wikipedia.org/wiki/Polymorphism polymorphism] and [http://en.wikipedia.org/wiki/Dynamic_binding_%28computer_science%29 Dynamic binding] provide the solution to this problem.

The graphics system given above can be reimplemented in the Object Oriented Manner as:

<pre>
class SHAPE
display_details
end
end

class CIRCLE < SHAPE
display_details
print "Circle. r=" + radius;
end
end

class SQUARE < SHAPE
display_details
print "Square. sides=" + sideLength;
end
end

class RECTANGLE < SHAPE
display_details
print "Rect. h=" + height + " w=" + width;
end
end
</pre>
Thus a new sub class of shape is created for each new type of shape. The function display_details to be called depends upon the type of the invoking object. Thus the list of switch case / if else statements would only be needed while creating the object. Further on no such statements have to be written for any of the other operations such as computing the area, rendering to a GUI or checking for overlap with another shape, etc., etc.

===Other Highlights===
# According to the Single Choice principle exactly one module should know the list of choices, which contrasts the modularity goal which suggests that at most one module should have this knowledge.
# The principle is about distribution of knowledge in a software system. The amount of information available to each module should be limited to the information that is required for its proper functioning. This can analogous to the "need-to-know" policy. That is, a module only knows that much as it needs to know.
# SCP is a direct consequence of the [http://en.wikipedia.org/wiki/Open/closed_principle Open Closed Principle].
# SCP is a strong form of [http://en.wikipedia.org/wiki/Information_hiding Information Hiding]. The module containing the list of choices tries to hide it from the the other modules.

===Conclusions===
The single choice principle is a principle of [http://en.wikipedia.org/wiki/Imperative_programming imperative] [http://en.wikipedia.org/wiki/Computer_programming computer programming].It directs us to limit the dissemination of exhaustive knowledge about variants of a certain notion. It is an impetus to [http://en.wikipedia.org/wiki/Polymorphism polymorphism] and aims at achieving high [http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 cohesion] and low [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 coupling], one of the most important aspects of [http://en.wikipedia.org/wiki/Modular_programming Modular Programming].

===References===
# Object-Oriented Software Construction Second Edition, Bertrand Meyer pg 62-64.
# [http://c2.com/cgi/wiki?SingleChoicePrinciple Single Choice Principle]

CSC/ECE 517 Fall 2009/wiki3 7 Single Choice Pattern am

2009-11-18T19:04:03Z

Mjampal: /* Conclusion */

CSC/ECE 517 Fall 2009/wiki3 7 Single Choice Pattern am

2009-11-18T19:00:32Z

Mjampal: /* Other Highlights */

CSC/ECE 517 Fall 2009/wiki3 7 Single Choice Pattern am

2009-11-18T18:59:21Z

Mjampal: /* Implementation of SCP */

=='''Single Choice Principle'''==
===Introduction===

Single Choice Principle states that whenever a software system must support a set of alternatives, one and only one module in the system should know their exhaustive list. It is one of the five principles of software construction as stated by Bertrand Meyer, the other four being the [http://hebb.cis.uoguelph.ca/~dave/343/Lectures/swquality.html#linguistic Linguistic Modular Units Principle], the Self- Documentation Principle, the [http://en.wikipedia.org/wiki/Uniform_access_principle Uniform- Access Principle], and the [http://en.wikipedia.org/wiki/Open/closed_principle Open- Closed Principle]. The Single Choice Principle may be viewed as a consequence of both the Open-Closed and information Hiding rules. It was applied when designing [http://en.wikipedia.org/wiki/Eiffel_%28programming_language%29 Eiffel].This principle is a particular case of the [http://en.wikipedia.org/wiki/Don%27t_repeat_yourself Don't repeat yourself principle].

===Violation of SCP===

Consider a type used to manage a declared in Pascal-Ada syntax :
<pre>Type Publication=
record
author,title:STRING;
publication_year:INTEGER;
case pubtype: (book,journal,conference_proceedings)of
book: (publisher:STRING);
journal: (volume,issue:STRING);
proceedings: (editor, place:STRING) – Conference proceedings
end</pre>
Let B be a typical client of A. B will manipulate publications through a variable such as
p:PUBLICATION
and to do anything useful with p, will need to discriminate explicitly between the various cases, as in:
<pre> case p of
book:...Instructions which may access the field p.publisher
journal:...Instructions which may access fields p.volume,p.issue
proceedings:...Instructions which may access fields p.editor,p.place
end</pre>

Now, whenever there is a need for a new variant, say technical reports of companies in this case, there is a need to extend the definition of type PUBLICATION in module A to support the new case, as well as any client of A, such as B, will also require updating if it is used as a structure such as above, relying on an explicit list of cases for p.
What is observed is a violation of the SCP and is a disastrous situation for software change and evolution as a simple and natural addition may cause a chain reaction of changes across many client changes. This violation will occur whenever a certain notion admits a number of variants for ex. -

*In graphics system: the notion of figure, with such variants as polygon, circle, ellipse, and other basic figure types.
<pre>For example old style procedural code to print different "shape" objects might read:

if (type==CIRCLE)
print "Circle. r=" + radius;
else if (type==Square)
print "Square. sides=" + sideLength;
else if (type==Rectangle)
print "Rect. h=" + height + " w=" + width;
endif</pre>

This same list of alternatives would be used in computing the area, and it rendering to a GUI and in checking for overlap with another shape, etc., etc. So these lists of cases have to be modified in all locations whenever you add a new shape.

*In a text editor: the notion of user command, with such variants as line insertion, line deletion, character deletion.
*In a compiler for a programming language, the notion of language construct, with such variants as instruction, expression, procedure.

===Implementation of SCP===
Traditional methods do not provide a solution to the SCP violations. Inheritance related concepts of [http://en.wikipedia.org/wiki/Polymorphism polymorphism] and [http://en.wikipedia.org/wiki/Dynamic_binding_%28computer_science%29 Dynamic binding] provide the solution to this problem.

The graphics system given above can be reimplemented in the Object Oriented Manner as:

<pre>
class SHAPE
display_details
end
end

class CIRCLE < SHAPE
display_details
print "Circle. r=" + radius;
end
end

class SQUARE < SHAPE
display_details
print "Square. sides=" + sideLength;
end
end

class RECTANGLE < SHAPE
display_details
print "Rect. h=" + height + " w=" + width;
end
end
</pre>
Thus a new sub class of shape is created for each new type of shape. The function display_details to be called depends upon the type of the invoking object. Thus the list of switch case / if else statements would only be needed while creating the object. Further on no such statements have to be written for any of the other operations such as computing the area, rendering to a GUI or checking for overlap with another shape, etc., etc.

===Other Highlights===
# According to the Single Choice principle exactly one module should know the list of choices contrasting the modularity goal that suggests at most one module to have this knowledge
# The principle is about distribution of knowledge in a software system. The amount of information available to each module should be limited to the information that is required for its proper functioning. This can analogous to the "need-to-know" policy. That is, a module only knows that much as it needs to know.
# SCP is a direct consequence of the [http://en.wikipedia.org/wiki/Open/closed_principle Open Closed Principle].
# SCP is a strong form of [http://en.wikipedia.org/wiki/Information_hiding Information Hiding]. The module containing the list of choices tries to hide it from the the other modules.

===Conclusion===
The single choice principle is a principle of [http://en.wikipedia.org/wiki/Imperative_programming imperative] [http://en.wikipedia.org/wiki/Computer_programming computer programming].It directs us to limit the dissemination of exhaustive knowledge about variants of a certain notion. It is an impetus to [http://en.wikipedia.org/wiki/Polymorphism polymorphism] and aims at achieving high [http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 cohesion] and low [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 coupling], one of the most important aspects of [http://en.wikipedia.org/wiki/Modular_programming Modular Programming].

CSC/ECE 517 Fall 2009/wiki3 7 Single Choice Pattern am

2009-11-18T18:51:34Z

Mjampal: /* Implementation of SCP */

=='''Single Choice Principle'''==
===Introduction===

Single Choice Principle states that whenever a software system must support a set of alternatives, one and only one module in the system should know their exhaustive list. It is one of the five principles of software construction as stated by Bertrand Meyer, the other four being the [http://hebb.cis.uoguelph.ca/~dave/343/Lectures/swquality.html#linguistic Linguistic Modular Units Principle], the Self- Documentation Principle, the [http://en.wikipedia.org/wiki/Uniform_access_principle Uniform- Access Principle], and the [http://en.wikipedia.org/wiki/Open/closed_principle Open- Closed Principle]. The Single Choice Principle may be viewed as a consequence of both the Open-Closed and information Hiding rules. It was applied when designing [http://en.wikipedia.org/wiki/Eiffel_%28programming_language%29 Eiffel].This principle is a particular case of the [http://en.wikipedia.org/wiki/Don%27t_repeat_yourself Don't repeat yourself principle].

===Violation of SCP===

Consider a type used to manage a declared in Pascal-Ada syntax :
<pre>Type Publication=
record
author,title:STRING;
publication_year:INTEGER;
case pubtype: (book,journal,conference_proceedings)of
book: (publisher:STRING);
journal: (volume,issue:STRING);
proceedings: (editor, place:STRING) – Conference proceedings
end</pre>
Let B be a typical client of A. B will manipulate publications through a variable such as
p:PUBLICATION
and to do anything useful with p, will need to discriminate explicitly between the various cases, as in:
<pre> case p of
book:...Instructions which may access the field p.publisher
journal:...Instructions which may access fields p.volume,p.issue
proceedings:...Instructions which may access fields p.editor,p.place
end</pre>

Now, whenever there is a need for a new variant, say technical reports of companies in this case, there is a need to extend the definition of type PUBLICATION in module A to support the new case, as well as any client of A, such as B, will also require updating if it is used as a structure such as above, relying on an explicit list of cases for p.
What is observed is a violation of the SCP and is a disastrous situation for software change and evolution as a simple and natural addition may cause a chain reaction of changes across many client changes. This violation will occur whenever a certain notion admits a number of variants for ex. -

*In graphics system: the notion of figure, with such variants as polygon, circle, ellipse, and other basic figure types.
<pre>For example old style procedural code to print different "shape" objects might read:

if (type==CIRCLE)
print "Circle. r=" + radius;
else if (type==Square)
print "Square. sides=" + sideLength;
else if (type==Rectangle)
print "Rect. h=" + height + " w=" + width;
endif</pre>

This same list of alternatives would be used in computing the area, and it rendering to a GUI and in checking for overlap with another shape, etc., etc. So these lists of cases have to be modified in all locations whenever you add a new shape.

*In a text editor: the notion of user command, with such variants as line insertion, line deletion, character deletion.
*In a compiler for a programming language, the notion of language construct, with such variants as instruction, expression, procedure.

===Implementation of SCP===
Traditional methods do not provide a solution to the SCP violations. Inheritance related concepts of [http://en.wikipedia.org/wiki/Polymorphism polymorphism] and [http://en.wikipedia.org/wiki/Dynamic_binding_%28computer_science%29 Dynamic binding] provide the solution to this problem.

For the graphics system given above can be reimplemented in the Object Oriented Method as:

<pre>
class SHAPE
display_details
end
end

class CIRCLE < SHAPE
display_details
print "Circle. r=" + radius;
end
end

class SQUARE < SHAPE
display_details
print "Square. sides=" + sideLength;
end
end

class RECTANGLE < SHAPE
display_details
print "Rect. h=" + height + " w=" + width;
end
end
</pre>
Thus a new sub class of shape is created for each new type of shape. The function display_details to be called depends upon the type of the invoking object. Thus the list of switch case/if else statements would only be needed while creating the object. Further on no such statements have to be written for any of the other operations such as computing the area, rendering to a GUI or checking for overlap with another shape, etc., etc.

===Other Highlights===
# According to the Single Choice principle exactly one module should know the list of choices contrasting the modularity goal that suggests at most one module to have this knowledge
# The principle is about distribution of knowledge in a software system. The amount of information available to each module should be limited to the information that is required for its proper functioning. This can analogous to the "need-to-know" policy. That is, a module only knows that much as it needs to know.
# SCP is a direct consequence of the [http://en.wikipedia.org/wiki/Open/closed_principle Open Closed Principle].
# SCP is a strong form of [http://en.wikipedia.org/wiki/Information_hiding Information Hiding]. The module containing the list of choices tries to hide it from the the other modules.

===Conclusion===
The single choice principle is a principle of [http://en.wikipedia.org/wiki/Imperative_programming imperative] [http://en.wikipedia.org/wiki/Computer_programming computer programming].It directs us to limit the dissemination of exhaustive knowledge about variants of a certain notion. It is an impetus to [http://en.wikipedia.org/wiki/Polymorphism polymorphism] and aims at achieving high [http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 cohesion] and low [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 coupling], one of the most important aspects of [http://en.wikipedia.org/wiki/Modular_programming Modular Programming].

CSC/ECE 517 Fall 2009/wiki3 7 Single Choice Pattern am

2009-11-18T18:49:39Z

Mjampal: /* Other Highlights */

=='''Single Choice Principle'''==
===Introduction===

Single Choice Principle states that whenever a software system must support a set of alternatives, one and only one module in the system should know their exhaustive list. It is one of the five principles of software construction as stated by Bertrand Meyer, the other four being the [http://hebb.cis.uoguelph.ca/~dave/343/Lectures/swquality.html#linguistic Linguistic Modular Units Principle], the Self- Documentation Principle, the [http://en.wikipedia.org/wiki/Uniform_access_principle Uniform- Access Principle], and the [http://en.wikipedia.org/wiki/Open/closed_principle Open- Closed Principle]. The Single Choice Principle may be viewed as a consequence of both the Open-Closed and information Hiding rules. It was applied when designing [http://en.wikipedia.org/wiki/Eiffel_%28programming_language%29 Eiffel].This principle is a particular case of the [http://en.wikipedia.org/wiki/Don%27t_repeat_yourself Don't repeat yourself principle].

===Violation of SCP===

Consider a type used to manage a declared in Pascal-Ada syntax :
<pre>Type Publication=
record
author,title:STRING;
publication_year:INTEGER;
case pubtype: (book,journal,conference_proceedings)of
book: (publisher:STRING);
journal: (volume,issue:STRING);
proceedings: (editor, place:STRING) – Conference proceedings
end</pre>
Let B be a typical client of A. B will manipulate publications through a variable such as
p:PUBLICATION
and to do anything useful with p, will need to discriminate explicitly between the various cases, as in:
<pre> case p of
book:...Instructions which may access the field p.publisher
journal:...Instructions which may access fields p.volume,p.issue
proceedings:...Instructions which may access fields p.editor,p.place
end</pre>

Now, whenever there is a need for a new variant, say technical reports of companies in this case, there is a need to extend the definition of type PUBLICATION in module A to support the new case, as well as any client of A, such as B, will also require updating if it is used as a structure such as above, relying on an explicit list of cases for p.
What is observed is a violation of the SCP and is a disastrous situation for software change and evolution as a simple and natural addition may cause a chain reaction of changes across many client changes. This violation will occur whenever a certain notion admits a number of variants for ex. -

*In graphics system: the notion of figure, with such variants as polygon, circle, ellipse, and other basic figure types.
<pre>For example old style procedural code to print different "shape" objects might read:

if (type==CIRCLE)
print "Circle. r=" + radius;
else if (type==Square)
print "Square. sides=" + sideLength;
else if (type==Rectangle)
print "Rect. h=" + height + " w=" + width;
endif</pre>

This same list of alternatives would be used in computing the area, and it rendering to a GUI and in checking for overlap with another shape, etc., etc. So these lists of cases have to be modified in all locations whenever you add a new shape.

*In a text editor: the notion of user command, with such variants as line insertion, line deletion, character deletion.
*In a compiler for a programming language, the notion of language construct, with such variants as instruction, expression, procedure.

===Implementation of SCP===
Traditional methods do not provide a solution to the SCP violations. Inheritance related concepts of polymorphism and Dynamic binding provide the solution to this problem.

For the graphics system given above can be reimplemented in the Object Oriented Method as:

<pre>
class SHAPE
display_details
end
end

class CIRCLE < SHAPE
display_details
print "Circle. r=" + radius;
end
end

class SQUARE < SHAPE
display_details
print "Square. sides=" + sideLength;
end
end

class RECTANGLE < SHAPE
display_details
print "Rect. h=" + height + " w=" + width;
end
end
</pre>
Thus a new sub class of shape is created for each new type of shape. The function display_details to be called depends upon the type of the invoking object. Thus the list of switch case/if else statements would only be needed while creating the object. Further on no such statements have to be written for any of the other operations such as computing the area, rendering to a GUI or checking for overlap with another shape, etc., etc.

===Other Highlights===
# According to the Single Choice principle exactly one module should know the list of choices contrasting the modularity goal that suggests at most one module to have this knowledge
# The principle is about distribution of knowledge in a software system. The amount of information available to each module should be limited to the information that is required for its proper functioning. This can analogous to the "need-to-know" policy. That is, a module only knows that much as it needs to know.
# SCP is a direct consequence of the [http://en.wikipedia.org/wiki/Open/closed_principle Open Closed Principle].
# SCP is a strong form of [http://en.wikipedia.org/wiki/Information_hiding Information Hiding]. The module containing the list of choices tries to hide it from the the other modules.

===Conclusion===
The single choice principle is a principle of [http://en.wikipedia.org/wiki/Imperative_programming imperative] [http://en.wikipedia.org/wiki/Computer_programming computer programming].It directs us to limit the dissemination of exhaustive knowledge about variants of a certain notion. It is an impetus to [http://en.wikipedia.org/wiki/Polymorphism polymorphism] and aims at achieving high [http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 cohesion] and low [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 coupling], one of the most important aspects of [http://en.wikipedia.org/wiki/Modular_programming Modular Programming].

CSC/ECE 517 Fall 2009/wiki3 7 Single Choice Pattern am

2009-11-18T18:31:50Z

Mjampal: /* Implementation of SCP */

=='''Single Choice Principle'''==
===Introduction===

Single Choice Principle states that whenever a software system must support a set of alternatives, one and only one module in the system should know their exhaustive list. It is one of the five principles of software construction as stated by Bertrand Meyer, the other four being the [http://hebb.cis.uoguelph.ca/~dave/343/Lectures/swquality.html#linguistic Linguistic Modular Units Principle], the Self- Documentation Principle, the [http://en.wikipedia.org/wiki/Uniform_access_principle Uniform- Access Principle], and the [http://en.wikipedia.org/wiki/Open/closed_principle Open- Closed Principle]. The Single Choice Principle may be viewed as a consequence of both the Open-Closed and information Hiding rules. It was applied when designing [http://en.wikipedia.org/wiki/Eiffel_%28programming_language%29 Eiffel].This principle is a particular case of the [http://en.wikipedia.org/wiki/Don%27t_repeat_yourself Don't repeat yourself principle].

===Violation of SCP===

Consider a type used to manage a declared in Pascal-Ada syntax :
<pre>Type Publication=
record
author,title:STRING;
publication_year:INTEGER;
case pubtype: (book,journal,conference_proceedings)of
book: (publisher:STRING);
journal: (volume,issue:STRING);
proceedings: (editor, place:STRING) – Conference proceedings
end</pre>
Let B be a typical client of A. B will manipulate publications through a variable such as
p:PUBLICATION
and to do anything useful with p, will need to discriminate explicitly between the various cases, as in:
<pre> case p of
book:...Instructions which may access the field p.publisher
journal:...Instructions which may access fields p.volume,p.issue
proceedings:...Instructions which may access fields p.editor,p.place
end</pre>

Now, whenever there is a need for a new variant, say technical reports of companies in this case, there is a need to extend the definition of type PUBLICATION in module A to support the new case, as well as any client of A, such as B, will also require updating if it is used as a structure such as above, relying on an explicit list of cases for p.
What is observed is a violation of the SCP and is a disastrous situation for software change and evolution as a simple and natural addition may cause a chain reaction of changes across many client changes. This violation will occur whenever a certain notion admits a number of variants for ex. -

*In graphics system: the notion of figure, with such variants as polygon, circle, ellipse, and other basic figure types.
<pre>For example old style procedural code to print different "shape" objects might read:

if (type==CIRCLE)
print "Circle. r=" + radius;
else if (type==Square)
print "Square. sides=" + sideLength;
else if (type==Rectangle)
print "Rect. h=" + height + " w=" + width;
endif</pre>

This same list of alternatives would be used in computing the area, and it rendering to a GUI and in checking for overlap with another shape, etc., etc. So these lists of cases have to be modified in all locations whenever you add a new shape.

*In a text editor: the notion of user command, with such variants as line insertion, line deletion, character deletion.
*In a compiler for a programming language, the notion of language construct, with such variants as instruction, expression, procedure.

===Implementation of SCP===
Traditional methods do not provide a solution to the SCP violations. Inheritance related concepts of polymorphism and Dynamic binding provide the solution to this problem.

For the graphics system given above can be reimplemented in the Object Oriented Method as:

<pre>
class SHAPE
display_details
end
end

class CIRCLE < SHAPE
display_details
print "Circle. r=" + radius;
end
end

class SQUARE < SHAPE
display_details
print "Square. sides=" + sideLength;
end
end

class RECTANGLE < SHAPE
display_details
print "Rect. h=" + height + " w=" + width;
end
end
</pre>
Thus a new sub class of shape is created for each new type of shape. The function display_details to be called depends upon the type of the invoking object. Thus the list of switch case/if else statements would only be needed while creating the object. Further on no such statements have to be written for any of the other operations such as computing the area, rendering to a GUI or checking for overlap with another shape, etc., etc.

===Other Highlights===
# According to the Single Choice principle exactly one module should know the list of choices contrasting the modularity goal that suggests at most one module to have this knowledge
# The principle is about distribution of knowledge in a software system. The amount of information available to each module should be limited to the information that is required for its proper functioning. This can analogous to the "need-to-know" policy. That is, a module only knows that much as it needs to know.
# SCP is a direct consequence of the Open Closed Principle.
# SCP is a strong form of Information Hiding. The module containing the list of choices tries to hide it from the the other modules.

===Conclusion===
The single choice principle is a principle of [http://en.wikipedia.org/wiki/Imperative_programming imperative] [http://en.wikipedia.org/wiki/Computer_programming computer programming].It directs us to limit the dissemination of exhaustive knowledge about variants of a certain notion. It is an impetus to [http://en.wikipedia.org/wiki/Polymorphism polymorphism] and aims at achieving high [http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 cohesion] and low [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 coupling], one of the most important aspects of [http://en.wikipedia.org/wiki/Modular_programming Modular Programming].

CSC/ECE 517 Fall 2009/wiki3 7 Single Choice Pattern am

2009-11-18T17:59:12Z

Mjampal: /* Implementation of SCP */

=='''Single Choice Principle'''==
===Introduction===

Single Choice Principle states that whenever a software system must support a set of alternatives, one and only one module in the system should know their exhaustive list. It is one of the five principles of software construction as stated by Bertrand Meyer, the other four being the [http://hebb.cis.uoguelph.ca/~dave/343/Lectures/swquality.html#linguistic Linguistic Modular Units Principle], the Self- Documentation Principle, the [http://en.wikipedia.org/wiki/Uniform_access_principle Uniform- Access Principle], and the [http://en.wikipedia.org/wiki/Open/closed_principle Open- Closed Principle]. The Single Choice Principle may be viewed as a consequence of both the Open-Closed and information Hiding rules. It was applied when designing [http://en.wikipedia.org/wiki/Eiffel_%28programming_language%29 Eiffel].This principle is a particular case of the [http://en.wikipedia.org/wiki/Don%27t_repeat_yourself Don't repeat yourself principle].

===Violation of SCP===

Consider a type used to manage a declared in Pascal-Ada syntax :
<pre>Type Publication=
record
author,title:STRING;
publication_year:INTEGER;
case pubtype: (book,journal,conference_proceedings)of
book: (publisher:STRING);
journal: (volume,issue:STRING);
proceedings: (editor, place:STRING) – Conference proceedings
end</pre>
Let B be a typical client of A. B will manipulate publications through a variable such as
p:PUBLICATION
and to do anything useful with p, will need to discriminate explicitly between the various cases, as in:
<pre> case p of
book:...Instructions which may access the field p.publisher
journal:...Instructions which may access fields p.volume,p.issue
proceedings:...Instructions which may access fields p.editor,p.place
end</pre>

Now, whenever there is a need for a new variant, say technical reports of companies in this case, there is a need to extend the definition of type PUBLICATION in module A to support the new case, as well as any client of A, such as B, will also require updating if it is used as a structure such as above, relying on an explicit list of cases for p.
What is observed is a violation of the SCP and is a disastrous situation for software change and evolution as a simple and natural addition may cause a chain reaction of changes across many client changes. This violation will occur whenever a certain notion admits a number of variants for ex. -

*In graphics system: the notion of figure, with such variants as polygon, circle, ellipse, and other basic figure types.
<pre>For example old style procedural code to print different "shape" objects might read:

if (type==CIRCLE)
print "Circle. r=" + radius;
else if (type==Square)
print "Square. sides=" + sideLength;
else if (type==Rectangle)
print "Rect. h=" + height + " w=" + width;
endif</pre>

This same list of alternatives would be used in computing the area, and it rendering to a GUI and in checking for overlap with another shape, etc., etc. So these lists of cases have to be modified in all locations whenever you add a new shape.

*In a text editor: the notion of user command, with such variants as line insertion, line deletion, character deletion.
*In a compiler for a programming language, the notion of language construct, with such variants as instruction, expression, procedure.

===Implementation of SCP===
Traditional methods do not provide a solution to the SCP violations. Inheritance related concepts of polymorphism and Dynamic binding provide the solution to this problem.

For the graphics system given above can be reimplemented in the Object Oriented Method as:

<pre>
class SHAPE
display_details
end
end

class CIRCLE < SHAPE
display_details
print "Circle. r=" + radius;
end
end

class SQUARE < SHAPE
display_details
print "Square. sides=" + sideLength;
end
end

class RECTANGLE < SHAPE
display_details
print "Rect. h=" + height + " w=" + width;
end
end
</pre>
Thus a new sub class of shape is created for each new type of shape.

This same list of alternatives would be used in computing the area, and it rendering to a GUI and in checking for overlap with another shape, etc., etc. So these lists of cases have to be modified in all locations whenever you add a new shape.

===Other Highlights===
# According to the Single Choice principle exactly one module should know the list of choices contrasting the modularity goal that suggests at most one module to have this knowledge
# The principle is about distribution of knowledge in a software system. The amount of information available to each module should be limited to the information that is required for its proper functioning. This can analogous to the "need-to-know" policy. That is, a module only knows that much as it needs to know.
# SCP is a direct consequence of the Open Closed Principle.
# SCP is a strong form of Information Hiding. The module containing the list of choices tries to hide it from the the other modules.

===Conclusion===
The single choice principle is a principle of [http://en.wikipedia.org/wiki/Imperative_programming imperative] [http://en.wikipedia.org/wiki/Computer_programming computer programming].It directs us to limit the dissemination of exhaustive knowledge about variants of a certain notion. It is an impetus to [http://en.wikipedia.org/wiki/Polymorphism polymorphism] and aims at achieving high [http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 cohesion] and low [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 coupling], one of the most important aspects of [http://en.wikipedia.org/wiki/Modular_programming Modular Programming].

CSC/ECE 517 Fall 2009/wiki3 7 Single Choice Pattern am

2009-11-18T17:47:39Z

Mjampal: /* Implementation of SCP */

=='''Single Choice Principle'''==
===Introduction===

Single Choice Principle states that whenever a software system must support a set of alternatives, one and only one module in the system should know their exhaustive list. It is one of the five principles of software construction as stated by Bertrand Meyer, the other four being the [http://hebb.cis.uoguelph.ca/~dave/343/Lectures/swquality.html#linguistic Linguistic Modular Units Principle], the Self- Documentation Principle, the [http://en.wikipedia.org/wiki/Uniform_access_principle Uniform- Access Principle], and the [http://en.wikipedia.org/wiki/Open/closed_principle Open- Closed Principle]. The Single Choice Principle may be viewed as a consequence of both the Open-Closed and information Hiding rules. It was applied when designing [http://en.wikipedia.org/wiki/Eiffel_%28programming_language%29 Eiffel].This principle is a particular case of the [http://en.wikipedia.org/wiki/Don%27t_repeat_yourself Don't repeat yourself principle].

===Violation of SCP===

Consider a type used to manage a declared in Pascal-Ada syntax :
<pre>Type Publication=
record
author,title:STRING;
publication_year:INTEGER;
case pubtype: (book,journal,conference_proceedings)of
book: (publisher:STRING);
journal: (volume,issue:STRING);
proceedings: (editor, place:STRING) – Conference proceedings
end</pre>
Let B be a typical client of A. B will manipulate publications through a variable such as
p:PUBLICATION
and to do anything useful with p, will need to discriminate explicitly between the various cases, as in:
<pre> case p of
book:...Instructions which may access the field p.publisher
journal:...Instructions which may access fields p.volume,p.issue
proceedings:...Instructions which may access fields p.editor,p.place
end</pre>

Now, whenever there is a need for a new variant, say technical reports of companies in this case, there is a need to extend the definition of type PUBLICATION in module A to support the new case, as well as any client of A, such as B, will also require updating if it is used as a structure such as above, relying on an explicit list of cases for p.
What is observed is a violation of the SCP and is a disastrous situation for software change and evolution as a simple and natural addition may cause a chain reaction of changes across many client changes. This violation will occur whenever a certain notion admits a number of variants for ex. -

*In graphics system: the notion of figure, with such variants as polygon, circle, ellipse, and other basic figure types.
<pre>For example old style procedural code to print different "shape" objects might read:

if (type==CIRCLE)
print "Circle. r=" + radius;
else if (type==Square)
print "Square. sides=" + sideLength;
else if (type==Rectangle)
print "Rect. h=" + height + " w=" + width;
endif</pre>

This same list of alternatives would be used in computing the area, and it rendering to a GUI and in checking for overlap with another shape, etc., etc. So these lists of cases have to be modified in all locations whenever you add a new shape.

*In a text editor: the notion of user command, with such variants as line insertion, line deletion, character deletion.
*In a compiler for a programming language, the notion of language construct, with such variants as instruction, expression, procedure.

===Implementation of SCP===
Traditional methods do not provide a solution to the SCP violations. Inheritance related concepts of polymorphism and Dynamic binding provide the solution to this problem.

===Other Highlights===
# According to the Single Choice principle exactly one module should know the list of choices contrasting the modularity goal that suggests at most one module to have this knowledge
# The principle is about distribution of knowledge in a software system. The amount of information available to each module should be limited to the information that is required for its proper functioning. This can analogous to the "need-to-know" policy. That is, a module only knows that much as it needs to know.
# SCP is a direct consequence of the Open Closed Principle.
# SCP is a strong form of Information Hiding. The module containing the list of choices tries to hide it from the the other modules.

===Conclusion===
The single choice principle is a principle of [http://en.wikipedia.org/wiki/Imperative_programming imperative] [http://en.wikipedia.org/wiki/Computer_programming computer programming].It directs us to limit the dissemination of exhaustive knowledge about variants of a certain notion. It is an impetus to [http://en.wikipedia.org/wiki/Polymorphism polymorphism] and aims at achieving high [http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 cohesion] and low [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 coupling], one of the most important aspects of [http://en.wikipedia.org/wiki/Modular_programming Modular Programming].

CSC/ECE 517 Fall 2009/wiki3 7 Single Choice Pattern am

2009-11-18T17:35:11Z

Mjampal: /* Other Highlights */

=='''Single Choice Principle'''==
===Introduction===

Single Choice Principle states that whenever a software system must support a set of alternatives, one and only one module in the system should know their exhaustive list. It is one of the five principles of software construction as stated by Bertrand Meyer, the other four being the [http://hebb.cis.uoguelph.ca/~dave/343/Lectures/swquality.html#linguistic Linguistic Modular Units Principle], the Self- Documentation Principle, the [http://en.wikipedia.org/wiki/Uniform_access_principle Uniform- Access Principle], and the [http://en.wikipedia.org/wiki/Open/closed_principle Open- Closed Principle]. The Single Choice Principle may be viewed as a consequence of both the Open-Closed and information Hiding rules. It was applied when designing [http://en.wikipedia.org/wiki/Eiffel_%28programming_language%29 Eiffel].This principle is a particular case of the [http://en.wikipedia.org/wiki/Don%27t_repeat_yourself Don't repeat yourself principle].

===Violation of SCP===

Consider a type used to manage a declared in Pascal-Ada syntax :
<pre>Type Publication=
record
author,title:STRING;
publication_year:INTEGER;
case pubtype: (book,journal,conference_proceedings)of
book: (publisher:STRING);
journal: (volume,issue:STRING);
proceedings: (editor, place:STRING) – Conference proceedings
end</pre>
Let B be a typical client of A. B will manipulate publications through a variable such as
p:PUBLICATION
and to do anything useful with p, will need to discriminate explicitly between the various cases, as in:
<pre> case p of
book:...Instructions which may access the field p.publisher
journal:...Instructions which may access fields p.volume,p.issue
proceedings:...Instructions which may access fields p.editor,p.place
end</pre>

Now, whenever there is a need for a new variant, say technical reports of companies in this case, there is a need to extend the definition of type PUBLICATION in module A to support the new case, as well as any client of A, such as B, will also require updating if it is used as a structure such as above, relying on an explicit list of cases for p.
What is observed is a violation of the SCP and is a disastrous situation for software change and evolution as a simple and natural addition may cause a chain reaction of changes across many client changes. This violation will occur whenever a certain notion admits a number of variants for ex. -

*In graphics system: the notion of figure, with such variants as polygon, circle, ellipse, and other basic figure types.
<pre>For example old style procedural code to print different "shape" objects might read:

if (type==CIRCLE)
print "Circle. r=" + radius;
else if (type==Square)
print "Square. sides=" + sideLength;
else if (type==Rectangle)
print "Rect. h=" + height + " w=" + width;
endif</pre>

This same list of alternatives would be used in computing the area, and it rendering to a GUI and in checking for overlap with another shape, etc., etc. So these lists of cases have to be modified in all locations whenever you add a new shape.

*In a text editor: the notion of user command, with such variants as line insertion, line deletion, character deletion.
*In a compiler for a programming language, the notion of language construct, with such variants as instruction, expression, procedure.

===Implementation of SCP===
===Other Highlights===
# According to the Single Choice principle exactly one module should know the list of choices contrasting the modularity goal that suggests at most one module to have this knowledge
# The principle is about distribution of knowledge in a software system. The amount of information available to each module should be limited to the information that is required for its proper functioning. This can analogous to the "need-to-know" policy. That is, a module only knows that much as it needs to know.
# SCP is a direct consequence of the Open Closed Principle.
# SCP is a strong form of Information Hiding. The module containing the list of choices tries to hide it from the the other modules.

===Conclusion===
The single choice principle is a principle of [http://en.wikipedia.org/wiki/Imperative_programming imperative] [http://en.wikipedia.org/wiki/Computer_programming computer programming].It directs us to limit the dissemination of exhaustive knowledge about variants of a certain notion. It is an impetus to [http://en.wikipedia.org/wiki/Polymorphism polymorphism] and aims at achieving high [http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 cohesion] and low [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 coupling], one of the most important aspects of [http://en.wikipedia.org/wiki/Modular_programming Modular Programming].

CSC/ECE 517 Fall 2009/wiki3 7 Single Choice Pattern am

2009-11-18T17:34:04Z

Mjampal: /* Other Highlights */

=='''Single Choice Principle'''==
===Introduction===

Single Choice Principle states that whenever a software system must support a set of alternatives, one and only one module in the system should know their exhaustive list. It is one of the five principles of software construction as stated by Bertrand Meyer, the other four being the [http://hebb.cis.uoguelph.ca/~dave/343/Lectures/swquality.html#linguistic Linguistic Modular Units Principle], the Self- Documentation Principle, the [http://en.wikipedia.org/wiki/Uniform_access_principle Uniform- Access Principle], and the [http://en.wikipedia.org/wiki/Open/closed_principle Open- Closed Principle]. The Single Choice Principle may be viewed as a consequence of both the Open-Closed and information Hiding rules. It was applied when designing [http://en.wikipedia.org/wiki/Eiffel_%28programming_language%29 Eiffel].This principle is a particular case of the [http://en.wikipedia.org/wiki/Don%27t_repeat_yourself Don't repeat yourself principle].

===Violation of SCP===

Consider a type used to manage a declared in Pascal-Ada syntax :
<pre>Type Publication=
record
author,title:STRING;
publication_year:INTEGER;
case pubtype: (book,journal,conference_proceedings)of
book: (publisher:STRING);
journal: (volume,issue:STRING);
proceedings: (editor, place:STRING) – Conference proceedings
end</pre>
Let B be a typical client of A. B will manipulate publications through a variable such as
p:PUBLICATION
and to do anything useful with p, will need to discriminate explicitly between the various cases, as in:
<pre> case p of
book:...Instructions which may access the field p.publisher
journal:...Instructions which may access fields p.volume,p.issue
proceedings:...Instructions which may access fields p.editor,p.place
end</pre>

Now, whenever there is a need for a new variant, say technical reports of companies in this case, there is a need to extend the definition of type PUBLICATION in module A to support the new case, as well as any client of A, such as B, will also require updating if it is used as a structure such as above, relying on an explicit list of cases for p.
What is observed is a violation of the SCP and is a disastrous situation for software change and evolution as a simple and natural addition may cause a chain reaction of changes across many client changes. This violation will occur whenever a certain notion admits a number of variants for ex. -

*In graphics system: the notion of figure, with such variants as polygon, circle, ellipse, and other basic figure types.
<pre>For example old style procedural code to print different "shape" objects might read:

if (type==CIRCLE)
print "Circle. r=" + radius;
else if (type==Square)
print "Square. sides=" + sideLength;
else if (type==Rectangle)
print "Rect. h=" + height + " w=" + width;
endif</pre>

This same list of alternatives would be used in computing the area, and it rendering to a GUI and in checking for overlap with another shape, etc., etc. So these lists of cases have to be modified in all locations whenever you add a new shape.

*In a text editor: the notion of user command, with such variants as line insertion, line deletion, character deletion.
*In a compiler for a programming language, the notion of language construct, with such variants as instruction, expression, procedure.

===Implementation of SCP===
===Other Highlights===
# According to the Single Choice principle exactly one module should know the list of choices contrasting the modularity goal that suggests at most one module to have this knowledge
# The principle is about distribution of knowledge in a software system. The amount of information available to each module should be limited to the information that is required for its proper functioning. This can analogous to the "need-to-know" policy. That is, a module only knows that much as it needs to know.
# Single Choice Principle is a direct consequence of the Open Closed Principle.
# Single Choice Principle is a strong form of Information Hiding. The module containing the list of choices tries to hide it from the the other modules.

===Conclusion===
The single choice principle is a principle of [http://en.wikipedia.org/wiki/Imperative_programming imperative] [http://en.wikipedia.org/wiki/Computer_programming computer programming].It directs us to limit the dissemination of exhaustive knowledge about variants of a certain notion. It is an impetus to [http://en.wikipedia.org/wiki/Polymorphism polymorphism] and aims at achieving high [http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 cohesion] and low [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 coupling], one of the most important aspects of [http://en.wikipedia.org/wiki/Modular_programming Modular Programming].

CSC/ECE 517 Fall 2009/wiki2 1 ma

2009-10-08T22:19:49Z

Mjampal: /* Appendix */

= Metaprogramming =
== What is Metaprogramming? ==
'''Meta-''' (from Greek: μετά = "after", "beyond", "with", "adjacent", "self"), is a prefix used in English to indicate a concept which is an abstraction from another concept, used to complete or add to the latter.

''Metaprogramming is the writing of computer programs that write or manipulate other programs (or themselves) as their data, or that do part of the work at compile time that would otherwise be done at runtime. In many cases, this allows programmers to get more done in the same amount of time as they would take to write all the code manually, or it gives programs greater flexibility to efficiently handle new situations without recompilation.'' Source: [http://en.wikipedia.org/wiki/Metaprogramming]

Metaprogramming is divided into runtime metaprogramming, also known as reflection, and compile time metaprogramming. Reflection is more interesting since it allows interaction and modification of objects, components and structures that do not exist at compile time.

== Examples of Metaprograms ==

*the compiler or interpreter of your favourite language
*Lex and Yacc
*CORBA's IDL compiler
*a Quine (a program that, when executed, prints a copy of its own source code - see QuineProgram for examples)
*Programs to generate EJB code and XML from database metadata
*Macros are nothing but special cases of metaprograms, as they are replaced by the actual code during macro expansion.

Source: [http://c2.com/cgi/wiki?MetaProgramming]

== Metaprogramming style in various languages ==

Metaprogramming seems to have origniated in Lisp. John Foderaro mentions Lisp as a programmable programming language. Lisp facilitates reflection through the use of an interpreter implemented in the same language. Unlike Smalltalk and Lisp, Java and C++ do not feature extensive built-in reflection facilities.

=== Metaprogramming in Ruby ===
Ruby is a dynamically-typed, interpreted, object oriented language. One of the unique aspects of Ruby is its extensive reflexive metaprogramming facilities.

==== What makes Ruby good for metaprogramming ====
*Ruby is Dynamic and reflective
*Everything is open to change
*Blocks allow writing new control structures
*Most declarations are executable statements
*An easy syntax

==== Classification of metaprogramming features in Ruby ====
* The dynamic nature of Ruby supports creating classes and methods at runtime
* Methods can be defined directly on Singleton classes: class_eval can be used to define methods on singleton classes. This will then modify the behaviour of the sub classes(if any) and not the base class.
* Blocks and proc objects: Materializing a Proc and saving this in variables and sending it around is a good way to use metaprogramming to do interesting things. Lambda function is used to define proc objects
* The different evals: There are 4 different evals in Ruby
** eval: This call can take a string or binding to evaluate but not a block
** class_eval: It is just a alias for module_eval
** instance_eval: It will evaluate the string or the block in the context of the receiver. Thus it sets self to be the receiver.
** module_eval: It will evaluate the string or the block in the context of the module it is called on. Thus it is used to define new methods on singleton classes. This is the most commonly used eval call.

The difference between the above 4 evals can be understood with examples [http://www.elctech.com/snippets/the-difference-between-eval-class_eval-module_eval-and-instance_eval here]. Another useful external link on evals can be found [http://4loc.wordpress.com/2009/05/29/eval-module_eval-and-instance_eval/ here]

==== Examples ====
We begin by showing how methods can be defined dynamically in Ruby. Consider we need a method that duplicates strings eg. "foo".duplicate -> "foofoo". And a deduplicate method for removing duplication eg. "foofoo".deduplicate -> "foo". We can define such methods dynamically in Ruby. This ''dynamic'' feature in Ruby forms the simplest kind of metapgrogramming.

class String
def duplicate
self * 2
end
def deduplicate
self[0, self.length/2]
end
end

For instance attr_reader, attr_writer, attr_accessor are inbuilt keywords that declare the object properties. These are actually not just syntax, but methods defined in Module. ''These methods are written in C''. In other words, the ''object language'' here is Ruby but the ''metalanguage'' is C - Refer [http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki2_1_ma#Appendix Appendix]. Representing the functionality for the attr_reader method as a metaprogram in Ruby.

class Module
def attr_reader (*syms)
sys.each do |sym|
class_eval %{def #{sym} @#{sym} end}
end
end
end

Consider how define_method can be used dynamically in Ruby
Eagle=Class.new
e=Eagle.new
class Eagle
define_method:fly do
puts "I am flying"
end
end
e.fly
Output: ''I am flying''

Rails becomes an all-powerful MVC framework, thanks to the metaprogramming features in Ruby.

''Other elaborate examples can be found in the [http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki2_1_ma#References References] section of this wiki page. A detailed discussion on Metaprogramming in Ruby was done in the CSC517 course lecture, the notes for which can be found [http://courses.ncsu.edu/csc517/common/lectures/notes/lec12-f09.pdf here]''

=== Metaprogramming in C++ ===

C++ provides for a type of metaprogramming called as [http://en.wikipedia.org/wiki/Template_metaprogramming template metaprograming]. Template Metaprogramming (TMP) is a programming technique that uses the priniciple of [http://en.wikipedia.org/wiki/Name_binding early binding]. This means that pieces of codes called templates are replaced by actual code including compile-time constants, data structures, and complete functions. Then the compiler puts together all the code and compiles it. Hence the compiler in a sense acts as a "virtual computer" [http://www.codeproject.com/KB/cpp/crc_meta.aspx] as it replaces parts of the program with instructions, which would otherwise have been done at run time.

In TMP similar groups of lines of codes are replaced by a common template. Initially the template has to be defined with a base set of lines of code which are common in all. Then at the time of usage, templates have to be instantiated. Thus the templte definition specifies the general form of the code whereas the instantiation gives the specific lines of code formed from the template definition.

====Examples ====
'''Calculating a value at compile time''' 
The code to find summation of a number without using templates can be given as: 
int summation(int n)
{
if (n == 0 )
return 0;
return n + summation(n - 1);
}
void findsummation()
{
int a = summation(5); //a= (5+ 4 + 3 + 2 + 1 + 0) == 15
int b = summation(0); //b=0
}

Now using templates the same program can be written as:

template <int N>
//TEMPLATE DEFINITION
struct Summation
{
enum { value = N + Summation<N - 1>::value };
};
template <>
struct Summation<0>
{
enum { value = 0 };
};
void findsummation()
{
int a = Summation<5>::value; // == 15 // INSTANTIATION
int b = Summation<0>::value; // == 1 // INSTANTIATION
}

Thus with templates, the values of a and b were calculated at compile time rather than at run time. This was possible because 5 and 0 were literals, if they had been variables then their values wouldn’t have been known at compile time and hence a and b could not have been calculated at compile time.

'''Loop unrolling''' 
Further templates can be used to unroll loops, that is a loop is replaced by repeating the code within the loop a certain number of times. [http://www.codeproject.com/KB/cpp/crc_meta.aspx more on this example]

template< int i >
class LOOP{
public:
static inline void EXEC(){
cout << "A-" <::EXEC();
cout << "B-" <{
public:
static inline void EXEC(){
cout << "A-" << i;
cout << "\n";
cout << "B-" << i;
}
};

The output of LOOP< 8 >::EXEC() is shown below: 
A-8 A-7 A-6 A-5 A-4 A-3 A-2 A-1 A-0 
B-0 B-1 B-2 B-3 B-4 B-5 B-6 B-7 B-8 

At compile time the loop unrolls itself and produces the following lines of code:

cout << "A-" << 8 << " ";
cout << "A-" << 7 << " ";
...
cout << "A-" << 0;
cout << "\n";
cout << "B-" << 0;
...
cout << "B-" << 7 << " ";
cout << "B-" << 8 << " ";

More Examples can be found at [http://en.wikibooks.org/wiki/C++_Programming/Template/Template_Meta-Programming C++ Template Programming], [http://en.wikipedia.org/wiki/Template_metaprogramming Template Metaprogramming] and [http://www.codeproject.com/KB/cpp/crc_meta.aspx TMP in c++]

=== Illustrating the differences ===
Unlike Ruby, C++ does not support a built-in metaprogramming system aside from template metaprogramming. Template programming is also known as "programming at compile time". Templates allow the compiler to determine certain variable and object types at compile time. The disadvantages of templates are : i) it is not specialized enough (C++ templates are Turing-complete [http://homepage.mac.com/sigfpe/Computing/peano.html]. Often they can be used for collection classes but they can also be employed in metaprogramming. This can make it hard to figure out how templates can be used to solve a specific problem), ii) poor error messages (when errors occur at compile time due to incorrectness of templates, the error messages can be cryptic)

== Conclusion ==
Metaprogramming is thus an essential and useful programming feature that allows elimination of duplicated code and enables clean execution with lesser lines of code. The style of metaprogramming differs when it comes to different languages. Ruby and Lisp have more specialized metaprogramming constructs as compared to Java or C++. Metaprogramming is apparently is a higher-level concept and probably used often by expert programmers, nevertheless through metaprogramming the overall code or program becomes very easy to interpret. Its a trade-off that should be balanced by software programmers.

== Appendix ==
* Metalanguage: The language in which the metaprogram is written
* Object language: The language of the programs that are manipulated
* Reflection or Reflexivity: The ability of a programming language to be its own metalanguage
* Template: A feature of the C++ programming language that allow functions and classes to operate with generic types. This allows a function or class to work on many different data types without being rewritten for each one.
* Early Binding: In programming languages, name binding is the association of values with identifiers. The binding of names before the program is run is called early (also "static")

== References/External Links ==
# [http://en.wikipedia.org/wiki/Metaprogramming Wikipedia article on metaprogramming]
# [http://c2.com/cgi/wiki?MetaProgramming Metaprogramming]
# [http://www.codeproject.com/KB/cpp/crc_meta.aspx Template programming in C++]
# [http://homepage.mac.com/sigfpe/Computing/peano.html Turing completeness in C++]
# [http://www.vanderburg.org/Speaking/Stuff/oscon05.pdf presentation about Meta programming in Ruby made at the 2005 O’Reilly Open Source Convention by Glenn Vanderburg]
# [http://theplana.wordpress.com/2007/03/12/how-to-define-a-attribute-using-metaprogramming/ Defining attributes with Metaprogramming]
# More examples on Ruby metaprogramming
## [http://ozone.wordpress.com/2006/03/02/binary-search-tree-sauce-ruby-part-1/ Link 1]
## [http://www.ruby-doc.org/core/classes/Object.src/M000366.html Link 2]
## [http://expressica.com/category/metaprogramming/ Link 3]
# [http://ozone.wordpress.com/2006/02/22/rubybeans-a-short-example-of-ruby-metaprogramming/#comment-1286 Rubybeans and Metaprogramming]
# [http://reference.jumpingmonkey.org/programming_languages/ruby/ruby-metaprogramming.html Metaprogramming in Ruby]
# [http://en.wikibooks.org/wiki/C++_Programming/Template/Template_Meta-Programming C++ Template Programming]
# [http://en.wikipedia.org/wiki/Template_metaprogramming Template Metaprogramming]
# [http://www.codeproject.com/KB/cpp/crc_meta.aspx TMP in c++]

CSC/ECE 517 Fall 2009/wiki2 1 ma

2009-10-08T22:12:32Z

Mjampal: /* Appendix */

= Metaprogramming =
== What is Metaprogramming? ==
'''Meta-''' (from Greek: μετά = "after", "beyond", "with", "adjacent", "self"), is a prefix used in English to indicate a concept which is an abstraction from another concept, used to complete or add to the latter.

''Metaprogramming is the writing of computer programs that write or manipulate other programs (or themselves) as their data, or that do part of the work at compile time that would otherwise be done at runtime. In many cases, this allows programmers to get more done in the same amount of time as they would take to write all the code manually, or it gives programs greater flexibility to efficiently handle new situations without recompilation.'' Source: [http://en.wikipedia.org/wiki/Metaprogramming]

Metaprogramming is divided into runtime metaprogramming, also known as reflection, and compile time metaprogramming. Reflection is more interesting since it allows interaction and modification of objects, components and structures that do not exist at compile time.

== Examples of Metaprograms ==

*the compiler or interpreter of your favourite language
*Lex and Yacc
*CORBA's IDL compiler
*a Quine (a program that, when executed, prints a copy of its own source code - see QuineProgram for examples)
*Programs to generate EJB code and XML from database metadata
*Macros are nothing but special cases of metaprograms, as they are replaced by the actual code during macro expansion.

Source: [http://c2.com/cgi/wiki?MetaProgramming]

== Metaprogramming style in various languages ==

Metaprogramming seems to have origniated in Lisp. John Foderaro mentions Lisp as a programmable programming language. Lisp facilitates reflection through the use of an interpreter implemented in the same language. Unlike Smalltalk and Lisp, Java and C++ do not feature extensive built-in reflection facilities.

=== Metaprogramming in Ruby ===
Ruby is a dynamically-typed, interpreted, object oriented language. One of the unique aspects of Ruby is its extensive reflexive metaprogramming facilities.

==== What makes Ruby good for metaprogramming ====
*Ruby is Dynamic and reflective
*Everything is open to change
*Blocks allow writing new control structures
*Most declarations are executable statements
*An easy syntax

==== Classification of metaprogramming features in Ruby ====
* The dynamic nature of Ruby supports creating classes and methods at runtime
* Methods can be defined directly on Singleton classes: class_eval can be used to define methods on singleton classes. This will then modify the behaviour of the sub classes(if any) and not the base class.
* Blocks and proc objects: Materializing a Proc and saving this in variables and sending it around is a good way to use metaprogramming to do interesting things. Lambda function is used to define proc objects
* The different evals: There are 4 different evals in Ruby
** eval: This call can take a string or binding to evaluate but not a block
** class_eval: It is just a alias for module_eval
** instance_eval: It will evaluate the string or the block in the context of the receiver. Thus it sets self to be the receiver.
** module_eval: It will evaluate the string or the block in the context of the module it is called on. Thus it is used to define new methods on singleton classes. This is the most commonly used eval call.

The difference between the above 4 evals can be understood with examples [http://www.elctech.com/snippets/the-difference-between-eval-class_eval-module_eval-and-instance_eval here]. Another useful external link on evals can be found [http://4loc.wordpress.com/2009/05/29/eval-module_eval-and-instance_eval/ here]

==== Examples ====
We begin by showing how methods can be defined dynamically in Ruby. Consider we need a method that duplicates strings eg. "foo".duplicate -> "foofoo". And a deduplicate method for removing duplication eg. "foofoo".deduplicate -> "foo". We can define such methods dynamically in Ruby. This ''dynamic'' feature in Ruby forms the simplest kind of metapgrogramming.

class String
def duplicate
self * 2
end
def deduplicate
self[0, self.length/2]
end
end

For instance attr_reader, attr_writer, attr_accessor are inbuilt keywords that declare the object properties. These are actually not just syntax, but methods defined in Module. ''These methods are written in C''. In other words, the ''object language'' here is Ruby but the ''metalanguage'' is C - Refer [http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki2_1_ma#Appendix Appendix]. Representing the functionality for the attr_reader method as a metaprogram in Ruby.

class Module
def attr_reader (*syms)
sys.each do |sym|
class_eval %{def #{sym} @#{sym} end}
end
end
end

Consider how define_method can be used dynamically in Ruby
Eagle=Class.new
e=Eagle.new
class Eagle
define_method:fly do
puts "I am flying"
end
end
e.fly
Output: ''I am flying''

Rails becomes an all-powerful MVC framework, thanks to the metaprogramming features in Ruby.

''Other elaborate examples can be found in the [http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki2_1_ma#References References] section of this wiki page. A detailed discussion on Metaprogramming in Ruby was done in the CSC517 course lecture, the notes for which can be found [http://courses.ncsu.edu/csc517/common/lectures/notes/lec12-f09.pdf here]''

=== Metaprogramming in C++ ===

C++ provides for a type of metaprogramming called as [http://en.wikipedia.org/wiki/Template_metaprogramming template metaprograming]. Template Metaprogramming (TMP) is a programming technique that uses the priniciple of [http://en.wikipedia.org/wiki/Name_binding early binding]. This means that pieces of codes called templates are replaced by actual code including compile-time constants, data structures, and complete functions. Then the compiler puts together all the code and compiles it. Hence the compiler in a sense acts as a "virtual computer" [http://www.codeproject.com/KB/cpp/crc_meta.aspx] as it replaces parts of the program with instructions, which would otherwise have been done at run time.

In TMP similar groups of lines of codes are replaced by a common template. Initially the template has to be defined with a base set of lines of code which are common in all. Then at the time of usage, templates have to be instantiated. Thus the templte definition specifies the general form of the code whereas the instantiation gives the specific lines of code formed from the template definition.

====Examples ====
'''Calculating a value at compile time''' 
The code to find summation of a number without using templates can be given as: 
int summation(int n)
{
if (n == 0 )
return 0;
return n + summation(n - 1);
}
void findsummation()
{
int a = summation(5); //a= (5+ 4 + 3 + 2 + 1 + 0) == 15
int b = summation(0); //b=0
}

Now using templates the same program can be written as:

template <int N>
//TEMPLATE DEFINITION
struct Summation
{
enum { value = N + Summation<N - 1>::value };
};
template <>
struct Summation<0>
{
enum { value = 0 };
};
void findsummation()
{
int a = Summation<5>::value; // == 15 // INSTANTIATION
int b = Summation<0>::value; // == 1 // INSTANTIATION
}

Thus with templates, the values of a and b were calculated at compile time rather than at run time. This was possible because 5 and 0 were literals, if they had been variables then their values wouldn’t have been known at compile time and hence a and b could not have been calculated at compile time.

'''Loop unrolling''' 
Further templates can be used to unroll loops, that is a loop is replaced by repeating the code within the loop a certain number of times. [http://www.codeproject.com/KB/cpp/crc_meta.aspx more on this example]

template< int i >
class LOOP{
public:
static inline void EXEC(){
cout << "A-" <::EXEC();
cout << "B-" <{
public:
static inline void EXEC(){
cout << "A-" << i;
cout << "\n";
cout << "B-" << i;
}
};

The output of LOOP< 8 >::EXEC() is shown below: 
A-8 A-7 A-6 A-5 A-4 A-3 A-2 A-1 A-0 
B-0 B-1 B-2 B-3 B-4 B-5 B-6 B-7 B-8 

At compile time the loop unrolls itself and produces the following lines of code:

cout << "A-" << 8 << " ";
cout << "A-" << 7 << " ";
...
cout << "A-" << 0;
cout << "\n";
cout << "B-" << 0;
...
cout << "B-" << 7 << " ";
cout << "B-" << 8 << " ";

More Examples can be found at [http://en.wikibooks.org/wiki/C++_Programming/Template/Template_Meta-Programming C++ Template Programming], [http://en.wikipedia.org/wiki/Template_metaprogramming Template Metaprogramming] and [http://www.codeproject.com/KB/cpp/crc_meta.aspx TMP in c++]

=== Illustrating the differences ===
Unlike Ruby, C++ does not support a built-in metaprogramming system aside from template metaprogramming. Template programming is also known as "programming at compile time". Templates allow the compiler to determine certain variable and object types at compile time. The disadvantages of templates are : i) it is not specialized enough (C++ templates are Turing-complete [http://homepage.mac.com/sigfpe/Computing/peano.html]. Often they can be used for collection classes but they can also be employed in metaprogramming. This can make it hard to figure out how templates can be used to solve a specific problem), ii) poor error messages (when errors occur at compile time due to incorrectness of templates, the error messages can be cryptic)

== Conclusion ==
Metaprogramming is thus an essential and useful programming feature that allows elimination of duplicated code and enables clean execution with lesser lines of code. The style of metaprogramming differs when it comes to different languages. Ruby and Lisp have more specialized metaprogramming constructs as compared to Java or C++. Metaprogramming is apparently is a higher-level concept and probably used often by expert programmers, nevertheless through metaprogramming the overall code or program becomes very easy to interpret. Its a trade-off that should be balanced by software programmers.

== Appendix ==
* Metalanguage: The language in which the metaprogram is written
* Object language: The language of the programs that are manipulated
* Reflection or Reflexivity: The ability of a programming language to be its own metalanguage
* Early Binding: In programming languages, name binding is the association of values with identifiers. The binding of names before the program is run is called early (also "static")

== References/External Links ==
# [http://en.wikipedia.org/wiki/Metaprogramming Wikipedia article on metaprogramming]
# [http://c2.com/cgi/wiki?MetaProgramming Metaprogramming]
# [http://www.codeproject.com/KB/cpp/crc_meta.aspx Template programming in C++]
# [http://homepage.mac.com/sigfpe/Computing/peano.html Turing completeness in C++]
# [http://www.vanderburg.org/Speaking/Stuff/oscon05.pdf presentation about Meta programming in Ruby made at the 2005 O’Reilly Open Source Convention by Glenn Vanderburg]
# [http://theplana.wordpress.com/2007/03/12/how-to-define-a-attribute-using-metaprogramming/ Defining attributes with Metaprogramming]
# More examples on Ruby metaprogramming
## [http://ozone.wordpress.com/2006/03/02/binary-search-tree-sauce-ruby-part-1/ Link 1]
## [http://www.ruby-doc.org/core/classes/Object.src/M000366.html Link 2]
## [http://expressica.com/category/metaprogramming/ Link 3]
# [http://ozone.wordpress.com/2006/02/22/rubybeans-a-short-example-of-ruby-metaprogramming/#comment-1286 Rubybeans and Metaprogramming]
# [http://reference.jumpingmonkey.org/programming_languages/ruby/ruby-metaprogramming.html Metaprogramming in Ruby]
# [http://en.wikibooks.org/wiki/C++_Programming/Template/Template_Meta-Programming C++ Template Programming]
# [http://en.wikipedia.org/wiki/Template_metaprogramming Template Metaprogramming]
# [http://www.codeproject.com/KB/cpp/crc_meta.aspx TMP in c++]

CSC/ECE 517 Fall 2009/wiki2 1 ma

2009-10-08T22:09:19Z

Mjampal: /* Metaprogramming in C++ */

= Metaprogramming =
== What is Metaprogramming? ==
'''Meta-''' (from Greek: μετά = "after", "beyond", "with", "adjacent", "self"), is a prefix used in English to indicate a concept which is an abstraction from another concept, used to complete or add to the latter.

''Metaprogramming is the writing of computer programs that write or manipulate other programs (or themselves) as their data, or that do part of the work at compile time that would otherwise be done at runtime. In many cases, this allows programmers to get more done in the same amount of time as they would take to write all the code manually, or it gives programs greater flexibility to efficiently handle new situations without recompilation.'' Source: [http://en.wikipedia.org/wiki/Metaprogramming]

Metaprogramming is divided into runtime metaprogramming, also known as reflection, and compile time metaprogramming. Reflection is more interesting since it allows interaction and modification of objects, components and structures that do not exist at compile time.

== Examples of Metaprograms ==

*the compiler or interpreter of your favourite language
*Lex and Yacc
*CORBA's IDL compiler
*a Quine (a program that, when executed, prints a copy of its own source code - see QuineProgram for examples)
*Programs to generate EJB code and XML from database metadata
*Macros are nothing but special cases of metaprograms, as they are replaced by the actual code during macro expansion.

Source: [http://c2.com/cgi/wiki?MetaProgramming]

== Metaprogramming style in various languages ==

Metaprogramming seems to have origniated in Lisp. John Foderaro mentions Lisp as a programmable programming language. Lisp facilitates reflection through the use of an interpreter implemented in the same language. Unlike Smalltalk and Lisp, Java and C++ do not feature extensive built-in reflection facilities.

=== Metaprogramming in Ruby ===
Ruby is a dynamically-typed, interpreted, object oriented language. One of the unique aspects of Ruby is its extensive reflexive metaprogramming facilities.

==== What makes Ruby good for metaprogramming ====
*Ruby is Dynamic and reflective
*Everything is open to change
*Blocks allow writing new control structures
*Most declarations are executable statements
*An easy syntax

==== Classification of metaprogramming features in Ruby ====
* The dynamic nature of Ruby supports creating classes and methods at runtime
* Methods can be defined directly on Singleton classes: class_eval can be used to define methods on singleton classes. This will then modify the behaviour of the sub classes(if any) and not the base class.
* Blocks and proc objects: Materializing a Proc and saving this in variables and sending it around is a good way to use metaprogramming to do interesting things. Lambda function is used to define proc objects
* The different evals: There are 4 different evals in Ruby
** eval: This call can take a string or binding to evaluate but not a block
** class_eval: It is just a alias for module_eval
** instance_eval: It will evaluate the string or the block in the context of the receiver. Thus it sets self to be the receiver.
** module_eval: It will evaluate the string or the block in the context of the module it is called on. Thus it is used to define new methods on singleton classes. This is the most commonly used eval call.

The difference between the above 4 evals can be understood with examples [http://www.elctech.com/snippets/the-difference-between-eval-class_eval-module_eval-and-instance_eval here]. Another useful external link on evals can be found [http://4loc.wordpress.com/2009/05/29/eval-module_eval-and-instance_eval/ here]

==== Examples ====
We begin by showing how methods can be defined dynamically in Ruby. Consider we need a method that duplicates strings eg. "foo".duplicate -> "foofoo". And a deduplicate method for removing duplication eg. "foofoo".deduplicate -> "foo". We can define such methods dynamically in Ruby. This ''dynamic'' feature in Ruby forms the simplest kind of metapgrogramming.

class String
def duplicate
self * 2
end
def deduplicate
self[0, self.length/2]
end
end

For instance attr_reader, attr_writer, attr_accessor are inbuilt keywords that declare the object properties. These are actually not just syntax, but methods defined in Module. ''These methods are written in C''. In other words, the ''object language'' here is Ruby but the ''metalanguage'' is C - Refer [http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki2_1_ma#Appendix Appendix]. Representing the functionality for the attr_reader method as a metaprogram in Ruby.

class Module
def attr_reader (*syms)
sys.each do |sym|
class_eval %{def #{sym} @#{sym} end}
end
end
end

Consider how define_method can be used dynamically in Ruby
Eagle=Class.new
e=Eagle.new
class Eagle
define_method:fly do
puts "I am flying"
end
end
e.fly
Output: ''I am flying''

Rails becomes an all-powerful MVC framework, thanks to the metaprogramming features in Ruby.

''Other elaborate examples can be found in the [http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki2_1_ma#References References] section of this wiki page. A detailed discussion on Metaprogramming in Ruby was done in the CSC517 course lecture, the notes for which can be found [http://courses.ncsu.edu/csc517/common/lectures/notes/lec12-f09.pdf here]''

=== Metaprogramming in C++ ===

C++ provides for a type of metaprogramming called as [http://en.wikipedia.org/wiki/Template_metaprogramming template metaprograming]. Template Metaprogramming (TMP) is a programming technique that uses the priniciple of [http://en.wikipedia.org/wiki/Name_binding early binding]. This means that pieces of codes called templates are replaced by actual code including compile-time constants, data structures, and complete functions. Then the compiler puts together all the code and compiles it. Hence the compiler in a sense acts as a "virtual computer" [http://www.codeproject.com/KB/cpp/crc_meta.aspx] as it replaces parts of the program with instructions, which would otherwise have been done at run time.

In TMP similar groups of lines of codes are replaced by a common template. Initially the template has to be defined with a base set of lines of code which are common in all. Then at the time of usage, templates have to be instantiated. Thus the templte definition specifies the general form of the code whereas the instantiation gives the specific lines of code formed from the template definition.

====Examples ====
'''Calculating a value at compile time''' 
The code to find summation of a number without using templates can be given as: 
int summation(int n)
{
if (n == 0 )
return 0;
return n + summation(n - 1);
}
void findsummation()
{
int a = summation(5); //a= (5+ 4 + 3 + 2 + 1 + 0) == 15
int b = summation(0); //b=0
}

Now using templates the same program can be written as:

template <int N>
//TEMPLATE DEFINITION
struct Summation
{
enum { value = N + Summation<N - 1>::value };
};
template <>
struct Summation<0>
{
enum { value = 0 };
};
void findsummation()
{
int a = Summation<5>::value; // == 15 // INSTANTIATION
int b = Summation<0>::value; // == 1 // INSTANTIATION
}

Thus with templates, the values of a and b were calculated at compile time rather than at run time. This was possible because 5 and 0 were literals, if they had been variables then their values wouldn’t have been known at compile time and hence a and b could not have been calculated at compile time.

'''Loop unrolling''' 
Further templates can be used to unroll loops, that is a loop is replaced by repeating the code within the loop a certain number of times. [http://www.codeproject.com/KB/cpp/crc_meta.aspx more on this example]

template< int i >
class LOOP{
public:
static inline void EXEC(){
cout << "A-" <::EXEC();
cout << "B-" <{
public:
static inline void EXEC(){
cout << "A-" << i;
cout << "\n";
cout << "B-" << i;
}
};

The output of LOOP< 8 >::EXEC() is shown below: 
A-8 A-7 A-6 A-5 A-4 A-3 A-2 A-1 A-0 
B-0 B-1 B-2 B-3 B-4 B-5 B-6 B-7 B-8 

At compile time the loop unrolls itself and produces the following lines of code:

cout << "A-" << 8 << " ";
cout << "A-" << 7 << " ";
...
cout << "A-" << 0;
cout << "\n";
cout << "B-" << 0;
...
cout << "B-" << 7 << " ";
cout << "B-" << 8 << " ";

More Examples can be found at [http://en.wikibooks.org/wiki/C++_Programming/Template/Template_Meta-Programming C++ Template Programming], [http://en.wikipedia.org/wiki/Template_metaprogramming Template Metaprogramming] and [http://www.codeproject.com/KB/cpp/crc_meta.aspx TMP in c++]

=== Illustrating the differences ===
Unlike Ruby, C++ does not support a built-in metaprogramming system aside from template metaprogramming. Template programming is also known as "programming at compile time". Templates allow the compiler to determine certain variable and object types at compile time. The disadvantages of templates are : i) it is not specialized enough (C++ templates are Turing-complete [http://homepage.mac.com/sigfpe/Computing/peano.html]. Often they can be used for collection classes but they can also be employed in metaprogramming. This can make it hard to figure out how templates can be used to solve a specific problem), ii) poor error messages (when errors occur at compile time due to incorrectness of templates, the error messages can be cryptic)

== Conclusion ==
Metaprogramming is thus an essential and useful programming feature that allows elimination of duplicated code and enables clean execution with lesser lines of code. The style of metaprogramming differs when it comes to different languages. Ruby and Lisp have more specialized metaprogramming constructs as compared to Java or C++. Metaprogramming is apparently is a higher-level concept and probably used often by expert programmers, nevertheless through metaprogramming the overall code or program becomes very easy to interpret. Its a trade-off that should be balanced by software programmers.

== Appendix ==
* Metalanguage: The language in which the metaprogram is written
* Object language: The language of the programs that are manipulated
* Reflection or Reflexivity: The ability of a programming language to be its own metalanguage

== References/External Links ==
# [http://en.wikipedia.org/wiki/Metaprogramming Wikipedia article on metaprogramming]
# [http://c2.com/cgi/wiki?MetaProgramming Metaprogramming]
# [http://www.codeproject.com/KB/cpp/crc_meta.aspx Template programming in C++]
# [http://homepage.mac.com/sigfpe/Computing/peano.html Turing completeness in C++]
# [http://www.vanderburg.org/Speaking/Stuff/oscon05.pdf presentation about Meta programming in Ruby made at the 2005 O’Reilly Open Source Convention by Glenn Vanderburg]
# [http://theplana.wordpress.com/2007/03/12/how-to-define-a-attribute-using-metaprogramming/ Defining attributes with Metaprogramming]
# More examples on Ruby metaprogramming
## [http://ozone.wordpress.com/2006/03/02/binary-search-tree-sauce-ruby-part-1/ Link 1]
## [http://www.ruby-doc.org/core/classes/Object.src/M000366.html Link 2]
## [http://expressica.com/category/metaprogramming/ Link 3]
# [http://ozone.wordpress.com/2006/02/22/rubybeans-a-short-example-of-ruby-metaprogramming/#comment-1286 Rubybeans and Metaprogramming]
# [http://reference.jumpingmonkey.org/programming_languages/ruby/ruby-metaprogramming.html Metaprogramming in Ruby]
# [http://en.wikibooks.org/wiki/C++_Programming/Template/Template_Meta-Programming C++ Template Programming]
# [http://en.wikipedia.org/wiki/Template_metaprogramming Template Metaprogramming]
# [http://www.codeproject.com/KB/cpp/crc_meta.aspx TMP in c++]

CSC/ECE 517 Fall 2009/wiki2 1 ma

2009-10-08T22:04:07Z

Mjampal: /* References/External Links */

= Metaprogramming =
== What is Metaprogramming? ==
'''Meta-''' (from Greek: μετά = "after", "beyond", "with", "adjacent", "self"), is a prefix used in English to indicate a concept which is an abstraction from another concept, used to complete or add to the latter.

''Metaprogramming is the writing of computer programs that write or manipulate other programs (or themselves) as their data, or that do part of the work at compile time that would otherwise be done at runtime. In many cases, this allows programmers to get more done in the same amount of time as they would take to write all the code manually, or it gives programs greater flexibility to efficiently handle new situations without recompilation.'' Source: [http://en.wikipedia.org/wiki/Metaprogramming]

Metaprogramming is divided into runtime metaprogramming, also known as reflection, and compile time metaprogramming. Reflection is more interesting since it allows interaction and modification of objects, components and structures that do not exist at compile time.

== Examples of Metaprograms ==

*the compiler or interpreter of your favourite language
*Lex and Yacc
*CORBA's IDL compiler
*a Quine (a program that, when executed, prints a copy of its own source code - see QuineProgram for examples)
*Programs to generate EJB code and XML from database metadata
*Macros are nothing but special cases of metaprograms, as they are replaced by the actual code during macro expansion.

Source: [http://c2.com/cgi/wiki?MetaProgramming]

== Metaprogramming style in various languages ==

Metaprogramming seems to have origniated in Lisp. John Foderaro mentions Lisp as a programmable programming language. Lisp facilitates reflection through the use of an interpreter implemented in the same language. Unlike Smalltalk and Lisp, Java and C++ do not feature extensive built-in reflection facilities.

=== Metaprogramming in Ruby ===
Ruby is a dynamically-typed, interpreted, object oriented language. One of the unique aspects of Ruby is its extensive reflexive metaprogramming facilities.

==== What makes Ruby good for metaprogramming ====
*Ruby is Dynamic and reflective
*Everything is open to change
*Blocks allow writing new control structures
*Most declarations are executable statements
*An easy syntax

==== Classification of metaprogramming features in Ruby ====
* The dynamic nature of Ruby supports creating classes and methods at runtime
* Methods can be defined directly on Singleton classes: class_eval can be used to define methods on singleton classes. This will then modify the behaviour of the sub classes(if any) and not the base class.
* Blocks and proc objects: Materializing a Proc and saving this in variables and sending it around is a good way to use metaprogramming to do interesting things. Lambda function is used to define proc objects
* The different evals: There are 4 different evals in Ruby
** eval: This call can take a string or binding to evaluate but not a block
** class_eval: It is just a alias for module_eval
** instance_eval: It will evaluate the string or the block in the context of the receiver. Thus it sets self to be the receiver.
** module_eval: It will evaluate the string or the block in the context of the module it is called on. Thus it is used to define new methods on singleton classes. This is the most commonly used eval call.

The difference between the above 4 evals can be understood with examples [http://www.elctech.com/snippets/the-difference-between-eval-class_eval-module_eval-and-instance_eval here]. Another useful external link on evals can be found [http://4loc.wordpress.com/2009/05/29/eval-module_eval-and-instance_eval/ here]

==== Examples ====
We begin by showing how methods can be defined dynamically in Ruby. Consider we need a method that duplicates strings eg. "foo".duplicate -> "foofoo". And a deduplicate method for removing duplication eg. "foofoo".deduplicate -> "foo". We can define such methods dynamically in Ruby. This ''dynamic'' feature in Ruby forms the simplest kind of metapgrogramming.

class String
def duplicate
self * 2
end
def deduplicate
self[0, self.length/2]
end
end

For instance attr_reader, attr_writer, attr_accessor are inbuilt keywords that declare the object properties. These are actually not just syntax, but methods defined in Module. ''These methods are written in C''. In other words, the ''object language'' here is Ruby but the ''metalanguage'' is C - Refer [http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki2_1_ma#Appendix Appendix]. Representing the functionality for the attr_reader method as a metaprogram in Ruby.

class Module
def attr_reader (*syms)
sys.each do |sym|
class_eval %{def #{sym} @#{sym} end}
end
end
end

Consider how define_method can be used dynamically in Ruby
Eagle=Class.new
e=Eagle.new
class Eagle
define_method:fly do
puts "I am flying"
end
end
e.fly
Output: ''I am flying''

Rails becomes an all-powerful MVC framework, thanks to the metaprogramming features in Ruby.

''Other elaborate examples can be found in the [http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki2_1_ma#References References] section of this wiki page. A detailed discussion on Metaprogramming in Ruby was done in the CSC517 course lecture, the notes for which can be found [http://courses.ncsu.edu/csc517/common/lectures/notes/lec12-f09.pdf here]''

=== Metaprogramming in C++ ===

C++ provides for a type of metaprogramming called as [http://en.wikipedia.org/wiki/Template_metaprogramming template metaprograming]. Template Metaprogramming (TMP) is a programming technique that uses the priniciple of early binding . This means that pieces of codes called templates are replaced by actual code including compile-time constants, data structures, and complete functions. Then the compiler puts together all the code and compiles it. Hence the compiler in a sense acts as a "virtual computer" [http://www.codeproject.com/KB/cpp/crc_meta.aspx] as it replaces parts of the program with instructions, which would otherwise have been done at run time.

In TMP similar groups of lines of codes are replaced by a common template. Initially the template has to be defined with a base set of lines of code which are common in all. Then at the time of usage, templates have to be instantiated. Thus the templte definition specifies the general form of the code whereas the instantiation gives the specific lines of code formed from the template definition.

====Examples ====
'''Calculating a value at compile time''' 
The code to find summation of a number without using templates can be given as: 
int summation(int n)
{
if (n == 0 )
return 0;
return n + summation(n - 1);
}
void findsummation()
{
int a = summation(5); //a= (5+ 4 + 3 + 2 + 1 + 0) == 15
int b = summation(0); //b=0
}

Now using templates the same program can be written as:

template <int N>
//TEMPLATE DEFINITION
struct Summation
{
enum { value = N + Summation<N - 1>::value };
};
template <>
struct Summation<0>
{
enum { value = 0 };
};
void findsummation()
{
int a = Summation<5>::value; // == 15 // INSTANTIATION
int b = Summation<0>::value; // == 1 // INSTANTIATION
}

Thus with templates, the values of a and b were calculated at compile time rather than at run time. This was possible because 5 and 0 were literals, if they had been variables then their values wouldn’t have been known at compile time and hence a and b could not have been calculated at compile time.

'''Loop unrolling''' 
Further templates can be used to unroll loops, that is a loop is replaced by repeating the code within the loop a certain number of times. [http://www.codeproject.com/KB/cpp/crc_meta.aspx more on this example]

template< int i >
class LOOP{
public:
static inline void EXEC(){
cout << "A-" <::EXEC();
cout << "B-" <{
public:
static inline void EXEC(){
cout << "A-" << i;
cout << "\n";
cout << "B-" << i;
}
};

The output of LOOP< 8 >::EXEC() is shown below: 
A-8 A-7 A-6 A-5 A-4 A-3 A-2 A-1 A-0 
B-0 B-1 B-2 B-3 B-4 B-5 B-6 B-7 B-8 

At compile time the loop unrolls itself and produces the following lines of code:

cout << "A-" << 8 << " ";
cout << "A-" << 7 << " ";
...
cout << "A-" << 0;
cout << "\n";
cout << "B-" << 0;
...
cout << "B-" << 7 << " ";
cout << "B-" << 8 << " ";

More Examples can be found at [http://en.wikibooks.org/wiki/C++_Programming/Template/Template_Meta-Programming C++ Template Programming], [http://en.wikipedia.org/wiki/Template_metaprogramming Template Metaprogramming] and [http://www.codeproject.com/KB/cpp/crc_meta.aspx TMP in c++]

=== Illustrating the differences ===
Unlike Ruby, C++ does not support a built-in metaprogramming system aside from template metaprogramming. Template programming is also known as "programming at compile time". Templates allow the compiler to determine certain variable and object types at compile time. The disadvantages of templates are : i) it is not specialized enough (C++ templates are Turing-complete [http://homepage.mac.com/sigfpe/Computing/peano.html]. Often they can be used for collection classes but they can also be employed in metaprogramming. This can make it hard to figure out how templates can be used to solve a specific problem), ii) poor error messages (when errors occur at compile time due to incorrectness of templates, the error messages can be cryptic)

== Conclusion ==
Metaprogramming is thus an essential and useful programming feature that allows elimination of duplicated code and enables clean execution with lesser lines of code. The style of metaprogramming differs when it comes to different languages. Ruby and Lisp have more specialized metaprogramming constructs as compared to Java or C++. Metaprogramming is apparently is a higher-level concept and probably used often by expert programmers, nevertheless through metaprogramming the overall code or program becomes very easy to interpret. Its a trade-off that should be balanced by software programmers.

== Appendix ==
* Metalanguage: The language in which the metaprogram is written
* Object language: The language of the programs that are manipulated
* Reflection or Reflexivity: The ability of a programming language to be its own metalanguage

== References/External Links ==
# [http://en.wikipedia.org/wiki/Metaprogramming Wikipedia article on metaprogramming]
# [http://c2.com/cgi/wiki?MetaProgramming Metaprogramming]
# [http://www.codeproject.com/KB/cpp/crc_meta.aspx Template programming in C++]
# [http://homepage.mac.com/sigfpe/Computing/peano.html Turing completeness in C++]
# [http://www.vanderburg.org/Speaking/Stuff/oscon05.pdf presentation about Meta programming in Ruby made at the 2005 O’Reilly Open Source Convention by Glenn Vanderburg]
# [http://theplana.wordpress.com/2007/03/12/how-to-define-a-attribute-using-metaprogramming/ Defining attributes with Metaprogramming]
# More examples on Ruby metaprogramming
## [http://ozone.wordpress.com/2006/03/02/binary-search-tree-sauce-ruby-part-1/ Link 1]
## [http://www.ruby-doc.org/core/classes/Object.src/M000366.html Link 2]
## [http://expressica.com/category/metaprogramming/ Link 3]
# [http://ozone.wordpress.com/2006/02/22/rubybeans-a-short-example-of-ruby-metaprogramming/#comment-1286 Rubybeans and Metaprogramming]
# [http://reference.jumpingmonkey.org/programming_languages/ruby/ruby-metaprogramming.html Metaprogramming in Ruby]
# [http://en.wikibooks.org/wiki/C++_Programming/Template/Template_Meta-Programming C++ Template Programming]
# [http://en.wikipedia.org/wiki/Template_metaprogramming Template Metaprogramming]
# [http://www.codeproject.com/KB/cpp/crc_meta.aspx TMP in c++]

CSC/ECE 517 Fall 2009/wiki2 1 ma

2009-10-08T22:02:09Z

Mjampal: /* Examples */

= Metaprogramming =
== What is Metaprogramming? ==
'''Meta-''' (from Greek: μετά = "after", "beyond", "with", "adjacent", "self"), is a prefix used in English to indicate a concept which is an abstraction from another concept, used to complete or add to the latter.

''Metaprogramming is the writing of computer programs that write or manipulate other programs (or themselves) as their data, or that do part of the work at compile time that would otherwise be done at runtime. In many cases, this allows programmers to get more done in the same amount of time as they would take to write all the code manually, or it gives programs greater flexibility to efficiently handle new situations without recompilation.'' Source: [http://en.wikipedia.org/wiki/Metaprogramming]

Metaprogramming is divided into runtime metaprogramming, also known as reflection, and compile time metaprogramming. Reflection is more interesting since it allows interaction and modification of objects, components and structures that do not exist at compile time.

== Examples of Metaprograms ==

*the compiler or interpreter of your favourite language
*Lex and Yacc
*CORBA's IDL compiler
*a Quine (a program that, when executed, prints a copy of its own source code - see QuineProgram for examples)
*Programs to generate EJB code and XML from database metadata
*Macros are nothing but special cases of metaprograms, as they are replaced by the actual code during macro expansion.

Source: [http://c2.com/cgi/wiki?MetaProgramming]

== Metaprogramming style in various languages ==

Metaprogramming seems to have origniated in Lisp. John Foderaro mentions Lisp as a programmable programming language. Lisp facilitates reflection through the use of an interpreter implemented in the same language. Unlike Smalltalk and Lisp, Java and C++ do not feature extensive built-in reflection facilities.

=== Metaprogramming in Ruby ===
Ruby is a dynamically-typed, interpreted, object oriented language. One of the unique aspects of Ruby is its extensive reflexive metaprogramming facilities.

==== What makes Ruby good for metaprogramming ====
*Ruby is Dynamic and reflective
*Everything is open to change
*Blocks allow writing new control structures
*Most declarations are executable statements
*An easy syntax

==== Classification of metaprogramming features in Ruby ====
* The dynamic nature of Ruby supports creating classes and methods at runtime
* Methods can be defined directly on Singleton classes: class_eval can be used to define methods on singleton classes. This will then modify the behaviour of the sub classes(if any) and not the base class.
* Blocks and proc objects: Materializing a Proc and saving this in variables and sending it around is a good way to use metaprogramming to do interesting things. Lambda function is used to define proc objects
* The different evals: There are 4 different evals in Ruby
** eval: This call can take a string or binding to evaluate but not a block
** class_eval: It is just a alias for module_eval
** instance_eval: It will evaluate the string or the block in the context of the receiver. Thus it sets self to be the receiver.
** module_eval: It will evaluate the string or the block in the context of the module it is called on. Thus it is used to define new methods on singleton classes. This is the most commonly used eval call.

The difference between the above 4 evals can be understood with examples [http://www.elctech.com/snippets/the-difference-between-eval-class_eval-module_eval-and-instance_eval here]. Another useful external link on evals can be found [http://4loc.wordpress.com/2009/05/29/eval-module_eval-and-instance_eval/ here]

==== Examples ====
We begin by showing how methods can be defined dynamically in Ruby. Consider we need a method that duplicates strings eg. "foo".duplicate -> "foofoo". And a deduplicate method for removing duplication eg. "foofoo".deduplicate -> "foo". We can define such methods dynamically in Ruby. This ''dynamic'' feature in Ruby forms the simplest kind of metapgrogramming.

class String
def duplicate
self * 2
end
def deduplicate
self[0, self.length/2]
end
end

For instance attr_reader, attr_writer, attr_accessor are inbuilt keywords that declare the object properties. These are actually not just syntax, but methods defined in Module. ''These methods are written in C''. In other words, the ''object language'' here is Ruby but the ''metalanguage'' is C - Refer [http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki2_1_ma#Appendix Appendix]. Representing the functionality for the attr_reader method as a metaprogram in Ruby.

class Module
def attr_reader (*syms)
sys.each do |sym|
class_eval %{def #{sym} @#{sym} end}
end
end
end

Consider how define_method can be used dynamically in Ruby
Eagle=Class.new
e=Eagle.new
class Eagle
define_method:fly do
puts "I am flying"
end
end
e.fly
Output: ''I am flying''

Rails becomes an all-powerful MVC framework, thanks to the metaprogramming features in Ruby.

''Other elaborate examples can be found in the [http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki2_1_ma#References References] section of this wiki page. A detailed discussion on Metaprogramming in Ruby was done in the CSC517 course lecture, the notes for which can be found [http://courses.ncsu.edu/csc517/common/lectures/notes/lec12-f09.pdf here]''

=== Metaprogramming in C++ ===

C++ provides for a type of metaprogramming called as [http://en.wikipedia.org/wiki/Template_metaprogramming template metaprograming]. Template Metaprogramming (TMP) is a programming technique that uses the priniciple of early binding . This means that pieces of codes called templates are replaced by actual code including compile-time constants, data structures, and complete functions. Then the compiler puts together all the code and compiles it. Hence the compiler in a sense acts as a "virtual computer" [http://www.codeproject.com/KB/cpp/crc_meta.aspx] as it replaces parts of the program with instructions, which would otherwise have been done at run time.

In TMP similar groups of lines of codes are replaced by a common template. Initially the template has to be defined with a base set of lines of code which are common in all. Then at the time of usage, templates have to be instantiated. Thus the templte definition specifies the general form of the code whereas the instantiation gives the specific lines of code formed from the template definition.

====Examples ====
'''Calculating a value at compile time''' 
The code to find summation of a number without using templates can be given as: 
int summation(int n)
{
if (n == 0 )
return 0;
return n + summation(n - 1);
}
void findsummation()
{
int a = summation(5); //a= (5+ 4 + 3 + 2 + 1 + 0) == 15
int b = summation(0); //b=0
}

Now using templates the same program can be written as:

template <int N>
//TEMPLATE DEFINITION
struct Summation
{
enum { value = N + Summation<N - 1>::value };
};
template <>
struct Summation<0>
{
enum { value = 0 };
};
void findsummation()
{
int a = Summation<5>::value; // == 15 // INSTANTIATION
int b = Summation<0>::value; // == 1 // INSTANTIATION
}

Thus with templates, the values of a and b were calculated at compile time rather than at run time. This was possible because 5 and 0 were literals, if they had been variables then their values wouldn’t have been known at compile time and hence a and b could not have been calculated at compile time.

'''Loop unrolling''' 
Further templates can be used to unroll loops, that is a loop is replaced by repeating the code within the loop a certain number of times. [http://www.codeproject.com/KB/cpp/crc_meta.aspx more on this example]

template< int i >
class LOOP{
public:
static inline void EXEC(){
cout << "A-" <::EXEC();
cout << "B-" <{
public:
static inline void EXEC(){
cout << "A-" << i;
cout << "\n";
cout << "B-" << i;
}
};

The output of LOOP< 8 >::EXEC() is shown below: 
A-8 A-7 A-6 A-5 A-4 A-3 A-2 A-1 A-0 
B-0 B-1 B-2 B-3 B-4 B-5 B-6 B-7 B-8 

At compile time the loop unrolls itself and produces the following lines of code:

cout << "A-" << 8 << " ";
cout << "A-" << 7 << " ";
...
cout << "A-" << 0;
cout << "\n";
cout << "B-" << 0;
...
cout << "B-" << 7 << " ";
cout << "B-" << 8 << " ";

More Examples can be found at [http://en.wikibooks.org/wiki/C++_Programming/Template/Template_Meta-Programming C++ Template Programming], [http://en.wikipedia.org/wiki/Template_metaprogramming Template Metaprogramming] and [http://www.codeproject.com/KB/cpp/crc_meta.aspx TMP in c++]

=== Illustrating the differences ===
Unlike Ruby, C++ does not support a built-in metaprogramming system aside from template metaprogramming. Template programming is also known as "programming at compile time". Templates allow the compiler to determine certain variable and object types at compile time. The disadvantages of templates are : i) it is not specialized enough (C++ templates are Turing-complete [http://homepage.mac.com/sigfpe/Computing/peano.html]. Often they can be used for collection classes but they can also be employed in metaprogramming. This can make it hard to figure out how templates can be used to solve a specific problem), ii) poor error messages (when errors occur at compile time due to incorrectness of templates, the error messages can be cryptic)

== Conclusion ==
Metaprogramming is thus an essential and useful programming feature that allows elimination of duplicated code and enables clean execution with lesser lines of code. The style of metaprogramming differs when it comes to different languages. Ruby and Lisp have more specialized metaprogramming constructs as compared to Java or C++. Metaprogramming is apparently is a higher-level concept and probably used often by expert programmers, nevertheless through metaprogramming the overall code or program becomes very easy to interpret. Its a trade-off that should be balanced by software programmers.

== Appendix ==
* Metalanguage: The language in which the metaprogram is written
* Object language: The language of the programs that are manipulated
* Reflection or Reflexivity: The ability of a programming language to be its own metalanguage

== References/External Links ==
# [http://en.wikipedia.org/wiki/Metaprogramming Wikipedia article on metaprogramming]
# [http://c2.com/cgi/wiki?MetaProgramming Metaprogramming]
# [http://www.codeproject.com/KB/cpp/crc_meta.aspx Template programming in C++]
# [http://homepage.mac.com/sigfpe/Computing/peano.html Turing completeness in C++]
# [http://www.vanderburg.org/Speaking/Stuff/oscon05.pdf presentation about Meta programming in Ruby made at the 2005 O’Reilly Open Source Convention by Glenn Vanderburg]
# [http://theplana.wordpress.com/2007/03/12/how-to-define-a-attribute-using-metaprogramming/ Defining attributes with Metaprogramming]
# More examples on Ruby metaprogramming
## [http://ozone.wordpress.com/2006/03/02/binary-search-tree-sauce-ruby-part-1/ Link 1]
## [http://www.ruby-doc.org/core/classes/Object.src/M000366.html Link 2]
## [http://expressica.com/category/metaprogramming/ Link 3]
# [http://ozone.wordpress.com/2006/02/22/rubybeans-a-short-example-of-ruby-metaprogramming/#comment-1286 Rubybeans and Metaprogramming]
# [http://reference.jumpingmonkey.org/programming_languages/ruby/ruby-metaprogramming.html Metaprogramming in Ruby]

CSC/ECE 517 Fall 2009/wiki2 1 ma

2009-10-08T21:56:08Z

Mjampal: /* Examples */

= Metaprogramming =
== What is Metaprogramming? ==
'''Meta-''' (from Greek: μετά = "after", "beyond", "with", "adjacent", "self"), is a prefix used in English to indicate a concept which is an abstraction from another concept, used to complete or add to the latter.

''Metaprogramming is the writing of computer programs that write or manipulate other programs (or themselves) as their data, or that do part of the work at compile time that would otherwise be done at runtime. In many cases, this allows programmers to get more done in the same amount of time as they would take to write all the code manually, or it gives programs greater flexibility to efficiently handle new situations without recompilation.'' Source: [http://en.wikipedia.org/wiki/Metaprogramming]

Metaprogramming is divided into runtime metaprogramming, also known as reflection, and compile time metaprogramming. Reflection is more interesting since it allows interaction and modification of objects, components and structures that do not exist at compile time.

== Examples of Metaprograms ==

*the compiler or interpreter of your favourite language
*Lex and Yacc
*CORBA's IDL compiler
*a Quine (a program that, when executed, prints a copy of its own source code - see QuineProgram for examples)
*Programs to generate EJB code and XML from database metadata
*Macros are nothing but special cases of metaprograms, as they are replaced by the actual code during macro expansion.

Source: [http://c2.com/cgi/wiki?MetaProgramming]

== Metaprogramming style in various languages ==

Metaprogramming seems to have origniated in Lisp. John Foderaro mentions Lisp as a programmable programming language. Lisp facilitates reflection through the use of an interpreter implemented in the same language. Unlike Smalltalk and Lisp, Java and C++ do not feature extensive built-in reflection facilities.

=== Metaprogramming in Ruby ===
Ruby is a dynamically-typed, interpreted, object oriented language. One of the unique aspects of Ruby is its extensive reflexive metaprogramming facilities.

==== What makes Ruby good for metaprogramming ====
*Ruby is Dynamic and reflective
*Everything is open to change
*Blocks allow writing new control structures
*Most declarations are executable statements
*An easy syntax

==== Classification of metaprogramming features in Ruby ====
* The dynamic nature of Ruby supports creating classes and methods at runtime
* Methods can be defined directly on Singleton classes: class_eval can be used to define methods on singleton classes. This will then modify the behaviour of the sub classes(if any) and not the base class.
* Blocks and proc objects: Materializing a Proc and saving this in variables and sending it around is a good way to use metaprogramming to do interesting things. Lambda function is used to define proc objects
* The different evals: There are 4 different evals in Ruby
** eval: This call can take a string or binding to evaluate but not a block
** class_eval: It is just a alias for module_eval
** instance_eval: It will evaluate the string or the block in the context of the receiver. Thus it sets self to be the receiver.
** module_eval: It will evaluate the string or the block in the context of the module it is called on. Thus it is used to define new methods on singleton classes. This is the most commonly used eval call.

The difference between the above 4 evals can be understood with examples [http://www.elctech.com/snippets/the-difference-between-eval-class_eval-module_eval-and-instance_eval here]. Another useful external link on evals can be found [http://4loc.wordpress.com/2009/05/29/eval-module_eval-and-instance_eval/ here]

==== Examples ====
We begin by showing how methods can be defined dynamically in Ruby. Consider we need a method that duplicates strings eg. "foo".duplicate -> "foofoo". And a deduplicate method for removing duplication eg. "foofoo".deduplicate -> "foo". We can define such methods dynamically in Ruby. This ''dynamic'' feature in Ruby forms the simplest kind of metapgrogramming.

class String
def duplicate
self * 2
end
def deduplicate
self[0, self.length/2]
end
end

For instance attr_reader, attr_writer, attr_accessor are inbuilt keywords that declare the object properties. These are actually not just syntax, but methods defined in Module. ''These methods are written in C''. In other words, the ''object language'' here is Ruby but the ''metalanguage'' is C - Refer [http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki2_1_ma#Appendix Appendix]. Representing the functionality for the attr_reader method as a metaprogram in Ruby.

class Module
def attr_reader (*syms)
sys.each do |sym|
class_eval %{def #{sym} @#{sym} end}
end
end
end

Consider how define_method can be used dynamically in Ruby
Eagle=Class.new
e=Eagle.new
class Eagle
define_method:fly do
puts "I am flying"
end
end
e.fly
Output: ''I am flying''

Rails becomes an all-powerful MVC framework, thanks to the metaprogramming features in Ruby.

''Other elaborate examples can be found in the [http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki2_1_ma#References References] section of this wiki page. A detailed discussion on Metaprogramming in Ruby was done in the CSC517 course lecture, the notes for which can be found [http://courses.ncsu.edu/csc517/common/lectures/notes/lec12-f09.pdf here]''

=== Metaprogramming in C++ ===

C++ provides for a type of metaprogramming called as [http://en.wikipedia.org/wiki/Template_metaprogramming template metaprograming]. Template Metaprogramming (TMP) is a programming technique that uses the priniciple of early binding . This means that pieces of codes called templates are replaced by actual code including compile-time constants, data structures, and complete functions. Then the compiler puts together all the code and compiles it. Hence the compiler in a sense acts as a "virtual computer" [http://www.codeproject.com/KB/cpp/crc_meta.aspx] as it replaces parts of the program with instructions, which would otherwise have been done at run time.

In TMP similar groups of lines of codes are replaced by a common template. Initially the template has to be defined with a base set of lines of code which are common in all. Then at the time of usage, templates have to be instantiated. Thus the templte definition specifies the general form of the code whereas the instantiation gives the specific lines of code formed from the template definition.

====Examples ====
'''Calculating a value at compile time''' 
The code to find summation of a number without using templates can be given as: 
int summation(int n)
{
if (n == 0 )
return 0;
return n + summation(n - 1);
}
void findsummation()
{
int a = summation(5); //a= (5+ 4 + 3 + 2 + 1 + 0) == 15
int b = summation(0); //b=0
}

Now using templates the same program can be written as:

template <int N>
//TEMPLATE DEFINITION
struct Summation
{
enum { value = N + Summation<N - 1>::value };
};
template <>
struct Summation<0>
{
enum { value = 0 };
};
void findsummation()
{
int a = Summation<5>::value; // == 15 // INSTANTIATION
int b = Summation<0>::value; // == 1 // INSTANTIATION
}

Thus with templates, the values of a and b were calculated at compile time rather than at run time. This was possible because 5 and 0 were literals, if they had been variables then their values wouldn’t have been known at compile time and hence a and b could not have been calculated at compile time.

'''Loop unrolling''' 
Further templates can be used to unroll loops, that is a loop is replaced by repeating the code within the loop a certain number of times. [http://www.codeproject.com/KB/cpp/crc_meta.aspx more on this example]

template< int i >
class LOOP{
public:
static inline void EXEC(){
cout << "A-" <::EXEC();
cout << "B-" <{
public:
static inline void EXEC(){
cout << "A-" << i;
cout << "\n";
cout << "B-" << i;
}
};

The output of LOOP< 8 >::EXEC() is shown below: 
A-8 A-7 A-6 A-5 A-4 A-3 A-2 A-1 A-0 
B-0 B-1 B-2 B-3 B-4 B-5 B-6 B-7 B-8 

At compile time the loop unrolls itself and produces the following lines of code:

cout << "A-" << 8 << " ";
cout << "A-" << 7 << " ";
...
cout << "A-" << 0;
cout << "\n";
cout << "B-" << 0;
...
cout << "B-" << 7 << " ";
cout << "B-" << 8 << " ";

=== Illustrating the differences ===
Unlike Ruby, C++ does not support a built-in metaprogramming system aside from template metaprogramming. Template programming is also known as "programming at compile time". Templates allow the compiler to determine certain variable and object types at compile time. The disadvantages of templates are : i) it is not specialized enough (C++ templates are Turing-complete [http://homepage.mac.com/sigfpe/Computing/peano.html]. Often they can be used for collection classes but they can also be employed in metaprogramming. This can make it hard to figure out how templates can be used to solve a specific problem), ii) poor error messages (when errors occur at compile time due to incorrectness of templates, the error messages can be cryptic)

== Conclusion ==
Metaprogramming is thus an essential and useful programming feature that allows elimination of duplicated code and enables clean execution with lesser lines of code. The style of metaprogramming differs when it comes to different languages. Ruby and Lisp have more specialized metaprogramming constructs as compared to Java or C++. Metaprogramming is apparently is a higher-level concept and probably used often by expert programmers, nevertheless through metaprogramming the overall code or program becomes very easy to interpret. Its a trade-off that should be balanced by software programmers.

== Appendix ==
* Metalanguage: The language in which the metaprogram is written
* Object language: The language of the programs that are manipulated
* Reflection or Reflexivity: The ability of a programming language to be its own metalanguage

== References/External Links ==
# [http://en.wikipedia.org/wiki/Metaprogramming Wikipedia article on metaprogramming]
# [http://c2.com/cgi/wiki?MetaProgramming Metaprogramming]
# [http://www.codeproject.com/KB/cpp/crc_meta.aspx Template programming in C++]
# [http://homepage.mac.com/sigfpe/Computing/peano.html Turing completeness in C++]
# [http://www.vanderburg.org/Speaking/Stuff/oscon05.pdf presentation about Meta programming in Ruby made at the 2005 O’Reilly Open Source Convention by Glenn Vanderburg]
# [http://theplana.wordpress.com/2007/03/12/how-to-define-a-attribute-using-metaprogramming/ Defining attributes with Metaprogramming]
# More examples on Ruby metaprogramming
## [http://ozone.wordpress.com/2006/03/02/binary-search-tree-sauce-ruby-part-1/ Link 1]
## [http://www.ruby-doc.org/core/classes/Object.src/M000366.html Link 2]
## [http://expressica.com/category/metaprogramming/ Link 3]
# [http://ozone.wordpress.com/2006/02/22/rubybeans-a-short-example-of-ruby-metaprogramming/#comment-1286 Rubybeans and Metaprogramming]
# [http://reference.jumpingmonkey.org/programming_languages/ruby/ruby-metaprogramming.html Metaprogramming in Ruby]

CSC/ECE 517 Fall 2009/wiki2 1 ma

2009-10-08T21:53:33Z

Mjampal: /* Examples */

= Metaprogramming =
== What is Metaprogramming? ==
'''Meta-''' (from Greek: μετά = "after", "beyond", "with", "adjacent", "self"), is a prefix used in English to indicate a concept which is an abstraction from another concept, used to complete or add to the latter.

''Metaprogramming is the writing of computer programs that write or manipulate other programs (or themselves) as their data, or that do part of the work at compile time that would otherwise be done at runtime. In many cases, this allows programmers to get more done in the same amount of time as they would take to write all the code manually, or it gives programs greater flexibility to efficiently handle new situations without recompilation.'' Source: [http://en.wikipedia.org/wiki/Metaprogramming]

Metaprogramming is divided into runtime metaprogramming, also known as reflection, and compile time metaprogramming. Reflection is more interesting since it allows interaction and modification of objects, components and structures that do not exist at compile time.

== Examples of Metaprograms ==

*the compiler or interpreter of your favourite language
*Lex and Yacc
*CORBA's IDL compiler
*a Quine (a program that, when executed, prints a copy of its own source code - see QuineProgram for examples)
*Programs to generate EJB code and XML from database metadata
*Macros are nothing but special cases of metaprograms, as they are replaced by the actual code during macro expansion.

Source: [http://c2.com/cgi/wiki?MetaProgramming]

== Metaprogramming style in various languages ==

Metaprogramming seems to have origniated in Lisp. John Foderaro mentions Lisp as a programmable programming language. Lisp facilitates reflection through the use of an interpreter implemented in the same language. Unlike Smalltalk and Lisp, Java and C++ do not feature extensive built-in reflection facilities.

=== Metaprogramming in Ruby ===
Ruby is a dynamically-typed, interpreted, object oriented language. One of the unique aspects of Ruby is its extensive reflexive metaprogramming facilities.

==== What makes Ruby good for metaprogramming ====
*Ruby is Dynamic and reflective
*Everything is open to change
*Blocks allow writing new control structures
*Most declarations are executable statements
*An easy syntax

==== Classification of metaprogramming features in Ruby ====
* The dynamic nature of Ruby supports creating classes and methods at runtime
* Methods can be defined directly on Singleton classes: class_eval can be used to define methods on singleton classes. This will then modify the behaviour of the sub classes(if any) and not the base class.
* Blocks and proc objects: Materializing a Proc and saving this in variables and sending it around is a good way to use metaprogramming to do interesting things. Lambda function is used to define proc objects
* The different evals: There are 4 different evals in Ruby
** eval: This call can take a string or binding to evaluate but not a block
** class_eval: It is just a alias for module_eval
** instance_eval: It will evaluate the string or the block in the context of the receiver. Thus it sets self to be the receiver.
** module_eval: It will evaluate the string or the block in the context of the module it is called on. Thus it is used to define new methods on singleton classes. This is the most commonly used eval call.

The difference between the above 4 evals can be understood with examples [http://www.elctech.com/snippets/the-difference-between-eval-class_eval-module_eval-and-instance_eval here]. Another useful external link on evals can be found [http://4loc.wordpress.com/2009/05/29/eval-module_eval-and-instance_eval/ here]

==== Examples ====
We begin by showing how methods can be defined dynamically in Ruby. Consider we need a method that duplicates strings eg. "foo".duplicate -> "foofoo". And a deduplicate method for removing duplication eg. "foofoo".deduplicate -> "foo". We can define such methods dynamically in Ruby. This ''dynamic'' feature in Ruby forms the simplest kind of metapgrogramming.

class String
def duplicate
self * 2
end
def deduplicate
self[0, self.length/2]
end
end

For instance attr_reader, attr_writer, attr_accessor are inbuilt keywords that declare the object properties. These are actually not just syntax, but methods defined in Module. ''These methods are written in C''. In other words, the ''object language'' here is Ruby but the ''metalanguage'' is C - Refer [http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki2_1_ma#Appendix Appendix]. Representing the functionality for the attr_reader method as a metaprogram in Ruby.

class Module
def attr_reader (*syms)
sys.each do |sym|
class_eval %{def #{sym} @#{sym} end}
end
end
end

Consider how define_method can be used dynamically in Ruby
Eagle=Class.new
e=Eagle.new
class Eagle
define_method:fly do
puts "I am flying"
end
end
e.fly
Output: ''I am flying''

Rails becomes an all-powerful MVC framework, thanks to the metaprogramming features in Ruby.

''Other elaborate examples can be found in the [http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki2_1_ma#References References] section of this wiki page. A detailed discussion on Metaprogramming in Ruby was done in the CSC517 course lecture, the notes for which can be found [http://courses.ncsu.edu/csc517/common/lectures/notes/lec12-f09.pdf here]''

=== Metaprogramming in C++ ===

C++ provides for a type of metaprogramming called as [http://en.wikipedia.org/wiki/Template_metaprogramming template metaprograming]. Template Metaprogramming (TMP) is a programming technique that uses the priniciple of early binding . This means that pieces of codes called templates are replaced by actual code including compile-time constants, data structures, and complete functions. Then the compiler puts together all the code and compiles it. Hence the compiler in a sense acts as a "virtual computer" [http://www.codeproject.com/KB/cpp/crc_meta.aspx] as it replaces parts of the program with instructions, which would otherwise have been done at run time.

In TMP similar groups of lines of codes are replaced by a common template. Initially the template has to be defined with a base set of lines of code which are common in all. Then at the time of usage, templates have to be instantiated. Thus the templte definition specifies the general form of the code whereas the instantiation gives the specific lines of code formed from the template definition.

====Examples ====
'''Calculating a value at compile time''' 
The code to find summation of a number without using templates can be given as: 
int summation(int n)
{
if (n == 0 )
return 0;
return n + summation(n - 1);
}
void findsummation()
{
int a = summation(5); //a= (5+ 4 + 3 + 2 + 1 + 0) == 15
int b = summation(0); //b=0
}

Now using templates the same program can be written as:

template <int N>
//TEMPLATE DEFINITION
struct Summation
{
enum { value = N + Summation<N - 1>::value };
};
template <>
struct Summation<0>
{
enum { value = 0 };
};
void findsummation()
{
int a = Summation<5>::value; // == 15 // INSTANTIATION
int b = Summation<0>::value; // == 1 // INSTANTIATION
}

Thus with templates, the values of a and b were calculated at compile time rather than at run time. This was possible because 5 and 0 were literals, if they had been variables then their values wouldn’t have been known at compile time and hence a and b could not have been calculated at compile time.

'''Loop unrolling''' 
Further templates can be used to unroll loops, that is a loop is replaced by repeating the code within the loop a certain number of times

template< int i >
class LOOP{
public:
static inline void EXEC(){
cout << "A-" <::EXEC();
cout << "B-" <{
public:
static inline void EXEC(){
cout << "A-" << i;
cout << "\n";
cout << "B-" << i;
}
};

The output of LOOP< 8 >::EXEC() is shown below: 
A-8 A-7 A-6 A-5 A-4 A-3 A-2 A-1 A-0 
B-0 B-1 B-2 B-3 B-4 B-5 B-6 B-7 B-8 

At compile time the loop unrolls itself and produces the following lines of code:

cout << "A-" << 8 << " ";
cout << "A-" << 7 << " ";
...
cout << "A-" << 0;
cout << "\n";
cout << "B-" << 0;
...
cout << "B-" << 7 << " ";
cout << "B-" << 8 << " ";

=== Illustrating the differences ===
Unlike Ruby, C++ does not support a built-in metaprogramming system aside from template metaprogramming. Template programming is also known as "programming at compile time". Templates allow the compiler to determine certain variable and object types at compile time. The disadvantages of templates are : i) it is not specialized enough (C++ templates are Turing-complete [http://homepage.mac.com/sigfpe/Computing/peano.html]. Often they can be used for collection classes but they can also be employed in metaprogramming. This can make it hard to figure out how templates can be used to solve a specific problem), ii) poor error messages (when errors occur at compile time due to incorrectness of templates, the error messages can be cryptic)

== Conclusion ==
Metaprogramming is thus an essential and useful programming feature that allows elimination of duplicated code and enables clean execution with lesser lines of code. The style of metaprogramming differs when it comes to different languages. Ruby and Lisp have more specialized metaprogramming constructs as compared to Java or C++. Metaprogramming is apparently is a higher-level concept and probably used often by expert programmers, nevertheless through metaprogramming the overall code or program becomes very easy to interpret. Its a trade-off that should be balanced by software programmers.

== Appendix ==
* Metalanguage: The language in which the metaprogram is written
* Object language: The language of the programs that are manipulated
* Reflection or Reflexivity: The ability of a programming language to be its own metalanguage

== References/External Links ==
# [http://en.wikipedia.org/wiki/Metaprogramming Wikipedia article on metaprogramming]
# [http://c2.com/cgi/wiki?MetaProgramming Metaprogramming]
# [http://www.codeproject.com/KB/cpp/crc_meta.aspx Template programming in C++]
# [http://homepage.mac.com/sigfpe/Computing/peano.html Turing completeness in C++]
# [http://www.vanderburg.org/Speaking/Stuff/oscon05.pdf presentation about Meta programming in Ruby made at the 2005 O’Reilly Open Source Convention by Glenn Vanderburg]
# [http://theplana.wordpress.com/2007/03/12/how-to-define-a-attribute-using-metaprogramming/ Defining attributes with Metaprogramming]
# More examples on Ruby metaprogramming
## [http://ozone.wordpress.com/2006/03/02/binary-search-tree-sauce-ruby-part-1/ Link 1]
## [http://www.ruby-doc.org/core/classes/Object.src/M000366.html Link 2]
## [http://expressica.com/category/metaprogramming/ Link 3]
# [http://ozone.wordpress.com/2006/02/22/rubybeans-a-short-example-of-ruby-metaprogramming/#comment-1286 Rubybeans and Metaprogramming]
# [http://reference.jumpingmonkey.org/programming_languages/ruby/ruby-metaprogramming.html Metaprogramming in Ruby]

CSC/ECE 517 Fall 2009/wiki2 1 ma

2009-10-08T21:51:43Z

Mjampal: /* Examples */

= Metaprogramming =
== What is Metaprogramming? ==
'''Meta-''' (from Greek: μετά = "after", "beyond", "with", "adjacent", "self"), is a prefix used in English to indicate a concept which is an abstraction from another concept, used to complete or add to the latter.

''Metaprogramming is the writing of computer programs that write or manipulate other programs (or themselves) as their data, or that do part of the work at compile time that would otherwise be done at runtime. In many cases, this allows programmers to get more done in the same amount of time as they would take to write all the code manually, or it gives programs greater flexibility to efficiently handle new situations without recompilation.'' Source: [http://en.wikipedia.org/wiki/Metaprogramming]

Metaprogramming is divided into runtime metaprogramming, also known as reflection, and compile time metaprogramming. Reflection is more interesting since it allows interaction and modification of objects, components and structures that do not exist at compile time.

== Examples of Metaprograms ==

*the compiler or interpreter of your favourite language
*Lex and Yacc
*CORBA's IDL compiler
*a Quine (a program that, when executed, prints a copy of its own source code - see QuineProgram for examples)
*Programs to generate EJB code and XML from database metadata
*Macros are nothing but special cases of metaprograms, as they are replaced by the actual code during macro expansion.

Source: [http://c2.com/cgi/wiki?MetaProgramming]

== Metaprogramming style in various languages ==

Metaprogramming seems to have origniated in Lisp. John Foderaro mentions Lisp as a programmable programming language. Lisp facilitates reflection through the use of an interpreter implemented in the same language. Unlike Smalltalk and Lisp, Java and C++ do not feature extensive built-in reflection facilities.

=== Metaprogramming in Ruby ===
Ruby is a dynamically-typed, interpreted, object oriented language. One of the unique aspects of Ruby is its extensive reflexive metaprogramming facilities.

==== What makes Ruby good for metaprogramming ====
*Ruby is Dynamic and reflective
*Everything is open to change
*Blocks allow writing new control structures
*Most declarations are executable statements
*An easy syntax

==== Classification of metaprogramming features in Ruby ====
* The dynamic nature of Ruby supports creating classes and methods at runtime
* Methods can be defined directly on Singleton classes: class_eval can be used to define methods on singleton classes. This will then modify the behaviour of the sub classes(if any) and not the base class.
* Blocks and proc objects: Materializing a Proc and saving this in variables and sending it around is a good way to use metaprogramming to do interesting things. Lambda function is used to define proc objects
* The different evals: There are 4 different evals in Ruby
** eval: This call can take a string or binding to evaluate but not a block
** class_eval: It is just a alias for module_eval
** instance_eval: It will evaluate the string or the block in the context of the receiver. Thus it sets self to be the receiver.
** module_eval: It will evaluate the string or the block in the context of the module it is called on. Thus it is used to define new methods on singleton classes. This is the most commonly used eval call.

The difference between the above 4 evals can be understood with examples [http://www.elctech.com/snippets/the-difference-between-eval-class_eval-module_eval-and-instance_eval here]. Another useful external link on evals can be found [http://4loc.wordpress.com/2009/05/29/eval-module_eval-and-instance_eval/ here]

==== Examples ====
We begin by showing how methods can be defined dynamically in Ruby. Consider we need a method that duplicates strings eg. "foo".duplicate -> "foofoo". And a deduplicate method for removing duplication eg. "foofoo".deduplicate -> "foo". We can define such methods dynamically in Ruby. This ''dynamic'' feature in Ruby forms the simplest kind of metapgrogramming.

class String
def duplicate
self * 2
end
def deduplicate
self[0, self.length/2]
end
end

For instance attr_reader, attr_writer, attr_accessor are inbuilt keywords that declare the object properties. These are actually not just syntax, but methods defined in Module. ''These methods are written in C''. In other words, the ''object language'' here is Ruby but the ''metalanguage'' is C - Refer [http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki2_1_ma#Appendix Appendix]. Representing the functionality for the attr_reader method as a metaprogram in Ruby.

class Module
def attr_reader (*syms)
sys.each do |sym|
class_eval %{def #{sym} @#{sym} end}
end
end
end

Consider how define_method can be used dynamically in Ruby
Eagle=Class.new
e=Eagle.new
class Eagle
define_method:fly do
puts "I am flying"
end
end
e.fly
Output: ''I am flying''

Rails becomes an all-powerful MVC framework, thanks to the metaprogramming features in Ruby.

''Other elaborate examples can be found in the [http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki2_1_ma#References References] section of this wiki page. A detailed discussion on Metaprogramming in Ruby was done in the CSC517 course lecture, the notes for which can be found [http://courses.ncsu.edu/csc517/common/lectures/notes/lec12-f09.pdf here]''

=== Metaprogramming in C++ ===

C++ provides for a type of metaprogramming called as [http://en.wikipedia.org/wiki/Template_metaprogramming template metaprograming]. Template Metaprogramming (TMP) is a programming technique that uses the priniciple of early binding . This means that pieces of codes called templates are replaced by actual code including compile-time constants, data structures, and complete functions. Then the compiler puts together all the code and compiles it. Hence the compiler in a sense acts as a "virtual computer" [http://www.codeproject.com/KB/cpp/crc_meta.aspx] as it replaces parts of the program with instructions, which would otherwise have been done at run time.

In TMP similar groups of lines of codes are replaced by a common template. Initially the template has to be defined with a base set of lines of code which are common in all. Then at the time of usage, templates have to be instantiated. Thus the templte definition specifies the general form of the code whereas the instantiation gives the specific lines of code formed from the template definition.

====Examples ====
'''Calculating a value at compile time'''
The code to find summation of a number without using templates can be given as:
int summation(int n)
{
if (n == 0 )
return 0;
return n + summation(n - 1);
}
void findsummation()
{
int a = summation(5); //a= (5+ 4 + 3 + 2 + 1 + 0) == 15
int b = summation(0); //b=0
}

Now using templates the same program can be written as:

template <int N>
//TEMPLATE DEFINITION
struct Summation
{
enum { value = N + Summation<N - 1>::value };
};
template <>
struct Summation<0>
{
enum { value = 0 };
};
void findsummation()
{
int a = Summation<5>::value; // == 15 // INSTANTIATION
int b = Summation<0>::value; // == 1 // INSTANTIATION
}

Thus with templates, the values of a and b were calculated at compile time rather than at run time. This was possible because 5 and 0 were literals, if they had been variables then their values wouldn’t have been known at compile time and hence a and b could not have been calculated at compile time.

'''Loop unrolling'''
Further templates can be used to unroll loops, that is a loop is replaced by repeating the code within the loop a certain number of times

template< int i >
class LOOP{
public:
static inline void EXEC(){
cout << "A-" <::EXEC();
cout << "B-" <{
public:
static inline void EXEC(){
cout << "A-" << i;
cout << "\n";
cout << "B-" << i;
}
};

The output of LOOP< 8 >::EXEC() is shown below:
A-8 A-7 A-6 A-5 A-4 A-3 A-2 A-1 A-0
B-0 B-1 B-2 B-3 B-4 B-5 B-6 B-7 B-8

At compile time the loop unrolls itself and produces the following lines of code:

cout << "A-" << 8 << " ";
cout << "A-" << 7 << " ";
...
cout << "A-" << 0;
cout << "\n";
cout << "B-" << 0;
...
cout << "B-" << 7 << " ";
cout << "B-" << 8 << " ";

=== Illustrating the differences ===
Unlike Ruby, C++ does not support a built-in metaprogramming system aside from template metaprogramming. Template programming is also known as "programming at compile time". Templates allow the compiler to determine certain variable and object types at compile time. The disadvantages of templates are : i) it is not specialized enough (C++ templates are Turing-complete [http://homepage.mac.com/sigfpe/Computing/peano.html]. Often they can be used for collection classes but they can also be employed in metaprogramming. This can make it hard to figure out how templates can be used to solve a specific problem), ii) poor error messages (when errors occur at compile time due to incorrectness of templates, the error messages can be cryptic)

== Conclusion ==
Metaprogramming is thus an essential and useful programming feature that allows elimination of duplicated code and enables clean execution with lesser lines of code. The style of metaprogramming differs when it comes to different languages. Ruby and Lisp have more specialized metaprogramming constructs as compared to Java or C++. Metaprogramming is apparently is a higher-level concept and probably used often by expert programmers, nevertheless through metaprogramming the overall code or program becomes very easy to interpret. Its a trade-off that should be balanced by software programmers.

== Appendix ==
* Metalanguage: The language in which the metaprogram is written
* Object language: The language of the programs that are manipulated
* Reflection or Reflexivity: The ability of a programming language to be its own metalanguage

== References/External Links ==
# [http://en.wikipedia.org/wiki/Metaprogramming Wikipedia article on metaprogramming]
# [http://c2.com/cgi/wiki?MetaProgramming Metaprogramming]
# [http://www.codeproject.com/KB/cpp/crc_meta.aspx Template programming in C++]
# [http://homepage.mac.com/sigfpe/Computing/peano.html Turing completeness in C++]
# [http://www.vanderburg.org/Speaking/Stuff/oscon05.pdf presentation about Meta programming in Ruby made at the 2005 O’Reilly Open Source Convention by Glenn Vanderburg]
# [http://theplana.wordpress.com/2007/03/12/how-to-define-a-attribute-using-metaprogramming/ Defining attributes with Metaprogramming]
# More examples on Ruby metaprogramming
## [http://ozone.wordpress.com/2006/03/02/binary-search-tree-sauce-ruby-part-1/ Link 1]
## [http://www.ruby-doc.org/core/classes/Object.src/M000366.html Link 2]
## [http://expressica.com/category/metaprogramming/ Link 3]
# [http://ozone.wordpress.com/2006/02/22/rubybeans-a-short-example-of-ruby-metaprogramming/#comment-1286 Rubybeans and Metaprogramming]
# [http://reference.jumpingmonkey.org/programming_languages/ruby/ruby-metaprogramming.html Metaprogramming in Ruby]

CSC/ECE 517 Fall 2009/wiki2 1 ma

2009-10-08T17:24:41Z

Mjampal: /* Metaprogramming in C++ */

Metaprogramming is the writing of a program that writes other programs. Metaprogramming is not limited to o-o languages, but it seems that about half of the languages that support metaprogramming are object oriented. Consider how metaprogramming is done in the various languages, and give an example of writing a particular metaprogram in at least two of these languages to illustrate the differences. Since the Wikipedia article on metaprogramming is not very detailed, if you do a good job, you could submit this article to Wikipedia.

== What is Metaprogramming? ==
'''Meta-''' (from Greek: μετά = "after", "beyond", "with", "adjacent", "self"), is a prefix used in English to indicate a concept which is an abstraction from another concept, used to complete or add to the latter. Source: Wikipedia

''Metaprogramming is the writing of computer programs that write or manipulate other programs (or themselves) as their data, or that do part of the work at compile time that would otherwise be done at runtime. In many cases, this allows programmers to get more done in the same amount of time as they would take to write all the code manually, or it gives programs greater flexibility to efficiently handle new situations without recompilation."

Metaprogramming is divided into runtime metaprogramming, also known as reflection, and compile time metaprogramming. Reflection is more interesting since it allows interaction and modification of objects, components and structures that do not exist at compile time.

== Examples of Metaprograms ==

*the compiler or interpreter of your favourite language
*Lex and Yacc
*CORBA's IDL compiler
*a Quine (a program that, when executed, prints a copy of its own source code - see QuineProgram for examples)
*Programs to generate EJB code and XML from database metadata
*Macros are nothing but special cases of metaprograms, as they are replaced by the actual code during macro expansion.

== Metaprogramming style in various languages ==

Metaprogramming seems to have origniated in Lisp. John Foderaro mentions Lisp as a programmable programming language. Lisp facilitates reflection through the use of an interpreter implemented in the same language. Unlike Smalltalk and Lisp, Java and C++ do not feature extensive built-in reflection facilities.

=== Metaprogramming in Ruby ===
Ruby is a dynamically-typed, interpreted, object oriented language. One of the unique aspects of Ruby is its extensive reflexive metaprogramming facilities.

What makes Ruby good for metaprogramming
*Ruby is Dynamic and reflective
*Everything is open to change
*Blocks allow writing new control structures
*Most declarations are executable statements
*Only slightly less malleable than Lisp (no macros)
*A fantastic syntax

For instance attr_reader, attr_writer, attr_accessor are inbuilt keywords that declare the object properties. These are actually not just syntax, but methods defined in Module. These methods are written in C. In other words, the ''object language'' here is Ruby but the ''metalanguage'' is C - Refer Appendix.

Representing the functionality for the attr_reader method as a metaprogram in Ruby.

class Module
def attr_reader (*syms)
sys.each do |sym|
class_eval %{def #{sym} @#{sym} end}
end
end
end

=== Metaprogramming in C++ ===

C++ provides for a type of metaprogramming called as [http://en.wikipedia.org/wiki/Template_metaprogramming template metaprograming]. Template Metaprogramming (TMP) is a programming technique that uses the priniciple of early binding . This means that pieces of codes called templates are replaced by actual code including compile-time constants, data structures, and complete functions. Then the compiler puts together all the code and compiles it. Hence the compiler in a sense acts as a "virtual computer" [http://www.codeproject.com/KB/cpp/crc_meta.aspx] as it replaces parts of the program with instructions, which would otherwise have been done at run time.

In TMP similar groups of lines of codes are replaced by a common template. Initially the template has to be defined with a base set of lines of code which are common in all. Then at the time of usage, templates have to be instantiated. Thus the templte definition specifies the general form of the code whereas the instantiation gives the specific lines of code formed from the template definition.

====Examples ====
The code to find summation of a number without using templates can be given as:

int summation(int n)
{
if (n == 0 )
return 0;
return n + summation(n - 1);
}

void findsummation()
{
int a = summation(5); //a= (5+ 4 + 3 + 2 + 1 + 0) == 15
int b = summation(0); //b=0
}

Now using templates the same program can be written as:

template <int N>
//TEMPLATE DEFINITION
struct Summation
{
enum { value = N + Summation<N - 1>::value };
};
template <>
struct Summation<0>
{
enum { value = 0 };
};
void findsummation()
{
int a = Summation<5>::value; // == 15 // INSTANTIATION
int b = Summation<0>::value; // == 1 // INSTANTIATION
}

Thus with templates, the values of a and b were calculated at compile time rather than at run time. This was possible because 5 and 0 were literals, if they had been variables then their values wouldn’t have been known at compile time and hence a and b could not have been calculated at compile time.

Loop unrolling
Further templates can be used to unroll loops , that is a loop is replaced by repeating the code within the loop a certain number of times
Collapse code snippet
template< int i >
class LOOP{
public:
static inline void EXEC(){
cout << "A-" <::EXEC();
cout << "B-" <{
public:
static inline void EXEC(){
cout << "A-" << i;
cout << "\n";
cout << "B-" << i;
}
};
The output of LOOP< 8 >::EXEC() is shown below:
A-8 A-7 A-6 A-5 A-4 A-3 A-2 A-1 A-0
B-0 B-1 B-2 B-3 B-4 B-5 B-6 B-7 B-8
At compile time the loop unrolls itself and produces the following lines of code:
Collapse
cout << "A-" << 8 << " ";
cout << "A-" << 7 << " ";
...
cout << "A-" << 0;
cout << "\n";
cout << "B-" << 0;
...
cout << "B-" << 7 << " ";
cout << "B-" << 8 << " ";

=== Illustrating the differences ===
Unlike Ruby, C++ does not support a built-in metaprogramming system aside from template metaprogramming. Template programming is also known as "programming at compile time". Templates allow the compiler to determine certain variable and object types at compile time. The disadvantages of templates are : i) it is not specialized enough (C++ templates are Turing-complete. Often they can be used for collection classes but they can also be employed in metaprogramming. This can make it hard to figure out how templates can be used to solve a specific problem), ii) poor error messages (when errors occur at compile time due to incorrectness of templates, the error messages can be cryptic)

== Conclusion ==
Metaprogramming is thus an essential and useful programming feature that allows elimination of duplicated code and enables clean execution with lesser lines of code. The style of metaprogramming differs when it comes to different languages. Ruby and Lisp have more specialized metaprogramming constructs as compared to Java or C++. Metaprogramming is apparently is a higher-level concept and probably used often by expert programmers, nevertheless through metaprogramming the overall code or program becomes very easy to interpret. Its a trade-off that should be balanced by software programmers.

== Appendix ==
* Metalanguage: The language in which the metaprogram is written
* Object language: The language of the programs that are manipulated
* Reflection or Reflexivity: The ability of a programming language to be its own metalanguage

== References ==

CSC/ECE 517 Fall 2009/wiki2 1 ma

2009-10-08T17:09:50Z

Mjampal: /* Examples */

Metaprogramming is the writing of a program that writes other programs. Metaprogramming is not limited to o-o languages, but it seems that about half of the languages that support metaprogramming are object oriented. Consider how metaprogramming is done in the various languages, and give an example of writing a particular metaprogram in at least two of these languages to illustrate the differences. Since the Wikipedia article on metaprogramming is not very detailed, if you do a good job, you could submit this article to Wikipedia.

== What is Metaprogramming? ==
'''Meta-''' (from Greek: μετά = "after", "beyond", "with", "adjacent", "self"), is a prefix used in English to indicate a concept which is an abstraction from another concept, used to complete or add to the latter. Source: Wikipedia

''Metaprogramming is the writing of computer programs that write or manipulate other programs (or themselves) as their data, or that do part of the work at compile time that would otherwise be done at runtime. In many cases, this allows programmers to get more done in the same amount of time as they would take to write all the code manually, or it gives programs greater flexibility to efficiently handle new situations without recompilation."

Metaprogramming is divided into runtime metaprogramming, also known as reflection, and compile time metaprogramming. Reflection is more interesting since it allows interaction and modification of objects, components and structures that do not exist at compile time.

== Examples of Metaprograms ==

*the compiler or interpreter of your favourite language
*Lex and Yacc
*CORBA's IDL compiler
*a Quine (a program that, when executed, prints a copy of its own source code - see QuineProgram for examples)
*Programs to generate EJB code and XML from database metadata
*Macros are nothing but special cases of metaprograms, as they are replaced by the actual code during macro expansion.

== Metaprogramming style in various languages ==

Metaprogramming seems to have origniated in Lisp. John Foderaro mentions Lisp as a programmable programming language. Lisp facilitates reflection through the use of an interpreter implemented in the same language. Unlike Smalltalk and Lisp, Java and C++ do not feature extensive built-in reflection facilities.

=== Metaprogramming in Ruby ===
Ruby is a dynamically-typed, interpreted, object oriented language. One of the unique aspects of Ruby is its extensive reflexive metaprogramming facilities.

What makes Ruby good for metaprogramming
*Ruby is Dynamic and reflective
*Everything is open to change
*Blocks allow writing new control structures
*Most declarations are executable statements
*Only slightly less malleable than Lisp (no macros)
*A fantastic syntax

For instance attr_reader, attr_writer, attr_accessor are inbuilt keywords that declare the object properties. These are actually not just syntax, but methods defined in Module. These methods are written in C. In other words, the ''object language'' here is Ruby but the ''metalanguage'' is C - Refer Appendix.

Representing the functionality for the attr_reader method as a metaprogram in Ruby.

class Module
def attr_reader (*syms)
sys.each do |sym|
class_eval %{def #{sym} @#{sym} end}
end
end
end

=== Metaprogramming in C++ ===

C++ provides for a type of metaprogramming called as [http://en.wikipedia.org/wiki/Template_metaprogramming template metaprograming]. Template Metaprogramming (TMP) is a programming technique that uses the priniciple of early binding . This means that pieces of codes called templates are replaced by actual code including compile-time constants, data structures, and complete functions. Then the compiler puts together all the code and compiles it. Hence the compiler in a sense acts as a "virtual computer" [http://www.codeproject.com/KB/cpp/crc_meta.aspx] as it replaces parts of the program with instructions, which would otherwise have been done at run time.

In TMP similar groups of lines of codes are replaced by a common template. Initially the template has to be defined with a base set of lines of code which are common in all. Then at the time of usage, templates have to be instantiated. Thus the templte definition specifies the general form of the code whereas the instantiation gives the specific lines of code formed from the template definition.

====Examples ====
The code to find summation of a number without using templates can be given as:

int summation(int n)
{
if (n == 0 )
return 0;
return n + summation(n - 1);
}

void findsummation()
{
int a = summation(5); //a= (5+ 4 + 3 + 2 + 1 + 0) == 15
int b = summation(0); //b=0
}

Now using templates the same program can be written as:

template <int N>
//TEMPLATE DEFINITION
struct Summation
{
enum { value = N + Summation<N - 1>::value };
};
template <>
struct Summation<0>
{
enum { value = 0 };
};
void findsummation()
{
int a = Summation<5>::value; // == 15 // INSTANTIATION
int b = Summation<0>::value; // == 1 // INSTANTIATION
}

Thus with templates, the values of a and b were calculated at compile time rather than at run time. This was possible because 5 and 0 were literals, if they had been variables then their values wouldn’t have been known at compile time and hence a and b could not have been calculated at compile time.

=== Illustrating the differences ===
Unlike Ruby, C++ does not support a built-in metaprogramming system aside from template metaprogramming. Template programming is also known as "programming at compile time". Templates allow the compiler to determine certain variable and object types at compile time. The disadvantages of templates are : i) it is not specialized enough (C++ templates are Turing-complete. Often they can be used for collection classes but they can also be employed in metaprogramming. This can make it hard to figure out how templates can be used to solve a specific problem), ii) poor error messages (when errors occur at compile time due to incorrectness of templates, the error messages can be cryptic)

== Conclusion ==

== Appendix ==
* Metalanguage: The language in which the metaprogram is written
* Object language: The language of the programs that are manipulated
* Reflection or Reflexivity: The ability of a programming language to be its own metalanguage

== References ==

CSC/ECE 517 Fall 2009/wiki2 1 ma

2009-10-08T17:08:46Z

Mjampal: /* Examples */

Metaprogramming is the writing of a program that writes other programs. Metaprogramming is not limited to o-o languages, but it seems that about half of the languages that support metaprogramming are object oriented. Consider how metaprogramming is done in the various languages, and give an example of writing a particular metaprogram in at least two of these languages to illustrate the differences. Since the Wikipedia article on metaprogramming is not very detailed, if you do a good job, you could submit this article to Wikipedia.

== What is Metaprogramming? ==
'''Meta-''' (from Greek: μετά = "after", "beyond", "with", "adjacent", "self"), is a prefix used in English to indicate a concept which is an abstraction from another concept, used to complete or add to the latter. Source: Wikipedia

''Metaprogramming is the writing of computer programs that write or manipulate other programs (or themselves) as their data, or that do part of the work at compile time that would otherwise be done at runtime. In many cases, this allows programmers to get more done in the same amount of time as they would take to write all the code manually, or it gives programs greater flexibility to efficiently handle new situations without recompilation."

Metaprogramming is divided into runtime metaprogramming, also known as reflection, and compile time metaprogramming. Reflection is more interesting since it allows interaction and modification of objects, components and structures that do not exist at compile time.

== Examples of Metaprograms ==

*the compiler or interpreter of your favourite language
*Lex and Yacc
*CORBA's IDL compiler
*a Quine (a program that, when executed, prints a copy of its own source code - see QuineProgram for examples)
*Programs to generate EJB code and XML from database metadata
*Macros are nothing but special cases of metaprograms, as they are replaced by the actual code during macro expansion.

== Metaprogramming style in various languages ==

Metaprogramming seems to have origniated in Lisp. John Foderaro mentions Lisp as a programmable programming language. Lisp facilitates reflection through the use of an interpreter implemented in the same language. Unlike Smalltalk and Lisp, Java and C++ do not feature extensive built-in reflection facilities.

=== Metaprogramming in Ruby ===
Ruby is a dynamically-typed, interpreted, object oriented language. One of the unique aspects of Ruby is its extensive reflexive metaprogramming facilities.

What makes Ruby good for metaprogramming
*Ruby is Dynamic and reflective
*Everything is open to change
*Blocks allow writing new control structures
*Most declarations are executable statements
*Only slightly less malleable than Lisp (no macros)
*A fantastic syntax

For instance attr_reader, attr_writer, attr_accessor are inbuilt keywords that declare the object properties. These are actually not just syntax, but methods defined in Module. These methods are written in C. In other words, the ''object language'' here is Ruby but the ''metalanguage'' is C - Refer Appendix.

Representing the functionality for the attr_reader method as a metaprogram in Ruby.

class Module
def attr_reader (*syms)
sys.each do |sym|
class_eval %{def #{sym} @#{sym} end}
end
end
end

=== Metaprogramming in C++ ===

C++ provides for a type of metaprogramming called as [http://en.wikipedia.org/wiki/Template_metaprogramming template metaprograming]. Template Metaprogramming (TMP) is a programming technique that uses the priniciple of early binding . This means that pieces of codes called templates are replaced by actual code including compile-time constants, data structures, and complete functions. Then the compiler puts together all the code and compiles it. Hence the compiler in a sense acts as a "virtual computer" [http://www.codeproject.com/KB/cpp/crc_meta.aspx] as it replaces parts of the program with instructions, which would otherwise have been done at run time.

In TMP similar groups of lines of codes are replaced by a common template. Initially the template has to be defined with a base set of lines of code which are common in all. Then at the time of usage, templates have to be instantiated. Thus the templte definition specifies the general form of the code whereas the instantiation gives the specific lines of code formed from the template definition.

====Examples ====
The code to find summation of a number without using templates can be given as:

<source lang="cpp">
int summation(int n)
{
if (n == 0 )
return 0;
return n + summation(n - 1);
}

void findsummation()
{
int a = summation(5); //a= (5+ 4 + 3 + 2 + 1 + 0) == 15
int b = summation(0); //b=0
}
</source>
Now using templates the same program can be written as:
<source lang="cpp">
template <int N>
//TEMPLATE DEFINITION
struct Summation
{
enum { value = N + Summation<N - 1>::value };
};
template <>
struct Summation<0>
{
enum { value = 0 };
};
Void findsummation()
{
int a = Summation<5>::value; // == 15 // INSTANTIATION
int b = Summation<0>::value; // == 1 // INSTANTIATION
}
</source>

Thus with templates, the values of a and b were calculated at compile time rather than at run time. This was possible because 5 and 0 were literals, if they had been variables then their values wouldn’t have been known at compile time and hence a and b could not have been calculated at compile time.

=== Illustrating the differences ===
Unlike Ruby, C++ does not support a built-in metaprogramming system aside from template metaprogramming. Template programming is also known as "programming at compile time". Templates allow the compiler to determine certain variable and object types at compile time. The disadvantages of templates are : i) it is not specialized enough (C++ templates are Turing-complete. Often they can be used for collection classes but they can also be employed in metaprogramming. This can make it hard to figure out how templates can be used to solve a specific problem), ii) poor error messages (when errors occur at compile time due to incorrectness of templates, the error messages can be cryptic)

== Conclusion ==

== Appendix ==
* Metalanguage: The language in which the metaprogram is written
* Object language: The language of the programs that are manipulated
* Reflection or Reflexivity: The ability of a programming language to be its own metalanguage

== References ==

CSC/ECE 517 Fall 2009/wiki2 1 ma

2009-10-08T17:08:17Z

Mjampal: /* Metaprogramming in C++ */

Metaprogramming is the writing of a program that writes other programs. Metaprogramming is not limited to o-o languages, but it seems that about half of the languages that support metaprogramming are object oriented. Consider how metaprogramming is done in the various languages, and give an example of writing a particular metaprogram in at least two of these languages to illustrate the differences. Since the Wikipedia article on metaprogramming is not very detailed, if you do a good job, you could submit this article to Wikipedia.

== What is Metaprogramming? ==
'''Meta-''' (from Greek: μετά = "after", "beyond", "with", "adjacent", "self"), is a prefix used in English to indicate a concept which is an abstraction from another concept, used to complete or add to the latter. Source: Wikipedia

''Metaprogramming is the writing of computer programs that write or manipulate other programs (or themselves) as their data, or that do part of the work at compile time that would otherwise be done at runtime. In many cases, this allows programmers to get more done in the same amount of time as they would take to write all the code manually, or it gives programs greater flexibility to efficiently handle new situations without recompilation."

Metaprogramming is divided into runtime metaprogramming, also known as reflection, and compile time metaprogramming. Reflection is more interesting since it allows interaction and modification of objects, components and structures that do not exist at compile time.

== Examples of Metaprograms ==

*the compiler or interpreter of your favourite language
*Lex and Yacc
*CORBA's IDL compiler
*a Quine (a program that, when executed, prints a copy of its own source code - see QuineProgram for examples)
*Programs to generate EJB code and XML from database metadata
*Macros are nothing but special cases of metaprograms, as they are replaced by the actual code during macro expansion.

== Metaprogramming style in various languages ==

Metaprogramming seems to have origniated in Lisp. John Foderaro mentions Lisp as a programmable programming language. Lisp facilitates reflection through the use of an interpreter implemented in the same language. Unlike Smalltalk and Lisp, Java and C++ do not feature extensive built-in reflection facilities.

=== Metaprogramming in Ruby ===
Ruby is a dynamically-typed, interpreted, object oriented language. One of the unique aspects of Ruby is its extensive reflexive metaprogramming facilities.

What makes Ruby good for metaprogramming
*Ruby is Dynamic and reflective
*Everything is open to change
*Blocks allow writing new control structures
*Most declarations are executable statements
*Only slightly less malleable than Lisp (no macros)
*A fantastic syntax

For instance attr_reader, attr_writer, attr_accessor are inbuilt keywords that declare the object properties. These are actually not just syntax, but methods defined in Module. These methods are written in C. In other words, the ''object language'' here is Ruby but the ''metalanguage'' is C - Refer Appendix.

Representing the functionality for the attr_reader method as a metaprogram in Ruby.

class Module
def attr_reader (*syms)
sys.each do |sym|
class_eval %{def #{sym} @#{sym} end}
end
end
end

=== Metaprogramming in C++ ===

C++ provides for a type of metaprogramming called as [http://en.wikipedia.org/wiki/Template_metaprogramming template metaprograming]. Template Metaprogramming (TMP) is a programming technique that uses the priniciple of early binding . This means that pieces of codes called templates are replaced by actual code including compile-time constants, data structures, and complete functions. Then the compiler puts together all the code and compiles it. Hence the compiler in a sense acts as a "virtual computer" [http://www.codeproject.com/KB/cpp/crc_meta.aspx] as it replaces parts of the program with instructions, which would otherwise have been done at run time.

In TMP similar groups of lines of codes are replaced by a common template. Initially the template has to be defined with a base set of lines of code which are common in all. Then at the time of usage, templates have to be instantiated. Thus the templte definition specifies the general form of the code whereas the instantiation gives the specific lines of code formed from the template definition.

====Examples ====
The code to find summation of a number without using templates can be given as:
<source lang="cpp">
int summation(int n)
{
if (n == 0 )
return 0;
return n + summation(n - 1);
}

void findsummation()
{
int a = summation(5); //a= (5+ 4 + 3 + 2 + 1 + 0) == 15
int b = summation(0); //b=0
}
</source>
Now using templates the same program can be written as:
<source lang="cpp">
template <int N>
//TEMPLATE DEFINITION
struct Summation
{
enum { value = N + Summation<N - 1>::value };
};
template <>
struct Summation<0>
{
enum { value = 0 };
};
Void findsummation()
{
int a = Summation<5>::value; // == 15 // INSTANTIATION
int b = Summation<0>::value; // == 1 // INSTANTIATION
}
</source>

Thus with templates, the values of a and b were calculated at compile time rather than at run time. This was possible because 5 and 0 were literals, if they had been variables then their values wouldn’t have been known at compile time and hence a and b could not have been calculated at compile time.

=== Illustrating the differences ===
Unlike Ruby, C++ does not support a built-in metaprogramming system aside from template metaprogramming. Template programming is also known as "programming at compile time". Templates allow the compiler to determine certain variable and object types at compile time. The disadvantages of templates are : i) it is not specialized enough (C++ templates are Turing-complete. Often they can be used for collection classes but they can also be employed in metaprogramming. This can make it hard to figure out how templates can be used to solve a specific problem), ii) poor error messages (when errors occur at compile time due to incorrectness of templates, the error messages can be cryptic)

== Conclusion ==

== Appendix ==
* Metalanguage: The language in which the metaprogram is written
* Object language: The language of the programs that are manipulated
* Reflection or Reflexivity: The ability of a programming language to be its own metalanguage

== References ==

CSC/ECE 517 Fall 2009/wiki2 1 ma

2009-10-08T16:38:45Z

Mjampal: /* Metaprogramming in C++ */

CSC/ECE 517 Fall 2009/wiki2 1 ma

2009-10-08T04:27:46Z

Mjampal: /* Metaprogramming style in various languages */

CSC/ECE 517 Fall 2009/wiki2 1 ma

2009-10-08T04:26:23Z

Mjampal: /* Metaprogramming style in various languages */

CSC/ECE 517 Fall 2009/wiki2 1 ma

2009-10-08T02:59:13Z

Mjampal:

CSC/ECE 517 Fall 2009/wik2 1 ma

2009-10-08T01:41:13Z

Mjampal:

=Topic=
Metaprogramming is the writing of a program that writes other programs. Metaprogramming is not limited to o-o languages, but it seems that about half of the languages that support metaprogramming are object oriented. Consider how metaprogramming is done in the various languages, and give an example of writing a particular metaprogram in at least two of these languages to illustrate the differences. Since the Wikipedia article on metaprogramming is not very detailed, if you do a good job, you could submit this article to Wikipedia

CSC/ECE 517 Fall 2009/wiki1b 4 mv

2009-09-28T23:31:06Z

Mjampal: /* External Links */

=Introduction=
Unit Testing is given a lot of importance in Software Testing. But functional and integration testing are essential too. Hence Functional and Integration Testing is discussed here. This page provides an introduction to these testing methods; also including the good practices to write functional and integration tests. Later additional types of Software Tests are mentioned, which could be used to gain further confidence that one's code is correct.

=Functional Testing=
Functional testing is the process of testing of all the functions of a system, ensuring that the system conforms to the user requirements and specifications. It is sometimes referred to as black-box testing, as it does not require understanding of the internal structure of the implementation.

Functional testing can be done by using manual or automated methods[http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki1b_4_mv#References]. In both the methods, a series of tests have to be run marking the interaction between the user and the system, ensuring that the system performs as it was supposed to. Since Use cases mainly depict the interaction between the user and system, functional test suites are created from requirement use cases, with each scenario becoming a functional test[http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki1b_4_mv#References].

==Functional Test Plan==
"The functional test plan measures the quality of the functional components of the system[http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki1b_4_mv#References]". The test plan is written by the Author. The Author lists a number of test cases, containing the input, expected results, and pre and post-test setup. After a module is unit tested, the Tester executes the functional test cases and records the actual results. The Reviewer compares the Actual results with the expected results and reports whether each test case passed or failed the test.

==Guidelines to write good Functional Tests==
# The test plan must be written by persons who have extensive knowledge of the business requirements. It is advisable that the developers do not write the test plans. This is because developers tend to unknowingly write test cases whose functionality is based on the implementation rather than the initial functional specifications.
# The functional test plans should be created as early as possible, probably as soon as the functional specifications are ready.
# The functional test plan should be updated when there are changes in the business requirements.
# For each functionality, a list of test cases should be defined so that each aspect of the functionality is covered.
# The Author should clearly include the pre-test setup for the test cases so that the Tester can easily execute the test cases.
# Usually the same test cases are run a number of times. Hence after executing a test case, any data added to the system should be cleared so as to not affect further tests or rerunning of the same test case. Hence the Author should also give post-test setup details.
# As a module is built and unit tested, the Tester should execute the particular test cases and record the results.
# Reviewer should review the results and report any bugs to the developers.

==Examples==
Examples of pre-test setup, test cases and post-test setup are given below. The complete reference for the example can be found at [http://www.developer.com/java/ent/article.php/3623476/Functional-Test-Plans-The-Right-Way.htm Functional Test Plans]

The pre-test setup for Test Case: Create new user profile can be given as:
[UserName: "A": --> username: "A"]
[UserName: "A": --> first name: "John"]
[UserName: "A": --> last name: "Smith"]
[UserName: "A": --> access level: "read-only"]
[UserName: "A": --> password: "profile1"]

The test cases for the function:Verify that only valid users can access the system can be given as:

<table cellspacing="2" width=900 border="1" align="center" >
<tr valign="top" bgcolor="#99ffff">
<th>Test Case #</th>
<th>Required Input</th>
<th>Expected Results</th>
<th>Results</th>

<th>Pass/Fail</th></tr>

<tr valign="top"><td colspan="5">
<ul>
<li>Verify that only valid users can access the system.</li>
<li>Verify that valid users cannot access the system without entering a valid password.</li>
</ul></td></tr>

<tr valign="top"><td>1</td>
<td>Navigate to the login screen</td>
<td>Login screen with release number A is loaded.</td>

<td> </td>
<td> </td></tr>

<tr valign="top"><td>2</td>
<td>Enter user name "INVALIDUSER", password "INVALIDUSER", and click on login button</td>
<td>Error message: 
"User name is not found"</td>
<td> </td>
<td> </td></tr>

<tr valign="top"><td>3</td>
<td>Enter user name for user [UserName: "A":--> username] and password "test"</td>

<td>Error Message: 
"Password for user [UserName: "A": --> username] is invalid"</td>
<td> </td>
<td> </td></tr>

<tr valign="top"><td>4</td>
<td>Enter user name [UserName: "A": --> username] and password [UserName: "A": --> password]</td>

<td>The main page is loaded with a message: 
"Welcome [UserName: "A": --> first name] [UserName: "A": --> last name]</td>
<td> </td>
<td> </td></tr>
</table>

The post-test setup for the above scenario can be given as:
Remove [UserName: "A": --> username: "A"] from the LDAP Server.

Another Example of Test Cases can be found at [http://math-cs.gordon.edu/courses/cs211/ATMExample/InitialFunctionalTests.html Initial Functional Test Cases for an ATM system]

=Integration Testing=
Integration Testing is a process of testing the application on the whole. After going through the unit testing of the modules, these modules need to be integrated, and during this process things may go wrong, Integration process is the phase wherein these errors are captured and rectified.
It is very common for modules after having successful passed all the unit test cases to fail when they are integrated with other modules. Integration testing is an important phase and sometimes there are separate teams which handle integration testing.
 
DEFINITION:Integration testing is a systematic technique for constructing the program structure while at the same time conducting tests to uncover errors associated with interfacing. The objective is to take unit tested components
and build a program structure that has been dictated by design.[http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki1b_4_mv#References]

==Integration Test approaches==
Integration testing can be done in a variety of ways [[Image:TopDown_Approach.jpg|thumb|Top Down Approach]]
# '''Top-Down Approach.''' In this approach the modules higher up in the control hierarchy are integrated first and low-level modules are added later. The advantage of this approach is that the modules with high level logic are tested first and hence bugs in the crucial logic are caught early. Further this approach does not require drivers (dummy control modules used instead of the actual modules for the purpose of testing) to be written. Although a number of [http://en.wikipedia.org/wiki/Test_stubs stubs] have to be written and managed
# '''Bottom Up Approach.''' In this approach, the low level modules are integrated first and high level logic is tested late. While integrating the low level modules, the control modules are replaced by dummy modules called as drivers. Thus driver codes have to be written and managed while using this approach. [[Image:BottomUp_Approach.jpg|thumb|Bottom Up Approach]]
# '''Umbrella approach.''' Another approach is called the umbrella approach. It is a hybrid of the top down and the botom up approach, ie both the bottom up and top down approaches are used.In this approach we first test along the functional and control flow paths, for this we use the bottom up approach. The results thus gathered are later integrated in a top down manner. This kind of testing allows creating early prototypes of the system with has limited functionality thereby helping is the creations of the product in an incremental manner. This types of testing also minimizes the use of [http://en.wikipedia.org/wiki/Test_stubs stubs] and drivers which are needed in the top-down and bottom up approaches.

==Prerequisites before Integration Testing==
The system that is being tested, all of its modules should be rigorously tested as a component, i.e they should have gone through unit tests.
==Steps to write good Integration Test Cases==
#Create a Test Plan
#Create test cases and the sample data against which they would be tested.
#If automated tools are being used, scripts should be created.
#After the components have been integrated, start executing the test cases created in point 2.
#Log the bugs found and rectify the same.
#Retest the code.

==How To write good Integration Test Cases and do effective Integration Testing==
The main focus of integration testing is that it needs to check whether the different components are working smoothly and are interacting with each other in the proper manner. The Integration test cases specifically focus on the flow of data/information/control from one component to the other.
A few thing that needs to be kept in mind for effective integration testing are
# Ensure that the correct versions of the components are integrated together.
# Automate the integration of components so that there is lesser chance for human error.
# Log all the errors that have been found and document them with the solutions as well as the version number so that we could keep track of which build was being tested when the error was discovered.

==Examples==
Sample Integration test case Templates can be found at [http://it.toolbox.com/blogs/enterprise-solutions/deliverable-integration-test-cases-29932 Integration test cases]

Integration test plan Templates can be found at [http://geekswithblogs.net/dthakur/articles/10430.aspx Integration test plans]

=Beyond Functional and Integration Testing=
[[Image:TestPhase.jpg|thumb|Test Phases]]
Integration and Functional testing are not the only testing that are done for checking the validity of the system. Other test cases includes: 
'''Unit Testing:''' This is the first stage where the developer tests the component he/she is creating. More can be found at [http://en.wikipedia.org/wiki/Unit_testing Unit Testing] 
'''Validation Testing:''' After integration Testing, validation testing takes place wherein checks are made to ensure that the functional requirements are satisfied. 
'''Alpha and Beta Testing:'''When the product about to be released, it is first exposed to some end users who test the application. This is alpha beta testing. More can be found at [http://www.majordojo.com/uploads/AlphaBetaTesting.pdf Alpha and Beta Testing] 
'''Recovery Testing:''' In this phase the system is made to crash and is used to check to see if it recovers in the proper manner. More can be found at [http://en.wikipedia.org/wiki/Recovery_testing Recovery Testing] 
'''Security Testing:''' Systems that store and record sensitive information need to be protected from threats, in this phase the systems protection mechanisms are tested. More can be found at [http://en.wikipedia.org/wiki/Security_testing Security Testing] 
'''Stress Testing:'''The system is overloaded with data and it is checked to whether it crashes. More can be found at [http://en.wikipedia.org/wiki/Stress_testing Stress Testing] 
'''Performance Testing:''' It tests the run time performance of software within the context of the system. More can be found at [http://en.wikipedia.org/wiki/Performance_testing Performance Testing] 
'''Smoke Testing:''' smoke testing is a preliminary to further testing, which should reveal simple failures severe enough to reject a prospective software release. More can be found at [http://en.wikipedia.org/wiki/Smoke_test Smoke Test] 
'''Acceptance Testing:''' acceptance testing performed by the customer is known as user acceptance testing (UAT). This is also known as end-user testing, site (acceptance) testing, or field (acceptance) testing. More can be found at [http://en.wikipedia.org/wiki/Acceptance_testing Acceptance Testing]

=References=

# [http://www.segue.com/pdf/automated_functional_testing.pdf Automated Functional Testing]
# [http://searchsoftwarequality.techtarget.com/generic/0,295582,sid92_gci1303938,00.html# Functional Tests to ensure Software Quality]
# [http://www.developer.com/tech/article.php/3623476/Functional-Test-Plans-The-Right-Way.htm Functional Test Plans]
# Software Engineering: A Practitioner's Approach by Roger S. Pressman ISBN 0073655783

=External Links=
# [http://math-cs.gordon.edu/courses/cs211/ATMExample/InitialFunctionalTests.html Initial Functional Test Cases for an ATM system]
# [http://it.toolbox.com/blogs/enterprise-solutions/deliverable-integration-test-cases-29932 Integration test cases]
# [http://geekswithblogs.net/dthakur/articles/10430.aspx Integration test plans]
# [http://en.wikipedia.org/wiki/Unit_testing Unit Testing]
# [http://www.majordojo.com/uploads/AlphaBetaTesting.pdf Alpha Beta Testing]
# [http://en.wikipedia.org/wiki/Recovery_testing Recovery Testing]
# [http://en.wikipedia.org/wiki/Security_testing Security Testing]
# [http://en.wikipedia.org/wiki/Stress_testing Stress Testing]
# [http://en.wikipedia.org/wiki/Performance_testing Performance Testing]
# [http://en.wikipedia.org/wiki/Smoke_test Smoke Test]
# [http://en.wikipedia.org/wiki/Acceptance_testing Acceptance Testing]

CSC/ECE 517 Fall 2009/wiki1b 4 mv

2009-09-28T23:30:22Z

Mjampal: /* Examples */

=Introduction=
Unit Testing is given a lot of importance in Software Testing. But functional and integration testing are essential too. Hence Functional and Integration Testing is discussed here. This page provides an introduction to these testing methods; also including the good practices to write functional and integration tests. Later additional types of Software Tests are mentioned, which could be used to gain further confidence that one's code is correct.

=Functional Testing=
Functional testing is the process of testing of all the functions of a system, ensuring that the system conforms to the user requirements and specifications. It is sometimes referred to as black-box testing, as it does not require understanding of the internal structure of the implementation.

Functional testing can be done by using manual or automated methods[http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki1b_4_mv#References]. In both the methods, a series of tests have to be run marking the interaction between the user and the system, ensuring that the system performs as it was supposed to. Since Use cases mainly depict the interaction between the user and system, functional test suites are created from requirement use cases, with each scenario becoming a functional test[http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki1b_4_mv#References].

==Functional Test Plan==
"The functional test plan measures the quality of the functional components of the system[http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki1b_4_mv#References]". The test plan is written by the Author. The Author lists a number of test cases, containing the input, expected results, and pre and post-test setup. After a module is unit tested, the Tester executes the functional test cases and records the actual results. The Reviewer compares the Actual results with the expected results and reports whether each test case passed or failed the test.

==Guidelines to write good Functional Tests==
# The test plan must be written by persons who have extensive knowledge of the business requirements. It is advisable that the developers do not write the test plans. This is because developers tend to unknowingly write test cases whose functionality is based on the implementation rather than the initial functional specifications.
# The functional test plans should be created as early as possible, probably as soon as the functional specifications are ready.
# The functional test plan should be updated when there are changes in the business requirements.
# For each functionality, a list of test cases should be defined so that each aspect of the functionality is covered.
# The Author should clearly include the pre-test setup for the test cases so that the Tester can easily execute the test cases.
# Usually the same test cases are run a number of times. Hence after executing a test case, any data added to the system should be cleared so as to not affect further tests or rerunning of the same test case. Hence the Author should also give post-test setup details.
# As a module is built and unit tested, the Tester should execute the particular test cases and record the results.
# Reviewer should review the results and report any bugs to the developers.

==Examples==
Examples of pre-test setup, test cases and post-test setup are given below. The complete reference for the example can be found at [http://www.developer.com/java/ent/article.php/3623476/Functional-Test-Plans-The-Right-Way.htm Functional Test Plans]

The pre-test setup for Test Case: Create new user profile can be given as:
[UserName: "A": --> username: "A"]
[UserName: "A": --> first name: "John"]
[UserName: "A": --> last name: "Smith"]
[UserName: "A": --> access level: "read-only"]
[UserName: "A": --> password: "profile1"]

The test cases for the function:Verify that only valid users can access the system can be given as:

<table cellspacing="2" width=900 border="1" align="center" >
<tr valign="top" bgcolor="#99ffff">
<th>Test Case #</th>
<th>Required Input</th>
<th>Expected Results</th>
<th>Results</th>

<th>Pass/Fail</th></tr>

<tr valign="top"><td colspan="5">
<ul>
<li>Verify that only valid users can access the system.</li>
<li>Verify that valid users cannot access the system without entering a valid password.</li>
</ul></td></tr>

<tr valign="top"><td>1</td>
<td>Navigate to the login screen</td>
<td>Login screen with release number A is loaded.</td>

<td> </td>
<td> </td></tr>

<tr valign="top"><td>2</td>
<td>Enter user name "INVALIDUSER", password "INVALIDUSER", and click on login button</td>
<td>Error message: 
"User name is not found"</td>
<td> </td>
<td> </td></tr>

<tr valign="top"><td>3</td>
<td>Enter user name for user [UserName: "A":--> username] and password "test"</td>

<td>Error Message: 
"Password for user [UserName: "A": --> username] is invalid"</td>
<td> </td>
<td> </td></tr>

<tr valign="top"><td>4</td>
<td>Enter user name [UserName: "A": --> username] and password [UserName: "A": --> password]</td>

<td>The main page is loaded with a message: 
"Welcome [UserName: "A": --> first name] [UserName: "A": --> last name]</td>
<td> </td>
<td> </td></tr>
</table>

The post-test setup for the above scenario can be given as:
Remove [UserName: "A": --> username: "A"] from the LDAP Server.

Another Example of Test Cases can be found at [http://math-cs.gordon.edu/courses/cs211/ATMExample/InitialFunctionalTests.html Initial Functional Test Cases for an ATM system]

=Integration Testing=
Integration Testing is a process of testing the application on the whole. After going through the unit testing of the modules, these modules need to be integrated, and during this process things may go wrong, Integration process is the phase wherein these errors are captured and rectified.
It is very common for modules after having successful passed all the unit test cases to fail when they are integrated with other modules. Integration testing is an important phase and sometimes there are separate teams which handle integration testing.
 
DEFINITION:Integration testing is a systematic technique for constructing the program structure while at the same time conducting tests to uncover errors associated with interfacing. The objective is to take unit tested components
and build a program structure that has been dictated by design.[http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki1b_4_mv#References]

==Integration Test approaches==
Integration testing can be done in a variety of ways [[Image:TopDown_Approach.jpg|thumb|Top Down Approach]]
# '''Top-Down Approach.''' In this approach the modules higher up in the control hierarchy are integrated first and low-level modules are added later. The advantage of this approach is that the modules with high level logic are tested first and hence bugs in the crucial logic are caught early. Further this approach does not require drivers (dummy control modules used instead of the actual modules for the purpose of testing) to be written. Although a number of [http://en.wikipedia.org/wiki/Test_stubs stubs] have to be written and managed
# '''Bottom Up Approach.''' In this approach, the low level modules are integrated first and high level logic is tested late. While integrating the low level modules, the control modules are replaced by dummy modules called as drivers. Thus driver codes have to be written and managed while using this approach. [[Image:BottomUp_Approach.jpg|thumb|Bottom Up Approach]]
# '''Umbrella approach.''' Another approach is called the umbrella approach. It is a hybrid of the top down and the botom up approach, ie both the bottom up and top down approaches are used.In this approach we first test along the functional and control flow paths, for this we use the bottom up approach. The results thus gathered are later integrated in a top down manner. This kind of testing allows creating early prototypes of the system with has limited functionality thereby helping is the creations of the product in an incremental manner. This types of testing also minimizes the use of [http://en.wikipedia.org/wiki/Test_stubs stubs] and drivers which are needed in the top-down and bottom up approaches.

==Prerequisites before Integration Testing==
The system that is being tested, all of its modules should be rigorously tested as a component, i.e they should have gone through unit tests.
==Steps to write good Integration Test Cases==
#Create a Test Plan
#Create test cases and the sample data against which they would be tested.
#If automated tools are being used, scripts should be created.
#After the components have been integrated, start executing the test cases created in point 2.
#Log the bugs found and rectify the same.
#Retest the code.

==How To write good Integration Test Cases and do effective Integration Testing==
The main focus of integration testing is that it needs to check whether the different components are working smoothly and are interacting with each other in the proper manner. The Integration test cases specifically focus on the flow of data/information/control from one component to the other.
A few thing that needs to be kept in mind for effective integration testing are
# Ensure that the correct versions of the components are integrated together.
# Automate the integration of components so that there is lesser chance for human error.
# Log all the errors that have been found and document them with the solutions as well as the version number so that we could keep track of which build was being tested when the error was discovered.

==Examples==
Sample Integration test case Templates can be found at [http://it.toolbox.com/blogs/enterprise-solutions/deliverable-integration-test-cases-29932 Integration test cases]

Integration test plan Templates can be found at [http://geekswithblogs.net/dthakur/articles/10430.aspx Integration test plans]

=Beyond Functional and Integration Testing=
[[Image:TestPhase.jpg|thumb|Test Phases]]
Integration and Functional testing are not the only testing that are done for checking the validity of the system. Other test cases includes: 
'''Unit Testing:''' This is the first stage where the developer tests the component he/she is creating. More can be found at [http://en.wikipedia.org/wiki/Unit_testing Unit Testing] 
'''Validation Testing:''' After integration Testing, validation testing takes place wherein checks are made to ensure that the functional requirements are satisfied. 
'''Alpha and Beta Testing:'''When the product about to be released, it is first exposed to some end users who test the application. This is alpha beta testing. More can be found at [http://www.majordojo.com/uploads/AlphaBetaTesting.pdf Alpha and Beta Testing] 
'''Recovery Testing:''' In this phase the system is made to crash and is used to check to see if it recovers in the proper manner. More can be found at [http://en.wikipedia.org/wiki/Recovery_testing Recovery Testing] 
'''Security Testing:''' Systems that store and record sensitive information need to be protected from threats, in this phase the systems protection mechanisms are tested. More can be found at [http://en.wikipedia.org/wiki/Security_testing Security Testing] 
'''Stress Testing:'''The system is overloaded with data and it is checked to whether it crashes. More can be found at [http://en.wikipedia.org/wiki/Stress_testing Stress Testing] 
'''Performance Testing:''' It tests the run time performance of software within the context of the system. More can be found at [http://en.wikipedia.org/wiki/Performance_testing Performance Testing] 
'''Smoke Testing:''' smoke testing is a preliminary to further testing, which should reveal simple failures severe enough to reject a prospective software release. More can be found at [http://en.wikipedia.org/wiki/Smoke_test Smoke Test] 
'''Acceptance Testing:''' acceptance testing performed by the customer is known as user acceptance testing (UAT). This is also known as end-user testing, site (acceptance) testing, or field (acceptance) testing. More can be found at [http://en.wikipedia.org/wiki/Acceptance_testing Acceptance Testing]

=References=

# [http://www.segue.com/pdf/automated_functional_testing.pdf Automated Functional Testing]
# [http://searchsoftwarequality.techtarget.com/generic/0,295582,sid92_gci1303938,00.html# Functional Tests to ensure Software Quality]
# [http://www.developer.com/tech/article.php/3623476/Functional-Test-Plans-The-Right-Way.htm Functional Test Plans]
# Software Engineering: A Practitioner's Approach by Roger S. Pressman ISBN 0073655783

=External Links=
# [http://math-cs.gordon.edu/courses/cs211/ATMExample/InitialFunctionalTests.html Initial Functional Test Cases for an ATM system]
# [http://it.toolbox.com/blogs/enterprise-solutions/deliverable-integration-test-cases-29932 Integration test cases]
# [http://geekswithblogs.net/dthakur/articles/10430.aspx Integration Test Plan]
# [http://en.wikipedia.org/wiki/Unit_testing Unit Testing]
# [http://www.majordojo.com/uploads/AlphaBetaTesting.pdf Alpha Beta Testing]
# [http://en.wikipedia.org/wiki/Recovery_testing Recovery Testing]
# [http://en.wikipedia.org/wiki/Security_testing Security Testing]
# [http://en.wikipedia.org/wiki/Stress_testing Stress Testing]
# [http://en.wikipedia.org/wiki/Performance_testing Performance Testing]
# [http://en.wikipedia.org/wiki/Smoke_test Smoke Test]
# [http://en.wikipedia.org/wiki/Acceptance_testing Acceptance Testing]

CSC/ECE 517 Fall 2009/wiki1b 4 mv

2009-09-28T23:29:50Z

Mjampal: /* External Links */

=Introduction=
Unit Testing is given a lot of importance in Software Testing. But functional and integration testing are essential too. Hence Functional and Integration Testing is discussed here. This page provides an introduction to these testing methods; also including the good practices to write functional and integration tests. Later additional types of Software Tests are mentioned, which could be used to gain further confidence that one's code is correct.

=Functional Testing=
Functional testing is the process of testing of all the functions of a system, ensuring that the system conforms to the user requirements and specifications. It is sometimes referred to as black-box testing, as it does not require understanding of the internal structure of the implementation.

Functional testing can be done by using manual or automated methods[http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki1b_4_mv#References]. In both the methods, a series of tests have to be run marking the interaction between the user and the system, ensuring that the system performs as it was supposed to. Since Use cases mainly depict the interaction between the user and system, functional test suites are created from requirement use cases, with each scenario becoming a functional test[http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki1b_4_mv#References].

==Functional Test Plan==
"The functional test plan measures the quality of the functional components of the system[http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki1b_4_mv#References]". The test plan is written by the Author. The Author lists a number of test cases, containing the input, expected results, and pre and post-test setup. After a module is unit tested, the Tester executes the functional test cases and records the actual results. The Reviewer compares the Actual results with the expected results and reports whether each test case passed or failed the test.

==Guidelines to write good Functional Tests==
# The test plan must be written by persons who have extensive knowledge of the business requirements. It is advisable that the developers do not write the test plans. This is because developers tend to unknowingly write test cases whose functionality is based on the implementation rather than the initial functional specifications.
# The functional test plans should be created as early as possible, probably as soon as the functional specifications are ready.
# The functional test plan should be updated when there are changes in the business requirements.
# For each functionality, a list of test cases should be defined so that each aspect of the functionality is covered.
# The Author should clearly include the pre-test setup for the test cases so that the Tester can easily execute the test cases.
# Usually the same test cases are run a number of times. Hence after executing a test case, any data added to the system should be cleared so as to not affect further tests or rerunning of the same test case. Hence the Author should also give post-test setup details.
# As a module is built and unit tested, the Tester should execute the particular test cases and record the results.
# Reviewer should review the results and report any bugs to the developers.

==Examples==
Examples of pre-test setup, test cases and post-test setup are given below. The complete reference for the example can be found at [http://www.developer.com/java/ent/article.php/3623476/Functional-Test-Plans-The-Right-Way.htm Functional Test Plans]

The pre-test setup for Test Case: Create new user profile can be given as:
[UserName: "A": --> username: "A"]
[UserName: "A": --> first name: "John"]
[UserName: "A": --> last name: "Smith"]
[UserName: "A": --> access level: "read-only"]
[UserName: "A": --> password: "profile1"]

The test cases for the function:Verify that only valid users can access the system can be given as:

<table cellspacing="2" width=900 border="1" align="center" >
<tr valign="top" bgcolor="#99ffff">
<th>Test Case #</th>
<th>Required Input</th>
<th>Expected Results</th>
<th>Results</th>

<th>Pass/Fail</th></tr>

<tr valign="top"><td colspan="5">
<ul>
<li>Verify that only valid users can access the system.</li>
<li>Verify that valid users cannot access the system without entering a valid password.</li>
</ul></td></tr>

<tr valign="top"><td>1</td>
<td>Navigate to the login screen</td>
<td>Login screen with release number A is loaded.</td>

<td> </td>
<td> </td></tr>

<tr valign="top"><td>2</td>
<td>Enter user name "INVALIDUSER", password "INVALIDUSER", and click on login button</td>
<td>Error message: 
"User name is not found"</td>
<td> </td>
<td> </td></tr>

<tr valign="top"><td>3</td>
<td>Enter user name for user [UserName: "A":--> username] and password "test"</td>

<td>Error Message: 
"Password for user [UserName: "A": --> username] is invalid"</td>
<td> </td>
<td> </td></tr>

<tr valign="top"><td>4</td>
<td>Enter user name [UserName: "A": --> username] and password [UserName: "A": --> password]</td>

<td>The main page is loaded with a message: 
"Welcome [UserName: "A": --> first name] [UserName: "A": --> last name]</td>
<td> </td>
<td> </td></tr>
</table>

The post-test setup for the above scenario can be given as:
Remove [UserName: "A": --> username: "A"] from the LDAP Server.

Another Example of Test Cases can be found at [http://math-cs.gordon.edu/courses/cs211/ATMExample/InitialFunctionalTests.html Initial Functional Test Cases for an ATM system]

=Integration Testing=
Integration Testing is a process of testing the application on the whole. After going through the unit testing of the modules, these modules need to be integrated, and during this process things may go wrong, Integration process is the phase wherein these errors are captured and rectified.
It is very common for modules after having successful passed all the unit test cases to fail when they are integrated with other modules. Integration testing is an important phase and sometimes there are separate teams which handle integration testing.
 
DEFINITION:Integration testing is a systematic technique for constructing the program structure while at the same time conducting tests to uncover errors associated with interfacing. The objective is to take unit tested components
and build a program structure that has been dictated by design.[http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki1b_4_mv#References]

==Integration Test approaches==
Integration testing can be done in a variety of ways [[Image:TopDown_Approach.jpg|thumb|Top Down Approach]]
# '''Top-Down Approach.''' In this approach the modules higher up in the control hierarchy are integrated first and low-level modules are added later. The advantage of this approach is that the modules with high level logic are tested first and hence bugs in the crucial logic are caught early. Further this approach does not require drivers (dummy control modules used instead of the actual modules for the purpose of testing) to be written. Although a number of [http://en.wikipedia.org/wiki/Test_stubs stubs] have to be written and managed
# '''Bottom Up Approach.''' In this approach, the low level modules are integrated first and high level logic is tested late. While integrating the low level modules, the control modules are replaced by dummy modules called as drivers. Thus driver codes have to be written and managed while using this approach. [[Image:BottomUp_Approach.jpg|thumb|Bottom Up Approach]]
# '''Umbrella approach.''' Another approach is called the umbrella approach. It is a hybrid of the top down and the botom up approach, ie both the bottom up and top down approaches are used.In this approach we first test along the functional and control flow paths, for this we use the bottom up approach. The results thus gathered are later integrated in a top down manner. This kind of testing allows creating early prototypes of the system with has limited functionality thereby helping is the creations of the product in an incremental manner. This types of testing also minimizes the use of [http://en.wikipedia.org/wiki/Test_stubs stubs] and drivers which are needed in the top-down and bottom up approaches.

==Prerequisites before Integration Testing==
The system that is being tested, all of its modules should be rigorously tested as a component, i.e they should have gone through unit tests.
==Steps to write good Integration Test Cases==
#Create a Test Plan
#Create test cases and the sample data against which they would be tested.
#If automated tools are being used, scripts should be created.
#After the components have been integrated, start executing the test cases created in point 2.
#Log the bugs found and rectify the same.
#Retest the code.

==How To write good Integration Test Cases and do effective Integration Testing==
The main focus of integration testing is that it needs to check whether the different components are working smoothly and are interacting with each other in the proper manner. The Integration test cases specifically focus on the flow of data/information/control from one component to the other.
A few thing that needs to be kept in mind for effective integration testing are
# Ensure that the correct versions of the components are integrated together.
# Automate the integration of components so that there is lesser chance for human error.
# Log all the errors that have been found and document them with the solutions as well as the version number so that we could keep track of which build was being tested when the error was discovered.

==Examples==
Sample Integration test case Templates can be found at [http://it.toolbox.com/blogs/enterprise-solutions/deliverable-integration-test-cases-29932 deliverable integration test cases]

Integration test plan Templates can be found at [http://geekswithblogs.net/dthakur/articles/10430.aspx Integration test plans]

=Beyond Functional and Integration Testing=
[[Image:TestPhase.jpg|thumb|Test Phases]]
Integration and Functional testing are not the only testing that are done for checking the validity of the system. Other test cases includes: 
'''Unit Testing:''' This is the first stage where the developer tests the component he/she is creating. More can be found at [http://en.wikipedia.org/wiki/Unit_testing Unit Testing] 
'''Validation Testing:''' After integration Testing, validation testing takes place wherein checks are made to ensure that the functional requirements are satisfied. 
'''Alpha and Beta Testing:'''When the product about to be released, it is first exposed to some end users who test the application. This is alpha beta testing. More can be found at [http://www.majordojo.com/uploads/AlphaBetaTesting.pdf Alpha and Beta Testing] 
'''Recovery Testing:''' In this phase the system is made to crash and is used to check to see if it recovers in the proper manner. More can be found at [http://en.wikipedia.org/wiki/Recovery_testing Recovery Testing] 
'''Security Testing:''' Systems that store and record sensitive information need to be protected from threats, in this phase the systems protection mechanisms are tested. More can be found at [http://en.wikipedia.org/wiki/Security_testing Security Testing] 
'''Stress Testing:'''The system is overloaded with data and it is checked to whether it crashes. More can be found at [http://en.wikipedia.org/wiki/Stress_testing Stress Testing] 
'''Performance Testing:''' It tests the run time performance of software within the context of the system. More can be found at [http://en.wikipedia.org/wiki/Performance_testing Performance Testing] 
'''Smoke Testing:''' smoke testing is a preliminary to further testing, which should reveal simple failures severe enough to reject a prospective software release. More can be found at [http://en.wikipedia.org/wiki/Smoke_test Smoke Test] 
'''Acceptance Testing:''' acceptance testing performed by the customer is known as user acceptance testing (UAT). This is also known as end-user testing, site (acceptance) testing, or field (acceptance) testing. More can be found at [http://en.wikipedia.org/wiki/Acceptance_testing Acceptance Testing]

=References=

# [http://www.segue.com/pdf/automated_functional_testing.pdf Automated Functional Testing]
# [http://searchsoftwarequality.techtarget.com/generic/0,295582,sid92_gci1303938,00.html# Functional Tests to ensure Software Quality]
# [http://www.developer.com/tech/article.php/3623476/Functional-Test-Plans-The-Right-Way.htm Functional Test Plans]
# Software Engineering: A Practitioner's Approach by Roger S. Pressman ISBN 0073655783

=External Links=
# [http://math-cs.gordon.edu/courses/cs211/ATMExample/InitialFunctionalTests.html Initial Functional Test Cases for an ATM system]
# [http://it.toolbox.com/blogs/enterprise-solutions/deliverable-integration-test-cases-29932 Integration test cases]
# [http://geekswithblogs.net/dthakur/articles/10430.aspx Integration Test Plan]
# [http://en.wikipedia.org/wiki/Unit_testing Unit Testing]
# [http://www.majordojo.com/uploads/AlphaBetaTesting.pdf Alpha Beta Testing]
# [http://en.wikipedia.org/wiki/Recovery_testing Recovery Testing]
# [http://en.wikipedia.org/wiki/Security_testing Security Testing]
# [http://en.wikipedia.org/wiki/Stress_testing Stress Testing]
# [http://en.wikipedia.org/wiki/Performance_testing Performance Testing]
# [http://en.wikipedia.org/wiki/Smoke_test Smoke Test]
# [http://en.wikipedia.org/wiki/Acceptance_testing Acceptance Testing]

CSC/ECE 517 Fall 2009/wiki1b 4 mv

2009-09-28T23:28:23Z

Mjampal: /* How To write good Integration Test Cases and do effective Integration Testing */

=Introduction=
Unit Testing is given a lot of importance in Software Testing. But functional and integration testing are essential too. Hence Functional and Integration Testing is discussed here. This page provides an introduction to these testing methods; also including the good practices to write functional and integration tests. Later additional types of Software Tests are mentioned, which could be used to gain further confidence that one's code is correct.

=Functional Testing=
Functional testing is the process of testing of all the functions of a system, ensuring that the system conforms to the user requirements and specifications. It is sometimes referred to as black-box testing, as it does not require understanding of the internal structure of the implementation.

Functional testing can be done by using manual or automated methods[http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki1b_4_mv#References]. In both the methods, a series of tests have to be run marking the interaction between the user and the system, ensuring that the system performs as it was supposed to. Since Use cases mainly depict the interaction between the user and system, functional test suites are created from requirement use cases, with each scenario becoming a functional test[http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki1b_4_mv#References].

==Functional Test Plan==
"The functional test plan measures the quality of the functional components of the system[http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki1b_4_mv#References]". The test plan is written by the Author. The Author lists a number of test cases, containing the input, expected results, and pre and post-test setup. After a module is unit tested, the Tester executes the functional test cases and records the actual results. The Reviewer compares the Actual results with the expected results and reports whether each test case passed or failed the test.

==Guidelines to write good Functional Tests==
# The test plan must be written by persons who have extensive knowledge of the business requirements. It is advisable that the developers do not write the test plans. This is because developers tend to unknowingly write test cases whose functionality is based on the implementation rather than the initial functional specifications.
# The functional test plans should be created as early as possible, probably as soon as the functional specifications are ready.
# The functional test plan should be updated when there are changes in the business requirements.
# For each functionality, a list of test cases should be defined so that each aspect of the functionality is covered.
# The Author should clearly include the pre-test setup for the test cases so that the Tester can easily execute the test cases.
# Usually the same test cases are run a number of times. Hence after executing a test case, any data added to the system should be cleared so as to not affect further tests or rerunning of the same test case. Hence the Author should also give post-test setup details.
# As a module is built and unit tested, the Tester should execute the particular test cases and record the results.
# Reviewer should review the results and report any bugs to the developers.

==Examples==
Examples of pre-test setup, test cases and post-test setup are given below. The complete reference for the example can be found at [http://www.developer.com/java/ent/article.php/3623476/Functional-Test-Plans-The-Right-Way.htm Functional Test Plans]

The pre-test setup for Test Case: Create new user profile can be given as:
[UserName: "A": --> username: "A"]
[UserName: "A": --> first name: "John"]
[UserName: "A": --> last name: "Smith"]
[UserName: "A": --> access level: "read-only"]
[UserName: "A": --> password: "profile1"]

The test cases for the function:Verify that only valid users can access the system can be given as:

<table cellspacing="2" width=900 border="1" align="center" >
<tr valign="top" bgcolor="#99ffff">
<th>Test Case #</th>
<th>Required Input</th>
<th>Expected Results</th>
<th>Results</th>

<th>Pass/Fail</th></tr>

<tr valign="top"><td colspan="5">
<ul>
<li>Verify that only valid users can access the system.</li>
<li>Verify that valid users cannot access the system without entering a valid password.</li>
</ul></td></tr>

<tr valign="top"><td>1</td>
<td>Navigate to the login screen</td>
<td>Login screen with release number A is loaded.</td>

<td> </td>
<td> </td></tr>

<tr valign="top"><td>2</td>
<td>Enter user name "INVALIDUSER", password "INVALIDUSER", and click on login button</td>
<td>Error message: 
"User name is not found"</td>
<td> </td>
<td> </td></tr>

<tr valign="top"><td>3</td>
<td>Enter user name for user [UserName: "A":--> username] and password "test"</td>

<td>Error Message: 
"Password for user [UserName: "A": --> username] is invalid"</td>
<td> </td>
<td> </td></tr>

<tr valign="top"><td>4</td>
<td>Enter user name [UserName: "A": --> username] and password [UserName: "A": --> password]</td>

<td>The main page is loaded with a message: 
"Welcome [UserName: "A": --> first name] [UserName: "A": --> last name]</td>
<td> </td>
<td> </td></tr>
</table>

The post-test setup for the above scenario can be given as:
Remove [UserName: "A": --> username: "A"] from the LDAP Server.

Another Example of Test Cases can be found at [http://math-cs.gordon.edu/courses/cs211/ATMExample/InitialFunctionalTests.html Initial Functional Test Cases for an ATM system]

=Integration Testing=
Integration Testing is a process of testing the application on the whole. After going through the unit testing of the modules, these modules need to be integrated, and during this process things may go wrong, Integration process is the phase wherein these errors are captured and rectified.
It is very common for modules after having successful passed all the unit test cases to fail when they are integrated with other modules. Integration testing is an important phase and sometimes there are separate teams which handle integration testing.
 
DEFINITION:Integration testing is a systematic technique for constructing the program structure while at the same time conducting tests to uncover errors associated with interfacing. The objective is to take unit tested components
and build a program structure that has been dictated by design.[http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki1b_4_mv#References]

==Integration Test approaches==
Integration testing can be done in a variety of ways [[Image:TopDown_Approach.jpg|thumb|Top Down Approach]]
# '''Top-Down Approach.''' In this approach the modules higher up in the control hierarchy are integrated first and low-level modules are added later. The advantage of this approach is that the modules with high level logic are tested first and hence bugs in the crucial logic are caught early. Further this approach does not require drivers (dummy control modules used instead of the actual modules for the purpose of testing) to be written. Although a number of [http://en.wikipedia.org/wiki/Test_stubs stubs] have to be written and managed
# '''Bottom Up Approach.''' In this approach, the low level modules are integrated first and high level logic is tested late. While integrating the low level modules, the control modules are replaced by dummy modules called as drivers. Thus driver codes have to be written and managed while using this approach. [[Image:BottomUp_Approach.jpg|thumb|Bottom Up Approach]]
# '''Umbrella approach.''' Another approach is called the umbrella approach. It is a hybrid of the top down and the botom up approach, ie both the bottom up and top down approaches are used.In this approach we first test along the functional and control flow paths, for this we use the bottom up approach. The results thus gathered are later integrated in a top down manner. This kind of testing allows creating early prototypes of the system with has limited functionality thereby helping is the creations of the product in an incremental manner. This types of testing also minimizes the use of [http://en.wikipedia.org/wiki/Test_stubs stubs] and drivers which are needed in the top-down and bottom up approaches.

==Prerequisites before Integration Testing==
The system that is being tested, all of its modules should be rigorously tested as a component, i.e they should have gone through unit tests.
==Steps to write good Integration Test Cases==
#Create a Test Plan
#Create test cases and the sample data against which they would be tested.
#If automated tools are being used, scripts should be created.
#After the components have been integrated, start executing the test cases created in point 2.
#Log the bugs found and rectify the same.
#Retest the code.

==How To write good Integration Test Cases and do effective Integration Testing==
The main focus of integration testing is that it needs to check whether the different components are working smoothly and are interacting with each other in the proper manner. The Integration test cases specifically focus on the flow of data/information/control from one component to the other.
A few thing that needs to be kept in mind for effective integration testing are
# Ensure that the correct versions of the components are integrated together.
# Automate the integration of components so that there is lesser chance for human error.
# Log all the errors that have been found and document them with the solutions as well as the version number so that we could keep track of which build was being tested when the error was discovered.

==Examples==
Sample Integration test case Templates can be found at [http://it.toolbox.com/blogs/enterprise-solutions/deliverable-integration-test-cases-29932 deliverable integration test cases]

Integration test plan Templates can be found at [http://geekswithblogs.net/dthakur/articles/10430.aspx Integration test plans]

=Beyond Functional and Integration Testing=
[[Image:TestPhase.jpg|thumb|Test Phases]]
Integration and Functional testing are not the only testing that are done for checking the validity of the system. Other test cases includes: 
'''Unit Testing:''' This is the first stage where the developer tests the component he/she is creating. More can be found at [http://en.wikipedia.org/wiki/Unit_testing Unit Testing] 
'''Validation Testing:''' After integration Testing, validation testing takes place wherein checks are made to ensure that the functional requirements are satisfied. 
'''Alpha and Beta Testing:'''When the product about to be released, it is first exposed to some end users who test the application. This is alpha beta testing. More can be found at [http://www.majordojo.com/uploads/AlphaBetaTesting.pdf Alpha and Beta Testing] 
'''Recovery Testing:''' In this phase the system is made to crash and is used to check to see if it recovers in the proper manner. More can be found at [http://en.wikipedia.org/wiki/Recovery_testing Recovery Testing] 
'''Security Testing:''' Systems that store and record sensitive information need to be protected from threats, in this phase the systems protection mechanisms are tested. More can be found at [http://en.wikipedia.org/wiki/Security_testing Security Testing] 
'''Stress Testing:'''The system is overloaded with data and it is checked to whether it crashes. More can be found at [http://en.wikipedia.org/wiki/Stress_testing Stress Testing] 
'''Performance Testing:''' It tests the run time performance of software within the context of the system. More can be found at [http://en.wikipedia.org/wiki/Performance_testing Performance Testing] 
'''Smoke Testing:''' smoke testing is a preliminary to further testing, which should reveal simple failures severe enough to reject a prospective software release. More can be found at [http://en.wikipedia.org/wiki/Smoke_test Smoke Test] 
'''Acceptance Testing:''' acceptance testing performed by the customer is known as user acceptance testing (UAT). This is also known as end-user testing, site (acceptance) testing, or field (acceptance) testing. More can be found at [http://en.wikipedia.org/wiki/Acceptance_testing Acceptance Testing]

=References=

# [http://www.segue.com/pdf/automated_functional_testing.pdf Automated Functional Testing]
# [http://searchsoftwarequality.techtarget.com/generic/0,295582,sid92_gci1303938,00.html# Functional Tests to ensure Software Quality]
# [http://www.developer.com/tech/article.php/3623476/Functional-Test-Plans-The-Right-Way.htm Functional Test Plans]
# Software Engineering: A Practitioner's Approach by Roger S. Pressman ISBN 0073655783

=External Links=
# [http://math-cs.gordon.edu/courses/cs211/ATMExample/InitialFunctionalTests.html Initial Functional Test Cases for an ATM system]
# [http://en.wikipedia.org/wiki/Unit_testing Unit Testing]
# [http://www.majordojo.com/uploads/AlphaBetaTesting.pdf Alpha Beta Testing]
# [http://en.wikipedia.org/wiki/Recovery_testing Recovery Testing]
# [http://en.wikipedia.org/wiki/Security_testing Security Testing]
# [http://en.wikipedia.org/wiki/Stress_testing Stress Testing]
# [http://en.wikipedia.org/wiki/Performance_testing Performance Testing]
# [http://en.wikipedia.org/wiki/Smoke_test Smoke Test]
# [http://en.wikipedia.org/wiki/Acceptance_testing Acceptance Testing]

CSC/ECE 517 Fall 2009/wiki1b 4 mv

2009-09-28T23:20:49Z

Mjampal: /* Integration Test approaches */

=Introduction=
Unit Testing is given a lot of importance in Software Testing. But functional and integration testing are essential too. Hence Functional and Integration Testing is discussed here. This page provides an introduction to these testing methods; also including the good practices to write functional and integration tests. Later additional types of Software Tests are mentioned, which could be used to gain further confidence that one's code is correct.

=Functional Testing=
Functional testing is the process of testing of all the functions of a system, ensuring that the system conforms to the user requirements and specifications. It is sometimes referred to as black-box testing, as it does not require understanding of the internal structure of the implementation.

Functional testing can be done by using manual or automated methods[http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki1b_4_mv#References]. In both the methods, a series of tests have to be run marking the interaction between the user and the system, ensuring that the system performs as it was supposed to. Since Use cases mainly depict the interaction between the user and system, functional test suites are created from requirement use cases, with each scenario becoming a functional test[http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki1b_4_mv#References].

==Functional Test Plan==
"The functional test plan measures the quality of the functional components of the system[http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki1b_4_mv#References]". The test plan is written by the Author. The Author lists a number of test cases, containing the input, expected results, and pre and post-test setup. After a module is unit tested, the Tester executes the functional test cases and records the actual results. The Reviewer compares the Actual results with the expected results and reports whether each test case passed or failed the test.

==Guidelines to write good Functional Tests==
# The test plan must be written by persons who have extensive knowledge of the business requirements. It is advisable that the developers do not write the test plans. This is because developers tend to unknowingly write test cases whose functionality is based on the implementation rather than the initial functional specifications.
# The functional test plans should be created as early as possible, probably as soon as the functional specifications are ready.
# The functional test plan should be updated when there are changes in the business requirements.
# For each functionality, a list of test cases should be defined so that each aspect of the functionality is covered.
# The Author should clearly include the pre-test setup for the test cases so that the Tester can easily execute the test cases.
# Usually the same test cases are run a number of times. Hence after executing a test case, any data added to the system should be cleared so as to not affect further tests or rerunning of the same test case. Hence the Author should also give post-test setup details.
# As a module is built and unit tested, the Tester should execute the particular test cases and record the results.
# Reviewer should review the results and report any bugs to the developers.

==Examples==
Examples of pre-test setup, test cases and post-test setup are given below. The complete reference for the example can be found at [http://www.developer.com/java/ent/article.php/3623476/Functional-Test-Plans-The-Right-Way.htm Functional Test Plans]

The pre-test setup for Test Case: Create new user profile can be given as:
[UserName: "A": --> username: "A"]
[UserName: "A": --> first name: "John"]
[UserName: "A": --> last name: "Smith"]
[UserName: "A": --> access level: "read-only"]
[UserName: "A": --> password: "profile1"]

The test cases for the function:Verify that only valid users can access the system can be given as:

<table cellspacing="2" width=900 border="1" align="center" >
<tr valign="top" bgcolor="#99ffff">
<th>Test Case #</th>
<th>Required Input</th>
<th>Expected Results</th>
<th>Results</th>

<th>Pass/Fail</th></tr>

<tr valign="top"><td colspan="5">
<ul>
<li>Verify that only valid users can access the system.</li>
<li>Verify that valid users cannot access the system without entering a valid password.</li>
</ul></td></tr>

<tr valign="top"><td>1</td>
<td>Navigate to the login screen</td>
<td>Login screen with release number A is loaded.</td>

<td> </td>
<td> </td></tr>

<tr valign="top"><td>2</td>
<td>Enter user name "INVALIDUSER", password "INVALIDUSER", and click on login button</td>
<td>Error message: 
"User name is not found"</td>
<td> </td>
<td> </td></tr>

<tr valign="top"><td>3</td>
<td>Enter user name for user [UserName: "A":--> username] and password "test"</td>

<td>Error Message: 
"Password for user [UserName: "A": --> username] is invalid"</td>
<td> </td>
<td> </td></tr>

<tr valign="top"><td>4</td>
<td>Enter user name [UserName: "A": --> username] and password [UserName: "A": --> password]</td>

<td>The main page is loaded with a message: 
"Welcome [UserName: "A": --> first name] [UserName: "A": --> last name]</td>
<td> </td>
<td> </td></tr>
</table>

The post-test setup for the above scenario can be given as:
Remove [UserName: "A": --> username: "A"] from the LDAP Server.

Another Example of Test Cases can be found at [http://math-cs.gordon.edu/courses/cs211/ATMExample/InitialFunctionalTests.html Initial Functional Test Cases for an ATM system]

=Integration Testing=
Integration Testing is a process of testing the application on the whole. After going through the unit testing of the modules, these modules need to be integrated, and during this process things may go wrong, Integration process is the phase wherein these errors are captured and rectified.
It is very common for modules after having successful passed all the unit test cases to fail when they are integrated with other modules. Integration testing is an important phase and sometimes there are separate teams which handle integration testing.
 
DEFINITION:Integration testing is a systematic technique for constructing the program structure while at the same time conducting tests to uncover errors associated with interfacing. The objective is to take unit tested components
and build a program structure that has been dictated by design.[http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki1b_4_mv#References]

==Integration Test approaches==
Integration testing can be done in a variety of ways [[Image:TopDown_Approach.jpg|thumb|Top Down Approach]]
# '''Top-Down Approach.''' In this approach the modules higher up in the control hierarchy are integrated first and low-level modules are added later. The advantage of this approach is that the modules with high level logic are tested first and hence bugs in the crucial logic are caught early. Further this approach does not require drivers (dummy control modules used instead of the actual modules for the purpose of testing) to be written. Although a number of [http://en.wikipedia.org/wiki/Test_stubs stubs] have to be written and managed
# '''Bottom Up Approach.''' In this approach, the low level modules are integrated first and high level logic is tested late. While integrating the low level modules, the control modules are replaced by dummy modules called as drivers. Thus driver codes have to be written and managed while using this approach. [[Image:BottomUp_Approach.jpg|thumb|Bottom Up Approach]]
# '''Umbrella approach.''' Another approach is called the umbrella approach. It is a hybrid of the top down and the botom up approach, ie both the bottom up and top down approaches are used.In this approach we first test along the functional and control flow paths, for this we use the bottom up approach. The results thus gathered are later integrated in a top down manner. This kind of testing allows creating early prototypes of the system with has limited functionality thereby helping is the creations of the product in an incremental manner. This types of testing also minimizes the use of [http://en.wikipedia.org/wiki/Test_stubs stubs] and drivers which are needed in the top-down and bottom up approaches.

==Prerequisites before Integration Testing==
The system that is being tested, all of its modules should be rigorously tested as a component, i.e they should have gone through unit tests.
==Steps to write good Integration Test Cases==
#Create a Test Plan
#Create test cases and the sample data against which they would be tested.
#If automated tools are being used, scripts should be created.
#After the components have been integrated, start executing the test cases created in point 2.
#Log the bugs found and rectify the same.
#Retest the code.

==How To write good Integration Test Cases and do effective Integration Testing==
The main focus of integration testing is that it needs to check whether the different components are working smoothly and are interacting with each other in the proper manner. The Integration test cases specifically focus on the flow of data/information/control from one component to the other.
A few thing that needs to be kept in mind for effective integration testing are
# Ensure that the correct versions of the components are integrated together.
# Automate the integration of components so that there is lesser chance for human error.
# Log all the errors that have been found and document them with the solutions as well as the version number so that we could keep track of which build was being tested when the error was discovered.

=Beyond Functional and Integration Testing=
[[Image:TestPhase.jpg|thumb|Test Phases]]
Integration and Functional testing are not the only testing that are done for checking the validity of the system. Other test cases includes: 
'''Unit Testing:''' This is the first stage where the developer tests the component he/she is creating. More can be found at [http://en.wikipedia.org/wiki/Unit_testing Unit Testing] 
'''Validation Testing:''' After integration Testing, validation testing takes place wherein checks are made to ensure that the functional requirements are satisfied. 
'''Alpha and Beta Testing:'''When the product about to be released, it is first exposed to some end users who test the application. This is alpha beta testing. More can be found at [http://www.majordojo.com/uploads/AlphaBetaTesting.pdf Alpha and Beta Testing] 
'''Recovery Testing:''' In this phase the system is made to crash and is used to check to see if it recovers in the proper manner. More can be found at [http://en.wikipedia.org/wiki/Recovery_testing Recovery Testing] 
'''Security Testing:''' Systems that store and record sensitive information need to be protected from threats, in this phase the systems protection mechanisms are tested. More can be found at [http://en.wikipedia.org/wiki/Security_testing Security Testing] 
'''Stress Testing:'''The system is overloaded with data and it is checked to whether it crashes. More can be found at [http://en.wikipedia.org/wiki/Stress_testing Stress Testing] 
'''Performance Testing:''' It tests the run time performance of software within the context of the system. More can be found at [http://en.wikipedia.org/wiki/Performance_testing Performance Testing] 
'''Smoke Testing:''' smoke testing is a preliminary to further testing, which should reveal simple failures severe enough to reject a prospective software release. More can be found at [http://en.wikipedia.org/wiki/Smoke_test Smoke Test] 
'''Acceptance Testing:''' acceptance testing performed by the customer is known as user acceptance testing (UAT). This is also known as end-user testing, site (acceptance) testing, or field (acceptance) testing. More can be found at [http://en.wikipedia.org/wiki/Acceptance_testing Acceptance Testing]

=References=

# [http://www.segue.com/pdf/automated_functional_testing.pdf Automated Functional Testing]
# [http://searchsoftwarequality.techtarget.com/generic/0,295582,sid92_gci1303938,00.html# Functional Tests to ensure Software Quality]
# [http://www.developer.com/tech/article.php/3623476/Functional-Test-Plans-The-Right-Way.htm Functional Test Plans]
# Software Engineering: A Practitioner's Approach by Roger S. Pressman ISBN 0073655783

=External Links=
# [http://math-cs.gordon.edu/courses/cs211/ATMExample/InitialFunctionalTests.html Initial Functional Test Cases for an ATM system]
# [http://en.wikipedia.org/wiki/Unit_testing Unit Testing]
# [http://www.majordojo.com/uploads/AlphaBetaTesting.pdf Alpha Beta Testing]
# [http://en.wikipedia.org/wiki/Recovery_testing Recovery Testing]
# [http://en.wikipedia.org/wiki/Security_testing Security Testing]
# [http://en.wikipedia.org/wiki/Stress_testing Stress Testing]
# [http://en.wikipedia.org/wiki/Performance_testing Performance Testing]
# [http://en.wikipedia.org/wiki/Smoke_test Smoke Test]
# [http://en.wikipedia.org/wiki/Acceptance_testing Acceptance Testing]

CSC/ECE 517 Fall 2009/wiki1b 4 mv

2009-09-28T23:12:14Z

Mjampal: /* Integration Test approaches */

=Introduction=
Unit Testing is given a lot of importance in Software Testing. But functional and integration testing are essential too. Hence Functional and Integration Testing is discussed here. This page provides an introduction to these testing methods; also including the good practices to write functional and integration tests. Later additional types of Software Tests are mentioned, which could be used to gain further confidence that one's code is correct.

=Functional Testing=
Functional testing is the process of testing of all the functions of a system, ensuring that the system conforms to the user requirements and specifications. It is sometimes referred to as black-box testing, as it does not require understanding of the internal structure of the implementation.

Functional testing can be done by using manual or automated methods[http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki1b_4_mv#References]. In both the methods, a series of tests have to be run marking the interaction between the user and the system, ensuring that the system performs as it was supposed to. Since Use cases mainly depict the interaction between the user and system, functional test suites are created from requirement use cases, with each scenario becoming a functional test[http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki1b_4_mv#References].

==Functional Test Plan==
"The functional test plan measures the quality of the functional components of the system[http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki1b_4_mv#References]". The test plan is written by the Author. The Author lists a number of test cases, containing the input, expected results, and pre and post-test setup. After a module is unit tested, the Tester executes the functional test cases and records the actual results. The Reviewer compares the Actual results with the expected results and reports whether each test case passed or failed the test.

==Guidelines to write good Functional Tests==
# The test plan must be written by persons who have extensive knowledge of the business requirements. It is advisable that the developers do not write the test plans. This is because developers tend to unknowingly write test cases whose functionality is based on the implementation rather than the initial functional specifications.
# The functional test plans should be created as early as possible, probably as soon as the functional specifications are ready.
# The functional test plan should be updated when there are changes in the business requirements.
# For each functionality, a list of test cases should be defined so that each aspect of the functionality is covered.
# The Author should clearly include the pre-test setup for the test cases so that the Tester can easily execute the test cases.
# Usually the same test cases are run a number of times. Hence after executing a test case, any data added to the system should be cleared so as to not affect further tests or rerunning of the same test case. Hence the Author should also give post-test setup details.
# As a module is built and unit tested, the Tester should execute the particular test cases and record the results.
# Reviewer should review the results and report any bugs to the developers.

==Examples==
Examples of pre-test setup, test cases and post-test setup are given below. The complete reference for the example can be found at [http://www.developer.com/java/ent/article.php/3623476/Functional-Test-Plans-The-Right-Way.htm Functional Test Plans]

The pre-test setup for Test Case: Create new user profile can be given as:
[UserName: "A": --> username: "A"]
[UserName: "A": --> first name: "John"]
[UserName: "A": --> last name: "Smith"]
[UserName: "A": --> access level: "read-only"]
[UserName: "A": --> password: "profile1"]

The test cases for the function:Verify that only valid users can access the system can be given as:

<table cellspacing="2" width=900 border="1" align="center" >
<tr valign="top" bgcolor="#99ffff">
<th>Test Case #</th>
<th>Required Input</th>
<th>Expected Results</th>
<th>Results</th>

<th>Pass/Fail</th></tr>

<tr valign="top"><td colspan="5">
<ul>
<li>Verify that only valid users can access the system.</li>
<li>Verify that valid users cannot access the system without entering a valid password.</li>
</ul></td></tr>

<tr valign="top"><td>1</td>
<td>Navigate to the login screen</td>
<td>Login screen with release number A is loaded.</td>

<td> </td>
<td> </td></tr>

<tr valign="top"><td>2</td>
<td>Enter user name "INVALIDUSER", password "INVALIDUSER", and click on login button</td>
<td>Error message: 
"User name is not found"</td>
<td> </td>
<td> </td></tr>

<tr valign="top"><td>3</td>
<td>Enter user name for user [UserName: "A":--> username] and password "test"</td>

<td>Error Message: 
"Password for user [UserName: "A": --> username] is invalid"</td>
<td> </td>
<td> </td></tr>

<tr valign="top"><td>4</td>
<td>Enter user name [UserName: "A": --> username] and password [UserName: "A": --> password]</td>

<td>The main page is loaded with a message: 
"Welcome [UserName: "A": --> first name] [UserName: "A": --> last name]</td>
<td> </td>
<td> </td></tr>
</table>

The post-test setup for the above scenario can be given as:
Remove [UserName: "A": --> username: "A"] from the LDAP Server.

Another Example of Test Cases can be found at [http://math-cs.gordon.edu/courses/cs211/ATMExample/InitialFunctionalTests.html Initial Functional Test Cases for an ATM system]

=Integration Testing=
Integration Testing is a process of testing the application on the whole. After going through the unit testing of the modules, these modules need to be integrated, and during this process things may go wrong, Integration process is the phase wherein these errors are captured and rectified.
It is very common for modules after having successful passed all the unit test cases to fail when they are integrated with other modules. Integration testing is an important phase and sometimes there are separate teams which handle integration testing.
 
DEFINITION:Integration testing is a systematic technique for constructing the program structure while at the same time conducting tests to uncover errors associated with interfacing. The objective is to take unit tested components
and build a program structure that has been dictated by design.[http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki1b_4_mv#References]

==Integration Test approaches==
Integration testing can be done in a variety of ways [[Image:TopDown_Approach.jpg|thumb|Top Down Approach]]
# '''Top-Down Approach.''' In this approach the modules higher up in the control hierarchy are integrated first and low-level modules are added later. The advantage of this approach is that the modules with high level logic are tested first and hence bugs in the crucial logic are caught early. Further this approach does not require drivers to be written. Although a number of [http://en.wikipedia.org/wiki/Test_stubs stubs] have to be written and managed
# '''Bottom Up Approach.''' In this approach, the low level modules are integrated first and high level logic is tested late. While integrating the low level modules, the control modules are replaced by dummy modules called as drivers. Thus driver codes have to be written and managed while using this approach. [[Image:BottomUp_Approach.jpg|thumb|Bottom Up Approach]]
# '''Umbrella approach.''' Another approach is called the umbrella approach. It is a hybrid of the top down and the botom up approach, ie both the bottom up and top down approaches are used.In this approach we first test along the functional and control flow paths, for this we use the bottom up approach. The results thus gathered are later integrated in a top down manner. This kind of testing allows creating early prototypes of the system with has limited functionality thereby helping is the creations of the product in an incremental manner. This types of testing also minimizes the use of stubs and drivers which are needed in the top-down and bottom up approaches.

==Prerequisites before Integration Testing==
The system that is being tested, all of its modules should be rigorously tested as a component, i.e they should have gone through unit tests.
==Steps to write good Integration Test Cases==
#Create a Test Plan
#Create test cases and the sample data against which they would be tested.
#If automated tools are being used, scripts should be created.
#After the components have been integrated, start executing the test cases created in point 2.
#Log the bugs found and rectify the same.
#Retest the code.

==How To write good Integration Test Cases and do effective Integration Testing==
The main focus of integration testing is that it needs to check whether the different components are working smoothly and are interacting with each other in the proper manner. The Integration test cases specifically focus on the flow of data/information/control from one component to the other.
A few thing that needs to be kept in mind for effective integration testing are
# Ensure that the correct versions of the components are integrated together.
# Automate the integration of components so that there is lesser chance for human error.
# Log all the errors that have been found and document them with the solutions as well as the version number so that we could keep track of which build was being tested when the error was discovered.

=Beyond Functional and Integration Testing=
[[Image:TestPhase.jpg|thumb|Test Phases]]
Integration and Functional testing are not the only testing that are done for checking the validity of the system. Other test cases includes: 
'''Unit Testing:''' This is the first stage where the developer tests the component he/she is creating. More can be found at [http://en.wikipedia.org/wiki/Unit_testing Unit Testing] 
'''Validation Testing:''' After integration Testing, validation testing takes place wherein checks are made to ensure that the functional requirements are satisfied. 
'''Alpha and Beta Testing:'''When the product about to be released, it is first exposed to some end users who test the application. This is alpha beta testing. More can be found at [http://www.majordojo.com/uploads/AlphaBetaTesting.pdf Alpha and Beta Testing] 
'''Recovery Testing:''' In this phase the system is made to crash and is used to check to see if it recovers in the proper manner. More can be found at [http://en.wikipedia.org/wiki/Recovery_testing Recovery Testing] 
'''Security Testing:''' Systems that store and record sensitive information need to be protected from threats, in this phase the systems protection mechanisms are tested. More can be found at [http://en.wikipedia.org/wiki/Security_testing Security Testing] 
'''Stress Testing:'''The system is overloaded with data and it is checked to whether it crashes. More can be found at [http://en.wikipedia.org/wiki/Stress_testing Stress Testing] 
'''Performance Testing:''' It tests the run time performance of software within the context of the system. More can be found at [http://en.wikipedia.org/wiki/Performance_testing Performance Testing] 
'''Smoke Testing:''' smoke testing is a preliminary to further testing, which should reveal simple failures severe enough to reject a prospective software release. More can be found at [http://en.wikipedia.org/wiki/Smoke_test Smoke Test] 
'''Acceptance Testing:''' acceptance testing performed by the customer is known as user acceptance testing (UAT). This is also known as end-user testing, site (acceptance) testing, or field (acceptance) testing. More can be found at [http://en.wikipedia.org/wiki/Acceptance_testing Acceptance Testing]

=References=

# [http://www.segue.com/pdf/automated_functional_testing.pdf Automated Functional Testing]
# [http://searchsoftwarequality.techtarget.com/generic/0,295582,sid92_gci1303938,00.html# Functional Tests to ensure Software Quality]
# [http://www.developer.com/tech/article.php/3623476/Functional-Test-Plans-The-Right-Way.htm Functional Test Plans]
# Software Engineering: A Practitioner's Approach by Roger S. Pressman ISBN 0073655783

=External Links=
# [http://math-cs.gordon.edu/courses/cs211/ATMExample/InitialFunctionalTests.html Initial Functional Test Cases for an ATM system]
# [http://en.wikipedia.org/wiki/Unit_testing Unit Testing]
# [http://www.majordojo.com/uploads/AlphaBetaTesting.pdf Alpha Beta Testing]
# [http://en.wikipedia.org/wiki/Recovery_testing Recovery Testing]
# [http://en.wikipedia.org/wiki/Security_testing Security Testing]
# [http://en.wikipedia.org/wiki/Stress_testing Stress Testing]
# [http://en.wikipedia.org/wiki/Performance_testing Performance Testing]
# [http://en.wikipedia.org/wiki/Smoke_test Smoke Test]
# [http://en.wikipedia.org/wiki/Acceptance_testing Acceptance Testing]

CSC/ECE 517 Fall 2009/wiki1b 4 mv

2009-09-28T23:11:43Z

Mjampal: /* Integration Test approaches */

=Introduction=
Unit Testing is given a lot of importance in Software Testing. But functional and integration testing are essential too. Hence Functional and Integration Testing is discussed here. This page provides an introduction to these testing methods; also including the good practices to write functional and integration tests. Later additional types of Software Tests are mentioned, which could be used to gain further confidence that one's code is correct.

=Functional Testing=
Functional testing is the process of testing of all the functions of a system, ensuring that the system conforms to the user requirements and specifications. It is sometimes referred to as black-box testing, as it does not require understanding of the internal structure of the implementation.

Functional testing can be done by using manual or automated methods[http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki1b_4_mv#References]. In both the methods, a series of tests have to be run marking the interaction between the user and the system, ensuring that the system performs as it was supposed to. Since Use cases mainly depict the interaction between the user and system, functional test suites are created from requirement use cases, with each scenario becoming a functional test[http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki1b_4_mv#References].

==Functional Test Plan==
"The functional test plan measures the quality of the functional components of the system[http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki1b_4_mv#References]". The test plan is written by the Author. The Author lists a number of test cases, containing the input, expected results, and pre and post-test setup. After a module is unit tested, the Tester executes the functional test cases and records the actual results. The Reviewer compares the Actual results with the expected results and reports whether each test case passed or failed the test.

==Guidelines to write good Functional Tests==
# The test plan must be written by persons who have extensive knowledge of the business requirements. It is advisable that the developers do not write the test plans. This is because developers tend to unknowingly write test cases whose functionality is based on the implementation rather than the initial functional specifications.
# The functional test plans should be created as early as possible, probably as soon as the functional specifications are ready.
# The functional test plan should be updated when there are changes in the business requirements.
# For each functionality, a list of test cases should be defined so that each aspect of the functionality is covered.
# The Author should clearly include the pre-test setup for the test cases so that the Tester can easily execute the test cases.
# Usually the same test cases are run a number of times. Hence after executing a test case, any data added to the system should be cleared so as to not affect further tests or rerunning of the same test case. Hence the Author should also give post-test setup details.
# As a module is built and unit tested, the Tester should execute the particular test cases and record the results.
# Reviewer should review the results and report any bugs to the developers.

==Examples==
Examples of pre-test setup, test cases and post-test setup are given below. The complete reference for the example can be found at [http://www.developer.com/java/ent/article.php/3623476/Functional-Test-Plans-The-Right-Way.htm Functional Test Plans]

The pre-test setup for Test Case: Create new user profile can be given as:
[UserName: "A": --> username: "A"]
[UserName: "A": --> first name: "John"]
[UserName: "A": --> last name: "Smith"]
[UserName: "A": --> access level: "read-only"]
[UserName: "A": --> password: "profile1"]

The test cases for the function:Verify that only valid users can access the system can be given as:

<table cellspacing="2" width=900 border="1" align="center" >
<tr valign="top" bgcolor="#99ffff">
<th>Test Case #</th>
<th>Required Input</th>
<th>Expected Results</th>
<th>Results</th>

<th>Pass/Fail</th></tr>

<tr valign="top"><td colspan="5">
<ul>
<li>Verify that only valid users can access the system.</li>
<li>Verify that valid users cannot access the system without entering a valid password.</li>
</ul></td></tr>

<tr valign="top"><td>1</td>
<td>Navigate to the login screen</td>
<td>Login screen with release number A is loaded.</td>

<td> </td>
<td> </td></tr>

<tr valign="top"><td>2</td>
<td>Enter user name "INVALIDUSER", password "INVALIDUSER", and click on login button</td>
<td>Error message: 
"User name is not found"</td>
<td> </td>
<td> </td></tr>

<tr valign="top"><td>3</td>
<td>Enter user name for user [UserName: "A":--> username] and password "test"</td>

<td>Error Message: 
"Password for user [UserName: "A": --> username] is invalid"</td>
<td> </td>
<td> </td></tr>

<tr valign="top"><td>4</td>
<td>Enter user name [UserName: "A": --> username] and password [UserName: "A": --> password]</td>

<td>The main page is loaded with a message: 
"Welcome [UserName: "A": --> first name] [UserName: "A": --> last name]</td>
<td> </td>
<td> </td></tr>
</table>

The post-test setup for the above scenario can be given as:
Remove [UserName: "A": --> username: "A"] from the LDAP Server.

Another Example of Test Cases can be found at [http://math-cs.gordon.edu/courses/cs211/ATMExample/InitialFunctionalTests.html Initial Functional Test Cases for an ATM system]

=Integration Testing=
Integration Testing is a process of testing the application on the whole. After going through the unit testing of the modules, these modules need to be integrated, and during this process things may go wrong, Integration process is the phase wherein these errors are captured and rectified.
It is very common for modules after having successful passed all the unit test cases to fail when they are integrated with other modules. Integration testing is an important phase and sometimes there are separate teams which handle integration testing.
 
DEFINITION:Integration testing is a systematic technique for constructing the program structure while at the same time conducting tests to uncover errors associated with interfacing. The objective is to take unit tested components
and build a program structure that has been dictated by design.[http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki1b_4_mv#References]

==Integration Test approaches==
Integration testing can be done in a variety of ways [[Image:TopDown_Approach.jpg|thumb|Top Down Approach]]
# '''Top-Down Approach.''' In this approach the modules higher up in the control hierarchy are integrated first and low-level modules are added later. The advantage of this approach is that the modules with high level logic are tested first and hence bugs in the crucial logic are caught early. Further this approach does not require drivers to be written. Although a number of [[http://en.wikipedia.org/wiki/Test_stubs stubs]] have to be written and managed
# '''Bottom Up Approach.''' In this approach, the low level modules are integrated first and high level logic is tested late. While integrating the low level modules, the control modules are replaced by dummy modules called as drivers. Thus driver codes have to be written and managed while using this approach. [[Image:BottomUp_Approach.jpg|thumb|Bottom Up Approach]]
# '''Umbrella approach.''' Another approach is called the umbrella approach. It is a hybrid of the top down and the botom up approach, ie both the bottom up and top down approaches are used.In this approach we first test along the functional and control flow paths, for this we use the bottom up approach. The results thus gathered are later integrated in a top down manner. This kind of testing allows creating early prototypes of the system with has limited functionality thereby helping is the creations of the product in an incremental manner. This types of testing also minimizes the use of stubs and drivers which are needed in the top-down and bottom up approaches.

==Prerequisites before Integration Testing==
The system that is being tested, all of its modules should be rigorously tested as a component, i.e they should have gone through unit tests.
==Steps to write good Integration Test Cases==
#Create a Test Plan
#Create test cases and the sample data against which they would be tested.
#If automated tools are being used, scripts should be created.
#After the components have been integrated, start executing the test cases created in point 2.
#Log the bugs found and rectify the same.
#Retest the code.

==How To write good Integration Test Cases and do effective Integration Testing==
The main focus of integration testing is that it needs to check whether the different components are working smoothly and are interacting with each other in the proper manner. The Integration test cases specifically focus on the flow of data/information/control from one component to the other.
A few thing that needs to be kept in mind for effective integration testing are
# Ensure that the correct versions of the components are integrated together.
# Automate the integration of components so that there is lesser chance for human error.
# Log all the errors that have been found and document them with the solutions as well as the version number so that we could keep track of which build was being tested when the error was discovered.

=Beyond Functional and Integration Testing=
[[Image:TestPhase.jpg|thumb|Test Phases]]
Integration and Functional testing are not the only testing that are done for checking the validity of the system. Other test cases includes: 
'''Unit Testing:''' This is the first stage where the developer tests the component he/she is creating. More can be found at [http://en.wikipedia.org/wiki/Unit_testing Unit Testing] 
'''Validation Testing:''' After integration Testing, validation testing takes place wherein checks are made to ensure that the functional requirements are satisfied. 
'''Alpha and Beta Testing:'''When the product about to be released, it is first exposed to some end users who test the application. This is alpha beta testing. More can be found at [http://www.majordojo.com/uploads/AlphaBetaTesting.pdf Alpha and Beta Testing] 
'''Recovery Testing:''' In this phase the system is made to crash and is used to check to see if it recovers in the proper manner. More can be found at [http://en.wikipedia.org/wiki/Recovery_testing Recovery Testing] 
'''Security Testing:''' Systems that store and record sensitive information need to be protected from threats, in this phase the systems protection mechanisms are tested. More can be found at [http://en.wikipedia.org/wiki/Security_testing Security Testing] 
'''Stress Testing:'''The system is overloaded with data and it is checked to whether it crashes. More can be found at [http://en.wikipedia.org/wiki/Stress_testing Stress Testing] 
'''Performance Testing:''' It tests the run time performance of software within the context of the system. More can be found at [http://en.wikipedia.org/wiki/Performance_testing Performance Testing] 
'''Smoke Testing:''' smoke testing is a preliminary to further testing, which should reveal simple failures severe enough to reject a prospective software release. More can be found at [http://en.wikipedia.org/wiki/Smoke_test Smoke Test] 
'''Acceptance Testing:''' acceptance testing performed by the customer is known as user acceptance testing (UAT). This is also known as end-user testing, site (acceptance) testing, or field (acceptance) testing. More can be found at [http://en.wikipedia.org/wiki/Acceptance_testing Acceptance Testing]

=References=

# [http://www.segue.com/pdf/automated_functional_testing.pdf Automated Functional Testing]
# [http://searchsoftwarequality.techtarget.com/generic/0,295582,sid92_gci1303938,00.html# Functional Tests to ensure Software Quality]
# [http://www.developer.com/tech/article.php/3623476/Functional-Test-Plans-The-Right-Way.htm Functional Test Plans]
# Software Engineering: A Practitioner's Approach by Roger S. Pressman ISBN 0073655783

=External Links=
# [http://math-cs.gordon.edu/courses/cs211/ATMExample/InitialFunctionalTests.html Initial Functional Test Cases for an ATM system]
# [http://en.wikipedia.org/wiki/Unit_testing Unit Testing]
# [http://www.majordojo.com/uploads/AlphaBetaTesting.pdf Alpha Beta Testing]
# [http://en.wikipedia.org/wiki/Recovery_testing Recovery Testing]
# [http://en.wikipedia.org/wiki/Security_testing Security Testing]
# [http://en.wikipedia.org/wiki/Stress_testing Stress Testing]
# [http://en.wikipedia.org/wiki/Performance_testing Performance Testing]
# [http://en.wikipedia.org/wiki/Smoke_test Smoke Test]
# [http://en.wikipedia.org/wiki/Acceptance_testing Acceptance Testing]

CSC/ECE 517 Fall 2009/wiki1b 4 mv

2009-09-28T22:44:06Z

Mjampal: /* Steps to write good Functional Tests */

=Introduction=
Unit Testing is given a lot of importance in Software Testing. But functional and integration testing are essential too. Hence Functional and Integration Testing is discussed here. This page provides an introduction to these testing methods; also including the good practices to write functional and integration tests. Later additional types of Software Tests are mentioned, which could be used to gain further confidence that one's code is correct.

=Functional Testing=
Functional testing is the process of testing of all the functions of a system, ensuring that the system conforms to the user requirements and specifications. It is sometimes referred to as black-box testing, as it does not require understanding of the internal structure of the implementation.

Functional testing can be done by using manual or automated methods[http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki1b_4_mv#References]. In both the methods, a series of tests have to be run marking the interaction between the user and the system, ensuring that the system performs as it was supposed to. Since Use cases mainly depict the interaction between the user and system, functional test suites are created from requirement use cases, with each scenario becoming a functional test[http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki1b_4_mv#References].

==Functional Test Plan==
"The functional test plan measures the quality of the functional components of the system[http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki1b_4_mv#References]". The test plan is written by the Author. The Author lists a number of test cases, containing the input, expected results, and pre and post-test setup. After a module is unit tested, the Tester executes the functional test cases and records the actual results. The Reviewer compares the Actual results with the expected results and reports whether each test case passed or failed the test.

==Guidelines to write good Functional Tests==
# The test plan must be written by persons who have extensive knowledge of the business requirements. It is advisable that the developers do not write the test plans. This is because developers tend to unknowingly write test cases whose functionality is based on the implementation rather than the initial functional specifications.
# The functional test plans should be created as early as possible, probably as soon as the functional specifications are ready.
# The functional test plan should be updated when there are changes in the business requirements.
# For each functionality, a list of test cases should be defined so that each aspect of the functionality is covered.
# The Author should clearly include the pre-test setup for the test cases so that the Tester can easily execute the test cases.
# Usually the same test cases are run a number of times. Hence after executing a test case, any data added to the system should be cleared so as to not affect further tests or rerunning of the same test case. Hence the Author should also give post-test setup details.
# As a module is built and unit tested, the Tester should execute the particular test cases and record the results.
# Reviewer should review the results and report any bugs to the developers.

==Examples==
Examples of pre-test setup, test cases and post-test setup are given below. The complete reference for the example can be found at [http://www.developer.com/java/ent/article.php/3623476/Functional-Test-Plans-The-Right-Way.htm Functional Test Plans]

The pre-test setup for Test Case: Create new user profile can be given as:
[UserName: "A": --> username: "A"]
[UserName: "A": --> first name: "John"]
[UserName: "A": --> last name: "Smith"]
[UserName: "A": --> access level: "read-only"]
[UserName: "A": --> password: "profile1"]

The test cases for the function:Verify that only valid users can access the system can be given as:

<table cellspacing="2" width=900 border="1" align="center" >
<tr valign="top" bgcolor="#99ffff">
<th>Test Case #</th>
<th>Required Input</th>
<th>Expected Results</th>
<th>Results</th>

<th>Pass/Fail</th></tr>

<tr valign="top"><td colspan="5">
<ul>
<li>Verify that only valid users can access the system.</li>
<li>Verify that valid users cannot access the system without entering a valid password.</li>
</ul></td></tr>

<tr valign="top"><td>1</td>
<td>Navigate to the login screen</td>
<td>Login screen with release number A is loaded.</td>

<td> </td>
<td> </td></tr>

<tr valign="top"><td>2</td>
<td>Enter user name "INVALIDUSER", password "INVALIDUSER", and click on login button</td>
<td>Error message: 
"User name is not found"</td>
<td> </td>
<td> </td></tr>

<tr valign="top"><td>3</td>
<td>Enter user name for user [UserName: "A":--> username] and password "test"</td>

<td>Error Message: 
"Password for user [UserName: "A": --> username] is invalid"</td>
<td> </td>
<td> </td></tr>

<tr valign="top"><td>4</td>
<td>Enter user name [UserName: "A": --> username] and password [UserName: "A": --> password]</td>

<td>The main page is loaded with a message: 
"Welcome [UserName: "A": --> first name] [UserName: "A": --> last name]</td>
<td> </td>
<td> </td></tr>
</table>

The post-test setup for the above scenario can be given as:
Remove [UserName: "A": --> username: "A"] from the LDAP Server.

Another Example of Test Cases can be found at [http://math-cs.gordon.edu/courses/cs211/ATMExample/InitialFunctionalTests.html Initial Functional Test Cases for an ATM system]

=Integration Testing=
Integration Testing is a process of testing the application on the whole. After going through the unit testing of the modules, these modules need to be integrated, and during this process things may go wrong, Integration process is the phase wherein these errors are captured and rectified.
It is very common for modules after having successful passed all the unit test cases to fail when they are integrated with other modules. Integration testing is an important phase and sometimes there are separate teams which handle integration testing.
 
DEFINITION:Integration testing is a systematic technique for constructing the program structure while at the same time conducting tests to uncover errors associated with interfacing. The objective is to take unit tested components
and build a program structure that has been dictated by design.[http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki1b_4_mv#References]

==Integration Test approaches==
Integration testing can be done in a variety of ways [[Image:TopDown_Approach.jpg|thumb|Top Down Approach]]
# '''Top-Down Approach.''' In this approach the modules higher up in the control hierarchy are integrated first and low-level modules are added later. The advantage of this approach is that the modules with high level logic are tested first and hence bugs in the crucial logic are caught early. Further this approach does not require drivers to be written. Although a number of stubs have to be written and managed
# '''Bottom Up Approach.''' In this approach, the low level modules are integrated first and high level logic is tested late. While integrating the low level modules, the control modules are replaced by dummy modules called as drivers. Thus driver codes have to be written and managed while using this approach. [[Image:BottomUp_Approach.jpg|thumb|Bottom Up Approach]]
# '''Umbrella approach.''' Another approach is called the umbrella approach. It is a hybrid of the top down and the botom up approach, ie both the bottom up and top down approaches are used.In this approach we first test along the functional and control flow paths, for this we use the bottom up approach. The results thus gathered are later integrated in a top down manner. This kind of testing allows creating early prototypes of the system with has limited functionality thereby helping is the creations of the product in an incremental manner. This types of testing also minimizes the use of stubs and drivers which are needed in the top-down and bottom up approaches.
==Prerequisites before Integration Testing==
The system that is being tested, all of its modules should be rigorously tested as a component, i.e they should have gone through unit tests.
==Steps to write good Integration Test Cases==
#Create a Test Plan
#Create test cases and the sample data against which they would be tested.
#If automated tools are being used, scripts should be created.
#After the components have been integrated, start executing the test cases created in point 2.
#Log the bugs found and rectify the same.
#Retest the code.

==How To write good Integration Test Cases and do effective Integration Testing==
The main focus of integration testing is that it needs to check whether the different components are working smoothly and are interacting with each other in the proper manner. The Integration test cases specifically focus on the flow of data/information/control from one component to the other.
A few thing that needs to be kept in mind for effective integration testing are
# Ensure that the correct versions of the components are integrated together.
# Automate the integration of components so that there is lesser chance for human error.
# Log all the errors that have been found and document them with the solutions as well as the version number so that we could keep track of which build was being tested when the error was discovered.

=Beyond Functional and Integration Testing=
[[Image:TestPhase.jpg|thumb|Test Phases]]
Integration and Functional testing are not the only testing that are done for checking the validity of the system. Other test cases includes: 
'''Unit Testing:''' This is the first stage where the developer tests the component he/she is creating. More can be found at [http://en.wikipedia.org/wiki/Unit_testing Unit Testing] 
'''Validation Testing:''' After integration Testing, validation testing takes place wherein checks are made to ensure that the functional requirements are satisfied. 
'''Alpha and Beta Testing:'''When the product about to be released, it is first exposed to some end users who test the application. This is alpha beta testing. More can be found at [http://www.majordojo.com/uploads/AlphaBetaTesting.pdf Alpha and Beta Testing] 
'''Recovery Testing:''' In this phase the system is made to crash and is used to check to see if it recovers in the proper manner. More can be found at [http://en.wikipedia.org/wiki/Recovery_testing Recovery Testing] 
'''Security Testing:''' Systems that store and record sensitive information need to be protected from threats, in this phase the systems protection mechanisms are tested. More can be found at [http://en.wikipedia.org/wiki/Security_testing Security Testing] 
'''Stress Testing:'''The system is overloaded with data and it is checked to whether it crashes. More can be found at [http://en.wikipedia.org/wiki/Stress_testing Stress Testing] 
'''Performance Testing:''' It tests the run time performance of software within the context of the system. More can be found at [http://en.wikipedia.org/wiki/Performance_testing Performance Testing] 
'''Smoke Testing:''' smoke testing is a preliminary to further testing, which should reveal simple failures severe enough to reject a prospective software release. More can be found at [http://en.wikipedia.org/wiki/Smoke_test Smoke Test] 
'''Acceptance Testing:''' acceptance testing performed by the customer is known as user acceptance testing (UAT). This is also known as end-user testing, site (acceptance) testing, or field (acceptance) testing. More can be found at [http://en.wikipedia.org/wiki/Acceptance_testing Acceptance Testing]

=References=

# [http://www.segue.com/pdf/automated_functional_testing.pdf Automated Functional Testing]
# [http://searchsoftwarequality.techtarget.com/generic/0,295582,sid92_gci1303938,00.html# Functional Tests to ensure Software Quality]
# [http://www.developer.com/tech/article.php/3623476/Functional-Test-Plans-The-Right-Way.htm Functional Test Plans]
# Software Engineering: A Practitioner's Approach by Roger S. Pressman ISBN 0073655783

=External Links=
# [http://math-cs.gordon.edu/courses/cs211/ATMExample/InitialFunctionalTests.html Initial Functional Test Cases for an ATM system]
# [http://en.wikipedia.org/wiki/Unit_testing Unit Testing]
# [http://www.majordojo.com/uploads/AlphaBetaTesting.pdf Alpha Beta Testing]
# [http://en.wikipedia.org/wiki/Recovery_testing Recovery Testing]
# [http://en.wikipedia.org/wiki/Security_testing Security Testing]
# [http://en.wikipedia.org/wiki/Stress_testing Stress Testing]
# [http://en.wikipedia.org/wiki/Performance_testing Performance Testing]
# [http://en.wikipedia.org/wiki/Smoke_test Smoke Test]
# [http://en.wikipedia.org/wiki/Acceptance_testing Acceptance Testing]

CSC/ECE 517 Fall 2009/wiki1b 4 mv

2009-09-24T18:47:10Z

Mjampal:

=Introduction=
Unit Testing is given a lot of importance in Software Testing. But functional and integration testing are essential too. Hence Functional and Integration Testing is discussed here. This page provides an introduction to these testing methods; also including the good practices to write functional and integration tests. Later additional types of Software Tests are mentioned, which could be used to gain further confidence that one's code is correct.

=Functional Testing=
Functional testing is the process of testing of all the functions of a system, ensuring that the system conforms to the user requirements and specifications. It is sometimes referred to as black-box testing, as it does not require understanding of the internal structure of the implementation.

Functional testing can be done by using manual or automated methods[http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki1b_4_mv#References]. In both the methods, a series of tests have to be run marking the interaction between the user and the system, ensuring that the system performs as it was supposed to. Since Use cases mainly depict the interaction between the user and system, functional test suites are created from requirement use cases, with each scenario becoming a functional test[http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki1b_4_mv#References].

==Functional Test Plan==
"The functional test plan measures the quality of the functional components of the system[http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki1b_4_mv#References]". The test plan is written by the Author. The Author lists a number of test cases, containing the input, expected results, and pre and post-test setup. After a module is unit tested, the Tester executes the functional test cases and records the actual results. The Reviewer compares the Actual results with the expected results and reports whether each test case passed or failed the test.

==Steps to write good Functional Tests==
# The test plan must be written by persons who have extensive knowledge of the business requirements. It is advisable that the developers do not write the test plans. This is because developers tend to unknowingly write test cases whose functionality is based on the implementation rather than the initial functional specifications.
# The functional test plans should be created as early as possible, probably as soon as the functional specifications are ready.
# The functional test plan should be updated when there are changes in the business requirements.
# For each functionality, a list of test cases should be defined so that each aspect of the functionality is covered.
# The Author should clearly include the pre-test setup for the test cases so that the Tester can easily execute the test cases.
# Usually the same test cases are run a number of times. Hence after executing a test case, any data added to the system should be cleared so as to not affect further tests or rerunning of the same test case. Hence the Author should also give post-test setup details.
# As a module is built and unit tested, the Tester should execute the particular test cases and record the results.
# Reviewer should review the results and report any bugs to the developers.

==Examples==
Examples of pre-test setup, test cases and post-test setup are given below. The complete reference for the example can be found at [http://www.developer.com/java/ent/article.php/3623476/Functional-Test-Plans-The-Right-Way.htm Functional Test Plans]

The pre-test setup for Test Case: Create new user profile can be given as:
[UserName: "A": --> username: "A"]
[UserName: "A": --> first name: "John"]
[UserName: "A": --> last name: "Smith"]
[UserName: "A": --> access level: "read-only"]
[UserName: "A": --> password: "profile1"]

The test cases for the function:Verify that only valid users can access the system can be given as:

<table cellspacing="2" width=900 border="1" align="center" >
<tr valign="top" bgcolor="#99ffff">
<th>Test Case #</th>
<th>Required Input</th>
<th>Expected Results</th>
<th>Results</th>

<th>Pass/Fail</th></tr>

<tr valign="top"><td colspan="5">
<ul>
<li>Verify that only valid users can access the system.</li>
<li>Verify that valid users cannot access the system without entering a valid password.</li>
</ul></td></tr>

<tr valign="top"><td>1</td>
<td>Navigate to the login screen</td>
<td>Login screen with release number A is loaded.</td>

<td> </td>
<td> </td></tr>

<tr valign="top"><td>2</td>
<td>Enter user name "INVALIDUSER", password "INVALIDUSER", and click on login button</td>
<td>Error message: 
"User name is not found"</td>
<td> </td>
<td> </td></tr>

<tr valign="top"><td>3</td>
<td>Enter user name for user [UserName: "A":--> username] and password "test"</td>

<td>Error Message: 
"Password for user [UserName: "A": --> username] is invalid"</td>
<td> </td>
<td> </td></tr>

<tr valign="top"><td>4</td>
<td>Enter user name [UserName: "A": --> username] and password [UserName: "A": --> password]</td>

<td>The main page is loaded with a message: 
"Welcome [UserName: "A": --> first name] [UserName: "A": --> last name]</td>
<td> </td>
<td> </td></tr>
</table>

The post-test setup for the above scenario can be given as:
Remove [UserName: "A": --> username: "A"] from the LDAP Server.

Another Example of Test Cases can be found at [http://math-cs.gordon.edu/courses/cs211/ATMExample/InitialFunctionalTests.html Initial Functional Test Cases for an ATM system]

=Integration Testing=
Integration Testing is a process of testing the application on the whole. After going through the unit testing of the modules, these modules need to be integrated, and during this process things may go wrong, Integration process is the phase wherein these errors are captured and rectified.
It is very common for modules after having successful passed all the unit test cases to fail when they are integrated with other modules. Integration testing is an important phase and sometimes there are separate teams which handle integration testing.
 
DEFINITION:Integration testing is a systematic technique for constructing the program structure while at the same time conducting tests to uncover errors associated with interfacing. The objective is to take unit tested components
and build a program structure that has been dictated by design.[http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki1b_4_mv#References]

==Integration Test approaches==
Integration testing can be done in a variety of ways [[Image:TopDown_Approach.jpg|thumb|Top Down Approach]]
# '''Top-Down Approach.''' In this approach the modules higher up in the control hierarchy are integrated first and low-level modules are added later. The advantage of this approach is that the modules with high level logic are tested first and hence bugs in the crucial logic are caught early. Further this approach does not require drivers to be written. Although a number of stubs have to be written and managed
# '''Bottom Up Approach.''' In this approach, the low level modules are integrated first and high level logic is tested late. While integrating the low level modules, the control modules are replaced by dummy modules called as drivers. Thus driver codes have to be written and managed while using this approach. [[Image:BottomUp_Approach.jpg|thumb|Bottom Up Approach]]
# '''Umbrella approach.''' Another approach is called the umbrella approach. It is a hybrid of the top down and the botom up approach, ie both the bottom up and top down approaches are used.In this approach we first test along the functional and control flow paths, for this we use the bottom up approach. The results thus gathered are later integrated in a top down manner. This kind of testing allows creating early prototypes of the system with has limited functionality thereby helping is the creations of the product in an incremental manner. This types of testing also minimizes the use of stubs and drivers which are needed in the top-down and bottom up approaches.
==Prerequisites before Integration Testing==
The system that is being tested, all of its modules should be rigorously tested as a component, i.e they should have gone through unit tests.
==Steps to write good Integration Test Cases==
#Create a Test Plan
#Create test cases and the sample data against which they would be tested.
#If automated tools are being used, scripts should be created.
#After the components have been integrated, start executing the test cases created in point 2.
#Log the bugs found and rectify the same.
#Retest the code.

==How To write good Integration Test Cases and do effective Integration Testing==
The main focus of integration testing is that it needs to check whether the different components are working smoothly and are interacting with each other in the proper manner. The Integration test cases specifically focus on the flow of data/information/control from one component to the other.
A few thing that needs to be kept in mind for effective integration testing are
# Ensure that the correct versions of the components are integrated together.
# Automate the integration of components so that there is lesser chance for human error.
# Log all the errors that have been found and document them with the solutions as well as the version number so that we could keep track of which build was being tested when the error was discovered.

=Beyond Functional and Integration Testing=
[[Image:TestPhase.jpg|thumb|Test Phases]]
Integration and Functional testing are not the only testing that are done for checking the validity of the system. Other test cases includes: 
'''Unit Testing:''' This is the first stage where the developer tests the component he/she is creating. More can be found at [http://en.wikipedia.org/wiki/Unit_testing Unit Testing] 
'''Validation Testing:''' After integration Testing, validation testing takes place wherein checks are made to ensure that the functional requirements are satisfied. 
'''Alpha and Beta Testing:'''When the product about to be released, it is first exposed to some end users who test the application. This is alpha beta testing. More can be found at [http://www.majordojo.com/uploads/AlphaBetaTesting.pdf Alpha and Beta Testing] 
'''Recovery Testing:''' In this phase the system is made to crash and is used to check to see if it recovers in the proper manner. More can be found at [http://en.wikipedia.org/wiki/Recovery_testing Recovery Testing] 
'''Security Testing:''' Systems that store and record sensitive information need to be protected from threats, in this phase the systems protection mechanisms are tested. More can be found at [http://en.wikipedia.org/wiki/Security_testing Security Testing] 
'''Stress Testing:'''The system is overloaded with data and it is checked to whether it crashes. More can be found at [http://en.wikipedia.org/wiki/Stress_testing Stress Testing] 
'''Performance Testing:''' It tests the run time performance of software within the context of the system. More can be found at [http://en.wikipedia.org/wiki/Performance_testing Performance Testing] 
'''Smoke Testing:''' smoke testing is a preliminary to further testing, which should reveal simple failures severe enough to reject a prospective software release. More can be found at [http://en.wikipedia.org/wiki/Smoke_test Smoke Test] 
'''Acceptance Testing:''' acceptance testing performed by the customer is known as user acceptance testing (UAT). This is also known as end-user testing, site (acceptance) testing, or field (acceptance) testing. More can be found at [http://en.wikipedia.org/wiki/Acceptance_testing Acceptance Testing]

=References=

# [http://www.segue.com/pdf/automated_functional_testing.pdf Automated Functional Testing]
# [http://searchsoftwarequality.techtarget.com/generic/0,295582,sid92_gci1303938,00.html# Functional Tests to ensure Software Quality]
# [http://www.developer.com/tech/article.php/3623476/Functional-Test-Plans-The-Right-Way.htm Functional Test Plans]
# Software Engineering: A Practitioner's Approach by Roger S. Pressman ISBN 0073655783

=External Links=
# [http://math-cs.gordon.edu/courses/cs211/ATMExample/InitialFunctionalTests.html Initial Functional Test Cases for an ATM system]
# [http://en.wikipedia.org/wiki/Unit_testing Unit Testing]
# [http://www.majordojo.com/uploads/AlphaBetaTesting.pdf Alpha Beta Testing]
# [http://en.wikipedia.org/wiki/Recovery_testing Recovery Testing]
# [http://en.wikipedia.org/wiki/Security_testing Security Testing]
# [http://en.wikipedia.org/wiki/Stress_testing Stress Testing]
# [http://en.wikipedia.org/wiki/Performance_testing Performance Testing]
# [http://en.wikipedia.org/wiki/Smoke_test Smoke Test]
# [http://en.wikipedia.org/wiki/Acceptance_testing Acceptance Testing]

CSC/ECE 517 Fall 2009/wiki1b 4 mv

2009-09-22T03:49:23Z

Mjampal: /* Steps to write good Functional Tests */

=Introduction=
Unit Testing is given a lot of importance in Software Testing. But functional and integration testing are essential too. Hence Functional and Integration Testing is discussed here. This page provides an introduction to these testing methods; also including the good practices to write functional and integration tests. Later additional types of Software Tests are mentioned, which could be used to gain further confidence that one's code is correct.

=Functional Testing=
Functional testing is the process of testing of all the functions of a system, ensuring that the system conforms to the user requirements and specifications. It is sometimes referred to as black-box testing, as it does not require understanding of the internal structure of the implementation.

Functional testing can be done by using manual or automated methods[http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki1b_4_mv#References]. In both the methods, a series of tests have to be run marking the interaction between the user and the system, ensuring that the system performs as it was supposed to. Since Use cases mainly depict the interaction between the user and system, functional test suites are created from requirement use cases, with each scenario becoming a functional test[http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki1b_4_mv#References].

==Functional Test Plan==
"The functional test plan measures the quality of the functional components of the system[http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki1b_4_mv#References]". The test plan is written by the Author. The Author lists a number of test cases, containing the input, expected results, and pre and post-test setup. After a module is unit tested, the Tester executes the functional test cases and records the actual results. The Reviewer compares the Actual results with the expected results and reports whether each test case passed or failed the test.

==Steps to write good Functional Tests==
# The test plan must be written by persons who have extensive knowledge of the business requirements. It is advisable that the developers do not write the test plans. This is because developers tend to unknowingly write test cases whose functionality is based on the implementation rather than the initial functional specifications.
# The functional test plans should be created as early as possible, probably as soon as the functional specifications are ready.
# The functional test plan should be updated when there are changes in the business requirements.
# For each functionality, a list of test cases should be defined so that each aspect of the functionality is covered.
# The Author should clearly include the pre-test setup for the test cases so that the Tester can easily execute the test cases.
# Usually the same test cases are run a number of times. Hence after executing a test case, any data added to the system should be cleared so as to not affect further tests or rerunning of the same test case. Hence the Author should also give post-test setup details.
# As a module is built and unit tested, the Tester should execute the particular test cases and record the results.
# Reviewer should review the results and report any bugs to the developers.

==Examples==
Examples of pre-test setup, test cases and post-test setup are given below. The complete reference for the example can be found at [http://www.developer.com/java/ent/article.php/3623476/Functional-Test-Plans-The-Right-Way.htm Functional Test Plans]

The pre-test setup for Test Case: Create new user profile can be given as:
[UserName: "A": --> username: "A"]
[UserName: "A": --> first name: "John"]
[UserName: "A": --> last name: "Smith"]
[UserName: "A": --> access level: "read-only"]
[UserName: "A": --> password: "profile1"]

The test cases for the function:Verify that only valid users can access the system can be given as:

<table cellspacing="2" width=900 border="1" align="center" >
<tr valign="top" bgcolor="#99ffff">
<th>Test Case #</th>
<th>Required Input</th>
<th>Expected Results</th>
<th>Results</th>

<th>Pass/Fail</th></tr>

<tr valign="top"><td colspan="5">
<ul>
<li>Verify that only valid users can access the system.</li>
<li>Verify that valid users cannot access the system without entering a valid password.</li>
</ul></td></tr>

<tr valign="top"><td>1</td>
<td>Navigate to the login screen</td>
<td>Login screen with release number A is loaded.</td>

<td> </td>
<td> </td></tr>

<tr valign="top"><td>2</td>
<td>Enter user name "INVALIDUSER", password "INVALIDUSER", and click on login button</td>
<td>Error message: 
"User name is not found"</td>
<td> </td>
<td> </td></tr>

<tr valign="top"><td>3</td>
<td>Enter user name for user [UserName: "A":--> username] and password "test"</td>

<td>Error Message: 
"Password for user [UserName: "A": --> username] is invalid"</td>
<td> </td>
<td> </td></tr>

<tr valign="top"><td>4</td>
<td>Enter user name [UserName: "A": --> username] and password [UserName: "A": --> password]</td>

<td>The main page is loaded with a message: 
"Welcome [UserName: "A": --> first name] [UserName: "A": --> last name]</td>
<td> </td>
<td> </td></tr>
</table>

The post-test setup for the above scenario can be given as:
Remove [UserName: "A": --> username: "A"] from the LDAP Server.

Another Example of Test Cases can be found at [http://math-cs.gordon.edu/courses/cs211/ATMExample/InitialFunctionalTests.html Initial Functional Test Cases for an ATM system]

=Integration Testing=
Integration Testing is a process of testing the application on the whole. After going through the unit testing of the modules, these modules need to be integrated, and during this process things may go wrong, Integration process is the phase wherein these errors are captured and rectified.
It is very common for modules after having successful passed all the unit test cases to fail when they are integrated with other modules. Integration testing is an important phase and sometimes there are separate teams which handle integration testing.
 
DEFINITION:Integration testing is a systematic technique for constructing the program structure while at the same time conducting tests to uncover errors associated with interfacing. The objective is to take unit tested components
and build a program structure that has been dictated by design.[http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki1b_4_mv#References]

==Integration Test approaches==
Integration testing can be done in a variety of ways [[Image:TopDown_Approach.jpg|thumb|Top Down Approach]]
# '''Top-Down Approach.''' In this approach the modules higher up in the control hierarchy are integrated first and low-level modules are added later. The advantage of this approach is that the modules with high level logic are tested first and hence bugs in the crucial logic are caught early. Further this approach does not require drivers to be written. Although a number of stubs have to be written and managed
# '''Bottom Up Approach.''' In this approach, the low level modules are integrated first and high level logic is tested late. While integrating the low level modules, the control modules are replaced by dummy modules called as drivers. Thus driver codes have to be written and managed while using this approach. [[Image:BottomUp_Approach.jpg|thumb|Bottom Up Approach]]
# '''Umbrella approach.''' Another approach is called the umbrella approach. It is a hybrid of the top down and the botom up approach, ie both the bottom up and top down approaches are used.In this approach we first test along the functional and control flow paths, for this we use the bottom up approach. The results thus gathered are later integrated in a top down manner. This kind of testing allows creating early prototypes of the system with has limited functionality thereby helping is the creations of the product in an incremental manner. This types of testing also minimizes the use of stubs and drivers which are needed in the top-down and bottom up approaches.
==Prerequisites before Integration Testing==
The system that is being tested, all of its modules should be rigorously tested as a component, i.e they should have gone through unit tests.
==Steps to write good Integration Test Cases==
#Create a Test Plan
#Create test cases and the sample data against which they would be tested.
#If automated tools are being used, scripts should be created.
#After the components have been integrated, start executing the test cases created in point 2.
#Log the bugs found and rectify the same.
#Retest the code.

==How To write good Integration Test Cases and do effective Integration Testing==
The main focus of integration testing is that it needs to check whether the different components are working smoothly and are interacting with each other in the proper manner. The Integration test cases specifically focus on the flow of data/information/control from one component to the other.
A few thing that needs to be kept in mind for effective integration testing are
# Ensure that the correct versions of the components are integrated together.
# Automate the integration of components so that there is lesser chance for human error.
# Log all the errors that have been found and document them with the solutions as well as the version number so that we could keep track of which build was being tested when the error was discovered.

=Beyond Functional and Integration Testing=
[[Image:TestPhase.jpg|thumb|Test Phases]]
Integration and Functional testing are not the only testing that are done for checking the validity of the system. Other test cases includes: 
'''Unit Testing:''' This is the first stage where the developer tests the component he/she is creating. More can be found at [http://en.wikipedia.org/wiki/Unit_testing Unit Testing] 
'''Validation Testing:''' After integration Testing, validation testing takes place wherein checks are made to ensure that the functional requirements are satisfied. 
'''Alpha and Beta Testing:'''When the product about to be released, it is first exposed to some end users who test the application. This is alpha beta testing. More can be found at [http://www.majordojo.com/uploads/AlphaBetaTesting.pdf Alpha and Beta Testing] 
'''Recovery Testing:''' In this phase the system is made to crash and is used to check to see if it recovers in the proper manner. More can be found at [http://en.wikipedia.org/wiki/Recovery_testing Recovery Testing] 
'''Security Testing:''' Systems that store and record sensitive information need to be protected from threats, in this phase the systems protection mechanisms are tested. More can be found at [http://en.wikipedia.org/wiki/Security_testing Security Testing] 
'''Stress Testing:'''The system is overloaded with data and it is checked to whether it crashes. More can be found at [http://en.wikipedia.org/wiki/Stress_testing Stress Testing] 
'''Performance Testing:''' It tests the run time performance of software within the context of the system. More can be found at [http://en.wikipedia.org/wiki/Performance_testing Performance Testing] 
'''Smoke Testing:''' smoke testing is a preliminary to further testing, which should reveal simple failures severe enough to reject a prospective software release. More can be found at [http://en.wikipedia.org/wiki/Smoke_test Smoke Test] 
'''Acceptance Testing:''' acceptance testing performed by the customer is known as user acceptance testing (UAT). This is also known as end-user testing, site (acceptance) testing, or field (acceptance) testing. More can be found at [http://en.wikipedia.org/wiki/Acceptance_testing Acceptance Testing]

=References=

# [http://www.segue.com/pdf/automated_functional_testing.pdf Automated Functional Testing]
# [http://searchsoftwarequality.techtarget.com/generic/0,295582,sid92_gci1303938,00.html# Functional Tests to ensure Software Quality]
# [http://www.developer.com/tech/article.php/3623476/Functional-Test-Plans-The-Right-Way.htm Functional Test Plans]
# Software Engineering: A Practitioner's Approach by Roger S. Pressman ISBN 0073655783

=External Links=
# [http://math-cs.gordon.edu/courses/cs211/ATMExample/InitialFunctionalTests.html Initial Functional Test Cases for an ATM system]
# [http://en.wikipedia.org/wiki/Unit_testing Unit Testing]
# [http://www.majordojo.com/uploads/AlphaBetaTesting.pdf Alpha Beta Testing]
# [http://en.wikipedia.org/wiki/Recovery_testing Recovery Testing]
# [http://en.wikipedia.org/wiki/Security_testing Security Testing]
# [http://en.wikipedia.org/wiki/Stress_testing Stress Testing]
# [http://en.wikipedia.org/wiki/Performance_testing Performance Testing]
# [http://en.wikipedia.org/wiki/Smoke_test Smoke Test]
# [http://en.wikipedia.org/wiki/Acceptance_testing Acceptance Testing]

CSC/ECE 517 Fall 2009/wiki1b 4 mv

2009-09-22T03:33:03Z

Mjampal: /* Steps to write good Functional Tests */

=Introduction=
Unit Testing is given a lot of importance in Software Testing. But functional and integration testing are essential too. Hence Functional and Integration Testing is discussed here. This page provides an introduction to these testing methods; also including the good practices to write functional and integration tests. Later additional types of Software Tests are mentioned, which could be used to gain further confidence that one's code is correct.

=Functional Testing=
Functional testing is the process of testing of all the functions of a system, ensuring that the system conforms to the user requirements and specifications. It is sometimes referred to as black-box testing, as it does not require understanding of the internal structure of the implementation.

Functional testing can be done by using manual or automated methods[http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki1b_4_mv#References]. In both the methods, a series of tests have to be run marking the interaction between the user and the system, ensuring that the system performs as it was supposed to. Since Use cases mainly depict the interaction between the user and system, functional test suites are created from requirement use cases, with each scenario becoming a functional test[http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki1b_4_mv#References].

==Functional Test Plan==
"The functional test plan measures the quality of the functional components of the system[http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki1b_4_mv#References]". The test plan is written by the Author. The Author lists a number of test cases, containing the input, expected results, and pre and post-test setup. After a module is unit tested, the Tester executes the functional test cases and records the actual results. The Reviewer compares the Actual results with the expected results and reports whether each test case passed or failed the test.

==Steps to write good Functional Tests==
# The test plan must be written by persons who have extensive knowledge of the business requirements. It is advisable that the developers do not write the test plans. This is because developers tend to unknowingly write test cases whose functionality is based on the implementation rather than the initial functional specifications.
# The functional test plans should be created as early as possible, probably as soon as the functional specifications are ready.
# The functional test plan should be updated when there are changes in the business requirements.
# For each functionality, a list of test cases should be defined so that each aspect of the functionality is covered.
# The Author should clearly include the pre-test setup for the test cases so that the Tester can easily execute the test cases.
# Usually the same test cases are run a number of times. Hence after executing a test case, any data added to the system should be cleared so as to not affect further tests or rerunning of the same test case. Hence the Author should also give post-test setup details.
# As a module is built and unit tested, the Tester should execute the particular test cases.

==Examples==
Examples of pre-test setup, test cases and post-test setup are given below. The complete reference for the example can be found at [http://www.developer.com/java/ent/article.php/3623476/Functional-Test-Plans-The-Right-Way.htm Functional Test Plans]

The pre-test setup for Test Case: Create new user profile can be given as:
[UserName: "A": --> username: "A"]
[UserName: "A": --> first name: "John"]
[UserName: "A": --> last name: "Smith"]
[UserName: "A": --> access level: "read-only"]
[UserName: "A": --> password: "profile1"]

The test cases for the function:Verify that only valid users can access the system can be given as:

<table cellspacing="2" width=900 border="1" align="center" >
<tr valign="top" bgcolor="#99ffff">
<th>Test Case #</th>
<th>Required Input</th>
<th>Expected Results</th>
<th>Results</th>

<th>Pass/Fail</th></tr>

<tr valign="top"><td colspan="5">
<ul>
<li>Verify that only valid users can access the system.</li>
<li>Verify that valid users cannot access the system without entering a valid password.</li>
</ul></td></tr>

<tr valign="top"><td>1</td>
<td>Navigate to the login screen</td>
<td>Login screen with release number A is loaded.</td>

<td> </td>
<td> </td></tr>

<tr valign="top"><td>2</td>
<td>Enter user name "INVALIDUSER", password "INVALIDUSER", and click on login button</td>
<td>Error message: 
"User name is not found"</td>
<td> </td>
<td> </td></tr>

<tr valign="top"><td>3</td>
<td>Enter user name for user [UserName: "A":--> username] and password "test"</td>

<td>Error Message: 
"Password for user [UserName: "A": --> username] is invalid"</td>
<td> </td>
<td> </td></tr>

<tr valign="top"><td>4</td>
<td>Enter user name [UserName: "A": --> username] and password [UserName: "A": --> password]</td>

<td>The main page is loaded with a message: 
"Welcome [UserName: "A": --> first name] [UserName: "A": --> last name]</td>
<td> </td>
<td> </td></tr>
</table>

The post-test setup for the above scenario can be given as:
Remove [UserName: "A": --> username: "A"] from the LDAP Server.

Another Example of Test Cases can be found at [http://math-cs.gordon.edu/courses/cs211/ATMExample/InitialFunctionalTests.html Initial Functional Test Cases for an ATM system]

=Integration Testing=
Integration Testing is a process of testing the application on the whole. After going through the unit testing of the modules, these modules need to be integrated, and during this process things may go wrong, Integration process is the phase wherein these errors are captured and rectified.
It is very common for modules after having successful passed all the unit test cases to fail when they are integrated with other modules. Integration testing is an important phase and sometimes there are separate teams which handle integration testing.
 
DEFINITION:Integration testing is a systematic technique for constructing the program structure while at the same time conducting tests to uncover errors associated with interfacing. The objective is to take unit tested components
and build a program structure that has been dictated by design.[http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki1b_4_mv#References]

==Integration Test approaches==
Integration testing can be done in a variety of ways [[Image:TopDown_Approach.jpg|thumb|Top Down Approach]]
# '''Top-Down Approach.''' In this approach the modules higher up in the control hierarchy are integrated first and low-level modules are added later. The advantage of this approach is that the modules with high level logic are tested first and hence bugs in the crucial logic are caught early. Further this approach does not require drivers to be written. Although a number of stubs have to be written and managed
# '''Bottom Up Approach.''' In this approach, the low level modules are integrated first and high level logic is tested late. While integrating the low level modules, the control modules are replaced by dummy modules called as drivers. Thus driver codes have to be written and managed while using this approach. [[Image:BottomUp_Approach.jpg|thumb|Bottom Up Approach]]
# '''Umbrella approach.''' Another approach is called the umbrella approach. It is a hybrid of the top down and the botom up approach, ie both the bottom up and top down approaches are used.In this approach we first test along the functional and control flow paths, for this we use the bottom up approach. The results thus gathered are later integrated in a top down manner. This kind of testing allows creating early prototypes of the system with has limited functionality thereby helping is the creations of the product in an incremental manner. This types of testing also minimizes the use of stubs and drivers which are needed in the top-down and bottom up approaches.
==Prerequisites before Integration Testing==
The system that is being tested, all of its modules should be rigorously tested as a component, i.e they should have gone through unit tests.
==Steps to write good Integration Test Cases==
#Create a Test Plan
#Create test cases and the sample data against which they would be tested.
#If automated tools are being used, scripts should be created.
#After the components have been integrated, start executing the test cases created in point 2.
#Log the bugs found and rectify the same.
#Retest the code.

==How To write good Integration Test Cases and do effective Integration Testing==
The main focus of integration testing is that it needs to check whether the different components are working smoothly and are interacting with each other in the proper manner. The Integration test cases specifically focus on the flow of data/information/control from one component to the other.
A few thing that needs to be kept in mind for effective integration testing are
# Ensure that the correct versions of the components are integrated together.
# Automate the integration of components so that there is lesser chance for human error.
# Log all the errors that have been found and document them with the solutions as well as the version number so that we could keep track of which build was being tested when the error was discovered.

=Beyond Functional and Integration Testing=
[[Image:TestPhase.jpg|thumb|Test Phases]]
Integration and Functional testing are not the only testing that are done for checking the validity of the system. Other test cases includes: 
'''Unit Testing:''' This is the first stage where the developer tests the component he/she is creating. More can be found at [http://en.wikipedia.org/wiki/Unit_testing Unit Testing] 
'''Validation Testing:''' After integration Testing, validation testing takes place wherein checks are made to ensure that the functional requirements are satisfied. 
'''Alpha and Beta Testing:'''When the product about to be released, it is first exposed to some end users who test the application. This is alpha beta testing. More can be found at [http://www.majordojo.com/uploads/AlphaBetaTesting.pdf Alpha and Beta Testing] 
'''Recovery Testing:''' In this phase the system is made to crash and is used to check to see if it recovers in the proper manner. More can be found at [http://en.wikipedia.org/wiki/Recovery_testing Recovery Testing] 
'''Security Testing:''' Systems that store and record sensitive information need to be protected from threats, in this phase the systems protection mechanisms are tested. More can be found at [http://en.wikipedia.org/wiki/Security_testing Security Testing] 
'''Stress Testing:'''The system is overloaded with data and it is checked to whether it crashes. More can be found at [http://en.wikipedia.org/wiki/Stress_testing Stress Testing] 
'''Performance Testing:''' It tests the run time performance of software within the context of the system. More can be found at [http://en.wikipedia.org/wiki/Performance_testing Performance Testing] 
'''Smoke Testing:''' smoke testing is a preliminary to further testing, which should reveal simple failures severe enough to reject a prospective software release. More can be found at [http://en.wikipedia.org/wiki/Smoke_test Smoke Test] 
'''Acceptance Testing:''' acceptance testing performed by the customer is known as user acceptance testing (UAT). This is also known as end-user testing, site (acceptance) testing, or field (acceptance) testing. More can be found at [http://en.wikipedia.org/wiki/Acceptance_testing Acceptance Testing]

=References=

# [http://www.segue.com/pdf/automated_functional_testing.pdf Automated Functional Testing]
# [http://searchsoftwarequality.techtarget.com/generic/0,295582,sid92_gci1303938,00.html# Functional Tests to ensure Software Quality]
# [http://www.developer.com/tech/article.php/3623476/Functional-Test-Plans-The-Right-Way.htm Functional Test Plans]
# Software Engineering: A Practitioner's Approach by Roger S. Pressman ISBN 0073655783

=External Links=
# [http://math-cs.gordon.edu/courses/cs211/ATMExample/InitialFunctionalTests.html Initial Functional Test Cases for an ATM system]
# [http://en.wikipedia.org/wiki/Unit_testing Unit Testing]
# [http://www.majordojo.com/uploads/AlphaBetaTesting.pdf Alpha Beta Testing]
# [http://en.wikipedia.org/wiki/Recovery_testing Recovery Testing]
# [http://en.wikipedia.org/wiki/Security_testing Security Testing]
# [http://en.wikipedia.org/wiki/Stress_testing Stress Testing]
# [http://en.wikipedia.org/wiki/Performance_testing Performance Testing]
# [http://en.wikipedia.org/wiki/Smoke_test Smoke Test]
# [http://en.wikipedia.org/wiki/Acceptance_testing Acceptance Testing]

CSC/ECE 517 Fall 2009/wiki1b 4 mv

2009-09-22T03:32:20Z

Mjampal: /* Steps to write good Functional Tests */

=Introduction=
Unit Testing is given a lot of importance in Software Testing. But functional and integration testing are essential too. Hence Functional and Integration Testing is discussed here. This page provides an introduction to these testing methods; also including the good practices to write functional and integration tests. Later additional types of Software Tests are mentioned, which could be used to gain further confidence that one's code is correct.

=Functional Testing=
Functional testing is the process of testing of all the functions of a system, ensuring that the system conforms to the user requirements and specifications. It is sometimes referred to as black-box testing, as it does not require understanding of the internal structure of the implementation.

Functional testing can be done by using manual or automated methods[http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki1b_4_mv#References]. In both the methods, a series of tests have to be run marking the interaction between the user and the system, ensuring that the system performs as it was supposed to. Since Use cases mainly depict the interaction between the user and system, functional test suites are created from requirement use cases, with each scenario becoming a functional test[http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki1b_4_mv#References].

==Functional Test Plan==
"The functional test plan measures the quality of the functional components of the system[http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki1b_4_mv#References]". The test plan is written by the Author. The Author lists a number of test cases, containing the input, expected results, and pre and post-test setup. After a module is unit tested, the Tester executes the functional test cases and records the actual results. The Reviewer compares the Actual results with the expected results and reports whether each test case passed or failed the test.

==Steps to write good Functional Tests==
# The test plan must be written by persons who have extensive knowledge of the business requirements. It is advisable that the developers do not write the test plans. This is because developers tend to unknowingly write test cases whose functionality is based on the implementation rather than the initial functional specifications.
# The functional test plans should be created as early as possible, probably as soon as the functional specifications are ready.
# The functional test plan should be updated when there are changes in the business requirements.
# For each functionality, a list of test cases should be defined so that each aspect of the functionality is covered.
# The Author should clearly include the pre-test setup for the test cases so that the Tester can easily execute the test cases.
# Usually the same test cases are run a number of times. Hence after executing a test case, any data added to the system should be cleared so as to not affect further tests or rerunning of the same test case. Hence the Author should also give post-test setup details.
# As a module is built and unit tested, the Tester should execute the particular test cases.

==Examples==
Examples of pre-test setup, test cases and post-test setup are given below. The complete reference for the example can be found at [http://www.developer.com/java/ent/article.php/3623476/Functional-Test-Plans-The-Right-Way.htm Functional Test Plans]

The pre-test setup for Test Case: Create new user profile can be given as:
[UserName: "A": --> username: "A"]
[UserName: "A": --> first name: "John"]
[UserName: "A": --> last name: "Smith"]
[UserName: "A": --> access level: "read-only"]
[UserName: "A": --> password: "profile1"]

The test cases for the function:Verify that only valid users can access the system can be given as:

<table cellspacing="2" width=900 border="1" align="center" >
<tr valign="top" bgcolor="#99ffff">
<th>Test Case #</th>
<th>Required Input</th>
<th>Expected Results</th>
<th>Results</th>

<th>Pass/Fail</th></tr>

<tr valign="top"><td colspan="5">
<ul>
<li>Verify that only valid users can access the system.</li>
<li>Verify that valid users cannot access the system without entering a valid password.</li>
</ul></td></tr>

<tr valign="top"><td>1</td>
<td>Navigate to the login screen</td>
<td>Login screen with release number A is loaded.</td>

<td> </td>
<td> </td></tr>

<tr valign="top"><td>2</td>
<td>Enter user name "INVALIDUSER", password "INVALIDUSER", and click on login button</td>
<td>Error message: 
"User name is not found"</td>
<td> </td>
<td> </td></tr>

<tr valign="top"><td>3</td>
<td>Enter user name for user [UserName: "A":--> username] and password "test"</td>

<td>Error Message: 
"Password for user [UserName: "A": --> username] is invalid"</td>
<td> </td>
<td> </td></tr>

<tr valign="top"><td>4</td>
<td>Enter user name [UserName: "A": --> username] and password [UserName: "A": --> password]</td>

<td>The main page is loaded with a message: 
"Welcome [UserName: "A": --> first name] [UserName: "A": --> last name]</td>
<td> </td>
<td> </td></tr>
</table>

The post-test setup for the above scenario can be given as:
Remove [UserName: "A": --> username: "A"] from the LDAP Server.

Another Example of Test Cases can be found at [http://math-cs.gordon.edu/courses/cs211/ATMExample/InitialFunctionalTests.html Initial Functional Test Cases for an ATM system]

=Integration Testing=
Integration Testing is a process of testing the application on the whole. After going through the unit testing of the modules, these modules need to be integrated, and during this process things may go wrong, Integration process is the phase wherein these errors are captured and rectified.
It is very common for modules after having successful passed all the unit test cases to fail when they are integrated with other modules. Integration testing is an important phase and sometimes there are separate teams which handle integration testing.
 
DEFINITION:Integration testing is a systematic technique for constructing the program structure while at the same time conducting tests to uncover errors associated with interfacing. The objective is to take unit tested components
and build a program structure that has been dictated by design.[http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki1b_4_mv#References]

==Integration Test approaches==
Integration testing can be done in a variety of ways [[Image:TopDown_Approach.jpg|thumb|Top Down Approach]]
# '''Top-Down Approach.''' In this approach the modules higher up in the control hierarchy are integrated first and low-level modules are added later. The advantage of this approach is that the modules with high level logic are tested first and hence bugs in the crucial logic are caught early. Further this approach does not require drivers to be written. Although a number of stubs have to be written and managed
# '''Bottom Up Approach.''' In this approach, the low level modules are integrated first and high level logic is tested late. While integrating the low level modules, the control modules are replaced by dummy modules called as drivers. Thus driver codes have to be written and managed while using this approach. [[Image:BottomUp_Approach.jpg|thumb|Bottom Up Approach]]
# '''Umbrella approach.''' Another approach is called the umbrella approach. It is a hybrid of the top down and the botom up approach, ie both the bottom up and top down approaches are used.In this approach we first test along the functional and control flow paths, for this we use the bottom up approach. The results thus gathered are later integrated in a top down manner. This kind of testing allows creating early prototypes of the system with has limited functionality thereby helping is the creations of the product in an incremental manner. This types of testing also minimizes the use of stubs and drivers which are needed in the top-down and bottom up approaches.
==Prerequisites before Integration Testing==
The system that is being tested, all of its modules should be rigorously tested as a component, i.e they should have gone through unit tests.
==Steps to write good Integration Test Cases==
#Create a Test Plan
#Create test cases and the sample data against which they would be tested.
#If automated tools are being used, scripts should be created.
#After the components have been integrated, start executing the test cases created in point 2.
#Log the bugs found and rectify the same.
#Retest the code.

==How To write good Integration Test Cases and do effective Integration Testing==
The main focus of integration testing is that it needs to check whether the different components are working smoothly and are interacting with each other in the proper manner. The Integration test cases specifically focus on the flow of data/information/control from one component to the other.
A few thing that needs to be kept in mind for effective integration testing are
# Ensure that the correct versions of the components are integrated together.
# Automate the integration of components so that there is lesser chance for human error.
# Log all the errors that have been found and document them with the solutions as well as the version number so that we could keep track of which build was being tested when the error was discovered.

=Beyond Functional and Integration Testing=
[[Image:TestPhase.jpg|thumb|Test Phases]]
Integration and Functional testing are not the only testing that are done for checking the validity of the system. Other test cases includes: 
'''Unit Testing:''' This is the first stage where the developer tests the component he/she is creating. More can be found at [http://en.wikipedia.org/wiki/Unit_testing Unit Testing] 
'''Validation Testing:''' After integration Testing, validation testing takes place wherein checks are made to ensure that the functional requirements are satisfied. 
'''Alpha and Beta Testing:'''When the product about to be released, it is first exposed to some end users who test the application. This is alpha beta testing. More can be found at [http://www.majordojo.com/uploads/AlphaBetaTesting.pdf Alpha and Beta Testing] 
'''Recovery Testing:''' In this phase the system is made to crash and is used to check to see if it recovers in the proper manner. More can be found at [http://en.wikipedia.org/wiki/Recovery_testing Recovery Testing] 
'''Security Testing:''' Systems that store and record sensitive information need to be protected from threats, in this phase the systems protection mechanisms are tested. More can be found at [http://en.wikipedia.org/wiki/Security_testing Security Testing] 
'''Stress Testing:'''The system is overloaded with data and it is checked to whether it crashes. More can be found at [http://en.wikipedia.org/wiki/Stress_testing Stress Testing] 
'''Performance Testing:''' It tests the run time performance of software within the context of the system. More can be found at [http://en.wikipedia.org/wiki/Performance_testing Performance Testing] 
'''Smoke Testing:''' smoke testing is a preliminary to further testing, which should reveal simple failures severe enough to reject a prospective software release. More can be found at [http://en.wikipedia.org/wiki/Smoke_test Smoke Test] 
'''Acceptance Testing:''' acceptance testing performed by the customer is known as user acceptance testing (UAT). This is also known as end-user testing, site (acceptance) testing, or field (acceptance) testing. More can be found at [http://en.wikipedia.org/wiki/Acceptance_testing Acceptance Testing]

=References=

# [http://www.segue.com/pdf/automated_functional_testing.pdf Automated Functional Testing]
# [http://searchsoftwarequality.techtarget.com/generic/0,295582,sid92_gci1303938,00.html# Functional Tests to ensure Software Quality]
# [http://www.developer.com/tech/article.php/3623476/Functional-Test-Plans-The-Right-Way.htm Functional Test Plans]
# Software Engineering: A Practitioner's Approach by Roger S. Pressman ISBN 0073655783

=External Links=
# [http://math-cs.gordon.edu/courses/cs211/ATMExample/InitialFunctionalTests.html Initial Functional Test Cases for an ATM system]
# [http://en.wikipedia.org/wiki/Unit_testing Unit Testing]
# [http://www.majordojo.com/uploads/AlphaBetaTesting.pdf Alpha Beta Testing]
# [http://en.wikipedia.org/wiki/Recovery_testing Recovery Testing]
# [http://en.wikipedia.org/wiki/Security_testing Security Testing]
# [http://en.wikipedia.org/wiki/Stress_testing Stress Testing]
# [http://en.wikipedia.org/wiki/Performance_testing Performance Testing]
# [http://en.wikipedia.org/wiki/Smoke_test Smoke Test]
# [http://en.wikipedia.org/wiki/Acceptance_testing Acceptance Testing]

CSC/ECE 517 Fall 2009/wiki1b 4 mv

2009-09-22T03:29:58Z

Mjampal: /* Functional Testing */

=Introduction=
Unit Testing is given a lot of importance in Software Testing. But functional and integration testing are essential too. Hence Functional and Integration Testing is discussed here. This page provides an introduction to these testing methods; also including the good practices to write functional and integration tests. Later additional types of Software Tests are mentioned, which could be used to gain further confidence that one's code is correct.

=Functional Testing=
Functional testing is the process of testing of all the functions of a system, ensuring that the system conforms to the user requirements and specifications. It is sometimes referred to as black-box testing, as it does not require understanding of the internal structure of the implementation.

Functional testing can be done by using manual or automated methods[http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki1b_4_mv#References]. In both the methods, a series of tests have to be run marking the interaction between the user and the system, ensuring that the system performs as it was supposed to. Since Use cases mainly depict the interaction between the user and system, functional test suites are created from requirement use cases, with each scenario becoming a functional test[http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki1b_4_mv#References].

==Functional Test Plan==
"The functional test plan measures the quality of the functional components of the system[http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki1b_4_mv#References]". The test plan is written by the Author. The Author lists a number of test cases, containing the input, expected results, and pre and post-test setup. After a module is unit tested, the Tester executes the functional test cases and records the actual results. The Reviewer compares the Actual results with the expected results and reports whether each test case passed or failed the test.

==Steps to write good Functional Tests==
# The test plan must be written by persons who have extensive knowledge of the business requirements. It is advisable that the developers do not write the test plans. This is because developers tend to unknowingly write test cases whose functionality is based on the implementation rather than the initial functional specifications.
# The functional test plans should be created as early as possible, probably as soon as the functional specifications are ready.
# The functional test plan should be updated when there are changes in the business requirements.
# For each functionality, a list of test cases should be defined so that each aspect of the functionality is covered.
# The Author should clearly include the pre-test setup for the test cases so that the Tester can easily execute the test cases.
# Usually the same test cases are run a number of times. Hence after executing a test case, any data added to the system should be cleared as as to not effect further tests or rerunning of the same test case. Hence the Author should also give post-test setup details.
# As a module is built and unit tested, the Tester should execute the particular test cases.

==Examples==
Examples of pre-test setup, test cases and post-test setup are given below. The complete reference for the example can be found at [http://www.developer.com/java/ent/article.php/3623476/Functional-Test-Plans-The-Right-Way.htm Functional Test Plans]

The pre-test setup for Test Case: Create new user profile can be given as:
[UserName: "A": --> username: "A"]
[UserName: "A": --> first name: "John"]
[UserName: "A": --> last name: "Smith"]
[UserName: "A": --> access level: "read-only"]
[UserName: "A": --> password: "profile1"]

The test cases for the function:Verify that only valid users can access the system can be given as:

<table cellspacing="2" width=900 border="1" align="center" >
<tr valign="top" bgcolor="#99ffff">
<th>Test Case #</th>
<th>Required Input</th>
<th>Expected Results</th>
<th>Results</th>

<th>Pass/Fail</th></tr>

<tr valign="top"><td colspan="5">
<ul>
<li>Verify that only valid users can access the system.</li>
<li>Verify that valid users cannot access the system without entering a valid password.</li>
</ul></td></tr>

<tr valign="top"><td>1</td>
<td>Navigate to the login screen</td>
<td>Login screen with release number A is loaded.</td>

<td> </td>
<td> </td></tr>

<tr valign="top"><td>2</td>
<td>Enter user name "INVALIDUSER", password "INVALIDUSER", and click on login button</td>
<td>Error message: 
"User name is not found"</td>
<td> </td>
<td> </td></tr>

<tr valign="top"><td>3</td>
<td>Enter user name for user [UserName: "A":--> username] and password "test"</td>

<td>Error Message: 
"Password for user [UserName: "A": --> username] is invalid"</td>
<td> </td>
<td> </td></tr>

<tr valign="top"><td>4</td>
<td>Enter user name [UserName: "A": --> username] and password [UserName: "A": --> password]</td>

<td>The main page is loaded with a message: 
"Welcome [UserName: "A": --> first name] [UserName: "A": --> last name]</td>
<td> </td>
<td> </td></tr>
</table>

The post-test setup for the above scenario can be given as:
Remove [UserName: "A": --> username: "A"] from the LDAP Server.

Another Example of Test Cases can be found at [http://math-cs.gordon.edu/courses/cs211/ATMExample/InitialFunctionalTests.html Initial Functional Test Cases for an ATM system]

=Integration Testing=
Integration Testing is a process of testing the application on the whole. After going through the unit testing of the modules, these modules need to be integrated, and during this process things may go wrong, Integration process is the phase wherein these errors are captured and rectified.
It is very common for modules after having successful passed all the unit test cases to fail when they are integrated with other modules. Integration testing is an important phase and sometimes there are separate teams which handle integration testing.
 
DEFINITION:Integration testing is a systematic technique for constructing the program structure while at the same time conducting tests to uncover errors associated with interfacing. The objective is to take unit tested components
and build a program structure that has been dictated by design.[http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki1b_4_mv#References]

==Integration Test approaches==
Integration testing can be done in a variety of ways [[Image:TopDown_Approach.jpg|thumb|Top Down Approach]]
# '''Top-Down Approach.''' In this approach the modules higher up in the control hierarchy are integrated first and low-level modules are added later. The advantage of this approach is that the modules with high level logic are tested first and hence bugs in the crucial logic are caught early. Further this approach does not require drivers to be written. Although a number of stubs have to be written and managed
# '''Bottom Up Approach.''' In this approach, the low level modules are integrated first and high level logic is tested late. While integrating the low level modules, the control modules are replaced by dummy modules called as drivers. Thus driver codes have to be written and managed while using this approach. [[Image:BottomUp_Approach.jpg|thumb|Bottom Up Approach]]
# '''Umbrella approach.''' Another approach is called the umbrella approach. It is a hybrid of the top down and the botom up approach, ie both the bottom up and top down approaches are used.In this approach we first test along the functional and control flow paths, for this we use the bottom up approach. The results thus gathered are later integrated in a top down manner. This kind of testing allows creating early prototypes of the system with has limited functionality thereby helping is the creations of the product in an incremental manner. This types of testing also minimizes the use of stubs and drivers which are needed in the top-down and bottom up approaches.
==Prerequisites before Integration Testing==
The system that is being tested, all of its modules should be rigorously tested as a component, i.e they should have gone through unit tests.
==Steps to write good Integration Test Cases==
#Create a Test Plan
#Create test cases and the sample data against which they would be tested.
#If automated tools are being used, scripts should be created.
#After the components have been integrated, start executing the test cases created in point 2.
#Log the bugs found and rectify the same.
#Retest the code.

==How To write good Integration Test Cases and do effective Integration Testing==
The main focus of integration testing is that it needs to check whether the different components are working smoothly and are interacting with each other in the proper manner. The Integration test cases specifically focus on the flow of data/information/control from one component to the other.
A few thing that needs to be kept in mind for effective integration testing are
# Ensure that the correct versions of the components are integrated together.
# Automate the integration of components so that there is lesser chance for human error.
# Log all the errors that have been found and document them with the solutions as well as the version number so that we could keep track of which build was being tested when the error was discovered.

=Beyond Functional and Integration Testing=
[[Image:TestPhase.jpg|thumb|Test Phases]]
Integration and Functional testing are not the only testing that are done for checking the validity of the system. Other test cases includes: 
'''Unit Testing:''' This is the first stage where the developer tests the component he/she is creating. More can be found at [http://en.wikipedia.org/wiki/Unit_testing Unit Testing] 
'''Validation Testing:''' After integration Testing, validation testing takes place wherein checks are made to ensure that the functional requirements are satisfied. 
'''Alpha and Beta Testing:'''When the product about to be released, it is first exposed to some end users who test the application. This is alpha beta testing. More can be found at [http://www.majordojo.com/uploads/AlphaBetaTesting.pdf Alpha and Beta Testing] 
'''Recovery Testing:''' In this phase the system is made to crash and is used to check to see if it recovers in the proper manner. More can be found at [http://en.wikipedia.org/wiki/Recovery_testing Recovery Testing] 
'''Security Testing:''' Systems that store and record sensitive information need to be protected from threats, in this phase the systems protection mechanisms are tested. More can be found at [http://en.wikipedia.org/wiki/Security_testing Security Testing] 
'''Stress Testing:'''The system is overloaded with data and it is checked to whether it crashes. More can be found at [http://en.wikipedia.org/wiki/Stress_testing Stress Testing] 
'''Performance Testing:''' It tests the run time performance of software within the context of the system. More can be found at [http://en.wikipedia.org/wiki/Performance_testing Performance Testing] 
'''Smoke Testing:''' smoke testing is a preliminary to further testing, which should reveal simple failures severe enough to reject a prospective software release. More can be found at [http://en.wikipedia.org/wiki/Smoke_test Smoke Test] 
'''Acceptance Testing:''' acceptance testing performed by the customer is known as user acceptance testing (UAT). This is also known as end-user testing, site (acceptance) testing, or field (acceptance) testing. More can be found at [http://en.wikipedia.org/wiki/Acceptance_testing Acceptance Testing]

=References=

# [http://www.segue.com/pdf/automated_functional_testing.pdf Automated Functional Testing]
# [http://searchsoftwarequality.techtarget.com/generic/0,295582,sid92_gci1303938,00.html# Functional Tests to ensure Software Quality]
# [http://www.developer.com/tech/article.php/3623476/Functional-Test-Plans-The-Right-Way.htm Functional Test Plans]
# Software Engineering: A Practitioner's Approach by Roger S. Pressman ISBN 0073655783

=External Links=
# [http://math-cs.gordon.edu/courses/cs211/ATMExample/InitialFunctionalTests.html Initial Functional Test Cases for an ATM system]
# [http://en.wikipedia.org/wiki/Unit_testing Unit Testing]
# [http://www.majordojo.com/uploads/AlphaBetaTesting.pdf Alpha Beta Testing]
# [http://en.wikipedia.org/wiki/Recovery_testing Recovery Testing]
# [http://en.wikipedia.org/wiki/Security_testing Security Testing]
# [http://en.wikipedia.org/wiki/Stress_testing Stress Testing]
# [http://en.wikipedia.org/wiki/Performance_testing Performance Testing]
# [http://en.wikipedia.org/wiki/Smoke_test Smoke Test]
# [http://en.wikipedia.org/wiki/Acceptance_testing Acceptance Testing]

CSC/ECE 517 Fall 2009/wiki1b 4 mv

2009-09-22T03:29:38Z

Mjampal: /* Introduction */

=Introduction=
Unit Testing is given a lot of importance in Software Testing. But functional and integration testing are essential too. Hence Functional and Integration Testing is discussed here. This page provides an introduction to these testing methods; also including the good practices to write functional and integration tests. Later additional types of Software Tests are mentioned, which could be used to gain further confidence that one's code is correct.

=Functional Testing=
Functional testing is the process of testing of all the functions of a system, ensuring that the system conforms to the user requirements and specifications. It is sometimes referred to as [[Black-box testing]], as it does not require understanding of the internal structure of the implementation.

Functional testing can be done by using manual or automated methods[http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki1b_4_mv#References]. In both the methods, a series of tests have to be run marking the interaction between the user and the system, ensuring that the system performs as it was supposed to. Since Use cases mainly depict the interaction between the user and system, functional test suites are created from requirement use cases, with each scenario becoming a functional test[http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki1b_4_mv#References].

==Functional Test Plan==
"The functional test plan measures the quality of the functional components of the system[http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki1b_4_mv#References]". The test plan is written by the Author. The Author lists a number of test cases, containing the input, expected results, and pre and post-test setup. After a module is unit tested, the Tester executes the functional test cases and records the actual results. The Reviewer compares the Actual results with the expected results and reports whether each test case passed or failed the test.

==Steps to write good Functional Tests==
# The test plan must be written by persons who have extensive knowledge of the business requirements. It is advisable that the developers do not write the test plans. This is because developers tend to unknowingly write test cases whose functionality is based on the implementation rather than the initial functional specifications.
# The functional test plans should be created as early as possible, probably as soon as the functional specifications are ready.
# The functional test plan should be updated when there are changes in the business requirements.
# For each functionality, a list of test cases should be defined so that each aspect of the functionality is covered.
# The Author should clearly include the pre-test setup for the test cases so that the Tester can easily execute the test cases.
# Usually the same test cases are run a number of times. Hence after executing a test case, any data added to the system should be cleared as as to not effect further tests or rerunning of the same test case. Hence the Author should also give post-test setup details.
# As a module is built and unit tested, the Tester should execute the particular test cases.

==Examples==
Examples of pre-test setup, test cases and post-test setup are given below. The complete reference for the example can be found at [http://www.developer.com/java/ent/article.php/3623476/Functional-Test-Plans-The-Right-Way.htm Functional Test Plans]

The pre-test setup for Test Case: Create new user profile can be given as:
[UserName: "A": --> username: "A"]
[UserName: "A": --> first name: "John"]
[UserName: "A": --> last name: "Smith"]
[UserName: "A": --> access level: "read-only"]
[UserName: "A": --> password: "profile1"]

The test cases for the function:Verify that only valid users can access the system can be given as:

<table cellspacing="2" width=900 border="1" align="center" >
<tr valign="top" bgcolor="#99ffff">
<th>Test Case #</th>
<th>Required Input</th>
<th>Expected Results</th>
<th>Results</th>

<th>Pass/Fail</th></tr>

<tr valign="top"><td colspan="5">
<ul>
<li>Verify that only valid users can access the system.</li>
<li>Verify that valid users cannot access the system without entering a valid password.</li>
</ul></td></tr>

<tr valign="top"><td>1</td>
<td>Navigate to the login screen</td>
<td>Login screen with release number A is loaded.</td>

<td> </td>
<td> </td></tr>

<tr valign="top"><td>2</td>
<td>Enter user name "INVALIDUSER", password "INVALIDUSER", and click on login button</td>
<td>Error message: 
"User name is not found"</td>
<td> </td>
<td> </td></tr>

<tr valign="top"><td>3</td>
<td>Enter user name for user [UserName: "A":--> username] and password "test"</td>

<td>Error Message: 
"Password for user [UserName: "A": --> username] is invalid"</td>
<td> </td>
<td> </td></tr>

<tr valign="top"><td>4</td>
<td>Enter user name [UserName: "A": --> username] and password [UserName: "A": --> password]</td>

<td>The main page is loaded with a message: 
"Welcome [UserName: "A": --> first name] [UserName: "A": --> last name]</td>
<td> </td>
<td> </td></tr>
</table>

The post-test setup for the above scenario can be given as:
Remove [UserName: "A": --> username: "A"] from the LDAP Server.

Another Example of Test Cases can be found at [http://math-cs.gordon.edu/courses/cs211/ATMExample/InitialFunctionalTests.html Initial Functional Test Cases for an ATM system]

=Integration Testing=
Integration Testing is a process of testing the application on the whole. After going through the unit testing of the modules, these modules need to be integrated, and during this process things may go wrong, Integration process is the phase wherein these errors are captured and rectified.
It is very common for modules after having successful passed all the unit test cases to fail when they are integrated with other modules. Integration testing is an important phase and sometimes there are separate teams which handle integration testing.
 
DEFINITION:Integration testing is a systematic technique for constructing the program structure while at the same time conducting tests to uncover errors associated with interfacing. The objective is to take unit tested components
and build a program structure that has been dictated by design.[http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki1b_4_mv#References]

==Integration Test approaches==
Integration testing can be done in a variety of ways [[Image:TopDown_Approach.jpg|thumb|Top Down Approach]]
# '''Top-Down Approach.''' In this approach the modules higher up in the control hierarchy are integrated first and low-level modules are added later. The advantage of this approach is that the modules with high level logic are tested first and hence bugs in the crucial logic are caught early. Further this approach does not require drivers to be written. Although a number of stubs have to be written and managed
# '''Bottom Up Approach.''' In this approach, the low level modules are integrated first and high level logic is tested late. While integrating the low level modules, the control modules are replaced by dummy modules called as drivers. Thus driver codes have to be written and managed while using this approach. [[Image:BottomUp_Approach.jpg|thumb|Bottom Up Approach]]
# '''Umbrella approach.''' Another approach is called the umbrella approach. It is a hybrid of the top down and the botom up approach, ie both the bottom up and top down approaches are used.In this approach we first test along the functional and control flow paths, for this we use the bottom up approach. The results thus gathered are later integrated in a top down manner. This kind of testing allows creating early prototypes of the system with has limited functionality thereby helping is the creations of the product in an incremental manner. This types of testing also minimizes the use of stubs and drivers which are needed in the top-down and bottom up approaches.
==Prerequisites before Integration Testing==
The system that is being tested, all of its modules should be rigorously tested as a component, i.e they should have gone through unit tests.
==Steps to write good Integration Test Cases==
#Create a Test Plan
#Create test cases and the sample data against which they would be tested.
#If automated tools are being used, scripts should be created.
#After the components have been integrated, start executing the test cases created in point 2.
#Log the bugs found and rectify the same.
#Retest the code.

==How To write good Integration Test Cases and do effective Integration Testing==
The main focus of integration testing is that it needs to check whether the different components are working smoothly and are interacting with each other in the proper manner. The Integration test cases specifically focus on the flow of data/information/control from one component to the other.
A few thing that needs to be kept in mind for effective integration testing are
# Ensure that the correct versions of the components are integrated together.
# Automate the integration of components so that there is lesser chance for human error.
# Log all the errors that have been found and document them with the solutions as well as the version number so that we could keep track of which build was being tested when the error was discovered.

=Beyond Functional and Integration Testing=
[[Image:TestPhase.jpg|thumb|Test Phases]]
Integration and Functional testing are not the only testing that are done for checking the validity of the system. Other test cases includes: 
'''Unit Testing:''' This is the first stage where the developer tests the component he/she is creating. More can be found at [http://en.wikipedia.org/wiki/Unit_testing Unit Testing] 
'''Validation Testing:''' After integration Testing, validation testing takes place wherein checks are made to ensure that the functional requirements are satisfied. 
'''Alpha and Beta Testing:'''When the product about to be released, it is first exposed to some end users who test the application. This is alpha beta testing. More can be found at [http://www.majordojo.com/uploads/AlphaBetaTesting.pdf Alpha and Beta Testing] 
'''Recovery Testing:''' In this phase the system is made to crash and is used to check to see if it recovers in the proper manner. More can be found at [http://en.wikipedia.org/wiki/Recovery_testing Recovery Testing] 
'''Security Testing:''' Systems that store and record sensitive information need to be protected from threats, in this phase the systems protection mechanisms are tested. More can be found at [http://en.wikipedia.org/wiki/Security_testing Security Testing] 
'''Stress Testing:'''The system is overloaded with data and it is checked to whether it crashes. More can be found at [http://en.wikipedia.org/wiki/Stress_testing Stress Testing] 
'''Performance Testing:''' It tests the run time performance of software within the context of the system. More can be found at [http://en.wikipedia.org/wiki/Performance_testing Performance Testing] 
'''Smoke Testing:''' smoke testing is a preliminary to further testing, which should reveal simple failures severe enough to reject a prospective software release. More can be found at [http://en.wikipedia.org/wiki/Smoke_test Smoke Test] 
'''Acceptance Testing:''' acceptance testing performed by the customer is known as user acceptance testing (UAT). This is also known as end-user testing, site (acceptance) testing, or field (acceptance) testing. More can be found at [http://en.wikipedia.org/wiki/Acceptance_testing Acceptance Testing]

=References=

# [http://www.segue.com/pdf/automated_functional_testing.pdf Automated Functional Testing]
# [http://searchsoftwarequality.techtarget.com/generic/0,295582,sid92_gci1303938,00.html# Functional Tests to ensure Software Quality]
# [http://www.developer.com/tech/article.php/3623476/Functional-Test-Plans-The-Right-Way.htm Functional Test Plans]
# Software Engineering: A Practitioner's Approach by Roger S. Pressman ISBN 0073655783

=External Links=
# [http://math-cs.gordon.edu/courses/cs211/ATMExample/InitialFunctionalTests.html Initial Functional Test Cases for an ATM system]
# [http://en.wikipedia.org/wiki/Unit_testing Unit Testing]
# [http://www.majordojo.com/uploads/AlphaBetaTesting.pdf Alpha Beta Testing]
# [http://en.wikipedia.org/wiki/Recovery_testing Recovery Testing]
# [http://en.wikipedia.org/wiki/Security_testing Security Testing]
# [http://en.wikipedia.org/wiki/Stress_testing Stress Testing]
# [http://en.wikipedia.org/wiki/Performance_testing Performance Testing]
# [http://en.wikipedia.org/wiki/Smoke_test Smoke Test]
# [http://en.wikipedia.org/wiki/Acceptance_testing Acceptance Testing]

CSC/ECE 517 Fall 2009/wiki1b 4 mv

2009-09-22T03:28:05Z

Mjampal: /* Functional Testing */

=Introduction=
Unit Testing is given a lot of importance in [[Software Testing]]. But functional and integration testing are essential too. Hence Functional and Integration Testing is discussed here. This page provides an introduction to these testing methods; also including the good practices to write functional and integration tests. Later additional types of Software Tests are mentioned, which could be used to gain further confidence that one's code is correct.

=Functional Testing=
Functional testing is the process of testing of all the functions of a system, ensuring that the system conforms to the user requirements and specifications. It is sometimes referred to as [[Black-box testing]], as it does not require understanding of the internal structure of the implementation.

Functional testing can be done by using manual or automated methods[http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki1b_4_mv#References]. In both the methods, a series of tests have to be run marking the interaction between the user and the system, ensuring that the system performs as it was supposed to. Since Use cases mainly depict the interaction between the user and system, functional test suites are created from requirement use cases, with each scenario becoming a functional test[http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki1b_4_mv#References].

==Functional Test Plan==
"The functional test plan measures the quality of the functional components of the system[http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki1b_4_mv#References]". The test plan is written by the Author. The Author lists a number of test cases, containing the input, expected results, and pre and post-test setup. After a module is unit tested, the Tester executes the functional test cases and records the actual results. The Reviewer compares the Actual results with the expected results and reports whether each test case passed or failed the test.

==Steps to write good Functional Tests==
# The test plan must be written by persons who have extensive knowledge of the business requirements. It is advisable that the developers do not write the test plans. This is because developers tend to unknowingly write test cases whose functionality is based on the implementation rather than the initial functional specifications.
# The functional test plans should be created as early as possible, probably as soon as the functional specifications are ready.
# The functional test plan should be updated when there are changes in the business requirements.
# For each functionality, a list of test cases should be defined so that each aspect of the functionality is covered.
# The Author should clearly include the pre-test setup for the test cases so that the Tester can easily execute the test cases.
# Usually the same test cases are run a number of times. Hence after executing a test case, any data added to the system should be cleared as as to not effect further tests or rerunning of the same test case. Hence the Author should also give post-test setup details.
# As a module is built and unit tested, the Tester should execute the particular test cases.

==Examples==
Examples of pre-test setup, test cases and post-test setup are given below. The complete reference for the example can be found at [http://www.developer.com/java/ent/article.php/3623476/Functional-Test-Plans-The-Right-Way.htm Functional Test Plans]

The pre-test setup for Test Case: Create new user profile can be given as:
[UserName: "A": --> username: "A"]
[UserName: "A": --> first name: "John"]
[UserName: "A": --> last name: "Smith"]
[UserName: "A": --> access level: "read-only"]
[UserName: "A": --> password: "profile1"]

The test cases for the function:Verify that only valid users can access the system can be given as:

<table cellspacing="2" width=900 border="1" align="center" >
<tr valign="top" bgcolor="#99ffff">
<th>Test Case #</th>
<th>Required Input</th>
<th>Expected Results</th>
<th>Results</th>

<th>Pass/Fail</th></tr>

<tr valign="top"><td colspan="5">
<ul>
<li>Verify that only valid users can access the system.</li>
<li>Verify that valid users cannot access the system without entering a valid password.</li>
</ul></td></tr>

<tr valign="top"><td>1</td>
<td>Navigate to the login screen</td>
<td>Login screen with release number A is loaded.</td>

<td> </td>
<td> </td></tr>

<tr valign="top"><td>2</td>
<td>Enter user name "INVALIDUSER", password "INVALIDUSER", and click on login button</td>
<td>Error message: 
"User name is not found"</td>
<td> </td>
<td> </td></tr>

<tr valign="top"><td>3</td>
<td>Enter user name for user [UserName: "A":--> username] and password "test"</td>

<td>Error Message: 
"Password for user [UserName: "A": --> username] is invalid"</td>
<td> </td>
<td> </td></tr>

<tr valign="top"><td>4</td>
<td>Enter user name [UserName: "A": --> username] and password [UserName: "A": --> password]</td>

<td>The main page is loaded with a message: 
"Welcome [UserName: "A": --> first name] [UserName: "A": --> last name]</td>
<td> </td>
<td> </td></tr>
</table>

The post-test setup for the above scenario can be given as:
Remove [UserName: "A": --> username: "A"] from the LDAP Server.

Another Example of Test Cases can be found at [http://math-cs.gordon.edu/courses/cs211/ATMExample/InitialFunctionalTests.html Initial Functional Test Cases for an ATM system]

=Integration Testing=
Integration Testing is a process of testing the application on the whole. After going through the unit testing of the modules, these modules need to be integrated, and during this process things may go wrong, Integration process is the phase wherein these errors are captured and rectified.
It is very common for modules after having successful passed all the unit test cases to fail when they are integrated with other modules. Integration testing is an important phase and sometimes there are separate teams which handle integration testing.
 
DEFINITION:Integration testing is a systematic technique for constructing the program structure while at the same time conducting tests to uncover errors associated with interfacing. The objective is to take unit tested components
and build a program structure that has been dictated by design.[http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki1b_4_mv#References]

==Integration Test approaches==
Integration testing can be done in a variety of ways [[Image:TopDown_Approach.jpg|thumb|Top Down Approach]]
# '''Top-Down Approach.''' In this approach the modules higher up in the control hierarchy are integrated first and low-level modules are added later. The advantage of this approach is that the modules with high level logic are tested first and hence bugs in the crucial logic are caught early. Further this approach does not require drivers to be written. Although a number of stubs have to be written and managed
# '''Bottom Up Approach.''' In this approach, the low level modules are integrated first and high level logic is tested late. While integrating the low level modules, the control modules are replaced by dummy modules called as drivers. Thus driver codes have to be written and managed while using this approach. [[Image:BottomUp_Approach.jpg|thumb|Bottom Up Approach]]
# '''Umbrella approach.''' Another approach is called the umbrella approach. It is a hybrid of the top down and the botom up approach, ie both the bottom up and top down approaches are used.In this approach we first test along the functional and control flow paths, for this we use the bottom up approach. The results thus gathered are later integrated in a top down manner. This kind of testing allows creating early prototypes of the system with has limited functionality thereby helping is the creations of the product in an incremental manner. This types of testing also minimizes the use of stubs and drivers which are needed in the top-down and bottom up approaches.
==Prerequisites before Integration Testing==
The system that is being tested, all of its modules should be rigorously tested as a component, i.e they should have gone through unit tests.
==Steps to write good Integration Test Cases==
#Create a Test Plan
#Create test cases and the sample data against which they would be tested.
#If automated tools are being used, scripts should be created.
#After the components have been integrated, start executing the test cases created in point 2.
#Log the bugs found and rectify the same.
#Retest the code.

==How To write good Integration Test Cases and do effective Integration Testing==
The main focus of integration testing is that it needs to check whether the different components are working smoothly and are interacting with each other in the proper manner. The Integration test cases specifically focus on the flow of data/information/control from one component to the other.
A few thing that needs to be kept in mind for effective integration testing are
# Ensure that the correct versions of the components are integrated together.
# Automate the integration of components so that there is lesser chance for human error.
# Log all the errors that have been found and document them with the solutions as well as the version number so that we could keep track of which build was being tested when the error was discovered.

=Beyond Functional and Integration Testing=
[[Image:TestPhase.jpg|thumb|Test Phases]]
Integration and Functional testing are not the only testing that are done for checking the validity of the system. Other test cases includes: 
'''Unit Testing:''' This is the first stage where the developer tests the component he/she is creating. More can be found at [http://en.wikipedia.org/wiki/Unit_testing Unit Testing] 
'''Validation Testing:''' After integration Testing, validation testing takes place wherein checks are made to ensure that the functional requirements are satisfied. 
'''Alpha and Beta Testing:'''When the product about to be released, it is first exposed to some end users who test the application. This is alpha beta testing. More can be found at [http://www.majordojo.com/uploads/AlphaBetaTesting.pdf Alpha and Beta Testing] 
'''Recovery Testing:''' In this phase the system is made to crash and is used to check to see if it recovers in the proper manner. More can be found at [http://en.wikipedia.org/wiki/Recovery_testing Recovery Testing] 
'''Security Testing:''' Systems that store and record sensitive information need to be protected from threats, in this phase the systems protection mechanisms are tested. More can be found at [http://en.wikipedia.org/wiki/Security_testing Security Testing] 
'''Stress Testing:'''The system is overloaded with data and it is checked to whether it crashes. More can be found at [http://en.wikipedia.org/wiki/Stress_testing Stress Testing] 
'''Performance Testing:''' It tests the run time performance of software within the context of the system. More can be found at [http://en.wikipedia.org/wiki/Performance_testing Performance Testing] 
'''Smoke Testing:''' smoke testing is a preliminary to further testing, which should reveal simple failures severe enough to reject a prospective software release. More can be found at [http://en.wikipedia.org/wiki/Smoke_test Smoke Test] 
'''Acceptance Testing:''' acceptance testing performed by the customer is known as user acceptance testing (UAT). This is also known as end-user testing, site (acceptance) testing, or field (acceptance) testing. More can be found at [http://en.wikipedia.org/wiki/Acceptance_testing Acceptance Testing]

=References=

# [http://www.segue.com/pdf/automated_functional_testing.pdf Automated Functional Testing]
# [http://searchsoftwarequality.techtarget.com/generic/0,295582,sid92_gci1303938,00.html# Functional Tests to ensure Software Quality]
# [http://www.developer.com/tech/article.php/3623476/Functional-Test-Plans-The-Right-Way.htm Functional Test Plans]
# Software Engineering: A Practitioner's Approach by Roger S. Pressman ISBN 0073655783

=External Links=
# [http://math-cs.gordon.edu/courses/cs211/ATMExample/InitialFunctionalTests.html Initial Functional Test Cases for an ATM system]
# [http://en.wikipedia.org/wiki/Unit_testing Unit Testing]
# [http://www.majordojo.com/uploads/AlphaBetaTesting.pdf Alpha Beta Testing]
# [http://en.wikipedia.org/wiki/Recovery_testing Recovery Testing]
# [http://en.wikipedia.org/wiki/Security_testing Security Testing]
# [http://en.wikipedia.org/wiki/Stress_testing Stress Testing]
# [http://en.wikipedia.org/wiki/Performance_testing Performance Testing]
# [http://en.wikipedia.org/wiki/Smoke_test Smoke Test]
# [http://en.wikipedia.org/wiki/Acceptance_testing Acceptance Testing]

CSC/ECE 517 Fall 2009/wiki1b 4 mv

2009-09-22T03:27:35Z

Mjampal: /* Functional Testing */

=Introduction=
Unit Testing is given a lot of importance in [[Software Testing]]. But functional and integration testing are essential too. Hence Functional and Integration Testing is discussed here. This page provides an introduction to these testing methods; also including the good practices to write functional and integration tests. Later additional types of Software Tests are mentioned, which could be used to gain further confidence that one's code is correct.

=Functional Testing=
Functional testing is the process of testing of all the functions of a system, ensuring that the system conforms to the user requirements and specifications. It is sometimes referred to as [Black-box testing], as it does not require understanding of the internal structure of the implementation.

Functional testing can be done by using manual or automated methods[http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki1b_4_mv#References]. In both the methods, a series of tests have to be run marking the interaction between the user and the system, ensuring that the system performs as it was supposed to. Since Use cases mainly depict the interaction between the user and system, functional test suites are created from requirement use cases, with each scenario becoming a functional test[http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki1b_4_mv#References].

==Functional Test Plan==
"The functional test plan measures the quality of the functional components of the system[http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki1b_4_mv#References]". The test plan is written by the Author. The Author lists a number of test cases, containing the input, expected results, and pre and post-test setup. After a module is unit tested, the Tester executes the functional test cases and records the actual results. The Reviewer compares the Actual results with the expected results and reports whether each test case passed or failed the test.

==Steps to write good Functional Tests==
# The test plan must be written by persons who have extensive knowledge of the business requirements. It is advisable that the developers do not write the test plans. This is because developers tend to unknowingly write test cases whose functionality is based on the implementation rather than the initial functional specifications.
# The functional test plans should be created as early as possible, probably as soon as the functional specifications are ready.
# The functional test plan should be updated when there are changes in the business requirements.
# For each functionality, a list of test cases should be defined so that each aspect of the functionality is covered.
# The Author should clearly include the pre-test setup for the test cases so that the Tester can easily execute the test cases.
# Usually the same test cases are run a number of times. Hence after executing a test case, any data added to the system should be cleared as as to not effect further tests or rerunning of the same test case. Hence the Author should also give post-test setup details.
# As a module is built and unit tested, the Tester should execute the particular test cases.

==Examples==
Examples of pre-test setup, test cases and post-test setup are given below. The complete reference for the example can be found at [http://www.developer.com/java/ent/article.php/3623476/Functional-Test-Plans-The-Right-Way.htm Functional Test Plans]

The pre-test setup for Test Case: Create new user profile can be given as:
[UserName: "A": --> username: "A"]
[UserName: "A": --> first name: "John"]
[UserName: "A": --> last name: "Smith"]
[UserName: "A": --> access level: "read-only"]
[UserName: "A": --> password: "profile1"]

The test cases for the function:Verify that only valid users can access the system can be given as:

<table cellspacing="2" width=900 border="1" align="center" >
<tr valign="top" bgcolor="#99ffff">
<th>Test Case #</th>
<th>Required Input</th>
<th>Expected Results</th>
<th>Results</th>

<th>Pass/Fail</th></tr>

<tr valign="top"><td colspan="5">
<ul>
<li>Verify that only valid users can access the system.</li>
<li>Verify that valid users cannot access the system without entering a valid password.</li>
</ul></td></tr>

<tr valign="top"><td>1</td>
<td>Navigate to the login screen</td>
<td>Login screen with release number A is loaded.</td>

<td> </td>
<td> </td></tr>

<tr valign="top"><td>2</td>
<td>Enter user name "INVALIDUSER", password "INVALIDUSER", and click on login button</td>
<td>Error message: 
"User name is not found"</td>
<td> </td>
<td> </td></tr>

<tr valign="top"><td>3</td>
<td>Enter user name for user [UserName: "A":--> username] and password "test"</td>

<td>Error Message: 
"Password for user [UserName: "A": --> username] is invalid"</td>
<td> </td>
<td> </td></tr>

<tr valign="top"><td>4</td>
<td>Enter user name [UserName: "A": --> username] and password [UserName: "A": --> password]</td>

<td>The main page is loaded with a message: 
"Welcome [UserName: "A": --> first name] [UserName: "A": --> last name]</td>
<td> </td>
<td> </td></tr>
</table>

The post-test setup for the above scenario can be given as:
Remove [UserName: "A": --> username: "A"] from the LDAP Server.

Another Example of Test Cases can be found at [http://math-cs.gordon.edu/courses/cs211/ATMExample/InitialFunctionalTests.html Initial Functional Test Cases for an ATM system]

=Integration Testing=
Integration Testing is a process of testing the application on the whole. After going through the unit testing of the modules, these modules need to be integrated, and during this process things may go wrong, Integration process is the phase wherein these errors are captured and rectified.
It is very common for modules after having successful passed all the unit test cases to fail when they are integrated with other modules. Integration testing is an important phase and sometimes there are separate teams which handle integration testing.
 
DEFINITION:Integration testing is a systematic technique for constructing the program structure while at the same time conducting tests to uncover errors associated with interfacing. The objective is to take unit tested components
and build a program structure that has been dictated by design.[http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki1b_4_mv#References]

==Integration Test approaches==
Integration testing can be done in a variety of ways [[Image:TopDown_Approach.jpg|thumb|Top Down Approach]]
# '''Top-Down Approach.''' In this approach the modules higher up in the control hierarchy are integrated first and low-level modules are added later. The advantage of this approach is that the modules with high level logic are tested first and hence bugs in the crucial logic are caught early. Further this approach does not require drivers to be written. Although a number of stubs have to be written and managed
# '''Bottom Up Approach.''' In this approach, the low level modules are integrated first and high level logic is tested late. While integrating the low level modules, the control modules are replaced by dummy modules called as drivers. Thus driver codes have to be written and managed while using this approach. [[Image:BottomUp_Approach.jpg|thumb|Bottom Up Approach]]
# '''Umbrella approach.''' Another approach is called the umbrella approach. It is a hybrid of the top down and the botom up approach, ie both the bottom up and top down approaches are used.In this approach we first test along the functional and control flow paths, for this we use the bottom up approach. The results thus gathered are later integrated in a top down manner. This kind of testing allows creating early prototypes of the system with has limited functionality thereby helping is the creations of the product in an incremental manner. This types of testing also minimizes the use of stubs and drivers which are needed in the top-down and bottom up approaches.
==Prerequisites before Integration Testing==
The system that is being tested, all of its modules should be rigorously tested as a component, i.e they should have gone through unit tests.
==Steps to write good Integration Test Cases==
#Create a Test Plan
#Create test cases and the sample data against which they would be tested.
#If automated tools are being used, scripts should be created.
#After the components have been integrated, start executing the test cases created in point 2.
#Log the bugs found and rectify the same.
#Retest the code.

==How To write good Integration Test Cases and do effective Integration Testing==
The main focus of integration testing is that it needs to check whether the different components are working smoothly and are interacting with each other in the proper manner. The Integration test cases specifically focus on the flow of data/information/control from one component to the other.
A few thing that needs to be kept in mind for effective integration testing are
# Ensure that the correct versions of the components are integrated together.
# Automate the integration of components so that there is lesser chance for human error.
# Log all the errors that have been found and document them with the solutions as well as the version number so that we could keep track of which build was being tested when the error was discovered.

=Beyond Functional and Integration Testing=
[[Image:TestPhase.jpg|thumb|Test Phases]]
Integration and Functional testing are not the only testing that are done for checking the validity of the system. Other test cases includes: 
'''Unit Testing:''' This is the first stage where the developer tests the component he/she is creating. More can be found at [http://en.wikipedia.org/wiki/Unit_testing Unit Testing] 
'''Validation Testing:''' After integration Testing, validation testing takes place wherein checks are made to ensure that the functional requirements are satisfied. 
'''Alpha and Beta Testing:'''When the product about to be released, it is first exposed to some end users who test the application. This is alpha beta testing. More can be found at [http://www.majordojo.com/uploads/AlphaBetaTesting.pdf Alpha and Beta Testing] 
'''Recovery Testing:''' In this phase the system is made to crash and is used to check to see if it recovers in the proper manner. More can be found at [http://en.wikipedia.org/wiki/Recovery_testing Recovery Testing] 
'''Security Testing:''' Systems that store and record sensitive information need to be protected from threats, in this phase the systems protection mechanisms are tested. More can be found at [http://en.wikipedia.org/wiki/Security_testing Security Testing] 
'''Stress Testing:'''The system is overloaded with data and it is checked to whether it crashes. More can be found at [http://en.wikipedia.org/wiki/Stress_testing Stress Testing] 
'''Performance Testing:''' It tests the run time performance of software within the context of the system. More can be found at [http://en.wikipedia.org/wiki/Performance_testing Performance Testing] 
'''Smoke Testing:''' smoke testing is a preliminary to further testing, which should reveal simple failures severe enough to reject a prospective software release. More can be found at [http://en.wikipedia.org/wiki/Smoke_test Smoke Test] 
'''Acceptance Testing:''' acceptance testing performed by the customer is known as user acceptance testing (UAT). This is also known as end-user testing, site (acceptance) testing, or field (acceptance) testing. More can be found at [http://en.wikipedia.org/wiki/Acceptance_testing Acceptance Testing]

=References=

# [http://www.segue.com/pdf/automated_functional_testing.pdf Automated Functional Testing]
# [http://searchsoftwarequality.techtarget.com/generic/0,295582,sid92_gci1303938,00.html# Functional Tests to ensure Software Quality]
# [http://www.developer.com/tech/article.php/3623476/Functional-Test-Plans-The-Right-Way.htm Functional Test Plans]
# Software Engineering: A Practitioner's Approach by Roger S. Pressman ISBN 0073655783

=External Links=
# [http://math-cs.gordon.edu/courses/cs211/ATMExample/InitialFunctionalTests.html Initial Functional Test Cases for an ATM system]
# [http://en.wikipedia.org/wiki/Unit_testing Unit Testing]
# [http://www.majordojo.com/uploads/AlphaBetaTesting.pdf Alpha Beta Testing]
# [http://en.wikipedia.org/wiki/Recovery_testing Recovery Testing]
# [http://en.wikipedia.org/wiki/Security_testing Security Testing]
# [http://en.wikipedia.org/wiki/Stress_testing Stress Testing]
# [http://en.wikipedia.org/wiki/Performance_testing Performance Testing]
# [http://en.wikipedia.org/wiki/Smoke_test Smoke Test]
# [http://en.wikipedia.org/wiki/Acceptance_testing Acceptance Testing]

CSC/ECE 517 Fall 2009/wiki1b 4 mv

2009-09-22T03:26:32Z

Mjampal: /* Introduction */

=Introduction=
Unit Testing is given a lot of importance in [[Software Testing]]. But functional and integration testing are essential too. Hence Functional and Integration Testing is discussed here. This page provides an introduction to these testing methods; also including the good practices to write functional and integration tests. Later additional types of Software Tests are mentioned, which could be used to gain further confidence that one's code is correct.

=Functional Testing=
Functional testing is the process of testing of all the functions of a system, ensuring that the system conforms to the user requirements and specifications. It is sometimes referred to as black box testing, as it does not require understanding of the internal structure of the implementation.

Functional testing can be done by using manual or automated methods[http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki1b_4_mv#References]. In both the methods, a series of tests have to be run marking the interaction between the user and the system, ensuring that the system performs as it was supposed to. Since Use cases mainly depict the interaction between the user and system, functional test suites are created from requirement use cases, with each scenario becoming a functional test[http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki1b_4_mv#References].

==Functional Test Plan==
"The functional test plan measures the quality of the functional components of the system[http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki1b_4_mv#References]". The test plan is written by the Author. The Author lists a number of test cases, containing the input, expected results, and pre and post-test setup. After a module is unit tested, the Tester executes the functional test cases and records the actual results. The Reviewer compares the Actual results with the expected results and reports whether each test case passed or failed the test.

==Steps to write good Functional Tests==
# The test plan must be written by persons who have extensive knowledge of the business requirements. It is advisable that the developers do not write the test plans. This is because developers tend to unknowingly write test cases whose functionality is based on the implementation rather than the initial functional specifications.
# The functional test plans should be created as early as possible, probably as soon as the functional specifications are ready.
# The functional test plan should be updated when there are changes in the business requirements.
# For each functionality, a list of test cases should be defined so that each aspect of the functionality is covered.
# The Author should clearly include the pre-test setup for the test cases so that the Tester can easily execute the test cases.
# Usually the same test cases are run a number of times. Hence after executing a test case, any data added to the system should be cleared as as to not effect further tests or rerunning of the same test case. Hence the Author should also give post-test setup details.
# As a module is built and unit tested, the Tester should execute the particular test cases.

==Examples==
Examples of pre-test setup, test cases and post-test setup are given below. The complete reference for the example can be found at [http://www.developer.com/java/ent/article.php/3623476/Functional-Test-Plans-The-Right-Way.htm Functional Test Plans]

The pre-test setup for Test Case: Create new user profile can be given as:
[UserName: "A": --> username: "A"]
[UserName: "A": --> first name: "John"]
[UserName: "A": --> last name: "Smith"]
[UserName: "A": --> access level: "read-only"]
[UserName: "A": --> password: "profile1"]

The test cases for the function:Verify that only valid users can access the system can be given as:

<table cellspacing="2" width=900 border="1" align="center" >
<tr valign="top" bgcolor="#99ffff">
<th>Test Case #</th>
<th>Required Input</th>
<th>Expected Results</th>
<th>Results</th>

<th>Pass/Fail</th></tr>

<tr valign="top"><td colspan="5">
<ul>
<li>Verify that only valid users can access the system.</li>
<li>Verify that valid users cannot access the system without entering a valid password.</li>
</ul></td></tr>

<tr valign="top"><td>1</td>
<td>Navigate to the login screen</td>
<td>Login screen with release number A is loaded.</td>

<td> </td>
<td> </td></tr>

<tr valign="top"><td>2</td>
<td>Enter user name "INVALIDUSER", password "INVALIDUSER", and click on login button</td>
<td>Error message: 
"User name is not found"</td>
<td> </td>
<td> </td></tr>

<tr valign="top"><td>3</td>
<td>Enter user name for user [UserName: "A":--> username] and password "test"</td>

<td>Error Message: 
"Password for user [UserName: "A": --> username] is invalid"</td>
<td> </td>
<td> </td></tr>

<tr valign="top"><td>4</td>
<td>Enter user name [UserName: "A": --> username] and password [UserName: "A": --> password]</td>

<td>The main page is loaded with a message: 
"Welcome [UserName: "A": --> first name] [UserName: "A": --> last name]</td>
<td> </td>
<td> </td></tr>
</table>

The post-test setup for the above scenario can be given as:
Remove [UserName: "A": --> username: "A"] from the LDAP Server.

Another Example of Test Cases can be found at [http://math-cs.gordon.edu/courses/cs211/ATMExample/InitialFunctionalTests.html Initial Functional Test Cases for an ATM system]

=Integration Testing=
Integration Testing is a process of testing the application on the whole. After going through the unit testing of the modules, these modules need to be integrated, and during this process things may go wrong, Integration process is the phase wherein these errors are captured and rectified.
It is very common for modules after having successful passed all the unit test cases to fail when they are integrated with other modules. Integration testing is an important phase and sometimes there are separate teams which handle integration testing.
 
DEFINITION:Integration testing is a systematic technique for constructing the program structure while at the same time conducting tests to uncover errors associated with interfacing. The objective is to take unit tested components
and build a program structure that has been dictated by design.[http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki1b_4_mv#References]

==Integration Test approaches==
Integration testing can be done in a variety of ways [[Image:TopDown_Approach.jpg|thumb|Top Down Approach]]
# '''Top-Down Approach.''' In this approach the modules higher up in the control hierarchy are integrated first and low-level modules are added later. The advantage of this approach is that the modules with high level logic are tested first and hence bugs in the crucial logic are caught early. Further this approach does not require drivers to be written. Although a number of stubs have to be written and managed
# '''Bottom Up Approach.''' In this approach, the low level modules are integrated first and high level logic is tested late. While integrating the low level modules, the control modules are replaced by dummy modules called as drivers. Thus driver codes have to be written and managed while using this approach. [[Image:BottomUp_Approach.jpg|thumb|Bottom Up Approach]]
# '''Umbrella approach.''' Another approach is called the umbrella approach. It is a hybrid of the top down and the botom up approach, ie both the bottom up and top down approaches are used.In this approach we first test along the functional and control flow paths, for this we use the bottom up approach. The results thus gathered are later integrated in a top down manner. This kind of testing allows creating early prototypes of the system with has limited functionality thereby helping is the creations of the product in an incremental manner. This types of testing also minimizes the use of stubs and drivers which are needed in the top-down and bottom up approaches.
==Prerequisites before Integration Testing==
The system that is being tested, all of its modules should be rigorously tested as a component, i.e they should have gone through unit tests.
==Steps to write good Integration Test Cases==
#Create a Test Plan
#Create test cases and the sample data against which they would be tested.
#If automated tools are being used, scripts should be created.
#After the components have been integrated, start executing the test cases created in point 2.
#Log the bugs found and rectify the same.
#Retest the code.

==How To write good Integration Test Cases and do effective Integration Testing==
The main focus of integration testing is that it needs to check whether the different components are working smoothly and are interacting with each other in the proper manner. The Integration test cases specifically focus on the flow of data/information/control from one component to the other.
A few thing that needs to be kept in mind for effective integration testing are
# Ensure that the correct versions of the components are integrated together.
# Automate the integration of components so that there is lesser chance for human error.
# Log all the errors that have been found and document them with the solutions as well as the version number so that we could keep track of which build was being tested when the error was discovered.

=Beyond Functional and Integration Testing=
[[Image:TestPhase.jpg|thumb|Test Phases]]
Integration and Functional testing are not the only testing that are done for checking the validity of the system. Other test cases includes: 
'''Unit Testing:''' This is the first stage where the developer tests the component he/she is creating. More can be found at [http://en.wikipedia.org/wiki/Unit_testing Unit Testing] 
'''Validation Testing:''' After integration Testing, validation testing takes place wherein checks are made to ensure that the functional requirements are satisfied. 
'''Alpha and Beta Testing:'''When the product about to be released, it is first exposed to some end users who test the application. This is alpha beta testing. More can be found at [http://www.majordojo.com/uploads/AlphaBetaTesting.pdf Alpha and Beta Testing] 
'''Recovery Testing:''' In this phase the system is made to crash and is used to check to see if it recovers in the proper manner. More can be found at [http://en.wikipedia.org/wiki/Recovery_testing Recovery Testing] 
'''Security Testing:''' Systems that store and record sensitive information need to be protected from threats, in this phase the systems protection mechanisms are tested. More can be found at [http://en.wikipedia.org/wiki/Security_testing Security Testing] 
'''Stress Testing:'''The system is overloaded with data and it is checked to whether it crashes. More can be found at [http://en.wikipedia.org/wiki/Stress_testing Stress Testing] 
'''Performance Testing:''' It tests the run time performance of software within the context of the system. More can be found at [http://en.wikipedia.org/wiki/Performance_testing Performance Testing] 
'''Smoke Testing:''' smoke testing is a preliminary to further testing, which should reveal simple failures severe enough to reject a prospective software release. More can be found at [http://en.wikipedia.org/wiki/Smoke_test Smoke Test] 
'''Acceptance Testing:''' acceptance testing performed by the customer is known as user acceptance testing (UAT). This is also known as end-user testing, site (acceptance) testing, or field (acceptance) testing. More can be found at [http://en.wikipedia.org/wiki/Acceptance_testing Acceptance Testing]

=References=

# [http://www.segue.com/pdf/automated_functional_testing.pdf Automated Functional Testing]
# [http://searchsoftwarequality.techtarget.com/generic/0,295582,sid92_gci1303938,00.html# Functional Tests to ensure Software Quality]
# [http://www.developer.com/tech/article.php/3623476/Functional-Test-Plans-The-Right-Way.htm Functional Test Plans]
# Software Engineering: A Practitioner's Approach by Roger S. Pressman ISBN 0073655783

=External Links=
# [http://math-cs.gordon.edu/courses/cs211/ATMExample/InitialFunctionalTests.html Initial Functional Test Cases for an ATM system]
# [http://en.wikipedia.org/wiki/Unit_testing Unit Testing]
# [http://www.majordojo.com/uploads/AlphaBetaTesting.pdf Alpha Beta Testing]
# [http://en.wikipedia.org/wiki/Recovery_testing Recovery Testing]
# [http://en.wikipedia.org/wiki/Security_testing Security Testing]
# [http://en.wikipedia.org/wiki/Stress_testing Stress Testing]
# [http://en.wikipedia.org/wiki/Performance_testing Performance Testing]
# [http://en.wikipedia.org/wiki/Smoke_test Smoke Test]
# [http://en.wikipedia.org/wiki/Acceptance_testing Acceptance Testing]

CSC/ECE 517 Fall 2009/wiki1b 4 mv

2009-09-22T03:19:45Z

Mjampal: /* External Links */

=Introduction=
Unit Testing is given a lot of importance in [[Software Testing]]. But functional and integration testing are essential too. Hence Functional and Integration Testing is discussed here. This page provides an introduction to these testing methods; also including the good practices to write functional and integration tests. Later additional types of software Tests are mentioned which could be used to gain further confidence that one's code is correct.

=Functional Testing=
Functional testing is the process of testing of all the functions of a system, ensuring that the system conforms to the user requirements and specifications. It is sometimes referred to as black box testing, as it does not require understanding of the internal structure of the implementation.

Functional testing can be done by using manual or automated methods[http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki1b_4_mv#References]. In both the methods, a series of tests have to be run marking the interaction between the user and the system, ensuring that the system performs as it was supposed to. Since Use cases mainly depict the interaction between the user and system, functional test suites are created from requirement use cases, with each scenario becoming a functional test[http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki1b_4_mv#References].

==Functional Test Plan==
"The functional test plan measures the quality of the functional components of the system[http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki1b_4_mv#References]". The test plan is written by the Author. The Author lists a number of test cases, containing the input, expected results, and pre and post-test setup. After a module is unit tested, the Tester executes the functional test cases and records the actual results. The Reviewer compares the Actual results with the expected results and reports whether each test case passed or failed the test.

==Steps to write good Functional Tests==
# The test plan must be written by persons who have extensive knowledge of the business requirements. It is advisable that the developers do not write the test plans. This is because developers tend to unknowingly write test cases whose functionality is based on the implementation rather than the initial functional specifications.
# The functional test plans should be created as early as possible, probably as soon as the functional specifications are ready.
# The functional test plan should be updated when there are changes in the business requirements.
# For each functionality, a list of test cases should be defined so that each aspect of the functionality is covered.
# The Author should clearly include the pre-test setup for the test cases so that the Tester can easily execute the test cases.
# Usually the same test cases are run a number of times. Hence after executing a test case, any data added to the system should be cleared as as to not effect further tests or rerunning of the same test case. Hence the Author should also give post-test setup details.
# As a module is built and unit tested, the Tester should execute the particular test cases.

==Examples==
Examples of pre-test setup, test cases and post-test setup are given below. The complete reference for the example can be found at [http://www.developer.com/java/ent/article.php/3623476/Functional-Test-Plans-The-Right-Way.htm Functional Test Plans]

The pre-test setup for Test Case: Create new user profile can be given as:
[UserName: "A": --> username: "A"]
[UserName: "A": --> first name: "John"]
[UserName: "A": --> last name: "Smith"]
[UserName: "A": --> access level: "read-only"]
[UserName: "A": --> password: "profile1"]

The test cases for the function:Verify that only valid users can access the system can be given as:

<table cellspacing="2" width=900 border="1" align="center" >
<tr valign="top" bgcolor="#99ffff">
<th>Test Case #</th>
<th>Required Input</th>
<th>Expected Results</th>
<th>Results</th>

<th>Pass/Fail</th></tr>

<tr valign="top"><td colspan="5">
<ul>
<li>Verify that only valid users can access the system.</li>
<li>Verify that valid users cannot access the system without entering a valid password.</li>
</ul></td></tr>

<tr valign="top"><td>1</td>
<td>Navigate to the login screen</td>
<td>Login screen with release number A is loaded.</td>

<td> </td>
<td> </td></tr>

<tr valign="top"><td>2</td>
<td>Enter user name "INVALIDUSER", password "INVALIDUSER", and click on login button</td>
<td>Error message: 
"User name is not found"</td>
<td> </td>
<td> </td></tr>

<tr valign="top"><td>3</td>
<td>Enter user name for user [UserName: "A":--> username] and password "test"</td>

<td>Error Message: 
"Password for user [UserName: "A": --> username] is invalid"</td>
<td> </td>
<td> </td></tr>

<tr valign="top"><td>4</td>
<td>Enter user name [UserName: "A": --> username] and password [UserName: "A": --> password]</td>

<td>The main page is loaded with a message: 
"Welcome [UserName: "A": --> first name] [UserName: "A": --> last name]</td>
<td> </td>
<td> </td></tr>
</table>

The post-test setup for the above scenario can be given as:
Remove [UserName: "A": --> username: "A"] from the LDAP Server.

Another Example of Test Cases can be found at [http://math-cs.gordon.edu/courses/cs211/ATMExample/InitialFunctionalTests.html Initial Functional Test Cases for an ATM system]

=Integration Testing=
Integration Testing is a process of testing the application on the whole. After going through the unit testing of the modules, these modules need to be integrated, and during this process things may go wrong, Integration process is the phase wherein these errors are captured and rectified.
It is very common for modules after having successful passed all the unit test cases to fail when they are integrated with other modules. Integration testing is an important phase and sometimes there are separate teams which handle integration testing.
 
DEFINITION:Integration testing is a systematic technique for constructing the program structure while at the same time conducting tests to uncover errors associated with interfacing. The objective is to take unit tested components
and build a program structure that has been dictated by design.[http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki1b_4_mv#References]

==Integration Test approaches==
Integration testing can be done in a variety of ways [[Image:TopDown_Approach.jpg|thumb|Top Down Approach]]
# '''Top-Down Approach.''' In this approach the modules higher up in the control hierarchy are integrated first and low-level modules are added later. The advantage of this approach is that the modules with high level logic are tested first and hence bugs in the crucial logic are caught early. Further this approach does not require drivers to be written. Although a number of stubs have to be written and managed
# '''Bottom Up Approach.''' In this approach, the low level modules are integrated first and high level logic is tested late. While integrating the low level modules, the control modules are replaced by dummy modules called as drivers. Thus driver codes have to be written and managed while using this approach. [[Image:BottomUp_Approach.jpg|thumb|Bottom Up Approach]]
# '''Umbrella approach.''' Another approach is called the umbrella approach. It is a hybrid of the top down and the botom up approach, ie both the bottom up and top down approaches are used.In this approach we first test along the functional and control flow paths, for this we use the bottom up approach. The results thus gathered are later integrated in a top down manner. This kind of testing allows creating early prototypes of the system with has limited functionality thereby helping is the creations of the product in an incremental manner. This types of testing also minimizes the use of stubs and drivers which are needed in the top-down and bottom up approaches.
==Prerequisites before Integration Testing==
The system that is being tested, all of its modules should be rigorously tested as a component, i.e they should have gone through unit tests.
==Steps to write good Integration Test Cases==
#Create a Test Plan
#Create test cases and the sample data against which they would be tested.
#If automated tools are being used, scripts should be created.
#After the components have been integrated, start executing the test cases created in point 2.
#Log the bugs found and rectify the same.
#Retest the code.

==How To write good Integration Test Cases and do effective Integration Testing==
The main focus of integration testing is that it needs to check whether the different components are working smoothly and are interacting with each other in the proper manner. The Integration test cases specifically focus on the flow of data/information/control from one component to the other.
A few thing that needs to be kept in mind for effective integration testing are
# Ensure that the correct versions of the components are integrated together.
# Automate the integration of components so that there is lesser chance for human error.
# Log all the errors that have been found and document them with the solutions as well as the version number so that we could keep track of which build was being tested when the error was discovered.

=Beyond Functional and Integration Testing=
[[Image:TestPhase.jpg|thumb|Test Phases]]
Integration and Functional testing are not the only testing that are done for checking the validity of the system. Other test cases includes: 
'''Unit Testing:''' This is the first stage where the developer tests the component he/she is creating. More can be found at [http://en.wikipedia.org/wiki/Unit_testing Unit Testing] 
'''Validation Testing:''' After integration Testing, validation testing takes place wherein checks are made to ensure that the functional requirements are satisfied. 
'''Alpha and Beta Testing:'''When the product about to be released, it is first exposed to some end users who test the application. This is alpha beta testing. More can be found at [http://www.majordojo.com/uploads/AlphaBetaTesting.pdf Alpha and Beta Testing] 
'''Recovery Testing:''' In this phase the system is made to crash and is used to check to see if it recovers in the proper manner. More can be found at [http://en.wikipedia.org/wiki/Recovery_testing Recovery Testing] 
'''Security Testing:''' Systems that store and record sensitive information need to be protected from threats, in this phase the systems protection mechanisms are tested. More can be found at [http://en.wikipedia.org/wiki/Security_testing Security Testing] 
'''Stress Testing:'''The system is overloaded with data and it is checked to whether it crashes. More can be found at [http://en.wikipedia.org/wiki/Stress_testing Stress Testing] 
'''Performance Testing:''' It tests the run time performance of software within the context of the system. More can be found at [http://en.wikipedia.org/wiki/Performance_testing Performance Testing] 
'''Smoke Testing:''' smoke testing is a preliminary to further testing, which should reveal simple failures severe enough to reject a prospective software release. More can be found at [http://en.wikipedia.org/wiki/Smoke_test Smoke Test] 
'''Acceptance Testing:''' acceptance testing performed by the customer is known as user acceptance testing (UAT). This is also known as end-user testing, site (acceptance) testing, or field (acceptance) testing. More can be found at [http://en.wikipedia.org/wiki/Acceptance_testing Acceptance Testing]

=References=

# [http://www.segue.com/pdf/automated_functional_testing.pdf Automated Functional Testing]
# [http://searchsoftwarequality.techtarget.com/generic/0,295582,sid92_gci1303938,00.html# Functional Tests to ensure Software Quality]
# [http://www.developer.com/tech/article.php/3623476/Functional-Test-Plans-The-Right-Way.htm Functional Test Plans]
# Software Engineering: A Practitioner's Approach by Roger S. Pressman ISBN 0073655783

=External Links=
# [http://math-cs.gordon.edu/courses/cs211/ATMExample/InitialFunctionalTests.html Initial Functional Test Cases for an ATM system]
# [http://en.wikipedia.org/wiki/Unit_testing Unit Testing]
# [http://www.majordojo.com/uploads/AlphaBetaTesting.pdf Alpha Beta Testing]
# [http://en.wikipedia.org/wiki/Recovery_testing Recovery Testing]
# [http://en.wikipedia.org/wiki/Security_testing Security Testing]
# [http://en.wikipedia.org/wiki/Stress_testing Stress Testing]
# [http://en.wikipedia.org/wiki/Performance_testing Performance Testing]
# [http://en.wikipedia.org/wiki/Smoke_test Smoke Test]
# [http://en.wikipedia.org/wiki/Acceptance_testing Acceptance Testing]

CSC/ECE 517 Fall 2009/wiki1b 4 mv

2009-09-22T03:18:25Z

Mjampal: /* Example */

=Introduction=
Unit Testing is given a lot of importance in [[Software Testing]]. But functional and integration testing are essential too. Hence Functional and Integration Testing is discussed here. This page provides an introduction to these testing methods; also including the good practices to write functional and integration tests. Later additional types of software Tests are mentioned which could be used to gain further confidence that one's code is correct.

=Functional Testing=
Functional testing is the process of testing of all the functions of a system, ensuring that the system conforms to the user requirements and specifications. It is sometimes referred to as black box testing, as it does not require understanding of the internal structure of the implementation.

Functional testing can be done by using manual or automated methods[http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki1b_4_mv#References]. In both the methods, a series of tests have to be run marking the interaction between the user and the system, ensuring that the system performs as it was supposed to. Since Use cases mainly depict the interaction between the user and system, functional test suites are created from requirement use cases, with each scenario becoming a functional test[http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki1b_4_mv#References].

==Functional Test Plan==
"The functional test plan measures the quality of the functional components of the system[http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki1b_4_mv#References]". The test plan is written by the Author. The Author lists a number of test cases, containing the input, expected results, and pre and post-test setup. After a module is unit tested, the Tester executes the functional test cases and records the actual results. The Reviewer compares the Actual results with the expected results and reports whether each test case passed or failed the test.

==Steps to write good Functional Tests==
# The test plan must be written by persons who have extensive knowledge of the business requirements. It is advisable that the developers do not write the test plans. This is because developers tend to unknowingly write test cases whose functionality is based on the implementation rather than the initial functional specifications.
# The functional test plans should be created as early as possible, probably as soon as the functional specifications are ready.
# The functional test plan should be updated when there are changes in the business requirements.
# For each functionality, a list of test cases should be defined so that each aspect of the functionality is covered.
# The Author should clearly include the pre-test setup for the test cases so that the Tester can easily execute the test cases.
# Usually the same test cases are run a number of times. Hence after executing a test case, any data added to the system should be cleared as as to not effect further tests or rerunning of the same test case. Hence the Author should also give post-test setup details.
# As a module is built and unit tested, the Tester should execute the particular test cases.

==Examples==
Examples of pre-test setup, test cases and post-test setup are given below. The complete reference for the example can be found at [http://www.developer.com/java/ent/article.php/3623476/Functional-Test-Plans-The-Right-Way.htm Functional Test Plans]

The pre-test setup for Test Case: Create new user profile can be given as:
[UserName: "A": --> username: "A"]
[UserName: "A": --> first name: "John"]
[UserName: "A": --> last name: "Smith"]
[UserName: "A": --> access level: "read-only"]
[UserName: "A": --> password: "profile1"]

The test cases for the function:Verify that only valid users can access the system can be given as:

<table cellspacing="2" width=900 border="1" align="center" >
<tr valign="top" bgcolor="#99ffff">
<th>Test Case #</th>
<th>Required Input</th>
<th>Expected Results</th>
<th>Results</th>

<th>Pass/Fail</th></tr>

<tr valign="top"><td colspan="5">
<ul>
<li>Verify that only valid users can access the system.</li>
<li>Verify that valid users cannot access the system without entering a valid password.</li>
</ul></td></tr>

<tr valign="top"><td>1</td>
<td>Navigate to the login screen</td>
<td>Login screen with release number A is loaded.</td>

<td> </td>
<td> </td></tr>

<tr valign="top"><td>2</td>
<td>Enter user name "INVALIDUSER", password "INVALIDUSER", and click on login button</td>
<td>Error message: 
"User name is not found"</td>
<td> </td>
<td> </td></tr>

<tr valign="top"><td>3</td>
<td>Enter user name for user [UserName: "A":--> username] and password "test"</td>

<td>Error Message: 
"Password for user [UserName: "A": --> username] is invalid"</td>
<td> </td>
<td> </td></tr>

<tr valign="top"><td>4</td>
<td>Enter user name [UserName: "A": --> username] and password [UserName: "A": --> password]</td>

<td>The main page is loaded with a message: 
"Welcome [UserName: "A": --> first name] [UserName: "A": --> last name]</td>
<td> </td>
<td> </td></tr>
</table>

The post-test setup for the above scenario can be given as:
Remove [UserName: "A": --> username: "A"] from the LDAP Server.

Another Example of Test Cases can be found at [http://math-cs.gordon.edu/courses/cs211/ATMExample/InitialFunctionalTests.html Initial Functional Test Cases for an ATM system]

=Integration Testing=
Integration Testing is a process of testing the application on the whole. After going through the unit testing of the modules, these modules need to be integrated, and during this process things may go wrong, Integration process is the phase wherein these errors are captured and rectified.
It is very common for modules after having successful passed all the unit test cases to fail when they are integrated with other modules. Integration testing is an important phase and sometimes there are separate teams which handle integration testing.
 
DEFINITION:Integration testing is a systematic technique for constructing the program structure while at the same time conducting tests to uncover errors associated with interfacing. The objective is to take unit tested components
and build a program structure that has been dictated by design.[http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki1b_4_mv#References]

==Integration Test approaches==
Integration testing can be done in a variety of ways [[Image:TopDown_Approach.jpg|thumb|Top Down Approach]]
# '''Top-Down Approach.''' In this approach the modules higher up in the control hierarchy are integrated first and low-level modules are added later. The advantage of this approach is that the modules with high level logic are tested first and hence bugs in the crucial logic are caught early. Further this approach does not require drivers to be written. Although a number of stubs have to be written and managed
# '''Bottom Up Approach.''' In this approach, the low level modules are integrated first and high level logic is tested late. While integrating the low level modules, the control modules are replaced by dummy modules called as drivers. Thus driver codes have to be written and managed while using this approach. [[Image:BottomUp_Approach.jpg|thumb|Bottom Up Approach]]
# '''Umbrella approach.''' Another approach is called the umbrella approach. It is a hybrid of the top down and the botom up approach, ie both the bottom up and top down approaches are used.In this approach we first test along the functional and control flow paths, for this we use the bottom up approach. The results thus gathered are later integrated in a top down manner. This kind of testing allows creating early prototypes of the system with has limited functionality thereby helping is the creations of the product in an incremental manner. This types of testing also minimizes the use of stubs and drivers which are needed in the top-down and bottom up approaches.
==Prerequisites before Integration Testing==
The system that is being tested, all of its modules should be rigorously tested as a component, i.e they should have gone through unit tests.
==Steps to write good Integration Test Cases==
#Create a Test Plan
#Create test cases and the sample data against which they would be tested.
#If automated tools are being used, scripts should be created.
#After the components have been integrated, start executing the test cases created in point 2.
#Log the bugs found and rectify the same.
#Retest the code.

==How To write good Integration Test Cases and do effective Integration Testing==
The main focus of integration testing is that it needs to check whether the different components are working smoothly and are interacting with each other in the proper manner. The Integration test cases specifically focus on the flow of data/information/control from one component to the other.
A few thing that needs to be kept in mind for effective integration testing are
# Ensure that the correct versions of the components are integrated together.
# Automate the integration of components so that there is lesser chance for human error.
# Log all the errors that have been found and document them with the solutions as well as the version number so that we could keep track of which build was being tested when the error was discovered.

=Beyond Functional and Integration Testing=
[[Image:TestPhase.jpg|thumb|Test Phases]]
Integration and Functional testing are not the only testing that are done for checking the validity of the system. Other test cases includes: 
'''Unit Testing:''' This is the first stage where the developer tests the component he/she is creating. More can be found at [http://en.wikipedia.org/wiki/Unit_testing Unit Testing] 
'''Validation Testing:''' After integration Testing, validation testing takes place wherein checks are made to ensure that the functional requirements are satisfied. 
'''Alpha and Beta Testing:'''When the product about to be released, it is first exposed to some end users who test the application. This is alpha beta testing. More can be found at [http://www.majordojo.com/uploads/AlphaBetaTesting.pdf Alpha and Beta Testing] 
'''Recovery Testing:''' In this phase the system is made to crash and is used to check to see if it recovers in the proper manner. More can be found at [http://en.wikipedia.org/wiki/Recovery_testing Recovery Testing] 
'''Security Testing:''' Systems that store and record sensitive information need to be protected from threats, in this phase the systems protection mechanisms are tested. More can be found at [http://en.wikipedia.org/wiki/Security_testing Security Testing] 
'''Stress Testing:'''The system is overloaded with data and it is checked to whether it crashes. More can be found at [http://en.wikipedia.org/wiki/Stress_testing Stress Testing] 
'''Performance Testing:''' It tests the run time performance of software within the context of the system. More can be found at [http://en.wikipedia.org/wiki/Performance_testing Performance Testing] 
'''Smoke Testing:''' smoke testing is a preliminary to further testing, which should reveal simple failures severe enough to reject a prospective software release. More can be found at [http://en.wikipedia.org/wiki/Smoke_test Smoke Test] 
'''Acceptance Testing:''' acceptance testing performed by the customer is known as user acceptance testing (UAT). This is also known as end-user testing, site (acceptance) testing, or field (acceptance) testing. More can be found at [http://en.wikipedia.org/wiki/Acceptance_testing Acceptance Testing]

=References=

# [http://www.segue.com/pdf/automated_functional_testing.pdf Automated Functional Testing]
# [http://searchsoftwarequality.techtarget.com/generic/0,295582,sid92_gci1303938,00.html# Functional Tests to ensure Software Quality]
# [http://www.developer.com/tech/article.php/3623476/Functional-Test-Plans-The-Right-Way.htm Functional Test Plans]
# Software Engineering: A Practitioner's Approach by Roger S. Pressman ISBN 0073655783

=External Links=

# [http://en.wikipedia.org/wiki/Unit_testing Unit Testing]
# [http://www.majordojo.com/uploads/AlphaBetaTesting.pdf Alpha Beta Testing]
# [http://en.wikipedia.org/wiki/Recovery_testing Recovery Testing]
# [http://en.wikipedia.org/wiki/Security_testing Security Testing]
# [http://en.wikipedia.org/wiki/Stress_testing Stress Testing]
# [http://en.wikipedia.org/wiki/Performance_testing Performance Testing]
# [http://en.wikipedia.org/wiki/Smoke_test Smoke Test]
# [http://en.wikipedia.org/wiki/Acceptance_testing Acceptance Testing]

CSC/ECE 517 Fall 2009/wiki1b 4 mv

2009-09-22T03:09:55Z

Mjampal: /* Steps to write good Functional Tests */

=Introduction=
Unit Testing is given a lot of importance in [[Software Testing]]. But functional and integration testing are essential too. Hence Functional and Integration Testing is discussed here. This page provides an introduction to these testing methods; also including the good practices to write functional and integration tests. Later additional types of software Tests are mentioned which could be used to gain further confidence that one's code is correct.

=Functional Testing=
Functional testing is the process of testing of all the functions of a system, ensuring that the system conforms to the user requirements and specifications. It is sometimes referred to as black box testing, as it does not require understanding of the internal structure of the implementation.

Functional testing can be done by using manual or automated methods[http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki1b_4_mv#References]. In both the methods, a series of tests have to be run marking the interaction between the user and the system, ensuring that the system performs as it was supposed to. Since Use cases mainly depict the interaction between the user and system, functional test suites are created from requirement use cases, with each scenario becoming a functional test[http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki1b_4_mv#References].

==Functional Test Plan==
"The functional test plan measures the quality of the functional components of the system[http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki1b_4_mv#References]". The test plan is written by the Author. The Author lists a number of test cases, containing the input, expected results, and pre and post-test setup. After a module is unit tested, the Tester executes the functional test cases and records the actual results. The Reviewer compares the Actual results with the expected results and reports whether each test case passed or failed the test.

==Steps to write good Functional Tests==
# The test plan must be written by persons who have extensive knowledge of the business requirements. It is advisable that the developers do not write the test plans. This is because developers tend to unknowingly write test cases whose functionality is based on the implementation rather than the initial functional specifications.
# The functional test plans should be created as early as possible, probably as soon as the functional specifications are ready.
# The functional test plan should be updated when there are changes in the business requirements.
# For each functionality, a list of test cases should be defined so that each aspect of the functionality is covered.
# The Author should clearly include the pre-test setup for the test cases so that the Tester can easily execute the test cases.
# Usually the same test cases are run a number of times. Hence after executing a test case, any data added to the system should be cleared as as to not effect further tests or rerunning of the same test case. Hence the Author should also give post-test setup details.
# As a module is built and unit tested, the Tester should execute the particular test cases.

==Example==
Examples of pre-test setup, test cases and post-test setup are given below. The complete reference for the example can be found at [http://www.developer.com/java/ent/article.php/3623476/Functional-Test-Plans-The-Right-Way.htm Functional Test Plans]

The pre-test setup for Test Case: Create new user profile can be given as:
[UserName: "A": --> username: "A"]
[UserName: "A": --> first name: "John"]
[UserName: "A": --> last name: "Smith"]
[UserName: "A": --> access level: "read-only"]
[UserName: "A": --> password: "profile1"]

The test cases for the function:Verify that only valid users can access the system can be given as:

<table cellspacing="2" width=900 border="1" align="center" >
<tr valign="top" bgcolor="#99ffff">
<th>Test Case #</th>
<th>Required Input</th>
<th>Expected Results</th>
<th>Results</th>

<th>Pass/Fail</th></tr>

<tr valign="top"><td colspan="5">
<ul>
<li>Verify that only valid users can access the system.</li>
<li>Verify that valid users cannot access the system without entering a valid password.</li>
</ul></td></tr>

<tr valign="top"><td>1</td>
<td>Navigate to the login screen</td>
<td>Login screen with release number A is loaded.</td>

<td> </td>
<td> </td></tr>

<tr valign="top"><td>2</td>
<td>Enter user name "INVALIDUSER", password "INVALIDUSER", and click on login button</td>
<td>Error message: 
"User name is not found"</td>
<td> </td>
<td> </td></tr>

<tr valign="top"><td>3</td>
<td>Enter user name for user [UserName: "A":--> username] and password "test"</td>

<td>Error Message: 
"Password for user [UserName: "A": --> username] is invalid"</td>
<td> </td>
<td> </td></tr>

<tr valign="top"><td>4</td>
<td>Enter user name [UserName: "A": --> username] and password [UserName: "A": --> password]</td>

<td>The main page is loaded with a message: 
"Welcome [UserName: "A": --> first name] [UserName: "A": --> last name]</td>
<td> </td>
<td> </td></tr>
</table>

The post-test setup for the above scenario can be given as:
Remove [UserName: "A": --> username: "A"] from the LDAP Server.

=Integration Testing=
Integration Testing is a process of testing the application on the whole. After going through the unit testing of the modules, these modules need to be integrated, and during this process things may go wrong, Integration process is the phase wherein these errors are captured and rectified.
It is very common for modules after having successful passed all the unit test cases to fail when they are integrated with other modules. Integration testing is an important phase and sometimes there are separate teams which handle integration testing.
 
DEFINITION:Integration testing is a systematic technique for constructing the program structure while at the same time conducting tests to uncover errors associated with interfacing. The objective is to take unit tested components
and build a program structure that has been dictated by design.[http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki1b_4_mv#References]

==Integration Test approaches==
Integration testing can be done in a variety of ways [[Image:TopDown_Approach.jpg|thumb|Top Down Approach]]
# '''Top-Down Approach.''' In this approach the modules higher up in the control hierarchy are integrated first and low-level modules are added later. The advantage of this approach is that the modules with high level logic are tested first and hence bugs in the crucial logic are caught early. Further this approach does not require drivers to be written. Although a number of stubs have to be written and managed
# '''Bottom Up Approach.''' In this approach, the low level modules are integrated first and high level logic is tested late. While integrating the low level modules, the control modules are replaced by dummy modules called as drivers. Thus driver codes have to be written and managed while using this approach. [[Image:BottomUp_Approach.jpg|thumb|Bottom Up Approach]]
# '''Umbrella approach.''' Another approach is called the umbrella approach. It is a hybrid of the top down and the botom up approach, ie both the bottom up and top down approaches are used.In this approach we first test along the functional and control flow paths, for this we use the bottom up approach. The results thus gathered are later integrated in a top down manner. This kind of testing allows creating early prototypes of the system with has limited functionality thereby helping is the creations of the product in an incremental manner. This types of testing also minimizes the use of stubs and drivers which are needed in the top-down and bottom up approaches.
==Prerequisites before Integration Testing==
The system that is being tested, all of its modules should be rigorously tested as a component, i.e they should have gone through unit tests.
==Steps to write good Integration Test Cases==
#Create a Test Plan
#Create test cases and the sample data against which they would be tested.
#If automated tools are being used, scripts should be created.
#After the components have been integrated, start executing the test cases created in point 2.
#Log the bugs found and rectify the same.
#Retest the code.

==How To write good Integration Test Cases and do effective Integration Testing==
The main focus of integration testing is that it needs to check whether the different components are working smoothly and are interacting with each other in the proper manner. The Integration test cases specifically focus on the flow of data/information/control from one component to the other.
A few thing that needs to be kept in mind for effective integration testing are
# Ensure that the correct versions of the components are integrated together.
# Automate the integration of components so that there is lesser chance for human error.
# Log all the errors that have been found and document them with the solutions as well as the version number so that we could keep track of which build was being tested when the error was discovered.

=Beyond Functional and Integration Testing=
[[Image:TestPhase.jpg|thumb|Test Phases]]
Integration and Functional testing are not the only testing that are done for checking the validity of the system. Other test cases includes: 
'''Unit Testing:''' This is the first stage where the developer tests the component he/she is creating. More can be found at [http://en.wikipedia.org/wiki/Unit_testing Unit Testing] 
'''Validation Testing:''' After integration Testing, validation testing takes place wherein checks are made to ensure that the functional requirements are satisfied. 
'''Alpha and Beta Testing:'''When the product about to be released, it is first exposed to some end users who test the application. This is alpha beta testing. More can be found at [http://www.majordojo.com/uploads/AlphaBetaTesting.pdf Alpha and Beta Testing] 
'''Recovery Testing:''' In this phase the system is made to crash and is used to check to see if it recovers in the proper manner. More can be found at [http://en.wikipedia.org/wiki/Recovery_testing Recovery Testing] 
'''Security Testing:''' Systems that store and record sensitive information need to be protected from threats, in this phase the systems protection mechanisms are tested. More can be found at [http://en.wikipedia.org/wiki/Security_testing Security Testing] 
'''Stress Testing:'''The system is overloaded with data and it is checked to whether it crashes. More can be found at [http://en.wikipedia.org/wiki/Stress_testing Stress Testing] 
'''Performance Testing:''' It tests the run time performance of software within the context of the system. More can be found at [http://en.wikipedia.org/wiki/Performance_testing Performance Testing] 
'''Smoke Testing:''' smoke testing is a preliminary to further testing, which should reveal simple failures severe enough to reject a prospective software release. More can be found at [http://en.wikipedia.org/wiki/Smoke_test Smoke Test] 
'''Acceptance Testing:''' acceptance testing performed by the customer is known as user acceptance testing (UAT). This is also known as end-user testing, site (acceptance) testing, or field (acceptance) testing. More can be found at [http://en.wikipedia.org/wiki/Acceptance_testing Acceptance Testing]

=References=

# [http://www.segue.com/pdf/automated_functional_testing.pdf Automated Functional Testing]
# [http://searchsoftwarequality.techtarget.com/generic/0,295582,sid92_gci1303938,00.html# Functional Tests to ensure Software Quality]
# [http://www.developer.com/tech/article.php/3623476/Functional-Test-Plans-The-Right-Way.htm Functional Test Plans]
# Software Engineering: A Practitioner's Approach by Roger S. Pressman ISBN 0073655783

=External Links=

# [http://en.wikipedia.org/wiki/Unit_testing Unit Testing]
# [http://www.majordojo.com/uploads/AlphaBetaTesting.pdf Alpha Beta Testing]
# [http://en.wikipedia.org/wiki/Recovery_testing Recovery Testing]
# [http://en.wikipedia.org/wiki/Security_testing Security Testing]
# [http://en.wikipedia.org/wiki/Stress_testing Stress Testing]
# [http://en.wikipedia.org/wiki/Performance_testing Performance Testing]
# [http://en.wikipedia.org/wiki/Smoke_test Smoke Test]
# [http://en.wikipedia.org/wiki/Acceptance_testing Acceptance Testing]

CSC/ECE 517 Fall 2009/wiki1b 4 mv

2009-09-22T03:04:25Z

Mjampal: /* References */

=Introduction=
Unit Testing is given a lot of importance in [[Software Testing]]. But functional and integration testing are essential too. Hence Functional and Integration Testing is discussed here. This page provides an introduction to these testing methods; also including the good practices to write functional and integration tests. Later additional types of software Tests are mentioned which could be used to gain further confidence that one's code is correct.

=Functional Testing=
Functional testing is the process of testing of all the functions of a system, ensuring that the system conforms to the user requirements and specifications. It is sometimes referred to as black box testing, as it does not require understanding of the internal structure of the implementation.

Functional testing can be done by using manual or automated methods[http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki1b_4_mv#References]. In both the methods, a series of tests have to be run marking the interaction between the user and the system, ensuring that the system performs as it was supposed to. Since Use cases mainly depict the interaction between the user and system, functional test suites are created from requirement use cases, with each scenario becoming a functional test[http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki1b_4_mv#References].

==Functional Test Plan==
"The functional test plan measures the quality of the functional components of the system[http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki1b_4_mv#References]". The test plan is written by the Author. The Author lists a number of test cases, containing the input, expected results, and pre and post-test setup. After a module is unit tested, the Tester executes the functional test cases and records the actual results. The Reviewer compares the Actual results with the expected results and reports whether each test case passed or failed the test.

==Steps to write good Functional Tests==
# The test plan must be written by persons who have extensive knowledge of the business requirements. It is advisable that the developers do not write the test plans. This is because developers tend to unknowingly write test cases whose functionality is based on the implementation rather than the initial functional specifications.
# The functional test plans should be created as early as possible, probably as soon as the functional specifications are ready.
# The functional test plan should be updated when there are changes in the business requirements.
# For each functionality, a list of test cases should be defined so that each aspect of the functionality is covered.
# The Author should clearly include the pre-test setup for the test cases so that the Tester can easily execute the test cases.
# The Author should also provide post-test setup which has instructions on how to clear any data that would prevent the test case from being executed more than once.
# As a module is built and unit tested, the Tester should execute the particular test cases.

==Example==
Examples of pre-test setup, test cases and post-test setup are given below. The complete reference for the example can be found at [http://www.developer.com/java/ent/article.php/3623476/Functional-Test-Plans-The-Right-Way.htm Functional Test Plans]

The pre-test setup for Test Case: Create new user profile can be given as:
[UserName: "A": --> username: "A"]
[UserName: "A": --> first name: "John"]
[UserName: "A": --> last name: "Smith"]
[UserName: "A": --> access level: "read-only"]
[UserName: "A": --> password: "profile1"]

The test cases for the function:Verify that only valid users can access the system can be given as:

<table cellspacing="2" width=900 border="1" align="center" >
<tr valign="top" bgcolor="#99ffff">
<th>Test Case #</th>
<th>Required Input</th>
<th>Expected Results</th>
<th>Results</th>

<th>Pass/Fail</th></tr>

<tr valign="top"><td colspan="5">
<ul>
<li>Verify that only valid users can access the system.</li>
<li>Verify that valid users cannot access the system without entering a valid password.</li>
</ul></td></tr>

<tr valign="top"><td>1</td>
<td>Navigate to the login screen</td>
<td>Login screen with release number A is loaded.</td>

<td> </td>
<td> </td></tr>

<tr valign="top"><td>2</td>
<td>Enter user name "INVALIDUSER", password "INVALIDUSER", and click on login button</td>
<td>Error message: 
"User name is not found"</td>
<td> </td>
<td> </td></tr>

<tr valign="top"><td>3</td>
<td>Enter user name for user [UserName: "A":--> username] and password "test"</td>

<td>Error Message: 
"Password for user [UserName: "A": --> username] is invalid"</td>
<td> </td>
<td> </td></tr>

<tr valign="top"><td>4</td>
<td>Enter user name [UserName: "A": --> username] and password [UserName: "A": --> password]</td>

<td>The main page is loaded with a message: 
"Welcome [UserName: "A": --> first name] [UserName: "A": --> last name]</td>
<td> </td>
<td> </td></tr>
</table>

The post-test setup for the above scenario can be given as:
Remove [UserName: "A": --> username: "A"] from the LDAP Server.

=Integration Testing=
Integration Testing is a process of testing the application on the whole. After going through the unit testing of the modules, these modules need to be integrated, and during this process things may go wrong, Integration process is the phase wherein these errors are captured and rectified.
It is very common for modules after having successful passed all the unit test cases to fail when they are integrated with other modules. Integration testing is an important phase and sometimes there are separate teams which handle integration testing.
 
DEFINITION:Integration testing is a systematic technique for constructing the program structure while at the same time conducting tests to uncover errors associated with interfacing. The objective is to take unit tested components
and build a program structure that has been dictated by design.[http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki1b_4_mv#References]

==Integration Test approaches==
Integration testing can be done in a variety of ways [[Image:TopDown_Approach.jpg|thumb|Top Down Approach]]
# '''Top-Down Approach.''' In this approach the modules higher up in the control hierarchy are integrated first and low-level modules are added later. The advantage of this approach is that the modules with high level logic are tested first and hence bugs in the crucial logic are caught early. Further this approach does not require drivers to be written. Although a number of stubs have to be written and managed
# '''Bottom Up Approach.''' In this approach, the low level modules are integrated first and high level logic is tested late. While integrating the low level modules, the control modules are replaced by dummy modules called as drivers. Thus driver codes have to be written and managed while using this approach. [[Image:BottomUp_Approach.jpg|thumb|Bottom Up Approach]]
# '''Umbrella approach.''' Another approach is called the umbrella approach. It is a hybrid of the top down and the botom up approach, ie both the bottom up and top down approaches are used.In this approach we first test along the functional and control flow paths, for this we use the bottom up approach. The results thus gathered are later integrated in a top down manner. This kind of testing allows creating early prototypes of the system with has limited functionality thereby helping is the creations of the product in an incremental manner. This types of testing also minimizes the use of stubs and drivers which are needed in the top-down and bottom up approaches.
==Prerequisites before Integration Testing==
The system that is being tested, all of its modules should be rigorously tested as a component, i.e they should have gone through unit tests.
==Steps to write good Integration Test Cases==
#Create a Test Plan
#Create test cases and the sample data against which they would be tested.
#If automated tools are being used, scripts should be created.
#After the components have been integrated, start executing the test cases created in point 2.
#Log the bugs found and rectify the same.
#Retest the code.

==How To write good Integration Test Cases and do effective Integration Testing==
The main focus of integration testing is that it needs to check whether the different components are working smoothly and are interacting with each other in the proper manner. The Integration test cases specifically focus on the flow of data/information/control from one component to the other.
A few thing that needs to be kept in mind for effective integration testing are
# Ensure that the correct versions of the components are integrated together.
# Automate the integration of components so that there is lesser chance for human error.
# Log all the errors that have been found and document them with the solutions as well as the version number so that we could keep track of which build was being tested when the error was discovered.

=Beyond Functional and Integration Testing=
[[Image:TestPhase.jpg|thumb|Test Phases]]
Integration and Functional testing are not the only testing that are done for checking the validity of the system. Other test cases includes: 
'''Unit Testing:''' This is the first stage where the developer tests the component he/she is creating. More can be found at [http://en.wikipedia.org/wiki/Unit_testing Unit Testing] 
'''Validation Testing:''' After integration Testing, validation testing takes place wherein checks are made to ensure that the functional requirements are satisfied. 
'''Alpha and Beta Testing:'''When the product about to be released, it is first exposed to some end users who test the application. This is alpha beta testing. More can be found at [http://www.majordojo.com/uploads/AlphaBetaTesting.pdf Alpha and Beta Testing] 
'''Recovery Testing:''' In this phase the system is made to crash and is used to check to see if it recovers in the proper manner. More can be found at [http://en.wikipedia.org/wiki/Recovery_testing Recovery Testing] 
'''Security Testing:''' Systems that store and record sensitive information need to be protected from threats, in this phase the systems protection mechanisms are tested. More can be found at [http://en.wikipedia.org/wiki/Security_testing Security Testing] 
'''Stress Testing:'''The system is overloaded with data and it is checked to whether it crashes. More can be found at [http://en.wikipedia.org/wiki/Stress_testing Stress Testing] 
'''Performance Testing:''' It tests the run time performance of software within the context of the system. More can be found at [http://en.wikipedia.org/wiki/Performance_testing Performance Testing] 
'''Smoke Testing:''' smoke testing is a preliminary to further testing, which should reveal simple failures severe enough to reject a prospective software release. More can be found at [http://en.wikipedia.org/wiki/Smoke_test Smoke Test] 
'''Acceptance Testing:''' acceptance testing performed by the customer is known as user acceptance testing (UAT). This is also known as end-user testing, site (acceptance) testing, or field (acceptance) testing. More can be found at [http://en.wikipedia.org/wiki/Acceptance_testing Acceptance Testing]

=References=

# [http://www.segue.com/pdf/automated_functional_testing.pdf Automated Functional Testing]
# [http://searchsoftwarequality.techtarget.com/generic/0,295582,sid92_gci1303938,00.html# Functional Tests to ensure Software Quality]
# [http://www.developer.com/tech/article.php/3623476/Functional-Test-Plans-The-Right-Way.htm Functional Test Plans]
# Software Engineering: A Practitioner's Approach by Roger S. Pressman ISBN 0073655783

=External Links=

# [http://en.wikipedia.org/wiki/Unit_testing Unit Testing]
# [http://www.majordojo.com/uploads/AlphaBetaTesting.pdf Alpha Beta Testing]
# [http://en.wikipedia.org/wiki/Recovery_testing Recovery Testing]
# [http://en.wikipedia.org/wiki/Security_testing Security Testing]
# [http://en.wikipedia.org/wiki/Stress_testing Stress Testing]
# [http://en.wikipedia.org/wiki/Performance_testing Performance Testing]
# [http://en.wikipedia.org/wiki/Smoke_test Smoke Test]
# [http://en.wikipedia.org/wiki/Acceptance_testing Acceptance Testing]