Expertiza_Wiki - User contributions [en]

File:E1875UI 2.jpg

2018-12-02T19:57:14Z

Bbryson: uploaded a new version of "File:E1875UI 2.jpg": This is the correct image

File:E1875UI 2.jpg

2018-12-02T19:54:36Z

Bbryson: uploaded a new version of "File:E1875UI 2.jpg"

File:E1875UI 2.jpg

2018-12-02T19:53:49Z

Bbryson: uploaded a new version of "File:E1875UI 2.jpg"

File:E1875UML.png

2018-11-21T03:11:17Z

Bbryson: uploaded a new version of "File:E1875UML.png"

File:E1875UML.png

2018-11-21T03:10:48Z

Bbryson: uploaded a new version of "File:E1875UML.png"

File:E1875UML.png

2018-11-21T03:09:26Z

Bbryson: uploaded a new version of "File:E1875UML.png"

E1875 Revision Planning Tool

2018-11-21T03:08:40Z

Bbryson:

== What's it about? ==
In the first round of Expertiza reviews, we ask reviewers to give authors some guidance on how to improve their work. Then in the second round, reviewers rate how well authors have followed their suggestions. We could carry the interaction one step further if we asked authors to make up a revision plan based on the first-round reviews. That is, authors would say what they were planning to do to improve their work. Then second-round reviewers would assess how well they did it. In essence, this means that authors would be adding criteria to the second-round rubric that applied only to their submission. We are interested in having this implemented and used in a class so that we can study its effect.

 
== What needs to be done? ==
* Develop UI for authors to create new questions to add to the second round-rubric. This should be a form that includes the following:
** A description of the revision plan. Eg: We will add feature X to address issues a,b and c. We will modify feature Y and expect it to resolve errors d, c and e.
** One or more questions for every proposed improvement. Example:
*** How effectively did feature X address / solve issues a, b and c?
*** Did modification of feature Y resolve error d?
* Every new question must be linked to the second-round questionnaire.
* Every new question must be linked to the author’s submission

 
== Problem Statement ==
In the 2nd round of reviews, the Author should be able to add a statement to direct towards Author selected improvements from Round 1 to Round 2.

 
== Motivation ==
The OSS and Final projects are different for every team. From a reviewers perspective, not all questions make sense for all projects. The motivation behind this project is:
* Questions unique to each project gives the reviewers a perspective on the author’s objectives.
* Allow the Author to get feedback on whether or not they accomplished their self-directed goal.

 
== Criteria for completion ==
# Direct user to Revision Improvement Questionnaire.
# Create a form for a Assignment Team to add Questions to a Questionnaire that are specific to that Submission.
# Append Revision Improvement Questionnaire to 2nd Round Review Questionnaire.

 
== Implementation Plan ==
[[File:E1875UML.png]]
 
=== Files to be modified ===
==== Questionnaire ====
* questionnaire_controller.rb
* questionnaire.rb
* author_review_questionnaire.rb ( doesn’t exist, needs to be created and named appropriately )
* questionnaires/*.erb
 
==== Submitted Content ====
* submitted_content_controller.rb
* submission_record.rb
 
=== UI mockups ===
The first image shows a mockup of what the Author will see on the submission page to submit new additional questions for review. 
[[File:E1875U1_1.jpg]] 
Second is a view of what the reviewer will see. It should blend in with the review questions submitted by the instructor for all similar projects. 
[[File:E1875UI_2.jpg]]
 
 
=== Test Plan ===
# Authors should be able to add additional review questions to their submission.
# Reviewers should be able to give feedback according to the review question written by the author.
# Authors should be able to view the feedback given on the questions they wrote.
# ''Stretch'': Instructors should be able to set requirements on the number of additional review questions authors are required to add.

File:E1875UML.png

2018-11-21T03:07:54Z

Bbryson:

CSC/ECE 517 Fall 2018

2018-11-16T00:08:48Z

Bbryson:

* [[CSC/ECE 517 Fall 2018- Project E1846. OSS Project Navy: Character Issues]]
* [[CSC/ECE 517 Fall 2018/OSS E1848 Write unit tests for assignment team.rb]]
* [http://wiki.expertiza.ncsu.edu/index.php/E1839_Review_Requirements_and_Thresholds CSC/ECE 517 Fall 2018 E1839 Review Requirements and Thresholds]
* [http://wiki.expertiza.ncsu.edu/index.php/E1848_Write_unit_tests_for_assignment_team CSC/ECE 517 Fall 2018 E1848 Write unit tests for assignment_team]
* [http://wiki.expertiza.ncsu.edu/index.php/E1835_Refactor_delayed_mailer_and_scheduled_task CSC/ECE 517 Fall 2018 E1835_Refactor_delayed_mailer_and_scheduled_task]
* [http://wiki.expertiza.ncsu.edu/index.php/E1829_OSS_project_Duke_Blue_Fix_import_glitches CSC/ECE 517 Fall 2018 E1829 OSS project Duke Blue: Fix import glitches]
* [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2018/E1853_Write_unit_tests_for_menu.rb CSC/ECE 517 Fall 2018 E1853 Write unit tests for menu.rb]
* [http://wiki.expertiza.ncsu.edu/index.php/E1853_write_unit_tests_for_menu CSC/ECE517 Fall 2018 E1853 Write Unit Tests For menu.rb]
* [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2018_-_Project_E1852_Write_unit_tests_for_participant.rb CSC/ECE 517 Fall 2018 E1852 Write unit tests for participant.rb]
* [http://wiki.expertiza.ncsu.edu/index.php/E1844_Issues_related_to_names CSC/ECE 517 Fall 2018 E1844 Issues related to names]
* [http://wiki.expertiza.ncsu.edu/index.php/User_talk:Rshakya CSC/ECE 517 Fall 2018/E1852 Unit Test for Participant Model]
* [http://wiki.expertiza.ncsu.edu/index.php/E1850_Write_unit_tests_for_review_response_map CSC/ECE 517 Fall 2018 Write unit tests for review-response_map.rb]
* [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2018/E1849_Write_Unit_Tests_for_vm_question_response.rb CSC/ECE 517 Fall 2018/E1849 Write Unit Tests for vm_question_response.rb]
* [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2018/E1866_Expertiza_Internationalization CSC/ECE 517 Fall 2018/E1866 Expertiza Internationalization]
* [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2018/E1879_Student_Generated_Questions_Added_To_Rubric CSC/ECE 517 Fall 2018/E1879 Student Generated Questions Added To Rubric]
* [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2018/E1856_Allow_reviewers_to_bid_on_what_to_review CSC/ECE 517 Fall 2018/E1856 Allow]
* [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2018/E1876_Completion/Progress_view CSC/ECE 517 Fall 2018 E1876_Completion/Progress_view]
* [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2018/E1872_Track_Time_Students_Look_At_Other_Submissions CSC/ECE 517 Fall 2018/E1872 Track Time Students Look At Other Submissions]
* [[CSC/ECE 517 Fall 2018- Project E1865. Conflict Notification]]
* [[CSC/ECE 517 Fall 2018- Project E1861. Improving search facility in Expertiza]]
* [[CSC/ECE 517 Fall 2018- Project E1858. Github metrics integration]]
* [[CSC/ECE 517 Fall 2018 E1832. OSS Project Orange: Author feedback (rejoinder) enhancements]]
* [[E1875 Revision Planning Tool]]

E1875 Revision Planning Tool

2018-11-14T03:46:03Z

Bbryson:

== What's it about? ==
In the first round of Expertiza reviews, we ask reviewers to give authors some guidance on how to improve their work. Then in the second round, reviewers rate how well authors have followed their suggestions. We could carry the interaction one step further if we asked authors to make up a revision plan based on the first-round reviews. That is, authors would say what they were planning to do to improve their work. Then second-round reviewers would assess how well they did it. In essence, this means that authors would be adding criteria to the second-round rubric that applied only to their submission. We are interested in having this implemented and used in a class so that we can study its effect.

 
== What needs to be done? ==
* Develop UI for authors to create new questions to add to the second round-rubric. This should be a form that includes the following:
** A description of the revision plan. Eg: We will add feature X to address issues a,b and c. We will modify feature Y and expect it to resolve errors d, c and e.
** One or more questions for every proposed improvement. Example:
*** How effectively did feature X address / solve issues a, b and c?
*** Did modification of feature Y resolve error d?
* Every new question must be linked to the second-round questionnaire.
* Every new question must be linked to the author’s submission

 
== Problem Statement ==
In the 2nd round of reviews, the Author should be able to add a statement to direct towards Author selected improvements from Round 1 to Round 2.

 
== Motivation ==
The OSS and Final projects are different for every team. From a reviewers perspective, not all questions make sense for all projects. The motivation behind this project is:
* Questions unique to each project gives the reviewers a perspective on the author’s objectives.
* Allow the Author to get feedback on whether or not they accomplished their self-directed goal.

 
== Criteria for completion ==
# Direct user to Revision Improvement Questionnaire.
# Create a form for a Assignment Team to add Questions to a Questionnaire that are specific to that Submission.
# Append Revision Improvement Questionnaire to 2nd Round Review Questionnaire.

 
== Implementation Plan ==
 
=== Files to be modified ===
==== Questionnaire ====
* questionnaire_controller.rb
* questionnaire.rb
* author_review_questionnaire.rb ( doesn’t exist, needs to be created and named appropriately )
* questionnaires/*.erb
 
==== Submitted Content ====
* submitted_content_controller.rb
* submission_record.rb
 
=== UI mockups ===
The first image shows a mockup of what the Author will see on the submission page to submit new additional questions for review. 
[[File:E1875U1_1.jpg]] 
Second is a view of what the reviewer will see. It should blend in with the review questions submitted by the instructor for all similar projects. 
[[File:E1875UI_2.jpg]]
 
 
=== Test Plan ===
# Authors should be able to add additional review questions to their submission.
# Reviewers should be able to give feedback according to the review question written by the author.
# Authors should be able to view the feedback given on the questions they wrote.
# ''Stretch'': Instructors should be able to set requirements on the number of additional review questions authors are required to add.

E1875 Revision Planning Tool

2018-11-14T03:45:26Z

Bbryson:

== What's it about? ==
In the first round of Expertiza reviews, we ask reviewers to give authors some guidance on how to improve their work. Then in the second round, reviewers rate how well authors have followed their suggestions. We could carry the interaction one step further if we asked authors to make up a revision plan based on the first-round reviews. That is, authors would say what they were planning to do to improve their work. Then second-round reviewers would assess how well they did it. In essence, this means that authors would be adding criteria to the second-round rubric that applied only to their submission. We are interested in having this implemented and used in a class so that we can study its effect.

 
== What needs to be done? ==
* Develop UI for authors to create new questions to add to the second round-rubric. This should be a form that includes the following:
** A description of the revision plan. Eg: We will add feature X to address issues a,b and c. We will modify feature Y and expect it to resolve errors d, c and e.
** One or more questions for every proposed improvement. Example:
*** How effectively did feature X address / solve issues a, b and c?
*** Did modification of feature Y resolve error d?
* Every new question must be linked to the second-round questionnaire.
* Every new question must be linked to the author’s submission

 
== Problem Statement ==
In the 2nd round of reviews, the Author should be able to add a statement to direct towards Author selected improvements from Round 1 to Round 2.

 
== Motivation ==
The OSS and Final projects are different for every team. From a reviewers perspective, not all questions make sense for all projects. The motivation behind this project is:
* Questions unique to each project gives the reviewers a perspective on the author’s objectives.
* Allow the Author to get feedback on whether or not they accomplished their self-directed goal.

 
== Criteria for completion ==
# Direct user to Revision Improvement Questionnaire.
# Create a form for a Assignment Team to add Questions to a Questionnaire that are specific to that Submission.
# Append Revision Improvement Questionnaire to 2nd Round Review Questionnaire.

 
== Implementation Plan ==
 
=== Files to be modified ===
==== Questionnaire ====
* questionnaire_controller.rb
* questionnaire.rb
* author_review_questionnaire.rb ( doesn’t exist, needs to be created and named appropriately )
* questionnaires/*.erb
 
==== Submitted Content ====
* submitted_content_controller.rb
* submission_record.rb
 
=== UI mockups ===
The first image shows a mockup of what the Author will see on the submission page to submit new additional questions for review. 
[[File:E1875U1_1.jpg]] 
Second is a view of what the reviewer will see. It should blend in with the review questions submitted by the instructor for all similar projects. 
[[File:E1875U1_2.jpg]]
 
 
=== Test Plan ===
# Authors should be able to add additional review questions to their submission.
# Reviewers should be able to give feedback according to the review question written by the author.
# Authors should be able to view the feedback given on the questions they wrote.
# ''Stretch'': Instructors should be able to set requirements on the number of additional review questions authors are required to add.

E1875 Revision Planning Tool

2018-11-14T03:44:51Z

Bbryson:

== What's it about? ==
In the first round of Expertiza reviews, we ask reviewers to give authors some guidance on how to improve their work. Then in the second round, reviewers rate how well authors have followed their suggestions. We could carry the interaction one step further if we asked authors to make up a revision plan based on the first-round reviews. That is, authors would say what they were planning to do to improve their work. Then second-round reviewers would assess how well they did it. In essence, this means that authors would be adding criteria to the second-round rubric that applied only to their submission. We are interested in having this implemented and used in a class so that we can study its effect.

 
== What needs to be done? ==
* Develop UI for authors to create new questions to add to the second round-rubric. This should be a form that includes the following:
** A description of the revision plan. Eg: We will add feature X to address issues a,b and c. We will modify feature Y and expect it to resolve errors d, c and e.
** One or more questions for every proposed improvement. Example:
*** How effectively did feature X address / solve issues a, b and c?
*** Did modification of feature Y resolve error d?
* Every new question must be linked to the second-round questionnaire.
* Every new question must be linked to the author’s submission

 
== Problem Statement ==
In the 2nd round of reviews, the Author should be able to add a statement to direct towards Author selected improvements from Round 1 to Round 2.

 
== Motivation ==
The OSS and Final projects are different for every team. From a reviewers perspective, not all questions make sense for all projects. The motivation behind this project is:
* Questions unique to each project gives the reviewers a perspective on the author’s objectives.
* Allow the Author to get feedback on whether or not they accomplished their self-directed goal.

 
== Criteria for completion ==
# Direct user to Revision Improvement Questionnaire.
# Create a form for a Assignment Team to add Questions to a Questionnaire that are specific to that Submission.
# Append Revision Improvement Questionnaire to 2nd Round Review Questionnaire.

 
== Implementation Plan ==
 
=== Files to be modified ===
==== Questionnaire ====
* questionnaire_controller.rb
* questionnaire.rb
* author_review_questionnaire.rb ( doesn’t exist, needs to be created and named appropriately )
* questionnaires/*.erb
 
==== Submitted Content ====
* submitted_content_controller.rb
* submission_record.rb
 
=== UI mockups ===
The first image shows a mockup of what the Author will see on the submission page to submit new additional questions for review.
[[File:E1875U1_1.jpg]]
Second is a view of what the reviewer will see. It should blend in with the review questions submitted by the instructor for all similar projects.
[[File:E1875U1_2.jpg]]
 
 
=== Test Plan ===
# Authors should be able to add additional review questions to their submission.
# Reviewers should be able to give feedback according to the review question written by the author.
# Authors should be able to view the feedback given on the questions they wrote.
# ''Stretch'': Instructors should be able to set requirements on the number of additional review questions authors are required to add.

File:E1875UI 2.jpg

2018-11-14T03:44:35Z

Bbryson: uploaded a new version of "File:E1875UI 2.jpg"

File:E1875U1 1.jpg

2018-11-14T03:44:28Z

Bbryson: uploaded a new version of "File:E1875U1 1.jpg"

E1875 Revision Planning Tool

2018-11-14T03:43:23Z

Bbryson:

== What's it about? ==
In the first round of Expertiza reviews, we ask reviewers to give authors some guidance on how to improve their work. Then in the second round, reviewers rate how well authors have followed their suggestions. We could carry the interaction one step further if we asked authors to make up a revision plan based on the first-round reviews. That is, authors would say what they were planning to do to improve their work. Then second-round reviewers would assess how well they did it. In essence, this means that authors would be adding criteria to the second-round rubric that applied only to their submission. We are interested in having this implemented and used in a class so that we can study its effect.

 
== What needs to be done? ==
* Develop UI for authors to create new questions to add to the second round-rubric. This should be a form that includes the following:
** A description of the revision plan. Eg: We will add feature X to address issues a,b and c. We will modify feature Y and expect it to resolve errors d, c and e.
** One or more questions for every proposed improvement. Example:
*** How effectively did feature X address / solve issues a, b and c?
*** Did modification of feature Y resolve error d?
* Every new question must be linked to the second-round questionnaire.
* Every new question must be linked to the author’s submission

 
== Problem Statement ==
In the 2nd round of reviews, the Author should be able to add a statement to direct towards Author selected improvements from Round 1 to Round 2.

 
== Motivation ==
The OSS and Final projects are different for every team. From a reviewers perspective, not all questions make sense for all projects. The motivation behind this project is:
* Questions unique to each project gives the reviewers a perspective on the author’s objectives.
* Allow the Author to get feedback on whether or not they accomplished their self-directed goal.

 
== Criteria for completion ==
# Direct user to Revision Improvement Questionnaire.
# Create a form for a Assignment Team to add Questions to a Questionnaire that are specific to that Submission.
# Append Revision Improvement Questionnaire to 2nd Round Review Questionnaire.

 
== Implementation Plan ==
 
=== Files to be modified ===
==== Questionnaire ====
* questionnaire_controller.rb
* questionnaire.rb
* author_review_questionnaire.rb ( doesn’t exist, needs to be created and named appropriately )
* questionnaires/*.erb
 
==== Submitted Content ====
* submitted_content_controller.rb
* submission_record.rb
 
=== UI mockups ===
The first image shows a mockup of what the Author will see on the submission page to submit new additional questions for review.
[[File:E1875U1_1.jpg|100px|Image: 100px]]
Second is a view of what the reviewer will see. It should blend in with the review questions submitted by the instructor for all similar projects.
[[File:E1875U1_2.jpg|100px|Image: 100px]]
 
 
=== Test Plan ===
# Authors should be able to add additional review questions to their submission.
# Reviewers should be able to give feedback according to the review question written by the author.
# Authors should be able to view the feedback given on the questions they wrote.
# ''Stretch'': Instructors should be able to set requirements on the number of additional review questions authors are required to add.

E1875 Revision Planning Tool

2018-11-14T03:42:31Z

Bbryson:

== What's it about? ==
In the first round of Expertiza reviews, we ask reviewers to give authors some guidance on how to improve their work. Then in the second round, reviewers rate how well authors have followed their suggestions. We could carry the interaction one step further if we asked authors to make up a revision plan based on the first-round reviews. That is, authors would say what they were planning to do to improve their work. Then second-round reviewers would assess how well they did it. In essence, this means that authors would be adding criteria to the second-round rubric that applied only to their submission. We are interested in having this implemented and used in a class so that we can study its effect.

 
== What needs to be done? ==
* Develop UI for authors to create new questions to add to the second round-rubric. This should be a form that includes the following:
** A description of the revision plan. Eg: We will add feature X to address issues a,b and c. We will modify feature Y and expect it to resolve errors d, c and e.
** One or more questions for every proposed improvement. Example:
*** How effectively did feature X address / solve issues a, b and c?
*** Did modification of feature Y resolve error d?
* Every new question must be linked to the second-round questionnaire.
* Every new question must be linked to the author’s submission

 
== Problem Statement ==
In the 2nd round of reviews, the Author should be able to add a statement to direct towards Author selected improvements from Round 1 to Round 2.

 
== Motivation ==
The OSS and Final projects are different for every team. From a reviewers perspective, not all questions make sense for all projects. The motivation behind this project is:
* Questions unique to each project gives the reviewers a perspective on the author’s objectives.
* Allow the Author to get feedback on whether or not they accomplished their self-directed goal.

 
== Criteria for completion ==
# Direct user to Revision Improvement Questionnaire.
# Create a form for a Assignment Team to add Questions to a Questionnaire that are specific to that Submission.
# Append Revision Improvement Questionnaire to 2nd Round Review Questionnaire.

 
== Implementation Plan ==
 
=== Files to be modified ===
==== Questionnaire ====
* questionnaire_controller.rb
* questionnaire.rb
* author_review_questionnaire.rb ( doesn’t exist, needs to be created and named appropriately )
* questionnaires/*.erb
 
==== Submitted Content ====
* submitted_content_controller.rb
* submission_record.rb
 
=== UI mockups ===
The first image shows a mockup of what the Author will see on the submission page to submit new additional questions for review.
[[File:E1875U1_1.jpg|100px]]
Second is a view of what the reviewer will see. It should blend in with the review questions submitted by the instructor for all similar projects.
[[File:E1875U1_2.jpg|100px]]
 
 
=== Test Plan ===
# Authors should be able to add additional review questions to their submission.
# Reviewers should be able to give feedback according to the review question written by the author.
# Authors should be able to view the feedback given on the questions they wrote.
# ''Stretch'': Instructors should be able to set requirements on the number of additional review questions authors are required to add.

E1875 Revision Planning Tool

2018-11-14T03:41:12Z

Bbryson:

== What's it about? ==
In the first round of Expertiza reviews, we ask reviewers to give authors some guidance on how to improve their work. Then in the second round, reviewers rate how well authors have followed their suggestions. We could carry the interaction one step further if we asked authors to make up a revision plan based on the first-round reviews. That is, authors would say what they were planning to do to improve their work. Then second-round reviewers would assess how well they did it. In essence, this means that authors would be adding criteria to the second-round rubric that applied only to their submission. We are interested in having this implemented and used in a class so that we can study its effect.

 
== What needs to be done? ==
* Develop UI for authors to create new questions to add to the second round-rubric. This should be a form that includes the following:
** A description of the revision plan. Eg: We will add feature X to address issues a,b and c. We will modify feature Y and expect it to resolve errors d, c and e.
** One or more questions for every proposed improvement. Example:
*** How effectively did feature X address / solve issues a, b and c?
*** Did modification of feature Y resolve error d?
* Every new question must be linked to the second-round questionnaire.
* Every new question must be linked to the author’s submission

 
== Problem Statement ==
In the 2nd round of reviews, the Author should be able to add a statement to direct towards Author selected improvements from Round 1 to Round 2.

 
== Motivation ==
The OSS and Final projects are different for every team. From a reviewers perspective, not all questions make sense for all projects. The motivation behind this project is:
* Questions unique to each project gives the reviewers a perspective on the author’s objectives.
* Allow the Author to get feedback on whether or not they accomplished their self-directed goal.

 
== Criteria for completion ==
# Direct user to Revision Improvement Questionnaire.
# Create a form for a Assignment Team to add Questions to a Questionnaire that are specific to that Submission.
# Append Revision Improvement Questionnaire to 2nd Round Review Questionnaire.

 
== Implementation Plan ==
 
=== Files to be modified ===
==== Questionnaire ====
* questionnaire_controller.rb
* questionnaire.rb
* author_review_questionnaire.rb ( doesn’t exist, needs to be created and named appropriately )
* questionnaires/*.erb
 
==== Submitted Content ====
* submitted_content_controller.rb
* submission_record.rb
 
=== UI mockups ===
The first image shows a mockup of what the Author will see on the submission page to submit new additional questions for review.
[[File:E1875U1_1.jpg|200px]]
Second is a view of what the reviewer will see. It should blend in with the review questions submitted by the instructor for all similar projects.
[[File:E1875U1_2.jpg|200px]]
 
 
=== Test Plan ===
# Authors should be able to add additional review questions to their submission.
# Reviewers should be able to give feedback according to the review question written by the author.
# Authors should be able to view the feedback given on the questions they wrote.
# ''Stretch'': Instructors should be able to set requirements on the number of additional review questions authors are required to add.

E1875 Revision Planning Tool

2018-11-14T03:39:17Z

Bbryson:

== What's it about? ==
In the first round of Expertiza reviews, we ask reviewers to give authors some guidance on how to improve their work. Then in the second round, reviewers rate how well authors have followed their suggestions. We could carry the interaction one step further if we asked authors to make up a revision plan based on the first-round reviews. That is, authors would say what they were planning to do to improve their work. Then second-round reviewers would assess how well they did it. In essence, this means that authors would be adding criteria to the second-round rubric that applied only to their submission. We are interested in having this implemented and used in a class so that we can study its effect.

 
== What needs to be done? ==
* Develop UI for authors to create new questions to add to the second round-rubric. This should be a form that includes the following:
** A description of the revision plan. Eg: We will add feature X to address issues a,b and c. We will modify feature Y and expect it to resolve errors d, c and e.
** One or more questions for every proposed improvement. Example:
*** How effectively did feature X address / solve issues a, b and c?
*** Did modification of feature Y resolve error d?
* Every new question must be linked to the second-round questionnaire.
* Every new question must be linked to the author’s submission

 
== Problem Statement ==
In the 2nd round of reviews, the Author should be able to add a statement to direct towards Author selected improvements from Round 1 to Round 2.

 
== Motivation ==
The OSS and Final projects are different for every team. From a reviewers perspective, not all questions make sense for all projects. The motivation behind this project is:
* Questions unique to each project gives the reviewers a perspective on the author’s objectives.
* Allow the Author to get feedback on whether or not they accomplished their self-directed goal.

 
== Criteria for completion ==
# Direct user to Revision Improvement Questionnaire.
# Create a form for a Assignment Team to add Questions to a Questionnaire that are specific to that Submission.
# Append Revision Improvement Questionnaire to 2nd Round Review Questionnaire.

 
== Implementation Plan ==
 
=== Files to be modified ===
==== Questionnaire ====
* questionnaire_controller.rb
* questionnaire.rb
* author_review_questionnaire.rb ( doesn’t exist, needs to be created and named appropriately )
* questionnaires/*.erb
 
==== Submitted Content ====
* submitted_content_controller.rb
* submission_record.rb
 
=== UI mockups ===
The first image shows a mockup of what the Author will see on the submission page to submit new additional questions for review.
[[File:E1875U1_1.jpg]]
Second is a view of what the reviewer will see. It should blend in with the review questions submitted by the instructor for all similar projects.
[[File:E1875U1_2.jpg]]
 
 
=== Test Plan ===
# Authors should be able to add additional review questions to their submission.
# Reviewers should be able to give feedback according to the review question written by the author.
# Authors should be able to view the feedback given on the questions they wrote.
# ''Stretch'': Instructors should be able to set requirements on the number of additional review questions authors are required to add.

File:E1875UI 2.jpg

2018-11-14T03:36:57Z

Bbryson:

File:E1875U1 1.jpg

2018-11-14T03:36:25Z

Bbryson:

File:Snap1.jpg

2018-11-14T03:35:49Z

Bbryson:

CSC/ECE 517 Fall 2018/E1853 Write unit tests for menu.rb

2018-11-09T23:53:41Z

Bbryson:

This project wrote unit tests for the menu.rb model in Expertiza. '''A test plan can be found at the bottom.'''

==Project Introduction==
The Menu model is used to create the top bar menu in Expertiza. It does this by obtaining and organizing MenuItems based on the current user's Role. Before this project, there were no unit tests for menu.rb. This project seeks to bring the unit test coverage above 90%.

===Team===
Barrett Bryson (bbryson)

Komal Kangutkar (kmkangut)

===RSpec File===
The final result can be found at expertiza/spec/models/menu_spec.rb. This specific spec file can be run by calling the following in the expertiza directory:
<pre>
rspec -fd ./spec/models/menu_spec.rb
</pre>
The addition of the -fd argument will write out full descriptions of the tests and provide an easy look at the work we did.

==Design==
In total, we wrote 29 tests that covered all the functions in both Menu and its internal Node class. Using the given factories, we created 6 MenuItems (test1 to test6) to pass to the Menu as well as 1 Role used to test the Menu constructor.

let!(:test1) { create(:menu_item, name: "home1", parent_id: nil, seq: 1) }

admin_role = build(:role_of_administrator, id: 3, name: "Administrator", description: "", parent_id: nil, default_page_id: nil)

We stubbed the MenuItem method, items_for_permissions, to return an array of the 6 test items that we created.

allow(MenuItem).to receive(:items_for_permissions).with(anything).and_return(items)

Other pieces of the code were stubbed because these pieces should be tested in other model specs and not Menu spec. The double 'temp' is created, which acts as a stand-in for some other class objects which interact with Menu, in order to only test the functionalities of Menu.

Each method in menu.rb has at least two tests checking both a known success case and an edge case or potential failure. As an example, a detailed look at the tests for Menu#initialize is shown below.

<pre>
context "when role is nil" do
it "creates a new menu" do
menu = Menu.new
expect(menu.instance_of?(Menu))
end
end
</pre>
This first test revealed an error in the existing menu.rb code in the line shown below.
<pre>
items = MenuItem.items_for_permissions(role.try(:cache)[:credentials].try(:permission_ids))
</pre>
The below line shows the change that we made. This allowed the code to be more robust and prevent NoMethodError from nilClass. Without this change, a menu created with a nil role will throw an error causing the program to fail unnecessarily. This is important because the default value of role is nil and that should not fail.
<pre>
items = MenuItem.items_for_permissions(role.try(:cache).try(:[], :credentials).try(:permission_ids))
</pre>
The second test covers the main use case of Menu. It is supplied with a role and assembles a menu. Only a single role is tested because further testing of roles and menus should instead be handled in integration tests.
<pre>
context "when a role is passed as an argument" do
it "creates a new menu" do
admin_role = build(:role_of_administrator, id: 3, name: "Administrator", description: '', parent_id: nil, default_page_id: nil)
menu = Menu.new(admin_role)
expect(menu.instance_of?(Menu))
end
end
</pre>
The third test checks that when the menu is created with items, these items are put into nodes, arranged appropriately and contained within the menu. In this case, the children of root will contain a single item, the node with id 1, because this node has a nil parent. The other nodes all have non-nil parents.
<pre>
context "when menu has items" do
it "creates a new menu with items" do
menu = Menu.new
expect(menu.root.children.length).to eq(1)
end
end
</pre>
The final test checks a menu without any nodes. While this case is unlikely in actual use, it is important that it can be handled without throwing any errors. When a menu without any items is created, the root will never have anything added to its children array so this array will be nil.
<pre>
context "when menu has not items" do
it "creates a new menu without items" do
allow(MenuItem).to receive(:items_for_permissions).with(anything).and_return([])
menu = Menu.new
expect(menu.root.children).to be_nil
end
end
</pre>
These 4 tests alone provide nearly 85% coverage of menu.rb because of how much they rely on a variety of other methods within the class.

Many of the functions in menu.rb return a Menu::Node. The simplest, Menu#get_item, takes a Node id and returns the corresponding Node object. All following functions use this to test that the correct Node is returned. However to prevent circular logic, the Menu#get_item test only checks the id of the returned Node.

==Results==
The 29 tests provide 100% coverage of the lines in menu.rb. Before the project the coverage was only

A video of all tests running can be seen [https://www.youtube.com/watch?v=yB_E5OORja0 here].

The main repository can be found [https://github.com/expertiza/expertiza here]

The forked git repository for this project can be found [https://github.com/BarrettJB/expertiza/ here]

Below is a snapshot of the coverage of our tests. Full coverage can be found at expertiza/coverage/coverage.html. The specific coverage can be found in menu under the models tab.

[[File:Fall2018E1853Coverage.png]]

==Test Plan==
Below is a list of the descriptions of all of the tests we wrote

'''Menu::Node'''

#initialize
when role is nil
initializes with a nil parent

#setup
when item.action_controller is nil
returns /content_page.name
when item.action_controller is not nil
returns /controller.name/controller_action.name

#content_page
should update the content_page instance variable

#controller_action
when @controller_action already has a value
remains the same
when @controller_action is nil
updates @controller_action

#site_controller
when @site_controller is nil
updates @site_controller
when @site_controller already has a value
remains the same

#add_child
when node has children
adds a child
when node has no children
can add multiple children
when node has no children
adds a child

'''Menu'''
#initialize
when menu has items
creates a new menu with item
when menu has not items
creates a new menu without items
when role is nil
creates a new menu
when a role is passed as an argument
creates a new menu

#select
returns a node.id based on the given name

#get_item
when menu has items
returns the correct item
when menu has no items
returns nil
when a nonexistent id is passed
returns nil

#get_menu
when a node is selected
returns a list of nodes that are the children of the selected node
when called on a nonexistent node
returns nil
when menu has no items
returns nil

#selected?
when id passed is not of a selected menu item
returns false
when id passed is of a selected menu item
returns true
when passed nil as the id
return false

#selected
when a nonexistent node is selected
returns nil
when an item is selected
returns the name of the currently selected item

#crumbs
when a node besides root is selected
returns a list of nodes based on the selected item
when root is selected
returns a list of nodes based on the root

CSC/ECE 517 Fall 2018/E1853 Write unit tests for menu.rb

2018-11-09T23:48:23Z

Bbryson:

This project wrote unit tests for the menu.rb model in Expertiza. '''A test plan can be found at the bottom.'''

==Project Introduction==
The Menu model is used to create the top bar menu in Expertiza. It does this by obtaining and organizing MenuItems based on the current user's Role. Before this project, there were no unit tests for menu.rb. This project seeks to bring the unit test coverage above 90%.

===Team===
Barrett Bryson (bbryson)

Komal Kangutkar (kmkangut)

===RSpec File===
The final result can be found at expertiza/spec/models/menu_spec.rb. This specific spec file can be run by calling the following in the expertiza directory:
<pre>
rspec -fd ./spec/models/menu_spec.rb
</pre>
The addition of the -fd argument will write out full descriptions of the tests and provide an easy look at the work we did.

==Design==
In total, we wrote 29 tests that covered all the functions in both Menu and its internal Node class. Using the given factories, we created 6 MenuItems (test1 to test6) to pass to the Menu as well as 1 Role used to test the Menu constructor.

let!(:test1) { create(:menu_item, name: "home1", parent_id: nil, seq: 1) }

admin_role = build(:role_of_administrator, id: 3, name: "Administrator", description: "", parent_id: nil, default_page_id: nil)

We stubbed the MenuItem method, items_for_permissions, to return an array of the 6 test items that we created.

allow(MenuItem).to receive(:items_for_permissions).with(anything).and_return(items)

Other pieces of the code were stubbed because these pieces should be tested in other model specs and not Menu spec. The double 'temp' is created, which acts as a stand-in for some other class objects which interact with Menu, in order to only test the functionalities of Menu.

Each method in menu.rb has at least two tests checking both a known success case and an edge case or potential failure. As an example, a detailed look at the tests for Menu#initialize is shown below.

<pre>
context "when role is nil" do
it "creates a new menu" do
menu = Menu.new
expect(menu.instance_of?(Menu))
end
end
</pre>
This first test revealed an error in the existing menu.rb code in the line shown below.
<pre>
items = MenuItem.items_for_permissions(role.try(:cache)[:credentials].try(:permission_ids))
</pre>
The below line shows the change that we made. This allowed the code to be more robust and prevent NoMethodError from nilClass. Without this change, a menu created with a nil role will throw an error causing the program to fail unnecessarily. This is important because the default value of role is nil and that should not fail.
<pre>
items = MenuItem.items_for_permissions(role.try(:cache).try(:[], :credentials).try(:permission_ids))
</pre>
The second test covers the main use case of Menu. It is supplied with a role and assembles a menu. Only a single role is tested because further testing of roles and menus should instead be handled in integration tests.
<pre>
context "when a role is passed as an argument" do
it "creates a new menu" do
admin_role = build(:role_of_administrator, id: 3, name: "Administrator", description: '', parent_id: nil, default_page_id: nil)
menu = Menu.new(admin_role)
expect(menu.instance_of?(Menu))
end
end
</pre>
The third test checks that when the menu is created with items, these items are put into nodes, arranged appropriately and contained within the menu. In this case, the children of root will contain a single item, the node with id 1, because this node has a nil parent. The other nodes all have non-nil parents.
<pre>
context "when menu has items" do
it "creates a new menu with items" do
menu = Menu.new
expect(menu.root.children.length).to eq(1)
end
end
</pre>
The final test checks a menu without any nodes. While this case is unlikely in actual use, it is important that it can be handled without throwing any errors. When a menu without any items is created, the root will never have anything added to its children array so this array will be nil.
<pre>
context "when menu has not items" do
it "creates a new menu without items" do
allow(MenuItem).to receive(:items_for_permissions).with(anything).and_return([])
menu = Menu.new
expect(menu.root.children).to be_nil
end
end
</pre>
These 4 tests alone provide nearly 85% coverage of menu.rb because of how much they rely on a variety of other methods within the class.

Many of the functions in menu.rb return a Menu::Node. The simplest, Menu#get_item, takes a Node id and returns the corresponding Node object. All following functions use this to test that the correct Node is returned. However to prevent circular logic, the Menu#get_item test only checks the id of the returned Node.

==Results==
The 29 tests provide 100% coverage of the lines in menu.rb.

A video of all tests running can be seen [https://www.youtube.com/watch?v=yB_E5OORja0 here].

The main repository can be found [https://github.com/expertiza/expertiza here]

The forked git repository for this project can be found [https://github.com/BarrettJB/expertiza/ here]

Below is a snapshot of the coverage of our tests. Full coverage can be found at expertiza/coverage/coverage.html. The specific coverage can be found in menu under the models tab.

[[File:Fall2018E1853Coverage.png]]

==Test Plan==
Below is a list of the descriptions of all of the tests we wrote

'''Menu::Node'''

#initialize
when role is nil
initializes with a nil parent

#setup
when item.action_controller is nil
returns /content_page.name
when item.action_controller is not nil
returns /controller.name/controller_action.name

#content_page
should update the content_page instance variable

#controller_action
when @controller_action already has a value
remains the same
when @controller_action is nil
updates @controller_action

#site_controller
when @site_controller is nil
updates @site_controller
when @site_controller already has a value
remains the same

#add_child
when node has children
adds a child
when node has no children
can add multiple children
when node has no children
adds a child

'''Menu'''
#initialize
when menu has items
creates a new menu with item
when menu has not items
creates a new menu without items
when role is nil
creates a new menu
when a role is passed as an argument
creates a new menu

#select
returns a node.id based on the given name

#get_item
when menu has items
returns the correct item
when menu has no items
returns nil
when a nonexistent id is passed
returns nil

#get_menu
when a node is selected
returns a list of nodes that are the children of the selected node
when called on a nonexistent node
returns nil
when menu has no items
returns nil

#selected?
when id passed is not of a selected menu item
returns false
when id passed is of a selected menu item
returns true
when passed nil as the id
return false

#selected
when a nonexistent node is selected
returns nil
when an item is selected
returns the name of the currently selected item

#crumbs
when a node besides root is selected
returns a list of nodes based on the selected item
when root is selected
returns a list of nodes based on the root

CSC/ECE 517 Fall 2018/E1853 Write unit tests for menu.rb

2018-11-09T23:48:01Z

Bbryson:

This project wrote unit tests for the menu.rb model in Expertiza. '''A test plan can be found at the bottom.'''

==Project Introduction==
The Menu model is used to create the top bar menu in Expertiza. It does this by obtaining and organizing MenuItems based on the current user's Role. Before this project, there were no unit tests for menu.rb. This project seeks to bring the unit test coverage above 90%.

===Team===
Barrett Bryson (bbryson)

Komal Kangutkar (kmkangut)

===RSpec File===
The final result can be found at expertiza/spec/models/menu_spec.rb. This specific spec file can be run by calling the following in the expertiza directory:
<pre>
rspec -fd ./spec/models/menu_spec.rb
</pre>
The addition of the -fd argument will write out full descriptions of the tests and provide an easy look at the work we did.

==Design==
In total, we wrote 29 tests that covered all the functions in both Menu and its internal Node class. Using the given factories, we created 6 MenuItems (test1 to test6) to pass to the Menu as well as 1 Role used to test the Menu constructor.

let!(:test1) { create(:menu_item, name: "home1", parent_id: nil, seq: 1) }

admin_role = build(:role_of_administrator, id: 3, name: "Administrator", description: "", parent_id: nil, default_page_id: nil)

We stubbed the MenuItem method, items_for_permissions, to return an array of the 6 test items that we created.

allow(MenuItem).to receive(:items_for_permissions).with(anything).and_return(items)

Other pieces of the code were stubbed because these pieces should be tested in other model specs and not Menu spec. The double 'temp' is created, which acts as a stand-in for some other class objects which interact with Menu, in order to only test the functionalities of Menu.

Each method in menu.rb has at least two tests checking both a known success case and an edge case or potential failure. As an example, a detailed look at the tests for Menu#initialize is shown below.

<pre>
context "when role is nil" do
it "creates a new menu" do
menu = Menu.new
expect(menu.instance_of?(Menu))
end
end
</pre>
This first test revealed an error in the existing menu.rb code in the line shown below.
<pre>
items = MenuItem.items_for_permissions(role.try(:cache)[:credentials].try(:permission_ids))
</pre>
The below line shows the change that we made. This allowed the code to be more robust and prevent NoMethodError from nilClass. Without this change, a menu created with a nil role will throw an error causing the program to fail unnecessarily. This is important because the default value of role is nil and that should not fail.
<pre>
items = MenuItem.items_for_permissions(role.try(:cache).try(:[], :credentials).try(:permission_ids))
</pre>
The second test covers the main use case of Menu. It is supplied with a role and assembles a menu. Only a single role is tested because further testing of roles and menus should instead be handled in integration tests.
<pre>
context "when a role is passed as an argument" do
it "creates a new menu" do
admin_role = build(:role_of_administrator, id: 3, name: "Administrator", description: '', parent_id: nil, default_page_id: nil)
menu = Menu.new(admin_role)
expect(menu.instance_of?(Menu))
end
end
</pre>
The third test checks that when the menu is created with items, these items are put into nodes, arranged appropriately and contained within the menu. In this case, the children of root will contain a single item, the node with id 1, because this node has a nil parent. The other nodes all have non-nil parents.
<pre>
context "when menu has items" do
it "creates a new menu with items" do
menu = Menu.new
expect(menu.root.children.length).to eq(1)
end
end
</pre>
The final test checks a menu without any nodes. While this case is unlikely in actual use, it is important that it can be handled without throwing any errors. When a menu without any items is created, the root will never have anything added to its children array so this array will be nil.
<pre>
context "when menu has not items" do
it "creates a new menu without items" do
allow(MenuItem).to receive(:items_for_permissions).with(anything).and_return([])
menu = Menu.new
expect(menu.root.children).to be_nil
end
end
</pre>
These 4 tests alone provide nearly 85% coverage of menu.rb because of how much they rely on a variety of other methods within the class.

Many of the functions in menu.rb return a Menu::Node. The simplest, Menu#get_item, takes a Node id and returns the corresponding Node object. All following functions use this to test that the correct Node is returned. However to prevent circular logic, the Menu#get_item test only checks the id of the returned Node.

==Results==
The 29 tests provide 100% coverage of the lines in menu.rb.

A video of all tests running can be seen [https://www.youtube.com/watch?v=yB_E5OORja0 here].

The main repository can be found [https://github.com/expertiza/expertiza here]

The forked git repository for this project can be found [https://github.com/BarrettJB/expertiza/ here]

Below is a snapshot of the coverage of our tests. Full coverage can be found at expertiza/coverage/coverage.html. The specific coverage can be found in menu under the models tab.
[[File:Fall2018E1853Coverage.png]]

==Test Plan==
Below is a list of the descriptions of all of the tests we wrote

'''Menu::Node'''

#initialize
when role is nil
initializes with a nil parent

#setup
when item.action_controller is nil
returns /content_page.name
when item.action_controller is not nil
returns /controller.name/controller_action.name

#content_page
should update the content_page instance variable

#controller_action
when @controller_action already has a value
remains the same
when @controller_action is nil
updates @controller_action

#site_controller
when @site_controller is nil
updates @site_controller
when @site_controller already has a value
remains the same

#add_child
when node has children
adds a child
when node has no children
can add multiple children
when node has no children
adds a child

'''Menu'''
#initialize
when menu has items
creates a new menu with item
when menu has not items
creates a new menu without items
when role is nil
creates a new menu
when a role is passed as an argument
creates a new menu

#select
returns a node.id based on the given name

#get_item
when menu has items
returns the correct item
when menu has no items
returns nil
when a nonexistent id is passed
returns nil

#get_menu
when a node is selected
returns a list of nodes that are the children of the selected node
when called on a nonexistent node
returns nil
when menu has no items
returns nil

#selected?
when id passed is not of a selected menu item
returns false
when id passed is of a selected menu item
returns true
when passed nil as the id
return false

#selected
when a nonexistent node is selected
returns nil
when an item is selected
returns the name of the currently selected item

#crumbs
when a node besides root is selected
returns a list of nodes based on the selected item
when root is selected
returns a list of nodes based on the root

File:Fall2018E1853Coverage.png

2018-11-09T23:45:46Z

Bbryson: A snap of the coverage provided by our project

A snap of the coverage provided by our project

CSC/ECE 517 Fall 2018/E1853 Write unit tests for menu.rb

2018-11-09T23:36:18Z

Bbryson:

This project wrote unit tests for the menu.rb model in Expertiza. '''A test plan can be found at the bottom.'''

==Project Introduction==
The Menu model is used to create the top bar menu in Expertiza. It does this by obtaining and organizing MenuItems based on the current user's Role. Before this project, there were no unit tests for menu.rb. This project seeks to bring the unit test coverage above 90%.

===Team===
Barrett Bryson (bbryson)

Komal Kangutkar (kmkangut)

===RSpec File===
The final result can be found at expertiza/spec/models/menu_spec.rb. This specific spec file can be run by calling the following in the expertiza directory:
<pre>
rspec -fd ./spec/models/menu_spec.rb
</pre>
The addition of the -fd argument will write out full descriptions of the tests and provide an easy look at the work we did.

==Design==
In total, we wrote 29 tests that covered all the functions in both Menu and its internal Node class. Using the given factories, we created 6 MenuItems (test1 to test6) to pass to the Menu as well as 1 Role used to test the Menu constructor.

let!(:test1) { create(:menu_item, name: "home1", parent_id: nil, seq: 1) }

admin_role = build(:role_of_administrator, id: 3, name: "Administrator", description: "", parent_id: nil, default_page_id: nil)

We stubbed the MenuItem method, items_for_permissions, to return an array of the 6 test items that we created.

allow(MenuItem).to receive(:items_for_permissions).with(anything).and_return(items)

Other pieces of the code were stubbed because these pieces should be tested in other model specs and not Menu spec. The double 'temp' is created, which acts as a stand-in for some other class objects which interact with Menu, in order to only test the functionalities of Menu.

Each method in menu.rb has at least two tests checking both a known success case and an edge case or potential failure. As an example, a detailed look at the tests for Menu#initialize is shown below.

<pre>
context "when role is nil" do
it "creates a new menu" do
menu = Menu.new
expect(menu.instance_of?(Menu))
end
end
</pre>
This first test revealed an error in the existing menu.rb code in the line shown below.
<pre>
items = MenuItem.items_for_permissions(role.try(:cache)[:credentials].try(:permission_ids))
</pre>
The below line shows the change that we made. This allowed the code to be more robust and prevent NoMethodError from nilClass. Without this change, a menu created with a nil role will throw an error causing the program to fail unnecessarily. This is important because the default value of role is nil and that should not fail.
<pre>
items = MenuItem.items_for_permissions(role.try(:cache).try(:[], :credentials).try(:permission_ids))
</pre>
The second test covers the main use case of Menu. It is supplied with a role and assembles a menu. Only a single role is tested because further testing of roles and menus should instead be handled in integration tests.
<pre>
context "when a role is passed as an argument" do
it "creates a new menu" do
admin_role = build(:role_of_administrator, id: 3, name: "Administrator", description: '', parent_id: nil, default_page_id: nil)
menu = Menu.new(admin_role)
expect(menu.instance_of?(Menu))
end
end
</pre>
The third test checks that when the menu is created with items, these items are put into nodes, arranged appropriately and contained within the menu. In this case, the children of root will contain a single item, the node with id 1, because this node has a nil parent. The other nodes all have non-nil parents.
<pre>
context "when menu has items" do
it "creates a new menu with items" do
menu = Menu.new
expect(menu.root.children.length).to eq(1)
end
end
</pre>
The final test checks a menu without any nodes. While this case is unlikely in actual use, it is important that it can be handled without throwing any errors. When a menu without any items is created, the root will never have anything added to its children array so this array will be nil.
<pre>
context "when menu has not items" do
it "creates a new menu without items" do
allow(MenuItem).to receive(:items_for_permissions).with(anything).and_return([])
menu = Menu.new
expect(menu.root.children).to be_nil
end
end
</pre>
These 4 tests alone provide nearly 85% coverage of menu.rb because of how much they rely on a variety of other methods within the class.

Many of the functions in menu.rb return a Menu::Node. The simplest, Menu#get_item, takes a Node id and returns the corresponding Node object. All following functions use this to test that the correct Node is returned. However to prevent circular logic, the Menu#get_item test only checks the id of the returned Node.

==Results==
The 29 tests provide 100% coverage of the lines in menu.rb.

A video of all tests running can be seen [https://www.youtube.com/watch?v=yB_E5OORja0 here].

The main repository can be found [https://github.com/expertiza/expertiza here]

The forked git repository for this project can be found [https://github.com/BarrettJB/expertiza/ here]

==Test Plan==
Below is a list of the descriptions of all of the tests we wrote

'''Menu::Node'''

#initialize
when role is nil
initializes with a nil parent

#setup
when item.action_controller is nil
returns /content_page.name
when item.action_controller is not nil
returns /controller.name/controller_action.name

#content_page
should update the content_page instance variable

#controller_action
when @controller_action already has a value
remains the same
when @controller_action is nil
updates @controller_action

#site_controller
when @site_controller is nil
updates @site_controller
when @site_controller already has a value
remains the same

#add_child
when node has children
adds a child
when node has no children
can add multiple children
when node has no children
adds a child

'''Menu'''
#initialize
when menu has items
creates a new menu with item
when menu has not items
creates a new menu without items
when role is nil
creates a new menu
when a role is passed as an argument
creates a new menu

#select
returns a node.id based on the given name

#get_item
when menu has items
returns the correct item
when menu has no items
returns nil
when a nonexistent id is passed
returns nil

#get_menu
when a node is selected
returns a list of nodes that are the children of the selected node
when called on a nonexistent node
returns nil
when menu has no items
returns nil

#selected?
when id passed is not of a selected menu item
returns false
when id passed is of a selected menu item
returns true
when passed nil as the id
return false

#selected
when a nonexistent node is selected
returns nil
when an item is selected
returns the name of the currently selected item

#crumbs
when a node besides root is selected
returns a list of nodes based on the selected item
when root is selected
returns a list of nodes based on the root

CSC/ECE 517 Fall 2018/E1853 Write unit tests for menu.rb

2018-11-09T23:34:09Z

Bbryson:

This project wrote unit tests for the menu.rb model in Expertiza. '''If you are a reviewer who just wants fast answers the test plan is at the bottom.'''

==Project Introduction==
The Menu model is used to create the top bar menu in Expertiza. It does this by obtaining and organizing MenuItems based on the current user's Role. Before this project, there were no unit tests for menu.rb. This project seeks to bring the unit test coverage above 90%.

===Team===
Barrett Bryson (bbryson)

Komal Kangutkar (kmkangut)

===RSpec File===
The final result can be found at expertiza/spec/models/menu_spec.rb. This specific spec file can be run by calling the following in the expertiza directory:
<pre>
rspec -fd ./spec/models/menu_spec.rb
</pre>
The addition of the -fd argument will write out full descriptions of the tests and provide an easy look at the work we did.

==Design==
In total, we wrote 29 tests that covered all the functions in both Menu and its internal Node class. Using the given factories, we created 6 MenuItems (test1 to test6) to pass to the Menu as well as 1 Role used to test the Menu constructor.

let!(:test1) { create(:menu_item, name: "home1", parent_id: nil, seq: 1) }

admin_role = build(:role_of_administrator, id: 3, name: "Administrator", description: "", parent_id: nil, default_page_id: nil)

We stubbed the MenuItem method, items_for_permissions, to return an array of the 6 test items that we created.

allow(MenuItem).to receive(:items_for_permissions).with(anything).and_return(items)

Other pieces of the code were stubbed because these pieces should be tested in other model specs and not Menu spec. The double 'temp' is created, which acts as a stand-in for some other class objects which interact with Menu, in order to only test the functionalities of Menu.

Each method in menu.rb has at least two tests checking both a known success case and an edge case or potential failure. As an example, a detailed look at the tests for Menu#initialize is shown below.

<pre>
context "when role is nil" do
it "creates a new menu" do
menu = Menu.new
expect(menu.instance_of?(Menu))
end
end
</pre>
This first test revealed an error in the existing menu.rb code in the line shown below.
<pre>
items = MenuItem.items_for_permissions(role.try(:cache)[:credentials].try(:permission_ids))
</pre>
The below line shows the change that we made. This allowed the code to be more robust and prevent NoMethodError from nilClass. Without this change, a menu created with a nil role will throw an error causing the program to fail unnecessarily. This is important because the default value of role is nil and that should not fail.
<pre>
items = MenuItem.items_for_permissions(role.try(:cache).try(:[], :credentials).try(:permission_ids))
</pre>
The second test covers the main use case of Menu. It is supplied with a role and assembles a menu. Only a single role is tested because further testing of roles and menus should instead be handled in integration tests.
<pre>
context "when a role is passed as an argument" do
it "creates a new menu" do
admin_role = build(:role_of_administrator, id: 3, name: "Administrator", description: '', parent_id: nil, default_page_id: nil)
menu = Menu.new(admin_role)
expect(menu.instance_of?(Menu))
end
end
</pre>
The third test checks that when the menu is created with items, these items are put into nodes, arranged appropriately and contained within the menu. In this case, the children of root will contain a single item, the node with id 1, because this node has a nil parent. The other nodes all have non-nil parents.
<pre>
context "when menu has items" do
it "creates a new menu with items" do
menu = Menu.new
expect(menu.root.children.length).to eq(1)
end
end
</pre>
The final test checks a menu without any nodes. While this case is unlikely in actual use, it is important that it can be handled without throwing any errors. When a menu without any items is created, the root will never have anything added to its children array so this array will be nil.
<pre>
context "when menu has not items" do
it "creates a new menu without items" do
allow(MenuItem).to receive(:items_for_permissions).with(anything).and_return([])
menu = Menu.new
expect(menu.root.children).to be_nil
end
end
</pre>
These 4 tests alone provide nearly 85% coverage of menu.rb because of how much they rely on a variety of other methods within the class.

Many of the functions in menu.rb return a Menu::Node. The simplest, Menu#get_item, takes a Node id and returns the corresponding Node object. All following functions use this to test that the correct Node is returned. However to prevent circular logic, the Menu#get_item test only checks the id of the returned Node.

==Results==
The 29 tests provide 100% coverage of the lines in menu.rb.

A video of all tests running can be seen [https://www.youtube.com/watch?v=yB_E5OORja0 here].

The main repository can be found [https://github.com/expertiza/expertiza here]

The forked git repository for this project can be found [https://github.com/BarrettJB/expertiza/ here]

==Test Plan==
Below is a list of the descriptions of all of the tests we wrote

'''Menu::Node'''

#initialize
when role is nil
initializes with a nil parent

#setup
when item.action_controller is nil
returns /content_page.name
when item.action_controller is not nil
returns /controller.name/controller_action.name

#content_page
should update the content_page instance variable

#controller_action
when @controller_action already has a value
remains the same
when @controller_action is nil
updates @controller_action

#site_controller
when @site_controller is nil
updates @site_controller
when @site_controller already has a value
remains the same

#add_child
when node has children
adds a child
when node has no children
can add multiple children
when node has no children
adds a child

'''Menu'''
#initialize
when menu has items
creates a new menu with item
when menu has not items
creates a new menu without items
when role is nil
creates a new menu
when a role is passed as an argument
creates a new menu

#select
returns a node.id based on the given name

#get_item
when menu has items
returns the correct item
when menu has no items
returns nil
when a nonexistent id is passed
returns nil

#get_menu
when a node is selected
returns a list of nodes that are the children of the selected node
when called on a nonexistent node
returns nil
when menu has no items
returns nil

#selected?
when id passed is not of a selected menu item
returns false
when id passed is of a selected menu item
returns true
when passed nil as the id
return false

#selected
when a nonexistent node is selected
returns nil
when an item is selected
returns the name of the currently selected item

#crumbs
when a node besides root is selected
returns a list of nodes based on the selected item
when root is selected
returns a list of nodes based on the root

CSC/ECE 517 Fall 2018

2018-11-02T21:19:31Z

Bbryson:

CSC/ECE 517 Fall 2018

2018-11-02T21:19:20Z

Bbryson:

CSC/ECE 517 Fall 2018/E1853 Write unit tests for menu.rb

2018-11-02T21:17:44Z

Bbryson: /* Results */

This project wrote unit tests for the Menu.rb model in Expertiza.

==Project Introduction==
The menu model is used to create the top bar menu in expertiza. It does this by obtaining and organizing Menu_Items based on the current users Role. Before this project there were no unit tests for menu.rb. This project seeked to bring the unit test coverage above %90.

===Team===
Barrett Bryson (bbryson)

Komal Kangutkar (kmkangut)

===RSpec File===
The final result can be found at expertiza/spec/models/menu_spec.rb. This specific test can be run by calling in the expertiza directory:
<pre>
rspec -fd ./spec/models/menu_spec.rb
</pre>
The addition of the -fd argument will write out full descriptions of the tests and provide a easy look at the work we did.

==Design==
In total we wrote 29 tests that covered all of the functions in both menu and its internal node class. We created 6 menu items for testing using the given factories as well as 1 role used to test the menu constructor. We stubbed menu item to always return an array of the 6 test items that we created. Other pieces of the code were stubbed because these pieces should be tested by menu item not menu. The double temp is used to only test the functionalities of menu.

Each method in menu.rb has at least two tests checking both a know success case and a edge case or potential failure. As an example, a detailed look at the functions to test menu#initialize is found below.

<pre>
context "when role is nil" do
it "creates a new menu" do
menu = Menu.new
expect(menu.instance_of?(Menu))
end
end
</pre>
This first test revealed an error in the existing menu.rb code in the line shown below. The second line shows the change that we made. This allowed the code to be more robust and prevent noMethodErrors from nilClass. Without this change a menu created with a nil role will throw an error causing the program to fail unnecessarily. This is important because the default value of role is nil and that should not fail.
<pre>
items = MenuItem.items_for_permissions(role.try(:cache)[:credentials].try(:permission_ids))
</pre>
<pre>
items = MenuItem.items_for_permissions(role.try(:cache).try(:[], :credentials).try(:permission_ids))
</pre>
The second test uses the main covers the main use case of menu. It will be supplied with a role and will assemble a menu. Only a single role is tested because further testing of roles and menus should instead be handled in integration tests.
<pre>
context "when a role is passed as an argument" do
it "creates a new menu" do
admin_role = build(:role_of_administrator, id: 3, name: "Administrator", description: '', parent_id: nil, default_page_id: nil)
menu = Menu.new(admin_role)
expect(menu.instance_of?(Menu))
end
end
</pre>
The third test checks that when the menu is created with items, these items are put into nodes and contained within the menu. In this case the children of root will contain a single item, the node with id 1, because this node has a nil parent. The other nodes all have parents.
<pre>
context "when menu has items" do
it "creates a new menu with items" do
menu = Menu.new
expect(menu.root.children.length).to eq(1)
end
end
</pre>
The final test checks a menu without any nodes. While this case is unlikely in actual use it is important it can be handled without throwing any errors. When a menu without any items is created, the root will never have anything added to its children array so this array will be nil.
<pre>
context "when menu has not items" do
it "creates a new menu without items" do
allow(MenuItem).to receive(:items_for_permissions).with(anything).and_return([])
menu = Menu.new
expect(menu.root.children).to be_nil
end
end
</pre>
This 4 tests alone provide nearly 85% coverage of menu.rb because of how much they rely on a variety of other methods within the class.

Many of the functions in menu return a menu node. The simplest, get_item, takes the node id and returns the node object. All following functions use this to test that the correct node is returned. However to prevent circular logic, the get_item test only checks the id of the returned node.

==Results==
The 29 tests provide 100% coverage of the lines in menu.rb.

A video of all tests running can be seen [https://www.youtube.com/watch?v=yB_E5OORja0 here].

The main repository can be found [https://github.com/expertiza/expertiza here]

The forked git repository for this project can be found [https://github.com/BarrettJB/expertiza/ here]

==List of all tests==
Below is a list of the descriptions of all of the tests we wrote

CSC/ECE 517 Fall 2018/E1853 Write unit tests for menu.rb

2018-11-02T21:17:30Z

Bbryson: /* Results */

This project wrote unit tests for the Menu.rb model in Expertiza.

==Project Introduction==
The menu model is used to create the top bar menu in expertiza. It does this by obtaining and organizing Menu_Items based on the current users Role. Before this project there were no unit tests for menu.rb. This project seeked to bring the unit test coverage above %90.

===Team===
Barrett Bryson (bbryson)

Komal Kangutkar (kmkangut)

===RSpec File===
The final result can be found at expertiza/spec/models/menu_spec.rb. This specific test can be run by calling in the expertiza directory:
<pre>
rspec -fd ./spec/models/menu_spec.rb
</pre>
The addition of the -fd argument will write out full descriptions of the tests and provide a easy look at the work we did.

==Design==
In total we wrote 29 tests that covered all of the functions in both menu and its internal node class. We created 6 menu items for testing using the given factories as well as 1 role used to test the menu constructor. We stubbed menu item to always return an array of the 6 test items that we created. Other pieces of the code were stubbed because these pieces should be tested by menu item not menu. The double temp is used to only test the functionalities of menu.

Each method in menu.rb has at least two tests checking both a know success case and a edge case or potential failure. As an example, a detailed look at the functions to test menu#initialize is found below.

<pre>
context "when role is nil" do
it "creates a new menu" do
menu = Menu.new
expect(menu.instance_of?(Menu))
end
end
</pre>
This first test revealed an error in the existing menu.rb code in the line shown below. The second line shows the change that we made. This allowed the code to be more robust and prevent noMethodErrors from nilClass. Without this change a menu created with a nil role will throw an error causing the program to fail unnecessarily. This is important because the default value of role is nil and that should not fail.
<pre>
items = MenuItem.items_for_permissions(role.try(:cache)[:credentials].try(:permission_ids))
</pre>
<pre>
items = MenuItem.items_for_permissions(role.try(:cache).try(:[], :credentials).try(:permission_ids))
</pre>
The second test uses the main covers the main use case of menu. It will be supplied with a role and will assemble a menu. Only a single role is tested because further testing of roles and menus should instead be handled in integration tests.
<pre>
context "when a role is passed as an argument" do
it "creates a new menu" do
admin_role = build(:role_of_administrator, id: 3, name: "Administrator", description: '', parent_id: nil, default_page_id: nil)
menu = Menu.new(admin_role)
expect(menu.instance_of?(Menu))
end
end
</pre>
The third test checks that when the menu is created with items, these items are put into nodes and contained within the menu. In this case the children of root will contain a single item, the node with id 1, because this node has a nil parent. The other nodes all have parents.
<pre>
context "when menu has items" do
it "creates a new menu with items" do
menu = Menu.new
expect(menu.root.children.length).to eq(1)
end
end
</pre>
The final test checks a menu without any nodes. While this case is unlikely in actual use it is important it can be handled without throwing any errors. When a menu without any items is created, the root will never have anything added to its children array so this array will be nil.
<pre>
context "when menu has not items" do
it "creates a new menu without items" do
allow(MenuItem).to receive(:items_for_permissions).with(anything).and_return([])
menu = Menu.new
expect(menu.root.children).to be_nil
end
end
</pre>
This 4 tests alone provide nearly 85% coverage of menu.rb because of how much they rely on a variety of other methods within the class.

Many of the functions in menu return a menu node. The simplest, get_item, takes the node id and returns the node object. All following functions use this to test that the correct node is returned. However to prevent circular logic, the get_item test only checks the id of the returned node.

==Results==
The 29 tests provide 100% coverage of the lines in menu.rb. A video of all tests running can be seen [https://www.youtube.com/watch?v=yB_E5OORja0 here].

The main repository can be found [https://github.com/expertiza/expertiza here]

The forked git repository for this project can be found [https://github.com/BarrettJB/expertiza/ here]

==List of all tests==
Below is a list of the descriptions of all of the tests we wrote

CSC/ECE 517 Fall 2018/E1853 Write unit tests for menu.rb

2018-11-02T21:17:20Z

Bbryson: /* Results */

This project wrote unit tests for the Menu.rb model in Expertiza.

==Project Introduction==
The menu model is used to create the top bar menu in expertiza. It does this by obtaining and organizing Menu_Items based on the current users Role. Before this project there were no unit tests for menu.rb. This project seeked to bring the unit test coverage above %90.

===Team===
Barrett Bryson (bbryson)

Komal Kangutkar (kmkangut)

===RSpec File===
The final result can be found at expertiza/spec/models/menu_spec.rb. This specific test can be run by calling in the expertiza directory:
<pre>
rspec -fd ./spec/models/menu_spec.rb
</pre>
The addition of the -fd argument will write out full descriptions of the tests and provide a easy look at the work we did.

==Design==
In total we wrote 29 tests that covered all of the functions in both menu and its internal node class. We created 6 menu items for testing using the given factories as well as 1 role used to test the menu constructor. We stubbed menu item to always return an array of the 6 test items that we created. Other pieces of the code were stubbed because these pieces should be tested by menu item not menu. The double temp is used to only test the functionalities of menu.

Each method in menu.rb has at least two tests checking both a know success case and a edge case or potential failure. As an example, a detailed look at the functions to test menu#initialize is found below.

<pre>
context "when role is nil" do
it "creates a new menu" do
menu = Menu.new
expect(menu.instance_of?(Menu))
end
end
</pre>
This first test revealed an error in the existing menu.rb code in the line shown below. The second line shows the change that we made. This allowed the code to be more robust and prevent noMethodErrors from nilClass. Without this change a menu created with a nil role will throw an error causing the program to fail unnecessarily. This is important because the default value of role is nil and that should not fail.
<pre>
items = MenuItem.items_for_permissions(role.try(:cache)[:credentials].try(:permission_ids))
</pre>
<pre>
items = MenuItem.items_for_permissions(role.try(:cache).try(:[], :credentials).try(:permission_ids))
</pre>
The second test uses the main covers the main use case of menu. It will be supplied with a role and will assemble a menu. Only a single role is tested because further testing of roles and menus should instead be handled in integration tests.
<pre>
context "when a role is passed as an argument" do
it "creates a new menu" do
admin_role = build(:role_of_administrator, id: 3, name: "Administrator", description: '', parent_id: nil, default_page_id: nil)
menu = Menu.new(admin_role)
expect(menu.instance_of?(Menu))
end
end
</pre>
The third test checks that when the menu is created with items, these items are put into nodes and contained within the menu. In this case the children of root will contain a single item, the node with id 1, because this node has a nil parent. The other nodes all have parents.
<pre>
context "when menu has items" do
it "creates a new menu with items" do
menu = Menu.new
expect(menu.root.children.length).to eq(1)
end
end
</pre>
The final test checks a menu without any nodes. While this case is unlikely in actual use it is important it can be handled without throwing any errors. When a menu without any items is created, the root will never have anything added to its children array so this array will be nil.
<pre>
context "when menu has not items" do
it "creates a new menu without items" do
allow(MenuItem).to receive(:items_for_permissions).with(anything).and_return([])
menu = Menu.new
expect(menu.root.children).to be_nil
end
end
</pre>
This 4 tests alone provide nearly 85% coverage of menu.rb because of how much they rely on a variety of other methods within the class.

Many of the functions in menu return a menu node. The simplest, get_item, takes the node id and returns the node object. All following functions use this to test that the correct node is returned. However to prevent circular logic, the get_item test only checks the id of the returned node.

==Results==
The 29 tests provide 100% coverage of the lines in menu.rb. A video of all tests running can be seen [https://www.youtube.com/watch?v=yB_E5OORja0 here].
The main repository can be found [https://github.com/expertiza/expertiza here]
The forked git repository for this project can be found [https://github.com/BarrettJB/expertiza/ here]

==List of all tests==
Below is a list of the descriptions of all of the tests we wrote

CSC/ECE 517 Fall 2018/E1853 Write unit tests for menu.rb

2018-11-02T21:14:06Z

Bbryson:

This project wrote unit tests for the Menu.rb model in Expertiza.

==Project Introduction==
The menu model is used to create the top bar menu in expertiza. It does this by obtaining and organizing Menu_Items based on the current users Role. Before this project there were no unit tests for menu.rb. This project seeked to bring the unit test coverage above %90.

===Team===
Barrett Bryson (bbryson)

Komal Kangutkar (kmkangut)

===RSpec File===
The final result can be found at expertiza/spec/models/menu_spec.rb. This specific test can be run by calling in the expertiza directory:
<pre>
rspec -fd ./spec/models/menu_spec.rb
</pre>
The addition of the -fd argument will write out full descriptions of the tests and provide a easy look at the work we did.

==Design==
In total we wrote 29 tests that covered all of the functions in both menu and its internal node class. We created a 6 menu items for testing using the given factories as well as 1 role used to test the menu constructor. We stubbed menu item to always return an array of the 6 test items that we created. Other pieces of the code were stubbed because these pieces should be tested by menu item not menu. The double temp is used to only test the functionalities of menu.

Each method in menu.rb has at least two tests checking both a know success case and a edge case or potential failure. As an example, a detailed look at the functions to test menu#initialize is found below.

<pre>
context "when role is nil" do
it "creates a new menu" do
menu = Menu.new
expect(menu.instance_of?(Menu))
end
end
</pre>
This first test revealed an error in the existing menu.rb code in the line shown below. The second line shows the change that we made. This allowed the code to be more robust and prevent noMethodErrors from nilClass. Without this change a menu created with a nil role will throw an error causing the program to fail unnecessarily. This is important because the default value of role is nil and that should not fail.
<pre>
items = MenuItem.items_for_permissions(role.try(:cache)[:credentials].try(:permission_ids))
</pre>
<pre>
items = MenuItem.items_for_permissions(role.try(:cache).try(:[], :credentials).try(:permission_ids))
</pre>
The second test uses the main covers the main use case of menu. It will be supplied with a role and will assemble a menu. Only a single role is tested because further testing of roles and menus should instead be handled in integration tests.
<pre>
context "when a role is passed as an argument" do
it "creates a new menu" do
admin_role = build(:role_of_administrator, id: 3, name: "Administrator", description: '', parent_id: nil, default_page_id: nil)
menu = Menu.new(admin_role)
expect(menu.instance_of?(Menu))
end
end
</pre>
The third test checks that when the menu is created with items, these items are put into nodes and contained within the menu. In this case the children of root will contain a single item, the node with id 1, because this node has a nil parent. The other nodes all have parents.
<pre>
context "when menu has items" do
it "creates a new menu with items" do
menu = Menu.new
expect(menu.root.children.length).to eq(1)
end
end
</pre>
The final test checks a menu without any nodes. While this case is unlikely in actual use it is important it can be handled without throwing any errors. When a menu without any items is created, the root will never have anything added to its children array so this array will be nil.
<pre>
context "when menu has not items" do
it "creates a new menu without items" do
allow(MenuItem).to receive(:items_for_permissions).with(anything).and_return([])
menu = Menu.new
expect(menu.root.children).to be_nil
end
end
</pre>
This 4 tests alone provide nearly 85% coverage of menu.rb because of how much they rely on a variety of other methods within the class.

Many of the functions in menu return a menu node. The simplest, get_item, takes the node id and returns the node object. All following functions use this to test that the correct node is returned. However to prevent circular logic, the get_item test only checks the id of the returned node.

==Results==
The 29 tests provide 100% coverage of the lines in menu.rb. A video of all tests running can be seen [https://www.youtube.com/watch?v=yB_E5OORja0 here].

==List of all tests==
Below is a list of the descriptions of all of the tests we wrote

CSC/ECE 517 Fall 2018/E1853 Write unit tests for menu.rb

2018-11-02T21:01:53Z

Bbryson:

CSC/ECE 517 Fall 2018/E1853 Write unit tests for menu.rb

2018-11-02T20:56:52Z

Bbryson:

CSC/ECE 517 Fall 2018/E1853 Write unit tests for menu.rb

2018-11-02T20:55:31Z

Bbryson:

CSC/ECE 517 Fall 2018/E1853 Write unit tests for menu.rb

2018-11-02T20:53:07Z

Bbryson:

CSC/ECE 517 Fall 2018/E1853 Write unit tests for menu.rb

2018-11-02T20:46:12Z

Bbryson:

CSC/ECE 517 Fall 2018/E1853 Write unit tests for menu.rb

2018-11-02T20:31:58Z

Bbryson:

CSC/ECE 517 Fall 2018/E1853 Write unit tests for menu.rb

2018-10-31T19:23:04Z

Bbryson:

For reviewers:
To run all tests call "rspec -fd ./spec/models/menu.rb"

CSC/ECE 517 Fall 2018/E1853 Write unit tests for menu.rb

2018-10-31T19:13:44Z

Bbryson: Created page with "This is a test of the documentation for this project"

This is a test of the documentation for this project