Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2016 E1709 Visualizations for instructors

2016-12-02T23:30:12Z

Aagrawa6: /* Mockups */

== Introduction ==

Expertiza<ref>https://expertiza.ncsu.edu/</ref> is an open-source web application to create re-usable learning objects through peer-reviews to facilitate incremental learning. Students can submit learning objects such as articles, wiki pages, repository links and with the help of peer reviews, improve them. The project has been developed using the Ruby on Rails<ref>https://en.wikipedia.org/wiki/Ruby_on_Rails</ref> framework and is supported by the [http://www.nsf.gov National Science Foundation].

== Project Description ==

=== Purpose and Scope ===

Expertiza assignments are based on a peer review system where the instructor creates rubrics for an assignment through questionnaires which students use to review other students' submissions. The author of the submission is given an opportunity to provide feedback about these reviews. All questions in the questionnaire have an assigned grade which is based on a pre-defined grading scale. Instructors can see a report on the scores of a student given by reviewers, on the score of feedback given to the reviewers and many other reports. Based on these reports (which are all on separate pages), the instructors grade the student. These reports are, however, on separate pages and it is difficult for an instructor to navigate to many pages before grading the student. The first requirement is meant to solve this problem by merging the review scores with the author feedbacks on the same page.

Furthermore, there is no way for an instructor to evaluate the rubric he/she has posted on assignments. Students may consistently be getting negative reviews for a rubric which might not be totally relevant to the assignment thereby reducing their scores. A report of average class scores for each rubric in the questionnaires would help instructors refactor their rubric and understand where students generally perform well and where they struggle. This new report forms the second part of the requirement.

We are not modifying any of the existing functionalities of Expertiza. Our work would involve modifying the review report and creating a new report for average class scores.

=== Task Description ===

The project requires completion of the following tasks:

* Integrate review data with author feedback data to help instructors grade the reviewers.
* Create a new table for review and author feedback report.
* The new table should have the following information: reviewer name, the number of reviews he has done, length of reviews, review summary, whether there is a link or a file attached, Average author feedback rating per team, Author feedback summary and a field where an instructor can give his grades and write comments.
* Add interactive visualization to show the class performance of an assignment to an instructor.
* Create a new route/view/controller for class performance.
* Add a new link to point to the new controller created. This new link will be created per assignment.
* Create two new views, one for selecting rubric criteria and second to show the graph.
* Create graphs to show the class performance as per the rubric metrics selected dynamically.

== Project Design ==

=== Design Patterns ===

'''Iterator Pattern<ref>https://en.wikipedia.org/wiki/Iterator_pattern</ref>:'''
The iterator design pattern uses an iterator to traverse a container and access its elements. When we are implementing the response and author feedback report, we will be iterating through each reviewer to get the review performed by them and then each author based on the feedback given for each review. This iteration will occur with the data returned by the ResponseMap model for all of the review and feedback information. For the class performance report, we will be iterating through each questionnaire per assignment, and thereafter each question per questionnaire. The same iteration will also be required to get answers per question per reviewer.

'''MVC Pattern<ref>https://www.tutorialspoint.com/design_pattern/mvc_pattern.htm</ref>:'''
In the MVC design pattern a controller processes the request, interprets the data in model and then renders particular view.
For rendering response and author feedback report, we check the the data, in the form that was submitted from the UI, in the ResponseMappingController. Depending on the data, we process various models and then display a particular view.

=== Review and Author Feedback Report ===

==== Workflow ====
[[File:workflow1.png]]

==== Mockups ====
* When the author will select the review and author feedback, it will show him the screen shown below.

[[File:Mockup1.png]]

==== Implementation Thoughts ====

This report is an integration of two preexisting reports "Review"and "Author Feedback". Thus we will be reusing a lot of components with addition of few.

* A new option will be provided in the dropdown called as "Review and Author Feedback Report".
* On submitting this form, the user is redirected to action "response_report" in controller "ReviewMappingController".
* We will add new case for our requirement.
** We will require data from ReviewResponseMap, FeedbackResponseMap, AssignmentParticipant models.
** From ReviewResponseMap and AssignmentParticipant, for each reviewer we will get number of reviews completed, length of reviews, summary of reviews and whether reviewers had added a file or link for their review.
** From FeedbackResponseMap, we will get author feedback summary and the total score that author gave for the particular reviewer.
* All the above data will be rendered using a new partial "_response_and_feedback.html.erb" in "/app/views/review_mapping". This partial is called from "response_report.html.haml".
* In a similar tabular format for Review/ Author feedback report, we will show the data in a table.
*Hyperlinks will be provided where necessary, so instructor can view additional details. For e.g. to view review summary or author feedback summary.

==== Implementation ====

==== Pull Request and Demo ====

=== Class Performance Report ===

==== Workflow ====
[[File:workflow3.png]]

==== Mockups(Final Versions) ====
* The instructor can view the class performance on assignments by clicking on the graph icon on the assignments page as shown below.

[[File:Image11.png]]

* Once you click on the graph icon, it will take the instructor to the page shown below where the instructor can select various rubric questions used for evaluation of that assignment.

[[File:Image22.png]]

* Once you click on the graph icon, it will take the instructor to the page shown below where the instructor can see the performance of the class based on various selected rubric questions.

[[File:Image33.png]]

==== Implementation ====

In order to implement the above functionality for the class performance report, we have finally implemented the following:

* We added a new controller ''ClassPerformanceController''.
* We added the following two new views.
** A view to ''select_rubrics''. This view will allow instructors to select a number of rubrics to evaluate the class performance on.
** A view to ''show_class_performance''. This view will display the class performance using relevant graphs to represent the information clearly.
* Routes for each of the views created.

We need to provide a link to the instructor to see this view. As shown above, this will be a button in the assignment management page routed at ''tree_display/list'' which corresponds to the function ''list'' in the controller ''TreeDisplayController.rb''. The button we added here routes to the newly created ''select_rubrics'' view.

The ''select_rubrics'' view receives the following parameters.

<pre>
assignment_id
</pre>

The controller gets all the questionnaires related to that assignment from the ''AssignmentQuestionnaire'' model. It then gets a list of all the rubrics used in those questionnaires from the ''Questions'' model. These are displayed to the instructor. It then routes the instructor to the ''show_class_performance'' view upon selection of rubrics. It will pass the following parameters to the ''show_class_performance'' view.

<pre>
assignment_id
Array[question_id]
</pre>

The controller will take the list of questions for the assignment and find all the answers of those questions. It will then calculate the average score per question for the entire class from those answers and pass this to the view. The ''show_class_performance'' view will use the [https://github.com/topfunky/gruff Gruff API] in order to provide an aesthetically appealing visualization of the data.

==== Pull Request and Demo ====

The demo for the class performance report can be seen here: https://youtu.be/_fp4YYCgY2w
The pull request is here: https://github.com/expertiza/expertiza/pull/861

== Use Cases ==

* '''View Review and Author Feedback Report as Instructor''': As an instructor, he can see the different metrics of reviews and average feedback rating received per student done for an assignment or a project.
* '''View Class Performance as Instructor''': As an instructor, he can select 5 rubric metrics used per assignment. The instructor is able to see the graph to check the class performance based upon the metrics selected.
* '''RSpec''': RSpec is a behavior design development framework which is used for testing the functionality of the system.
* ''' Capybara''': We will be using capybara for automation of the manual test cases written in RSpec.

== Test Plan ==

*'''For use case 1''', test if the instructor can see the text metrics of reviews and author feedbacks received for an assignment or a project per student.
*'''For use case 2''', test if the instructor can any number of rubric metrics used for an assignment. Also, test if the instructor can view the class performance from a graph using the metrics selected by the instructor.

== Requirements ==

While software and hardware requirements are the same as current Expertiza system, we will require following addition tools:

* '''Tools:''' Gruff API in addition to the current Expertiza system.

== References ==
<references/>

CSC/ECE 517 Fall 2016 E1709 Visualizations for instructors

2016-12-02T23:29:15Z

Aagrawa6: /* Implementation Thoughts */

== Introduction ==

Expertiza<ref>https://expertiza.ncsu.edu/</ref> is an open-source web application to create re-usable learning objects through peer-reviews to facilitate incremental learning. Students can submit learning objects such as articles, wiki pages, repository links and with the help of peer reviews, improve them. The project has been developed using the Ruby on Rails<ref>https://en.wikipedia.org/wiki/Ruby_on_Rails</ref> framework and is supported by the [http://www.nsf.gov National Science Foundation].

== Project Description ==

=== Purpose and Scope ===

Expertiza assignments are based on a peer review system where the instructor creates rubrics for an assignment through questionnaires which students use to review other students' submissions. The author of the submission is given an opportunity to provide feedback about these reviews. All questions in the questionnaire have an assigned grade which is based on a pre-defined grading scale. Instructors can see a report on the scores of a student given by reviewers, on the score of feedback given to the reviewers and many other reports. Based on these reports (which are all on separate pages), the instructors grade the student. These reports are, however, on separate pages and it is difficult for an instructor to navigate to many pages before grading the student. The first requirement is meant to solve this problem by merging the review scores with the author feedbacks on the same page.

Furthermore, there is no way for an instructor to evaluate the rubric he/she has posted on assignments. Students may consistently be getting negative reviews for a rubric which might not be totally relevant to the assignment thereby reducing their scores. A report of average class scores for each rubric in the questionnaires would help instructors refactor their rubric and understand where students generally perform well and where they struggle. This new report forms the second part of the requirement.

We are not modifying any of the existing functionalities of Expertiza. Our work would involve modifying the review report and creating a new report for average class scores.

=== Task Description ===

The project requires completion of the following tasks:

* Integrate review data with author feedback data to help instructors grade the reviewers.
* Create a new table for review and author feedback report.
* The new table should have the following information: reviewer name, the number of reviews he has done, length of reviews, review summary, whether there is a link or a file attached, Average author feedback rating per team, Author feedback summary and a field where an instructor can give his grades and write comments.
* Add interactive visualization to show the class performance of an assignment to an instructor.
* Create a new route/view/controller for class performance.
* Add a new link to point to the new controller created. This new link will be created per assignment.
* Create two new views, one for selecting rubric criteria and second to show the graph.
* Create graphs to show the class performance as per the rubric metrics selected dynamically.

== Project Design ==

=== Design Patterns ===

'''Iterator Pattern<ref>https://en.wikipedia.org/wiki/Iterator_pattern</ref>:'''
The iterator design pattern uses an iterator to traverse a container and access its elements. When we are implementing the response and author feedback report, we will be iterating through each reviewer to get the review performed by them and then each author based on the feedback given for each review. This iteration will occur with the data returned by the ResponseMap model for all of the review and feedback information. For the class performance report, we will be iterating through each questionnaire per assignment, and thereafter each question per questionnaire. The same iteration will also be required to get answers per question per reviewer.

'''MVC Pattern<ref>https://www.tutorialspoint.com/design_pattern/mvc_pattern.htm</ref>:'''
In the MVC design pattern a controller processes the request, interprets the data in model and then renders particular view.
For rendering response and author feedback report, we check the the data, in the form that was submitted from the UI, in the ResponseMappingController. Depending on the data, we process various models and then display a particular view.

=== Review and Author Feedback Report ===

==== Workflow ====
[[File:workflow1.png]]

==== Mockups ====
* When the author will select the review and author feedback, it will show him the screen shown below.

[[File:Mockup1.png]]

==== Implementation Thoughts ====

This report is an integration of two preexisting reports "Review"and "Author Feedback". Thus we will be reusing a lot of components with addition of few.

* A new option will be provided in the dropdown called as "Review and Author Feedback Report".
* On submitting this form, the user is redirected to action "response_report" in controller "ReviewMappingController".
* We will add new case for our requirement.
** We will require data from ReviewResponseMap, FeedbackResponseMap, AssignmentParticipant models.
** From ReviewResponseMap and AssignmentParticipant, for each reviewer we will get number of reviews completed, length of reviews, summary of reviews and whether reviewers had added a file or link for their review.
** From FeedbackResponseMap, we will get author feedback summary and the total score that author gave for the particular reviewer.
* All the above data will be rendered using a new partial "_response_and_feedback.html.erb" in "/app/views/review_mapping". This partial is called from "response_report.html.haml".
* In a similar tabular format for Review/ Author feedback report, we will show the data in a table.
*Hyperlinks will be provided where necessary, so instructor can view additional details. For e.g. to view review summary or author feedback summary.

==== Implementation ====

==== Pull Request and Demo ====

=== Class Performance Report ===

==== Workflow ====
[[File:workflow3.png]]

==== Mockups ====
* The instructor can view the class performance on assignments by clicking on the graph icon on the assignments page as shown below.

[[File:Image11.png]]

* Once you click on the graph icon, it will take the instructor to the page shown below where the instructor can select various rubric questions used for evaluation of that assignment.

[[File:Image22.png]]

* Once you click on the graph icon, it will take the instructor to the page shown below where the instructor can see the performance of the class based on various selected rubric questions.

[[File:Image33.png]]

==== Implementation ====

In order to implement the above functionality for the class performance report, we have finally implemented the following:

* We added a new controller ''ClassPerformanceController''.
* We added the following two new views.
** A view to ''select_rubrics''. This view will allow instructors to select a number of rubrics to evaluate the class performance on.
** A view to ''show_class_performance''. This view will display the class performance using relevant graphs to represent the information clearly.
* Routes for each of the views created.

We need to provide a link to the instructor to see this view. As shown above, this will be a button in the assignment management page routed at ''tree_display/list'' which corresponds to the function ''list'' in the controller ''TreeDisplayController.rb''. The button we added here routes to the newly created ''select_rubrics'' view.

The ''select_rubrics'' view receives the following parameters.

<pre>
assignment_id
</pre>

The controller gets all the questionnaires related to that assignment from the ''AssignmentQuestionnaire'' model. It then gets a list of all the rubrics used in those questionnaires from the ''Questions'' model. These are displayed to the instructor. It then routes the instructor to the ''show_class_performance'' view upon selection of rubrics. It will pass the following parameters to the ''show_class_performance'' view.

<pre>
assignment_id
Array[question_id]
</pre>

The controller will take the list of questions for the assignment and find all the answers of those questions. It will then calculate the average score per question for the entire class from those answers and pass this to the view. The ''show_class_performance'' view will use the [https://github.com/topfunky/gruff Gruff API] in order to provide an aesthetically appealing visualization of the data.

==== Pull Request and Demo ====

The demo for the class performance report can be seen here: https://youtu.be/_fp4YYCgY2w
The pull request is here: https://github.com/expertiza/expertiza/pull/861

== Use Cases ==

* '''View Review and Author Feedback Report as Instructor''': As an instructor, he can see the different metrics of reviews and average feedback rating received per student done for an assignment or a project.
* '''View Class Performance as Instructor''': As an instructor, he can select 5 rubric metrics used per assignment. The instructor is able to see the graph to check the class performance based upon the metrics selected.
* '''RSpec''': RSpec is a behavior design development framework which is used for testing the functionality of the system.
* ''' Capybara''': We will be using capybara for automation of the manual test cases written in RSpec.

== Test Plan ==

*'''For use case 1''', test if the instructor can see the text metrics of reviews and author feedbacks received for an assignment or a project per student.
*'''For use case 2''', test if the instructor can any number of rubric metrics used for an assignment. Also, test if the instructor can view the class performance from a graph using the metrics selected by the instructor.

== Requirements ==

While software and hardware requirements are the same as current Expertiza system, we will require following addition tools:

* '''Tools:''' Gruff API in addition to the current Expertiza system.

== References ==
<references/>

CSC/ECE 517 Fall 2016 E1709 Visualizations for instructors

2016-12-02T23:29:02Z

Aagrawa6: /* Implementation */

== Introduction ==

Expertiza<ref>https://expertiza.ncsu.edu/</ref> is an open-source web application to create re-usable learning objects through peer-reviews to facilitate incremental learning. Students can submit learning objects such as articles, wiki pages, repository links and with the help of peer reviews, improve them. The project has been developed using the Ruby on Rails<ref>https://en.wikipedia.org/wiki/Ruby_on_Rails</ref> framework and is supported by the [http://www.nsf.gov National Science Foundation].

== Project Description ==

=== Purpose and Scope ===

Expertiza assignments are based on a peer review system where the instructor creates rubrics for an assignment through questionnaires which students use to review other students' submissions. The author of the submission is given an opportunity to provide feedback about these reviews. All questions in the questionnaire have an assigned grade which is based on a pre-defined grading scale. Instructors can see a report on the scores of a student given by reviewers, on the score of feedback given to the reviewers and many other reports. Based on these reports (which are all on separate pages), the instructors grade the student. These reports are, however, on separate pages and it is difficult for an instructor to navigate to many pages before grading the student. The first requirement is meant to solve this problem by merging the review scores with the author feedbacks on the same page.

Furthermore, there is no way for an instructor to evaluate the rubric he/she has posted on assignments. Students may consistently be getting negative reviews for a rubric which might not be totally relevant to the assignment thereby reducing their scores. A report of average class scores for each rubric in the questionnaires would help instructors refactor their rubric and understand where students generally perform well and where they struggle. This new report forms the second part of the requirement.

We are not modifying any of the existing functionalities of Expertiza. Our work would involve modifying the review report and creating a new report for average class scores.

=== Task Description ===

The project requires completion of the following tasks:

* Integrate review data with author feedback data to help instructors grade the reviewers.
* Create a new table for review and author feedback report.
* The new table should have the following information: reviewer name, the number of reviews he has done, length of reviews, review summary, whether there is a link or a file attached, Average author feedback rating per team, Author feedback summary and a field where an instructor can give his grades and write comments.
* Add interactive visualization to show the class performance of an assignment to an instructor.
* Create a new route/view/controller for class performance.
* Add a new link to point to the new controller created. This new link will be created per assignment.
* Create two new views, one for selecting rubric criteria and second to show the graph.
* Create graphs to show the class performance as per the rubric metrics selected dynamically.

== Project Design ==

=== Design Patterns ===

'''Iterator Pattern<ref>https://en.wikipedia.org/wiki/Iterator_pattern</ref>:'''
The iterator design pattern uses an iterator to traverse a container and access its elements. When we are implementing the response and author feedback report, we will be iterating through each reviewer to get the review performed by them and then each author based on the feedback given for each review. This iteration will occur with the data returned by the ResponseMap model for all of the review and feedback information. For the class performance report, we will be iterating through each questionnaire per assignment, and thereafter each question per questionnaire. The same iteration will also be required to get answers per question per reviewer.

'''MVC Pattern<ref>https://www.tutorialspoint.com/design_pattern/mvc_pattern.htm</ref>:'''
In the MVC design pattern a controller processes the request, interprets the data in model and then renders particular view.
For rendering response and author feedback report, we check the the data, in the form that was submitted from the UI, in the ResponseMappingController. Depending on the data, we process various models and then display a particular view.

=== Review and Author Feedback Report ===

==== Workflow ====
[[File:workflow1.png]]

==== Mockups ====
* When the author will select the review and author feedback, it will show him the screen shown below.

[[File:Mockup1.png]]

==== Implementation Thoughts ====

This report is an integration of two preexisting reports "Review"and "Author Feedback". Thus we will be reusing a lot of components with addition of few.

* A new option will be provided in the dropdown called as "Review and Author Feedback Report".
* On submitting this form, the user is redirected to action "response_report" in controller "ReviewMappingController".
* We will add new case for our requirement.
** We will require data from ReviewResponseMap, FeedbackResponseMap, AssignmentParticipant models.
** From ReviewResponseMap and AssignmentParticipant, for each reviewer we will get number of reviews completed, length of reviews, summary of reviews and whether reviewers had added a file or link for their review.
** From FeedbackResponseMap, we will get author feedback summary and the total score that author gave for the particular reviewer.
* All the above data will be rendered using a new partial "_response_and_feedback.html.erb" in "/app/views/review_mapping". This partial is called from "response_report.html.haml".
* In a similar tabular format for Review/ Author feedback report, we will show the data in a table.
*Hyperlinks will be provided where necessary, so instructor can view additional details. For e.g. to view review summary or author feedback summary.

==== Implementation ====

==== Pull Request and Demo ====

=== Class Performance Report ===

==== Workflow ====
[[File:workflow3.png]]

==== Mockups ====
* The instructor can view the class performance on assignments by clicking on the graph icon on the assignments page as shown below.

[[File:Image11.png]]

* Once you click on the graph icon, it will take the instructor to the page shown below where the instructor can select various rubric questions used for evaluation of that assignment.

[[File:Image22.png]]

* Once you click on the graph icon, it will take the instructor to the page shown below where the instructor can see the performance of the class based on various selected rubric questions.

[[File:Image33.png]]

==== Implementation Thoughts ====

In order to implement the above functionality for the class performance report, our initial observation resulted in the following path for implementation.

* We will need a new controller ''ClassPerformanceController''.
* We will need the following two new views.
** A view to ''select_rubrics''. This view will allow instructors to select a couple of rubrics to evaluate the class performance on.
** A view to ''show_class_performance''. This view will display the class performance using relevant graphs to represent the information clearly.
* Routes for each of the views created.
* Model methods to facilitate getting the required information and calculations.

We need to provide a link to the instructor to see this view. As shown above, this will be a button in the assignment management page routed at ''tree_display/list'' which corresponds to the function ''list'' in the controller ''TreeDisplayController.rb''. The button we are adding here to route to the newly created ''select_rubrics'' view.

The ''select_rubrics'' view will receive the following parameters.

<pre>
assignment_id
</pre>

The controller will get all the questionnaires related to that assignment from the ''AssignmentQuestionnaire'' model. It will then get a list of all the rubrics used in those questionnaires from the ''Questions'' model. These will be displayed to the instructor. It will then route the instructor to the ''show_class_performance'' view upon selection of rubrics. It will pass the following parameters to the ''show_class_performance'' view.

<pre>
assignment_id
Array[question_id]
</pre>

The controller will take the list of questions for the assignment and find all the answers for those questions. It will then calculate the average score per question for the entire class from those answers and pass this to the view. The ''show_class_performance'' view will use the [https://github.com/topfunky/gruff Gruff API] in order to provide an aesthetically appealing visualization of the data.

==== Implementation ====

In order to implement the above functionality for the class performance report, we have finally implemented the following:

* We added a new controller ''ClassPerformanceController''.
* We added the following two new views.
** A view to ''select_rubrics''. This view will allow instructors to select a number of rubrics to evaluate the class performance on.
** A view to ''show_class_performance''. This view will display the class performance using relevant graphs to represent the information clearly.
* Routes for each of the views created.

We need to provide a link to the instructor to see this view. As shown above, this will be a button in the assignment management page routed at ''tree_display/list'' which corresponds to the function ''list'' in the controller ''TreeDisplayController.rb''. The button we added here routes to the newly created ''select_rubrics'' view.

The ''select_rubrics'' view receives the following parameters.

<pre>
assignment_id
</pre>

The controller gets all the questionnaires related to that assignment from the ''AssignmentQuestionnaire'' model. It then gets a list of all the rubrics used in those questionnaires from the ''Questions'' model. These are displayed to the instructor. It then routes the instructor to the ''show_class_performance'' view upon selection of rubrics. It will pass the following parameters to the ''show_class_performance'' view.

<pre>
assignment_id
Array[question_id]
</pre>

The controller will take the list of questions for the assignment and find all the answers of those questions. It will then calculate the average score per question for the entire class from those answers and pass this to the view. The ''show_class_performance'' view will use the [https://github.com/topfunky/gruff Gruff API] in order to provide an aesthetically appealing visualization of the data.

==== Pull Request and Demo ====

The demo for the class performance report can be seen here: https://youtu.be/_fp4YYCgY2w
The pull request is here: https://github.com/expertiza/expertiza/pull/861

== Use Cases ==

* '''View Review and Author Feedback Report as Instructor''': As an instructor, he can see the different metrics of reviews and average feedback rating received per student done for an assignment or a project.
* '''View Class Performance as Instructor''': As an instructor, he can select 5 rubric metrics used per assignment. The instructor is able to see the graph to check the class performance based upon the metrics selected.
* '''RSpec''': RSpec is a behavior design development framework which is used for testing the functionality of the system.
* ''' Capybara''': We will be using capybara for automation of the manual test cases written in RSpec.

== Test Plan ==

*'''For use case 1''', test if the instructor can see the text metrics of reviews and author feedbacks received for an assignment or a project per student.
*'''For use case 2''', test if the instructor can any number of rubric metrics used for an assignment. Also, test if the instructor can view the class performance from a graph using the metrics selected by the instructor.

== Requirements ==

While software and hardware requirements are the same as current Expertiza system, we will require following addition tools:

* '''Tools:''' Gruff API in addition to the current Expertiza system.

== References ==
<references/>

CSC/ECE 517 Fall 2016 E1709 Visualizations for instructors

2016-12-02T23:16:47Z

Aagrawa6: /* Pull Request and Demo */

== Introduction ==

Expertiza<ref>https://expertiza.ncsu.edu/</ref> is an open-source web application to create re-usable learning objects through peer-reviews to facilitate incremental learning. Students can submit learning objects such as articles, wiki pages, repository links and with the help of peer reviews, improve them. The project has been developed using the Ruby on Rails<ref>https://en.wikipedia.org/wiki/Ruby_on_Rails</ref> framework and is supported by the [http://www.nsf.gov National Science Foundation].

== Project Description ==

=== Purpose and Scope ===

Expertiza assignments are based on a peer review system where the instructor creates rubrics for an assignment through questionnaires which students use to review other students' submissions. The author of the submission is given an opportunity to provide feedback about these reviews. All questions in the questionnaire have an assigned grade which is based on a pre-defined grading scale. Instructors can see a report on the scores of a student given by reviewers, on the score of feedback given to the reviewers and many other reports. Based on these reports (which are all on separate pages), the instructors grade the student. These reports are, however, on separate pages and it is difficult for an instructor to navigate to many pages before grading the student. The first requirement is meant to solve this problem by merging the review scores with the author feedbacks on the same page.

Furthermore, there is no way for an instructor to evaluate the rubric he/she has posted on assignments. Students may consistently be getting negative reviews for a rubric which might not be totally relevant to the assignment thereby reducing their scores. A report of average class scores for each rubric in the questionnaires would help instructors refactor their rubric and understand where students generally perform well and where they struggle. This new report forms the second part of the requirement.

We are not modifying any of the existing functionalities of Expertiza. Our work would involve modifying the review report and creating a new report for average class scores.

=== Task Description ===

The project requires completion of the following tasks:

* Integrate review data with author feedback data to help instructors grade the reviewers.
* Create a new table for review and author feedback report.
* The new table should have the following information: reviewer name, the number of reviews he has done, length of reviews, review summary, whether there is a link or a file attached, Average author feedback rating per team, Author feedback summary and a field where an instructor can give his grades and write comments.
* Add interactive visualization to show the class performance of an assignment to an instructor.
* Create a new route/view/controller for class performance.
* Add a new link to point to the new controller created. This new link will be created per assignment.
* Create two new views, one for selecting rubric criteria and second to show the graph.
* Create graphs to show the class performance as per the rubric metrics selected dynamically.

== Project Design ==

=== Design Patterns ===

'''Iterator Pattern<ref>https://en.wikipedia.org/wiki/Iterator_pattern</ref>:'''
The iterator design pattern uses an iterator to traverse a container and access its elements. When we are implementing the response and author feedback report, we will be iterating through each reviewer to get the review performed by them and then each author based on the feedback given for each review. This iteration will occur with the data returned by the ResponseMap model for all of the review and feedback information. For the class performance report, we will be iterating through each questionnaire per assignment, and thereafter each question per questionnaire. The same iteration will also be required to get answers per question per reviewer.

'''MVC Pattern<ref>https://www.tutorialspoint.com/design_pattern/mvc_pattern.htm</ref>:'''
In the MVC design pattern a controller processes the request, interprets the data in model and then renders particular view.
For rendering response and author feedback report, we check the the data, in the form that was submitted from the UI, in the ResponseMappingController. Depending on the data, we process various models and then display a particular view.

=== Review and Author Feedback Report ===

==== Workflow ====
[[File:workflow1.png]]

==== Mockups ====
* When the author will select the review and author feedback, it will show him the screen shown below.

[[File:Mockup1.png]]

==== Implementation Thoughts ====

This report is an integration of two preexisting reports "Review"and "Author Feedback". Thus we will be reusing a lot of components with addition of few.

* A new option will be provided in the dropdown called as "Review and Author Feedback Report".
* On submitting this form, the user is redirected to action "response_report" in controller "ReviewMappingController".
* We will add new case for our requirement.
** We will require data from ReviewResponseMap, FeedbackResponseMap, AssignmentParticipant models.
** From ReviewResponseMap and AssignmentParticipant, for each reviewer we will get number of reviews completed, length of reviews, summary of reviews and whether reviewers had added a file or link for their review.
** From FeedbackResponseMap, we will get author feedback summary and the total score that author gave for the particular reviewer.
* All the above data will be rendered using a new partial "_response_and_feedback.html.erb" in "/app/views/review_mapping". This partial is called from "response_report.html.haml".
* In a similar tabular format for Review/ Author feedback report, we will show the data in a table.
*Hyperlinks will be provided where necessary, so instructor can view additional details. For e.g. to view review summary or author feedback summary.

==== Implementation ====

==== Pull Request and Demo ====

=== Class Performance Report ===

==== Workflow ====
[[File:workflow3.png]]

==== Mockups ====
* The instructor can view the class performance on assignments by clicking on the graph icon on the assignments page as shown below.

[[File:Image11.png]]

* Once you click on the graph icon, it will take the instructor to the page shown below where the instructor can select various rubric questions used for evaluation of that assignment.

[[File:Image22.png]]

* Once you click on the graph icon, it will take the instructor to the page shown below where the instructor can see the performance of the class based on various selected rubric questions.

[[File:Image33.png]]

==== Implementation Thoughts ====

In order to implement the above functionality for the class performance report, our initial observation resulted in the following path for implementation.

* We will need a new controller ''ClassPerformanceController''.
* We will need the following two new views.
** A view to ''select_rubrics''. This view will allow instructors to select a couple of rubrics to evaluate the class performance on.
** A view to ''show_class_performance''. This view will display the class performance using relevant graphs to represent the information clearly.
* Routes for each of the views created.
* Model methods to facilitate getting the required information and calculations.

We need to provide a link to the instructor to see this view. As shown above, this will be a button in the assignment management page routed at ''tree_display/list'' which corresponds to the function ''list'' in the controller ''TreeDisplayController.rb''. The button we are adding here to route to the newly created ''select_rubrics'' view.

The ''select_rubrics'' view will receive the following parameters.

<pre>
assignment_id
</pre>

The controller will get all the questionnaires related to that assignment from the ''AssignmentQuestionnaire'' model. It will then get a list of all the rubrics used in those questionnaires from the ''Questions'' model. These will be displayed to the instructor. It will then route the instructor to the ''show_class_performance'' view upon selection of rubrics. It will pass the following parameters to the ''show_class_performance'' view.

<pre>
assignment_id
Array[question_id]
</pre>

The controller will take the list of questions for the assignment and find all the answers for those questions. It will then calculate the average score per question for the entire class from those answers and pass this to the view. The ''show_class_performance'' view will use the [https://github.com/topfunky/gruff Gruff API] in order to provide an aesthetically appealing visualization of the data.

==== Implementation ====

==== Pull Request and Demo ====

The demo for the class performance report can be seen here: https://youtu.be/_fp4YYCgY2w
The pull request is here: https://github.com/expertiza/expertiza/pull/861

== Use Cases ==

* '''View Review and Author Feedback Report as Instructor''': As an instructor, he can see the different metrics of reviews and average feedback rating received per student done for an assignment or a project.
* '''View Class Performance as Instructor''': As an instructor, he can select 5 rubric metrics used per assignment. The instructor is able to see the graph to check the class performance based upon the metrics selected.
* '''RSpec''': RSpec is a behavior design development framework which is used for testing the functionality of the system.
* ''' Capybara''': We will be using capybara for automation of the manual test cases written in RSpec.

== Test Plan ==

*'''For use case 1''', test if the instructor can see the text metrics of reviews and author feedbacks received for an assignment or a project per student.
*'''For use case 2''', test if the instructor can any number of rubric metrics used for an assignment. Also, test if the instructor can view the class performance from a graph using the metrics selected by the instructor.

== Requirements ==

While software and hardware requirements are the same as current Expertiza system, we will require following addition tools:

* '''Tools:''' Gruff API in addition to the current Expertiza system.

== References ==
<references/>

CSC/ECE 517 Fall 2016 E1709 Visualizations for instructors

2016-12-02T23:08:53Z

Aagrawa6: /* Test Plan */

== Introduction ==

Expertiza<ref>https://expertiza.ncsu.edu/</ref> is an open-source web application to create re-usable learning objects through peer-reviews to facilitate incremental learning. Students can submit learning objects such as articles, wiki pages, repository links and with the help of peer reviews, improve them. The project has been developed using the Ruby on Rails<ref>https://en.wikipedia.org/wiki/Ruby_on_Rails</ref> framework and is supported by the [http://www.nsf.gov National Science Foundation].

== Project Description ==

=== Purpose and Scope ===

Expertiza assignments are based on a peer review system where the instructor creates rubrics for an assignment through questionnaires which students use to review other students' submissions. The author of the submission is given an opportunity to provide feedback about these reviews. All questions in the questionnaire have an assigned grade which is based on a pre-defined grading scale. Instructors can see a report on the scores of a student given by reviewers, on the score of feedback given to the reviewers and many other reports. Based on these reports (which are all on separate pages), the instructors grade the student. These reports are, however, on separate pages and it is difficult for an instructor to navigate to many pages before grading the student. The first requirement is meant to solve this problem by merging the review scores with the author feedbacks on the same page.

Furthermore, there is no way for an instructor to evaluate the rubric he/she has posted on assignments. Students may consistently be getting negative reviews for a rubric which might not be totally relevant to the assignment thereby reducing their scores. A report of average class scores for each rubric in the questionnaires would help instructors refactor their rubric and understand where students generally perform well and where they struggle. This new report forms the second part of the requirement.

We are not modifying any of the existing functionalities of Expertiza. Our work would involve modifying the review report and creating a new report for average class scores.

=== Task Description ===

The project requires completion of the following tasks:

* Integrate review data with author feedback data to help instructors grade the reviewers.
* Create a new table for review and author feedback report.
* The new table should have the following information: reviewer name, the number of reviews he has done, length of reviews, review summary, whether there is a link or a file attached, Average author feedback rating per team, Author feedback summary and a field where an instructor can give his grades and write comments.
* Add interactive visualization to show the class performance of an assignment to an instructor.
* Create a new route/view/controller for class performance.
* Add a new link to point to the new controller created. This new link will be created per assignment.
* Create two new views, one for selecting rubric criteria and second to show the graph.
* Create graphs to show the class performance as per the rubric metrics selected dynamically.

== Project Design ==

=== Design Patterns ===

'''Iterator Pattern<ref>https://en.wikipedia.org/wiki/Iterator_pattern</ref>:'''
The iterator design pattern uses an iterator to traverse a container and access its elements. When we are implementing the response and author feedback report, we will be iterating through each reviewer to get the review performed by them and then each author based on the feedback given for each review. This iteration will occur with the data returned by the ResponseMap model for all of the review and feedback information. For the class performance report, we will be iterating through each questionnaire per assignment, and thereafter each question per questionnaire. The same iteration will also be required to get answers per question per reviewer.

'''MVC Pattern<ref>https://www.tutorialspoint.com/design_pattern/mvc_pattern.htm</ref>:'''
In the MVC design pattern a controller processes the request, interprets the data in model and then renders particular view.
For rendering response and author feedback report, we check the the data, in the form that was submitted from the UI, in the ResponseMappingController. Depending on the data, we process various models and then display a particular view.

=== Review and Author Feedback Report ===

==== Workflow ====
[[File:workflow1.png]]

==== Mockups ====
* When the author will select the review and author feedback, it will show him the screen shown below.

[[File:Mockup1.png]]

==== Implementation Thoughts ====

This report is an integration of two preexisting reports "Review"and "Author Feedback". Thus we will be reusing a lot of components with addition of few.

* A new option will be provided in the dropdown called as "Review and Author Feedback Report".
* On submitting this form, the user is redirected to action "response_report" in controller "ReviewMappingController".
* We will add new case for our requirement.
** We will require data from ReviewResponseMap, FeedbackResponseMap, AssignmentParticipant models.
** From ReviewResponseMap and AssignmentParticipant, for each reviewer we will get number of reviews completed, length of reviews, summary of reviews and whether reviewers had added a file or link for their review.
** From FeedbackResponseMap, we will get author feedback summary and the total score that author gave for the particular reviewer.
* All the above data will be rendered using a new partial "_response_and_feedback.html.erb" in "/app/views/review_mapping". This partial is called from "response_report.html.haml".
* In a similar tabular format for Review/ Author feedback report, we will show the data in a table.
*Hyperlinks will be provided where necessary, so instructor can view additional details. For e.g. to view review summary or author feedback summary.

==== Implementation ====

==== Pull Request and Demo ====

=== Class Performance Report ===

==== Workflow ====
[[File:workflow3.png]]

==== Mockups ====
* The instructor can view the class performance on assignments by clicking on the graph icon on the assignments page as shown below.

[[File:Image11.png]]

* Once you click on the graph icon, it will take the instructor to the page shown below where the instructor can select various rubric questions used for evaluation of that assignment.

[[File:Image22.png]]

* Once you click on the graph icon, it will take the instructor to the page shown below where the instructor can see the performance of the class based on various selected rubric questions.

[[File:Image33.png]]

==== Implementation Thoughts ====

In order to implement the above functionality for the class performance report, our initial observation resulted in the following path for implementation.

* We will need a new controller ''ClassPerformanceController''.
* We will need the following two new views.
** A view to ''select_rubrics''. This view will allow instructors to select a couple of rubrics to evaluate the class performance on.
** A view to ''show_class_performance''. This view will display the class performance using relevant graphs to represent the information clearly.
* Routes for each of the views created.
* Model methods to facilitate getting the required information and calculations.

We need to provide a link to the instructor to see this view. As shown above, this will be a button in the assignment management page routed at ''tree_display/list'' which corresponds to the function ''list'' in the controller ''TreeDisplayController.rb''. The button we are adding here to route to the newly created ''select_rubrics'' view.

The ''select_rubrics'' view will receive the following parameters.

<pre>
assignment_id
</pre>

The controller will get all the questionnaires related to that assignment from the ''AssignmentQuestionnaire'' model. It will then get a list of all the rubrics used in those questionnaires from the ''Questions'' model. These will be displayed to the instructor. It will then route the instructor to the ''show_class_performance'' view upon selection of rubrics. It will pass the following parameters to the ''show_class_performance'' view.

<pre>
assignment_id
Array[question_id]
</pre>

The controller will take the list of questions for the assignment and find all the answers for those questions. It will then calculate the average score per question for the entire class from those answers and pass this to the view. The ''show_class_performance'' view will use the [https://github.com/topfunky/gruff Gruff API] in order to provide an aesthetically appealing visualization of the data.

==== Implementation ====

==== Pull Request and Demo ====

The demo for the class performance report can be seen here: https://youtu.be/_fp4YYCgY2w
The pull request is here:

== Use Cases ==

* '''View Review and Author Feedback Report as Instructor''': As an instructor, he can see the different metrics of reviews and average feedback rating received per student done for an assignment or a project.
* '''View Class Performance as Instructor''': As an instructor, he can select 5 rubric metrics used per assignment. The instructor is able to see the graph to check the class performance based upon the metrics selected.
* '''RSpec''': RSpec is a behavior design development framework which is used for testing the functionality of the system.
* ''' Capybara''': We will be using capybara for automation of the manual test cases written in RSpec.

== Test Plan ==

*'''For use case 1''', test if the instructor can see the text metrics of reviews and author feedbacks received for an assignment or a project per student.
*'''For use case 2''', test if the instructor can any number of rubric metrics used for an assignment. Also, test if the instructor can view the class performance from a graph using the metrics selected by the instructor.

== Requirements ==

While software and hardware requirements are the same as current Expertiza system, we will require following addition tools:

* '''Tools:''' Gruff API in addition to the current Expertiza system.

== References ==
<references/>

CSC/ECE 517 Fall 2016 E1709 Visualizations for instructors

2016-12-02T23:05:48Z

Aagrawa6:

== Introduction ==

Expertiza<ref>https://expertiza.ncsu.edu/</ref> is an open-source web application to create re-usable learning objects through peer-reviews to facilitate incremental learning. Students can submit learning objects such as articles, wiki pages, repository links and with the help of peer reviews, improve them. The project has been developed using the Ruby on Rails<ref>https://en.wikipedia.org/wiki/Ruby_on_Rails</ref> framework and is supported by the [http://www.nsf.gov National Science Foundation].

== Project Description ==

=== Purpose and Scope ===

Expertiza assignments are based on a peer review system where the instructor creates rubrics for an assignment through questionnaires which students use to review other students' submissions. The author of the submission is given an opportunity to provide feedback about these reviews. All questions in the questionnaire have an assigned grade which is based on a pre-defined grading scale. Instructors can see a report on the scores of a student given by reviewers, on the score of feedback given to the reviewers and many other reports. Based on these reports (which are all on separate pages), the instructors grade the student. These reports are, however, on separate pages and it is difficult for an instructor to navigate to many pages before grading the student. The first requirement is meant to solve this problem by merging the review scores with the author feedbacks on the same page.

Furthermore, there is no way for an instructor to evaluate the rubric he/she has posted on assignments. Students may consistently be getting negative reviews for a rubric which might not be totally relevant to the assignment thereby reducing their scores. A report of average class scores for each rubric in the questionnaires would help instructors refactor their rubric and understand where students generally perform well and where they struggle. This new report forms the second part of the requirement.

We are not modifying any of the existing functionalities of Expertiza. Our work would involve modifying the review report and creating a new report for average class scores.

=== Task Description ===

The project requires completion of the following tasks:

* Integrate review data with author feedback data to help instructors grade the reviewers.
* Create a new table for review and author feedback report.
* The new table should have the following information: reviewer name, the number of reviews he has done, length of reviews, review summary, whether there is a link or a file attached, Average author feedback rating per team, Author feedback summary and a field where an instructor can give his grades and write comments.
* Add interactive visualization to show the class performance of an assignment to an instructor.
* Create a new route/view/controller for class performance.
* Add a new link to point to the new controller created. This new link will be created per assignment.
* Create two new views, one for selecting rubric criteria and second to show the graph.
* Create graphs to show the class performance as per the rubric metrics selected dynamically.

== Project Design ==

=== Design Patterns ===

'''Iterator Pattern<ref>https://en.wikipedia.org/wiki/Iterator_pattern</ref>:'''
The iterator design pattern uses an iterator to traverse a container and access its elements. When we are implementing the response and author feedback report, we will be iterating through each reviewer to get the review performed by them and then each author based on the feedback given for each review. This iteration will occur with the data returned by the ResponseMap model for all of the review and feedback information. For the class performance report, we will be iterating through each questionnaire per assignment, and thereafter each question per questionnaire. The same iteration will also be required to get answers per question per reviewer.

'''MVC Pattern<ref>https://www.tutorialspoint.com/design_pattern/mvc_pattern.htm</ref>:'''
In the MVC design pattern a controller processes the request, interprets the data in model and then renders particular view.
For rendering response and author feedback report, we check the the data, in the form that was submitted from the UI, in the ResponseMappingController. Depending on the data, we process various models and then display a particular view.

=== Review and Author Feedback Report ===

==== Workflow ====
[[File:workflow1.png]]

==== Mockups ====
* When the author will select the review and author feedback, it will show him the screen shown below.

[[File:Mockup1.png]]

==== Implementation Thoughts ====

This report is an integration of two preexisting reports "Review"and "Author Feedback". Thus we will be reusing a lot of components with addition of few.

* A new option will be provided in the dropdown called as "Review and Author Feedback Report".
* On submitting this form, the user is redirected to action "response_report" in controller "ReviewMappingController".
* We will add new case for our requirement.
** We will require data from ReviewResponseMap, FeedbackResponseMap, AssignmentParticipant models.
** From ReviewResponseMap and AssignmentParticipant, for each reviewer we will get number of reviews completed, length of reviews, summary of reviews and whether reviewers had added a file or link for their review.
** From FeedbackResponseMap, we will get author feedback summary and the total score that author gave for the particular reviewer.
* All the above data will be rendered using a new partial "_response_and_feedback.html.erb" in "/app/views/review_mapping". This partial is called from "response_report.html.haml".
* In a similar tabular format for Review/ Author feedback report, we will show the data in a table.
*Hyperlinks will be provided where necessary, so instructor can view additional details. For e.g. to view review summary or author feedback summary.

==== Implementation ====

==== Pull Request and Demo ====

=== Class Performance Report ===

==== Workflow ====
[[File:workflow3.png]]

==== Mockups ====
* The instructor can view the class performance on assignments by clicking on the graph icon on the assignments page as shown below.

[[File:Image11.png]]

* Once you click on the graph icon, it will take the instructor to the page shown below where the instructor can select various rubric questions used for evaluation of that assignment.

[[File:Image22.png]]

* Once you click on the graph icon, it will take the instructor to the page shown below where the instructor can see the performance of the class based on various selected rubric questions.

[[File:Image33.png]]

==== Implementation Thoughts ====

In order to implement the above functionality for the class performance report, our initial observation resulted in the following path for implementation.

* We will need a new controller ''ClassPerformanceController''.
* We will need the following two new views.
** A view to ''select_rubrics''. This view will allow instructors to select a couple of rubrics to evaluate the class performance on.
** A view to ''show_class_performance''. This view will display the class performance using relevant graphs to represent the information clearly.
* Routes for each of the views created.
* Model methods to facilitate getting the required information and calculations.

We need to provide a link to the instructor to see this view. As shown above, this will be a button in the assignment management page routed at ''tree_display/list'' which corresponds to the function ''list'' in the controller ''TreeDisplayController.rb''. The button we are adding here to route to the newly created ''select_rubrics'' view.

The ''select_rubrics'' view will receive the following parameters.

<pre>
assignment_id
</pre>

The controller will get all the questionnaires related to that assignment from the ''AssignmentQuestionnaire'' model. It will then get a list of all the rubrics used in those questionnaires from the ''Questions'' model. These will be displayed to the instructor. It will then route the instructor to the ''show_class_performance'' view upon selection of rubrics. It will pass the following parameters to the ''show_class_performance'' view.

<pre>
assignment_id
Array[question_id]
</pre>

The controller will take the list of questions for the assignment and find all the answers for those questions. It will then calculate the average score per question for the entire class from those answers and pass this to the view. The ''show_class_performance'' view will use the [https://github.com/topfunky/gruff Gruff API] in order to provide an aesthetically appealing visualization of the data.

==== Implementation ====

==== Pull Request and Demo ====

The demo for the class performance report can be seen here: https://youtu.be/_fp4YYCgY2w
The pull request is here:

== Use Cases ==

* '''View Review and Author Feedback Report as Instructor''': As an instructor, he can see the different metrics of reviews and average feedback rating received per student done for an assignment or a project.
* '''View Class Performance as Instructor''': As an instructor, he can select 5 rubric metrics used per assignment. The instructor is able to see the graph to check the class performance based upon the metrics selected.
* '''RSpec''': RSpec is a behavior design development framework which is used for testing the functionality of the system.
* ''' Capybara''': We will be using capybara for automation of the manual test cases written in RSpec.

== Test Plan ==

*'''For use case 1''', test if the instructor can see the text metrics of reviews and author feedbacks received for an assignment or a project per student.
*'''For use case 2''', test if the instructor can select 5 rubric metrics used for an assignment. Also, test if the instructor can view the class performance from a graph using the metrics selected by the instructor.

== Requirements ==

While software and hardware requirements are the same as current Expertiza system, we will require following addition tools:

* '''Tools:''' Gruff API in addition to the current Expertiza system.

== References ==
<references/>

CSC/ECE 517 Fall 2016 E1709 Visualizations for instructors

2016-12-02T23:04:37Z

Aagrawa6: Mockups Updated with final Version

== Introduction ==

Expertiza<ref>https://expertiza.ncsu.edu/</ref> is an open-source web application to create re-usable learning objects through peer-reviews to facilitate incremental learning. Students can submit learning objects such as articles, wiki pages, repository links and with the help of peer reviews, improve them. The project has been developed using the Ruby on Rails<ref>https://en.wikipedia.org/wiki/Ruby_on_Rails</ref> framework and is supported by the [http://www.nsf.gov National Science Foundation].

== Project Description ==

=== Purpose and Scope ===

Expertiza assignments are based on a peer review system where the instructor creates rubrics for an assignment through questionnaires which students use to review other students' submissions. The author of the submission is given an opportunity to provide feedback about these reviews. All questions in the questionnaire have an assigned grade which is based on a pre-defined grading scale. Instructors can see a report on the scores of a student given by reviewers, on the score of feedback given to the reviewers and many other reports. Based on these reports (which are all on separate pages), the instructors grade the student. These reports are, however, on separate pages and it is difficult for an instructor to navigate to many pages before grading the student. The first requirement is meant to solve this problem by merging the review scores with the author feedbacks on the same page.

Furthermore, there is no way for an instructor to evaluate the rubric he/she has posted on assignments. Students may consistently be getting negative reviews for a rubric which might not be totally relevant to the assignment thereby reducing their scores. A report of average class scores for each rubric in the questionnaires would help instructors refactor their rubric and understand where students generally perform well and where they struggle. This new report forms the second part of the requirement.

We are not modifying any of the existing functionalities of Expertiza. Our work would involve modifying the review report and creating a new report for average class scores.

=== Task Description ===

The project requires completion of the following tasks:

* Integrate review data with author feedback data to help instructors grade the reviewers.
* Create a new table for review and author feedback report.
* The new table should have the following information: reviewer name, the number of reviews he has done, length of reviews, review summary, whether there is a link or a file attached, Average author feedback rating per team, Author feedback summary and a field where an instructor can give his grades and write comments.
* Add interactive visualization to show the class performance of an assignment to an instructor.
* Create a new route/view/controller for class performance.
* Add a new link to point to the new controller created. This new link will be created per assignment.
* Create two new views, one for selecting rubric criteria and second to show the graph.
* Create graphs to show the class performance as per the rubric metrics selected dynamically.

== Project Design ==

=== Design Patterns ===

'''Iterator Pattern<ref>https://en.wikipedia.org/wiki/Iterator_pattern</ref>:'''
The iterator design pattern uses an iterator to traverse a container and access its elements. When we are implementing the response and author feedback report, we will be iterating through each reviewer to get the review performed by them and then each author based on the feedback given for each review. This iteration will occur with the data returned by the ResponseMap model for all of the review and feedback information. For the class performance report, we will be iterating through each questionnaire per assignment, and thereafter each question per questionnaire. The same iteration will also be required to get answers per question per reviewer.

'''MVC Pattern<ref>https://www.tutorialspoint.com/design_pattern/mvc_pattern.htm</ref>:'''
In the MVC design pattern a controller processes the request, interprets the data in model and then renders particular view.
For rendering response and author feedback report, we check the the data, in the form that was submitted from the UI, in the ResponseMappingController. Depending on the data, we process various models and then display a particular view.

=== Review and Author Feedback Report ===

==== Workflow ====
[[File:workflow1.png]]

==== Mockups ====
* When the author will select the review and author feedback, it will show him the screen shown below.

[[File:Mockup1.png]]

==== Implementation Thoughts ====

This report is an integration of two preexisting reports "Review"and "Author Feedback". Thus we will be reusing a lot of components with addition of few.

* A new option will be provided in the dropdown called as "Review and Author Feedback Report".
* On submitting this form, the user is redirected to action "response_report" in controller "ReviewMappingController".
* We will add new case for our requirement.
** We will require data from ReviewResponseMap, FeedbackResponseMap, AssignmentParticipant models.
** From ReviewResponseMap and AssignmentParticipant, for each reviewer we will get number of reviews completed, length of reviews, summary of reviews and whether reviewers had added a file or link for their review.
** From FeedbackResponseMap, we will get author feedback summary and the total score that author gave for the particular reviewer.
* All the above data will be rendered using a new partial "_response_and_feedback.html.erb" in "/app/views/review_mapping". This partial is called from "response_report.html.haml".
* In a similar tabular format for Review/ Author feedback report, we will show the data in a table.
*Hyperlinks will be provided where necessary, so instructor can view additional details. For e.g. to view review summary or author feedback summary.

==== Implementation ====

==== Pull Request and Demo ====

=== Class Performance Report ===

==== Workflow ====
[[File:workflow3.png]]

==== Mockups ====
* The instructor can view the class performance on assignments by clicking on the graph icon on the assignments page as shown below.

[[File:Image11.png]]

* Once you click on the graph icon, it will take the instructor to the page shown below where the instructor can select various rubric questions used for evaluation of that assignment.

[[File:Image22.png]]

* Once you click on the graph icon, it will take the instructor to the page shown below where the instructor can see the performance of the class based on various selected rubric questions.

[[File:Image33.png]]

* The instructor can select the round 1 or round 2 from the drop-down menu.

==== Implementation Thoughts ====

In order to implement the above functionality for the class performance report, our initial observation resulted in the following path for implementation.

* We will need a new controller ''ClassPerformanceController''.
* We will need the following two new views.
** A view to ''select_rubrics''. This view will allow instructors to select a couple of rubrics to evaluate the class performance on.
** A view to ''show_class_performance''. This view will display the class performance using relevant graphs to represent the information clearly.
* Routes for each of the views created.
* Model methods to facilitate getting the required information and calculations.

We need to provide a link to the instructor to see this view. As shown above, this will be a button in the assignment management page routed at ''tree_display/list'' which corresponds to the function ''list'' in the controller ''TreeDisplayController.rb''. The button we are adding here to route to the newly created ''select_rubrics'' view.

The ''select_rubrics'' view will receive the following parameters.

<pre>
assignment_id
</pre>

The controller will get all the questionnaires related to that assignment from the ''AssignmentQuestionnaire'' model. It will then get a list of all the rubrics used in those questionnaires from the ''Questions'' model. These will be displayed to the instructor. It will then route the instructor to the ''show_class_performance'' view upon selection of rubrics. It will pass the following parameters to the ''show_class_performance'' view.

<pre>
assignment_id
Array[question_id]
</pre>

The controller will take the list of questions for the assignment and find all the answers for those questions. It will then calculate the average score per question for the entire class from those answers and pass this to the view. The ''show_class_performance'' view will use the [https://github.com/topfunky/gruff Gruff API] in order to provide an aesthetically appealing visualization of the data.

==== Implementation ====

==== Pull Request and Demo ====

The demo for the class performance report can be seen here: https://youtu.be/_fp4YYCgY2w
The pull request is here:

== Use Cases ==

* '''View Review and Author Feedback Report as Instructor''': As an instructor, he can see the different metrics of reviews and average feedback rating received per student done for an assignment or a project.
* '''View Class Performance as Instructor''': As an instructor, he can select 5 rubric metrics used per assignment. The instructor is able to see the graph to check the class performance based upon the metrics selected.
* '''RSpec''': RSpec is a behavior design development framework which is used for testing the functionality of the system.
* ''' Capybara''': We will be using capybara for automation of the manual test cases written in RSpec.

== Test Plan ==

*'''For use case 1''', test if the instructor can see the text metrics of reviews and author feedbacks received for an assignment or a project per student.
*'''For use case 2''', test if the instructor can select 5 rubric metrics used for an assignment. Also, test if the instructor can view the class performance from a graph using the metrics selected by the instructor.

== Requirements ==

While software and hardware requirements are the same as current Expertiza system, we will require following addition tools:

* '''Tools:''' Gruff API in addition to the current Expertiza system.

== References ==
<references/>

File:Image33.png

2016-12-02T23:01:50Z

Aagrawa6:

File:Image22.png

2016-12-02T23:01:35Z

Aagrawa6: Imag22

Imag22

File:Image11.png

2016-12-02T23:00:55Z

Aagrawa6:

CSC/ECE 517 Fall 2016 E1709 Visualizations for instructors

2016-11-09T05:31:23Z

Aagrawa6: /* Test Plan */

== Introduction ==

[https://expertiza.ncsu.edu/ Expertiza] is an open-source web application to create re-usable learning objects through peer-reviews to facilitate incremental learning. Students can submit learning objects such as articles, wiki pages, repository links and with the help of peer reviews, improve them. The project has been developed using the [https://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails] framework and is supported by the [http://www.nsf.gov National Science Foundation].

== Project Description ==

=== Purpose and Scope ===

Expertiza assignments are based on a peer review system where the instructor creates rubrics for an assignment through questionnaires which students use to review other students' submissions. The author of the submission is given an opportunity to provide feedback about these reviews. All questions in the questionnaire have an assigned grade which is based on a pre-defined grading scale. Instructors can see a report on the scores of a student given by reviewers, on the score of feedback given to the reviewers and many other reports. Based on these reports (which are all on separate pages), the instructors grade the student. These reports are, however, on separate pages and it is difficult for an instructor to navigate to many pages before grading the student. The first requirement is meant to solve this problem by merging the review scores with the author feedbacks on the same page.

Furthermore, there is no way for an instructor to evaluate the rubric he/she has posted on assignments. Students may consistently be getting negative reviews for a rubric which might not be totally relevant to the assignment thereby reducing their scores. A report of average class scores for each rubric in the questionnaires would help instructors refactor their rubric and understand where students generally perform well and where they struggle. This new report forms the second part of the requirement.

We are not modifying any of the existing functionalities of Expertiza. Our work would involve modifying the review report and creating a new report for average class scores.

=== Task Description ===

The project requires completion of the following tasks:

* Integrate review data with author feedback data to help instructors grade the reviewers.
* Add a new column to give the length of reviews.
* Separate data from columns number of reviews and summary details.
* Create a new column to check if a reviewer added a link or a file.
* Create a new column to check the average author feedback rating per team.
* Add interactive visualization to show class performance of an assignment to an instructor.
* Create a new route/view/controller for class performance.
* Add a new link to point to the new controller created. This new link will be created per assignment.
* Create two new views, one for selecting rubric criteria and second to show the graph.
* Create graphs to show the class performance as per the rubric metrics selected dynamically.

== Project Design ==

=== Design Patterns ===

=== Review and Author Feedback Report ===

==== Workflow ====
[[File:workflow1.png]]

==== Mockups ====

==== Implementation Thoughts ====

=== Class Performance Report ===

==== Workflow ====
[[File:workflow3.png]]

==== Mockups ====

==== Implementation Thoughts ====

In order to implement the above functionality for the class performance report, our initial observation resulted in the following path for implementation.

* We will need a new controller ''ClassPerformanceController''.
* We will need the following two new views.
** A view to ''select_rubrics''. This view will allow instructors to select a couple of rubrics to evaluate the class performance on.
** A view to ''show_class_performance''. This view will display the class performance using relevant graphs to represent the information clearly.
* Routes for each of the views created.
* Model methods to facilitate getting the required information and calculations.

We need to provide a link to the instructor to see this view. As shown above, this will be a button in the assignment management page routed at ''tree_display/list'' which corresponds to the function ''list'' in the controller ''TreeDisplayController.rb''. The button we are adding here to route to the newly created ''select_rubrics'' view.

The ''select_rubrics'' view will receive the following parameters.

<pre>
assignment_id
</pre>

The controller will get all the questionnaires related to that assignment from the ''AssignmentQuestionnaire'' model. It will then get a list of all the rubrics used in those questionnaires from the ''Questions'' model. These will be displayed to the instructor. It will then route the instructor to the ''show_class_performance'' view upon selection of rubrics. It will pass the following parameters to the ''show_class_performance'' view.

<pre>
assignment_id
Array[question_id]
</pre>

The controller will take the list of questions for the assignment and find all the answers for those questions. It will then calculate the average score per question for the entire class from those answers and pass this to the view. The ''show_class_performance'' view will use the [https://github.com/topfunky/gruff Gruff API] in order to provide an aesthetically appealing visualization of the data.

== Use Cases ==

* '''View Review and Author Feedback Report as Instructor''': As an instructor, he can see the different metrics of reviews and average feedback rating received per student done for an assignment or a project.
* '''View Class Performance as Instructor''': As an instructor, he can select 5 rubric metrics used per assignment. The instructor is able to see the graph to check the class performance based upon the metrics selected.

== Test Plan ==

*'''For use case 1''', test if the instructor can see the text metrics of reviews and author feedbacks received for an assignment or a project per student.
*'''For use case 2''', test if the instructor can select 5 rubric metrics used for an assignment. Also, test if the instructor can view the class performance from a graph using the metrics selected by the instructor.

== System Requirements ==

=== Hardware Requirements ===

* '''Computing Power:''' Same as the current Expertiza system.
* '''Memory:''' Same as the current Expertiza system.
* '''Disk Storage:''' Same as the current Expertiza system.
* '''Peripherals:''' Same as the current Expertiza system.
* '''Network:''' Same as the current Expertiza system.

=== Software Requirements ===

* '''Operating system environment:''' Same as the current Expertiza system.
* '''Networking environment:''' Same as the current Expertiza system.
* '''Tools:''' Gruff API in addition to the current Expertiza system.

== References ==

CSC/ECE 517 Fall 2016 E1709 Visualizations for instructors

2016-11-09T05:31:08Z

Aagrawa6: /* Test Plan Added*/

== Introduction ==

[https://expertiza.ncsu.edu/ Expertiza] is an open-source web application to create re-usable learning objects through peer-reviews to facilitate incremental learning. Students can submit learning objects such as articles, wiki pages, repository links and with the help of peer reviews, improve them. The project has been developed using the [https://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails] framework and is supported by the [http://www.nsf.gov National Science Foundation].

== Project Description ==

=== Purpose and Scope ===

Expertiza assignments are based on a peer review system where the instructor creates rubrics for an assignment through questionnaires which students use to review other students' submissions. The author of the submission is given an opportunity to provide feedback about these reviews. All questions in the questionnaire have an assigned grade which is based on a pre-defined grading scale. Instructors can see a report on the scores of a student given by reviewers, on the score of feedback given to the reviewers and many other reports. Based on these reports (which are all on separate pages), the instructors grade the student. These reports are, however, on separate pages and it is difficult for an instructor to navigate to many pages before grading the student. The first requirement is meant to solve this problem by merging the review scores with the author feedbacks on the same page.

Furthermore, there is no way for an instructor to evaluate the rubric he/she has posted on assignments. Students may consistently be getting negative reviews for a rubric which might not be totally relevant to the assignment thereby reducing their scores. A report of average class scores for each rubric in the questionnaires would help instructors refactor their rubric and understand where students generally perform well and where they struggle. This new report forms the second part of the requirement.

We are not modifying any of the existing functionalities of Expertiza. Our work would involve modifying the review report and creating a new report for average class scores.

=== Task Description ===

The project requires completion of the following tasks:

* Integrate review data with author feedback data to help instructors grade the reviewers.
* Add a new column to give the length of reviews.
* Separate data from columns number of reviews and summary details.
* Create a new column to check if a reviewer added a link or a file.
* Create a new column to check the average author feedback rating per team.
* Add interactive visualization to show class performance of an assignment to an instructor.
* Create a new route/view/controller for class performance.
* Add a new link to point to the new controller created. This new link will be created per assignment.
* Create two new views, one for selecting rubric criteria and second to show the graph.
* Create graphs to show the class performance as per the rubric metrics selected dynamically.

== Project Design ==

=== Design Patterns ===

=== Review and Author Feedback Report ===

==== Workflow ====
[[File:workflow1.png]]

==== Mockups ====

==== Implementation Thoughts ====

=== Class Performance Report ===

==== Workflow ====
[[File:workflow3.png]]

==== Mockups ====

==== Implementation Thoughts ====

In order to implement the above functionality for the class performance report, our initial observation resulted in the following path for implementation.

* We will need a new controller ''ClassPerformanceController''.
* We will need the following two new views.
** A view to ''select_rubrics''. This view will allow instructors to select a couple of rubrics to evaluate the class performance on.
** A view to ''show_class_performance''. This view will display the class performance using relevant graphs to represent the information clearly.
* Routes for each of the views created.
* Model methods to facilitate getting the required information and calculations.

We need to provide a link to the instructor to see this view. As shown above, this will be a button in the assignment management page routed at ''tree_display/list'' which corresponds to the function ''list'' in the controller ''TreeDisplayController.rb''. The button we are adding here to route to the newly created ''select_rubrics'' view.

The ''select_rubrics'' view will receive the following parameters.

<pre>
assignment_id
</pre>

The controller will get all the questionnaires related to that assignment from the ''AssignmentQuestionnaire'' model. It will then get a list of all the rubrics used in those questionnaires from the ''Questions'' model. These will be displayed to the instructor. It will then route the instructor to the ''show_class_performance'' view upon selection of rubrics. It will pass the following parameters to the ''show_class_performance'' view.

<pre>
assignment_id
Array[question_id]
</pre>

The controller will take the list of questions for the assignment and find all the answers for those questions. It will then calculate the average score per question for the entire class from those answers and pass this to the view. The ''show_class_performance'' view will use the [https://github.com/topfunky/gruff Gruff API] in order to provide an aesthetically appealing visualization of the data.

== Use Cases ==

* '''View Review and Author Feedback Report as Instructor''': As an instructor, he can see the different metrics of reviews and average feedback rating received per student done for an assignment or a project.
* '''View Class Performance as Instructor''': As an instructor, he can select 5 rubric metrics used per assignment. The instructor is able to see the graph to check the class performance based upon the metrics selected.

== Test Plan ==

'''For use case 1''', test if the instructor can see the text metrics of reviews and author feedbacks received for an assignment or a project per student.
'''For use case 2''', test if the instructor can select 5 rubric metrics used for an assignment. Also, test if the instructor can view the class performance from a graph using the metrics selected by the instructor.

== System Requirements ==

=== Hardware Requirements ===

* '''Computing Power:''' Same as the current Expertiza system.
* '''Memory:''' Same as the current Expertiza system.
* '''Disk Storage:''' Same as the current Expertiza system.
* '''Peripherals:''' Same as the current Expertiza system.
* '''Network:''' Same as the current Expertiza system.

=== Software Requirements ===

* '''Operating system environment:''' Same as the current Expertiza system.
* '''Networking environment:''' Same as the current Expertiza system.
* '''Tools:''' Gruff API in addition to the current Expertiza system.

== References ==

CSC/ECE 517 Fall 2016 E1709 Visualizations for instructors

2016-11-09T05:22:47Z

Aagrawa6: /* Use Cases */

== Introduction ==

[https://expertiza.ncsu.edu/ Expertiza] is an open-source web application to create re-usable learning objects through peer-reviews to facilitate incremental learning. Students can submit learning objects such as articles, wiki pages, repository links and with the help of peer reviews, improve them. The project has been developed using the [https://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails] framework and is supported by the [http://www.nsf.gov National Science Foundation].

== Project Description ==

=== Purpose and Scope ===

Expertiza assignments are based on a peer review system where the instructor creates rubrics for an assignment through questionnaires which students use to review other students' submissions. The author of the submission is given an opportunity to provide feedback about these reviews. All questions in the questionnaire have an assigned grade which is based on a pre-defined grading scale. Instructors can see a report on the scores of a student given by reviewers, on the score of feedback given to the reviewers and many other reports. Based on these reports (which are all on separate pages), the instructors grade the student. These reports are, however, on separate pages and it is difficult for an instructor to navigate to many pages before grading the student. The first requirement is meant to solve this problem by merging the review scores with the author feedbacks on the same page.

Furthermore, there is no way for an instructor to evaluate the rubric he/she has posted on assignments. Students may consistently be getting negative reviews for a rubric which might not be totally relevant to the assignment thereby reducing their scores. A report of average class scores for each rubric in the questionnaires would help instructors refactor their rubric and understand where students generally perform well and where they struggle. This new report forms the second part of the requirement.

We are not modifying any of the existing functionalities of Expertiza. Our work would involve modifying the review report and creating a new report for average class scores.

=== Task Description ===

The project requires completion of the following tasks:

* Integrate review data with author feedback data to help instructors grade the reviewers.
* Add a new column to give the length of reviews.
* Separate data from columns number of reviews and summary details.
* Create a new column to check if a reviewer added a link or a file.
* Create a new column to check the average author feedback rating per team.
* Add interactive visualization to show class performance of an assignment to an instructor.
* Create a new route/view/controller for class performance.
* Add a new link to point to the new controller created. This new link will be created per assignment.
* Create two new views, one for selecting rubric criteria and second to show the graph.
* Create graphs to show the class performance as per the rubric metrics selected dynamically.

== Design ==

=== Review and Author Feedback Report ===

==== Workflow ====
[[File:workflow1.png]]

==== Mockups ====

==== Implementation Thoughts ====

In order to implement the above functionality for the class performance report, our initial observation resulted in the following path for implementation.

* We will need a new controller ''ClassPerformanceController''.
* We will need the following two new views.
** A view to ''select_rubrics''. This view will allow instructors to select a couple of rubrics to evaluate the class performance on.
** A view to ''show_class_performance''. This view will display the class performance using relevant graphs to represent the information clearly.
* Routes for each of the views created.
* Model methods to facilitate getting the required information and calculations.

We need to provide a link to the instructor to see this view. As shown above, this will be a button in the assignment management page routed at ''tree_display/list'' which corresponds to the function ''list'' in the controller ''TreeDisplayController.rb''. The button we are adding here to route to the newly created ''select_rubrics'' view.

The ''select_rubrics'' view will receive the following parameters.

<pre>
assignment_id
</pre>

The controller will get all the questionnaires related to that assignment from the ''AssignmentQuestionnaire'' model. It will then get a list of all the rubrics used in those questionnaires from the ''Questions'' model. These will be displayed to the instructor. It will then route the instructor to the ''show_class_performance'' view upon selection of rubrics. It will pass the following parameters to the ''show_class_performance'' view.

<pre>
assignment_id
Array[question_id]
</pre>

The controller will take the list of questions for the assignment and find all the answers for those questions. It will then calculate the average score per question for the entire class from those answers and pass this to the view. The ''show_class_performance'' view will use the [https://github.com/topfunky/gruff Gruff API] in order to provide an aesthetically appealing visualization of the data.

=== Class Performance Report ===

==== Workflow ====
[[File:workflow3.png]]

==== Mockups ====

==== Implementation Thoughts ====

== Use Cases ==

* '''View Review and Author Feedback Report as Instructor''': As an instructor, he can see the different metrics of reviews and average feedback rating received per student done for an assignment or a project.
* '''View Class Performance as Instructor''': As an instructor, he can select 5 rubric metrics used per assignment. The instructor is able to see the graph to check the class performance based upon the metrics selected.

== Test Plan ==

== System Requirements ==

=== Hardware Requirements ===

=== Software Requirements ===

== References ==

CSC/ECE 517 Fall 2016 E1709 Visualizations for instructors

2016-11-09T05:22:14Z

Aagrawa6: /* Use Cases Added */

== Introduction ==

[https://expertiza.ncsu.edu/ Expertiza] is an open-source web application to create re-usable learning objects through peer-reviews to facilitate incremental learning. Students can submit learning objects such as articles, wiki pages, repository links and with the help of peer reviews, improve them. The project has been developed using the [https://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails] framework and is supported by the [http://www.nsf.gov National Science Foundation].

== Project Description ==

=== Purpose and Scope ===

Expertiza assignments are based on a peer review system where the instructor creates rubrics for an assignment through questionnaires which students use to review other students' submissions. The author of the submission is given an opportunity to provide feedback about these reviews. All questions in the questionnaire have an assigned grade which is based on a pre-defined grading scale. Instructors can see a report on the scores of a student given by reviewers, on the score of feedback given to the reviewers and many other reports. Based on these reports (which are all on separate pages), the instructors grade the student. These reports are, however, on separate pages and it is difficult for an instructor to navigate to many pages before grading the student. The first requirement is meant to solve this problem by merging the review scores with the author feedbacks on the same page.

Furthermore, there is no way for an instructor to evaluate the rubric he/she has posted on assignments. Students may consistently be getting negative reviews for a rubric which might not be totally relevant to the assignment thereby reducing their scores. A report of average class scores for each rubric in the questionnaires would help instructors refactor their rubric and understand where students generally perform well and where they struggle. This new report forms the second part of the requirement.

We are not modifying any of the existing functionalities of Expertiza. Our work would involve modifying the review report and creating a new report for average class scores.

=== Task Description ===

The project requires completion of the following tasks:

* Integrate review data with author feedback data to help instructors grade the reviewers.
* Add a new column to give the length of reviews.
* Separate data from columns number of reviews and summary details.
* Create a new column to check if a reviewer added a link or a file.
* Create a new column to check the average author feedback rating per team.
* Add interactive visualization to show class performance of an assignment to an instructor.
* Create a new route/view/controller for class performance.
* Add a new link to point to the new controller created. This new link will be created per assignment.
* Create two new views, one for selecting rubric criteria and second to show the graph.
* Create graphs to show the class performance as per the rubric metrics selected dynamically.

== Design ==

=== Review and Author Feedback Report ===

==== Workflow ====
[[File:workflow1.png]]

==== Mockups ====

==== Implementation Thoughts ====

In order to implement the above functionality for the class performance report, our initial observation resulted in the following path for implementation.

* We will need a new controller ''ClassPerformanceController''.
* We will need the following two new views.
** A view to ''select_rubrics''. This view will allow instructors to select a couple of rubrics to evaluate the class performance on.
** A view to ''show_class_performance''. This view will display the class performance using relevant graphs to represent the information clearly.
* Routes for each of the views created.
* Model methods to facilitate getting the required information and calculations.

We need to provide a link to the instructor to see this view. As shown above, this will be a button in the assignment management page routed at ''tree_display/list'' which corresponds to the function ''list'' in the controller ''TreeDisplayController.rb''. The button we are adding here to route to the newly created ''select_rubrics'' view.

The ''select_rubrics'' view will receive the following parameters.

<pre>
assignment_id
</pre>

The controller will get all the questionnaires related to that assignment from the ''AssignmentQuestionnaire'' model. It will then get a list of all the rubrics used in those questionnaires from the ''Questions'' model. These will be displayed to the instructor. It will then route the instructor to the ''show_class_performance'' view upon selection of rubrics. It will pass the following parameters to the ''show_class_performance'' view.

<pre>
assignment_id
Array[question_id]
</pre>

The controller will take the list of questions for the assignment and find all the answers for those questions. It will then calculate the average score per question for the entire class from those answers and pass this to the view. The ''show_class_performance'' view will use the [https://github.com/topfunky/gruff Gruff API] in order to provide an aesthetically appealing visualization of the data.

=== Class Performance Report ===

==== Workflow ====
[[File:workflow3.png]]

==== Mockups ====

==== Implementation Thoughts ====

== Use Cases ==

* View Review and Author Feedback Report as Instructor: As an instructor, he can see the different metrics of reviews and average feedback rating received per student done for an assignment or a project.
* View Class Performance as Instructor: As an instructor, he can select 5 rubric metrics used per assignment. The instructor is able to see the graph to check the class performance based upon the metrics selected.

== Test Plan ==

== System Requirements ==

=== Hardware Requirements ===

=== Software Requirements ===

== References ==

CSC/ECE 517 Fall 2016 E1709 Visualizations for instructors

2016-11-09T05:10:57Z

Aagrawa6: /* Class Performance Report */

CSC/ECE 517 Fall 2016 E1709 Visualizations for instructors

2016-11-09T05:10:44Z

Aagrawa6: Workflow Diagram 2 added

File:Workflow3.png

2016-11-09T05:10:16Z

Aagrawa6:

CSC/ECE 517 Fall 2016 E1709 Visualizations for instructors

2016-11-09T05:02:01Z

Aagrawa6: /* Design */

CSC/ECE 517 Fall 2016 E1709 Visualizations for instructors

2016-11-09T05:01:37Z

Aagrawa6: /* Workflow */

CSC/ECE 517 Fall 2016 E1709 Visualizations for instructors

2016-11-09T05:00:34Z

Aagrawa6: Workflow Diagram 1 added

File:Workflow1.png

2016-11-09T04:59:52Z

Aagrawa6:

CSC/ECE 517 Fall 2016 E1709 Visualizations for instructors

2016-11-09T04:29:10Z

Aagrawa6: /* Task Description */

CSC/ECE 517 Fall 2016 E1709 Visualizations for instructors

2016-11-09T04:27:25Z

Aagrawa6: /* Task Description */

CSC/ECE 517 Fall 2016 E1709 Visualizations for instructors

2016-11-09T04:26:11Z

Aagrawa6: /* Task Description */

CSC/ECE 517 Fall 2016 E1709 Visualizations for instructors

2016-11-09T04:21:04Z

Aagrawa6: Task Description Added

CSC/ECE 517 Fall 2016/E1634. Refactor and write unit test of due date.rb and deadline helper.rb

2016-11-05T03:19:48Z

Aagrawa6: /* UI Testing */

== '''Introduction''' ==

=== Expertiza ===
Expertiza<ref>https://expertiza.ncsu.edu/</ref> is an open source project for school assignment management for instructors and students based on the Ruby on Rails<ref>http://www.rubyonrails.org</ref> framework. Expertiza allows the instructor to create new assignments and customise new or existing assignments. It also allows the instructor to create a list of topics the students can sign up for. Students can form teams in Expertiza to work on various projects and assignments. Students can also peer review other students' submissions. Expertiza supports submission across various document types, including the URLs and word documents. Expertiza provides a dashboard for all the assignments corresponding to a course and provides absolute control to the Instructors and Teaching Assistants. In addition to assignments, it encompasses peer reviews wherein participants are allowed to provide feedback anonymously about each other's work thereby providing scope for the better outcome. The due_date.rb file is responsible for informing the users about the deadline for submission of the each assignment. Due dates in Expertiza have their association with many other components like assignments, reviews etc.

=== Code Climate ===
Code Climate<ref>https://codeclimate.com/dashboard</ref> is a tool that runs static analysis on a GitHub project and outputs many details like test coverage, complexity, duplication, security, style, and more. There is a Google Chrome extension to integrate the Code Climate results generated directly into GitHub which is visible when browsing the repository on the browser. It allows us to see issues displayed directly inside GitHub's UI, to review which lines are covered in diffs and files, and add repositories and open tickets without changing your workflow.

== '''Tasks Identified''' ==
To install Code climate Chrome Extension that highlights the duplicated code.

To refactor the following two files:
* due_date.rb
** Ternary operators must not be nested. Prefer `if` or `else` constructs instead.
** Useless assignment to variable - `sorted_deadlines`.
** Prefer `each` over `for`.
** Use `find_by` instead of `where.first`.
** Correct the use of Time function
* deadline_helper.rb
** Do not use `Time.now` without zone. Use one of `Time.zone.now`, `Time.current`, `Time.now.in_time_zone`, `Time.now.utc`, `Time.now.getlocal`, `Time.now.iso8601`, `Time.now.jisx0301`, `Time.now.rfc3339`, `Time.now.to_i`, `Time.now.to_f` instead.
** Trailing whitespace detected.
** Extra empty line detected at module body end.

* Create respective RSpec<ref>http://www.rspec.info</ref> files in /spec/models/ and /spec/helper folder and write unit tests for each method in due_date.rb and deadline_helper.rb.

== '''Current Implementation''' ==
DueDate is a Model class to manage the deadlines of an assignment. It has methods for setting due dates for an assignment, copying due dates from one assignment to a new assignment etc. DeadlineHelper provides helper functions that help DueDate perform certain tasks. The assignment focuses on refactoring some of the methods based on warnings received from Code Climate's static analysis and modifying the language to make it more Ruby-friendly. The assignment also involves writing unit test cases for due_date.rb and deadline_helper.rb in order to increase test coverage.

The goal of this project is to attempt to make this part of the application easier to read and write unit test cases that the application must pass.

== '''Changed Implementation''' ==
Changes implemented involves refactoring the code and making it more understandable by adding comments in the code.

The modified files are
* due_date.rb (path: /app/models)
* deadline_helper.rb (path: /app/helpers)
Testing files
* due_date_spec.rb (path: /spec/models)
* deadline_helper_spec.rb (path: /spec/helpers)

=== due_date.rb ===
* Converted for..in loop to object.each in order to follow better Ruby syntax.
* Unnecessary assignment to sorted_deadlines removed.
* Nested ternary operators have been changed to if..else in order to make it more readable.
[[File:Duedaterb.png]]
* Changed where(...).first to find_by(...) which is the newer recommended syntax.
* Corrected the Time.now functions by adding the correct zones to them such as Time.zone.now.
* Removed trailing whitespaces.
[[File:DueDaterb2.png]]

=== deadline_helper.rb ===
* Time functions were changed to functions with zones
* Extra line removed
[[File:Deadlinehelper.png]]

== '''RSpec testing''' ==
There were no existing tests for the functions in due_date.rb and deadline_helper.rb. We have added exhaustive set of RSpec tests to test all the code. We have added two new spec files 'due_date_spec.rb' and ‘deadline_helper_spec.rb’ which cover the testing scenarios for the functions in ‘due_date.rb’ and ‘deadline_helper.rb’.

For both of these two files, all Travis CI<ref>http://www.travis-ci.com</ref> test cases have passed for all previous test cases as well as the ones added by us with the test coverage for the files due_date.rb and deadline_helper.rb reported as 100%.

These RSpec files have 100% code coverage visible at: /coverage/index.html.

=== due_date_spec.rb ===
This file is located at spec/models and tests the functionalities of the due_date.rb file located in app/models. There are 18 test cases in total which are listed below.
* If the factory is successfully able to build the due_date objects.
<pre>
it "due date factory created successfully" do
expect(@assignment_due_date).to be_valid
end
</pre>
<pre>
it "due dates created correctly" do
expect(@due_dates.length).to be == 10
end
</pre>
* If the function "set_flag" successfully sets the due_date flag.
<pre>
it "due date flag is set" do
expect(@assignment_due_date.flag).to be false
@assignment_due_date.set_flag
expect(@assignment_due_date.flag).to be true
end
</pre>
* If the function "due_at_is_valid_datetime" returns nil (no errors) for a valid datetime in due_at (no invalid test cases can be added here because model does not allow invalid datetime to be set at all).
<pre>
it "due at is valid datetime" do
expect(@assignment_due_date.due_at_is_valid_datetime).to be nil
end
</pre>
* If the function "self.copy" is able to copy due dates from one assignment to another.
<pre>
it "copy due dates to new assignment" do
new_assignment_id = build(:assignment, id: 999).id
old_assignment_id = @assignment_due_date.assignment.id
DueDate.copy(old_assignment_id, new_assignment_id)
expect(DueDate.where(parent_id: new_assignment_id).count).to eql DueDate.where(parent_id: old_assignment_id).count
end
</pre>
* If the function "self.set_duedate" is able to create another due date by copying data from an existing due date object.
<pre>
it "create new duedate record with values" do
DueDate.set_duedate({id: 999}, @assignment_due_date.deadline_type_id,
@assignment_due_date.parent_id, @assignment_due_date.round)
new_due_date = DueDate.find_by(id: 999)
expect(new_due_date).to be_valid
expect(new_due_date.deadline_type_id).to eql @assignment_due_date.deadline_type_id
expect(new_due_date.parent_id).to eql @assignment_due_date.parent_id
expect(new_due_date.round).to eql @assignment_due_date.round
end
</pre>
* If the function "self.deadline_sort" is able to sort the due dates in ascending order.
<pre>
it "sort duedate records" do
sorted_due_dates = @due_dates
expect(sorted_due_dates.each_cons(2).all?{|m1, m2| (m1.due_at <=> m2.due_at) != 1}).to eql false

sorted_due_dates = DueDate.deadline_sort(@due_dates)
expect(sorted_due_dates.each_cons(2).all?{|m1, m2| (m1.due_at <=> m2.due_at) != 1}).to eql true
end
</pre>
* If the function "self.done_in_assignment_round" returns the correct number of rounds for specific inputs. This involves an invalid test case as well for 0 rounds.
<pre>
describe "#done_in_assignment_round" do
it "return 0 when no response map" do
response = ReviewResponseMap.create
response.type = "ResponseMap"
response.save
expect(DueDate.done_in_assignment_round(1, response)).to eql 0
end

it "return round 1 for single round" do
response = ReviewResponseMap.create
expect(DueDate.done_in_assignment_round(@assignment_due_date.parent_id, response)).to eql 1
end
end
</pre>
* If the function "self.get_next_due_date" works as expected. This involves several invalid test cases as well.
<pre>
describe "#get_next_due_date" do
it "no subsequent due date" do
expect(DueDate.get_next_due_date(@assignment_due_date.parent_id)).to be nil
end

it "nil value throws exception" do
expect { DueDate.get_next_due_date(nil) }.to raise_exception(ActiveRecord::RecordNotFound)
end

it "get next assignment due date" do
due_date = create(:assignment_due_date, deadline_type: @deadline_type,
submission_allowed_id: @deadline_right.id, review_allowed_id: @deadline_right.id,
review_of_review_allowed_id: @deadline_right.id, due_at: Time.zone.now + 5000)
expect(DueDate.get_next_due_date(due_date.parent_id)).to be_valid
end

it "get next due date from topic for staggered deadline" do
assignment_id = create(:assignment, staggered_deadline: true, name: "testassignment").id
due_date = create(:topic_due_date, deadline_type: @deadline_type,
submission_allowed_id: @deadline_right.id, review_allowed_id: @deadline_right.id,
review_of_review_allowed_id: @deadline_right.id, due_at: Time.zone.now + 5000, parent_id: assignment_id)
expect(DueDate.get_next_due_date(assignment_id, due_date.parent_id)).to be_valid
end

it "next due date does not exist for staggered deadline" do
assignment_id = create(:assignment, staggered_deadline: true, name: "testassignment").id
due_date = create(:topic_due_date, deadline_type: @deadline_type,
submission_allowed_id: @deadline_right, review_allowed_id: @deadline_right,
review_of_review_allowed_id: @deadline_right, due_at: Time.zone.now + 5000, parent_id: assignment_id)
expect(DueDate.get_next_due_date(assignment_id)).to be nil
end

it "next due date is before Time.now for staggered deadline" do
assignment_id = create(:assignment, staggered_deadline: true, name: "testassignment").id
due_date = create(:topic_due_date, deadline_type: @deadline_type,
submission_allowed_id: @deadline_right, review_allowed_id: @deadline_right,
review_of_review_allowed_id: @deadline_right, due_at: Time.zone.now - 5000, parent_id: assignment_id)
expect(DueDate.get_next_due_date(assignment_id, due_date.parent_id)).to be nil
end

it "get next due date from assignment for staggered deadline" do
assignment_id = create(:assignment, staggered_deadline: true, name: "testassignment").id
due_date = create(:assignment_due_date, deadline_type: @deadline_type,
submission_allowed_id: @deadline_right, review_allowed_id: @deadline_right,
review_of_review_allowed_id: @deadline_right, due_at: Time.zone.now + 5000, parent_id: assignment_id)
expect(DueDate.get_next_due_date(assignment_id)).to be_valid
end
end
</pre>
* If the function "self.default_permission" returns the correct default permissions for particular deadline and permission types.
<pre>
it "metareview review_of_review_allowed default permission OK" do
expect(DueDate.default_permission('metareview', 'review_of_review_allowed')).to be == DeadlineRight::OK
end
</pre>
<pre>
it "review submission_allowed default permission NO" do
expect(DueDate.default_permission('review', 'submission_allowed')).to be == DeadlineRight::NO
end
</pre>
To test this file run the following command:
<pre>
rspec spec/models/due_date_spec.rb
</pre>
The output of this RSpec file is present in below screenshot:
[[File:Duedaterspec.png]]

Code coverage details of the above RSpec files is present in below screenshot:
[[File:Duedatecoverage.png]]

=== deadline_helper_spec.rb ===
This is a test file for testing the functionalities of Deadline_helper.rb file located at app/helpers. Different test cases present in this file are:
* Check if the factory<ref>http://www.semaphoreci.com|access-date</ref> is valid:
<pre>
it "has a valid factory" do
factory = FactoryGirl.build(:topic_due_date)
expect(factory).to be_valid
end
</pre>
* Fail if the due date is invalid:
<pre>
it "should fail because of invalid due_date" do
expect { DeadlineHelper.create_topic_deadline(nil, 0, 0)}.to raise_exception(NoMethodError)
end
</pre>
* If new due_date object is created:
<pre>
it "new due_date object created" do
DeadlineHelper.create_topic_deadline(@topic_due_date, 0, 1)
expect(TopicDueDate.count).to be == 2
end
</pre>
* due_at should be same for 0 offset:
<pre>
it "due_at should be same for 0 offset" do
DeadlineHelper.create_topic_deadline(@topic_due_date, 0, 10)
new_due_date = TopicDueDate.find_by(parent_id: 10)
expect(new_due_date).to be_valid
expect(new_due_date.due_at.to_s).to be == @topic_due_date.due_at.to_s
end
</pre>
* due_at is calculated correctly if offset is positive:
<pre>
it "due_at calculated correctly for positive offset" do
DeadlineHelper.create_topic_deadline(@topic_due_date, 5000, 10)
new_due_date = TopicDueDate.find_by(parent_id: 10)
expect(new_due_date).to be_valid
expect(new_due_date.due_at.to_s).to be == (Time.zone.parse(@topic_due_date.due_at.to_s) + 5000).to_s
end
</pre>
* due_at is calculated correctly if offset is negative:
<pre>
it "due_at calculated correctly for negative offset" do
DeadlineHelper.create_topic_deadline(@topic_due_date, -5000, 10)
new_due_date = TopicDueDate.find_by(parent_id: 10)
expect(new_due_date).to be_valid
expect(new_due_date.due_at.to_s).to be == (Time.zone.parse(@topic_due_date.due_at.to_s) - 5000).to_s
end
</pre>
* The offset is being converted to integer properly:
<pre>
it "offset converted to integer correctly" do
DeadlineHelper.create_topic_deadline(@topic_due_date, 5000.15, 10)
new_due_date = TopicDueDate.find_by(parent_id: 10)
expect(new_due_date).to be_valid
expect(new_due_date.due_at.to_s).to be == (Time.zone.parse(@topic_due_date.due_at.to_s) + 5000).to_s
end
</pre>
To test this file run the following command:
<pre>
rspec spec/models/deadline_helper_spec.rb
</pre>
The output of this RSpec file is present in below screenshot:
[[File:Deadlinerspec.png]]

Code coverage details of the above RSpec files is present in below screenshot:
[[File:Deadlinecoverage.png]]

== '''Testing The System''' ==
Run the following commands to test the new RSpec files created:
* rspec spec/models/deadline_helper_spec.rb
* rspec spec/models/due_date_spec.rb

== '''UI Testing''' ==
* How to test creation of new assignment with due dates using U(username: instructor6, password: password)I: [https://www.youtube.com/watch?v=zJILRQpSgn4]

==References==
<references/>

CSC/ECE 517 Fall 2016/E1634. Refactor and write unit test of due date.rb and deadline helper.rb

2016-11-05T02:53:37Z

Aagrawa6: /* UI Testing */

== '''Introduction''' ==

=== Expertiza ===
Expertiza<ref>https://expertiza.ncsu.edu/</ref> is an open source project for school assignment management for instructors and students based on the Ruby on Rails<ref>http://www.rubyonrails.org</ref> framework. Expertiza allows the instructor to create new assignments and customise new or existing assignments. It also allows the instructor to create a list of topics the students can sign up for. Students can form teams in Expertiza to work on various projects and assignments. Students can also peer review other students' submissions. Expertiza supports submission across various document types, including the URLs and word documents. Expertiza provides a dashboard for all the assignments corresponding to a course and provides absolute control to the Instructors and Teaching Assistants. In addition to assignments, it encompasses peer reviews wherein participants are allowed to provide feedback anonymously about each other's work thereby providing scope for the better outcome. The due_date.rb file is responsible for informing the users about the deadline for submission of the each assignment. Due dates in Expertiza have their association with many other components like assignments, reviews etc.

=== Code Climate ===
Code Climate<ref>https://codeclimate.com/dashboard</ref> is a tool that runs static analysis on a GitHub project and outputs many details like test coverage, complexity, duplication, security, style, and more. There is a Google Chrome extension to integrate the Code Climate results generated directly into GitHub which is visible when browsing the repository on the browser. It allows us to see issues displayed directly inside GitHub's UI, to review which lines are covered in diffs and files, and add repositories and open tickets without changing your workflow.

== '''Tasks Identified''' ==
To install Code climate Chrome Extension that highlights the duplicated code.

To refactor the following two files:
* due_date.rb
** Ternary operators must not be nested. Prefer `if` or `else` constructs instead.
** Useless assignment to variable - `sorted_deadlines`.
** Prefer `each` over `for`.
** Use `find_by` instead of `where.first`.
** Correct the use of Time function
* deadline_helper.rb
** Do not use `Time.now` without zone. Use one of `Time.zone.now`, `Time.current`, `Time.now.in_time_zone`, `Time.now.utc`, `Time.now.getlocal`, `Time.now.iso8601`, `Time.now.jisx0301`, `Time.now.rfc3339`, `Time.now.to_i`, `Time.now.to_f` instead.
** Trailing whitespace detected.
** Extra empty line detected at module body end.

* Create respective RSpec<ref>http://www.rspec.info</ref> files in /spec/models/ and /spec/helper folder and write unit tests for each method in due_date.rb and deadline_helper.rb.

== '''Current Implementation''' ==
DueDate is a Model class to manage the deadlines of an assignment. It has methods for setting due dates for an assignment, copying due dates from one assignment to a new assignment etc. DeadlineHelper provides helper functions that help DueDate perform certain tasks. The assignment focuses on refactoring some of the methods based on warnings received from Code Climate's static analysis and modifying the language to make it more Ruby-friendly. The assignment also involves writing unit test cases for due_date.rb and deadline_helper.rb in order to increase test coverage.

The goal of this project is to attempt to make this part of the application easier to read and write unit test cases that the application must pass.

== '''Changed Implementation''' ==
Changes implemented involves refactoring the code and making it more understandable by adding comments in the code.

The modified files are
* due_date.rb (path: /app/models)
* deadline_helper.rb (path: /app/helpers)
Testing files
* due_date_spec.rb (path: /spec/models)
* deadline_helper_spec.rb (path: /spec/helpers)

=== due_date.rb ===
* Converted for..in loop to object.each in order to follow better Ruby syntax.
* Unnecessary assignment to sorted_deadlines removed.
* Nested ternary operators have been changed to if..else in order to make it more readable.
[[File:Duedaterb.png]]
* Changed where(...).first to find_by(...) which is the newer recommended syntax.
* Corrected the Time.now functions by adding the correct zones to them such as Time.zone.now.
* Removed trailing whitespaces.
[[File:DueDaterb2.png]]

=== deadline_helper.rb ===
* Time functions were changed to functions with zones
* Extra line removed
[[File:Deadlinehelper.png]]

== '''RSpec testing''' ==
There were no existing tests for the functions in due_date.rb and deadline_helper.rb. We have added exhaustive set of RSpec tests to test all the code. We have added two new spec files 'due_date_spec.rb' and ‘deadline_helper_spec.rb’ which cover the testing scenarios for the functions in ‘due_date.rb’ and ‘deadline_helper.rb’.

For both of these two files, all Travis CI<ref>http://www.travis-ci.com</ref> test cases have passed for all previous test cases as well as the ones added by us with the test coverage for the files due_date.rb and deadline_helper.rb reported as 100%.

These RSpec files have 100% code coverage visible at: /coverage/index.html.

=== due_date_spec.rb ===
This file is located at spec/models and tests the functionalities of the due_date.rb file located in app/models. There are 18 test cases in total which are listed below.
* If the factory is successfully able to build the due_date objects.
<pre>
it "due date factory created successfully" do
expect(@assignment_due_date).to be_valid
end
</pre>
<pre>
it "due dates created correctly" do
expect(@due_dates.length).to be == 10
end
</pre>
* If the function "set_flag" successfully sets the due_date flag.
<pre>
it "due date flag is set" do
expect(@assignment_due_date.flag).to be false
@assignment_due_date.set_flag
expect(@assignment_due_date.flag).to be true
end
</pre>
* If the function "due_at_is_valid_datetime" returns nil (no errors) for a valid datetime in due_at (no invalid test cases can be added here because model does not allow invalid datetime to be set at all).
<pre>
it "due at is valid datetime" do
expect(@assignment_due_date.due_at_is_valid_datetime).to be nil
end
</pre>
* If the function "self.copy" is able to copy due dates from one assignment to another.
<pre>
it "copy due dates to new assignment" do
new_assignment_id = build(:assignment, id: 999).id
old_assignment_id = @assignment_due_date.assignment.id
DueDate.copy(old_assignment_id, new_assignment_id)
expect(DueDate.where(parent_id: new_assignment_id).count).to eql DueDate.where(parent_id: old_assignment_id).count
end
</pre>
* If the function "self.set_duedate" is able to create another due date by copying data from an existing due date object.
<pre>
it "create new duedate record with values" do
DueDate.set_duedate({id: 999}, @assignment_due_date.deadline_type_id,
@assignment_due_date.parent_id, @assignment_due_date.round)
new_due_date = DueDate.find_by(id: 999)
expect(new_due_date).to be_valid
expect(new_due_date.deadline_type_id).to eql @assignment_due_date.deadline_type_id
expect(new_due_date.parent_id).to eql @assignment_due_date.parent_id
expect(new_due_date.round).to eql @assignment_due_date.round
end
</pre>
* If the function "self.deadline_sort" is able to sort the due dates in ascending order.
<pre>
it "sort duedate records" do
sorted_due_dates = @due_dates
expect(sorted_due_dates.each_cons(2).all?{|m1, m2| (m1.due_at <=> m2.due_at) != 1}).to eql false

sorted_due_dates = DueDate.deadline_sort(@due_dates)
expect(sorted_due_dates.each_cons(2).all?{|m1, m2| (m1.due_at <=> m2.due_at) != 1}).to eql true
end
</pre>
* If the function "self.done_in_assignment_round" returns the correct number of rounds for specific inputs. This involves an invalid test case as well for 0 rounds.
<pre>
describe "#done_in_assignment_round" do
it "return 0 when no response map" do
response = ReviewResponseMap.create
response.type = "ResponseMap"
response.save
expect(DueDate.done_in_assignment_round(1, response)).to eql 0
end

it "return round 1 for single round" do
response = ReviewResponseMap.create
expect(DueDate.done_in_assignment_round(@assignment_due_date.parent_id, response)).to eql 1
end
end
</pre>
* If the function "self.get_next_due_date" works as expected. This involves several invalid test cases as well.
<pre>
describe "#get_next_due_date" do
it "no subsequent due date" do
expect(DueDate.get_next_due_date(@assignment_due_date.parent_id)).to be nil
end

it "nil value throws exception" do
expect { DueDate.get_next_due_date(nil) }.to raise_exception(ActiveRecord::RecordNotFound)
end

it "get next assignment due date" do
due_date = create(:assignment_due_date, deadline_type: @deadline_type,
submission_allowed_id: @deadline_right.id, review_allowed_id: @deadline_right.id,
review_of_review_allowed_id: @deadline_right.id, due_at: Time.zone.now + 5000)
expect(DueDate.get_next_due_date(due_date.parent_id)).to be_valid
end

it "get next due date from topic for staggered deadline" do
assignment_id = create(:assignment, staggered_deadline: true, name: "testassignment").id
due_date = create(:topic_due_date, deadline_type: @deadline_type,
submission_allowed_id: @deadline_right.id, review_allowed_id: @deadline_right.id,
review_of_review_allowed_id: @deadline_right.id, due_at: Time.zone.now + 5000, parent_id: assignment_id)
expect(DueDate.get_next_due_date(assignment_id, due_date.parent_id)).to be_valid
end

it "next due date does not exist for staggered deadline" do
assignment_id = create(:assignment, staggered_deadline: true, name: "testassignment").id
due_date = create(:topic_due_date, deadline_type: @deadline_type,
submission_allowed_id: @deadline_right, review_allowed_id: @deadline_right,
review_of_review_allowed_id: @deadline_right, due_at: Time.zone.now + 5000, parent_id: assignment_id)
expect(DueDate.get_next_due_date(assignment_id)).to be nil
end

it "next due date is before Time.now for staggered deadline" do
assignment_id = create(:assignment, staggered_deadline: true, name: "testassignment").id
due_date = create(:topic_due_date, deadline_type: @deadline_type,
submission_allowed_id: @deadline_right, review_allowed_id: @deadline_right,
review_of_review_allowed_id: @deadline_right, due_at: Time.zone.now - 5000, parent_id: assignment_id)
expect(DueDate.get_next_due_date(assignment_id, due_date.parent_id)).to be nil
end

it "get next due date from assignment for staggered deadline" do
assignment_id = create(:assignment, staggered_deadline: true, name: "testassignment").id
due_date = create(:assignment_due_date, deadline_type: @deadline_type,
submission_allowed_id: @deadline_right, review_allowed_id: @deadline_right,
review_of_review_allowed_id: @deadline_right, due_at: Time.zone.now + 5000, parent_id: assignment_id)
expect(DueDate.get_next_due_date(assignment_id)).to be_valid
end
end
</pre>
* If the function "self.default_permission" returns the correct default permissions for particular deadline and permission types.
<pre>
it "metareview review_of_review_allowed default permission OK" do
expect(DueDate.default_permission('metareview', 'review_of_review_allowed')).to be == DeadlineRight::OK
end
</pre>
<pre>
it "review submission_allowed default permission NO" do
expect(DueDate.default_permission('review', 'submission_allowed')).to be == DeadlineRight::NO
end
</pre>
To test this file run the following command:
<pre>
rspec spec/models/due_date_spec.rb
</pre>
The output of this RSpec file is present in below screenshot:
[[File:Duedaterspec.png]]

Code coverage details of the above RSpec files is present in below screenshot:
[[File:Duedatecoverage.png]]

=== deadline_helper_spec.rb ===
This is a test file for testing the functionalities of Deadline_helper.rb file located at app/helpers. Different test cases present in this file are:
* Check if the factory<ref>http://www.semaphoreci.com|access-date</ref> is valid:
<pre>
it "has a valid factory" do
factory = FactoryGirl.build(:topic_due_date)
expect(factory).to be_valid
end
</pre>
* Fail if the due date is invalid:
<pre>
it "should fail because of invalid due_date" do
expect { DeadlineHelper.create_topic_deadline(nil, 0, 0)}.to raise_exception(NoMethodError)
end
</pre>
* If new due_date object is created:
<pre>
it "new due_date object created" do
DeadlineHelper.create_topic_deadline(@topic_due_date, 0, 1)
expect(TopicDueDate.count).to be == 2
end
</pre>
* due_at should be same for 0 offset:
<pre>
it "due_at should be same for 0 offset" do
DeadlineHelper.create_topic_deadline(@topic_due_date, 0, 10)
new_due_date = TopicDueDate.find_by(parent_id: 10)
expect(new_due_date).to be_valid
expect(new_due_date.due_at.to_s).to be == @topic_due_date.due_at.to_s
end
</pre>
* due_at is calculated correctly if offset is positive:
<pre>
it "due_at calculated correctly for positive offset" do
DeadlineHelper.create_topic_deadline(@topic_due_date, 5000, 10)
new_due_date = TopicDueDate.find_by(parent_id: 10)
expect(new_due_date).to be_valid
expect(new_due_date.due_at.to_s).to be == (Time.zone.parse(@topic_due_date.due_at.to_s) + 5000).to_s
end
</pre>
* due_at is calculated correctly if offset is negative:
<pre>
it "due_at calculated correctly for negative offset" do
DeadlineHelper.create_topic_deadline(@topic_due_date, -5000, 10)
new_due_date = TopicDueDate.find_by(parent_id: 10)
expect(new_due_date).to be_valid
expect(new_due_date.due_at.to_s).to be == (Time.zone.parse(@topic_due_date.due_at.to_s) - 5000).to_s
end
</pre>
* The offset is being converted to integer properly:
<pre>
it "offset converted to integer correctly" do
DeadlineHelper.create_topic_deadline(@topic_due_date, 5000.15, 10)
new_due_date = TopicDueDate.find_by(parent_id: 10)
expect(new_due_date).to be_valid
expect(new_due_date.due_at.to_s).to be == (Time.zone.parse(@topic_due_date.due_at.to_s) + 5000).to_s
end
</pre>
To test this file run the following command:
<pre>
rspec spec/models/deadline_helper_spec.rb
</pre>
The output of this RSpec file is present in below screenshot:
[[File:Deadlinerspec.png]]

Code coverage details of the above RSpec files is present in below screenshot:
[[File:Deadlinecoverage.png]]

== '''Testing The System''' ==
Run the following commands to test the new RSpec files created:
* rspec spec/models/deadline_helper_spec.rb
* rspec spec/models/due_date_spec.rb

== '''UI Testing''' ==
* How to test creation of new assignment with due dates using UI: [https://www.youtube.com/watch?v=zJILRQpSgn4]

==References==
<references/>

CSC/ECE 517 Fall 2016/E1634. Refactor and write unit test of due date.rb and deadline helper.rb

2016-11-05T02:53:12Z

Aagrawa6: /* Testing The System */

== '''Introduction''' ==

=== Expertiza ===
Expertiza<ref>https://expertiza.ncsu.edu/</ref> is an open source project for school assignment management for instructors and students based on the Ruby on Rails<ref>http://www.rubyonrails.org</ref> framework. Expertiza allows the instructor to create new assignments and customise new or existing assignments. It also allows the instructor to create a list of topics the students can sign up for. Students can form teams in Expertiza to work on various projects and assignments. Students can also peer review other students' submissions. Expertiza supports submission across various document types, including the URLs and word documents. Expertiza provides a dashboard for all the assignments corresponding to a course and provides absolute control to the Instructors and Teaching Assistants. In addition to assignments, it encompasses peer reviews wherein participants are allowed to provide feedback anonymously about each other's work thereby providing scope for the better outcome. The due_date.rb file is responsible for informing the users about the deadline for submission of the each assignment. Due dates in Expertiza have their association with many other components like assignments, reviews etc.

=== Code Climate ===
Code Climate<ref>https://codeclimate.com/dashboard</ref> is a tool that runs static analysis on a GitHub project and outputs many details like test coverage, complexity, duplication, security, style, and more. There is a Google Chrome extension to integrate the Code Climate results generated directly into GitHub which is visible when browsing the repository on the browser. It allows us to see issues displayed directly inside GitHub's UI, to review which lines are covered in diffs and files, and add repositories and open tickets without changing your workflow.

== '''Tasks Identified''' ==
To install Code climate Chrome Extension that highlights the duplicated code.

To refactor the following two files:
* due_date.rb
** Ternary operators must not be nested. Prefer `if` or `else` constructs instead.
** Useless assignment to variable - `sorted_deadlines`.
** Prefer `each` over `for`.
** Use `find_by` instead of `where.first`.
** Correct the use of Time function
* deadline_helper.rb
** Do not use `Time.now` without zone. Use one of `Time.zone.now`, `Time.current`, `Time.now.in_time_zone`, `Time.now.utc`, `Time.now.getlocal`, `Time.now.iso8601`, `Time.now.jisx0301`, `Time.now.rfc3339`, `Time.now.to_i`, `Time.now.to_f` instead.
** Trailing whitespace detected.
** Extra empty line detected at module body end.

* Create respective RSpec<ref>http://www.rspec.info</ref> files in /spec/models/ and /spec/helper folder and write unit tests for each method in due_date.rb and deadline_helper.rb.

== '''Current Implementation''' ==
DueDate is a Model class to manage the deadlines of an assignment. It has methods for setting due dates for an assignment, copying due dates from one assignment to a new assignment etc. DeadlineHelper provides helper functions that help DueDate perform certain tasks. The assignment focuses on refactoring some of the methods based on warnings received from Code Climate's static analysis and modifying the language to make it more Ruby-friendly. The assignment also involves writing unit test cases for due_date.rb and deadline_helper.rb in order to increase test coverage.

The goal of this project is to attempt to make this part of the application easier to read and write unit test cases that the application must pass.

== '''Changed Implementation''' ==
Changes implemented involves refactoring the code and making it more understandable by adding comments in the code.

The modified files are
* due_date.rb (path: /app/models)
* deadline_helper.rb (path: /app/helpers)
Testing files
* due_date_spec.rb (path: /spec/models)
* deadline_helper_spec.rb (path: /spec/helpers)

=== due_date.rb ===
* Converted for..in loop to object.each in order to follow better Ruby syntax.
* Unnecessary assignment to sorted_deadlines removed.
* Nested ternary operators have been changed to if..else in order to make it more readable.
[[File:Duedaterb.png]]
* Changed where(...).first to find_by(...) which is the newer recommended syntax.
* Corrected the Time.now functions by adding the correct zones to them such as Time.zone.now.
* Removed trailing whitespaces.
[[File:DueDaterb2.png]]

=== deadline_helper.rb ===
* Time functions were changed to functions with zones
* Extra line removed
[[File:Deadlinehelper.png]]

== '''RSpec testing''' ==
There were no existing tests for the functions in due_date.rb and deadline_helper.rb. We have added exhaustive set of RSpec tests to test all the code. We have added two new spec files 'due_date_spec.rb' and ‘deadline_helper_spec.rb’ which cover the testing scenarios for the functions in ‘due_date.rb’ and ‘deadline_helper.rb’.

For both of these two files, all Travis CI<ref>http://www.travis-ci.com</ref> test cases have passed for all previous test cases as well as the ones added by us with the test coverage for the files due_date.rb and deadline_helper.rb reported as 100%.

These RSpec files have 100% code coverage visible at: /coverage/index.html.

=== due_date_spec.rb ===
This file is located at spec/models and tests the functionalities of the due_date.rb file located in app/models. There are 18 test cases in total which are listed below.
* If the factory is successfully able to build the due_date objects.
<pre>
it "due date factory created successfully" do
expect(@assignment_due_date).to be_valid
end
</pre>
<pre>
it "due dates created correctly" do
expect(@due_dates.length).to be == 10
end
</pre>
* If the function "set_flag" successfully sets the due_date flag.
<pre>
it "due date flag is set" do
expect(@assignment_due_date.flag).to be false
@assignment_due_date.set_flag
expect(@assignment_due_date.flag).to be true
end
</pre>
* If the function "due_at_is_valid_datetime" returns nil (no errors) for a valid datetime in due_at (no invalid test cases can be added here because model does not allow invalid datetime to be set at all).
<pre>
it "due at is valid datetime" do
expect(@assignment_due_date.due_at_is_valid_datetime).to be nil
end
</pre>
* If the function "self.copy" is able to copy due dates from one assignment to another.
<pre>
it "copy due dates to new assignment" do
new_assignment_id = build(:assignment, id: 999).id
old_assignment_id = @assignment_due_date.assignment.id
DueDate.copy(old_assignment_id, new_assignment_id)
expect(DueDate.where(parent_id: new_assignment_id).count).to eql DueDate.where(parent_id: old_assignment_id).count
end
</pre>
* If the function "self.set_duedate" is able to create another due date by copying data from an existing due date object.
<pre>
it "create new duedate record with values" do
DueDate.set_duedate({id: 999}, @assignment_due_date.deadline_type_id,
@assignment_due_date.parent_id, @assignment_due_date.round)
new_due_date = DueDate.find_by(id: 999)
expect(new_due_date).to be_valid
expect(new_due_date.deadline_type_id).to eql @assignment_due_date.deadline_type_id
expect(new_due_date.parent_id).to eql @assignment_due_date.parent_id
expect(new_due_date.round).to eql @assignment_due_date.round
end
</pre>
* If the function "self.deadline_sort" is able to sort the due dates in ascending order.
<pre>
it "sort duedate records" do
sorted_due_dates = @due_dates
expect(sorted_due_dates.each_cons(2).all?{|m1, m2| (m1.due_at <=> m2.due_at) != 1}).to eql false

sorted_due_dates = DueDate.deadline_sort(@due_dates)
expect(sorted_due_dates.each_cons(2).all?{|m1, m2| (m1.due_at <=> m2.due_at) != 1}).to eql true
end
</pre>
* If the function "self.done_in_assignment_round" returns the correct number of rounds for specific inputs. This involves an invalid test case as well for 0 rounds.
<pre>
describe "#done_in_assignment_round" do
it "return 0 when no response map" do
response = ReviewResponseMap.create
response.type = "ResponseMap"
response.save
expect(DueDate.done_in_assignment_round(1, response)).to eql 0
end

it "return round 1 for single round" do
response = ReviewResponseMap.create
expect(DueDate.done_in_assignment_round(@assignment_due_date.parent_id, response)).to eql 1
end
end
</pre>
* If the function "self.get_next_due_date" works as expected. This involves several invalid test cases as well.
<pre>
describe "#get_next_due_date" do
it "no subsequent due date" do
expect(DueDate.get_next_due_date(@assignment_due_date.parent_id)).to be nil
end

it "nil value throws exception" do
expect { DueDate.get_next_due_date(nil) }.to raise_exception(ActiveRecord::RecordNotFound)
end

it "get next assignment due date" do
due_date = create(:assignment_due_date, deadline_type: @deadline_type,
submission_allowed_id: @deadline_right.id, review_allowed_id: @deadline_right.id,
review_of_review_allowed_id: @deadline_right.id, due_at: Time.zone.now + 5000)
expect(DueDate.get_next_due_date(due_date.parent_id)).to be_valid
end

it "get next due date from topic for staggered deadline" do
assignment_id = create(:assignment, staggered_deadline: true, name: "testassignment").id
due_date = create(:topic_due_date, deadline_type: @deadline_type,
submission_allowed_id: @deadline_right.id, review_allowed_id: @deadline_right.id,
review_of_review_allowed_id: @deadline_right.id, due_at: Time.zone.now + 5000, parent_id: assignment_id)
expect(DueDate.get_next_due_date(assignment_id, due_date.parent_id)).to be_valid
end

it "next due date does not exist for staggered deadline" do
assignment_id = create(:assignment, staggered_deadline: true, name: "testassignment").id
due_date = create(:topic_due_date, deadline_type: @deadline_type,
submission_allowed_id: @deadline_right, review_allowed_id: @deadline_right,
review_of_review_allowed_id: @deadline_right, due_at: Time.zone.now + 5000, parent_id: assignment_id)
expect(DueDate.get_next_due_date(assignment_id)).to be nil
end

it "next due date is before Time.now for staggered deadline" do
assignment_id = create(:assignment, staggered_deadline: true, name: "testassignment").id
due_date = create(:topic_due_date, deadline_type: @deadline_type,
submission_allowed_id: @deadline_right, review_allowed_id: @deadline_right,
review_of_review_allowed_id: @deadline_right, due_at: Time.zone.now - 5000, parent_id: assignment_id)
expect(DueDate.get_next_due_date(assignment_id, due_date.parent_id)).to be nil
end

it "get next due date from assignment for staggered deadline" do
assignment_id = create(:assignment, staggered_deadline: true, name: "testassignment").id
due_date = create(:assignment_due_date, deadline_type: @deadline_type,
submission_allowed_id: @deadline_right, review_allowed_id: @deadline_right,
review_of_review_allowed_id: @deadline_right, due_at: Time.zone.now + 5000, parent_id: assignment_id)
expect(DueDate.get_next_due_date(assignment_id)).to be_valid
end
end
</pre>
* If the function "self.default_permission" returns the correct default permissions for particular deadline and permission types.
<pre>
it "metareview review_of_review_allowed default permission OK" do
expect(DueDate.default_permission('metareview', 'review_of_review_allowed')).to be == DeadlineRight::OK
end
</pre>
<pre>
it "review submission_allowed default permission NO" do
expect(DueDate.default_permission('review', 'submission_allowed')).to be == DeadlineRight::NO
end
</pre>
To test this file run the following command:
<pre>
rspec spec/models/due_date_spec.rb
</pre>
The output of this RSpec file is present in below screenshot:
[[File:Duedaterspec.png]]

Code coverage details of the above RSpec files is present in below screenshot:
[[File:Duedatecoverage.png]]

=== deadline_helper_spec.rb ===
This is a test file for testing the functionalities of Deadline_helper.rb file located at app/helpers. Different test cases present in this file are:
* Check if the factory<ref>http://www.semaphoreci.com|access-date</ref> is valid:
<pre>
it "has a valid factory" do
factory = FactoryGirl.build(:topic_due_date)
expect(factory).to be_valid
end
</pre>
* Fail if the due date is invalid:
<pre>
it "should fail because of invalid due_date" do
expect { DeadlineHelper.create_topic_deadline(nil, 0, 0)}.to raise_exception(NoMethodError)
end
</pre>
* If new due_date object is created:
<pre>
it "new due_date object created" do
DeadlineHelper.create_topic_deadline(@topic_due_date, 0, 1)
expect(TopicDueDate.count).to be == 2
end
</pre>
* due_at should be same for 0 offset:
<pre>
it "due_at should be same for 0 offset" do
DeadlineHelper.create_topic_deadline(@topic_due_date, 0, 10)
new_due_date = TopicDueDate.find_by(parent_id: 10)
expect(new_due_date).to be_valid
expect(new_due_date.due_at.to_s).to be == @topic_due_date.due_at.to_s
end
</pre>
* due_at is calculated correctly if offset is positive:
<pre>
it "due_at calculated correctly for positive offset" do
DeadlineHelper.create_topic_deadline(@topic_due_date, 5000, 10)
new_due_date = TopicDueDate.find_by(parent_id: 10)
expect(new_due_date).to be_valid
expect(new_due_date.due_at.to_s).to be == (Time.zone.parse(@topic_due_date.due_at.to_s) + 5000).to_s
end
</pre>
* due_at is calculated correctly if offset is negative:
<pre>
it "due_at calculated correctly for negative offset" do
DeadlineHelper.create_topic_deadline(@topic_due_date, -5000, 10)
new_due_date = TopicDueDate.find_by(parent_id: 10)
expect(new_due_date).to be_valid
expect(new_due_date.due_at.to_s).to be == (Time.zone.parse(@topic_due_date.due_at.to_s) - 5000).to_s
end
</pre>
* The offset is being converted to integer properly:
<pre>
it "offset converted to integer correctly" do
DeadlineHelper.create_topic_deadline(@topic_due_date, 5000.15, 10)
new_due_date = TopicDueDate.find_by(parent_id: 10)
expect(new_due_date).to be_valid
expect(new_due_date.due_at.to_s).to be == (Time.zone.parse(@topic_due_date.due_at.to_s) + 5000).to_s
end
</pre>
To test this file run the following command:
<pre>
rspec spec/models/deadline_helper_spec.rb
</pre>
The output of this RSpec file is present in below screenshot:
[[File:Deadlinerspec.png]]

Code coverage details of the above RSpec files is present in below screenshot:
[[File:Deadlinecoverage.png]]

== '''Testing The System''' ==
Run the following commands to test the new RSpec files created:
* rspec spec/models/deadline_helper_spec.rb
* rspec spec/models/due_date_spec.rb

== '''UI Testing''' ==
* How to test creation of new assignment with due dates using UI:
[https://www.youtube.com/watch?v=zJILRQpSgn4]

==References==
<references/>

CSC/ECE 517 Fall 2016/E1634. Refactor and write unit test of due date.rb and deadline helper.rb

2016-11-05T02:52:54Z

Aagrawa6: /* UI Testing */

== '''Introduction''' ==

=== Expertiza ===
Expertiza<ref>https://expertiza.ncsu.edu/</ref> is an open source project for school assignment management for instructors and students based on the Ruby on Rails<ref>http://www.rubyonrails.org</ref> framework. Expertiza allows the instructor to create new assignments and customise new or existing assignments. It also allows the instructor to create a list of topics the students can sign up for. Students can form teams in Expertiza to work on various projects and assignments. Students can also peer review other students' submissions. Expertiza supports submission across various document types, including the URLs and word documents. Expertiza provides a dashboard for all the assignments corresponding to a course and provides absolute control to the Instructors and Teaching Assistants. In addition to assignments, it encompasses peer reviews wherein participants are allowed to provide feedback anonymously about each other's work thereby providing scope for the better outcome. The due_date.rb file is responsible for informing the users about the deadline for submission of the each assignment. Due dates in Expertiza have their association with many other components like assignments, reviews etc.

=== Code Climate ===
Code Climate<ref>https://codeclimate.com/dashboard</ref> is a tool that runs static analysis on a GitHub project and outputs many details like test coverage, complexity, duplication, security, style, and more. There is a Google Chrome extension to integrate the Code Climate results generated directly into GitHub which is visible when browsing the repository on the browser. It allows us to see issues displayed directly inside GitHub's UI, to review which lines are covered in diffs and files, and add repositories and open tickets without changing your workflow.

== '''Tasks Identified''' ==
To install Code climate Chrome Extension that highlights the duplicated code.

To refactor the following two files:
* due_date.rb
** Ternary operators must not be nested. Prefer `if` or `else` constructs instead.
** Useless assignment to variable - `sorted_deadlines`.
** Prefer `each` over `for`.
** Use `find_by` instead of `where.first`.
** Correct the use of Time function
* deadline_helper.rb
** Do not use `Time.now` without zone. Use one of `Time.zone.now`, `Time.current`, `Time.now.in_time_zone`, `Time.now.utc`, `Time.now.getlocal`, `Time.now.iso8601`, `Time.now.jisx0301`, `Time.now.rfc3339`, `Time.now.to_i`, `Time.now.to_f` instead.
** Trailing whitespace detected.
** Extra empty line detected at module body end.

* Create respective RSpec<ref>http://www.rspec.info</ref> files in /spec/models/ and /spec/helper folder and write unit tests for each method in due_date.rb and deadline_helper.rb.

== '''Current Implementation''' ==
DueDate is a Model class to manage the deadlines of an assignment. It has methods for setting due dates for an assignment, copying due dates from one assignment to a new assignment etc. DeadlineHelper provides helper functions that help DueDate perform certain tasks. The assignment focuses on refactoring some of the methods based on warnings received from Code Climate's static analysis and modifying the language to make it more Ruby-friendly. The assignment also involves writing unit test cases for due_date.rb and deadline_helper.rb in order to increase test coverage.

The goal of this project is to attempt to make this part of the application easier to read and write unit test cases that the application must pass.

== '''Changed Implementation''' ==
Changes implemented involves refactoring the code and making it more understandable by adding comments in the code.

The modified files are
* due_date.rb (path: /app/models)
* deadline_helper.rb (path: /app/helpers)
Testing files
* due_date_spec.rb (path: /spec/models)
* deadline_helper_spec.rb (path: /spec/helpers)

=== due_date.rb ===
* Converted for..in loop to object.each in order to follow better Ruby syntax.
* Unnecessary assignment to sorted_deadlines removed.
* Nested ternary operators have been changed to if..else in order to make it more readable.
[[File:Duedaterb.png]]
* Changed where(...).first to find_by(...) which is the newer recommended syntax.
* Corrected the Time.now functions by adding the correct zones to them such as Time.zone.now.
* Removed trailing whitespaces.
[[File:DueDaterb2.png]]

=== deadline_helper.rb ===
* Time functions were changed to functions with zones
* Extra line removed
[[File:Deadlinehelper.png]]

== '''RSpec testing''' ==
There were no existing tests for the functions in due_date.rb and deadline_helper.rb. We have added exhaustive set of RSpec tests to test all the code. We have added two new spec files 'due_date_spec.rb' and ‘deadline_helper_spec.rb’ which cover the testing scenarios for the functions in ‘due_date.rb’ and ‘deadline_helper.rb’.

For both of these two files, all Travis CI<ref>http://www.travis-ci.com</ref> test cases have passed for all previous test cases as well as the ones added by us with the test coverage for the files due_date.rb and deadline_helper.rb reported as 100%.

These RSpec files have 100% code coverage visible at: /coverage/index.html.

=== due_date_spec.rb ===
This file is located at spec/models and tests the functionalities of the due_date.rb file located in app/models. There are 18 test cases in total which are listed below.
* If the factory is successfully able to build the due_date objects.
<pre>
it "due date factory created successfully" do
expect(@assignment_due_date).to be_valid
end
</pre>
<pre>
it "due dates created correctly" do
expect(@due_dates.length).to be == 10
end
</pre>
* If the function "set_flag" successfully sets the due_date flag.
<pre>
it "due date flag is set" do
expect(@assignment_due_date.flag).to be false
@assignment_due_date.set_flag
expect(@assignment_due_date.flag).to be true
end
</pre>
* If the function "due_at_is_valid_datetime" returns nil (no errors) for a valid datetime in due_at (no invalid test cases can be added here because model does not allow invalid datetime to be set at all).
<pre>
it "due at is valid datetime" do
expect(@assignment_due_date.due_at_is_valid_datetime).to be nil
end
</pre>
* If the function "self.copy" is able to copy due dates from one assignment to another.
<pre>
it "copy due dates to new assignment" do
new_assignment_id = build(:assignment, id: 999).id
old_assignment_id = @assignment_due_date.assignment.id
DueDate.copy(old_assignment_id, new_assignment_id)
expect(DueDate.where(parent_id: new_assignment_id).count).to eql DueDate.where(parent_id: old_assignment_id).count
end
</pre>
* If the function "self.set_duedate" is able to create another due date by copying data from an existing due date object.
<pre>
it "create new duedate record with values" do
DueDate.set_duedate({id: 999}, @assignment_due_date.deadline_type_id,
@assignment_due_date.parent_id, @assignment_due_date.round)
new_due_date = DueDate.find_by(id: 999)
expect(new_due_date).to be_valid
expect(new_due_date.deadline_type_id).to eql @assignment_due_date.deadline_type_id
expect(new_due_date.parent_id).to eql @assignment_due_date.parent_id
expect(new_due_date.round).to eql @assignment_due_date.round
end
</pre>
* If the function "self.deadline_sort" is able to sort the due dates in ascending order.
<pre>
it "sort duedate records" do
sorted_due_dates = @due_dates
expect(sorted_due_dates.each_cons(2).all?{|m1, m2| (m1.due_at <=> m2.due_at) != 1}).to eql false

sorted_due_dates = DueDate.deadline_sort(@due_dates)
expect(sorted_due_dates.each_cons(2).all?{|m1, m2| (m1.due_at <=> m2.due_at) != 1}).to eql true
end
</pre>
* If the function "self.done_in_assignment_round" returns the correct number of rounds for specific inputs. This involves an invalid test case as well for 0 rounds.
<pre>
describe "#done_in_assignment_round" do
it "return 0 when no response map" do
response = ReviewResponseMap.create
response.type = "ResponseMap"
response.save
expect(DueDate.done_in_assignment_round(1, response)).to eql 0
end

it "return round 1 for single round" do
response = ReviewResponseMap.create
expect(DueDate.done_in_assignment_round(@assignment_due_date.parent_id, response)).to eql 1
end
end
</pre>
* If the function "self.get_next_due_date" works as expected. This involves several invalid test cases as well.
<pre>
describe "#get_next_due_date" do
it "no subsequent due date" do
expect(DueDate.get_next_due_date(@assignment_due_date.parent_id)).to be nil
end

it "nil value throws exception" do
expect { DueDate.get_next_due_date(nil) }.to raise_exception(ActiveRecord::RecordNotFound)
end

it "get next assignment due date" do
due_date = create(:assignment_due_date, deadline_type: @deadline_type,
submission_allowed_id: @deadline_right.id, review_allowed_id: @deadline_right.id,
review_of_review_allowed_id: @deadline_right.id, due_at: Time.zone.now + 5000)
expect(DueDate.get_next_due_date(due_date.parent_id)).to be_valid
end

it "get next due date from topic for staggered deadline" do
assignment_id = create(:assignment, staggered_deadline: true, name: "testassignment").id
due_date = create(:topic_due_date, deadline_type: @deadline_type,
submission_allowed_id: @deadline_right.id, review_allowed_id: @deadline_right.id,
review_of_review_allowed_id: @deadline_right.id, due_at: Time.zone.now + 5000, parent_id: assignment_id)
expect(DueDate.get_next_due_date(assignment_id, due_date.parent_id)).to be_valid
end

it "next due date does not exist for staggered deadline" do
assignment_id = create(:assignment, staggered_deadline: true, name: "testassignment").id
due_date = create(:topic_due_date, deadline_type: @deadline_type,
submission_allowed_id: @deadline_right, review_allowed_id: @deadline_right,
review_of_review_allowed_id: @deadline_right, due_at: Time.zone.now + 5000, parent_id: assignment_id)
expect(DueDate.get_next_due_date(assignment_id)).to be nil
end

it "next due date is before Time.now for staggered deadline" do
assignment_id = create(:assignment, staggered_deadline: true, name: "testassignment").id
due_date = create(:topic_due_date, deadline_type: @deadline_type,
submission_allowed_id: @deadline_right, review_allowed_id: @deadline_right,
review_of_review_allowed_id: @deadline_right, due_at: Time.zone.now - 5000, parent_id: assignment_id)
expect(DueDate.get_next_due_date(assignment_id, due_date.parent_id)).to be nil
end

it "get next due date from assignment for staggered deadline" do
assignment_id = create(:assignment, staggered_deadline: true, name: "testassignment").id
due_date = create(:assignment_due_date, deadline_type: @deadline_type,
submission_allowed_id: @deadline_right, review_allowed_id: @deadline_right,
review_of_review_allowed_id: @deadline_right, due_at: Time.zone.now + 5000, parent_id: assignment_id)
expect(DueDate.get_next_due_date(assignment_id)).to be_valid
end
end
</pre>
* If the function "self.default_permission" returns the correct default permissions for particular deadline and permission types.
<pre>
it "metareview review_of_review_allowed default permission OK" do
expect(DueDate.default_permission('metareview', 'review_of_review_allowed')).to be == DeadlineRight::OK
end
</pre>
<pre>
it "review submission_allowed default permission NO" do
expect(DueDate.default_permission('review', 'submission_allowed')).to be == DeadlineRight::NO
end
</pre>
To test this file run the following command:
<pre>
rspec spec/models/due_date_spec.rb
</pre>
The output of this RSpec file is present in below screenshot:
[[File:Duedaterspec.png]]

Code coverage details of the above RSpec files is present in below screenshot:
[[File:Duedatecoverage.png]]

=== deadline_helper_spec.rb ===
This is a test file for testing the functionalities of Deadline_helper.rb file located at app/helpers. Different test cases present in this file are:
* Check if the factory<ref>http://www.semaphoreci.com|access-date</ref> is valid:
<pre>
it "has a valid factory" do
factory = FactoryGirl.build(:topic_due_date)
expect(factory).to be_valid
end
</pre>
* Fail if the due date is invalid:
<pre>
it "should fail because of invalid due_date" do
expect { DeadlineHelper.create_topic_deadline(nil, 0, 0)}.to raise_exception(NoMethodError)
end
</pre>
* If new due_date object is created:
<pre>
it "new due_date object created" do
DeadlineHelper.create_topic_deadline(@topic_due_date, 0, 1)
expect(TopicDueDate.count).to be == 2
end
</pre>
* due_at should be same for 0 offset:
<pre>
it "due_at should be same for 0 offset" do
DeadlineHelper.create_topic_deadline(@topic_due_date, 0, 10)
new_due_date = TopicDueDate.find_by(parent_id: 10)
expect(new_due_date).to be_valid
expect(new_due_date.due_at.to_s).to be == @topic_due_date.due_at.to_s
end
</pre>
* due_at is calculated correctly if offset is positive:
<pre>
it "due_at calculated correctly for positive offset" do
DeadlineHelper.create_topic_deadline(@topic_due_date, 5000, 10)
new_due_date = TopicDueDate.find_by(parent_id: 10)
expect(new_due_date).to be_valid
expect(new_due_date.due_at.to_s).to be == (Time.zone.parse(@topic_due_date.due_at.to_s) + 5000).to_s
end
</pre>
* due_at is calculated correctly if offset is negative:
<pre>
it "due_at calculated correctly for negative offset" do
DeadlineHelper.create_topic_deadline(@topic_due_date, -5000, 10)
new_due_date = TopicDueDate.find_by(parent_id: 10)
expect(new_due_date).to be_valid
expect(new_due_date.due_at.to_s).to be == (Time.zone.parse(@topic_due_date.due_at.to_s) - 5000).to_s
end
</pre>
* The offset is being converted to integer properly:
<pre>
it "offset converted to integer correctly" do
DeadlineHelper.create_topic_deadline(@topic_due_date, 5000.15, 10)
new_due_date = TopicDueDate.find_by(parent_id: 10)
expect(new_due_date).to be_valid
expect(new_due_date.due_at.to_s).to be == (Time.zone.parse(@topic_due_date.due_at.to_s) + 5000).to_s
end
</pre>
To test this file run the following command:
<pre>
rspec spec/models/deadline_helper_spec.rb
</pre>
The output of this RSpec file is present in below screenshot:
[[File:Deadlinerspec.png]]

Code coverage details of the above RSpec files is present in below screenshot:
[[File:Deadlinecoverage.png]]

== '''Testing The System''' ==
Run the following commands to test the new RSpec files created:
* rspec spec/models/deadline_helper_spec.rb
* rspec spec/models/due_date_spec.rb

[http://www.example.com link title]== '''UI Testing''' ==
* How to test creation of new assignment with due dates using UI:
[https://www.youtube.com/watch?v=zJILRQpSgn4]

==References==
<references/>

CSC/ECE 517 Fall 2016/E1634. Refactor and write unit test of due date.rb and deadline helper.rb

2016-11-05T02:52:16Z

Aagrawa6: Screencast

== '''Introduction''' ==

=== Expertiza ===
Expertiza<ref>https://expertiza.ncsu.edu/</ref> is an open source project for school assignment management for instructors and students based on the Ruby on Rails<ref>http://www.rubyonrails.org</ref> framework. Expertiza allows the instructor to create new assignments and customise new or existing assignments. It also allows the instructor to create a list of topics the students can sign up for. Students can form teams in Expertiza to work on various projects and assignments. Students can also peer review other students' submissions. Expertiza supports submission across various document types, including the URLs and word documents. Expertiza provides a dashboard for all the assignments corresponding to a course and provides absolute control to the Instructors and Teaching Assistants. In addition to assignments, it encompasses peer reviews wherein participants are allowed to provide feedback anonymously about each other's work thereby providing scope for the better outcome. The due_date.rb file is responsible for informing the users about the deadline for submission of the each assignment. Due dates in Expertiza have their association with many other components like assignments, reviews etc.

=== Code Climate ===
Code Climate<ref>https://codeclimate.com/dashboard</ref> is a tool that runs static analysis on a GitHub project and outputs many details like test coverage, complexity, duplication, security, style, and more. There is a Google Chrome extension to integrate the Code Climate results generated directly into GitHub which is visible when browsing the repository on the browser. It allows us to see issues displayed directly inside GitHub's UI, to review which lines are covered in diffs and files, and add repositories and open tickets without changing your workflow.

== '''Tasks Identified''' ==
To install Code climate Chrome Extension that highlights the duplicated code.

To refactor the following two files:
* due_date.rb
** Ternary operators must not be nested. Prefer `if` or `else` constructs instead.
** Useless assignment to variable - `sorted_deadlines`.
** Prefer `each` over `for`.
** Use `find_by` instead of `where.first`.
** Correct the use of Time function
* deadline_helper.rb
** Do not use `Time.now` without zone. Use one of `Time.zone.now`, `Time.current`, `Time.now.in_time_zone`, `Time.now.utc`, `Time.now.getlocal`, `Time.now.iso8601`, `Time.now.jisx0301`, `Time.now.rfc3339`, `Time.now.to_i`, `Time.now.to_f` instead.
** Trailing whitespace detected.
** Extra empty line detected at module body end.

* Create respective RSpec<ref>http://www.rspec.info</ref> files in /spec/models/ and /spec/helper folder and write unit tests for each method in due_date.rb and deadline_helper.rb.

== '''Current Implementation''' ==
DueDate is a Model class to manage the deadlines of an assignment. It has methods for setting due dates for an assignment, copying due dates from one assignment to a new assignment etc. DeadlineHelper provides helper functions that help DueDate perform certain tasks. The assignment focuses on refactoring some of the methods based on warnings received from Code Climate's static analysis and modifying the language to make it more Ruby-friendly. The assignment also involves writing unit test cases for due_date.rb and deadline_helper.rb in order to increase test coverage.

The goal of this project is to attempt to make this part of the application easier to read and write unit test cases that the application must pass.

== '''Changed Implementation''' ==
Changes implemented involves refactoring the code and making it more understandable by adding comments in the code.

The modified files are
* due_date.rb (path: /app/models)
* deadline_helper.rb (path: /app/helpers)
Testing files
* due_date_spec.rb (path: /spec/models)
* deadline_helper_spec.rb (path: /spec/helpers)

=== due_date.rb ===
* Converted for..in loop to object.each in order to follow better Ruby syntax.
* Unnecessary assignment to sorted_deadlines removed.
* Nested ternary operators have been changed to if..else in order to make it more readable.
[[File:Duedaterb.png]]
* Changed where(...).first to find_by(...) which is the newer recommended syntax.
* Corrected the Time.now functions by adding the correct zones to them such as Time.zone.now.
* Removed trailing whitespaces.
[[File:DueDaterb2.png]]

=== deadline_helper.rb ===
* Time functions were changed to functions with zones
* Extra line removed
[[File:Deadlinehelper.png]]

== '''RSpec testing''' ==
There were no existing tests for the functions in due_date.rb and deadline_helper.rb. We have added exhaustive set of RSpec tests to test all the code. We have added two new spec files 'due_date_spec.rb' and ‘deadline_helper_spec.rb’ which cover the testing scenarios for the functions in ‘due_date.rb’ and ‘deadline_helper.rb’.

For both of these two files, all Travis CI<ref>http://www.travis-ci.com</ref> test cases have passed for all previous test cases as well as the ones added by us with the test coverage for the files due_date.rb and deadline_helper.rb reported as 100%.

These RSpec files have 100% code coverage visible at: /coverage/index.html.

=== due_date_spec.rb ===
This file is located at spec/models and tests the functionalities of the due_date.rb file located in app/models. There are 18 test cases in total which are listed below.
* If the factory is successfully able to build the due_date objects.
<pre>
it "due date factory created successfully" do
expect(@assignment_due_date).to be_valid
end
</pre>
<pre>
it "due dates created correctly" do
expect(@due_dates.length).to be == 10
end
</pre>
* If the function "set_flag" successfully sets the due_date flag.
<pre>
it "due date flag is set" do
expect(@assignment_due_date.flag).to be false
@assignment_due_date.set_flag
expect(@assignment_due_date.flag).to be true
end
</pre>
* If the function "due_at_is_valid_datetime" returns nil (no errors) for a valid datetime in due_at (no invalid test cases can be added here because model does not allow invalid datetime to be set at all).
<pre>
it "due at is valid datetime" do
expect(@assignment_due_date.due_at_is_valid_datetime).to be nil
end
</pre>
* If the function "self.copy" is able to copy due dates from one assignment to another.
<pre>
it "copy due dates to new assignment" do
new_assignment_id = build(:assignment, id: 999).id
old_assignment_id = @assignment_due_date.assignment.id
DueDate.copy(old_assignment_id, new_assignment_id)
expect(DueDate.where(parent_id: new_assignment_id).count).to eql DueDate.where(parent_id: old_assignment_id).count
end
</pre>
* If the function "self.set_duedate" is able to create another due date by copying data from an existing due date object.
<pre>
it "create new duedate record with values" do
DueDate.set_duedate({id: 999}, @assignment_due_date.deadline_type_id,
@assignment_due_date.parent_id, @assignment_due_date.round)
new_due_date = DueDate.find_by(id: 999)
expect(new_due_date).to be_valid
expect(new_due_date.deadline_type_id).to eql @assignment_due_date.deadline_type_id
expect(new_due_date.parent_id).to eql @assignment_due_date.parent_id
expect(new_due_date.round).to eql @assignment_due_date.round
end
</pre>
* If the function "self.deadline_sort" is able to sort the due dates in ascending order.
<pre>
it "sort duedate records" do
sorted_due_dates = @due_dates
expect(sorted_due_dates.each_cons(2).all?{|m1, m2| (m1.due_at <=> m2.due_at) != 1}).to eql false

sorted_due_dates = DueDate.deadline_sort(@due_dates)
expect(sorted_due_dates.each_cons(2).all?{|m1, m2| (m1.due_at <=> m2.due_at) != 1}).to eql true
end
</pre>
* If the function "self.done_in_assignment_round" returns the correct number of rounds for specific inputs. This involves an invalid test case as well for 0 rounds.
<pre>
describe "#done_in_assignment_round" do
it "return 0 when no response map" do
response = ReviewResponseMap.create
response.type = "ResponseMap"
response.save
expect(DueDate.done_in_assignment_round(1, response)).to eql 0
end

it "return round 1 for single round" do
response = ReviewResponseMap.create
expect(DueDate.done_in_assignment_round(@assignment_due_date.parent_id, response)).to eql 1
end
end
</pre>
* If the function "self.get_next_due_date" works as expected. This involves several invalid test cases as well.
<pre>
describe "#get_next_due_date" do
it "no subsequent due date" do
expect(DueDate.get_next_due_date(@assignment_due_date.parent_id)).to be nil
end

it "nil value throws exception" do
expect { DueDate.get_next_due_date(nil) }.to raise_exception(ActiveRecord::RecordNotFound)
end

it "get next assignment due date" do
due_date = create(:assignment_due_date, deadline_type: @deadline_type,
submission_allowed_id: @deadline_right.id, review_allowed_id: @deadline_right.id,
review_of_review_allowed_id: @deadline_right.id, due_at: Time.zone.now + 5000)
expect(DueDate.get_next_due_date(due_date.parent_id)).to be_valid
end

it "get next due date from topic for staggered deadline" do
assignment_id = create(:assignment, staggered_deadline: true, name: "testassignment").id
due_date = create(:topic_due_date, deadline_type: @deadline_type,
submission_allowed_id: @deadline_right.id, review_allowed_id: @deadline_right.id,
review_of_review_allowed_id: @deadline_right.id, due_at: Time.zone.now + 5000, parent_id: assignment_id)
expect(DueDate.get_next_due_date(assignment_id, due_date.parent_id)).to be_valid
end

it "next due date does not exist for staggered deadline" do
assignment_id = create(:assignment, staggered_deadline: true, name: "testassignment").id
due_date = create(:topic_due_date, deadline_type: @deadline_type,
submission_allowed_id: @deadline_right, review_allowed_id: @deadline_right,
review_of_review_allowed_id: @deadline_right, due_at: Time.zone.now + 5000, parent_id: assignment_id)
expect(DueDate.get_next_due_date(assignment_id)).to be nil
end

it "next due date is before Time.now for staggered deadline" do
assignment_id = create(:assignment, staggered_deadline: true, name: "testassignment").id
due_date = create(:topic_due_date, deadline_type: @deadline_type,
submission_allowed_id: @deadline_right, review_allowed_id: @deadline_right,
review_of_review_allowed_id: @deadline_right, due_at: Time.zone.now - 5000, parent_id: assignment_id)
expect(DueDate.get_next_due_date(assignment_id, due_date.parent_id)).to be nil
end

it "get next due date from assignment for staggered deadline" do
assignment_id = create(:assignment, staggered_deadline: true, name: "testassignment").id
due_date = create(:assignment_due_date, deadline_type: @deadline_type,
submission_allowed_id: @deadline_right, review_allowed_id: @deadline_right,
review_of_review_allowed_id: @deadline_right, due_at: Time.zone.now + 5000, parent_id: assignment_id)
expect(DueDate.get_next_due_date(assignment_id)).to be_valid
end
end
</pre>
* If the function "self.default_permission" returns the correct default permissions for particular deadline and permission types.
<pre>
it "metareview review_of_review_allowed default permission OK" do
expect(DueDate.default_permission('metareview', 'review_of_review_allowed')).to be == DeadlineRight::OK
end
</pre>
<pre>
it "review submission_allowed default permission NO" do
expect(DueDate.default_permission('review', 'submission_allowed')).to be == DeadlineRight::NO
end
</pre>
To test this file run the following command:
<pre>
rspec spec/models/due_date_spec.rb
</pre>
The output of this RSpec file is present in below screenshot:
[[File:Duedaterspec.png]]

Code coverage details of the above RSpec files is present in below screenshot:
[[File:Duedatecoverage.png]]

=== deadline_helper_spec.rb ===
This is a test file for testing the functionalities of Deadline_helper.rb file located at app/helpers. Different test cases present in this file are:
* Check if the factory<ref>http://www.semaphoreci.com|access-date</ref> is valid:
<pre>
it "has a valid factory" do
factory = FactoryGirl.build(:topic_due_date)
expect(factory).to be_valid
end
</pre>
* Fail if the due date is invalid:
<pre>
it "should fail because of invalid due_date" do
expect { DeadlineHelper.create_topic_deadline(nil, 0, 0)}.to raise_exception(NoMethodError)
end
</pre>
* If new due_date object is created:
<pre>
it "new due_date object created" do
DeadlineHelper.create_topic_deadline(@topic_due_date, 0, 1)
expect(TopicDueDate.count).to be == 2
end
</pre>
* due_at should be same for 0 offset:
<pre>
it "due_at should be same for 0 offset" do
DeadlineHelper.create_topic_deadline(@topic_due_date, 0, 10)
new_due_date = TopicDueDate.find_by(parent_id: 10)
expect(new_due_date).to be_valid
expect(new_due_date.due_at.to_s).to be == @topic_due_date.due_at.to_s
end
</pre>
* due_at is calculated correctly if offset is positive:
<pre>
it "due_at calculated correctly for positive offset" do
DeadlineHelper.create_topic_deadline(@topic_due_date, 5000, 10)
new_due_date = TopicDueDate.find_by(parent_id: 10)
expect(new_due_date).to be_valid
expect(new_due_date.due_at.to_s).to be == (Time.zone.parse(@topic_due_date.due_at.to_s) + 5000).to_s
end
</pre>
* due_at is calculated correctly if offset is negative:
<pre>
it "due_at calculated correctly for negative offset" do
DeadlineHelper.create_topic_deadline(@topic_due_date, -5000, 10)
new_due_date = TopicDueDate.find_by(parent_id: 10)
expect(new_due_date).to be_valid
expect(new_due_date.due_at.to_s).to be == (Time.zone.parse(@topic_due_date.due_at.to_s) - 5000).to_s
end
</pre>
* The offset is being converted to integer properly:
<pre>
it "offset converted to integer correctly" do
DeadlineHelper.create_topic_deadline(@topic_due_date, 5000.15, 10)
new_due_date = TopicDueDate.find_by(parent_id: 10)
expect(new_due_date).to be_valid
expect(new_due_date.due_at.to_s).to be == (Time.zone.parse(@topic_due_date.due_at.to_s) + 5000).to_s
end
</pre>
To test this file run the following command:
<pre>
rspec spec/models/deadline_helper_spec.rb
</pre>
The output of this RSpec file is present in below screenshot:
[[File:Deadlinerspec.png]]

Code coverage details of the above RSpec files is present in below screenshot:
[[File:Deadlinecoverage.png]]

== '''Testing The System''' ==
Run the following commands to test the new RSpec files created:
* rspec spec/models/deadline_helper_spec.rb
* rspec spec/models/due_date_spec.rb

== '''UI Testing''' ==
* How to test creation of new assignment with due dates using UI:
[[Media:https://www.youtube.com/watch?v=zJILRQpSgn4]]

==References==
<references/>

CSC/ECE 517 Fall 2016/E1634. Refactor and write unit test of due date.rb and deadline helper.rb

2016-11-05T01:10:46Z

Aagrawa6:

CSC/ECE 517 Fall 2016/E1634. Refactor and write unit test of due date.rb and deadline helper.rb

2016-11-05T01:10:21Z

Aagrawa6:

== '''Introduction''' ==

=== Expertiza ===
Expertiza<ref>https://expertiza.ncsu.edu/</ref> is an open source project for school assignment management for instructors and students based on the Ruby on Rails<ref>http://www.rubyonrails.org</ref> framework. Expertiza allows the instructor to create new assignments and customise new or existing assignments. It also allows the instructor to create a list of topics the students can sign up for. Students can form teams in Expertiza to work on various projects and assignments. Students can also peer review other students' submissions. Expertiza supports submission across various document types, including the URLs and word documents. Expertiza provides a dashboard for all the assignments corresponding to a course and provides absolute control to the Instructors and Teaching Assistants. In addition to assignments, it encompasses peer reviews wherein participants are allowed to provide feedback anonymously about each other's work thereby providing scope for the better outcome. The due_date.rb file is responsible for informing the users about the deadline for submission of the each assignment. Due dates in Expertiza have their association with many other components like assignments, reviews etc.

=== Code Climate ===
Code Climate<ref>https://codeclimate.com/dashboard</ref> is a tool that runs static analysis on a GitHub project and outputs many details like test coverage, complexity, duplication, security, style, and more. There is a Google Chrome extension to integrate the Code Climate results generated directly into GitHub which is visible when browsing the repository on the browser. It allows us to see issues displayed directly inside GitHub's UI, to review which lines are covered in diffs and files, and add repositories and open tickets without changing your workflow.

== '''Tasks Identified''' ==
To install Code climate Chrome Extension that highlights the duplicated code.

To refactor the following two files:
* due_date.rb
** Ternary operators must not be nested. Prefer `if` or `else` constructs instead.
** Useless assignment to variable - `sorted_deadlines`.
** Prefer `each` over `for`.
** Use `find_by` instead of `where.first`.
** Correct the use of Time function
* deadline_helper.rb
** Do not use `Time.now` without zone. Use one of `Time.zone.now`, `Time.current`, `Time.now.in_time_zone`, `Time.now.utc`, `Time.now.getlocal`, `Time.now.iso8601`, `Time.now.jisx0301`, `Time.now.rfc3339`, `Time.now.to_i`, `Time.now.to_f` instead.
** Trailing whitespace detected.
** Extra empty line detected at module body end.

* Create respective RSpec<ref>http://www.rspec.info</ref> files in /spec/models/ and /spec/helper folder and write unit tests for each method in due_date.rb and deadline_helper.rb.

== '''Current Implementation''' ==
DueDate is a Model class to manage the deadlines of an assignment. It has methods for setting due dates for an assignment, copying due dates from one assignment to a new assignment etc. DeadlineHelper provides helper functions that help DueDate perform certain tasks. The assignment focuses on refactoring some of the methods based on warnings received from Code Climate's static analysis and modifying the language to make it more Ruby-friendly. The assignment also involves writing unit test cases for due_date.rb and deadline_helper.rb in order to increase test coverage.

The goal of this project is to attempt to make this part of the application easier to read and write unit test cases that the application must pass.

== '''Changed Implementation''' ==
Changes implemented involves refactoring the code and making it more understandable by adding comments in the code.

The modified files are
* due_date.rb (path: /app/models)
* deadline_helper.rb (path: /app/helpers)
Testing files
* due_date_spec.rb (path: /spec/models)
* deadline_helper_spec.rb (path: /spec/helpers)

=== due_date.rb ===
* Converted for..in loop to object.each in order to follow better Ruby syntax.
* Unnecessary assignment to sorted_deadlines removed.
* Nested ternary operators have been changed to if..else in order to make it more readable.
[[File:Duedaterb.png]]
* Changed where(...).first to find_by(...) which is the newer recommended syntax.
* Corrected the Time.now functions by adding the correct zones to them such as Time.zone.now.
* Removed trailing whitespaces.
[[File:DueDaterb2.png]]

=== deadline_helper.rb ===
* Time functions were changed to functions with zones
* Extra line removed
[[File:Deadlinehelper.png]]

== '''RSpec testing''' ==
There were no existing tests for the functions in due_date.rb and deadline_helper.rb. We have added exhaustive set of RSpec tests to test all the code. We have added two new spec files 'due_date_spec.rb' and ‘deadline_helper_spec.rb’ which cover the testing scenarios for the functions in ‘due_date.rb’ and ‘deadline_helper.rb’.

For both of these two files, all Travis CI<ref>http://www.travis-ci.com</ref> test cases have passed for all previous test cases as well as the ones added by us with the test coverage for the files due_date.rb and deadline_helper.rb reported as 100%.

These RSpec files have 100% code coverage visible at: /coverage/index.html.

=== due_date_spec.rb ===
This file is located at spec/models and tests the functionalities of the due_date.rb file located in app/models. There are 18 test cases in total which are listed below.
* If the factory is successfully able to build the due_date objects.
<pre>
it "due date factory created successfully" do
expect(@assignment_due_date).to be_valid
end
</pre>
<pre>
it "due dates created correctly" do
expect(@due_dates.length).to be == 10
end
</pre>
* If the function "set_flag" successfully sets the due_date flag.
<pre>
it "due date flag is set" do
expect(@assignment_due_date.flag).to be false
@assignment_due_date.set_flag
expect(@assignment_due_date.flag).to be true
end
</pre>
* If the function "due_at_is_valid_datetime" returns nil (no errors) for a valid datetime in due_at (no invalid test cases can be added here because model does not allow invalid datetime to be set at all).
<pre>
it "due at is valid datetime" do
expect(@assignment_due_date.due_at_is_valid_datetime).to be nil
end
</pre>
* If the function "self.copy" is able to copy due dates from one assignment to another.
<pre>
it "copy due dates to new assignment" do
new_assignment_id = build(:assignment, id: 999).id
old_assignment_id = @assignment_due_date.assignment.id
DueDate.copy(old_assignment_id, new_assignment_id)
expect(DueDate.where(parent_id: new_assignment_id).count).to eql DueDate.where(parent_id: old_assignment_id).count
end
</pre>
* If the function "self.set_duedate" is able to create another due date by copying data from an existing due date object.
<pre>
it "create new duedate record with values" do
DueDate.set_duedate({id: 999}, @assignment_due_date.deadline_type_id,
@assignment_due_date.parent_id, @assignment_due_date.round)
new_due_date = DueDate.find_by(id: 999)
expect(new_due_date).to be_valid
expect(new_due_date.deadline_type_id).to eql @assignment_due_date.deadline_type_id
expect(new_due_date.parent_id).to eql @assignment_due_date.parent_id
expect(new_due_date.round).to eql @assignment_due_date.round
end
</pre>
* If the function "self.deadline_sort" is able to sort the due dates in ascending order.
<pre>
it "sort duedate records" do
sorted_due_dates = @due_dates
expect(sorted_due_dates.each_cons(2).all?{|m1, m2| (m1.due_at <=> m2.due_at) != 1}).to eql false

sorted_due_dates = DueDate.deadline_sort(@due_dates)
expect(sorted_due_dates.each_cons(2).all?{|m1, m2| (m1.due_at <=> m2.due_at) != 1}).to eql true
end
</pre>
* If the function "self.done_in_assignment_round" returns the correct number of rounds for specific inputs. This involves an invalid test case as well for 0 rounds.
<pre>
describe "#done_in_assignment_round" do
it "return 0 when no response map" do
response = ReviewResponseMap.create
response.type = "ResponseMap"
response.save
expect(DueDate.done_in_assignment_round(1, response)).to eql 0
end

it "return round 1 for single round" do
response = ReviewResponseMap.create
expect(DueDate.done_in_assignment_round(@assignment_due_date.parent_id, response)).to eql 1
end
end
</pre>
* If the function "self.get_next_due_date" works as expected. This involves several invalid test cases as well.
<pre>
describe "#get_next_due_date" do
it "no subsequent due date" do
expect(DueDate.get_next_due_date(@assignment_due_date.parent_id)).to be nil
end

it "nil value throws exception" do
expect { DueDate.get_next_due_date(nil) }.to raise_exception(ActiveRecord::RecordNotFound)
end

it "get next assignment due date" do
due_date = create(:assignment_due_date, deadline_type: @deadline_type,
submission_allowed_id: @deadline_right.id, review_allowed_id: @deadline_right.id,
review_of_review_allowed_id: @deadline_right.id, due_at: Time.zone.now + 5000)
expect(DueDate.get_next_due_date(due_date.parent_id)).to be_valid
end

it "get next due date from topic for staggered deadline" do
assignment_id = create(:assignment, staggered_deadline: true, name: "testassignment").id
due_date = create(:topic_due_date, deadline_type: @deadline_type,
submission_allowed_id: @deadline_right.id, review_allowed_id: @deadline_right.id,
review_of_review_allowed_id: @deadline_right.id, due_at: Time.zone.now + 5000, parent_id: assignment_id)
expect(DueDate.get_next_due_date(assignment_id, due_date.parent_id)).to be_valid
end

it "next due date does not exist for staggered deadline" do
assignment_id = create(:assignment, staggered_deadline: true, name: "testassignment").id
due_date = create(:topic_due_date, deadline_type: @deadline_type,
submission_allowed_id: @deadline_right, review_allowed_id: @deadline_right,
review_of_review_allowed_id: @deadline_right, due_at: Time.zone.now + 5000, parent_id: assignment_id)
expect(DueDate.get_next_due_date(assignment_id)).to be nil
end

it "next due date is before Time.now for staggered deadline" do
assignment_id = create(:assignment, staggered_deadline: true, name: "testassignment").id
due_date = create(:topic_due_date, deadline_type: @deadline_type,
submission_allowed_id: @deadline_right, review_allowed_id: @deadline_right,
review_of_review_allowed_id: @deadline_right, due_at: Time.zone.now - 5000, parent_id: assignment_id)
expect(DueDate.get_next_due_date(assignment_id, due_date.parent_id)).to be nil
end

it "get next due date from assignment for staggered deadline" do
assignment_id = create(:assignment, staggered_deadline: true, name: "testassignment").id
due_date = create(:assignment_due_date, deadline_type: @deadline_type,
submission_allowed_id: @deadline_right, review_allowed_id: @deadline_right,
review_of_review_allowed_id: @deadline_right, due_at: Time.zone.now + 5000, parent_id: assignment_id)
expect(DueDate.get_next_due_date(assignment_id)).to be_valid
end
end
</pre>
* If the function "self.default_permission" returns the correct default permissions for particular deadline and permission types.
<pre>
it "metareview review_of_review_allowed default permission OK" do
expect(DueDate.default_permission('metareview', 'review_of_review_allowed')).to be == DeadlineRight::OK
end
</pre>
<pre>
it "review submission_allowed default permission NO" do
expect(DueDate.default_permission('review', 'submission_allowed')).to be == DeadlineRight::NO
end
</pre>
To test this file run the following command:
<pre>
rspec spec/models/due_date_spec.rb
</pre>
The output of this RSpec file is present in below screenshot:
[[File:Duedaterspec.png]]

Code coverage details of the above RSpec files is present in below screenshot:
[[File:Duedatecoverage.png]]

=== deadline_helper_spec.rb ===
This is a test file for testing the functionalities of Deadline_helper.rb file located at app/helpers. Different test cases present in this file are:
* Check if the factory<ref>http://www.semaphoreci.com|access-date</ref> is valid:
<pre>
it "has a valid factory" do
factory = FactoryGirl.build(:topic_due_date)
expect(factory).to be_valid
end
</pre>
* Fail if the due date is invalid:
<pre>
it "should fail because of invalid due_date" do
expect { DeadlineHelper.create_topic_deadline(nil, 0, 0)}.to raise_exception(NoMethodError)
end
</pre>
* If new due_date object is created:
<pre>
it "new due_date object created" do
DeadlineHelper.create_topic_deadline(@topic_due_date, 0, 1)
expect(TopicDueDate.count).to be == 2
end
</pre>
* due_at should be same for 0 offset:
<pre>
it "due_at should be same for 0 offset" do
DeadlineHelper.create_topic_deadline(@topic_due_date, 0, 10)
new_due_date = TopicDueDate.find_by(parent_id: 10)
expect(new_due_date).to be_valid
expect(new_due_date.due_at.to_s).to be == @topic_due_date.due_at.to_s
end
</pre>
* due_at is calculated correctly if offset is positive:
<pre>
it "due_at calculated correctly for positive offset" do
DeadlineHelper.create_topic_deadline(@topic_due_date, 5000, 10)
new_due_date = TopicDueDate.find_by(parent_id: 10)
expect(new_due_date).to be_valid
expect(new_due_date.due_at.to_s).to be == (Time.zone.parse(@topic_due_date.due_at.to_s) + 5000).to_s
end
</pre>
* due_at is calculated correctly if offset is negative:
<pre>
it "due_at calculated correctly for negative offset" do
DeadlineHelper.create_topic_deadline(@topic_due_date, -5000, 10)
new_due_date = TopicDueDate.find_by(parent_id: 10)
expect(new_due_date).to be_valid
expect(new_due_date.due_at.to_s).to be == (Time.zone.parse(@topic_due_date.due_at.to_s) - 5000).to_s
end
</pre>
* The offset is being converted to integer properly:
<pre>
it "offset converted to integer correctly" do
DeadlineHelper.create_topic_deadline(@topic_due_date, 5000.15, 10)
new_due_date = TopicDueDate.find_by(parent_id: 10)
expect(new_due_date).to be_valid
expect(new_due_date.due_at.to_s).to be == (Time.zone.parse(@topic_due_date.due_at.to_s) + 5000).to_s
end
</pre>
To test this file run the following command:
<pre>
rspec spec/models/deadline_helper_spec.rb
</pre>
The output of this RSpec file is present in below screenshot:
[[File:Deadlinerspec.png]]

Code coverage details of the above RSpec files is present in below screenshot:
[[File:Deadlinecoverage.png]]

=== '''Testing The System''' ===
Run the following commands to test the new RSpec files created:
* rspec spec/models/deadline_helper_spec.rb
* rspec spec/models/due_date_spec.rb

==References==
<references/>

CSC/ECE 517 Fall 2016/E1634. Refactor and write unit test of due date.rb and deadline helper.rb

2016-11-05T01:09:26Z

Aagrawa6:

== '''Introduction''' ==

=== Expertiza ===
Expertiza<ref>https://expertiza.ncsu.edu/</ref> is an open source project for school assignment management for instructors and students based on the Ruby on Rails<ref>http://www.rubyonrails.org</ref> framework. Expertiza allows the instructor to create new assignments and customise new or existing assignments. It also allows the instructor to create a list of topics the students can sign up for. Students can form teams in Expertiza to work on various projects and assignments. Students can also peer review other students' submissions. Expertiza supports submission across various document types, including the URLs and word documents. Expertiza provides a dashboard for all the assignments corresponding to a course and provides absolute control to the Instructors and Teaching Assistants. In addition to assignments, it encompasses peer reviews wherein participants are allowed to provide feedback anonymously about each other's work thereby providing scope for the better outcome. The due_date.rb file is responsible for informing the users about the deadline for submission of the each assignment. Due dates in Expertiza have their association with many other components like assignments, reviews etc.

=== Code Climate ===
Code Climate<ref>https://codeclimate.com/dashboard</ref> is a tool that runs static analysis on a GitHub project and outputs many details like test coverage, complexity, duplication, security, style, and more. There is a Google Chrome extension to integrate the Code Climate results generated directly into GitHub which is visible when browsing the repository on the browser. It allows us to see issues displayed directly inside GitHub's UI, to review which lines are covered in diffs and files, and add repositories and open tickets without changing your workflow.

== '''Tasks Identified''' ==
To install Code climate Chrome Extension that highlights the duplicated code.

To refactor the following two files:
* due_date.rb
** Ternary operators must not be nested. Prefer `if` or `else` constructs instead.
** Useless assignment to variable - `sorted_deadlines`.
** Prefer `each` over `for`.
** Use `find_by` instead of `where.first`.
** Correct the use of Time function
* deadline_helper.rb
** Do not use `Time.now` without zone. Use one of `Time.zone.now`, `Time.current`, `Time.now.in_time_zone`, `Time.now.utc`, `Time.now.getlocal`, `Time.now.iso8601`, `Time.now.jisx0301`, `Time.now.rfc3339`, `Time.now.to_i`, `Time.now.to_f` instead.
** Trailing whitespace detected.
** Extra empty line detected at module body end.

* Create respective RSpec<ref>http://www.rspec.info</ref> files in /spec/models/ and /spec/helper folder and write unit tests for each method in due_date.rb and deadline_helper.rb.

== '''Current Implementation''' ==
DueDate is a Model class to manage the deadlines of an assignment. It has methods for setting due dates for an assignment, copying due dates from one assignment to a new assignment etc. DeadlineHelper provides helper functions that help DueDate perform certain tasks. The assignment focuses on refactoring some of the methods based on warnings received from Code Climate's static analysis and modifying the language to make it more Ruby-friendly. The assignment also involves writing unit test cases for due_date.rb and deadline_helper.rb in order to increase test coverage.

The goal of this project is to attempt to make this part of the application easier to read and write unit test cases that the application must pass.

== '''Changed Implementation''' ==
Changes implemented involves refactoring the code and making it more understandable by adding comments in the code.

The modified files are
* due_date.rb (path: /app/models)
* deadline_helper.rb (path: /app/helpers)
Testing files
* due_date_spec.rb (path: /spec/models)
* deadline_helper_spec.rb (path: /spec/helpers)

=== due_date.rb ===
* Converted for..in loop to object.each in order to follow better Ruby syntax.
* Unnecessary assignment to sorted_deadlines removed.
* Nested ternary operators have been changed to if..else in order to make it more readable.
[[File:Duedaterb.png]]
* Changed where(...).first to find_by(...) which is the newer recommended syntax.
* Corrected the Time.now functions by adding the correct zones to them such as Time.zone.now.
* Removed trailing whitespaces.
[[File:DueDaterb2.png]]

=== deadline_helper.rb ===
* Time functions were changed to functions with zones
* Extra line removed
[[File:Deadlinehelper.png]]

== '''RSpec testing''' ==
There were no existing tests for the functions in due_date.rb and deadline_helper.rb. We have added exhaustive set of RSpec tests to test all the code. We have added two new spec files 'due_date_spec.rb' and ‘deadline_helper_spec.rb’ which cover the testing scenarios for the functions in ‘due_date.rb’ and ‘deadline_helper.rb’.

For both of these two files, all Travis CI<ref>http://www.travis-ci.com</ref> test cases have passed for all previous test cases as well as the ones added by us with the test coverage for the files due_date.rb and deadline_helper.rb reported as 100%.

These RSpec files have 100% code coverage visible at: /coverage/index.html.

=== due_date_spec.rb ===
This file is located at spec/models and tests the functionalities of the due_date.rb file located in app/models. There are 18 test cases in total which are listed below.
* If the factory is successfully able to build the due_date objects.
<pre>
it "due date factory created successfully" do
expect(@assignment_due_date).to be_valid
end
</pre>
<pre>
it "due dates created correctly" do
expect(@due_dates.length).to be == 10
end
</pre>
* If the function "set_flag" successfully sets the due_date flag.
<pre>
it "due date flag is set" do
expect(@assignment_due_date.flag).to be false
@assignment_due_date.set_flag
expect(@assignment_due_date.flag).to be true
end
</pre>
* If the function "due_at_is_valid_datetime" returns nil (no errors) for a valid datetime in due_at (no invalid test cases can be added here because model does not allow invalid datetime to be set at all).
<pre>
it "due at is valid datetime" do
expect(@assignment_due_date.due_at_is_valid_datetime).to be nil
end
</pre>
* If the function "self.copy" is able to copy due dates from one assignment to another.
<pre>
it "copy due dates to new assignment" do
new_assignment_id = build(:assignment, id: 999).id
old_assignment_id = @assignment_due_date.assignment.id
DueDate.copy(old_assignment_id, new_assignment_id)
expect(DueDate.where(parent_id: new_assignment_id).count).to eql DueDate.where(parent_id: old_assignment_id).count
end
</pre>
* If the function "self.set_duedate" is able to create another due date by copying data from an existing due date object.
<pre>
it "create new duedate record with values" do
DueDate.set_duedate({id: 999}, @assignment_due_date.deadline_type_id,
@assignment_due_date.parent_id, @assignment_due_date.round)
new_due_date = DueDate.find_by(id: 999)
expect(new_due_date).to be_valid
expect(new_due_date.deadline_type_id).to eql @assignment_due_date.deadline_type_id
expect(new_due_date.parent_id).to eql @assignment_due_date.parent_id
expect(new_due_date.round).to eql @assignment_due_date.round
end
</pre>
* If the function "self.deadline_sort" is able to sort the due dates in ascending order.
<pre>
it "sort duedate records" do
sorted_due_dates = @due_dates
expect(sorted_due_dates.each_cons(2).all?{|m1, m2| (m1.due_at <=> m2.due_at) != 1}).to eql false

sorted_due_dates = DueDate.deadline_sort(@due_dates)
expect(sorted_due_dates.each_cons(2).all?{|m1, m2| (m1.due_at <=> m2.due_at) != 1}).to eql true
end
</pre>
* If the function "self.done_in_assignment_round" returns the correct number of rounds for specific inputs. This involves an invalid test case as well for 0 rounds.
<pre>
describe "#done_in_assignment_round" do
it "return 0 when no response map" do
response = ReviewResponseMap.create
response.type = "ResponseMap"
response.save
expect(DueDate.done_in_assignment_round(1, response)).to eql 0
end

it "return round 1 for single round" do
response = ReviewResponseMap.create
expect(DueDate.done_in_assignment_round(@assignment_due_date.parent_id, response)).to eql 1
end
end
</pre>
* If the function "self.get_next_due_date" works as expected. This involves several invalid test cases as well.
<pre>
describe "#get_next_due_date" do
it "no subsequent due date" do
expect(DueDate.get_next_due_date(@assignment_due_date.parent_id)).to be nil
end

it "nil value throws exception" do
expect { DueDate.get_next_due_date(nil) }.to raise_exception(ActiveRecord::RecordNotFound)
end

it "get next assignment due date" do
due_date = create(:assignment_due_date, deadline_type: @deadline_type,
submission_allowed_id: @deadline_right.id, review_allowed_id: @deadline_right.id,
review_of_review_allowed_id: @deadline_right.id, due_at: Time.zone.now + 5000)
expect(DueDate.get_next_due_date(due_date.parent_id)).to be_valid
end

it "get next due date from topic for staggered deadline" do
assignment_id = create(:assignment, staggered_deadline: true, name: "testassignment").id
due_date = create(:topic_due_date, deadline_type: @deadline_type,
submission_allowed_id: @deadline_right.id, review_allowed_id: @deadline_right.id,
review_of_review_allowed_id: @deadline_right.id, due_at: Time.zone.now + 5000, parent_id: assignment_id)
expect(DueDate.get_next_due_date(assignment_id, due_date.parent_id)).to be_valid
end

it "next due date does not exist for staggered deadline" do
assignment_id = create(:assignment, staggered_deadline: true, name: "testassignment").id
due_date = create(:topic_due_date, deadline_type: @deadline_type,
submission_allowed_id: @deadline_right, review_allowed_id: @deadline_right,
review_of_review_allowed_id: @deadline_right, due_at: Time.zone.now + 5000, parent_id: assignment_id)
expect(DueDate.get_next_due_date(assignment_id)).to be nil
end

it "next due date is before Time.now for staggered deadline" do
assignment_id = create(:assignment, staggered_deadline: true, name: "testassignment").id
due_date = create(:topic_due_date, deadline_type: @deadline_type,
submission_allowed_id: @deadline_right, review_allowed_id: @deadline_right,
review_of_review_allowed_id: @deadline_right, due_at: Time.zone.now - 5000, parent_id: assignment_id)
expect(DueDate.get_next_due_date(assignment_id, due_date.parent_id)).to be nil
end

it "get next due date from assignment for staggered deadline" do
assignment_id = create(:assignment, staggered_deadline: true, name: "testassignment").id
due_date = create(:assignment_due_date, deadline_type: @deadline_type,
submission_allowed_id: @deadline_right, review_allowed_id: @deadline_right,
review_of_review_allowed_id: @deadline_right, due_at: Time.zone.now + 5000, parent_id: assignment_id)
expect(DueDate.get_next_due_date(assignment_id)).to be_valid
end
end
</pre>
* If the function "self.default_permission" returns the correct default permissions for particular deadline and permission types.
<pre>
it "metareview review_of_review_allowed default permission OK" do
expect(DueDate.default_permission('metareview', 'review_of_review_allowed')).to be == DeadlineRight::OK
end
</pre>
<pre>
it "review submission_allowed default permission NO" do
expect(DueDate.default_permission('review', 'submission_allowed')).to be == DeadlineRight::NO
end
</pre>
To test this file run the following command:
<pre>
rspec spec/models/due_date_spec.rb
</pre>
The output of this RSpec file is present in below screenshot:
[[File:Duedaterspec.png]]

Code coverage details of the above RSpec files is present in below screenshot:
[[File:Duedatecoverage.png]]

=== deadline_helper_spec.rb ===
This is a test file for testing the functionalities of Deadline_helper.rb file located at app/helpers. Different test cases present in this file are:
* Check if the factory<ref>http://www.semaphoreci.com|access-date</ref> is valid:
<pre>
it "has a valid factory" do
factory = FactoryGirl.build(:topic_due_date)
expect(factory).to be_valid
end
</pre>
* Fail if the due date is invalid:
<pre>
it "should fail because of invalid due_date" do
expect { DeadlineHelper.create_topic_deadline(nil, 0, 0)}.to raise_exception(NoMethodError)
end
</pre>
* If new due_date object is created:
<pre>
it "new due_date object created" do
DeadlineHelper.create_topic_deadline(@topic_due_date, 0, 1)
expect(TopicDueDate.count).to be == 2
end
</pre>
* due_at should be same for 0 offset:
<pre>
it "due_at should be same for 0 offset" do
DeadlineHelper.create_topic_deadline(@topic_due_date, 0, 10)
new_due_date = TopicDueDate.find_by(parent_id: 10)
expect(new_due_date).to be_valid
expect(new_due_date.due_at.to_s).to be == @topic_due_date.due_at.to_s
end
</pre>
* due_at is calculated correctly if offset is positive:
<pre>
it "due_at calculated correctly for positive offset" do
DeadlineHelper.create_topic_deadline(@topic_due_date, 5000, 10)
new_due_date = TopicDueDate.find_by(parent_id: 10)
expect(new_due_date).to be_valid
expect(new_due_date.due_at.to_s).to be == (Time.zone.parse(@topic_due_date.due_at.to_s) + 5000).to_s
end
</pre>
* due_at is calculated correctly if offset is negative:
<pre>
it "due_at calculated correctly for negative offset" do
DeadlineHelper.create_topic_deadline(@topic_due_date, -5000, 10)
new_due_date = TopicDueDate.find_by(parent_id: 10)
expect(new_due_date).to be_valid
expect(new_due_date.due_at.to_s).to be == (Time.zone.parse(@topic_due_date.due_at.to_s) - 5000).to_s
end
</pre>
* The offset is being converted to integer properly:
<pre>
it "offset converted to integer correctly" do
DeadlineHelper.create_topic_deadline(@topic_due_date, 5000.15, 10)
new_due_date = TopicDueDate.find_by(parent_id: 10)
expect(new_due_date).to be_valid
expect(new_due_date.due_at.to_s).to be == (Time.zone.parse(@topic_due_date.due_at.to_s) + 5000).to_s
end
</pre>
To test this file run the following command:
<pre>
rspec spec/models/deadline_helper_spec.rb
</pre>
The output of this RSpec file is present in below screenshot:
[[File:Deadlinerspec.png]]

Code coverage details of the above RSpec files is present in below screenshot:
[[File:Deadlinecoverage.png]]

=== '''Testing The System''' ===
Run the following commands to test the new RSpec files created:
* rspec spec/models/deadline_helper_spec.rb
* rspec spec/models/due_date_spec.rb

==References==
<references/>

CSC/ECE 517 Fall 2016/E1634. Refactor and write unit test of due date.rb and deadline helper.rb

2016-11-05T01:08:38Z

Aagrawa6:

== '''Introduction''' ==

=== Expertiza ===
Expertiza<ref>https://expertiza.ncsu.edu/</ref> is an open source project for school assignment management for instructors and students based on the Ruby on Rails<ref>http://www.rubyonrails.org</ref> framework. Expertiza allows the instructor to create new assignments and customise new or existing assignments. It also allows the instructor to create a list of topics the students can sign up for. Students can form teams in Expertiza to work on various projects and assignments. Students can also peer review other students' submissions. Expertiza supports submission across various document types, including the URLs and word documents. Expertiza provides a dashboard for all the assignments corresponding to a course and provides absolute control to the Instructors and Teaching Assistants. In addition to assignments, it encompasses peer reviews wherein participants are allowed to provide feedback anonymously about each other's work thereby providing scope for the better outcome. The due_date.rb file is responsible for informing the users about the deadline for submission of the each assignment. Due dates in Expertiza have their association with many other components like assignments, reviews etc.

=== Code Climate ===
Code Climate<ref>https://codeclimate.com/dashboard</ref> is a tool that runs static analysis on a GitHub project and outputs many details like test coverage, complexity, duplication, security, style, and more. There is a Google Chrome extension to integrate the Code Climate results generated directly into GitHub which is visible when browsing the repository on the browser. It allows us to see issues displayed directly inside GitHub's UI, to review which lines are covered in diffs and files, and add repositories and open tickets without changing your workflow.

== '''Tasks Identified''' ==
To install Code climate Chrome Extension that highlights the duplicated code.

To refactor the following two files:
* due_date.rb
** Ternary operators must not be nested. Prefer `if` or `else` constructs instead.
** Useless assignment to variable - `sorted_deadlines`.
** Prefer `each` over `for`.
** Use `find_by` instead of `where.first`.
** Correct the use of Time function
* deadline_helper.rb
** Do not use `Time.now` without zone. Use one of `Time.zone.now`, `Time.current`, `Time.now.in_time_zone`, `Time.now.utc`, `Time.now.getlocal`, `Time.now.iso8601`, `Time.now.jisx0301`, `Time.now.rfc3339`, `Time.now.to_i`, `Time.now.to_f` instead.
** Trailing whitespace detected.
** Extra empty line detected at module body end.

* Create respective RSpec<ref>http://www.rspec.info</ref> files in /spec/models/ and /spec/helper folder and write unit tests for each method in due_date.rb and deadline_helper.rb.

== '''Current Implementation''' ==
DueDate is a Model class to manage the deadlines of an assignment. It has methods for setting due dates for an assignment, copying due dates from one assignment to a new assignment etc. DeadlineHelper provides helper functions that help DueDate perform certain tasks. The assignment focuses on refactoring some of the methods based on warnings received from Code Climate's static analysis and modifying the language to make it more Ruby-friendly. The assignment also involves writing unit test cases for due_date.rb and deadline_helper.rb in order to increase test coverage.

The goal of this project is to attempt to make this part of the application easier to read and write unit test cases that the application must pass.

== '''Changed Implementation''' ==
Changes implemented involves refactoring the code and making it more understandable by adding comments in the code.

The modified files are
* due_date.rb (path: /app/models)
* deadline_helper.rb (path: /app/helpers)
Testing files
* due_date_spec.rb (path: /spec/models)
* deadline_helper_spec.rb (path: /spec/helpers)

=== due_date.rb ===
* Converted for..in loop to object.each in order to follow better Ruby syntax.
* Unnecessary assignment to sorted_deadlines removed.
* Nested ternary operators have been changed to if..else in order to make it more readable.
[[File:Duedaterb.png]]
* Changed where(...).first to find_by(...) which is the newer recommended syntax.
* Corrected the Time.now functions by adding the correct zones to them such as Time.zone.now.
* Removed trailing whitespaces.
[[File:DueDaterb2.png]]

=== deadline_helper.rb ===
* Time functions were changed to functions with zones
* Extra line removed
[[File:Deadlinehelper.png]]

== '''RSpec testing''' ==
There were no existing tests for the functions in due_date.rb and deadline_helper.rb. We have added exhaustive set of RSpec tests to test all the code. We have added two new spec files 'due_date_spec.rb' and ‘deadline_helper_spec.rb’ which cover the testing scenarios for the functions in ‘due_date.rb’ and ‘deadline_helper.rb’.

For both of these two files, all Travis CI<ref>http://www.travis-ci.com</ref> test cases have passed for all previous test cases as well as the ones added by us with the test coverage for the files due_date.rb and deadline_helper.rb reported as 100%.

These RSpec files have 100% code coverage visible at: /coverage/index.html.

=== due_date_spec.rb ===
This file is located at spec/models and tests the functionalities of the due_date.rb file located in app/models. There are 18 test cases in total which are listed below.
* If the factory is successfully able to build the due_date objects.
<pre>
it "due date factory created successfully" do
expect(@assignment_due_date).to be_valid
end
</pre>
<pre>
it "due dates created correctly" do
expect(@due_dates.length).to be == 10
end
</pre>
* If the function "set_flag" successfully sets the due_date flag.
<pre>
it "due date flag is set" do
expect(@assignment_due_date.flag).to be false
@assignment_due_date.set_flag
expect(@assignment_due_date.flag).to be true
end
</pre>
* If the function "due_at_is_valid_datetime" returns nil (no errors) for a valid datetime in due_at (no invalid test cases can be added here because model does not allow invalid datetime to be set at all).
<pre>
it "due at is valid datetime" do
expect(@assignment_due_date.due_at_is_valid_datetime).to be nil
end
</pre>
* If the function "self.copy" is able to copy due dates from one assignment to another.
<pre>
it "copy due dates to new assignment" do
new_assignment_id = build(:assignment, id: 999).id
old_assignment_id = @assignment_due_date.assignment.id
DueDate.copy(old_assignment_id, new_assignment_id)
expect(DueDate.where(parent_id: new_assignment_id).count).to eql DueDate.where(parent_id: old_assignment_id).count
end
</pre>
* If the function "self.set_duedate" is able to create another due date by copying data from an existing due date object.
<pre>
it "create new duedate record with values" do
DueDate.set_duedate({id: 999}, @assignment_due_date.deadline_type_id,
@assignment_due_date.parent_id, @assignment_due_date.round)
new_due_date = DueDate.find_by(id: 999)
expect(new_due_date).to be_valid
expect(new_due_date.deadline_type_id).to eql @assignment_due_date.deadline_type_id
expect(new_due_date.parent_id).to eql @assignment_due_date.parent_id
expect(new_due_date.round).to eql @assignment_due_date.round
end
</pre>
* If the function "self.deadline_sort" is able to sort the due dates in ascending order.
<pre>
it "sort duedate records" do
sorted_due_dates = @due_dates
expect(sorted_due_dates.each_cons(2).all?{|m1, m2| (m1.due_at <=> m2.due_at) != 1}).to eql false

sorted_due_dates = DueDate.deadline_sort(@due_dates)
expect(sorted_due_dates.each_cons(2).all?{|m1, m2| (m1.due_at <=> m2.due_at) != 1}).to eql true
end
</pre>
* If the function "self.done_in_assignment_round" returns the correct number of rounds for specific inputs. This involves an invalid test case as well for 0 rounds.
<pre>
describe "#done_in_assignment_round" do
it "return 0 when no response map" do
response = ReviewResponseMap.create
response.type = "ResponseMap"
response.save
expect(DueDate.done_in_assignment_round(1, response)).to eql 0
end

it "return round 1 for single round" do
response = ReviewResponseMap.create
expect(DueDate.done_in_assignment_round(@assignment_due_date.parent_id, response)).to eql 1
end
end
</pre>
* If the function "self.get_next_due_date" works as expected. This involves several invalid test cases as well.
<pre>
describe "#get_next_due_date" do
it "no subsequent due date" do
expect(DueDate.get_next_due_date(@assignment_due_date.parent_id)).to be nil
end

it "nil value throws exception" do
expect { DueDate.get_next_due_date(nil) }.to raise_exception(ActiveRecord::RecordNotFound)
end

it "get next assignment due date" do
due_date = create(:assignment_due_date, deadline_type: @deadline_type,
submission_allowed_id: @deadline_right.id, review_allowed_id: @deadline_right.id,
review_of_review_allowed_id: @deadline_right.id, due_at: Time.zone.now + 5000)
expect(DueDate.get_next_due_date(due_date.parent_id)).to be_valid
end

it "get next due date from topic for staggered deadline" do
assignment_id = create(:assignment, staggered_deadline: true, name: "testassignment").id
due_date = create(:topic_due_date, deadline_type: @deadline_type,
submission_allowed_id: @deadline_right.id, review_allowed_id: @deadline_right.id,
review_of_review_allowed_id: @deadline_right.id, due_at: Time.zone.now + 5000, parent_id: assignment_id)
expect(DueDate.get_next_due_date(assignment_id, due_date.parent_id)).to be_valid
end

it "next due date does not exist for staggered deadline" do
assignment_id = create(:assignment, staggered_deadline: true, name: "testassignment").id
due_date = create(:topic_due_date, deadline_type: @deadline_type,
submission_allowed_id: @deadline_right, review_allowed_id: @deadline_right,
review_of_review_allowed_id: @deadline_right, due_at: Time.zone.now + 5000, parent_id: assignment_id)
expect(DueDate.get_next_due_date(assignment_id)).to be nil
end

it "next due date is before Time.now for staggered deadline" do
assignment_id = create(:assignment, staggered_deadline: true, name: "testassignment").id
due_date = create(:topic_due_date, deadline_type: @deadline_type,
submission_allowed_id: @deadline_right, review_allowed_id: @deadline_right,
review_of_review_allowed_id: @deadline_right, due_at: Time.zone.now - 5000, parent_id: assignment_id)
expect(DueDate.get_next_due_date(assignment_id, due_date.parent_id)).to be nil
end

it "get next due date from assignment for staggered deadline" do
assignment_id = create(:assignment, staggered_deadline: true, name: "testassignment").id
due_date = create(:assignment_due_date, deadline_type: @deadline_type,
submission_allowed_id: @deadline_right, review_allowed_id: @deadline_right,
review_of_review_allowed_id: @deadline_right, due_at: Time.zone.now + 5000, parent_id: assignment_id)
expect(DueDate.get_next_due_date(assignment_id)).to be_valid
end
end
</pre>
* If the function "self.default_permission" returns the correct default permissions for particular deadline and permission types.
<pre>
it "metareview review_of_review_allowed default permission OK" do
expect(DueDate.default_permission('metareview', 'review_of_review_allowed')).to be == DeadlineRight::OK
end
</pre>
<pre>
it "review submission_allowed default permission NO" do
expect(DueDate.default_permission('review', 'submission_allowed')).to be == DeadlineRight::NO
end
</pre>
To test this file run the following command:
<pre>
rspec spec/models/due_date_spec.rb
</pre>
The output of this RSpec file is present in below screenshot:
[[File:Duedaterspec.png]]

Code coverage details of the above RSpec files is present in below screenshot:
[[File:Duedatecoverage.png]]

=== deadline_helper_spec.rb ===
This is a test file for testing the functionalities of Deadline_helper.rb file located at app/helpers. Different test cases present in this file are:
* Check if the factory<ref>http://www.semaphoreci.com|access-date</ref> is valid:
<pre>
it "has a valid factory" do
factory = FactoryGirl.build(:topic_due_date)
expect(factory).to be_valid
end
</pre>
* Fail if the due date is invalid:
<pre>
it "should fail because of invalid due_date" do
expect { DeadlineHelper.create_topic_deadline(nil, 0, 0)}.to raise_exception(NoMethodError)
end
</pre>
* If new due_date object is created:
<pre>
it "new due_date object created" do
DeadlineHelper.create_topic_deadline(@topic_due_date, 0, 1)
expect(TopicDueDate.count).to be == 2
end
</pre>
* due_at should be same for 0 offset:
<pre>
it "due_at should be same for 0 offset" do
DeadlineHelper.create_topic_deadline(@topic_due_date, 0, 10)
new_due_date = TopicDueDate.find_by(parent_id: 10)
expect(new_due_date).to be_valid
expect(new_due_date.due_at.to_s).to be == @topic_due_date.due_at.to_s
end
</pre>
* due_at is calculated correctly if offset is positive:
<pre>
it "due_at calculated correctly for positive offset" do
DeadlineHelper.create_topic_deadline(@topic_due_date, 5000, 10)
new_due_date = TopicDueDate.find_by(parent_id: 10)
expect(new_due_date).to be_valid
expect(new_due_date.due_at.to_s).to be == (Time.zone.parse(@topic_due_date.due_at.to_s) + 5000).to_s
end
</pre>
* due_at is calculated correctly if offset is negative:
<pre>
it "due_at calculated correctly for negative offset" do
DeadlineHelper.create_topic_deadline(@topic_due_date, -5000, 10)
new_due_date = TopicDueDate.find_by(parent_id: 10)
expect(new_due_date).to be_valid
expect(new_due_date.due_at.to_s).to be == (Time.zone.parse(@topic_due_date.due_at.to_s) - 5000).to_s
end
</pre>
* The offset is being converted to integer properly:
<pre>
it "offset converted to integer correctly" do
DeadlineHelper.create_topic_deadline(@topic_due_date, 5000.15, 10)
new_due_date = TopicDueDate.find_by(parent_id: 10)
expect(new_due_date).to be_valid
expect(new_due_date.due_at.to_s).to be == (Time.zone.parse(@topic_due_date.due_at.to_s) + 5000).to_s
end
</pre>
To test this file run the following command:
<pre>
rspec spec/models/deadline_helper_spec.rb
</pre>
The output of this RSpec file is present in below screenshot:
[[File:Deadlinerspec.png]]

Code coverage details of the above RSpec files is present in below screenshot:
[[File:Deadlinecoverage.png]]

=== ""Testing The System"" ===
Run the following commands to test the new RSpec files created:
* rspec spec/models/deadline_helper_spec.rb
* rspec spec/models/due_date_spec.rb

==References==
<references/>

CSC/ECE 517 Fall 2016/E1634. Refactor and write unit test of due date.rb and deadline helper.rb

2016-11-05T01:08:15Z

Aagrawa6: /* Testing The System */

== '''Introduction''' ==

=== Expertiza ===
Expertiza<ref>https://expertiza.ncsu.edu/</ref> is an open source project for school assignment management for instructors and students based on the Ruby on Rails<ref>http://www.rubyonrails.org</ref> framework. Expertiza allows the instructor to create new assignments and customise new or existing assignments. It also allows the instructor to create a list of topics the students can sign up for. Students can form teams in Expertiza to work on various projects and assignments. Students can also peer review other students' submissions. Expertiza supports submission across various document types, including the URLs and word documents. Expertiza provides a dashboard for all the assignments corresponding to a course and provides absolute control to the Instructors and Teaching Assistants. In addition to assignments, it encompasses peer reviews wherein participants are allowed to provide feedback anonymously about each other's work thereby providing scope for the better outcome. The due_date.rb file is responsible for informing the users about the deadline for submission of the each assignment. Due dates in Expertiza have their association with many other components like assignments, reviews etc.

=== Code Climate ===
Code Climate<ref>https://codeclimate.com/dashboard</ref> is a tool that runs static analysis on a GitHub project and outputs many details like test coverage, complexity, duplication, security, style, and more. There is a Google Chrome extension to integrate the Code Climate results generated directly into GitHub which is visible when browsing the repository on the browser. It allows us to see issues displayed directly inside GitHub's UI, to review which lines are covered in diffs and files, and add repositories and open tickets without changing your workflow.

== '''Tasks Identified''' ==
To install Code climate Chrome Extension that highlights the duplicated code.

To refactor the following two files:
* due_date.rb
** Ternary operators must not be nested. Prefer `if` or `else` constructs instead.
** Useless assignment to variable - `sorted_deadlines`.
** Prefer `each` over `for`.
** Use `find_by` instead of `where.first`.
** Correct the use of Time function
* deadline_helper.rb
** Do not use `Time.now` without zone. Use one of `Time.zone.now`, `Time.current`, `Time.now.in_time_zone`, `Time.now.utc`, `Time.now.getlocal`, `Time.now.iso8601`, `Time.now.jisx0301`, `Time.now.rfc3339`, `Time.now.to_i`, `Time.now.to_f` instead.
** Trailing whitespace detected.
** Extra empty line detected at module body end.

* Create respective RSpec<ref>http://www.rspec.info</ref> files in /spec/models/ and /spec/helper folder and write unit tests for each method in due_date.rb and deadline_helper.rb.

== '''Current Implementation''' ==
DueDate is a Model class to manage the deadlines of an assignment. It has methods for setting due dates for an assignment, copying due dates from one assignment to a new assignment etc. DeadlineHelper provides helper functions that help DueDate perform certain tasks. The assignment focuses on refactoring some of the methods based on warnings received from Code Climate's static analysis and modifying the language to make it more Ruby-friendly. The assignment also involves writing unit test cases for due_date.rb and deadline_helper.rb in order to increase test coverage.

The goal of this project is to attempt to make this part of the application easier to read and write unit test cases that the application must pass.

== '''Changed Implementation''' ==
Changes implemented involves refactoring the code and making it more understandable by adding comments in the code.

The modified files are
* due_date.rb (path: /app/models)
* deadline_helper.rb (path: /app/helpers)
Testing files
* due_date_spec.rb (path: /spec/models)
* deadline_helper_spec.rb (path: /spec/helpers)

=== due_date.rb ===
* Converted for..in loop to object.each in order to follow better Ruby syntax.
* Unnecessary assignment to sorted_deadlines removed.
* Nested ternary operators have been changed to if..else in order to make it more readable.
[[File:Duedaterb.png]]
* Changed where(...).first to find_by(...) which is the newer recommended syntax.
* Corrected the Time.now functions by adding the correct zones to them such as Time.zone.now.
* Removed trailing whitespaces.
[[File:DueDaterb2.png]]

=== deadline_helper.rb ===
* Time functions were changed to functions with zones
* Extra line removed
[[File:Deadlinehelper.png]]

== '''RSpec testing''' ==
There were no existing tests for the functions in due_date.rb and deadline_helper.rb. We have added exhaustive set of RSpec tests to test all the code. We have added two new spec files 'due_date_spec.rb' and ‘deadline_helper_spec.rb’ which cover the testing scenarios for the functions in ‘due_date.rb’ and ‘deadline_helper.rb’.

For both of these two files, all Travis CI<ref>http://www.travis-ci.com</ref> test cases have passed for all previous test cases as well as the ones added by us with the test coverage for the files due_date.rb and deadline_helper.rb reported as 100%.

These RSpec files have 100% code coverage visible at: /coverage/index.html.

=== due_date_spec.rb ===
This file is located at spec/models and tests the functionalities of the due_date.rb file located in app/models. There are 18 test cases in total which are listed below.
* If the factory is successfully able to build the due_date objects.
<pre>
it "due date factory created successfully" do
expect(@assignment_due_date).to be_valid
end
</pre>
<pre>
it "due dates created correctly" do
expect(@due_dates.length).to be == 10
end
</pre>
* If the function "set_flag" successfully sets the due_date flag.
<pre>
it "due date flag is set" do
expect(@assignment_due_date.flag).to be false
@assignment_due_date.set_flag
expect(@assignment_due_date.flag).to be true
end
</pre>
* If the function "due_at_is_valid_datetime" returns nil (no errors) for a valid datetime in due_at (no invalid test cases can be added here because model does not allow invalid datetime to be set at all).
<pre>
it "due at is valid datetime" do
expect(@assignment_due_date.due_at_is_valid_datetime).to be nil
end
</pre>
* If the function "self.copy" is able to copy due dates from one assignment to another.
<pre>
it "copy due dates to new assignment" do
new_assignment_id = build(:assignment, id: 999).id
old_assignment_id = @assignment_due_date.assignment.id
DueDate.copy(old_assignment_id, new_assignment_id)
expect(DueDate.where(parent_id: new_assignment_id).count).to eql DueDate.where(parent_id: old_assignment_id).count
end
</pre>
* If the function "self.set_duedate" is able to create another due date by copying data from an existing due date object.
<pre>
it "create new duedate record with values" do
DueDate.set_duedate({id: 999}, @assignment_due_date.deadline_type_id,
@assignment_due_date.parent_id, @assignment_due_date.round)
new_due_date = DueDate.find_by(id: 999)
expect(new_due_date).to be_valid
expect(new_due_date.deadline_type_id).to eql @assignment_due_date.deadline_type_id
expect(new_due_date.parent_id).to eql @assignment_due_date.parent_id
expect(new_due_date.round).to eql @assignment_due_date.round
end
</pre>
* If the function "self.deadline_sort" is able to sort the due dates in ascending order.
<pre>
it "sort duedate records" do
sorted_due_dates = @due_dates
expect(sorted_due_dates.each_cons(2).all?{|m1, m2| (m1.due_at <=> m2.due_at) != 1}).to eql false

sorted_due_dates = DueDate.deadline_sort(@due_dates)
expect(sorted_due_dates.each_cons(2).all?{|m1, m2| (m1.due_at <=> m2.due_at) != 1}).to eql true
end
</pre>
* If the function "self.done_in_assignment_round" returns the correct number of rounds for specific inputs. This involves an invalid test case as well for 0 rounds.
<pre>
describe "#done_in_assignment_round" do
it "return 0 when no response map" do
response = ReviewResponseMap.create
response.type = "ResponseMap"
response.save
expect(DueDate.done_in_assignment_round(1, response)).to eql 0
end

it "return round 1 for single round" do
response = ReviewResponseMap.create
expect(DueDate.done_in_assignment_round(@assignment_due_date.parent_id, response)).to eql 1
end
end
</pre>
* If the function "self.get_next_due_date" works as expected. This involves several invalid test cases as well.
<pre>
describe "#get_next_due_date" do
it "no subsequent due date" do
expect(DueDate.get_next_due_date(@assignment_due_date.parent_id)).to be nil
end

it "nil value throws exception" do
expect { DueDate.get_next_due_date(nil) }.to raise_exception(ActiveRecord::RecordNotFound)
end

it "get next assignment due date" do
due_date = create(:assignment_due_date, deadline_type: @deadline_type,
submission_allowed_id: @deadline_right.id, review_allowed_id: @deadline_right.id,
review_of_review_allowed_id: @deadline_right.id, due_at: Time.zone.now + 5000)
expect(DueDate.get_next_due_date(due_date.parent_id)).to be_valid
end

it "get next due date from topic for staggered deadline" do
assignment_id = create(:assignment, staggered_deadline: true, name: "testassignment").id
due_date = create(:topic_due_date, deadline_type: @deadline_type,
submission_allowed_id: @deadline_right.id, review_allowed_id: @deadline_right.id,
review_of_review_allowed_id: @deadline_right.id, due_at: Time.zone.now + 5000, parent_id: assignment_id)
expect(DueDate.get_next_due_date(assignment_id, due_date.parent_id)).to be_valid
end

it "next due date does not exist for staggered deadline" do
assignment_id = create(:assignment, staggered_deadline: true, name: "testassignment").id
due_date = create(:topic_due_date, deadline_type: @deadline_type,
submission_allowed_id: @deadline_right, review_allowed_id: @deadline_right,
review_of_review_allowed_id: @deadline_right, due_at: Time.zone.now + 5000, parent_id: assignment_id)
expect(DueDate.get_next_due_date(assignment_id)).to be nil
end

it "next due date is before Time.now for staggered deadline" do
assignment_id = create(:assignment, staggered_deadline: true, name: "testassignment").id
due_date = create(:topic_due_date, deadline_type: @deadline_type,
submission_allowed_id: @deadline_right, review_allowed_id: @deadline_right,
review_of_review_allowed_id: @deadline_right, due_at: Time.zone.now - 5000, parent_id: assignment_id)
expect(DueDate.get_next_due_date(assignment_id, due_date.parent_id)).to be nil
end

it "get next due date from assignment for staggered deadline" do
assignment_id = create(:assignment, staggered_deadline: true, name: "testassignment").id
due_date = create(:assignment_due_date, deadline_type: @deadline_type,
submission_allowed_id: @deadline_right, review_allowed_id: @deadline_right,
review_of_review_allowed_id: @deadline_right, due_at: Time.zone.now + 5000, parent_id: assignment_id)
expect(DueDate.get_next_due_date(assignment_id)).to be_valid
end
end
</pre>
* If the function "self.default_permission" returns the correct default permissions for particular deadline and permission types.
<pre>
it "metareview review_of_review_allowed default permission OK" do
expect(DueDate.default_permission('metareview', 'review_of_review_allowed')).to be == DeadlineRight::OK
end
</pre>
<pre>
it "review submission_allowed default permission NO" do
expect(DueDate.default_permission('review', 'submission_allowed')).to be == DeadlineRight::NO
end
</pre>
To test this file run the following command:
<pre>
rspec spec/models/due_date_spec.rb
</pre>
The output of this RSpec file is present in below screenshot:
[[File:Duedaterspec.png]]

Code coverage details of the above RSpec files is present in below screenshot:
[[File:Duedatecoverage.png]]

=== deadline_helper_spec.rb ===
This is a test file for testing the functionalities of Deadline_helper.rb file located at app/helpers. Different test cases present in this file are:
* Check if the factory<ref>http://www.semaphoreci.com|access-date</ref> is valid:
<pre>
it "has a valid factory" do
factory = FactoryGirl.build(:topic_due_date)
expect(factory).to be_valid
end
</pre>
* Fail if the due date is invalid:
<pre>
it "should fail because of invalid due_date" do
expect { DeadlineHelper.create_topic_deadline(nil, 0, 0)}.to raise_exception(NoMethodError)
end
</pre>
* If new due_date object is created:
<pre>
it "new due_date object created" do
DeadlineHelper.create_topic_deadline(@topic_due_date, 0, 1)
expect(TopicDueDate.count).to be == 2
end
</pre>
* due_at should be same for 0 offset:
<pre>
it "due_at should be same for 0 offset" do
DeadlineHelper.create_topic_deadline(@topic_due_date, 0, 10)
new_due_date = TopicDueDate.find_by(parent_id: 10)
expect(new_due_date).to be_valid
expect(new_due_date.due_at.to_s).to be == @topic_due_date.due_at.to_s
end
</pre>
* due_at is calculated correctly if offset is positive:
<pre>
it "due_at calculated correctly for positive offset" do
DeadlineHelper.create_topic_deadline(@topic_due_date, 5000, 10)
new_due_date = TopicDueDate.find_by(parent_id: 10)
expect(new_due_date).to be_valid
expect(new_due_date.due_at.to_s).to be == (Time.zone.parse(@topic_due_date.due_at.to_s) + 5000).to_s
end
</pre>
* due_at is calculated correctly if offset is negative:
<pre>
it "due_at calculated correctly for negative offset" do
DeadlineHelper.create_topic_deadline(@topic_due_date, -5000, 10)
new_due_date = TopicDueDate.find_by(parent_id: 10)
expect(new_due_date).to be_valid
expect(new_due_date.due_at.to_s).to be == (Time.zone.parse(@topic_due_date.due_at.to_s) - 5000).to_s
end
</pre>
* The offset is being converted to integer properly:
<pre>
it "offset converted to integer correctly" do
DeadlineHelper.create_topic_deadline(@topic_due_date, 5000.15, 10)
new_due_date = TopicDueDate.find_by(parent_id: 10)
expect(new_due_date).to be_valid
expect(new_due_date.due_at.to_s).to be == (Time.zone.parse(@topic_due_date.due_at.to_s) + 5000).to_s
end
</pre>
To test this file run the following command:
<pre>
rspec spec/models/deadline_helper_spec.rb
</pre>
The output of this RSpec file is present in below screenshot:
[[File:Deadlinerspec.png]]

Code coverage details of the above RSpec files is present in below screenshot:
[[File:Deadlinecoverage.png]]

=== Testing The System ===
Run the following commands to test the new RSpec files created:
* rspec spec/models/deadline_helper_spec.rb
* rspec spec/models/due_date_spec.rb

==References==
<references/>

CSC/ECE 517 Fall 2016/E1634. Refactor and write unit test of due date.rb and deadline helper.rb

2016-11-05T01:07:09Z

Aagrawa6: /* Testing The System */

== '''Introduction''' ==

=== Expertiza ===
Expertiza<ref>https://expertiza.ncsu.edu/</ref> is an open source project for school assignment management for instructors and students based on the Ruby on Rails<ref>http://www.rubyonrails.org</ref> framework. Expertiza allows the instructor to create new assignments and customise new or existing assignments. It also allows the instructor to create a list of topics the students can sign up for. Students can form teams in Expertiza to work on various projects and assignments. Students can also peer review other students' submissions. Expertiza supports submission across various document types, including the URLs and word documents. Expertiza provides a dashboard for all the assignments corresponding to a course and provides absolute control to the Instructors and Teaching Assistants. In addition to assignments, it encompasses peer reviews wherein participants are allowed to provide feedback anonymously about each other's work thereby providing scope for the better outcome. The due_date.rb file is responsible for informing the users about the deadline for submission of the each assignment. Due dates in Expertiza have their association with many other components like assignments, reviews etc.

=== Code Climate ===
Code Climate<ref>https://codeclimate.com/dashboard</ref> is a tool that runs static analysis on a GitHub project and outputs many details like test coverage, complexity, duplication, security, style, and more. There is a Google Chrome extension to integrate the Code Climate results generated directly into GitHub which is visible when browsing the repository on the browser. It allows us to see issues displayed directly inside GitHub's UI, to review which lines are covered in diffs and files, and add repositories and open tickets without changing your workflow.

== '''Tasks Identified''' ==
To install Code climate Chrome Extension that highlights the duplicated code.

To refactor the following two files:
* due_date.rb
** Ternary operators must not be nested. Prefer `if` or `else` constructs instead.
** Useless assignment to variable - `sorted_deadlines`.
** Prefer `each` over `for`.
** Use `find_by` instead of `where.first`.
** Correct the use of Time function
* deadline_helper.rb
** Do not use `Time.now` without zone. Use one of `Time.zone.now`, `Time.current`, `Time.now.in_time_zone`, `Time.now.utc`, `Time.now.getlocal`, `Time.now.iso8601`, `Time.now.jisx0301`, `Time.now.rfc3339`, `Time.now.to_i`, `Time.now.to_f` instead.
** Trailing whitespace detected.
** Extra empty line detected at module body end.

* Create respective RSpec<ref>http://www.rspec.info</ref> files in /spec/models/ and /spec/helper folder and write unit tests for each method in due_date.rb and deadline_helper.rb.

== '''Current Implementation''' ==
DueDate is a Model class to manage the deadlines of an assignment. It has methods for setting due dates for an assignment, copying due dates from one assignment to a new assignment etc. DeadlineHelper provides helper functions that help DueDate perform certain tasks. The assignment focuses on refactoring some of the methods based on warnings received from Code Climate's static analysis and modifying the language to make it more Ruby-friendly. The assignment also involves writing unit test cases for due_date.rb and deadline_helper.rb in order to increase test coverage.

The goal of this project is to attempt to make this part of the application easier to read and write unit test cases that the application must pass.

== '''Changed Implementation''' ==
Changes implemented involves refactoring the code and making it more understandable by adding comments in the code.

The modified files are
* due_date.rb (path: /app/models)
* deadline_helper.rb (path: /app/helpers)
Testing files
* due_date_spec.rb (path: /spec/models)
* deadline_helper_spec.rb (path: /spec/helpers)

=== due_date.rb ===
* Converted for..in loop to object.each in order to follow better Ruby syntax.
* Unnecessary assignment to sorted_deadlines removed.
* Nested ternary operators have been changed to if..else in order to make it more readable.
[[File:Duedaterb.png]]
* Changed where(...).first to find_by(...) which is the newer recommended syntax.
* Corrected the Time.now functions by adding the correct zones to them such as Time.zone.now.
* Removed trailing whitespaces.
[[File:DueDaterb2.png]]

=== deadline_helper.rb ===
* Time functions were changed to functions with zones
* Extra line removed
[[File:Deadlinehelper.png]]

== '''RSpec testing''' ==
There were no existing tests for the functions in due_date.rb and deadline_helper.rb. We have added exhaustive set of RSpec tests to test all the code. We have added two new spec files 'due_date_spec.rb' and ‘deadline_helper_spec.rb’ which cover the testing scenarios for the functions in ‘due_date.rb’ and ‘deadline_helper.rb’.

For both of these two files, all Travis CI<ref>http://www.travis-ci.com</ref> test cases have passed for all previous test cases as well as the ones added by us with the test coverage for the files due_date.rb and deadline_helper.rb reported as 100%.

These RSpec files have 100% code coverage visible at: /coverage/index.html.

=== due_date_spec.rb ===
This file is located at spec/models and tests the functionalities of the due_date.rb file located in app/models. There are 18 test cases in total which are listed below.
* If the factory is successfully able to build the due_date objects.
<pre>
it "due date factory created successfully" do
expect(@assignment_due_date).to be_valid
end
</pre>
<pre>
it "due dates created correctly" do
expect(@due_dates.length).to be == 10
end
</pre>
* If the function "set_flag" successfully sets the due_date flag.
<pre>
it "due date flag is set" do
expect(@assignment_due_date.flag).to be false
@assignment_due_date.set_flag
expect(@assignment_due_date.flag).to be true
end
</pre>
* If the function "due_at_is_valid_datetime" returns nil (no errors) for a valid datetime in due_at (no invalid test cases can be added here because model does not allow invalid datetime to be set at all).
<pre>
it "due at is valid datetime" do
expect(@assignment_due_date.due_at_is_valid_datetime).to be nil
end
</pre>
* If the function "self.copy" is able to copy due dates from one assignment to another.
<pre>
it "copy due dates to new assignment" do
new_assignment_id = build(:assignment, id: 999).id
old_assignment_id = @assignment_due_date.assignment.id
DueDate.copy(old_assignment_id, new_assignment_id)
expect(DueDate.where(parent_id: new_assignment_id).count).to eql DueDate.where(parent_id: old_assignment_id).count
end
</pre>
* If the function "self.set_duedate" is able to create another due date by copying data from an existing due date object.
<pre>
it "create new duedate record with values" do
DueDate.set_duedate({id: 999}, @assignment_due_date.deadline_type_id,
@assignment_due_date.parent_id, @assignment_due_date.round)
new_due_date = DueDate.find_by(id: 999)
expect(new_due_date).to be_valid
expect(new_due_date.deadline_type_id).to eql @assignment_due_date.deadline_type_id
expect(new_due_date.parent_id).to eql @assignment_due_date.parent_id
expect(new_due_date.round).to eql @assignment_due_date.round
end
</pre>
* If the function "self.deadline_sort" is able to sort the due dates in ascending order.
<pre>
it "sort duedate records" do
sorted_due_dates = @due_dates
expect(sorted_due_dates.each_cons(2).all?{|m1, m2| (m1.due_at <=> m2.due_at) != 1}).to eql false

sorted_due_dates = DueDate.deadline_sort(@due_dates)
expect(sorted_due_dates.each_cons(2).all?{|m1, m2| (m1.due_at <=> m2.due_at) != 1}).to eql true
end
</pre>
* If the function "self.done_in_assignment_round" returns the correct number of rounds for specific inputs. This involves an invalid test case as well for 0 rounds.
<pre>
describe "#done_in_assignment_round" do
it "return 0 when no response map" do
response = ReviewResponseMap.create
response.type = "ResponseMap"
response.save
expect(DueDate.done_in_assignment_round(1, response)).to eql 0
end

it "return round 1 for single round" do
response = ReviewResponseMap.create
expect(DueDate.done_in_assignment_round(@assignment_due_date.parent_id, response)).to eql 1
end
end
</pre>
* If the function "self.get_next_due_date" works as expected. This involves several invalid test cases as well.
<pre>
describe "#get_next_due_date" do
it "no subsequent due date" do
expect(DueDate.get_next_due_date(@assignment_due_date.parent_id)).to be nil
end

it "nil value throws exception" do
expect { DueDate.get_next_due_date(nil) }.to raise_exception(ActiveRecord::RecordNotFound)
end

it "get next assignment due date" do
due_date = create(:assignment_due_date, deadline_type: @deadline_type,
submission_allowed_id: @deadline_right.id, review_allowed_id: @deadline_right.id,
review_of_review_allowed_id: @deadline_right.id, due_at: Time.zone.now + 5000)
expect(DueDate.get_next_due_date(due_date.parent_id)).to be_valid
end

it "get next due date from topic for staggered deadline" do
assignment_id = create(:assignment, staggered_deadline: true, name: "testassignment").id
due_date = create(:topic_due_date, deadline_type: @deadline_type,
submission_allowed_id: @deadline_right.id, review_allowed_id: @deadline_right.id,
review_of_review_allowed_id: @deadline_right.id, due_at: Time.zone.now + 5000, parent_id: assignment_id)
expect(DueDate.get_next_due_date(assignment_id, due_date.parent_id)).to be_valid
end

it "next due date does not exist for staggered deadline" do
assignment_id = create(:assignment, staggered_deadline: true, name: "testassignment").id
due_date = create(:topic_due_date, deadline_type: @deadline_type,
submission_allowed_id: @deadline_right, review_allowed_id: @deadline_right,
review_of_review_allowed_id: @deadline_right, due_at: Time.zone.now + 5000, parent_id: assignment_id)
expect(DueDate.get_next_due_date(assignment_id)).to be nil
end

it "next due date is before Time.now for staggered deadline" do
assignment_id = create(:assignment, staggered_deadline: true, name: "testassignment").id
due_date = create(:topic_due_date, deadline_type: @deadline_type,
submission_allowed_id: @deadline_right, review_allowed_id: @deadline_right,
review_of_review_allowed_id: @deadline_right, due_at: Time.zone.now - 5000, parent_id: assignment_id)
expect(DueDate.get_next_due_date(assignment_id, due_date.parent_id)).to be nil
end

it "get next due date from assignment for staggered deadline" do
assignment_id = create(:assignment, staggered_deadline: true, name: "testassignment").id
due_date = create(:assignment_due_date, deadline_type: @deadline_type,
submission_allowed_id: @deadline_right, review_allowed_id: @deadline_right,
review_of_review_allowed_id: @deadline_right, due_at: Time.zone.now + 5000, parent_id: assignment_id)
expect(DueDate.get_next_due_date(assignment_id)).to be_valid
end
end
</pre>
* If the function "self.default_permission" returns the correct default permissions for particular deadline and permission types.
<pre>
it "metareview review_of_review_allowed default permission OK" do
expect(DueDate.default_permission('metareview', 'review_of_review_allowed')).to be == DeadlineRight::OK
end
</pre>
<pre>
it "review submission_allowed default permission NO" do
expect(DueDate.default_permission('review', 'submission_allowed')).to be == DeadlineRight::NO
end
</pre>
To test this file run the following command:
<pre>
rspec spec/models/due_date_spec.rb
</pre>
The output of this RSpec file is present in below screenshot:
[[File:Duedaterspec.png]]

Code coverage details of the above RSpec files is present in below screenshot:
[[File:Duedatecoverage.png]]

=== deadline_helper_spec.rb ===
This is a test file for testing the functionalities of Deadline_helper.rb file located at app/helpers. Different test cases present in this file are:
* Check if the factory<ref>http://www.semaphoreci.com|access-date</ref> is valid:
<pre>
it "has a valid factory" do
factory = FactoryGirl.build(:topic_due_date)
expect(factory).to be_valid
end
</pre>
* Fail if the due date is invalid:
<pre>
it "should fail because of invalid due_date" do
expect { DeadlineHelper.create_topic_deadline(nil, 0, 0)}.to raise_exception(NoMethodError)
end
</pre>
* If new due_date object is created:
<pre>
it "new due_date object created" do
DeadlineHelper.create_topic_deadline(@topic_due_date, 0, 1)
expect(TopicDueDate.count).to be == 2
end
</pre>
* due_at should be same for 0 offset:
<pre>
it "due_at should be same for 0 offset" do
DeadlineHelper.create_topic_deadline(@topic_due_date, 0, 10)
new_due_date = TopicDueDate.find_by(parent_id: 10)
expect(new_due_date).to be_valid
expect(new_due_date.due_at.to_s).to be == @topic_due_date.due_at.to_s
end
</pre>
* due_at is calculated correctly if offset is positive:
<pre>
it "due_at calculated correctly for positive offset" do
DeadlineHelper.create_topic_deadline(@topic_due_date, 5000, 10)
new_due_date = TopicDueDate.find_by(parent_id: 10)
expect(new_due_date).to be_valid
expect(new_due_date.due_at.to_s).to be == (Time.zone.parse(@topic_due_date.due_at.to_s) + 5000).to_s
end
</pre>
* due_at is calculated correctly if offset is negative:
<pre>
it "due_at calculated correctly for negative offset" do
DeadlineHelper.create_topic_deadline(@topic_due_date, -5000, 10)
new_due_date = TopicDueDate.find_by(parent_id: 10)
expect(new_due_date).to be_valid
expect(new_due_date.due_at.to_s).to be == (Time.zone.parse(@topic_due_date.due_at.to_s) - 5000).to_s
end
</pre>
* The offset is being converted to integer properly:
<pre>
it "offset converted to integer correctly" do
DeadlineHelper.create_topic_deadline(@topic_due_date, 5000.15, 10)
new_due_date = TopicDueDate.find_by(parent_id: 10)
expect(new_due_date).to be_valid
expect(new_due_date.due_at.to_s).to be == (Time.zone.parse(@topic_due_date.due_at.to_s) + 5000).to_s
end
</pre>
To test this file run the following command:
<pre>
rspec spec/models/deadline_helper_spec.rb
</pre>
The output of this RSpec file is present in below screenshot:
[[File:Deadlinerspec.png]]

Code coverage details of the above RSpec files is present in below screenshot:
[[File:Deadlinecoverage.png]]

=== Testing The System ===
Run the following commands to test the new RSpec files created: 
1. rspec spec/models/deadline_helper_spec.rb 
2. rspec spec/models/due_date_spec.rb 

==References==
<references/>

CSC/ECE 517 Fall 2016/E1634. Refactor and write unit test of due date.rb and deadline helper.rb

2016-11-05T01:06:45Z

Aagrawa6: Testing the System Section Added

== '''Introduction''' ==

=== Expertiza ===
Expertiza<ref>https://expertiza.ncsu.edu/</ref> is an open source project for school assignment management for instructors and students based on the Ruby on Rails<ref>http://www.rubyonrails.org</ref> framework. Expertiza allows the instructor to create new assignments and customise new or existing assignments. It also allows the instructor to create a list of topics the students can sign up for. Students can form teams in Expertiza to work on various projects and assignments. Students can also peer review other students' submissions. Expertiza supports submission across various document types, including the URLs and word documents. Expertiza provides a dashboard for all the assignments corresponding to a course and provides absolute control to the Instructors and Teaching Assistants. In addition to assignments, it encompasses peer reviews wherein participants are allowed to provide feedback anonymously about each other's work thereby providing scope for the better outcome. The due_date.rb file is responsible for informing the users about the deadline for submission of the each assignment. Due dates in Expertiza have their association with many other components like assignments, reviews etc.

=== Code Climate ===
Code Climate<ref>https://codeclimate.com/dashboard</ref> is a tool that runs static analysis on a GitHub project and outputs many details like test coverage, complexity, duplication, security, style, and more. There is a Google Chrome extension to integrate the Code Climate results generated directly into GitHub which is visible when browsing the repository on the browser. It allows us to see issues displayed directly inside GitHub's UI, to review which lines are covered in diffs and files, and add repositories and open tickets without changing your workflow.

== '''Tasks Identified''' ==
To install Code climate Chrome Extension that highlights the duplicated code.

To refactor the following two files:
* due_date.rb
** Ternary operators must not be nested. Prefer `if` or `else` constructs instead.
** Useless assignment to variable - `sorted_deadlines`.
** Prefer `each` over `for`.
** Use `find_by` instead of `where.first`.
** Correct the use of Time function
* deadline_helper.rb
** Do not use `Time.now` without zone. Use one of `Time.zone.now`, `Time.current`, `Time.now.in_time_zone`, `Time.now.utc`, `Time.now.getlocal`, `Time.now.iso8601`, `Time.now.jisx0301`, `Time.now.rfc3339`, `Time.now.to_i`, `Time.now.to_f` instead.
** Trailing whitespace detected.
** Extra empty line detected at module body end.

* Create respective RSpec<ref>http://www.rspec.info</ref> files in /spec/models/ and /spec/helper folder and write unit tests for each method in due_date.rb and deadline_helper.rb.

== '''Current Implementation''' ==
DueDate is a Model class to manage the deadlines of an assignment. It has methods for setting due dates for an assignment, copying due dates from one assignment to a new assignment etc. DeadlineHelper provides helper functions that help DueDate perform certain tasks. The assignment focuses on refactoring some of the methods based on warnings received from Code Climate's static analysis and modifying the language to make it more Ruby-friendly. The assignment also involves writing unit test cases for due_date.rb and deadline_helper.rb in order to increase test coverage.

The goal of this project is to attempt to make this part of the application easier to read and write unit test cases that the application must pass.

== '''Changed Implementation''' ==
Changes implemented involves refactoring the code and making it more understandable by adding comments in the code.

The modified files are
* due_date.rb (path: /app/models)
* deadline_helper.rb (path: /app/helpers)
Testing files
* due_date_spec.rb (path: /spec/models)
* deadline_helper_spec.rb (path: /spec/helpers)

=== due_date.rb ===
* Converted for..in loop to object.each in order to follow better Ruby syntax.
* Unnecessary assignment to sorted_deadlines removed.
* Nested ternary operators have been changed to if..else in order to make it more readable.
[[File:Duedaterb.png]]
* Changed where(...).first to find_by(...) which is the newer recommended syntax.
* Corrected the Time.now functions by adding the correct zones to them such as Time.zone.now.
* Removed trailing whitespaces.
[[File:DueDaterb2.png]]

=== deadline_helper.rb ===
* Time functions were changed to functions with zones
* Extra line removed
[[File:Deadlinehelper.png]]

== '''RSpec testing''' ==
There were no existing tests for the functions in due_date.rb and deadline_helper.rb. We have added exhaustive set of RSpec tests to test all the code. We have added two new spec files 'due_date_spec.rb' and ‘deadline_helper_spec.rb’ which cover the testing scenarios for the functions in ‘due_date.rb’ and ‘deadline_helper.rb’.

For both of these two files, all Travis CI<ref>http://www.travis-ci.com</ref> test cases have passed for all previous test cases as well as the ones added by us with the test coverage for the files due_date.rb and deadline_helper.rb reported as 100%.

These RSpec files have 100% code coverage visible at: /coverage/index.html.

=== due_date_spec.rb ===
This file is located at spec/models and tests the functionalities of the due_date.rb file located in app/models. There are 18 test cases in total which are listed below.
* If the factory is successfully able to build the due_date objects.
<pre>
it "due date factory created successfully" do
expect(@assignment_due_date).to be_valid
end
</pre>
<pre>
it "due dates created correctly" do
expect(@due_dates.length).to be == 10
end
</pre>
* If the function "set_flag" successfully sets the due_date flag.
<pre>
it "due date flag is set" do
expect(@assignment_due_date.flag).to be false
@assignment_due_date.set_flag
expect(@assignment_due_date.flag).to be true
end
</pre>
* If the function "due_at_is_valid_datetime" returns nil (no errors) for a valid datetime in due_at (no invalid test cases can be added here because model does not allow invalid datetime to be set at all).
<pre>
it "due at is valid datetime" do
expect(@assignment_due_date.due_at_is_valid_datetime).to be nil
end
</pre>
* If the function "self.copy" is able to copy due dates from one assignment to another.
<pre>
it "copy due dates to new assignment" do
new_assignment_id = build(:assignment, id: 999).id
old_assignment_id = @assignment_due_date.assignment.id
DueDate.copy(old_assignment_id, new_assignment_id)
expect(DueDate.where(parent_id: new_assignment_id).count).to eql DueDate.where(parent_id: old_assignment_id).count
end
</pre>
* If the function "self.set_duedate" is able to create another due date by copying data from an existing due date object.
<pre>
it "create new duedate record with values" do
DueDate.set_duedate({id: 999}, @assignment_due_date.deadline_type_id,
@assignment_due_date.parent_id, @assignment_due_date.round)
new_due_date = DueDate.find_by(id: 999)
expect(new_due_date).to be_valid
expect(new_due_date.deadline_type_id).to eql @assignment_due_date.deadline_type_id
expect(new_due_date.parent_id).to eql @assignment_due_date.parent_id
expect(new_due_date.round).to eql @assignment_due_date.round
end
</pre>
* If the function "self.deadline_sort" is able to sort the due dates in ascending order.
<pre>
it "sort duedate records" do
sorted_due_dates = @due_dates
expect(sorted_due_dates.each_cons(2).all?{|m1, m2| (m1.due_at <=> m2.due_at) != 1}).to eql false

sorted_due_dates = DueDate.deadline_sort(@due_dates)
expect(sorted_due_dates.each_cons(2).all?{|m1, m2| (m1.due_at <=> m2.due_at) != 1}).to eql true
end
</pre>
* If the function "self.done_in_assignment_round" returns the correct number of rounds for specific inputs. This involves an invalid test case as well for 0 rounds.
<pre>
describe "#done_in_assignment_round" do
it "return 0 when no response map" do
response = ReviewResponseMap.create
response.type = "ResponseMap"
response.save
expect(DueDate.done_in_assignment_round(1, response)).to eql 0
end

it "return round 1 for single round" do
response = ReviewResponseMap.create
expect(DueDate.done_in_assignment_round(@assignment_due_date.parent_id, response)).to eql 1
end
end
</pre>
* If the function "self.get_next_due_date" works as expected. This involves several invalid test cases as well.
<pre>
describe "#get_next_due_date" do
it "no subsequent due date" do
expect(DueDate.get_next_due_date(@assignment_due_date.parent_id)).to be nil
end

it "nil value throws exception" do
expect { DueDate.get_next_due_date(nil) }.to raise_exception(ActiveRecord::RecordNotFound)
end

it "get next assignment due date" do
due_date = create(:assignment_due_date, deadline_type: @deadline_type,
submission_allowed_id: @deadline_right.id, review_allowed_id: @deadline_right.id,
review_of_review_allowed_id: @deadline_right.id, due_at: Time.zone.now + 5000)
expect(DueDate.get_next_due_date(due_date.parent_id)).to be_valid
end

it "get next due date from topic for staggered deadline" do
assignment_id = create(:assignment, staggered_deadline: true, name: "testassignment").id
due_date = create(:topic_due_date, deadline_type: @deadline_type,
submission_allowed_id: @deadline_right.id, review_allowed_id: @deadline_right.id,
review_of_review_allowed_id: @deadline_right.id, due_at: Time.zone.now + 5000, parent_id: assignment_id)
expect(DueDate.get_next_due_date(assignment_id, due_date.parent_id)).to be_valid
end

it "next due date does not exist for staggered deadline" do
assignment_id = create(:assignment, staggered_deadline: true, name: "testassignment").id
due_date = create(:topic_due_date, deadline_type: @deadline_type,
submission_allowed_id: @deadline_right, review_allowed_id: @deadline_right,
review_of_review_allowed_id: @deadline_right, due_at: Time.zone.now + 5000, parent_id: assignment_id)
expect(DueDate.get_next_due_date(assignment_id)).to be nil
end

it "next due date is before Time.now for staggered deadline" do
assignment_id = create(:assignment, staggered_deadline: true, name: "testassignment").id
due_date = create(:topic_due_date, deadline_type: @deadline_type,
submission_allowed_id: @deadline_right, review_allowed_id: @deadline_right,
review_of_review_allowed_id: @deadline_right, due_at: Time.zone.now - 5000, parent_id: assignment_id)
expect(DueDate.get_next_due_date(assignment_id, due_date.parent_id)).to be nil
end

it "get next due date from assignment for staggered deadline" do
assignment_id = create(:assignment, staggered_deadline: true, name: "testassignment").id
due_date = create(:assignment_due_date, deadline_type: @deadline_type,
submission_allowed_id: @deadline_right, review_allowed_id: @deadline_right,
review_of_review_allowed_id: @deadline_right, due_at: Time.zone.now + 5000, parent_id: assignment_id)
expect(DueDate.get_next_due_date(assignment_id)).to be_valid
end
end
</pre>
* If the function "self.default_permission" returns the correct default permissions for particular deadline and permission types.
<pre>
it "metareview review_of_review_allowed default permission OK" do
expect(DueDate.default_permission('metareview', 'review_of_review_allowed')).to be == DeadlineRight::OK
end
</pre>
<pre>
it "review submission_allowed default permission NO" do
expect(DueDate.default_permission('review', 'submission_allowed')).to be == DeadlineRight::NO
end
</pre>
To test this file run the following command:
<pre>
rspec spec/models/due_date_spec.rb
</pre>
The output of this RSpec file is present in below screenshot:
[[File:Duedaterspec.png]]

Code coverage details of the above RSpec files is present in below screenshot:
[[File:Duedatecoverage.png]]

=== deadline_helper_spec.rb ===
This is a test file for testing the functionalities of Deadline_helper.rb file located at app/helpers. Different test cases present in this file are:
* Check if the factory<ref>http://www.semaphoreci.com|access-date</ref> is valid:
<pre>
it "has a valid factory" do
factory = FactoryGirl.build(:topic_due_date)
expect(factory).to be_valid
end
</pre>
* Fail if the due date is invalid:
<pre>
it "should fail because of invalid due_date" do
expect { DeadlineHelper.create_topic_deadline(nil, 0, 0)}.to raise_exception(NoMethodError)
end
</pre>
* If new due_date object is created:
<pre>
it "new due_date object created" do
DeadlineHelper.create_topic_deadline(@topic_due_date, 0, 1)
expect(TopicDueDate.count).to be == 2
end
</pre>
* due_at should be same for 0 offset:
<pre>
it "due_at should be same for 0 offset" do
DeadlineHelper.create_topic_deadline(@topic_due_date, 0, 10)
new_due_date = TopicDueDate.find_by(parent_id: 10)
expect(new_due_date).to be_valid
expect(new_due_date.due_at.to_s).to be == @topic_due_date.due_at.to_s
end
</pre>
* due_at is calculated correctly if offset is positive:
<pre>
it "due_at calculated correctly for positive offset" do
DeadlineHelper.create_topic_deadline(@topic_due_date, 5000, 10)
new_due_date = TopicDueDate.find_by(parent_id: 10)
expect(new_due_date).to be_valid
expect(new_due_date.due_at.to_s).to be == (Time.zone.parse(@topic_due_date.due_at.to_s) + 5000).to_s
end
</pre>
* due_at is calculated correctly if offset is negative:
<pre>
it "due_at calculated correctly for negative offset" do
DeadlineHelper.create_topic_deadline(@topic_due_date, -5000, 10)
new_due_date = TopicDueDate.find_by(parent_id: 10)
expect(new_due_date).to be_valid
expect(new_due_date.due_at.to_s).to be == (Time.zone.parse(@topic_due_date.due_at.to_s) - 5000).to_s
end
</pre>
* The offset is being converted to integer properly:
<pre>
it "offset converted to integer correctly" do
DeadlineHelper.create_topic_deadline(@topic_due_date, 5000.15, 10)
new_due_date = TopicDueDate.find_by(parent_id: 10)
expect(new_due_date).to be_valid
expect(new_due_date.due_at.to_s).to be == (Time.zone.parse(@topic_due_date.due_at.to_s) + 5000).to_s
end
</pre>
To test this file run the following command:
<pre>
rspec spec/models/deadline_helper_spec.rb
</pre>
The output of this RSpec file is present in below screenshot:
[[File:Deadlinerspec.png]]

Code coverage details of the above RSpec files is present in below screenshot:
[[File:Deadlinecoverage.png]]

=== Testing The System ===
Run the following commands to test the new RSpec files created:
1. rspec spec/models/deadline_helper_spec.rb
2. rspec spec/models/due_date_spec.rb

==References==
<references/>

CSC/ECE 517 Fall 2016/E1634. Refactor and write unit test of due date.rb and deadline helper.rb

2016-10-29T01:53:12Z

Aagrawa6: References Added

CSC/ECE 517 Fall 2016/E1634. Refactor and write unit test of due date.rb and deadline helper.rb

2016-10-29T01:52:10Z

Aagrawa6: /* Expertiza */

== '''Introduction''' ==

=== Expertiza ===
Expertiza<ref>{{Cite web|url=https://expertiza.ncsu.edu/|title=|last=|first=|date=|website=|publisher=|access-date=}}</ref> is an open source project for school assignment management for instructors and students based on the Ruby on Rails<ref>http://www.rubyonrails.org</ref> framework. Expertiza allows the instructor to create new assignments and customise new or existing assignments. It also allows the instructor to create a list of topics the students can sign up for. Students can form teams in Expertiza to work on various projects and assignments. Students can also peer review other students' submissions. Expertiza supports submission across various document types, including the URLs and word documents. Expertiza provides a dashboard for all the assignments corresponding to a course and provides absolute control to the Instructors and Teaching Assistants. In addition to assignments, it encompasses peer reviews wherein participants are allowed to provide feedback anonymously about each other's work thereby providing scope for the better outcome. The due_date.rb file is responsible for informing the users about the deadline for submission of the each assignment. Due dates in Expertiza have their association with many other components like assignments, reviews etc.

=== Code Climate ===
Code Climate<ref>https://codeclimate.com/dashboard</ref> is a tool that runs static analysis on a GitHub project and outputs many details like test coverage, complexity, duplication, security, style, and more. There is a Google Chrome extension to integrate the Code Climate results generated directly into GitHub which is visible when browsing the repository on the browser. It allows us to see issues displayed directly inside GitHub's UI, to review which lines are covered in diffs and files, and add repositories and open tickets without changing your workflow.

== '''Tasks Identified''' ==
To install Code climate Chrome Extension that highlights the duplicated code.

To refactor the following two files:
* due_date.rb
** Ternary operators must not be nested. Prefer `if` or `else` constructs instead.
** Useless assignment to variable - `sorted_deadlines`.
** Prefer `each` over `for`.
** Use `find_by` instead of `where.first`.
** Correct the use of Time function
* deadline_helper.rb
** Do not use `Time.now` without zone. Use one of `Time.zone.now`, `Time.current`, `Time.now.in_time_zone`, `Time.now.utc`, `Time.now.getlocal`, `Time.now.iso8601`, `Time.now.jisx0301`, `Time.now.rfc3339`, `Time.now.to_i`, `Time.now.to_f` instead.
** Trailing whitespace detected.
** Extra empty line detected at module body end.

* Create respective RSpec<ref>http://www.rspec.info</ref> files in /spec/models/ and /spec/helper folder and write unit tests for each method in due_date.rb and deadline_helper.rb.

== '''Current Implementation''' ==
DueDate is a Model class to manage the deadlines of an assignment. It has methods for setting due dates for an assignment, copying due dates from one assignment to a new assignment etc. DeadlineHelper provides helper functions that help DueDate perform certain tasks. The assignment focuses on refactoring some of the methods based on warnings received from Code Climate's static analysis and modifying the language to make it more Ruby-friendly. The assignment also involves writing unit test cases for due_date.rb and deadline_helper.rb in order to increase test coverage.

The goal of this project is to attempt to make this part of the application easier to read and write unit test cases that the application must pass.

== '''Changed Implementation''' ==
Changes implemented involves refactoring the code and making it more understandable by adding comments in the code.

The modified files are
* due_date.rb (path: /app/models)
* deadline_helper.rb (path: /app/helpers)
Testing files
* due_date_spec.rb (path: /spec/models)
* deadline_helper_spec.rb (path: /spec/helpers)

=== due_date.rb ===
* Converted for..in loop to object.each in order to follow better Ruby syntax.
* Unnecessary assignment to sorted_deadlines removed.
* Nested ternary operators have been changed to if..else in order to make it more readable.
[[File:Duedaterb.png]]
* Changed where(...).first to find_by(...) which is the newer recommended syntax.
* Corrected the Time.now functions by adding the correct zones to them such as Time.zone.now.
* Removed trailing whitespaces.
[[File:DueDaterb2.png]]

=== deadline_helper.rb ===
* Time functions were changed to functions with zones
* Extra line removed
[[File:Deadlinehelper.png]]

== '''RSpec testing''' ==
There were no existing tests for the functions in due_date.rb and deadline_helper.rb. We have added exhaustive set of RSpec tests to test all the code. We have added two new spec files 'due_date_spec.rb' and ‘deadline_helper_spec.rb’ which cover the testing scenarios for the functions in ‘due_date.rb’ and ‘deadline_helper.rb’.

For both of these two files, all Travis CI<ref>http://www.travis-ci.com</ref> test cases have passed for all previous test cases as well as the ones added by us with the test coverage for the files due_date.rb and deadline_helper.rb reported as 100%.

These RSpec files have 100% code coverage visible at: /coverage/index.html.

=== due_date_spec.rb ===
This file is located at spec/models and tests the functionalities of the due_date.rb file located in app/models. There are 18 test cases in total which are listed below.
* If the factory is successfully able to build the due_date objects.
<pre>
it "due date factory created successfully" do
expect(@assignment_due_date).to be_valid
end
</pre>
<pre>
it "due dates created correctly" do
expect(@due_dates.length).to be == 10
end
</pre>
* If the function "set_flag" successfully sets the due_date flag.
<pre>
it "due date flag is set" do
expect(@assignment_due_date.flag).to be false
@assignment_due_date.set_flag
expect(@assignment_due_date.flag).to be true
end
</pre>
* If the function "due_at_is_valid_datetime" returns nil (no errors) for a valid datetime in due_at (no invalid test cases can be added here because model does not allow invalid datetime to be set at all).
<pre>
it "due at is valid datetime" do
expect(@assignment_due_date.due_at_is_valid_datetime).to be nil
end
</pre>
* If the function "self.copy" is able to copy due dates from one assignment to another.
<pre>
it "copy due dates to new assignment" do
new_assignment_id = build(:assignment, id: 999).id
old_assignment_id = @assignment_due_date.assignment.id
DueDate.copy(old_assignment_id, new_assignment_id)
expect(DueDate.where(parent_id: new_assignment_id).count).to eql DueDate.where(parent_id: old_assignment_id).count
end
</pre>
* If the function "self.set_duedate" is able to create another due date by copying data from an existing due date object.
<pre>
it "create new duedate record with values" do
DueDate.set_duedate({id: 999}, @assignment_due_date.deadline_type_id,
@assignment_due_date.parent_id, @assignment_due_date.round)
new_due_date = DueDate.find_by(id: 999)
expect(new_due_date).to be_valid
expect(new_due_date.deadline_type_id).to eql @assignment_due_date.deadline_type_id
expect(new_due_date.parent_id).to eql @assignment_due_date.parent_id
expect(new_due_date.round).to eql @assignment_due_date.round
end
</pre>
* If the function "self.deadline_sort" is able to sort the due dates in ascending order.
<pre>
it "sort duedate records" do
sorted_due_dates = @due_dates
expect(sorted_due_dates.each_cons(2).all?{|m1, m2| (m1.due_at <=> m2.due_at) != 1}).to eql false

sorted_due_dates = DueDate.deadline_sort(@due_dates)
expect(sorted_due_dates.each_cons(2).all?{|m1, m2| (m1.due_at <=> m2.due_at) != 1}).to eql true
end
</pre>
* If the function "self.done_in_assignment_round" returns the correct number of rounds for specific inputs. This involves an invalid test case as well for 0 rounds.
<pre>
describe "#done_in_assignment_round" do
it "return 0 when no response map" do
response = ReviewResponseMap.create
response.type = "ResponseMap"
response.save
expect(DueDate.done_in_assignment_round(1, response)).to eql 0
end

it "return round 1 for single round" do
response = ReviewResponseMap.create
expect(DueDate.done_in_assignment_round(@assignment_due_date.parent_id, response)).to eql 1
end
end
</pre>
* If the function "self.get_next_due_date" works as expected. This involves several invalid test cases as well.
<pre>
describe "#get_next_due_date" do
it "no subsequent due date" do
expect(DueDate.get_next_due_date(@assignment_due_date.parent_id)).to be nil
end

it "nil value throws exception" do
expect { DueDate.get_next_due_date(nil) }.to raise_exception(ActiveRecord::RecordNotFound)
end

it "get next assignment due date" do
due_date = create(:assignment_due_date, deadline_type: @deadline_type,
submission_allowed_id: @deadline_right.id, review_allowed_id: @deadline_right.id,
review_of_review_allowed_id: @deadline_right.id, due_at: Time.zone.now + 5000)
expect(DueDate.get_next_due_date(due_date.parent_id)).to be_valid
end

it "get next due date from topic for staggered deadline" do
assignment_id = create(:assignment, staggered_deadline: true, name: "testassignment").id
due_date = create(:topic_due_date, deadline_type: @deadline_type,
submission_allowed_id: @deadline_right.id, review_allowed_id: @deadline_right.id,
review_of_review_allowed_id: @deadline_right.id, due_at: Time.zone.now + 5000, parent_id: assignment_id)
expect(DueDate.get_next_due_date(assignment_id, due_date.parent_id)).to be_valid
end

it "next due date does not exist for staggered deadline" do
assignment_id = create(:assignment, staggered_deadline: true, name: "testassignment").id
due_date = create(:topic_due_date, deadline_type: @deadline_type,
submission_allowed_id: @deadline_right, review_allowed_id: @deadline_right,
review_of_review_allowed_id: @deadline_right, due_at: Time.zone.now + 5000, parent_id: assignment_id)
expect(DueDate.get_next_due_date(assignment_id)).to be nil
end

it "next due date is before Time.now for staggered deadline" do
assignment_id = create(:assignment, staggered_deadline: true, name: "testassignment").id
due_date = create(:topic_due_date, deadline_type: @deadline_type,
submission_allowed_id: @deadline_right, review_allowed_id: @deadline_right,
review_of_review_allowed_id: @deadline_right, due_at: Time.zone.now - 5000, parent_id: assignment_id)
expect(DueDate.get_next_due_date(assignment_id, due_date.parent_id)).to be nil
end

it "get next due date from assignment for staggered deadline" do
assignment_id = create(:assignment, staggered_deadline: true, name: "testassignment").id
due_date = create(:assignment_due_date, deadline_type: @deadline_type,
submission_allowed_id: @deadline_right, review_allowed_id: @deadline_right,
review_of_review_allowed_id: @deadline_right, due_at: Time.zone.now + 5000, parent_id: assignment_id)
expect(DueDate.get_next_due_date(assignment_id)).to be_valid
end
end
</pre>
* If the function "self.default_permission" returns the correct default permissions for particular deadline and permission types.
<pre>
it "metareview review_of_review_allowed default permission OK" do
expect(DueDate.default_permission('metareview', 'review_of_review_allowed')).to be == DeadlineRight::OK
end
</pre>
<pre>
it "review submission_allowed default permission NO" do
expect(DueDate.default_permission('review', 'submission_allowed')).to be == DeadlineRight::NO
end
</pre>
To test this file run the following command:
<pre>
rspec spec/models/due_date_spec.rb
</pre>
The output of this RSpec file is present in below screenshot:
[[File:Duedaterspec.png]]

Code coverage details of the above RSpec files is present in below screenshot:
[[File:Duedatecoverage.png]]

=== deadline_helper_spec.rb ===
This is a test file for testing the functionalities of Deadline_helper.rb file located at app/helpers. Different test cases present in this file are:
* Check if the factory<ref>http://www.semaphoreci.com|access-date</ref> is valid:
<pre>
it "has a valid factory" do
factory = FactoryGirl.build(:topic_due_date)
expect(factory).to be_valid
end
</pre>
* Fail if the due date is invalid:
<pre>
it "should fail because of invalid due_date" do
expect { DeadlineHelper.create_topic_deadline(nil, 0, 0)}.to raise_exception(NoMethodError)
end
</pre>
* If new due_date object is created:
<pre>
it "new due_date object created" do
DeadlineHelper.create_topic_deadline(@topic_due_date, 0, 1)
expect(TopicDueDate.count).to be == 2
end
</pre>
* due_at should be same for 0 offset:
<pre>
it "due_at should be same for 0 offset" do
DeadlineHelper.create_topic_deadline(@topic_due_date, 0, 10)
new_due_date = TopicDueDate.find_by(parent_id: 10)
expect(new_due_date).to be_valid
expect(new_due_date.due_at.to_s).to be == @topic_due_date.due_at.to_s
end
</pre>
* due_at is calculated correctly if offset is positive:
<pre>
it "due_at calculated correctly for positive offset" do
DeadlineHelper.create_topic_deadline(@topic_due_date, 5000, 10)
new_due_date = TopicDueDate.find_by(parent_id: 10)
expect(new_due_date).to be_valid
expect(new_due_date.due_at.to_s).to be == (Time.zone.parse(@topic_due_date.due_at.to_s) + 5000).to_s
end
</pre>
* due_at is calculated correctly if offset is negative:
<pre>
it "due_at calculated correctly for negative offset" do
DeadlineHelper.create_topic_deadline(@topic_due_date, -5000, 10)
new_due_date = TopicDueDate.find_by(parent_id: 10)
expect(new_due_date).to be_valid
expect(new_due_date.due_at.to_s).to be == (Time.zone.parse(@topic_due_date.due_at.to_s) - 5000).to_s
end
</pre>
* The offset is being converted to integer properly:
<pre>
it "offset converted to integer correctly" do
DeadlineHelper.create_topic_deadline(@topic_due_date, 5000.15, 10)
new_due_date = TopicDueDate.find_by(parent_id: 10)
expect(new_due_date).to be_valid
expect(new_due_date.due_at.to_s).to be == (Time.zone.parse(@topic_due_date.due_at.to_s) + 5000).to_s
end
</pre>
To test this file run the following command:
<pre>
rspec spec/models/deadline_helper_spec.rb
</pre>
The output of this RSpec file is present in below screenshot:
[[File:Deadlinerspec.png]]

Code coverage details of the above RSpec files is present in below screenshot:
[[File:Deadlinecoverage.png]]

==References==
<references/>

CSC/ECE 517 Fall 2016/E1634. Refactor and write unit test of due date.rb and deadline helper.rb

2016-10-29T01:51:39Z

Aagrawa6: /* Sources and Citations */

== '''Introduction''' ==

=== Expertiza ===
Expertiza<ref>http://www.expertiza.ncsu.edu</ref>{{Reflist}} is an open source project for school assignment management for instructors and students based on the Ruby on Rails<ref>http://www.rubyonrails.org</ref> framework. Expertiza allows the instructor to create new assignments and customise new or existing assignments. It also allows the instructor to create a list of topics the students can sign up for. Students can form teams in Expertiza to work on various projects and assignments. Students can also peer review other students' submissions. Expertiza supports submission across various document types, including the URLs and word documents. Expertiza provides a dashboard for all the assignments corresponding to a course and provides absolute control to the Instructors and Teaching Assistants. In addition to assignments, it encompasses peer reviews wherein participants are allowed to provide feedback anonymously about each other's work thereby providing scope for the better outcome. The due_date.rb file is responsible for informing the users about the deadline for submission of the each assignment. Due dates in Expertiza have their association with many other components like assignments, reviews etc.

=== Code Climate ===
Code Climate<ref>https://codeclimate.com/dashboard</ref> is a tool that runs static analysis on a GitHub project and outputs many details like test coverage, complexity, duplication, security, style, and more. There is a Google Chrome extension to integrate the Code Climate results generated directly into GitHub which is visible when browsing the repository on the browser. It allows us to see issues displayed directly inside GitHub's UI, to review which lines are covered in diffs and files, and add repositories and open tickets without changing your workflow.

== '''Tasks Identified''' ==
To install Code climate Chrome Extension that highlights the duplicated code.

To refactor the following two files:
* due_date.rb
** Ternary operators must not be nested. Prefer `if` or `else` constructs instead.
** Useless assignment to variable - `sorted_deadlines`.
** Prefer `each` over `for`.
** Use `find_by` instead of `where.first`.
** Correct the use of Time function
* deadline_helper.rb
** Do not use `Time.now` without zone. Use one of `Time.zone.now`, `Time.current`, `Time.now.in_time_zone`, `Time.now.utc`, `Time.now.getlocal`, `Time.now.iso8601`, `Time.now.jisx0301`, `Time.now.rfc3339`, `Time.now.to_i`, `Time.now.to_f` instead.
** Trailing whitespace detected.
** Extra empty line detected at module body end.

* Create respective RSpec<ref>http://www.rspec.info</ref> files in /spec/models/ and /spec/helper folder and write unit tests for each method in due_date.rb and deadline_helper.rb.

== '''Current Implementation''' ==
DueDate is a Model class to manage the deadlines of an assignment. It has methods for setting due dates for an assignment, copying due dates from one assignment to a new assignment etc. DeadlineHelper provides helper functions that help DueDate perform certain tasks. The assignment focuses on refactoring some of the methods based on warnings received from Code Climate's static analysis and modifying the language to make it more Ruby-friendly. The assignment also involves writing unit test cases for due_date.rb and deadline_helper.rb in order to increase test coverage.

The goal of this project is to attempt to make this part of the application easier to read and write unit test cases that the application must pass.

== '''Changed Implementation''' ==
Changes implemented involves refactoring the code and making it more understandable by adding comments in the code.

The modified files are
* due_date.rb (path: /app/models)
* deadline_helper.rb (path: /app/helpers)
Testing files
* due_date_spec.rb (path: /spec/models)
* deadline_helper_spec.rb (path: /spec/helpers)

=== due_date.rb ===
* Converted for..in loop to object.each in order to follow better Ruby syntax.
* Unnecessary assignment to sorted_deadlines removed.
* Nested ternary operators have been changed to if..else in order to make it more readable.
[[File:Duedaterb.png]]
* Changed where(...).first to find_by(...) which is the newer recommended syntax.
* Corrected the Time.now functions by adding the correct zones to them such as Time.zone.now.
* Removed trailing whitespaces.
[[File:DueDaterb2.png]]

=== deadline_helper.rb ===
* Time functions were changed to functions with zones
* Extra line removed
[[File:Deadlinehelper.png]]

== '''RSpec testing''' ==
There were no existing tests for the functions in due_date.rb and deadline_helper.rb. We have added exhaustive set of RSpec tests to test all the code. We have added two new spec files 'due_date_spec.rb' and ‘deadline_helper_spec.rb’ which cover the testing scenarios for the functions in ‘due_date.rb’ and ‘deadline_helper.rb’.

For both of these two files, all Travis CI<ref>http://www.travis-ci.com</ref> test cases have passed for all previous test cases as well as the ones added by us with the test coverage for the files due_date.rb and deadline_helper.rb reported as 100%.

These RSpec files have 100% code coverage visible at: /coverage/index.html.

=== due_date_spec.rb ===
This file is located at spec/models and tests the functionalities of the due_date.rb file located in app/models. There are 18 test cases in total which are listed below.
* If the factory is successfully able to build the due_date objects.
<pre>
it "due date factory created successfully" do
expect(@assignment_due_date).to be_valid
end
</pre>
<pre>
it "due dates created correctly" do
expect(@due_dates.length).to be == 10
end
</pre>
* If the function "set_flag" successfully sets the due_date flag.
<pre>
it "due date flag is set" do
expect(@assignment_due_date.flag).to be false
@assignment_due_date.set_flag
expect(@assignment_due_date.flag).to be true
end
</pre>
* If the function "due_at_is_valid_datetime" returns nil (no errors) for a valid datetime in due_at (no invalid test cases can be added here because model does not allow invalid datetime to be set at all).
<pre>
it "due at is valid datetime" do
expect(@assignment_due_date.due_at_is_valid_datetime).to be nil
end
</pre>
* If the function "self.copy" is able to copy due dates from one assignment to another.
<pre>
it "copy due dates to new assignment" do
new_assignment_id = build(:assignment, id: 999).id
old_assignment_id = @assignment_due_date.assignment.id
DueDate.copy(old_assignment_id, new_assignment_id)
expect(DueDate.where(parent_id: new_assignment_id).count).to eql DueDate.where(parent_id: old_assignment_id).count
end
</pre>
* If the function "self.set_duedate" is able to create another due date by copying data from an existing due date object.
<pre>
it "create new duedate record with values" do
DueDate.set_duedate({id: 999}, @assignment_due_date.deadline_type_id,
@assignment_due_date.parent_id, @assignment_due_date.round)
new_due_date = DueDate.find_by(id: 999)
expect(new_due_date).to be_valid
expect(new_due_date.deadline_type_id).to eql @assignment_due_date.deadline_type_id
expect(new_due_date.parent_id).to eql @assignment_due_date.parent_id
expect(new_due_date.round).to eql @assignment_due_date.round
end
</pre>
* If the function "self.deadline_sort" is able to sort the due dates in ascending order.
<pre>
it "sort duedate records" do
sorted_due_dates = @due_dates
expect(sorted_due_dates.each_cons(2).all?{|m1, m2| (m1.due_at <=> m2.due_at) != 1}).to eql false

sorted_due_dates = DueDate.deadline_sort(@due_dates)
expect(sorted_due_dates.each_cons(2).all?{|m1, m2| (m1.due_at <=> m2.due_at) != 1}).to eql true
end
</pre>
* If the function "self.done_in_assignment_round" returns the correct number of rounds for specific inputs. This involves an invalid test case as well for 0 rounds.
<pre>
describe "#done_in_assignment_round" do
it "return 0 when no response map" do
response = ReviewResponseMap.create
response.type = "ResponseMap"
response.save
expect(DueDate.done_in_assignment_round(1, response)).to eql 0
end

it "return round 1 for single round" do
response = ReviewResponseMap.create
expect(DueDate.done_in_assignment_round(@assignment_due_date.parent_id, response)).to eql 1
end
end
</pre>
* If the function "self.get_next_due_date" works as expected. This involves several invalid test cases as well.
<pre>
describe "#get_next_due_date" do
it "no subsequent due date" do
expect(DueDate.get_next_due_date(@assignment_due_date.parent_id)).to be nil
end

it "nil value throws exception" do
expect { DueDate.get_next_due_date(nil) }.to raise_exception(ActiveRecord::RecordNotFound)
end

it "get next assignment due date" do
due_date = create(:assignment_due_date, deadline_type: @deadline_type,
submission_allowed_id: @deadline_right.id, review_allowed_id: @deadline_right.id,
review_of_review_allowed_id: @deadline_right.id, due_at: Time.zone.now + 5000)
expect(DueDate.get_next_due_date(due_date.parent_id)).to be_valid
end

it "get next due date from topic for staggered deadline" do
assignment_id = create(:assignment, staggered_deadline: true, name: "testassignment").id
due_date = create(:topic_due_date, deadline_type: @deadline_type,
submission_allowed_id: @deadline_right.id, review_allowed_id: @deadline_right.id,
review_of_review_allowed_id: @deadline_right.id, due_at: Time.zone.now + 5000, parent_id: assignment_id)
expect(DueDate.get_next_due_date(assignment_id, due_date.parent_id)).to be_valid
end

it "next due date does not exist for staggered deadline" do
assignment_id = create(:assignment, staggered_deadline: true, name: "testassignment").id
due_date = create(:topic_due_date, deadline_type: @deadline_type,
submission_allowed_id: @deadline_right, review_allowed_id: @deadline_right,
review_of_review_allowed_id: @deadline_right, due_at: Time.zone.now + 5000, parent_id: assignment_id)
expect(DueDate.get_next_due_date(assignment_id)).to be nil
end

it "next due date is before Time.now for staggered deadline" do
assignment_id = create(:assignment, staggered_deadline: true, name: "testassignment").id
due_date = create(:topic_due_date, deadline_type: @deadline_type,
submission_allowed_id: @deadline_right, review_allowed_id: @deadline_right,
review_of_review_allowed_id: @deadline_right, due_at: Time.zone.now - 5000, parent_id: assignment_id)
expect(DueDate.get_next_due_date(assignment_id, due_date.parent_id)).to be nil
end

it "get next due date from assignment for staggered deadline" do
assignment_id = create(:assignment, staggered_deadline: true, name: "testassignment").id
due_date = create(:assignment_due_date, deadline_type: @deadline_type,
submission_allowed_id: @deadline_right, review_allowed_id: @deadline_right,
review_of_review_allowed_id: @deadline_right, due_at: Time.zone.now + 5000, parent_id: assignment_id)
expect(DueDate.get_next_due_date(assignment_id)).to be_valid
end
end
</pre>
* If the function "self.default_permission" returns the correct default permissions for particular deadline and permission types.
<pre>
it "metareview review_of_review_allowed default permission OK" do
expect(DueDate.default_permission('metareview', 'review_of_review_allowed')).to be == DeadlineRight::OK
end
</pre>
<pre>
it "review submission_allowed default permission NO" do
expect(DueDate.default_permission('review', 'submission_allowed')).to be == DeadlineRight::NO
end
</pre>
To test this file run the following command:
<pre>
rspec spec/models/due_date_spec.rb
</pre>
The output of this RSpec file is present in below screenshot:
[[File:Duedaterspec.png]]

Code coverage details of the above RSpec files is present in below screenshot:
[[File:Duedatecoverage.png]]

=== deadline_helper_spec.rb ===
This is a test file for testing the functionalities of Deadline_helper.rb file located at app/helpers. Different test cases present in this file are:
* Check if the factory<ref>http://www.semaphoreci.com|access-date</ref> is valid:
<pre>
it "has a valid factory" do
factory = FactoryGirl.build(:topic_due_date)
expect(factory).to be_valid
end
</pre>
* Fail if the due date is invalid:
<pre>
it "should fail because of invalid due_date" do
expect { DeadlineHelper.create_topic_deadline(nil, 0, 0)}.to raise_exception(NoMethodError)
end
</pre>
* If new due_date object is created:
<pre>
it "new due_date object created" do
DeadlineHelper.create_topic_deadline(@topic_due_date, 0, 1)
expect(TopicDueDate.count).to be == 2
end
</pre>
* due_at should be same for 0 offset:
<pre>
it "due_at should be same for 0 offset" do
DeadlineHelper.create_topic_deadline(@topic_due_date, 0, 10)
new_due_date = TopicDueDate.find_by(parent_id: 10)
expect(new_due_date).to be_valid
expect(new_due_date.due_at.to_s).to be == @topic_due_date.due_at.to_s
end
</pre>
* due_at is calculated correctly if offset is positive:
<pre>
it "due_at calculated correctly for positive offset" do
DeadlineHelper.create_topic_deadline(@topic_due_date, 5000, 10)
new_due_date = TopicDueDate.find_by(parent_id: 10)
expect(new_due_date).to be_valid
expect(new_due_date.due_at.to_s).to be == (Time.zone.parse(@topic_due_date.due_at.to_s) + 5000).to_s
end
</pre>
* due_at is calculated correctly if offset is negative:
<pre>
it "due_at calculated correctly for negative offset" do
DeadlineHelper.create_topic_deadline(@topic_due_date, -5000, 10)
new_due_date = TopicDueDate.find_by(parent_id: 10)
expect(new_due_date).to be_valid
expect(new_due_date.due_at.to_s).to be == (Time.zone.parse(@topic_due_date.due_at.to_s) - 5000).to_s
end
</pre>
* The offset is being converted to integer properly:
<pre>
it "offset converted to integer correctly" do
DeadlineHelper.create_topic_deadline(@topic_due_date, 5000.15, 10)
new_due_date = TopicDueDate.find_by(parent_id: 10)
expect(new_due_date).to be_valid
expect(new_due_date.due_at.to_s).to be == (Time.zone.parse(@topic_due_date.due_at.to_s) + 5000).to_s
end
</pre>
To test this file run the following command:
<pre>
rspec spec/models/deadline_helper_spec.rb
</pre>
The output of this RSpec file is present in below screenshot:
[[File:Deadlinerspec.png]]

Code coverage details of the above RSpec files is present in below screenshot:
[[File:Deadlinecoverage.png]]

==References==
<references/>

CSC/ECE 517 Fall 2016/E1634. Refactor and write unit test of due date.rb and deadline helper.rb

2016-10-29T01:51:13Z

Aagrawa6: /* Sources and Citations */

CSC/ECE 517 Fall 2016/E1634. Refactor and write unit test of due date.rb and deadline helper.rb

2016-10-29T01:48:00Z

Aagrawa6: /* Tasks Identified */

CSC/ECE 517 Fall 2016/E1634. Refactor and write unit test of due date.rb and deadline helper.rb

2016-10-29T01:47:45Z

Aagrawa6: /* Tasks Identified */

== '''Introduction''' ==

=== Expertiza ===
Expertiza<ref>http://www.expertiza.ncsu.edu</ref>{{Reflist}} is an open source project for school assignment management for instructors and students based on the Ruby on Rails<ref>http://www.rubyonrails.org</ref> framework. Expertiza allows the instructor to create new assignments and customise new or existing assignments. It also allows the instructor to create a list of topics the students can sign up for. Students can form teams in Expertiza to work on various projects and assignments. Students can also peer review other students' submissions. Expertiza supports submission across various document types, including the URLs and word documents. Expertiza provides a dashboard for all the assignments corresponding to a course and provides absolute control to the Instructors and Teaching Assistants. In addition to assignments, it encompasses peer reviews wherein participants are allowed to provide feedback anonymously about each other's work thereby providing scope for the better outcome. The due_date.rb file is responsible for informing the users about the deadline for submission of the each assignment. Due dates in Expertiza have their association with many other components like assignments, reviews etc.

=== Code Climate ===
Code Climate<ref>https://codeclimate.com/dashboard</ref> is a tool that runs static analysis on a GitHub project and outputs many details like test coverage, complexity, duplication, security, style, and more. There is a Google Chrome extension to integrate the Code Climate results generated directly into GitHub which is visible when browsing the repository on the browser. It allows us to see issues displayed directly inside GitHub's UI, to review which lines are covered in diffs and files, and add repositories and open tickets without changing your workflow.

== '''Tasks Identified''' ==
To install Code climate Chrome Extension that highlights the duplicated code.

To refactor the following two files:
* due_date.rb
** Ternary operators must not be nested. Prefer `if` or `else` constructs instead.
** Useless assignment to variable - `sorted_deadlines`.
** Prefer `each` over `for`.
** Use `find_by` instead of `where.first`.
** Correct the use of Time function
* deadline_helper.rb
** Do not use `Time.now` without zone. Use one of `Time.zone.now`, `Time.current`, `Time.now.in_time_zone`, `Time.now.utc`, `Time.now.getlocal`, `Time.now.iso8601`, `Time.now.jisx0301`, `Time.now.rfc3339`, `Time.now.to_i`, `Time.now.to_f` instead.
** Trailing whitespace detected.
** Extra empty line detected at module body end.

* Create respective RSpec<ref>http://www.rspec.info</ref>files in /spec/models/ and /spec/helper folder and write unit tests for each method in due_date.rb and deadline_helper.rb.

== '''Current Implementation''' ==
DueDate is a Model class to manage the deadlines of an assignment. It has methods for setting due dates for an assignment, copying due dates from one assignment to a new assignment etc. DeadlineHelper provides helper functions that help DueDate perform certain tasks. The assignment focuses on refactoring some of the methods based on warnings received from Code Climate's static analysis and modifying the language to make it more Ruby-friendly. The assignment also involves writing unit test cases for due_date.rb and deadline_helper.rb in order to increase test coverage.

The goal of this project is to attempt to make this part of the application easier to read and write unit test cases that the application must pass.

== '''Changed Implementation''' ==
Changes implemented involves refactoring the code and making it more understandable by adding comments in the code.

The modified files are
* due_date.rb (path: /app/models)
* deadline_helper.rb (path: /app/helpers)
Testing files
* due_date_spec.rb (path: /spec/models)
* deadline_helper_spec.rb (path: /spec/helpers)

=== due_date.rb ===
* Converted for..in loop to object.each in order to follow better Ruby syntax.
* Unnecessary assignment to sorted_deadlines removed.
* Nested ternary operators have been changed to if..else in order to make it more readable.
[[File:Duedaterb.png]]
* Changed where(...).first to find_by(...) which is the newer recommended syntax.
* Corrected the Time.now functions by adding the correct zones to them such as Time.zone.now.
* Removed trailing whitespaces.
[[File:DueDaterb2.png]]

=== deadline_helper.rb ===
* Time functions were changed to functions with zones
* Extra line removed
[[File:Deadlinehelper.png]]

== '''RSpec testing''' ==
There were no existing tests for the functions in due_date.rb and deadline_helper.rb. We have added exhaustive set of RSpec tests to test all the code. We have added two new spec files 'due_date_spec.rb' and ‘deadline_helper_spec.rb’ which cover the testing scenarios for the functions in ‘due_date.rb’ and ‘deadline_helper.rb’.

For both of these two files, all Travis CI<ref>http://www.travis-ci.com</ref> test cases have passed for all previous test cases as well as the ones added by us with the test coverage for the files due_date.rb and deadline_helper.rb reported as 100%.

These RSpec files have 100% code coverage visible at: /coverage/index.html.

=== due_date_spec.rb ===
This file is located at spec/models and tests the functionalities of the due_date.rb file located in app/models. There are 18 test cases in total which are listed below.
* If the factory is successfully able to build the due_date objects.
<pre>
it "due date factory created successfully" do
expect(@assignment_due_date).to be_valid
end
</pre>
<pre>
it "due dates created correctly" do
expect(@due_dates.length).to be == 10
end
</pre>
* If the function "set_flag" successfully sets the due_date flag.
<pre>
it "due date flag is set" do
expect(@assignment_due_date.flag).to be false
@assignment_due_date.set_flag
expect(@assignment_due_date.flag).to be true
end
</pre>
* If the function "due_at_is_valid_datetime" returns nil (no errors) for a valid datetime in due_at (no invalid test cases can be added here because model does not allow invalid datetime to be set at all).
<pre>
it "due at is valid datetime" do
expect(@assignment_due_date.due_at_is_valid_datetime).to be nil
end
</pre>
* If the function "self.copy" is able to copy due dates from one assignment to another.
<pre>
it "copy due dates to new assignment" do
new_assignment_id = build(:assignment, id: 999).id
old_assignment_id = @assignment_due_date.assignment.id
DueDate.copy(old_assignment_id, new_assignment_id)
expect(DueDate.where(parent_id: new_assignment_id).count).to eql DueDate.where(parent_id: old_assignment_id).count
end
</pre>
* If the function "self.set_duedate" is able to create another due date by copying data from an existing due date object.
<pre>
it "create new duedate record with values" do
DueDate.set_duedate({id: 999}, @assignment_due_date.deadline_type_id,
@assignment_due_date.parent_id, @assignment_due_date.round)
new_due_date = DueDate.find_by(id: 999)
expect(new_due_date).to be_valid
expect(new_due_date.deadline_type_id).to eql @assignment_due_date.deadline_type_id
expect(new_due_date.parent_id).to eql @assignment_due_date.parent_id
expect(new_due_date.round).to eql @assignment_due_date.round
end
</pre>
* If the function "self.deadline_sort" is able to sort the due dates in ascending order.
<pre>
it "sort duedate records" do
sorted_due_dates = @due_dates
expect(sorted_due_dates.each_cons(2).all?{|m1, m2| (m1.due_at <=> m2.due_at) != 1}).to eql false

sorted_due_dates = DueDate.deadline_sort(@due_dates)
expect(sorted_due_dates.each_cons(2).all?{|m1, m2| (m1.due_at <=> m2.due_at) != 1}).to eql true
end
</pre>
* If the function "self.done_in_assignment_round" returns the correct number of rounds for specific inputs. This involves an invalid test case as well for 0 rounds.
<pre>
describe "#done_in_assignment_round" do
it "return 0 when no response map" do
response = ReviewResponseMap.create
response.type = "ResponseMap"
response.save
expect(DueDate.done_in_assignment_round(1, response)).to eql 0
end

it "return round 1 for single round" do
response = ReviewResponseMap.create
expect(DueDate.done_in_assignment_round(@assignment_due_date.parent_id, response)).to eql 1
end
end
</pre>
* If the function "self.get_next_due_date" works as expected. This involves several invalid test cases as well.
<pre>
describe "#get_next_due_date" do
it "no subsequent due date" do
expect(DueDate.get_next_due_date(@assignment_due_date.parent_id)).to be nil
end

it "nil value throws exception" do
expect { DueDate.get_next_due_date(nil) }.to raise_exception(ActiveRecord::RecordNotFound)
end

it "get next assignment due date" do
due_date = create(:assignment_due_date, deadline_type: @deadline_type,
submission_allowed_id: @deadline_right.id, review_allowed_id: @deadline_right.id,
review_of_review_allowed_id: @deadline_right.id, due_at: Time.zone.now + 5000)
expect(DueDate.get_next_due_date(due_date.parent_id)).to be_valid
end

it "get next due date from topic for staggered deadline" do
assignment_id = create(:assignment, staggered_deadline: true, name: "testassignment").id
due_date = create(:topic_due_date, deadline_type: @deadline_type,
submission_allowed_id: @deadline_right.id, review_allowed_id: @deadline_right.id,
review_of_review_allowed_id: @deadline_right.id, due_at: Time.zone.now + 5000, parent_id: assignment_id)
expect(DueDate.get_next_due_date(assignment_id, due_date.parent_id)).to be_valid
end

it "next due date does not exist for staggered deadline" do
assignment_id = create(:assignment, staggered_deadline: true, name: "testassignment").id
due_date = create(:topic_due_date, deadline_type: @deadline_type,
submission_allowed_id: @deadline_right, review_allowed_id: @deadline_right,
review_of_review_allowed_id: @deadline_right, due_at: Time.zone.now + 5000, parent_id: assignment_id)
expect(DueDate.get_next_due_date(assignment_id)).to be nil
end

it "next due date is before Time.now for staggered deadline" do
assignment_id = create(:assignment, staggered_deadline: true, name: "testassignment").id
due_date = create(:topic_due_date, deadline_type: @deadline_type,
submission_allowed_id: @deadline_right, review_allowed_id: @deadline_right,
review_of_review_allowed_id: @deadline_right, due_at: Time.zone.now - 5000, parent_id: assignment_id)
expect(DueDate.get_next_due_date(assignment_id, due_date.parent_id)).to be nil
end

it "get next due date from assignment for staggered deadline" do
assignment_id = create(:assignment, staggered_deadline: true, name: "testassignment").id
due_date = create(:assignment_due_date, deadline_type: @deadline_type,
submission_allowed_id: @deadline_right, review_allowed_id: @deadline_right,
review_of_review_allowed_id: @deadline_right, due_at: Time.zone.now + 5000, parent_id: assignment_id)
expect(DueDate.get_next_due_date(assignment_id)).to be_valid
end
end
</pre>
* If the function "self.default_permission" returns the correct default permissions for particular deadline and permission types.
<pre>
it "metareview review_of_review_allowed default permission OK" do
expect(DueDate.default_permission('metareview', 'review_of_review_allowed')).to be == DeadlineRight::OK
end
</pre>
<pre>
it "review submission_allowed default permission NO" do
expect(DueDate.default_permission('review', 'submission_allowed')).to be == DeadlineRight::NO
end
</pre>
To test this file run the following command:
<pre>
rspec spec/models/due_date_spec.rb
</pre>
The output of this RSpec file is present in below screenshot:
[[File:Duedaterspec.png]]

Code coverage details of the above RSpec files is present in below screenshot:
[[File:Duedatecoverage.png]]

=== deadline_helper_spec.rb ===
This is a test file for testing the functionalities of Deadline_helper.rb file located at app/helpers. Different test cases present in this file are:
* Check if the factory<ref>http://www.semaphoreci.com|access-date</ref> is valid:
<pre>
it "has a valid factory" do
factory = FactoryGirl.build(:topic_due_date)
expect(factory).to be_valid
end
</pre>
* Fail if the due date is invalid:
<pre>
it "should fail because of invalid due_date" do
expect { DeadlineHelper.create_topic_deadline(nil, 0, 0)}.to raise_exception(NoMethodError)
end
</pre>
* If new due_date object is created:
<pre>
it "new due_date object created" do
DeadlineHelper.create_topic_deadline(@topic_due_date, 0, 1)
expect(TopicDueDate.count).to be == 2
end
</pre>
* due_at should be same for 0 offset:
<pre>
it "due_at should be same for 0 offset" do
DeadlineHelper.create_topic_deadline(@topic_due_date, 0, 10)
new_due_date = TopicDueDate.find_by(parent_id: 10)
expect(new_due_date).to be_valid
expect(new_due_date.due_at.to_s).to be == @topic_due_date.due_at.to_s
end
</pre>
* due_at is calculated correctly if offset is positive:
<pre>
it "due_at calculated correctly for positive offset" do
DeadlineHelper.create_topic_deadline(@topic_due_date, 5000, 10)
new_due_date = TopicDueDate.find_by(parent_id: 10)
expect(new_due_date).to be_valid
expect(new_due_date.due_at.to_s).to be == (Time.zone.parse(@topic_due_date.due_at.to_s) + 5000).to_s
end
</pre>
* due_at is calculated correctly if offset is negative:
<pre>
it "due_at calculated correctly for negative offset" do
DeadlineHelper.create_topic_deadline(@topic_due_date, -5000, 10)
new_due_date = TopicDueDate.find_by(parent_id: 10)
expect(new_due_date).to be_valid
expect(new_due_date.due_at.to_s).to be == (Time.zone.parse(@topic_due_date.due_at.to_s) - 5000).to_s
end
</pre>
* The offset is being converted to integer properly:
<pre>
it "offset converted to integer correctly" do
DeadlineHelper.create_topic_deadline(@topic_due_date, 5000.15, 10)
new_due_date = TopicDueDate.find_by(parent_id: 10)
expect(new_due_date).to be_valid
expect(new_due_date.due_at.to_s).to be == (Time.zone.parse(@topic_due_date.due_at.to_s) + 5000).to_s
end
</pre>
To test this file run the following command:
<pre>
rspec spec/models/deadline_helper_spec.rb
</pre>
The output of this RSpec file is present in below screenshot:
[[File:Deadlinerspec.png]]

Code coverage details of the above RSpec files is present in below screenshot:
[[File:Deadlinecoverage.png]]

==Sources and Citations==
{{reflist}}

CSC/ECE 517 Fall 2016/E1634. Refactor and write unit test of due date.rb and deadline helper.rb

2016-10-29T01:47:21Z

Aagrawa6: /* deadline_helper_spec.rb */

== '''Introduction''' ==

=== Expertiza ===
Expertiza<ref>http://www.expertiza.ncsu.edu</ref>{{Reflist}} is an open source project for school assignment management for instructors and students based on the Ruby on Rails<ref>http://www.rubyonrails.org</ref> framework. Expertiza allows the instructor to create new assignments and customise new or existing assignments. It also allows the instructor to create a list of topics the students can sign up for. Students can form teams in Expertiza to work on various projects and assignments. Students can also peer review other students' submissions. Expertiza supports submission across various document types, including the URLs and word documents. Expertiza provides a dashboard for all the assignments corresponding to a course and provides absolute control to the Instructors and Teaching Assistants. In addition to assignments, it encompasses peer reviews wherein participants are allowed to provide feedback anonymously about each other's work thereby providing scope for the better outcome. The due_date.rb file is responsible for informing the users about the deadline for submission of the each assignment. Due dates in Expertiza have their association with many other components like assignments, reviews etc.

=== Code Climate ===
Code Climate<ref>https://codeclimate.com/dashboard</ref> is a tool that runs static analysis on a GitHub project and outputs many details like test coverage, complexity, duplication, security, style, and more. There is a Google Chrome extension to integrate the Code Climate results generated directly into GitHub which is visible when browsing the repository on the browser. It allows us to see issues displayed directly inside GitHub's UI, to review which lines are covered in diffs and files, and add repositories and open tickets without changing your workflow.

== '''Tasks Identified''' ==
To install Code climate Chrome Extension that highlights the duplicated code.

To refactor the following two files:
* due_date.rb
** Ternary operators must not be nested. Prefer `if` or `else` constructs instead.
** Useless assignment to variable - `sorted_deadlines`.
** Prefer `each` over `for`.
** Use `find_by` instead of `where.first`.
** Correct the use of Time function
* deadline_helper.rb
** Do not use `Time.now` without zone. Use one of `Time.zone.now`, `Time.current`, `Time.now.in_time_zone`, `Time.now.utc`, `Time.now.getlocal`, `Time.now.iso8601`, `Time.now.jisx0301`, `Time.now.rfc3339`, `Time.now.to_i`, `Time.now.to_f` instead.
** Trailing whitespace detected.
** Extra empty line detected at module body end.

* Create respective RSpec<ref>{{Cite web|url=http://www.rspec.info|access-date=2016-10-28}}</ref>files in /spec/models/ and /spec/helper folder and write unit tests for each method in due_date.rb and deadline_helper.rb.

== '''Current Implementation''' ==
DueDate is a Model class to manage the deadlines of an assignment. It has methods for setting due dates for an assignment, copying due dates from one assignment to a new assignment etc. DeadlineHelper provides helper functions that help DueDate perform certain tasks. The assignment focuses on refactoring some of the methods based on warnings received from Code Climate's static analysis and modifying the language to make it more Ruby-friendly. The assignment also involves writing unit test cases for due_date.rb and deadline_helper.rb in order to increase test coverage.

The goal of this project is to attempt to make this part of the application easier to read and write unit test cases that the application must pass.

== '''Changed Implementation''' ==
Changes implemented involves refactoring the code and making it more understandable by adding comments in the code.

The modified files are
* due_date.rb (path: /app/models)
* deadline_helper.rb (path: /app/helpers)
Testing files
* due_date_spec.rb (path: /spec/models)
* deadline_helper_spec.rb (path: /spec/helpers)

=== due_date.rb ===
* Converted for..in loop to object.each in order to follow better Ruby syntax.
* Unnecessary assignment to sorted_deadlines removed.
* Nested ternary operators have been changed to if..else in order to make it more readable.
[[File:Duedaterb.png]]
* Changed where(...).first to find_by(...) which is the newer recommended syntax.
* Corrected the Time.now functions by adding the correct zones to them such as Time.zone.now.
* Removed trailing whitespaces.
[[File:DueDaterb2.png]]

=== deadline_helper.rb ===
* Time functions were changed to functions with zones
* Extra line removed
[[File:Deadlinehelper.png]]

== '''RSpec testing''' ==
There were no existing tests for the functions in due_date.rb and deadline_helper.rb. We have added exhaustive set of RSpec tests to test all the code. We have added two new spec files 'due_date_spec.rb' and ‘deadline_helper_spec.rb’ which cover the testing scenarios for the functions in ‘due_date.rb’ and ‘deadline_helper.rb’.

For both of these two files, all Travis CI<ref>http://www.travis-ci.com</ref> test cases have passed for all previous test cases as well as the ones added by us with the test coverage for the files due_date.rb and deadline_helper.rb reported as 100%.

These RSpec files have 100% code coverage visible at: /coverage/index.html.

=== due_date_spec.rb ===
This file is located at spec/models and tests the functionalities of the due_date.rb file located in app/models. There are 18 test cases in total which are listed below.
* If the factory is successfully able to build the due_date objects.
<pre>
it "due date factory created successfully" do
expect(@assignment_due_date).to be_valid
end
</pre>
<pre>
it "due dates created correctly" do
expect(@due_dates.length).to be == 10
end
</pre>
* If the function "set_flag" successfully sets the due_date flag.
<pre>
it "due date flag is set" do
expect(@assignment_due_date.flag).to be false
@assignment_due_date.set_flag
expect(@assignment_due_date.flag).to be true
end
</pre>
* If the function "due_at_is_valid_datetime" returns nil (no errors) for a valid datetime in due_at (no invalid test cases can be added here because model does not allow invalid datetime to be set at all).
<pre>
it "due at is valid datetime" do
expect(@assignment_due_date.due_at_is_valid_datetime).to be nil
end
</pre>
* If the function "self.copy" is able to copy due dates from one assignment to another.
<pre>
it "copy due dates to new assignment" do
new_assignment_id = build(:assignment, id: 999).id
old_assignment_id = @assignment_due_date.assignment.id
DueDate.copy(old_assignment_id, new_assignment_id)
expect(DueDate.where(parent_id: new_assignment_id).count).to eql DueDate.where(parent_id: old_assignment_id).count
end
</pre>
* If the function "self.set_duedate" is able to create another due date by copying data from an existing due date object.
<pre>
it "create new duedate record with values" do
DueDate.set_duedate({id: 999}, @assignment_due_date.deadline_type_id,
@assignment_due_date.parent_id, @assignment_due_date.round)
new_due_date = DueDate.find_by(id: 999)
expect(new_due_date).to be_valid
expect(new_due_date.deadline_type_id).to eql @assignment_due_date.deadline_type_id
expect(new_due_date.parent_id).to eql @assignment_due_date.parent_id
expect(new_due_date.round).to eql @assignment_due_date.round
end
</pre>
* If the function "self.deadline_sort" is able to sort the due dates in ascending order.
<pre>
it "sort duedate records" do
sorted_due_dates = @due_dates
expect(sorted_due_dates.each_cons(2).all?{|m1, m2| (m1.due_at <=> m2.due_at) != 1}).to eql false

sorted_due_dates = DueDate.deadline_sort(@due_dates)
expect(sorted_due_dates.each_cons(2).all?{|m1, m2| (m1.due_at <=> m2.due_at) != 1}).to eql true
end
</pre>
* If the function "self.done_in_assignment_round" returns the correct number of rounds for specific inputs. This involves an invalid test case as well for 0 rounds.
<pre>
describe "#done_in_assignment_round" do
it "return 0 when no response map" do
response = ReviewResponseMap.create
response.type = "ResponseMap"
response.save
expect(DueDate.done_in_assignment_round(1, response)).to eql 0
end

it "return round 1 for single round" do
response = ReviewResponseMap.create
expect(DueDate.done_in_assignment_round(@assignment_due_date.parent_id, response)).to eql 1
end
end
</pre>
* If the function "self.get_next_due_date" works as expected. This involves several invalid test cases as well.
<pre>
describe "#get_next_due_date" do
it "no subsequent due date" do
expect(DueDate.get_next_due_date(@assignment_due_date.parent_id)).to be nil
end

it "nil value throws exception" do
expect { DueDate.get_next_due_date(nil) }.to raise_exception(ActiveRecord::RecordNotFound)
end

it "get next assignment due date" do
due_date = create(:assignment_due_date, deadline_type: @deadline_type,
submission_allowed_id: @deadline_right.id, review_allowed_id: @deadline_right.id,
review_of_review_allowed_id: @deadline_right.id, due_at: Time.zone.now + 5000)
expect(DueDate.get_next_due_date(due_date.parent_id)).to be_valid
end

it "get next due date from topic for staggered deadline" do
assignment_id = create(:assignment, staggered_deadline: true, name: "testassignment").id
due_date = create(:topic_due_date, deadline_type: @deadline_type,
submission_allowed_id: @deadline_right.id, review_allowed_id: @deadline_right.id,
review_of_review_allowed_id: @deadline_right.id, due_at: Time.zone.now + 5000, parent_id: assignment_id)
expect(DueDate.get_next_due_date(assignment_id, due_date.parent_id)).to be_valid
end

it "next due date does not exist for staggered deadline" do
assignment_id = create(:assignment, staggered_deadline: true, name: "testassignment").id
due_date = create(:topic_due_date, deadline_type: @deadline_type,
submission_allowed_id: @deadline_right, review_allowed_id: @deadline_right,
review_of_review_allowed_id: @deadline_right, due_at: Time.zone.now + 5000, parent_id: assignment_id)
expect(DueDate.get_next_due_date(assignment_id)).to be nil
end

it "next due date is before Time.now for staggered deadline" do
assignment_id = create(:assignment, staggered_deadline: true, name: "testassignment").id
due_date = create(:topic_due_date, deadline_type: @deadline_type,
submission_allowed_id: @deadline_right, review_allowed_id: @deadline_right,
review_of_review_allowed_id: @deadline_right, due_at: Time.zone.now - 5000, parent_id: assignment_id)
expect(DueDate.get_next_due_date(assignment_id, due_date.parent_id)).to be nil
end

it "get next due date from assignment for staggered deadline" do
assignment_id = create(:assignment, staggered_deadline: true, name: "testassignment").id
due_date = create(:assignment_due_date, deadline_type: @deadline_type,
submission_allowed_id: @deadline_right, review_allowed_id: @deadline_right,
review_of_review_allowed_id: @deadline_right, due_at: Time.zone.now + 5000, parent_id: assignment_id)
expect(DueDate.get_next_due_date(assignment_id)).to be_valid
end
end
</pre>
* If the function "self.default_permission" returns the correct default permissions for particular deadline and permission types.
<pre>
it "metareview review_of_review_allowed default permission OK" do
expect(DueDate.default_permission('metareview', 'review_of_review_allowed')).to be == DeadlineRight::OK
end
</pre>
<pre>
it "review submission_allowed default permission NO" do
expect(DueDate.default_permission('review', 'submission_allowed')).to be == DeadlineRight::NO
end
</pre>
To test this file run the following command:
<pre>
rspec spec/models/due_date_spec.rb
</pre>
The output of this RSpec file is present in below screenshot:
[[File:Duedaterspec.png]]

Code coverage details of the above RSpec files is present in below screenshot:
[[File:Duedatecoverage.png]]

=== deadline_helper_spec.rb ===
This is a test file for testing the functionalities of Deadline_helper.rb file located at app/helpers. Different test cases present in this file are:
* Check if the factory<ref>http://www.semaphoreci.com|access-date</ref> is valid:
<pre>
it "has a valid factory" do
factory = FactoryGirl.build(:topic_due_date)
expect(factory).to be_valid
end
</pre>
* Fail if the due date is invalid:
<pre>
it "should fail because of invalid due_date" do
expect { DeadlineHelper.create_topic_deadline(nil, 0, 0)}.to raise_exception(NoMethodError)
end
</pre>
* If new due_date object is created:
<pre>
it "new due_date object created" do
DeadlineHelper.create_topic_deadline(@topic_due_date, 0, 1)
expect(TopicDueDate.count).to be == 2
end
</pre>
* due_at should be same for 0 offset:
<pre>
it "due_at should be same for 0 offset" do
DeadlineHelper.create_topic_deadline(@topic_due_date, 0, 10)
new_due_date = TopicDueDate.find_by(parent_id: 10)
expect(new_due_date).to be_valid
expect(new_due_date.due_at.to_s).to be == @topic_due_date.due_at.to_s
end
</pre>
* due_at is calculated correctly if offset is positive:
<pre>
it "due_at calculated correctly for positive offset" do
DeadlineHelper.create_topic_deadline(@topic_due_date, 5000, 10)
new_due_date = TopicDueDate.find_by(parent_id: 10)
expect(new_due_date).to be_valid
expect(new_due_date.due_at.to_s).to be == (Time.zone.parse(@topic_due_date.due_at.to_s) + 5000).to_s
end
</pre>
* due_at is calculated correctly if offset is negative:
<pre>
it "due_at calculated correctly for negative offset" do
DeadlineHelper.create_topic_deadline(@topic_due_date, -5000, 10)
new_due_date = TopicDueDate.find_by(parent_id: 10)
expect(new_due_date).to be_valid
expect(new_due_date.due_at.to_s).to be == (Time.zone.parse(@topic_due_date.due_at.to_s) - 5000).to_s
end
</pre>
* The offset is being converted to integer properly:
<pre>
it "offset converted to integer correctly" do
DeadlineHelper.create_topic_deadline(@topic_due_date, 5000.15, 10)
new_due_date = TopicDueDate.find_by(parent_id: 10)
expect(new_due_date).to be_valid
expect(new_due_date.due_at.to_s).to be == (Time.zone.parse(@topic_due_date.due_at.to_s) + 5000).to_s
end
</pre>
To test this file run the following command:
<pre>
rspec spec/models/deadline_helper_spec.rb
</pre>
The output of this RSpec file is present in below screenshot:
[[File:Deadlinerspec.png]]

Code coverage details of the above RSpec files is present in below screenshot:
[[File:Deadlinecoverage.png]]

==Sources and Citations==
{{reflist}}

CSC/ECE 517 Fall 2016/E1634. Refactor and write unit test of due date.rb and deadline helper.rb

2016-10-29T01:46:55Z

Aagrawa6: /* RSpec testing */

== '''Introduction''' ==

=== Expertiza ===
Expertiza<ref>http://www.expertiza.ncsu.edu</ref>{{Reflist}} is an open source project for school assignment management for instructors and students based on the Ruby on Rails<ref>http://www.rubyonrails.org</ref> framework. Expertiza allows the instructor to create new assignments and customise new or existing assignments. It also allows the instructor to create a list of topics the students can sign up for. Students can form teams in Expertiza to work on various projects and assignments. Students can also peer review other students' submissions. Expertiza supports submission across various document types, including the URLs and word documents. Expertiza provides a dashboard for all the assignments corresponding to a course and provides absolute control to the Instructors and Teaching Assistants. In addition to assignments, it encompasses peer reviews wherein participants are allowed to provide feedback anonymously about each other's work thereby providing scope for the better outcome. The due_date.rb file is responsible for informing the users about the deadline for submission of the each assignment. Due dates in Expertiza have their association with many other components like assignments, reviews etc.

=== Code Climate ===
Code Climate<ref>https://codeclimate.com/dashboard</ref> is a tool that runs static analysis on a GitHub project and outputs many details like test coverage, complexity, duplication, security, style, and more. There is a Google Chrome extension to integrate the Code Climate results generated directly into GitHub which is visible when browsing the repository on the browser. It allows us to see issues displayed directly inside GitHub's UI, to review which lines are covered in diffs and files, and add repositories and open tickets without changing your workflow.

== '''Tasks Identified''' ==
To install Code climate Chrome Extension that highlights the duplicated code.

To refactor the following two files:
* due_date.rb
** Ternary operators must not be nested. Prefer `if` or `else` constructs instead.
** Useless assignment to variable - `sorted_deadlines`.
** Prefer `each` over `for`.
** Use `find_by` instead of `where.first`.
** Correct the use of Time function
* deadline_helper.rb
** Do not use `Time.now` without zone. Use one of `Time.zone.now`, `Time.current`, `Time.now.in_time_zone`, `Time.now.utc`, `Time.now.getlocal`, `Time.now.iso8601`, `Time.now.jisx0301`, `Time.now.rfc3339`, `Time.now.to_i`, `Time.now.to_f` instead.
** Trailing whitespace detected.
** Extra empty line detected at module body end.

* Create respective RSpec<ref>{{Cite web|url=http://www.rspec.info|access-date=2016-10-28}}</ref>files in /spec/models/ and /spec/helper folder and write unit tests for each method in due_date.rb and deadline_helper.rb.

== '''Current Implementation''' ==
DueDate is a Model class to manage the deadlines of an assignment. It has methods for setting due dates for an assignment, copying due dates from one assignment to a new assignment etc. DeadlineHelper provides helper functions that help DueDate perform certain tasks. The assignment focuses on refactoring some of the methods based on warnings received from Code Climate's static analysis and modifying the language to make it more Ruby-friendly. The assignment also involves writing unit test cases for due_date.rb and deadline_helper.rb in order to increase test coverage.

The goal of this project is to attempt to make this part of the application easier to read and write unit test cases that the application must pass.

== '''Changed Implementation''' ==
Changes implemented involves refactoring the code and making it more understandable by adding comments in the code.

The modified files are
* due_date.rb (path: /app/models)
* deadline_helper.rb (path: /app/helpers)
Testing files
* due_date_spec.rb (path: /spec/models)
* deadline_helper_spec.rb (path: /spec/helpers)

=== due_date.rb ===
* Converted for..in loop to object.each in order to follow better Ruby syntax.
* Unnecessary assignment to sorted_deadlines removed.
* Nested ternary operators have been changed to if..else in order to make it more readable.
[[File:Duedaterb.png]]
* Changed where(...).first to find_by(...) which is the newer recommended syntax.
* Corrected the Time.now functions by adding the correct zones to them such as Time.zone.now.
* Removed trailing whitespaces.
[[File:DueDaterb2.png]]

=== deadline_helper.rb ===
* Time functions were changed to functions with zones
* Extra line removed
[[File:Deadlinehelper.png]]

== '''RSpec testing''' ==
There were no existing tests for the functions in due_date.rb and deadline_helper.rb. We have added exhaustive set of RSpec tests to test all the code. We have added two new spec files 'due_date_spec.rb' and ‘deadline_helper_spec.rb’ which cover the testing scenarios for the functions in ‘due_date.rb’ and ‘deadline_helper.rb’.

For both of these two files, all Travis CI<ref>http://www.travis-ci.com</ref> test cases have passed for all previous test cases as well as the ones added by us with the test coverage for the files due_date.rb and deadline_helper.rb reported as 100%.

These RSpec files have 100% code coverage visible at: /coverage/index.html.

=== due_date_spec.rb ===
This file is located at spec/models and tests the functionalities of the due_date.rb file located in app/models. There are 18 test cases in total which are listed below.
* If the factory is successfully able to build the due_date objects.
<pre>
it "due date factory created successfully" do
expect(@assignment_due_date).to be_valid
end
</pre>
<pre>
it "due dates created correctly" do
expect(@due_dates.length).to be == 10
end
</pre>
* If the function "set_flag" successfully sets the due_date flag.
<pre>
it "due date flag is set" do
expect(@assignment_due_date.flag).to be false
@assignment_due_date.set_flag
expect(@assignment_due_date.flag).to be true
end
</pre>
* If the function "due_at_is_valid_datetime" returns nil (no errors) for a valid datetime in due_at (no invalid test cases can be added here because model does not allow invalid datetime to be set at all).
<pre>
it "due at is valid datetime" do
expect(@assignment_due_date.due_at_is_valid_datetime).to be nil
end
</pre>
* If the function "self.copy" is able to copy due dates from one assignment to another.
<pre>
it "copy due dates to new assignment" do
new_assignment_id = build(:assignment, id: 999).id
old_assignment_id = @assignment_due_date.assignment.id
DueDate.copy(old_assignment_id, new_assignment_id)
expect(DueDate.where(parent_id: new_assignment_id).count).to eql DueDate.where(parent_id: old_assignment_id).count
end
</pre>
* If the function "self.set_duedate" is able to create another due date by copying data from an existing due date object.
<pre>
it "create new duedate record with values" do
DueDate.set_duedate({id: 999}, @assignment_due_date.deadline_type_id,
@assignment_due_date.parent_id, @assignment_due_date.round)
new_due_date = DueDate.find_by(id: 999)
expect(new_due_date).to be_valid
expect(new_due_date.deadline_type_id).to eql @assignment_due_date.deadline_type_id
expect(new_due_date.parent_id).to eql @assignment_due_date.parent_id
expect(new_due_date.round).to eql @assignment_due_date.round
end
</pre>
* If the function "self.deadline_sort" is able to sort the due dates in ascending order.
<pre>
it "sort duedate records" do
sorted_due_dates = @due_dates
expect(sorted_due_dates.each_cons(2).all?{|m1, m2| (m1.due_at <=> m2.due_at) != 1}).to eql false

sorted_due_dates = DueDate.deadline_sort(@due_dates)
expect(sorted_due_dates.each_cons(2).all?{|m1, m2| (m1.due_at <=> m2.due_at) != 1}).to eql true
end
</pre>
* If the function "self.done_in_assignment_round" returns the correct number of rounds for specific inputs. This involves an invalid test case as well for 0 rounds.
<pre>
describe "#done_in_assignment_round" do
it "return 0 when no response map" do
response = ReviewResponseMap.create
response.type = "ResponseMap"
response.save
expect(DueDate.done_in_assignment_round(1, response)).to eql 0
end

it "return round 1 for single round" do
response = ReviewResponseMap.create
expect(DueDate.done_in_assignment_round(@assignment_due_date.parent_id, response)).to eql 1
end
end
</pre>
* If the function "self.get_next_due_date" works as expected. This involves several invalid test cases as well.
<pre>
describe "#get_next_due_date" do
it "no subsequent due date" do
expect(DueDate.get_next_due_date(@assignment_due_date.parent_id)).to be nil
end

it "nil value throws exception" do
expect { DueDate.get_next_due_date(nil) }.to raise_exception(ActiveRecord::RecordNotFound)
end

it "get next assignment due date" do
due_date = create(:assignment_due_date, deadline_type: @deadline_type,
submission_allowed_id: @deadline_right.id, review_allowed_id: @deadline_right.id,
review_of_review_allowed_id: @deadline_right.id, due_at: Time.zone.now + 5000)
expect(DueDate.get_next_due_date(due_date.parent_id)).to be_valid
end

it "get next due date from topic for staggered deadline" do
assignment_id = create(:assignment, staggered_deadline: true, name: "testassignment").id
due_date = create(:topic_due_date, deadline_type: @deadline_type,
submission_allowed_id: @deadline_right.id, review_allowed_id: @deadline_right.id,
review_of_review_allowed_id: @deadline_right.id, due_at: Time.zone.now + 5000, parent_id: assignment_id)
expect(DueDate.get_next_due_date(assignment_id, due_date.parent_id)).to be_valid
end

it "next due date does not exist for staggered deadline" do
assignment_id = create(:assignment, staggered_deadline: true, name: "testassignment").id
due_date = create(:topic_due_date, deadline_type: @deadline_type,
submission_allowed_id: @deadline_right, review_allowed_id: @deadline_right,
review_of_review_allowed_id: @deadline_right, due_at: Time.zone.now + 5000, parent_id: assignment_id)
expect(DueDate.get_next_due_date(assignment_id)).to be nil
end

it "next due date is before Time.now for staggered deadline" do
assignment_id = create(:assignment, staggered_deadline: true, name: "testassignment").id
due_date = create(:topic_due_date, deadline_type: @deadline_type,
submission_allowed_id: @deadline_right, review_allowed_id: @deadline_right,
review_of_review_allowed_id: @deadline_right, due_at: Time.zone.now - 5000, parent_id: assignment_id)
expect(DueDate.get_next_due_date(assignment_id, due_date.parent_id)).to be nil
end

it "get next due date from assignment for staggered deadline" do
assignment_id = create(:assignment, staggered_deadline: true, name: "testassignment").id
due_date = create(:assignment_due_date, deadline_type: @deadline_type,
submission_allowed_id: @deadline_right, review_allowed_id: @deadline_right,
review_of_review_allowed_id: @deadline_right, due_at: Time.zone.now + 5000, parent_id: assignment_id)
expect(DueDate.get_next_due_date(assignment_id)).to be_valid
end
end
</pre>
* If the function "self.default_permission" returns the correct default permissions for particular deadline and permission types.
<pre>
it "metareview review_of_review_allowed default permission OK" do
expect(DueDate.default_permission('metareview', 'review_of_review_allowed')).to be == DeadlineRight::OK
end
</pre>
<pre>
it "review submission_allowed default permission NO" do
expect(DueDate.default_permission('review', 'submission_allowed')).to be == DeadlineRight::NO
end
</pre>
To test this file run the following command:
<pre>
rspec spec/models/due_date_spec.rb
</pre>
The output of this RSpec file is present in below screenshot:
[[File:Duedaterspec.png]]

Code coverage details of the above RSpec files is present in below screenshot:
[[File:Duedatecoverage.png]]

=== deadline_helper_spec.rb ===
This is a test file for testing the functionalities of Deadline_helper.rb file located at app/helpers. Different test cases present in this file are:
* Check if the factory<ref>{{Cite web|url=http://http://www.semaphoreci.com|access-date=2016-10-28}}</ref> is valid:
<pre>
it "has a valid factory" do
factory = FactoryGirl.build(:topic_due_date)
expect(factory).to be_valid
end
</pre>
* Fail if the due date is invalid:
<pre>
it "should fail because of invalid due_date" do
expect { DeadlineHelper.create_topic_deadline(nil, 0, 0)}.to raise_exception(NoMethodError)
end
</pre>
* If new due_date object is created:
<pre>
it "new due_date object created" do
DeadlineHelper.create_topic_deadline(@topic_due_date, 0, 1)
expect(TopicDueDate.count).to be == 2
end
</pre>
* due_at should be same for 0 offset:
<pre>
it "due_at should be same for 0 offset" do
DeadlineHelper.create_topic_deadline(@topic_due_date, 0, 10)
new_due_date = TopicDueDate.find_by(parent_id: 10)
expect(new_due_date).to be_valid
expect(new_due_date.due_at.to_s).to be == @topic_due_date.due_at.to_s
end
</pre>
* due_at is calculated correctly if offset is positive:
<pre>
it "due_at calculated correctly for positive offset" do
DeadlineHelper.create_topic_deadline(@topic_due_date, 5000, 10)
new_due_date = TopicDueDate.find_by(parent_id: 10)
expect(new_due_date).to be_valid
expect(new_due_date.due_at.to_s).to be == (Time.zone.parse(@topic_due_date.due_at.to_s) + 5000).to_s
end
</pre>
* due_at is calculated correctly if offset is negative:
<pre>
it "due_at calculated correctly for negative offset" do
DeadlineHelper.create_topic_deadline(@topic_due_date, -5000, 10)
new_due_date = TopicDueDate.find_by(parent_id: 10)
expect(new_due_date).to be_valid
expect(new_due_date.due_at.to_s).to be == (Time.zone.parse(@topic_due_date.due_at.to_s) - 5000).to_s
end
</pre>
* The offset is being converted to integer properly:
<pre>
it "offset converted to integer correctly" do
DeadlineHelper.create_topic_deadline(@topic_due_date, 5000.15, 10)
new_due_date = TopicDueDate.find_by(parent_id: 10)
expect(new_due_date).to be_valid
expect(new_due_date.due_at.to_s).to be == (Time.zone.parse(@topic_due_date.due_at.to_s) + 5000).to_s
end
</pre>
To test this file run the following command:
<pre>
rspec spec/models/deadline_helper_spec.rb
</pre>
The output of this RSpec file is present in below screenshot:
[[File:Deadlinerspec.png]]

Code coverage details of the above RSpec files is present in below screenshot:
[[File:Deadlinecoverage.png]]

==Sources and Citations==
{{reflist}}

CSC/ECE 517 Fall 2016/E1634. Refactor and write unit test of due date.rb and deadline helper.rb

2016-10-29T01:46:26Z

Aagrawa6: /* Code Climate */

== '''Introduction''' ==

=== Expertiza ===
Expertiza<ref>http://www.expertiza.ncsu.edu</ref>{{Reflist}} is an open source project for school assignment management for instructors and students based on the Ruby on Rails<ref>http://www.rubyonrails.org</ref> framework. Expertiza allows the instructor to create new assignments and customise new or existing assignments. It also allows the instructor to create a list of topics the students can sign up for. Students can form teams in Expertiza to work on various projects and assignments. Students can also peer review other students' submissions. Expertiza supports submission across various document types, including the URLs and word documents. Expertiza provides a dashboard for all the assignments corresponding to a course and provides absolute control to the Instructors and Teaching Assistants. In addition to assignments, it encompasses peer reviews wherein participants are allowed to provide feedback anonymously about each other's work thereby providing scope for the better outcome. The due_date.rb file is responsible for informing the users about the deadline for submission of the each assignment. Due dates in Expertiza have their association with many other components like assignments, reviews etc.

=== Code Climate ===
Code Climate<ref>https://codeclimate.com/dashboard</ref> is a tool that runs static analysis on a GitHub project and outputs many details like test coverage, complexity, duplication, security, style, and more. There is a Google Chrome extension to integrate the Code Climate results generated directly into GitHub which is visible when browsing the repository on the browser. It allows us to see issues displayed directly inside GitHub's UI, to review which lines are covered in diffs and files, and add repositories and open tickets without changing your workflow.

== '''Tasks Identified''' ==
To install Code climate Chrome Extension that highlights the duplicated code.

To refactor the following two files:
* due_date.rb
** Ternary operators must not be nested. Prefer `if` or `else` constructs instead.
** Useless assignment to variable - `sorted_deadlines`.
** Prefer `each` over `for`.
** Use `find_by` instead of `where.first`.
** Correct the use of Time function
* deadline_helper.rb
** Do not use `Time.now` without zone. Use one of `Time.zone.now`, `Time.current`, `Time.now.in_time_zone`, `Time.now.utc`, `Time.now.getlocal`, `Time.now.iso8601`, `Time.now.jisx0301`, `Time.now.rfc3339`, `Time.now.to_i`, `Time.now.to_f` instead.
** Trailing whitespace detected.
** Extra empty line detected at module body end.

* Create respective RSpec<ref>{{Cite web|url=http://www.rspec.info|access-date=2016-10-28}}</ref>files in /spec/models/ and /spec/helper folder and write unit tests for each method in due_date.rb and deadline_helper.rb.

== '''Current Implementation''' ==
DueDate is a Model class to manage the deadlines of an assignment. It has methods for setting due dates for an assignment, copying due dates from one assignment to a new assignment etc. DeadlineHelper provides helper functions that help DueDate perform certain tasks. The assignment focuses on refactoring some of the methods based on warnings received from Code Climate's static analysis and modifying the language to make it more Ruby-friendly. The assignment also involves writing unit test cases for due_date.rb and deadline_helper.rb in order to increase test coverage.

The goal of this project is to attempt to make this part of the application easier to read and write unit test cases that the application must pass.

== '''Changed Implementation''' ==
Changes implemented involves refactoring the code and making it more understandable by adding comments in the code.

The modified files are
* due_date.rb (path: /app/models)
* deadline_helper.rb (path: /app/helpers)
Testing files
* due_date_spec.rb (path: /spec/models)
* deadline_helper_spec.rb (path: /spec/helpers)

=== due_date.rb ===
* Converted for..in loop to object.each in order to follow better Ruby syntax.
* Unnecessary assignment to sorted_deadlines removed.
* Nested ternary operators have been changed to if..else in order to make it more readable.
[[File:Duedaterb.png]]
* Changed where(...).first to find_by(...) which is the newer recommended syntax.
* Corrected the Time.now functions by adding the correct zones to them such as Time.zone.now.
* Removed trailing whitespaces.
[[File:DueDaterb2.png]]

=== deadline_helper.rb ===
* Time functions were changed to functions with zones
* Extra line removed
[[File:Deadlinehelper.png]]

== '''RSpec testing''' ==
There were no existing tests for the functions in due_date.rb and deadline_helper.rb. We have added exhaustive set of RSpec tests to test all the code. We have added two new spec files 'due_date_spec.rb' and ‘deadline_helper_spec.rb’ which cover the testing scenarios for the functions in ‘due_date.rb’ and ‘deadline_helper.rb’.

For both of these two files, all Travis CI<ref>{{Cite web|url=http://http://www.travis-ci.com|access-date=2016-10-28}}</ref> test cases have passed for all previous test cases as well as the ones added by us with the test coverage for the files due_date.rb and deadline_helper.rb reported as 100%.

These RSpec files have 100% code coverage visible at: /coverage/index.html.

=== due_date_spec.rb ===
This file is located at spec/models and tests the functionalities of the due_date.rb file located in app/models. There are 18 test cases in total which are listed below.
* If the factory is successfully able to build the due_date objects.
<pre>
it "due date factory created successfully" do
expect(@assignment_due_date).to be_valid
end
</pre>
<pre>
it "due dates created correctly" do
expect(@due_dates.length).to be == 10
end
</pre>
* If the function "set_flag" successfully sets the due_date flag.
<pre>
it "due date flag is set" do
expect(@assignment_due_date.flag).to be false
@assignment_due_date.set_flag
expect(@assignment_due_date.flag).to be true
end
</pre>
* If the function "due_at_is_valid_datetime" returns nil (no errors) for a valid datetime in due_at (no invalid test cases can be added here because model does not allow invalid datetime to be set at all).
<pre>
it "due at is valid datetime" do
expect(@assignment_due_date.due_at_is_valid_datetime).to be nil
end
</pre>
* If the function "self.copy" is able to copy due dates from one assignment to another.
<pre>
it "copy due dates to new assignment" do
new_assignment_id = build(:assignment, id: 999).id
old_assignment_id = @assignment_due_date.assignment.id
DueDate.copy(old_assignment_id, new_assignment_id)
expect(DueDate.where(parent_id: new_assignment_id).count).to eql DueDate.where(parent_id: old_assignment_id).count
end
</pre>
* If the function "self.set_duedate" is able to create another due date by copying data from an existing due date object.
<pre>
it "create new duedate record with values" do
DueDate.set_duedate({id: 999}, @assignment_due_date.deadline_type_id,
@assignment_due_date.parent_id, @assignment_due_date.round)
new_due_date = DueDate.find_by(id: 999)
expect(new_due_date).to be_valid
expect(new_due_date.deadline_type_id).to eql @assignment_due_date.deadline_type_id
expect(new_due_date.parent_id).to eql @assignment_due_date.parent_id
expect(new_due_date.round).to eql @assignment_due_date.round
end
</pre>
* If the function "self.deadline_sort" is able to sort the due dates in ascending order.
<pre>
it "sort duedate records" do
sorted_due_dates = @due_dates
expect(sorted_due_dates.each_cons(2).all?{|m1, m2| (m1.due_at <=> m2.due_at) != 1}).to eql false

sorted_due_dates = DueDate.deadline_sort(@due_dates)
expect(sorted_due_dates.each_cons(2).all?{|m1, m2| (m1.due_at <=> m2.due_at) != 1}).to eql true
end
</pre>
* If the function "self.done_in_assignment_round" returns the correct number of rounds for specific inputs. This involves an invalid test case as well for 0 rounds.
<pre>
describe "#done_in_assignment_round" do
it "return 0 when no response map" do
response = ReviewResponseMap.create
response.type = "ResponseMap"
response.save
expect(DueDate.done_in_assignment_round(1, response)).to eql 0
end

it "return round 1 for single round" do
response = ReviewResponseMap.create
expect(DueDate.done_in_assignment_round(@assignment_due_date.parent_id, response)).to eql 1
end
end
</pre>
* If the function "self.get_next_due_date" works as expected. This involves several invalid test cases as well.
<pre>
describe "#get_next_due_date" do
it "no subsequent due date" do
expect(DueDate.get_next_due_date(@assignment_due_date.parent_id)).to be nil
end

it "nil value throws exception" do
expect { DueDate.get_next_due_date(nil) }.to raise_exception(ActiveRecord::RecordNotFound)
end

it "get next assignment due date" do
due_date = create(:assignment_due_date, deadline_type: @deadline_type,
submission_allowed_id: @deadline_right.id, review_allowed_id: @deadline_right.id,
review_of_review_allowed_id: @deadline_right.id, due_at: Time.zone.now + 5000)
expect(DueDate.get_next_due_date(due_date.parent_id)).to be_valid
end

it "get next due date from topic for staggered deadline" do
assignment_id = create(:assignment, staggered_deadline: true, name: "testassignment").id
due_date = create(:topic_due_date, deadline_type: @deadline_type,
submission_allowed_id: @deadline_right.id, review_allowed_id: @deadline_right.id,
review_of_review_allowed_id: @deadline_right.id, due_at: Time.zone.now + 5000, parent_id: assignment_id)
expect(DueDate.get_next_due_date(assignment_id, due_date.parent_id)).to be_valid
end

it "next due date does not exist for staggered deadline" do
assignment_id = create(:assignment, staggered_deadline: true, name: "testassignment").id
due_date = create(:topic_due_date, deadline_type: @deadline_type,
submission_allowed_id: @deadline_right, review_allowed_id: @deadline_right,
review_of_review_allowed_id: @deadline_right, due_at: Time.zone.now + 5000, parent_id: assignment_id)
expect(DueDate.get_next_due_date(assignment_id)).to be nil
end

it "next due date is before Time.now for staggered deadline" do
assignment_id = create(:assignment, staggered_deadline: true, name: "testassignment").id
due_date = create(:topic_due_date, deadline_type: @deadline_type,
submission_allowed_id: @deadline_right, review_allowed_id: @deadline_right,
review_of_review_allowed_id: @deadline_right, due_at: Time.zone.now - 5000, parent_id: assignment_id)
expect(DueDate.get_next_due_date(assignment_id, due_date.parent_id)).to be nil
end

it "get next due date from assignment for staggered deadline" do
assignment_id = create(:assignment, staggered_deadline: true, name: "testassignment").id
due_date = create(:assignment_due_date, deadline_type: @deadline_type,
submission_allowed_id: @deadline_right, review_allowed_id: @deadline_right,
review_of_review_allowed_id: @deadline_right, due_at: Time.zone.now + 5000, parent_id: assignment_id)
expect(DueDate.get_next_due_date(assignment_id)).to be_valid
end
end
</pre>
* If the function "self.default_permission" returns the correct default permissions for particular deadline and permission types.
<pre>
it "metareview review_of_review_allowed default permission OK" do
expect(DueDate.default_permission('metareview', 'review_of_review_allowed')).to be == DeadlineRight::OK
end
</pre>
<pre>
it "review submission_allowed default permission NO" do
expect(DueDate.default_permission('review', 'submission_allowed')).to be == DeadlineRight::NO
end
</pre>
To test this file run the following command:
<pre>
rspec spec/models/due_date_spec.rb
</pre>
The output of this RSpec file is present in below screenshot:
[[File:Duedaterspec.png]]

Code coverage details of the above RSpec files is present in below screenshot:
[[File:Duedatecoverage.png]]

=== deadline_helper_spec.rb ===
This is a test file for testing the functionalities of Deadline_helper.rb file located at app/helpers. Different test cases present in this file are:
* Check if the factory<ref>{{Cite web|url=http://http://www.semaphoreci.com|access-date=2016-10-28}}</ref> is valid:
<pre>
it "has a valid factory" do
factory = FactoryGirl.build(:topic_due_date)
expect(factory).to be_valid
end
</pre>
* Fail if the due date is invalid:
<pre>
it "should fail because of invalid due_date" do
expect { DeadlineHelper.create_topic_deadline(nil, 0, 0)}.to raise_exception(NoMethodError)
end
</pre>
* If new due_date object is created:
<pre>
it "new due_date object created" do
DeadlineHelper.create_topic_deadline(@topic_due_date, 0, 1)
expect(TopicDueDate.count).to be == 2
end
</pre>
* due_at should be same for 0 offset:
<pre>
it "due_at should be same for 0 offset" do
DeadlineHelper.create_topic_deadline(@topic_due_date, 0, 10)
new_due_date = TopicDueDate.find_by(parent_id: 10)
expect(new_due_date).to be_valid
expect(new_due_date.due_at.to_s).to be == @topic_due_date.due_at.to_s
end
</pre>
* due_at is calculated correctly if offset is positive:
<pre>
it "due_at calculated correctly for positive offset" do
DeadlineHelper.create_topic_deadline(@topic_due_date, 5000, 10)
new_due_date = TopicDueDate.find_by(parent_id: 10)
expect(new_due_date).to be_valid
expect(new_due_date.due_at.to_s).to be == (Time.zone.parse(@topic_due_date.due_at.to_s) + 5000).to_s
end
</pre>
* due_at is calculated correctly if offset is negative:
<pre>
it "due_at calculated correctly for negative offset" do
DeadlineHelper.create_topic_deadline(@topic_due_date, -5000, 10)
new_due_date = TopicDueDate.find_by(parent_id: 10)
expect(new_due_date).to be_valid
expect(new_due_date.due_at.to_s).to be == (Time.zone.parse(@topic_due_date.due_at.to_s) - 5000).to_s
end
</pre>
* The offset is being converted to integer properly:
<pre>
it "offset converted to integer correctly" do
DeadlineHelper.create_topic_deadline(@topic_due_date, 5000.15, 10)
new_due_date = TopicDueDate.find_by(parent_id: 10)
expect(new_due_date).to be_valid
expect(new_due_date.due_at.to_s).to be == (Time.zone.parse(@topic_due_date.due_at.to_s) + 5000).to_s
end
</pre>
To test this file run the following command:
<pre>
rspec spec/models/deadline_helper_spec.rb
</pre>
The output of this RSpec file is present in below screenshot:
[[File:Deadlinerspec.png]]

Code coverage details of the above RSpec files is present in below screenshot:
[[File:Deadlinecoverage.png]]

==Sources and Citations==
{{reflist}}

CSC/ECE 517 Fall 2016/E1634. Refactor and write unit test of due date.rb and deadline helper.rb

2016-10-29T01:44:35Z

Aagrawa6: /* References */

== '''Introduction''' ==

=== Expertiza ===
Expertiza<ref>http://www.expertiza.ncsu.edu</ref>{{Reflist}} is an open source project for school assignment management for instructors and students based on the Ruby on Rails<ref>http://www.rubyonrails.org</ref> framework. Expertiza allows the instructor to create new assignments and customise new or existing assignments. It also allows the instructor to create a list of topics the students can sign up for. Students can form teams in Expertiza to work on various projects and assignments. Students can also peer review other students' submissions. Expertiza supports submission across various document types, including the URLs and word documents. Expertiza provides a dashboard for all the assignments corresponding to a course and provides absolute control to the Instructors and Teaching Assistants. In addition to assignments, it encompasses peer reviews wherein participants are allowed to provide feedback anonymously about each other's work thereby providing scope for the better outcome. The due_date.rb file is responsible for informing the users about the deadline for submission of the each assignment. Due dates in Expertiza have their association with many other components like assignments, reviews etc.

=== Code Climate ===
Code Climate<ref>{{Cite web|url=https://codeclimate.com/dashboard|title=Log in to your Code Climate dashboard with GitHub or your email.|website=codeclimate.com|access-date=2016-10-28}}</ref> is a tool that runs static analysis on a GitHub project and outputs many details like test coverage, complexity, duplication, security, style, and more. There is a Google Chrome extension to integrate the Code Climate results generated directly into GitHub which is visible when browsing the repository on the browser. It allows us to see issues displayed directly inside GitHub's UI, to review which lines are covered in diffs and files, and add repositories and open tickets without changing your workflow.

== '''Tasks Identified''' ==
To install Code climate Chrome Extension that highlights the duplicated code.

To refactor the following two files:
* due_date.rb
** Ternary operators must not be nested. Prefer `if` or `else` constructs instead.
** Useless assignment to variable - `sorted_deadlines`.
** Prefer `each` over `for`.
** Use `find_by` instead of `where.first`.
** Correct the use of Time function
* deadline_helper.rb
** Do not use `Time.now` without zone. Use one of `Time.zone.now`, `Time.current`, `Time.now.in_time_zone`, `Time.now.utc`, `Time.now.getlocal`, `Time.now.iso8601`, `Time.now.jisx0301`, `Time.now.rfc3339`, `Time.now.to_i`, `Time.now.to_f` instead.
** Trailing whitespace detected.
** Extra empty line detected at module body end.

* Create respective RSpec<ref>{{Cite web|url=http://www.rspec.info|access-date=2016-10-28}}</ref>files in /spec/models/ and /spec/helper folder and write unit tests for each method in due_date.rb and deadline_helper.rb.

== '''Current Implementation''' ==
DueDate is a Model class to manage the deadlines of an assignment. It has methods for setting due dates for an assignment, copying due dates from one assignment to a new assignment etc. DeadlineHelper provides helper functions that help DueDate perform certain tasks. The assignment focuses on refactoring some of the methods based on warnings received from Code Climate's static analysis and modifying the language to make it more Ruby-friendly. The assignment also involves writing unit test cases for due_date.rb and deadline_helper.rb in order to increase test coverage.

The goal of this project is to attempt to make this part of the application easier to read and write unit test cases that the application must pass.

== '''Changed Implementation''' ==
Changes implemented involves refactoring the code and making it more understandable by adding comments in the code.

The modified files are
* due_date.rb (path: /app/models)
* deadline_helper.rb (path: /app/helpers)
Testing files
* due_date_spec.rb (path: /spec/models)
* deadline_helper_spec.rb (path: /spec/helpers)

=== due_date.rb ===
* Converted for..in loop to object.each in order to follow better Ruby syntax.
* Unnecessary assignment to sorted_deadlines removed.
* Nested ternary operators have been changed to if..else in order to make it more readable.
[[File:Duedaterb.png]]
* Changed where(...).first to find_by(...) which is the newer recommended syntax.
* Corrected the Time.now functions by adding the correct zones to them such as Time.zone.now.
* Removed trailing whitespaces.
[[File:DueDaterb2.png]]

=== deadline_helper.rb ===
* Time functions were changed to functions with zones
* Extra line removed
[[File:Deadlinehelper.png]]

== '''RSpec testing''' ==
There were no existing tests for the functions in due_date.rb and deadline_helper.rb. We have added exhaustive set of RSpec tests to test all the code. We have added two new spec files 'due_date_spec.rb' and ‘deadline_helper_spec.rb’ which cover the testing scenarios for the functions in ‘due_date.rb’ and ‘deadline_helper.rb’.

For both of these two files, all Travis CI<ref>{{Cite web|url=http://http://www.travis-ci.com|access-date=2016-10-28}}</ref> test cases have passed for all previous test cases as well as the ones added by us with the test coverage for the files due_date.rb and deadline_helper.rb reported as 100%.

These RSpec files have 100% code coverage visible at: /coverage/index.html.

=== due_date_spec.rb ===
This file is located at spec/models and tests the functionalities of the due_date.rb file located in app/models. There are 18 test cases in total which are listed below.
* If the factory is successfully able to build the due_date objects.
<pre>
it "due date factory created successfully" do
expect(@assignment_due_date).to be_valid
end
</pre>
<pre>
it "due dates created correctly" do
expect(@due_dates.length).to be == 10
end
</pre>
* If the function "set_flag" successfully sets the due_date flag.
<pre>
it "due date flag is set" do
expect(@assignment_due_date.flag).to be false
@assignment_due_date.set_flag
expect(@assignment_due_date.flag).to be true
end
</pre>
* If the function "due_at_is_valid_datetime" returns nil (no errors) for a valid datetime in due_at (no invalid test cases can be added here because model does not allow invalid datetime to be set at all).
<pre>
it "due at is valid datetime" do
expect(@assignment_due_date.due_at_is_valid_datetime).to be nil
end
</pre>
* If the function "self.copy" is able to copy due dates from one assignment to another.
<pre>
it "copy due dates to new assignment" do
new_assignment_id = build(:assignment, id: 999).id
old_assignment_id = @assignment_due_date.assignment.id
DueDate.copy(old_assignment_id, new_assignment_id)
expect(DueDate.where(parent_id: new_assignment_id).count).to eql DueDate.where(parent_id: old_assignment_id).count
end
</pre>
* If the function "self.set_duedate" is able to create another due date by copying data from an existing due date object.
<pre>
it "create new duedate record with values" do
DueDate.set_duedate({id: 999}, @assignment_due_date.deadline_type_id,
@assignment_due_date.parent_id, @assignment_due_date.round)
new_due_date = DueDate.find_by(id: 999)
expect(new_due_date).to be_valid
expect(new_due_date.deadline_type_id).to eql @assignment_due_date.deadline_type_id
expect(new_due_date.parent_id).to eql @assignment_due_date.parent_id
expect(new_due_date.round).to eql @assignment_due_date.round
end
</pre>
* If the function "self.deadline_sort" is able to sort the due dates in ascending order.
<pre>
it "sort duedate records" do
sorted_due_dates = @due_dates
expect(sorted_due_dates.each_cons(2).all?{|m1, m2| (m1.due_at <=> m2.due_at) != 1}).to eql false

sorted_due_dates = DueDate.deadline_sort(@due_dates)
expect(sorted_due_dates.each_cons(2).all?{|m1, m2| (m1.due_at <=> m2.due_at) != 1}).to eql true
end
</pre>
* If the function "self.done_in_assignment_round" returns the correct number of rounds for specific inputs. This involves an invalid test case as well for 0 rounds.
<pre>
describe "#done_in_assignment_round" do
it "return 0 when no response map" do
response = ReviewResponseMap.create
response.type = "ResponseMap"
response.save
expect(DueDate.done_in_assignment_round(1, response)).to eql 0
end

it "return round 1 for single round" do
response = ReviewResponseMap.create
expect(DueDate.done_in_assignment_round(@assignment_due_date.parent_id, response)).to eql 1
end
end
</pre>
* If the function "self.get_next_due_date" works as expected. This involves several invalid test cases as well.
<pre>
describe "#get_next_due_date" do
it "no subsequent due date" do
expect(DueDate.get_next_due_date(@assignment_due_date.parent_id)).to be nil
end

it "nil value throws exception" do
expect { DueDate.get_next_due_date(nil) }.to raise_exception(ActiveRecord::RecordNotFound)
end

it "get next assignment due date" do
due_date = create(:assignment_due_date, deadline_type: @deadline_type,
submission_allowed_id: @deadline_right.id, review_allowed_id: @deadline_right.id,
review_of_review_allowed_id: @deadline_right.id, due_at: Time.zone.now + 5000)
expect(DueDate.get_next_due_date(due_date.parent_id)).to be_valid
end

it "get next due date from topic for staggered deadline" do
assignment_id = create(:assignment, staggered_deadline: true, name: "testassignment").id
due_date = create(:topic_due_date, deadline_type: @deadline_type,
submission_allowed_id: @deadline_right.id, review_allowed_id: @deadline_right.id,
review_of_review_allowed_id: @deadline_right.id, due_at: Time.zone.now + 5000, parent_id: assignment_id)
expect(DueDate.get_next_due_date(assignment_id, due_date.parent_id)).to be_valid
end

it "next due date does not exist for staggered deadline" do
assignment_id = create(:assignment, staggered_deadline: true, name: "testassignment").id
due_date = create(:topic_due_date, deadline_type: @deadline_type,
submission_allowed_id: @deadline_right, review_allowed_id: @deadline_right,
review_of_review_allowed_id: @deadline_right, due_at: Time.zone.now + 5000, parent_id: assignment_id)
expect(DueDate.get_next_due_date(assignment_id)).to be nil
end

it "next due date is before Time.now for staggered deadline" do
assignment_id = create(:assignment, staggered_deadline: true, name: "testassignment").id
due_date = create(:topic_due_date, deadline_type: @deadline_type,
submission_allowed_id: @deadline_right, review_allowed_id: @deadline_right,
review_of_review_allowed_id: @deadline_right, due_at: Time.zone.now - 5000, parent_id: assignment_id)
expect(DueDate.get_next_due_date(assignment_id, due_date.parent_id)).to be nil
end

it "get next due date from assignment for staggered deadline" do
assignment_id = create(:assignment, staggered_deadline: true, name: "testassignment").id
due_date = create(:assignment_due_date, deadline_type: @deadline_type,
submission_allowed_id: @deadline_right, review_allowed_id: @deadline_right,
review_of_review_allowed_id: @deadline_right, due_at: Time.zone.now + 5000, parent_id: assignment_id)
expect(DueDate.get_next_due_date(assignment_id)).to be_valid
end
end
</pre>
* If the function "self.default_permission" returns the correct default permissions for particular deadline and permission types.
<pre>
it "metareview review_of_review_allowed default permission OK" do
expect(DueDate.default_permission('metareview', 'review_of_review_allowed')).to be == DeadlineRight::OK
end
</pre>
<pre>
it "review submission_allowed default permission NO" do
expect(DueDate.default_permission('review', 'submission_allowed')).to be == DeadlineRight::NO
end
</pre>
To test this file run the following command:
<pre>
rspec spec/models/due_date_spec.rb
</pre>
The output of this RSpec file is present in below screenshot:
[[File:Duedaterspec.png]]

Code coverage details of the above RSpec files is present in below screenshot:
[[File:Duedatecoverage.png]]

=== deadline_helper_spec.rb ===
This is a test file for testing the functionalities of Deadline_helper.rb file located at app/helpers. Different test cases present in this file are:
* Check if the factory<ref>{{Cite web|url=http://http://www.semaphoreci.com|access-date=2016-10-28}}</ref> is valid:
<pre>
it "has a valid factory" do
factory = FactoryGirl.build(:topic_due_date)
expect(factory).to be_valid
end
</pre>
* Fail if the due date is invalid:
<pre>
it "should fail because of invalid due_date" do
expect { DeadlineHelper.create_topic_deadline(nil, 0, 0)}.to raise_exception(NoMethodError)
end
</pre>
* If new due_date object is created:
<pre>
it "new due_date object created" do
DeadlineHelper.create_topic_deadline(@topic_due_date, 0, 1)
expect(TopicDueDate.count).to be == 2
end
</pre>
* due_at should be same for 0 offset:
<pre>
it "due_at should be same for 0 offset" do
DeadlineHelper.create_topic_deadline(@topic_due_date, 0, 10)
new_due_date = TopicDueDate.find_by(parent_id: 10)
expect(new_due_date).to be_valid
expect(new_due_date.due_at.to_s).to be == @topic_due_date.due_at.to_s
end
</pre>
* due_at is calculated correctly if offset is positive:
<pre>
it "due_at calculated correctly for positive offset" do
DeadlineHelper.create_topic_deadline(@topic_due_date, 5000, 10)
new_due_date = TopicDueDate.find_by(parent_id: 10)
expect(new_due_date).to be_valid
expect(new_due_date.due_at.to_s).to be == (Time.zone.parse(@topic_due_date.due_at.to_s) + 5000).to_s
end
</pre>
* due_at is calculated correctly if offset is negative:
<pre>
it "due_at calculated correctly for negative offset" do
DeadlineHelper.create_topic_deadline(@topic_due_date, -5000, 10)
new_due_date = TopicDueDate.find_by(parent_id: 10)
expect(new_due_date).to be_valid
expect(new_due_date.due_at.to_s).to be == (Time.zone.parse(@topic_due_date.due_at.to_s) - 5000).to_s
end
</pre>
* The offset is being converted to integer properly:
<pre>
it "offset converted to integer correctly" do
DeadlineHelper.create_topic_deadline(@topic_due_date, 5000.15, 10)
new_due_date = TopicDueDate.find_by(parent_id: 10)
expect(new_due_date).to be_valid
expect(new_due_date.due_at.to_s).to be == (Time.zone.parse(@topic_due_date.due_at.to_s) + 5000).to_s
end
</pre>
To test this file run the following command:
<pre>
rspec spec/models/deadline_helper_spec.rb
</pre>
The output of this RSpec file is present in below screenshot:
[[File:Deadlinerspec.png]]

Code coverage details of the above RSpec files is present in below screenshot:
[[File:Deadlinecoverage.png]]

==Sources and Citations==
{{reflist}}

CSC/ECE 517 Fall 2016/E1634. Refactor and write unit test of due date.rb and deadline helper.rb

2016-10-29T01:42:26Z

Aagrawa6: /* Expertiza */

== '''Introduction''' ==

=== Expertiza ===
Expertiza<ref>http://www.expertiza.ncsu.edu</ref>{{Reflist}} is an open source project for school assignment management for instructors and students based on the Ruby on Rails<ref>http://www.rubyonrails.org</ref> framework. Expertiza allows the instructor to create new assignments and customise new or existing assignments. It also allows the instructor to create a list of topics the students can sign up for. Students can form teams in Expertiza to work on various projects and assignments. Students can also peer review other students' submissions. Expertiza supports submission across various document types, including the URLs and word documents. Expertiza provides a dashboard for all the assignments corresponding to a course and provides absolute control to the Instructors and Teaching Assistants. In addition to assignments, it encompasses peer reviews wherein participants are allowed to provide feedback anonymously about each other's work thereby providing scope for the better outcome. The due_date.rb file is responsible for informing the users about the deadline for submission of the each assignment. Due dates in Expertiza have their association with many other components like assignments, reviews etc.

=== Code Climate ===
Code Climate<ref>{{Cite web|url=https://codeclimate.com/dashboard|title=Log in to your Code Climate dashboard with GitHub or your email.|website=codeclimate.com|access-date=2016-10-28}}</ref> is a tool that runs static analysis on a GitHub project and outputs many details like test coverage, complexity, duplication, security, style, and more. There is a Google Chrome extension to integrate the Code Climate results generated directly into GitHub which is visible when browsing the repository on the browser. It allows us to see issues displayed directly inside GitHub's UI, to review which lines are covered in diffs and files, and add repositories and open tickets without changing your workflow.

== '''Tasks Identified''' ==
To install Code climate Chrome Extension that highlights the duplicated code.

To refactor the following two files:
* due_date.rb
** Ternary operators must not be nested. Prefer `if` or `else` constructs instead.
** Useless assignment to variable - `sorted_deadlines`.
** Prefer `each` over `for`.
** Use `find_by` instead of `where.first`.
** Correct the use of Time function
* deadline_helper.rb
** Do not use `Time.now` without zone. Use one of `Time.zone.now`, `Time.current`, `Time.now.in_time_zone`, `Time.now.utc`, `Time.now.getlocal`, `Time.now.iso8601`, `Time.now.jisx0301`, `Time.now.rfc3339`, `Time.now.to_i`, `Time.now.to_f` instead.
** Trailing whitespace detected.
** Extra empty line detected at module body end.

* Create respective RSpec<ref>{{Cite web|url=http://www.rspec.info|access-date=2016-10-28}}</ref>files in /spec/models/ and /spec/helper folder and write unit tests for each method in due_date.rb and deadline_helper.rb.

== '''Current Implementation''' ==
DueDate is a Model class to manage the deadlines of an assignment. It has methods for setting due dates for an assignment, copying due dates from one assignment to a new assignment etc. DeadlineHelper provides helper functions that help DueDate perform certain tasks. The assignment focuses on refactoring some of the methods based on warnings received from Code Climate's static analysis and modifying the language to make it more Ruby-friendly. The assignment also involves writing unit test cases for due_date.rb and deadline_helper.rb in order to increase test coverage.

The goal of this project is to attempt to make this part of the application easier to read and write unit test cases that the application must pass.

== '''Changed Implementation''' ==
Changes implemented involves refactoring the code and making it more understandable by adding comments in the code.

The modified files are
* due_date.rb (path: /app/models)
* deadline_helper.rb (path: /app/helpers)
Testing files
* due_date_spec.rb (path: /spec/models)
* deadline_helper_spec.rb (path: /spec/helpers)

=== due_date.rb ===
* Converted for..in loop to object.each in order to follow better Ruby syntax.
* Unnecessary assignment to sorted_deadlines removed.
* Nested ternary operators have been changed to if..else in order to make it more readable.
[[File:Duedaterb.png]]
* Changed where(...).first to find_by(...) which is the newer recommended syntax.
* Corrected the Time.now functions by adding the correct zones to them such as Time.zone.now.
* Removed trailing whitespaces.
[[File:DueDaterb2.png]]

=== deadline_helper.rb ===
* Time functions were changed to functions with zones
* Extra line removed
[[File:Deadlinehelper.png]]

== '''RSpec testing''' ==
There were no existing tests for the functions in due_date.rb and deadline_helper.rb. We have added exhaustive set of RSpec tests to test all the code. We have added two new spec files 'due_date_spec.rb' and ‘deadline_helper_spec.rb’ which cover the testing scenarios for the functions in ‘due_date.rb’ and ‘deadline_helper.rb’.

For both of these two files, all Travis CI<ref>{{Cite web|url=http://http://www.travis-ci.com|access-date=2016-10-28}}</ref> test cases have passed for all previous test cases as well as the ones added by us with the test coverage for the files due_date.rb and deadline_helper.rb reported as 100%.

These RSpec files have 100% code coverage visible at: /coverage/index.html.

=== due_date_spec.rb ===
This file is located at spec/models and tests the functionalities of the due_date.rb file located in app/models. There are 18 test cases in total which are listed below.
* If the factory is successfully able to build the due_date objects.
<pre>
it "due date factory created successfully" do
expect(@assignment_due_date).to be_valid
end
</pre>
<pre>
it "due dates created correctly" do
expect(@due_dates.length).to be == 10
end
</pre>
* If the function "set_flag" successfully sets the due_date flag.
<pre>
it "due date flag is set" do
expect(@assignment_due_date.flag).to be false
@assignment_due_date.set_flag
expect(@assignment_due_date.flag).to be true
end
</pre>
* If the function "due_at_is_valid_datetime" returns nil (no errors) for a valid datetime in due_at (no invalid test cases can be added here because model does not allow invalid datetime to be set at all).
<pre>
it "due at is valid datetime" do
expect(@assignment_due_date.due_at_is_valid_datetime).to be nil
end
</pre>
* If the function "self.copy" is able to copy due dates from one assignment to another.
<pre>
it "copy due dates to new assignment" do
new_assignment_id = build(:assignment, id: 999).id
old_assignment_id = @assignment_due_date.assignment.id
DueDate.copy(old_assignment_id, new_assignment_id)
expect(DueDate.where(parent_id: new_assignment_id).count).to eql DueDate.where(parent_id: old_assignment_id).count
end
</pre>
* If the function "self.set_duedate" is able to create another due date by copying data from an existing due date object.
<pre>
it "create new duedate record with values" do
DueDate.set_duedate({id: 999}, @assignment_due_date.deadline_type_id,
@assignment_due_date.parent_id, @assignment_due_date.round)
new_due_date = DueDate.find_by(id: 999)
expect(new_due_date).to be_valid
expect(new_due_date.deadline_type_id).to eql @assignment_due_date.deadline_type_id
expect(new_due_date.parent_id).to eql @assignment_due_date.parent_id
expect(new_due_date.round).to eql @assignment_due_date.round
end
</pre>
* If the function "self.deadline_sort" is able to sort the due dates in ascending order.
<pre>
it "sort duedate records" do
sorted_due_dates = @due_dates
expect(sorted_due_dates.each_cons(2).all?{|m1, m2| (m1.due_at <=> m2.due_at) != 1}).to eql false

sorted_due_dates = DueDate.deadline_sort(@due_dates)
expect(sorted_due_dates.each_cons(2).all?{|m1, m2| (m1.due_at <=> m2.due_at) != 1}).to eql true
end
</pre>
* If the function "self.done_in_assignment_round" returns the correct number of rounds for specific inputs. This involves an invalid test case as well for 0 rounds.
<pre>
describe "#done_in_assignment_round" do
it "return 0 when no response map" do
response = ReviewResponseMap.create
response.type = "ResponseMap"
response.save
expect(DueDate.done_in_assignment_round(1, response)).to eql 0
end

it "return round 1 for single round" do
response = ReviewResponseMap.create
expect(DueDate.done_in_assignment_round(@assignment_due_date.parent_id, response)).to eql 1
end
end
</pre>
* If the function "self.get_next_due_date" works as expected. This involves several invalid test cases as well.
<pre>
describe "#get_next_due_date" do
it "no subsequent due date" do
expect(DueDate.get_next_due_date(@assignment_due_date.parent_id)).to be nil
end

it "nil value throws exception" do
expect { DueDate.get_next_due_date(nil) }.to raise_exception(ActiveRecord::RecordNotFound)
end

it "get next assignment due date" do
due_date = create(:assignment_due_date, deadline_type: @deadline_type,
submission_allowed_id: @deadline_right.id, review_allowed_id: @deadline_right.id,
review_of_review_allowed_id: @deadline_right.id, due_at: Time.zone.now + 5000)
expect(DueDate.get_next_due_date(due_date.parent_id)).to be_valid
end

it "get next due date from topic for staggered deadline" do
assignment_id = create(:assignment, staggered_deadline: true, name: "testassignment").id
due_date = create(:topic_due_date, deadline_type: @deadline_type,
submission_allowed_id: @deadline_right.id, review_allowed_id: @deadline_right.id,
review_of_review_allowed_id: @deadline_right.id, due_at: Time.zone.now + 5000, parent_id: assignment_id)
expect(DueDate.get_next_due_date(assignment_id, due_date.parent_id)).to be_valid
end

it "next due date does not exist for staggered deadline" do
assignment_id = create(:assignment, staggered_deadline: true, name: "testassignment").id
due_date = create(:topic_due_date, deadline_type: @deadline_type,
submission_allowed_id: @deadline_right, review_allowed_id: @deadline_right,
review_of_review_allowed_id: @deadline_right, due_at: Time.zone.now + 5000, parent_id: assignment_id)
expect(DueDate.get_next_due_date(assignment_id)).to be nil
end

it "next due date is before Time.now for staggered deadline" do
assignment_id = create(:assignment, staggered_deadline: true, name: "testassignment").id
due_date = create(:topic_due_date, deadline_type: @deadline_type,
submission_allowed_id: @deadline_right, review_allowed_id: @deadline_right,
review_of_review_allowed_id: @deadline_right, due_at: Time.zone.now - 5000, parent_id: assignment_id)
expect(DueDate.get_next_due_date(assignment_id, due_date.parent_id)).to be nil
end

it "get next due date from assignment for staggered deadline" do
assignment_id = create(:assignment, staggered_deadline: true, name: "testassignment").id
due_date = create(:assignment_due_date, deadline_type: @deadline_type,
submission_allowed_id: @deadline_right, review_allowed_id: @deadline_right,
review_of_review_allowed_id: @deadline_right, due_at: Time.zone.now + 5000, parent_id: assignment_id)
expect(DueDate.get_next_due_date(assignment_id)).to be_valid
end
end
</pre>
* If the function "self.default_permission" returns the correct default permissions for particular deadline and permission types.
<pre>
it "metareview review_of_review_allowed default permission OK" do
expect(DueDate.default_permission('metareview', 'review_of_review_allowed')).to be == DeadlineRight::OK
end
</pre>
<pre>
it "review submission_allowed default permission NO" do
expect(DueDate.default_permission('review', 'submission_allowed')).to be == DeadlineRight::NO
end
</pre>
To test this file run the following command:
<pre>
rspec spec/models/due_date_spec.rb
</pre>
The output of this RSpec file is present in below screenshot:
[[File:Duedaterspec.png]]

Code coverage details of the above RSpec files is present in below screenshot:
[[File:Duedatecoverage.png]]

=== deadline_helper_spec.rb ===
This is a test file for testing the functionalities of Deadline_helper.rb file located at app/helpers. Different test cases present in this file are:
* Check if the factory<ref>{{Cite web|url=http://http://www.semaphoreci.com|access-date=2016-10-28}}</ref> is valid:
<pre>
it "has a valid factory" do
factory = FactoryGirl.build(:topic_due_date)
expect(factory).to be_valid
end
</pre>
* Fail if the due date is invalid:
<pre>
it "should fail because of invalid due_date" do
expect { DeadlineHelper.create_topic_deadline(nil, 0, 0)}.to raise_exception(NoMethodError)
end
</pre>
* If new due_date object is created:
<pre>
it "new due_date object created" do
DeadlineHelper.create_topic_deadline(@topic_due_date, 0, 1)
expect(TopicDueDate.count).to be == 2
end
</pre>
* due_at should be same for 0 offset:
<pre>
it "due_at should be same for 0 offset" do
DeadlineHelper.create_topic_deadline(@topic_due_date, 0, 10)
new_due_date = TopicDueDate.find_by(parent_id: 10)
expect(new_due_date).to be_valid
expect(new_due_date.due_at.to_s).to be == @topic_due_date.due_at.to_s
end
</pre>
* due_at is calculated correctly if offset is positive:
<pre>
it "due_at calculated correctly for positive offset" do
DeadlineHelper.create_topic_deadline(@topic_due_date, 5000, 10)
new_due_date = TopicDueDate.find_by(parent_id: 10)
expect(new_due_date).to be_valid
expect(new_due_date.due_at.to_s).to be == (Time.zone.parse(@topic_due_date.due_at.to_s) + 5000).to_s
end
</pre>
* due_at is calculated correctly if offset is negative:
<pre>
it "due_at calculated correctly for negative offset" do
DeadlineHelper.create_topic_deadline(@topic_due_date, -5000, 10)
new_due_date = TopicDueDate.find_by(parent_id: 10)
expect(new_due_date).to be_valid
expect(new_due_date.due_at.to_s).to be == (Time.zone.parse(@topic_due_date.due_at.to_s) - 5000).to_s
end
</pre>
* The offset is being converted to integer properly:
<pre>
it "offset converted to integer correctly" do
DeadlineHelper.create_topic_deadline(@topic_due_date, 5000.15, 10)
new_due_date = TopicDueDate.find_by(parent_id: 10)
expect(new_due_date).to be_valid
expect(new_due_date.due_at.to_s).to be == (Time.zone.parse(@topic_due_date.due_at.to_s) + 5000).to_s
end
</pre>
To test this file run the following command:
<pre>
rspec spec/models/deadline_helper_spec.rb
</pre>
The output of this RSpec file is present in below screenshot:
[[File:Deadlinerspec.png]]

Code coverage details of the above RSpec files is present in below screenshot:
[[File:Deadlinecoverage.png]]

== '''References''' ==
"[http://www.expertiza.ncsu.edu]" 
"[Ruby on Rails]". [http://www.rubyonrails.org]. Retrieved 2016-10-28. 
"[Log in to your Code Climate dashboard with GitHub or your email].". [http://www.codeclimate.com]. Retrieved 2016-10-28. 
"[RSpec: Behaviour Driven Development for Ruby]". [http://www.rspec.info]. Retrieved 2016-10-28. 
"[Travis CI - Test and Deploy with Confidence]". [http://www.travis-ci.com link title]. Retrieved 2016-10-28 
"[Working Effectively with Data Factories Using FactoryGirl]". [http://www.semaphoreci.com]. Retrieved 2016-10-28

CSC/ECE 517 Fall 2016/E1634. Refactor and write unit test of due date.rb and deadline helper.rb

2016-10-29T01:39:20Z

Aagrawa6: /* Expertiza */

== '''Introduction''' ==

=== Expertiza ===
Expertiza<ref>{{Cite web|url=http://www.expertiza.ncsu.edu|access-date=2016-10-28}}</ref>{{Reflist}} is an open source project for school assignment management for instructors and students based on the Ruby on Rails<ref>{{Cite web|url=http://www.rubyonrails.org|access-date=2016-10-28}}</ref> framework. Expertiza allows the instructor to create new assignments and customise new or existing assignments. It also allows the instructor to create a list of topics the students can sign up for. Students can form teams in Expertiza to work on various projects and assignments. Students can also peer review other students' submissions. Expertiza supports submission across various document types, including the URLs and word documents. Expertiza provides a dashboard for all the assignments corresponding to a course and provides absolute control to the Instructors and Teaching Assistants. In addition to assignments, it encompasses peer reviews wherein participants are allowed to provide feedback anonymously about each other's work thereby providing scope for the better outcome. The due_date.rb file is responsible for informing the users about the deadline for submission of the each assignment. Due dates in Expertiza have their association with many other components like assignments, reviews etc.

=== Code Climate ===
Code Climate<ref>{{Cite web|url=https://codeclimate.com/dashboard|title=Log in to your Code Climate dashboard with GitHub or your email.|website=codeclimate.com|access-date=2016-10-28}}</ref> is a tool that runs static analysis on a GitHub project and outputs many details like test coverage, complexity, duplication, security, style, and more. There is a Google Chrome extension to integrate the Code Climate results generated directly into GitHub which is visible when browsing the repository on the browser. It allows us to see issues displayed directly inside GitHub's UI, to review which lines are covered in diffs and files, and add repositories and open tickets without changing your workflow.

== '''Tasks Identified''' ==
To install Code climate Chrome Extension that highlights the duplicated code.

To refactor the following two files:
* due_date.rb
** Ternary operators must not be nested. Prefer `if` or `else` constructs instead.
** Useless assignment to variable - `sorted_deadlines`.
** Prefer `each` over `for`.
** Use `find_by` instead of `where.first`.
** Correct the use of Time function
* deadline_helper.rb
** Do not use `Time.now` without zone. Use one of `Time.zone.now`, `Time.current`, `Time.now.in_time_zone`, `Time.now.utc`, `Time.now.getlocal`, `Time.now.iso8601`, `Time.now.jisx0301`, `Time.now.rfc3339`, `Time.now.to_i`, `Time.now.to_f` instead.
** Trailing whitespace detected.
** Extra empty line detected at module body end.

* Create respective RSpec<ref>{{Cite web|url=http://www.rspec.info|access-date=2016-10-28}}</ref>files in /spec/models/ and /spec/helper folder and write unit tests for each method in due_date.rb and deadline_helper.rb.

== '''Current Implementation''' ==
DueDate is a Model class to manage the deadlines of an assignment. It has methods for setting due dates for an assignment, copying due dates from one assignment to a new assignment etc. DeadlineHelper provides helper functions that help DueDate perform certain tasks. The assignment focuses on refactoring some of the methods based on warnings received from Code Climate's static analysis and modifying the language to make it more Ruby-friendly. The assignment also involves writing unit test cases for due_date.rb and deadline_helper.rb in order to increase test coverage.

The goal of this project is to attempt to make this part of the application easier to read and write unit test cases that the application must pass.

== '''Changed Implementation''' ==
Changes implemented involves refactoring the code and making it more understandable by adding comments in the code.

The modified files are
* due_date.rb (path: /app/models)
* deadline_helper.rb (path: /app/helpers)
Testing files
* due_date_spec.rb (path: /spec/models)
* deadline_helper_spec.rb (path: /spec/helpers)

=== due_date.rb ===
* Converted for..in loop to object.each in order to follow better Ruby syntax.
* Unnecessary assignment to sorted_deadlines removed.
* Nested ternary operators have been changed to if..else in order to make it more readable.
[[File:Duedaterb.png]]
* Changed where(...).first to find_by(...) which is the newer recommended syntax.
* Corrected the Time.now functions by adding the correct zones to them such as Time.zone.now.
* Removed trailing whitespaces.
[[File:DueDaterb2.png]]

=== deadline_helper.rb ===
* Time functions were changed to functions with zones
* Extra line removed
[[File:Deadlinehelper.png]]

== '''RSpec testing''' ==
There were no existing tests for the functions in due_date.rb and deadline_helper.rb. We have added exhaustive set of RSpec tests to test all the code. We have added two new spec files 'due_date_spec.rb' and ‘deadline_helper_spec.rb’ which cover the testing scenarios for the functions in ‘due_date.rb’ and ‘deadline_helper.rb’.

For both of these two files, all Travis CI<ref>{{Cite web|url=http://http://www.travis-ci.com|access-date=2016-10-28}}</ref> test cases have passed for all previous test cases as well as the ones added by us with the test coverage for the files due_date.rb and deadline_helper.rb reported as 100%.

These RSpec files have 100% code coverage visible at: /coverage/index.html.

=== due_date_spec.rb ===
This file is located at spec/models and tests the functionalities of the due_date.rb file located in app/models. There are 18 test cases in total which are listed below.
* If the factory is successfully able to build the due_date objects.
<pre>
it "due date factory created successfully" do
expect(@assignment_due_date).to be_valid
end
</pre>
<pre>
it "due dates created correctly" do
expect(@due_dates.length).to be == 10
end
</pre>
* If the function "set_flag" successfully sets the due_date flag.
<pre>
it "due date flag is set" do
expect(@assignment_due_date.flag).to be false
@assignment_due_date.set_flag
expect(@assignment_due_date.flag).to be true
end
</pre>
* If the function "due_at_is_valid_datetime" returns nil (no errors) for a valid datetime in due_at (no invalid test cases can be added here because model does not allow invalid datetime to be set at all).
<pre>
it "due at is valid datetime" do
expect(@assignment_due_date.due_at_is_valid_datetime).to be nil
end
</pre>
* If the function "self.copy" is able to copy due dates from one assignment to another.
<pre>
it "copy due dates to new assignment" do
new_assignment_id = build(:assignment, id: 999).id
old_assignment_id = @assignment_due_date.assignment.id
DueDate.copy(old_assignment_id, new_assignment_id)
expect(DueDate.where(parent_id: new_assignment_id).count).to eql DueDate.where(parent_id: old_assignment_id).count
end
</pre>
* If the function "self.set_duedate" is able to create another due date by copying data from an existing due date object.
<pre>
it "create new duedate record with values" do
DueDate.set_duedate({id: 999}, @assignment_due_date.deadline_type_id,
@assignment_due_date.parent_id, @assignment_due_date.round)
new_due_date = DueDate.find_by(id: 999)
expect(new_due_date).to be_valid
expect(new_due_date.deadline_type_id).to eql @assignment_due_date.deadline_type_id
expect(new_due_date.parent_id).to eql @assignment_due_date.parent_id
expect(new_due_date.round).to eql @assignment_due_date.round
end
</pre>
* If the function "self.deadline_sort" is able to sort the due dates in ascending order.
<pre>
it "sort duedate records" do
sorted_due_dates = @due_dates
expect(sorted_due_dates.each_cons(2).all?{|m1, m2| (m1.due_at <=> m2.due_at) != 1}).to eql false

sorted_due_dates = DueDate.deadline_sort(@due_dates)
expect(sorted_due_dates.each_cons(2).all?{|m1, m2| (m1.due_at <=> m2.due_at) != 1}).to eql true
end
</pre>
* If the function "self.done_in_assignment_round" returns the correct number of rounds for specific inputs. This involves an invalid test case as well for 0 rounds.
<pre>
describe "#done_in_assignment_round" do
it "return 0 when no response map" do
response = ReviewResponseMap.create
response.type = "ResponseMap"
response.save
expect(DueDate.done_in_assignment_round(1, response)).to eql 0
end

it "return round 1 for single round" do
response = ReviewResponseMap.create
expect(DueDate.done_in_assignment_round(@assignment_due_date.parent_id, response)).to eql 1
end
end
</pre>
* If the function "self.get_next_due_date" works as expected. This involves several invalid test cases as well.
<pre>
describe "#get_next_due_date" do
it "no subsequent due date" do
expect(DueDate.get_next_due_date(@assignment_due_date.parent_id)).to be nil
end

it "nil value throws exception" do
expect { DueDate.get_next_due_date(nil) }.to raise_exception(ActiveRecord::RecordNotFound)
end

it "get next assignment due date" do
due_date = create(:assignment_due_date, deadline_type: @deadline_type,
submission_allowed_id: @deadline_right.id, review_allowed_id: @deadline_right.id,
review_of_review_allowed_id: @deadline_right.id, due_at: Time.zone.now + 5000)
expect(DueDate.get_next_due_date(due_date.parent_id)).to be_valid
end

it "get next due date from topic for staggered deadline" do
assignment_id = create(:assignment, staggered_deadline: true, name: "testassignment").id
due_date = create(:topic_due_date, deadline_type: @deadline_type,
submission_allowed_id: @deadline_right.id, review_allowed_id: @deadline_right.id,
review_of_review_allowed_id: @deadline_right.id, due_at: Time.zone.now + 5000, parent_id: assignment_id)
expect(DueDate.get_next_due_date(assignment_id, due_date.parent_id)).to be_valid
end

it "next due date does not exist for staggered deadline" do
assignment_id = create(:assignment, staggered_deadline: true, name: "testassignment").id
due_date = create(:topic_due_date, deadline_type: @deadline_type,
submission_allowed_id: @deadline_right, review_allowed_id: @deadline_right,
review_of_review_allowed_id: @deadline_right, due_at: Time.zone.now + 5000, parent_id: assignment_id)
expect(DueDate.get_next_due_date(assignment_id)).to be nil
end

it "next due date is before Time.now for staggered deadline" do
assignment_id = create(:assignment, staggered_deadline: true, name: "testassignment").id
due_date = create(:topic_due_date, deadline_type: @deadline_type,
submission_allowed_id: @deadline_right, review_allowed_id: @deadline_right,
review_of_review_allowed_id: @deadline_right, due_at: Time.zone.now - 5000, parent_id: assignment_id)
expect(DueDate.get_next_due_date(assignment_id, due_date.parent_id)).to be nil
end

it "get next due date from assignment for staggered deadline" do
assignment_id = create(:assignment, staggered_deadline: true, name: "testassignment").id
due_date = create(:assignment_due_date, deadline_type: @deadline_type,
submission_allowed_id: @deadline_right, review_allowed_id: @deadline_right,
review_of_review_allowed_id: @deadline_right, due_at: Time.zone.now + 5000, parent_id: assignment_id)
expect(DueDate.get_next_due_date(assignment_id)).to be_valid
end
end
</pre>
* If the function "self.default_permission" returns the correct default permissions for particular deadline and permission types.
<pre>
it "metareview review_of_review_allowed default permission OK" do
expect(DueDate.default_permission('metareview', 'review_of_review_allowed')).to be == DeadlineRight::OK
end
</pre>
<pre>
it "review submission_allowed default permission NO" do
expect(DueDate.default_permission('review', 'submission_allowed')).to be == DeadlineRight::NO
end
</pre>
To test this file run the following command:
<pre>
rspec spec/models/due_date_spec.rb
</pre>
The output of this RSpec file is present in below screenshot:
[[File:Duedaterspec.png]]

Code coverage details of the above RSpec files is present in below screenshot:
[[File:Duedatecoverage.png]]

=== deadline_helper_spec.rb ===
This is a test file for testing the functionalities of Deadline_helper.rb file located at app/helpers. Different test cases present in this file are:
* Check if the factory<ref>{{Cite web|url=http://http://www.semaphoreci.com|access-date=2016-10-28}}</ref> is valid:
<pre>
it "has a valid factory" do
factory = FactoryGirl.build(:topic_due_date)
expect(factory).to be_valid
end
</pre>
* Fail if the due date is invalid:
<pre>
it "should fail because of invalid due_date" do
expect { DeadlineHelper.create_topic_deadline(nil, 0, 0)}.to raise_exception(NoMethodError)
end
</pre>
* If new due_date object is created:
<pre>
it "new due_date object created" do
DeadlineHelper.create_topic_deadline(@topic_due_date, 0, 1)
expect(TopicDueDate.count).to be == 2
end
</pre>
* due_at should be same for 0 offset:
<pre>
it "due_at should be same for 0 offset" do
DeadlineHelper.create_topic_deadline(@topic_due_date, 0, 10)
new_due_date = TopicDueDate.find_by(parent_id: 10)
expect(new_due_date).to be_valid
expect(new_due_date.due_at.to_s).to be == @topic_due_date.due_at.to_s
end
</pre>
* due_at is calculated correctly if offset is positive:
<pre>
it "due_at calculated correctly for positive offset" do
DeadlineHelper.create_topic_deadline(@topic_due_date, 5000, 10)
new_due_date = TopicDueDate.find_by(parent_id: 10)
expect(new_due_date).to be_valid
expect(new_due_date.due_at.to_s).to be == (Time.zone.parse(@topic_due_date.due_at.to_s) + 5000).to_s
end
</pre>
* due_at is calculated correctly if offset is negative:
<pre>
it "due_at calculated correctly for negative offset" do
DeadlineHelper.create_topic_deadline(@topic_due_date, -5000, 10)
new_due_date = TopicDueDate.find_by(parent_id: 10)
expect(new_due_date).to be_valid
expect(new_due_date.due_at.to_s).to be == (Time.zone.parse(@topic_due_date.due_at.to_s) - 5000).to_s
end
</pre>
* The offset is being converted to integer properly:
<pre>
it "offset converted to integer correctly" do
DeadlineHelper.create_topic_deadline(@topic_due_date, 5000.15, 10)
new_due_date = TopicDueDate.find_by(parent_id: 10)
expect(new_due_date).to be_valid
expect(new_due_date.due_at.to_s).to be == (Time.zone.parse(@topic_due_date.due_at.to_s) + 5000).to_s
end
</pre>
To test this file run the following command:
<pre>
rspec spec/models/deadline_helper_spec.rb
</pre>
The output of this RSpec file is present in below screenshot:
[[File:Deadlinerspec.png]]

Code coverage details of the above RSpec files is present in below screenshot:
[[File:Deadlinecoverage.png]]

== '''References''' ==
"[http://www.expertiza.ncsu.edu]" 
"[Ruby on Rails]". [http://www.rubyonrails.org]. Retrieved 2016-10-28. 
"[Log in to your Code Climate dashboard with GitHub or your email].". [http://www.codeclimate.com]. Retrieved 2016-10-28. 
"[RSpec: Behaviour Driven Development for Ruby]". [http://www.rspec.info]. Retrieved 2016-10-28. 
"[Travis CI - Test and Deploy with Confidence]". [http://www.travis-ci.com link title]. Retrieved 2016-10-28 
"[Working Effectively with Data Factories Using FactoryGirl]". [http://www.semaphoreci.com]. Retrieved 2016-10-28

CSC/ECE 517 Fall 2016/E1634. Refactor and write unit test of due date.rb and deadline helper.rb

2016-10-29T01:30:21Z

Aagrawa6: /* References */

== '''Introduction''' ==

=== Expertiza ===
Expertiza<ref>{{Cite web|url=http://www.expertiza.ncsu.edu|access-date=2016-10-28}}</ref> is an open source project for school assignment management for instructors and students based on the Ruby on Rails<ref>{{Cite web|url=http://www.rubyonrails.org|access-date=2016-10-28}}</ref> framework. Expertiza allows the instructor to create new assignments and customise new or existing assignments. It also allows the instructor to create a list of topics the students can sign up for. Students can form teams in Expertiza to work on various projects and assignments. Students can also peer review other students' submissions. Expertiza supports submission across various document types, including the URLs and word documents. Expertiza provides a dashboard for all the assignments corresponding to a course and provides absolute control to the Instructors and Teaching Assistants. In addition to assignments, it encompasses peer reviews wherein participants are allowed to provide feedback anonymously about each other's work thereby providing scope for the better outcome. The due_date.rb file is responsible for informing the users about the deadline for submission of the each assignment. Due dates in Expertiza have their association with many other components like assignments, reviews etc.

=== Code Climate ===
Code Climate<ref>{{Cite web|url=https://codeclimate.com/dashboard|title=Log in to your Code Climate dashboard with GitHub or your email.|website=codeclimate.com|access-date=2016-10-28}}</ref> is a tool that runs static analysis on a GitHub project and outputs many details like test coverage, complexity, duplication, security, style, and more. There is a Google Chrome extension to integrate the Code Climate results generated directly into GitHub which is visible when browsing the repository on the browser. It allows us to see issues displayed directly inside GitHub's UI, to review which lines are covered in diffs and files, and add repositories and open tickets without changing your workflow.

== '''Tasks Identified''' ==
To install Code climate Chrome Extension that highlights the duplicated code.

To refactor the following two files:
* due_date.rb
** Ternary operators must not be nested. Prefer `if` or `else` constructs instead.
** Useless assignment to variable - `sorted_deadlines`.
** Prefer `each` over `for`.
** Use `find_by` instead of `where.first`.
** Correct the use of Time function
* deadline_helper.rb
** Do not use `Time.now` without zone. Use one of `Time.zone.now`, `Time.current`, `Time.now.in_time_zone`, `Time.now.utc`, `Time.now.getlocal`, `Time.now.iso8601`, `Time.now.jisx0301`, `Time.now.rfc3339`, `Time.now.to_i`, `Time.now.to_f` instead.
** Trailing whitespace detected.
** Extra empty line detected at module body end.

* Create respective RSpec<ref>{{Cite web|url=http://www.rspec.info|access-date=2016-10-28}}</ref>files in /spec/models/ and /spec/helper folder and write unit tests for each method in due_date.rb and deadline_helper.rb.

== '''Current Implementation''' ==
DueDate is a Model class to manage the deadlines of an assignment. It has methods for setting due dates for an assignment, copying due dates from one assignment to a new assignment etc. DeadlineHelper provides helper functions that help DueDate perform certain tasks. The assignment focuses on refactoring some of the methods based on warnings received from Code Climate's static analysis and modifying the language to make it more Ruby-friendly. The assignment also involves writing unit test cases for due_date.rb and deadline_helper.rb in order to increase test coverage.

The goal of this project is to attempt to make this part of the application easier to read and write unit test cases that the application must pass.

== '''Changed Implementation''' ==
Changes implemented involves refactoring the code and making it more understandable by adding comments in the code.

The modified files are
* due_date.rb (path: /app/models)
* deadline_helper.rb (path: /app/helpers)
Testing files
* due_date_spec.rb (path: /spec/models)
* deadline_helper_spec.rb (path: /spec/helpers)

=== due_date.rb ===
* Converted for..in loop to object.each in order to follow better Ruby syntax.
* Unnecessary assignment to sorted_deadlines removed.
* Nested ternary operators have been changed to if..else in order to make it more readable.
[[File:Duedaterb.png]]
* Changed where(...).first to find_by(...) which is the newer recommended syntax.
* Corrected the Time.now functions by adding the correct zones to them such as Time.zone.now.
* Removed trailing whitespaces.
[[File:DueDaterb2.png]]

=== deadline_helper.rb ===
* Time functions were changed to functions with zones
* Extra line removed
[[File:Deadlinehelper.png]]

== '''RSpec testing''' ==
There were no existing tests for the functions in due_date.rb and deadline_helper.rb. We have added exhaustive set of RSpec tests to test all the code. We have added two new spec files 'due_date_spec.rb' and ‘deadline_helper_spec.rb’ which cover the testing scenarios for the functions in ‘due_date.rb’ and ‘deadline_helper.rb’.

For both of these two files, all Travis CI<ref>{{Cite web|url=http://http://www.travis-ci.com|access-date=2016-10-28}}</ref> test cases have passed for all previous test cases as well as the ones added by us with the test coverage for the files due_date.rb and deadline_helper.rb reported as 100%.

These RSpec files have 100% code coverage visible at: /coverage/index.html.

=== due_date_spec.rb ===
This file is located at spec/models and tests the functionalities of the due_date.rb file located in app/models. There are 18 test cases in total which are listed below.
* If the factory is successfully able to build the due_date objects.
<pre>
it "due date factory created successfully" do
expect(@assignment_due_date).to be_valid
end
</pre>
<pre>
it "due dates created correctly" do
expect(@due_dates.length).to be == 10
end
</pre>
* If the function "set_flag" successfully sets the due_date flag.
<pre>
it "due date flag is set" do
expect(@assignment_due_date.flag).to be false
@assignment_due_date.set_flag
expect(@assignment_due_date.flag).to be true
end
</pre>
* If the function "due_at_is_valid_datetime" returns nil (no errors) for a valid datetime in due_at (no invalid test cases can be added here because model does not allow invalid datetime to be set at all).
<pre>
it "due at is valid datetime" do
expect(@assignment_due_date.due_at_is_valid_datetime).to be nil
end
</pre>
* If the function "self.copy" is able to copy due dates from one assignment to another.
<pre>
it "copy due dates to new assignment" do
new_assignment_id = build(:assignment, id: 999).id
old_assignment_id = @assignment_due_date.assignment.id
DueDate.copy(old_assignment_id, new_assignment_id)
expect(DueDate.where(parent_id: new_assignment_id).count).to eql DueDate.where(parent_id: old_assignment_id).count
end
</pre>
* If the function "self.set_duedate" is able to create another due date by copying data from an existing due date object.
<pre>
it "create new duedate record with values" do
DueDate.set_duedate({id: 999}, @assignment_due_date.deadline_type_id,
@assignment_due_date.parent_id, @assignment_due_date.round)
new_due_date = DueDate.find_by(id: 999)
expect(new_due_date).to be_valid
expect(new_due_date.deadline_type_id).to eql @assignment_due_date.deadline_type_id
expect(new_due_date.parent_id).to eql @assignment_due_date.parent_id
expect(new_due_date.round).to eql @assignment_due_date.round
end
</pre>
* If the function "self.deadline_sort" is able to sort the due dates in ascending order.
<pre>
it "sort duedate records" do
sorted_due_dates = @due_dates
expect(sorted_due_dates.each_cons(2).all?{|m1, m2| (m1.due_at <=> m2.due_at) != 1}).to eql false

sorted_due_dates = DueDate.deadline_sort(@due_dates)
expect(sorted_due_dates.each_cons(2).all?{|m1, m2| (m1.due_at <=> m2.due_at) != 1}).to eql true
end
</pre>
* If the function "self.done_in_assignment_round" returns the correct number of rounds for specific inputs. This involves an invalid test case as well for 0 rounds.
<pre>
describe "#done_in_assignment_round" do
it "return 0 when no response map" do
response = ReviewResponseMap.create
response.type = "ResponseMap"
response.save
expect(DueDate.done_in_assignment_round(1, response)).to eql 0
end

it "return round 1 for single round" do
response = ReviewResponseMap.create
expect(DueDate.done_in_assignment_round(@assignment_due_date.parent_id, response)).to eql 1
end
end
</pre>
* If the function "self.get_next_due_date" works as expected. This involves several invalid test cases as well.
<pre>
describe "#get_next_due_date" do
it "no subsequent due date" do
expect(DueDate.get_next_due_date(@assignment_due_date.parent_id)).to be nil
end

it "nil value throws exception" do
expect { DueDate.get_next_due_date(nil) }.to raise_exception(ActiveRecord::RecordNotFound)
end

it "get next assignment due date" do
due_date = create(:assignment_due_date, deadline_type: @deadline_type,
submission_allowed_id: @deadline_right.id, review_allowed_id: @deadline_right.id,
review_of_review_allowed_id: @deadline_right.id, due_at: Time.zone.now + 5000)
expect(DueDate.get_next_due_date(due_date.parent_id)).to be_valid
end

it "get next due date from topic for staggered deadline" do
assignment_id = create(:assignment, staggered_deadline: true, name: "testassignment").id
due_date = create(:topic_due_date, deadline_type: @deadline_type,
submission_allowed_id: @deadline_right.id, review_allowed_id: @deadline_right.id,
review_of_review_allowed_id: @deadline_right.id, due_at: Time.zone.now + 5000, parent_id: assignment_id)
expect(DueDate.get_next_due_date(assignment_id, due_date.parent_id)).to be_valid
end

it "next due date does not exist for staggered deadline" do
assignment_id = create(:assignment, staggered_deadline: true, name: "testassignment").id
due_date = create(:topic_due_date, deadline_type: @deadline_type,
submission_allowed_id: @deadline_right, review_allowed_id: @deadline_right,
review_of_review_allowed_id: @deadline_right, due_at: Time.zone.now + 5000, parent_id: assignment_id)
expect(DueDate.get_next_due_date(assignment_id)).to be nil
end

it "next due date is before Time.now for staggered deadline" do
assignment_id = create(:assignment, staggered_deadline: true, name: "testassignment").id
due_date = create(:topic_due_date, deadline_type: @deadline_type,
submission_allowed_id: @deadline_right, review_allowed_id: @deadline_right,
review_of_review_allowed_id: @deadline_right, due_at: Time.zone.now - 5000, parent_id: assignment_id)
expect(DueDate.get_next_due_date(assignment_id, due_date.parent_id)).to be nil
end

it "get next due date from assignment for staggered deadline" do
assignment_id = create(:assignment, staggered_deadline: true, name: "testassignment").id
due_date = create(:assignment_due_date, deadline_type: @deadline_type,
submission_allowed_id: @deadline_right, review_allowed_id: @deadline_right,
review_of_review_allowed_id: @deadline_right, due_at: Time.zone.now + 5000, parent_id: assignment_id)
expect(DueDate.get_next_due_date(assignment_id)).to be_valid
end
end
</pre>
* If the function "self.default_permission" returns the correct default permissions for particular deadline and permission types.
<pre>
it "metareview review_of_review_allowed default permission OK" do
expect(DueDate.default_permission('metareview', 'review_of_review_allowed')).to be == DeadlineRight::OK
end
</pre>
<pre>
it "review submission_allowed default permission NO" do
expect(DueDate.default_permission('review', 'submission_allowed')).to be == DeadlineRight::NO
end
</pre>
To test this file run the following command:
<pre>
rspec spec/models/due_date_spec.rb
</pre>
The output of this RSpec file is present in below screenshot:
[[File:Duedaterspec.png]]

Code coverage details of the above RSpec files is present in below screenshot:
[[File:Duedatecoverage.png]]

=== deadline_helper_spec.rb ===
This is a test file for testing the functionalities of Deadline_helper.rb file located at app/helpers. Different test cases present in this file are:
* Check if the factory<ref>{{Cite web|url=http://http://www.semaphoreci.com|access-date=2016-10-28}}</ref> is valid:
<pre>
it "has a valid factory" do
factory = FactoryGirl.build(:topic_due_date)
expect(factory).to be_valid
end
</pre>
* Fail if the due date is invalid:
<pre>
it "should fail because of invalid due_date" do
expect { DeadlineHelper.create_topic_deadline(nil, 0, 0)}.to raise_exception(NoMethodError)
end
</pre>
* If new due_date object is created:
<pre>
it "new due_date object created" do
DeadlineHelper.create_topic_deadline(@topic_due_date, 0, 1)
expect(TopicDueDate.count).to be == 2
end
</pre>
* due_at should be same for 0 offset:
<pre>
it "due_at should be same for 0 offset" do
DeadlineHelper.create_topic_deadline(@topic_due_date, 0, 10)
new_due_date = TopicDueDate.find_by(parent_id: 10)
expect(new_due_date).to be_valid
expect(new_due_date.due_at.to_s).to be == @topic_due_date.due_at.to_s
end
</pre>
* due_at is calculated correctly if offset is positive:
<pre>
it "due_at calculated correctly for positive offset" do
DeadlineHelper.create_topic_deadline(@topic_due_date, 5000, 10)
new_due_date = TopicDueDate.find_by(parent_id: 10)
expect(new_due_date).to be_valid
expect(new_due_date.due_at.to_s).to be == (Time.zone.parse(@topic_due_date.due_at.to_s) + 5000).to_s
end
</pre>
* due_at is calculated correctly if offset is negative:
<pre>
it "due_at calculated correctly for negative offset" do
DeadlineHelper.create_topic_deadline(@topic_due_date, -5000, 10)
new_due_date = TopicDueDate.find_by(parent_id: 10)
expect(new_due_date).to be_valid
expect(new_due_date.due_at.to_s).to be == (Time.zone.parse(@topic_due_date.due_at.to_s) - 5000).to_s
end
</pre>
* The offset is being converted to integer properly:
<pre>
it "offset converted to integer correctly" do
DeadlineHelper.create_topic_deadline(@topic_due_date, 5000.15, 10)
new_due_date = TopicDueDate.find_by(parent_id: 10)
expect(new_due_date).to be_valid
expect(new_due_date.due_at.to_s).to be == (Time.zone.parse(@topic_due_date.due_at.to_s) + 5000).to_s
end
</pre>
To test this file run the following command:
<pre>
rspec spec/models/deadline_helper_spec.rb
</pre>
The output of this RSpec file is present in below screenshot:
[[File:Deadlinerspec.png]]

Code coverage details of the above RSpec files is present in below screenshot:
[[File:Deadlinecoverage.png]]

== '''References''' ==
"[http://www.expertiza.ncsu.edu]" 
"[Ruby on Rails]". [http://www.rubyonrails.org]. Retrieved 2016-10-28. 
"[Log in to your Code Climate dashboard with GitHub or your email].". [http://www.codeclimate.com]. Retrieved 2016-10-28. 
"[RSpec: Behaviour Driven Development for Ruby]". [http://www.rspec.info]. Retrieved 2016-10-28. 
"[Travis CI - Test and Deploy with Confidence]". [http://www.travis-ci.com link title]. Retrieved 2016-10-28 
"[Working Effectively with Data Factories Using FactoryGirl]". [http://www.semaphoreci.com]. Retrieved 2016-10-28