https://wiki.expertiza.ncsu.edu/api.php?action=feedcontributions&feedformat=atom&user=Agoel2 2026-07-17T22:35:21Z User contributions MediaWiki 1.41.0 https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/oss_paa&diff=80473 2013-10-30T01:59:37Z

<p>Agoel2: </p> <hr /> <div>'''Expertiza OSS Project –E809 (TreeDisplay)'''<br /> <br /> __TOC__<br /> == Introduction ==<br /> The [http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza] project has a collapsible tree view structure to facilitate traversal through all learning objects. The problem statement is to redesign the underlying structure and include efficient search, filter and sort mechanism in the tree view structure. The tree is composed of different folders namely Assignments, Courses, Questionnaires and their subfolders respectively.<br /> <br /> ==Existing Design==<br /> Currently the folders structure is displayed as a tree. The structure of the tree is as follows -<br /> <br /> : • Questionnaire<br /> <br /> :: o Review<br /> <br /> :: o Metareview<br /> <br /> :: o Author Feedback<br /> <br /> :: o Teammate Review<br /> <br /> :: o Survey<br /> <br /> :: o Global Survey<br /> <br /> :: o Course Evaluation<br /> <br /> : • Courses<br /> <br /> :: o Course<br /> <br /> :::  assignment<br /> <br /> : • Assignments<br /> <br /> <br /> The whole set of Courses, Assignments and Questionnaires are displayed on screen in a collapsible tree view upon login. Items may be expanded and collapsed. There is no functionality to search/filter results.<br /> The sort functionality has been provided which sorts the tree structure with important metrics such as creation date, name and directory in ascending as well as descending order. <br /> We also have the option to view either the public and private items or the private items only.<br /> <br /> '''[[File:ExistingUI.jpg]]'''<br /> <br /> Fig.1 Existing UI which implements display of nodes and a sort utility<br /> <br /> ==Project Requirement==<br /> The tree display can be inefficient given many objects (courses, etc.). We are supposed to design the underlying structure at the model level to efficiently retrieve organized data. <br /> <br /> We are also required to redesign the view to enable users to filter/search and sort by important metrics such as creation date, name (alphabetical) and relationship (e.g. filter all assignments by a course). <br /> <br /> The interface should be kept modular in the code to increase extensibility for future metrics. We have to keep the controller as ‘skinny’ as possible, leaving the model to perform computational logic.<br /> <br /> <br /> ==Implementation==<br /> We have introduced two new features - search and filter.<br /> To implement the search/filter, we have decided to use the same tree display which is efficient and simple to show the current data.<br /> <br /> '''[[File:newUI.jpg]]'''<br /> <br /> Fig.2 Above is the new UI which includes search and filter functionality<br /> <br /> ===Search===<br /> This functionality searches for a keyword among 3 categories courses/assignment/questionnaire. It is implemented using substring search. All the entries whose substring matches with the search string are returned. Based on the input the user can view the filtered results in any of the 3 categories.<br /> <br /> '''[[File:sample1.jpg]]'''<br /> <br /> Fig.3 A sample output of searching “demo” in assignments.<br /> <br /> ===Filter===<br /> There are 2 main relationships in the tree structure. These are as follows -<br /> <br /> : 1. A course can have many assignments.<br /> <br /> : 2. An assignment can have many questionnaires.<br /> <br /> The user selects one of the two fields and enters the course/assignment name. Then he will see a list of all the elements which are related to that course/assignment.<br /> <br /> '''[[File:sample2.jpg]]'''<br /> <br /> Fig.4 Sample output which shows the result of filtering assignments by course “CourseTest1” <br /> <br /> ===Compatibility with existing features===<br /> We have implemented these 2 filters in the code. A user can search all assignments for a respective course, and also search for all questionnaires related to one assignment. We preserve the sort feature across the implementation which means that the user can sort the filtered results also. The user can also view the public and private items or the private items only for the filtered result.<br /> <br /> '''[[File:sample3.jpg]]'''<br /> <br /> Fig.5 Sample output which shows the same result of searching “demo” in assignments but sorted in descending order.<br /> <br /> ==Design==<br /> ===View===<br /> Since the tree display is the best way to show the folder structure and to maximize code reuse, we choose the same display style for search results. We add search and filter boxes to input the search/filter keyword on the main page and output the result on the same page. We also add the reset button to return to the primary key structure.<br /> All the above changes are done in -<br /> ''' \view \tree_display\_page_header.html.erb '''<br /> <br /> ===Controller===<br /> We modify the existing list function in the tree_display_controller.rb as it is responsible for all the inputs on the tree display page. We also add a new function filter in the file which parses the input string given by the user and converts it into a meaningful string depending on what user wants to filter. Filter is called by list function and the string is placed into a global variable, so that future sort can make use of the previous search.<br /> '''tree_display_controller.rb '''<br /> <br /> ===Model===<br /> We have made changes to the following models to search/filter for the keyword in corresponding nodes.-<br /> <br /> '''questionnaire_node.rb '''<br /> '''assignment_node.rb '''<br /> '''course_node.rb '''<br /> '''node.rb '''<br /> '''folder_node.rb '''<br /> <br /> All the models have the same logic to parse the input search string and accordingly find the nodes in the model objects. The design is extensible and controller is left skinny which just does the parsing of input string and calls a generic model function. The summary is given below<br /> <br /> The view takes the string and passes to controller<br /> <br /> '''User -&gt; input string -&gt; Controller. '''<br /> <br /> <br /> Controller does the parsing and calls a generic function which iterates over folders.<br /> <br /> '''Controller -&gt; search string -&gt; Models(Iterator) '''<br /> '''Iterator -&gt; Controller -&gt; View(display) '''<br /> <br /> <br /> Model returns the required nodes and controller handles them to view. The code which has been put in all model objects is generic. The same code can be used with future nodes or new folders when they are added in future.<br /> <br /> The controller code remains generic and it only needs to include a new case which specifies the new filter. This way we can extend the same controller and model code later for future searches. By adding the code in this manner, we have introduced maximum cohesion as all search/filter functionality always uses the same code.<br /> <br /> == External Links ==<br /> <br /> :1. [http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza]<br /> <br /> :2. [http://152.46.20.83:3000/ VCL Link]<br /> <br /> :3. [https://github.com/prateeky1407/expertiza Git repository]<br /> <br /> :4. [https://docs.google.com/a/ncsu.edu/document/d/1Z0xjFZu-Zy-xm73YyUVUgFCtfWgRwhN1rZuThoyF-U0/edit Steps to setup Expertiza]</div>

Agoel2 https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/oss_paa&diff=80471 2013-10-30T01:45:39Z

<p>Agoel2: </p> <hr /> <div>'''Expertiza OSS Project –E809 (TreeDisplay)'''<br /> <br /> __TOC__<br /> == Introduction ==<br /> The [http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza] project has a collapsible tree view structure to facilitate traversal through all learning objects. The problem statement is to redesign the underlying structure and include efficient search, filter and sort mechanism in the tree view structure. The tree is composed of different folders namely Assignments, Courses, Questionnaires and their subfolders respectively.<br /> <br /> ==Existing Design==<br /> Currently the folders structure is displayed as a tree. The structure of the tree is as follows -<br /> <br /> : • Questionnaire<br /> <br /> :: o Review<br /> <br /> :: o Metareview<br /> <br /> :: o Author Feedback<br /> <br /> :: o Teammate Review<br /> <br /> :: o Survey<br /> <br /> :: o Global Survey<br /> <br /> :: o Course Evaluation<br /> <br /> : • Courses<br /> <br /> :: o Course<br /> <br /> :::  assignment<br /> <br /> : • Assignments<br /> <br /> <br /> The whole set of Courses, Assignments and Questionnaires are displayed on screen in a collapsible tree view upon login. Items may be expanded and collapsed. There is no functionality to search/filter results.<br /> The sort functionality has been provided which sorts the tree structure with important metrics such as creation date, name and directory in ascending as well as descending order. <br /> We also have the option to view either the public and private items or the private items only.<br /> <br /> '''[[File:ExistingUI.jpg]]'''<br /> <br /> Fig.1 Existing UI which implements display of nodes and a sort utility<br /> <br /> ==Project Requirement==<br /> The tree display can be inefficient given many objects (courses, etc.). We are supposed to design the underlying structure at the model level to efficiently retrieve organized data. <br /> <br /> We are also required to redesign the view to enable users to filter/search and sort by important metrics such as creation date, name (alphabetical) and relationship (e.g. filter all assignments by a course). <br /> <br /> The interface should be kept modular in the code to increase extensibility for future metrics. We have to keep the controller as ‘skinny’ as possible, leaving the model to perform computational logic.<br /> <br /> <br /> ==Implementation==<br /> We have introduced two new features - search and filter.<br /> To implement the search/filter, we have decided to use the same tree display which is efficient and simple to show the current data.<br /> <br /> '''[[File:newUI.jpg]]'''<br /> <br /> Fig.2 Above is the new UI which includes search and filter functionality<br /> <br /> ===Search===<br /> This functionality searches for a keyword among 3 categories courses/assignment/questionnaire. It is implemented using substring search. All the entries whose substring matches with the search string are returned. Based on the input the user can view the filtered results in any of the 3 categories.<br /> <br /> '''[[File:sample1.jpg]]'''<br /> <br /> Fig.3 A sample output of searching “demo” in assignments.<br /> <br /> ===Filter===<br /> There are 2 main relationships in the tree structure. These are as follows -<br /> <br /> : 1. A course can have many assignments.<br /> <br /> : 2. An assignment can have many questionnaires.<br /> <br /> The user selects one of the two fields and enters the course/assignment name. Then he will see a list of all the elements which are related to that course/assignment.<br /> <br /> '''[[File:sample2.jpg]]'''<br /> <br /> Fig.4 Sample output which shows the result of filtering assignments by course “CourseTest1” <br /> <br /> ===Compatibility with existing features===<br /> We have implemented these 2 filters in the code. A user can search all assignments for a respective course, and also search for all questionnaires related to one assignment. We preserve the sort feature across the implementation which means that the user can sort the filtered results also. The user can also view the public and private items or the private items only for the filtered result.<br /> <br /> '''[[File:sample3.jpg]]'''<br /> <br /> Fig.5 Sample output which shows the same result of searching “demo” in assignments but sorted in descending order.<br /> <br /> ==Design==<br /> ===View===<br /> Since the tree display is the best way to show the folder structure and to maximize code reuse, we choose the same display style for search results. We add search and filter boxes to input the search/filter keyword on the main page and output the result on the same page. We also add the reset button to return to the primary key structure.<br /> All the above changes are done in -<br /> ''' \view \tree_display\_page_header.html.erb '''<br /> <br /> ===Controller===<br /> We modify the existing list function in the tree_display_controller.rb as it is responsible for all the inputs on the tree display page. We also add a new function filter in the file which parses the input string given by the user and converts it into a meaningful string depending on what user wants to filter. Filter is called by list function and the string is placed into a global variable, so that future sort can make use of the previous search.<br /> '''tree_display_controller.rb '''<br /> <br /> ===Model===<br /> We have made changes to the following models to search/filter for the keyword in corresponding nodes.-<br /> <br /> '''questionnaire_node.rb '''<br /> '''assignment_node.rb '''<br /> '''course_node.rb '''<br /> '''node.rb '''<br /> '''folder_node.rb '''<br /> <br /> All the models have the same logic to parse the input search string and accordingly find the nodes in the model objects. The design is extensible and controller is left skinny which just does the parsing of input string and calls a generic model function. The summary is given below<br /> <br /> The view takes the string and passes to controller<br /> <br /> '''User -&gt; input string -&gt; Controller. '''<br /> <br /> <br /> Controller does the parsing and calls a generic function which iterates over folders.<br /> <br /> '''Controller -&gt; search string -&gt; Models(Iterator) '''<br /> '''Iterator -&gt; Controller -&gt; View(display) '''<br /> <br /> <br /> Model returns the required nodes and controller handles them to view. The code which has been put in all model objects is generic. The same code can be used with future nodes or new folders when they are added in future.<br /> <br /> The controller code remains generic and it only needs to include a new case which specifies the new filter. This way we can extend the same controller and model code later for future searches. By adding the code in this manner, we have introduced maximum cohesion as all search/filter functionality always uses the same code.<br /> <br /> == External Links ==<br /> <br /> :1. [http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza]<br /> <br /> :2. [http://152.46.20.83:3000/ VCL Link]<br /> <br /> :3. [https://github.com/prateeky1407/expertiza Git repository]</div>

Agoel2 https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/oss_paa&diff=80261 2013-10-29T04:30:12Z

<p>Agoel2: </p> <hr /> <div>'''Expertiza OSS Project –E809 (TreeDisplay)'''<br /> <br /> __TOC__<br /> == Introduction ==<br /> The [http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza] project has a collapsible tree view structure to facilitate traversal through all learning objects. The problem statement is to redesign the underlying structure and include efficient search, filter and sort mechanism in the tree view structure. The tree is composed of different folders namely Assignments, Courses, Questionnaires and their subfolders respectively.<br /> <br /> ==Existing Design==<br /> Currently the folders structure is displayed as a tree. The structure of the tree is as follows -<br /> <br /> : • Questionnaire<br /> <br /> :: o Review<br /> <br /> :: o Metareview<br /> <br /> :: o Author Feedback<br /> <br /> :: o Teammate Review<br /> <br /> :: o Survey<br /> <br /> :: o Global Survey<br /> <br /> :: o Course Evaluation<br /> <br /> : • Courses<br /> <br /> :: o Course<br /> <br /> :::  assignment<br /> <br /> : • Assignments<br /> <br /> <br /> The whole set of Courses, Assignments and Questionnaires are displayed on screen in a collapsible tree view upon login. Items may be expanded and collapsed. There is no functionality to search/filter results.<br /> The sort functionality has been provided which sorts the tree structure with important metrics such as creation date, name and directory in ascending as well as descending order. <br /> We also have the option to view either the public and private items or the private items only.<br /> <br /> '''[[File:ExistingUI.jpg]]'''<br /> <br /> Fig.1 Existing UI which implements display of nodes and a sort utility<br /> <br /> ==Project Requirement==<br /> The tree display can be inefficient given many objects (courses, etc.). We are supposed to design the underlying structure at the model level to efficiently retrieve organized data. <br /> <br /> We are also required to redesign the view to enable users to filter/search and sort by important metrics such as creation date, name (alphabetical) and relationship (e.g. filter all assignments by a course). <br /> <br /> The interface should be kept modular in the code to increase extensibility for future metrics. We have to keep the controller as ‘skinny’ as possible, leaving the model to perform computational logic.<br /> <br /> <br /> ==Implementation==<br /> We have introduced two new features - search and filter.<br /> To implement the search/filter, we have decided to use the same tree display which is efficient and simple to show the current data.<br /> <br /> '''[[File:newUI.jpg]]'''<br /> <br /> Fig.2 Above is the new UI which includes search and filter functionality<br /> <br /> ===Search===<br /> This functionality searches for a keyword among 3 categories courses/assignment/questionnaire. It is implemented using substring search. All the entries whose substring matches with the search string are returned. Based on the input the user can view the filtered results in any of the 3 categories.<br /> <br /> '''[[File:sample1.jpg]]'''<br /> <br /> Fig.3 A sample output of searching “demo” in assignments.<br /> <br /> ===Filter===<br /> There are 2 main relationships in the tree structure. These are as follows --<br /> <br /> : 1. A course can have many assignments.<br /> <br /> : 2. An assignment can have many questionnaires.<br /> <br /> '''[[File:sample2.jpg]]'''<br /> <br /> Fig.4 Sample output which shows the result of filtering assignments by course “CourseTest1” <br /> <br /> ===Compatibility with existing features===<br /> We have implemented these 2 filters in the code. A user can search all assignments for a respective course, and also search for all questionnaires related to one assignment. We preserve the sort feature across the implementation which means that the user can sort the filtered results also. The user can also view the public and private items or the private items only for the filtered result.<br /> <br /> '''[[File:sample3.jpg]]'''<br /> <br /> Fig.5 Sample output which shows the same result of searching “demo” in assignments but sorted in descending order.<br /> <br /> ==Design==<br /> ===View===<br /> Since the tree display is the best way to show the folder structure and to maximize code reuse, we choose the same display style for search results. We add search and filter boxes to input the search/filter keyword on the main page and output the result on the same page. We also add the reset button to return to the primary key structure.<br /> All the above changes are done in -<br /> ''' \view \tree_display\_page_header.html.erb '''<br /> <br /> ===Controller===<br /> We modify the existing list function in the tree_display_controller.rb as it is responsible for all the inputs on the tree display page. We also add a new function filter in the file which parses the input string given by the user and converts it into a meaningful string depending on what user wants to filter. Filter is called by list function and the string is placed into a global variable, so that future sort can make use of the previous search.<br /> '''tree_display_controller.rb '''<br /> <br /> ===Model===<br /> We have made changes to the following models to search/filter for the keyword in corresponding nodes.-<br /> <br /> '''questionnaire_node.rb '''<br /> '''assignment_node.rb '''<br /> '''course_node.rb '''<br /> '''node.rb '''<br /> '''folder_node.rb '''<br /> <br /> All the models have the same logic to parse the input search string and accordingly find the nodes in the model objects. The design is extensible and controller is left skinny which just does the parsing of input string and calls a generic model function. The summary is given below<br /> <br /> The view takes the string and passes to controller<br /> <br /> '''User -&gt; input string -&gt; Controller. '''<br /> <br /> <br /> Controller does the parsing and calls a generic function which iterates over folders.<br /> <br /> '''Controller -&gt; search string -&gt; Models(Iterator) '''<br /> '''Iterator -&gt; Controller -&gt; View(display) '''<br /> <br /> <br /> Model returns the required nodes and controller handles them to view. The code which has been put in all model objects is generic. The same code can be used with future nodes or new folders when they are added in future.<br /> <br /> The controller code remains generic and it only needs to include a new case which specifies the new filter. This way we can extend the same controller and model code later for future searches. By adding the code in this manner, we have introduced maximum cohesion as all search/filter functionality always uses the same code.<br /> <br /> == External Links ==<br /> <br /> :1. [http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza]<br /> <br /> :2. [http://152.46.20.83:3000/ VCL Link]<br /> <br /> :3. [https://github.com/prateeky1407/expertiza Git repository]</div>

Agoel2 https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/oss_paa&diff=80260 2013-10-29T04:26:55Z

<p>Agoel2: </p> <hr /> <div>'''Expertiza OSS Project –E809 (TreeDisplay)'''<br /> <br /> __TOC__<br /> == Introduction ==<br /> The [http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza] project has a collapsible tree view structure to facilitate traversal through all learning objects. The problem statement is to redesign the underlying structure and include efficient search, filter and sort mechanism in the tree view structure. The tree is composed of different folders namely Assignments, Courses, Questionnaires and their subfolders respectively.<br /> <br /> ==Existing Design==<br /> Currently the folders structure is displayed as a tree. The structure of the tree is as follows -<br /> <br /> : • Questionnaire<br /> <br /> :: o Review<br /> <br /> :: o Metareview<br /> <br /> :: o Author Feedback<br /> <br /> :: o Teammate Review<br /> <br /> :: o Survey<br /> <br /> :: o Global Survey<br /> <br /> :: o Course Evaluation<br /> <br /> : • Courses<br /> <br /> :: o Course<br /> <br /> :::  assignment<br /> <br /> : • Assignments<br /> <br /> <br /> The whole set of Courses, Assignments and Questionnaires are displayed on screen in a collapsible tree view upon login. Items may be expanded and collapsed. There is no functionality to search/filter results.<br /> The sort functionality has been provided which sorts the tree structure with important metrics such as creation date, name and directory in ascending as well as descending order. <br /> We also have the option to view either the public and private items or the private items only.<br /> <br /> '''[[File:ExistingUI.jpg]]'''<br /> <br /> Fig.1 Existing UI which implements display of nodes and a sort utility<br /> <br /> ==Project Requirement==<br /> The tree display can be inefficient given many objects (courses, etc.). We are supposed to design the underlying structure at the model level to efficiently retrieve organized data. <br /> <br /> We are also required to redesign the view to enable users to filter/search and sort by important metrics such as creation date, name (alphabetical) and relationship (e.g. filter all assignments by a course). <br /> <br /> The interface should be kept modular in the code to increase extensibility for future metrics. We have to keep the controller as ‘skinny’ as possible, leaving the model to perform computational logic.<br /> <br /> <br /> ==Implementation==<br /> We have introduced two new features - search and filter.<br /> To implement the search/filter, we have decided to use the same tree display which is efficient and simple to show the current data.<br /> <br /> '''[[File:newUI.jpg]]'''<br /> <br /> Fig.2 Above is the new UI which includes search and filter functionality<br /> <br /> ===Search===<br /> This functionality searches for a keyword among 3 categories courses/assignment/questionnaire. It is implemented using substring search. All the entries whose substring matches with the search string are returned. Based on the input the user can view the filtered results in any of the 3 categories.<br /> <br /> '''[[File:sample1.jpg]]'''<br /> <br /> Fig.3 A sample output of searching “demo” in assignments.<br /> <br /> ===Filter===<br /> There are 2 main relationships in the tree structure. These are as follows --<br /> <br /> : 1. A course can have many assignments.<br /> <br /> : 2. An assignment can have many questionnaires.<br /> <br /> '''[[File:sample2.jpg]]'''<br /> <br /> Fig.4 Sample output which shows the result of filtering assignments by course “CourseTest1” <br /> <br /> ===Compatibility with existing features===<br /> We have implemented these 2 filters in the code. A user can search all assignments for a respective course, and also search for all questionnaires related to one assignment. We preserve the sort feature across the implementation which means that the user can sort the filtered results also. The user can also view the public and private items or the private items only for the filtered result.<br /> <br /> '''[[File:sample3.jpg]]'''<br /> <br /> Fig.5 Sample output which shows the same result of searching “demo” in assignments but sorted in descending order.<br /> <br /> ==Design==<br /> ===View===<br /> Since the tree display is the best way to show the folder structure and to maximize code reuse, we choose the same display style for search results. We add search and filter boxes to input the search/filter keyword on the main page and output the result on the same page. We also add the reset button to return to the primary key structure.<br /> All the above changes are done in -<br /> ''' \view \tree_display\_page_header.html.erb '''<br /> <br /> ===Controller===<br /> We modify the existing list function in the tree_display_controller.rb as it is responsible for all the inputs on the tree display page. We also add a new function filter in the file which parses the input string given by the user and converts it into a meaningful string depending on what user wants to filter. Filter is called by list function and the string is placed into a global variable, so that future sort can make use of the previous search.<br /> '''tree_display_controller.rb '''<br /> <br /> ===Model===<br /> We have made changes to the following models to search/filter for the keyword in corresponding nodes.-<br /> <br /> '''questionnaire_node.rb '''<br /> '''assignment_node.rb '''<br /> '''course_node.rb '''<br /> '''node.rb '''<br /> '''folder_node.rb '''<br /> <br /> All the models have the same logic to parse the input search string and accordingly find the nodes in the model objects. The design is extensible and controller is left skinny which just does the parsing of input string and calls a generic model function. The summary is given below<br /> <br /> The view takes the string and passes to controller<br /> <br /> '''User -&gt; input string -&gt; Controller. '''<br /> <br /> <br /> Controller does the parsing and calls a generic function which iterates over folders.<br /> <br /> '''Controller -&gt; search string -&gt; Models(Iterator) '''<br /> '''Iterator -&gt; Controller -&gt; View(display) '''<br /> <br /> <br /> Model returns the required nodes and controller handles them to view. The code which has been put in all model objects is generic. The same code can be used with future nodes or new folders when they are added in future.<br /> <br /> The controller code remains generic and it only needs to include a new case which specifies the new filter. This way we can extend the same controller and model code later for future searches. By adding the code in this manner, we have introduced maximum cohesion as all search/filter functionality always uses the same code.<br /> <br /> == External Links ==<br /> <br /> :1. [http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza]<br /> <br /> :2. [http://152.46.20.83:3000/ VCL Link]<br /> <br /> :3. [https://github.com/prateeky1407/expertiza Git repository]<br /> <br /> == References ==<br /> <br /> &lt;references /&gt;</div>

Agoel2 https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/oss_paa&diff=80259 2013-10-29T04:23:29Z

<p>Agoel2: </p> <hr /> <div>'''Expertiza OSS Project –E809 (TreeDisplay)'''<br /> <br /> __TOC__<br /> == Introduction ==<br /> The [http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza] project has a collapsible tree view structure to facilitate traversal through all learning objects. The problem statement is to redesign the underlying structure and include efficient search, filter and sort mechanism in the tree view structure. The tree is composed of different folders namely Assignments, Courses, Questionnaires and their subfolders respectively.<br /> <br /> ==Existing Design==<br /> Currently the folders structure is displayed as a tree; the structure of the tree is as follows --<br /> <br /> : • Questionnaire<br /> <br /> :: o Review<br /> <br /> :: o Metareview<br /> <br /> :: o Author Feedback<br /> <br /> :: o Teammate Review<br /> <br /> :: o Survey<br /> <br /> :: o Global Survey<br /> <br /> :: o Course Evaluation<br /> <br /> : • Courses<br /> <br /> :: o Course<br /> <br /> :::  assignment<br /> <br /> : • Assignments<br /> <br /> <br /> The whole set of Courses, Assignments and Questionnaires are displayed on screen in a collapsible tree view upon login. Items may be expanded and collapsed. There is no functionality to search/filter results.<br /> The sort functionality has been provided which sorts the tree structure with important metrics such as creation date, name and directory in ascending as well as descending order. <br /> We also have the option to view either the public and private items or the private items only.<br /> <br /> '''[[File:ExistingUI.jpg]]'''<br /> <br /> Fig.1 Existing UI which implements display of nodes and a sort utility<br /> <br /> ==Project Requirement==<br /> The tree display can be inefficient given many objects (courses, etc.). We are supposed to design the underlying structure at the model level to efficiently retrieve organized data. <br /> <br /> We are also required to redesign the view to enable users to filter/search and sort by important metrics such as creation date, name (alphabetical) and relationship (e.g. filter all assignments by a course). <br /> <br /> The interface should be kept modular in the code to increase extensibility for future metrics. We have to keep the controller as ‘skinny’ as possible, leaving the model to perform computational logic.<br /> <br /> <br /> ==Implementation==<br /> We have introduced two new features - search and filter.<br /> To implement the search/filter, we have decided to use the same tree display which is efficient and simple to show the current data.<br /> <br /> '''[[File:newUI.jpg]]'''<br /> <br /> Fig.2 Above is the new UI which includes search and filter functionality<br /> <br /> ===Search===<br /> This functionality searches for a keyword among 3 categories courses/assignment/questionnaire. It is implemented using substring search. All the entries whose substring matches with the search string are returned. Based on the input the user can view the filtered results in any of the 3 categories.<br /> <br /> '''[[File:sample1.jpg]]'''<br /> <br /> Fig.3 A sample output of searching “demo” in assignments.<br /> <br /> ===Filter===<br /> There are 2 main relationships in the tree structure. These are as follows --<br /> <br /> : 1. A course can have many assignments.<br /> <br /> : 2. An assignment can have many questionnaires.<br /> <br /> '''[[File:sample2.jpg]]'''<br /> <br /> Fig.4 Sample output which shows the result of filtering assignments by course “CourseTest1” <br /> <br /> ===Compatibility with existing features===<br /> We have implemented these 2 filters in the code. A user can search all assignments for a respective course, and also search for all questionnaires related to one assignment. We preserve the sort feature across the implementation which means that the user can sort the filtered results also. The user can also view the public and private items or the private items only for the filtered result.<br /> <br /> '''[[File:sample3.jpg]]'''<br /> <br /> Fig.5 Sample output which shows the same result of searching “demo” in assignments but sorted in descending order.<br /> <br /> ==Design==<br /> ===View===<br /> Since the tree display is the best way to show the folder structure and to maximize code reuse, we choose the same display style for search results. We add search and filter boxes to input the search/filter keyword on the main page and output the result on the same page. We also add the reset button to return to the primary key structure.<br /> All the above changes are done in -<br /> ''' \view \tree_display\_page_header.html.erb '''<br /> <br /> ===Controller===<br /> We modify the existing list function in the tree_display_controller.rb as it is responsible for all the inputs on the tree display page. We also add a new function filter in the file which parses the input string given by the user and converts it into a meaningful string depending on what user wants to filter. Filter is called by list function and the string is placed into a global variable, so that future sort can make use of the previous search.<br /> '''tree_display_controller.rb '''<br /> <br /> ===Model===<br /> We have made changes to the following models to search/filter for the keyword in corresponding nodes.-<br /> <br /> '''questionnaire_node.rb '''<br /> '''assignment_node.rb '''<br /> '''course_node.rb '''<br /> '''node.rb '''<br /> '''folder_node.rb '''<br /> <br /> All the models have the same logic to parse the input search string and accordingly find the nodes in the model objects. The design is extensible and controller is left skinny which just does the parsing of input string and calls a generic model function. The summary is given below<br /> <br /> The view takes the string and passes to controller<br /> <br /> '''User -&gt; input string -&gt; Controller. '''<br /> <br /> <br /> Controller does the parsing and calls a generic function which iterates over folders.<br /> <br /> '''Controller -&gt; search string -&gt; Models(Iterator) '''<br /> '''Iterator -&gt; Controller -&gt; View(display) '''<br /> <br /> <br /> Model returns the required nodes and controller handles them to view. The code which has been put in all model objects is generic. The same code can be used with future nodes or new folders when they are added in future.<br /> <br /> The controller code remains generic and it only needs to include a new case which specifies the new filter. This way we can extend the same controller and model code later for future searches. By adding the code in this manner, we have introduced maximum cohesion as all search/filter functionality always uses the same code.<br /> <br /> == External Links ==<br /> <br /> :1. [http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza]<br /> <br /> :2. [http://152.46.20.83:3000/ VCL Link]<br /> <br /> :3. [https://github.com/prateeky1407/expertiza Git repository]<br /> <br /> == References ==<br /> <br /> &lt;references /&gt;</div>

Agoel2 https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/oss_paa&diff=80258 2013-10-29T04:21:41Z

<p>Agoel2: </p> <hr /> <div>'''Expertiza OSS Project –E809 (TreeDisplay)'''<br /> <br /> __TOC__<br /> == Introduction ==<br /> The Expertiza project has a collapsible tree view structure to facilitate traversal through all learning objects. The problem statement is to redesign the underlying structure and include efficient search, filter and sort mechanism in the tree view structure. The tree is composed of different folders namely Assignments, Courses, Questionnaires and their subfolder respectively.<br /> <br /> ==Existing Design==<br /> Currently the folders structure is displayed as a tree; the structure of the tree is as follows --<br /> <br /> : • Questionnaire<br /> <br /> :: o Review<br /> <br /> :: o Metareview<br /> <br /> :: o Author Feedback<br /> <br /> :: o Teammate Review<br /> <br /> :: o Survey<br /> <br /> :: o Global Survey<br /> <br /> :: o Course Evaluation<br /> <br /> : • Courses<br /> <br /> :: o Course<br /> <br /> :::  assignment<br /> <br /> : • Assignments<br /> <br /> <br /> The whole set of Courses, Assignments and Questionnaires are displayed on screen in a collapsible tree view upon login. Items may be expanded and collapsed. There is no functionality to search/filter results.<br /> The sort functionality has been provided which sorts the tree structure with important metrics such as creation date, name and directory in ascending as well as descending order. <br /> We also have the option to view either the public and private items or the private items only.<br /> <br /> '''[[File:ExistingUI.jpg]]'''<br /> <br /> Fig.1 Existing UI which implements display of nodes and a sort utility<br /> <br /> ==Project Requirement==<br /> The tree display can be inefficient given many objects (courses, etc.). We are supposed to design the underlying structure at the model level to efficiently retrieve organized data. <br /> <br /> We are also required to redesign the view to enable users to filter/search and sort by important metrics such as creation date, name (alphabetical) and relationship (e.g. filter all assignments by a course). <br /> <br /> The interface should be kept modular in the code to increase extensibility for future metrics. We have to keep the controller as ‘skinny’ as possible, leaving the model to perform computational logic.<br /> <br /> <br /> ==Implementation==<br /> We have introduced two new features - search and filter.<br /> To implement the search/filter, we have decided to use the same tree display which is efficient and simple to show the current data.<br /> <br /> '''[[File:newUI.jpg]]'''<br /> <br /> Fig.2 Above is the new UI which includes search and filter functionality<br /> <br /> ===Search===<br /> This functionality searches for a keyword among 3 categories courses/assignment/questionnaire. It is implemented using substring search. All the entries whose substring matches with the search string are returned. Based on the input the user can view the filtered results in any of the 3 categories.<br /> <br /> '''[[File:sample1.jpg]]'''<br /> <br /> Fig.3 A sample output of searching “demo” in assignments.<br /> <br /> ===Filter===<br /> There are 2 main relationships in the tree structure. These are as follows --<br /> <br /> : 1. A course can have many assignments.<br /> <br /> : 2. An assignment can have many questionnaires.<br /> <br /> '''[[File:sample2.jpg]]'''<br /> <br /> Fig.4 Sample output which shows the result of filtering assignments by course “CourseTest1” <br /> <br /> ===Compatibility with existing features===<br /> We have implemented these 2 filters in the code. A user can search all assignments for a respective course, and also search for all questionnaires related to one assignment. We preserve the sort feature across the implementation which means that the user can sort the filtered results also. The user can also view the public and private items or the private items only for the filtered result.<br /> <br /> '''[[File:sample3.jpg]]'''<br /> <br /> Fig.5 Sample output which shows the same result of searching “demo” in assignments but sorted in descending order.<br /> <br /> ==Design==<br /> ===View===<br /> Since the tree display is the best way to show the folder structure and to maximize code reuse, we choose the same display style for search results. We add search and filter boxes to input the search/filter keyword on the main page and output the result on the same page. We also add the reset button to return to the primary key structure.<br /> All the above changes are done in -<br /> ''' \view \tree_display\_page_header.html.erb '''<br /> <br /> ===Controller===<br /> We modify the existing list function in the tree_display_controller.rb as it is responsible for all the inputs on the tree display page. We also add a new function filter in the file which parses the input string given by the user and converts it into a meaningful string depending on what user wants to filter. Filter is called by list function and the string is placed into a global variable, so that future sort can make use of the previous search.<br /> '''tree_display_controller.rb '''<br /> <br /> ===Model===<br /> We have made changes to the following models to search/filter for the keyword in corresponding nodes.-<br /> <br /> '''questionnaire_node.rb '''<br /> '''assignment_node.rb '''<br /> '''course_node.rb '''<br /> '''node.rb '''<br /> '''folder_node.rb '''<br /> <br /> All the models have the same logic to parse the input search string and accordingly find the nodes in the model objects. The design is extensible and controller is left skinny which just does the parsing of input string and calls a generic model function. The summary is given below<br /> <br /> The view takes the string and passes to controller<br /> <br /> '''User -&gt; input string -&gt; Controller. '''<br /> <br /> <br /> Controller does the parsing and calls a generic function which iterates over folders.<br /> <br /> '''Controller -&gt; search string -&gt; Models(Iterator) '''<br /> '''Iterator -&gt; Controller -&gt; View(display) '''<br /> <br /> <br /> Model returns the required nodes and controller handles them to view. The code which has been put in all model objects is generic. The same code can be used with future nodes or new folders when they are added in future.<br /> <br /> The controller code remains generic and it only needs to include a new case which specifies the new filter. This way we can extend the same controller and model code later for future searches. By adding the code in this manner, we have introduced maximum cohesion as all search/filter functionality always uses the same code.<br /> <br /> == External Links ==<br /> <br /> :1. [http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza]<br /> <br /> :2. [http://152.46.20.83:3000/ VCL Link]<br /> <br /> :3. [https://github.com/prateeky1407/expertiza Git repository]</div>

Agoel2 https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/oss_paa&diff=80257 2013-10-29T04:09:09Z

<p>Agoel2: </p> <hr /> <div>'''Expertiza OSS Project –E809 (TreeDisplay)'''<br /> <br /> __TOC__<br /> == Introduction ==<br /> The problem statement is to include search/filter/sort using a collapsible tree view structure. The tree is composed of different folders namely Assignments, Courses, Questionnaires and their subfolder respectively.<br /> <br /> ==Existing Design==<br /> Currently the folders structure is displayed as a tree; the structure of the tree is as follows --<br /> <br /> : • Questionnaire<br /> <br /> :: o Review<br /> <br /> :: o Metareview<br /> <br /> :: o Author Feedback<br /> <br /> :: o Teammate Review<br /> <br /> :: o Survey<br /> <br /> :: o Global Survey<br /> <br /> :: o Course Evaluation<br /> <br /> : • Courses<br /> <br /> :: o Course<br /> <br /> :::  assignment<br /> <br /> : • Assignments<br /> <br /> <br /> The whole set of Courses, Assignments and Questionnaires are displayed on screen in a collapsible tree view upon login. Items may be expanded and collapsed. There is no functionality to search/filter results.<br /> The sort functionality has been provided which sorts the tree structure with important metrics such as creation date, name and directory in ascending as well as descending order. <br /> We also have the option to view either the public and private items or the private items only.<br /> <br /> '''[[File:ExistingUI.jpg]]'''<br /> <br /> Fig.1 Existing UI which implements display of nodes and a sort utility<br /> <br /> ==Project Requirement==<br /> The tree display can be inefficient given many objects (courses, etc.). We are supposed to design the underlying structure at the model level to efficiently retrieve organized data. <br /> <br /> We are also required to redesign the view to enable users to filter/search and sort by important metrics such as creation date, name (alphabetical) and relationship (e.g. filter all assignments by a course). <br /> <br /> The interface should be kept modular in the code to increase extensibility for future metrics. We have to keep the controller as ‘skinny’ as possible, leaving the model to perform computational logic.<br /> <br /> <br /> ==Implementation==<br /> We have introduced two new features - search and filter.<br /> To implement the search/filter, we have decided to use the same tree display which is efficient and simple to show the current data.<br /> <br /> '''[[File:newUI.jpg]]'''<br /> <br /> Fig.2 Above is the new UI which includes search and filter functionality<br /> <br /> ===Search===<br /> This functionality searches for a keyword among 3 categories courses/assignment/questionnaire. It is implemented using substring search. All the entries whose substring matches with the search string are returned. Based on the input the user can view the filtered results in any of the 3 categories.<br /> <br /> '''[[File:sample1.jpg]]'''<br /> <br /> Fig.3 A sample output of searching “demo” in assignments.<br /> <br /> ===Filter===<br /> There are 2 main relationships in the tree structure. These are as follows --<br /> <br /> : 1. A course can have many assignments.<br /> <br /> : 2. An assignment can have many questionnaires.<br /> <br /> '''[[File:sample2.jpg]]'''<br /> <br /> Fig.4 Sample output which shows the result of filtering assignments by course “CourseTest1” <br /> <br /> ===Compatibility with existing features===<br /> We have implemented these 2 filters in the code. A user can search all assignments for a respective course, and also search for all questionnaires related to one assignment. We preserve the sort feature across the implementation which means that the user can sort the filtered results also. The user can also view the public and private items or the private items only for the filtered result.<br /> <br /> '''[[File:sample3.jpg]]'''<br /> <br /> Fig.5 Sample output which shows the same result of searching “demo” in assignments but sorted in descending order.<br /> <br /> ==Design==<br /> ===View===<br /> Since the tree display is the best way to show the folder structure and to maximize code reuse, we choose the same display style for search results. We add search and filter boxes to input the search/filter keyword on the main page and output the result on the same page. We also add the reset button to return to the primary key structure.<br /> All the above changes are done in -<br /> ''' \view \tree_display\_page_header.html.erb '''<br /> <br /> ===Controller===<br /> We modify the existing list function in the tree_display_controller.rb as it is responsible for all the inputs on the tree display page. We also add a new function filter in the file which parses the input string given by the user and converts it into a meaningful string depending on what user wants to filter. Filter is called by list function and the string is placed into a global variable, so that future sort can make use of the previous search.<br /> '''tree_display_controller.rb '''<br /> <br /> ===Model===<br /> We have made changes to the following models to search/filter for the keyword in corresponding nodes.-<br /> <br /> '''questionnaire_node.rb '''<br /> '''assignment_node.rb '''<br /> '''course_node.rb '''<br /> '''node.rb '''<br /> '''folder_node.rb '''<br /> <br /> All the models have the same logic to parse the input search string and accordingly find the nodes in the model objects. The design is extensible and controller is left skinny which just does the parsing of input string and calls a generic model function. The summary is given below<br /> <br /> The view takes the string and passes to controller<br /> <br /> '''User -&gt; input string -&gt; Controller. '''<br /> <br /> <br /> Controller does the parsing and calls a generic function which iterates over folders.<br /> <br /> '''Controller -&gt; search string -&gt; Models(Iterator) '''<br /> '''Iterator -&gt; Controller -&gt; View(display) '''<br /> <br /> <br /> Model returns the required nodes and controller handles them to view. The code which has been put in all model objects is generic. The same code can be used with future nodes or new folders when they are added in future.<br /> <br /> The controller code remains generic and it only needs to include a new case which specifies the new filter. This way we can extend the same controller and model code later for future searches. By adding the code in this manner, we have introduced maximum cohesion as all search/filter functionality always uses the same code.<br /> <br /> == External Links ==<br /> <br /> :1. [http://152.46.20.83:3000/ VCL Link]<br /> <br /> :2. [https://github.com/prateeky1407/expertiza Git repository]</div>

Agoel2 https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/oss_paa&diff=80256 2013-10-29T04:07:23Z

<p>Agoel2: </p> <hr /> <div>'''Expertiza OSS Project –E809 (TreeDisplay)'''<br /> <br /> __TOC__<br /> == Introduction ==<br /> The problem statement is to include search/filter/sort using a collapsible tree view structure. The tree is composed of different folders namely Assignments, Courses, Questionnaires and their subfolder respectively.<br /> <br /> ==Existing Design==<br /> Currently the folders structure is displayed as a tree; the structure of the tree is as follows --<br /> <br /> : • Questionnaire<br /> <br /> :: o Review<br /> <br /> :: o Metareview<br /> <br /> :: o Author Feedback<br /> <br /> :: o Teammate Review<br /> <br /> :: o Survey<br /> <br /> :: o Global Survey<br /> <br /> :: o Course Evaluation<br /> <br /> : • Courses<br /> <br /> :: o Course<br /> <br /> :::  assignment<br /> <br /> : • Assignments<br /> <br /> <br /> The whole set of Courses, Assignments and Questionnaires are displayed on screen in a collapsible tree view upon login. Items may be expanded and collapsed. There is no functionality to search/filter results.<br /> The sort functionality has been provided which sorts the tree structure with important metrics such as creation date, name and directory in ascending as well as descending order. <br /> We also have the option to view either the public and private items or the private items only.<br /> <br /> [[File:ExistingUI.jpg]]<br /> <br /> Fig.1 Existing UI which implements display of nodes and a sort utility<br /> <br /> ==Project Requirement==<br /> The tree display can be inefficient given many objects (courses, etc.). We are supposed to design the underlying structure at the model level to efficiently retrieve organized data. <br /> <br /> We are also required to redesign the view to enable users to filter/search and sort by important metrics such as creation date, name (alphabetical) and relationship (e.g. filter all assignments by a course). <br /> <br /> The interface should be kept modular in the code to increase extensibility for future metrics. We have to keep the controller as ‘skinny’ as possible, leaving the model to perform computational logic.<br /> <br /> <br /> ==Implementation==<br /> We have introduced two new features - search and filter.<br /> To implement the search/filter, we have decided to use the same tree display which is efficient and simple to show the current data.<br /> <br /> [[File:newUI.jpg]]<br /> <br /> Fig.2 Above is the new UI which includes search and filter functionality<br /> <br /> ===Search===<br /> This functionality searches for a keyword among 3 categories courses/assignment/questionnaire. It is implemented using substring search. All the entries whose substring matches with the search string are returned. Based on the input the user can view the filtered results in any of the 3 categories.<br /> <br /> [[File:sample1.jpg]]<br /> <br /> Fig.3 A sample output of searching “demo” in assignments.<br /> <br /> ===Filter===<br /> There are 2 main relationships in the tree structure. These are as follows --<br /> <br /> : 1. A course can have many assignments.<br /> <br /> : 2. An assignment can have many questionnaires.<br /> <br /> [[File:sample2.jpg]]<br /> <br /> Fig.4 Sample output which shows the result of filtering assignments by course “CourseTest1” <br /> <br /> ===Compatibility with existing features===<br /> We have implemented these 2 filters in the code. A user can search all assignments for a respective course, and also search for all questionnaires related to one assignment. We preserve the sort feature across the implementation which means that the user can sort the filtered results also. The user can also view the public and private items or the private items only for the filtered result.<br /> <br /> [[File:sample3.jpg]]<br /> <br /> Fig.5 Sample output which shows the same result of searching “demo” in assignments but sorted in descending order.<br /> <br /> ==Design==<br /> ===View===<br /> Since the tree display is the best way to show the folder structure and to maximize code reuse, we choose the same display style for search results. We add search and filter boxes to input the search/filter keyword on the main page and output the result on the same page. We also add the reset button to return to the primary key structure.<br /> All the above changes are done in -<br /> ''' \view \tree_display\_page_header.html.erb '''<br /> <br /> ===Controller===<br /> We modify the existing list function in the tree_display_controller.rb as it is responsible for all the inputs on the tree display page. We also add a new function filter in the file which parses the input string given by the user and converts it into a meaningful string depending on what user wants to filter. Filter is called by list function and the string is placed into a global variable, so that future sort can make use of the previous search.<br /> '''tree_display_controller.rb '''<br /> <br /> ===Model===<br /> We have made changes to the following models to search/filter for the keyword in corresponding nodes.-<br /> <br /> '''questionnaire_node.rb '''<br /> '''assignment_node.rb '''<br /> '''course_node.rb '''<br /> '''node.rb '''<br /> '''folder_node.rb '''<br /> <br /> All the models have the same logic to parse the input search string and accordingly find the nodes in the model objects. The design is extensible and controller is left skinny which just does the parsing of input string and calls a generic model function. The summary is given below<br /> <br /> The view takes the string and passes to controller<br /> <br /> '''User -&gt; input string -&gt; Controller. '''<br /> <br /> <br /> Controller does the parsing and calls a generic function which iterates over folders.<br /> <br /> '''Controller -&gt; search string -&gt; Models(Iterator) '''<br /> '''Iterator -&gt; Controller -&gt; View(display) '''<br /> <br /> <br /> Model returns the required nodes and controller handles them to view. The code which has been put in all model objects is generic. The same code can be used with future nodes or new folders when they are added in future.<br /> <br /> The controller code remains generic and it only needs to include a new case which specifies the new filter. This way we can extend the same controller and model code later for future searches. By adding the code in this manner, we have introduced maximum cohesion as all search/filter functionality always uses the same code.<br /> <br /> == External Links ==<br /> <br /> :1. [http://152.46.20.83:3000/ VCL Link]<br /> <br /> :2. [https://github.com/prateeky1407/expertiza Git repository]</div>

Agoel2 https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/oss_paa&diff=80255 2013-10-29T04:01:38Z

<p>Agoel2: </p> <hr /> <div>'''Expertiza OSS Project –E809 (TreeDisplay)'''<br /> <br /> __TOC__<br /> == Introduction ==<br /> The problem statement is to include search/filter/sort using a collapsible tree view structure. The tree is composed of different folders namely Assignments, Courses, Questionnaires and their subfolder respectively.<br /> <br /> ==Existing Design==<br /> Currently the folders structure is displayed as a tree; the structure of the tree is as follows --<br /> <br /> : • Questionnaire<br /> <br /> :: o Review<br /> <br /> :: o Metareview<br /> <br /> :: o Author Feedback<br /> <br /> :: o Teammate Review<br /> <br /> :: o Survey<br /> <br /> :: o Global Survey<br /> <br /> :: o Course Evaluation<br /> <br /> : • Courses<br /> <br /> :: o Course<br /> <br /> :::  assignment<br /> <br /> : • Assignments<br /> <br /> <br /> The whole set of Courses, Assignments and Questionnaires are displayed on screen in a collapsible tree view upon login. Items may be expanded and collapsed. There is no functionality to search/filter results.<br /> The sort functionality has been provided which sorts the tree structure with important metrics such as creation date, name and directory in ascending as well as descending order. <br /> We also have the option to view either the public and private items or the private items only.<br /> <br /> [[File:ExistingUI.jpg]]<br /> <br /> Fig.1 Existing UI which implements display of nodes and a sort utility<br /> <br /> ==Project Requirement==<br /> The tree display can be inefficient given many objects (courses, etc.). We are supposed to design the underlying structure at the model level to efficiently retrieve organized data. <br /> <br /> We are also required to redesign the view to enable users to filter/search and sort by important metrics such as creation date, name (alphabetical) and relationship (e.g. filter all assignments by a course). <br /> <br /> The interface should be kept modular in the code to increase extensibility for future metrics. We have to keep the controller as ‘skinny’ as possible, leaving the model to perform computational logic.<br /> <br /> <br /> ==Implementation==<br /> We have introduced two new features - search and filter.<br /> To implement the search/filter, we have decided to use the same tree display which is efficient and simple to show the current data.<br /> <br /> [[File:newUI.jpg]]<br /> <br /> Fig.2 Above is the new UI which includes search and filter functionality<br /> <br /> ===Search===<br /> This functionality searches for a keyword among 3 categories courses/assignment/questionnaire. It is implemented using substring search. All the entries whose substring matches with the search string are returned. Based on the input the user can view the filtered results in any of the 3 categories.<br /> <br /> [[File:sample1.jpg]]<br /> <br /> Fig.3 A sample output of searching “demo” in assignments.<br /> <br /> ===Filter===<br /> There are 2 main relationships in the tree structure. These are as follows --<br /> <br /> : 1. A course can have many assignments.<br /> <br /> : 2. An assignment can have many questionnaires.<br /> <br /> [[File:sample2.jpg]]<br /> <br /> Fig.4 Sample output which shows the result of filtering assignments by course “CourseTest1” <br /> <br /> ===Compatibility with existing features===<br /> We have implemented these 2 filters in the code. A user can search all assignments for a respective course, and also search for all questionnaires related to one assignment. We preserve the sort feature across the implementation which means that the user can sort the filtered results also. The user can also view the public and private items or the private items only for the filtered result.<br /> <br /> [[File:sample3.jpg]]<br /> <br /> Fig.5 Sample output which shows the same result of searching “demo” in assignments but sorted in descending order.<br /> <br /> ==Design==<br /> ===View===<br /> Since the tree display is the best way to show the folder structure and to maximize code reuse, we choose the same display style for search results. We add search and filter boxes to input the search/filter keyword on the main page and output the result on the same page. We also add the reset button to return to the primary key structure.<br /> All the above changes are done in -<br /> ''' \view \tree_display\_page_header.html.erb '''<br /> <br /> ===Controller===<br /> We modify the existing list function in the tree_display_controller.rb as it is responsible for all the inputs on the tree display page. We also add a new function filter in the file which parses the input string given by the user and converts it into a meaningful string depending on what user wants to filter. Filter is called by list function and the string is placed into a global variable, so that future sort can make use of the previous search.<br /> '''tree_display_controller.rb '''<br /> <br /> ===Model===<br /> We have made changes to the following models to search/filter for the keyword in corresponding nodes.-<br /> <br /> '''questionnaire_node.rb '''<br /> '''assignment_node.rb '''<br /> '''course_node.rb '''<br /> '''node.rb '''<br /> '''folder_node.rb '''<br /> <br /> All the models have the same logic to parse the input search string and accordingly find the nodes in the model objects. The design is extensible and controller is left skinny which just does the parsing of input string and calls a generic model function. The summary is given below<br /> <br /> The view takes the string and passes to controller<br /> <br /> '''User -&gt; input string -&gt; Controller. '''<br /> <br /> <br /> Controller does the parsing and calls a generic function which iterates over folders.<br /> <br /> '''Controller -&gt; search string -&gt; Models(Iterator) '''<br /> '''Iterator -&gt; Controller -&gt; View(display) '''<br /> <br /> <br /> Model returns the required nodes and controller handles them to view. The code which has been put in all model objects is generic. The same code can be used with future nodes or new folders when they are added in future.<br /> <br /> The controller code remains generic and it only needs to include a new case which specifies the new filter. This way we can extend the same controller and model code later for future searches. By adding the code in this manner, we have introduced maximum cohesion as all search/filter functionality always uses the same code.</div>

Agoel2 https://wiki.expertiza.ncsu.edu/index.php?title=File:Sample3.jpg&diff=80254 2013-10-29T03:54:14Z

<p>Agoel2: </p> <hr /> <div></div>

Agoel2 https://wiki.expertiza.ncsu.edu/index.php?title=File:Sample2.jpg&diff=80253 2013-10-29T03:54:04Z

<p>Agoel2: </p> <hr /> <div></div>

Agoel2 https://wiki.expertiza.ncsu.edu/index.php?title=File:Sample1.jpg&diff=80252 2013-10-29T03:53:50Z

<p>Agoel2: </p> <hr /> <div></div>

Agoel2 https://wiki.expertiza.ncsu.edu/index.php?title=File:NewUI.jpg&diff=80251 2013-10-29T03:53:18Z

<p>Agoel2: </p> <hr /> <div></div>

Agoel2 https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/oss_paa&diff=80250 2013-10-29T03:52:33Z

<p>Agoel2: </p> <hr /> <div>'''Expertiza OSS Project –E809 (TreeDisplay)'''<br /> <br /> __TOC__<br /> == Introduction ==<br /> The problem statement is to include search/filter/sort using a collapsible tree view structure. The tree is composed of different folders namely Assignments, Courses, Questionnaires and their subfolder respectively.<br /> <br /> ==Existing Design==<br /> Currently the folders structure is displayed as a tree; the structure of the tree is as follows --<br /> <br /> : • Questionnaire<br /> <br /> :: o Review<br /> <br /> :: o Metareview<br /> <br /> :: o Author Feedback<br /> <br /> :: o Teammate Review<br /> <br /> :: o Survey<br /> <br /> :: o Global Survey<br /> <br /> :: o Course Evaluation<br /> <br /> : • Courses<br /> <br /> :: o Course<br /> <br /> :::  assignment<br /> <br /> : • Assignments<br /> <br /> <br /> The whole set of Courses, Assignments and Questionnaires are displayed on screen in a collapsible tree view upon login. Items may be expanded and collapsed. There is no functionality to search/filter results.<br /> The sort functionality has been provided which sorts the tree structure with important metrics such as creation date, name and directory in ascending as well as descending order. <br /> We also have the option to view either the public and private items or the private items only.<br /> <br /> [[File:ExistingUI.jpg]]<br /> <br /> Fig.1 Existing UI which implements display of nodes and a sort utility<br /> <br /> ==Project Requirement==<br /> The tree display can be inefficient given many objects (courses, etc.). We are supposed to design the underlying structure at the model level to efficiently retrieve organized data. <br /> <br /> We are also required to redesign the view to enable users to filter/search and sort by important metrics such as creation date, name (alphabetical) and relationship (e.g. filter all assignments by a course). <br /> <br /> The interface should be kept modular in the code to increase extensibility for future metrics. We have to keep the controller as ‘skinny’ as possible, leaving the model to perform computational logic.<br /> <br /> <br /> ==Implementation==<br /> We have introduced two new features - search and filter.<br /> To implement the search/filter, we have decided to use the same tree display which is efficient and simple to show the current data.<br /> <br /> [[File:newUI.jpg]]<br /> <br /> Fig.2 Above is the new UI which includes search and filter functionality<br /> <br /> ===Search===<br /> This functionality searches for a keyword among 3 categories courses/assignment/questionnaire. It is implemented using substring search. All the entries whose substring matches with the search string are returned. Based on the input the user can view the filtered results in any of the 3 categories.<br /> <br /> [[File:sample1.jpg]]<br /> <br /> Fig.3 A sample output of searching “demo” in assignments.<br /> <br /> ===Filter===<br /> There are 2 main relationships in the tree structure. These are as follows --<br /> <br /> : 1. A course can have many assignments.<br /> <br /> : 2. An assignment can have many questionnaires.<br /> <br /> [[File:sample2.jpg]]<br /> <br /> Fig.4 Sample output which shows the result of filtering assignments by course “CourseTest1” <br /> <br /> ===Compatibility with existing features===<br /> We have implemented these 2 filters in the code. A user can search all assignments for a respective course, and also search for all questionnaires related to one assignment. We preserve the sort feature across the implementation which means that the user can sort the filtered results also. The user can also view the public and private items or the private items only for the filtered result.<br /> <br /> [[File:sample3.jpg]]<br /> <br /> Fig.5 Sample output which shows the same result of searching “demo” in assignments but sorted in descending order.<br /> <br /> ==Design==<br /> ===View===<br /> Since the tree display is the best way to show the folder structure and to maximize code reuse, we choose the same display style for search results. We add search and filter boxes to input the search/filter keyword on the main page and output the result on the same page. We also add the reset button to return to the primary key structure.<br /> All the above changes are done in \view \tree_display\_page_header.html.erb <br /> <br /> ===Controller===<br /> We modify the existing list function in the tree_display_controller.rb as it is responsible for all the inputs on the tree display page. We also add a new function filter in the file which parses the input string given by the user and converts it into a meaningful string depending on what user wants to filter. Filter is called by list function and the string is placed into a global variable, so that future sort can make use of the previous search.<br /> <br /> ===Model===<br /> We have made changes to the following models to search/filter for the keyword in corresponding nodes.-<br /> <br /> questionnaire_node.rb<br /> <br /> assignment_node.rb<br /> <br /> course_node.rb<br /> <br /> node.rb<br /> <br /> folder_node.rb<br /> <br /> All the models have the same logic to parse the input search string and accordingly find the nodes in the model objects. The design is extensible and controller is left skinny which just does the parsing of input string and calls a generic model function. The summary is given below<br /> <br /> The view takes the string and passes to controller<br /> <br /> User -&gt; input string -&gt; Controller.<br /> <br /> <br /> Controller does the parsing and calls a generic function which iterates over folders.<br /> <br /> Controller -&gt; search string -&gt; Models(Iterator)<br /> <br /> Iterator -&gt; Controller -&gt; View(display)<br /> <br /> <br /> Model returns the required nodes and controller handles them to view. The code which has been put in all model objects is generic. The same code can be used with future nodes or new folders when they are added in future.<br /> <br /> The controller code remains generic and it only needs to include a new case which specifies the new filter. This way we can extend the same controller and model code later for future searches. By adding the code in this manner, we have introduced maximum cohesion as all search/filter functionality always uses the same code.</div>

Agoel2 https://wiki.expertiza.ncsu.edu/index.php?title=File:ExistingUI.jpg&diff=80249 2013-10-29T03:47:49Z

<p>Agoel2: uploaded a new version of &amp;quot;File:ExistingUI.jpg&amp;quot;</p> <hr /> <div></div>

Agoel2 https://wiki.expertiza.ncsu.edu/index.php?title=File:ExistingUI.jpg&diff=80248 2013-10-29T03:44:20Z

<p>Agoel2: </p> <hr /> <div></div>

Agoel2 https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/oss_paa&diff=80247 2013-10-29T03:43:59Z

<p>Agoel2: </p> <hr /> <div>'''Expertiza OSS Project –E809 (TreeDisplay)'''<br /> <br /> __TOC__<br /> == Introduction ==<br /> The problem statement is to include search/filter/sort using a collapsible tree view structure. The tree is composed of different folders namely Assignments, Courses, Questionnaires and their subfolder respectively.<br /> <br /> ==Existing Design==<br /> Currently the folders structure is displayed as a tree; the structure of the tree is as follows --<br /> <br /> : • Questionnaire<br /> <br /> :: o Review<br /> <br /> :: o Metareview<br /> <br /> :: o Author Feedback<br /> <br /> :: o Teammate Review<br /> <br /> :: o Survey<br /> <br /> :: o Global Survey<br /> <br /> :: o Course Evaluation<br /> <br /> : • Courses<br /> <br /> :: o Course<br /> <br /> :::  assignment<br /> <br /> : • Assignments<br /> <br /> <br /> The whole set of Courses, Assignments and Questionnaires are displayed on screen in a collapsible tree view upon login. Items may be expanded and collapsed. There is no functionality to search/filter results.<br /> The sort functionality has been provided which sorts the tree structure with important metrics such as creation date, name and directory in ascending as well as descending order. <br /> We also have the option to view either the public and private items or the private items only.<br /> <br /> [[File:ExistingUI.jpg]]<br /> Fig.1 Existing UI which implements display of nodes and a sort utility<br /> <br /> ==Project Requirement==<br /> The tree display can be inefficient given many objects (courses, etc.). We are supposed to design the underlying structure at the model level to efficiently retrieve organized data. <br /> <br /> We are also required to redesign the view to enable users to filter/search and sort by important metrics such as creation date, name (alphabetical) and relationship (e.g. filter all assignments by a course). <br /> <br /> The interface should be kept modular in the code to increase extensibility for future metrics. We have to keep the controller as ‘skinny’ as possible, leaving the model to perform computational logic.<br /> <br /> <br /> ==Implementation==<br /> We have introduced two new features - search and filter.<br /> To implement the search/filter, we have decided to use the same tree display which is efficient and simple to show the current data.<br /> ===Search===<br /> This functionality searches for a keyword among 3 categories courses/assignment/questionnaire. It is implemented using substring search. All the entries whose substring matches with the search string are returned. Based on the input the user can view the filtered results in any of the 3 categories.<br /> ===Filter===<br /> There are 2 main relationships in the tree structure. These are as follows --<br /> <br /> : 1. A course can have many assignments.<br /> <br /> : 2. An assignment can have many questionnaires.<br /> <br /> ===Compatibility with existing features===<br /> We have implemented these 2 filters in the code. A user can search all assignments for a respective course, and also search for all questionnaires related to one assignment. We preserve the sort feature across the implementation which means that the user can sort the filtered results also. The user can also view the public and private items or the private items only for the filtered result.<br /> <br /> <br /> ==Design==<br /> ===View===<br /> Since the tree display is the best way to show the folder structure and to maximize code reuse, we choose the same display style for search results. We add search and filter boxes to input the search/filter keyword on the main page and output the result on the same page. We also add the reset button to return to the primary key structure.<br /> All the above changes are done in \view \tree_display\_page_header.html.erb <br /> <br /> ===Controller===<br /> We modify the existing list function in the tree_display_controller.rb as it is responsible for all the inputs on the tree display page. We also add a new function filter in the file which parses the input string given by the user and converts it into a meaningful string depending on what user wants to filter. Filter is called by list function and the string is placed into a global variable, so that future sort can make use of the previous search.<br /> <br /> ===Model===<br /> We have made changes to the following models to search/filter for the keyword in corresponding nodes.-<br /> <br /> questionnaire_node.rb<br /> <br /> assignment_node.rb<br /> <br /> course_node.rb<br /> <br /> node.rb<br /> <br /> folder_node.rb<br /> <br /> All the models have the same logic to parse the input search string and accordingly find the nodes in the model objects. The design is extensible and controller is left skinny which just does the parsing of input string and calls a generic model function. The summary is given below<br /> <br /> The view takes the string and passes to controller<br /> <br /> User -&gt; input string -&gt; Controller.<br /> <br /> <br /> Controller does the parsing and calls a generic function which iterates over folders.<br /> <br /> Controller -&gt; search string -&gt; Models(Iterator)<br /> <br /> Iterator -&gt; Controller -&gt; View(display)<br /> <br /> <br /> Model returns the required nodes and controller handles them to view. The code which has been put in all model objects is generic. The same code can be used with future nodes or new folders when they are added in future.<br /> <br /> The controller code remains generic and it only needs to include a new case which specifies the new filter. This way we can extend the same controller and model code later for future searches. By adding the code in this manner, we have introduced maximum cohesion as all search/filter functionality always uses the same code.</div>

Agoel2 https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/oss_paa&diff=80246 2013-10-29T03:37:44Z

<p>Agoel2: </p> <hr /> <div>'''Expertiza OSS Project –E809 (TreeDisplay)'''<br /> <br /> __TOC__<br /> == Introduction ==<br /> The problem statement is to include search/filter/sort using a collapsible tree view structure. The tree is composed of different folders namely Assignments, Courses, Questionnaires and their subfolder respectively.<br /> <br /> ==Existing Design==<br /> Currently the folders structure is displayed as a tree; the structure of the tree is as follows --<br /> <br /> : • Questionnaire<br /> <br /> :: o Review<br /> <br /> :: o Metareview<br /> <br /> :: o Author Feedback<br /> <br /> :: o Teammate Review<br /> <br /> :: o Survey<br /> <br /> :: o Global Survey<br /> <br /> :: o Course Evaluation<br /> <br /> : • Courses<br /> <br /> :: o Course<br /> <br /> :::  assignment<br /> <br /> : • Assignments<br /> <br /> <br /> The whole set of Courses, Assignments and Questionnaires are displayed on screen in a collapsible tree view upon login. Items may be expanded and collapsed. There is no functionality to search/filter results.<br /> The sort functionality has been provided which sorts the tree structure with important metrics such as creation date, name and directory in ascending as well as descending order. <br /> We also have the option to view either the public and private items or the private items only.<br /> <br /> <br /> ==Project Requirement==<br /> The tree display can be inefficient given many objects (courses, etc.). We are supposed to design the underlying structure at the model level to efficiently retrieve organized data. <br /> <br /> We are also required to redesign the view to enable users to filter/search and sort by important metrics such as creation date, name (alphabetical) and relationship (e.g. filter all assignments by a course). <br /> <br /> The interface should be kept modular in the code to increase extensibility for future metrics. We have to keep the controller as ‘skinny’ as possible, leaving the model to perform computational logic.<br /> <br /> <br /> ==Implementation==<br /> We have introduced two new features - search and filter.<br /> To implement the search/filter, we have decided to use the same tree display which is efficient and simple to show the current data.<br /> ===Search===<br /> This functionality searches for a keyword among 3 categories courses/assignment/questionnaire. It is implemented using substring search. All the entries whose substring matches with the search string are returned. Based on the input the user can view the filtered results in any of the 3 categories.<br /> ===Filter===<br /> There are 2 main relationships in the tree structure. These are as follows --<br /> <br /> : 1. A course can have many assignments.<br /> <br /> : 2. An assignment can have many questionnaires.<br /> <br /> ===Compatibility with existing features===<br /> We have implemented these 2 filters in the code. A user can search all assignments for a respective course, and also search for all questionnaires related to one assignment. We preserve the sort feature across the implementation which means that the user can sort the filtered results also. The user can also view the public and private items or the private items only for the filtered result.<br /> <br /> <br /> ==Design==<br /> ===View===<br /> Since the tree display is the best way to show the folder structure and to maximize code reuse, we choose the same display style for search results. We add search and filter boxes to input the search/filter keyword on the main page and output the result on the same page. We also add the reset button to return to the primary key structure.<br /> All the above changes are done in \view \tree_display\_page_header.html.erb <br /> <br /> ===Controller===<br /> We modify the existing list function in the tree_display_controller.rb as it is responsible for all the inputs on the tree display page. We also add a new function filter in the file which parses the input string given by the user and converts it into a meaningful string depending on what user wants to filter. Filter is called by list function and the string is placed into a global variable, so that future sort can make use of the previous search.<br /> <br /> ===Model===<br /> We have made changes to the following models to search/filter for the keyword in corresponding nodes.-<br /> <br /> questionnaire_node.rb<br /> <br /> assignment_node.rb<br /> <br /> course_node.rb<br /> <br /> node.rb<br /> <br /> folder_node.rb<br /> <br /> All the models have the same logic to parse the input search string and accordingly find the nodes in the model objects. The design is extensible and controller is left skinny which just does the parsing of input string and calls a generic model function. The summary is given below<br /> <br /> The view takes the string and passes to controller<br /> <br /> User -&gt; input string -&gt; Controller.<br /> <br /> <br /> Controller does the parsing and calls a generic function which iterates over folders.<br /> <br /> Controller -&gt; search string -&gt; Models(Iterator)<br /> <br /> Iterator -&gt; Controller -&gt; View(display)<br /> <br /> <br /> Model returns the required nodes and controller handles them to view. The code which has been put in all model objects is generic. The same code can be used with future nodes or new folders when they are added in future.<br /> <br /> The controller code remains generic and it only needs to include a new case which specifies the new filter. This way we can extend the same controller and model code later for future searches. By adding the code in this manner, we have introduced maximum cohesion as all search/filter functionality always uses the same code.</div>

Agoel2 https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/oss_paa&diff=80245 2013-10-29T03:29:36Z

<p>Agoel2: Created page with &quot;== '''Expertiza OSS Project –E809 (TreeDisplay)''' == __TOC__ == Introduction == The problem statement is to include search/filter/sort using a collapsible tree view structur...&quot;</p> <hr /> <div>== '''Expertiza OSS Project –E809 (TreeDisplay)''' ==<br /> <br /> __TOC__<br /> == Introduction ==<br /> The problem statement is to include search/filter/sort using a collapsible tree view structure. The tree is composed of different folders namely Assignments, Courses, Questionnaires and their subfolder respectively.<br /> <br /> ==Existing Design==<br /> Currently the folders structure is displayed as a tree; the structure of the tree is as follows --<br /> • Questionnaire<br /> o Review<br /> o Metareview<br /> o Author Feedback<br /> o Teammate Review<br /> o Survey<br /> o Global Survey<br /> o Course Evaluation<br /> • Courses<br /> o Course<br />  assignment<br /> • Assignments<br /> <br /> The whole set of Courses, Assignments and Questionnaires are displayed on screen in a collapsible tree view upon login. Items may be expanded and collapsed. There is no functionality to search/filter results.<br /> The sort functionality has been provided which sorts the tree structure with important metrics such as creation date, name and directory in ascending as well as descending order. <br /> We also have the option to view either the public and private items or the private items only.<br /> <br /> ==Project Requirement==<br /> The tree display can be inefficient given many objects (courses, etc.). We are supposed to design the underlying structure at the model level to efficiently retrieve organized data. <br /> We are also required to redesign the view to enable users to filter/search and sort by important metrics such as creation date, name (alphabetical) and relationship (e.g. filter all assignments by a course). <br /> The interface should be kept modular in the code to increase extensibility for future metrics. We have to keep the controller as ‘skinny’ as possible, leaving the model to perform computational logic.<br /> <br /> ==Implementation==<br /> We have introduced two new features - search and filter.<br /> To implement the search/filter, we have decided to use the same tree display which is efficient and simple to show the current data.<br /> ===Search===<br /> This functionality searches for a keyword among 3 categories courses/assignment/questionnaire. It is implemented using substring search. All the entries whose substring matches with the search string are returned. Based on the input the user can view the filtered results in any of the 3 categories.<br /> ===Filter===<br /> There are 2 main relationships in the tree structure. These are as follows --<br /> 1. A course can have many assignments.<br /> 2. An assignment can have many questionnaires.<br /> ===Compatibility with existing features===<br /> We have implemented these 2 filters in the code. A user can search all assignments for a respective course, and also search for all questionnaires related to one assignment. We preserve the sort feature across the implementation which means that the user can sort the filtered results also. The user can also view the public and private items or the private items only for the filtered result.<br /> <br /> ==Design==<br /> ===View===<br /> Since the tree display is the best way to show the folder structure and to maximize code reuse, we choose the same display style for search results. We add search and filter boxes to input the search/filter keyword on the main page and output the result on the same page. We also add the reset button to return to the primary key structure.<br /> All the above changes are done in \view \tree_display\_page_header.html.erb <br /> <br /> ===Controller===<br /> We modify the existing list function in the tree_display_controller.rb as it is responsible for all the inputs on the tree display page. We also add a new function filter in the file which parses the input string given by the user and converts it into a meaningful string depending on what user wants to filter. Filter is called by list function and the string is placed into a global variable, so that future sort can make use of the previous search.<br /> <br /> ===Model===<br /> We have made changes to the following models to search/filter for the keyword in corresponding nodes.-<br /> questionnaire_node.rb<br /> assignment_node.rb<br /> course_node.rb<br /> node.rb<br /> folder_node.rb<br /> All the models have the same logic to parse the input search string and accordingly find the nodes in the model objects. The design is extensible and controller is left skinny which just does the parsing of input string and calls a generic model function. The summary is given below<br /> The view takes the string and passes to controller<br /> User  input string  Controller.<br /> Controller does the parsing and calls a generic function which iterates over folders.<br /> Controller  search string  Models(Iterator)<br /> Iterator  Controller  View(display)<br /> Model returns the required nodes and controller handles them to view. The code which has been put in all model objects is generic. The same code can be used with future nodes or new folders when they are added in future.<br /> The controller code remains generic and it only needs to include a new case which specifies the new filter. This way we can extend the same controller and model code later for future searches. By adding the code in this manner, we have introduced maximum cohesion as all search/filter functionality always uses the same code.</div>

Agoel2 https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013&diff=80244 2013-10-29T03:20:45Z

<p>Agoel2: </p> <hr /> <div>* [[ CSC/ECE 517 Fall 2012/ch1 1w23 ph ]]<br /> * [[ CSC/ECE 517 Fall 2013/ch1 1w30 nn]]<br /> * [[ CSC/ECE 517 Fall 2013/ch1 1w21 w]]<br /> * [[ CSC/ECE 517 Fall 2013/ch1 1w01 aj]]<br /> * [[ CSC/ECE 517 Fall 2013/ch1 1w24 nv]]<br /> * [[ CSC/ECE 517 Fall 2013/ch1 1w29 rkld]]<br /> * [[ CSC/ECE 517 Fall 2013/ch1 1w25 aras]]<br /> * [[ CSC/ECE 517 Fall 2013/ch1 1w30 ps]]<br /> * [[ CSC/ECE 517 Fall 2013/ch1 1w19 rj]]<br /> * [[ CSC/ECE 517 Fall 2013/ch1 1w18 bs]]<br /> * [[ CSC/ECE 517 Fall 2013/ch1 1w17 pk]]<br /> * [[ CSC/ECE 517 Fall 2013/ch1 1w22 ss]]<br /> * [[ CSC/ECE 517 Fall 2013/ch1 1w12 vn]]<br /> * [[ CSC/ECE 517 Fall 2013/ch1 1w14 st]]<br /> * [[ CSC/ECE 517 Fall 2013/ch1 1w08 cc]]<br /> * [[ CSC/ECE 517 Fall 2013/ch1 1w10 ga ]]<br /> * [[ CSC/ECE 517 Fall 2013/ch1 1w26 as ]]<br /> * [[ CSC/ECE 517 Fall 2013/ch1 1w27 ma ]]<br /> * [[ CSC/ECE 517 Fall 2013/ch1 1w13 aa ]]<br /> * [[ CSC/ECE 517 Fall 2013/ch1 1w11 sv ]]<br /> * [[ CSC/ECE 517 Fall 2013/ch1 1w07 d ]]<br /> * [[ CSC/ECE 517 Fall 2013/ch1 1w20 gq ]]<br /> * [[ CSC/ECE 517 Fall 2013/ch1 1w03 ss ]]<br /> * [[ CSC/ECE 517 Fall 2013/ch1 1w28 nm ]]<br /> * [[ CSC/ECE 517 Fall 2013/ch1 1w02 pp ]]<br /> * [[ CSC/ECE 517 Fall 2013/ch1 1w6 zs ]]<br /> * [[ CSC/ECE 517 Fall 2013/ch1 1w04 y ]]<br /> * [[ CSC/ECE 517 Fall 2013/ch1 1w05 st ]]<br /> * [[ CSC/ECE 517 Fall 2013/ch1 1w09 hs ]]<br /> * [[ CSC/ECE 517 Fall 2013/ch1 1w32 av ]]<br /> * [[ CSC/ECE 517 Fall 2013/ch1 1w48 x ]]<br /> * [[ CSC/ECE 517 Fall 2013/ch1 1w43 av]]<br /> * [[ CSC/ECE 517 Fall 2013/ch1 1w46 ka]]<br /> * [[ CSC/ECE 517 Fall 2013/ch1 1w33 aa]]<br /> * [[ CSC/ECE 517 Fall 2013/ch1 1w35 sa ]]<br /> * [[ CSC/ECE 517 Fall 2013/ch1 1w39 as ]]<br /> * [[ CSC/ECE 517 Fall 2013/ch1 1w31 vm ]]<br /> * [[ CSC/ECE 517 Fall 2013/ch1 1w43 sm ]]<br /> * [[ CSC/ECE 517 Fall 2013/ch1 1w44 s ]]<br /> * [[ CSC/ECE 517 Fall 2013/ch1 1w47 ka ]]<br /> * [[ CSC/ECE 517 Fall 2013/ch1 1w34 fs ]]<br /> * [[ CSC/ECE 517 Fall 2013/ch1 1w40 ao ]]<br /> * [[ CSC/ECE 517 Fall 2013/oss fmv ]]<br /> * [[ CSC/ECE 517 Fall 2013/oss vna ]]<br /> * [[ CSC/ECE 517 Fall 2013/oss paa ]]</div>

Agoel2 https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/ch1_1w33_aa&diff=79948 2013-10-08T00:55:47Z

<p>Agoel2: </p> <hr /> <div>== '''Behavior Driven Development in Ruby on Rails''' ==<br /> <br /> Behavior-driven development (also known as BDD) is an [http://en.wikipedia.org/wiki/Agile_software_development Agile] development strategy that has been derived from [http://en.wikipedia.org/wiki/Test-driven_development Test Driven Development](also known as TDD). It was developed by [http://dannorth.net/ Dan North] in order to address the problems faced by TDD. <br /> <br /> <br /> __TOC__<br /> == Introduction ==<br /> <br /> Behavior Driven Development approach focuses on design, documentation and behavior rather than on tests. This approach enables more interactions between the client and the developer. The client specifies his functional specifications to the developer by writing [http://en.wikipedia.org/wiki/User_story user stories] which describe how the system should perform when a certain condition is met. These user stories are then translated into tests using tools like RSpec and Cucumber. These tests are then run to check whether they satisfy the desired functional behavior. The business requirement is delivered when all the tests pass.<br /> <br /> [[File:img_bdd.jpg]]<br /> <br /> '''Figure-1. Steps for BDD&lt;ref&gt;http://msdn.microsoft.com/en-us/magazine/gg490346.aspx&lt;/ref&gt;'''<br /> <br /> <br /> == Difference from other development strategies ==<br /> === Test-driven development (TDD) ===<br /> Another type of Test Driven Development is Behavior-driven development (also known as TDD). In TDD, software developers write automated test cases before they write any code.<br /> : • The first step of TDD is to write a failing test for a particular unit of functionality to be added. <br /> <br /> : • The next step is to write a piece of code only to pass that failing test.<br /> <br /> : • The last step would be to refactor the code so that it meets the requirement standards of the code.<br /> <br /> [[File:Steps.jpg]]<br /> <br /> '''Figure-2. Steps for TDD'''<br /> <br /> <br /> Test Driven Development follows three rules.&lt;ref&gt;http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd&lt;/ref&gt; They are:<br /> <br /> : • One must not write any production code unless it is to make a failing unit test pass.<br /> <br /> : • One must not write any more of a unit test than is sufficient to fail<br /> <br /> : • One must not write any more production code than is sufficient to pass the one failing unit test.<br /> <br /> === Difference between TDD and BDD &lt;ref&gt;http://stackoverflow.com/questions/2509/what-are-the-primary-differences-between-tdd-and-bdd&lt;/ref&gt; ===<br /> : • TDD’s main focus is on the tests while BDD mainly focuses on the behavioral specification from the user point of view. <br /> <br /> : • With TDD, unit tests are written, whereas for BDD tests are written using “User Stories”.<br /> <br /> : • TDD uses language which is intelligible to only the software programmers.<br /> <br /> : • BDD uses language which is more easily understood by technical as well as non technical people.<br /> <br /> For example, to define a class named Student, TDD will create StudentTest class containing required tests, whereas BDD will create StudentBehaviour class which will contain example methods to define the behaviour of Student class.<br /> <br /> == Advantages of BDD &lt;ref&gt;http://www.slideshare.net/IosifItkin/behavior-driven-development-pros-and-cons&lt;/ref&gt;==<br /> : • Due to BDD language being comprehensible by both technical as well as domain experts, the BDD involves the customers and the business partners in writing the scenarios for the tests.<br /> <br /> : • Unlike tests which come after implementation, focusing on the behavior proves to be a better approach.<br /> <br /> : • TDD methodology can lead to a number of failed tests before arriving at the correct result because it focuses mainly on implementation. But BDD does not require so many tests as its main focus is behavior thus resulting in less code.<br /> <br /> == Disadvantages of BDD ==<br /> : • The user stories written by the customers might not be good quality and may have to be rewritten by the developer.<br /> <br /> : • The customer might not have enough time to review the scenarios on a regular basis.<br /> <br /> == Examples of BDD with Ruby on Rails &lt;ref&gt;http://www.ryangreenhall.com/articles/bdd-by-example.html&lt;/ref&gt;==<br /> In BDD, business requirements are identified by user stories. The user stories are described using the following format<br /> <br /> '''As a ''' [role]<br /> '''I can '''[feature] <br /> '''so that '''[reason]<br /> <br /> Example to explain this-<br /> <br /> ''' As a Bank account holder '''<br /> ''' I can login with my credentials '''<br /> ''' so that I can check my account details '''<br /> <br /> <br /> Once the user stories are written, the acceptance tests can be written for the user stories. The acceptance tests have the following format<br /> <br /> ''' Given '''[Context]<br /> ''' When ''' [Event Occurs]<br /> ''' Then ''' [Outcome]<br /> <br /> <br /> Scenario: Enter a Login Page<br /> <br /> ''' Given I enter a valid username '''<br /> ''' And I enter a valid password '''<br /> ''' When I press the Login Button '''<br /> ''' Then I should be redirected to the home page '''<br /> <br /> These acceptance tests for the user stories are entered in the application as automated tests by the developer. <br /> <br /> == Implementation ==<br /> Ruby on Rails uses various tools like Cucumber, Rspec etc to implement the user tests using Behaviour-driven development.<br /> <br /> === Cucumber &lt;ref&gt;http://cukes.info/&lt;/ref&gt;===<br /> BDD makes the use of Cucumber for running automated acceptance tests. Cucumber specifies what a user should see and be able to do. Cucumber works with Ruby to help the software development teams describe how an application should behave. Cucumber is intelligible to both software developers as well as domain experts. It can serve both as documentation and automated tests.<br /> <br /> <br /> [[File:img_cucumber.jpg]]<br /> <br /> '''Figure-3. Use of Cucumber&lt;ref&gt;http://infowarestudios.co.za/agile-testing-getting-agile-tests-incorporated-into-your-sprints-using-bdd-and-cucumber-in-c/&lt;/ref&gt;'''<br /> <br /> === RSpec ===<br /> RSpec mainly deals with unit tests which mean testing a class method in isolation from the rest of the application. So it guarantees that the model does what it is supposed to do, the controller does what it is supposed to do, etc. It explains the behavior of objects at the code level. It provides a simple and elegant syntax and works effectively with some other frameworks like [http://rubyonrails.org/ Rails] and [http://mocha.rubyforge.org/ Mocha] library.<br /> <br /> [[File:img_rspec.jpg]]<br /> <br /> '''Figure-4. Use of RSpec&lt;ref&gt;http://i.stack.imgur.com/&lt;/ref&gt;'''<br /> <br /> === RBehave &lt;ref&gt;http://dannorth.net/2007/06/17/introducing-rbehave/&lt;/ref&gt;===<br /> RBehave is a framework based on the story framework from [http://jbehave.org JBehave] which describes behaviour at the application level. It is simpler than RSpec and eliminates the need to reuse code. The choice of frameworks depend on the level of [http://en.wikipedia.org/wiki/Granularity granularity]. RBehave and RSpec are often used as a combination to simplify BDD wordings.<br /> <br /> <br /> == See also ==<br /> <br /> :1. [http://en.wikipedia.org/wiki/Behavior-driven_development Behavior-driven development]<br /> <br /> :2. [http://en.wikipedia.org/wiki/Test-driven_development Test-driven development]<br /> <br /> :3. [http://en.wikipedia.org/wiki/Cucumber_(software) Cucumber]<br /> <br /> :4. [http://en.wikipedia.org/wiki/RSpec RSpec]<br /> <br /> == References ==<br /> <br /> &lt;references /&gt;<br /> <br /> == External links ==<br /> <br /> :1. [http://www.slideshare.net/MarkMenard/behavior-driven-development-with-rails Behavior driven development with Rails]<br /> <br /> :2. [http://rorataspire.wordpress.com/2008/06/16/behaviour-driven-development-have-a-definite-edge-in-the-outsourced-software-development/ Lifecycle]<br /> <br /> :3. [http://codesqueeze.com/the-easy-way-to-writing-good-user-stories/ Writing user stories]<br /> <br /> :4. [http://bob-roberts.net/2012/02/17/608/ Using Rspec and Capybara]<br /> <br /> :5. [http://stackoverflow.com/questions/11762245/whats-the-difference-between-rspec-and-cucumber Difference between RSpec and Cucumber]</div>

Agoel2 https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/ch1_1w33_aa&diff=79947 2013-10-08T00:53:16Z

<p>Agoel2: </p> <hr /> <div>== '''Behavior Driven Development in Ruby on Rails''' ==<br /> <br /> Behavior-driven development (also known as BDD) is an [http://en.wikipedia.org/wiki/Agile_software_development Agile] development strategy that has been derived from [http://en.wikipedia.org/wiki/Test-driven_development Test Driven Development](also known as TDD). It was developed by [http://dannorth.net/ Dan North] in order to address the problems faced by TDD. <br /> <br /> <br /> __TOC__<br /> == Introduction ==<br /> <br /> Behavior Driven Development approach focuses on design, documentation and behavior rather than on tests. This approach enables more interactions between the client and the developer. The client specifies his functional specifications to the developer by writing [http://en.wikipedia.org/wiki/User_story user stories] which describe how the system should perform when a certain condition is met. These user stories are then translated into tests using tools like RSpec and Cucumber. These tests are then run to check whether they satisfy the desired functional behavior. The business requirement is delivered when all the tests pass.<br /> <br /> [[File:img_bdd.jpg]]<br /> <br /> '''Figure-1. Steps for BDD&lt;ref&gt;http://msdn.microsoft.com/en-us/magazine/gg490346.aspx&lt;/ref&gt;'''<br /> <br /> <br /> == Difference from other development strategies ==<br /> === Test-driven development (TDD) ===<br /> Another type of Test Driven Development is Behavior-driven development (also known as TDD). In TDD, software developers write automated test cases before they write any code.<br /> : • The first step of TDD is to write a failing test for a particular unit of functionality to be added. <br /> <br /> : • The next step is to write a piece of code only to pass that failing test.<br /> <br /> : • The last step would be to refactor the code so that it meets the requirement standards of the code.<br /> <br /> [[File:Steps.jpg]]<br /> <br /> '''Figure-2. Steps for TDD'''<br /> <br /> <br /> Test Driven Development follows three rules.&lt;ref&gt;http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd&lt;/ref&gt; They are:<br /> <br /> : • One must not write any production code unless it is to make a failing unit test pass.<br /> <br /> : • One must not write any more of a unit test than is sufficient to fail<br /> <br /> : • One must not write any more production code than is sufficient to pass the one failing unit test.<br /> <br /> === Difference between TDD and BDD &lt;ref&gt;http://stackoverflow.com/questions/2509/what-are-the-primary-differences-between-tdd-and-bdd&lt;/ref&gt; ===<br /> : • TDD’s main focus is on the tests while BDD mainly focuses on the behavioral specification from the user point of view. <br /> <br /> : • With TDD, unit tests are written, whereas for BDD tests are written using “User Stories”.<br /> <br /> : • TDD uses language which is intelligible to only the software programmers.<br /> <br /> : • BDD uses language which is more easily understood by technical as well as non technical people.<br /> <br /> For example, to define a class named Student, TDD will create StudentTest class containing required tests, whereas BDD will create StudentBehaviour class which will contain example methods to define the behaviour of Student class.<br /> <br /> == Advantages of BDD &lt;ref&gt;http://www.slideshare.net/IosifItkin/behavior-driven-development-pros-and-cons&lt;/ref&gt;==<br /> : • Due to BDD language being comprehensible by both technical as well as domain experts, the BDD involves the customers and the business partners in writing the scenarios for the tests.<br /> <br /> : • Unlike tests which come after implementation, focusing on the behavior proves to be a better approach.<br /> <br /> : • TDD methodology can lead to a number of failed tests before arriving at the correct result because it focuses mainly on implementation. But BDD does not require so many tests as its main focus is behavior thus resulting in less code.<br /> <br /> == Disadvantages of BDD ==<br /> : • The user stories written by the customers might not be good quality and may have to be rewritten by the developer.<br /> <br /> : • The customer might not have enough time to review the scenarios on a regular basis.<br /> <br /> == Examples of BDD with Ruby on Rails &lt;ref&gt;http://www.ryangreenhall.com/articles/bdd-by-example.html&lt;/ref&gt;==<br /> In BDD, business requirements are identified by user stories. The user stories are described using the following format<br /> <br /> '''As a ''' [role]<br /> '''I can '''[feature] <br /> '''so that '''[reason]<br /> <br /> Example to explain this-<br /> <br /> ''' As a Bank account holder '''<br /> ''' I can login with my credentials '''<br /> ''' so that I can check my account details '''<br /> <br /> <br /> Once the user stories are written, the acceptance tests can be written for the user stories. The acceptance tests have the following format<br /> <br /> ''' Given '''[Context]<br /> ''' When ''' [Event Occurs]<br /> ''' Then ''' [Outcome]<br /> <br /> <br /> Scenario: Enter a Login Page<br /> <br /> ''' Given I enter a valid username '''<br /> ''' And I enter a valid password '''<br /> ''' When I press the Login Button '''<br /> ''' Then I should be redirected to the home page '''<br /> <br /> These acceptance tests for the user stories are entered in the application as automated tests by the developer. <br /> <br /> == Implementation ==<br /> Ruby on Rails uses various tools like Cucumber, Rspec etc to implement the user tests using Behaviour-driven development.<br /> <br /> === Cucumber &lt;ref&gt;http://cukes.info/&lt;/ref&gt;===<br /> BDD makes the use of Cucumber for running automated acceptance tests. Cucumber specifies what a user should see and be able to do. Cucumber works with Ruby to help the software development teams describe how an application should behave. Cucumber is intelligible to both software developers as well as domain experts. It can serve both as documentation and automated tests.<br /> <br /> <br /> [[File:img_cucumber.jpg]]<br /> <br /> '''Figure-3. Use of Cucumber&lt;ref&gt;http://infowarestudios.co.za/agile-testing-getting-agile-tests-incorporated-into-your-sprints-using-bdd-and-cucumber-in-c/&lt;/ref&gt;'''<br /> <br /> === RSpec ===<br /> RSpec mainly deals with unit tests which mean testing a class method in isolation from the rest of the application. So it guarantees that the model does what it is supposed to do, the controller does what it is supposed to do, etc. It explains the behavior of objects at the code level. It provides a simple and elegant syntax and works effectively with some other frameworks like [http://rubyonrails.org/ Rails] and [http://mocha.rubyforge.org/ Mocha] library.<br /> <br /> [[File:img_rspec.jpg]]<br /> <br /> '''Figure-4. Use of RSpec&lt;ref&gt;http://i.stack.imgur.com/&lt;/ref&gt;'''<br /> <br /> === RBehave &lt;ref&gt;http://dannorth.net/2007/06/17/introducing-rbehave/&lt;/ref&gt;===<br /> RBehave is a framework based on the story framework from [http://jbehave.org JBehave] which describes behaviour at the application level. It is simpler than RSpec and eliminates the need to reuse code. The choice of frameworks depend on the level of [http://en.wikipedia.org/wiki/Granularity granularity]. RBehave and RSpec are often used as a combination to simplify BDD wordings.<br /> <br /> <br /> == See also ==<br /> <br /> :1. [http://en.wikipedia.org/wiki/Behavior-driven_development Behavior-driven development]<br /> <br /> :2. [http://en.wikipedia.org/wiki/Test-driven_development Test-driven development]<br /> <br /> :3. [http://en.wikipedia.org/wiki/Cucumber_(software) Cucumber]<br /> <br /> :4. [http://en.wikipedia.org/wiki/RSpec RSpec]<br /> <br /> :5. [http://www.slideshare.net/MarkMenard/behavior-driven-development-with-rails Behavior driven development with Rails]<br /> <br /> :6. [http://rorataspire.wordpress.com/2008/06/16/behaviour-driven-development-have-a-definite-edge-in-the-outsourced-software-development/ Lifecycle]<br /> <br /> :7. [http://codesqueeze.com/the-easy-way-to-writing-good-user-stories/ Writing user stories]<br /> <br /> :8. [http://bob-roberts.net/2012/02/17/608/ Using Rspec and Capybara]<br /> <br /> :9. [http://stackoverflow.com/questions/11762245/whats-the-difference-between-rspec-and-cucumber Difference between RSpec and Cucumber]<br /> <br /> == References ==<br /> <br /> &lt;references /&gt;</div>

Agoel2 https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/ch1_1w33_aa&diff=79945 2013-10-08T00:49:08Z

<p>Agoel2: </p> <hr /> <div>== '''Behavior Driven Development in Ruby on Rails''' ==<br /> <br /> Behavior-driven development (also known as BDD) is an [http://en.wikipedia.org/wiki/Agile_software_development Agile] development strategy that has been derived from [http://en.wikipedia.org/wiki/Test-driven_development Test Driven Development](also known as TDD). It was developed by [http://dannorth.net/ Dan North] in order to address the problems faced by TDD. <br /> <br /> <br /> __TOC__<br /> == Introduction ==<br /> <br /> Behavior Driven Development approach focuses on design, documentation and behavior rather than on tests. This approach enables more interactions between the client and the developer. The client specifies his functional specifications to the developer by writing [http://en.wikipedia.org/wiki/User_story user stories] which describe how the system should perform when a certain condition is met. These user stories are then translated into tests using tools like RSpec and Cucumber. These tests are then run to check whether they satisfy the desired functional behavior. The business requirement is delivered when all the tests pass.<br /> <br /> [[File:img_bdd.jpg]]<br /> <br /> '''Figure-1. Steps for BDD&lt;ref&gt;http://msdn.microsoft.com/en-us/magazine/gg490346.aspx&lt;/ref&gt;'''<br /> <br /> <br /> == Difference from other development strategies ==<br /> === Test-driven development (TDD) ===<br /> Another type of Test Driven Development is Behavior-driven development (also known as TDD). In TDD, software developers write automated test cases before they write any code.<br /> : • The first step of TDD is to write a failing test for a particular unit of functionality to be added. <br /> <br /> : • The next step is to write a piece of code only to pass that failing test.<br /> <br /> : • The last step would be to refactor the code so that it meets the requirement standards of the code.<br /> <br /> [[File:Steps.jpg]]<br /> <br /> '''Figure-2. Steps for TDD'''<br /> <br /> <br /> Test Driven Development follows three rules.&lt;ref&gt;http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd&lt;/ref&gt; They are:<br /> <br /> : • One must not write any production code unless it is to make a failing unit test pass.<br /> <br /> : • One must not write any more of a unit test than is sufficient to fail<br /> <br /> : • One must not write any more production code than is sufficient to pass the one failing unit test.<br /> <br /> <br /> === Difference between TDD and BDD &lt;ref&gt;http://stackoverflow.com/questions/2509/what-are-the-primary-differences-between-tdd-and-bdd&lt;/ref&gt; ===<br /> : • TDD’s main focus is on the tests while BDD mainly focuses on the behavioral specification from the user point of view. <br /> <br /> : • With TDD, unit tests are written, whereas for BDD tests are written using “User Stories”.<br /> <br /> : • TDD uses language which is intelligible to only the software programmers.<br /> <br /> : • BDD uses language which is more easily understood by technical as well as non technical people.<br /> <br /> For example, to define a class named Student, TDD will create StudentTest class containing required tests, whereas BDD will create StudentBehaviour class which will contain example methods to define the behaviour of Student class.<br /> <br /> == Advantages of BDD &lt;ref&gt;http://www.slideshare.net/IosifItkin/behavior-driven-development-pros-and-cons&lt;/ref&gt;==<br /> : • Due to BDD language being comprehensible by both technical as well as domain experts, the BDD involves the customers and the business partners in writing the scenarios for the tests.<br /> <br /> : • Unlike tests which come after implementation, focusing on the behavior proves to be a better approach.<br /> <br /> : • TDD methodology can lead to a number of failed tests before arriving at the correct result because it focuses mainly on implementation. But BDD does not require so many tests as its main focus is behavior thus resulting in less code.<br /> <br /> == Disadvantages of BDD ==<br /> : • The user stories written by the customers might not be good quality and may have to be rewritten by the developer.<br /> <br /> : • The customer might not have enough time to review the scenarios on a regular basis.<br /> <br /> <br /> == Examples of BDD with Ruby on Rails &lt;ref&gt;http://www.ryangreenhall.com/articles/bdd-by-example.html&lt;/ref&gt;==<br /> In BDD, business requirements are identified by user stories. The user stories are described using the following format<br /> <br /> '''As a ''' [role]<br /> '''I can '''[feature] <br /> '''so that '''[reason]<br /> <br /> Example to explain this-<br /> <br /> ''' As a Bank account holder '''<br /> ''' I can login with my credentials '''<br /> ''' so that I can check my account details '''<br /> <br /> <br /> Once the user stories are written, the acceptance tests can be written for the user stories. The acceptance tests have the following format<br /> <br /> ''' Given '''[Context]<br /> ''' When ''' [Event Occurs]<br /> ''' Then ''' [Outcome]<br /> <br /> <br /> Scenario: Enter a Login Page<br /> <br /> ''' Given I enter a valid username '''<br /> ''' And I enter a valid password '''<br /> ''' When I press the Login Button '''<br /> ''' Then I should be redirected to the home page '''<br /> <br /> These acceptance tests for the user stories are entered in the application as automated tests by the developer. <br /> <br /> <br /> == Implementation ==<br /> Ruby on Rails uses various tools like Cucumber, Rspec etc to implement the user tests using Behaviour-driven development.<br /> <br /> === Cucumber &lt;ref&gt;http://cukes.info/&lt;/ref&gt;===<br /> BDD makes the use of Cucumber for running automated acceptance tests. Cucumber specifies what a user should see and be able to do. Cucumber works with Ruby to help the software development teams describe how an application should behave. Cucumber is intelligible to both software developers as well as domain experts. It can serve both as documentation and automated tests.<br /> <br /> <br /> [[File:img_cucumber.jpg]]<br /> <br /> '''Figure-3. Use of Cucumber&lt;ref&gt;http://infowarestudios.co.za/agile-testing-getting-agile-tests-incorporated-into-your-sprints-using-bdd-and-cucumber-in-c/&lt;/ref&gt;'''<br /> <br /> === RSpec ===<br /> RSpec mainly deals with unit tests which mean testing a class method in isolation from the rest of the application. So it guarantees that the model does what it is supposed to do, the controller does what it is supposed to do, etc. It explains the behavior of objects at the code level. It provides a simple and elegant syntax and works effectively with some other frameworks like [http://rubyonrails.org/ Rails] and [http://mocha.rubyforge.org/ Mocha] library.<br /> <br /> [[File:img_rspec.jpg]]<br /> <br /> '''Figure-4. Use of RSpec&lt;ref&gt;http://i.stack.imgur.com/&lt;/ref&gt;'''<br /> <br /> === RBehave &lt;ref&gt;http://dannorth.net/2007/06/17/introducing-rbehave/&lt;/ref&gt;===<br /> RBehave is a framework based on the story framework from [http://jbehave.org JBehave] which describes behaviour at the application level. It is simpler than RSpec and eliminates the need to reuse code. The choice of frameworks depend on the level of [http://en.wikipedia.org/wiki/Granularity granularity]. RBehave and RSpec are often used as a combination to simplify BDD wordings.<br /> <br /> <br /> == See also ==<br /> <br /> 1. [http://en.wikipedia.org/wiki/Behavior-driven_development Behavior-driven development]<br /> <br /> 2. [http://en.wikipedia.org/wiki/Test-driven_development Test-driven development]<br /> <br /> 3. [http://en.wikipedia.org/wiki/Cucumber_(software) Cucumber]<br /> <br /> 4. [http://www.slideshare.net/MarkMenard/behavior-driven-development-with-rails Behavior driven development with Rails]<br /> <br /> 5. [http://rorataspire.wordpress.com/2008/06/16/behaviour-driven-development-have-a-definite-edge-in-the-outsourced-software-development/ Lifecycle]<br /> <br /> 6. [http://codesqueeze.com/the-easy-way-to-writing-good-user-stories/ Writing user stories]<br /> <br /> 7. [http://bob-roberts.net/2012/02/17/608/ Using Rspec and Capybara]<br /> <br /> 8. [http://stackoverflow.com/questions/11762245/whats-the-difference-between-rspec-and-cucumber Difference between RSpec and Cucumber]<br /> <br /> == References ==<br /> <br /> &lt;references /&gt;</div>

Agoel2 https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/ch1_1w33_aa&diff=79942 2013-10-08T00:46:34Z

<p>Agoel2: </p> <hr /> <div>== '''Behavior Driven Development in Ruby on Rails''' ==<br /> <br /> Behavior-driven development (also known as BDD) is an [http://en.wikipedia.org/wiki/Agile_software_development Agile] development strategy that has been derived from [http://en.wikipedia.org/wiki/Test-driven_development Test Driven Development](also known as TDD). It was developed by [http://dannorth.net/ Dan North] in order to address the problems faced by TDD. <br /> <br /> <br /> __TOC__<br /> == Introduction ==<br /> <br /> Behavior Driven Development approach focuses on design, documentation and behavior rather than on tests. This approach enables more interactions between the client and the developer. The client specifies his functional specifications to the developer by writing [http://en.wikipedia.org/wiki/User_story user stories] which describe how the system should perform when a certain condition is met. These user stories are then translated into tests using tools like RSpec and Cucumber. These tests are then run to check whether they satisfy the desired functional behavior. The business requirement is delivered when all the tests pass.<br /> <br /> [[File:img_bdd.jpg]]<br /> <br /> '''Figure-1. Steps for BDD&lt;ref&gt;http://msdn.microsoft.com/en-us/magazine/gg490346.aspx&lt;/ref&gt;'''<br /> <br /> <br /> == Difference from other development strategies ==<br /> === Test-driven development (TDD) ===<br /> Another type of Test Driven Development is Behavior-driven development (also known as TDD). In TDD, software developers write automated test cases before they write any code.<br /> : • The first step of TDD is to write a failing test for a particular unit of functionality to be added. <br /> <br /> : • The next step is to write a piece of code only to pass that failing test.<br /> <br /> : • The last step would be to refactor the code so that it meets the requirement standards of the code.<br /> <br /> [[File:Steps.jpg]]<br /> <br /> '''Figure-2. Steps for TDD'''<br /> <br /> <br /> Test Driven Development follows three rules.&lt;ref&gt;http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd&lt;/ref&gt; They are:<br /> <br /> : • One must not write any production code unless it is to make a failing unit test pass.<br /> <br /> : • One must not write any more of a unit test than is sufficient to fail<br /> <br /> : • One must not write any more production code than is sufficient to pass the one failing unit test.<br /> <br /> <br /> === Difference between TDD and BDD &lt;ref&gt;http://stackoverflow.com/questions/2509/what-are-the-primary-differences-between-tdd-and-bdd&lt;/ref&gt; ===<br /> : • TDD’s main focus is on the tests while BDD mainly focuses on the behavioral specification from the user point of view. <br /> <br /> : • With TDD, unit tests are written, whereas for BDD tests are written using “User Stories”.<br /> <br /> : • TDD uses language which is intelligible to only the software programmers.<br /> <br /> : • BDD uses language which is more easily understood by technical as well as non technical people.<br /> <br /> For example, to define a class named Student, TDD will create StudentTest class containing required tests, whereas BDD will create StudentBehaviour class which will contain example methods to define the behaviour of Student class.<br /> <br /> == Advantages of BDD &lt;ref&gt;http://www.slideshare.net/IosifItkin/behavior-driven-development-pros-and-cons&lt;/ref&gt;==<br /> : • Due to BDD language being comprehensible by both technical as well as domain experts, the BDD involves the customers and the business partners in writing the scenarios for the tests.<br /> <br /> : • Unlike tests which come after implementation, focusing on the behavior proves to be a better approach.<br /> <br /> : • TDD methodology can lead to a number of failed tests before arriving at the correct result because it focuses mainly on implementation. But BDD does not require so many tests as its main focus is behavior thus resulting in less code.<br /> <br /> == Disadvantages of BDD ==<br /> : • The user stories written by the customers might not be good quality and may have to be rewritten by the developer.<br /> <br /> : • The customer might not have enough time to review the scenarios on a regular basis.<br /> <br /> <br /> == Examples of BDD with Ruby on Rails &lt;ref&gt;http://www.ryangreenhall.com/articles/bdd-by-example.html&lt;/ref&gt;==<br /> In BDD, business requirements are identified by user stories. The user stories are described using the following format<br /> <br /> '''As a ''' [role]<br /> '''I can '''[feature] <br /> '''so that '''[reason]<br /> <br /> Example to explain this-<br /> <br /> ''' As a Bank account holder '''<br /> ''' I can login with my credentials '''<br /> ''' so that I can check my account details '''<br /> <br /> <br /> Once the user stories are written, the acceptance tests can be written for the user stories. The acceptance tests have the following format<br /> <br /> ''' Given '''[Context]<br /> ''' When ''' [Event Occurs]<br /> ''' Then ''' [Outcome]<br /> <br /> <br /> Scenario: Enter a Login Page<br /> <br /> ''' Given I enter a valid username '''<br /> ''' And I enter a valid password '''<br /> ''' When I press the Login Button '''<br /> ''' Then I should be redirected to the home page '''<br /> <br /> These acceptance tests for the user stories are entered in the application as automated tests by the developer. <br /> <br /> <br /> == Implementation ==<br /> Ruby on Rails uses various tools like Cucumber, Rspec etc to implement the user tests using Behaviour-driven development.<br /> <br /> === Cucumber &lt;ref&gt;http://cukes.info/&lt;/ref&gt;===<br /> BDD makes the use of Cucumber for running automated acceptance tests. Cucumber specifies what a user should see and be able to do. Cucumber works with Ruby to help the software development teams describe how an application should behave. Cucumber is intelligible to both software developers as well as domain experts. It can serve both as documentation and automated tests.<br /> <br /> <br /> [[File:img_cucumber.jpg]]<br /> <br /> '''Figure-3. Use of Cucumber&lt;ref&gt;http://infowarestudios.co.za/agile-testing-getting-agile-tests-incorporated-into-your-sprints-using-bdd-and-cucumber-in-c/&lt;/ref&gt;'''<br /> <br /> === RSpec ===<br /> RSpec mainly deals with unit tests which mean testing a class method in isolation from the rest of the application. So it guarantees that the model does what it is supposed to do, the controller does what it is supposed to do, etc. It explains the behavior of objects at the code level. It provides a simple and elegant syntax and works effectively with some other frameworks like [http://rubyonrails.org/ Rails] and [http://mocha.rubyforge.org/ Mocha] library.<br /> <br /> [[File:img_rspec.jpg]]<br /> <br /> '''Figure-4. Use of RSpec&lt;ref&gt;http://i.stack.imgur.com/&lt;/ref&gt;'''<br /> <br /> === RBehave &lt;ref&gt;http://dannorth.net/2007/06/17/introducing-rbehave/&lt;/ref&gt;===<br /> RBehave is a framework based on the story framework from [http://jbehave.org JBehave] which describes behaviour at the application level. It is simpler than RSpec and eliminates the need to reuse code. The choice of frameworks depend on the level of [http://en.wikipedia.org/wiki/Granularity granularity]. RBehave and RSpec are often used as a combination to simplify BDD wordings.<br /> <br /> <br /> == See also ==<br /> <br /> 1. [http://en.wikipedia.org/wiki/Behavior-driven_development Behavior-driven development]<br /> <br /> 2. [http://en.wikipedia.org/wiki/Test-driven_development Test-driven development]<br /> <br /> 3. [http://en.wikipedia.org/wiki/Cucumber_(software) Cucumber]<br /> <br /> 4. [http://bob-roberts.net/2012/02/17/608/ Using Rspec and Capybara]<br /> <br /> 5. [http://rorataspire.wordpress.com/2008/06/16/behaviour-driven-development-have-a-definite-edge-in-the-outsourced-software-development/ Lifecycle]<br /> <br /> 6. [http://www.slideshare.net/MarkMenard/behavior-driven-development-with-rails Behavior driven development with Rails]<br /> <br /> 7. [http://codesqueeze.com/the-easy-way-to-writing-good-user-stories/ Writing user stories]<br /> <br /> 8. [http://stackoverflow.com/questions/11762245/whats-the-difference-between-rspec-and-cucumber Difference between RSpec and Cucumber]<br /> <br /> == References ==<br /> <br /> &lt;references /&gt;</div>

Agoel2 https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/ch1_1w33_aa&diff=79932 2013-10-08T00:29:57Z

<p>Agoel2: </p> <hr /> <div>== '''Behavior Driven Development in Ruby on Rails''' ==<br /> <br /> Behavior-driven development (also known as BDD) is an [http://en.wikipedia.org/wiki/Agile_software_development Agile] development strategy that has been derived from [http://en.wikipedia.org/wiki/Test-driven_development Test Driven Development](also known as TDD). It was developed by [http://dannorth.net/ Dan North] in order to address the problems faced by TDD. <br /> <br /> <br /> __TOC__<br /> == Introduction ==<br /> <br /> Behavior Driven Development approach focuses on design, documentation and behavior rather than on tests. This approach enables more interactions between the client and the developer. The client specifies his functional specifications to the developer by writing [http://en.wikipedia.org/wiki/User_story user stories] which describe how the system should perform when a certain condition is met. These user stories are then translated into tests using tools like RSpec and Cucumber. These tests are then run to check whether they satisfy the desired functional behavior. The business requirement is delivered when all the tests pass.<br /> <br /> [[File:img_bdd.jpg]]<br /> <br /> '''Figure-1. Steps for BDD'''<br /> <br /> == Difference from other development strategies ==<br /> === Test-driven development (TDD) ===<br /> Another type of Test Driven Development is Behavior-driven development (also known as TDD). In TDD, software developers write automated test cases before they write any code.<br /> : • The first step of TDD is to write a failing test for a particular unit of functionality to be added. <br /> <br /> : • The next step is to write a piece of code only to pass that failing test.<br /> <br /> : • The last step would be to refactor the code so that it meets the requirement standards of the code.<br /> <br /> [[File:Steps.jpg]]<br /> <br /> '''Figure-2. Steps for TDD'''<br /> <br /> <br /> Test Driven Development follows three rules. They are:<br /> <br /> : • One must not write any production code unless it is to make a failing unit test pass.<br /> <br /> : • One must not write any more of a unit test than is sufficient to fail<br /> <br /> : • One must not write any more production code than is sufficient to pass the one failing unit test.<br /> <br /> <br /> === Difference between TDD and BDD ===<br /> : • TDD’s main focus is on the tests while BDD mainly focuses on the behavioral specification from the user point of view. <br /> <br /> : • With TDD, unit tests are written, whereas for BDD tests are written using “User Stories”.<br /> <br /> : • TDD uses language which is intelligible to only the software programmers.<br /> <br /> : • BDD uses language which is more easily understood by technical as well as non technical people.<br /> <br /> For example, to define a class named Student, TDD will create StudentTest class containing required tests, whereas BDD will create StudentBehaviour class which will contain example methods to define the behaviour of Student class.<br /> <br /> == Advantages of BDD ==<br /> : • Due to BDD language being comprehensible by both technical as well as domain experts, the BDD involves the customers and the business partners in writing the scenarios for the tests.<br /> <br /> : • Unlike tests which come after implementation, focusing on the behavior proves to be a better approach.<br /> <br /> : • TDD methodology can lead to a number of failed tests before arriving at the correct result because it focuses mainly on implementation. But BDD does not require so many tests as its main focus is behavior thus resulting in less code.<br /> <br /> == Disadvantages of BDD ==<br /> : • The user stories written by the customers might not be good quality and may have to be rewritten by the developer.<br /> <br /> : • The customer might not have enough time to review the scenarios on a regular basis.<br /> <br /> <br /> == Examples of BDD with Ruby on Rails ==<br /> In BDD, business requirements are identified by user stories. The user stories are described using the following format<br /> <br /> '''As a ''' [role]<br /> '''I can '''[feature] <br /> '''so that '''[reason]<br /> <br /> Example to explain this-<br /> <br /> ''' As a Bank account holder '''<br /> ''' I can login with my credentials '''<br /> ''' so that I can check my account details '''<br /> <br /> <br /> Once the user stories are written, the acceptance tests can be written for the user stories. The acceptance tests have the following format<br /> <br /> ''' Given '''[Context]<br /> ''' When ''' [Event Occurs]<br /> ''' Then ''' [Outcome]<br /> <br /> <br /> Scenario: Enter a Login Page<br /> <br /> ''' Given I enter a valid username '''<br /> ''' And I enter a valid password '''<br /> ''' When I press the Login Button '''<br /> ''' Then I should be redirected to the home page '''<br /> <br /> These acceptance tests for the user stories are entered in the application as automated tests by the developer. <br /> <br /> <br /> == Implementation ==<br /> Ruby on Rails uses various tools like Cucumber, Rspec etc to implement the user tests using Behaviour-driven development.<br /> <br /> === Cucumber ===<br /> BDD makes the use of Cucumber for running automated acceptance tests. Cucumber specifies what a user should see and be able to do. Cucumber works with Ruby to help the software development teams describe how an application should behave. Cucumber is intelligible to both software developers as well as domain experts. It can serve both as documentation and automated tests.<br /> <br /> [[File:img_cucumber.jpg]]<br /> <br /> '''Figure-3. Use of Cucumber'''<br /> <br /> === RSpec ===<br /> RSpec mainly deals with unit tests which mean testing a class method in isolation from the rest of the application. So it guarantees that the model does what it is supposed to do, the controller does what it is supposed to do, etc. It explains the behavior of objects at the code level. It provides a simple and elegant syntax and works effectively with some other frameworks like [http://rubyonrails.org/ Rails] and [http://mocha.rubyforge.org/ Mocha] library.<br /> <br /> [[File:img_rspec.jpg]]<br /> <br /> '''Figure-4. Use of RSpec'''<br /> <br /> === RBehave ===<br /> RBehave is a framework based on the story framework from [http://jbehave.org JBehave] which describes behaviour at the application level. It is simpler than RSpec and eliminates the need to reuse code. The choice of frameworks depend on the level of [http://en.wikipedia.org/wiki/Granularity granularity]. RBehave and RSpec are often used as a combination to simplify BDD wordings.<br /> <br /> <br /> == References ==<br /> <br /> 1. [http://en.wikipedia.org/wiki/Behavior-driven_development Behavior-driven development]<br /> <br /> 2. [http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd Rules of Test-driven development]<br /> <br /> 3. [http://bob-roberts.net/2012/02/17/608/ Using Rspec and Capybara]<br /> <br /> 4. [http://stackoverflow.com/questions/2509/what-are-the-primary-differences-between-tdd-and-bdd Difference between TDD and BDD]<br /> <br /> 5. [http://www.slideshare.net/IosifItkin/behavior-driven-development-pros-and-cons Benefits of behavior-driven development]<br /> <br /> 6. [http://rorataspire.wordpress.com/2008/06/16/behaviour-driven-development-have-a-definite-edge-in-the-outsourced-software-development/ Lifecycle]<br /> <br /> 7. [http://en.wikipedia.org/wiki/Test-driven_development Test-driven development]<br /> <br /> 8. [http://www.ryangreenhall.com/articles/bdd-by-example.html Examples of BDD]<br /> <br /> 9. [http://en.wikipedia.org/wiki/Cucumber_(software) Cucumber]<br /> <br /> 10. [http://cukes.info/ Cucumber coding style]<br /> <br /> 11. [http://www.slideshare.net/MarkMenard/behavior-driven-development-with-rails Behavior driven development with Rails]<br /> <br /> 12. [http://codesqueeze.com/the-easy-way-to-writing-good-user-stories/ Writing user stories]<br /> <br /> 13. [http://stackoverflow.com/questions/11762245/whats-the-difference-between-rspec-and-cucumber Difference between RSpec and Cucumber]<br /> <br /> 14. [http://dannorth.net/2007/06/17/introducing-rbehave/ RBehave]</div>

Agoel2 https://wiki.expertiza.ncsu.edu/index.php?title=File:Img_rspec.jpg&diff=79929 2013-10-08T00:27:51Z

<p>Agoel2: </p> <hr /> <div></div>

Agoel2 https://wiki.expertiza.ncsu.edu/index.php?title=File:Img_cucumber.jpg&diff=79927 2013-10-08T00:27:33Z

<p>Agoel2: </p> <hr /> <div></div>

Agoel2 https://wiki.expertiza.ncsu.edu/index.php?title=File:Img_bdd.jpg&diff=79926 2013-10-08T00:25:49Z

<p>Agoel2: </p> <hr /> <div></div>

Agoel2 https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/ch1_1w33_aa&diff=79904 2013-10-07T23:47:46Z

<p>Agoel2: </p> <hr /> <div>== '''Behavior Driven Development in Ruby on Rails''' ==<br /> <br /> Behavior-driven development (also known as BDD) is an [http://en.wikipedia.org/wiki/Agile_software_development Agile] development strategy that has been derived from [http://en.wikipedia.org/wiki/Test-driven_development Test Driven Development](also known as TDD). It was developed by [http://dannorth.net/ Dan North] in order to address the problems faced by TDD. <br /> <br /> <br /> __TOC__<br /> == Introduction ==<br /> <br /> Behavior Driven Development approach focuses on design, documentation and behavior rather than on tests. This approach enables more interactions between the client and the developer. The client specifies his functional specifications to the developer by writing [http://en.wikipedia.org/wiki/User_story user stories] which describe how the system should perform when a certain condition is met. These user stories are then translated into tests using tools like RSpec and Cucumber. These tests are then run to check whether they satisfy the desired functional behavior. The business requirement is delivered when all the tests pass.<br /> <br /> <br /> == Difference from other development strategies ==<br /> === Test-driven development (TDD) ===<br /> Another type of Test Driven Development is Behavior-driven development (also known as TDD). In TDD, software developers write automated test cases before they write any code.<br /> : • The first step of TDD is to write a failing test for a particular unit of functionality to be added. <br /> <br /> : • The next step is to write a piece of code only to pass that failing test.<br /> <br /> : • The last step would be to refactor the code so that it meets the requirement standards of the code.<br /> <br /> [[File:Steps.jpg]]<br /> <br /> '''Figure-1. Steps for TDD'''<br /> <br /> <br /> Test Driven Development follows three rules. They are:<br /> <br /> : • One must not write any production code unless it is to make a failing unit test pass.<br /> <br /> : • One must not write any more of a unit test than is sufficient to fail<br /> <br /> : • One must not write any more production code than is sufficient to pass the one failing unit test.<br /> <br /> <br /> === Difference between TDD and BDD ===<br /> : • TDD’s main focus is on the tests while BDD mainly focuses on the behavioral specification from the user point of view. <br /> <br /> : • With TDD, unit tests are written, whereas for BDD tests are written using “User Stories”.<br /> <br /> : • TDD uses language which is intelligible to only the software programmers.<br /> <br /> : • BDD uses language which is more easily understood by technical as well as non technical people.<br /> <br /> For example, to define a class named Student, TDD will create StudentTest class containing required tests, whereas BDD will create StudentBehaviour class which will contain example methods to define the behaviour of Student class.<br /> <br /> == Advantages of BDD ==<br /> : • Due to BDD language being comprehensible by both technical as well as domain experts, the BDD involves the customers and the business partners in writing the scenarios for the tests.<br /> <br /> : • Unlike tests which come after implementation, focusing on the behavior proves to be a better approach.<br /> <br /> : • TDD methodology can lead to a number of failed tests before arriving at the correct result because it focuses mainly on implementation. But BDD does not require so many tests as its main focus is behavior thus resulting in less code.<br /> <br /> == Disadvantages of BDD ==<br /> : • The user stories written by the customers might not be good quality and may have to be rewritten by the developer.<br /> <br /> : • The customer might not have enough time to review the scenarios on a regular basis.<br /> <br /> <br /> == Examples of BDD with Ruby on Rails ==<br /> In BDD, business requirements are identified by user stories. The user stories are described using the following format<br /> <br /> '''As a ''' [role]<br /> '''I can '''[feature] <br /> '''so that '''[reason]<br /> <br /> Example to explain this-<br /> <br /> ''' As a Bank account holder '''<br /> ''' I can login with my credentials '''<br /> ''' so that I can check my account details '''<br /> <br /> <br /> Once the user stories are written, the acceptance tests can be written for the user stories. The acceptance tests have the following format<br /> <br /> ''' Given '''[Context]<br /> ''' When ''' [Event Occurs]<br /> ''' Then ''' [Outcome]<br /> <br /> <br /> Scenario: Enter a Login Page<br /> <br /> ''' Given I enter a valid username '''<br /> ''' And I enter a valid password '''<br /> ''' When I press the Login Button '''<br /> ''' Then I should be redirected to the home page '''<br /> <br /> These acceptance tests for the user stories are entered in the application as automated tests by the developer. <br /> <br /> <br /> == Implementation ==<br /> Ruby on Rails uses various tools like Cucumber, Rspec etc to implement the user tests using Behaviour-driven development.<br /> <br /> === Cucumber ===<br /> BDD makes the use of Cucumber for running automated acceptance tests. Cucumber specifies what a user should see and be able to do. Cucumber works with Ruby to help the software development teams describe how an application should behave. Cucumber is intelligible to both software developers as well as domain experts. It can serve both as documentation and automated tests.<br /> <br /> <br /> === RSpec ===<br /> RSpec mainly deals with unit tests which mean testing a class method in isolation from the rest of the application. So it guarantees that the model does what it is supposed to do, the controller does what it is supposed to do, etc. It explains the behavior of objects at the code level. It provides a simple and elegant syntax and works effectively with some other frameworks like [http://rubyonrails.org/ Rails] and [http://mocha.rubyforge.org/ Mocha] library.<br /> <br /> <br /> === RBehave ===<br /> RBehave is a framework based on the story framework from [http://jbehave.org JBehave] which describes behaviour at the application level. It is simpler than RSpec and eliminates the need to reuse code. The choice of frameworks depend on the level of [http://en.wikipedia.org/wiki/Granularity granularity]. RBehave and RSpec are often used as a combination to simplify BDD wordings.<br /> <br /> <br /> == References ==<br /> <br /> 1. [http://en.wikipedia.org/wiki/Behavior-driven_development Behavior-driven development]<br /> <br /> 2. [http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd Rules of Test-driven development]<br /> <br /> 3. [http://bob-roberts.net/2012/02/17/608/ Using Rspec and Capybara]<br /> <br /> 4. [http://stackoverflow.com/questions/2509/what-are-the-primary-differences-between-tdd-and-bdd Difference between TDD and BDD]<br /> <br /> 5. [http://www.slideshare.net/IosifItkin/behavior-driven-development-pros-and-cons Benefits of behavior-driven development]<br /> <br /> 6. [http://rorataspire.wordpress.com/2008/06/16/behaviour-driven-development-have-a-definite-edge-in-the-outsourced-software-development/ Lifecycle]<br /> <br /> 7. [http://en.wikipedia.org/wiki/Test-driven_development Test-driven development]<br /> <br /> 8. [http://www.ryangreenhall.com/articles/bdd-by-example.html Examples of BDD]<br /> <br /> 9. [http://en.wikipedia.org/wiki/Cucumber_(software) Cucumber]<br /> <br /> 10. [http://cukes.info/ Cucumber coding style]<br /> <br /> 11. [http://www.slideshare.net/MarkMenard/behavior-driven-development-with-rails Behavior driven development with Rails]<br /> <br /> 12. [http://codesqueeze.com/the-easy-way-to-writing-good-user-stories/ Writing user stories]<br /> <br /> 13. [http://stackoverflow.com/questions/11762245/whats-the-difference-between-rspec-and-cucumber Difference between RSpec and Cucumber]<br /> <br /> 14. [http://dannorth.net/2007/06/17/introducing-rbehave/ RBehave]</div>

Agoel2 https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/ch1_1w33_aa&diff=79901 2013-10-07T23:44:13Z

<p>Agoel2: </p> <hr /> <div>== '''Behavior Driven Development in Ruby on Rails''' ==<br /> <br /> Behavior-driven development (also known as BDD) is an [http://en.wikipedia.org/wiki/Agile_software_development Agile] development strategy that has been derived from [http://en.wikipedia.org/wiki/Test-driven_development Test Driven Development](also known as TDD). It was developed by [http://dannorth.net/ Dan North] in order to address the problems faced by TDD. <br /> <br /> <br /> __TOC__<br /> == Introduction ==<br /> <br /> Behavior Driven Development approach focuses on design, documentation and behavior rather than on tests. This approach enables more interactions between the client and the developer. The client specifies his functional specifications to the developer by writing [http://en.wikipedia.org/wiki/User_story user stories] which describe how the system should perform when a certain condition is met. These user stories are then translated into tests using tools like RSpec and Cucumber. These tests are then run to check whether they satisfy the desired functional behavior. The business requirement is delivered when all the tests pass.<br /> <br /> <br /> == Difference from other development strategies ==<br /> === Test-driven development (TDD) ===<br /> Another type of Test Driven Development is Behavior-driven development (also known as TDD). In TDD, software developers write automated test cases before they write any code.<br /> : • The first step of TDD is to write a failing test for a particular unit of functionality to be added. <br /> <br /> : • The next step is to write a piece of code only to pass that failing test.<br /> <br /> : • The last step would be to refactor the code so that it meets the requirement standards of the code.<br /> <br /> [[File:Steps.jpg]]<br /> <br /> Test Driven Development follows three rules. They are:<br /> <br /> : • One must not write any production code unless it is to make a failing unit test pass.<br /> <br /> : • One must not write any more of a unit test than is sufficient to fail<br /> <br /> : • One must not write any more production code than is sufficient to pass the one failing unit test.<br /> <br /> <br /> === Difference between TDD and BDD ===<br /> : • TDD’s main focus is on the tests while BDD mainly focuses on the behavioral specification from the user point of view. <br /> <br /> : • With TDD, unit tests are written, whereas for BDD tests are written using “User Stories”.<br /> <br /> : • TDD uses language which is intelligible to only the software programmers.<br /> <br /> : • BDD uses language which is more easily understood by technical as well as non technical people.<br /> <br /> For example, to define a class named Student, TDD will create StudentTest class containing required tests, whereas BDD will create StudentBehaviour class which will contain example methods to define the behaviour of Student class.<br /> <br /> == Advantages of BDD ==<br /> : • Due to BDD language being comprehensible by both technical as well as domain experts, the BDD involves the customers and the business partners in writing the scenarios for the tests.<br /> <br /> : • Unlike tests which come after implementation, focusing on the behavior proves to be a better approach.<br /> <br /> : • TDD methodology can lead to a number of failed tests before arriving at the correct result because it focuses mainly on implementation. But BDD does not require so many tests as its main focus is behavior thus resulting in less code.<br /> <br /> == Disadvantages of BDD ==<br /> : • The user stories written by the customers might not be good quality and may have to be rewritten by the developer.<br /> <br /> : • The customer might not have enough time to review the scenarios on a regular basis.<br /> <br /> <br /> == Examples of BDD with Ruby on Rails ==<br /> In BDD, business requirements are identified by user stories. The user stories are described using the following format<br /> <br /> '''As a ''' [role]<br /> '''I can '''[feature] <br /> '''so that '''[reason]<br /> <br /> Example to explain this-<br /> <br /> ''' As a Bank account holder '''<br /> ''' I can login with my credentials '''<br /> ''' so that I can check my account details '''<br /> <br /> <br /> Once the user stories are written, the acceptance tests can be written for the user stories. The acceptance tests have the following format<br /> <br /> ''' Given '''[Context]<br /> ''' When ''' [Event Occurs]<br /> ''' Then ''' [Outcome]<br /> <br /> <br /> Scenario: Enter a Login Page<br /> <br /> ''' Given I enter a valid username '''<br /> ''' And I enter a valid password '''<br /> ''' When I press the Login Button '''<br /> ''' Then I should be redirected to the home page '''<br /> <br /> These acceptance tests for the user stories are entered in the application as automated tests by the developer. <br /> <br /> <br /> == Implementation ==<br /> Ruby on Rails uses various tools like Cucumber, Rspec etc to implement the user tests using Behaviour-driven development.<br /> <br /> === Cucumber ===<br /> BDD makes the use of Cucumber for running automated acceptance tests. Cucumber specifies what a user should see and be able to do. Cucumber works with Ruby to help the software development teams describe how an application should behave. Cucumber is intelligible to both software developers as well as domain experts. It can serve both as documentation and automated tests.<br /> <br /> <br /> === RSpec ===<br /> RSpec mainly deals with unit tests which mean testing a class method in isolation from the rest of the application. So it guarantees that the model does what it is supposed to do, the controller does what it is supposed to do, etc. It explains the behavior of objects at the code level. It provides a simple and elegant syntax and works effectively with some other frameworks like [http://rubyonrails.org/ Rails] and [http://mocha.rubyforge.org/ Mocha] library.<br /> <br /> <br /> === RBehave ===<br /> RBehave is a framework based on the story framework from [http://jbehave.org JBehave] which describes behaviour at the application level. It is simpler than RSpec and eliminates the need to reuse code. The choice of frameworks depend on the level of [http://en.wikipedia.org/wiki/Granularity granularity]. RBehave and RSpec are often used as a combination to simplify BDD wordings.<br /> <br /> <br /> == References ==<br /> <br /> 1. [http://en.wikipedia.org/wiki/Behavior-driven_development Behavior-driven development]<br /> <br /> 2. [http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd Rules of Test-driven development]<br /> <br /> 3. [http://bob-roberts.net/2012/02/17/608/ Using Rspec and Capybara]<br /> <br /> 4. [http://stackoverflow.com/questions/2509/what-are-the-primary-differences-between-tdd-and-bdd Difference between TDD and BDD]<br /> <br /> 5. [http://www.slideshare.net/IosifItkin/behavior-driven-development-pros-and-cons Benefits of behavior-driven development]<br /> <br /> 6. [http://rorataspire.wordpress.com/2008/06/16/behaviour-driven-development-have-a-definite-edge-in-the-outsourced-software-development/ Lifecycle]<br /> <br /> 7. [http://en.wikipedia.org/wiki/Test-driven_development Test-driven development]<br /> <br /> 8. [http://www.ryangreenhall.com/articles/bdd-by-example.html Examples of BDD]<br /> <br /> 9. [http://en.wikipedia.org/wiki/Cucumber_(software) Cucumber]<br /> <br /> 10. [http://cukes.info/ Cucumber coding style]<br /> <br /> 11. [http://www.slideshare.net/MarkMenard/behavior-driven-development-with-rails Behavior driven development with Rails]<br /> <br /> 12. [http://codesqueeze.com/the-easy-way-to-writing-good-user-stories/ Writing user stories]<br /> <br /> 13. [http://stackoverflow.com/questions/11762245/whats-the-difference-between-rspec-and-cucumber Difference between RSpec and Cucumber]<br /> <br /> 14. [http://dannorth.net/2007/06/17/introducing-rbehave/ RBehave]</div>

Agoel2 https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/ch1_1w33_aa&diff=79892 2013-10-07T23:32:22Z

<p>Agoel2: </p> <hr /> <div>== '''Behavior Driven Development in Ruby on Rails''' ==<br /> <br /> Behavior-driven development (also known as BDD) is an [http://en.wikipedia.org/wiki/Agile_software_development Agile] development strategy that has been derived from [http://en.wikipedia.org/wiki/Test-driven_development Test Driven Development](also known as TDD). It was developed by [http://dannorth.net/ Dan North] in order to address the problems faced by TDD. <br /> <br /> <br /> __TOC__<br /> == Introduction ==<br /> <br /> Behavior Driven Development approach focuses on design, documentation and behavior rather than on tests. This approach enables more interactions between the client and the developer. The client specifies his functional specifications to the developer by writing [http://en.wikipedia.org/wiki/User_story user stories] which describe how the system should perform when a certain condition is met. These user stories are then translated into tests using tools like RSpec and Cucumber. These tests are then run to check whether they satisfy the desired functional behavior. The business requirement is delivered when all the tests pass.<br /> <br /> == Difference from other development strategies ==<br /> === Test-driven development (TDD) ===<br /> Another type of Test Driven Development is Behavior-driven development (also known as TDD). In TDD, software developers write automated test cases before they write any code.<br /> : • The first step of TDD is to write a failing test for a particular unit of functionality to be added. <br /> <br /> : • The next step is to write a piece of code only to pass that failing test.<br /> <br /> : • The last step would be to refactor the code so that it meets the requirement standards of the code.<br /> <br /> [[File:Steps.jpg]]<br /> <br /> Test Driven Development follows three rules. They are:<br /> <br /> : • One must not write any production code unless it is to make a failing unit test pass.<br /> <br /> : • One must not write any more of a unit test than is sufficient to fail<br /> <br /> : • One must not write any more production code than is sufficient to pass the one failing unit test.<br /> <br /> === Difference between TDD and BDD ===<br /> : • TDD’s main focus is on the tests while BDD mainly focuses on the behavioral specification from the user point of view. <br /> <br /> : • With TDD, unit tests are written, whereas for BDD tests are written using “User Stories”.<br /> <br /> : • TDD uses language which is intelligible to only the software programmers.<br /> <br /> : • BDD uses language which is more easily understood by technical as well as non technical people.<br /> <br /> == Advantages of BDD ==<br /> : • Due to BDD language being comprehensible by both technical as well as domain experts, the BDD involves the customers and the business partners in writing the scenarios for the tests.<br /> <br /> : • Unlike tests which come after implementation, focusing on the behavior proves to be a better approach.<br /> <br /> : • TDD methodology can lead to a number of failed tests before arriving at the correct result because it focuses mainly on implementation. But BDD does not require so many tests as its main focus is behavior thus resulting in less code.<br /> <br /> == Disadvantages of BDD ==<br /> : • The user stories written by the customers might not be good quality and may have to be rewritten by the developer.<br /> <br /> : • The customer might not have enough time to review the scenarios on a regular basis.<br /> <br /> == Examples of BDD with Ruby on Rails ==<br /> In BDD, business requirements are identified by user stories. The user stories are described using the following format<br /> <br /> '''As a ''' [role]<br /> '''I can '''[feature] <br /> '''so that '''[reason]<br /> <br /> Example to explain this-<br /> <br /> ''' As a Bank account holder '''<br /> ''' I can login with my credentials '''<br /> ''' so that I can check my account details '''<br /> <br /> <br /> Once the user stories are written, the acceptance tests can be written for the user stories. The acceptance tests have the following format<br /> <br /> ''' Given '''[Context]<br /> ''' When ''' [Event Occurs]<br /> ''' Then ''' [Outcome]<br /> <br /> <br /> <br /> Scenario: Enter a Login Page<br /> <br /> ''' Given I enter a valid username '''<br /> ''' And I enter a valid password '''<br /> ''' When I press the Login Button '''<br /> ''' Then I should be redirected to the home page '''<br /> <br /> These acceptance tests for the user stories are entered in the application as automated tests by the developer. <br /> <br /> == Implementation ==<br /> Ruby on Rails uses various tools like Cucumber, Rspec etc to implement the user tests using Behaviour-driven development.<br /> <br /> === Cucumber ===<br /> BDD makes the use of Cucumber for running automated acceptance tests. Cucumber specifies what a user should see and be able to do. Cucumber works with Ruby to help the software development teams describe how an application should behave. Cucumber is intelligible to both software developers as well as domain experts. It can serve both as documentation and automated tests.<br /> <br /> <br /> === RSpec ===<br /> RSpec mainly deals with unit tests which mean testing a class method in isolation from the rest of the application. So it guarantees that the model does what it is supposed to do, the controller does what it is supposed to do, etc. It explains the behavior of objects at the code level. It provides a simple and elegant syntax and works effectively with some other frameworks like [http://rubyonrails.org/ Rails] and [http://mocha.rubyforge.org/ Mocha] library.<br /> <br /> <br /> === RBehave ===<br /> RBehave is a framework based on the story framework from [http://jbehave.org JBehave] which describes behaviour at the application level. It is simpler than RSpec and eliminates the need to reuse code. The choice of frameworks depend on the level of [http://en.wikipedia.org/wiki/Granularity granularity]. RBehave and RSpec are often used as a combination to simplify BDD wordings.<br /> <br /> == References ==<br /> <br /> 1. [http://en.wikipedia.org/wiki/Behavior-driven_development Behavior-driven development]<br /> <br /> 2. [http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd Rules of Test-driven development]<br /> <br /> 3. [http://bob-roberts.net/2012/02/17/608/ Using Rspec and Capybara]<br /> <br /> 4. [http://stackoverflow.com/questions/2509/what-are-the-primary-differences-between-tdd-and-bdd Difference between TDD and BDD]<br /> <br /> 5. [http://www.slideshare.net/IosifItkin/behavior-driven-development-pros-and-cons Benefits of behavior-driven development]<br /> <br /> 6. [http://rorataspire.wordpress.com/2008/06/16/behaviour-driven-development-have-a-definite-edge-in-the-outsourced-software-development/ Lifecycle]<br /> <br /> 7. [http://en.wikipedia.org/wiki/Test-driven_development Test-driven development]<br /> <br /> 8. [http://www.ryangreenhall.com/articles/bdd-by-example.html Examples of BDD]<br /> <br /> 9. [http://cukes.info/ Cucumber info]<br /> <br /> 10. [http://en.wikipedia.org/wiki/Cucumber_(software) Cucumber]<br /> <br /> 11. [http://www.slideshare.net/MarkMenard/behavior-driven-development-with-rails Behavior driven development with Rails]<br /> <br /> 12. [http://codesqueeze.com/the-easy-way-to-writing-good-user-stories/ Writing user stories]<br /> <br /> 13. [http://stackoverflow.com/questions/11762245/whats-the-difference-between-rspec-and-cucumber Difference between RSpec and Cucumber]<br /> <br /> 14. [http://dannorth.net/2007/06/17/introducing-rbehave/ RBehave]</div>

Agoel2 https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/ch1_1w33_aa&diff=79890 2013-10-07T23:28:40Z

<p>Agoel2: </p> <hr /> <div>== '''Behavior Driven Development in Ruby on Rails''' ==<br /> <br /> Behavior-driven development (also known as BDD) is an [http://en.wikipedia.org/wiki/Agile_software_development Agile] development strategy that has been derived from [http://en.wikipedia.org/wiki/Test-driven_development Test Driven Development]. It was developed by [http://dannorth.net/ Dan North] in order to address the problems faced by TDD. <br /> <br /> <br /> __TOC__<br /> == Introduction ==<br /> <br /> Behavior Driven Development approach focuses on design, documentation and behavior rather than on tests. This approach enables more interactions between the client and the developer. The client specifies his functional specifications to the developer by writing [http://en.wikipedia.org/wiki/User_story user stories] which describe how the system should perform when a certain condition is met. These user stories are then translated into tests using tools like RSpec and Cucumber. These tests are then run to check whether they satisfy the desired functional behavior. The business requirement is delivered when all the tests pass.<br /> <br /> == Difference from other development strategies ==<br /> === Test-driven development (TDD) ===<br /> Another type of Test Driven Development is Behavior-driven development (also known as TDD). In TDD, software developers write automated test cases before they write any code.<br /> : • The first step of TDD is to write a failing test for a particular unit of functionality to be added. <br /> <br /> : • The next step is to write a piece of code only to pass that failing test.<br /> <br /> : • The last step would be to refactor the code so that it meets the requirement standards of the code.<br /> <br /> [[File:Steps.jpg]]<br /> <br /> Test Driven Development follows three rules. They are:<br /> <br /> : • One must not write any production code unless it is to make a failing unit test pass.<br /> <br /> : • One must not write any more of a unit test than is sufficient to fail<br /> <br /> : • One must not write any more production code than is sufficient to pass the one failing unit test.<br /> <br /> === Difference between TDD and BDD ===<br /> : • TDD’s main focus is on the tests while BDD mainly focuses on the behavioral specification from the user point of view. <br /> <br /> : • With TDD, unit tests are written, whereas for BDD tests are written using “User Stories”.<br /> <br /> : • TDD uses language which is intelligible to only the software programmers.<br /> <br /> : • BDD uses language which is more easily understood by technical as well as non technical people.<br /> <br /> == Advantages of BDD ==<br /> : • Due to BDD language being comprehensible by both technical as well as domain experts, the BDD involves the customers and the business partners in writing the scenarios for the tests.<br /> <br /> : • Unlike tests which come after implementation, focusing on the behavior proves to be a better approach.<br /> <br /> : • TDD methodology can lead to a number of failed tests before arriving at the correct result because it focuses mainly on implementation. But BDD does not require so many tests as its main focus is behavior thus resulting in less code.<br /> <br /> == Disadvantages of BDD ==<br /> : • The user stories written by the customers might not be good quality and may have to be rewritten by the developer.<br /> <br /> : • The customer might not have enough time to review the scenarios on a regular basis.<br /> <br /> == Examples of BDD with Ruby on Rails ==<br /> In BDD, business requirements are identified by user stories. The user stories are described using the following format<br /> <br /> '''As a ''' [role]<br /> '''I can '''[feature] <br /> '''so that '''[reason]<br /> <br /> Example to explain this-<br /> <br /> ''' As a Bank account holder '''<br /> ''' I can login with my credentials '''<br /> ''' so that I can check my account details '''<br /> <br /> <br /> Once the user stories are written, the acceptance tests can be written for the user stories. The acceptance tests have the following format<br /> <br /> ''' Given '''[Context]<br /> ''' When ''' [Event Occurs]<br /> ''' Then ''' [Outcome]<br /> <br /> <br /> <br /> Scenario: Enter a Login Page<br /> <br /> ''' Given I enter a valid username '''<br /> ''' And I enter a valid password '''<br /> ''' When I press the Login Button '''<br /> ''' Then I should be redirected to the home page '''<br /> <br /> These acceptance tests for the user stories are entered in the application as automated tests by the developer. <br /> <br /> == Implementation ==<br /> Ruby on Rails uses various tools like Cucumber, Rspec etc to implement the user tests using Behaviour-driven development.<br /> <br /> === Cucumber ===<br /> BDD makes the use of Cucumber for running automated acceptance tests. Cucumber specifies what a user should see and be able to do. Cucumber works with Ruby to help the software development teams describe how an application should behave. Cucumber is intelligible to both software developers as well as domain experts. It can serve both as documentation and automated tests.<br /> <br /> <br /> === RSpec ===<br /> RSpec mainly deals with unit tests which mean testing a class method in isolation from the rest of the application. So it guarantees that the model does what it is supposed to do, the controller does what it is supposed to do, etc. It explains the behavior of objects at the code level. It provides a simple and elegant syntax and works effectively with some other frameworks like [http://rubyonrails.org/ Rails] and [http://mocha.rubyforge.org/ Mocha] library.<br /> <br /> <br /> === RBehave ===<br /> RBehave is a framework based on the story framework from [http://jbehave.org JBehave] which describes behaviour at the application level. It is simpler than RSpec and eliminates the need to reuse code. The choice of frameworks depend on the level of [http://en.wikipedia.org/wiki/Granularity granularity]. RBehave and RSpec are often used as a combination to simplify BDD wordings.<br /> <br /> == References ==<br /> <br /> 1. [http://en.wikipedia.org/wiki/Behavior-driven_development Behavior-driven development]<br /> <br /> 2. [http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd Rules of Test-driven development]<br /> <br /> 3. [http://bob-roberts.net/2012/02/17/608/ Using Rspec and Capybara]<br /> <br /> 4. [http://stackoverflow.com/questions/2509/what-are-the-primary-differences-between-tdd-and-bdd Difference between TDD and BDD]<br /> <br /> 5. [http://www.slideshare.net/IosifItkin/behavior-driven-development-pros-and-cons Benefits of behavior-driven development]<br /> <br /> 6. [http://rorataspire.wordpress.com/2008/06/16/behaviour-driven-development-have-a-definite-edge-in-the-outsourced-software-development/ Lifecycle]<br /> <br /> 7. [http://en.wikipedia.org/wiki/Test-driven_development Test-driven development]<br /> <br /> 8. [http://www.ryangreenhall.com/articles/bdd-by-example.html Examples of BDD]<br /> <br /> 9. [http://cukes.info/ Cucumber info]<br /> <br /> 10. [http://en.wikipedia.org/wiki/Cucumber_(software) Cucumber]<br /> <br /> 11. [http://www.slideshare.net/MarkMenard/behavior-driven-development-with-rails Behavior driven development with Rails]<br /> <br /> 12. [http://codesqueeze.com/the-easy-way-to-writing-good-user-stories/ Writing user stories]<br /> <br /> 13. [http://stackoverflow.com/questions/11762245/whats-the-difference-between-rspec-and-cucumber Difference between RSpec and Cucumber]<br /> <br /> 14. [http://dannorth.net/2007/06/17/introducing-rbehave/ RBehave]</div>

Agoel2 https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/ch1_1w33_aa&diff=79658 2013-10-07T03:10:16Z

<p>Agoel2: </p> <hr /> <div>== Behavior-driven development in Ruby on Rails ==<br /> <br /> Behavior-driven development (also known as BDD) is an [http://en.wikipedia.org/wiki/Agile_software_development Agile] development strategy that has been derived from Test Driven Development. It was developed by [http://dannorth.net/ Dan North] in order to address the problems faced by TDD. BDD approach focuses on design, documentation and behavior rather than on tests. This approach enables more interactions between the client and the developer. <br /> The client specifies his functional specifications to the developer by writing user stories which describe how the system should perform when a certain condition is met. These user stories are then translated into tests using tools like RSpec and Cucumber. These tests are then run to check whether they satisfy the desired functional behavior. The business requirement is delivered when all the tests pass.<br /> <br /> == Difference from other development strategies ==<br /> === Test-driven development (TDD) ===<br /> Another type of Test Driven Development is Behavior-driven development (also known as TDD). In TDD, software developers write automated test cases before they write any code.<br /> : • The first step of TDD is to write a failing test for a particular unit of functionality to be added. <br /> <br /> : • The next step is to write a piece of code only to pass that failing test.<br /> <br /> : • The last step would be to refactor the code so that it meets the requirement standards of the code.<br /> <br /> [[File:Steps.jpg]]<br /> <br /> Test Driven Development follows three rules. They are:<br /> <br /> : • One must not write any production code unless it is to make a failing unit test pass.<br /> <br /> : • One must not write any more of a unit test than is sufficient to fail<br /> <br /> : • One must not write any more production code than is sufficient to pass the one failing unit test.<br /> <br /> === Difference between TDD and BDD ===<br /> : • TDD’s main focus is on the tests while BDD mainly focuses on the behavioral specification from the user point of view. <br /> <br /> : • With TDD, unit tests are written, whereas for BDD tests are written using “User Stories”.<br /> <br /> : • TDD uses language which is intelligible to only the software programmers.<br /> <br /> : • BDD uses language which is more easily understood by technical as well as non technical people.<br /> <br /> == Advantages of BDD ==<br /> : • Due to BDD language being comprehensible by both technical as well as domain experts, the BDD involves the customers and the business partners in writing the scenarios for the tests.<br /> <br /> : • Unlike tests which come after implementation, focusing on the behavior proves to be a better approach.<br /> <br /> : • TDD methodology can lead to a number of failed tests before arriving at the correct result because it focuses mainly on implementation. But BDD does not require so many tests as its main focus is behavior thus resulting in less code.<br /> <br /> == Disadvantages of BDD ==<br /> : • The user stories written by the customers might not be good quality and may have to be rewritten by the developer.<br /> <br /> : • The customer might not have enough time to review the scenarios on a regular basis.<br /> <br /> == Examples of BDD with Ruby on Rails ==<br /> In BDD, business requirements are identified by user stories. The user stories are described using the following format<br /> <br /> '''As a ''' [role]<br /> '''I can '''[feature] <br /> '''so that '''[reason]<br /> <br /> Example to explain this-<br /> <br /> ''' As a Bank account holder '''<br /> ''' I can login with my credentials '''<br /> ''' so that I can check my account details '''<br /> <br /> <br /> Once the user stories are written, the acceptance tests can be written for the user stories. The acceptance tests have the following format<br /> <br /> ''' Given '''[Context]<br /> ''' When ''' [Event Occurs]<br /> ''' Then ''' [Outcome]<br /> <br /> <br /> <br /> Scenario: Enter a Login Page<br /> <br /> ''' Given I enter a valid username '''<br /> ''' And I enter a valid password '''<br /> ''' When I press the Login Button '''<br /> ''' Then I should be redirected to the home page '''<br /> <br /> These acceptance tests for the user stories are entered in the application as automated tests by the developer. <br /> <br /> == Implementation ==<br /> Ruby on Rails uses various tools like Cucumber, Rspec etc to implement the user tests using Behaviour-driven development.<br /> <br /> === Cucumber ===<br /> BDD makes the use of Cucumber for running automated acceptance tests. Cucumber specifies what a user should see and be able to do. Cucumber works with Ruby to help the software development teams describe how an application should behave. Cucumber is intelligible to both software developers as well as domain experts. It can serve both as documentation and automated tests.<br /> <br /> <br /> === RSpec ===<br /> RSpec mainly deals with unit tests which mean testing a class method in isolation from the rest of the application. So it guarantees that the model does what it is supposed to do, the controller does what it is supposed to do, etc. It explains the behavior of objects at the code level. It provides a simple and elegant syntax and works effectively with some other frameworks like [http://rubyonrails.org/ Rails] and [http://mocha.rubyforge.org/ Mocha] library.<br /> <br /> <br /> === RBehave ===<br /> RBehave is a framework based on the story framework from [http://jbehave.org JBehave] which describes behaviour at the application level. It is simpler than RSpec and eliminates the need to reuse code. The choice of frameworks depend on the level of [http://en.wikipedia.org/wiki/Granularity granularity]. RBehave and RSpec are often used as a combination to simplify BDD wordings.<br /> <br /> == References ==<br /> <br /> 1. [http://en.wikipedia.org/wiki/Behavior-driven_development Behavior-driven development]<br /> <br /> 2. [http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd Rules of Test-driven development]<br /> <br /> 3. [http://bob-roberts.net/2012/02/17/608/ Using Rspec and Capybara]<br /> <br /> 4. [http://stackoverflow.com/questions/2509/what-are-the-primary-differences-between-tdd-and-bdd Difference between TDD and BDD]<br /> <br /> 5. [http://www.slideshare.net/IosifItkin/behavior-driven-development-pros-and-cons Benefits of behavior-driven development]<br /> <br /> 6. [http://rorataspire.wordpress.com/2008/06/16/behaviour-driven-development-have-a-definite-edge-in-the-outsourced-software-development/ Lifecycle]<br /> <br /> 7. [http://en.wikipedia.org/wiki/Test-driven_development Test-driven development]<br /> <br /> 8. [http://www.ryangreenhall.com/articles/bdd-by-example.html Examples of BDD]<br /> <br /> 9. [http://cukes.info/ Cucumber info]<br /> <br /> 10. [http://en.wikipedia.org/wiki/Cucumber_(software) Cucumber]<br /> <br /> 11. [http://www.slideshare.net/MarkMenard/behavior-driven-development-with-rails Behavior driven development with Rails]<br /> <br /> 12. [http://codesqueeze.com/the-easy-way-to-writing-good-user-stories/ Writing user stories]<br /> <br /> 13. [http://stackoverflow.com/questions/11762245/whats-the-difference-between-rspec-and-cucumber Difference between RSpec and Cucumber]<br /> <br /> 14. [http://dannorth.net/2007/06/17/introducing-rbehave/ RBehave]</div>

Agoel2 https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/ch1_1w33_aa&diff=79657 2013-10-07T03:01:36Z

<p>Agoel2: </p> <hr /> <div>== Behavior-driven development in Ruby on Rails ==<br /> <br /> Behavior-driven development (also known as BDD) is an agile development strategy that has been derived from Test Driven Development. It was developed by Dan North in order to address the problems faced by TDD. BDD approach focuses on design, documentation and behavior rather than on tests. This approach enables more interactions between the client and the developer. <br /> The client specifies his functional specifications to the developer by writing user stories which describe how the system should perform when a certain condition is met. These user stories are then translated into tests using tools like RSpec and Cucumber. These tests are then run to check whether they satisfy the desired functional behavior. The business requirement is delivered when all the tests pass.<br /> <br /> == Difference from other development strategies ==<br /> === Test-driven development (TDD) ===<br /> Another type of Test Driven Development is Behavior-driven development (also known as TDD). In TDD, software developers write automated test cases before they write any code.<br /> : • The first step of TDD is to write a failing test for a particular unit of functionality to be added. <br /> <br /> : • The next step is to write a piece of code only to pass that failing test.<br /> <br /> : • The last step would be to refactor the code so that it meets the requirement standards of the code.<br /> <br /> [[File:Steps.jpg]]<br /> <br /> Test Driven Development follows three rules. They are:<br /> <br /> : • One must not write any production code unless it is to make a failing unit test pass.<br /> <br /> : • One must not write any more of a unit test than is sufficient to fail<br /> <br /> : • One must not write any more production code than is sufficient to pass the one failing unit test.<br /> <br /> === Difference between TDD and BDD ===<br /> : • TDD’s main focus is on the tests while BDD mainly focuses on the behavioral specification from the user point of view. <br /> <br /> : • With TDD, unit tests are written, whereas for BDD tests are written using “User Stories”.<br /> <br /> : • TDD uses language which is intelligible to only the software programmers.<br /> <br /> : • BDD uses language which is more easily understood by technical as well as non technical people.<br /> <br /> == Advantages of BDD ==<br /> : • Due to BDD language being comprehensible by both technical as well as domain experts, the BDD involves the customers and the business partners in writing the scenarios for the tests.<br /> <br /> : • Unlike tests which come after implementation, focusing on the behavior proves to be a better approach.<br /> <br /> : • TDD methodology can lead to a number of failed tests before arriving at the correct result because it focuses mainly on implementation. But BDD does not require so many tests as its main focus is behavior thus resulting in less code.<br /> <br /> == Disadvantages of BDD ==<br /> : • The user stories written by the customers might not be good quality and may have to be rewritten by the developer.<br /> <br /> : • The customer might not have enough time to review the scenarios on a regular basis.<br /> <br /> == Examples of BDD with Ruby on Rails ==<br /> In BDD, business requirements are identified by user stories. The user stories are described using the following format<br /> <br /> '''As a ''' [role]<br /> '''I can '''[feature] <br /> '''so that '''[reason]<br /> <br /> Example to explain this-<br /> <br /> ''' As a Bank account holder '''<br /> ''' I can login with my credentials '''<br /> ''' so that I can check my account details '''<br /> <br /> <br /> Once the user stories are written, the acceptance tests can be written for the user stories. The acceptance tests have the following format<br /> <br /> ''' Given '''[Context]<br /> ''' When ''' [Event Occurs]<br /> ''' Then ''' [Outcome]<br /> <br /> <br /> <br /> Scenario: Enter a Login Page<br /> <br /> ''' Given I enter a valid username '''<br /> ''' And I enter a valid password '''<br /> ''' When I press the Login Button '''<br /> ''' Then I should be redirected to the home page '''<br /> <br /> These acceptance tests for the user stories are entered in the application as automated tests by the developer. <br /> <br /> == Implementation ==<br /> Ruby on Rails uses various tools like Cucumber, Rspec etc to implement the user tests using Behaviour-driven development.<br /> <br /> === Cucumber ===<br /> BDD makes the use of Cucumber for running automated acceptance tests. Cucumber specifies what a user should see and be able to do. Cucumber works with Ruby to help the software development teams describe how an application should behave. Cucumber is intelligible to both software developers as well as domain experts. It can serve both as documentation and automated tests.<br /> <br /> <br /> === RSpec ===<br /> RSpec mainly deals with unit tests which mean testing a class method in isolation from the rest of the application. So it guarantees that the model does what it is supposed to do, the controller does what it is supposed to do, etc. It explains the behavior of objects at the code level. It provides a simple and elegant syntax and works effectively with some other frameworks like [http://rubyonrails.org/ Rails] and [http://mocha.rubyforge.org/ Mocha] library.<br /> <br /> <br /> === RBehave ===<br /> RBehave is a framework based on the story framework from [http://jbehave.org JBehave] which describes behaviour at the application level. It is simpler than RSpec and eliminates the need to reuse code. The choice of frameworks depend on the level of [http://en.wikipedia.org/wiki/Granularity granularity]. RBehave and RSpec are often used as a combination to simplify BDD wordings.<br /> <br /> == References ==<br /> <br /> 1. [http://en.wikipedia.org/wiki/Behavior-driven_development Behavior-driven development]<br /> <br /> 2. [http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd Rules of Test-driven development]<br /> <br /> 3. [http://bob-roberts.net/2012/02/17/608/ Using Rspec and Capybara]<br /> <br /> 4. [http://stackoverflow.com/questions/2509/what-are-the-primary-differences-between-tdd-and-bdd Difference between TDD and BDD]<br /> <br /> 5. [http://www.slideshare.net/IosifItkin/behavior-driven-development-pros-and-cons Benefits of behavior-driven development]<br /> <br /> 6. [http://rorataspire.wordpress.com/2008/06/16/behaviour-driven-development-have-a-definite-edge-in-the-outsourced-software-development/ Lifecycle]<br /> <br /> 7. [http://en.wikipedia.org/wiki/Test-driven_development Test-driven development]<br /> <br /> 8. [http://www.ryangreenhall.com/articles/bdd-by-example.html Examples of BDD]<br /> <br /> 9. [http://cukes.info/ Cucumber info]<br /> <br /> 10. [http://en.wikipedia.org/wiki/Cucumber_(software) Cucumber]<br /> <br /> 11. [http://www.slideshare.net/MarkMenard/behavior-driven-development-with-rails Behavior driven development with Rails]<br /> <br /> 12. [http://codesqueeze.com/the-easy-way-to-writing-good-user-stories/ Writing user stories]<br /> <br /> 13. [http://stackoverflow.com/questions/11762245/whats-the-difference-between-rspec-and-cucumber Difference between RSpec and Cucumber]<br /> <br /> 14. [http://dannorth.net/2007/06/17/introducing-rbehave/ RBehave]</div>

Agoel2 https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/ch1_1w33_aa&diff=79655 2013-10-07T02:57:45Z

<p>Agoel2: </p> <hr /> <div>== Behavior-driven development in Ruby on Rails ==<br /> <br /> Behavior-driven development (also known as BDD) is an agile development strategy that has been derived from Test Driven Development. It was developed by Dan North in order to address the problems faced by TDD. BDD approach focuses on design, documentation and behavior rather than on tests. This approach enables more interactions between the client and the developer. <br /> The client specifies his functional specifications to the developer by writing user stories which describe how the system should perform when a certain condition is met. These user stories are then translated into tests using tools like RSpec and Cucumber. These tests are then run to check whether they satisfy the desired functional behavior. The business requirement is delivered when all the tests pass.<br /> <br /> == Difference from other development strategies ==<br /> === Test-driven development (TDD) ===<br /> Another type of Test Driven Development is Behavior-driven development (also known as TDD). In TDD, software developers write automated test cases before they write any code.<br /> :: • The first step of TDD is to write a failing test for a particular unit of functionality to be added. <br /> <br /> :: • The next step is to write a piece of code only to pass that failing test.<br /> <br /> :: • The last step would be to refactor the code so that it meets the requirement standards of the code.<br /> <br /> [[File:Steps.jpg]]<br /> <br /> Test Driven Development follows three rules. They are:<br /> <br /> :: • One must not write any production code unless it is to make a failing unit test pass.<br /> <br /> :: • One must not write any more of a unit test than is sufficient to fail<br /> <br /> :: • One must not write any more production code than is sufficient to pass the one failing unit test.<br /> <br /> === Difference between TDD and BDD ===<br /> :: • TDD’s main focus is on the tests while BDD mainly focuses on the behavioral specification from the user point of view. <br /> <br /> :: • With TDD, unit tests are written, whereas for BDD tests are written using “User Stories”.<br /> <br /> :: • TDD uses language which is intelligible to only the software programmers.<br /> <br /> :: • BDD uses language which is more easily understood by technical as well as non technical people.<br /> <br /> == Advantages of BDD ==<br /> :: • Due to BDD language being comprehensible by both technical as well as domain experts, the BDD involves the customers and the business partners in writing the scenarios for the tests.<br /> <br /> :: • Unlike tests which come after implementation, focusing on the behavior proves to be a better approach.<br /> <br /> :: • TDD methodology can lead to a number of failed tests before arriving at the correct result because it focuses mainly on implementation. But BDD does not require so many tests as its main focus is behavior thus resulting in less code.<br /> <br /> == Disadvantages of BDD ==<br /> :: • The user stories written by the customers might not be good quality and may have to be rewritten by the developer.<br /> <br /> :: • The customer might not have enough time to review the scenarios on a regular basis.<br /> <br /> == Examples of BDD with Ruby on Rails ==<br /> In BDD, business requirements are identified by user stories. The user stories are described using the following format<br /> <br /> '''As a ''' [role]<br /> '''I can '''[feature] <br /> '''so that '''[reason]<br /> <br /> Example to explain this-<br /> <br /> ''' As a Bank account holder '''<br /> ''' I can login with my credentials '''<br /> ''' so that I can check my account details '''<br /> <br /> <br /> Once the user stories are written, the acceptance tests can be written for the user stories. The acceptance tests have the following format<br /> <br /> ''' Given '''[Context]<br /> ''' When ''' [Event Occurs]<br /> ''' Then ''' [Outcome]<br /> <br /> <br /> <br /> Scenario: Enter a Login Page<br /> <br /> ''' Given I enter a valid username '''<br /> ''' And I enter a valid password '''<br /> ''' When I press the Login Button '''<br /> ''' Then I should be redirected to the home page '''<br /> <br /> These acceptance tests for the user stories are entered in the application as automated tests by the developer. <br /> <br /> == Implementation ==<br /> Ruby on Rails uses various tools like Cucumber, Rspec etc to implement the user tests using Behaviour-driven development.<br /> <br /> === Cucumber ===<br /> BDD makes the use of Cucumber for running automated acceptance tests. Cucumber specifies what a user should see and be able to do. Cucumber works with Ruby to help the software development teams describe how an application should behave. Cucumber is intelligible to both software developers as well as domain experts. It can serve both as documentation and automated tests.<br /> <br /> <br /> === RSpec ===<br /> RSpec mainly deals with unit tests which mean testing a class method in isolation from the rest of the application. So it guarantees that the model does what it is supposed to do, the controller does what it is supposed to do, etc. It explains the behavior of objects at the code level. It provides a simple and elegant syntax and works effectively with some other frameworks like [http://rubyonrails.org/ Rails] and [http://mocha.rubyforge.org/ Mocha] library.<br /> <br /> <br /> === RBehave ===<br /> RBehave is a framework based on the story framework from [http://jbehave.org JBehave] which describes behaviour at the application level. It is simpler than RSpec and eliminates the need to reuse code. The choice of frameworks depend on the level of [http://en.wikipedia.org/wiki/Granularity granularity]. RBehave and RSpec are often used as a combination to simplify BDD wordings.<br /> <br /> == References ==<br /> <br /> 1. [http://en.wikipedia.org/wiki/Behavior-driven_development Behavior-driven development]<br /> <br /> 2. [http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd Rules of Test-driven development]<br /> <br /> 3. [http://bob-roberts.net/2012/02/17/608/ Using Rspec and Capybara]<br /> <br /> 4. [http://stackoverflow.com/questions/2509/what-are-the-primary-differences-between-tdd-and-bdd Difference between TDD and BDD]<br /> <br /> 5. [http://www.slideshare.net/IosifItkin/behavior-driven-development-pros-and-cons Benefits of behavior-driven development]<br /> <br /> 6. [http://rorataspire.wordpress.com/2008/06/16/behaviour-driven-development-have-a-definite-edge-in-the-outsourced-software-development/ Lifecycle]<br /> <br /> 7. [http://en.wikipedia.org/wiki/Test-driven_development Test-driven development]<br /> <br /> 8. [http://www.ryangreenhall.com/articles/bdd-by-example.html Examples of BDD]<br /> <br /> 9. [http://cukes.info/ Cucumber info]<br /> <br /> 10. [http://en.wikipedia.org/wiki/Cucumber_(software) Cucumber]<br /> <br /> 11. [http://www.slideshare.net/MarkMenard/behavior-driven-development-with-rails Behavior driven development with Rails]<br /> <br /> 12. [http://codesqueeze.com/the-easy-way-to-writing-good-user-stories/ Writing user stories]<br /> <br /> 13. [http://stackoverflow.com/questions/11762245/whats-the-difference-between-rspec-and-cucumber Difference between RSpec and Cucumber]<br /> <br /> 14. [http://dannorth.net/2007/06/17/introducing-rbehave/ RBehave]</div>

Agoel2 https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/ch1_1w33_aa&diff=79653 2013-10-07T02:54:22Z

<p>Agoel2: </p> <hr /> <div>== Behavior-driven development in Ruby on Rails ==<br /> <br /> Behavior-driven development (also known as BDD) is an agile development strategy that has been derived from Test Driven Development. It was developed by Dan North in order to address the problems faced by TDD. BDD approach focuses on design, documentation and behavior rather than on tests. This approach enables more interactions between the client and the developer. <br /> The client specifies his functional specifications to the developer by writing user stories which describe how the system should perform when a certain condition is met. These user stories are then translated into tests using tools like RSpec and Cucumber. These tests are then run to check whether they satisfy the desired functional behavior. The business requirement is delivered when all the tests pass.<br /> <br /> == Difference from other development strategies ==<br /> === Test-driven development (TDD) ===<br /> Another type of Test Driven Development is Behavior-driven development (also known as TDD). In TDD, software developers write automated test cases before they write any code.<br /> :: • The first step of TDD is to write a failing test for a particular unit of functionality to be added. <br /> <br /> :: • The next step is to write a piece of code only to pass that failing test.<br /> <br /> :: • The last step would be to refactor the code so that it meets the requirement standards of the code.<br /> <br /> [[File:Steps.jpg]]<br /> <br /> Test Driven Development follows three rules. They are:<br /> <br /> :: • One must not write any production code unless it is to make a failing unit test pass.<br /> <br /> :: • One must not write any more of a unit test than is sufficient to fail<br /> <br /> :: • One must not write any more production code than is sufficient to pass the one failing unit test.<br /> <br /> === Difference between TDD and BDD ===<br /> :: • TDD’s main focus is on the tests while BDD mainly focuses on the behavioral specification from the user point of view. <br /> <br /> :: • With TDD, unit tests are written, whereas for BDD tests are written using “User Stories”.<br /> <br /> :: • TDD uses language which is intelligible to only the software programmers.<br /> <br /> :: • BDD uses language which is more easily understood by technical as well as non technical people.<br /> <br /> == Advantages of BDD ==<br /> :: • Due to BDD language being comprehensible by both technical as well as domain experts, the BDD involves the customers and the business partners in writing the scenarios for the tests.<br /> <br /> :: • Unlike tests which come after implementation, focusing on the behavior proves to be a better approach.<br /> <br /> :: • TDD methodology can lead to a number of failed tests before arriving at the correct result because it focuses mainly on implementation. But BDD does not require so many tests as its main focus is behavior thus resulting in less code.<br /> <br /> == Disadvantages of BDD ==<br /> :: • The user stories written by the customers might not be good quality and may have to be rewritten by the developer.<br /> <br /> :: • The customer might not have enough time to review the scenarios on a regular basis.<br /> <br /> == Examples of BDD with Ruby on Rails ==<br /> In BDD, business requirements are identified by user stories. The user stories are described using the following format<br /> <br /> '''As a ''' [role]<br /> '''I can '''[feature] <br /> '''so that '''[reason]<br /> <br /> Example to explain this-<br /> <br /> ''' As a Bank account holder '''<br /> ''' I can login with my credentials '''<br /> ''' so that I can check my account details '''<br /> <br /> <br /> Once the user stories are written, the acceptance tests can be written for the user stories. The acceptance tests have the following format<br /> <br /> ''' Given '''[Context]<br /> ''' When ''' [Event Occurs]<br /> ''' Then ''' [Outcome]<br /> <br /> <br /> <br /> Scenario: Enter a Login Page<br /> <br /> ''' Given I enter a valid username '''<br /> ''' And I enter a valid password '''<br /> ''' When I press the Login Button '''<br /> ''' Then I should be redirected to the home page '''<br /> <br /> These acceptance tests for the user stories are entered in the application as automated tests by the developer. <br /> <br /> == Implementation ==<br /> Ruby on Rails uses various tools like Cucumber, Rspec etc to implement the user tests using Behaviour-driven development.<br /> <br /> === Cucumber ===<br /> BDD makes the use of Cucumber for running automated acceptance tests. Cucumber specifies what a user should see and be able to do. Cucumber works with Ruby to help the software development teams describe how an application should behave. Cucumber is intelligible to both software developers as well as domain experts. It can serve both as documentation and automated tests.<br /> <br /> <br /> === RSpec ===<br /> RSpec mainly deals with unit tests which mean testing a class method in isolation from the rest of the application. So it guarantees that the model does what it is supposed to do, the controller does what it is supposed to do, etc. It explains the behavior of objects at the code level. It provides a simple and elegant syntax and works effectively with some other frameworks like [http://rubyonrails.org/ Rails] and [http://mocha.rubyforge.org/ Mocha] library.<br /> <br /> <br /> === RBehave ===<br /> RBehave is a framework based on the story framework from [http://jbehave.org JBehave] which describes behaviour at the application level. It is simpler than RSpec and eliminates the need to reuse code. The choice of frameworks depend on the level of [http://en.wikipedia.org/wiki/Granularity granularity]<br /> <br /> == References ==<br /> <br /> 1. [http://en.wikipedia.org/wiki/Behavior-driven_development Behavior-driven development]<br /> <br /> 2. [http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd Rules of Test-driven development]<br /> <br /> 3. [http://bob-roberts.net/2012/02/17/608/ Using Rspec and Capybara]<br /> <br /> 4. [http://stackoverflow.com/questions/2509/what-are-the-primary-differences-between-tdd-and-bdd Difference between TDD and BDD]<br /> <br /> 5. [http://www.slideshare.net/IosifItkin/behavior-driven-development-pros-and-cons Benefits of behavior-driven development]<br /> <br /> 6. [http://rorataspire.wordpress.com/2008/06/16/behaviour-driven-development-have-a-definite-edge-in-the-outsourced-software-development/ Lifecycle]<br /> <br /> 7. [http://en.wikipedia.org/wiki/Test-driven_development Test-driven development]<br /> <br /> 8. [http://www.ryangreenhall.com/articles/bdd-by-example.html Examples of BDD]<br /> <br /> 9. [http://cukes.info/ Cucumber info]<br /> <br /> 10. [http://en.wikipedia.org/wiki/Cucumber_(software) Cucumber]<br /> <br /> 11. [http://www.slideshare.net/MarkMenard/behavior-driven-development-with-rails Behavior driven development with Rails]<br /> <br /> 12. [http://codesqueeze.com/the-easy-way-to-writing-good-user-stories/ Writing user stories]<br /> <br /> 13. [http://stackoverflow.com/questions/11762245/whats-the-difference-between-rspec-and-cucumber Difference between RSpec and Cucumber]<br /> <br /> 14. [http://dannorth.net/2007/06/17/introducing-rbehave/ RBehave]</div>

Agoel2 https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/ch1_1w33_aa&diff=79651 2013-10-07T02:51:39Z

<p>Agoel2: </p> <hr /> <div>== Behavior-driven development in Ruby on Rails ==<br /> <br /> Behavior-driven development (also known as BDD) is an agile development strategy that has been derived from Test Driven Development. It was developed by Dan North in order to address the problems faced by TDD. BDD approach focuses on design, documentation and behavior rather than on tests. This approach enables more interactions between the client and the developer. <br /> The client specifies his functional specifications to the developer by writing user stories which describe how the system should perform when a certain condition is met. These user stories are then translated into tests using tools like RSpec and Cucumber. These tests are then run to check whether they satisfy the desired functional behavior. The business requirement is delivered when all the tests pass.<br /> <br /> == Difference from other development strategies ==<br /> === Test-driven development (TDD) ===<br /> Another type of Test Driven Development is Behavior-driven development (also known as TDD). In TDD, software developers write automated test cases before they write any code.<br /> :: • The first step of TDD is to write a failing test for a particular unit of functionality to be added. <br /> <br /> :: • The next step is to write a piece of code only to pass that failing test.<br /> <br /> :: • The last step would be to refactor the code so that it meets the requirement standards of the code.<br /> <br /> [[File:Steps.jpg]]<br /> <br /> Test Driven Development follows three rules. They are:<br /> <br /> :: • One must not write any production code unless it is to make a failing unit test pass.<br /> <br /> :: • One must not write any more of a unit test than is sufficient to fail<br /> <br /> :: • One must not write any more production code than is sufficient to pass the one failing unit test.<br /> <br /> === Difference between TDD and BDD ===<br /> :: • TDD’s main focus is on the tests while BDD mainly focuses on the behavioral specification from the user point of view. <br /> <br /> :: • With TDD, unit tests are written, whereas for BDD tests are written using “User Stories”.<br /> <br /> :: • TDD uses language which is intelligible to only the software programmers.<br /> <br /> :: • BDD uses language which is more easily understood by technical as well as non technical people.<br /> <br /> == Advantages of BDD ==<br /> :: • Due to BDD language being comprehensible by both technical as well as domain experts, the BDD involves the customers and the business partners in writing the scenarios for the tests.<br /> <br /> :: • Unlike tests which come after implementation, focusing on the behavior proves to be a better approach.<br /> <br /> :: • TDD methodology can lead to a number of failed tests before arriving at the correct result because it focuses mainly on implementation. But BDD does not require so many tests as its main focus is behavior thus resulting in less code.<br /> <br /> == Disadvantages of BDD ==<br /> :: • The user stories written by the customers might not be good quality and may have to be rewritten by the developer.<br /> <br /> :: • The customer might not have enough time to review the scenarios on a regular basis.<br /> <br /> == Examples of BDD with Ruby on Rails ==<br /> In BDD, business requirements are identified by user stories. The user stories are described using the following format<br /> <br /> '''As a ''' [role]<br /> '''I can '''[feature] <br /> '''so that '''[reason]<br /> <br /> Example to explain this-<br /> <br /> ''' As a Bank account holder '''<br /> ''' I can login with my credentials '''<br /> ''' so that I can check my account details '''<br /> <br /> <br /> Once the user stories are written, the acceptance tests can be written for the user stories. The acceptance tests have the following format<br /> <br /> ''' Given '''[Context]<br /> ''' When ''' [Event Occurs]<br /> ''' Then ''' [Outcome]<br /> <br /> <br /> <br /> Scenario: Enter a Login Page<br /> <br /> ''' Given I enter a valid username '''<br /> ''' And I enter a valid password '''<br /> ''' When I press the Login Button '''<br /> ''' Then I should be redirected to the home page '''<br /> <br /> These acceptance tests for the user stories are entered in the application as automated tests by the developer. <br /> <br /> == Implementation ==<br /> Ruby on Rails uses various tools like Cucumber, Rspec etc to implement the user tests using Behaviour-driven development.<br /> <br /> === Cucumber ===<br /> BDD makes the use of Cucumber for running automated acceptance tests. Cucumber specifies what a user should see and be able to do. Cucumber works with Ruby to help the software development teams describe how an application should behave. Cucumber is intelligible to both software developers as well as domain experts. It can serve both as documentation and automated tests.<br /> <br /> <br /> === RSpec ===<br /> RSpec mainly deals with unit tests which mean testing a class method in isolation from the rest of the application. So it guarantees that the model does what it is supposed to do, the controller does what it is supposed to do, etc. It explains the behavior of objects at the code level. It provides a simple and elegant syntax and works effectively with some other frameworks like [http://rubyonrails.org/ Rails] and [http://mocha.rubyforge.org/ Mocha] library.<br /> <br /> <br /> === RBehave ===<br /> RBehave is a framework based on the story framework from [http://jbehave.org JBehave] which describes behaviour at the application level. It is simpler than RSpec and eliminates the need to reuse code. The choice of frameworks depend on the level of [http://en.wikipedia.org/wiki/Granularity granularity]<br /> <br /> == References ==<br /> <br /> 1. [http://en.wikipedia.org/wiki/Behavior-driven_development Behavior-driven development]<br /> <br /> 2. [http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd Rules of Test-driven development]<br /> <br /> 3. [http://bob-roberts.net/2012/02/17/608/ Using Rspec and Capybara]<br /> <br /> 4. [http://stackoverflow.com/questions/2509/what-are-the-primary-differences-between-tdd-and-bdd Difference between TDD and BDD]<br /> <br /> 5. [http://www.slideshare.net/IosifItkin/behavior-driven-development-pros-and-cons Benefits of behavior-driven development]<br /> <br /> 6. [http://rorataspire.wordpress.com/2008/06/16/behaviour-driven-development-have-a-definite-edge-in-the-outsourced-software-development/ Lifecycle]<br /> <br /> 7. [http://en.wikipedia.org/wiki/Test-driven_development Test-driven development]<br /> <br /> 8. [http://www.ryangreenhall.com/articles/bdd-by-example.html Examples of BDD]<br /> <br /> 9. [http://cukes.info/ Cucumber info]<br /> <br /> 10. [http://en.wikipedia.org/wiki/Cucumber_(software) Cucumber]<br /> <br /> 11. [http://www.slideshare.net/MarkMenard/behavior-driven-development-with-rails Behavior driven development with Rails]<br /> <br /> 12. [http://codesqueeze.com/the-easy-way-to-writing-good-user-stories/ Writing user stories]<br /> <br /> 13. [http://stackoverflow.com/questions/11762245/whats-the-difference-between-rspec-and-cucumber Difference between RSpec and Cucumber]<br /> <br /> 14. [http://www.infoq.com/news/2007/10/RSpec-incorporates-RBehave RSpec incorporates RBehave]</div>

Agoel2 https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/ch1_1w33_aa&diff=79644 2013-10-07T02:35:19Z

<p>Agoel2: </p> <hr /> <div>== Behavior-driven development in Ruby on Rails ==<br /> <br /> Behavior-driven development (also known as BDD) is an agile development strategy that has been derived from Test Driven Development. It was developed by Dan North in order to address the problems faced by TDD. BDD approach focuses on design, documentation and behavior rather than on tests. This approach enables more interactions between the client and the developer. <br /> The client specifies his functional specifications to the developer by writing user stories which describe how the system should perform when a certain condition is met. These user stories are then translated into tests using tools like RSpec and Cucumber. These tests are then run to check whether they satisfy the desired functional behavior. The business requirement is delivered when all the tests pass.<br /> <br /> == Difference from other development strategies ==<br /> === Test-driven development (TDD) ===<br /> Another type of Test Driven Development is Behavior-driven development (also known as TDD). In TDD, software developers write automated test cases before they write any code.<br /> :: • The first step of TDD is to write a failing test for a particular unit of functionality to be added. <br /> <br /> :: • The next step is to write a piece of code only to pass that failing test.<br /> <br /> :: • The last step would be to refactor the code so that it meets the requirement standards of the code.<br /> <br /> [[File:Steps.jpg]]<br /> <br /> Test Driven Development follows three rules. They are:<br /> <br /> :: • One must not write any production code unless it is to make a failing unit test pass.<br /> <br /> :: • One must not write any more of a unit test than is sufficient to fail<br /> <br /> :: • One must not write any more production code than is sufficient to pass the one failing unit test.<br /> <br /> === Difference between TDD and BDD ===<br /> :: • TDD’s main focus is on the tests while BDD mainly focuses on the behavioral specification from the user point of view. <br /> <br /> :: • With TDD, unit tests are written, whereas for BDD tests are written using “User Stories”.<br /> <br /> :: • TDD uses language which is intelligible to only the software programmers.<br /> <br /> :: • BDD uses language which is more easily understood by technical as well as non technical people.<br /> <br /> == Advantages of BDD ==<br /> :: • Due to BDD language being comprehensible by both technical as well as domain experts, the BDD involves the customers and the business partners in writing the scenarios for the tests.<br /> <br /> :: • Unlike tests which come after implementation, focusing on the behavior proves to be a better approach.<br /> <br /> :: • TDD methodology can lead to a number of failed tests before arriving at the correct result because it focuses mainly on implementation. But BDD does not require so many tests as its main focus is behavior thus resulting in less code.<br /> <br /> == Disadvantages of BDD ==<br /> :: • The user stories written by the customers might not be good quality and may have to be rewritten by the developer.<br /> <br /> :: • The customer might not have enough time to review the scenarios on a regular basis.<br /> <br /> == Examples of BDD with Ruby on Rails ==<br /> In BDD, business requirements are identified by user stories. The user stories are described using the following format<br /> <br /> '''As a ''' [role]<br /> '''I can '''[feature] <br /> '''so that '''[reason]<br /> <br /> Example to explain this-<br /> <br /> ''' As a Bank account holder '''<br /> ''' I can login with my credentials '''<br /> ''' so that I can check my account details '''<br /> <br /> <br /> Once the user stories are written, the acceptance tests can be written for the user stories. The acceptance tests have the following format<br /> <br /> ''' Given '''[Context]<br /> ''' When ''' [Event Occurs]<br /> ''' Then ''' [Outcome]<br /> <br /> <br /> <br /> Scenario: Enter a Login Page<br /> <br /> ''' Given I enter a valid username '''<br /> ''' And I enter a valid password '''<br /> ''' When I press the Login Button '''<br /> ''' Then I should be redirected to the home page '''<br /> <br /> These acceptance tests for the user stories are entered in the application as automated tests by the developer. <br /> <br /> == Implementation ==<br /> Ruby on Rails uses various tools like Cucumber, Rspec etc to implement the user tests.<br /> <br /> === Cucumber ===<br /> BDD makes the use of Cucumber for running automated acceptance tests. Cucumber specifies what a user should see and be able to do. Cucumber works with Ruby to help the software development teams describe how an application should behave. Cucumber is intelligible to both software developers as well as domain experts. It can serve both as documentation and automated tests.<br /> <br /> <br /> === RSpec ===<br /> RSpec mainly deals with unit tests which mean testing a class method in isolation from the rest of the application. So it guarantees that the model does what it is supposed to do, the controller does what it is supposed to do, etc. It explains the behavior of objects at the code level. It provides a simple and elegant syntax and works effectively with some other frameworks like [http://rubyonrails.org/ Rails] and [http://mocha.rubyforge.org/ Mocha] library.<br /> <br /> <br /> == References ==<br /> <br /> 1. [http://en.wikipedia.org/wiki/Behavior-driven_development Behavior-driven development]<br /> <br /> 2. [http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd Rules of Test-driven development]<br /> <br /> 3. [http://bob-roberts.net/2012/02/17/608/ Using Rspec and Capybara]<br /> <br /> 4. [http://stackoverflow.com/questions/2509/what-are-the-primary-differences-between-tdd-and-bdd Difference between TDD and BDD]<br /> <br /> 5. [http://www.slideshare.net/IosifItkin/behavior-driven-development-pros-and-cons Benefits of behavior-driven development]<br /> <br /> 6. [http://rorataspire.wordpress.com/2008/06/16/behaviour-driven-development-have-a-definite-edge-in-the-outsourced-software-development/ Lifecycle]<br /> <br /> 7. [http://en.wikipedia.org/wiki/Test-driven_development Test-driven development]<br /> <br /> 8. [http://www.ryangreenhall.com/articles/bdd-by-example.html Examples of BDD]<br /> <br /> 9. [http://cukes.info/ Cucumber info]<br /> <br /> 10. [http://en.wikipedia.org/wiki/Cucumber_(software) Cucumber]<br /> <br /> 11. [http://www.slideshare.net/MarkMenard/behavior-driven-development-with-rails Behavior driven development with Rails]<br /> <br /> 12. [http://codesqueeze.com/the-easy-way-to-writing-good-user-stories/ Writing user stories]<br /> <br /> 13. [http://stackoverflow.com/questions/11762245/whats-the-difference-between-rspec-and-cucumber Difference between RSpec and Cucumber]</div>

Agoel2 https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/ch1_1w33_aa&diff=79643 2013-10-07T02:30:35Z

<p>Agoel2: </p> <hr /> <div>== Behavior-driven development in Ruby on Rails ==<br /> <br /> Behavior-driven development (also known as BDD) is an agile development strategy that has been derived from Test Driven Development. It was developed by Dan North in order to address the problems faced by TDD. BDD approach focuses on design, documentation and behavior rather than on tests. This approach enables more interactions between the client and the developer. <br /> The client specifies his functional specifications to the developer by writing user stories which describe how the system should perform when a certain condition is met. These user stories are then translated into tests using tools like RSpec and Cucumber. These tests are then run to check whether they satisfy the desired functional behavior. The business requirement is delivered when all the tests pass.<br /> <br /> == Difference from other development strategies ==<br /> === Test-driven development (TDD) ===<br /> Another type of Test Driven Development is Behavior-driven development (also known as TDD). In TDD, software developers write automated test cases before they write any code.<br /> :: • The first step of TDD is to write a failing test for a particular unit of functionality to be added. <br /> <br /> :: • The next step is to write a piece of code only to pass that failing test.<br /> <br /> :: • The last step would be to refactor the code so that it meets the requirement standards of the code.<br /> <br /> [[File:Steps.jpg]]<br /> <br /> Test Driven Development follows three rules. They are:<br /> <br /> :: • One must not write any production code unless it is to make a failing unit test pass.<br /> <br /> :: • One must not write any more of a unit test than is sufficient to fail<br /> <br /> :: • One must not write any more production code than is sufficient to pass the one failing unit test.<br /> <br /> === Difference between TDD and BDD ===<br /> :: • TDD’s main focus is on the tests while BDD mainly focuses on the behavioral specification from the user point of view. <br /> <br /> :: • With TDD, unit tests are written, whereas for BDD tests are written using “User Stories”.<br /> <br /> :: • TDD uses language which is intelligible to only the software programmers.<br /> <br /> :: • BDD uses language which is more easily understood by technical as well as non technical people.<br /> <br /> == Advantages of BDD ==<br /> :: • Due to BDD language being comprehensible by both technical as well as domain experts, the BDD involves the customers and the business partners in writing the scenarios for the tests.<br /> <br /> :: • Unlike tests which come after implementation, focusing on the behavior proves to be a better approach.<br /> <br /> :: • TDD methodology can lead to a number of failed tests before arriving at the correct result because it focuses mainly on implementation. But BDD does not require so many tests as its main focus is behavior thus resulting in less code.<br /> <br /> == Disadvantages of BDD ==<br /> :: • The user stories written by the customers might not be good quality and may have to be rewritten by the developer.<br /> <br /> :: • The customer might not have enough time to review the scenarios on a regular basis.<br /> <br /> == Examples of BDD with Ruby on Rails ==<br /> In BDD, business requirements are identified by user stories. The user stories are described using the following format<br /> <br /> '''As a ''' [role]<br /> '''I can '''[feature] <br /> '''so that '''[reason]<br /> <br /> Example to explain this-<br /> <br /> ''' As a Bank account holder '''<br /> ''' I can login with my credentials '''<br /> ''' so that I can check my account details '''<br /> <br /> <br /> Once the user stories are written, the acceptance tests can be written for the user stories. The acceptance tests have the following format<br /> <br /> ''' Given '''[Context]<br /> ''' When ''' [Event Occurs]<br /> ''' Then ''' [Outcome]<br /> <br /> <br /> <br /> Scenario: Enter a Login Page<br /> <br /> ''' Given I enter a valid username '''<br /> ''' And I enter a valid password '''<br /> ''' When I press the Login Button '''<br /> ''' Then I should be redirected to the home page '''<br /> <br /> These acceptance tests for the user stories are entered in the application as automated tests by the developer. <br /> <br /> == Implementation ==<br /> Ruby on Rails uses various tools like Cucumber, Rspec etc to implement the user tests.<br /> <br /> === Cucumber ===<br /> BDD makes the use of Cucumber for running automated acceptance tests. Cucumber specifies what a user should see and be able to do. Cucumber works with Ruby to help the software development teams describe how an application should behave. Cucumber is intelligible to both software developers as well as domain experts. It can serve both as documentation and automated tests.<br /> <br /> <br /> === RSpec ===<br /> RSpec mainly deals with unit tests which mean testing a class method in isolation from the rest of the application. So it guarantees that the model does what it is supposed to do, the controller does what it is supposed to do, etc.<br /> <br /> <br /> == References ==<br /> <br /> 1. [http://en.wikipedia.org/wiki/Behavior-driven_development Behavior-driven development]<br /> <br /> 2. [http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd Rules of Test-driven development]<br /> <br /> 3. [http://bob-roberts.net/2012/02/17/608/ Using Rspec and Capybara]<br /> <br /> 4. [http://stackoverflow.com/questions/2509/what-are-the-primary-differences-between-tdd-and-bdd Difference between TDD and BDD]<br /> <br /> 5. [http://www.slideshare.net/IosifItkin/behavior-driven-development-pros-and-cons Benefits of behavior-driven development]<br /> <br /> 6. [http://rorataspire.wordpress.com/2008/06/16/behaviour-driven-development-have-a-definite-edge-in-the-outsourced-software-development/ Lifecycle]<br /> <br /> 7. [http://en.wikipedia.org/wiki/Test-driven_development Test-driven development]<br /> <br /> 8. [http://www.ryangreenhall.com/articles/bdd-by-example.html Examples of BDD]<br /> <br /> 9. [http://cukes.info/ Cucumber info]<br /> <br /> 10. [http://en.wikipedia.org/wiki/Cucumber_(software) Cucumber]<br /> <br /> 11. [http://www.slideshare.net/MarkMenard/behavior-driven-development-with-rails Behavior driven development with Rails]<br /> <br /> 12. [http://codesqueeze.com/the-easy-way-to-writing-good-user-stories/ Writing user stories]<br /> <br /> 13. [http://stackoverflow.com/questions/11762245/whats-the-difference-between-rspec-and-cucumber Difference between RSpec and Cucumber]</div>

Agoel2 https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/ch1_1w33_aa&diff=79457 2013-10-06T16:49:21Z

<p>Agoel2: </p> <hr /> <div>== Behavior-driven development in Ruby on Rails ==<br /> <br /> Behavior-driven development (also known as BDD) is an agile development strategy that has been derived from Test Driven Development. It was developed by Dan North in order to address the problems faced by TDD. BDD approach focuses on design, documentation and behavior rather than on tests. This approach enables more interactions between the client and the developer. <br /> The client specifies his functional specifications to the developer by writing user stories which describe how the system should perform when a certain condition is met. These user stories are then translated into tests using tools like RSpec and Cucumber. These tests are then run to check whether they satisfy the desired functional behavior. The business requirement is delivered when all the tests pass.<br /> <br /> == Difference from other development strategies ==<br /> === Test-driven development (TDD) ===<br /> Another type of Test Driven Development is Behavior-driven development (also known as TDD). In TDD, software developers write automated test cases before they write any code.<br /> :: • The first step of TDD is to write a failing test for a particular unit of functionality to be added. <br /> <br /> :: • The next step is to write a piece of code only to pass that failing test.<br /> <br /> :: • The last step would be to refactor the code so that it meets the requirement standards of the code.<br /> <br /> [[File:Steps.jpg]]<br /> <br /> Test Driven Development follows three rules. They are:<br /> <br /> :: • One must not write any production code unless it is to make a failing unit test pass.<br /> <br /> :: • One must not write any more of a unit test than is sufficient to fail<br /> <br /> :: • One must not write any more production code than is sufficient to pass the one failing unit test.<br /> <br /> === Difference between TDD and BDD ===<br /> :: • TDD’s main focus is on the tests while BDD mainly focuses on the behavioral specification from the user point of view. <br /> <br /> :: • With TDD, unit tests are written, whereas for BDD tests are written using “User Stories”.<br /> <br /> :: • TDD uses language which is intelligible to only the software programmers.<br /> <br /> BDD uses language which is more easily understood by technical as well as non technical people.<br /> <br /> == Advantages of BDD ==<br /> :: • Due to BDD language being comprehensible by both technical as well as domain experts, the BDD involves the customers and the business partners in writing the scenarios for the tests.<br /> <br /> :: • Unlike tests which come after implementation, focusing on the behavior proves to be a better approach.<br /> <br /> :: • TDD methodology can lead to a number of failed tests before arriving at the correct result because it focuses mainly on implementation. But BDD does not require so many tests as its main focus is behavior thus resulting in less code.<br /> <br /> == Disadvantages of BDD ==<br /> :: • The user stories written by the customers might not be good quality and may have to be rewritten by the developer.<br /> <br /> :: • The customer might not have enough time to review the scenarios on a regular basis.<br /> <br /> == Examples of BDD with Ruby on Rails ==<br /> In BDD, business requirements are identified by user stories. The user stories are described using the following format<br /> <br /> '''As a ''' [role]<br /> '''I can '''[feature] <br /> '''so that '''[reason]<br /> <br /> Example to explain this-<br /> <br /> ''' As a Bank account holder '''<br /> ''' I can login with my credentials '''<br /> ''' so that I can check my account details '''<br /> <br /> <br /> Once the user stories are written, the acceptance tests can be written for the user stories. The acceptance tests have the following format<br /> <br /> ''' Given '''[Context]<br /> ''' When ''' [Event Occurs]<br /> ''' Then ''' [Outcome]<br /> <br /> <br /> <br /> Scenario: Enter a Login Page<br /> <br /> ''' Given I enter a valid username '''<br /> ''' And I enter a valid password '''<br /> ''' When I press the Login Button '''<br /> ''' Then I should be redirected to the home page '''<br /> <br /> These acceptance tests for the user stories are entered in the application as automated tests by the developer. <br /> <br /> == Implementation ==<br /> Ruby on Rails uses various tools like Cucumber, Rspec etc to implement the user tests.<br /> <br /> === Cucumber ===<br /> BDD makes the use of Cucumber for running automated acceptance tests. Cucumber specifies what a user should see and be able to do. Cucumber works with Ruby to help the software development teams describe how an application should behave. Cucumber is intelligible to both software developers as well as domain experts. It can serve both as documentation and automated tests.<br /> <br /> <br /> === RSpec ===<br /> RSpec mainly deals with unit tests which mean testing a class method in isolation from the rest of the application. So it guarantees that the model does what it is supposed to do, the controller does what it is supposed to do, etc.<br /> [[File:BDD.jpg]]<br /> <br /> == References ==<br /> <br /> 1. [http://en.wikipedia.org/wiki/Behavior-driven_development Behavior-driven development]<br /> <br /> 2. [http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd Rules of Test-driven development]<br /> <br /> 3. [http://bob-roberts.net/2012/02/17/608/ Using Rspec and Capybara]<br /> <br /> 4. [http://stackoverflow.com/questions/2509/what-are-the-primary-differences-between-tdd-and-bdd Difference between TDD and BDD]<br /> <br /> 5. [http://www.slideshare.net/IosifItkin/behavior-driven-development-pros-and-cons Benefits of behavior-driven development]<br /> <br /> 6. [http://rorataspire.wordpress.com/2008/06/16/behaviour-driven-development-have-a-definite-edge-in-the-outsourced-software-development/ Lifecycle]<br /> <br /> 7. [http://en.wikipedia.org/wiki/Test-driven_development Test-driven development]<br /> <br /> 8. [http://www.ryangreenhall.com/articles/bdd-by-example.html Examples of BDD]<br /> <br /> 9. [http://cukes.info/ Cucumber info]<br /> <br /> 10. [http://en.wikipedia.org/wiki/Cucumber_(software) Cucumber]<br /> <br /> 11. [http://www.slideshare.net/MarkMenard/behavior-driven-development-with-rails Behavior driven development with Rails]<br /> <br /> 12. [http://codesqueeze.com/the-easy-way-to-writing-good-user-stories/ Writing user stories]<br /> <br /> 13. [http://stackoverflow.com/questions/11762245/whats-the-difference-between-rspec-and-cucumber Difference between RSpec and Cucumber]</div>

Agoel2 https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/ch1_1w33_aa&diff=79455 2013-10-06T16:38:53Z

<p>Agoel2: </p> <hr /> <div>== Behavior-driven development in Ruby on Rails ==<br /> <br /> Behavior-driven development (also known as BDD) is an agile development strategy that has been derived from Test Driven Development. It was developed by Dan North in order to address the problems faced by TDD. BDD approach focuses on design, documentation and behavior rather than on tests. This approach enables more interactions between the client and the developer. <br /> The client specifies his functional specifications to the developer by writing user stories which describe how the system should perform when a certain condition is met. These user stories are then translated into tests using tools like RSpec and Cucumber. These tests are then run to check whether they satisfy the desired functional behavior. The business requirement is delivered when all the tests pass.<br /> <br /> == Difference from other development strategies ==<br /> === Test-driven development (TDD) ===<br /> Another type of Test Driven Development is Behavior-driven development (also known as TDD). In TDD, software developers write automated test cases before they write any code.<br /> :: • The first step of TDD is to write a failing test for a particular unit of functionality to be added. <br /> <br /> :: • The next step is to write a piece of code only to pass that failing test.<br /> <br /> :: • The last step would be to refactor the code so that it meets the requirement standards of the code.<br /> <br /> [[File:Steps.jpg]]<br /> <br /> Test Driven Development follows three rules. They are:<br /> <br /> :: • One must not write any production code unless it is to make a failing unit test pass.<br /> <br /> :: • One must not write any more of a unit test than is sufficient to fail<br /> <br /> :: • One must not write any more production code than is sufficient to pass the one failing unit test.<br /> <br /> === Difference between TDD and BDD ===<br /> :: • TDD’s main focus is on the tests while BDD mainly focuses on the behavioral specification from the user point of view. <br /> <br /> :: • With TDD, unit tests are written, whereas for BDD tests are written using “User Stories”.<br /> <br /> :: • TDD uses language which is intelligible to only the software programmers.<br /> <br /> BDD uses language which is more easily understood by technical as well as non technical people.<br /> <br /> == Advantages of BDD ==<br /> :: • Due to BDD language being comprehensible by both technical as well as domain experts, the BDD involves the customers and the business partners in writing the scenarios for the tests.<br /> <br /> :: • Unlike tests which come after implementation, focusing on the behavior proves to be a better approach.<br /> <br /> :: • TDD methodology can lead to a number of failed tests before arriving at the correct result because it focuses mainly on implementation. But BDD does not require so many tests as its main focus is behavior thus resulting in less code.<br /> <br /> == Disadvantages of BDD ==<br /> :: • The user stories written by the customers might not be good quality and may have to be rewritten by the developer.<br /> <br /> :: • The customer might not have enough time to review the scenarios on a regular basis.<br /> <br /> == Examples of BDD with Ruby on Rails ==<br /> In BDD, business requirements are identified by user stories. The user stories are described using the following format<br /> <br /> '''As a [role], I can [feature] so that [reason]'''<br /> <br /> Example to explain this-<br /> <br /> ''' As a Bank account holder, I can login with my credentials so that I can check my account details '''<br /> <br /> <br /> Once the user stories are written, the acceptance tests can be written for the user stories. The acceptance tests have the following format<br /> <br /> ''' Given '''[Context]<br /> ''' When ''' [Event Occurs]<br /> ''' Then ''' [Outcome]<br /> <br /> <br /> <br /> Scenario: Enter a Login Page<br /> <br /> ''' Given I enter a valid username '''<br /> ''' And I enter a valid password '''<br /> ''' When I press the Login Button '''<br /> ''' Then I should be redirected to the home page '''<br /> <br /> These acceptance tests for the user stories are entered in the application as automated tests by the developer. <br /> <br /> == Implementation ==<br /> Ruby on Rails uses various tools like Cucumber, Rspec etc to implement the user tests.<br /> <br /> === Cucumber ===<br /> BDD makes the use of Cucumber for running automated acceptance tests. Cucumber specifies what a user should see and be able to do. Cucumber works with Ruby to help the software development teams describe how an application should behave. Cucumber is intelligible to both software developers as well as domain experts. It can serve both as documentation and automated tests.<br /> <br /> <br /> === RSpec ===<br /> RSpec mainly deals with unit tests which mean testing a class method in isolation from the rest of the application. So it guarantees that the model does what it is supposed to do, the controller does what it is supposed to do, etc.<br /> [[File:BDD.jpg]]<br /> <br /> == References ==<br /> <br /> 1. [http://en.wikipedia.org/wiki/Behavior-driven_development Behavior-driven development]<br /> <br /> 2. [http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd Rules of Test-driven development]<br /> <br /> 3. [http://bob-roberts.net/2012/02/17/608/ Using Rspec and Capybara]<br /> <br /> 4. [http://stackoverflow.com/questions/2509/what-are-the-primary-differences-between-tdd-and-bdd Difference between TDD and BDD]<br /> <br /> 5. [http://www.slideshare.net/IosifItkin/behavior-driven-development-pros-and-cons Benefits of behavior-driven development]<br /> <br /> 6. [http://rorataspire.wordpress.com/2008/06/16/behaviour-driven-development-have-a-definite-edge-in-the-outsourced-software-development/ Lifecycle]<br /> <br /> 7. [http://en.wikipedia.org/wiki/Test-driven_development Test-driven development]<br /> <br /> 8. [http://www.ryangreenhall.com/articles/bdd-by-example.html Examples of BDD]<br /> <br /> 9. [http://cukes.info/ Cucumber info]<br /> <br /> 10. [http://en.wikipedia.org/wiki/Cucumber_(software) Cucumber]<br /> <br /> 11. [http://www.slideshare.net/MarkMenard/behavior-driven-development-with-rails Behavior driven development with Rails]<br /> <br /> 12. [http://codesqueeze.com/the-easy-way-to-writing-good-user-stories/ Writing user stories]<br /> <br /> 13. [http://stackoverflow.com/questions/11762245/whats-the-difference-between-rspec-and-cucumber Difference between RSpec and Cucumber]</div>

Agoel2 https://wiki.expertiza.ncsu.edu/index.php?title=File:BDD.jpg&diff=79454 2013-10-06T16:12:48Z

<p>Agoel2: uploaded a new version of &amp;quot;File:BDD.jpg&amp;quot;</p> <hr /> <div></div>

Agoel2 https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/ch1_1w33_aa&diff=79453 2013-10-06T16:11:36Z

<p>Agoel2: /* Test-driven development (TDD) */</p> <hr /> <div>== Behavior-driven development in Ruby on Rails ==<br /> <br /> Behavior-driven development (also known as BDD) is an agile development strategy that has been derived from Test Driven Development. It was developed by Dan North in order to address the problems faced by TDD. BDD approach focuses on design, documentation and behavior rather than on tests. This approach enables more interactions between the client and the developer. <br /> The client specifies his functional specifications to the developer by writing user stories which describe how the system should perform when a certain condition is met. These user stories are then translated into tests using tools like RSpec and Cucumber. These tests are then run to check whether they satisfy the desired functional behavior. The business requirement is delivered when all the tests pass.<br /> <br /> == Difference from other development strategies ==<br /> === Test-driven development (TDD) ===<br /> Another type of Test Driven Development is Behavior-driven development (also known as TDD). In TDD, software developers write automated test cases before they write any code.<br /> :: • The first step of TDD is to write a failing test for a particular unit of functionality to be added. <br /> <br /> :: • The next step is to write a piece of code only to pass that failing test.<br /> <br /> :: • The last step would be to refactor the code so that it meets the requirement standards of the code.<br /> <br /> [[File:Steps.jpg]]<br /> <br /> Test Driven Development follows three rules. They are:<br /> <br /> :: • One must not write any production code unless it is to make a failing unit test pass.<br /> <br /> :: • One must not write any more of a unit test than is sufficient to fail<br /> <br /> :: • One must not write any more production code than is sufficient to pass the one failing unit test.<br /> <br /> === Difference between TDD and BDD ===<br /> :: • TDD’s main focus is on the tests while BDD mainly focuses on the behavioral specification from the user point of view. <br /> <br /> :: • With TDD, unit tests are written, whereas for BDD tests are written using “User Stories”.<br /> <br /> :: • TDD uses language which is intelligible to only the software programmers.<br /> <br /> BDD uses language which is more easily understood by technical as well as non technical people.<br /> <br /> == Advantages of BDD ==<br /> :: • Due to BDD language being comprehensible by both technical as well as domain experts, the BDD involves the customers and the business partners in writing the scenarios for the tests.<br /> <br /> :: • Unlike tests which come after implementation, focusing on the behavior proves to be a better approach.<br /> <br /> :: • TDD methodology can lead to a number of failed tests before arriving at the correct result because it focuses mainly on implementation. But BDD does not require so many tests as its main focus is behavior thus resulting in less code.<br /> <br /> == Disadvantages of BDD ==<br /> :: • The user stories written by the customers might not be good quality and may have to be rewritten by the developer.<br /> <br /> :: • The customer might not have enough time to review the scenarios on a regular basis.<br /> <br /> == Examples of BDD with Ruby on Rails ==<br /> In BDD, business requirements are identified by user stories. The user stories are described using the following format<br /> <br /> :: As a [role], I can [feature] so that [reason]<br /> <br /> Example to explain this-<br /> <br /> :: As a Bank account holder, I can login with my credentials so that I can check my account details<br /> <br /> <br /> Once the user stories are written, the acceptance tests can be written for the user stories. The acceptance tests have the following format<br /> <br /> :: Given [Context]<br /> <br /> :: When [Event Occurs]<br /> <br /> :: Then [Outcome]<br /> <br /> <br /> Scenario: Enter a Login Page<br /> <br /> :: Given I enter a valid username <br /> <br /> :: And I enter a valid password<br /> <br /> :: When I press the Login Button<br /> <br /> :: Then I should be redirected to the home page<br /> <br /> These acceptance tests for the user stories are entered in the application as automated tests by the developer. <br /> <br /> == Implementation ==<br /> Ruby on Rails uses various tools like Cucumber, Rspec etc to implement the user tests.<br /> <br /> === Cucumber ===<br /> BDD makes the use of Cucumber for running automated acceptance tests. Cucumber specifies what a user should see and be able to do. Cucumber works with Ruby to help the software development teams describe how an application should behave. Cucumber is intelligible to both software developers as well as domain experts. It can serve both as documentation and automated tests.<br /> <br /> <br /> === RSpec ===<br /> RSpec mainly deals with unit tests which mean testing a class method in isolation from the rest of the application. So it guarantees that the model does what it is supposed to do, the controller does what it is supposed to do, etc.<br /> [[File:BDD.jpg]]<br /> <br /> == References ==<br /> <br /> 1. [http://en.wikipedia.org/wiki/Behavior-driven_development Behavior-driven development]<br /> <br /> 2. [http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd Rules of Test-driven development]<br /> <br /> 3. [http://bob-roberts.net/2012/02/17/608/ Using Rspec and Capybara]<br /> <br /> 4. [http://stackoverflow.com/questions/2509/what-are-the-primary-differences-between-tdd-and-bdd Difference between TDD and BDD]<br /> <br /> 5. [http://www.slideshare.net/IosifItkin/behavior-driven-development-pros-and-cons Benefits of behavior-driven development]<br /> <br /> 6. [http://rorataspire.wordpress.com/2008/06/16/behaviour-driven-development-have-a-definite-edge-in-the-outsourced-software-development/ Lifecycle]<br /> <br /> 7. [http://en.wikipedia.org/wiki/Test-driven_development Test-driven development]<br /> <br /> 8. [http://www.ryangreenhall.com/articles/bdd-by-example.html Examples of BDD]<br /> <br /> 9. [http://cukes.info/ Cucumber info]<br /> <br /> 10. [http://en.wikipedia.org/wiki/Cucumber_(software) Cucumber]<br /> <br /> 11. [http://www.slideshare.net/MarkMenard/behavior-driven-development-with-rails Behavior driven development with Rails]<br /> <br /> 12. [http://codesqueeze.com/the-easy-way-to-writing-good-user-stories/ Writing user stories]<br /> <br /> 13. [http://stackoverflow.com/questions/11762245/whats-the-difference-between-rspec-and-cucumber Difference between RSpec and Cucumber]</div>

Agoel2 https://wiki.expertiza.ncsu.edu/index.php?title=File:Steps.jpg&diff=79452 2013-10-06T16:11:24Z

<p>Agoel2: </p> <hr /> <div></div>

Agoel2 https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/ch1_1w33_aa&diff=79451 2013-10-06T16:08:40Z

<p>Agoel2: </p> <hr /> <div>== Behavior-driven development in Ruby on Rails ==<br /> <br /> Behavior-driven development (also known as BDD) is an agile development strategy that has been derived from Test Driven Development. It was developed by Dan North in order to address the problems faced by TDD. BDD approach focuses on design, documentation and behavior rather than on tests. This approach enables more interactions between the client and the developer. <br /> The client specifies his functional specifications to the developer by writing user stories which describe how the system should perform when a certain condition is met. These user stories are then translated into tests using tools like RSpec and Cucumber. These tests are then run to check whether they satisfy the desired functional behavior. The business requirement is delivered when all the tests pass.<br /> <br /> == Difference from other development strategies ==<br /> === Test-driven development (TDD) ===<br /> Another type of Test Driven Development is Behavior-driven development (also known as TDD). In TDD, software developers write automated test cases before they write any code.<br /> :: • The first step of TDD is to write a failing test for a particular unit of functionality to be added. <br /> <br /> :: • The next step is to write a piece of code only to pass that failing test.<br /> <br /> :: • The last step would be to refactor the code so that it meets the requirement standards of the code.<br /> <br /> <br /> <br /> <br /> <br /> Test Driven Development follows three rules. They are:<br /> <br /> :: • One must not write any production code unless it is to make a failing unit test pass.<br /> <br /> :: • One must not write any more of a unit test than is sufficient to fail<br /> <br /> :: • One must not write any more production code than is sufficient to pass the one failing unit test.<br /> <br /> === Difference between TDD and BDD ===<br /> :: • TDD’s main focus is on the tests while BDD mainly focuses on the behavioral specification from the user point of view. <br /> <br /> :: • With TDD, unit tests are written, whereas for BDD tests are written using “User Stories”.<br /> <br /> :: • TDD uses language which is intelligible to only the software programmers.<br /> <br /> BDD uses language which is more easily understood by technical as well as non technical people.<br /> <br /> == Advantages of BDD ==<br /> :: • Due to BDD language being comprehensible by both technical as well as domain experts, the BDD involves the customers and the business partners in writing the scenarios for the tests.<br /> <br /> :: • Unlike tests which come after implementation, focusing on the behavior proves to be a better approach.<br /> <br /> :: • TDD methodology can lead to a number of failed tests before arriving at the correct result because it focuses mainly on implementation. But BDD does not require so many tests as its main focus is behavior thus resulting in less code.<br /> <br /> == Disadvantages of BDD ==<br /> :: • The user stories written by the customers might not be good quality and may have to be rewritten by the developer.<br /> <br /> :: • The customer might not have enough time to review the scenarios on a regular basis.<br /> <br /> == Examples of BDD with Ruby on Rails ==<br /> In BDD, business requirements are identified by user stories. The user stories are described using the following format<br /> <br /> :: As a [role], I can [feature] so that [reason]<br /> <br /> Example to explain this-<br /> <br /> :: As a Bank account holder, I can login with my credentials so that I can check my account details<br /> <br /> <br /> Once the user stories are written, the acceptance tests can be written for the user stories. The acceptance tests have the following format<br /> <br /> :: Given [Context]<br /> <br /> :: When [Event Occurs]<br /> <br /> :: Then [Outcome]<br /> <br /> <br /> Scenario: Enter a Login Page<br /> <br /> :: Given I enter a valid username <br /> <br /> :: And I enter a valid password<br /> <br /> :: When I press the Login Button<br /> <br /> :: Then I should be redirected to the home page<br /> <br /> These acceptance tests for the user stories are entered in the application as automated tests by the developer. <br /> <br /> == Implementation ==<br /> Ruby on Rails uses various tools like Cucumber, Rspec etc to implement the user tests.<br /> <br /> === Cucumber ===<br /> BDD makes the use of Cucumber for running automated acceptance tests. Cucumber specifies what a user should see and be able to do. Cucumber works with Ruby to help the software development teams describe how an application should behave. Cucumber is intelligible to both software developers as well as domain experts. It can serve both as documentation and automated tests.<br /> <br /> <br /> === RSpec ===<br /> RSpec mainly deals with unit tests which mean testing a class method in isolation from the rest of the application. So it guarantees that the model does what it is supposed to do, the controller does what it is supposed to do, etc.<br /> [[File:BDD.jpg]]<br /> <br /> == References ==<br /> <br /> 1. [http://en.wikipedia.org/wiki/Behavior-driven_development Behavior-driven development]<br /> <br /> 2. [http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd Rules of Test-driven development]<br /> <br /> 3. [http://bob-roberts.net/2012/02/17/608/ Using Rspec and Capybara]<br /> <br /> 4. [http://stackoverflow.com/questions/2509/what-are-the-primary-differences-between-tdd-and-bdd Difference between TDD and BDD]<br /> <br /> 5. [http://www.slideshare.net/IosifItkin/behavior-driven-development-pros-and-cons Benefits of behavior-driven development]<br /> <br /> 6. [http://rorataspire.wordpress.com/2008/06/16/behaviour-driven-development-have-a-definite-edge-in-the-outsourced-software-development/ Lifecycle]<br /> <br /> 7. [http://en.wikipedia.org/wiki/Test-driven_development Test-driven development]<br /> <br /> 8. [http://www.ryangreenhall.com/articles/bdd-by-example.html Examples of BDD]<br /> <br /> 9. [http://cukes.info/ Cucumber info]<br /> <br /> 10. [http://en.wikipedia.org/wiki/Cucumber_(software) Cucumber]<br /> <br /> 11. [http://www.slideshare.net/MarkMenard/behavior-driven-development-with-rails Behavior driven development with Rails]<br /> <br /> 12. [http://codesqueeze.com/the-easy-way-to-writing-good-user-stories/ Writing user stories]<br /> <br /> 13. [http://stackoverflow.com/questions/11762245/whats-the-difference-between-rspec-and-cucumber Difference between RSpec and Cucumber]</div>

Agoel2 https://wiki.expertiza.ncsu.edu/index.php?title=File:BDD.jpg&diff=79450 2013-10-06T16:07:05Z

<p>Agoel2: </p> <hr /> <div></div>

Agoel2 https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/ch1_1w33_aa&diff=79449 2013-10-06T15:49:09Z

<p>Agoel2: Created page with &quot;== Behavior-driven development in Ruby on Rails == Behavior-driven development (also known as BDD) is an agile development strategy that has been derived from Test Driven Develo...&quot;</p> <hr /> <div>== Behavior-driven development in Ruby on Rails ==<br /> <br /> Behavior-driven development (also known as BDD) is an agile development strategy that has been derived from Test Driven Development. It was developed by Dan North in order to address the problems faced by TDD. BDD approach focuses on design, documentation and behavior rather than on tests. This approach enables more interactions between the client and the developer. <br /> The client specifies his functional specifications to the developer by writing user stories which describe how the system should perform when a certain condition is met. These user stories are then translated into tests using tools like RSpec and Cucumber. These tests are then run to check whether they satisfy the desired functional behavior. The business requirement is delivered when all the tests pass.<br /> <br /> == Difference from other development strategies ==<br /> === Test-driven development (TDD) ===<br /> Another type of Test Driven Development is Behavior-driven development (also known as TDD). In TDD, software developers write automated test cases before they write any code.<br /> :: • The first step of TDD is to write a failing test for a particular unit of functionality to be added. <br /> <br /> :: • The next step is to write a piece of code only to pass that failing test.<br /> <br /> :: • The last step would be to refactor the code so that it meets the requirement standards of the code.<br /> <br /> <br /> <br /> <br /> <br /> Test Driven Development follows three rules. They are:<br /> <br /> :: • One must not write any production code unless it is to make a failing unit test pass.<br /> <br /> :: • One must not write any more of a unit test than is sufficient to fail<br /> <br /> :: • One must not write any more production code than is sufficient to pass the one failing unit test.<br /> <br /> === Difference between TDD and BDD ===<br /> :: • TDD’s main focus is on the tests while BDD mainly focuses on the behavioral specification from the user point of view. <br /> <br /> :: • With TDD, unit tests are written, whereas for BDD tests are written using “User Stories”.<br /> <br /> :: • TDD uses language which is intelligible to only the software programmers.<br /> <br /> BDD uses language which is more easily understood by technical as well as non technical people.<br /> <br /> == Advantages of BDD ==<br /> :: • Due to BDD language being comprehensible by both technical as well as domain experts, the BDD involves the customers and the business partners in writing the scenarios for the tests.<br /> <br /> :: • Unlike tests which come after implementation, focusing on the behavior proves to be a better approach.<br /> <br /> :: • TDD methodology can lead to a number of failed tests before arriving at the correct result because it focuses mainly on implementation. But BDD does not require so many tests as its main focus is behavior thus resulting in less code.<br /> <br /> == Disadvantages of BDD ==<br /> :: • The user stories written by the customers might not be good quality and may have to be rewritten by the developer.<br /> <br /> :: • The customer might not have enough time to review the scenarios on a regular basis.<br /> <br /> == Examples of BDD with Ruby on Rails ==<br /> In BDD, business requirements are identified by user stories. The user stories are described using the following format<br /> <br /> :: As a [role], I can [feature] so that [reason]<br /> <br /> Example to explain this-<br /> <br /> :: As a Bank account holder, I can login with my credentials so that I can check my account details<br /> <br /> <br /> Once the user stories are written, the acceptance tests can be written for the user stories. The acceptance tests have the following format<br /> <br /> :: Given [Context]<br /> <br /> :: When [Event Occurs]<br /> <br /> :: Then [Outcome]<br /> <br /> <br /> Scenario: Enter a Login Page<br /> <br /> :: Given I enter a valid username <br /> <br /> :: And I enter a valid password<br /> <br /> :: When I press the Login Button<br /> <br /> :: Then I should be redirected to the home page<br /> <br /> These acceptance tests for the user stories are entered in the application as automated tests by the developer. <br /> <br /> == Implementation ==<br /> Ruby on Rails uses various tools like Cucumber, Rspec etc to implement the user tests.<br /> <br /> === Cucumber ===<br /> BDD makes the use of Cucumber for running automated acceptance tests. Cucumber specifies what a user should see and be able to do. Cucumber works with Ruby to help the software development teams describe how an application should behave. Cucumber is intelligible to both software developers as well as domain experts. It can serve both as documentation and automated tests.<br /> <br /> <br /> === RSpec ===<br /> RSpec mainly deals with unit tests which mean testing a class method in isolation from the rest of the application. So it guarantees that the model does what it is supposed to do, the controller does what it is supposed to do, etc.<br /> <br /> <br /> == References ==<br /> <br /> 1. [http://en.wikipedia.org/wiki/Behavior-driven_development Behavior-driven development]<br /> <br /> 2. [http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd Rules of Test-driven development]<br /> <br /> 3. [http://bob-roberts.net/2012/02/17/608/ Using Rspec and Capybara]<br /> <br /> 4. [http://stackoverflow.com/questions/2509/what-are-the-primary-differences-between-tdd-and-bdd Difference between TDD and BDD]<br /> <br /> 5. [http://www.slideshare.net/IosifItkin/behavior-driven-development-pros-and-cons Benefits of behavior-driven development]<br /> <br /> 6. [http://rorataspire.wordpress.com/2008/06/16/behaviour-driven-development-have-a-definite-edge-in-the-outsourced-software-development/ Lifecycle]<br /> <br /> 7. [http://en.wikipedia.org/wiki/Test-driven_development Test-driven development]<br /> <br /> 8. [http://www.ryangreenhall.com/articles/bdd-by-example.html Examples of BDD]<br /> <br /> 9. [http://cukes.info/ Cucumber info]<br /> <br /> 10. [http://en.wikipedia.org/wiki/Cucumber_(software) Cucumber]<br /> <br /> 11. [http://www.slideshare.net/MarkMenard/behavior-driven-development-with-rails Behavior driven development with Rails]<br /> <br /> 12. [http://codesqueeze.com/the-easy-way-to-writing-good-user-stories/ Writing user stories]<br /> <br /> 13. [http://stackoverflow.com/questions/11762245/whats-the-difference-between-rspec-and-cucumber]</div>

Agoel2 https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/ch1_1w01_aj&diff=79448 2013-10-06T15:48:27Z

<p>Agoel2: </p> <hr /> <div>== Version Control Tools ==<br /> <br /> Version control tools are the tools which manage the changes to documents, computer programs, large web sites, and other collections of information. It is a repository of code along with the history of the changes. All the change made to the source is tracked, along with the other details like who made the changes, why the changes were made and other comments. This concept is very important for large projects requiring collaborated development. Whether it is the history of this wiki page or large software development project like Facebook, the ability to track the changes, and to reverse changes when necessary can make all huge difference between a well-managed and controlled process and an uncontrolled ‘first come, first served’ system. It can be used to track the development lifecycle of a project in detail.<br /> <br /> == Categories of version control tools ==<br /> <br /> === Distributed Model ===<br /> <br /> [http://en.wikipedia.org/wiki/Peer-to-peer Peer-to-peer] approach is followed in distributed revision control system in which each person’s copy of codebase is the current version of his code. In this way, each developer has the copy of full code rather than a part of code on which that developer is working. This system then synchronizes the copies of each developer by exchanging patches which contain the sets of changes. In this way each developer gets the latest copy of the code portion that others are working on. This method, most of the times, does not use the central repository. <br /> Major advantages of this system are:<br /> <br /> <br /> • As the full code is available on the hard disk, most of the actions are very fast as the interaction with the remote server is not required.<br /> <br /> • Committing new change sets can be done locally without anyone else seeing them. Once you have a group of change sets ready, you can push all of them at once.<br /> <br /> • Except pushing and pulling, most of the actions can be performed without an internet connection.<br /> <br /> Despite the above advantages, Distributed Version Control Tools pose some problems. As the copy of whole code is maintained at the local machine, it requires a huge amount of space in case the files cannot be compressed (binary files). Moreover, in case the project has a huge history of changes, it might require large amount of time to download the entire patches.<br /> <br /> Few examples of such tools are Codeville, Fossil, LibreSource, Monotone, Veracity and Git. <br /> Let us consider Git to explain the features of distributed model for version control tools.<br /> <br /> <br /> ==== Git ====<br /> Git is a free and open source distributed version control system. Its highest priority is to provide the high speed to its users. It was initially designed and developed for Linux kernel in 2005. was originally designed as a low-level version control system engine on top of which others could write front ends. However, the core Git project has since become a complete version control system that is usable directly. As of today, Git is estimated to have captured 30% of the market.<br /> Every Git working directory is a full-fledged repository with complete history and full version tracking capabilities, not dependent on network access or a central server.<br /> <br /> [[File:Branching-Git.png]]<br /> ''(Image showing the concept of branching for Git)''<br /> <br /> ==== Design of Git ====<br /> Git, like any other distributed version control system, has three main functionalities:<br /> <br /> • Code storage<br /> <br /> • Keeping track of the changes made to the code<br /> <br /> • Synchronizing all the developers for the latest code<br /> <br /> ===== Code Storage =====<br /> <br /> Blob is the basic storage in Git. Git stores the contents of the file for tracking history, and not just the differences between individual files for each change. The contents are then referenced by a 40 character [http://en.wikipedia.org/wiki/SHA-1 SHA1 hash]. Pretty much every object, be it a commit, tree, or blob has a SHA.<br /> <br /> This gives an added advantage that if two or more copies of the same file are stored in the repository, Git will store only one file internally.<br /> <br /> The next level object is a tree. These can be thought of as folders or directories. Finally, this brings us to the most important object: the commit. Commits can be thought of as snapshots. The major difference between Git and any other tool is the way Git thinks about its data. Conceptually, most other systems store information as a list of file-based changes. Tools consider the information they keep as a set of files and the changes made to each file over time.<br /> <br /> [[File:Data_storage_git.png]]<br /> ''(Image showing data storage in case of normal control system)''<br /> In contrast, Git thinks of its data more like a set of snapshots of a mini file system.<br /> Every time you commit, or save the state of your project in Git, it basically takes a picture of what all your files look like at that moment and stores a reference to that snapshot.<br /> <br /> Git stores data as:<br /> <br /> [[File:Git_commit.png‎]]<br /> ''(Image showing data storage in case of Git)''<br /> <br /> This is an important difference between Git and all other tools. It makes Git reconsider almost every aspect of version control that most other systems copied from the previous generation.<br /> <br /> ===== Tracking the changes made to the code =====<br /> Git uses directed acyclic graph to store its history. Each commit in Git can have multiple or single parent commits. This info about the ancestors is stored with each commit. Here we can have nonlinear history. That means a commit can have multiple parent commits on which the child commit depends. Below example shows 3-way merge that has 3 parents:<br /> <br /> <br /> [[File:Git_Tree.png‎]]<br /> <br /> <br /> The history of a file is linked all the way up its directory structure to the root directory, which is then linked to a commit node. This commit node, in turn, can have one or more parents. When merging multiple branches we are merging the contents in a DAG. This allows Git to determine common ancestors.<br /> <br /> ===== Synchronizing all the developers for the latest code =====<br /> <br /> In Git, when a developer makes the same modification to the equivalent file in the local Git code, the change will be recorded locally first, then they can &quot;push&quot; the commits to the other users who are working on the same project. The content changes are stored identically for each Git repository that the commit exists in. <br /> Upon the local commit, the local Git repository will create a new object representing a file for the changed file. For each directory above the changed file, a new tree object is created with a new identifier. A DAG is created starting from the newly created root tree object pointing to the files and referencing the newly created blob in place of that file's previous blob object in the previous tree hierarchy.<br /> At this point the commit is still local to the current Git code on developer’s local device. When he &quot;pushes&quot; the commit to a publicly accessible Git repository this commit gets sent to that repository. After the public repository verifies that the commit can apply to the branch, the same objects are stored in the public repository as were originally created in the local Git repository.<br /> <br /> ==== Tools available for Git ====<br /> <br /> Git provides many command line and UI tools for most of the platforms. All these tools are based on Git core toolkit.<br /> Git toolkit is divided into 2 parts: plumbing and porcelain. Plumbing contains two level commands that enable basic content tracking and modification of directed acyclic graphs. Procelain contains the more commonly used commands which are used to maintain repositories and communicating with other developers. Work is in progress for improving the toolkit design and making it faster.<br /> <br /> <br /> <br /> ===== Some of the major characteristics of Git: =====<br /> ===== Good support for expansion =====<br /> Git is extremely fast and scalable. Referring to a local copy of code instead of the copy on remote server is very fast. As the project size increases, the affect of size on performance is very less.<br /> <br /> ===== Distributed development =====<br /> Each developer is provided with the local copy of the entire development history. Changes are copied from one of the repository to another. These changes are transferred and can integrate the same way the local branches of the repository.<br /> <br /> ===== Backward compatibility =====<br /> Repositories can be published by HTTP, FTP, rsync, or a Git protocol over either a plain socket, ssh or HTTP. Git also has a CVS server emulation, which enables the use of existing CVS clients and IDE plugins to access Git repositories.<br /> <br /> ===== Non-linear development =====<br /> Git provides quick branching and merging. A branch in git is only a reference to a single commit. It supports non-linear development through various tools.<br /> <br /> ===== Support for incomplete merge =====<br /> In case of an incomplete merge, Git provides multiple algorithms for letting the user know of this situation and also provides support for manual editing.<br /> <br /> ===== Cryptographic authentication of history =====<br /> Git stores the history so that the id of a particular version depends upon the history of changes resulting into that commit. Once it is published, it is not possible to change the old versions without it being noticed.<br /> <br /> Some of the major companies using Git in their projects include Google, Facebook, Microsoft(ASP.NET), Twitter, Eclipse and Netflix.<br /> <br /> '''Some of the other major tools in this category are given below'''<br /> <br /> ==== GNU Bazaar ====<br /> [http://en.wikipedia.org/wiki/GNU_Bazaar GNU Bazaar] (formerly Bazaar-NG, command line tool bzr) is a distributed revision control system sponsored by Canonical.<br /> Bazaar can be used by a single developer working on multiple branches of local content, or by teams collaborating across a network.<br /> Bazaar is written in the Python programming language, with packages for major GNU/Linux distributions, Mac OS X and Microsoft Windows.<br /> <br /> ==== Mercurial ====<br /> [http://mercurial.selenic.com/ Mercurial] is a cross-platform, distributed revision control tool for software developers. It is mainly implemented using the Python programming language, but includes a binary diff implementation written in C. It is supported on Windows and Unix-like systems, such as FreeBSD, Mac OS X andLinux. Mercurial is primarily a command line program but graphical user interface extensions are available. All of Mercurial's operations are invoked as arguments to its driver program hg, a reference to the chemical symbol of the element mercury.<br /> <br /> ==== Bitkeeper ====<br /> [http://www.bitkeeper.com/ BitKeeper] is a software tool for distributed revision control (configuration management, SCM, etc.) of computer source code. A distributed system, BitKeeper competes largely against other systems such as Git and Mercurial. BitKeeper is produced by BitMover Inc., a privately held company based in Campbell, California[2] and owned by CEO Larry McVoy, who had previously designed TeamWare.<br /> <br /> BitKeeper builds upon many of the TeamWare concepts. Its key selling point is the fact that it is a distributed version control tool, as opposed to CVSor SVN. One of the defining characteristics of any distributed version control tool is the ease with which distributed development teams can keep their own local source repositories and still work with the central repository. Its web site claims that &quot;BitKeeper has been shown to double the pace of software development&quot;.<br /> <br /> === Client Server Model ===<br /> Centralized or client-server version control systems are based on the idea that there is a single “central” copy of your project somewhere (probably on a server), and programmers will “commit” their changes to this central copy.<br /> <br /> “Committing” a change simply means recording the change in the central system. Other programmers can then see this change. They can also pull down the change, and the version control tool will automatically update the contents of any files that were changed.<br /> <br /> Most modern version control systems deal with “changesets,” which simply are a groups of changes (possibly to many files) that should be treated as a cohesive whole. For example: a change to a C header file and the corresponding .c file should always be kept together.<br /> <br /> ==== Major Advantages of Centralized Version Control over Distributed Version Control ====<br /> If the project contains many large, binary files that cannot be easily compressed, the space needed to store all versions of these files can accumulate quickly.<br /> <br /> If the project has a very long history (50,000 changesets or more), downloading the entire history can take an impractical amount of time and disk space.<br /> <br /> ==== Perforce ====<br /> Perforce is an enterprise version control and management system which uses centralized Version Control System. Dedicated Perforce applications are used to sync files between the file repository and individual users' workstations. <br /> Perforce supports both Git clients and clients that use Perforce's own protocol. A Git client can communicate with the Perforce server over SSH, and other Perforce clients communicate with the server via TCP/IP using a proprietary RPC and streaming protocol.<br /> <br /> [[File:perf1.jpg]]<br /> <br /> ===== The Perforce Versioning Service =====<br /> The Perforce versioning service manages shared file repositories called depots. Depots contains all revisions of all file under Perforce control. Perforce organizes all the files in depots into directory trees, like a hard drive. Files in a depot are referred to as depot files or versioned files. Files are identified by namespace (i.e., by OS-neutral filenames). File content itself is not stored in the database. MD5 hashes of file content are stored in the database. Text file revisions are stored as RCS deltas and binary file revisions are stored in their entirety. <br /> <br /> 　　The service maintains a database to track change logs, user permissions, and which users have which files checked out at any time. The <br /> information stored in this database is referred to as metadata. <br /> <br /> 　　Database tables are stored as binary files. Checkpoints and journals are written as text files that can be compressed and taken out. A database that has been corrupted by hardware failure or other catastrophe can be recovered from the most recent journal and checkpoint. Administrators must plan for disaster recovery by configuring database journaling and setting up regular checkpoints.<br /> <br /> [[File:perf2.jpg]]<br /> <br /> ===== Perforce applications (clients) =====<br /> Dedicated Perforce applications communicate with the versioning service to enable the checking in and out, conflict management, branch development, bug tracking request changing and more. They include:<br /> <br /> 　　• P4, the Perforce Command-Line Client, for all platforms<br /> <br /> 　　• P4V, the Perforce Visual Client, for Mac OS X, UNIX, Linux, and Windows<br /> <br /> 　　• P4Web, the Perforce Web Client, a browser-based interface to Perforce<br /> <br /> 　　• Integrations, or plug-ins, that work with commercial IDEs and productivity software<br /> <br /> 　　<br /> When the files are loaded into the workspace, the Perforce application requests the files from the central data repository. To optimize the network utilization, the service keeps track of which files you (and other users) have retrieved. Perforce applications do not require a persistent connection to the versioning service.<br /> <br /> ===== Connecting and Mapping files to the workspace =====<br /> 　　Perforce applications manages files in a certain location of the hard disk, called the workspace. More than one client workspace can co-exist, even on the same workstation.<br /> <br /> 　　To customize the location of depot files under the root workspace, users must map the files and directories on the shared versioning service to corresponding areas of local hard drive.<br /> 　　Workspace views:<br /> <br /> 　　• Determine which files in the depot needs to be in the workspace.<br /> <br /> 　　• Custom-map files in the depot to files in the workspace.<br /> <br /> 　　Client workspace views may consist multiple lines or mappings. Each line in the workspace view has a &quot;depot side&quot;, designates a subset of files within the depot, and a &quot;client side&quot; that controls where the files specified on the depot side are located under the workspace root.<br /> <br /> [[File:perf3.jpg]]<br /> <br /> =====　What file types are supported? =====<br /> 　　Perforce file types include seven base file types.<br /> <br /> 　　• text files,<br /> <br /> 　　• binary files,<br /> <br /> 　　• native apple files on the Macintosh,<br /> <br /> 　　• Mac resource forks,<br /> <br /> 　　• symbolic links (symlinks),<br /> <br /> 　　• unicode (and utf16) files.<br /> <br /> ===== Working with files =====<br /> The changelist is the fundamental unit of work. The basic file operations which are common to all VCS (such as editing, adding, deleting, rolling back changes, and file check in) are taken care in changelists.<br /> A changelist consists file list, their revision numbers, the changes made, and a description that describes the work that has been performed.<br /> Changelists serve two purposes:<br /> <br /> 　　• To logically organize the work by grouping related changes to files together,<br /> <br /> 　　• To ensure the work integrity by making sure that related changes to files are checked in together.<br /> <br /> Perforce changelists are atomic change transactions; if a changelist affects three files, then the changes for all three files are committed to the depot, or none of the changes are. Even if the network connection between your Perforce client program and the Perforce server is interrupted during changelist submission, the entire submit fails. Each changelist is identified by a changelist number (generated by Perforce), and a description (supplied by the user).<br /> <br /> [[File:perf4.jpg]]<br /> <br /> ===== Working concurrently =====<br /> 　　Perforce helps teams to work concurrently. The conflict resolution and three-way merge process enables multiple users to work on the same files at the same time without interfering with each other's work.<br /> <br /> 　　The three-way merge process for resolving file conflicts helps you to resolve conflicting changes to text files, but is not necessarily meaningful for binary files such as graphics or compiled code. If the user is working on files where merges are not meaningful, locking such files is an option to prevent others from making changes that conflict.<br /> <br /> 　　Perforce supports two types of file locking:<br /> <br /> 　　• To prevent inconsistencies in current file changes, lock the file. Other users can still check out the locked file, but are restricted to view only privileges.<br /> <br /> 　　• To prevent a file from being checked out by more than one user at a time, use the +l exclusive-open filetype modifier. Files that have the +l filetype modifier can only be opened by one user at a time. Your Perforce administrator can use a special table called the typemap table to automatically specify certain file types as exclusive-open.<br /> 　　<br /> =====　Streams =====<br /> 　　Perforce streams are structured containers for the files that consist projects, codelines, and components. Streams confer the following benefits:<br /> <br /> 　　• Ensures a hierarchical approach to branching<br /> <br /> 　　• Provides an &quot;out of the box&quot; best-practice branching strategy<br /> <br /> 　　• Provide metadata about the branch hierarchy to the Perforce service<br /> <br /> 　　• Provide a standard approach to structuring code (stability and hierarchy)<br /> <br /> 　　• Automate the generation of client workspace views and branch views<br /> <br /> 　　• Offer a compelling and informative visualization of stream structure and status<br /> <br /> 　　• Enable you to organize and visualize (bodies of) code.<br /> <br /> 　　• Provide rules to make development easier.<br /> 　　<br /> =====　Codeline Management =====<br /> Codelines are inter-related files that grow together. To organize groups of related files by purpose, branches are created. To move changes between branches, changelists are integrated. To create a snapshot of files in a specific phase, labels can be used.<br /> 　　<br /> =====　Branching =====<br /> 　　Branching is a method of managing changes between two or more sets of files. Perforce's Inter-File Branching mechanism enables copying of any set of files to a new location in the depot by allowing changes made to one set of files to be copied, or integrated, to the other. The new file set (or codeline) evolves separately from the original files, but changes in either codeline can be propagated to the other by means of integration. Almost all of the version control systems support some form of branching. <br /> <br /> 　　Merging is actually only one of three possible outcomes of an integration. The others are ignoring (aka &quot;blocking&quot;) and copying (aka &quot;promoting&quot;). Merging is used to keep one set of files up to date with another. For example, a development branch may be kept up to date with its trunk through repeated merging. Ignoring disqualifies changes in one set of files from future integration into another. It is often used when a development branch must be up to date with, and yet divergent from, its trunk. Copying is typically used to promote the content of an up-to-date development branch into a trunk.<br /> <br /> '''Some other tools in this category are given below'''<br /> <br /> ==== AccuRev ====<br /> [http://www.accurev.com/ AccuRev] is a centralized version control system which uses a client/server model. Communication is performed via TCP/IP using a proprietary protocol. Servers function as team servers, continuous integration servers, or build servers. AccuRev is built around a stream-based architecture in which streams form a hierarchical structure of code changes where parent streams pass on certain properties to child streams. Developers make changes using command line functions, the Java GUI, the web interface, or one of the IDE plug-ins.<br /> <br /> Characteristics:<br /> <br /> • Streams and parallel development<br /> <br /> • Private developer history<br /> <br /> • Change packages<br /> <br /> • Distributed development<br /> <br /> • Automated merging<br /> <br /> ==== IBM Rational ClearCase ====<br /> [http://www-03.ibm.com/software/products/us/en/clearcase/ The Rational ClearCase] family consists of several software tools for supporting software configuration management (SCM) of source code and other software development assets. It is developed by the Rational Software division of IBM. ClearCase forms the base for configuration management for many large and medium sized businesses and can handle projects with hundreds or thousands of developers.<br /> A part of Rational ClearCase is revision control system, which is a feature for end users.<br /> <br /> ClearCase supports two kinds of use models, UCM (Unified Change Management), and base ClearCase. UCM provides an out-of-the-box model while base ClearCase provides a basic infrastructure (upon which UCM is built). Both can be configured to support a wide variety of needs. UCM is part of RUP (Rational Unified Process) and therefore all process templates and roles can be used from RUP.<br /> <br /> '''Features:'''<br /> <br /> • Build auditing<br /> <br /> • VOB (Versioned Object Base)<br /> <br /> • Configuration Record<br /> <br /> • Build Avoidance<br /> <br /> • Unix/Windows Interoperability<br /> <br /> • Integration With Other Products<br /> <br /> • Space Saving<br /> <br /> '''Weaknesses:'''<br /> <br /> • Speed<br /> <br /> • Sensitivity to network problems<br /> <br /> === Local Data Model ===<br /> In the local-only approach, all developers must use the same computer system. These software often manage single files individually and are largely replaced or embedded within newer software. This data model is the grandfather of all the modern version control softwares. These are the very first softwares for version control that were implemented in the late 1970's. Technological and software advances have rendered these practically useless but certain legacy systems still use these due to the hardware and software limitations.<br /> <br /> ==== Source Code Control System (SCCS) ====<br /> 　　Source Code Control System (SCCS) is an early revision control system, geared toward program source code and other text files. It was originally developed in SNOBOL at Bell Labs in 1972 by Marc Rochkind for an IBM System/370 computer running OS/360 MVT. SCCS was the dominant version control system for Unix until the release of the Revision Control System (RCS)[dubious – discuss]. Today, SCCS is generally considered obsolete. However, its file format is still used internally by a few other revision control programs, including BitKeeper and TeamWare. The latter is a frontend to SCCS. Sablime has been developed from a modified version of SCCS but uses a history file format that is incompatible with SCCS. The SCCS file format uses a storage technique called interleaved deltas (or the weave). This storage technique is now considered by many revision control system developers as foundational to advanced merging and versioning techniques, such as the &quot;Precise Codeville&quot; (&quot;pcdv&quot;) merge.<br /> 　　<br /> ==== Revision Control System (RCS) ====<br /> The Revision Control System (RCS) is a software implementation of revision control that automates the storing, retrieval, logging, identification, and merging of revisions. RCS is useful for text that is revised frequently, for example programs, documentation, procedural graphics, papers, and form letters. RCS is also capable of handling binary files, though with reduced efficiency. Revisions are stored with the aid of the diff utility.<br /> <br /> This came into existency in 1982 and gave the version control systems a new dimension. It was the best VCS for the single user system, where all the files related to a project are in a single system. RCS just locks a single file that is being used and doesn't lock the entire project which is computationally cheaper.<br /> <br /> == References ==<br /> <br /> 1. [http://www.oss-watch.ac.uk/resources/versioncontrol Version Control Tools]<br /> <br /> 2. [http://www.mediamosa.org/content/source-code DVS]<br /> <br /> 3. [http://blogs.atlassian.com/2012/02/version-control-centralized-dvcs/ Distributed Version Control]<br /> <br /> 4. [http://git-scm.com/ Git]<br /> <br /> 5. [http://gitready.com/beginner/2009/02/17/how-git-stores-your-data.html GitReady]<br /> <br /> 6. [https://wiki.archlinux.org/index.php/Git‎ Archlinux] <br /> <br /> 7. [http://stackoverflow.com/questions/8198105/how-git-stores-files StackOverflow]<br /> <br /> 8. [http://en.wikipedia.org Wikipedia]<br /> <br /> 9. [http://www.perforce.com/perforce/doc.current/manuals/p4v-gs/p4v-gs.pdf Perforce documentation and manuals ‎]</div>

Agoel2 https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/ch1_1w01_aj&diff=79447 2013-10-06T15:47:42Z

<p>Agoel2: </p> <hr /> <div>== Behavior-driven development in Ruby on Rails ==<br /> <br /> Behavior-driven development (also known as BDD) is an agile development strategy that has been derived from Test Driven Development. It was developed by Dan North in order to address the problems faced by TDD. BDD approach focuses on design, documentation and behavior rather than on tests. This approach enables more interactions between the client and the developer. <br /> The client specifies his functional specifications to the developer by writing user stories which describe how the system should perform when a certain condition is met. These user stories are then translated into tests using tools like RSpec and Cucumber. These tests are then run to check whether they satisfy the desired functional behavior. The business requirement is delivered when all the tests pass.<br /> <br /> == Difference from other development strategies ==<br /> === Test-driven development (TDD) ===<br /> Another type of Test Driven Development is Behavior-driven development (also known as TDD). In TDD, software developers write automated test cases before they write any code.<br /> :: • The first step of TDD is to write a failing test for a particular unit of functionality to be added. <br /> <br /> :: • The next step is to write a piece of code only to pass that failing test.<br /> <br /> :: • The last step would be to refactor the code so that it meets the requirement standards of the code.<br /> <br /> <br /> <br /> <br /> <br /> Test Driven Development follows three rules. They are:<br /> <br /> :: • One must not write any production code unless it is to make a failing unit test pass.<br /> <br /> :: • One must not write any more of a unit test than is sufficient to fail<br /> <br /> :: • One must not write any more production code than is sufficient to pass the one failing unit test.<br /> <br /> === Difference between TDD and BDD ===<br /> :: • TDD’s main focus is on the tests while BDD mainly focuses on the behavioral specification from the user point of view. <br /> <br /> :: • With TDD, unit tests are written, whereas for BDD tests are written using “User Stories”.<br /> <br /> :: • TDD uses language which is intelligible to only the software programmers.<br /> <br /> BDD uses language which is more easily understood by technical as well as non technical people.<br /> <br /> == Advantages of BDD ==<br /> :: • Due to BDD language being comprehensible by both technical as well as domain experts, the BDD involves the customers and the business partners in writing the scenarios for the tests.<br /> <br /> :: • Unlike tests which come after implementation, focusing on the behavior proves to be a better approach.<br /> <br /> :: • TDD methodology can lead to a number of failed tests before arriving at the correct result because it focuses mainly on implementation. But BDD does not require so many tests as its main focus is behavior thus resulting in less code.<br /> <br /> == Disadvantages of BDD ==<br /> :: • The user stories written by the customers might not be good quality and may have to be rewritten by the developer.<br /> <br /> :: • The customer might not have enough time to review the scenarios on a regular basis.<br /> <br /> == Examples of BDD with Ruby on Rails ==<br /> In BDD, business requirements are identified by user stories. The user stories are described using the following format<br /> <br /> :: As a [role], I can [feature] so that [reason]<br /> <br /> Example to explain this-<br /> <br /> :: As a Bank account holder, I can login with my credentials so that I can check my account details<br /> <br /> <br /> Once the user stories are written, the acceptance tests can be written for the user stories. The acceptance tests have the following format<br /> <br /> :: Given [Context]<br /> <br /> :: When [Event Occurs]<br /> <br /> :: Then [Outcome]<br /> <br /> <br /> Scenario: Enter a Login Page<br /> <br /> :: Given I enter a valid username <br /> <br /> :: And I enter a valid password<br /> <br /> :: When I press the Login Button<br /> <br /> :: Then I should be redirected to the home page<br /> <br /> These acceptance tests for the user stories are entered in the application as automated tests by the developer. <br /> <br /> == Implementation ==<br /> Ruby on Rails uses various tools like Cucumber, Rspec etc to implement the user tests.<br /> <br /> === Cucumber ===<br /> BDD makes the use of Cucumber for running automated acceptance tests. Cucumber specifies what a user should see and be able to do. Cucumber works with Ruby to help the software development teams describe how an application should behave. Cucumber is intelligible to both software developers as well as domain experts. It can serve both as documentation and automated tests.<br /> <br /> <br /> === RSpec ===<br /> RSpec mainly deals with unit tests which mean testing a class method in isolation from the rest of the application. So it guarantees that the model does what it is supposed to do, the controller does what it is supposed to do, etc.<br /> <br /> <br /> == References ==<br /> <br /> 1. [http://en.wikipedia.org/wiki/Behavior-driven_development Behavior-driven development]<br /> <br /> 2. [http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd Rules of Test-driven development]<br /> <br /> 3. [http://bob-roberts.net/2012/02/17/608/ Using Rspec and Capybara]<br /> <br /> 4. [http://stackoverflow.com/questions/2509/what-are-the-primary-differences-between-tdd-and-bdd Difference between TDD and BDD]<br /> <br /> 5. [http://www.slideshare.net/IosifItkin/behavior-driven-development-pros-and-cons Benefits of behavior-driven development]<br /> <br /> 6. [http://rorataspire.wordpress.com/2008/06/16/behaviour-driven-development-have-a-definite-edge-in-the-outsourced-software-development/ Lifecycle]<br /> <br /> 7. [http://en.wikipedia.org/wiki/Test-driven_development Test-driven development]<br /> <br /> 8. [http://www.ryangreenhall.com/articles/bdd-by-example.html Examples of BDD]<br /> <br /> 9. [http://cukes.info/ Cucumber info]<br /> <br /> 10. [http://en.wikipedia.org/wiki/Cucumber_(software) Cucumber]<br /> <br /> 11. [http://www.slideshare.net/MarkMenard/behavior-driven-development-with-rails Behavior driven development with Rails]<br /> <br /> 12. [http://codesqueeze.com/the-easy-way-to-writing-good-user-stories/ Writing user stories]<br /> <br /> 13. [http://stackoverflow.com/questions/11762245/whats-the-difference-between-rspec-and-cucumber]</div>

Agoel2 https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013&diff=79446 2013-10-06T15:06:12Z

<p>Agoel2: </p> <hr /> <div>* [[ CSC/ECE 517 Fall 2012/ch1 1w23 ph ]]<br /> * [[ CSC/ECE 517 Fall 2013/ch1 1w30 nn]]<br /> * [[ CSC/ECE 517 Fall 2013/ch1 1w21 w]]<br /> * [[ CSC/ECE 517 Fall 2013/ch1 1w01 aj]]<br /> * [[ CSC/ECE 517 Fall 2013/ch1 1w24 nv]]<br /> * [[ CSC/ECE 517 Fall 2013/ch1 1w29 rkld]]<br /> * [[ CSC/ECE 517 Fall 2013/ch1 1w25 aras]]<br /> * [[ CSC/ECE 517 Fall 2013/ch1 1w30 ps]]<br /> * [[ CSC/ECE 517 Fall 2013/ch1 1w19 rj]]<br /> * [[ CSC/ECE 517 Fall 2013/ch1 1w18 bs]]<br /> * [[ CSC/ECE 517 Fall 2013/ch1 1w17 pk]]<br /> * [[ CSC/ECE 517 Fall 2013/ch1 1w22 ss]]<br /> * [[ CSC/ECE 517 Fall 2013/ch1 1w12 vn]]<br /> * [[ CSC/ECE 517 Fall 2013/ch1 1w14 st]]<br /> * [[ CSC/ECE 517 Fall 2013/ch1 1w08 cc]]<br /> * [[ CSC/ECE 517 Fall 2013/ch1 1w10 ga ]]<br /> * [[ CSC/ECE 517 Fall 2013/ch1 1w26 as ]]<br /> * [[ CSC/ECE 517 Fall 2013/ch1 1w27 ma ]]<br /> * [[ CSC/ECE 517 Fall 2013/ch1 1w13 aa ]]<br /> * [[ CSC/ECE 517 Fall 2013/ch1 1w11 sv ]]<br /> * [[ CSC/ECE 517 Fall 2013/ch1 1w07 d ]]<br /> * [[ CSC/ECE 517 Fall 2013/ch1 1w20 gq ]]<br /> * [[ CSC/ECE 517 Fall 2013/ch1 1w03 ss ]]<br /> * [[ CSC/ECE 517 Fall 2013/ch1 1w28 nm ]]<br /> * [[ CSC/ECE 517 Fall 2013/ch1 1w02 pp ]]<br /> * [[ CSC/ECE 517 Fall 2013/ch1 1w6 zs ]]<br /> * [[ CSC/ECE 517 Fall 2013/ch1 1w04 y ]]<br /> * [[ CSC/ECE 517 Fall 2013/ch1 1w05 st ]]<br /> * [[ CSC/ECE 517 Fall 2013/ch1 1w09 hs ]]<br /> * [[ CSC/ECE 517 Fall 2013/ch1 1w32 av ]]<br /> * [[ CSC/ECE 517 Fall 2013/ch1 1w48 x ]]<br /> * [[ CSC/ECE 517 Fall 2013/ch1 1w43 av]]<br /> * [[ CSC/ECE 517 Fall 2013/ch1 1w46 ka]]<br /> * [[ CSC/ECE 517 Fall 2013/ch1 1w33 aa]]</div>

Agoel2