Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2013/oss fmv

2013-10-31T01:55:25Z

Mjoshi: /* Summary */

[[File:sahana.jpg|right]]
This project is developed as a contribution to Sahana Software Foundation (Eden).

==History==

Sahana Software Foundation was originally developed by members of the Sri Lankan IT community who wanted to apply their talent and help their country to recover from the aftermath of 2004 Indian Ocean earthquake and tsunami. The word “Sahana” means “relief” in Sinhalese, one of the national language of Sri Lanka. Sahana community has since grown to include experts from emergency and disaster management as partners in software development process. This is one of the unique strength of Sahana Software Foundation.

Under the stewardship of "The Lanka Software Foundation (LSF)", Sahana Software grew into a free and open source software project. Hundreds of volunteers, contribute and support both local and national relief agencies in their response to numerous large-scale, sudden-onset disasters. The Sahana Software Foundation was established in 2009 as a non-profit organization, registered in the State of California to serve diverse group of customers. SSF partners together with disaster and technologies experts address following questions:

How can an urgent requirement be effectively communicated to international donor community?

How can responsible authorities find hospitals that can accommodate more patients?

How can family members be reunited who were separated during evacuation?

==Description and Objective==
Sahana Eden can be used to collect and manage a large variety of data. For the data to be useful and share-able, it needs to be presented in a way that can help users to make decisions and plan activities. To achieve this Sahana Eden produce reports that are flexible and user friendly.

Reports can be in the form of: Pivot Table, Bar Chart, or Pie chart. The objective of the project is to export reports in the form of downloadable format, so that user can see view reports offline. Currently we focused on exporting reports to PDF.

[[File:userscreen.png]]

[[File:samplepdf.png]]

==Design==
[[File:classDiagram.png]]

==Setup (Installation)==

Sahana Eden can be installed on different operating systems:Linux,Windows,Mac. Sahana Eden is written in Javascript, Perl, HTML, Python. To run Eden then you will need to run Python. Sahana Eden requires web2py framework. Eden uses SQLite database. Sahana Eden can be easily deployed on Amazon EC2, Heroku. Pycharm IDE can be used for development.

To contribute to Eden foundation, you can fork repository from
https://github.com/flavour/eden

==Implementation==
Exporting of reports is implemented using java script.

The base class Exporter is defined as:

<pre>
function Exporter(exp)
{
this.exporter = exp;
this.tableExporter = null;
}

Exporter.prototype.setExporter = function(exp)
{
this.exporter = exp;
}

Exporter.prototype.setTableExporter = function(exporter)
{
this.tableExporter = exporter;
}

Exporter.prototype.renderTable = function()
{
this.tableExporter.render();
}
</pre>

Currently we are focusing on exporting reports to PDF. PdfExporter Class serves this purpose. It is a sub-class of Exporter Class.

<pre>

function PdfExporter(exp)
{
this.exporter = exp;
}

PdfExporter.prototype = new Exporter();

PdfExporter.prototype.getPdf = function()
{
return this.exporter;
}

PdfExporter.prototype.export = function(imageObj, json)
{
this.exportImage(imageObj);
this.exportPivotTable(json);
}

PdfExporter.prototype.exportImage = function(imageObj)
{
this.exporter.pageAdd();

// load image from canvas into BytescoutPDF

this.exporter.imageLoadFromUrl(imageObj);

// place this mage at given coordinates and dimesionson on the page
this.exporter.imagePlaceSetSize(50, 50, 0, 750, 500);
}

PdfExporter.prototype.exportPivotTable = function(json)
{
this.exporter.pageAdd();

if(this.tableExporter == null || this.tableExporter == undefined)
{
this.setTableExporter(new PdfTableRenderer(json, this.exporter));
}

this.renderTable();
}

</pre>

Now, tableExporter is written only for table creation in Pdf. This can even be used for table creation in XLS or RSS or so. Thus, we use strategy pattern here using below classes.

Table renderer is defined as below:

<pre>
function TableRenderer()
{
this.X = 50;
this.Y = 50;
this.PageWidth = 750;
this.PageHeight = 500;
this.numcols = 0;
}

TableRenderer.prototype.constructor = function(json_data, exp)
{
this.json = json_data;
this.exporter = exp;
}

TableRenderer.prototype.render = function()
{
// this method is abstract and does nothing
}

</pre>

And Pdf table renderer having functionality of exporting table to Pdf, is defined as:

<pre>
function PdfTableRenderer(json_data, exp)
{
this.json = json_data;
this.exporter = exp;
}

PdfTableRenderer.prototype = new TableRenderer();

PdfTableRenderer.prototype.render = function()
{
// render code here
}
</pre>

By setting TableRenderer in Exporter class to an instance of PdfTableRenderer, we are making use of strategy pattern here. TableRenderer can be extended for XLS by writing (say) XLSTableRenderer class which inherits from TableRenderer and overrides the render() method.

At last, the final Pdf object which needs to be downloaded, is generated by PdfFactory. Here we have used Factory pattern to achieve the same. getPdf() method of PdfFactory hides all the implementation details from outside of the library.

PdfFactory is defined as:

<pre>
function PdfFactory()
{

}

PdfFactory.getPdf = function()
{
//... code to extract canvas image

var pe = new PdfExporter(pdf);

pe.export(dataURL, json_data);

return pe.getPdf(); // gets final pdf object
}

</pre>

==Dependency==

The code makes use of following external java-script libraries to achieve the objective.

===html2canvas.js===

The purpose of this file is to take "screenshots" of webpages or parts of it opened on users' browser. The screenshot is created by parsing several DOM objects.

===bytescoutpdf.js===

The purpose of this client-side Javascript library to generate PDF with text, images and graphics.It Works with mainstream desktop and mobile browsers, iPhone and iPad.

==Future==

Future development of the project can be implementation of following functionalities.

===Export to Excel File===

Currently our work is restricted to exporting graph and pivot table(generated interactively by user) to a PDF. In future, graphs and pivot table can be exported to an excel(.xls). Exporting to an excel will require significant amount of effort as excels are interactive. User should be able to manipulate the generated excel document.(Not required in the case of PDF as they are static).
XLS would ideally include raw Data on one or more sheets, the Pivot table on another sheet & Graphs on one or more additional sheets. The Pivot Table & Graphs should be linked to the raw data using XLS functionality.

===Subscription===

A user can subscribe to receive reports daily/weekly/monthly through emails. The format of this report can be PDF or Excel.

==External Links==

:1. [https://github.com/flavour/eden Git repository]
:2. [http://demo.eden.sahanafoundation.org/eden/ Sahana Eden Demo]
:3. [http://bytescout.com/ Bytescout]
:4. [http://html2canvas.hertzen.com/ Html2Canvas]

CSC/ECE 517 Fall 2013/oss fmv

2013-10-31T01:54:26Z

Mjoshi: /* Implementation */

[[File:sahana.jpg|right]]
This project is developed as a contribution to Sahana Software Foundation (Eden).

==History==

Sahana Software Foundation was originally developed by members of the Sri Lankan IT community who wanted to apply their talent and help their country to recover from the aftermath of 2004 Indian Ocean earthquake and tsunami. The word “Sahana” means “relief” in Sinhalese, one of the national language of Sri Lanka. Sahana community has since grown to include experts from emergency and disaster management as partners in software development process. This is one of the unique strength of Sahana Software Foundation.

Under the stewardship of "The Lanka Software Foundation (LSF)", Sahana Software grew into a free and open source software project. Hundreds of volunteers, contribute and support both local and national relief agencies in their response to numerous large-scale, sudden-onset disasters. The Sahana Software Foundation was established in 2009 as a non-profit organization, registered in the State of California to serve diverse group of customers. SSF partners together with disaster and technologies experts address following questions:

How can an urgent requirement be effectively communicated to international donor community?

How can responsible authorities find hospitals that can accommodate more patients?

How can family members be reunited who were separated during evacuation?

==Description and Objective==
Sahana Eden can be used to collect and manage a large variety of data. For the data to be useful and share-able, it needs to be presented in a way that can help users to make decisions and plan activities. To achieve this Sahana Eden produce reports that are flexible and user friendly.

Reports can be in the form of: Pivot Table, Bar Chart, or Pie chart. The objective of the project is to export reports in the form of downloadable format, so that user can see view reports offline. Currently we focused on exporting reports to PDF.

[[File:userscreen.png]]

[[File:samplepdf.png]]

==Design==
[[File:classDiagram.png]]

==Setup (Installation)==

Sahana Eden can be installed on different operating systems:Linux,Windows,Mac. Sahana Eden is written in Javascript, Perl, HTML, Python. To run Eden then you will need to run Python. Sahana Eden requires web2py framework. Eden uses SQLite database. Sahana Eden can be easily deployed on Amazon EC2, Heroku. Pycharm IDE can be used for development.

To contribute to Eden foundation, you can fork repository from
https://github.com/flavour/eden

==Implementation==
Exporting of reports is implemented using java script.

The base class Exporter is defined as:

<pre>
function Exporter(exp)
{
this.exporter = exp;
this.tableExporter = null;
}

Exporter.prototype.setExporter = function(exp)
{
this.exporter = exp;
}

Exporter.prototype.setTableExporter = function(exporter)
{
this.tableExporter = exporter;
}

Exporter.prototype.renderTable = function()
{
this.tableExporter.render();
}
</pre>

Currently we are focusing on exporting reports to PDF. PdfExporter Class serves this purpose. It is a sub-class of Exporter Class.

<pre>

function PdfExporter(exp)
{
this.exporter = exp;
}

PdfExporter.prototype = new Exporter();

PdfExporter.prototype.getPdf = function()
{
return this.exporter;
}

PdfExporter.prototype.export = function(imageObj, json)
{
this.exportImage(imageObj);
this.exportPivotTable(json);
}

PdfExporter.prototype.exportImage = function(imageObj)
{
this.exporter.pageAdd();

// load image from canvas into BytescoutPDF

this.exporter.imageLoadFromUrl(imageObj);

// place this mage at given coordinates and dimesionson on the page
this.exporter.imagePlaceSetSize(50, 50, 0, 750, 500);
}

PdfExporter.prototype.exportPivotTable = function(json)
{
this.exporter.pageAdd();

if(this.tableExporter == null || this.tableExporter == undefined)
{
this.setTableExporter(new PdfTableRenderer(json, this.exporter));
}

this.renderTable();
}

</pre>

Now, tableExporter is written only for table creation in Pdf. This can even be used for table creation in XLS or RSS or so. Thus, we use strategy pattern here using below classes.

Table renderer is defined as below:

<pre>
function TableRenderer()
{
this.X = 50;
this.Y = 50;
this.PageWidth = 750;
this.PageHeight = 500;
this.numcols = 0;
}

TableRenderer.prototype.constructor = function(json_data, exp)
{
this.json = json_data;
this.exporter = exp;
}

TableRenderer.prototype.render = function()
{
// this method is abstract and does nothing
}

</pre>

And Pdf table renderer having functionality of exporting table to Pdf, is defined as:

<pre>
function PdfTableRenderer(json_data, exp)
{
this.json = json_data;
this.exporter = exp;
}

PdfTableRenderer.prototype = new TableRenderer();

PdfTableRenderer.prototype.render = function()
{
// render code here
}
</pre>

By setting TableRenderer in Exporter class to an instance of PdfTableRenderer, we are making use of strategy pattern here. TableRenderer can be extended for XLS by writing (say) XLSTableRenderer class which inherits from TableRenderer and overrides the render() method.

At last, the final Pdf object which needs to be downloaded, is generated by PdfFactory. Here we have used Factory pattern to achieve the same. getPdf() method of PdfFactory hides all the implementation details from outside of the library.

PdfFactory is defined as:

<pre>
function PdfFactory()
{

}

PdfFactory.getPdf = function()
{
//... code to extract canvas image

var pe = new PdfExporter(pdf);

pe.export(dataURL, json_data);

return pe.getPdf(); // gets final pdf object
}

</pre>

==Dependency==

The code makes use of following external java-script libraries to achieve the objective.

===html2canvas.js===

The purpose of this file is to take "screenshots" of webpages or parts of it opened on users' browser. The screenshot is created by parsing several DOM objects.

===bytescoutpdf.js===

The purpose of this client-side Javascript library to generate PDF with text, images and graphics.It Works with mainstream desktop and mobile browsers, iPhone and iPad.

==Summary==

==Future==

Future development of the project can be implementation of following functionalities.

===Export to Excel File===

Currently our work is restricted to exporting graph and pivot table(generated interactively by user) to a PDF. In future, graphs and pivot table can be exported to an excel(.xls). Exporting to an excel will require significant amount of effort as excels are interactive. User should be able to manipulate the generated excel document.(Not required in the case of PDF as they are static).
XLS would ideally include raw Data on one or more sheets, the Pivot table on another sheet & Graphs on one or more additional sheets. The Pivot Table & Graphs should be linked to the raw data using XLS functionality.

===Subscription===

A user can subscribe to receive reports daily/weekly/monthly through emails. The format of this report can be PDF or Excel.

==External Links==

:1. [https://github.com/flavour/eden Git repository]
:2. [http://demo.eden.sahanafoundation.org/eden/ Sahana Eden Demo]
:3. [http://bytescout.com/ Bytescout]
:4. [http://html2canvas.hertzen.com/ Html2Canvas]

CSC/ECE 517 Fall 2013/oss fmv

2013-10-31T01:53:34Z

Mjoshi: /* Implementation */

[[File:sahana.jpg|right]]
This project is developed as a contribution to Sahana Software Foundation (Eden).

==History==

Sahana Software Foundation was originally developed by members of the Sri Lankan IT community who wanted to apply their talent and help their country to recover from the aftermath of 2004 Indian Ocean earthquake and tsunami. The word “Sahana” means “relief” in Sinhalese, one of the national language of Sri Lanka. Sahana community has since grown to include experts from emergency and disaster management as partners in software development process. This is one of the unique strength of Sahana Software Foundation.

Under the stewardship of "The Lanka Software Foundation (LSF)", Sahana Software grew into a free and open source software project. Hundreds of volunteers, contribute and support both local and national relief agencies in their response to numerous large-scale, sudden-onset disasters. The Sahana Software Foundation was established in 2009 as a non-profit organization, registered in the State of California to serve diverse group of customers. SSF partners together with disaster and technologies experts address following questions:

How can an urgent requirement be effectively communicated to international donor community?

How can responsible authorities find hospitals that can accommodate more patients?

How can family members be reunited who were separated during evacuation?

==Description and Objective==
Sahana Eden can be used to collect and manage a large variety of data. For the data to be useful and share-able, it needs to be presented in a way that can help users to make decisions and plan activities. To achieve this Sahana Eden produce reports that are flexible and user friendly.

Reports can be in the form of: Pivot Table, Bar Chart, or Pie chart. The objective of the project is to export reports in the form of downloadable format, so that user can see view reports offline. Currently we focused on exporting reports to PDF.

[[File:userscreen.png]]

[[File:samplepdf.png]]

==Design==
[[File:classDiagram.png]]

==Setup (Installation)==

Sahana Eden can be installed on different operating systems:Linux,Windows,Mac. Sahana Eden is written in Javascript, Perl, HTML, Python. To run Eden then you will need to run Python. Sahana Eden requires web2py framework. Eden uses SQLite database. Sahana Eden can be easily deployed on Amazon EC2, Heroku. Pycharm IDE can be used for development.

To contribute to Eden foundation, you can fork repository from
https://github.com/flavour/eden

==Implementation==
Exporting of reports is implemented using java script.

The base class Exporter is defined as:

<pre>
function Exporter(exp)
{
this.exporter = exp;
this.tableExporter = null;
}

Exporter.prototype.setExporter = function(exp)
{
this.exporter = exp;
}

Exporter.prototype.setTableExporter = function(exporter)
{
this.tableExporter = exporter;
}

Exporter.prototype.renderTable = function()
{
this.tableExporter.render();
}
</pre>

Currently we are focusing on exporting reports to PDF. PdfExporter Class serves this purpose. It is a sub-class of Exporter Class.

<pre>

function PdfExporter(exp)
{
this.exporter = exp;
}

PdfExporter.prototype = new Exporter();

PdfExporter.prototype.getPdf = function()
{
return this.exporter;
}

PdfExporter.prototype.export = function(imageObj, json)
{
this.exportImage(imageObj);
this.exportPivotTable(json);
}

PdfExporter.prototype.exportImage = function(imageObj)
{
this.exporter.pageAdd();

// load image from canvas into BytescoutPDF

this.exporter.imageLoadFromUrl(imageObj);

// place this mage at given coordinates and dimesionson on the page
this.exporter.imagePlaceSetSize(50, 50, 0, 750, 500);
}

PdfExporter.prototype.exportPivotTable = function(json)
{
this.exporter.pageAdd();

if(this.tableExporter == null || this.tableExporter == undefined)
{
this.setTableExporter(new PdfTableRenderer(json, this.exporter));
}

this.renderTable();
}

</pre>

Now, tableExporter is written only for table creation in Pdf. This can even be used for table creation in XLS or RSS or so. Thus, we use strategy pattern here.

Table renderer is defined as below:

<pre>
function TableRenderer()
{
this.X = 50;
this.Y = 50;
this.PageWidth = 750;
this.PageHeight = 500;
this.numcols = 0;
}

TableRenderer.prototype.constructor = function(json_data, exp)
{
this.json = json_data;
this.exporter = exp;
}

TableRenderer.prototype.render = function()
{
// this method is abstract and does nothing
}

</pre>

And Pdf table renderer having functionality of exporting table to Pdf, is defined as:

<pre>
function PdfTableRenderer(json_data, exp)
{
this.json = json_data;
this.exporter = exp;
}

PdfTableRenderer.prototype = new TableRenderer();

PdfTableRenderer.prototype.render = function()
{
// render code here
}
</pre>

By setting TableRenderer in Exporter class to an instance of PdfTableRenderer, we are making use of strategy pattern here. TableRenderer can be extended for XLS by writing (say) XLSTableRenderer class which inherits from TableRenderer and overrides the render() method.

At last, the final Pdf object which needs to be downloaded, is generated by PdfFactory. Here we have used Factory pattern to achieve the same. getPdf() method of PdfFactory hides all the implementation details from outside of the library.

PdfFactory is defined as:

<pre>
function PdfFactory()
{

}

PdfFactory.getPdf = function()
{
//... code to extract canvas image

var pe = new PdfExporter(pdf);

pe.export(dataURL, json_data);

return pe.getPdf(); // gets final pdf object
}

</pre>

==Dependency==

The code makes use of following external java-script libraries to achieve the objective.

===html2canvas.js===

The purpose of this file is to take "screenshots" of webpages or parts of it opened on users' browser. The screenshot is created by parsing several DOM objects.

===bytescoutpdf.js===

The purpose of this client-side Javascript library to generate PDF with text, images and graphics.It Works with mainstream desktop and mobile browsers, iPhone and iPad.

==Summary==

==Future==

Future development of the project can be implementation of following functionalities.

===Export to Excel File===

Currently our work is restricted to exporting graph and pivot table(generated interactively by user) to a PDF. In future, graphs and pivot table can be exported to an excel(.xls). Exporting to an excel will require significant amount of effort as excels are interactive. User should be able to manipulate the generated excel document.(Not required in the case of PDF as they are static).
XLS would ideally include raw Data on one or more sheets, the Pivot table on another sheet & Graphs on one or more additional sheets. The Pivot Table & Graphs should be linked to the raw data using XLS functionality.

===Subscription===

A user can subscribe to receive reports daily/weekly/monthly through emails. The format of this report can be PDF or Excel.

==External Links==

:1. [https://github.com/flavour/eden Git repository]
:2. [http://demo.eden.sahanafoundation.org/eden/ Sahana Eden Demo]
:3. [http://bytescout.com/ Bytescout]
:4. [http://html2canvas.hertzen.com/ Html2Canvas]

CSC/ECE 517 Fall 2013/oss fmv

2013-10-31T01:49:45Z

Mjoshi: /* Description and Objective */

[[File:sahana.jpg|right]]
This project is developed as a contribution to Sahana Software Foundation (Eden).

==History==

Sahana Software Foundation was originally developed by members of the Sri Lankan IT community who wanted to apply their talent and help their country to recover from the aftermath of 2004 Indian Ocean earthquake and tsunami. The word “Sahana” means “relief” in Sinhalese, one of the national language of Sri Lanka. Sahana community has since grown to include experts from emergency and disaster management as partners in software development process. This is one of the unique strength of Sahana Software Foundation.

Under the stewardship of "The Lanka Software Foundation (LSF)", Sahana Software grew into a free and open source software project. Hundreds of volunteers, contribute and support both local and national relief agencies in their response to numerous large-scale, sudden-onset disasters. The Sahana Software Foundation was established in 2009 as a non-profit organization, registered in the State of California to serve diverse group of customers. SSF partners together with disaster and technologies experts address following questions:

How can an urgent requirement be effectively communicated to international donor community?

How can responsible authorities find hospitals that can accommodate more patients?

How can family members be reunited who were separated during evacuation?

==Description and Objective==
Sahana Eden can be used to collect and manage a large variety of data. For the data to be useful and share-able, it needs to be presented in a way that can help users to make decisions and plan activities. To achieve this Sahana Eden produce reports that are flexible and user friendly.

Reports can be in the form of: Pivot Table, Bar Chart, or Pie chart. The objective of the project is to export reports in the form of downloadable format, so that user can see view reports offline. Currently we focused on exporting reports to PDF.

[[File:userscreen.png]]

[[File:samplepdf.png]]

==Design==
[[File:classDiagram.png]]

==Setup (Installation)==

Sahana Eden can be installed on different operating systems:Linux,Windows,Mac. Sahana Eden is written in Javascript, Perl, HTML, Python. To run Eden then you will need to run Python. Sahana Eden requires web2py framework. Eden uses SQLite database. Sahana Eden can be easily deployed on Amazon EC2, Heroku. Pycharm IDE can be used for development.

To contribute to Eden foundation, you can fork repository from
https://github.com/flavour/eden

==Implementation==
Exporting of reports is implemented using java script.

The base class is Exporter, defined as:

<pre>
function Exporter(exp)
{
this.exporter = exp;
this.tableExporter = null;
}

Exporter.prototype.setExporter = function(exp)
{
this.exporter = exp;
}

Exporter.prototype.setTableExporter = function(exporter)
{
this.tableExporter = exporter;
}

Exporter.prototype.renderTable = function()
{
this.tableExporter.render();
}
</pre>

Currently we are focusing on exporting report to a PDF. PdfExporter Class serves this purpose. It is a sub-class of Exporter Class

<pre>

function PdfExporter(exp)
{
this.exporter = exp;
}

PdfExporter.prototype = new Exporter();

PdfExporter.prototype.getPdf = function()
{
return this.exporter;
}

PdfExporter.prototype.export = function(imageObj, json)
{
this.exportImage(imageObj);
this.exportPivotTable(json);
}

PdfExporter.prototype.exportImage = function(imageObj)
{
this.exporter.pageAdd();

// load image from canvas into BytescoutPDF

this.exporter.imageLoadFromUrl(imageObj);

// place this mage at given coordinates and dimesionson on the page
this.exporter.imagePlaceSetSize(50, 50, 0, 750, 500);
}

PdfExporter.prototype.exportPivotTable = function(json)
{
this.exporter.pageAdd();

if(this.tableExporter == null || this.tableExporter == undefined)
{
this.setTableExporter(new PdfTableRenderer(json, this.exporter));
}

this.renderTable();
}

</pre>

Now, Table exporter is written only for table creation in Pdf. This can even be used for table creation in XLS or RSS or so. Thus, we use strategy pattern here.

Table renderer is defined as below:

<pre>
function TableRenderer()
{
this.X = 50;
this.Y = 50;
this.PageWidth = 750;
this.PageHeight = 500;
this.numcols = 0;
}

TableRenderer.prototype.constructor = function(json_data, exp)
{
this.json = json_data;
this.exporter = exp;
}

TableRenderer.prototype.render = function()
{
// this method is abstract and does nothing
}

</pre>

And Pdf table renderer having functionality of exporting table to Pdf, is defined as:

<pre>
function PdfTableRenderer(json_data, exp)
{
this.json = json_data;
this.exporter = exp;
}

PdfTableRenderer.prototype = new TableRenderer();

PdfTableRenderer.prototype.render = function()
{
// render code here
}
</pre>

By setting TableRenderer in Exporter class to an instance of PdfTableRenderer, we are reusing the code. TableRenderer can be extended for XLS by writing XLSTableRenderer class which inherits from TableRenderer and overrides the render() method.

At last, the final Pdf object which needs to be downloaded, is generated by PdfFactory. Here we have used Factory pattern to achieve the same. getPdf() method of PdfFactory hides all the implementation details from outside of the library.

PdfFactory is defined as:

<pre>
function PdfFactory()
{

}

PdfFactory.getPdf = function()
{
//... code to extract canvas image

var pe = new PdfExporter(pdf);

pe.export(dataURL, json_data);

return pe.getPdf(); // gets final pdf object
}

</pre>

==Dependency==

The code makes use of following external java-script libraries to achieve the objective.

===html2canvas.js===

The purpose of this file is to take "screenshots" of webpages or parts of it opened on users' browser. The screenshot is created by parsing several DOM objects.

===bytescoutpdf.js===

The purpose of this client-side Javascript library to generate PDF with text, images and graphics.It Works with mainstream desktop and mobile browsers, iPhone and iPad.

==Summary==

==Future==

Future development of the project can be implementation of following functionalities.

===Export to Excel File===

Currently our work is restricted to exporting graph and pivot table(generated interactively by user) to a PDF. In future, graphs and pivot table can be exported to an excel(.xls). Exporting to an excel will require significant amount of effort as excels are interactive. User should be able to manipulate the generated excel document.(Not required in the case of PDF as they are static).
XLS would ideally include raw Data on one or more sheets, the Pivot table on another sheet & Graphs on one or more additional sheets. The Pivot Table & Graphs should be linked to the raw data using XLS functionality.

===Subscription===

A user can subscribe to receive reports daily/weekly/monthly through emails. The format of this report can be PDF or Excel.

==External Links==

:1. [https://github.com/flavour/eden Git repository]
:2. [http://demo.eden.sahanafoundation.org/eden/ Sahana Eden Demo]
:3. [http://bytescout.com/ Bytescout]
:4. [http://html2canvas.hertzen.com/ Html2Canvas]

CSC/ECE 517 Fall 2013/oss fmv

2013-10-31T00:17:47Z

Mjoshi: /* Implementation */

This project is developed as a contribution to Sahana Software Foundation (Eden).

==History==

Sahana Software Foundation was originally developed by members of the Sri Lankan IT community who wanted to apply their talent and help their country to recover from the aftermath of 2004 Indian Ocean earthquake and tsunami. The word “Sahana” means “relief” in Sinhalese, one of the national language of Sri Lanka. Sahana community has since grown to include experts from emergency and disaster management as partners in software development process. This is one of the unique strength of Sahana Software Foundation.

Under the stewardship of "The Lanka Software Foundation (LSF)", Sahana Software grew into a free and open source software project. Hundreds of volunteers, contribute and support both local and national relief agencies in their response to numerous large-scale, sudden-onset disasters. The Sahana Software Foundation was established in 2009 as a non-profit organization, registered in the State of California to serve diverse group of customers. SSF partners together with disaster and technologies experts address following questions:

How can an urgent requirement be effectively communicated to international donor community?

How can responsible authorities find hospitals that can accommodate more patients?

How can family members be reunited who were separated during evacuation?

==Description and Objective==
Sahana Eden can be used to collect and manage a large variety of data. For the data to be useful and share-able, it needs to be presented in a way that can help users to make decisions and plan activities. To achieve this Sahana Eden produce reports that are flexible and user friendly.

Reports can be in the form of: Pivot Table, Bar Chart, or Pie chart. The objective of the project is to export reports in the form of downloadable format, so that user can see view reports offline. Currently we focused on exporting report to a PDF.

==Design==

==Setup (Installation)==

Sahana Eden can be installed on different operating systems:Linux,Windows,Mac. Sahana Eden is written in Javascript, Perl, HTML, Python. To run Eden then you will need to run Python. Sahana Eden requires web2py framework. Eden uses SQLite database. Sahana Eden can be easily deployed on Amazon EC2, Heroku. Pycharm IDE can be used for development.

To contribute to Eden foundation, you can fork repository from
https://github.com/flavour/eden

==Implementation==
Exporting of reports is implemented using java script.

The base class is Exporter, defined as:

[[File:classDiagram.jpg]]

<pre>
function Exporter(exp)
{
this.exporter = exp;
this.tableExporter = null;
}

Exporter.prototype.setExporter = function(exp)
{
this.exporter = exp;
}

Exporter.prototype.setTableExporter = function(exporter)
{
this.tableExporter = exporter;
}

Exporter.prototype.renderTable = function()
{
this.tableExporter.render();
}
</pre>

Currently we are focusing on exporting report to a PDF. PdfExporter Class serves this purpose. It is a sub-class of Exporter Class

<pre>

function PdfExporter(exp)
{
this.exporter = exp;
}

PdfExporter.prototype = new Exporter();

PdfExporter.prototype.getPdf = function()
{
return this.exporter;
}

PdfExporter.prototype.export = function(imageObj, json)
{
this.exportImage(imageObj);
this.exportPivotTable(json);
}

PdfExporter.prototype.exportImage = function(imageObj)
{
this.exporter.pageAdd();

// load image from canvas into BytescoutPDF

this.exporter.imageLoadFromUrl(imageObj);

// place this mage at given coordinates and dimesionson on the page
this.exporter.imagePlaceSetSize(50, 50, 0, 750, 500);
}

PdfExporter.prototype.exportPivotTable = function(json)
{
this.exporter.pageAdd();

if(this.tableExporter == null || this.tableExporter == undefined)
{
this.setTableExporter(new PdfTableRenderer(json, this.exporter));
}

this.renderTable();
}

</pre>

Now, Table exporter is written only for table creation in Pdf. This can even be used for table creation in XLS or RSS or so. Thus, we use strategy pattern here.

Table renderer is defined as below:

<pre>
function TableRenderer()
{
this.X = 50;
this.Y = 50;
this.PageWidth = 750;
this.PageHeight = 500;
this.numcols = 0;
}

TableRenderer.prototype.constructor = function(json_data, exp)
{
this.json = json_data;
this.exporter = exp;
}

TableRenderer.prototype.render = function()
{
// this method is abstract and does nothing
}

</pre>

And Pdf table renderer having functionality of exporting table to Pdf, is defined as:

<pre>
function PdfTableRenderer(json_data, exp)
{
this.json = json_data;
this.exporter = exp;
}

PdfTableRenderer.prototype = new TableRenderer();

PdfTableRenderer.prototype.render = function()
{
// render code here
}
</pre>

By setting TableRenderer in Exporter class to an instance of PdfTableRenderer, we are reusing the code. TableRenderer can be extended for XLS by writing XLSTableRenderer class which inherits from TableRenderer and overrides the render() method.

At last, the final Pdf object which needs to be downloaded, is generated by PdfFactory. Here we have used Factory pattern to achieve the same. getPdf() method of PdfFactory hides all the implementation details from outside of the library.

PdfFactory is defined as:

<pre>
function PdfFactory()
{

}

PdfFactory.getPdf = function()
{
//... code to extract canvas image

var pe = new PdfExporter(pdf);

pe.export(dataURL, json_data);

return pe.getPdf(); // gets final pdf object
}

</pre>

==Dependency==

The code makes use of following external java-script libraries to achieve the objective.

===html2canvas.js===

The purpose of this file is to take "screenshots" of webpages or parts of it opened on users' browser. The screenshot is created by parsing several DOM objects.

===bytescoutpdf.js===

The purpose of this client-side Javascript library to generate PDF with text, images and graphics.It Works with mainstream desktop and mobile browsers, iPhone and iPad.

==Summary==

==Future==

Future development of the project can be implementation of following functionalities.

===Export to Excel File===

Currently our work is restricted to exporting graph and pivot table(generated interactively by user) to a PDF. In future, graphs and pivot table can be exported to an excel(.xls). Exporting to an excel will require significant amount of effort as excels are interactive. User should be able to manipulate the generated excel document.(Not required in the case of PDF as they are static).
XLS would ideally include raw Data on one or more sheets, the Pivot table on another sheet & Graphs on one or more additional sheets. The Pivot Table & Graphs should be linked to the raw data using XLS functionality.

===Subscription===

A user can subscribe to receive reports daily/weekly/monthly through emails. The format of this report can be PDF or Excel.

==External Links==

:1. [https://github.com/flavour/eden Git repository]
:2. [http://demo.eden.sahanafoundation.org/eden/ Sahana Eden Demo]
:3. [http://bytescout.com/ Bytescout]
:4. [http://html2canvas.hertzen.com/ Html2Canvas]

CSC/ECE 517 Fall 2013/oss fmv

2013-10-30T23:24:09Z

Mjoshi: /* bytesscoutpdf.js */

This project is developed as a contribution to Sahana Software Foundation (Eden).

==History==

Sahana Software Foundation was originally developed by members of the Sri Lankan IT community who wanted to apply their talent and help their country to recover from the aftermath of 2004 Indian Ocean earthquake and tsunami. The word “Sahana” means “relief” in Sinhalese, one of the national language of Sri Lanka. Sahana community has since grown to include experts from emergency and disaster management as partners in software development process. This is one of the unique strength of Sahana Software Foundation.

Under the stewardship of "The Lanka Software Foundation (LSF)", Sahana Software grew into a free and open source software project. Hundreds of volunteers, contribute and support both local and national relief agencies in their response to numerous large-scale, sudden-onset disasters. The Sahana Software Foundation was established in 2009 as a non-profit organization, registered in the State of California to serve diverse group of customers. SSF partners together with disaster and technologies experts address following questions:

How can an urgent requirement be effectively communicated to international donor community?

How can responsible authorities find hospitals that can accommodate more patients?

How can family members be reunited who were separated during evacuation?

==Description==
Sahana Eden can be used to collect and manage a large variety of data. For the data to be useful and share-able, it needs to be presented in a way that can help users to make decisions and plan activities. To achieve this Sahana Eden produce reports that are flexible and user friendly.

Reports can be in the form of: Pivot Table, Bar Chart, or Pie chart. Our work includes the exporting the generated report to user's computer so that user can see the generated report offline. Currently we focused on exporting report to PDF document.

==Design==

==Setup (Installation)==

Sahana Eden can be installed on several different operating systems:Linux,Windows,Mac. The installation of Sahana eden requires web2py framework. Sahana Eden can be easily deployed on Amazon EC2, Heroku.

To contribute to Eden foundation, fork repository from
https://github.com/flavour/eden

==Implementation==

The base class Exporter is defined as:

<pre>
function Exporter(exp)
{
this.exporter = exp;
this.tableExporter = null;
}

Exporter.prototype.setExporter = function(exp)
{
this.exporter = exp;
}

Exporter.prototype.setTableExporter = function(exporter)
{
this.tableExporter = exporter;
}

Exporter.prototype.renderTable = function()
{
this.tableExporter.render();
}
</pre>

Since we have implemented the Pdf functionality, a PdfExporter is defined for this.

<pre>

function PdfExporter(exp)
{
this.exporter = exp;
}

PdfExporter.prototype = new Exporter();

PdfExporter.prototype.getPdf = function()
{
return this.exporter;
}

PdfExporter.prototype.export = function(imageObj, json)
{
this.exportImage(imageObj);
this.exportPivotTable(json);
}

PdfExporter.prototype.exportImage = function(imageObj)
{
this.exporter.pageAdd();

// load image from canvas into BytescoutPDF

this.exporter.imageLoadFromUrl(imageObj);

// place this mage at given coordinates and dimesionson on the page
this.exporter.imagePlaceSetSize(50, 50, 0, 750, 500);
}

PdfExporter.prototype.exportPivotTable = function(json)
{
this.exporter.pageAdd();

if(this.tableExporter == null || this.tableExporter == undefined)
{
this.setTableExporter(new PdfTableRenderer(json, this.exporter));
}

this.renderTable();
}

</pre>

Now, Table exporter is written only for table creation in Pdf. This can even be used for table creation in XLS or RSS or so. Thus, we use strategy pattern here.

Table renderer is defined as below:

<pre>
function TableRenderer()
{
this.X = 50;
this.Y = 50;
this.PageWidth = 750;
this.PageHeight = 500;
this.numcols = 0;
}

TableRenderer.prototype.constructor = function(json_data, exp)
{
this.json = json_data;
this.exporter = exp;
}

TableRenderer.prototype.render = function()
{
// this method is abstract and does nothing
}

</pre>

And Pdf table renderer having functionality of exporting table to Pdf, is defined as:

<pre>
function PdfTableRenderer(json_data, exp)
{
this.json = json_data;
this.exporter = exp;
}

PdfTableRenderer.prototype = new TableRenderer();

PdfTableRenderer.prototype.render = function()
{
// render code here
}
</pre>

By setting TableRenderer in Exporter class to an instance of PdfTableRenderer, we are achieving code reuse. This can be extended for XLS by writing XLSTableRenderer class which inherits from TableRenderer and overrides the render() method.

At last, the final Pdf object which needs to be downloaded, is generated by PdfFactory. Here we have used Factory pattern to achieve the same. getPdf() method of PdfFactory hides all the implementation details from outside of the library.

PdfFactory is defined as:

<pre>
function PdfFactory()
{

}

PdfFactory.getPdf = function()
{
//... code to extract canvas image

var pe = new PdfExporter(pdf);

pe.export(dataURL, json_data);

return pe.getPdf(); // gets final pdf object
}

</pre>

==Dependency==

We have implemented the code using external java-script libraries.

===html2canvas.js===

The purpose of this file is to having ability to take "screenshots" of webpages or parts of it, directly on the users browser. The screenshot is based on the DOM.

===bytescoutpdf.js===

The purpose of this client-side Javascript library to generate PDF with text, images and graphics.It Works with mainstream desktop and mobile browsers, iPhone and iPad.

==Summary==

==Future==

===Export to Excel File===

Currently our work is restricted to exporting the graph and pivot table-generated interactively by user to a PDF. In future, the grahps and pivot table can be exported to an excel(.xls). Exporting to an excel will require significant amount of effort as excel are interactive. User should be able to manipulate the generated excel document.(Not required in the case of PDF as they are static).
XLS would ideally include raw Data on one or more sheets, the Pivot table on another sheet & Graphs on one or more additional sheets. The Pivot Table & Graphs should be linked to the raw data using XLS functionality.

===Subscription===

A user would like to subscribe to a report to receive by email daily/weekly/monthly. The format of this report can be PDF or Excel document.

==External Links==

:1. [https://github.com/flavour/eden Git repository]
:2. [http://demo.eden.sahanafoundation.org/eden/ Sahana Eden Demo]
:3. [http://bytescout.com/ Bytescout]
:4. [http://html2canvas.hertzen.com/ Html2Canvas]

CSC/ECE 517 Fall 2013/oss fmv

2013-10-30T16:47:40Z

Mjoshi:

This project is developed as a contribution to Sahana foundation (Eden).
[[File:Screenshot.png]]
==History==

Sahana software was originally developed by members of the Sri Lankan IT community who wanted to find a way to apply their talents towards n helping their country recover in the immediate aftermath of the 2004 Indian Ocean earthquake and tsunami. The word “Sahana” means “relief” in Sinhalese, one of the national languages of Sri Lanka. Sahana community has since grown to include experts in emergency and disaster management as full partners in the software development process. This is extremely unique in the governance of software projects, and a unique strength of the Sahana Software Foundation.

Under the stewardship of The Lanka Software Foundation (LSF) Sahana software grew into a global free and open source software project supported by hundreds of volunteer contributors from dozens of countries and it supported national and local authorities and relief agencies in their response to numerous large-scale, sudden-onset disasters. The Sahana Software Foundation was established in 2009 by an initial board of directors as a non-profit organization registered in the State of California to serve the needs and requirements of a diverse group of customers. SSF partners with disaster and technologies experts, technology, professional services and disaster response organizations and to better address information needs and the following questions:

How can conditions and urgent requirement be effectively communicated to the international donor community?
How can responsible authorities understand where hospitals that can accommodate additional patients are located?
How can family members remaining in villages be reunited with their parents, spouses, and children separated by evacuation?

==Description==
Sahana Eden can be used to collect and manage a large variety of data. For this data to add value it needs to be processed and shared in a way in which it can present the information people need to make decisions and plan activities. To achieve this Sahana Eden should be able to produce reports which analyse and visualize data in a flexible, user friendly and configurable way.
The types of the report can be Pivot Table, Bar Chart, or Pie chart. Our work includes the exporting the generated report to user's computer so that user can see the generated report offline. Currently we focused on exporting report to PDF document.

==Design==

==Setup (Installation)==

Sahana Eden can be installed on several different operating systems:Linux,Windows,Mac. The installation of Sahana eden requires web2py framework. Sahana Eden can be easily deployed on Amazon EC2, Heroku.

To contribute to Eden foundation, fork repository from
https://github.com/flavour/eden

==Implementation==

The base class Exporter is defined as:

<pre>
function Exporter(exp)
{
this.exporter = exp;
this.tableExporter = null;
}

Exporter.prototype.setExporter = function(exp)
{
this.exporter = exp;
}

Exporter.prototype.setTableExporter = function(exporter)
{
this.tableExporter = exporter;
}

Exporter.prototype.renderTable = function()
{
this.tableExporter.render();
}
</pre>

Since we have implemented the Pdf functionality, a PdfExporter is defined for this.

<pre>

function PdfExporter(exp)
{
this.exporter = exp;
}

PdfExporter.prototype = new Exporter();

PdfExporter.prototype.getPdf = function()
{
return this.exporter;
}

PdfExporter.prototype.export = function(imageObj, json)
{
this.exportImage(imageObj);
this.exportPivotTable(json);
}

PdfExporter.prototype.exportImage = function(imageObj)
{
this.exporter.pageAdd();

// load image from canvas into BytescoutPDF

this.exporter.imageLoadFromUrl(imageObj);

// place this mage at given coordinates and dimesionson on the page
this.exporter.imagePlaceSetSize(50, 50, 0, 750, 500);
}

PdfExporter.prototype.exportPivotTable = function(json)
{
this.exporter.pageAdd();

if(this.tableExporter == null || this.tableExporter == undefined)
{
this.setTableExporter(new PdfTableRenderer(json, this.exporter));
}

this.renderTable();
}

</pre>

Now, Table exporter is written only for table creation in Pdf. This can even be used for table creation in XLS or RSS or so. Thus, we use strategy pattern here.

Table renderer is defined as below:

<pre>
function TableRenderer()
{
this.X = 50;
this.Y = 50;
this.PageWidth = 750;
this.PageHeight = 500;
this.numcols = 0;
}

TableRenderer.prototype.constructor = function(json_data, exp)
{
this.json = json_data;
this.exporter = exp;
}

TableRenderer.prototype.render = function()
{
// this method is abstract and does nothing
}

</pre>

And Pdf table renderer having functionality of exporting table to Pdf, is defined as:

<pre>
function PdfTableRenderer(json_data, exp)
{
this.json = json_data;
this.exporter = exp;
}

PdfTableRenderer.prototype = new TableRenderer();

PdfTableRenderer.prototype.render = function()
{
// render code here
}
</pre>

By setting TableRenderer in Exporter class to an instance of PdfTableRenderer, we are achieving code reuse. This can be extended for XLS by writing XLSTableRenderer class which inherits from TableRenderer and overrides the render() method.

At last, the final Pdf object which needs to be downloaded, is generated by PdfFactory. Here we have used Factory pattern to achieve the same. getPdf() method of PdfFactory hides all the implementation details from outside of the library.

PdfFactory is defined as:

<pre>
function PdfFactory()
{

}

PdfFactory.getPdf = function()
{
//... code to extract canvas image

var pe = new PdfExporter(pdf);

pe.export(dataURL, json_data);

return pe.getPdf(); // gets final pdf object
}

</pre>

==Dependency==

During implementation of this project we used external java-script library.

===html2canvas.js===

The purpose of this file is to having ability to take "screenshots" of webpages or parts of it, directly on the users browser. The screenshot is based on the DOM.

===bytesscoutpdf.js===

The purpose of this client-side Javascript library to generate PDF with text, images and graphics.It Works with mainstream desktop and mobile browsers, iPhone and iPad.

==Summary==

==Future==

===Export to Excel File===

Currently our work is restricted to exporting the graph and pivot table-generated interactively by user to the PDF version of it. In future newer implementation can include exporting the pivot table and graph to the excel(.xls) version. This implementation may requires significant efforts as excel documents are interactive. So a user should able to manipulate the generated excel document.(Not required in the case PDF document as they are static documents).
XLS would ideally include the raw Data on 1 or more sheets, the Pivot table on another sheet & Graphs on 1 or more additional sheets. The Pivot Table & Graphs should be linked to the raw data using XLS functionality.

===Subscription===

A user would like to subscribe to a report to receive by email daily/weekly/monthly. The format of this report can be PDF or Excel document.

==External Links==

:1. [https://github.com/flavour/eden Git repository]
:2. [http://demo.eden.sahanafoundation.org/eden/ Sahana Eden Demo]
:3. [http://bytescout.com/ Bytescout]
:4. [http://html2canvas.hertzen.com/ Html2Canvas]

CSC/ECE 517 Fall 2013/oss fmv

2013-10-30T16:44:32Z

Mjoshi: /* References */

==History==

Sahana software was originally developed by members of the Sri Lankan IT community who wanted to find a way to apply their talents towards n helping their country recover in the immediate aftermath of the 2004 Indian Ocean earthquake and tsunami. The word “Sahana” means “relief” in Sinhalese, one of the national languages of Sri Lanka. Sahana community has since grown to include experts in emergency and disaster management as full partners in the software development process. This is extremely unique in the governance of software projects, and a unique strength of the Sahana Software Foundation.

Under the stewardship of The Lanka Software Foundation (LSF) Sahana software grew into a global free and open source software project supported by hundreds of volunteer contributors from dozens of countries and it supported national and local authorities and relief agencies in their response to numerous large-scale, sudden-onset disasters. The Sahana Software Foundation was established in 2009 by an initial board of directors as a non-profit organization registered in the State of California to serve the needs and requirements of a diverse group of customers. SSF partners with disaster and technologies experts, technology, professional services and disaster response organizations and to better address information needs and the following questions:

How can conditions and urgent requirement be effectively communicated to the international donor community?
How can responsible authorities understand where hospitals that can accommodate additional patients are located?
How can family members remaining in villages be reunited with their parents, spouses, and children separated by evacuation?

==Description==
Sahana Eden can be used to collect and manage a large variety of data. For this data to add value it needs to be processed and shared in a way in which it can present the information people need to make decisions and plan activities. To achieve this Sahana Eden should be able to produce reports which analyse and visualize data in a flexible, user friendly and configurable way.
The types of the report can be Pivot Table, Bar Chart, or Pie chart. Our work includes the exporting the generated report to user's computer so that user can see the generated report offline. Currently we focused on exporting report to PDF document.

==Design==

==Setup (Installation)==

Sahana Eden can be installed on several different operating systems:Linux,Windows,Mac. The installation of Sahana eden requires web2py framework. Sahana Eden can be easily deployed on Amazon EC2, Heroku.

To contribute to Eden foundation, fork repository from
https://github.com/flavour/eden

==Implementation==

The base class Exporter is defined as:

<pre>
function Exporter(exp)
{
this.exporter = exp;
this.tableExporter = null;
}

Exporter.prototype.setExporter = function(exp)
{
this.exporter = exp;
}

Exporter.prototype.setTableExporter = function(exporter)
{
this.tableExporter = exporter;
}

Exporter.prototype.renderTable = function()
{
this.tableExporter.render();
}
</pre>

Since we have implemented the Pdf functionality, a PdfExporter is defined for this.

<pre>

function PdfExporter(exp)
{
this.exporter = exp;
}

PdfExporter.prototype = new Exporter();

PdfExporter.prototype.getPdf = function()
{
return this.exporter;
}

PdfExporter.prototype.export = function(imageObj, json)
{
this.exportImage(imageObj);
this.exportPivotTable(json);
}

PdfExporter.prototype.exportImage = function(imageObj)
{
this.exporter.pageAdd();

// load image from canvas into BytescoutPDF

this.exporter.imageLoadFromUrl(imageObj);

// place this mage at given coordinates and dimesionson on the page
this.exporter.imagePlaceSetSize(50, 50, 0, 750, 500);
}

PdfExporter.prototype.exportPivotTable = function(json)
{
this.exporter.pageAdd();

if(this.tableExporter == null || this.tableExporter == undefined)
{
this.setTableExporter(new PdfTableRenderer(json, this.exporter));
}

this.renderTable();
}

</pre>

Now, Table exporter is written only for table creation in Pdf. This can even be used for table creation in XLS or RSS or so. Thus, we use strategy pattern here.

Table renderer is defined as below:

<pre>
function TableRenderer()
{
this.X = 50;
this.Y = 50;
this.PageWidth = 750;
this.PageHeight = 500;
this.numcols = 0;
}

TableRenderer.prototype.constructor = function(json_data, exp)
{
this.json = json_data;
this.exporter = exp;
}

TableRenderer.prototype.render = function()
{
// this method is abstract and does nothing
}

</pre>

And Pdf table renderer having functionality of exporting table to Pdf, is defined as:

<pre>
function PdfTableRenderer(json_data, exp)
{
this.json = json_data;
this.exporter = exp;
}

PdfTableRenderer.prototype = new TableRenderer();

PdfTableRenderer.prototype.render = function()
{
// render code here
}
</pre>

By setting TableRenderer in Exporter class to an instance of PdfTableRenderer, we are achieving code reuse. This can be extended for XLS by writing XLSTableRenderer class which inherits from TableRenderer and overrides the render() method.

At last, the final Pdf object which needs to be downloaded, is generated by PdfFactory. Here we have used Factory pattern to achieve the same. getPdf() method of PdfFactory hides all the implementation details from outside of the library.

PdfFactory is defined as:

<pre>
function PdfFactory()
{

}

PdfFactory.getPdf = function()
{
//... code to extract canvas image

var pe = new PdfExporter(pdf);

pe.export(dataURL, json_data);

return pe.getPdf(); // gets final pdf object
}

</pre>

==Dependency==

During implementation of this project we used external java-script library.

===html2canvas.js===

The purpose of this file is to having ability to take "screenshots" of webpages or parts of it, directly on the users browser. The screenshot is based on the DOM.

===bytesscoutpdf.js===

The purpose of this client-side Javascript library to generate PDF with text, images and graphics.It Works with mainstream desktop and mobile browsers, iPhone and iPad.

==Summary==

==Future==

===Export to Excel File===

Currently our work is restricted to exporting the graph and pivot table-generated interactively by user to the PDF version of it. In future newer implementation can include exporting the pivot table and graph to the excel(.xls) version. This implementation may requires significant efforts as excel documents are interactive. So a user should able to manipulate the generated excel document.(Not required in the case PDF document as they are static documents).
XLS would ideally include the raw Data on 1 or more sheets, the Pivot table on another sheet & Graphs on 1 or more additional sheets. The Pivot Table & Graphs should be linked to the raw data using XLS functionality.

===Subscription===

A user would like to subscribe to a report to receive by email daily/weekly/monthly. The format of this report can be PDF or Excel document.

==External Links==

:1. [https://github.com/flavour/eden Git repository]
:2. [http://demo.eden.sahanafoundation.org/eden/ Sahana Eden Demo]
:3. [http://bytescout.com/ Bytescout]
:4. [http://html2canvas.hertzen.com/ Html2Canvas]

CSC/ECE 517 Fall 2013/oss fmv

2013-10-30T16:44:22Z

Mjoshi: /* Further Reading */

==History==

Sahana software was originally developed by members of the Sri Lankan IT community who wanted to find a way to apply their talents towards n helping their country recover in the immediate aftermath of the 2004 Indian Ocean earthquake and tsunami. The word “Sahana” means “relief” in Sinhalese, one of the national languages of Sri Lanka. Sahana community has since grown to include experts in emergency and disaster management as full partners in the software development process. This is extremely unique in the governance of software projects, and a unique strength of the Sahana Software Foundation.

Under the stewardship of The Lanka Software Foundation (LSF) Sahana software grew into a global free and open source software project supported by hundreds of volunteer contributors from dozens of countries and it supported national and local authorities and relief agencies in their response to numerous large-scale, sudden-onset disasters. The Sahana Software Foundation was established in 2009 by an initial board of directors as a non-profit organization registered in the State of California to serve the needs and requirements of a diverse group of customers. SSF partners with disaster and technologies experts, technology, professional services and disaster response organizations and to better address information needs and the following questions:

How can conditions and urgent requirement be effectively communicated to the international donor community?
How can responsible authorities understand where hospitals that can accommodate additional patients are located?
How can family members remaining in villages be reunited with their parents, spouses, and children separated by evacuation?

==Description==
Sahana Eden can be used to collect and manage a large variety of data. For this data to add value it needs to be processed and shared in a way in which it can present the information people need to make decisions and plan activities. To achieve this Sahana Eden should be able to produce reports which analyse and visualize data in a flexible, user friendly and configurable way.
The types of the report can be Pivot Table, Bar Chart, or Pie chart. Our work includes the exporting the generated report to user's computer so that user can see the generated report offline. Currently we focused on exporting report to PDF document.

==Design==

==Setup (Installation)==

Sahana Eden can be installed on several different operating systems:Linux,Windows,Mac. The installation of Sahana eden requires web2py framework. Sahana Eden can be easily deployed on Amazon EC2, Heroku.

To contribute to Eden foundation, fork repository from
https://github.com/flavour/eden

==Implementation==

The base class Exporter is defined as:

<pre>
function Exporter(exp)
{
this.exporter = exp;
this.tableExporter = null;
}

Exporter.prototype.setExporter = function(exp)
{
this.exporter = exp;
}

Exporter.prototype.setTableExporter = function(exporter)
{
this.tableExporter = exporter;
}

Exporter.prototype.renderTable = function()
{
this.tableExporter.render();
}
</pre>

Since we have implemented the Pdf functionality, a PdfExporter is defined for this.

<pre>

function PdfExporter(exp)
{
this.exporter = exp;
}

PdfExporter.prototype = new Exporter();

PdfExporter.prototype.getPdf = function()
{
return this.exporter;
}

PdfExporter.prototype.export = function(imageObj, json)
{
this.exportImage(imageObj);
this.exportPivotTable(json);
}

PdfExporter.prototype.exportImage = function(imageObj)
{
this.exporter.pageAdd();

// load image from canvas into BytescoutPDF

this.exporter.imageLoadFromUrl(imageObj);

// place this mage at given coordinates and dimesionson on the page
this.exporter.imagePlaceSetSize(50, 50, 0, 750, 500);
}

PdfExporter.prototype.exportPivotTable = function(json)
{
this.exporter.pageAdd();

if(this.tableExporter == null || this.tableExporter == undefined)
{
this.setTableExporter(new PdfTableRenderer(json, this.exporter));
}

this.renderTable();
}

</pre>

Now, Table exporter is written only for table creation in Pdf. This can even be used for table creation in XLS or RSS or so. Thus, we use strategy pattern here.

Table renderer is defined as below:

<pre>
function TableRenderer()
{
this.X = 50;
this.Y = 50;
this.PageWidth = 750;
this.PageHeight = 500;
this.numcols = 0;
}

TableRenderer.prototype.constructor = function(json_data, exp)
{
this.json = json_data;
this.exporter = exp;
}

TableRenderer.prototype.render = function()
{
// this method is abstract and does nothing
}

</pre>

And Pdf table renderer having functionality of exporting table to Pdf, is defined as:

<pre>
function PdfTableRenderer(json_data, exp)
{
this.json = json_data;
this.exporter = exp;
}

PdfTableRenderer.prototype = new TableRenderer();

PdfTableRenderer.prototype.render = function()
{
// render code here
}
</pre>

By setting TableRenderer in Exporter class to an instance of PdfTableRenderer, we are achieving code reuse. This can be extended for XLS by writing XLSTableRenderer class which inherits from TableRenderer and overrides the render() method.

At last, the final Pdf object which needs to be downloaded, is generated by PdfFactory. Here we have used Factory pattern to achieve the same. getPdf() method of PdfFactory hides all the implementation details from outside of the library.

PdfFactory is defined as:

<pre>
function PdfFactory()
{

}

PdfFactory.getPdf = function()
{
//... code to extract canvas image

var pe = new PdfExporter(pdf);

pe.export(dataURL, json_data);

return pe.getPdf(); // gets final pdf object
}

</pre>

==Dependency==

During implementation of this project we used external java-script library.

===html2canvas.js===

The purpose of this file is to having ability to take "screenshots" of webpages or parts of it, directly on the users browser. The screenshot is based on the DOM.

===bytesscoutpdf.js===

The purpose of this client-side Javascript library to generate PDF with text, images and graphics.It Works with mainstream desktop and mobile browsers, iPhone and iPad.

==Summary==

==Future==

===Export to Excel File===

Currently our work is restricted to exporting the graph and pivot table-generated interactively by user to the PDF version of it. In future newer implementation can include exporting the pivot table and graph to the excel(.xls) version. This implementation may requires significant efforts as excel documents are interactive. So a user should able to manipulate the generated excel document.(Not required in the case PDF document as they are static documents).
XLS would ideally include the raw Data on 1 or more sheets, the Pivot table on another sheet & Graphs on 1 or more additional sheets. The Pivot Table & Graphs should be linked to the raw data using XLS functionality.

===Subscription===

A user would like to subscribe to a report to receive by email daily/weekly/monthly. The format of this report can be PDF or Excel document.

==References==
<references/>

==External Links==

:1. [https://github.com/flavour/eden Git repository]
:2. [http://demo.eden.sahanafoundation.org/eden/ Sahana Eden Demo]
:3. [http://bytescout.com/ Bytescout]
:4. [http://html2canvas.hertzen.com/ Html2Canvas]

CSC/ECE 517 Fall 2013/oss fmv

2013-10-30T16:44:14Z

Mjoshi: /* External Links */

==History==

Sahana software was originally developed by members of the Sri Lankan IT community who wanted to find a way to apply their talents towards n helping their country recover in the immediate aftermath of the 2004 Indian Ocean earthquake and tsunami. The word “Sahana” means “relief” in Sinhalese, one of the national languages of Sri Lanka. Sahana community has since grown to include experts in emergency and disaster management as full partners in the software development process. This is extremely unique in the governance of software projects, and a unique strength of the Sahana Software Foundation.

Under the stewardship of The Lanka Software Foundation (LSF) Sahana software grew into a global free and open source software project supported by hundreds of volunteer contributors from dozens of countries and it supported national and local authorities and relief agencies in their response to numerous large-scale, sudden-onset disasters. The Sahana Software Foundation was established in 2009 by an initial board of directors as a non-profit organization registered in the State of California to serve the needs and requirements of a diverse group of customers. SSF partners with disaster and technologies experts, technology, professional services and disaster response organizations and to better address information needs and the following questions:

How can conditions and urgent requirement be effectively communicated to the international donor community?
How can responsible authorities understand where hospitals that can accommodate additional patients are located?
How can family members remaining in villages be reunited with their parents, spouses, and children separated by evacuation?

==Description==
Sahana Eden can be used to collect and manage a large variety of data. For this data to add value it needs to be processed and shared in a way in which it can present the information people need to make decisions and plan activities. To achieve this Sahana Eden should be able to produce reports which analyse and visualize data in a flexible, user friendly and configurable way.
The types of the report can be Pivot Table, Bar Chart, or Pie chart. Our work includes the exporting the generated report to user's computer so that user can see the generated report offline. Currently we focused on exporting report to PDF document.

==Design==

==Setup (Installation)==

Sahana Eden can be installed on several different operating systems:Linux,Windows,Mac. The installation of Sahana eden requires web2py framework. Sahana Eden can be easily deployed on Amazon EC2, Heroku.

To contribute to Eden foundation, fork repository from
https://github.com/flavour/eden

==Implementation==

The base class Exporter is defined as:

<pre>
function Exporter(exp)
{
this.exporter = exp;
this.tableExporter = null;
}

Exporter.prototype.setExporter = function(exp)
{
this.exporter = exp;
}

Exporter.prototype.setTableExporter = function(exporter)
{
this.tableExporter = exporter;
}

Exporter.prototype.renderTable = function()
{
this.tableExporter.render();
}
</pre>

Since we have implemented the Pdf functionality, a PdfExporter is defined for this.

<pre>

function PdfExporter(exp)
{
this.exporter = exp;
}

PdfExporter.prototype = new Exporter();

PdfExporter.prototype.getPdf = function()
{
return this.exporter;
}

PdfExporter.prototype.export = function(imageObj, json)
{
this.exportImage(imageObj);
this.exportPivotTable(json);
}

PdfExporter.prototype.exportImage = function(imageObj)
{
this.exporter.pageAdd();

// load image from canvas into BytescoutPDF

this.exporter.imageLoadFromUrl(imageObj);

// place this mage at given coordinates and dimesionson on the page
this.exporter.imagePlaceSetSize(50, 50, 0, 750, 500);
}

PdfExporter.prototype.exportPivotTable = function(json)
{
this.exporter.pageAdd();

if(this.tableExporter == null || this.tableExporter == undefined)
{
this.setTableExporter(new PdfTableRenderer(json, this.exporter));
}

this.renderTable();
}

</pre>

Now, Table exporter is written only for table creation in Pdf. This can even be used for table creation in XLS or RSS or so. Thus, we use strategy pattern here.

Table renderer is defined as below:

<pre>
function TableRenderer()
{
this.X = 50;
this.Y = 50;
this.PageWidth = 750;
this.PageHeight = 500;
this.numcols = 0;
}

TableRenderer.prototype.constructor = function(json_data, exp)
{
this.json = json_data;
this.exporter = exp;
}

TableRenderer.prototype.render = function()
{
// this method is abstract and does nothing
}

</pre>

And Pdf table renderer having functionality of exporting table to Pdf, is defined as:

<pre>
function PdfTableRenderer(json_data, exp)
{
this.json = json_data;
this.exporter = exp;
}

PdfTableRenderer.prototype = new TableRenderer();

PdfTableRenderer.prototype.render = function()
{
// render code here
}
</pre>

By setting TableRenderer in Exporter class to an instance of PdfTableRenderer, we are achieving code reuse. This can be extended for XLS by writing XLSTableRenderer class which inherits from TableRenderer and overrides the render() method.

At last, the final Pdf object which needs to be downloaded, is generated by PdfFactory. Here we have used Factory pattern to achieve the same. getPdf() method of PdfFactory hides all the implementation details from outside of the library.

PdfFactory is defined as:

<pre>
function PdfFactory()
{

}

PdfFactory.getPdf = function()
{
//... code to extract canvas image

var pe = new PdfExporter(pdf);

pe.export(dataURL, json_data);

return pe.getPdf(); // gets final pdf object
}

</pre>

==Dependency==

During implementation of this project we used external java-script library.

===html2canvas.js===

The purpose of this file is to having ability to take "screenshots" of webpages or parts of it, directly on the users browser. The screenshot is based on the DOM.

===bytesscoutpdf.js===

The purpose of this client-side Javascript library to generate PDF with text, images and graphics.It Works with mainstream desktop and mobile browsers, iPhone and iPad.

==Summary==

==Future==

===Export to Excel File===

Currently our work is restricted to exporting the graph and pivot table-generated interactively by user to the PDF version of it. In future newer implementation can include exporting the pivot table and graph to the excel(.xls) version. This implementation may requires significant efforts as excel documents are interactive. So a user should able to manipulate the generated excel document.(Not required in the case PDF document as they are static documents).
XLS would ideally include the raw Data on 1 or more sheets, the Pivot table on another sheet & Graphs on 1 or more additional sheets. The Pivot Table & Graphs should be linked to the raw data using XLS functionality.

===Subscription===

A user would like to subscribe to a report to receive by email daily/weekly/monthly. The format of this report can be PDF or Excel document.

==References==
<references/>

==Further Reading==

==External Links==

:1. [https://github.com/flavour/eden Git repository]
:2. [http://demo.eden.sahanafoundation.org/eden/ Sahana Eden Demo]
:3. [http://bytescout.com/ Bytescout]
:4. [http://html2canvas.hertzen.com/ Html2Canvas]

CSC/ECE 517 Fall 2013/oss fmv

2013-10-30T16:44:04Z

Mjoshi: /* External Links */

==History==

Sahana software was originally developed by members of the Sri Lankan IT community who wanted to find a way to apply their talents towards n helping their country recover in the immediate aftermath of the 2004 Indian Ocean earthquake and tsunami. The word “Sahana” means “relief” in Sinhalese, one of the national languages of Sri Lanka. Sahana community has since grown to include experts in emergency and disaster management as full partners in the software development process. This is extremely unique in the governance of software projects, and a unique strength of the Sahana Software Foundation.

Under the stewardship of The Lanka Software Foundation (LSF) Sahana software grew into a global free and open source software project supported by hundreds of volunteer contributors from dozens of countries and it supported national and local authorities and relief agencies in their response to numerous large-scale, sudden-onset disasters. The Sahana Software Foundation was established in 2009 by an initial board of directors as a non-profit organization registered in the State of California to serve the needs and requirements of a diverse group of customers. SSF partners with disaster and technologies experts, technology, professional services and disaster response organizations and to better address information needs and the following questions:

How can conditions and urgent requirement be effectively communicated to the international donor community?
How can responsible authorities understand where hospitals that can accommodate additional patients are located?
How can family members remaining in villages be reunited with their parents, spouses, and children separated by evacuation?

==Description==
Sahana Eden can be used to collect and manage a large variety of data. For this data to add value it needs to be processed and shared in a way in which it can present the information people need to make decisions and plan activities. To achieve this Sahana Eden should be able to produce reports which analyse and visualize data in a flexible, user friendly and configurable way.
The types of the report can be Pivot Table, Bar Chart, or Pie chart. Our work includes the exporting the generated report to user's computer so that user can see the generated report offline. Currently we focused on exporting report to PDF document.

==Design==

==Setup (Installation)==

Sahana Eden can be installed on several different operating systems:Linux,Windows,Mac. The installation of Sahana eden requires web2py framework. Sahana Eden can be easily deployed on Amazon EC2, Heroku.

To contribute to Eden foundation, fork repository from
https://github.com/flavour/eden

==Implementation==

The base class Exporter is defined as:

<pre>
function Exporter(exp)
{
this.exporter = exp;
this.tableExporter = null;
}

Exporter.prototype.setExporter = function(exp)
{
this.exporter = exp;
}

Exporter.prototype.setTableExporter = function(exporter)
{
this.tableExporter = exporter;
}

Exporter.prototype.renderTable = function()
{
this.tableExporter.render();
}
</pre>

Since we have implemented the Pdf functionality, a PdfExporter is defined for this.

<pre>

function PdfExporter(exp)
{
this.exporter = exp;
}

PdfExporter.prototype = new Exporter();

PdfExporter.prototype.getPdf = function()
{
return this.exporter;
}

PdfExporter.prototype.export = function(imageObj, json)
{
this.exportImage(imageObj);
this.exportPivotTable(json);
}

PdfExporter.prototype.exportImage = function(imageObj)
{
this.exporter.pageAdd();

// load image from canvas into BytescoutPDF

this.exporter.imageLoadFromUrl(imageObj);

// place this mage at given coordinates and dimesionson on the page
this.exporter.imagePlaceSetSize(50, 50, 0, 750, 500);
}

PdfExporter.prototype.exportPivotTable = function(json)
{
this.exporter.pageAdd();

if(this.tableExporter == null || this.tableExporter == undefined)
{
this.setTableExporter(new PdfTableRenderer(json, this.exporter));
}

this.renderTable();
}

</pre>

Now, Table exporter is written only for table creation in Pdf. This can even be used for table creation in XLS or RSS or so. Thus, we use strategy pattern here.

Table renderer is defined as below:

<pre>
function TableRenderer()
{
this.X = 50;
this.Y = 50;
this.PageWidth = 750;
this.PageHeight = 500;
this.numcols = 0;
}

TableRenderer.prototype.constructor = function(json_data, exp)
{
this.json = json_data;
this.exporter = exp;
}

TableRenderer.prototype.render = function()
{
// this method is abstract and does nothing
}

</pre>

And Pdf table renderer having functionality of exporting table to Pdf, is defined as:

<pre>
function PdfTableRenderer(json_data, exp)
{
this.json = json_data;
this.exporter = exp;
}

PdfTableRenderer.prototype = new TableRenderer();

PdfTableRenderer.prototype.render = function()
{
// render code here
}
</pre>

By setting TableRenderer in Exporter class to an instance of PdfTableRenderer, we are achieving code reuse. This can be extended for XLS by writing XLSTableRenderer class which inherits from TableRenderer and overrides the render() method.

At last, the final Pdf object which needs to be downloaded, is generated by PdfFactory. Here we have used Factory pattern to achieve the same. getPdf() method of PdfFactory hides all the implementation details from outside of the library.

PdfFactory is defined as:

<pre>
function PdfFactory()
{

}

PdfFactory.getPdf = function()
{
//... code to extract canvas image

var pe = new PdfExporter(pdf);

pe.export(dataURL, json_data);

return pe.getPdf(); // gets final pdf object
}

</pre>

==Dependency==

During implementation of this project we used external java-script library.

===html2canvas.js===

The purpose of this file is to having ability to take "screenshots" of webpages or parts of it, directly on the users browser. The screenshot is based on the DOM.

===bytesscoutpdf.js===

The purpose of this client-side Javascript library to generate PDF with text, images and graphics.It Works with mainstream desktop and mobile browsers, iPhone and iPad.

==Summary==

==Future==

===Export to Excel File===

Currently our work is restricted to exporting the graph and pivot table-generated interactively by user to the PDF version of it. In future newer implementation can include exporting the pivot table and graph to the excel(.xls) version. This implementation may requires significant efforts as excel documents are interactive. So a user should able to manipulate the generated excel document.(Not required in the case PDF document as they are static documents).
XLS would ideally include the raw Data on 1 or more sheets, the Pivot table on another sheet & Graphs on 1 or more additional sheets. The Pivot Table & Graphs should be linked to the raw data using XLS functionality.

===Subscription===

A user would like to subscribe to a report to receive by email daily/weekly/monthly. The format of this report can be PDF or Excel document.

==References==
<references/>

==Further Reading==

==External Links==

:1. [https://github.com/flavour/eden Git repository]
:2. [http://demo.eden.sahanafoundation.org/eden/ Sahana Eden Demo]
:3 [http://bytescout.com/ Bytescout]
:4 [http://html2canvas.hertzen.com/ Html2Canvas]

CSC/ECE 517 Fall 2013/oss fmv

2013-10-30T16:41:51Z

Mjoshi: /* Terminology */

==History==

Sahana software was originally developed by members of the Sri Lankan IT community who wanted to find a way to apply their talents towards n helping their country recover in the immediate aftermath of the 2004 Indian Ocean earthquake and tsunami. The word “Sahana” means “relief” in Sinhalese, one of the national languages of Sri Lanka. Sahana community has since grown to include experts in emergency and disaster management as full partners in the software development process. This is extremely unique in the governance of software projects, and a unique strength of the Sahana Software Foundation.

Under the stewardship of The Lanka Software Foundation (LSF) Sahana software grew into a global free and open source software project supported by hundreds of volunteer contributors from dozens of countries and it supported national and local authorities and relief agencies in their response to numerous large-scale, sudden-onset disasters. The Sahana Software Foundation was established in 2009 by an initial board of directors as a non-profit organization registered in the State of California to serve the needs and requirements of a diverse group of customers. SSF partners with disaster and technologies experts, technology, professional services and disaster response organizations and to better address information needs and the following questions:

How can conditions and urgent requirement be effectively communicated to the international donor community?
How can responsible authorities understand where hospitals that can accommodate additional patients are located?
How can family members remaining in villages be reunited with their parents, spouses, and children separated by evacuation?

==Description==
Sahana Eden can be used to collect and manage a large variety of data. For this data to add value it needs to be processed and shared in a way in which it can present the information people need to make decisions and plan activities. To achieve this Sahana Eden should be able to produce reports which analyse and visualize data in a flexible, user friendly and configurable way.
The types of the report can be Pivot Table, Bar Chart, or Pie chart. Our work includes the exporting the generated report to user's computer so that user can see the generated report offline. Currently we focused on exporting report to PDF document.

==Design==

==Setup (Installation)==

Sahana Eden can be installed on several different operating systems:Linux,Windows,Mac. The installation of Sahana eden requires web2py framework. Sahana Eden can be easily deployed on Amazon EC2, Heroku.

To contribute to Eden foundation, fork repository from
https://github.com/flavour/eden

==Implementation==

The base class Exporter is defined as:

<pre>
function Exporter(exp)
{
this.exporter = exp;
this.tableExporter = null;
}

Exporter.prototype.setExporter = function(exp)
{
this.exporter = exp;
}

Exporter.prototype.setTableExporter = function(exporter)
{
this.tableExporter = exporter;
}

Exporter.prototype.renderTable = function()
{
this.tableExporter.render();
}
</pre>

Since we have implemented the Pdf functionality, a PdfExporter is defined for this.

<pre>

function PdfExporter(exp)
{
this.exporter = exp;
}

PdfExporter.prototype = new Exporter();

PdfExporter.prototype.getPdf = function()
{
return this.exporter;
}

PdfExporter.prototype.export = function(imageObj, json)
{
this.exportImage(imageObj);
this.exportPivotTable(json);
}

PdfExporter.prototype.exportImage = function(imageObj)
{
this.exporter.pageAdd();

// load image from canvas into BytescoutPDF

this.exporter.imageLoadFromUrl(imageObj);

// place this mage at given coordinates and dimesionson on the page
this.exporter.imagePlaceSetSize(50, 50, 0, 750, 500);
}

PdfExporter.prototype.exportPivotTable = function(json)
{
this.exporter.pageAdd();

if(this.tableExporter == null || this.tableExporter == undefined)
{
this.setTableExporter(new PdfTableRenderer(json, this.exporter));
}

this.renderTable();
}

</pre>

Now, Table exporter is written only for table creation in Pdf. This can even be used for table creation in XLS or RSS or so. Thus, we use strategy pattern here.

Table renderer is defined as below:

<pre>
function TableRenderer()
{
this.X = 50;
this.Y = 50;
this.PageWidth = 750;
this.PageHeight = 500;
this.numcols = 0;
}

TableRenderer.prototype.constructor = function(json_data, exp)
{
this.json = json_data;
this.exporter = exp;
}

TableRenderer.prototype.render = function()
{
// this method is abstract and does nothing
}

</pre>

And Pdf table renderer having functionality of exporting table to Pdf, is defined as:

<pre>
function PdfTableRenderer(json_data, exp)
{
this.json = json_data;
this.exporter = exp;
}

PdfTableRenderer.prototype = new TableRenderer();

PdfTableRenderer.prototype.render = function()
{
// render code here
}
</pre>

By setting TableRenderer in Exporter class to an instance of PdfTableRenderer, we are achieving code reuse. This can be extended for XLS by writing XLSTableRenderer class which inherits from TableRenderer and overrides the render() method.

At last, the final Pdf object which needs to be downloaded, is generated by PdfFactory. Here we have used Factory pattern to achieve the same. getPdf() method of PdfFactory hides all the implementation details from outside of the library.

PdfFactory is defined as:

<pre>
function PdfFactory()
{

}

PdfFactory.getPdf = function()
{
//... code to extract canvas image

var pe = new PdfExporter(pdf);

pe.export(dataURL, json_data);

return pe.getPdf(); // gets final pdf object
}

</pre>

==Dependency==

During implementation of this project we used external java-script library.

===html2canvas.js===

The purpose of this file is to having ability to take "screenshots" of webpages or parts of it, directly on the users browser. The screenshot is based on the DOM.

===bytesscoutpdf.js===

The purpose of this client-side Javascript library to generate PDF with text, images and graphics.It Works with mainstream desktop and mobile browsers, iPhone and iPad.

==Summary==

==Future==

===Export to Excel File===

Currently our work is restricted to exporting the graph and pivot table-generated interactively by user to the PDF version of it. In future newer implementation can include exporting the pivot table and graph to the excel(.xls) version. This implementation may requires significant efforts as excel documents are interactive. So a user should able to manipulate the generated excel document.(Not required in the case PDF document as they are static documents).
XLS would ideally include the raw Data on 1 or more sheets, the Pivot table on another sheet & Graphs on 1 or more additional sheets. The Pivot Table & Graphs should be linked to the raw data using XLS functionality.

===Subscription===

A user would like to subscribe to a report to receive by email daily/weekly/monthly. The format of this report can be PDF or Excel document.

==References==
<references/>

==Further Reading==

==External Links==

CSC/ECE 517 Fall 2013/oss fmv

2013-10-30T16:41:39Z

Mjoshi: /* Motivation */

==History==

Sahana software was originally developed by members of the Sri Lankan IT community who wanted to find a way to apply their talents towards n helping their country recover in the immediate aftermath of the 2004 Indian Ocean earthquake and tsunami. The word “Sahana” means “relief” in Sinhalese, one of the national languages of Sri Lanka. Sahana community has since grown to include experts in emergency and disaster management as full partners in the software development process. This is extremely unique in the governance of software projects, and a unique strength of the Sahana Software Foundation.

Under the stewardship of The Lanka Software Foundation (LSF) Sahana software grew into a global free and open source software project supported by hundreds of volunteer contributors from dozens of countries and it supported national and local authorities and relief agencies in their response to numerous large-scale, sudden-onset disasters. The Sahana Software Foundation was established in 2009 by an initial board of directors as a non-profit organization registered in the State of California to serve the needs and requirements of a diverse group of customers. SSF partners with disaster and technologies experts, technology, professional services and disaster response organizations and to better address information needs and the following questions:

How can conditions and urgent requirement be effectively communicated to the international donor community?
How can responsible authorities understand where hospitals that can accommodate additional patients are located?
How can family members remaining in villages be reunited with their parents, spouses, and children separated by evacuation?

==Description==
Sahana Eden can be used to collect and manage a large variety of data. For this data to add value it needs to be processed and shared in a way in which it can present the information people need to make decisions and plan activities. To achieve this Sahana Eden should be able to produce reports which analyse and visualize data in a flexible, user friendly and configurable way.
The types of the report can be Pivot Table, Bar Chart, or Pie chart. Our work includes the exporting the generated report to user's computer so that user can see the generated report offline. Currently we focused on exporting report to PDF document.

==Terminology==

===Cross Cutting Concerns===

==Design==

==Setup (Installation)==

Sahana Eden can be installed on several different operating systems:Linux,Windows,Mac. The installation of Sahana eden requires web2py framework. Sahana Eden can be easily deployed on Amazon EC2, Heroku.

To contribute to Eden foundation, fork repository from
https://github.com/flavour/eden

==Implementation==

The base class Exporter is defined as:

<pre>
function Exporter(exp)
{
this.exporter = exp;
this.tableExporter = null;
}

Exporter.prototype.setExporter = function(exp)
{
this.exporter = exp;
}

Exporter.prototype.setTableExporter = function(exporter)
{
this.tableExporter = exporter;
}

Exporter.prototype.renderTable = function()
{
this.tableExporter.render();
}
</pre>

Since we have implemented the Pdf functionality, a PdfExporter is defined for this.

<pre>

function PdfExporter(exp)
{
this.exporter = exp;
}

PdfExporter.prototype = new Exporter();

PdfExporter.prototype.getPdf = function()
{
return this.exporter;
}

PdfExporter.prototype.export = function(imageObj, json)
{
this.exportImage(imageObj);
this.exportPivotTable(json);
}

PdfExporter.prototype.exportImage = function(imageObj)
{
this.exporter.pageAdd();

// load image from canvas into BytescoutPDF

this.exporter.imageLoadFromUrl(imageObj);

// place this mage at given coordinates and dimesionson on the page
this.exporter.imagePlaceSetSize(50, 50, 0, 750, 500);
}

PdfExporter.prototype.exportPivotTable = function(json)
{
this.exporter.pageAdd();

if(this.tableExporter == null || this.tableExporter == undefined)
{
this.setTableExporter(new PdfTableRenderer(json, this.exporter));
}

this.renderTable();
}

</pre>

Now, Table exporter is written only for table creation in Pdf. This can even be used for table creation in XLS or RSS or so. Thus, we use strategy pattern here.

Table renderer is defined as below:

<pre>
function TableRenderer()
{
this.X = 50;
this.Y = 50;
this.PageWidth = 750;
this.PageHeight = 500;
this.numcols = 0;
}

TableRenderer.prototype.constructor = function(json_data, exp)
{
this.json = json_data;
this.exporter = exp;
}

TableRenderer.prototype.render = function()
{
// this method is abstract and does nothing
}

</pre>

And Pdf table renderer having functionality of exporting table to Pdf, is defined as:

<pre>
function PdfTableRenderer(json_data, exp)
{
this.json = json_data;
this.exporter = exp;
}

PdfTableRenderer.prototype = new TableRenderer();

PdfTableRenderer.prototype.render = function()
{
// render code here
}
</pre>

By setting TableRenderer in Exporter class to an instance of PdfTableRenderer, we are achieving code reuse. This can be extended for XLS by writing XLSTableRenderer class which inherits from TableRenderer and overrides the render() method.

At last, the final Pdf object which needs to be downloaded, is generated by PdfFactory. Here we have used Factory pattern to achieve the same. getPdf() method of PdfFactory hides all the implementation details from outside of the library.

PdfFactory is defined as:

<pre>
function PdfFactory()
{

}

PdfFactory.getPdf = function()
{
//... code to extract canvas image

var pe = new PdfExporter(pdf);

pe.export(dataURL, json_data);

return pe.getPdf(); // gets final pdf object
}

</pre>

==Dependency==

During implementation of this project we used external java-script library.

===html2canvas.js===

The purpose of this file is to having ability to take "screenshots" of webpages or parts of it, directly on the users browser. The screenshot is based on the DOM.

===bytesscoutpdf.js===

The purpose of this client-side Javascript library to generate PDF with text, images and graphics.It Works with mainstream desktop and mobile browsers, iPhone and iPad.

==Summary==

==Future==

===Export to Excel File===

Currently our work is restricted to exporting the graph and pivot table-generated interactively by user to the PDF version of it. In future newer implementation can include exporting the pivot table and graph to the excel(.xls) version. This implementation may requires significant efforts as excel documents are interactive. So a user should able to manipulate the generated excel document.(Not required in the case PDF document as they are static documents).
XLS would ideally include the raw Data on 1 or more sheets, the Pivot table on another sheet & Graphs on 1 or more additional sheets. The Pivot Table & Graphs should be linked to the raw data using XLS functionality.

===Subscription===

A user would like to subscribe to a report to receive by email daily/weekly/monthly. The format of this report can be PDF or Excel document.

==References==
<references/>

==Further Reading==

==External Links==

CSC/ECE 517 Fall 2013/oss fmv

2013-10-30T16:41:21Z

Mjoshi: /* Setup (Installation) */

==History==

Sahana software was originally developed by members of the Sri Lankan IT community who wanted to find a way to apply their talents towards n helping their country recover in the immediate aftermath of the 2004 Indian Ocean earthquake and tsunami. The word “Sahana” means “relief” in Sinhalese, one of the national languages of Sri Lanka. Sahana community has since grown to include experts in emergency and disaster management as full partners in the software development process. This is extremely unique in the governance of software projects, and a unique strength of the Sahana Software Foundation.

Under the stewardship of The Lanka Software Foundation (LSF) Sahana software grew into a global free and open source software project supported by hundreds of volunteer contributors from dozens of countries and it supported national and local authorities and relief agencies in their response to numerous large-scale, sudden-onset disasters. The Sahana Software Foundation was established in 2009 by an initial board of directors as a non-profit organization registered in the State of California to serve the needs and requirements of a diverse group of customers. SSF partners with disaster and technologies experts, technology, professional services and disaster response organizations and to better address information needs and the following questions:

How can conditions and urgent requirement be effectively communicated to the international donor community?
How can responsible authorities understand where hospitals that can accommodate additional patients are located?
How can family members remaining in villages be reunited with their parents, spouses, and children separated by evacuation?

==Motivation==

==Description==
Sahana Eden can be used to collect and manage a large variety of data. For this data to add value it needs to be processed and shared in a way in which it can present the information people need to make decisions and plan activities. To achieve this Sahana Eden should be able to produce reports which analyse and visualize data in a flexible, user friendly and configurable way.
The types of the report can be Pivot Table, Bar Chart, or Pie chart. Our work includes the exporting the generated report to user's computer so that user can see the generated report offline. Currently we focused on exporting report to PDF document.

==Terminology==

===Cross Cutting Concerns===

==Design==

==Setup (Installation)==

Sahana Eden can be installed on several different operating systems:Linux,Windows,Mac. The installation of Sahana eden requires web2py framework. Sahana Eden can be easily deployed on Amazon EC2, Heroku.

To contribute to Eden foundation, fork repository from
https://github.com/flavour/eden

==Implementation==

The base class Exporter is defined as:

<pre>
function Exporter(exp)
{
this.exporter = exp;
this.tableExporter = null;
}

Exporter.prototype.setExporter = function(exp)
{
this.exporter = exp;
}

Exporter.prototype.setTableExporter = function(exporter)
{
this.tableExporter = exporter;
}

Exporter.prototype.renderTable = function()
{
this.tableExporter.render();
}
</pre>

Since we have implemented the Pdf functionality, a PdfExporter is defined for this.

<pre>

function PdfExporter(exp)
{
this.exporter = exp;
}

PdfExporter.prototype = new Exporter();

PdfExporter.prototype.getPdf = function()
{
return this.exporter;
}

PdfExporter.prototype.export = function(imageObj, json)
{
this.exportImage(imageObj);
this.exportPivotTable(json);
}

PdfExporter.prototype.exportImage = function(imageObj)
{
this.exporter.pageAdd();

// load image from canvas into BytescoutPDF

this.exporter.imageLoadFromUrl(imageObj);

// place this mage at given coordinates and dimesionson on the page
this.exporter.imagePlaceSetSize(50, 50, 0, 750, 500);
}

PdfExporter.prototype.exportPivotTable = function(json)
{
this.exporter.pageAdd();

if(this.tableExporter == null || this.tableExporter == undefined)
{
this.setTableExporter(new PdfTableRenderer(json, this.exporter));
}

this.renderTable();
}

</pre>

Now, Table exporter is written only for table creation in Pdf. This can even be used for table creation in XLS or RSS or so. Thus, we use strategy pattern here.

Table renderer is defined as below:

<pre>
function TableRenderer()
{
this.X = 50;
this.Y = 50;
this.PageWidth = 750;
this.PageHeight = 500;
this.numcols = 0;
}

TableRenderer.prototype.constructor = function(json_data, exp)
{
this.json = json_data;
this.exporter = exp;
}

TableRenderer.prototype.render = function()
{
// this method is abstract and does nothing
}

</pre>

And Pdf table renderer having functionality of exporting table to Pdf, is defined as:

<pre>
function PdfTableRenderer(json_data, exp)
{
this.json = json_data;
this.exporter = exp;
}

PdfTableRenderer.prototype = new TableRenderer();

PdfTableRenderer.prototype.render = function()
{
// render code here
}
</pre>

By setting TableRenderer in Exporter class to an instance of PdfTableRenderer, we are achieving code reuse. This can be extended for XLS by writing XLSTableRenderer class which inherits from TableRenderer and overrides the render() method.

At last, the final Pdf object which needs to be downloaded, is generated by PdfFactory. Here we have used Factory pattern to achieve the same. getPdf() method of PdfFactory hides all the implementation details from outside of the library.

PdfFactory is defined as:

<pre>
function PdfFactory()
{

}

PdfFactory.getPdf = function()
{
//... code to extract canvas image

var pe = new PdfExporter(pdf);

pe.export(dataURL, json_data);

return pe.getPdf(); // gets final pdf object
}

</pre>

==Dependency==

During implementation of this project we used external java-script library.

===html2canvas.js===

The purpose of this file is to having ability to take "screenshots" of webpages or parts of it, directly on the users browser. The screenshot is based on the DOM.

===bytesscoutpdf.js===

The purpose of this client-side Javascript library to generate PDF with text, images and graphics.It Works with mainstream desktop and mobile browsers, iPhone and iPad.

==Summary==

==Future==

===Export to Excel File===

Currently our work is restricted to exporting the graph and pivot table-generated interactively by user to the PDF version of it. In future newer implementation can include exporting the pivot table and graph to the excel(.xls) version. This implementation may requires significant efforts as excel documents are interactive. So a user should able to manipulate the generated excel document.(Not required in the case PDF document as they are static documents).
XLS would ideally include the raw Data on 1 or more sheets, the Pivot table on another sheet & Graphs on 1 or more additional sheets. The Pivot Table & Graphs should be linked to the raw data using XLS functionality.

===Subscription===

A user would like to subscribe to a report to receive by email daily/weekly/monthly. The format of this report can be PDF or Excel document.

==References==
<references/>

==Further Reading==

==External Links==

CSC/ECE 517 Fall 2013/oss fmv

2013-10-30T16:41:05Z

Mjoshi: /* Setup (Installation) */

==History==

Sahana software was originally developed by members of the Sri Lankan IT community who wanted to find a way to apply their talents towards n helping their country recover in the immediate aftermath of the 2004 Indian Ocean earthquake and tsunami. The word “Sahana” means “relief” in Sinhalese, one of the national languages of Sri Lanka. Sahana community has since grown to include experts in emergency and disaster management as full partners in the software development process. This is extremely unique in the governance of software projects, and a unique strength of the Sahana Software Foundation.

Under the stewardship of The Lanka Software Foundation (LSF) Sahana software grew into a global free and open source software project supported by hundreds of volunteer contributors from dozens of countries and it supported national and local authorities and relief agencies in their response to numerous large-scale, sudden-onset disasters. The Sahana Software Foundation was established in 2009 by an initial board of directors as a non-profit organization registered in the State of California to serve the needs and requirements of a diverse group of customers. SSF partners with disaster and technologies experts, technology, professional services and disaster response organizations and to better address information needs and the following questions:

How can conditions and urgent requirement be effectively communicated to the international donor community?
How can responsible authorities understand where hospitals that can accommodate additional patients are located?
How can family members remaining in villages be reunited with their parents, spouses, and children separated by evacuation?

==Motivation==

==Description==
Sahana Eden can be used to collect and manage a large variety of data. For this data to add value it needs to be processed and shared in a way in which it can present the information people need to make decisions and plan activities. To achieve this Sahana Eden should be able to produce reports which analyse and visualize data in a flexible, user friendly and configurable way.
The types of the report can be Pivot Table, Bar Chart, or Pie chart. Our work includes the exporting the generated report to user's computer so that user can see the generated report offline. Currently we focused on exporting report to PDF document.

==Terminology==

===Cross Cutting Concerns===

==Design==

==Setup (Installation)==

Sahana Eden can be installed on several different operating systems:Linux,Windows,Mac. The installation of Sahana eden requires web2py framework. Sahana Eden can be easily deployed on Amazon EC2, Heroku.

To contribute to Eden foundation, fork repository from below URL:
https://github.com/flavour/eden

==Implementation==

The base class Exporter is defined as:

<pre>
function Exporter(exp)
{
this.exporter = exp;
this.tableExporter = null;
}

Exporter.prototype.setExporter = function(exp)
{
this.exporter = exp;
}

Exporter.prototype.setTableExporter = function(exporter)
{
this.tableExporter = exporter;
}

Exporter.prototype.renderTable = function()
{
this.tableExporter.render();
}
</pre>

Since we have implemented the Pdf functionality, a PdfExporter is defined for this.

<pre>

function PdfExporter(exp)
{
this.exporter = exp;
}

PdfExporter.prototype = new Exporter();

PdfExporter.prototype.getPdf = function()
{
return this.exporter;
}

PdfExporter.prototype.export = function(imageObj, json)
{
this.exportImage(imageObj);
this.exportPivotTable(json);
}

PdfExporter.prototype.exportImage = function(imageObj)
{
this.exporter.pageAdd();

// load image from canvas into BytescoutPDF

this.exporter.imageLoadFromUrl(imageObj);

// place this mage at given coordinates and dimesionson on the page
this.exporter.imagePlaceSetSize(50, 50, 0, 750, 500);
}

PdfExporter.prototype.exportPivotTable = function(json)
{
this.exporter.pageAdd();

if(this.tableExporter == null || this.tableExporter == undefined)
{
this.setTableExporter(new PdfTableRenderer(json, this.exporter));
}

this.renderTable();
}

</pre>

Now, Table exporter is written only for table creation in Pdf. This can even be used for table creation in XLS or RSS or so. Thus, we use strategy pattern here.

Table renderer is defined as below:

<pre>
function TableRenderer()
{
this.X = 50;
this.Y = 50;
this.PageWidth = 750;
this.PageHeight = 500;
this.numcols = 0;
}

TableRenderer.prototype.constructor = function(json_data, exp)
{
this.json = json_data;
this.exporter = exp;
}

TableRenderer.prototype.render = function()
{
// this method is abstract and does nothing
}

</pre>

And Pdf table renderer having functionality of exporting table to Pdf, is defined as:

<pre>
function PdfTableRenderer(json_data, exp)
{
this.json = json_data;
this.exporter = exp;
}

PdfTableRenderer.prototype = new TableRenderer();

PdfTableRenderer.prototype.render = function()
{
// render code here
}
</pre>

By setting TableRenderer in Exporter class to an instance of PdfTableRenderer, we are achieving code reuse. This can be extended for XLS by writing XLSTableRenderer class which inherits from TableRenderer and overrides the render() method.

At last, the final Pdf object which needs to be downloaded, is generated by PdfFactory. Here we have used Factory pattern to achieve the same. getPdf() method of PdfFactory hides all the implementation details from outside of the library.

PdfFactory is defined as:

<pre>
function PdfFactory()
{

}

PdfFactory.getPdf = function()
{
//... code to extract canvas image

var pe = new PdfExporter(pdf);

pe.export(dataURL, json_data);

return pe.getPdf(); // gets final pdf object
}

</pre>

==Dependency==

During implementation of this project we used external java-script library.

===html2canvas.js===

The purpose of this file is to having ability to take "screenshots" of webpages or parts of it, directly on the users browser. The screenshot is based on the DOM.

===bytesscoutpdf.js===

The purpose of this client-side Javascript library to generate PDF with text, images and graphics.It Works with mainstream desktop and mobile browsers, iPhone and iPad.

==Summary==

==Future==

===Export to Excel File===

Currently our work is restricted to exporting the graph and pivot table-generated interactively by user to the PDF version of it. In future newer implementation can include exporting the pivot table and graph to the excel(.xls) version. This implementation may requires significant efforts as excel documents are interactive. So a user should able to manipulate the generated excel document.(Not required in the case PDF document as they are static documents).
XLS would ideally include the raw Data on 1 or more sheets, the Pivot table on another sheet & Graphs on 1 or more additional sheets. The Pivot Table & Graphs should be linked to the raw data using XLS functionality.

===Subscription===

A user would like to subscribe to a report to receive by email daily/weekly/monthly. The format of this report can be PDF or Excel document.

==References==
<references/>

==Further Reading==

==External Links==

CSC/ECE 517 Fall 2013/oss fmv

2013-10-30T16:40:53Z

Mjoshi: /* Setup (Installation) */

==History==

Sahana software was originally developed by members of the Sri Lankan IT community who wanted to find a way to apply their talents towards n helping their country recover in the immediate aftermath of the 2004 Indian Ocean earthquake and tsunami. The word “Sahana” means “relief” in Sinhalese, one of the national languages of Sri Lanka. Sahana community has since grown to include experts in emergency and disaster management as full partners in the software development process. This is extremely unique in the governance of software projects, and a unique strength of the Sahana Software Foundation.

Under the stewardship of The Lanka Software Foundation (LSF) Sahana software grew into a global free and open source software project supported by hundreds of volunteer contributors from dozens of countries and it supported national and local authorities and relief agencies in their response to numerous large-scale, sudden-onset disasters. The Sahana Software Foundation was established in 2009 by an initial board of directors as a non-profit organization registered in the State of California to serve the needs and requirements of a diverse group of customers. SSF partners with disaster and technologies experts, technology, professional services and disaster response organizations and to better address information needs and the following questions:

How can conditions and urgent requirement be effectively communicated to the international donor community?
How can responsible authorities understand where hospitals that can accommodate additional patients are located?
How can family members remaining in villages be reunited with their parents, spouses, and children separated by evacuation?

==Motivation==

==Description==
Sahana Eden can be used to collect and manage a large variety of data. For this data to add value it needs to be processed and shared in a way in which it can present the information people need to make decisions and plan activities. To achieve this Sahana Eden should be able to produce reports which analyse and visualize data in a flexible, user friendly and configurable way.
The types of the report can be Pivot Table, Bar Chart, or Pie chart. Our work includes the exporting the generated report to user's computer so that user can see the generated report offline. Currently we focused on exporting report to PDF document.

==Terminology==

===Cross Cutting Concerns===

==Design==

==Setup (Installation)==

Sahana Eden can be installed on several different operating systems:Linux,Windows,Mac. The installation of Sahana eden requires web2py framework. Sahana Eden can be easily deployed on Amazon EC2, Heroku.

To contribute to Eden foundation, fork repository from below URL:
<a href="https://github.com/flavour/eden">https://github.com/flavour/eden</a>

==Implementation==

The base class Exporter is defined as:

<pre>
function Exporter(exp)
{
this.exporter = exp;
this.tableExporter = null;
}

Exporter.prototype.setExporter = function(exp)
{
this.exporter = exp;
}

Exporter.prototype.setTableExporter = function(exporter)
{
this.tableExporter = exporter;
}

Exporter.prototype.renderTable = function()
{
this.tableExporter.render();
}
</pre>

Since we have implemented the Pdf functionality, a PdfExporter is defined for this.

<pre>

function PdfExporter(exp)
{
this.exporter = exp;
}

PdfExporter.prototype = new Exporter();

PdfExporter.prototype.getPdf = function()
{
return this.exporter;
}

PdfExporter.prototype.export = function(imageObj, json)
{
this.exportImage(imageObj);
this.exportPivotTable(json);
}

PdfExporter.prototype.exportImage = function(imageObj)
{
this.exporter.pageAdd();

// load image from canvas into BytescoutPDF

this.exporter.imageLoadFromUrl(imageObj);

// place this mage at given coordinates and dimesionson on the page
this.exporter.imagePlaceSetSize(50, 50, 0, 750, 500);
}

PdfExporter.prototype.exportPivotTable = function(json)
{
this.exporter.pageAdd();

if(this.tableExporter == null || this.tableExporter == undefined)
{
this.setTableExporter(new PdfTableRenderer(json, this.exporter));
}

this.renderTable();
}

</pre>

Now, Table exporter is written only for table creation in Pdf. This can even be used for table creation in XLS or RSS or so. Thus, we use strategy pattern here.

Table renderer is defined as below:

<pre>
function TableRenderer()
{
this.X = 50;
this.Y = 50;
this.PageWidth = 750;
this.PageHeight = 500;
this.numcols = 0;
}

TableRenderer.prototype.constructor = function(json_data, exp)
{
this.json = json_data;
this.exporter = exp;
}

TableRenderer.prototype.render = function()
{
// this method is abstract and does nothing
}

</pre>

And Pdf table renderer having functionality of exporting table to Pdf, is defined as:

<pre>
function PdfTableRenderer(json_data, exp)
{
this.json = json_data;
this.exporter = exp;
}

PdfTableRenderer.prototype = new TableRenderer();

PdfTableRenderer.prototype.render = function()
{
// render code here
}
</pre>

By setting TableRenderer in Exporter class to an instance of PdfTableRenderer, we are achieving code reuse. This can be extended for XLS by writing XLSTableRenderer class which inherits from TableRenderer and overrides the render() method.

At last, the final Pdf object which needs to be downloaded, is generated by PdfFactory. Here we have used Factory pattern to achieve the same. getPdf() method of PdfFactory hides all the implementation details from outside of the library.

PdfFactory is defined as:

<pre>
function PdfFactory()
{

}

PdfFactory.getPdf = function()
{
//... code to extract canvas image

var pe = new PdfExporter(pdf);

pe.export(dataURL, json_data);

return pe.getPdf(); // gets final pdf object
}

</pre>

==Dependency==

During implementation of this project we used external java-script library.

===html2canvas.js===

The purpose of this file is to having ability to take "screenshots" of webpages or parts of it, directly on the users browser. The screenshot is based on the DOM.

===bytesscoutpdf.js===

The purpose of this client-side Javascript library to generate PDF with text, images and graphics.It Works with mainstream desktop and mobile browsers, iPhone and iPad.

==Summary==

==Future==

===Export to Excel File===

Currently our work is restricted to exporting the graph and pivot table-generated interactively by user to the PDF version of it. In future newer implementation can include exporting the pivot table and graph to the excel(.xls) version. This implementation may requires significant efforts as excel documents are interactive. So a user should able to manipulate the generated excel document.(Not required in the case PDF document as they are static documents).
XLS would ideally include the raw Data on 1 or more sheets, the Pivot table on another sheet & Graphs on 1 or more additional sheets. The Pivot Table & Graphs should be linked to the raw data using XLS functionality.

===Subscription===

A user would like to subscribe to a report to receive by email daily/weekly/monthly. The format of this report can be PDF or Excel document.

==References==
<references/>

==Further Reading==

==External Links==

CSC/ECE 517 Fall 2013/oss fmv

2013-10-30T16:40:13Z

Mjoshi: /* Summary */

==History==

Sahana software was originally developed by members of the Sri Lankan IT community who wanted to find a way to apply their talents towards n helping their country recover in the immediate aftermath of the 2004 Indian Ocean earthquake and tsunami. The word “Sahana” means “relief” in Sinhalese, one of the national languages of Sri Lanka. Sahana community has since grown to include experts in emergency and disaster management as full partners in the software development process. This is extremely unique in the governance of software projects, and a unique strength of the Sahana Software Foundation.

Under the stewardship of The Lanka Software Foundation (LSF) Sahana software grew into a global free and open source software project supported by hundreds of volunteer contributors from dozens of countries and it supported national and local authorities and relief agencies in their response to numerous large-scale, sudden-onset disasters. The Sahana Software Foundation was established in 2009 by an initial board of directors as a non-profit organization registered in the State of California to serve the needs and requirements of a diverse group of customers. SSF partners with disaster and technologies experts, technology, professional services and disaster response organizations and to better address information needs and the following questions:

How can conditions and urgent requirement be effectively communicated to the international donor community?
How can responsible authorities understand where hospitals that can accommodate additional patients are located?
How can family members remaining in villages be reunited with their parents, spouses, and children separated by evacuation?

==Motivation==

==Description==
Sahana Eden can be used to collect and manage a large variety of data. For this data to add value it needs to be processed and shared in a way in which it can present the information people need to make decisions and plan activities. To achieve this Sahana Eden should be able to produce reports which analyse and visualize data in a flexible, user friendly and configurable way.
The types of the report can be Pivot Table, Bar Chart, or Pie chart. Our work includes the exporting the generated report to user's computer so that user can see the generated report offline. Currently we focused on exporting report to PDF document.

==Terminology==

===Cross Cutting Concerns===

==Design==

==Setup (Installation)==

Sahana Eden can be installed on several different operating systems:Linux,Windows,Mac. The installation of Sahana eden requires web2py framework. Sahana Eden can be easily deployed on Amazon EC2, Heroku.

==Implementation==

The base class Exporter is defined as:

<pre>
function Exporter(exp)
{
this.exporter = exp;
this.tableExporter = null;
}

Exporter.prototype.setExporter = function(exp)
{
this.exporter = exp;
}

Exporter.prototype.setTableExporter = function(exporter)
{
this.tableExporter = exporter;
}

Exporter.prototype.renderTable = function()
{
this.tableExporter.render();
}
</pre>

Since we have implemented the Pdf functionality, a PdfExporter is defined for this.

<pre>

function PdfExporter(exp)
{
this.exporter = exp;
}

PdfExporter.prototype = new Exporter();

PdfExporter.prototype.getPdf = function()
{
return this.exporter;
}

PdfExporter.prototype.export = function(imageObj, json)
{
this.exportImage(imageObj);
this.exportPivotTable(json);
}

PdfExporter.prototype.exportImage = function(imageObj)
{
this.exporter.pageAdd();

// load image from canvas into BytescoutPDF

this.exporter.imageLoadFromUrl(imageObj);

// place this mage at given coordinates and dimesionson on the page
this.exporter.imagePlaceSetSize(50, 50, 0, 750, 500);
}

PdfExporter.prototype.exportPivotTable = function(json)
{
this.exporter.pageAdd();

if(this.tableExporter == null || this.tableExporter == undefined)
{
this.setTableExporter(new PdfTableRenderer(json, this.exporter));
}

this.renderTable();
}

</pre>

Now, Table exporter is written only for table creation in Pdf. This can even be used for table creation in XLS or RSS or so. Thus, we use strategy pattern here.

Table renderer is defined as below:

<pre>
function TableRenderer()
{
this.X = 50;
this.Y = 50;
this.PageWidth = 750;
this.PageHeight = 500;
this.numcols = 0;
}

TableRenderer.prototype.constructor = function(json_data, exp)
{
this.json = json_data;
this.exporter = exp;
}

TableRenderer.prototype.render = function()
{
// this method is abstract and does nothing
}

</pre>

And Pdf table renderer having functionality of exporting table to Pdf, is defined as:

<pre>
function PdfTableRenderer(json_data, exp)
{
this.json = json_data;
this.exporter = exp;
}

PdfTableRenderer.prototype = new TableRenderer();

PdfTableRenderer.prototype.render = function()
{
// render code here
}
</pre>

By setting TableRenderer in Exporter class to an instance of PdfTableRenderer, we are achieving code reuse. This can be extended for XLS by writing XLSTableRenderer class which inherits from TableRenderer and overrides the render() method.

At last, the final Pdf object which needs to be downloaded, is generated by PdfFactory. Here we have used Factory pattern to achieve the same. getPdf() method of PdfFactory hides all the implementation details from outside of the library.

PdfFactory is defined as:

<pre>
function PdfFactory()
{

}

PdfFactory.getPdf = function()
{
//... code to extract canvas image

var pe = new PdfExporter(pdf);

pe.export(dataURL, json_data);

return pe.getPdf(); // gets final pdf object
}

</pre>

==Dependency==

During implementation of this project we used external java-script library.

===html2canvas.js===

The purpose of this file is to having ability to take "screenshots" of webpages or parts of it, directly on the users browser. The screenshot is based on the DOM.

===bytesscoutpdf.js===

The purpose of this client-side Javascript library to generate PDF with text, images and graphics.It Works with mainstream desktop and mobile browsers, iPhone and iPad.

==Summary==

==Future==

===Export to Excel File===

Currently our work is restricted to exporting the graph and pivot table-generated interactively by user to the PDF version of it. In future newer implementation can include exporting the pivot table and graph to the excel(.xls) version. This implementation may requires significant efforts as excel documents are interactive. So a user should able to manipulate the generated excel document.(Not required in the case PDF document as they are static documents).
XLS would ideally include the raw Data on 1 or more sheets, the Pivot table on another sheet & Graphs on 1 or more additional sheets. The Pivot Table & Graphs should be linked to the raw data using XLS functionality.

===Subscription===

A user would like to subscribe to a report to receive by email daily/weekly/monthly. The format of this report can be PDF or Excel document.

==References==
<references/>

==Further Reading==

==External Links==

CSC/ECE 517 Fall 2013/oss fmv

2013-10-30T16:37:27Z

Mjoshi: /* Dependency */

==History==

Sahana software was originally developed by members of the Sri Lankan IT community who wanted to find a way to apply their talents towards n helping their country recover in the immediate aftermath of the 2004 Indian Ocean earthquake and tsunami. The word “Sahana” means “relief” in Sinhalese, one of the national languages of Sri Lanka. Sahana community has since grown to include experts in emergency and disaster management as full partners in the software development process. This is extremely unique in the governance of software projects, and a unique strength of the Sahana Software Foundation.

Under the stewardship of The Lanka Software Foundation (LSF) Sahana software grew into a global free and open source software project supported by hundreds of volunteer contributors from dozens of countries and it supported national and local authorities and relief agencies in their response to numerous large-scale, sudden-onset disasters. The Sahana Software Foundation was established in 2009 by an initial board of directors as a non-profit organization registered in the State of California to serve the needs and requirements of a diverse group of customers. SSF partners with disaster and technologies experts, technology, professional services and disaster response organizations and to better address information needs and the following questions:

How can conditions and urgent requirement be effectively communicated to the international donor community?
How can responsible authorities understand where hospitals that can accommodate additional patients are located?
How can family members remaining in villages be reunited with their parents, spouses, and children separated by evacuation?

==Motivation==

==Description==
Sahana Eden can be used to collect and manage a large variety of data. For this data to add value it needs to be processed and shared in a way in which it can present the information people need to make decisions and plan activities. To achieve this Sahana Eden should be able to produce reports which analyse and visualize data in a flexible, user friendly and configurable way.
The types of the report can be Pivot Table, Bar Chart, or Pie chart. Our work includes the exporting the generated report to user's computer so that user can see the generated report offline. Currently we focused on exporting report to PDF document.

==Terminology==

===Cross Cutting Concerns===

==Design==

==Setup (Installation)==

Sahana Eden can be installed on several different operating systems:Linux,Windows,Mac. The installation of Sahana eden requires web2py framework. Sahana Eden can be easily deployed on Amazon EC2, Heroku.

==Implementation==

The base class Exporter is defined as:

<pre>
function Exporter(exp)
{
this.exporter = exp;
this.tableExporter = null;
}

Exporter.prototype.setExporter = function(exp)
{
this.exporter = exp;
}

Exporter.prototype.setTableExporter = function(exporter)
{
this.tableExporter = exporter;
}

Exporter.prototype.renderTable = function()
{
this.tableExporter.render();
}
</pre>

Since we have implemented the Pdf functionality, a PdfExporter is defined for this.

<pre>

function PdfExporter(exp)
{
this.exporter = exp;
}

PdfExporter.prototype = new Exporter();

PdfExporter.prototype.getPdf = function()
{
return this.exporter;
}

PdfExporter.prototype.export = function(imageObj, json)
{
this.exportImage(imageObj);
this.exportPivotTable(json);
}

PdfExporter.prototype.exportImage = function(imageObj)
{
this.exporter.pageAdd();

// load image from canvas into BytescoutPDF

this.exporter.imageLoadFromUrl(imageObj);

// place this mage at given coordinates and dimesionson on the page
this.exporter.imagePlaceSetSize(50, 50, 0, 750, 500);
}

PdfExporter.prototype.exportPivotTable = function(json)
{
this.exporter.pageAdd();

if(this.tableExporter == null || this.tableExporter == undefined)
{
this.setTableExporter(new PdfTableRenderer(json, this.exporter));
}

this.renderTable();
}

</pre>

Now, Table exporter is written only for table creation in Pdf. This can even be used for table creation in XLS or RSS or so. Thus, we use strategy pattern here.

Table renderer is defined as below:

<pre>
function TableRenderer()
{
this.X = 50;
this.Y = 50;
this.PageWidth = 750;
this.PageHeight = 500;
this.numcols = 0;
}

TableRenderer.prototype.constructor = function(json_data, exp)
{
this.json = json_data;
this.exporter = exp;
}

TableRenderer.prototype.render = function()
{
// this method is abstract and does nothing
}

</pre>

And Pdf table renderer having functionality of exporting table to Pdf, is defined as:

<pre>
function PdfTableRenderer(json_data, exp)
{
this.json = json_data;
this.exporter = exp;
}

PdfTableRenderer.prototype = new TableRenderer();

PdfTableRenderer.prototype.render = function()
{
// render code here
}
</pre>

By setting TableRenderer in Exporter class to an instance of PdfTableRenderer, we are achieving code reuse. This can be extended for XLS by writing XLSTableRenderer class which inherits from TableRenderer and overrides the render() method.

At last, the final Pdf object which needs to be downloaded, is generated by PdfFactory. Here we have used Factory pattern to achieve the same. getPdf() method of PdfFactory hides all the implementation details from outside of the library.

PdfFactory is defined as:

<pre>
function PdfFactory()
{

}

PdfFactory.getPdf = function()
{
//... code to extract canvas image

var pe = new PdfExporter(pdf);

pe.export(dataURL, json_data);

return pe.getPdf(); // gets final pdf object
}

</pre>

==Dependency==

During implementation of this project we used external java-script library.

===html2canvas.js===

The purpose of this file is to having ability to take "screenshots" of webpages or parts of it, directly on the users browser. The screenshot is based on the DOM.

===bytesscoutpdf.js===

The purpose of this client-side Javascript library to generate PDF with text, images and graphics.It Works with mainstream desktop and mobile browsers, iPhone and iPad.

==Summary==

===Moving toward a better way to build software===

==Future==

===Export to Excel File===

Currently our work is restricted to exporting the graph and pivot table-generated interactively by user to the PDF version of it. In future newer implementation can include exporting the pivot table and graph to the excel(.xls) version. This implementation may requires significant efforts as excel documents are interactive. So a user should able to manipulate the generated excel document.(Not required in the case PDF document as they are static documents).
XLS would ideally include the raw Data on 1 or more sheets, the Pivot table on another sheet & Graphs on 1 or more additional sheets. The Pivot Table & Graphs should be linked to the raw data using XLS functionality.

===Subscription===

A user would like to subscribe to a report to receive by email daily/weekly/monthly. The format of this report can be PDF or Excel document.

==References==
<references/>

==Further Reading==

==External Links==

CSC/ECE 517 Fall 2013/oss fmv

2013-10-30T16:37:15Z

Mjoshi: /* Dependency */

==History==

Sahana software was originally developed by members of the Sri Lankan IT community who wanted to find a way to apply their talents towards n helping their country recover in the immediate aftermath of the 2004 Indian Ocean earthquake and tsunami. The word “Sahana” means “relief” in Sinhalese, one of the national languages of Sri Lanka. Sahana community has since grown to include experts in emergency and disaster management as full partners in the software development process. This is extremely unique in the governance of software projects, and a unique strength of the Sahana Software Foundation.

Under the stewardship of The Lanka Software Foundation (LSF) Sahana software grew into a global free and open source software project supported by hundreds of volunteer contributors from dozens of countries and it supported national and local authorities and relief agencies in their response to numerous large-scale, sudden-onset disasters. The Sahana Software Foundation was established in 2009 by an initial board of directors as a non-profit organization registered in the State of California to serve the needs and requirements of a diverse group of customers. SSF partners with disaster and technologies experts, technology, professional services and disaster response organizations and to better address information needs and the following questions:

How can conditions and urgent requirement be effectively communicated to the international donor community?
How can responsible authorities understand where hospitals that can accommodate additional patients are located?
How can family members remaining in villages be reunited with their parents, spouses, and children separated by evacuation?

==Motivation==

==Description==
Sahana Eden can be used to collect and manage a large variety of data. For this data to add value it needs to be processed and shared in a way in which it can present the information people need to make decisions and plan activities. To achieve this Sahana Eden should be able to produce reports which analyse and visualize data in a flexible, user friendly and configurable way.
The types of the report can be Pivot Table, Bar Chart, or Pie chart. Our work includes the exporting the generated report to user's computer so that user can see the generated report offline. Currently we focused on exporting report to PDF document.

==Terminology==

===Cross Cutting Concerns===

==Design==

==Setup (Installation)==

Sahana Eden can be installed on several different operating systems:Linux,Windows,Mac. The installation of Sahana eden requires web2py framework. Sahana Eden can be easily deployed on Amazon EC2, Heroku.

==Implementation==

The base class Exporter is defined as:

<pre>
function Exporter(exp)
{
this.exporter = exp;
this.tableExporter = null;
}

Exporter.prototype.setExporter = function(exp)
{
this.exporter = exp;
}

Exporter.prototype.setTableExporter = function(exporter)
{
this.tableExporter = exporter;
}

Exporter.prototype.renderTable = function()
{
this.tableExporter.render();
}
</pre>

Since we have implemented the Pdf functionality, a PdfExporter is defined for this.

<pre>

function PdfExporter(exp)
{
this.exporter = exp;
}

PdfExporter.prototype = new Exporter();

PdfExporter.prototype.getPdf = function()
{
return this.exporter;
}

PdfExporter.prototype.export = function(imageObj, json)
{
this.exportImage(imageObj);
this.exportPivotTable(json);
}

PdfExporter.prototype.exportImage = function(imageObj)
{
this.exporter.pageAdd();

// load image from canvas into BytescoutPDF

this.exporter.imageLoadFromUrl(imageObj);

// place this mage at given coordinates and dimesionson on the page
this.exporter.imagePlaceSetSize(50, 50, 0, 750, 500);
}

PdfExporter.prototype.exportPivotTable = function(json)
{
this.exporter.pageAdd();

if(this.tableExporter == null || this.tableExporter == undefined)
{
this.setTableExporter(new PdfTableRenderer(json, this.exporter));
}

this.renderTable();
}

</pre>

Now, Table exporter is written only for table creation in Pdf. This can even be used for table creation in XLS or RSS or so. Thus, we use strategy pattern here.

Table renderer is defined as below:

<pre>
function TableRenderer()
{
this.X = 50;
this.Y = 50;
this.PageWidth = 750;
this.PageHeight = 500;
this.numcols = 0;
}

TableRenderer.prototype.constructor = function(json_data, exp)
{
this.json = json_data;
this.exporter = exp;
}

TableRenderer.prototype.render = function()
{
// this method is abstract and does nothing
}

</pre>

And Pdf table renderer having functionality of exporting table to Pdf, is defined as:

<pre>
function PdfTableRenderer(json_data, exp)
{
this.json = json_data;
this.exporter = exp;
}

PdfTableRenderer.prototype = new TableRenderer();

PdfTableRenderer.prototype.render = function()
{
// render code here
}
</pre>

By setting TableRenderer in Exporter class to an instance of PdfTableRenderer, we are achieving code reuse. This can be extended for XLS by writing XLSTableRenderer class which inherits from TableRenderer and overrides the render() method.

At last, the final Pdf object which needs to be downloaded, is generated by PdfFactory. Here we have used Factory pattern to achieve the same. getPdf() method of PdfFactory hides all the implementation details from outside of the library.

PdfFactory is defined as:

<pre>
function PdfFactory()
{

}

PdfFactory.getPdf = function()
{
//... code to extract canvas image

var pe = new PdfExporter(pdf);

pe.export(dataURL, json_data);

return pe.getPdf(); // gets final pdf object
}

</pre>

==Dependency==

During implementation of this project we used external java-script library.

===html2canvas.js===

The purpose of this file is to having ability to take "screenshots" of webpages or parts of it, directly on the users browser. The screenshot is based on the DOM.

===bytesscoutpdf.js===

The purpose of this client-side Javascript library to generate PDF with text, images and graphics.It Works with mainstream desktop and mobile browsers, iPhone and iPad.

==Summary==

===Moving toward a better way to build software===

==Future==

===Export to Excel File===

Currently our work is restricted to exporting the graph and pivot table-generated interactively by user to the PDF version of it. In future newer implementation can include exporting the pivot table and graph to the excel(.xls) version. This implementation may requires significant efforts as excel documents are interactive. So a user should able to manipulate the generated excel document.(Not required in the case PDF document as they are static documents).
XLS would ideally include the raw Data on 1 or more sheets, the Pivot table on another sheet & Graphs on 1 or more additional sheets. The Pivot Table & Graphs should be linked to the raw data using XLS functionality.

===Subscription===

A user would like to subscribe to a report to receive by email daily/weekly/monthly. The format of this report can be PDF or Excel document.

==References==
<references/>

==Further Reading==

==External Links==

CSC/ECE 517 Fall 2013/oss fmv

2013-10-30T16:29:13Z

Mjoshi:

==History==

Sahana software was originally developed by members of the Sri Lankan IT community who wanted to find a way to apply their talents towards n helping their country recover in the immediate aftermath of the 2004 Indian Ocean earthquake and tsunami. The word “Sahana” means “relief” in Sinhalese, one of the national languages of Sri Lanka. Sahana community has since grown to include experts in emergency and disaster management as full partners in the software development process. This is extremely unique in the governance of software projects, and a unique strength of the Sahana Software Foundation.

Under the stewardship of The Lanka Software Foundation (LSF) Sahana software grew into a global free and open source software project supported by hundreds of volunteer contributors from dozens of countries and it supported national and local authorities and relief agencies in their response to numerous large-scale, sudden-onset disasters. The Sahana Software Foundation was established in 2009 by an initial board of directors as a non-profit organization registered in the State of California to serve the needs and requirements of a diverse group of customers. SSF partners with disaster and technologies experts, technology, professional services and disaster response organizations and to better address information needs and the following questions:

How can conditions and urgent requirement be effectively communicated to the international donor community?
How can responsible authorities understand where hospitals that can accommodate additional patients are located?
How can family members remaining in villages be reunited with their parents, spouses, and children separated by evacuation?

==Motivation==

==Description==
Sahana Eden can be used to collect and manage a large variety of data. For this data to add value it needs to be processed and shared in a way in which it can present the information people need to make decisions and plan activities. To achieve this Sahana Eden should be able to produce reports which analyse and visualize data in a flexible, user friendly and configurable way.
The types of the report can be Pivot Table, Bar Chart, or Pie chart. Our work includes the exporting the generated report to user's computer so that user can see the generated report offline. Currently we focused on exporting report to PDF document.

==Terminology==

===Cross Cutting Concerns===

==Design==

==Setup (Installation)==

Sahana Eden can be installed on several different operating systems:Linux,Windows,Mac. The installation of Sahana eden requires web2py framework. Sahana Eden can be easily deployed on Amazon EC2, Heroku.

==Implementation==

The base class Exporter is defined as:

<pre>
function Exporter(exp)
{
this.exporter = exp;
this.tableExporter = null;
}

Exporter.prototype.setExporter = function(exp)
{
this.exporter = exp;
}

Exporter.prototype.setTableExporter = function(exporter)
{
this.tableExporter = exporter;
}

Exporter.prototype.renderTable = function()
{
this.tableExporter.render();
}
</pre>

Since we have implemented the Pdf functionality, a PdfExporter is defined for this.

<pre>

function PdfExporter(exp)
{
this.exporter = exp;
}

PdfExporter.prototype = new Exporter();

PdfExporter.prototype.getPdf = function()
{
return this.exporter;
}

PdfExporter.prototype.export = function(imageObj, json)
{
this.exportImage(imageObj);
this.exportPivotTable(json);
}

PdfExporter.prototype.exportImage = function(imageObj)
{
this.exporter.pageAdd();

// load image from canvas into BytescoutPDF

this.exporter.imageLoadFromUrl(imageObj);

// place this mage at given coordinates and dimesionson on the page
this.exporter.imagePlaceSetSize(50, 50, 0, 750, 500);
}

PdfExporter.prototype.exportPivotTable = function(json)
{
this.exporter.pageAdd();

if(this.tableExporter == null || this.tableExporter == undefined)
{
this.setTableExporter(new PdfTableRenderer(json, this.exporter));
}

this.renderTable();
}

</pre>

Now, Table exporter is written only for table creation in Pdf. This can even be used for table creation in XLS or RSS or so. Thus, we use strategy pattern here.

Table renderer is defined as below:

<pre>
function TableRenderer()
{
this.X = 50;
this.Y = 50;
this.PageWidth = 750;
this.PageHeight = 500;
this.numcols = 0;
}

TableRenderer.prototype.constructor = function(json_data, exp)
{
this.json = json_data;
this.exporter = exp;
}

TableRenderer.prototype.render = function()
{
// this method is abstract and does nothing
}

</pre>

And Pdf table renderer having functionality of exporting table to Pdf, is defined as:

<pre>
function PdfTableRenderer(json_data, exp)
{
this.json = json_data;
this.exporter = exp;
}

PdfTableRenderer.prototype = new TableRenderer();

PdfTableRenderer.prototype.render = function()
{
// render code here
}
</pre>

By setting TableRenderer in Exporter class to an instance of PdfTableRenderer, we are achieving code reuse. This can be extended for XLS by writing XLSTableRenderer class which inherits from TableRenderer and overrides the render() method.

At last, the final Pdf object which needs to be downloaded, is generated by PdfFactory. Here we have used Factory pattern to achieve the same. getPdf() method of PdfFactory hides all the implementation details from outside of the library.

PdfFactory is defined as:

<pre>
function PdfFactory()
{

}

PdfFactory.getPdf = function()
{
//... code to extract canvas image

var pe = new PdfExporter(pdf);

pe.export(dataURL, json_data);

return pe.getPdf(); // gets final pdf object
}

</pre>

==Dependency==

==Summary==

===Moving toward a better way to build software===

==Future==

===Export to Excel File===

Currently our work is restricted to exporting the graph and pivot table-generated interactively by user to the PDF version of it. In future newer implementation can include exporting the pivot table and graph to the excel(.xls) version. This implementation may requires significant efforts as excel documents are interactive. So a user should able to manipulate the generated excel document.(Not required in the case PDF document as they are static documents).
XLS would ideally include the raw Data on 1 or more sheets, the Pivot table on another sheet & Graphs on 1 or more additional sheets. The Pivot Table & Graphs should be linked to the raw data using XLS functionality.

===Subscription===

A user would like to subscribe to a report to receive by email daily/weekly/monthly. The format of this report can be PDF or Excel document.

==References==
<references/>

==Further Reading==

==External Links==

CSC/ECE 517 Fall 2013/oss fmv

2013-10-30T16:12:34Z

Mjoshi:

CSC/ECE 517 Fall 2013/oss fmv

2013-10-29T14:11:25Z

Mjoshi:

CSC/ECE 517 Fall 2013/oss fmv

2013-10-29T14:11:00Z

Mjoshi:

==[Under Construction]==

==History==

Sahana software was originally developed by members of the Sri Lankan IT community who wanted to find a way to apply their talents towards n helping their country recover in the immediate aftermath of the 2004 Indian Ocean earthquake and tsunami. The word “Sahana” means “relief” in Sinhalese, one of the national languages of Sri Lanka. Sahana community has since grown to include experts in emergency and disaster management as full partners in the software development process. This is extremely unique in the governance of software projects, and a unique strength of the Sahana Software Foundation.

Under the stewardship of The Lanka Software Foundation (LSF) Sahana software grew into a global free and open source software project supported by hundreds of volunteer contributors from dozens of countries and it supported national and local authorities and relief agencies in their response to numerous large-scale, sudden-onset disasters. The Sahana Software Foundation was established in 2009 by an initial board of directors as a non-profit organization registered in the State of California to serve the needs and requirements of a diverse group of customers. SSF partners with disaster and technologies experts, technology, professional services and disaster response organizations and to better address information needs and the following questions:

How can conditions and urgent requirement be effectively communicated to the international donor community?
How can responsible authorities understand where hospitals that can accommodate additional patients are located?
How can family members remaining in villages be reunited with their parents, spouses, and children separated by evacuation?

==Motivation==

==Description==
Sahana Eden can be used to collect and manage a large variety of data. For this data to add value it needs to be processed and shared in a way in which it can present the information people need to make decisions and plan activities. To achieve this Sahana Eden should be able to produce reports which analyse and visualize data in a flexible, user friendly and configurable way.
The types of the report can be Pivot Table, Bar Chart, or Pie chart. Our work includes the exporting the generated report to user's computer so that user can see the generated report offline. Currently we focused on exporting report to PDF document.

==Terminology==

===Cross Cutting Concerns===

==Design==

==Problem with Aspect Oriented Programming==

==Setup (Installation)==

Sahana Eden can be installed on several different operating systems:Linux,Windows,Mac. The installation of Sahana eden requires web2py framework. Sahana Eden can be easily deployed on Amazon EC2, Heroku.

==Summary==

===Moving toward a better way to build software===

==Future==

===Export to Excel File===

Currently our work is restricted to exporting the graph and pivot table-generated interactively by user to the PDF version of it. In future newer implementation can include exporting the pivot table and graph to the excel(.xls) version. This implementation may requires significant efforts as excel documents are interactive. So a user should able to manipulate the generated excel document.(Not required in the case PDF document as they are static documents).
XLS would ideally include the raw Data on 1 or more sheets, the Pivot table on another sheet & Graphs on 1 or more additional sheets. The Pivot Table & Graphs should be linked to the raw data using XLS functionality.

===Subscription===

A user would like to subscribe to a report to receive by email daily/weekly/monthly. The format of this report can be PDF or Excel document.

==References==
<references/>

==Further Reading==

==External Links==

CSC/ECE 517 Fall 2013/ch1 1w31 vm

2013-10-08T01:08:46Z

Mjoshi: /* Documentation */

'''Test-driven development''' (TDD) is a software development process that relies on the repetition of a very short development cycle: first the developer writes an (initially failing) automated test case that defines a desired improvement or new function, then produces the minimum amount of code to pass that test, and finally refactors the new code to acceptable standards.
Test-driven development is related to the test-first programming concepts of extreme programming, begun in 1999, but more recently has created more general interest in its own right.
Programmers also apply the concept to improving and debugging legacy code developed with older techniques.

== '''Why to use TDD?'''==
A significant advantage of TDD is that it enables you to take small steps when writing software. This is a practice that has been promoted for years because it is far more productive than attempting to code in large steps. For example, assume you add some new functional code, compile, and test it. Chances are pretty good that your tests will be broken by defects that exist in the new code. It is much easier to find, and then fix, those defects if you've written two new lines of code than two thousand. The implication is that the faster your compiler and regression test suite, the more attractive it is to proceed in smaller and smaller steps.

== '''Rules of Thumb'''==
<li>Don’t write a line of new code unless you first have a failing automated test
<li>Eliminate duplication.

These rules generate complex individual and group behavior. Some of the technical implications are:

; Design with organization
TDD recommends that programmers should write their code such that it provides feedback between decisions. It should exhibit a control hierarchy which is easy to manage and understand.

; Write your own tests
This states that developers should write their own tests, since it is not advisable to wait for someone else to write a test every time. In a software environment, developers usually used to rely on testers to find bugs. However, this design says otherwise. It implies that developers know their code inside out and hence should write their own test cases.

; Rapid Response
Your development environment must provide rapid response to small changes. Business requirments are generally fickle and they can change at any point of time. Hence, it is receommended that developers write code such that it can adapt to changes made in future.

; High Cohesion
In computer programming, cohesion refers to the degree to which the elements of a module belong together. Thus, it is a measure of how strongly-related each piece of functionality expressed by the source code of a software module is. The design must consist of many highly cohesive, loosely coupled components, just to make testing easy.

== '''Steps performed in TDD'''==
[[File:tdd_flow.jpg|right]]
The following sequence is based on the book Test-Driven Development by Example.[http://www.eecs.yorku.ca/course_archive/2003-04/W/3311/sectionM/case_studies/money/KentBeck_TDD_byexample.pdf]
=== Quickly add a test ===
In test-driven development, each new feature begins with writing a test. This test must inevitably fail because it is written before the feature has been implemented. (If it does not fail, then either the proposed "new" feature already exists or the test is defective.) To write a test, the developer must clearly understand the feature's specification and requirements. The developer can accomplish this through use cases and user stories to cover the requirements and exception conditions, and can write the test in whatever testing framework is appropriate to the software environment. This could also be a modification of an existing test. This is a differentiating feature of test-driven development versus writing unit tests after the code is written: it makes the developer focus on the requirements before writing the code, a subtle but important difference.
=== Run all tests and see the new one fail ===
This validates that the test harness is working correctly and that the new test does not mistakenly pass without requiring any new code. This step also tests the test itself, in the negative: it rules out the possibility that the new test always passes, and therefore is worthless. The new test should also fail for the expected reason. This increases confidence (though does not guarantee) that it is testing the right thing, and passes only in intended cases.
=== Make a little change ===
The next step is to write some code that causes the test to pass. The new code written at this stage is not perfect, and may, for example, pass the test in an inelegant way. That is acceptable because later steps improve and hone it.
At this point, the only purpose of the written code is to pass the test; no further (and therefore untested) functionality should be predicted and 'allowed for' at any stage.
=== Run all tests and see them all succeed ===
If all test cases now pass, the programmer can be confident that the code meets all the tested requirements. This is a good point from which to begin the final step of the cycle.
=== Refactor to remove duplication ===
Now the code should be cleaned up as necessary. Move code from where it was convenient for passing the test to where it logically belongs. Remove any duplication you can find. Make sure that variable and method names represent their current use. Clarify any constructs that might be misinterpreted. Use Kent Beck's four rules of simple design[5][6] to guide you, as well as anything else you know about writing clean code. By re-running the test cases, the developer can be confident that code refactoring is not damaging any existing functionality.
The concept of removing duplication is an important aspect of any software design. In this case, however, it also applies to removing any duplication between the test code and the production code—for example magic numbers or strings repeated in both to make the test pass in step 3.

== '''Levels of Test Driven Development''' ==
There are two levels of TDD:
;Acceptance TDD (ATDD): With ATDD developers write a single acceptance test, or behavioral specification depending on preferred terminology, and then just enough production functionality/code to fulfill that test. The goal of ATDD is to specify detailed, executable requirements for the solution be on a just in time (JIT) basis. ATDD is also called Behavior Driven Development (BDD).
;Developer TDD: With developer TDD a single developer test is written, sometimes inaccurately referred to as a unit test, and then just enough production code to fulfill that test. The goal of developer TDD is to specify a detailed, executable design for the solution be on a JIT basis. Developer TDD is often simply called TDD.
See more at: http://www.agiledata.org/essays/tdd.html#sthash.11uJfvXR.dpuf

;Testing using xUnit can be done as shown below:
[[File:tdd_xunit.jpg]]

== '''Test Driven Development using JUnit (Example)''' ==
Consider a simple class Money to represent a value in a single currency. We represent the amount by a simple int. To get full accuracy you would probably use double or java.math.BigDecimal to store arbitrary-precision signed decimal numbers. We represent a currency as a String holding the ISO three letter abbreviation (USD, CHF, etc.). In more complex implementations, currency might deserve its own object.
<pre>
class Money {
private int fAmount;
private String fCurrency;
public Money(int amount, String currency) {
fAmount= amount;
fCurrency= currency;
}

public int amount() {
return fAmount;
}

public String currency() {
return fCurrency;
}
}
</pre>

JUnit defines how to structure your test cases and provides the tools to run them. You implement a test in a subclass of TestCase. To test our Money implementation we therefore define MoneyTest as a subclass of TestCase. In Java, classes are contained in packages and we have to decide where to put MoneyTest. Our current practice is to put MoneyTest in the same package as the classes under test. In this way a test case has access to the package private methods.

<pre>
public class MoneyTest extends TestCase {
//…
public void testSimpleAdd() {
Money m12CHF= new Money(12, "CHF"); // (1)
Money m14CHF= new Money(14, "CHF");
Money expected= new Money(26, "CHF");
Money result= m12CHF.add(m14CHF); // (2)
Assert.assertTrue(expected.equals(result)); // (3)
}
}
</pre>

Line 3 in above code implies that there is an equals method defined for class Money. Else it will call Object's equals method. To make above code work, we need to write the equals method in Money as follows:

<pre>
public boolean equals(Object anObject) {
if (anObject instanceof Money) {
Money aMoney= (Money)anObject;
return aMoney.currency().equals(currency())
&& amount() == aMoney.amount();
}
return false;
}
</pre>

Since equals can receive any kind of object as its argument we first have to check its type before we cast it as a Money. As an aside, it is a recommended practice to also override the method hashCode whenever you override method equals.

In the static way you override the runTest method inherited from TestCase and call the desired test case. A convenient way to do this is with an anonymous inner class. Note that each test must be given a name, so you can identify it if it fails.

<pre>
TestCase test= new MoneyTest("simple add") {
public void runTest() {
testSimpleAdd();
}
};
</pre>

== '''Characteristics of Good Tests'''==
For developers, the implication is that they need to learn how to write effective unit tests. [http://en.wikipedia.org/wiki/Kent_Beck Beck]’s experience is that good unit tests:

<li>Run fast (they have short setups, run times, and break downs).
<li>Run in isolation (you should be able to reorder them).
<li>Use data that makes them easy to read and to understand.
<li>Use real data (e.g. copies of production data) when they need to.
<li>Represent one step towards your overall goal.

== '''Traditional Testing''' ==
TDD is primarily a specification technique with a side effect of ensuring that your source code is thoroughly tested at a confirmatory level. However, there is more to testing than this. Particularly at scale you'll still need to consider other agile testing techniques such as pre-production integration testing and investigative testing. Much of this testing can also be done early in your project if you choose to do so (and you should).
With traditional testing a successful test finds one or more defects. It is the same with TDD; when a test fails you have made progress because you now know that you need to resolve the problem. More importantly, you have a clear measure of success when the test no longer fails. TDD increases your confidence that your system actually meets the requirements defined for it, that your system actually works and therefore you can proceed with confidence.
As with traditional testing, the greater the risk profile of the system the more thorough your tests need to be. With both traditional testing and TDD you aren't striving for perfection, instead you are testing to the importance of the system. To paraphrase Agile Modeling (AM), you should "test with a purpose" and know why you are testing something and to what level it needs to be tested. An interesting side effect of TDD is that you achieve 100% coverage test – every single line of code is tested – something that traditional testing doesn’t guarantee (although it does recommend it). In general I think it’s fairly safe to say that although TDD is a specification technique, a valuable side effect is that it results in significantly better code testing than do traditional techniques.

== '''Documentation''' ==
Most programmers don’t read the written documentation for a system, instead they prefer to work with the code. And there’s nothing wrong with this. When trying to understand a class or operation most programmers will first look for sample code that already invokes it. Well-written unit tests do exactly this – the provide a working specification of your functional code – and as a result unit tests effectively become a significant portion of your technical documentation. The implication is that the expectations of the pro-documentation crowd need to reflect this reality. Similarly, acceptance tests can form an important part of your requirements documentation. This makes a lot of sense when you stop and think about it. Your acceptance tests define exactly what your stakeholders expect of your system, therefore they specify your critical requirements. Your regression test suite, particularly with a test-first approach, effectively becomes detailed executable specifications.

== '''Scaling TDD via Agile Model-Driven Development (AMDD)''' ==
TDD is very good at detailed specification and validation, but not so good at thinking through bigger issues such as the overall design, how people will use the system, or the UI design (for example). Modeling, or more to the point agile model-driven development (AMDD) (the lifecycle for which is captured in Figure 4) is better suited for this. AMDD addresses the agile scaling issues that TDD does not.

;Agile Model Driven Development (AMDD) Lifecycle
[[File:amdd.gif]]

=== TDD vs. AMDD ===

<li>TDD shortens the programming feedback loop whereas AMDD shortens the modeling feedback loop.
<li>TDD provides detailed specification (tests) whereas AMDD is better for thinking through bigger issues.
<li>TDD promotes the development of high-quality code whereas AMDD promotes high-quality communication with your stakeholders and other developers.
<li> TDD provides concrete evidence that your software works whereas AMDD supports your team, including stakeholders, in working toward a common understanding.
<li> TDD “speaks” to programmers whereas AMDD speaks to business analysts, stakeholders, and data professionals.
<li> TDD is provides very finely grained concrete feedback on the order of minutes whereas AMDD enables verbal feedback on the order minutes (concrete feedback requires developers to follow the practice Prove It With Code and thus becomes dependent on non-AM techniques).
<li> TDD helps to ensure that your design is clean by focusing on creation of operations that are callable and testable whereas AMDD provides an opportunity to think through larger design/architectural issues before you code.
<li> TDD is non-visually oriented whereas AMDD is visually oriented.
<li> Both techniques are new to traditional developers and therefore may be threatening to them.
<li> Both techniques support evolutionary development.

== Further Reading ==
* Test Driven Development by Exmaple http://www.eecs.yorku.ca/course_archive/2003-04/W/3311/sectionM/case_studies/money/KentBeck_TDD_byexample.pdf
* Test-Driven Database Development: Unlocking Agility (Net Objectives Lean-Agile Series) http://www.amazon.com/exec/obidos/ASIN/032178412X/ambysoftinc

== References ==

*[http://www.eecs.yorku.ca/course_archive/2003-04/W/3311/sectionM/case_studies/money/KentBeck_TDD_byexample.pdf KentBack Test Driven Development by Example]
*[http://en.wikipedia.org/wiki/Test-driven_development Test Driven Development]
*[http://junit.sourceforge.net/doc/testinfected/testing.htm Test Driven Development in JUnit]
*[http://www.agiledata.org/essays/tdd.html TDD Agile Data Method]

CSC/ECE 517 Fall 2013/ch1 1w31 vm

2013-10-08T01:07:47Z

Mjoshi: /* Characteristics of Good Tests */

'''Test-driven development''' (TDD) is a software development process that relies on the repetition of a very short development cycle: first the developer writes an (initially failing) automated test case that defines a desired improvement or new function, then produces the minimum amount of code to pass that test, and finally refactors the new code to acceptable standards.
Test-driven development is related to the test-first programming concepts of extreme programming, begun in 1999, but more recently has created more general interest in its own right.
Programmers also apply the concept to improving and debugging legacy code developed with older techniques.

== '''Why to use TDD?'''==
A significant advantage of TDD is that it enables you to take small steps when writing software. This is a practice that has been promoted for years because it is far more productive than attempting to code in large steps. For example, assume you add some new functional code, compile, and test it. Chances are pretty good that your tests will be broken by defects that exist in the new code. It is much easier to find, and then fix, those defects if you've written two new lines of code than two thousand. The implication is that the faster your compiler and regression test suite, the more attractive it is to proceed in smaller and smaller steps.

== '''Rules of Thumb'''==
<li>Don’t write a line of new code unless you first have a failing automated test
<li>Eliminate duplication.

These rules generate complex individual and group behavior. Some of the technical implications are:

; Design with organization
TDD recommends that programmers should write their code such that it provides feedback between decisions. It should exhibit a control hierarchy which is easy to manage and understand.

; Write your own tests
This states that developers should write their own tests, since it is not advisable to wait for someone else to write a test every time. In a software environment, developers usually used to rely on testers to find bugs. However, this design says otherwise. It implies that developers know their code inside out and hence should write their own test cases.

; Rapid Response
Your development environment must provide rapid response to small changes. Business requirments are generally fickle and they can change at any point of time. Hence, it is receommended that developers write code such that it can adapt to changes made in future.

; High Cohesion
In computer programming, cohesion refers to the degree to which the elements of a module belong together. Thus, it is a measure of how strongly-related each piece of functionality expressed by the source code of a software module is. The design must consist of many highly cohesive, loosely coupled components, just to make testing easy.

== '''Steps performed in TDD'''==
[[File:tdd_flow.jpg|right]]
The following sequence is based on the book Test-Driven Development by Example.[http://www.eecs.yorku.ca/course_archive/2003-04/W/3311/sectionM/case_studies/money/KentBeck_TDD_byexample.pdf]
=== Quickly add a test ===
In test-driven development, each new feature begins with writing a test. This test must inevitably fail because it is written before the feature has been implemented. (If it does not fail, then either the proposed "new" feature already exists or the test is defective.) To write a test, the developer must clearly understand the feature's specification and requirements. The developer can accomplish this through use cases and user stories to cover the requirements and exception conditions, and can write the test in whatever testing framework is appropriate to the software environment. This could also be a modification of an existing test. This is a differentiating feature of test-driven development versus writing unit tests after the code is written: it makes the developer focus on the requirements before writing the code, a subtle but important difference.
=== Run all tests and see the new one fail ===
This validates that the test harness is working correctly and that the new test does not mistakenly pass without requiring any new code. This step also tests the test itself, in the negative: it rules out the possibility that the new test always passes, and therefore is worthless. The new test should also fail for the expected reason. This increases confidence (though does not guarantee) that it is testing the right thing, and passes only in intended cases.
=== Make a little change ===
The next step is to write some code that causes the test to pass. The new code written at this stage is not perfect, and may, for example, pass the test in an inelegant way. That is acceptable because later steps improve and hone it.
At this point, the only purpose of the written code is to pass the test; no further (and therefore untested) functionality should be predicted and 'allowed for' at any stage.
=== Run all tests and see them all succeed ===
If all test cases now pass, the programmer can be confident that the code meets all the tested requirements. This is a good point from which to begin the final step of the cycle.
=== Refactor to remove duplication ===
Now the code should be cleaned up as necessary. Move code from where it was convenient for passing the test to where it logically belongs. Remove any duplication you can find. Make sure that variable and method names represent their current use. Clarify any constructs that might be misinterpreted. Use Kent Beck's four rules of simple design[5][6] to guide you, as well as anything else you know about writing clean code. By re-running the test cases, the developer can be confident that code refactoring is not damaging any existing functionality.
The concept of removing duplication is an important aspect of any software design. In this case, however, it also applies to removing any duplication between the test code and the production code—for example magic numbers or strings repeated in both to make the test pass in step 3.

== '''Levels of Test Driven Development''' ==
There are two levels of TDD:
;Acceptance TDD (ATDD): With ATDD developers write a single acceptance test, or behavioral specification depending on preferred terminology, and then just enough production functionality/code to fulfill that test. The goal of ATDD is to specify detailed, executable requirements for the solution be on a just in time (JIT) basis. ATDD is also called Behavior Driven Development (BDD).
;Developer TDD: With developer TDD a single developer test is written, sometimes inaccurately referred to as a unit test, and then just enough production code to fulfill that test. The goal of developer TDD is to specify a detailed, executable design for the solution be on a JIT basis. Developer TDD is often simply called TDD.
See more at: http://www.agiledata.org/essays/tdd.html#sthash.11uJfvXR.dpuf

;Testing using xUnit can be done as shown below:
[[File:tdd_xunit.jpg]]

== '''Test Driven Development using JUnit (Example)''' ==
Consider a simple class Money to represent a value in a single currency. We represent the amount by a simple int. To get full accuracy you would probably use double or java.math.BigDecimal to store arbitrary-precision signed decimal numbers. We represent a currency as a String holding the ISO three letter abbreviation (USD, CHF, etc.). In more complex implementations, currency might deserve its own object.
<pre>
class Money {
private int fAmount;
private String fCurrency;
public Money(int amount, String currency) {
fAmount= amount;
fCurrency= currency;
}

public int amount() {
return fAmount;
}

public String currency() {
return fCurrency;
}
}
</pre>

JUnit defines how to structure your test cases and provides the tools to run them. You implement a test in a subclass of TestCase. To test our Money implementation we therefore define MoneyTest as a subclass of TestCase. In Java, classes are contained in packages and we have to decide where to put MoneyTest. Our current practice is to put MoneyTest in the same package as the classes under test. In this way a test case has access to the package private methods.

<pre>
public class MoneyTest extends TestCase {
//…
public void testSimpleAdd() {
Money m12CHF= new Money(12, "CHF"); // (1)
Money m14CHF= new Money(14, "CHF");
Money expected= new Money(26, "CHF");
Money result= m12CHF.add(m14CHF); // (2)
Assert.assertTrue(expected.equals(result)); // (3)
}
}
</pre>

Line 3 in above code implies that there is an equals method defined for class Money. Else it will call Object's equals method. To make above code work, we need to write the equals method in Money as follows:

<pre>
public boolean equals(Object anObject) {
if (anObject instanceof Money) {
Money aMoney= (Money)anObject;
return aMoney.currency().equals(currency())
&& amount() == aMoney.amount();
}
return false;
}
</pre>

Since equals can receive any kind of object as its argument we first have to check its type before we cast it as a Money. As an aside, it is a recommended practice to also override the method hashCode whenever you override method equals.

In the static way you override the runTest method inherited from TestCase and call the desired test case. A convenient way to do this is with an anonymous inner class. Note that each test must be given a name, so you can identify it if it fails.

<pre>
TestCase test= new MoneyTest("simple add") {
public void runTest() {
testSimpleAdd();
}
};
</pre>

== '''Characteristics of Good Tests'''==
For developers, the implication is that they need to learn how to write effective unit tests. [http://en.wikipedia.org/wiki/Kent_Beck Beck]’s experience is that good unit tests:

<li>Run fast (they have short setups, run times, and break downs).
<li>Run in isolation (you should be able to reorder them).
<li>Use data that makes them easy to read and to understand.
<li>Use real data (e.g. copies of production data) when they need to.
<li>Represent one step towards your overall goal.

== '''Traditional Testing''' ==
TDD is primarily a specification technique with a side effect of ensuring that your source code is thoroughly tested at a confirmatory level. However, there is more to testing than this. Particularly at scale you'll still need to consider other agile testing techniques such as pre-production integration testing and investigative testing. Much of this testing can also be done early in your project if you choose to do so (and you should).
With traditional testing a successful test finds one or more defects. It is the same with TDD; when a test fails you have made progress because you now know that you need to resolve the problem. More importantly, you have a clear measure of success when the test no longer fails. TDD increases your confidence that your system actually meets the requirements defined for it, that your system actually works and therefore you can proceed with confidence.
As with traditional testing, the greater the risk profile of the system the more thorough your tests need to be. With both traditional testing and TDD you aren't striving for perfection, instead you are testing to the importance of the system. To paraphrase Agile Modeling (AM), you should "test with a purpose" and know why you are testing something and to what level it needs to be tested. An interesting side effect of TDD is that you achieve 100% coverage test – every single line of code is tested – something that traditional testing doesn’t guarantee (although it does recommend it). In general I think it’s fairly safe to say that although TDD is a specification technique, a valuable side effect is that it results in significantly better code testing than do traditional techniques.

== '''Documentation''' ==
Like it or not most programmers don’t read the written documentation for a system, instead they prefer to work with the code. And there’s nothing wrong with this. When trying to understand a class or operation most programmers will first look for sample code that already invokes it. Well-written unit tests do exactly this – the provide a working specification of your functional code – and as a result unit tests effectively become a significant portion of your technical documentation. The implication is that the expectations of the pro-documentation crowd need to reflect this reality. Similarly, acceptance tests can form an important part of your requirements documentation. This makes a lot of sense when you stop and think about it. Your acceptance tests define exactly what your stakeholders expect of your system, therefore they specify your critical requirements. Your regression test suite, particularly with a test-first approach, effectively becomes detailed executable specifications.

== '''Scaling TDD via Agile Model-Driven Development (AMDD)''' ==
TDD is very good at detailed specification and validation, but not so good at thinking through bigger issues such as the overall design, how people will use the system, or the UI design (for example). Modeling, or more to the point agile model-driven development (AMDD) (the lifecycle for which is captured in Figure 4) is better suited for this. AMDD addresses the agile scaling issues that TDD does not.

;Agile Model Driven Development (AMDD) Lifecycle
[[File:amdd.gif]]

=== TDD vs. AMDD ===

<li>TDD shortens the programming feedback loop whereas AMDD shortens the modeling feedback loop.
<li>TDD provides detailed specification (tests) whereas AMDD is better for thinking through bigger issues.
<li>TDD promotes the development of high-quality code whereas AMDD promotes high-quality communication with your stakeholders and other developers.
<li> TDD provides concrete evidence that your software works whereas AMDD supports your team, including stakeholders, in working toward a common understanding.
<li> TDD “speaks” to programmers whereas AMDD speaks to business analysts, stakeholders, and data professionals.
<li> TDD is provides very finely grained concrete feedback on the order of minutes whereas AMDD enables verbal feedback on the order minutes (concrete feedback requires developers to follow the practice Prove It With Code and thus becomes dependent on non-AM techniques).
<li> TDD helps to ensure that your design is clean by focusing on creation of operations that are callable and testable whereas AMDD provides an opportunity to think through larger design/architectural issues before you code.
<li> TDD is non-visually oriented whereas AMDD is visually oriented.
<li> Both techniques are new to traditional developers and therefore may be threatening to them.
<li> Both techniques support evolutionary development.

== Further Reading ==
* Test Driven Development by Exmaple http://www.eecs.yorku.ca/course_archive/2003-04/W/3311/sectionM/case_studies/money/KentBeck_TDD_byexample.pdf
* Test-Driven Database Development: Unlocking Agility (Net Objectives Lean-Agile Series) http://www.amazon.com/exec/obidos/ASIN/032178412X/ambysoftinc

== References ==

*[http://www.eecs.yorku.ca/course_archive/2003-04/W/3311/sectionM/case_studies/money/KentBeck_TDD_byexample.pdf KentBack Test Driven Development by Example]
*[http://en.wikipedia.org/wiki/Test-driven_development Test Driven Development]
*[http://junit.sourceforge.net/doc/testinfected/testing.htm Test Driven Development in JUnit]
*[http://www.agiledata.org/essays/tdd.html TDD Agile Data Method]

CSC/ECE 517 Fall 2013/ch1 1w31 vm

2013-10-08T01:05:56Z

Mjoshi: /* Test Driven Development using JUnit (Example) */

'''Test-driven development''' (TDD) is a software development process that relies on the repetition of a very short development cycle: first the developer writes an (initially failing) automated test case that defines a desired improvement or new function, then produces the minimum amount of code to pass that test, and finally refactors the new code to acceptable standards.
Test-driven development is related to the test-first programming concepts of extreme programming, begun in 1999, but more recently has created more general interest in its own right.
Programmers also apply the concept to improving and debugging legacy code developed with older techniques.

== '''Why to use TDD?'''==
A significant advantage of TDD is that it enables you to take small steps when writing software. This is a practice that has been promoted for years because it is far more productive than attempting to code in large steps. For example, assume you add some new functional code, compile, and test it. Chances are pretty good that your tests will be broken by defects that exist in the new code. It is much easier to find, and then fix, those defects if you've written two new lines of code than two thousand. The implication is that the faster your compiler and regression test suite, the more attractive it is to proceed in smaller and smaller steps.

== '''Rules of Thumb'''==
<li>Don’t write a line of new code unless you first have a failing automated test
<li>Eliminate duplication.

These rules generate complex individual and group behavior. Some of the technical implications are:

; Design with organization
TDD recommends that programmers should write their code such that it provides feedback between decisions. It should exhibit a control hierarchy which is easy to manage and understand.

; Write your own tests
This states that developers should write their own tests, since it is not advisable to wait for someone else to write a test every time. In a software environment, developers usually used to rely on testers to find bugs. However, this design says otherwise. It implies that developers know their code inside out and hence should write their own test cases.

; Rapid Response
Your development environment must provide rapid response to small changes. Business requirments are generally fickle and they can change at any point of time. Hence, it is receommended that developers write code such that it can adapt to changes made in future.

; High Cohesion
In computer programming, cohesion refers to the degree to which the elements of a module belong together. Thus, it is a measure of how strongly-related each piece of functionality expressed by the source code of a software module is. The design must consist of many highly cohesive, loosely coupled components, just to make testing easy.

== '''Steps performed in TDD'''==
[[File:tdd_flow.jpg|right]]
The following sequence is based on the book Test-Driven Development by Example.[http://www.eecs.yorku.ca/course_archive/2003-04/W/3311/sectionM/case_studies/money/KentBeck_TDD_byexample.pdf]
=== Quickly add a test ===
In test-driven development, each new feature begins with writing a test. This test must inevitably fail because it is written before the feature has been implemented. (If it does not fail, then either the proposed "new" feature already exists or the test is defective.) To write a test, the developer must clearly understand the feature's specification and requirements. The developer can accomplish this through use cases and user stories to cover the requirements and exception conditions, and can write the test in whatever testing framework is appropriate to the software environment. This could also be a modification of an existing test. This is a differentiating feature of test-driven development versus writing unit tests after the code is written: it makes the developer focus on the requirements before writing the code, a subtle but important difference.
=== Run all tests and see the new one fail ===
This validates that the test harness is working correctly and that the new test does not mistakenly pass without requiring any new code. This step also tests the test itself, in the negative: it rules out the possibility that the new test always passes, and therefore is worthless. The new test should also fail for the expected reason. This increases confidence (though does not guarantee) that it is testing the right thing, and passes only in intended cases.
=== Make a little change ===
The next step is to write some code that causes the test to pass. The new code written at this stage is not perfect, and may, for example, pass the test in an inelegant way. That is acceptable because later steps improve and hone it.
At this point, the only purpose of the written code is to pass the test; no further (and therefore untested) functionality should be predicted and 'allowed for' at any stage.
=== Run all tests and see them all succeed ===
If all test cases now pass, the programmer can be confident that the code meets all the tested requirements. This is a good point from which to begin the final step of the cycle.
=== Refactor to remove duplication ===
Now the code should be cleaned up as necessary. Move code from where it was convenient for passing the test to where it logically belongs. Remove any duplication you can find. Make sure that variable and method names represent their current use. Clarify any constructs that might be misinterpreted. Use Kent Beck's four rules of simple design[5][6] to guide you, as well as anything else you know about writing clean code. By re-running the test cases, the developer can be confident that code refactoring is not damaging any existing functionality.
The concept of removing duplication is an important aspect of any software design. In this case, however, it also applies to removing any duplication between the test code and the production code—for example magic numbers or strings repeated in both to make the test pass in step 3.

== '''Levels of Test Driven Development''' ==
There are two levels of TDD:
;Acceptance TDD (ATDD): With ATDD developers write a single acceptance test, or behavioral specification depending on preferred terminology, and then just enough production functionality/code to fulfill that test. The goal of ATDD is to specify detailed, executable requirements for the solution be on a just in time (JIT) basis. ATDD is also called Behavior Driven Development (BDD).
;Developer TDD: With developer TDD a single developer test is written, sometimes inaccurately referred to as a unit test, and then just enough production code to fulfill that test. The goal of developer TDD is to specify a detailed, executable design for the solution be on a JIT basis. Developer TDD is often simply called TDD.
See more at: http://www.agiledata.org/essays/tdd.html#sthash.11uJfvXR.dpuf

;Testing using xUnit can be done as shown below:
[[File:tdd_xunit.jpg]]

== '''Test Driven Development using JUnit (Example)''' ==
Consider a simple class Money to represent a value in a single currency. We represent the amount by a simple int. To get full accuracy you would probably use double or java.math.BigDecimal to store arbitrary-precision signed decimal numbers. We represent a currency as a String holding the ISO three letter abbreviation (USD, CHF, etc.). In more complex implementations, currency might deserve its own object.
<pre>
class Money {
private int fAmount;
private String fCurrency;
public Money(int amount, String currency) {
fAmount= amount;
fCurrency= currency;
}

public int amount() {
return fAmount;
}

public String currency() {
return fCurrency;
}
}
</pre>

JUnit defines how to structure your test cases and provides the tools to run them. You implement a test in a subclass of TestCase. To test our Money implementation we therefore define MoneyTest as a subclass of TestCase. In Java, classes are contained in packages and we have to decide where to put MoneyTest. Our current practice is to put MoneyTest in the same package as the classes under test. In this way a test case has access to the package private methods.

<pre>
public class MoneyTest extends TestCase {
//…
public void testSimpleAdd() {
Money m12CHF= new Money(12, "CHF"); // (1)
Money m14CHF= new Money(14, "CHF");
Money expected= new Money(26, "CHF");
Money result= m12CHF.add(m14CHF); // (2)
Assert.assertTrue(expected.equals(result)); // (3)
}
}
</pre>

Line 3 in above code implies that there is an equals method defined for class Money. Else it will call Object's equals method. To make above code work, we need to write the equals method in Money as follows:

<pre>
public boolean equals(Object anObject) {
if (anObject instanceof Money) {
Money aMoney= (Money)anObject;
return aMoney.currency().equals(currency())
&& amount() == aMoney.amount();
}
return false;
}
</pre>

Since equals can receive any kind of object as its argument we first have to check its type before we cast it as a Money. As an aside, it is a recommended practice to also override the method hashCode whenever you override method equals.

In the static way you override the runTest method inherited from TestCase and call the desired test case. A convenient way to do this is with an anonymous inner class. Note that each test must be given a name, so you can identify it if it fails.

<pre>
TestCase test= new MoneyTest("simple add") {
public void runTest() {
testSimpleAdd();
}
};
</pre>

== '''Characteristics of Good Tests'''==
For developers, the implication is that they need to learn how to write effective unit tests. Beck’s experience is that good unit tests:

<li>Run fast (they have short setups, run times, and break downs).
<li>Run in isolation (you should be able to reorder them).
<li>Use data that makes them easy to read and to understand.
<li>Use real data (e.g. copies of production data) when they need to.
<li>Represent one step towards your overall goal.

== '''Traditional Testing''' ==
TDD is primarily a specification technique with a side effect of ensuring that your source code is thoroughly tested at a confirmatory level. However, there is more to testing than this. Particularly at scale you'll still need to consider other agile testing techniques such as pre-production integration testing and investigative testing. Much of this testing can also be done early in your project if you choose to do so (and you should).
With traditional testing a successful test finds one or more defects. It is the same with TDD; when a test fails you have made progress because you now know that you need to resolve the problem. More importantly, you have a clear measure of success when the test no longer fails. TDD increases your confidence that your system actually meets the requirements defined for it, that your system actually works and therefore you can proceed with confidence.
As with traditional testing, the greater the risk profile of the system the more thorough your tests need to be. With both traditional testing and TDD you aren't striving for perfection, instead you are testing to the importance of the system. To paraphrase Agile Modeling (AM), you should "test with a purpose" and know why you are testing something and to what level it needs to be tested. An interesting side effect of TDD is that you achieve 100% coverage test – every single line of code is tested – something that traditional testing doesn’t guarantee (although it does recommend it). In general I think it’s fairly safe to say that although TDD is a specification technique, a valuable side effect is that it results in significantly better code testing than do traditional techniques.

== '''Documentation''' ==
Like it or not most programmers don’t read the written documentation for a system, instead they prefer to work with the code. And there’s nothing wrong with this. When trying to understand a class or operation most programmers will first look for sample code that already invokes it. Well-written unit tests do exactly this – the provide a working specification of your functional code – and as a result unit tests effectively become a significant portion of your technical documentation. The implication is that the expectations of the pro-documentation crowd need to reflect this reality. Similarly, acceptance tests can form an important part of your requirements documentation. This makes a lot of sense when you stop and think about it. Your acceptance tests define exactly what your stakeholders expect of your system, therefore they specify your critical requirements. Your regression test suite, particularly with a test-first approach, effectively becomes detailed executable specifications.

== '''Scaling TDD via Agile Model-Driven Development (AMDD)''' ==
TDD is very good at detailed specification and validation, but not so good at thinking through bigger issues such as the overall design, how people will use the system, or the UI design (for example). Modeling, or more to the point agile model-driven development (AMDD) (the lifecycle for which is captured in Figure 4) is better suited for this. AMDD addresses the agile scaling issues that TDD does not.

;Agile Model Driven Development (AMDD) Lifecycle
[[File:amdd.gif]]

=== TDD vs. AMDD ===

<li>TDD shortens the programming feedback loop whereas AMDD shortens the modeling feedback loop.
<li>TDD provides detailed specification (tests) whereas AMDD is better for thinking through bigger issues.
<li>TDD promotes the development of high-quality code whereas AMDD promotes high-quality communication with your stakeholders and other developers.
<li> TDD provides concrete evidence that your software works whereas AMDD supports your team, including stakeholders, in working toward a common understanding.
<li> TDD “speaks” to programmers whereas AMDD speaks to business analysts, stakeholders, and data professionals.
<li> TDD is provides very finely grained concrete feedback on the order of minutes whereas AMDD enables verbal feedback on the order minutes (concrete feedback requires developers to follow the practice Prove It With Code and thus becomes dependent on non-AM techniques).
<li> TDD helps to ensure that your design is clean by focusing on creation of operations that are callable and testable whereas AMDD provides an opportunity to think through larger design/architectural issues before you code.
<li> TDD is non-visually oriented whereas AMDD is visually oriented.
<li> Both techniques are new to traditional developers and therefore may be threatening to them.
<li> Both techniques support evolutionary development.

== Further Reading ==
* Test Driven Development by Exmaple http://www.eecs.yorku.ca/course_archive/2003-04/W/3311/sectionM/case_studies/money/KentBeck_TDD_byexample.pdf
* Test-Driven Database Development: Unlocking Agility (Net Objectives Lean-Agile Series) http://www.amazon.com/exec/obidos/ASIN/032178412X/ambysoftinc

== References ==

*[http://www.eecs.yorku.ca/course_archive/2003-04/W/3311/sectionM/case_studies/money/KentBeck_TDD_byexample.pdf KentBack Test Driven Development by Example]
*[http://en.wikipedia.org/wiki/Test-driven_development Test Driven Development]
*[http://junit.sourceforge.net/doc/testinfected/testing.htm Test Driven Development in JUnit]
*[http://www.agiledata.org/essays/tdd.html TDD Agile Data Method]

CSC/ECE 517 Fall 2013/ch1 1w31 vm

2013-10-08T00:59:57Z

Mjoshi: /* Why to use TDD? */

'''Test-driven development''' (TDD) is a software development process that relies on the repetition of a very short development cycle: first the developer writes an (initially failing) automated test case that defines a desired improvement or new function, then produces the minimum amount of code to pass that test, and finally refactors the new code to acceptable standards.
Test-driven development is related to the test-first programming concepts of extreme programming, begun in 1999, but more recently has created more general interest in its own right.
Programmers also apply the concept to improving and debugging legacy code developed with older techniques.

== '''Why to use TDD?'''==
A significant advantage of TDD is that it enables you to take small steps when writing software. This is a practice that has been promoted for years because it is far more productive than attempting to code in large steps. For example, assume you add some new functional code, compile, and test it. Chances are pretty good that your tests will be broken by defects that exist in the new code. It is much easier to find, and then fix, those defects if you've written two new lines of code than two thousand. The implication is that the faster your compiler and regression test suite, the more attractive it is to proceed in smaller and smaller steps.

== '''Rules of Thumb'''==
<li>Don’t write a line of new code unless you first have a failing automated test
<li>Eliminate duplication.

These rules generate complex individual and group behavior. Some of the technical implications are:

; Design with organization
TDD recommends that programmers should write their code such that it provides feedback between decisions. It should exhibit a control hierarchy which is easy to manage and understand.

; Write your own tests
This states that developers should write their own tests, since it is not advisable to wait for someone else to write a test every time. In a software environment, developers usually used to rely on testers to find bugs. However, this design says otherwise. It implies that developers know their code inside out and hence should write their own test cases.

; Rapid Response
Your development environment must provide rapid response to small changes. Business requirments are generally fickle and they can change at any point of time. Hence, it is receommended that developers write code such that it can adapt to changes made in future.

; High Cohesion
In computer programming, cohesion refers to the degree to which the elements of a module belong together. Thus, it is a measure of how strongly-related each piece of functionality expressed by the source code of a software module is. The design must consist of many highly cohesive, loosely coupled components, just to make testing easy.

== '''Steps performed in TDD'''==
[[File:tdd_flow.jpg|right]]
The following sequence is based on the book Test-Driven Development by Example.[http://www.eecs.yorku.ca/course_archive/2003-04/W/3311/sectionM/case_studies/money/KentBeck_TDD_byexample.pdf]
=== Quickly add a test ===
In test-driven development, each new feature begins with writing a test. This test must inevitably fail because it is written before the feature has been implemented. (If it does not fail, then either the proposed "new" feature already exists or the test is defective.) To write a test, the developer must clearly understand the feature's specification and requirements. The developer can accomplish this through use cases and user stories to cover the requirements and exception conditions, and can write the test in whatever testing framework is appropriate to the software environment. This could also be a modification of an existing test. This is a differentiating feature of test-driven development versus writing unit tests after the code is written: it makes the developer focus on the requirements before writing the code, a subtle but important difference.
=== Run all tests and see the new one fail ===
This validates that the test harness is working correctly and that the new test does not mistakenly pass without requiring any new code. This step also tests the test itself, in the negative: it rules out the possibility that the new test always passes, and therefore is worthless. The new test should also fail for the expected reason. This increases confidence (though does not guarantee) that it is testing the right thing, and passes only in intended cases.
=== Make a little change ===
The next step is to write some code that causes the test to pass. The new code written at this stage is not perfect, and may, for example, pass the test in an inelegant way. That is acceptable because later steps improve and hone it.
At this point, the only purpose of the written code is to pass the test; no further (and therefore untested) functionality should be predicted and 'allowed for' at any stage.
=== Run all tests and see them all succeed ===
If all test cases now pass, the programmer can be confident that the code meets all the tested requirements. This is a good point from which to begin the final step of the cycle.
=== Refactor to remove duplication ===
Now the code should be cleaned up as necessary. Move code from where it was convenient for passing the test to where it logically belongs. Remove any duplication you can find. Make sure that variable and method names represent their current use. Clarify any constructs that might be misinterpreted. Use Kent Beck's four rules of simple design[5][6] to guide you, as well as anything else you know about writing clean code. By re-running the test cases, the developer can be confident that code refactoring is not damaging any existing functionality.
The concept of removing duplication is an important aspect of any software design. In this case, however, it also applies to removing any duplication between the test code and the production code—for example magic numbers or strings repeated in both to make the test pass in step 3.

== '''Levels of Test Driven Development''' ==
There are two levels of TDD:
;Acceptance TDD (ATDD): With ATDD developers write a single acceptance test, or behavioral specification depending on preferred terminology, and then just enough production functionality/code to fulfill that test. The goal of ATDD is to specify detailed, executable requirements for the solution be on a just in time (JIT) basis. ATDD is also called Behavior Driven Development (BDD).
;Developer TDD: With developer TDD a single developer test is written, sometimes inaccurately referred to as a unit test, and then just enough production code to fulfill that test. The goal of developer TDD is to specify a detailed, executable design for the solution be on a JIT basis. Developer TDD is often simply called TDD.
See more at: http://www.agiledata.org/essays/tdd.html#sthash.11uJfvXR.dpuf

;Testing using xUnit can be done as shown below:
[[File:tdd_xunit.jpg]]

== '''Test Driven Development using JUnit (Example)''' ==
Let's start simple and define a class Money to represent a value in a single currency. We represent the amount by a simple int. To get full accuracy you would probably use double or java.math.BigDecimal to store arbitrary-precision signed decimal numbers. We represent a currency as a string holding the ISO three letter abbreviation (USD, CHF, etc.). In more complex implementations, currency might deserve its own object.
<pre>
class Money {
private int fAmount;
private String fCurrency;
public Money(int amount, String currency) {
fAmount= amount;
fCurrency= currency;
}

public int amount() {
return fAmount;
}

public String currency() {
return fCurrency;
}
}
</pre>

JUnit defines how to structure your test cases and provides the tools to run them. You implement a test in a subclass of TestCase. To test our Money implementation we therefore define MoneyTest as a subclass of TestCase. In Java, classes are contained in packages and we have to decide where to put MoneyTest. Our current practice is to put MoneyTest in the same package as the classes under test. In this way a test case has access to the package private methods.

<pre>
public class MoneyTest extends TestCase {
//…
public void testSimpleAdd() {
Money m12CHF= new Money(12, "CHF"); // (1)
Money m14CHF= new Money(14, "CHF");
Money expected= new Money(26, "CHF");
Money result= m12CHF.add(m14CHF); // (2)
Assert.assertTrue(expected.equals(result)); // (3)
}
}
</pre>

Next let's write the equals method in Money:

<pre>
public boolean equals(Object anObject) {
if (anObject instanceof Money) {
Money aMoney= (Money)anObject;
return aMoney.currency().equals(currency())
&& amount() == aMoney.amount();
}
return false;
}
</pre>
Since equals can receive any kind of object as its argument we first have to check its type before we cast it as a Money. As an aside, it is a recommended practice to also override the method hashCode whenever you override method equals.

In the static way you override the runTest method inherited from TestCase and call the desired test case. A convenient way to do this is with an anonymous inner class. Note that each test must be given a name, so you can identify it if it fails.

<pre>
TestCase test= new MoneyTest("simple add") {
public void runTest() {
testSimpleAdd();
}
};
</pre>

== '''Characteristics of Good Tests'''==
For developers, the implication is that they need to learn how to write effective unit tests. Beck’s experience is that good unit tests:

<li>Run fast (they have short setups, run times, and break downs).
<li>Run in isolation (you should be able to reorder them).
<li>Use data that makes them easy to read and to understand.
<li>Use real data (e.g. copies of production data) when they need to.
<li>Represent one step towards your overall goal.

== '''Traditional Testing''' ==
TDD is primarily a specification technique with a side effect of ensuring that your source code is thoroughly tested at a confirmatory level. However, there is more to testing than this. Particularly at scale you'll still need to consider other agile testing techniques such as pre-production integration testing and investigative testing. Much of this testing can also be done early in your project if you choose to do so (and you should).
With traditional testing a successful test finds one or more defects. It is the same with TDD; when a test fails you have made progress because you now know that you need to resolve the problem. More importantly, you have a clear measure of success when the test no longer fails. TDD increases your confidence that your system actually meets the requirements defined for it, that your system actually works and therefore you can proceed with confidence.
As with traditional testing, the greater the risk profile of the system the more thorough your tests need to be. With both traditional testing and TDD you aren't striving for perfection, instead you are testing to the importance of the system. To paraphrase Agile Modeling (AM), you should "test with a purpose" and know why you are testing something and to what level it needs to be tested. An interesting side effect of TDD is that you achieve 100% coverage test – every single line of code is tested – something that traditional testing doesn’t guarantee (although it does recommend it). In general I think it’s fairly safe to say that although TDD is a specification technique, a valuable side effect is that it results in significantly better code testing than do traditional techniques.

== '''Documentation''' ==
Like it or not most programmers don’t read the written documentation for a system, instead they prefer to work with the code. And there’s nothing wrong with this. When trying to understand a class or operation most programmers will first look for sample code that already invokes it. Well-written unit tests do exactly this – the provide a working specification of your functional code – and as a result unit tests effectively become a significant portion of your technical documentation. The implication is that the expectations of the pro-documentation crowd need to reflect this reality. Similarly, acceptance tests can form an important part of your requirements documentation. This makes a lot of sense when you stop and think about it. Your acceptance tests define exactly what your stakeholders expect of your system, therefore they specify your critical requirements. Your regression test suite, particularly with a test-first approach, effectively becomes detailed executable specifications.

== '''Scaling TDD via Agile Model-Driven Development (AMDD)''' ==
TDD is very good at detailed specification and validation, but not so good at thinking through bigger issues such as the overall design, how people will use the system, or the UI design (for example). Modeling, or more to the point agile model-driven development (AMDD) (the lifecycle for which is captured in Figure 4) is better suited for this. AMDD addresses the agile scaling issues that TDD does not.

;Agile Model Driven Development (AMDD) Lifecycle
[[File:amdd.gif]]

=== TDD vs. AMDD ===

<li>TDD shortens the programming feedback loop whereas AMDD shortens the modeling feedback loop.
<li>TDD provides detailed specification (tests) whereas AMDD is better for thinking through bigger issues.
<li>TDD promotes the development of high-quality code whereas AMDD promotes high-quality communication with your stakeholders and other developers.
<li> TDD provides concrete evidence that your software works whereas AMDD supports your team, including stakeholders, in working toward a common understanding.
<li> TDD “speaks” to programmers whereas AMDD speaks to business analysts, stakeholders, and data professionals.
<li> TDD is provides very finely grained concrete feedback on the order of minutes whereas AMDD enables verbal feedback on the order minutes (concrete feedback requires developers to follow the practice Prove It With Code and thus becomes dependent on non-AM techniques).
<li> TDD helps to ensure that your design is clean by focusing on creation of operations that are callable and testable whereas AMDD provides an opportunity to think through larger design/architectural issues before you code.
<li> TDD is non-visually oriented whereas AMDD is visually oriented.
<li> Both techniques are new to traditional developers and therefore may be threatening to them.
<li> Both techniques support evolutionary development.

== Further Reading ==
* Test Driven Development by Exmaple http://www.eecs.yorku.ca/course_archive/2003-04/W/3311/sectionM/case_studies/money/KentBeck_TDD_byexample.pdf
* Test-Driven Database Development: Unlocking Agility (Net Objectives Lean-Agile Series) http://www.amazon.com/exec/obidos/ASIN/032178412X/ambysoftinc

== References ==

*[http://www.eecs.yorku.ca/course_archive/2003-04/W/3311/sectionM/case_studies/money/KentBeck_TDD_byexample.pdf KentBack Test Driven Development by Example]
*[http://en.wikipedia.org/wiki/Test-driven_development Test Driven Development]
*[http://junit.sourceforge.net/doc/testinfected/testing.htm Test Driven Development in JUnit]
*[http://www.agiledata.org/essays/tdd.html TDD Agile Data Method]

CSC/ECE 517 Fall 2013/ch1 1w31 vm

2013-10-08T00:59:09Z

Mjoshi:

'''Test-driven development''' (TDD) is a software development process that relies on the repetition of a very short development cycle: first the developer writes an (initially failing) automated test case that defines a desired improvement or new function, then produces the minimum amount of code to pass that test, and finally refactors the new code to acceptable standards.
Test-driven development is related to the test-first programming concepts of extreme programming, begun in 1999, but more recently has created more general interest in its own right.
Programmers also apply the concept to improving and debugging legacy code developed with older techniques.

== '''Why to use TDD?'''==
A significant advantage of TDD is that it enables you to take small steps when writing software. This is a practice that has promoted for years because it is far more productive than attempting to code in large steps. For example, assume you add some new functional code, compile, and test it. Chances are pretty good that your tests will be broken by defects that exist in the new code. It is much easier to find, and then fix, those defects if you've written two new lines of code than two thousand. The implication is that the faster your compiler and regression test suite, the more attractive it is to proceed in smaller and smaller steps.

== '''Rules of Thumb'''==
<li>Don’t write a line of new code unless you first have a failing automated test
<li>Eliminate duplication.

These rules generate complex individual and group behavior. Some of the technical implications are:

; Design with organization
TDD recommends that programmers should write their code such that it provides feedback between decisions. It should exhibit a control hierarchy which is easy to manage and understand.

; Write your own tests
This states that developers should write their own tests, since it is not advisable to wait for someone else to write a test every time. In a software environment, developers usually used to rely on testers to find bugs. However, this design says otherwise. It implies that developers know their code inside out and hence should write their own test cases.

; Rapid Response
Your development environment must provide rapid response to small changes. Business requirments are generally fickle and they can change at any point of time. Hence, it is receommended that developers write code such that it can adapt to changes made in future.

; High Cohesion
In computer programming, cohesion refers to the degree to which the elements of a module belong together. Thus, it is a measure of how strongly-related each piece of functionality expressed by the source code of a software module is. The design must consist of many highly cohesive, loosely coupled components, just to make testing easy.

== '''Steps performed in TDD'''==
[[File:tdd_flow.jpg|right]]
The following sequence is based on the book Test-Driven Development by Example.[http://www.eecs.yorku.ca/course_archive/2003-04/W/3311/sectionM/case_studies/money/KentBeck_TDD_byexample.pdf]
=== Quickly add a test ===
In test-driven development, each new feature begins with writing a test. This test must inevitably fail because it is written before the feature has been implemented. (If it does not fail, then either the proposed "new" feature already exists or the test is defective.) To write a test, the developer must clearly understand the feature's specification and requirements. The developer can accomplish this through use cases and user stories to cover the requirements and exception conditions, and can write the test in whatever testing framework is appropriate to the software environment. This could also be a modification of an existing test. This is a differentiating feature of test-driven development versus writing unit tests after the code is written: it makes the developer focus on the requirements before writing the code, a subtle but important difference.
=== Run all tests and see the new one fail ===
This validates that the test harness is working correctly and that the new test does not mistakenly pass without requiring any new code. This step also tests the test itself, in the negative: it rules out the possibility that the new test always passes, and therefore is worthless. The new test should also fail for the expected reason. This increases confidence (though does not guarantee) that it is testing the right thing, and passes only in intended cases.
=== Make a little change ===
The next step is to write some code that causes the test to pass. The new code written at this stage is not perfect, and may, for example, pass the test in an inelegant way. That is acceptable because later steps improve and hone it.
At this point, the only purpose of the written code is to pass the test; no further (and therefore untested) functionality should be predicted and 'allowed for' at any stage.
=== Run all tests and see them all succeed ===
If all test cases now pass, the programmer can be confident that the code meets all the tested requirements. This is a good point from which to begin the final step of the cycle.
=== Refactor to remove duplication ===
Now the code should be cleaned up as necessary. Move code from where it was convenient for passing the test to where it logically belongs. Remove any duplication you can find. Make sure that variable and method names represent their current use. Clarify any constructs that might be misinterpreted. Use Kent Beck's four rules of simple design[5][6] to guide you, as well as anything else you know about writing clean code. By re-running the test cases, the developer can be confident that code refactoring is not damaging any existing functionality.
The concept of removing duplication is an important aspect of any software design. In this case, however, it also applies to removing any duplication between the test code and the production code—for example magic numbers or strings repeated in both to make the test pass in step 3.

== '''Levels of Test Driven Development''' ==
There are two levels of TDD:
;Acceptance TDD (ATDD): With ATDD developers write a single acceptance test, or behavioral specification depending on preferred terminology, and then just enough production functionality/code to fulfill that test. The goal of ATDD is to specify detailed, executable requirements for the solution be on a just in time (JIT) basis. ATDD is also called Behavior Driven Development (BDD).
;Developer TDD: With developer TDD a single developer test is written, sometimes inaccurately referred to as a unit test, and then just enough production code to fulfill that test. The goal of developer TDD is to specify a detailed, executable design for the solution be on a JIT basis. Developer TDD is often simply called TDD.
See more at: http://www.agiledata.org/essays/tdd.html#sthash.11uJfvXR.dpuf

;Testing using xUnit can be done as shown below:
[[File:tdd_xunit.jpg]]

== '''Test Driven Development using JUnit (Example)''' ==
Let's start simple and define a class Money to represent a value in a single currency. We represent the amount by a simple int. To get full accuracy you would probably use double or java.math.BigDecimal to store arbitrary-precision signed decimal numbers. We represent a currency as a string holding the ISO three letter abbreviation (USD, CHF, etc.). In more complex implementations, currency might deserve its own object.
<pre>
class Money {
private int fAmount;
private String fCurrency;
public Money(int amount, String currency) {
fAmount= amount;
fCurrency= currency;
}

public int amount() {
return fAmount;
}

public String currency() {
return fCurrency;
}
}
</pre>

JUnit defines how to structure your test cases and provides the tools to run them. You implement a test in a subclass of TestCase. To test our Money implementation we therefore define MoneyTest as a subclass of TestCase. In Java, classes are contained in packages and we have to decide where to put MoneyTest. Our current practice is to put MoneyTest in the same package as the classes under test. In this way a test case has access to the package private methods.

<pre>
public class MoneyTest extends TestCase {
//…
public void testSimpleAdd() {
Money m12CHF= new Money(12, "CHF"); // (1)
Money m14CHF= new Money(14, "CHF");
Money expected= new Money(26, "CHF");
Money result= m12CHF.add(m14CHF); // (2)
Assert.assertTrue(expected.equals(result)); // (3)
}
}
</pre>

Next let's write the equals method in Money:

<pre>
public boolean equals(Object anObject) {
if (anObject instanceof Money) {
Money aMoney= (Money)anObject;
return aMoney.currency().equals(currency())
&& amount() == aMoney.amount();
}
return false;
}
</pre>
Since equals can receive any kind of object as its argument we first have to check its type before we cast it as a Money. As an aside, it is a recommended practice to also override the method hashCode whenever you override method equals.

In the static way you override the runTest method inherited from TestCase and call the desired test case. A convenient way to do this is with an anonymous inner class. Note that each test must be given a name, so you can identify it if it fails.

<pre>
TestCase test= new MoneyTest("simple add") {
public void runTest() {
testSimpleAdd();
}
};
</pre>

== '''Characteristics of Good Tests'''==
For developers, the implication is that they need to learn how to write effective unit tests. Beck’s experience is that good unit tests:

<li>Run fast (they have short setups, run times, and break downs).
<li>Run in isolation (you should be able to reorder them).
<li>Use data that makes them easy to read and to understand.
<li>Use real data (e.g. copies of production data) when they need to.
<li>Represent one step towards your overall goal.

== '''Traditional Testing''' ==
TDD is primarily a specification technique with a side effect of ensuring that your source code is thoroughly tested at a confirmatory level. However, there is more to testing than this. Particularly at scale you'll still need to consider other agile testing techniques such as pre-production integration testing and investigative testing. Much of this testing can also be done early in your project if you choose to do so (and you should).
With traditional testing a successful test finds one or more defects. It is the same with TDD; when a test fails you have made progress because you now know that you need to resolve the problem. More importantly, you have a clear measure of success when the test no longer fails. TDD increases your confidence that your system actually meets the requirements defined for it, that your system actually works and therefore you can proceed with confidence.
As with traditional testing, the greater the risk profile of the system the more thorough your tests need to be. With both traditional testing and TDD you aren't striving for perfection, instead you are testing to the importance of the system. To paraphrase Agile Modeling (AM), you should "test with a purpose" and know why you are testing something and to what level it needs to be tested. An interesting side effect of TDD is that you achieve 100% coverage test – every single line of code is tested – something that traditional testing doesn’t guarantee (although it does recommend it). In general I think it’s fairly safe to say that although TDD is a specification technique, a valuable side effect is that it results in significantly better code testing than do traditional techniques.

== '''Documentation''' ==
Like it or not most programmers don’t read the written documentation for a system, instead they prefer to work with the code. And there’s nothing wrong with this. When trying to understand a class or operation most programmers will first look for sample code that already invokes it. Well-written unit tests do exactly this – the provide a working specification of your functional code – and as a result unit tests effectively become a significant portion of your technical documentation. The implication is that the expectations of the pro-documentation crowd need to reflect this reality. Similarly, acceptance tests can form an important part of your requirements documentation. This makes a lot of sense when you stop and think about it. Your acceptance tests define exactly what your stakeholders expect of your system, therefore they specify your critical requirements. Your regression test suite, particularly with a test-first approach, effectively becomes detailed executable specifications.

== '''Scaling TDD via Agile Model-Driven Development (AMDD)''' ==
TDD is very good at detailed specification and validation, but not so good at thinking through bigger issues such as the overall design, how people will use the system, or the UI design (for example). Modeling, or more to the point agile model-driven development (AMDD) (the lifecycle for which is captured in Figure 4) is better suited for this. AMDD addresses the agile scaling issues that TDD does not.

;Agile Model Driven Development (AMDD) Lifecycle
[[File:amdd.gif]]

=== TDD vs. AMDD ===

<li>TDD shortens the programming feedback loop whereas AMDD shortens the modeling feedback loop.
<li>TDD provides detailed specification (tests) whereas AMDD is better for thinking through bigger issues.
<li>TDD promotes the development of high-quality code whereas AMDD promotes high-quality communication with your stakeholders and other developers.
<li> TDD provides concrete evidence that your software works whereas AMDD supports your team, including stakeholders, in working toward a common understanding.
<li> TDD “speaks” to programmers whereas AMDD speaks to business analysts, stakeholders, and data professionals.
<li> TDD is provides very finely grained concrete feedback on the order of minutes whereas AMDD enables verbal feedback on the order minutes (concrete feedback requires developers to follow the practice Prove It With Code and thus becomes dependent on non-AM techniques).
<li> TDD helps to ensure that your design is clean by focusing on creation of operations that are callable and testable whereas AMDD provides an opportunity to think through larger design/architectural issues before you code.
<li> TDD is non-visually oriented whereas AMDD is visually oriented.
<li> Both techniques are new to traditional developers and therefore may be threatening to them.
<li> Both techniques support evolutionary development.

== Further Reading ==
* Test Driven Development by Exmaple http://www.eecs.yorku.ca/course_archive/2003-04/W/3311/sectionM/case_studies/money/KentBeck_TDD_byexample.pdf
* Test-Driven Database Development: Unlocking Agility (Net Objectives Lean-Agile Series) http://www.amazon.com/exec/obidos/ASIN/032178412X/ambysoftinc

== References ==

*[http://www.eecs.yorku.ca/course_archive/2003-04/W/3311/sectionM/case_studies/money/KentBeck_TDD_byexample.pdf KentBack Test Driven Development by Example]
*[http://en.wikipedia.org/wiki/Test-driven_development Test Driven Development]
*[http://junit.sourceforge.net/doc/testinfected/testing.htm Test Driven Development in JUnit]
*[http://www.agiledata.org/essays/tdd.html TDD Agile Data Method]

CSC/ECE 517 Fall 2013/ch1 1w31 vm

2013-10-07T13:12:01Z

Mjoshi: /* Why to use TDD? */

'''Test-driven development''' (TDD) is a software development process that relies on the repetition of a very short development cycle: first the developer writes an (initially failing) automated test case that defines a desired improvement or new function, then produces the minimum amount of code to pass that test, and finally refactors the new code to acceptable standards. Kent Beck, who is credited with having developed or 'rediscovered' the technique, stated in 2003 that TDD encourages simple designs and inspires confidence.
Test-driven development is related to the test-first programming concepts of extreme programming, begun in 1999, but more recently has created more general interest in its own right.
Programmers also apply the concept to improving and debugging legacy code developed with older techniques.

== '''Why to use TDD?'''==
A significant advantage of TDD is that it enables you to take small steps when writing software. This is a practice that has promoted for years because it is far more productive than attempting to code in large steps. For example, assume you add some new functional code, compile, and test it. Chances are pretty good that your tests will be broken by defects that exist in the new code. It is much easier to find, and then fix, those defects if you've written two new lines of code than two thousand. The implication is that the faster your compiler and regression test suite, the more attractive it is to proceed in smaller and smaller steps.

== '''Rules of Thumb'''==
<li>Don’t write a line of new code unless you first have a failing automated test
<li>Eliminate duplication.

These rules generate complex individual and group behavior. Some of the technical implications are:

; Design with organization
TDD recommends that programmers should write their code such that it provides feedback between decisions. It should exhibit a control hierarchy which is easy to manage and understand.

; Write your own tests
This states that developers should write their own tests, since it is not advisable to wait for someone else to write a test every time. In a software environment, developers usually used to rely on testers to find bugs. However, this design says otherwise. It implies that developers know their code inside out and hence should write their own test cases.

; Rapid Response
Your development environment must provide rapid response to small changes. Business requirments are generally fickle and they can change at any point of time. Hence, it is receommended that developers write code such that it can adapt to changes made in future.

; High Cohesion
In computer programming, cohesion refers to the degree to which the elements of a module belong together. Thus, it is a measure of how strongly-related each piece of functionality expressed by the source code of a software module is. The design must consist of many highly cohesive, loosely coupled components, just to make testing easy.

== '''Steps performed in TDD'''==
[[File:tdd_flow.jpg|right]]
The following sequence is based on the book Test-Driven Development by Example.[http://www.eecs.yorku.ca/course_archive/2003-04/W/3311/sectionM/case_studies/money/KentBeck_TDD_byexample.pdf]
=== Quickly add a test ===
In test-driven development, each new feature begins with writing a test. This test must inevitably fail because it is written before the feature has been implemented. (If it does not fail, then either the proposed "new" feature already exists or the test is defective.) To write a test, the developer must clearly understand the feature's specification and requirements. The developer can accomplish this through use cases and user stories to cover the requirements and exception conditions, and can write the test in whatever testing framework is appropriate to the software environment. This could also be a modification of an existing test. This is a differentiating feature of test-driven development versus writing unit tests after the code is written: it makes the developer focus on the requirements before writing the code, a subtle but important difference.
=== Run all tests and see the new one fail ===
This validates that the test harness is working correctly and that the new test does not mistakenly pass without requiring any new code. This step also tests the test itself, in the negative: it rules out the possibility that the new test always passes, and therefore is worthless. The new test should also fail for the expected reason. This increases confidence (though does not guarantee) that it is testing the right thing, and passes only in intended cases.
=== Make a little change ===
The next step is to write some code that causes the test to pass. The new code written at this stage is not perfect, and may, for example, pass the test in an inelegant way. That is acceptable because later steps improve and hone it.
At this point, the only purpose of the written code is to pass the test; no further (and therefore untested) functionality should be predicted and 'allowed for' at any stage.
=== Run all tests and see them all succeed ===
If all test cases now pass, the programmer can be confident that the code meets all the tested requirements. This is a good point from which to begin the final step of the cycle.
=== Refactor to remove duplication ===
Now the code should be cleaned up as necessary. Move code from where it was convenient for passing the test to where it logically belongs. Remove any duplication you can find. Make sure that variable and method names represent their current use. Clarify any constructs that might be misinterpreted. Use Kent Beck's four rules of simple design[5][6] to guide you, as well as anything else you know about writing clean code. By re-running the test cases, the developer can be confident that code refactoring is not damaging any existing functionality.
The concept of removing duplication is an important aspect of any software design. In this case, however, it also applies to removing any duplication between the test code and the production code—for example magic numbers or strings repeated in both to make the test pass in step 3.

== '''Levels of Test Driven Development''' ==
There are two levels of TDD:
;Acceptance TDD (ATDD): With ATDD developers write a single acceptance test, or behavioral specification depending on preferred terminology, and then just enough production functionality/code to fulfill that test. The goal of ATDD is to specify detailed, executable requirements for the solution be on a just in time (JIT) basis. ATDD is also called Behavior Driven Development (BDD).
;Developer TDD: With developer TDD a single developer test is written, sometimes inaccurately referred to as a unit test, and then just enough production code to fulfill that test. The goal of developer TDD is to specify a detailed, executable design for the solution be on a JIT basis. Developer TDD is often simply called TDD.
See more at: http://www.agiledata.org/essays/tdd.html#sthash.11uJfvXR.dpuf

;Testing using xUnit can be done as shown below:
[[File:tdd_xunit.jpg]]

== '''Test Driven Development using JUnit (Example)''' ==
Let's start simple and define a class Money to represent a value in a single currency. We represent the amount by a simple int. To get full accuracy you would probably use double or java.math.BigDecimal to store arbitrary-precision signed decimal numbers. We represent a currency as a string holding the ISO three letter abbreviation (USD, CHF, etc.). In more complex implementations, currency might deserve its own object.
<pre>
class Money {
private int fAmount;
private String fCurrency;
public Money(int amount, String currency) {
fAmount= amount;
fCurrency= currency;
}

public int amount() {
return fAmount;
}

public String currency() {
return fCurrency;
}
}
</pre>

JUnit defines how to structure your test cases and provides the tools to run them. You implement a test in a subclass of TestCase. To test our Money implementation we therefore define MoneyTest as a subclass of TestCase. In Java, classes are contained in packages and we have to decide where to put MoneyTest. Our current practice is to put MoneyTest in the same package as the classes under test. In this way a test case has access to the package private methods.

<pre>
public class MoneyTest extends TestCase {
//…
public void testSimpleAdd() {
Money m12CHF= new Money(12, "CHF"); // (1)
Money m14CHF= new Money(14, "CHF");
Money expected= new Money(26, "CHF");
Money result= m12CHF.add(m14CHF); // (2)
Assert.assertTrue(expected.equals(result)); // (3)
}
}
</pre>

Next let's write the equals method in Money:

<pre>
public boolean equals(Object anObject) {
if (anObject instanceof Money) {
Money aMoney= (Money)anObject;
return aMoney.currency().equals(currency())
&& amount() == aMoney.amount();
}
return false;
}
</pre>
Since equals can receive any kind of object as its argument we first have to check its type before we cast it as a Money. As an aside, it is a recommended practice to also override the method hashCode whenever you override method equals.

In the static way you override the runTest method inherited from TestCase and call the desired test case. A convenient way to do this is with an anonymous inner class. Note that each test must be given a name, so you can identify it if it fails.

<pre>
TestCase test= new MoneyTest("simple add") {
public void runTest() {
testSimpleAdd();
}
};
</pre>

== '''Characteristics of Good Tests'''==
For developers, the implication is that they need to learn how to write effective unit tests. Beck’s experience is that good unit tests:

<li>Run fast (they have short setups, run times, and break downs).
<li>Run in isolation (you should be able to reorder them).
<li>Use data that makes them easy to read and to understand.
<li>Use real data (e.g. copies of production data) when they need to.
<li>Represent one step towards your overall goal.

== '''Traditional Testing''' ==
TDD is primarily a specification technique with a side effect of ensuring that your source code is thoroughly tested at a confirmatory level. However, there is more to testing than this. Particularly at scale you'll still need to consider other agile testing techniques such as pre-production integration testing and investigative testing. Much of this testing can also be done early in your project if you choose to do so (and you should).
With traditional testing a successful test finds one or more defects. It is the same with TDD; when a test fails you have made progress because you now know that you need to resolve the problem. More importantly, you have a clear measure of success when the test no longer fails. TDD increases your confidence that your system actually meets the requirements defined for it, that your system actually works and therefore you can proceed with confidence.
As with traditional testing, the greater the risk profile of the system the more thorough your tests need to be. With both traditional testing and TDD you aren't striving for perfection, instead you are testing to the importance of the system. To paraphrase Agile Modeling (AM), you should "test with a purpose" and know why you are testing something and to what level it needs to be tested. An interesting side effect of TDD is that you achieve 100% coverage test – every single line of code is tested – something that traditional testing doesn’t guarantee (although it does recommend it). In general I think it’s fairly safe to say that although TDD is a specification technique, a valuable side effect is that it results in significantly better code testing than do traditional techniques.

== '''Documentation''' ==
Like it or not most programmers don’t read the written documentation for a system, instead they prefer to work with the code. And there’s nothing wrong with this. When trying to understand a class or operation most programmers will first look for sample code that already invokes it. Well-written unit tests do exactly this – the provide a working specification of your functional code – and as a result unit tests effectively become a significant portion of your technical documentation. The implication is that the expectations of the pro-documentation crowd need to reflect this reality. Similarly, acceptance tests can form an important part of your requirements documentation. This makes a lot of sense when you stop and think about it. Your acceptance tests define exactly what your stakeholders expect of your system, therefore they specify your critical requirements. Your regression test suite, particularly with a test-first approach, effectively becomes detailed executable specifications.

== '''Scaling TDD via Agile Model-Driven Development (AMDD)''' ==
TDD is very good at detailed specification and validation, but not so good at thinking through bigger issues such as the overall design, how people will use the system, or the UI design (for example). Modeling, or more to the point agile model-driven development (AMDD) (the lifecycle for which is captured in Figure 4) is better suited for this. AMDD addresses the agile scaling issues that TDD does not.

;Agile Model Driven Development (AMDD) Lifecycle
[[File:amdd.gif]]

=== TDD vs. AMDD ===

<li>TDD shortens the programming feedback loop whereas AMDD shortens the modeling feedback loop.
<li>TDD provides detailed specification (tests) whereas AMDD is better for thinking through bigger issues.
<li>TDD promotes the development of high-quality code whereas AMDD promotes high-quality communication with your stakeholders and other developers.
<li> TDD provides concrete evidence that your software works whereas AMDD supports your team, including stakeholders, in working toward a common understanding.
<li> TDD “speaks” to programmers whereas AMDD speaks to business analysts, stakeholders, and data professionals.
<li> TDD is provides very finely grained concrete feedback on the order of minutes whereas AMDD enables verbal feedback on the order minutes (concrete feedback requires developers to follow the practice Prove It With Code and thus becomes dependent on non-AM techniques).
<li> TDD helps to ensure that your design is clean by focusing on creation of operations that are callable and testable whereas AMDD provides an opportunity to think through larger design/architectural issues before you code.
<li> TDD is non-visually oriented whereas AMDD is visually oriented.
<li> Both techniques are new to traditional developers and therefore may be threatening to them.
<li> Both techniques support evolutionary development.

== Further Reading ==
* Test Driven Development by Exmaple http://www.eecs.yorku.ca/course_archive/2003-04/W/3311/sectionM/case_studies/money/KentBeck_TDD_byexample.pdf
* Test-Driven Database Development: Unlocking Agility (Net Objectives Lean-Agile Series) http://www.amazon.com/exec/obidos/ASIN/032178412X/ambysoftinc

== References ==

*[http://www.eecs.yorku.ca/course_archive/2003-04/W/3311/sectionM/case_studies/money/KentBeck_TDD_byexample.pdf KentBack Test Driven Development by Example]
*[http://en.wikipedia.org/wiki/Test-driven_development Test Driven Development]
*[http://junit.sourceforge.net/doc/testinfected/testing.htm Test Driven Development in JUnit]
*[http://www.agiledata.org/essays/tdd.html TDD Agile Data Method]

CSC/ECE 517 Fall 2013/ch1 1w31 vm

2013-10-07T11:36:46Z

Mjoshi: /* References */

'''Test-driven development''' (TDD) is a software development process that relies on the repetition of a very short development cycle: first the developer writes an (initially failing) automated test case that defines a desired improvement or new function, then produces the minimum amount of code to pass that test, and finally refactors the new code to acceptable standards. Kent Beck, who is credited with having developed or 'rediscovered' the technique, stated in 2003 that TDD encourages simple designs and inspires confidence.
Test-driven development is related to the test-first programming concepts of extreme programming, begun in 1999, but more recently has created more general interest in its own right.
Programmers also apply the concept to improving and debugging legacy code developed with older techniques.

== '''Why to use TDD?'''==
A significant advantage of TDD is that it enables you to take small steps when writing software. This is a practice that I have promoted for years because it is far more productive than attempting to code in large steps. For example, assume you add some new functional code, compile, and test it. Chances are pretty good that your tests will be broken by defects that exist in the new code. It is much easier to find, and then fix, those defects if you've written two new lines of code than two thousand. The implication is that the faster your compiler and regression test suite, the more attractive it is to proceed in smaller and smaller steps.

== '''Rules of Thumb'''==
<li>Don’t write a line of new code unless you first have a failing automated test
<li>Eliminate duplication.

These rules generate complex individual and group behavior. Some of the technical implications are:

; Design with organization
TDD recommends that programmers should write their code such that it provides feedback between decisions. It should exhibit a control hierarchy which is easy to manage and understand.

; Write your own tests
This states that developers should write their own tests, since it is not advisable to wait for someone else to write a test every time. In a software environment, developers usually used to rely on testers to find bugs. However, this design says otherwise. It implies that developers know their code inside out and hence should write their own test cases.

; Rapid Response
Your development environment must provide rapid response to small changes. Business requirments are generally fickle and they can change at any point of time. Hence, it is receommended that developers write code such that it can adapt to changes made in future.

; High Cohesion
In computer programming, cohesion refers to the degree to which the elements of a module belong together. Thus, it is a measure of how strongly-related each piece of functionality expressed by the source code of a software module is. The design must consist of many highly cohesive, loosely coupled components, just to make testing easy.

== '''Steps performed in TDD'''==
[[File:tdd_flow.jpg|right]]
The following sequence is based on the book Test-Driven Development by Example.[http://www.eecs.yorku.ca/course_archive/2003-04/W/3311/sectionM/case_studies/money/KentBeck_TDD_byexample.pdf]
=== Quickly add a test ===
In test-driven development, each new feature begins with writing a test. This test must inevitably fail because it is written before the feature has been implemented. (If it does not fail, then either the proposed "new" feature already exists or the test is defective.) To write a test, the developer must clearly understand the feature's specification and requirements. The developer can accomplish this through use cases and user stories to cover the requirements and exception conditions, and can write the test in whatever testing framework is appropriate to the software environment. This could also be a modification of an existing test. This is a differentiating feature of test-driven development versus writing unit tests after the code is written: it makes the developer focus on the requirements before writing the code, a subtle but important difference.
=== Run all tests and see the new one fail ===
This validates that the test harness is working correctly and that the new test does not mistakenly pass without requiring any new code. This step also tests the test itself, in the negative: it rules out the possibility that the new test always passes, and therefore is worthless. The new test should also fail for the expected reason. This increases confidence (though does not guarantee) that it is testing the right thing, and passes only in intended cases.
=== Make a little change ===
The next step is to write some code that causes the test to pass. The new code written at this stage is not perfect, and may, for example, pass the test in an inelegant way. That is acceptable because later steps improve and hone it.
At this point, the only purpose of the written code is to pass the test; no further (and therefore untested) functionality should be predicted and 'allowed for' at any stage.
=== Run all tests and see them all succeed ===
If all test cases now pass, the programmer can be confident that the code meets all the tested requirements. This is a good point from which to begin the final step of the cycle.
=== Refactor to remove duplication ===
Now the code should be cleaned up as necessary. Move code from where it was convenient for passing the test to where it logically belongs. Remove any duplication you can find. Make sure that variable and method names represent their current use. Clarify any constructs that might be misinterpreted. Use Kent Beck's four rules of simple design[5][6] to guide you, as well as anything else you know about writing clean code. By re-running the test cases, the developer can be confident that code refactoring is not damaging any existing functionality.
The concept of removing duplication is an important aspect of any software design. In this case, however, it also applies to removing any duplication between the test code and the production code—for example magic numbers or strings repeated in both to make the test pass in step 3.

== '''Levels of Test Driven Development''' ==
There are two levels of TDD:
;Acceptance TDD (ATDD): With ATDD developers write a single acceptance test, or behavioral specification depending on preferred terminology, and then just enough production functionality/code to fulfill that test. The goal of ATDD is to specify detailed, executable requirements for the solution be on a just in time (JIT) basis. ATDD is also called Behavior Driven Development (BDD).
;Developer TDD: With developer TDD a single developer test is written, sometimes inaccurately referred to as a unit test, and then just enough production code to fulfill that test. The goal of developer TDD is to specify a detailed, executable design for the solution be on a JIT basis. Developer TDD is often simply called TDD.
See more at: http://www.agiledata.org/essays/tdd.html#sthash.11uJfvXR.dpuf

;Testing using xUnit can be done as shown below:
[[File:tdd_xunit.jpg]]

== '''Test Driven Development using JUnit (Example)''' ==
Let's start simple and define a class Money to represent a value in a single currency. We represent the amount by a simple int. To get full accuracy you would probably use double or java.math.BigDecimal to store arbitrary-precision signed decimal numbers. We represent a currency as a string holding the ISO three letter abbreviation (USD, CHF, etc.). In more complex implementations, currency might deserve its own object.
<pre>
class Money {
private int fAmount;
private String fCurrency;
public Money(int amount, String currency) {
fAmount= amount;
fCurrency= currency;
}

public int amount() {
return fAmount;
}

public String currency() {
return fCurrency;
}
}
</pre>

JUnit defines how to structure your test cases and provides the tools to run them. You implement a test in a subclass of TestCase. To test our Money implementation we therefore define MoneyTest as a subclass of TestCase. In Java, classes are contained in packages and we have to decide where to put MoneyTest. Our current practice is to put MoneyTest in the same package as the classes under test. In this way a test case has access to the package private methods.

<pre>
public class MoneyTest extends TestCase {
//…
public void testSimpleAdd() {
Money m12CHF= new Money(12, "CHF"); // (1)
Money m14CHF= new Money(14, "CHF");
Money expected= new Money(26, "CHF");
Money result= m12CHF.add(m14CHF); // (2)
Assert.assertTrue(expected.equals(result)); // (3)
}
}
</pre>

Next let's write the equals method in Money:

<pre>
public boolean equals(Object anObject) {
if (anObject instanceof Money) {
Money aMoney= (Money)anObject;
return aMoney.currency().equals(currency())
&& amount() == aMoney.amount();
}
return false;
}
</pre>
Since equals can receive any kind of object as its argument we first have to check its type before we cast it as a Money. As an aside, it is a recommended practice to also override the method hashCode whenever you override method equals.

In the static way you override the runTest method inherited from TestCase and call the desired test case. A convenient way to do this is with an anonymous inner class. Note that each test must be given a name, so you can identify it if it fails.

<pre>
TestCase test= new MoneyTest("simple add") {
public void runTest() {
testSimpleAdd();
}
};
</pre>

== '''Characteristics of Good Tests'''==
For developers, the implication is that they need to learn how to write effective unit tests. Beck’s experience is that good unit tests:

<li>Run fast (they have short setups, run times, and break downs).
<li>Run in isolation (you should be able to reorder them).
<li>Use data that makes them easy to read and to understand.
<li>Use real data (e.g. copies of production data) when they need to.
<li>Represent one step towards your overall goal.

== '''Traditional Testing''' ==
TDD is primarily a specification technique with a side effect of ensuring that your source code is thoroughly tested at a confirmatory level. However, there is more to testing than this. Particularly at scale you'll still need to consider other agile testing techniques such as pre-production integration testing and investigative testing. Much of this testing can also be done early in your project if you choose to do so (and you should).
With traditional testing a successful test finds one or more defects. It is the same with TDD; when a test fails you have made progress because you now know that you need to resolve the problem. More importantly, you have a clear measure of success when the test no longer fails. TDD increases your confidence that your system actually meets the requirements defined for it, that your system actually works and therefore you can proceed with confidence.
As with traditional testing, the greater the risk profile of the system the more thorough your tests need to be. With both traditional testing and TDD you aren't striving for perfection, instead you are testing to the importance of the system. To paraphrase Agile Modeling (AM), you should "test with a purpose" and know why you are testing something and to what level it needs to be tested. An interesting side effect of TDD is that you achieve 100% coverage test – every single line of code is tested – something that traditional testing doesn’t guarantee (although it does recommend it). In general I think it’s fairly safe to say that although TDD is a specification technique, a valuable side effect is that it results in significantly better code testing than do traditional techniques.

== '''Documentation''' ==
Like it or not most programmers don’t read the written documentation for a system, instead they prefer to work with the code. And there’s nothing wrong with this. When trying to understand a class or operation most programmers will first look for sample code that already invokes it. Well-written unit tests do exactly this – the provide a working specification of your functional code – and as a result unit tests effectively become a significant portion of your technical documentation. The implication is that the expectations of the pro-documentation crowd need to reflect this reality. Similarly, acceptance tests can form an important part of your requirements documentation. This makes a lot of sense when you stop and think about it. Your acceptance tests define exactly what your stakeholders expect of your system, therefore they specify your critical requirements. Your regression test suite, particularly with a test-first approach, effectively becomes detailed executable specifications.

== '''Scaling TDD via Agile Model-Driven Development (AMDD)''' ==
TDD is very good at detailed specification and validation, but not so good at thinking through bigger issues such as the overall design, how people will use the system, or the UI design (for example). Modeling, or more to the point agile model-driven development (AMDD) (the lifecycle for which is captured in Figure 4) is better suited for this. AMDD addresses the agile scaling issues that TDD does not.

;Agile Model Driven Development (AMDD) Lifecycle
[[File:amdd.gif]]

=== TDD vs. AMDD ===

<li>TDD shortens the programming feedback loop whereas AMDD shortens the modeling feedback loop.
<li>TDD provides detailed specification (tests) whereas AMDD is better for thinking through bigger issues.
<li>TDD promotes the development of high-quality code whereas AMDD promotes high-quality communication with your stakeholders and other developers.
<li> TDD provides concrete evidence that your software works whereas AMDD supports your team, including stakeholders, in working toward a common understanding.
<li> TDD “speaks” to programmers whereas AMDD speaks to business analysts, stakeholders, and data professionals.
<li> TDD is provides very finely grained concrete feedback on the order of minutes whereas AMDD enables verbal feedback on the order minutes (concrete feedback requires developers to follow the practice Prove It With Code and thus becomes dependent on non-AM techniques).
<li> TDD helps to ensure that your design is clean by focusing on creation of operations that are callable and testable whereas AMDD provides an opportunity to think through larger design/architectural issues before you code.
<li> TDD is non-visually oriented whereas AMDD is visually oriented.
<li> Both techniques are new to traditional developers and therefore may be threatening to them.
<li> Both techniques support evolutionary development.

== Further Reading ==
* Test Driven Development by Exmaple http://www.eecs.yorku.ca/course_archive/2003-04/W/3311/sectionM/case_studies/money/KentBeck_TDD_byexample.pdf
* Test-Driven Database Development: Unlocking Agility (Net Objectives Lean-Agile Series) http://www.amazon.com/exec/obidos/ASIN/032178412X/ambysoftinc

== References ==

*[http://www.eecs.yorku.ca/course_archive/2003-04/W/3311/sectionM/case_studies/money/KentBeck_TDD_byexample.pdf KentBack Test Driven Development by Example]
*[http://en.wikipedia.org/wiki/Test-driven_development Test Driven Development]
*[http://junit.sourceforge.net/doc/testinfected/testing.htm Test Driven Development in JUnit]
*[http://www.agiledata.org/essays/tdd.html TDD Agile Data Method]

CSC/ECE 517 Fall 2013/ch1 1w31 vm

2013-10-07T11:34:52Z

Mjoshi:

'''Test-driven development''' (TDD) is a software development process that relies on the repetition of a very short development cycle: first the developer writes an (initially failing) automated test case that defines a desired improvement or new function, then produces the minimum amount of code to pass that test, and finally refactors the new code to acceptable standards. Kent Beck, who is credited with having developed or 'rediscovered' the technique, stated in 2003 that TDD encourages simple designs and inspires confidence.
Test-driven development is related to the test-first programming concepts of extreme programming, begun in 1999, but more recently has created more general interest in its own right.
Programmers also apply the concept to improving and debugging legacy code developed with older techniques.

== '''Why to use TDD?'''==
A significant advantage of TDD is that it enables you to take small steps when writing software. This is a practice that I have promoted for years because it is far more productive than attempting to code in large steps. For example, assume you add some new functional code, compile, and test it. Chances are pretty good that your tests will be broken by defects that exist in the new code. It is much easier to find, and then fix, those defects if you've written two new lines of code than two thousand. The implication is that the faster your compiler and regression test suite, the more attractive it is to proceed in smaller and smaller steps.

== '''Rules of Thumb'''==
<li>Don’t write a line of new code unless you first have a failing automated test
<li>Eliminate duplication.

These rules generate complex individual and group behavior. Some of the technical implications are:

; Design with organization
TDD recommends that programmers should write their code such that it provides feedback between decisions. It should exhibit a control hierarchy which is easy to manage and understand.

; Write your own tests
This states that developers should write their own tests, since it is not advisable to wait for someone else to write a test every time. In a software environment, developers usually used to rely on testers to find bugs. However, this design says otherwise. It implies that developers know their code inside out and hence should write their own test cases.

; Rapid Response
Your development environment must provide rapid response to small changes. Business requirments are generally fickle and they can change at any point of time. Hence, it is receommended that developers write code such that it can adapt to changes made in future.

; High Cohesion
In computer programming, cohesion refers to the degree to which the elements of a module belong together. Thus, it is a measure of how strongly-related each piece of functionality expressed by the source code of a software module is. The design must consist of many highly cohesive, loosely coupled components, just to make testing easy.

== '''Steps performed in TDD'''==
[[File:tdd_flow.jpg|right]]
The following sequence is based on the book Test-Driven Development by Example.[http://www.eecs.yorku.ca/course_archive/2003-04/W/3311/sectionM/case_studies/money/KentBeck_TDD_byexample.pdf]
=== Quickly add a test ===
In test-driven development, each new feature begins with writing a test. This test must inevitably fail because it is written before the feature has been implemented. (If it does not fail, then either the proposed "new" feature already exists or the test is defective.) To write a test, the developer must clearly understand the feature's specification and requirements. The developer can accomplish this through use cases and user stories to cover the requirements and exception conditions, and can write the test in whatever testing framework is appropriate to the software environment. This could also be a modification of an existing test. This is a differentiating feature of test-driven development versus writing unit tests after the code is written: it makes the developer focus on the requirements before writing the code, a subtle but important difference.
=== Run all tests and see the new one fail ===
This validates that the test harness is working correctly and that the new test does not mistakenly pass without requiring any new code. This step also tests the test itself, in the negative: it rules out the possibility that the new test always passes, and therefore is worthless. The new test should also fail for the expected reason. This increases confidence (though does not guarantee) that it is testing the right thing, and passes only in intended cases.
=== Make a little change ===
The next step is to write some code that causes the test to pass. The new code written at this stage is not perfect, and may, for example, pass the test in an inelegant way. That is acceptable because later steps improve and hone it.
At this point, the only purpose of the written code is to pass the test; no further (and therefore untested) functionality should be predicted and 'allowed for' at any stage.
=== Run all tests and see them all succeed ===
If all test cases now pass, the programmer can be confident that the code meets all the tested requirements. This is a good point from which to begin the final step of the cycle.
=== Refactor to remove duplication ===
Now the code should be cleaned up as necessary. Move code from where it was convenient for passing the test to where it logically belongs. Remove any duplication you can find. Make sure that variable and method names represent their current use. Clarify any constructs that might be misinterpreted. Use Kent Beck's four rules of simple design[5][6] to guide you, as well as anything else you know about writing clean code. By re-running the test cases, the developer can be confident that code refactoring is not damaging any existing functionality.
The concept of removing duplication is an important aspect of any software design. In this case, however, it also applies to removing any duplication between the test code and the production code—for example magic numbers or strings repeated in both to make the test pass in step 3.

== '''Levels of Test Driven Development''' ==
There are two levels of TDD:
;Acceptance TDD (ATDD): With ATDD developers write a single acceptance test, or behavioral specification depending on preferred terminology, and then just enough production functionality/code to fulfill that test. The goal of ATDD is to specify detailed, executable requirements for the solution be on a just in time (JIT) basis. ATDD is also called Behavior Driven Development (BDD).
;Developer TDD: With developer TDD a single developer test is written, sometimes inaccurately referred to as a unit test, and then just enough production code to fulfill that test. The goal of developer TDD is to specify a detailed, executable design for the solution be on a JIT basis. Developer TDD is often simply called TDD.
See more at: http://www.agiledata.org/essays/tdd.html#sthash.11uJfvXR.dpuf

;Testing using xUnit can be done as shown below:
[[File:tdd_xunit.jpg]]

== '''Test Driven Development using JUnit (Example)''' ==
Let's start simple and define a class Money to represent a value in a single currency. We represent the amount by a simple int. To get full accuracy you would probably use double or java.math.BigDecimal to store arbitrary-precision signed decimal numbers. We represent a currency as a string holding the ISO three letter abbreviation (USD, CHF, etc.). In more complex implementations, currency might deserve its own object.
<pre>
class Money {
private int fAmount;
private String fCurrency;
public Money(int amount, String currency) {
fAmount= amount;
fCurrency= currency;
}

public int amount() {
return fAmount;
}

public String currency() {
return fCurrency;
}
}
</pre>

JUnit defines how to structure your test cases and provides the tools to run them. You implement a test in a subclass of TestCase. To test our Money implementation we therefore define MoneyTest as a subclass of TestCase. In Java, classes are contained in packages and we have to decide where to put MoneyTest. Our current practice is to put MoneyTest in the same package as the classes under test. In this way a test case has access to the package private methods.

<pre>
public class MoneyTest extends TestCase {
//…
public void testSimpleAdd() {
Money m12CHF= new Money(12, "CHF"); // (1)
Money m14CHF= new Money(14, "CHF");
Money expected= new Money(26, "CHF");
Money result= m12CHF.add(m14CHF); // (2)
Assert.assertTrue(expected.equals(result)); // (3)
}
}
</pre>

Next let's write the equals method in Money:

<pre>
public boolean equals(Object anObject) {
if (anObject instanceof Money) {
Money aMoney= (Money)anObject;
return aMoney.currency().equals(currency())
&& amount() == aMoney.amount();
}
return false;
}
</pre>
Since equals can receive any kind of object as its argument we first have to check its type before we cast it as a Money. As an aside, it is a recommended practice to also override the method hashCode whenever you override method equals.

In the static way you override the runTest method inherited from TestCase and call the desired test case. A convenient way to do this is with an anonymous inner class. Note that each test must be given a name, so you can identify it if it fails.

<pre>
TestCase test= new MoneyTest("simple add") {
public void runTest() {
testSimpleAdd();
}
};
</pre>

== '''Characteristics of Good Tests'''==
For developers, the implication is that they need to learn how to write effective unit tests. Beck’s experience is that good unit tests:

<li>Run fast (they have short setups, run times, and break downs).
<li>Run in isolation (you should be able to reorder them).
<li>Use data that makes them easy to read and to understand.
<li>Use real data (e.g. copies of production data) when they need to.
<li>Represent one step towards your overall goal.

== '''Traditional Testing''' ==
TDD is primarily a specification technique with a side effect of ensuring that your source code is thoroughly tested at a confirmatory level. However, there is more to testing than this. Particularly at scale you'll still need to consider other agile testing techniques such as pre-production integration testing and investigative testing. Much of this testing can also be done early in your project if you choose to do so (and you should).
With traditional testing a successful test finds one or more defects. It is the same with TDD; when a test fails you have made progress because you now know that you need to resolve the problem. More importantly, you have a clear measure of success when the test no longer fails. TDD increases your confidence that your system actually meets the requirements defined for it, that your system actually works and therefore you can proceed with confidence.
As with traditional testing, the greater the risk profile of the system the more thorough your tests need to be. With both traditional testing and TDD you aren't striving for perfection, instead you are testing to the importance of the system. To paraphrase Agile Modeling (AM), you should "test with a purpose" and know why you are testing something and to what level it needs to be tested. An interesting side effect of TDD is that you achieve 100% coverage test – every single line of code is tested – something that traditional testing doesn’t guarantee (although it does recommend it). In general I think it’s fairly safe to say that although TDD is a specification technique, a valuable side effect is that it results in significantly better code testing than do traditional techniques.

== '''Documentation''' ==
Like it or not most programmers don’t read the written documentation for a system, instead they prefer to work with the code. And there’s nothing wrong with this. When trying to understand a class or operation most programmers will first look for sample code that already invokes it. Well-written unit tests do exactly this – the provide a working specification of your functional code – and as a result unit tests effectively become a significant portion of your technical documentation. The implication is that the expectations of the pro-documentation crowd need to reflect this reality. Similarly, acceptance tests can form an important part of your requirements documentation. This makes a lot of sense when you stop and think about it. Your acceptance tests define exactly what your stakeholders expect of your system, therefore they specify your critical requirements. Your regression test suite, particularly with a test-first approach, effectively becomes detailed executable specifications.

== '''Scaling TDD via Agile Model-Driven Development (AMDD)''' ==
TDD is very good at detailed specification and validation, but not so good at thinking through bigger issues such as the overall design, how people will use the system, or the UI design (for example). Modeling, or more to the point agile model-driven development (AMDD) (the lifecycle for which is captured in Figure 4) is better suited for this. AMDD addresses the agile scaling issues that TDD does not.

;Agile Model Driven Development (AMDD) Lifecycle
[[File:amdd.gif]]

=== TDD vs. AMDD ===

<li>TDD shortens the programming feedback loop whereas AMDD shortens the modeling feedback loop.
<li>TDD provides detailed specification (tests) whereas AMDD is better for thinking through bigger issues.
<li>TDD promotes the development of high-quality code whereas AMDD promotes high-quality communication with your stakeholders and other developers.
<li> TDD provides concrete evidence that your software works whereas AMDD supports your team, including stakeholders, in working toward a common understanding.
<li> TDD “speaks” to programmers whereas AMDD speaks to business analysts, stakeholders, and data professionals.
<li> TDD is provides very finely grained concrete feedback on the order of minutes whereas AMDD enables verbal feedback on the order minutes (concrete feedback requires developers to follow the practice Prove It With Code and thus becomes dependent on non-AM techniques).
<li> TDD helps to ensure that your design is clean by focusing on creation of operations that are callable and testable whereas AMDD provides an opportunity to think through larger design/architectural issues before you code.
<li> TDD is non-visually oriented whereas AMDD is visually oriented.
<li> Both techniques are new to traditional developers and therefore may be threatening to them.
<li> Both techniques support evolutionary development.

== Further Reading ==
* Test Driven Development by Exmaple http://www.eecs.yorku.ca/course_archive/2003-04/W/3311/sectionM/case_studies/money/KentBeck_TDD_byexample.pdf
* Test-Driven Database Development: Unlocking Agility (Net Objectives Lean-Agile Series) http://www.amazon.com/exec/obidos/ASIN/032178412X/ambysoftinc

== References ==

*[http://www.eecs.yorku.ca/course_archive/2003-04/W/3311/sectionM/case_studies/money/KentBeck_TDD_byexample.pdf]
*[http://en.wikipedia.org/wiki/Test-driven_development]
*[http://junit.sourceforge.net/doc/testinfected/testing.htm]
*[http://www.agiledata.org/essays/tdd.html]

CSC/ECE 517 Fall 2013/ch1 1w31 vm

2013-10-07T11:30:30Z

Mjoshi:

'''Test-driven development''' (TDD) is a software development process that relies on the repetition of a very short development cycle: first the developer writes an (initially failing) automated test case that defines a desired improvement or new function, then produces the minimum amount of code to pass that test, and finally refactors the new code to acceptable standards. Kent Beck, who is credited with having developed or 'rediscovered' the technique, stated in 2003 that TDD encourages simple designs and inspires confidence.
Test-driven development is related to the test-first programming concepts of extreme programming, begun in 1999, but more recently has created more general interest in its own right.
Programmers also apply the concept to improving and debugging legacy code developed with older techniques.

== '''Why to use TDD?'''==
A significant advantage of TDD is that it enables you to take small steps when writing software. This is a practice that I have promoted for years because it is far more productive than attempting to code in large steps. For example, assume you add some new functional code, compile, and test it. Chances are pretty good that your tests will be broken by defects that exist in the new code. It is much easier to find, and then fix, those defects if you've written two new lines of code than two thousand. The implication is that the faster your compiler and regression test suite, the more attractive it is to proceed in smaller and smaller steps.

== '''Rules of Thumb'''==
<li>Don’t write a line of new code unless you first have a failing automated test
<li>Eliminate duplication.

These rules generate complex individual and group behavior. Some of the technical implications are:

; Design with organization
TDD recommends that programmers should write their code such that it provides feedback between decisions. It should exhibit a control hierarchy which is easy to manage and understand.

; Write your own tests
This states that developers should write their own tests, since it is not advisable to wait for someone else to write a test every time. In a software environment, developers usually used to rely on testers to find bugs. However, this design says otherwise. It implies that developers know their code inside out and hence should write their own test cases.

; Rapid Response
Your development environment must provide rapid response to small changes. Business requirments are generally fickle and they can change at any point of time. Hence, it is receommended that developers write code such that it can adapt to changes made in future.

; High Cohesion
In computer programming, cohesion refers to the degree to which the elements of a module belong together. Thus, it is a measure of how strongly-related each piece of functionality expressed by the source code of a software module is. The design must consist of many highly cohesive, loosely coupled components, just to make testing easy.

== '''Steps performed in TDD'''==
[[File:tdd_flow.jpg|right]]
The following sequence is based on the book Test-Driven Development by Example.[http://www.eecs.yorku.ca/course_archive/2003-04/W/3311/sectionM/case_studies/money/KentBeck_TDD_byexample.pdf]
=== Quickly add a test ===
In test-driven development, each new feature begins with writing a test. This test must inevitably fail because it is written before the feature has been implemented. (If it does not fail, then either the proposed "new" feature already exists or the test is defective.) To write a test, the developer must clearly understand the feature's specification and requirements. The developer can accomplish this through use cases and user stories to cover the requirements and exception conditions, and can write the test in whatever testing framework is appropriate to the software environment. This could also be a modification of an existing test. This is a differentiating feature of test-driven development versus writing unit tests after the code is written: it makes the developer focus on the requirements before writing the code, a subtle but important difference.
=== Run all tests and see the new one fail ===
This validates that the test harness is working correctly and that the new test does not mistakenly pass without requiring any new code. This step also tests the test itself, in the negative: it rules out the possibility that the new test always passes, and therefore is worthless. The new test should also fail for the expected reason. This increases confidence (though does not guarantee) that it is testing the right thing, and passes only in intended cases.
=== Make a little change ===
The next step is to write some code that causes the test to pass. The new code written at this stage is not perfect, and may, for example, pass the test in an inelegant way. That is acceptable because later steps improve and hone it.
At this point, the only purpose of the written code is to pass the test; no further (and therefore untested) functionality should be predicted and 'allowed for' at any stage.
=== Run all tests and see them all succeed ===
If all test cases now pass, the programmer can be confident that the code meets all the tested requirements. This is a good point from which to begin the final step of the cycle.
=== Refactor to remove duplication ===
Now the code should be cleaned up as necessary. Move code from where it was convenient for passing the test to where it logically belongs. Remove any duplication you can find. Make sure that variable and method names represent their current use. Clarify any constructs that might be misinterpreted. Use Kent Beck's four rules of simple design[5][6] to guide you, as well as anything else you know about writing clean code. By re-running the test cases, the developer can be confident that code refactoring is not damaging any existing functionality.
The concept of removing duplication is an important aspect of any software design. In this case, however, it also applies to removing any duplication between the test code and the production code—for example magic numbers or strings repeated in both to make the test pass in step 3.

== '''Levels of Test Driven Development''' ==
There are two levels of TDD:
;Acceptance TDD (ATDD): With ATDD developers write a single acceptance test, or behavioral specification depending on preferred terminology, and then just enough production functionality/code to fulfill that test. The goal of ATDD is to specify detailed, executable requirements for the solution be on a just in time (JIT) basis. ATDD is also called Behavior Driven Development (BDD).
;Developer TDD: With developer TDD a single developer test is written, sometimes inaccurately referred to as a unit test, and then just enough production code to fulfill that test. The goal of developer TDD is to specify a detailed, executable design for the solution be on a JIT basis. Developer TDD is often simply called TDD.
See more at: http://www.agiledata.org/essays/tdd.html#sthash.11uJfvXR.dpuf

;Testing using xUnit can be done as shown below:
[[File:tdd_xunit.jpg]]

== '''Test Driven Development using JUnit (Example)''' ==
Let's start simple and define a class Money to represent a value in a single currency. We represent the amount by a simple int. To get full accuracy you would probably use double or java.math.BigDecimal to store arbitrary-precision signed decimal numbers. We represent a currency as a string holding the ISO three letter abbreviation (USD, CHF, etc.). In more complex implementations, currency might deserve its own object.
<pre>
class Money {
private int fAmount;
private String fCurrency;
public Money(int amount, String currency) {
fAmount= amount;
fCurrency= currency;
}

public int amount() {
return fAmount;
}

public String currency() {
return fCurrency;
}
}
</pre>

JUnit defines how to structure your test cases and provides the tools to run them. You implement a test in a subclass of TestCase. To test our Money implementation we therefore define MoneyTest as a subclass of TestCase. In Java, classes are contained in packages and we have to decide where to put MoneyTest. Our current practice is to put MoneyTest in the same package as the classes under test. In this way a test case has access to the package private methods.

<pre>
public class MoneyTest extends TestCase {
//…
public void testSimpleAdd() {
Money m12CHF= new Money(12, "CHF"); // (1)
Money m14CHF= new Money(14, "CHF");
Money expected= new Money(26, "CHF");
Money result= m12CHF.add(m14CHF); // (2)
Assert.assertTrue(expected.equals(result)); // (3)
}
}
</pre>

Next let's write the equals method in Money:

<pre>
public boolean equals(Object anObject) {
if (anObject instanceof Money) {
Money aMoney= (Money)anObject;
return aMoney.currency().equals(currency())
&& amount() == aMoney.amount();
}
return false;
}
</pre>
Since equals can receive any kind of object as its argument we first have to check its type before we cast it as a Money. As an aside, it is a recommended practice to also override the method hashCode whenever you override method equals.

In the static way you override the runTest method inherited from TestCase and call the desired test case. A convenient way to do this is with an anonymous inner class. Note that each test must be given a name, so you can identify it if it fails.

<pre>
TestCase test= new MoneyTest("simple add") {
public void runTest() {
testSimpleAdd();
}
};
</pre>

== '''Characteristics of Good Tests'''==
For developers, the implication is that they need to learn how to write effective unit tests. Beck’s experience is that good unit tests:

<li>Run fast (they have short setups, run times, and break downs).
<li>Run in isolation (you should be able to reorder them).
<li>Use data that makes them easy to read and to understand.
<li>Use real data (e.g. copies of production data) when they need to.
<li>Represent one step towards your overall goal.

== '''Traditional Testing''' ==
TDD is primarily a specification technique with a side effect of ensuring that your source code is thoroughly tested at a confirmatory level. However, there is more to testing than this. Particularly at scale you'll still need to consider other agile testing techniques such as pre-production integration testing and investigative testing. Much of this testing can also be done early in your project if you choose to do so (and you should).
With traditional testing a successful test finds one or more defects. It is the same with TDD; when a test fails you have made progress because you now know that you need to resolve the problem. More importantly, you have a clear measure of success when the test no longer fails. TDD increases your confidence that your system actually meets the requirements defined for it, that your system actually works and therefore you can proceed with confidence.
As with traditional testing, the greater the risk profile of the system the more thorough your tests need to be. With both traditional testing and TDD you aren't striving for perfection, instead you are testing to the importance of the system. To paraphrase Agile Modeling (AM), you should "test with a purpose" and know why you are testing something and to what level it needs to be tested. An interesting side effect of TDD is that you achieve 100% coverage test – every single line of code is tested – something that traditional testing doesn’t guarantee (although it does recommend it). In general I think it’s fairly safe to say that although TDD is a specification technique, a valuable side effect is that it results in significantly better code testing than do traditional techniques.

== '''Documentation''' ==
Like it or not most programmers don’t read the written documentation for a system, instead they prefer to work with the code. And there’s nothing wrong with this. When trying to understand a class or operation most programmers will first look for sample code that already invokes it. Well-written unit tests do exactly this – the provide a working specification of your functional code – and as a result unit tests effectively become a significant portion of your technical documentation. The implication is that the expectations of the pro-documentation crowd need to reflect this reality. Similarly, acceptance tests can form an important part of your requirements documentation. This makes a lot of sense when you stop and think about it. Your acceptance tests define exactly what your stakeholders expect of your system, therefore they specify your critical requirements. Your regression test suite, particularly with a test-first approach, effectively becomes detailed executable specifications.

== '''Scaling TDD via Agile Model-Driven Development (AMDD)''' ==
TDD is very good at detailed specification and validation, but not so good at thinking through bigger issues such as the overall design, how people will use the system, or the UI design (for example). Modeling, or more to the point agile model-driven development (AMDD) (the lifecycle for which is captured in Figure 4) is better suited for this. AMDD addresses the agile scaling issues that TDD does not.

;Agile Model Driven Development (AMDD) Lifecycle
[[File:amdd.gif]]

=== TDD vs. AMDD ===

<li>TDD shortens the programming feedback loop whereas AMDD shortens the modeling feedback loop.
<li>TDD provides detailed specification (tests) whereas AMDD is better for thinking through bigger issues.
<li>TDD promotes the development of high-quality code whereas AMDD promotes high-quality communication with your stakeholders and other developers.
<li> TDD provides concrete evidence that your software works whereas AMDD supports your team, including stakeholders, in working toward a common understanding.
<li> TDD “speaks” to programmers whereas AMDD speaks to business analysts, stakeholders, and data professionals.
<li> TDD is provides very finely grained concrete feedback on the order of minutes whereas AMDD enables verbal feedback on the order minutes (concrete feedback requires developers to follow the practice Prove It With Code and thus becomes dependent on non-AM techniques).
<li> TDD helps to ensure that your design is clean by focusing on creation of operations that are callable and testable whereas AMDD provides an opportunity to think through larger design/architectural issues before you code.
<li> TDD is non-visually oriented whereas AMDD is visually oriented.
<li> Both techniques are new to traditional developers and therefore may be threatening to them.
<li> Both techniques support evolutionary development.

CSC/ECE 517 Fall 2013/ch1 1w31 vm

2013-10-07T11:22:18Z

Mjoshi: /* Documentation */

'''Test-driven development''' (TDD) is a software development process that relies on the repetition of a very short development cycle: first the developer writes an (initially failing) automated test case that defines a desired improvement or new function, then produces the minimum amount of code to pass that test, and finally refactors the new code to acceptable standards. Kent Beck, who is credited with having developed or 'rediscovered' the technique, stated in 2003 that TDD encourages simple designs and inspires confidence.
Test-driven development is related to the test-first programming concepts of extreme programming, begun in 1999, but more recently has created more general interest in its own right.
Programmers also apply the concept to improving and debugging legacy code developed with older techniques.

== '''Why to use TDD?'''==
A significant advantage of TDD is that it enables you to take small steps when writing software. This is a practice that I have promoted for years because it is far more productive than attempting to code in large steps. For example, assume you add some new functional code, compile, and test it. Chances are pretty good that your tests will be broken by defects that exist in the new code. It is much easier to find, and then fix, those defects if you've written two new lines of code than two thousand. The implication is that the faster your compiler and regression test suite, the more attractive it is to proceed in smaller and smaller steps.

== '''Rules of Thumb'''==
<li>Don’t write a line of new code unless you first have a failing automated test
<li>Eliminate duplication.

These rules generate complex individual and group behavior. Some of the technical implications are:

; Design with organization
TDD recommends that programmers should write their code such that it provides feedback between decisions. It should exhibit a control hierarchy which is easy to manage and understand.

; Write your own tests
This states that developers should write their own tests, since it is not advisable to wait for someone else to write a test every time. In a software environment, developers usually used to rely on testers to find bugs. However, this design says otherwise. It implies that developers know their code inside out and hence should write their own test cases.

; Rapid Response
Your development environment must provide rapid response to small changes. Business requirments are generally fickle and they can change at any point of time. Hence, it is receommended that developers write code such that it can adapt to changes made in future.

; High Cohesion
In computer programming, cohesion refers to the degree to which the elements of a module belong together. Thus, it is a measure of how strongly-related each piece of functionality expressed by the source code of a software module is. The design must consist of many highly cohesive, loosely coupled components, just to make testing easy.

== '''Steps performed in TDD'''==
[[File:tdd_flow.jpg|right]]
The following sequence is based on the book Test-Driven Development by Example.[http://www.eecs.yorku.ca/course_archive/2003-04/W/3311/sectionM/case_studies/money/KentBeck_TDD_byexample.pdf]
=== Quickly add a test ===
In test-driven development, each new feature begins with writing a test. This test must inevitably fail because it is written before the feature has been implemented. (If it does not fail, then either the proposed "new" feature already exists or the test is defective.) To write a test, the developer must clearly understand the feature's specification and requirements. The developer can accomplish this through use cases and user stories to cover the requirements and exception conditions, and can write the test in whatever testing framework is appropriate to the software environment. This could also be a modification of an existing test. This is a differentiating feature of test-driven development versus writing unit tests after the code is written: it makes the developer focus on the requirements before writing the code, a subtle but important difference.
=== Run all tests and see the new one fail ===
This validates that the test harness is working correctly and that the new test does not mistakenly pass without requiring any new code. This step also tests the test itself, in the negative: it rules out the possibility that the new test always passes, and therefore is worthless. The new test should also fail for the expected reason. This increases confidence (though does not guarantee) that it is testing the right thing, and passes only in intended cases.
=== Make a little change ===
The next step is to write some code that causes the test to pass. The new code written at this stage is not perfect, and may, for example, pass the test in an inelegant way. That is acceptable because later steps improve and hone it.
At this point, the only purpose of the written code is to pass the test; no further (and therefore untested) functionality should be predicted and 'allowed for' at any stage.
=== Run all tests and see them all succeed ===
If all test cases now pass, the programmer can be confident that the code meets all the tested requirements. This is a good point from which to begin the final step of the cycle.
=== Refactor to remove duplication ===
Now the code should be cleaned up as necessary. Move code from where it was convenient for passing the test to where it logically belongs. Remove any duplication you can find. Make sure that variable and method names represent their current use. Clarify any constructs that might be misinterpreted. Use Kent Beck's four rules of simple design[5][6] to guide you, as well as anything else you know about writing clean code. By re-running the test cases, the developer can be confident that code refactoring is not damaging any existing functionality.
The concept of removing duplication is an important aspect of any software design. In this case, however, it also applies to removing any duplication between the test code and the production code—for example magic numbers or strings repeated in both to make the test pass in step 3.

== '''Levels of Test Driven Development''' ==
There are two levels of TDD:
;Acceptance TDD (ATDD): With ATDD developers write a single acceptance test, or behavioral specification depending on preferred terminology, and then just enough production functionality/code to fulfill that test. The goal of ATDD is to specify detailed, executable requirements for the solution be on a just in time (JIT) basis. ATDD is also called Behavior Driven Development (BDD).
;Developer TDD: With developer TDD a single developer test is written, sometimes inaccurately referred to as a unit test, and then just enough production code to fulfill that test. The goal of developer TDD is to specify a detailed, executable design for the solution be on a JIT basis. Developer TDD is often simply called TDD.
See more at: http://www.agiledata.org/essays/tdd.html#sthash.11uJfvXR.dpuf

;Testing using xUnit can be done as shown below:
[[File:tdd_xunit.jpg]]

== '''Characteristics of Good Tests'''==
For developers, the implication is that they need to learn how to write effective unit tests. Beck’s experience is that good unit tests:

<li>Run fast (they have short setups, run times, and break downs).
<li>Run in isolation (you should be able to reorder them).
<li>Use data that makes them easy to read and to understand.
<li>Use real data (e.g. copies of production data) when they need to.
<li>Represent one step towards your overall goal.

== '''Traditional Testing''' ==
TDD is primarily a specification technique with a side effect of ensuring that your source code is thoroughly tested at a confirmatory level. However, there is more to testing than this. Particularly at scale you'll still need to consider other agile testing techniques such as pre-production integration testing and investigative testing. Much of this testing can also be done early in your project if you choose to do so (and you should).
With traditional testing a successful test finds one or more defects. It is the same with TDD; when a test fails you have made progress because you now know that you need to resolve the problem. More importantly, you have a clear measure of success when the test no longer fails. TDD increases your confidence that your system actually meets the requirements defined for it, that your system actually works and therefore you can proceed with confidence.
As with traditional testing, the greater the risk profile of the system the more thorough your tests need to be. With both traditional testing and TDD you aren't striving for perfection, instead you are testing to the importance of the system. To paraphrase Agile Modeling (AM), you should "test with a purpose" and know why you are testing something and to what level it needs to be tested. An interesting side effect of TDD is that you achieve 100% coverage test – every single line of code is tested – something that traditional testing doesn’t guarantee (although it does recommend it). In general I think it’s fairly safe to say that although TDD is a specification technique, a valuable side effect is that it results in significantly better code testing than do traditional techniques.

== '''Documentation''' ==
Like it or not most programmers don’t read the written documentation for a system, instead they prefer to work with the code. And there’s nothing wrong with this. When trying to understand a class or operation most programmers will first look for sample code that already invokes it. Well-written unit tests do exactly this – the provide a working specification of your functional code – and as a result unit tests effectively become a significant portion of your technical documentation. The implication is that the expectations of the pro-documentation crowd need to reflect this reality. Similarly, acceptance tests can form an important part of your requirements documentation. This makes a lot of sense when you stop and think about it. Your acceptance tests define exactly what your stakeholders expect of your system, therefore they specify your critical requirements. Your regression test suite, particularly with a test-first approach, effectively becomes detailed executable specifications.

== '''Scaling TDD via Agile Model-Driven Development (AMDD)''' ==
TDD is very good at detailed specification and validation, but not so good at thinking through bigger issues such as the overall design, how people will use the system, or the UI design (for example). Modeling, or more to the point agile model-driven development (AMDD) (the lifecycle for which is captured in Figure 4) is better suited for this. AMDD addresses the agile scaling issues that TDD does not.

;Agile Model Driven Development (AMDD) Lifecycle
[[File:amdd.gif]]

=== TDD vs. AMDD ===

<li>TDD shortens the programming feedback loop whereas AMDD shortens the modeling feedback loop.
<li>TDD provides detailed specification (tests) whereas AMDD is better for thinking through bigger issues.
<li>TDD promotes the development of high-quality code whereas AMDD promotes high-quality communication with your stakeholders and other developers.
<li> TDD provides concrete evidence that your software works whereas AMDD supports your team, including stakeholders, in working toward a common understanding.
<li> TDD “speaks” to programmers whereas AMDD speaks to business analysts, stakeholders, and data professionals.
<li> TDD is provides very finely grained concrete feedback on the order of minutes whereas AMDD enables verbal feedback on the order minutes (concrete feedback requires developers to follow the practice Prove It With Code and thus becomes dependent on non-AM techniques).
<li> TDD helps to ensure that your design is clean by focusing on creation of operations that are callable and testable whereas AMDD provides an opportunity to think through larger design/architectural issues before you code.
<li> TDD is non-visually oriented whereas AMDD is visually oriented.
<li> Both techniques are new to traditional developers and therefore may be threatening to them.
<li> Both techniques support evolutionary development.

CSC/ECE 517 Fall 2013/ch1 1w31 vm

2013-10-07T11:22:07Z

Mjoshi: /* Traditional Testing */

'''Test-driven development''' (TDD) is a software development process that relies on the repetition of a very short development cycle: first the developer writes an (initially failing) automated test case that defines a desired improvement or new function, then produces the minimum amount of code to pass that test, and finally refactors the new code to acceptable standards. Kent Beck, who is credited with having developed or 'rediscovered' the technique, stated in 2003 that TDD encourages simple designs and inspires confidence.
Test-driven development is related to the test-first programming concepts of extreme programming, begun in 1999, but more recently has created more general interest in its own right.
Programmers also apply the concept to improving and debugging legacy code developed with older techniques.

== '''Why to use TDD?'''==
A significant advantage of TDD is that it enables you to take small steps when writing software. This is a practice that I have promoted for years because it is far more productive than attempting to code in large steps. For example, assume you add some new functional code, compile, and test it. Chances are pretty good that your tests will be broken by defects that exist in the new code. It is much easier to find, and then fix, those defects if you've written two new lines of code than two thousand. The implication is that the faster your compiler and regression test suite, the more attractive it is to proceed in smaller and smaller steps.

== '''Rules of Thumb'''==
<li>Don’t write a line of new code unless you first have a failing automated test
<li>Eliminate duplication.

These rules generate complex individual and group behavior. Some of the technical implications are:

; Design with organization
TDD recommends that programmers should write their code such that it provides feedback between decisions. It should exhibit a control hierarchy which is easy to manage and understand.

; Write your own tests
This states that developers should write their own tests, since it is not advisable to wait for someone else to write a test every time. In a software environment, developers usually used to rely on testers to find bugs. However, this design says otherwise. It implies that developers know their code inside out and hence should write their own test cases.

; Rapid Response
Your development environment must provide rapid response to small changes. Business requirments are generally fickle and they can change at any point of time. Hence, it is receommended that developers write code such that it can adapt to changes made in future.

; High Cohesion
In computer programming, cohesion refers to the degree to which the elements of a module belong together. Thus, it is a measure of how strongly-related each piece of functionality expressed by the source code of a software module is. The design must consist of many highly cohesive, loosely coupled components, just to make testing easy.

== '''Steps performed in TDD'''==
[[File:tdd_flow.jpg|right]]
The following sequence is based on the book Test-Driven Development by Example.[http://www.eecs.yorku.ca/course_archive/2003-04/W/3311/sectionM/case_studies/money/KentBeck_TDD_byexample.pdf]
=== Quickly add a test ===
In test-driven development, each new feature begins with writing a test. This test must inevitably fail because it is written before the feature has been implemented. (If it does not fail, then either the proposed "new" feature already exists or the test is defective.) To write a test, the developer must clearly understand the feature's specification and requirements. The developer can accomplish this through use cases and user stories to cover the requirements and exception conditions, and can write the test in whatever testing framework is appropriate to the software environment. This could also be a modification of an existing test. This is a differentiating feature of test-driven development versus writing unit tests after the code is written: it makes the developer focus on the requirements before writing the code, a subtle but important difference.
=== Run all tests and see the new one fail ===
This validates that the test harness is working correctly and that the new test does not mistakenly pass without requiring any new code. This step also tests the test itself, in the negative: it rules out the possibility that the new test always passes, and therefore is worthless. The new test should also fail for the expected reason. This increases confidence (though does not guarantee) that it is testing the right thing, and passes only in intended cases.
=== Make a little change ===
The next step is to write some code that causes the test to pass. The new code written at this stage is not perfect, and may, for example, pass the test in an inelegant way. That is acceptable because later steps improve and hone it.
At this point, the only purpose of the written code is to pass the test; no further (and therefore untested) functionality should be predicted and 'allowed for' at any stage.
=== Run all tests and see them all succeed ===
If all test cases now pass, the programmer can be confident that the code meets all the tested requirements. This is a good point from which to begin the final step of the cycle.
=== Refactor to remove duplication ===
Now the code should be cleaned up as necessary. Move code from where it was convenient for passing the test to where it logically belongs. Remove any duplication you can find. Make sure that variable and method names represent their current use. Clarify any constructs that might be misinterpreted. Use Kent Beck's four rules of simple design[5][6] to guide you, as well as anything else you know about writing clean code. By re-running the test cases, the developer can be confident that code refactoring is not damaging any existing functionality.
The concept of removing duplication is an important aspect of any software design. In this case, however, it also applies to removing any duplication between the test code and the production code—for example magic numbers or strings repeated in both to make the test pass in step 3.

== '''Levels of Test Driven Development''' ==
There are two levels of TDD:
;Acceptance TDD (ATDD): With ATDD developers write a single acceptance test, or behavioral specification depending on preferred terminology, and then just enough production functionality/code to fulfill that test. The goal of ATDD is to specify detailed, executable requirements for the solution be on a just in time (JIT) basis. ATDD is also called Behavior Driven Development (BDD).
;Developer TDD: With developer TDD a single developer test is written, sometimes inaccurately referred to as a unit test, and then just enough production code to fulfill that test. The goal of developer TDD is to specify a detailed, executable design for the solution be on a JIT basis. Developer TDD is often simply called TDD.
See more at: http://www.agiledata.org/essays/tdd.html#sthash.11uJfvXR.dpuf

;Testing using xUnit can be done as shown below:
[[File:tdd_xunit.jpg]]

== '''Characteristics of Good Tests'''==
For developers, the implication is that they need to learn how to write effective unit tests. Beck’s experience is that good unit tests:

<li>Run fast (they have short setups, run times, and break downs).
<li>Run in isolation (you should be able to reorder them).
<li>Use data that makes them easy to read and to understand.
<li>Use real data (e.g. copies of production data) when they need to.
<li>Represent one step towards your overall goal.

== '''Traditional Testing''' ==
TDD is primarily a specification technique with a side effect of ensuring that your source code is thoroughly tested at a confirmatory level. However, there is more to testing than this. Particularly at scale you'll still need to consider other agile testing techniques such as pre-production integration testing and investigative testing. Much of this testing can also be done early in your project if you choose to do so (and you should).
With traditional testing a successful test finds one or more defects. It is the same with TDD; when a test fails you have made progress because you now know that you need to resolve the problem. More importantly, you have a clear measure of success when the test no longer fails. TDD increases your confidence that your system actually meets the requirements defined for it, that your system actually works and therefore you can proceed with confidence.
As with traditional testing, the greater the risk profile of the system the more thorough your tests need to be. With both traditional testing and TDD you aren't striving for perfection, instead you are testing to the importance of the system. To paraphrase Agile Modeling (AM), you should "test with a purpose" and know why you are testing something and to what level it needs to be tested. An interesting side effect of TDD is that you achieve 100% coverage test – every single line of code is tested – something that traditional testing doesn’t guarantee (although it does recommend it). In general I think it’s fairly safe to say that although TDD is a specification technique, a valuable side effect is that it results in significantly better code testing than do traditional techniques.

== '''Documentation''' ==
Like it or not most programmers don’t read the written documentation for a system, instead they prefer to work with the code. And there’s nothing wrong with this. When trying to understand a class or operation most programmers will first look for sample code that already invokes it. Well-written unit tests do exactly this – the provide a working specification of your functional code – and as a result unit tests effectively become a significant portion of your technical documentation. The implication is that the expectations of the pro-documentation crowd need to reflect this reality. Similarly, acceptance tests can form an important part of your requirements documentation. This makes a lot of sense when you stop and think about it. Your acceptance tests define exactly what your stakeholders expect of your system, therefore they specify your critical requirements. Your regression test suite, particularly with a test-first approach, effectively becomes detailed executable specifications.
- See more at: http://www.agiledata.org/essays/tdd.html#sthash.11uJfvXR.dpuf

== '''Scaling TDD via Agile Model-Driven Development (AMDD)''' ==
TDD is very good at detailed specification and validation, but not so good at thinking through bigger issues such as the overall design, how people will use the system, or the UI design (for example). Modeling, or more to the point agile model-driven development (AMDD) (the lifecycle for which is captured in Figure 4) is better suited for this. AMDD addresses the agile scaling issues that TDD does not.

;Agile Model Driven Development (AMDD) Lifecycle
[[File:amdd.gif]]

=== TDD vs. AMDD ===

<li>TDD shortens the programming feedback loop whereas AMDD shortens the modeling feedback loop.
<li>TDD provides detailed specification (tests) whereas AMDD is better for thinking through bigger issues.
<li>TDD promotes the development of high-quality code whereas AMDD promotes high-quality communication with your stakeholders and other developers.
<li> TDD provides concrete evidence that your software works whereas AMDD supports your team, including stakeholders, in working toward a common understanding.
<li> TDD “speaks” to programmers whereas AMDD speaks to business analysts, stakeholders, and data professionals.
<li> TDD is provides very finely grained concrete feedback on the order of minutes whereas AMDD enables verbal feedback on the order minutes (concrete feedback requires developers to follow the practice Prove It With Code and thus becomes dependent on non-AM techniques).
<li> TDD helps to ensure that your design is clean by focusing on creation of operations that are callable and testable whereas AMDD provides an opportunity to think through larger design/architectural issues before you code.
<li> TDD is non-visually oriented whereas AMDD is visually oriented.
<li> Both techniques are new to traditional developers and therefore may be threatening to them.
<li> Both techniques support evolutionary development.

CSC/ECE 517 Fall 2013/ch1 1w31 vm

2013-10-07T11:21:37Z

Mjoshi:

'''Test-driven development''' (TDD) is a software development process that relies on the repetition of a very short development cycle: first the developer writes an (initially failing) automated test case that defines a desired improvement or new function, then produces the minimum amount of code to pass that test, and finally refactors the new code to acceptable standards. Kent Beck, who is credited with having developed or 'rediscovered' the technique, stated in 2003 that TDD encourages simple designs and inspires confidence.
Test-driven development is related to the test-first programming concepts of extreme programming, begun in 1999, but more recently has created more general interest in its own right.
Programmers also apply the concept to improving and debugging legacy code developed with older techniques.

== '''Why to use TDD?'''==
A significant advantage of TDD is that it enables you to take small steps when writing software. This is a practice that I have promoted for years because it is far more productive than attempting to code in large steps. For example, assume you add some new functional code, compile, and test it. Chances are pretty good that your tests will be broken by defects that exist in the new code. It is much easier to find, and then fix, those defects if you've written two new lines of code than two thousand. The implication is that the faster your compiler and regression test suite, the more attractive it is to proceed in smaller and smaller steps.

== '''Rules of Thumb'''==
<li>Don’t write a line of new code unless you first have a failing automated test
<li>Eliminate duplication.

These rules generate complex individual and group behavior. Some of the technical implications are:

; Design with organization
TDD recommends that programmers should write their code such that it provides feedback between decisions. It should exhibit a control hierarchy which is easy to manage and understand.

; Write your own tests
This states that developers should write their own tests, since it is not advisable to wait for someone else to write a test every time. In a software environment, developers usually used to rely on testers to find bugs. However, this design says otherwise. It implies that developers know their code inside out and hence should write their own test cases.

; Rapid Response
Your development environment must provide rapid response to small changes. Business requirments are generally fickle and they can change at any point of time. Hence, it is receommended that developers write code such that it can adapt to changes made in future.

; High Cohesion
In computer programming, cohesion refers to the degree to which the elements of a module belong together. Thus, it is a measure of how strongly-related each piece of functionality expressed by the source code of a software module is. The design must consist of many highly cohesive, loosely coupled components, just to make testing easy.

== '''Steps performed in TDD'''==
[[File:tdd_flow.jpg|right]]
The following sequence is based on the book Test-Driven Development by Example.[http://www.eecs.yorku.ca/course_archive/2003-04/W/3311/sectionM/case_studies/money/KentBeck_TDD_byexample.pdf]
=== Quickly add a test ===
In test-driven development, each new feature begins with writing a test. This test must inevitably fail because it is written before the feature has been implemented. (If it does not fail, then either the proposed "new" feature already exists or the test is defective.) To write a test, the developer must clearly understand the feature's specification and requirements. The developer can accomplish this through use cases and user stories to cover the requirements and exception conditions, and can write the test in whatever testing framework is appropriate to the software environment. This could also be a modification of an existing test. This is a differentiating feature of test-driven development versus writing unit tests after the code is written: it makes the developer focus on the requirements before writing the code, a subtle but important difference.
=== Run all tests and see the new one fail ===
This validates that the test harness is working correctly and that the new test does not mistakenly pass without requiring any new code. This step also tests the test itself, in the negative: it rules out the possibility that the new test always passes, and therefore is worthless. The new test should also fail for the expected reason. This increases confidence (though does not guarantee) that it is testing the right thing, and passes only in intended cases.
=== Make a little change ===
The next step is to write some code that causes the test to pass. The new code written at this stage is not perfect, and may, for example, pass the test in an inelegant way. That is acceptable because later steps improve and hone it.
At this point, the only purpose of the written code is to pass the test; no further (and therefore untested) functionality should be predicted and 'allowed for' at any stage.
=== Run all tests and see them all succeed ===
If all test cases now pass, the programmer can be confident that the code meets all the tested requirements. This is a good point from which to begin the final step of the cycle.
=== Refactor to remove duplication ===
Now the code should be cleaned up as necessary. Move code from where it was convenient for passing the test to where it logically belongs. Remove any duplication you can find. Make sure that variable and method names represent their current use. Clarify any constructs that might be misinterpreted. Use Kent Beck's four rules of simple design[5][6] to guide you, as well as anything else you know about writing clean code. By re-running the test cases, the developer can be confident that code refactoring is not damaging any existing functionality.
The concept of removing duplication is an important aspect of any software design. In this case, however, it also applies to removing any duplication between the test code and the production code—for example magic numbers or strings repeated in both to make the test pass in step 3.

== '''Levels of Test Driven Development''' ==
There are two levels of TDD:
;Acceptance TDD (ATDD): With ATDD developers write a single acceptance test, or behavioral specification depending on preferred terminology, and then just enough production functionality/code to fulfill that test. The goal of ATDD is to specify detailed, executable requirements for the solution be on a just in time (JIT) basis. ATDD is also called Behavior Driven Development (BDD).
;Developer TDD: With developer TDD a single developer test is written, sometimes inaccurately referred to as a unit test, and then just enough production code to fulfill that test. The goal of developer TDD is to specify a detailed, executable design for the solution be on a JIT basis. Developer TDD is often simply called TDD.
See more at: http://www.agiledata.org/essays/tdd.html#sthash.11uJfvXR.dpuf

;Testing using xUnit can be done as shown below:
[[File:tdd_xunit.jpg]]

== '''Characteristics of Good Tests'''==
For developers, the implication is that they need to learn how to write effective unit tests. Beck’s experience is that good unit tests:

<li>Run fast (they have short setups, run times, and break downs).
<li>Run in isolation (you should be able to reorder them).
<li>Use data that makes them easy to read and to understand.
<li>Use real data (e.g. copies of production data) when they need to.
<li>Represent one step towards your overall goal.

== '''Traditional Testing''' ==
TDD is primarily a specification technique with a side effect of ensuring that your source code is thoroughly tested at a confirmatory level. However, there is more to testing than this. Particularly at scale you'll still need to consider other agile testing techniques such as pre-production integration testing and investigative testing. Much of this testing can also be done early in your project if you choose to do so (and you should).
With traditional testing a successful test finds one or more defects. It is the same with TDD; when a test fails you have made progress because you now know that you need to resolve the problem. More importantly, you have a clear measure of success when the test no longer fails. TDD increases your confidence that your system actually meets the requirements defined for it, that your system actually works and therefore you can proceed with confidence.
As with traditional testing, the greater the risk profile of the system the more thorough your tests need to be. With both traditional testing and TDD you aren't striving for perfection, instead you are testing to the importance of the system. To paraphrase Agile Modeling (AM), you should "test with a purpose" and know why you are testing something and to what level it needs to be tested. An interesting side effect of TDD is that you achieve 100% coverage test – every single line of code is tested – something that traditional testing doesn’t guarantee (although it does recommend it). In general I think it’s fairly safe to say that although TDD is a specification technique, a valuable side effect is that it results in significantly better code testing than do traditional techniques.

- See more at: http://www.agiledata.org/essays/tdd.html#sthash.11uJfvXR.dpuf

== '''Documentation''' ==
Like it or not most programmers don’t read the written documentation for a system, instead they prefer to work with the code. And there’s nothing wrong with this. When trying to understand a class or operation most programmers will first look for sample code that already invokes it. Well-written unit tests do exactly this – the provide a working specification of your functional code – and as a result unit tests effectively become a significant portion of your technical documentation. The implication is that the expectations of the pro-documentation crowd need to reflect this reality. Similarly, acceptance tests can form an important part of your requirements documentation. This makes a lot of sense when you stop and think about it. Your acceptance tests define exactly what your stakeholders expect of your system, therefore they specify your critical requirements. Your regression test suite, particularly with a test-first approach, effectively becomes detailed executable specifications.
- See more at: http://www.agiledata.org/essays/tdd.html#sthash.11uJfvXR.dpuf

== '''Scaling TDD via Agile Model-Driven Development (AMDD)''' ==
TDD is very good at detailed specification and validation, but not so good at thinking through bigger issues such as the overall design, how people will use the system, or the UI design (for example). Modeling, or more to the point agile model-driven development (AMDD) (the lifecycle for which is captured in Figure 4) is better suited for this. AMDD addresses the agile scaling issues that TDD does not.

;Agile Model Driven Development (AMDD) Lifecycle
[[File:amdd.gif]]

=== TDD vs. AMDD ===

<li>TDD shortens the programming feedback loop whereas AMDD shortens the modeling feedback loop.
<li>TDD provides detailed specification (tests) whereas AMDD is better for thinking through bigger issues.
<li>TDD promotes the development of high-quality code whereas AMDD promotes high-quality communication with your stakeholders and other developers.
<li> TDD provides concrete evidence that your software works whereas AMDD supports your team, including stakeholders, in working toward a common understanding.
<li> TDD “speaks” to programmers whereas AMDD speaks to business analysts, stakeholders, and data professionals.
<li> TDD is provides very finely grained concrete feedback on the order of minutes whereas AMDD enables verbal feedback on the order minutes (concrete feedback requires developers to follow the practice Prove It With Code and thus becomes dependent on non-AM techniques).
<li> TDD helps to ensure that your design is clean by focusing on creation of operations that are callable and testable whereas AMDD provides an opportunity to think through larger design/architectural issues before you code.
<li> TDD is non-visually oriented whereas AMDD is visually oriented.
<li> Both techniques are new to traditional developers and therefore may be threatening to them.
<li> Both techniques support evolutionary development.

CSC/ECE 517 Fall 2013/ch1 1w31 vm

2013-10-07T11:20:39Z

Mjoshi:

== '''Test Driven Development (Under Construction)''' ==
'''Test-driven development''' (TDD) is a software development process that relies on the repetition of a very short development cycle: first the developer writes an (initially failing) automated test case that defines a desired improvement or new function, then produces the minimum amount of code to pass that test, and finally refactors the new code to acceptable standards. Kent Beck, who is credited with having developed or 'rediscovered' the technique, stated in 2003 that TDD encourages simple designs and inspires confidence.
Test-driven development is related to the test-first programming concepts of extreme programming, begun in 1999, but more recently has created more general interest in its own right.
Programmers also apply the concept to improving and debugging legacy code developed with older techniques.

== '''Why to use TDD?'''==
A significant advantage of TDD is that it enables you to take small steps when writing software. This is a practice that I have promoted for years because it is far more productive than attempting to code in large steps. For example, assume you add some new functional code, compile, and test it. Chances are pretty good that your tests will be broken by defects that exist in the new code. It is much easier to find, and then fix, those defects if you've written two new lines of code than two thousand. The implication is that the faster your compiler and regression test suite, the more attractive it is to proceed in smaller and smaller steps.

== '''Rules of Thumb'''==
<li>Don’t write a line of new code unless you first have a failing automated test
<li>Eliminate duplication.

These rules generate complex individual and group behavior. Some of the technical implications are:

; Design with organization
TDD recommends that programmers should write their code such that it provides feedback between decisions. It should exhibit a control hierarchy which is easy to manage and understand.

; Write your own tests
This states that developers should write their own tests, since it is not advisable to wait for someone else to write a test every time. In a software environment, developers usually used to rely on testers to find bugs. However, this design says otherwise. It implies that developers know their code inside out and hence should write their own test cases.

; Rapid Response
Your development environment must provide rapid response to small changes. Business requirments are generally fickle and they can change at any point of time. Hence, it is receommended that developers write code such that it can adapt to changes made in future.

; High Cohesion
In computer programming, cohesion refers to the degree to which the elements of a module belong together. Thus, it is a measure of how strongly-related each piece of functionality expressed by the source code of a software module is. The design must consist of many highly cohesive, loosely coupled components, just to make testing easy.

== '''Steps performed in TDD'''==
[[File:tdd_flow.jpg|right]]
The following sequence is based on the book Test-Driven Development by Example.[http://www.eecs.yorku.ca/course_archive/2003-04/W/3311/sectionM/case_studies/money/KentBeck_TDD_byexample.pdf]
=== Quickly add a test ===
In test-driven development, each new feature begins with writing a test. This test must inevitably fail because it is written before the feature has been implemented. (If it does not fail, then either the proposed "new" feature already exists or the test is defective.) To write a test, the developer must clearly understand the feature's specification and requirements. The developer can accomplish this through use cases and user stories to cover the requirements and exception conditions, and can write the test in whatever testing framework is appropriate to the software environment. This could also be a modification of an existing test. This is a differentiating feature of test-driven development versus writing unit tests after the code is written: it makes the developer focus on the requirements before writing the code, a subtle but important difference.
=== Run all tests and see the new one fail ===
This validates that the test harness is working correctly and that the new test does not mistakenly pass without requiring any new code. This step also tests the test itself, in the negative: it rules out the possibility that the new test always passes, and therefore is worthless. The new test should also fail for the expected reason. This increases confidence (though does not guarantee) that it is testing the right thing, and passes only in intended cases.
=== Make a little change ===
The next step is to write some code that causes the test to pass. The new code written at this stage is not perfect, and may, for example, pass the test in an inelegant way. That is acceptable because later steps improve and hone it.
At this point, the only purpose of the written code is to pass the test; no further (and therefore untested) functionality should be predicted and 'allowed for' at any stage.
=== Run all tests and see them all succeed ===
If all test cases now pass, the programmer can be confident that the code meets all the tested requirements. This is a good point from which to begin the final step of the cycle.
=== Refactor to remove duplication ===
Now the code should be cleaned up as necessary. Move code from where it was convenient for passing the test to where it logically belongs. Remove any duplication you can find. Make sure that variable and method names represent their current use. Clarify any constructs that might be misinterpreted. Use Kent Beck's four rules of simple design[5][6] to guide you, as well as anything else you know about writing clean code. By re-running the test cases, the developer can be confident that code refactoring is not damaging any existing functionality.
The concept of removing duplication is an important aspect of any software design. In this case, however, it also applies to removing any duplication between the test code and the production code—for example magic numbers or strings repeated in both to make the test pass in step 3.

== '''Levels of Test Driven Development''' ==
There are two levels of TDD:
;Acceptance TDD (ATDD): With ATDD developers write a single acceptance test, or behavioral specification depending on preferred terminology, and then just enough production functionality/code to fulfill that test. The goal of ATDD is to specify detailed, executable requirements for the solution be on a just in time (JIT) basis. ATDD is also called Behavior Driven Development (BDD).
;Developer TDD: With developer TDD a single developer test is written, sometimes inaccurately referred to as a unit test, and then just enough production code to fulfill that test. The goal of developer TDD is to specify a detailed, executable design for the solution be on a JIT basis. Developer TDD is often simply called TDD.
See more at: http://www.agiledata.org/essays/tdd.html#sthash.11uJfvXR.dpuf

;Testing using xUnit can be done as shown below:
[[File:tdd_xunit.jpg]]

== '''Characteristics of Good Tests'''==
For developers, the implication is that they need to learn how to write effective unit tests. Beck’s experience is that good unit tests:

<li>Run fast (they have short setups, run times, and break downs).
<li>Run in isolation (you should be able to reorder them).
<li>Use data that makes them easy to read and to understand.
<li>Use real data (e.g. copies of production data) when they need to.
<li>Represent one step towards your overall goal.

== '''Traditional Testing''' ==
TDD is primarily a specification technique with a side effect of ensuring that your source code is thoroughly tested at a confirmatory level. However, there is more to testing than this. Particularly at scale you'll still need to consider other agile testing techniques such as pre-production integration testing and investigative testing. Much of this testing can also be done early in your project if you choose to do so (and you should).
With traditional testing a successful test finds one or more defects. It is the same with TDD; when a test fails you have made progress because you now know that you need to resolve the problem. More importantly, you have a clear measure of success when the test no longer fails. TDD increases your confidence that your system actually meets the requirements defined for it, that your system actually works and therefore you can proceed with confidence.
As with traditional testing, the greater the risk profile of the system the more thorough your tests need to be. With both traditional testing and TDD you aren't striving for perfection, instead you are testing to the importance of the system. To paraphrase Agile Modeling (AM), you should "test with a purpose" and know why you are testing something and to what level it needs to be tested. An interesting side effect of TDD is that you achieve 100% coverage test – every single line of code is tested – something that traditional testing doesn’t guarantee (although it does recommend it). In general I think it’s fairly safe to say that although TDD is a specification technique, a valuable side effect is that it results in significantly better code testing than do traditional techniques.

- See more at: http://www.agiledata.org/essays/tdd.html#sthash.11uJfvXR.dpuf

== '''Documentation''' ==
Like it or not most programmers don’t read the written documentation for a system, instead they prefer to work with the code. And there’s nothing wrong with this. When trying to understand a class or operation most programmers will first look for sample code that already invokes it. Well-written unit tests do exactly this – the provide a working specification of your functional code – and as a result unit tests effectively become a significant portion of your technical documentation. The implication is that the expectations of the pro-documentation crowd need to reflect this reality. Similarly, acceptance tests can form an important part of your requirements documentation. This makes a lot of sense when you stop and think about it. Your acceptance tests define exactly what your stakeholders expect of your system, therefore they specify your critical requirements. Your regression test suite, particularly with a test-first approach, effectively becomes detailed executable specifications.
- See more at: http://www.agiledata.org/essays/tdd.html#sthash.11uJfvXR.dpuf

== '''Scaling TDD via Agile Model-Driven Development (AMDD)''' ==
TDD is very good at detailed specification and validation, but not so good at thinking through bigger issues such as the overall design, how people will use the system, or the UI design (for example). Modeling, or more to the point agile model-driven development (AMDD) (the lifecycle for which is captured in Figure 4) is better suited for this. AMDD addresses the agile scaling issues that TDD does not.

;Agile Model Driven Development (AMDD) Lifecycle
[[File:amdd.gif]]

=== TDD vs. AMDD ===

<li>TDD shortens the programming feedback loop whereas AMDD shortens the modeling feedback loop.
<li>TDD provides detailed specification (tests) whereas AMDD is better for thinking through bigger issues.
<li>TDD promotes the development of high-quality code whereas AMDD promotes high-quality communication with your stakeholders and other developers.
<li> TDD provides concrete evidence that your software works whereas AMDD supports your team, including stakeholders, in working toward a common understanding.
<li> TDD “speaks” to programmers whereas AMDD speaks to business analysts, stakeholders, and data professionals.
<li> TDD is provides very finely grained concrete feedback on the order of minutes whereas AMDD enables verbal feedback on the order minutes (concrete feedback requires developers to follow the practice Prove It With Code and thus becomes dependent on non-AM techniques).
<li> TDD helps to ensure that your design is clean by focusing on creation of operations that are callable and testable whereas AMDD provides an opportunity to think through larger design/architectural issues before you code.
<li> TDD is non-visually oriented whereas AMDD is visually oriented.
<li> Both techniques are new to traditional developers and therefore may be threatening to them.
<li> Both techniques support evolutionary development.

CSC/ECE 517 Fall 2013/ch1 1w31 vm

2013-10-07T11:19:10Z

Mjoshi:

== '''Test Driven Development (Under Construction)''' ==
'''Test-driven development''' (TDD) is a software development process that relies on the repetition of a very short development cycle: first the developer writes an (initially failing) automated test case that defines a desired improvement or new function, then produces the minimum amount of code to pass that test, and finally refactors the new code to acceptable standards. Kent Beck, who is credited with having developed or 'rediscovered' the technique, stated in 2003 that TDD encourages simple designs and inspires confidence.
Test-driven development is related to the test-first programming concepts of extreme programming, begun in 1999, but more recently has created more general interest in its own right.
Programmers also apply the concept to improving and debugging legacy code developed with older techniques.

== '''Rules of Thumb'''==
<li>Don’t write a line of new code unless you first have a failing automated test
<li>Eliminate duplication.

These rules generate complex individual and group behavior. Some of the technical implications are:

; Design with organization
TDD recommends that programmers should write their code such that it provides feedback between decisions. It should exhibit a control hierarchy which is easy to manage and understand.

; Write your own tests
This states that developers should write their own tests, since it is not advisable to wait for someone else to write a test every time. In a software environment, developers usually used to rely on testers to find bugs. However, this design says otherwise. It implies that developers know their code inside out and hence should write their own test cases.

; Rapid Response
Your development environment must provide rapid response to small changes. Business requirments are generally fickle and they can change at any point of time. Hence, it is receommended that developers write code such that it can adapt to changes made in future.

; High Cohesion
In computer programming, cohesion refers to the degree to which the elements of a module belong together. Thus, it is a measure of how strongly-related each piece of functionality expressed by the source code of a software module is. The design must consist of many highly cohesive, loosely coupled components, just to make testing easy.

== '''Steps performed in TDD'''==
[[File:tdd_flow.jpg|right]]
The following sequence is based on the book Test-Driven Development by Example.[http://www.eecs.yorku.ca/course_archive/2003-04/W/3311/sectionM/case_studies/money/KentBeck_TDD_byexample.pdf]
=== Quickly add a test ===
In test-driven development, each new feature begins with writing a test. This test must inevitably fail because it is written before the feature has been implemented. (If it does not fail, then either the proposed "new" feature already exists or the test is defective.) To write a test, the developer must clearly understand the feature's specification and requirements. The developer can accomplish this through use cases and user stories to cover the requirements and exception conditions, and can write the test in whatever testing framework is appropriate to the software environment. This could also be a modification of an existing test. This is a differentiating feature of test-driven development versus writing unit tests after the code is written: it makes the developer focus on the requirements before writing the code, a subtle but important difference.
=== Run all tests and see the new one fail ===
This validates that the test harness is working correctly and that the new test does not mistakenly pass without requiring any new code. This step also tests the test itself, in the negative: it rules out the possibility that the new test always passes, and therefore is worthless. The new test should also fail for the expected reason. This increases confidence (though does not guarantee) that it is testing the right thing, and passes only in intended cases.
=== Make a little change ===
The next step is to write some code that causes the test to pass. The new code written at this stage is not perfect, and may, for example, pass the test in an inelegant way. That is acceptable because later steps improve and hone it.
At this point, the only purpose of the written code is to pass the test; no further (and therefore untested) functionality should be predicted and 'allowed for' at any stage.
=== Run all tests and see them all succeed ===
If all test cases now pass, the programmer can be confident that the code meets all the tested requirements. This is a good point from which to begin the final step of the cycle.
=== Refactor to remove duplication ===
Now the code should be cleaned up as necessary. Move code from where it was convenient for passing the test to where it logically belongs. Remove any duplication you can find. Make sure that variable and method names represent their current use. Clarify any constructs that might be misinterpreted. Use Kent Beck's four rules of simple design[5][6] to guide you, as well as anything else you know about writing clean code. By re-running the test cases, the developer can be confident that code refactoring is not damaging any existing functionality.
The concept of removing duplication is an important aspect of any software design. In this case, however, it also applies to removing any duplication between the test code and the production code—for example magic numbers or strings repeated in both to make the test pass in step 3.

== '''Levels of Test Driven Development''' ==
There are two levels of TDD:
;Acceptance TDD (ATDD): With ATDD developers write a single acceptance test, or behavioral specification depending on preferred terminology, and then just enough production functionality/code to fulfill that test. The goal of ATDD is to specify detailed, executable requirements for the solution be on a just in time (JIT) basis. ATDD is also called Behavior Driven Development (BDD).
;Developer TDD: With developer TDD a single developer test is written, sometimes inaccurately referred to as a unit test, and then just enough production code to fulfill that test. The goal of developer TDD is to specify a detailed, executable design for the solution be on a JIT basis. Developer TDD is often simply called TDD.
See more at: http://www.agiledata.org/essays/tdd.html#sthash.11uJfvXR.dpuf

;Testing using xUnit can be done as shown below:
[[File:tdd_xunit.jpg]]

== '''Characteristics of Good Tests'''==
For developers, the implication is that they need to learn how to write effective unit tests. Beck’s experience is that good unit tests:

<li>Run fast (they have short setups, run times, and break downs).
<li>Run in isolation (you should be able to reorder them).
<li>Use data that makes them easy to read and to understand.
<li>Use real data (e.g. copies of production data) when they need to.
<li>Represent one step towards your overall goal.

== '''Traditional Testing''' ==
TDD is primarily a specification technique with a side effect of ensuring that your source code is thoroughly tested at a confirmatory level. However, there is more to testing than this. Particularly at scale you'll still need to consider other agile testing techniques such as pre-production integration testing and investigative testing. Much of this testing can also be done early in your project if you choose to do so (and you should).
With traditional testing a successful test finds one or more defects. It is the same with TDD; when a test fails you have made progress because you now know that you need to resolve the problem. More importantly, you have a clear measure of success when the test no longer fails. TDD increases your confidence that your system actually meets the requirements defined for it, that your system actually works and therefore you can proceed with confidence.
As with traditional testing, the greater the risk profile of the system the more thorough your tests need to be. With both traditional testing and TDD you aren't striving for perfection, instead you are testing to the importance of the system. To paraphrase Agile Modeling (AM), you should "test with a purpose" and know why you are testing something and to what level it needs to be tested. An interesting side effect of TDD is that you achieve 100% coverage test – every single line of code is tested – something that traditional testing doesn’t guarantee (although it does recommend it). In general I think it’s fairly safe to say that although TDD is a specification technique, a valuable side effect is that it results in significantly better code testing than do traditional techniques.

- See more at: http://www.agiledata.org/essays/tdd.html#sthash.11uJfvXR.dpuf

== '''Documentation''' ==
Like it or not most programmers don’t read the written documentation for a system, instead they prefer to work with the code. And there’s nothing wrong with this. When trying to understand a class or operation most programmers will first look for sample code that already invokes it. Well-written unit tests do exactly this – the provide a working specification of your functional code – and as a result unit tests effectively become a significant portion of your technical documentation. The implication is that the expectations of the pro-documentation crowd need to reflect this reality. Similarly, acceptance tests can form an important part of your requirements documentation. This makes a lot of sense when you stop and think about it. Your acceptance tests define exactly what your stakeholders expect of your system, therefore they specify your critical requirements. Your regression test suite, particularly with a test-first approach, effectively becomes detailed executable specifications.
- See more at: http://www.agiledata.org/essays/tdd.html#sthash.11uJfvXR.dpuf

== '''Scaling TDD via Agile Model-Driven Development (AMDD)''' ==
TDD is very good at detailed specification and validation, but not so good at thinking through bigger issues such as the overall design, how people will use the system, or the UI design (for example). Modeling, or more to the point agile model-driven development (AMDD) (the lifecycle for which is captured in Figure 4) is better suited for this. AMDD addresses the agile scaling issues that TDD does not.

;Agile Model Driven Development (AMDD) Lifecycle
[[File:amdd.gif]]

=== TDD vs. AMDD ===

<li>TDD shortens the programming feedback loop whereas AMDD shortens the modeling feedback loop.
<li>TDD provides detailed specification (tests) whereas AMDD is better for thinking through bigger issues.
<li>TDD promotes the development of high-quality code whereas AMDD promotes high-quality communication with your stakeholders and other developers.
<li> TDD provides concrete evidence that your software works whereas AMDD supports your team, including stakeholders, in working toward a common understanding.
<li> TDD “speaks” to programmers whereas AMDD speaks to business analysts, stakeholders, and data professionals.
<li> TDD is provides very finely grained concrete feedback on the order of minutes whereas AMDD enables verbal feedback on the order minutes (concrete feedback requires developers to follow the practice Prove It With Code and thus becomes dependent on non-AM techniques).
<li> TDD helps to ensure that your design is clean by focusing on creation of operations that are callable and testable whereas AMDD provides an opportunity to think through larger design/architectural issues before you code.
<li> TDD is non-visually oriented whereas AMDD is visually oriented.
<li> Both techniques are new to traditional developers and therefore may be threatening to them.
<li> Both techniques support evolutionary development.

CSC/ECE 517 Fall 2013/ch1 1w31 vm

2013-10-07T11:17:30Z

Mjoshi:

== '''Test Driven Development (Under Construction)''' ==
'''Test-driven development''' (TDD) is a software development process that relies on the repetition of a very short development cycle: first the developer writes an (initially failing) automated test case that defines a desired improvement or new function, then produces the minimum amount of code to pass that test, and finally refactors the new code to acceptable standards. Kent Beck, who is credited with having developed or 'rediscovered' the technique, stated in 2003 that TDD encourages simple designs and inspires confidence.
Test-driven development is related to the test-first programming concepts of extreme programming, begun in 1999, but more recently has created more general interest in its own right.
Programmers also apply the concept to improving and debugging legacy code developed with older techniques.

== '''Rules of Thumb'''==
<li>Don’t write a line of new code unless you first have a failing automated test
<li>Eliminate duplication.

These rules generate complex individual and group behavior. Some of the technical implications are:

; Design with organization
TDD recommends that programmers should write their code such that it provides feedback between decisions. It should exhibit a control hierarchy which is easy to manage and understand.

; Write your own tests
This states that developers should write their own tests, since it is not advisable to wait for someone else to write a test every time. In a software environment, developers usually used to rely on testers to find bugs. However, this design says otherwise. It implies that developers know their code inside out and hence should write their own test cases.

; Rapid Response
Your development environment must provide rapid response to small changes. Business requirments are generally fickle and they can change at any point of time. Hence, it is receommended that developers write code such that it can adapt to changes made in future.

; High Cohesion
In computer programming, cohesion refers to the degree to which the elements of a module belong together. Thus, it is a measure of how strongly-related each piece of functionality expressed by the source code of a software module is. The design must consist of many highly cohesive, loosely coupled components, just to make testing easy.

== '''Steps performed in TDD'''==
[[File:tdd_flow.jpg|right]]
The following sequence is based on the book Test-Driven Development by Example.[http://www.eecs.yorku.ca/course_archive/2003-04/W/3311/sectionM/case_studies/money/KentBeck_TDD_byexample.pdf]
=== Quickly add a test ===
In test-driven development, each new feature begins with writing a test. This test must inevitably fail because it is written before the feature has been implemented. (If it does not fail, then either the proposed "new" feature already exists or the test is defective.) To write a test, the developer must clearly understand the feature's specification and requirements. The developer can accomplish this through use cases and user stories to cover the requirements and exception conditions, and can write the test in whatever testing framework is appropriate to the software environment. This could also be a modification of an existing test. This is a differentiating feature of test-driven development versus writing unit tests after the code is written: it makes the developer focus on the requirements before writing the code, a subtle but important difference.
=== Run all tests and see the new one fail ===
This validates that the test harness is working correctly and that the new test does not mistakenly pass without requiring any new code. This step also tests the test itself, in the negative: it rules out the possibility that the new test always passes, and therefore is worthless. The new test should also fail for the expected reason. This increases confidence (though does not guarantee) that it is testing the right thing, and passes only in intended cases.
=== Make a little change ===
The next step is to write some code that causes the test to pass. The new code written at this stage is not perfect, and may, for example, pass the test in an inelegant way. That is acceptable because later steps improve and hone it.
At this point, the only purpose of the written code is to pass the test; no further (and therefore untested) functionality should be predicted and 'allowed for' at any stage.
=== Run all tests and see them all succeed ===
If all test cases now pass, the programmer can be confident that the code meets all the tested requirements. This is a good point from which to begin the final step of the cycle.
=== Refactor to remove duplication ===
Now the code should be cleaned up as necessary. Move code from where it was convenient for passing the test to where it logically belongs. Remove any duplication you can find. Make sure that variable and method names represent their current use. Clarify any constructs that might be misinterpreted. Use Kent Beck's four rules of simple design[5][6] to guide you, as well as anything else you know about writing clean code. By re-running the test cases, the developer can be confident that code refactoring is not damaging any existing functionality.
The concept of removing duplication is an important aspect of any software design. In this case, however, it also applies to removing any duplication between the test code and the production code—for example magic numbers or strings repeated in both to make the test pass in step 3.

== '''Levels of Test Driven Development''' ==
There are two levels of TDD:
;Acceptance TDD (ATDD): With ATDD developers write a single acceptance test, or behavioral specification depending on preferred terminology, and then just enough production functionality/code to fulfill that test. The goal of ATDD is to specify detailed, executable requirements for the solution be on a just in time (JIT) basis. ATDD is also called Behavior Driven Development (BDD).
;Developer TDD: With developer TDD a single developer test is written, sometimes inaccurately referred to as a unit test, and then just enough production code to fulfill that test. The goal of developer TDD is to specify a detailed, executable design for the solution be on a JIT basis. Developer TDD is often simply called TDD.
See more at: http://www.agiledata.org/essays/tdd.html#sthash.11uJfvXR.dpuf

;Testing using xUnit can be done as shown below:
[[File:tdd_xunit.jpg]]

== '''Characteristics of Good Tests'''==
For developers, the implication is that they need to learn how to write effective unit tests. Beck’s experience is that good unit tests:

<li>Run fast (they have short setups, run times, and break downs).
<li>Run in isolation (you should be able to reorder them).
<li>Use data that makes them easy to read and to understand.
<li>Use real data (e.g. copies of production data) when they need to.
<li>Represent one step towards your overall goal.

== '''Traditional Testing''' ==
TDD is primarily a specification technique with a side effect of ensuring that your source code is thoroughly tested at a confirmatory level. However, there is more to testing than this. Particularly at scale you'll still need to consider other agile testing techniques such as pre-production integration testing and investigative testing. Much of this testing can also be done early in your project if you choose to do so (and you should).
With traditional testing a successful test finds one or more defects. It is the same with TDD; when a test fails you have made progress because you now know that you need to resolve the problem. More importantly, you have a clear measure of success when the test no longer fails. TDD increases your confidence that your system actually meets the requirements defined for it, that your system actually works and therefore you can proceed with confidence.
As with traditional testing, the greater the risk profile of the system the more thorough your tests need to be. With both traditional testing and TDD you aren't striving for perfection, instead you are testing to the importance of the system. To paraphrase Agile Modeling (AM), you should "test with a purpose" and know why you are testing something and to what level it needs to be tested. An interesting side effect of TDD is that you achieve 100% coverage test – every single line of code is tested – something that traditional testing doesn’t guarantee (although it does recommend it). In general I think it’s fairly safe to say that although TDD is a specification technique, a valuable side effect is that it results in significantly better code testing than do traditional techniques.

- See more at: http://www.agiledata.org/essays/tdd.html#sthash.11uJfvXR.dpuf

== '''Documentation''' ==
Like it or not most programmers don’t read the written documentation for a system, instead they prefer to work with the code. And there’s nothing wrong with this. When trying to understand a class or operation most programmers will first look for sample code that already invokes it. Well-written unit tests do exactly this – the provide a working specification of your functional code – and as a result unit tests effectively become a significant portion of your technical documentation. The implication is that the expectations of the pro-documentation crowd need to reflect this reality. Similarly, acceptance tests can form an important part of your requirements documentation. This makes a lot of sense when you stop and think about it. Your acceptance tests define exactly what your stakeholders expect of your system, therefore they specify your critical requirements. Your regression test suite, particularly with a test-first approach, effectively becomes detailed executable specifications.
- See more at: http://www.agiledata.org/essays/tdd.html#sthash.11uJfvXR.dpuf

== '''Scaling TDD via Agile Model-Driven Development (AMDD)''' ==
TDD is very good at detailed specification and validation, but not so good at thinking through bigger issues such as the overall design, how people will use the system, or the UI design (for example). Modeling, or more to the point agile model-driven development (AMDD) (the lifecycle for which is captured in Figure 4) is better suited for this. AMDD addresses the agile scaling issues that TDD does not.

;Agile Model Driven Development (AMDD) Lifecycle
[[File:amdd.gif]]

File:Amdd.gif

2013-10-07T11:16:47Z

Mjoshi:

CSC/ECE 517 Fall 2013/ch1 1w31 vm

2013-10-07T11:16:33Z

Mjoshi:

== '''Test Driven Development (Under Construction)''' ==
'''Test-driven development''' (TDD) is a software development process that relies on the repetition of a very short development cycle: first the developer writes an (initially failing) automated test case that defines a desired improvement or new function, then produces the minimum amount of code to pass that test, and finally refactors the new code to acceptable standards. Kent Beck, who is credited with having developed or 'rediscovered' the technique, stated in 2003 that TDD encourages simple designs and inspires confidence.
Test-driven development is related to the test-first programming concepts of extreme programming, begun in 1999, but more recently has created more general interest in its own right.
Programmers also apply the concept to improving and debugging legacy code developed with older techniques.

== '''Rules of Thumb'''==
<li>Don’t write a line of new code unless you first have a failing automated test
<li>Eliminate duplication.

These rules generate complex individual and group behavior. Some of the technical implications are:

; Design with organization
TDD recommends that programmers should write their code such that it provides feedback between decisions. It should exhibit a control hierarchy which is easy to manage and understand.

; Write your own tests
This states that developers should write their own tests, since it is not advisable to wait for someone else to write a test every time. In a software environment, developers usually used to rely on testers to find bugs. However, this design says otherwise. It implies that developers know their code inside out and hence should write their own test cases.

; Rapid Response
Your development environment must provide rapid response to small changes. Business requirments are generally fickle and they can change at any point of time. Hence, it is receommended that developers write code such that it can adapt to changes made in future.

; High Cohesion
In computer programming, cohesion refers to the degree to which the elements of a module belong together. Thus, it is a measure of how strongly-related each piece of functionality expressed by the source code of a software module is. The design must consist of many highly cohesive, loosely coupled components, just to make testing easy.

== '''Steps performed in TDD'''==
[[File:tdd_flow.jpg|right]]
The following sequence is based on the book Test-Driven Development by Example.[http://www.eecs.yorku.ca/course_archive/2003-04/W/3311/sectionM/case_studies/money/KentBeck_TDD_byexample.pdf]
=== Quickly add a test ===
In test-driven development, each new feature begins with writing a test. This test must inevitably fail because it is written before the feature has been implemented. (If it does not fail, then either the proposed "new" feature already exists or the test is defective.) To write a test, the developer must clearly understand the feature's specification and requirements. The developer can accomplish this through use cases and user stories to cover the requirements and exception conditions, and can write the test in whatever testing framework is appropriate to the software environment. This could also be a modification of an existing test. This is a differentiating feature of test-driven development versus writing unit tests after the code is written: it makes the developer focus on the requirements before writing the code, a subtle but important difference.
=== Run all tests and see the new one fail ===
This validates that the test harness is working correctly and that the new test does not mistakenly pass without requiring any new code. This step also tests the test itself, in the negative: it rules out the possibility that the new test always passes, and therefore is worthless. The new test should also fail for the expected reason. This increases confidence (though does not guarantee) that it is testing the right thing, and passes only in intended cases.
=== Make a little change ===
The next step is to write some code that causes the test to pass. The new code written at this stage is not perfect, and may, for example, pass the test in an inelegant way. That is acceptable because later steps improve and hone it.
At this point, the only purpose of the written code is to pass the test; no further (and therefore untested) functionality should be predicted and 'allowed for' at any stage.
=== Run all tests and see them all succeed ===
If all test cases now pass, the programmer can be confident that the code meets all the tested requirements. This is a good point from which to begin the final step of the cycle.
=== Refactor to remove duplication ===
Now the code should be cleaned up as necessary. Move code from where it was convenient for passing the test to where it logically belongs. Remove any duplication you can find. Make sure that variable and method names represent their current use. Clarify any constructs that might be misinterpreted. Use Kent Beck's four rules of simple design[5][6] to guide you, as well as anything else you know about writing clean code. By re-running the test cases, the developer can be confident that code refactoring is not damaging any existing functionality.
The concept of removing duplication is an important aspect of any software design. In this case, however, it also applies to removing any duplication between the test code and the production code—for example magic numbers or strings repeated in both to make the test pass in step 3.

== '''Levels of Test Driven Development''' ==
There are two levels of TDD:
;Acceptance TDD (ATDD): With ATDD developers write a single acceptance test, or behavioral specification depending on preferred terminology, and then just enough production functionality/code to fulfill that test. The goal of ATDD is to specify detailed, executable requirements for the solution be on a just in time (JIT) basis. ATDD is also called Behavior Driven Development (BDD).
;Developer TDD: With developer TDD a single developer test is written, sometimes inaccurately referred to as a unit test, and then just enough production code to fulfill that test. The goal of developer TDD is to specify a detailed, executable design for the solution be on a JIT basis. Developer TDD is often simply called TDD.
See more at: http://www.agiledata.org/essays/tdd.html#sthash.11uJfvXR.dpuf

;Testing using xUnit can be done as shown below:
[[File:tdd_xunit.jpg]]

== '''Characteristics of Good Tests'''==
For developers, the implication is that they need to learn how to write effective unit tests. Beck’s experience is that good unit tests:

<li>Run fast (they have short setups, run times, and break downs).
<li>Run in isolation (you should be able to reorder them).
<li>Use data that makes them easy to read and to understand.
<li>Use real data (e.g. copies of production data) when they need to.
<li>Represent one step towards your overall goal.

== '''Traditional Testing''' ==
TDD is primarily a specification technique with a side effect of ensuring that your source code is thoroughly tested at a confirmatory level. However, there is more to testing than this. Particularly at scale you'll still need to consider other agile testing techniques such as pre-production integration testing and investigative testing. Much of this testing can also be done early in your project if you choose to do so (and you should).
With traditional testing a successful test finds one or more defects. It is the same with TDD; when a test fails you have made progress because you now know that you need to resolve the problem. More importantly, you have a clear measure of success when the test no longer fails. TDD increases your confidence that your system actually meets the requirements defined for it, that your system actually works and therefore you can proceed with confidence.
As with traditional testing, the greater the risk profile of the system the more thorough your tests need to be. With both traditional testing and TDD you aren't striving for perfection, instead you are testing to the importance of the system. To paraphrase Agile Modeling (AM), you should "test with a purpose" and know why you are testing something and to what level it needs to be tested. An interesting side effect of TDD is that you achieve 100% coverage test – every single line of code is tested – something that traditional testing doesn’t guarantee (although it does recommend it). In general I think it’s fairly safe to say that although TDD is a specification technique, a valuable side effect is that it results in significantly better code testing than do traditional techniques.

- See more at: http://www.agiledata.org/essays/tdd.html#sthash.11uJfvXR.dpuf

== '''Documentation''' ==
Like it or not most programmers don’t read the written documentation for a system, instead they prefer to work with the code. And there’s nothing wrong with this. When trying to understand a class or operation most programmers will first look for sample code that already invokes it. Well-written unit tests do exactly this – the provide a working specification of your functional code – and as a result unit tests effectively become a significant portion of your technical documentation. The implication is that the expectations of the pro-documentation crowd need to reflect this reality. Similarly, acceptance tests can form an important part of your requirements documentation. This makes a lot of sense when you stop and think about it. Your acceptance tests define exactly what your stakeholders expect of your system, therefore they specify your critical requirements. Your regression test suite, particularly with a test-first approach, effectively becomes detailed executable specifications.
- See more at: http://www.agiledata.org/essays/tdd.html#sthash.11uJfvXR.dpuf

== '''Scaling TDD via Agile Model-Driven Development (AMDD)''' ==
TDD is very good at detailed specification and validation, but not so good at thinking through bigger issues such as the overall design, how people will use the system, or the UI design (for example). Modeling, or more to the point agile model-driven development (AMDD) (the lifecycle for which is captured in Figure 4) is better suited for this. AMDD addresses the agile scaling issues that TDD does not.

CSC/ECE 517 Fall 2013/ch1 1w31 vm

2013-10-07T11:12:44Z

Mjoshi: /* Levels of Test Driven Development */

File:Tdd xunit.jpg

2013-10-07T11:11:50Z

Mjoshi:

CSC/ECE 517 Fall 2013/ch1 1w31 vm

2013-10-07T11:10:53Z

Mjoshi: /* Levels of Test Driven Development */

File:Atdd dtdd.jpg

2013-10-07T11:10:29Z

Mjoshi: uploaded a new version of "File:Atdd dtdd.jpg"

CSC/ECE 517 Fall 2013/ch1 1w31 vm

2013-10-07T11:08:54Z

Mjoshi: /* Levels of Test Driven Development */

File:Atdd dtdd.jpg

2013-10-07T11:05:14Z

Mjoshi:

CSC/ECE 517 Fall 2013/ch1 1w31 vm

2013-10-07T11:03:14Z

Mjoshi:

CSC/ECE 517 Fall 2013/ch1 1w31 vm

2013-10-07T10:59:32Z

Mjoshi: /* Steps performed in TDD */

CSC/ECE 517 Fall 2013/ch1 1w31 vm

2013-10-07T10:59:02Z

Mjoshi:

File:Tdd flow.jpg

2013-10-07T10:56:09Z

Mjoshi: Test Driven Development Flow

Test Driven Development Flow