Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2018 E1871 Grade Summary By Student

2018-12-07T04:08:35Z

Jfgiall2: Explain how to get data from objects.

==E1871. Grade Summary By Student==

__TOC__

==Introduction==
===Team===
Edward Gehringer(efg) (mentor)
* Dan Goslen (dwgoslen)
* Ishan Rohatgi (irohatg)
* Joe Giallo (jfgiall2)

===Task===
For this project, our task was to create a view which consolidates information related to each assignment for each student in a course in a single page. The objective was to ease the way in which final grades could be viewed, and to provide holistic insight into the performance of each student in a class.

===Repo===
Our fork and branch can be found here.
[https://github.com/ishanrohatgi0994/expertiza/tree/E1871 E1871 Branch]

===Pull Request===
Our pull request can be found here.
[https://github.com/expertiza/expertiza/pull/1298 E1871 Pull Request]

==Background==
This feature was requested by Dr. Gehringer in order to ease the process of collecting student grades for a course for reporting at the end of the semester. This process took nearly an entire day last semester, and the time savings given by a consolidated view containing all this information could be immense. Dr. Gehringer mentioned believing that this information had been previously available under the 360 Assessment tab in the Manage Courses menu, but that functionality had since been broken by an update. The current view indicates that one_course_all_assignments should be available from the 360 Assessment menu, and this appears to have provided similar but less complete information to what Dr. Gehringer has requested in this project.

Looking through the commit history, we determined that 360 Assessment had been removed intentionally in commit [https://github.com/ishanrohatgi0994/expertiza/commit/2c2160793b963d6efebd69bdcbb289edbd15f3f2#diff-0939dc014f523e60f6048caac18e470c 2c21607] for unknown reasons, then added back when Zhewei needed to count the total reviews done by each student in a semester in commit [https://github.com/ishanrohatgi0994/expertiza/commit/67d6ab405ddcba057421d4fa616872e48e83278b#diff-a3ce03cf4ce63e40acb2ae81c102dc2a 67d6ab4]. It was then removed again when [https://github.com/ishanrohatgi0994/expertiza/commit/1ebb5c29e2bd958505b1b57383657c328a2dd599#diff-0939dc014f523e60f6048caac18e470c 1ebb5c2] the committer determined that the functionality the page was providing could be gained by accessing View Aggregated Teammate and Meta-Reviews from the Manage Courses page.

==Use Case UML Activity Diagram==
This is the procedure for accessing the Grade Summary by Student view. It's not too complicated, but our reviewers really wanted some sweet UML action.

[[File:Expertiza_grade_summary_by_student_uml.png]]

==Design==
===Modified Files===
*# app/assets/javascripts/tree_display.jsx
*# app/controllers/assessment360_controller.rb
*# config/routes.rb
*# app/assets/stylesheets/table_sorter.scss
*# app/controllers/grades_controller.rb
*# app/models/sign_up_topic.rb
*# app/helpers/grades_helper.rb

===Created Files===
*# app/views/assessment360/course_student_grade_summary.html.erb
*# spec/controllers/assessment360_controller_spec.rb
*# spec/features/course_student_grade_summary_spec.rb

=== How We Get The Information We Need==
Getting the data we need to populate this view is a little more complicated than expected. Here is an explanation of what we need and why:
*# We start by getting a course with a course_id.
*# Once we have a course, it is straightforward to gets the assignments and course_participants.
*# For each course participant and for each assignment, we then conduct the rest of the procedure.
*# We get the user id from the course participant.
*# We use the user id to get an assignment_participant object from the assignment.
*# We use the assignment and user ids to get a topic id from the SignedUpTeam model.
*# Once we have the topic id we can add the name to the list for the UI.
*# Use the assignment id and user id to get a team id from the TeamsUser class.
*# Use the team id to get a team object.
*# Get a grade_for_submission from the team object.
*# Get questionnaires from the assignment.
*# For each questionnaire in an assignment, use AssignmentQuestionnare model to get rounds.
*# For each round, get questions.
*# Once you have all questions, call score on participants while passing questions as argument.

===The View===
The view for Grade Summary by Student must contain the following information, according to the requirements document and consultation with Dr. Gehringer.
*# Each student's name and id in a course.
*# Each assignment given to each student.
*# The topic name for each assignment.
*# The topic id for each assignment.
*# The grade for each assignment.
*# The peer review score for each assignment.
*# The total score of each student over all of their assignments.

From the Manage Courses page in Expertiza, we intend to place our view behind the 360 Assessment icon for each course. Being able to view every student's complete grades for each assignment constitutes a 360 degree view of every student's performance in a course, and no functionality exists behind the icon currently, so this seems to be a logical choice for placement.

[[File:Expertiza_manage_course_page_360_icon.png]]

The following image shows our initial LoFi sketch of the desired page. It shows our intention to list each student in a row, and to have each column be their assignments. We wanted to contain all the information about their assignment within the column, but did not decided on columns-within-columns until reviewing with Dr. Gehringer.

[[File:Expertiza_grade_summary_by_student_lofi_sketch.png]]

We took Dr. Gehringer's feedback and have created the following rough prototype for the view. The data is absent, but this uses Expertiza's color scheme and style conventions. In this case, Topic Name and Topic Id are space-holders for real values, and Aggregate Score will not have sub-fields in the final draft. We are contemplating putting dividers between the columns, so it is easier to parse where each assignment begins and ends. We are also working on a way for the columns to be sorted by student and by grades.

[[File:Expertiza_grade_summary_by_student_rough_draft_view.png]]

===The Controller===

All of the information required in this view is present in the system: the controller for this view will simply need to make the appropriate queries to the models and database. We intend to create a hash of students given the particular course id, and then use the course id and the student id to retrieve the specific information about the assignments.

All changes were made in the file assessment370controller.rb

==Test Plan==
Because the primary attraction of this feature is a view, the typical unit testing is not as practical as it would be if we were making changes to underlying models. Similarly, there aren't any interactive elements in the view we're testing. As a result, we plan to test the controller and the feature in general as best we can. Here are videos of each set of tests running successfully.

[https://youtu.be/PqpenMq_F2U Assessment360 Controller Tests Video]

[https://youtu.be/3e42Zi1C3_0 Grade Summary by Student Feature Tests Video]

===Controller Tests===
The controller we test is the assessment360_controller.rb, particularly the course_student_grade_summary function. Controller tests are tricky to write, as they can't be sensitive to the model's implementation or how the information will be displayed. As such, we intend to test that each of the instance variables provided to the view is instantiated, but not concern ourselves too much with what the values are (these would be tested by the unit tests for the manu models we query in this method.) This is identified as a best practice for controller tests in [https://guides.rubyonrails.org/testing.html#functional-tests-for-your-controllers Ruby-On-Rails Guide - Functional Tests for Your Controllers].

Here is an image of part of our Controller tests, showing how we handle the case where a course doesn't have any students.

[[File:Expertiza_grade_summary_by_student_assessment360_controller_tests1.png]]

Here is an image of all of the objects which must be mocked in order to properly test the controller function.

[[File:Expertiza_grade_summary_by_student_assessment360_controller_tests2.png]]

Here is an image of some of the tests which verify that the controller instantiates the view's instance variables.

[[File:Expertiza_grade_summary_by_student_assessment360_controller_tests3.png]]

===Feature Tests===
To verify that our view is correct, we'll implement some simple feature tests. Given some dummy students with dummy assignments with dummy fields, we expect that our view's page should display certain information. We'll check that upon navigation to our view, each element of data is present using the Rspec expectation 'to have_content'. In this way, we will verify that our view is performing its job.

Here is an image of all of the objects which must be mocked in order to properly test the feature.

[[File:Expertiza_grade_summary_by_student_feature_test1.png]]

Here is an image of some of the content-check tests for this feature.

[[File:Expertiza_grade_summary_by_student_feature_test2.png]]

CSC/ECE 517 Fall 2018 E1871 Grade Summary By Student

2018-12-07T02:36:49Z

Jfgiall2: update modified files

==E1871. Grade Summary By Student==

__TOC__

==Introduction==
===Team===
Edward Gehringer(efg) (mentor)
* Dan Goslen (dwgoslen)
* Ishan Rohatgi (irohatg)
* Joe Giallo (jfgiall2)

===Task===
For this project, our task was to create a view which consolidates information related to each assignment for each student in a course in a single page. The objective was to ease the way in which final grades could be viewed, and to provide holistic insight into the performance of each student in a class.

===Repo===
Our fork and branch can be found here.
[https://github.com/ishanrohatgi0994/expertiza/tree/E1871 E1871 Branch]

===Pull Request===
Our pull request can be found here.
[https://github.com/expertiza/expertiza/pull/1298 E1871 Pull Request]

==Background==
This feature was requested by Dr. Gehringer in order to ease the process of collecting student grades for a course for reporting at the end of the semester. This process took nearly an entire day last semester, and the time savings given by a consolidated view containing all this information could be immense. Dr. Gehringer mentioned believing that this information had been previously available under the 360 Assessment tab in the Manage Courses menu, but that functionality had since been broken by an update. The current view indicates that one_course_all_assignments should be available from the 360 Assessment menu, and this appears to have provided similar but less complete information to what Dr. Gehringer has requested in this project.

Looking through the commit history, we determined that 360 Assessment had been removed intentionally in commit [https://github.com/ishanrohatgi0994/expertiza/commit/2c2160793b963d6efebd69bdcbb289edbd15f3f2#diff-0939dc014f523e60f6048caac18e470c 2c21607] for unknown reasons, then added back when Zhewei needed to count the total reviews done by each student in a semester in commit [https://github.com/ishanrohatgi0994/expertiza/commit/67d6ab405ddcba057421d4fa616872e48e83278b#diff-a3ce03cf4ce63e40acb2ae81c102dc2a 67d6ab4]. It was then removed again when [https://github.com/ishanrohatgi0994/expertiza/commit/1ebb5c29e2bd958505b1b57383657c328a2dd599#diff-0939dc014f523e60f6048caac18e470c 1ebb5c2] the committer determined that the functionality the page was providing could be gained by accessing View Aggregated Teammate and Meta-Reviews from the Manage Courses page.

==Use Case UML Activity Diagram==
This is the procedure for accessing the Grade Summary by Student view. It's not too complicated, but our reviewers really wanted some sweet UML action.

[[File:Expertiza_grade_summary_by_student_uml.png]]

==Design==
===Modified Files===
*# app/assets/javascripts/tree_display.jsx
*# app/controllers/assessment360_controller.rb
*# config/routes.rb
*# app/assets/stylesheets/table_sorter.scss
*# app/controllers/grades_controller.rb
*# app/models/sign_up_topic.rb
*# app/helpers/grades_helper.rb

===Created Files===
*# app/views/assessment360/course_student_grade_summary.html.erb
*# spec/controllers/assessment360_controller_spec.rb
*# spec/features/course_student_grade_summary_spec.rb

===The View===
The view for Grade Summary by Student must contain the following information, according to the requirements document and consultation with Dr. Gehringer.
*# Each student's name and id in a course.
*# Each assignment given to each student.
*# The topic name for each assignment.
*# The topic id for each assignment.
*# The grade for each assignment.
*# The peer review score for each assignment.
*# The total score of each student over all of their assignments.

From the Manage Courses page in Expertiza, we intend to place our view behind the 360 Assessment icon for each course. Being able to view every student's complete grades for each assignment constitutes a 360 degree view of every student's performance in a course, and no functionality exists behind the icon currently, so this seems to be a logical choice for placement.

[[File:Expertiza_manage_course_page_360_icon.png]]

The following image shows our initial LoFi sketch of the desired page. It shows our intention to list each student in a row, and to have each column be their assignments. We wanted to contain all the information about their assignment within the column, but did not decided on columns-within-columns until reviewing with Dr. Gehringer.

[[File:Expertiza_grade_summary_by_student_lofi_sketch.png]]

We took Dr. Gehringer's feedback and have created the following rough prototype for the view. The data is absent, but this uses Expertiza's color scheme and style conventions. In this case, Topic Name and Topic Id are space-holders for real values, and Aggregate Score will not have sub-fields in the final draft. We are contemplating putting dividers between the columns, so it is easier to parse where each assignment begins and ends. We are also working on a way for the columns to be sorted by student and by grades.

[[File:Expertiza_grade_summary_by_student_rough_draft_view.png]]

===The Controller===

All of the information required in this view is present in the system: the controller for this view will simply need to make the appropriate queries to the models and database. We intend to create a hash of students given the particular course id, and then use the course id and the student id to retrieve the specific information about the assignments.

All changes were made in the file assessment370controller.rb

==Test Plan==
Because the primary attraction of this feature is a view, the typical unit testing is not as practical as it would be if we were making changes to underlying models. Similarly, there aren't any interactive elements in the view we're testing. As a result, we plan to test the controller and the feature in general as best we can. Here are videos of each set of tests running successfully.

[https://youtu.be/PqpenMq_F2U Assessment360 Controller Tests Video]

[https://youtu.be/3e42Zi1C3_0 Grade Summary by Student Feature Tests Video]

===Controller Tests===
The controller we test is the assessment360_controller.rb, particularly the course_student_grade_summary function. Controller tests are tricky to write, as they can't be sensitive to the model's implementation or how the information will be displayed. As such, we intend to test that each of the instance variables provided to the view is instantiated, but not concern ourselves too much with what the values are (these would be tested by the unit tests for the manu models we query in this method.) This is identified as a best practice for controller tests in [https://guides.rubyonrails.org/testing.html#functional-tests-for-your-controllers Ruby-On-Rails Guide - Functional Tests for Your Controllers].

Here is an image of part of our Controller tests, showing how we handle the case where a course doesn't have any students.

[[File:Expertiza_grade_summary_by_student_assessment360_controller_tests1.png]]

Here is an image of all of the objects which must be mocked in order to properly test the controller function.

[[File:Expertiza_grade_summary_by_student_assessment360_controller_tests2.png]]

Here is an image of some of the tests which verify that the controller instantiates the view's instance variables.

[[File:Expertiza_grade_summary_by_student_assessment360_controller_tests3.png]]

===Feature Tests===
To verify that our view is correct, we'll implement some simple feature tests. Given some dummy students with dummy assignments with dummy fields, we expect that our view's page should display certain information. We'll check that upon navigation to our view, each element of data is present using the Rspec expectation 'to have_content'. In this way, we will verify that our view is performing its job.

Here is an image of all of the objects which must be mocked in order to properly test the feature.

[[File:Expertiza_grade_summary_by_student_feature_test1.png]]

Here is an image of some of the content-check tests for this feature.

[[File:Expertiza_grade_summary_by_student_feature_test2.png]]

CSC/ECE 517 Fall 2018 E1871 Grade Summary By Student

2018-11-26T23:06:00Z

Jfgiall2: Added pull request.

==E1871. Grade Summary By Student==

__TOC__

==Introduction==
===Team===
Edward Gehringer(efg) (mentor)
* Dan Goslen (dwgoslen)
* Ishan Rohatgi (irohatg)
* Joe Giallo (jfgiall2)

===Task===
For this project, our task was to create a view which consolidates information related to each assignment for each student in a course in a single page. The objective was to ease the way in which final grades could be viewed, and to provide holistic insight into the performance of each student in a class.

===Repo===
Our fork and branch can be found here.
[https://github.com/ishanrohatgi0994/expertiza/tree/E1871 E1871 Branch]

===Pull Request===
Our pull request can be found here.
[https://github.com/expertiza/expertiza/pull/1298 E1871 Pull Request]

==Background==
This feature was requested by Dr. Gehringer in order to ease the process of collecting student grades for a course for reporting at the end of the semester. This process took nearly an entire day last semester, and the time savings given by a consolidated view containing all this information could be immense. Dr. Gehringer mentioned believing that this information had been previously available under the 360 Assessment tab in the Manage Courses menu, but that functionality had since been broken by an update. The current view indicates that one_course_all_assignments should be available from the 360 Assessment menu, and this appears to have provided similar but less complete information to what Dr. Gehringer has requested in this project.

Looking through the commit history, we determined that 360 Assessment had been removed intentionally in commit [https://github.com/ishanrohatgi0994/expertiza/commit/2c2160793b963d6efebd69bdcbb289edbd15f3f2#diff-0939dc014f523e60f6048caac18e470c 2c21607] for unknown reasons, then added back when Zhewei needed to count the total reviews done by each student in a semester in commit [https://github.com/ishanrohatgi0994/expertiza/commit/67d6ab405ddcba057421d4fa616872e48e83278b#diff-a3ce03cf4ce63e40acb2ae81c102dc2a 67d6ab4]. It was then removed again when [https://github.com/ishanrohatgi0994/expertiza/commit/1ebb5c29e2bd958505b1b57383657c328a2dd599#diff-0939dc014f523e60f6048caac18e470c 1ebb5c2] the committer determined that the functionality the page was providing could be gained by accessing View Aggregated Teammate and Meta-Reviews from the Manage Courses page.

==Use Case UML Activity Diagram==
This is the procedure for accessing the Grade Summary by Student view. It's not too complicated, but our reviewers really wanted some sweet UML action.

[[File:Expertiza_grade_summary_by_student_uml.png]]

==Design==
===Modified Files===
*# app/assets/javascripts/tree_display.jsx
*# app/controllers/assessment360_controller.rb
*# config/routes.rb
*# app/assets/stylesheets/table_sorter.scss

===Created Files===
*# app/views/assessment360/course_student_grade_summary.html.erb
*# spec/controllers/assessment360_controller_spec.rb
*# spec/features/course_student_grade_summary_spec.rb

===The View===
The view for Grade Summary by Student must contain the following information, according to the requirements document and consultation with Dr. Gehringer.
*# Each student's name and id in a course.
*# Each assignment given to each student.
*# The topic name for each assignment.
*# The topic id for each assignment.
*# The grade for each assignment.
*# The peer review score for each assignment.
*# The total score of each student over all of their assignments.

From the Manage Courses page in Expertiza, we intend to place our view behind the 360 Assessment icon for each course. Being able to view every student's complete grades for each assignment constitutes a 360 degree view of every student's performance in a course, and no functionality exists behind the icon currently, so this seems to be a logical choice for placement.

[[File:Expertiza_manage_course_page_360_icon.png]]

The following image shows our initial LoFi sketch of the desired page. It shows our intention to list each student in a row, and to have each column be their assignments. We wanted to contain all the information about their assignment within the column, but did not decided on columns-within-columns until reviewing with Dr. Gehringer.

[[File:Expertiza_grade_summary_by_student_lofi_sketch.png]]

We took Dr. Gehringer's feedback and have created the following rough prototype for the view. The data is absent, but this uses Expertiza's color scheme and style conventions. In this case, Topic Name and Topic Id are space-holders for real values, and Aggregate Score will not have sub-fields in the final draft. We are contemplating putting dividers between the columns, so it is easier to parse where each assignment begins and ends. We are also working on a way for the columns to be sorted by student and by grades.

[[File:Expertiza_grade_summary_by_student_rough_draft_view.png]]

===The Controller===

All of the information required in this view is present in the system: the controller for this view will simply need to make the appropriate queries to the models and database. We intend to create a hash of students given the particular course id, and then use the course id and the student id to retrieve the specific information about the assignments.

All changes were made in the file assessment370controller.rb

==Test Plan==
Because the primary attraction of this feature is a view, the typical unit testing is not as practical as it would be if we were making changes to underlying models. Similarly, there aren't any interactive elements in the view we're testing. As a result, we plan to test the controller and the feature in general as best we can. Here are videos of each set of tests running successfully.

[https://youtu.be/PqpenMq_F2U Assessment360 Controller Tests Video]

[https://youtu.be/3e42Zi1C3_0 Grade Summary by Student Feature Tests Video]

===Controller Tests===
The controller we test is the assessment360_controller.rb, particularly the course_student_grade_summary function. Controller tests are tricky to write, as they can't be sensitive to the model's implementation or how the information will be displayed. As such, we intend to test that each of the instance variables provided to the view is instantiated, but not concern ourselves too much with what the values are (these would be tested by the unit tests for the manu models we query in this method.) This is identified as a best practice for controller tests in [https://guides.rubyonrails.org/testing.html#functional-tests-for-your-controllers Ruby-On-Rails Guide - Functional Tests for Your Controllers].

Here is an image of part of our Controller tests, showing how we handle the case where a course doesn't have any students.

[[File:Expertiza_grade_summary_by_student_assessment360_controller_tests1.png]]

Here is an image of all of the objects which must be mocked in order to properly test the controller function.

[[File:Expertiza_grade_summary_by_student_assessment360_controller_tests2.png]]

Here is an image of some of the tests which verify that the controller instantiates the view's instance variables.

[[File:Expertiza_grade_summary_by_student_assessment360_controller_tests3.png]]

===Feature Tests===
To verify that our view is correct, we'll implement some simple feature tests. Given some dummy students with dummy assignments with dummy fields, we expect that our view's page should display certain information. We'll check that upon navigation to our view, each element of data is present using the Rspec expectation 'to have_content'. In this way, we will verify that our view is performing its job.

Here is an image of all of the objects which must be mocked in order to properly test the feature.

[[File:Expertiza_grade_summary_by_student_feature_test1.png]]

Here is an image of some of the content-check tests for this feature.

[[File:Expertiza_grade_summary_by_student_feature_test2.png]]

CSC/ECE 517 Fall 2018 E1871 Grade Summary By Student

2018-11-24T20:26:54Z

Jfgiall2: Added link to repo.

==E1871. Grade Summary By Student==

__TOC__

==Introduction==
===Team===
Edward Gehringer(efg) (mentor)
* Dan Goslen (dwgoslen)
* Ishan Rohatgi (irohatg)
* Joe Giallo (jfgiall2)

===Task===
For this project, our task was to create a view which consolidates information related to each assignment for each student in a course in a single page. The objective was to ease the way in which final grades could be viewed, and to provide holistic insight into the performance of each student in a class.

===Repo===
Our fork and branch can be found here.
[https://github.com/ishanrohatgi0994/expertiza/tree/E1871 E1871 Branch]

==Background==
This feature was requested by Dr. Gehringer in order to ease the process of collecting student grades for a course for reporting at the end of the semester. This process took nearly an entire day last semester, and the time savings given by a consolidated view containing all this information could be immense. Dr. Gehringer mentioned believing that this information had been previously available under the 360 Assessment tab in the Manage Courses menu, but that functionality had since been broken by an update. The current view indicates that one_course_all_assignments should be available from the 360 Assessment menu, and this appears to have provided similar but less complete information to what Dr. Gehringer has requested in this project.

Looking through the commit history, we determined that 360 Assessment had been removed intentionally in commit [https://github.com/ishanrohatgi0994/expertiza/commit/2c2160793b963d6efebd69bdcbb289edbd15f3f2#diff-0939dc014f523e60f6048caac18e470c 2c21607] for unknown reasons, then added back when Zhewei needed to count the total reviews done by each student in a semester in commit [https://github.com/ishanrohatgi0994/expertiza/commit/67d6ab405ddcba057421d4fa616872e48e83278b#diff-a3ce03cf4ce63e40acb2ae81c102dc2a 67d6ab4]. It was then removed again when [https://github.com/ishanrohatgi0994/expertiza/commit/1ebb5c29e2bd958505b1b57383657c328a2dd599#diff-0939dc014f523e60f6048caac18e470c 1ebb5c2] the committer determined that the functionality the page was providing could be gained by accessing View Aggregated Teammate and Meta-Reviews from the Manage Courses page.

==Use Case UML Activity Diagram==
This is the procedure for accessing the Grade Summary by Student view. It's not too complicated, but our reviewers really wanted some sweet UML action.

[[File:Expertiza_grade_summary_by_student_uml.png]]

==Design==
===Modified Files===
*# app/assets/javascripts/tree_display.jsx
*# app/controllers/assessment360_controller.rb
*# config/routes.rb
*# app/assets/stylesheets/table_sorter.scss

===Created Files===
*# app/views/assessment360/course_student_grade_summary.html.erb
*# spec/controllers/assessment360_controller_spec.rb
*# spec/features/course_student_grade_summary_spec.rb

===The View===
The view for Grade Summary by Student must contain the following information, according to the requirements document and consultation with Dr. Gehringer.
*# Each student's name and id in a course.
*# Each assignment given to each student.
*# The topic name for each assignment.
*# The topic id for each assignment.
*# The grade for each assignment.
*# The peer review score for each assignment.
*# The total score of each student over all of their assignments.

From the Manage Courses page in Expertiza, we intend to place our view behind the 360 Assessment icon for each course. Being able to view every student's complete grades for each assignment constitutes a 360 degree view of every student's performance in a course, and no functionality exists behind the icon currently, so this seems to be a logical choice for placement.

[[File:Expertiza_manage_course_page_360_icon.png]]

The following image shows our initial LoFi sketch of the desired page. It shows our intention to list each student in a row, and to have each column be their assignments. We wanted to contain all the information about their assignment within the column, but did not decided on columns-within-columns until reviewing with Dr. Gehringer.

[[File:Expertiza_grade_summary_by_student_lofi_sketch.png]]

We took Dr. Gehringer's feedback and have created the following rough prototype for the view. The data is absent, but this uses Expertiza's color scheme and style conventions. In this case, Topic Name and Topic Id are space-holders for real values, and Aggregate Score will not have sub-fields in the final draft. We are contemplating putting dividers between the columns, so it is easier to parse where each assignment begins and ends. We are also working on a way for the columns to be sorted by student and by grades.

[[File:Expertiza_grade_summary_by_student_rough_draft_view.png]]

===The Controller===

All of the information required in this view is present in the system: the controller for this view will simply need to make the appropriate queries to the models and database. We intend to create a hash of students given the particular course id, and then use the course id and the student id to retrieve the specific information about the assignments.

All changes were made in the file assessment370controller.rb

==Test Plan==
Because the primary attraction of this feature is a view, the typical unit testing is not as practical as it would be if we were making changes to underlying models. Similarly, there aren't any interactive elements in the view we're testing. As a result, we plan to test the controller and the feature in general as best we can. Here are videos of each set of tests running successfully.

[https://youtu.be/PqpenMq_F2U Assessment360 Controller Tests Video]

[https://youtu.be/3e42Zi1C3_0 Grade Summary by Student Feature Tests Video]

===Controller Tests===
The controller we test is the assessment360_controller.rb, particularly the course_student_grade_summary function. Controller tests are tricky to write, as they can't be sensitive to the model's implementation or how the information will be displayed. As such, we intend to test that each of the instance variables provided to the view is instantiated, but not concern ourselves too much with what the values are (these would be tested by the unit tests for the manu models we query in this method.) This is identified as a best practice for controller tests in [https://guides.rubyonrails.org/testing.html#functional-tests-for-your-controllers Ruby-On-Rails Guide - Functional Tests for Your Controllers].

Here is an image of part of our Controller tests, showing how we handle the case where a course doesn't have any students.

[[File:Expertiza_grade_summary_by_student_assessment360_controller_tests1.png]]

Here is an image of all of the objects which must be mocked in order to properly test the controller function.

[[File:Expertiza_grade_summary_by_student_assessment360_controller_tests2.png]]

Here is an image of some of the tests which verify that the controller instantiates the view's instance variables.

[[File:Expertiza_grade_summary_by_student_assessment360_controller_tests3.png]]

===Feature Tests===
To verify that our view is correct, we'll implement some simple feature tests. Given some dummy students with dummy assignments with dummy fields, we expect that our view's page should display certain information. We'll check that upon navigation to our view, each element of data is present using the Rspec expectation 'to have_content'. In this way, we will verify that our view is performing its job.

Here is an image of all of the objects which must be mocked in order to properly test the feature.

[[File:Expertiza_grade_summary_by_student_feature_test1.png]]

Here is an image of some of the content-check tests for this feature.

[[File:Expertiza_grade_summary_by_student_feature_test2.png]]

CSC/ECE 517 Fall 2018 E1871 Grade Summary By Student

2018-11-24T20:22:39Z

Jfgiall2: Added list of modified and created files.

==E1871. Grade Summary By Student==

__TOC__

==Introduction==
===Team===
Edward Gehringer(efg) (mentor)
* Dan Goslen (dwgoslen)
* Ishan Rohatgi (irohatg)
* Joe Giallo (jfgiall2)

===Task===
For this project, our task was to create a view which consolidates information related to each assignment for each student in a course in a single page. The objective was to ease the way in which final grades could be viewed, and to provide holistic insight into the performance of each student in a class.

==Background==
This feature was requested by Dr. Gehringer in order to ease the process of collecting student grades for a course for reporting at the end of the semester. This process took nearly an entire day last semester, and the time savings given by a consolidated view containing all this information could be immense. Dr. Gehringer mentioned believing that this information had been previously available under the 360 Assessment tab in the Manage Courses menu, but that functionality had since been broken by an update. The current view indicates that one_course_all_assignments should be available from the 360 Assessment menu, and this appears to have provided similar but less complete information to what Dr. Gehringer has requested in this project.

Looking through the commit history, we determined that 360 Assessment had been removed intentionally in commit [https://github.com/ishanrohatgi0994/expertiza/commit/2c2160793b963d6efebd69bdcbb289edbd15f3f2#diff-0939dc014f523e60f6048caac18e470c 2c21607] for unknown reasons, then added back when Zhewei needed to count the total reviews done by each student in a semester in commit [https://github.com/ishanrohatgi0994/expertiza/commit/67d6ab405ddcba057421d4fa616872e48e83278b#diff-a3ce03cf4ce63e40acb2ae81c102dc2a 67d6ab4]. It was then removed again when [https://github.com/ishanrohatgi0994/expertiza/commit/1ebb5c29e2bd958505b1b57383657c328a2dd599#diff-0939dc014f523e60f6048caac18e470c 1ebb5c2] the committer determined that the functionality the page was providing could be gained by accessing View Aggregated Teammate and Meta-Reviews from the Manage Courses page.

==Use Case UML Activity Diagram==
This is the procedure for accessing the Grade Summary by Student view. It's not too complicated, but our reviewers really wanted some sweet UML action.

[[File:Expertiza_grade_summary_by_student_uml.png]]

==Design==
===Modified Files===
*# app/assets/javascripts/tree_display.jsx
*# app/controllers/assessment360_controller.rb
*# config/routes.rb
*# app/assets/stylesheets/table_sorter.scss

===Created Files===
*# app/views/assessment360/course_student_grade_summary.html.erb
*# spec/controllers/assessment360_controller_spec.rb
*# spec/features/course_student_grade_summary_spec.rb

===The View===
The view for Grade Summary by Student must contain the following information, according to the requirements document and consultation with Dr. Gehringer.
*# Each student's name and id in a course.
*# Each assignment given to each student.
*# The topic name for each assignment.
*# The topic id for each assignment.
*# The grade for each assignment.
*# The peer review score for each assignment.
*# The total score of each student over all of their assignments.

From the Manage Courses page in Expertiza, we intend to place our view behind the 360 Assessment icon for each course. Being able to view every student's complete grades for each assignment constitutes a 360 degree view of every student's performance in a course, and no functionality exists behind the icon currently, so this seems to be a logical choice for placement.

[[File:Expertiza_manage_course_page_360_icon.png]]

The following image shows our initial LoFi sketch of the desired page. It shows our intention to list each student in a row, and to have each column be their assignments. We wanted to contain all the information about their assignment within the column, but did not decided on columns-within-columns until reviewing with Dr. Gehringer.

[[File:Expertiza_grade_summary_by_student_lofi_sketch.png]]

We took Dr. Gehringer's feedback and have created the following rough prototype for the view. The data is absent, but this uses Expertiza's color scheme and style conventions. In this case, Topic Name and Topic Id are space-holders for real values, and Aggregate Score will not have sub-fields in the final draft. We are contemplating putting dividers between the columns, so it is easier to parse where each assignment begins and ends. We are also working on a way for the columns to be sorted by student and by grades.

[[File:Expertiza_grade_summary_by_student_rough_draft_view.png]]

===The Controller===

All of the information required in this view is present in the system: the controller for this view will simply need to make the appropriate queries to the models and database. We intend to create a hash of students given the particular course id, and then use the course id and the student id to retrieve the specific information about the assignments.

All changes were made in the file assessment370controller.rb

==Test Plan==
Because the primary attraction of this feature is a view, the typical unit testing is not as practical as it would be if we were making changes to underlying models. Similarly, there aren't any interactive elements in the view we're testing. As a result, we plan to test the controller and the feature in general as best we can. Here are videos of each set of tests running successfully.

[https://youtu.be/PqpenMq_F2U Assessment360 Controller Tests Video]

[https://youtu.be/3e42Zi1C3_0 Grade Summary by Student Feature Tests Video]

===Controller Tests===
The controller we test is the assessment360_controller.rb, particularly the course_student_grade_summary function. Controller tests are tricky to write, as they can't be sensitive to the model's implementation or how the information will be displayed. As such, we intend to test that each of the instance variables provided to the view is instantiated, but not concern ourselves too much with what the values are (these would be tested by the unit tests for the manu models we query in this method.) This is identified as a best practice for controller tests in [https://guides.rubyonrails.org/testing.html#functional-tests-for-your-controllers Ruby-On-Rails Guide - Functional Tests for Your Controllers].

Here is an image of part of our Controller tests, showing how we handle the case where a course doesn't have any students.

[[File:Expertiza_grade_summary_by_student_assessment360_controller_tests1.png]]

Here is an image of all of the objects which must be mocked in order to properly test the controller function.

[[File:Expertiza_grade_summary_by_student_assessment360_controller_tests2.png]]

Here is an image of some of the tests which verify that the controller instantiates the view's instance variables.

[[File:Expertiza_grade_summary_by_student_assessment360_controller_tests3.png]]

===Feature Tests===
To verify that our view is correct, we'll implement some simple feature tests. Given some dummy students with dummy assignments with dummy fields, we expect that our view's page should display certain information. We'll check that upon navigation to our view, each element of data is present using the Rspec expectation 'to have_content'. In this way, we will verify that our view is performing its job.

Here is an image of all of the objects which must be mocked in order to properly test the feature.

[[File:Expertiza_grade_summary_by_student_feature_test1.png]]

Here is an image of some of the content-check tests for this feature.

[[File:Expertiza_grade_summary_by_student_feature_test2.png]]

CSC/ECE 517 Fall 2018 E1871 Grade Summary By Student

2018-11-24T20:11:32Z

Jfgiall2: added affected file.

==E1871. Grade Summary By Student==

__TOC__

==Introduction==
===Team===
Edward Gehringer(efg) (mentor)
* Dan Goslen (dwgoslen)
* Ishan Rohatgi (irohatg)
* Joe Giallo (jfgiall2)

===Task===
For this project, our task was to create a view which consolidates information related to each assignment for each student in a course in a single page. The objective was to ease the way in which final grades could be viewed, and to provide holistic insight into the performance of each student in a class.

==Background==
This feature was requested by Dr. Gehringer in order to ease the process of collecting student grades for a course for reporting at the end of the semester. This process took nearly an entire day last semester, and the time savings given by a consolidated view containing all this information could be immense. Dr. Gehringer mentioned believing that this information had been previously available under the 360 Assessment tab in the Manage Courses menu, but that functionality had since been broken by an update. The current view indicates that one_course_all_assignments should be available from the 360 Assessment menu, and this appears to have provided similar but less complete information to what Dr. Gehringer has requested in this project.

Looking through the commit history, we determined that 360 Assessment had been removed intentionally in commit [https://github.com/ishanrohatgi0994/expertiza/commit/2c2160793b963d6efebd69bdcbb289edbd15f3f2#diff-0939dc014f523e60f6048caac18e470c 2c21607] for unknown reasons, then added back when Zhewei needed to count the total reviews done by each student in a semester in commit [https://github.com/ishanrohatgi0994/expertiza/commit/67d6ab405ddcba057421d4fa616872e48e83278b#diff-a3ce03cf4ce63e40acb2ae81c102dc2a 67d6ab4]. It was then removed again when [https://github.com/ishanrohatgi0994/expertiza/commit/1ebb5c29e2bd958505b1b57383657c328a2dd599#diff-0939dc014f523e60f6048caac18e470c 1ebb5c2] the committer determined that the functionality the page was providing could be gained by accessing View Aggregated Teammate and Meta-Reviews from the Manage Courses page.

==Use Case UML Activity Diagram==
This is the procedure for accessing the Grade Summary by Student view. It's not too complicated, but our reviewers really wanted some sweet UML action.

[[File:Expertiza_grade_summary_by_student_uml.png]]

==Design==
===The View===
The view for Grade Summary by Student must contain the following information, according to the requirements document and consultation with Dr. Gehringer.
*# Each student's name and id in a course.
*# Each assignment given to each student.
*# The topic name for each assignment.
*# The topic id for each assignment.
*# The grade for each assignment.
*# The peer review score for each assignment.
*# The total score of each student over all of their assignments.

From the Manage Courses page in Expertiza, we intend to place our view behind the 360 Assessment icon for each course. Being able to view every student's complete grades for each assignment constitutes a 360 degree view of every student's performance in a course, and no functionality exists behind the icon currently, so this seems to be a logical choice for placement.

[[File:Expertiza_manage_course_page_360_icon.png]]

The following image shows our initial LoFi sketch of the desired page. It shows our intention to list each student in a row, and to have each column be their assignments. We wanted to contain all the information about their assignment within the column, but did not decided on columns-within-columns until reviewing with Dr. Gehringer.

[[File:Expertiza_grade_summary_by_student_lofi_sketch.png]]

We took Dr. Gehringer's feedback and have created the following rough prototype for the view. The data is absent, but this uses Expertiza's color scheme and style conventions. In this case, Topic Name and Topic Id are space-holders for real values, and Aggregate Score will not have sub-fields in the final draft. We are contemplating putting dividers between the columns, so it is easier to parse where each assignment begins and ends. We are also working on a way for the columns to be sorted by student and by grades.

[[File:Expertiza_grade_summary_by_student_rough_draft_view.png]]

===The Controller===

All of the information required in this view is present in the system: the controller for this view will simply need to make the appropriate queries to the models and database. We intend to create a hash of students given the particular course id, and then use the course id and the student id to retrieve the specific information about the assignments.

All changes were made in the file assessment370controller.rb

==Test Plan==
Because the primary attraction of this feature is a view, the typical unit testing is not as practical as it would be if we were making changes to underlying models. Similarly, there aren't any interactive elements in the view we're testing. As a result, we plan to test the controller and the feature in general as best we can. Here are videos of each set of tests running successfully.

[https://youtu.be/PqpenMq_F2U Assessment360 Controller Tests Video]

[https://youtu.be/3e42Zi1C3_0 Grade Summary by Student Feature Tests Video]

===Controller Tests===
The controller we test is the assessment360_controller.rb, particularly the course_student_grade_summary function. Controller tests are tricky to write, as they can't be sensitive to the model's implementation or how the information will be displayed. As such, we intend to test that each of the instance variables provided to the view is instantiated, but not concern ourselves too much with what the values are (these would be tested by the unit tests for the manu models we query in this method.) This is identified as a best practice for controller tests in [https://guides.rubyonrails.org/testing.html#functional-tests-for-your-controllers Ruby-On-Rails Guide - Functional Tests for Your Controllers].

Here is an image of part of our Controller tests, showing how we handle the case where a course doesn't have any students.

[[File:Expertiza_grade_summary_by_student_assessment360_controller_tests1.png]]

Here is an image of all of the objects which must be mocked in order to properly test the controller function.

[[File:Expertiza_grade_summary_by_student_assessment360_controller_tests2.png]]

Here is an image of some of the tests which verify that the controller instantiates the view's instance variables.

[[File:Expertiza_grade_summary_by_student_assessment360_controller_tests3.png]]

===Feature Tests===
To verify that our view is correct, we'll implement some simple feature tests. Given some dummy students with dummy assignments with dummy fields, we expect that our view's page should display certain information. We'll check that upon navigation to our view, each element of data is present using the Rspec expectation 'to have_content'. In this way, we will verify that our view is performing its job.

Here is an image of all of the objects which must be mocked in order to properly test the feature.

[[File:Expertiza_grade_summary_by_student_feature_test1.png]]

Here is an image of some of the content-check tests for this feature.

[[File:Expertiza_grade_summary_by_student_feature_test2.png]]

CSC/ECE 517 Fall 2018 E1871 Grade Summary By Student

2018-11-24T20:10:29Z

Jfgiall2: Added video links

==E1871. Grade Summary By Student==

__TOC__

==Introduction==
===Team===
Edward Gehringer(efg) (mentor)
* Dan Goslen (dwgoslen)
* Ishan Rohatgi (irohatg)
* Joe Giallo (jfgiall2)

===Task===
For this project, our task was to create a view which consolidates information related to each assignment for each student in a course in a single page. The objective was to ease the way in which final grades could be viewed, and to provide holistic insight into the performance of each student in a class.

==Background==
This feature was requested by Dr. Gehringer in order to ease the process of collecting student grades for a course for reporting at the end of the semester. This process took nearly an entire day last semester, and the time savings given by a consolidated view containing all this information could be immense. Dr. Gehringer mentioned believing that this information had been previously available under the 360 Assessment tab in the Manage Courses menu, but that functionality had since been broken by an update. The current view indicates that one_course_all_assignments should be available from the 360 Assessment menu, and this appears to have provided similar but less complete information to what Dr. Gehringer has requested in this project.

Looking through the commit history, we determined that 360 Assessment had been removed intentionally in commit [https://github.com/ishanrohatgi0994/expertiza/commit/2c2160793b963d6efebd69bdcbb289edbd15f3f2#diff-0939dc014f523e60f6048caac18e470c 2c21607] for unknown reasons, then added back when Zhewei needed to count the total reviews done by each student in a semester in commit [https://github.com/ishanrohatgi0994/expertiza/commit/67d6ab405ddcba057421d4fa616872e48e83278b#diff-a3ce03cf4ce63e40acb2ae81c102dc2a 67d6ab4]. It was then removed again when [https://github.com/ishanrohatgi0994/expertiza/commit/1ebb5c29e2bd958505b1b57383657c328a2dd599#diff-0939dc014f523e60f6048caac18e470c 1ebb5c2] the committer determined that the functionality the page was providing could be gained by accessing View Aggregated Teammate and Meta-Reviews from the Manage Courses page.

==Use Case UML Activity Diagram==
This is the procedure for accessing the Grade Summary by Student view. It's not too complicated, but our reviewers really wanted some sweet UML action.

[[File:Expertiza_grade_summary_by_student_uml.png]]

==Design==
===The View===
The view for Grade Summary by Student must contain the following information, according to the requirements document and consultation with Dr. Gehringer.
*# Each student's name and id in a course.
*# Each assignment given to each student.
*# The topic name for each assignment.
*# The topic id for each assignment.
*# The grade for each assignment.
*# The peer review score for each assignment.
*# The total score of each student over all of their assignments.

From the Manage Courses page in Expertiza, we intend to place our view behind the 360 Assessment icon for each course. Being able to view every student's complete grades for each assignment constitutes a 360 degree view of every student's performance in a course, and no functionality exists behind the icon currently, so this seems to be a logical choice for placement.

[[File:Expertiza_manage_course_page_360_icon.png]]

The following image shows our initial LoFi sketch of the desired page. It shows our intention to list each student in a row, and to have each column be their assignments. We wanted to contain all the information about their assignment within the column, but did not decided on columns-within-columns until reviewing with Dr. Gehringer.

[[File:Expertiza_grade_summary_by_student_lofi_sketch.png]]

We took Dr. Gehringer's feedback and have created the following rough prototype for the view. The data is absent, but this uses Expertiza's color scheme and style conventions. In this case, Topic Name and Topic Id are space-holders for real values, and Aggregate Score will not have sub-fields in the final draft. We are contemplating putting dividers between the columns, so it is easier to parse where each assignment begins and ends. We are also working on a way for the columns to be sorted by student and by grades.

[[File:Expertiza_grade_summary_by_student_rough_draft_view.png]]

===The Controller===

All of the information required in this view is present in the system: the controller for this view will simply need to make the appropriate queries to the models and database. We intend to create a hash of students given the particular course id, and then use the course id and the student id to retrieve the specific information about the assignments.

==Test Plan==
Because the primary attraction of this feature is a view, the typical unit testing is not as practical as it would be if we were making changes to underlying models. Similarly, there aren't any interactive elements in the view we're testing. As a result, we plan to test the controller and the feature in general as best we can. Here are videos of each set of tests running successfully.

[https://youtu.be/PqpenMq_F2U Assessment360 Controller Tests Video]

[https://youtu.be/3e42Zi1C3_0 Grade Summary by Student Feature Tests Video]

===Controller Tests===
The controller we test is the assessment360_controller.rb, particularly the course_student_grade_summary function. Controller tests are tricky to write, as they can't be sensitive to the model's implementation or how the information will be displayed. As such, we intend to test that each of the instance variables provided to the view is instantiated, but not concern ourselves too much with what the values are (these would be tested by the unit tests for the manu models we query in this method.) This is identified as a best practice for controller tests in [https://guides.rubyonrails.org/testing.html#functional-tests-for-your-controllers Ruby-On-Rails Guide - Functional Tests for Your Controllers].

Here is an image of part of our Controller tests, showing how we handle the case where a course doesn't have any students.

[[File:Expertiza_grade_summary_by_student_assessment360_controller_tests1.png]]

Here is an image of all of the objects which must be mocked in order to properly test the controller function.

[[File:Expertiza_grade_summary_by_student_assessment360_controller_tests2.png]]

Here is an image of some of the tests which verify that the controller instantiates the view's instance variables.

[[File:Expertiza_grade_summary_by_student_assessment360_controller_tests3.png]]

===Feature Tests===
To verify that our view is correct, we'll implement some simple feature tests. Given some dummy students with dummy assignments with dummy fields, we expect that our view's page should display certain information. We'll check that upon navigation to our view, each element of data is present using the Rspec expectation 'to have_content'. In this way, we will verify that our view is performing its job.

Here is an image of all of the objects which must be mocked in order to properly test the feature.

[[File:Expertiza_grade_summary_by_student_feature_test1.png]]

Here is an image of some of the content-check tests for this feature.

[[File:Expertiza_grade_summary_by_student_feature_test2.png]]

CSC/ECE 517 Fall 2018 E1871 Grade Summary By Student

2018-11-24T20:06:28Z

Jfgiall2: Added images to the Test Plan.

==E1871. Grade Summary By Student==

__TOC__

==Introduction==
===Team===
Edward Gehringer(efg) (mentor)
* Dan Goslen (dwgoslen)
* Ishan Rohatgi (irohatg)
* Joe Giallo (jfgiall2)

===Task===
For this project, our task was to create a view which consolidates information related to each assignment for each student in a course in a single page. The objective was to ease the way in which final grades could be viewed, and to provide holistic insight into the performance of each student in a class.

==Background==
This feature was requested by Dr. Gehringer in order to ease the process of collecting student grades for a course for reporting at the end of the semester. This process took nearly an entire day last semester, and the time savings given by a consolidated view containing all this information could be immense. Dr. Gehringer mentioned believing that this information had been previously available under the 360 Assessment tab in the Manage Courses menu, but that functionality had since been broken by an update. The current view indicates that one_course_all_assignments should be available from the 360 Assessment menu, and this appears to have provided similar but less complete information to what Dr. Gehringer has requested in this project.

Looking through the commit history, we determined that 360 Assessment had been removed intentionally in commit [https://github.com/ishanrohatgi0994/expertiza/commit/2c2160793b963d6efebd69bdcbb289edbd15f3f2#diff-0939dc014f523e60f6048caac18e470c 2c21607] for unknown reasons, then added back when Zhewei needed to count the total reviews done by each student in a semester in commit [https://github.com/ishanrohatgi0994/expertiza/commit/67d6ab405ddcba057421d4fa616872e48e83278b#diff-a3ce03cf4ce63e40acb2ae81c102dc2a 67d6ab4]. It was then removed again when [https://github.com/ishanrohatgi0994/expertiza/commit/1ebb5c29e2bd958505b1b57383657c328a2dd599#diff-0939dc014f523e60f6048caac18e470c 1ebb5c2] the committer determined that the functionality the page was providing could be gained by accessing View Aggregated Teammate and Meta-Reviews from the Manage Courses page.

==Use Case UML Activity Diagram==
This is the procedure for accessing the Grade Summary by Student view. It's not too complicated, but our reviewers really wanted some sweet UML action.

[[File:Expertiza_grade_summary_by_student_uml.png]]

==Design==
===The View===
The view for Grade Summary by Student must contain the following information, according to the requirements document and consultation with Dr. Gehringer.
*# Each student's name and id in a course.
*# Each assignment given to each student.
*# The topic name for each assignment.
*# The topic id for each assignment.
*# The grade for each assignment.
*# The peer review score for each assignment.
*# The total score of each student over all of their assignments.

From the Manage Courses page in Expertiza, we intend to place our view behind the 360 Assessment icon for each course. Being able to view every student's complete grades for each assignment constitutes a 360 degree view of every student's performance in a course, and no functionality exists behind the icon currently, so this seems to be a logical choice for placement.

[[File:Expertiza_manage_course_page_360_icon.png]]

The following image shows our initial LoFi sketch of the desired page. It shows our intention to list each student in a row, and to have each column be their assignments. We wanted to contain all the information about their assignment within the column, but did not decided on columns-within-columns until reviewing with Dr. Gehringer.

[[File:Expertiza_grade_summary_by_student_lofi_sketch.png]]

We took Dr. Gehringer's feedback and have created the following rough prototype for the view. The data is absent, but this uses Expertiza's color scheme and style conventions. In this case, Topic Name and Topic Id are space-holders for real values, and Aggregate Score will not have sub-fields in the final draft. We are contemplating putting dividers between the columns, so it is easier to parse where each assignment begins and ends. We are also working on a way for the columns to be sorted by student and by grades.

[[File:Expertiza_grade_summary_by_student_rough_draft_view.png]]

===The Controller===

All of the information required in this view is present in the system: the controller for this view will simply need to make the appropriate queries to the models and database. We intend to create a hash of students given the particular course id, and then use the course id and the student id to retrieve the specific information about the assignments.

==Test Plan==
Because the primary attraction of this feature is a view, the typical unit testing is not as practical as it would be if we were making changes to underlying models. Similarly, there aren't any interactive elements in the view we're testing. As a result, we plan to test the controller and the feature in general as best we can.

===Controller Tests===
The controller we test is the assessment360_controller.rb, particularly the course_student_grade_summary function. Controller tests are tricky to write, as they can't be sensitive to the model's implementation or how the information will be displayed. As such, we intend to test that each of the instance variables provided to the view is instantiated, but not concern ourselves too much with what the values are (these would be tested by the unit tests for the manu models we query in this method.) This is identified as a best practice for controller tests in [https://guides.rubyonrails.org/testing.html#functional-tests-for-your-controllers Ruby-On-Rails Guide - Functional Tests for Your Controllers].

Here is an image of part of our Controller tests, showing how we handle the case where a course doesn't have any students.

[[File:Expertiza_grade_summary_by_student_assessment360_controller_tests1.png]]

Here is an image of all of the objects which must be mocked in order to properly test the controller function.

[[File:Expertiza_grade_summary_by_student_assessment360_controller_tests2.png]]

Here is an image of some of the tests which verify that the controller instantiates the view's instance variables.

[[File:Expertiza_grade_summary_by_student_assessment360_controller_tests3.png]]

===Feature Tests===
To verify that our view is correct, we'll implement some simple feature tests. Given some dummy students with dummy assignments with dummy fields, we expect that our view's page should display certain information. We'll check that upon navigation to our view, each element of data is present using the Rspec expectation 'to have_content'. In this way, we will verify that our view is performing its job.

Here is an image of all of the objects which must be mocked in order to properly test the feature.

[[File:Expertiza_grade_summary_by_student_feature_test1.png]]

Here is an image of some of the content-check tests for this feature.

[[File:Expertiza_grade_summary_by_student_feature_test2.png]]

File:Expertiza grade summary by student feature test2.png

2018-11-24T19:58:59Z

Jfgiall2: Fall 2018 E1871 Grade Summary by Student Feature Test Part 2

Fall 2018 E1871 Grade Summary by Student Feature Test Part 2

File:Expertiza grade summary by student feature test1.png

2018-11-24T19:58:32Z

Jfgiall2: Fall 2018 E1871 Grade Summary by Student Feature Test Part 1

Fall 2018 E1871 Grade Summary by Student Feature Test Part 1

File:Expertiza grade summary by student assessment360 controller tests3.png

2018-11-24T19:57:45Z

Jfgiall2: Fall 2018 E1871 Assessment360 Controller Test Part 3

Fall 2018 E1871 Assessment360 Controller Test Part 3

File:Expertiza grade summary by student assessment360 controller tests2.png

2018-11-24T19:57:06Z

Jfgiall2: Fall 2018 E1871 Assessment360 Controller Test Part 2

Fall 2018 E1871 Assessment360 Controller Test Part 2

File:Expertiza grade summary by student assessment360 controller tests1.png

2018-11-24T19:56:35Z

Jfgiall2: Fall 2018 E1871 Assessment360 Controller Test Part 1

Fall 2018 E1871 Assessment360 Controller Test Part 1

CSC/ECE 517 Fall 2018 E1871 Grade Summary By Student

2018-11-17T16:01:21Z

Jfgiall2: /* Use Case UML Activity Diagram */

CSC/ECE 517 Fall 2018 E1871 Grade Summary By Student

2018-11-17T16:01:05Z

Jfgiall2: Added UML activity chart.

File:Expertiza grade summary by student uml.png

2018-11-17T16:00:38Z

Jfgiall2: uploaded a new version of "File:Expertiza grade summary by student uml.png": Forgot descriptions on conditional.

UML Activity Diagram for E1871 Fall 2018

File:Expertiza grade summary by student uml.png

2018-11-17T15:55:51Z

Jfgiall2: uploaded a new version of "File:Expertiza grade summary by student uml.png": Changed wording.

UML Activity Diagram for E1871 Fall 2018

File:Expertiza grade summary by student uml.png

2018-11-17T15:53:49Z

Jfgiall2: UML Activity Diagram for E1871 Fall 2018

UML Activity Diagram for E1871 Fall 2018

CSC/ECE 517 Fall 2018 E1871 Grade Summary By Student

2018-11-13T02:34:33Z

Jfgiall2: /* Feature Tests */

CSC/ECE 517 Fall 2018 E1871 Grade Summary By Student

2018-11-13T02:34:26Z

Jfgiall2: /* Controller Tests */

CSC/ECE 517 Fall 2018 E1871 Grade Summary By Student

2018-11-13T02:32:03Z

Jfgiall2: /* The View */

CSC/ECE 517 Fall 2018 E1871 Grade Summary By Student

2018-11-13T02:31:21Z

Jfgiall2: /* Controller Tests */

File:Expertiza grade summary by student rough draft view.png

2018-11-13T02:15:27Z

Jfgiall2: uploaded a new version of "File:Expertiza grade summary by student rough draft view.png"

E1871 draft view of grade summary by student.

CSC/ECE 517 Fall 2018 E1871 Grade Summary By Student

2018-11-13T02:14:46Z

Jfgiall2: /* The View */

File:Expertiza manage course page 360 icon.png

2018-11-13T02:10:55Z

Jfgiall2: uploaded a new version of "File:Expertiza manage course page 360 icon.png"

Image of Manage Course page demonstrating the location of the 360 degree icon.

File:Expertiza manage course page 360 icon.png

2018-11-13T02:10:15Z

Jfgiall2: uploaded a new version of "File:Expertiza manage course page 360 icon.png"

Image of Manage Course page demonstrating the location of the 360 degree icon.

CSC/ECE 517 Fall 2018 E1871 Grade Summary By Student

2018-11-13T02:03:19Z

Jfgiall2: /* The View */

CSC/ECE 517 Fall 2018 E1871 Grade Summary By Student

2018-11-12T00:12:27Z

Jfgiall2: Initialize E1871 Design Document page.

File:Expertiza grade summary by student rough draft view.png

2018-11-11T23:34:07Z

Jfgiall2: E1871 draft view of grade summary by student.

E1871 draft view of grade summary by student.

File:Expertiza grade summary by student lofi sketch.png

2018-11-11T23:29:33Z

Jfgiall2: lofi sketch for E1871

lofi sketch for E1871

File:Expertiza manage course page 360 icon.png

2018-11-11T23:23:29Z

Jfgiall2: uploaded a new version of "File:Expertiza manage course page 360 icon.png"

Image of Manage Course page demonstrating the location of the 360 degree icon.

File:Expertiza manage course page 360 icon.png

2018-11-11T23:21:44Z

Jfgiall2: Image of Manage Course page demonstrating the location of the 360 degree icon.

Image of Manage Course page demonstrating the location of the 360 degree icon.

CSC/ECE 517 Fall 2018

2018-11-04T21:06:54Z

Jfgiall2:

* [[CSC/ECE 517 Fall 2018- Project E1846. OSS Project Navy: Character Issues]]
* [[CSC/ECE 517 Fall 2018/OSS E1848 Write unit tests for assignment team.rb]]
* [http://wiki.expertiza.ncsu.edu/index.php/E1839_Review_Requirements_and_Thresholds CSC/ECE 517 Fall 2018 E1839 Review Requirements and Thresholds]
* [http://wiki.expertiza.ncsu.edu/index.php/E1848_Write_unit_tests_for_assignment_team CSC/ECE 517 Fall 2018 E1848 Write unit tests for assignment_team]
* [http://wiki.expertiza.ncsu.edu/index.php/E1835_Refactor_delayed_mailer_and_scheduled_task CSC/ECE 517 Fall 2018 E1835_Refactor_delayed_mailer_and_scheduled_task]
* [http://wiki.expertiza.ncsu.edu/index.php/E1829_OSS_project_Duke_Blue_Fix_import_glitches CSC/ECE 517 Fall 2018 E1829 OSS project Duke Blue: Fix import glitches]
* [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2018/E1853_Write_unit_tests_for_menu.rb CSC/ECE 517 Fall 2018 E1853 Write unit tests for menu.rb]
* [http://wiki.expertiza.ncsu.edu/index.php/E1853_write_unit_tests_for_menu CSC/ECE517 Fall 2018 E1853 Write Unit Tests For menu.rb]
* [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2018_-_Project_E1852_Write_unit_tests_for_participant.rb CSC/ECE 517 Fall 2018 E1852 Write unit tests for participant.rb]
* [http://wiki.expertiza.ncsu.edu/index.php/E1844_Issues_related_to_names CSC/ECE 517 Fall 2018 E1844 Issues related to names]
* [http://wiki.expertiza.ncsu.edu/index.php/User_talk:Rshakya CSC/ECE 517 Fall 2018/E1852 Unit Test for Participant Model]
* [http://wiki.expertiza.ncsu.edu/index.php/E1850_Write_unit_tests_for_review_response_map CSC/ECE 517 Fall 2018 Write unit tests for review-response_map.rb]

CSC/ECE 517 Fall 2018

2018-11-04T21:06:02Z

Jfgiall2:

* [[CSC/ECE 517 Fall 2018- Project E1846. OSS Project Navy: Character Issues]]
* [[CSC/ECE 517 Fall 2018/OSS E1848 Write unit tests for assignment team.rb]]
* [http://wiki.expertiza.ncsu.edu/index.php/E1839_Review_Requirements_and_Thresholds CSC/ECE 517 Fall 2018 E1839 Review Requirements and Thresholds]
* [http://wiki.expertiza.ncsu.edu/index.php/E1848_Write_unit_tests_for_assignment_team CSC/ECE 517 Fall 2018 E1848 Write unit tests for assignment_team]
* [http://wiki.expertiza.ncsu.edu/index.php/E1835_Refactor_delayed_mailer_and_scheduled_task CSC/ECE 517 Fall 2018 E1835_Refactor_delayed_mailer_and_scheduled_task]
* [http://wiki.expertiza.ncsu.edu/index.php/E1829_OSS_project_Duke_Blue_Fix_import_glitches CSC/ECE 517 Fall 2018 E1829 OSS project Duke Blue: Fix import glitches]
* [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2018/E1853_Write_unit_tests_for_menu.rb CSC/ECE 517 Fall 2018 E1853 Write unit tests for menu.rb]
* [http://wiki.expertiza.ncsu.edu/index.php/E1853_write_unit_tests_for_menu]
* [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2018_-_Project_E1852_Write_unit_tests_for_participant.rb CSC/ECE 517 Fall 2018 E1852 Write unit tests for participant.rb]
* [http://wiki.expertiza.ncsu.edu/index.php/E1844_Issues_related_to_names CSC/ECE 517 Fall 2018 E1844 Issues related to names]
* [http://wiki.expertiza.ncsu.edu/index.php/User_talk:Rshakya CSC/ECE 517 Fall 2018/E1852 Unit Test for Participant Model]
* [http://wiki.expertiza.ncsu.edu/index.php/E1850_Write_unit_tests_for_review_response_map CSC/ECE 517 Fall 2018 Write unit tests for review-response_map.rb]

E1853 write unit tests for menu

2018-10-30T23:15:23Z

Jfgiall2: /* Design */

==E1853. Write Unit Tests for Menu.rb==

__TOC__

==Introduction==
===Team===
Zhewei Hu (zhu6) (mentor)
*Joe Giallo (jfgiall2)
*Senthil Sankar (ssankar9)
*Vato Maskhulia (vmaskhu)

===Task===
For this project, our task was to achieve at least 90% code coverage on the menu.rb model.

==Background==

===Menus and Nodes===
Menus (and their sub-component, Nodes) provide the foundation for navigation within the Expertiza platform. With the role of the user as input, they present to the user all possible options a user of their role can have from the top of each Expertiza screen. The Menu is critical for navigating Expertiza and exposing the correct functionality to the correct users.

===Motivation===
Testing is critical to ensuring that software is functional. A robust test suite which tests the returns of query messages and the side effects of command messages will help expedite development by quickly ensuring nothing has broken when changes are made. While manually testing the behavior of the menu is quite straight-forward, automating the underlying mechanics of the menu, which are abstract and generic, is a good best practice to prove that the system for generating menus is not broken.

==Test Plan==
In order to fully test menu.rb, we composed a total of 29 tests, 12 for the Node class and 17 for the Menu class.
*'''Node'''
*# Node#setup - Node#setup appropriately sets a Node's parent_id, name, id, and label to those of the MenuItem passed to it as an argument.
*# Node#setup - When MenuItem has a ControllerAction, Node#setup(MenuItem) makes Node's controller_action_id becomes that ControllerAction's id.
*# Node#setup - When MenuItem has a ControllerAction, Node#setup(MenuItem) makes Node's url become ControllerAction's url_to_use.
*# Node#setup - When MenuItem's ControllerAction has a Controller, Node#setup(MenuItem) makes Node's site_controller_id equal to Controller's id.
*# Node#setup - When MenuItem's ControllerAction has no url_to_use, Node#setup(MenuItem) makes Node's url equal to "/#{controller.name}/#{controller_action.name}", the controller_action's name appended to the controller's name.
*# Node#setup - When MenuItem has a ContentPage, Node#setup(MenuItem) makes Node's content_page_id equal to ContentPage's id.
*# Node#setup - When MenuItem has a ContentPage, Node#setup(MenuItem) makes Node's url equal to ContentPage's name.
*# Node#site_controller - #site_controller sets the @site_controller instance variable.
*# Node#controller_action - #controller_action sets the @controller_action instance variable.
*# Node#content_page - #content_page sets the @content_page instance variable.
*# Node#add_child - #add_child updates Node's children
*# Node#add_child - #add_child adds multiple children to Node's children.
*'''Menu'''
*# Menu#select - it returns if select(name) is not in @by_name
*# Menu#select - when name is in @by_name, Menu.selected is equal to name, @crumbs ends with the lowest level node and begins with the highest level node, and #selected? returns true for all nodes from the selected node to the root.
*# Menu#get_item - returns nil when id is not in @by_id
*# Menu#get_item - returns the equivalent item when id is in @by_id (item is not identical, but all components of item are the same).
*# Menu#get_menu - returns nil if level has no children.
*# Menu#get_menu - return children of a level if level has children.
*# Menu#get_menu - return all nodes except root if level is root.
*# Menu#selected - returns root if nothing has been selected.
*# Menu#selected - returns the name of the last selected menu_item.
*# Menu#selected? - if nothing has been selected, selected?(root_node) returns true.
*# Menu#selected? - if a node has been selected, selected? returns true for selected node and all its parents.
*# Menu#selected? - if there are no menu items corresponding to the permission's of the role provided to menu, selected? does not return true.
*# Menu#selected? - if MenuItem returns an empty array, selected? returns false for all input.
*# Menu#crumbs - When top-level menu item is selected, crumbs has length one.
*# Menu#crumbs - When top-level menu item is selected, crumbs has the root node's id.
*# Menu#crumbs - When bottom-level menu item is selected, crumbs has two crumbs (assuming lowest level is two).
*# Menu#crumbs - When bottom-level menu item is selected, crumbs are ordered from child to parent and all are present up to root.

==Design and Impact==

===Design===
Because of the nature of our assignment, our only design decisions were made with respect to making our Rspec tests as clean and readable as possible. We did not modify the application code itself. That being said, the Menu model is highly compositional, and it touches on MenuItem, ControllerAction, Controller, ContentPage, and Role (in addition to Node, which is in the same model). As a result, one of our main objectives was to make sure that we were transparent about all the different models which need to exist and how they interact with each other, in order for the Menu model to work.

We address this issue by neatly creating all of the mock objects that we need in 'let' blocks before the tests, and explaining any of the tricky nuances (like how MenuItems and Roles interact using the role_(user_type).yml file). We also add additional comments to some of the more complex test cases (#select) to explain why we're expecting the particular side effects we're expecting, when our 'it' and 'context' block descriptions cannot easily convey all of the complexities.

Here is an example of how we mock objects for the Node unit tests.

[[File:Csc517_e1853_mocking_objects_example.png]]

Here is a snapshot of the Node unit tests, which shows proper utilization of Rspec best practices. We utilize short, coherent expectations. We use contexts to provide more information about the branches in a function that we are testing. We avoid binding ourselves to implementation by stubbing methods which are called in other classes.

[[File:Csc517_e1853_rspec_unit_test_examples.png]]

===Impact===
In the future, it will be very easy to test whether changes to the menu model have broken the original functionality. It will also be easy to add more tests to raise our test suite's mutant-killing rank, as we have done the hard part of defining all the mock objects and prototyping the relations they all have with each other in this initial set of tests.

==Results==
We ended up with 100% code coverage, and mutation testing on our test suite yielded 90.21% mutant-slaying capabilities. We believe this is a demonstration of the exemplary thoroughness of our test suite, and that these changes should be pulled in to the Expertiza master branch.
This image shows our test suite running.

[[File:Csc517_oss_project_rspec_run.png]]

This image shows an abbreviated version of /coverage/index.html page which is generate after running rspec. It shows us achieving 100% code coverage.

[[File:Csc517_oss_project_rspec_run_results.png]]

This image shows our mutation score. Of 531 mutations, we killed 479 and 52 were left alive. This is a mutation coverage of 90.21%. While we will leave it to the TA to verify this claim, examination of the living mutants shows that many of the mutations replaced lines with equivalent code (fetching a variable as opposed to just accessing it, or substituting equivalent variables for one another). Similarly, killing the remainder of the mutants would require binding our tests to implementation, to ensure that particular methods get called. As such, we believe our mutation score is quite good.

[[File:Csc517_oss_project_mutation_score.png]]

====Effected Files====
The files involved in this commit are:
* menu.rb - the model being tested. Contains the menu class and the node class.
* menu_spec.rb - the spec file for menu. Contains all of our tests.
* spec_helper.rb - we added a limit on how long tests can take to run, as one of the mutations which was generated had infinite runtime.

====Video of Test Suite Running====
A video of our test suite running properly can be found here!

[https://youtu.be/PGRU7dfAsXk E1853 Menu Unit Tests Running (Hosted on Youtube)]

File:Csc517 e1853 rspec unit test examples.png

2018-10-30T23:13:39Z

Jfgiall2: e1853- unit tests partial example for rspec with contexts and stuff

e1853- unit tests partial example for rspec with contexts and stuff

File:Csc517 e1853 mocking objects example.png

2018-10-30T23:13:05Z

Jfgiall2: e1853 fall 2018: broken down image for our object mocking methodology

e1853 fall 2018: broken down image for our object mocking methodology

E1853 write unit tests for menu

2018-10-30T23:09:36Z

Jfgiall2: remove extraneous expertiza background section.

==E1853. Write Unit Tests for Menu.rb==

__TOC__

==Introduction==
===Team===
Zhewei Hu (zhu6) (mentor)
*Joe Giallo (jfgiall2)
*Senthil Sankar (ssankar9)
*Vato Maskhulia (vmaskhu)

===Task===
For this project, our task was to achieve at least 90% code coverage on the menu.rb model.

==Background==

===Menus and Nodes===
Menus (and their sub-component, Nodes) provide the foundation for navigation within the Expertiza platform. With the role of the user as input, they present to the user all possible options a user of their role can have from the top of each Expertiza screen. The Menu is critical for navigating Expertiza and exposing the correct functionality to the correct users.

===Motivation===
Testing is critical to ensuring that software is functional. A robust test suite which tests the returns of query messages and the side effects of command messages will help expedite development by quickly ensuring nothing has broken when changes are made. While manually testing the behavior of the menu is quite straight-forward, automating the underlying mechanics of the menu, which are abstract and generic, is a good best practice to prove that the system for generating menus is not broken.

==Test Plan==
In order to fully test menu.rb, we composed a total of 29 tests, 12 for the Node class and 17 for the Menu class.
*'''Node'''
*# Node#setup - Node#setup appropriately sets a Node's parent_id, name, id, and label to those of the MenuItem passed to it as an argument.
*# Node#setup - When MenuItem has a ControllerAction, Node#setup(MenuItem) makes Node's controller_action_id becomes that ControllerAction's id.
*# Node#setup - When MenuItem has a ControllerAction, Node#setup(MenuItem) makes Node's url become ControllerAction's url_to_use.
*# Node#setup - When MenuItem's ControllerAction has a Controller, Node#setup(MenuItem) makes Node's site_controller_id equal to Controller's id.
*# Node#setup - When MenuItem's ControllerAction has no url_to_use, Node#setup(MenuItem) makes Node's url equal to "/#{controller.name}/#{controller_action.name}", the controller_action's name appended to the controller's name.
*# Node#setup - When MenuItem has a ContentPage, Node#setup(MenuItem) makes Node's content_page_id equal to ContentPage's id.
*# Node#setup - When MenuItem has a ContentPage, Node#setup(MenuItem) makes Node's url equal to ContentPage's name.
*# Node#site_controller - #site_controller sets the @site_controller instance variable.
*# Node#controller_action - #controller_action sets the @controller_action instance variable.
*# Node#content_page - #content_page sets the @content_page instance variable.
*# Node#add_child - #add_child updates Node's children
*# Node#add_child - #add_child adds multiple children to Node's children.
*'''Menu'''
*# Menu#select - it returns if select(name) is not in @by_name
*# Menu#select - when name is in @by_name, Menu.selected is equal to name, @crumbs ends with the lowest level node and begins with the highest level node, and #selected? returns true for all nodes from the selected node to the root.
*# Menu#get_item - returns nil when id is not in @by_id
*# Menu#get_item - returns the equivalent item when id is in @by_id (item is not identical, but all components of item are the same).
*# Menu#get_menu - returns nil if level has no children.
*# Menu#get_menu - return children of a level if level has children.
*# Menu#get_menu - return all nodes except root if level is root.
*# Menu#selected - returns root if nothing has been selected.
*# Menu#selected - returns the name of the last selected menu_item.
*# Menu#selected? - if nothing has been selected, selected?(root_node) returns true.
*# Menu#selected? - if a node has been selected, selected? returns true for selected node and all its parents.
*# Menu#selected? - if there are no menu items corresponding to the permission's of the role provided to menu, selected? does not return true.
*# Menu#selected? - if MenuItem returns an empty array, selected? returns false for all input.
*# Menu#crumbs - When top-level menu item is selected, crumbs has length one.
*# Menu#crumbs - When top-level menu item is selected, crumbs has the root node's id.
*# Menu#crumbs - When bottom-level menu item is selected, crumbs has two crumbs (assuming lowest level is two).
*# Menu#crumbs - When bottom-level menu item is selected, crumbs are ordered from child to parent and all are present up to root.

==Design and Impact==

===Design===
Because of the nature of our assignment, our only design decisions were made with respect to making our Rspec tests as clean and readable as possible. We did not modify the application code itself. That being said, the Menu model is highly compositional, and it touches on MenuItem, ControllerAction, Controller, ContentPage, and Role (in addition to Node, which is in the same model). As a result, one of our main objectives was to make sure that we were transparent about all the different models which need to exist and how they interact with each other, in order for the Menu model to work.

We address this issue by neatly creating all of the mock objects that we need in 'let' blocks before the tests, and explaining any of the tricky nuances (like how MenuItems and Roles interact using the role_(user_type).yml file). We also add additional comments to some of the more complex test cases (#select) to explain why we're expecting the particular side effects we're expecting, when our 'it' and 'context' block descriptions cannot easily convey all of the complexities.

Here is a snapshot of the Node unit tests, which shows proper utilization of Rspec best practices. We define all of our necessary mock objects. We utilize short, coherent expectations. We use contexts to provide more information about the branches in a function that we are testing. We avoid binding ourselves to implementation by stubbing methods which are called in other classes.

[[File:Csc517_oss_menu_unit_tests.png]]

===Impact===
In the future, it will be very easy to test whether changes to the menu model have broken the original functionality. It will also be easy to add more tests to raise our test suite's mutant-killing rank, as we have done the hard part of defining all the mock objects and prototyping the relations they all have with each other in this initial set of tests.

==Results==
We ended up with 100% code coverage, and mutation testing on our test suite yielded 90.21% mutant-slaying capabilities. We believe this is a demonstration of the exemplary thoroughness of our test suite, and that these changes should be pulled in to the Expertiza master branch.
This image shows our test suite running.

[[File:Csc517_oss_project_rspec_run.png]]

This image shows an abbreviated version of /coverage/index.html page which is generate after running rspec. It shows us achieving 100% code coverage.

[[File:Csc517_oss_project_rspec_run_results.png]]

This image shows our mutation score. Of 531 mutations, we killed 479 and 52 were left alive. This is a mutation coverage of 90.21%. While we will leave it to the TA to verify this claim, examination of the living mutants shows that many of the mutations replaced lines with equivalent code (fetching a variable as opposed to just accessing it, or substituting equivalent variables for one another). Similarly, killing the remainder of the mutants would require binding our tests to implementation, to ensure that particular methods get called. As such, we believe our mutation score is quite good.

[[File:Csc517_oss_project_mutation_score.png]]

====Effected Files====
The files involved in this commit are:
* menu.rb - the model being tested. Contains the menu class and the node class.
* menu_spec.rb - the spec file for menu. Contains all of our tests.
* spec_helper.rb - we added a limit on how long tests can take to run, as one of the mutations which was generated had infinite runtime.

====Video of Test Suite Running====
A video of our test suite running properly can be found here!

[https://youtu.be/PGRU7dfAsXk E1853 Menu Unit Tests Running (Hosted on Youtube)]

E1853 write unit tests for menu

2018-10-27T17:11:19Z

Jfgiall2: /* Video of Test Suite Running */

==E1853. Write Unit Tests for Menu.rb==

__TOC__

==Introduction==
===Team===
Zhewei Hu (zhu6) (mentor)
*Joe Giallo (jfgiall2)
*Senthil Sankar (ssankar9)
*Vato Maskhulia (vmaskhu)

===Task===
For this project, our task was to achieve at least 90% code coverage on the menu.rb model.

==Background==
===Expertiza===
[http://expertiza.ncsu.edu/ Expertiza] is an open source web application based on [http://rubyonrails.org/ Ruby on Rails] framework. It provides instructors with the ability to create, customize, and assign projects. It provides students with the ability to form teams and collaborate on these assignments, submit those assignments, as well as review others and be reviewed on their work.

===Menus and Nodes===
Menus (and their sub-component, Nodes) provide the foundation for navigation within the Expertiza platform. With the role of the user as input, they present to the user all possible options a user of their role can have from the top of each Expertiza screen. The Menu is critical for navigating Expertiza and exposing the correct functionality to the correct users.

===Motivation===
Testing is critical to ensuring that software is functional. A robust test suite which tests the returns of query messages and the side effects of command messages will help expedite development by quickly ensuring nothing has broken when changes are made. While manually testing the behavior of the menu is quite straight-forward, automating the underlying mechanics of the menu, which are abstract and generic, is a good best practice to prove that the system for generating menus is not broken.

==Test Plan==
In order to fully test menu.rb, we composed a total of 29 tests, 12 for the Node class and 17 for the Menu class.
*'''Node'''
*# Node#setup - Node#setup appropriately sets a Node's parent_id, name, id, and label to those of the MenuItem passed to it as an argument.
*# Node#setup - When MenuItem has a ControllerAction, Node#setup(MenuItem) makes Node's controller_action_id becomes that ControllerAction's id.
*# Node#setup - When MenuItem has a ControllerAction, Node#setup(MenuItem) makes Node's url become ControllerAction's url_to_use.
*# Node#setup - When MenuItem's ControllerAction has a Controller, Node#setup(MenuItem) makes Node's site_controller_id equal to Controller's id.
*# Node#setup - When MenuItem's ControllerAction has no url_to_use, Node#setup(MenuItem) makes Node's url equal to "/#{controller.name}/#{controller_action.name}", the controller_action's name appended to the controller's name.
*# Node#setup - When MenuItem has a ContentPage, Node#setup(MenuItem) makes Node's content_page_id equal to ContentPage's id.
*# Node#setup - When MenuItem has a ContentPage, Node#setup(MenuItem) makes Node's url equal to ContentPage's name.
*# Node#site_controller - #site_controller sets the @site_controller instance variable.
*# Node#controller_action - #controller_action sets the @controller_action instance variable.
*# Node#content_page - #content_page sets the @content_page instance variable.
*# Node#add_child - #add_child updates Node's children
*# Node#add_child - #add_child adds multiple children to Node's children.
*'''Menu'''
*# Menu#select - it returns if select(name) is not in @by_name
*# Menu#select - when name is in @by_name, Menu.selected is equal to name, @crumbs ends with the lowest level node and begins with the highest level node, and #selected? returns true for all nodes from the selected node to the root.
*# Menu#get_item - returns nil when id is not in @by_id
*# Menu#get_item - returns the equivalent item when id is in @by_id (item is not identical, but all components of item are the same).
*# Menu#get_menu - returns nil if level has no children.
*# Menu#get_menu - return children of a level if level has children.
*# Menu#get_menu - return all nodes except root if level is root.
*# Menu#selected - returns root if nothing has been selected.
*# Menu#selected - returns the name of the last selected menu_item.
*# Menu#selected? - if nothing has been selected, selected?(root_node) returns true.
*# Menu#selected? - if a node has been selected, selected? returns true for selected node and all its parents.
*# Menu#selected? - if there are no menu items corresponding to the permission's of the role provided to menu, selected? does not return true.
*# Menu#selected? - if MenuItem returns an empty array, selected? returns false for all input.
*# Menu#crumbs - When top-level menu item is selected, crumbs has length one.
*# Menu#crumbs - When top-level menu item is selected, crumbs has the root node's id.
*# Menu#crumbs - When bottom-level menu item is selected, crumbs has two crumbs (assuming lowest level is two).
*# Menu#crumbs - When bottom-level menu item is selected, crumbs are ordered from child to parent and all are present up to root.

==Design and Impact==

===Design===
Because of the nature of our assignment, our only design decisions were made with respect to making our Rspec tests as clean and readable as possible. We did not modify the application code itself. That being said, the Menu model is highly compositional, and it touches on MenuItem, ControllerAction, Controller, ContentPage, and Role (in addition to Node, which is in the same model). As a result, one of our main objectives was to make sure that we were transparent about all the different models which need to exist and how they interact with each other, in order for the Menu model to work.

We address this issue by neatly creating all of the mock objects that we need in 'let' blocks before the tests, and explaining any of the tricky nuances (like how MenuItems and Roles interact using the role_(user_type).yml file). We also add additional comments to some of the more complex test cases (#select) to explain why we're expecting the particular side effects we're expecting, when our 'it' and 'context' block descriptions cannot easily convey all of the complexities.

Here is a snapshot of the Node unit tests, which shows proper utilization of Rspec best practices. We define all of our necessary mock objects. We utilize short, coherent expectations. We use contexts to provide more information about the branches in a function that we are testing. We avoid binding ourselves to implementation by stubbing methods which are called in other classes.

[[File:Csc517_oss_menu_unit_tests.png]]

===Impact===
In the future, it will be very easy to test whether changes to the menu model have broken the original functionality. It will also be easy to add more tests to raise our test suite's mutant-killing rank, as we have done the hard part of defining all the mock objects and prototyping the relations they all have with each other in this initial set of tests.

==Results==
We ended up with 100% code coverage, and mutation testing on our test suite yielded 90.21% mutant-slaying capabilities. We believe this is a demonstration of the exemplary thoroughness of our test suite, and that these changes should be pulled in to the Expertiza master branch.
This image shows our test suite running.

[[File:Csc517_oss_project_rspec_run.png]]

This image shows an abbreviated version of /coverage/index.html page which is generate after running rspec. It shows us achieving 100% code coverage.

[[File:Csc517_oss_project_rspec_run_results.png]]

This image shows our mutation score. Of 531 mutations, we killed 479 and 52 were left alive. This is a mutation coverage of 90.21%. While we will leave it to the TA to verify this claim, examination of the living mutants shows that many of the mutations replaced lines with equivalent code (fetching a variable as opposed to just accessing it, or substituting equivalent variables for one another). Similarly, killing the remainder of the mutants would require binding our tests to implementation, to ensure that particular methods get called. As such, we believe our mutation score is quite good.

[[File:Csc517_oss_project_mutation_score.png]]

====Effected Files====
The files involved in this commit are:
* menu.rb - the model being tested. Contains the menu class and the node class.
* menu_spec.rb - the spec file for menu. Contains all of our tests.
* spec_helper.rb - we added a limit on how long tests can take to run, as one of the mutations which was generated had infinite runtime.

====Video of Test Suite Running====
A video of our test suite running properly can be found here!

[https://youtu.be/PGRU7dfAsXk E1853 Menu Unit Tests Running (Hosted on Youtube)]

E1853 write unit tests for menu

2018-10-27T17:04:16Z

Jfgiall2: formatting

==E1853. Write Unit Tests for Menu.rb==

__TOC__

==Introduction==
===Team===
Zhewei Hu (zhu6) (mentor)
*Joe Giallo (jfgiall2)
*Senthil Sankar (ssankar9)
*Vato Maskhulia (vmaskhu)

===Task===
For this project, our task was to achieve at least 90% code coverage on the menu.rb model.

==Background==
===Expertiza===
[http://expertiza.ncsu.edu/ Expertiza] is an open source web application based on [http://rubyonrails.org/ Ruby on Rails] framework. It provides instructors with the ability to create, customize, and assign projects. It provides students with the ability to form teams and collaborate on these assignments, submit those assignments, as well as review others and be reviewed on their work.

===Menus and Nodes===
Menus (and their sub-component, Nodes) provide the foundation for navigation within the Expertiza platform. With the role of the user as input, they present to the user all possible options a user of their role can have from the top of each Expertiza screen. The Menu is critical for navigating Expertiza and exposing the correct functionality to the correct users.

===Motivation===
Testing is critical to ensuring that software is functional. A robust test suite which tests the returns of query messages and the side effects of command messages will help expedite development by quickly ensuring nothing has broken when changes are made. While manually testing the behavior of the menu is quite straight-forward, automating the underlying mechanics of the menu, which are abstract and generic, is a good best practice to prove that the system for generating menus is not broken.

==Test Plan==
In order to fully test menu.rb, we composed a total of 29 tests, 12 for the Node class and 17 for the Menu class.
*'''Node'''
*# Node#setup - Node#setup appropriately sets a Node's parent_id, name, id, and label to those of the MenuItem passed to it as an argument.
*# Node#setup - When MenuItem has a ControllerAction, Node#setup(MenuItem) makes Node's controller_action_id becomes that ControllerAction's id.
*# Node#setup - When MenuItem has a ControllerAction, Node#setup(MenuItem) makes Node's url become ControllerAction's url_to_use.
*# Node#setup - When MenuItem's ControllerAction has a Controller, Node#setup(MenuItem) makes Node's site_controller_id equal to Controller's id.
*# Node#setup - When MenuItem's ControllerAction has no url_to_use, Node#setup(MenuItem) makes Node's url equal to "/#{controller.name}/#{controller_action.name}", the controller_action's name appended to the controller's name.
*# Node#setup - When MenuItem has a ContentPage, Node#setup(MenuItem) makes Node's content_page_id equal to ContentPage's id.
*# Node#setup - When MenuItem has a ContentPage, Node#setup(MenuItem) makes Node's url equal to ContentPage's name.
*# Node#site_controller - #site_controller sets the @site_controller instance variable.
*# Node#controller_action - #controller_action sets the @controller_action instance variable.
*# Node#content_page - #content_page sets the @content_page instance variable.
*# Node#add_child - #add_child updates Node's children
*# Node#add_child - #add_child adds multiple children to Node's children.
*'''Menu'''
*# Menu#select - it returns if select(name) is not in @by_name
*# Menu#select - when name is in @by_name, Menu.selected is equal to name, @crumbs ends with the lowest level node and begins with the highest level node, and #selected? returns true for all nodes from the selected node to the root.
*# Menu#get_item - returns nil when id is not in @by_id
*# Menu#get_item - returns the equivalent item when id is in @by_id (item is not identical, but all components of item are the same).
*# Menu#get_menu - returns nil if level has no children.
*# Menu#get_menu - return children of a level if level has children.
*# Menu#get_menu - return all nodes except root if level is root.
*# Menu#selected - returns root if nothing has been selected.
*# Menu#selected - returns the name of the last selected menu_item.
*# Menu#selected? - if nothing has been selected, selected?(root_node) returns true.
*# Menu#selected? - if a node has been selected, selected? returns true for selected node and all its parents.
*# Menu#selected? - if there are no menu items corresponding to the permission's of the role provided to menu, selected? does not return true.
*# Menu#selected? - if MenuItem returns an empty array, selected? returns false for all input.
*# Menu#crumbs - When top-level menu item is selected, crumbs has length one.
*# Menu#crumbs - When top-level menu item is selected, crumbs has the root node's id.
*# Menu#crumbs - When bottom-level menu item is selected, crumbs has two crumbs (assuming lowest level is two).
*# Menu#crumbs - When bottom-level menu item is selected, crumbs are ordered from child to parent and all are present up to root.

==Design and Impact==

===Design===
Because of the nature of our assignment, our only design decisions were made with respect to making our Rspec tests as clean and readable as possible. We did not modify the application code itself. That being said, the Menu model is highly compositional, and it touches on MenuItem, ControllerAction, Controller, ContentPage, and Role (in addition to Node, which is in the same model). As a result, one of our main objectives was to make sure that we were transparent about all the different models which need to exist and how they interact with each other, in order for the Menu model to work.

We address this issue by neatly creating all of the mock objects that we need in 'let' blocks before the tests, and explaining any of the tricky nuances (like how MenuItems and Roles interact using the role_(user_type).yml file). We also add additional comments to some of the more complex test cases (#select) to explain why we're expecting the particular side effects we're expecting, when our 'it' and 'context' block descriptions cannot easily convey all of the complexities.

Here is a snapshot of the Node unit tests, which shows proper utilization of Rspec best practices. We define all of our necessary mock objects. We utilize short, coherent expectations. We use contexts to provide more information about the branches in a function that we are testing. We avoid binding ourselves to implementation by stubbing methods which are called in other classes.

[[File:Csc517_oss_menu_unit_tests.png]]

===Impact===
In the future, it will be very easy to test whether changes to the menu model have broken the original functionality. It will also be easy to add more tests to raise our test suite's mutant-killing rank, as we have done the hard part of defining all the mock objects and prototyping the relations they all have with each other in this initial set of tests.

==Results==
We ended up with 100% code coverage, and mutation testing on our test suite yielded 90.21% mutant-slaying capabilities. We believe this is a demonstration of the exemplary thoroughness of our test suite, and that these changes should be pulled in to the Expertiza master branch.
This image shows our test suite running.

[[File:Csc517_oss_project_rspec_run.png]]

This image shows an abbreviated version of /coverage/index.html page which is generate after running rspec. It shows us achieving 100% code coverage.

[[File:Csc517_oss_project_rspec_run_results.png]]

This image shows our mutation score. Of 531 mutations, we killed 479 and 52 were left alive. This is a mutation coverage of 90.21%. While we will leave it to the TA to verify this claim, examination of the living mutants shows that many of the mutations replaced lines with equivalent code (fetching a variable as opposed to just accessing it, or substituting equivalent variables for one another). Similarly, killing the remainder of the mutants would require binding our tests to implementation, to ensure that particular methods get called. As such, we believe our mutation score is quite good.

[[File:Csc517_oss_project_mutation_score.png]]

====Effected Files====
The files involved in this commit are:
* menu.rb - the model being tested. Contains the menu class and the node class.
* menu_spec.rb - the spec file for menu. Contains all of our tests.
* spec_helper.rb - we added a limit on how long tests can take to run, as one of the mutations which was generated had infinite runtime.

====Video of Test Suite Running====
A video of our test suite running properly can be found here!

E1853 write unit tests for menu

2018-10-27T17:04:02Z

Jfgiall2: More Formatting. Like literally just so much.

==E1853. Write Unit Tests for Menu.rb==

__TOC__

==Introduction==
===Team===
Zhewei Hu (zhu6) (mentor)
*Joe Giallo (jfgiall2)
*Senthil Sankar (ssankar9)
*Vato Maskhulia (vmaskhu)

===Task===
For this project, our task was to achieve at least 90% code coverage on the menu.rb model.

==Background==
===Expertiza===
[http://expertiza.ncsu.edu/ Expertiza] is an open source web application based on [http://rubyonrails.org/ Ruby on Rails] framework. It provides instructors with the ability to create, customize, and assign projects. It provides students with the ability to form teams and collaborate on these assignments, submit those assignments, as well as review others and be reviewed on their work.

===Menus and Nodes===
Menus (and their sub-component, Nodes) provide the foundation for navigation within the Expertiza platform. With the role of the user as input, they present to the user all possible options a user of their role can have from the top of each Expertiza screen. The Menu is critical for navigating Expertiza and exposing the correct functionality to the correct users.

===Motivation===
Testing is critical to ensuring that software is functional. A robust test suite which tests the returns of query messages and the side effects of command messages will help expedite development by quickly ensuring nothing has broken when changes are made. While manually testing the behavior of the menu is quite straight-forward, automating the underlying mechanics of the menu, which are abstract and generic, is a good best practice to prove that the system for generating menus is not broken.

==Test Plan==
In order to fully test menu.rb, we composed a total of 29 tests, 12 for the Node class and 17 for the Menu class.
*'''Node'''
*# Node#setup - Node#setup appropriately sets a Node's parent_id, name, id, and label to those of the MenuItem passed to it as an argument.
*# Node#setup - When MenuItem has a ControllerAction, Node#setup(MenuItem) makes Node's controller_action_id becomes that ControllerAction's id.
*# Node#setup - When MenuItem has a ControllerAction, Node#setup(MenuItem) makes Node's url become ControllerAction's url_to_use.
*# Node#setup - When MenuItem's ControllerAction has a Controller, Node#setup(MenuItem) makes Node's site_controller_id equal to Controller's id.
*# Node#setup - When MenuItem's ControllerAction has no url_to_use, Node#setup(MenuItem) makes Node's url equal to "/#{controller.name}/#{controller_action.name}", the controller_action's name appended to the controller's name.
*# Node#setup - When MenuItem has a ContentPage, Node#setup(MenuItem) makes Node's content_page_id equal to ContentPage's id.
*# Node#setup - When MenuItem has a ContentPage, Node#setup(MenuItem) makes Node's url equal to ContentPage's name.
*# Node#site_controller - #site_controller sets the @site_controller instance variable.
*# Node#controller_action - #controller_action sets the @controller_action instance variable.
*# Node#content_page - #content_page sets the @content_page instance variable.
*# Node#add_child - #add_child updates Node's children
*# Node#add_child - #add_child adds multiple children to Node's children.
*'''Menu'''
*# Menu#select - it returns if select(name) is not in @by_name
*# Menu#select - when name is in @by_name, Menu.selected is equal to name, @crumbs ends with the lowest level node and begins with the highest level node, and #selected? returns true for all nodes from the selected node to the root.
*# Menu#get_item - returns nil when id is not in @by_id
*# Menu#get_item - returns the equivalent item when id is in @by_id (item is not identical, but all components of item are the same).
*# Menu#get_menu - returns nil if level has no children.
*# Menu#get_menu - return children of a level if level has children.
*# Menu#get_menu - return all nodes except root if level is root.
*# Menu#selected - returns root if nothing has been selected.
*# Menu#selected - returns the name of the last selected menu_item.
*# Menu#selected? - if nothing has been selected, selected?(root_node) returns true.
*# Menu#selected? - if a node has been selected, selected? returns true for selected node and all its parents.
*# Menu#selected? - if there are no menu items corresponding to the permission's of the role provided to menu, selected? does not return true.
*# Menu#selected? - if MenuItem returns an empty array, selected? returns false for all input.
*# Menu#crumbs - When top-level menu item is selected, crumbs has length one.
*# Menu#crumbs - When top-level menu item is selected, crumbs has the root node's id.
*# Menu#crumbs - When bottom-level menu item is selected, crumbs has two crumbs (assuming lowest level is two).
*# Menu#crumbs - When bottom-level menu item is selected, crumbs are ordered from child to parent and all are present up to root.

==Design and Impact==

===Design===
Because of the nature of our assignment, our only design decisions were made with respect to making our Rspec tests as clean and readable as possible. We did not modify the application code itself. That being said, the Menu model is highly compositional, and it touches on MenuItem, ControllerAction, Controller, ContentPage, and Role (in addition to Node, which is in the same model). As a result, one of our main objectives was to make sure that we were transparent about all the different models which need to exist and how they interact with each other, in order for the Menu model to work.

We address this issue by neatly creating all of the mock objects that we need in 'let' blocks before the tests, and explaining any of the tricky nuances (like how MenuItems and Roles interact using the role_(user_type).yml file). We also add additional comments to some of the more complex test cases (#select) to explain why we're expecting the particular side effects we're expecting, when our 'it' and 'context' block descriptions cannot easily convey all of the complexities.

Here is a snapshot of the Node unit tests, which shows proper utilization of Rspec best practices. We define all of our necessary mock objects. We utilize short, coherent expectations. We use contexts to provide more information about the branches in a function that we are testing. We avoid binding ourselves to implementation by stubbing methods which are called in other classes.

[[File:Csc517_oss_menu_unit_tests.png]]

===Impact===
In the future, it will be very easy to test whether changes to the menu model have broken the original functionality. It will also be easy to add more tests to raise our test suite's mutant-killing rank, as we have done the hard part of defining all the mock objects and prototyping the relations they all have with each other in this initial set of tests.

==Results==
We ended up with 100% code coverage, and mutation testing on our test suite yielded 90.21% mutant-slaying capabilities. We believe this is a demonstration of the exemplary thoroughness of our test suite, and that these changes should be pulled in to the Expertiza master branch.
This image shows our test suite running.

[[File:Csc517_oss_project_rspec_run.png]]

This image shows an abbreviated version of /coverage/index.html page which is generate after running rspec. It shows us achieving 100% code coverage.

[[File:Csc517_oss_project_rspec_run_results.png]]

This image shows our mutation score. Of 531 mutations, we killed 479 and 52 were left alive. This is a mutation coverage of 90.21%. While we will leave it to the TA to verify this claim, examination of the living mutants shows that many of the mutations replaced lines with equivalent code (fetching a variable as opposed to just accessing it, or substituting equivalent variables for one another). Similarly, killing the remainder of the mutants would require binding our tests to implementation, to ensure that particular methods get called. As such, we believe our mutation score is quite good.

[[File:Csc517_oss_project_mutation_score.png]]

====Effected Files====
The files involved in this commit are:
* menu.rb - the model being tested. Contains the menu class and the node class.
* menu_spec.rb - the spec file for menu. Contains all of our tests.
* spec_helper.rb - we added a limit on how long tests can take to run, as one of the mutations which was generated had infinite runtime.

====Video of Test Suite Running====
A video of our test suite running properly can be found here!

E1853 write unit tests for menu

2018-10-27T17:01:32Z

Jfgiall2: /* Test Plan */

==E1853. Write Unit Tests for Menu.rb==

__TOC__

==Introduction==
===Team===
Zhewei Hu (zhu6) (mentor)
*Joe Giallo (jfgiall2)
*Senthil Sankar (ssankar9)
*Vato Maskhulia (vmaskhu)
===Task and Results===
====Task====
For this project, our task was to achieve at least 90% code coverage on the menu.rb model.

====Results====
We ended up with 100% code coverage, and mutation testing on our test suite yielded 90.21% mutant-slaying capabilities. We believe this is a demonstration of the exemplary thoroughness of our test suite, and that these changes should be pulled in to the Expertiza master branch.
This image shows our test suite running.

[[File:Csc517_oss_project_rspec_run.png]]

This image shows an abbreviated version of /coverage/index.html page which is generate after running rspec. It shows us achieving 100% code coverage.

[[File:Csc517_oss_project_rspec_run_results.png]]

This image shows our mutation score. Of 531 mutations, we killed 479 and 52 were left alive. This is a mutation coverage of 90.21%. While we will leave it to the TA to verify this claim, examination of the living mutants shows that many of the mutations replaced lines with equivalent code (fetching a variable as opposed to just accessing it, or substituting equivalent variables for one another). Similarly, killing the remainder of the mutants would require binding our tests to implementation, to ensure that particular methods get called. As such, we believe our mutation score is quite good.

[[File:Csc517_oss_project_mutation_score.png]]

====Effected Files====
The files involved in this commit are:
* menu.rb - the model being tested. Contains the menu class and the node class.
* menu_spec.rb - the spec file for menu. Contains all of our tests.
* spec_helper.rb - we added a limit on how long tests can take to run, as one of the mutations which was generated had infinite runtime.

====Video of Test Suite Running====
A video of our test suite running properly can be found here!

===Background===
====Expertiza====
[http://expertiza.ncsu.edu/ Expertiza] is an open source web application based on [http://rubyonrails.org/ Ruby on Rails] framework. It provides instructors with the ability to create, customize, and assign projects. It provides students with the ability to form teams and collaborate on these assignments, submit those assignments, as well as review others and be reviewed on their work.

====Menus and Nodes====
Menus (and their sub-component, Nodes) provide the foundation for navigation within the Expertiza platform. With the role of the user as input, they present to the user all possible options a user of their role can have from the top of each Expertiza screen. The Menu is critical for navigating Expertiza and exposing the correct functionality to the correct users.

====Motivation====
Testing is critical to ensuring that software is functional. A robust test suite which tests the returns of query messages and the side effects of command messages will help expedite development by quickly ensuring nothing has broken when changes are made. While manually testing the behavior of the menu is quite straight-forward, automating the underlying mechanics of the menu, which are abstract and generic, is a good best practice to prove that the system for generating menus is not broken.

===Test Plan===
In order to fully test menu.rb, we composed a total of 29 tests, 12 for the Node class and 17 for the Menu class.
*'''Node'''
*# Node#setup - Node#setup appropriately sets a Node's parent_id, name, id, and label to those of the MenuItem passed to it as an argument.
*# Node#setup - When MenuItem has a ControllerAction, Node#setup(MenuItem) makes Node's controller_action_id becomes that ControllerAction's id.
*# Node#setup - When MenuItem has a ControllerAction, Node#setup(MenuItem) makes Node's url become ControllerAction's url_to_use.
*# Node#setup - When MenuItem's ControllerAction has a Controller, Node#setup(MenuItem) makes Node's site_controller_id equal to Controller's id.
*# Node#setup - When MenuItem's ControllerAction has no url_to_use, Node#setup(MenuItem) makes Node's url equal to "/#{controller.name}/#{controller_action.name}", the controller_action's name appended to the controller's name.
*# Node#setup - When MenuItem has a ContentPage, Node#setup(MenuItem) makes Node's content_page_id equal to ContentPage's id.
*# Node#setup - When MenuItem has a ContentPage, Node#setup(MenuItem) makes Node's url equal to ContentPage's name.
*# Node#site_controller - #site_controller sets the @site_controller instance variable.
*# Node#controller_action - #controller_action sets the @controller_action instance variable.
*# Node#content_page - #content_page sets the @content_page instance variable.
*# Node#add_child - #add_child updates Node's children
*# Node#add_child - #add_child adds multiple children to Node's children.
*'''Menu'''
*# Menu#select - it returns if select(name) is not in @by_name
*# Menu#select - when name is in @by_name, Menu.selected is equal to name, @crumbs ends with the lowest level node and begins with the highest level node, and #selected? returns true for all nodes from the selected node to the root.
*# Menu#get_item - returns nil when id is not in @by_id
*# Menu#get_item - returns the equivalent item when id is in @by_id (item is not identical, but all components of item are the same).
*# Menu#get_menu - returns nil if level has no children.
*# Menu#get_menu - return children of a level if level has children.
*# Menu#get_menu - return all nodes except root if level is root.
*# Menu#selected - returns root if nothing has been selected.
*# Menu#selected - returns the name of the last selected menu_item.
*# Menu#selected? - if nothing has been selected, selected?(root_node) returns true.
*# Menu#selected? - if a node has been selected, selected? returns true for selected node and all its parents.
*# Menu#selected? - if there are no menu items corresponding to the permission's of the role provided to menu, selected? does not return true.
*# Menu#selected? - if MenuItem returns an empty array, selected? returns false for all input.
*# Menu#crumbs - When top-level menu item is selected, crumbs has length one.
*# Menu#crumbs - When top-level menu item is selected, crumbs has the root node's id.
*# Menu#crumbs - When bottom-level menu item is selected, crumbs has two crumbs (assuming lowest level is two).
*# Menu#crumbs - When bottom-level menu item is selected, crumbs are ordered from child to parent and all are present up to root.

===Design and Impact===

====Design====
Because of the nature of our assignment, our only design decisions were made with respect to making our Rspec tests as clean and readable as possible. We did not modify the application code itself. That being said, the Menu model is highly compositional, and it touches on MenuItem, ControllerAction, Controller, ContentPage, and Role (in addition to Node, which is in the same model). As a result, one of our main objectives was to make sure that we were transparent about all the different models which need to exist and how they interact with each other, in order for the Menu model to work.

We address this issue by neatly creating all of the mock objects that we need in 'let' blocks before the tests, and explaining any of the tricky nuances (like how MenuItems and Roles interact using the role_(user_type).yml file). We also add additional comments to some of the more complex test cases (#select) to explain why we're expecting the particular side effects we're expecting, when our 'it' and 'context' block descriptions cannot easily convey all of the complexities.

Here is a snapshot of the Node unit tests, which shows proper utilization of Rspec best practices. We define all of our necessary mock objects. We utilize short, coherent expectations. We use contexts to provide more information about the branches in a function that we are testing. We avoid binding ourselves to implementation by stubbing methods which are called in other classes.

[[File:Csc517_oss_menu_unit_tests.png]]

====Impact====
In the future, it will be very easy to test whether changes to the menu model have broken the original functionality. It will also be easy to add more tests to raise our test suite's mutant-killing rank, as we have done the hard part of defining all the mock objects and prototyping the relations they all have with each other in this initial set of tests.

E1853 write unit tests for menu

2018-10-27T17:01:02Z

Jfgiall2: Fixed moooooore formatting.

==E1853. Write Unit Tests for Menu.rb==

__TOC__

==Introduction==
===Team===
Zhewei Hu (zhu6) (mentor)
*Joe Giallo (jfgiall2)
*Senthil Sankar (ssankar9)
*Vato Maskhulia (vmaskhu)
===Task and Results===
====Task====
For this project, our task was to achieve at least 90% code coverage on the menu.rb model.

====Results====
We ended up with 100% code coverage, and mutation testing on our test suite yielded 90.21% mutant-slaying capabilities. We believe this is a demonstration of the exemplary thoroughness of our test suite, and that these changes should be pulled in to the Expertiza master branch.
This image shows our test suite running.

[[File:Csc517_oss_project_rspec_run.png]]

This image shows an abbreviated version of /coverage/index.html page which is generate after running rspec. It shows us achieving 100% code coverage.

[[File:Csc517_oss_project_rspec_run_results.png]]

This image shows our mutation score. Of 531 mutations, we killed 479 and 52 were left alive. This is a mutation coverage of 90.21%. While we will leave it to the TA to verify this claim, examination of the living mutants shows that many of the mutations replaced lines with equivalent code (fetching a variable as opposed to just accessing it, or substituting equivalent variables for one another). Similarly, killing the remainder of the mutants would require binding our tests to implementation, to ensure that particular methods get called. As such, we believe our mutation score is quite good.

[[File:Csc517_oss_project_mutation_score.png]]

====Effected Files====
The files involved in this commit are:
* menu.rb - the model being tested. Contains the menu class and the node class.
* menu_spec.rb - the spec file for menu. Contains all of our tests.
* spec_helper.rb - we added a limit on how long tests can take to run, as one of the mutations which was generated had infinite runtime.

====Video of Test Suite Running====
A video of our test suite running properly can be found here!

===Background===
====Expertiza====
[http://expertiza.ncsu.edu/ Expertiza] is an open source web application based on [http://rubyonrails.org/ Ruby on Rails] framework. It provides instructors with the ability to create, customize, and assign projects. It provides students with the ability to form teams and collaborate on these assignments, submit those assignments, as well as review others and be reviewed on their work.

====Menus and Nodes====
Menus (and their sub-component, Nodes) provide the foundation for navigation within the Expertiza platform. With the role of the user as input, they present to the user all possible options a user of their role can have from the top of each Expertiza screen. The Menu is critical for navigating Expertiza and exposing the correct functionality to the correct users.

====Motivation====
Testing is critical to ensuring that software is functional. A robust test suite which tests the returns of query messages and the side effects of command messages will help expedite development by quickly ensuring nothing has broken when changes are made. While manually testing the behavior of the menu is quite straight-forward, automating the underlying mechanics of the menu, which are abstract and generic, is a good best practice to prove that the system for generating menus is not broken.

===Test Plan===
In order to fully test menu.rb, we composed a total of 29 tests, 12 for the Node class and 17 for the Menu class.

*'''Node'''
*# Node#setup - Node#setup appropriately sets a Node's parent_id, name, id, and label to those of the MenuItem passed to it as an argument.
*# Node#setup - When MenuItem has a ControllerAction, Node#setup(MenuItem) makes Node's controller_action_id becomes that ControllerAction's id.
*# Node#setup - When MenuItem has a ControllerAction, Node#setup(MenuItem) makes Node's url become ControllerAction's url_to_use.
*# Node#setup - When MenuItem's ControllerAction has a Controller, Node#setup(MenuItem) makes Node's site_controller_id equal to Controller's id.
*# Node#setup - When MenuItem's ControllerAction has no url_to_use, Node#setup(MenuItem) makes Node's url equal to "/#{controller.name}/#{controller_action.name}", the controller_action's name appended to the controller's name.
*# Node#setup - When MenuItem has a ContentPage, Node#setup(MenuItem) makes Node's content_page_id equal to ContentPage's id.
*# Node#setup - When MenuItem has a ContentPage, Node#setup(MenuItem) makes Node's url equal to ContentPage's name.
*# Node#site_controller - #site_controller sets the @site_controller instance variable.
*# Node#controller_action - #controller_action sets the @controller_action instance variable.
*# Node#content_page - #content_page sets the @content_page instance variable.
*# Node#add_child - #add_child updates Node's children
*# Node#add_child - #add_child adds multiple children to Node's children.
*'''Menu'''
*# Menu#select - it returns if select(name) is not in @by_name
*# Menu#select - when name is in @by_name, Menu.selected is equal to name, @crumbs ends with the lowest level node and begins with the highest level node, and #selected? returns true for all nodes from the selected node to the root.
*# Menu#get_item - returns nil when id is not in @by_id
*# Menu#get_item - returns the equivalent item when id is in @by_id (item is not identical, but all components of item are the same).
*# Menu#get_menu - returns nil if level has no children.
*# Menu#get_menu - return children of a level if level has children.
*# Menu#get_menu - return all nodes except root if level is root.
*# Menu#selected - returns root if nothing has been selected.
*# Menu#selected - returns the name of the last selected menu_item.
*# Menu#selected? - if nothing has been selected, selected?(root_node) returns true.
*# Menu#selected? - if a node has been selected, selected? returns true for selected node and all its parents.
*# Menu#selected? - if there are no menu items corresponding to the permission's of the role provided to menu, selected? does not return true.
*# Menu#selected? - if MenuItem returns an empty array, selected? returns false for all input.
*# Menu#crumbs - When top-level menu item is selected, crumbs has length one.
*# Menu#crumbs - When top-level menu item is selected, crumbs has the root node's id.
*# Menu#crumbs - When bottom-level menu item is selected, crumbs has two crumbs (assuming lowest level is two).
*# Menu#crumbs - When bottom-level menu item is selected, crumbs are ordered from child to parent and all are present up to root.

===Design and Impact===

====Design====
Because of the nature of our assignment, our only design decisions were made with respect to making our Rspec tests as clean and readable as possible. We did not modify the application code itself. That being said, the Menu model is highly compositional, and it touches on MenuItem, ControllerAction, Controller, ContentPage, and Role (in addition to Node, which is in the same model). As a result, one of our main objectives was to make sure that we were transparent about all the different models which need to exist and how they interact with each other, in order for the Menu model to work.

We address this issue by neatly creating all of the mock objects that we need in 'let' blocks before the tests, and explaining any of the tricky nuances (like how MenuItems and Roles interact using the role_(user_type).yml file). We also add additional comments to some of the more complex test cases (#select) to explain why we're expecting the particular side effects we're expecting, when our 'it' and 'context' block descriptions cannot easily convey all of the complexities.

Here is a snapshot of the Node unit tests, which shows proper utilization of Rspec best practices. We define all of our necessary mock objects. We utilize short, coherent expectations. We use contexts to provide more information about the branches in a function that we are testing. We avoid binding ourselves to implementation by stubbing methods which are called in other classes.

[[File:Csc517_oss_menu_unit_tests.png]]

====Impact====
In the future, it will be very easy to test whether changes to the menu model have broken the original functionality. It will also be easy to add more tests to raise our test suite's mutant-killing rank, as we have done the hard part of defining all the mock objects and prototyping the relations they all have with each other in this initial set of tests.

E1853 write unit tests for menu

2018-10-27T16:54:54Z

Jfgiall2: Fixed formatting typo.

==E1853. Write Unit Tests for Menu.rb==

__TOC__

==Introduction==
===Team===
Zhewei Hu (zhu6) (mentor)
*Joe Giallo (jfgiall2)
*Senthil Sankar (ssankar9)
*Vato Maskhulia (vmaskhu)
===Task and Results===
====Task====
For this project, our task was to achieve at least 90% code coverage on the menu.rb model.

====Results====
We ended up with 100% code coverage, and mutation testing on our test suite yielded 90.21% mutant-slaying capabilities. We believe this is a demonstration of the exemplary thoroughness of our test suite, and that these changes should be pulled in to the Expertiza master branch.
This image shows our test suite running.

[[File:Csc517_oss_project_rspec_run.png]]

This image shows an abbreviated version of /coverage/index.html page which is generate after running rspec. It shows us achieving 100% code coverage.

[[File:Csc517_oss_project_rspec_run_results.png]]

This image shows our mutation score. Of 531 mutations, we killed 479 and 52 were left alive. This is a mutation coverage of 90.21%. While we will leave it to the TA to verify this claim, examination of the living mutants shows that many of the mutations replaced lines with equivalent code (fetching a variable as opposed to just accessing it, or substituting equivalent variables for one another). Similarly, killing the remainder of the mutants would require binding our tests to implementation, to ensure that particular methods get called. As such, we believe our mutation score is quite good.

[[File:Csc517_oss_project_mutation_score.png]]

====Effected Files====
The files involved in this commit are:
* menu.rb - the model being tested. Contains the menu class and the node class.
* menu_spec.rb - the spec file for menu. Contains all of our tests.
* spec_helper.rb - we added a limit on how long tests can take to run, as one of the mutations which was generated had infinite runtime.

====Video of Test Suite Running====
A video of our test suite running properly can be found here!

===Background===
====Expertiza====
[http://expertiza.ncsu.edu/ Expertiza] is an open source web application based on [http://rubyonrails.org/ Ruby on Rails] framework. It provides instructors with the ability to create, customize, and assign projects. It provides students with the ability to form teams and collaborate on these assignments, submit those assignments, as well as review others and be reviewed on their work.

====Menus and Nodes====
Menus (and their sub-component, Nodes) provide the foundation for navigation within the Expertiza platform. With the role of the user as input, they present to the user all possible options a user of their role can have from the top of each Expertiza screen. The Menu is critical for navigating Expertiza and exposing the correct functionality to the correct users.

====Motivation====
Testing is critical to ensuring that software is functional. A robust test suite which tests the returns of query messages and the side effects of command messages will help expedite development by quickly ensuring nothing has broken when changes are made. While manually testing the behavior of the menu is quite straight-forward, automating the underlying mechanics of the menu, which are abstract and generic, is a good best practice to prove that the system for generating menus is not broken.

===Test Plan===
In order to fully test menu.rb, we composed a total of 29 tests, 12 for the Node class and 17 for the Menu class.
'''Node'''
1. Node#setup - Node#setup appropriately sets a Node's parent_id, name, id, and label to those of the MenuItem passed to it as an argument.
2. Node#setup - When MenuItem has a ControllerAction, Node#setup(MenuItem) makes Node's controller_action_id becomes that ControllerAction's id.
3. Node#setup - When MenuItem has a ControllerAction, Node#setup(MenuItem) makes Node's url become ControllerAction's url_to_use.
4. Node#setup - When MenuItem's ControllerAction has a Controller, Node#setup(MenuItem) makes Node's site_controller_id equal to Controller's id.
5. Node#setup - When MenuItem's ControllerAction has no url_to_use, Node#setup(MenuItem) makes Node's url equal to "/#{controller.name}/#{controller_action.name}", the controller_action's name appended to the controller's name.
6. Node#setup - When MenuItem has a ContentPage, Node#setup(MenuItem) makes Node's content_page_id equal to ContentPage's id.
7. Node#setup - When MenuItem has a ContentPage, Node#setup(MenuItem) makes Node's url equal to ContentPage's name.
8. Node#site_controller - #site_controller sets the @site_controller instance variable.
9. Node#controller_action - #controller_action sets the @controller_action instance variable.
10. Node#content_page - #content_page sets the @content_page instance variable.
11. Node#add_child - #add_child updates Node's children
12. Node#add_child - #add_child adds multiple children to Node's children.
'''Menu'''
1. Menu#select - it returns if select(name) is not in @by_name
2. Menu#select - when name is in @by_name, Menu.selected is equal to name, @crumbs ends with the lowest level node and begins with the highest level node, and #selected? returns true for all nodes from the selected node to the root.
3. Menu#get_item - returns nil when id is not in @by_id
4. Menu#get_item - returns the equivalent item when id is in @by_id (item is not identical, but all components of item are the same).
5. Menu#get_menu - returns nil if level has no children.
6. Menu#get_menu - return children of a level if level has children.
7. Menu#get_menu - return all nodes except root if level is root.
8. Menu#selected - returns root if nothing has been selected.
9. Menu#selected - returns the name of the last selected menu_item.
10. Menu#selected? - if nothing has been selected, selected?(root_node) returns true.
11. Menu#selected? - if a node has been selected, selected? returns true for selected node and all its parents.
12. Menu#selected? - if there are no menu items corresponding to the permission's of the role provided to menu, selected? does not return true.
13. Menu#selected? - if MenuItem returns an empty array, selected? returns false for all input.
14. Menu#crumbs - When top-level menu item is selected, crumbs has length one.
15. Menu#crumbs - When top-level menu item is selected, crumbs has the root node's id.
16. Menu#crumbs - When bottom-level menu item is selected, crumbs has two crumbs (assuming lowest level is two).
17. Menu#crumbs - When bottom-level menu item is selected, crumbs are ordered from child to parent and all are present up to root.

===Design and Impact===

====Design====
Because of the nature of our assignment, our only design decisions were made with respect to making our Rspec tests as clean and readable as possible. We did not modify the application code itself. That being said, the Menu model is highly compositional, and it touches on MenuItem, ControllerAction, Controller, ContentPage, and Role (in addition to Node, which is in the same model). As a result, one of our main objectives was to make sure that we were transparent about all the different models which need to exist and how they interact with each other, in order for the Menu model to work.

We address this issue by neatly creating all of the mock objects that we need in 'let' blocks before the tests, and explaining any of the tricky nuances (like how MenuItems and Roles interact using the role_(user_type).yml file). We also add additional comments to some of the more complex test cases (#select) to explain why we're expecting the particular side effects we're expecting, when our 'it' and 'context' block descriptions cannot easily convey all of the complexities.

Here is a snapshot of the Node unit tests, which shows proper utilization of Rspec best practices. We define all of our necessary mock objects. We utilize short, coherent expectations. We use contexts to provide more information about the branches in a function that we are testing. We avoid binding ourselves to implementation by stubbing methods which are called in other classes.

[[File:Csc517_oss_menu_unit_tests.png]]

====Impact====
In the future, it will be very easy to test whether changes to the menu model have broken the original functionality. It will also be easy to add more tests to raise our test suite's mutant-killing rank, as we have done the hard part of defining all the mock objects and prototyping the relations they all have with each other in this initial set of tests.

E1853 write unit tests for menu

2018-10-27T16:54:29Z

Jfgiall2: Changed formatting.

==E1853. Write Unit Tests for Menu.rb==

__TOC__

==Introduction==
===Team===
Zhewei Hu (zhu6) (mentor)
*Joe Giallo (jfgiall2)
*Senthil Sankar (ssankar9)
*Vato Maskhulia (vmaskhu)
===Task and Results===
====Task====
For this project, our task was to achieve at least 90% code coverage on the menu.rb model.

====Results====
We ended up with 100% code coverage, and mutation testing on our test suite yielded 90.21% mutant-slaying capabilities. We believe this is a demonstration of the exemplary thoroughness of our test suite, and that these changes should be pulled in to the Expertiza master branch.
This image shows our test suite running.

[[File:Csc517_oss_project_rspec_run.png]]

This image shows an abbreviated version of /coverage/index.html page which is generate after running rspec. It shows us achieving 100% code coverage.

[[File:Csc517_oss_project_rspec_run_results.png]]

This image shows our mutation score. Of 531 mutations, we killed 479 and 52 were left alive. This is a mutation coverage of 90.21%. While we will leave it to the TA to verify this claim, examination of the living mutants shows that many of the mutations replaced lines with equivalent code (fetching a variable as opposed to just accessing it, or substituting equivalent variables for one another). Similarly, killing the remainder of the mutants would require binding our tests to implementation, to ensure that particular methods get called. As such, we believe our mutation score is quite good.

[[File:Csc517_oss_project_mutation_score.png]]

====Effected Files====
The files involved in this commit are:
* menu.rb - the model being tested. Contains the menu class and the node class.
* menu_spec.rb - the spec file for menu. Contains all of our tests.
* spec_helper.rb - we added a limit on how long tests can take to run, as one of the mutations which was generated had infinite runtime.

====Video of Test Suite Running===
A video of our test suite running properly can be found here!

===Background===
====Expertiza====
[http://expertiza.ncsu.edu/ Expertiza] is an open source web application based on [http://rubyonrails.org/ Ruby on Rails] framework. It provides instructors with the ability to create, customize, and assign projects. It provides students with the ability to form teams and collaborate on these assignments, submit those assignments, as well as review others and be reviewed on their work.

====Menus and Nodes====
Menus (and their sub-component, Nodes) provide the foundation for navigation within the Expertiza platform. With the role of the user as input, they present to the user all possible options a user of their role can have from the top of each Expertiza screen. The Menu is critical for navigating Expertiza and exposing the correct functionality to the correct users.

====Motivation====
Testing is critical to ensuring that software is functional. A robust test suite which tests the returns of query messages and the side effects of command messages will help expedite development by quickly ensuring nothing has broken when changes are made. While manually testing the behavior of the menu is quite straight-forward, automating the underlying mechanics of the menu, which are abstract and generic, is a good best practice to prove that the system for generating menus is not broken.

===Test Plan===
In order to fully test menu.rb, we composed a total of 29 tests, 12 for the Node class and 17 for the Menu class.
'''Node'''
1. Node#setup - Node#setup appropriately sets a Node's parent_id, name, id, and label to those of the MenuItem passed to it as an argument.
2. Node#setup - When MenuItem has a ControllerAction, Node#setup(MenuItem) makes Node's controller_action_id becomes that ControllerAction's id.
3. Node#setup - When MenuItem has a ControllerAction, Node#setup(MenuItem) makes Node's url become ControllerAction's url_to_use.
4. Node#setup - When MenuItem's ControllerAction has a Controller, Node#setup(MenuItem) makes Node's site_controller_id equal to Controller's id.
5. Node#setup - When MenuItem's ControllerAction has no url_to_use, Node#setup(MenuItem) makes Node's url equal to "/#{controller.name}/#{controller_action.name}", the controller_action's name appended to the controller's name.
6. Node#setup - When MenuItem has a ContentPage, Node#setup(MenuItem) makes Node's content_page_id equal to ContentPage's id.
7. Node#setup - When MenuItem has a ContentPage, Node#setup(MenuItem) makes Node's url equal to ContentPage's name.
8. Node#site_controller - #site_controller sets the @site_controller instance variable.
9. Node#controller_action - #controller_action sets the @controller_action instance variable.
10. Node#content_page - #content_page sets the @content_page instance variable.
11. Node#add_child - #add_child updates Node's children
12. Node#add_child - #add_child adds multiple children to Node's children.
'''Menu'''
1. Menu#select - it returns if select(name) is not in @by_name
2. Menu#select - when name is in @by_name, Menu.selected is equal to name, @crumbs ends with the lowest level node and begins with the highest level node, and #selected? returns true for all nodes from the selected node to the root.
3. Menu#get_item - returns nil when id is not in @by_id
4. Menu#get_item - returns the equivalent item when id is in @by_id (item is not identical, but all components of item are the same).
5. Menu#get_menu - returns nil if level has no children.
6. Menu#get_menu - return children of a level if level has children.
7. Menu#get_menu - return all nodes except root if level is root.
8. Menu#selected - returns root if nothing has been selected.
9. Menu#selected - returns the name of the last selected menu_item.
10. Menu#selected? - if nothing has been selected, selected?(root_node) returns true.
11. Menu#selected? - if a node has been selected, selected? returns true for selected node and all its parents.
12. Menu#selected? - if there are no menu items corresponding to the permission's of the role provided to menu, selected? does not return true.
13. Menu#selected? - if MenuItem returns an empty array, selected? returns false for all input.
14. Menu#crumbs - When top-level menu item is selected, crumbs has length one.
15. Menu#crumbs - When top-level menu item is selected, crumbs has the root node's id.
16. Menu#crumbs - When bottom-level menu item is selected, crumbs has two crumbs (assuming lowest level is two).
17. Menu#crumbs - When bottom-level menu item is selected, crumbs are ordered from child to parent and all are present up to root.

===Design and Impact===

====Design====
Because of the nature of our assignment, our only design decisions were made with respect to making our Rspec tests as clean and readable as possible. We did not modify the application code itself. That being said, the Menu model is highly compositional, and it touches on MenuItem, ControllerAction, Controller, ContentPage, and Role (in addition to Node, which is in the same model). As a result, one of our main objectives was to make sure that we were transparent about all the different models which need to exist and how they interact with each other, in order for the Menu model to work.

We address this issue by neatly creating all of the mock objects that we need in 'let' blocks before the tests, and explaining any of the tricky nuances (like how MenuItems and Roles interact using the role_(user_type).yml file). We also add additional comments to some of the more complex test cases (#select) to explain why we're expecting the particular side effects we're expecting, when our 'it' and 'context' block descriptions cannot easily convey all of the complexities.

Here is a snapshot of the Node unit tests, which shows proper utilization of Rspec best practices. We define all of our necessary mock objects. We utilize short, coherent expectations. We use contexts to provide more information about the branches in a function that we are testing. We avoid binding ourselves to implementation by stubbing methods which are called in other classes.

[[File:Csc517_oss_menu_unit_tests.png]]

====Impact====
In the future, it will be very easy to test whether changes to the menu model have broken the original functionality. It will also be easy to add more tests to raise our test suite's mutant-killing rank, as we have done the hard part of defining all the mock objects and prototyping the relations they all have with each other in this initial set of tests.

E1853 write unit tests for menu

2018-10-27T16:52:49Z

Jfgiall2: Filled out test plan, design choices, and impact.

==E1853. Write Unit Tests for Menu.rb==

__TOC__

==Introduction==
===Team===
Zhewei Hu (zhu6) (mentor)
*Joe Giallo (jfgiall2)
*Senthil Sankar (ssankar9)
*Vato Maskhulia (vmaskhu)
===Task and Results===
For this project, our task was to achieve at least 90% code coverage on the menu.rb model. We ended up with 100% code coverage, and mutation testing on our test suite yielded 90.21% mutant-slaying capabilities. We believe this is a demonstration of the exemplary thoroughness of our test suite, and that these changes should be pulled in to the Expertiza master branch.
This image shows our test suite running.

[[File:Csc517_oss_project_rspec_run.png]]

This image shows an abbreviated version of /coverage/index.html page which is generate after running rspec. It shows us achieving 100% code coverage.

[[File:Csc517_oss_project_rspec_run_results.png]]

This image shows our mutation score. Of 531 mutations, we killed 479 and 52 were left alive. This is a mutation coverage of 90.21%. While we will leave it to the TA to verify this claim, examination of the living mutants shows that many of the mutations replaced lines with equivalent code (fetching a variable as opposed to just accessing it, or substituting equivalent variables for one another). Similarly, killing the remainder of the mutants would require binding our tests to implementation, to ensure that particular methods get called. As such, we believe our mutation score is quite good.

[[File:Csc517_oss_project_mutation_score.png]]

The files involved in this commit are:
* menu.rb - the model being tested. Contains the menu class and the node class.
* menu_spec.rb - the spec file for menu. Contains all of our tests.
* spec_helper.rb - we added a limit on how long tests can take to run, as one of the mutations which was generated had infinite runtime.

A video of our test suite running properly can be found here!

===Background===
====Expertiza====
[http://expertiza.ncsu.edu/ Expertiza] is an open source web application based on [http://rubyonrails.org/ Ruby on Rails] framework. It provides instructors with the ability to create, customize, and assign projects. It provides students with the ability to form teams and collaborate on these assignments, submit those assignments, as well as review others and be reviewed on their work.

====Menus and Nodes====
Menus (and their sub-component, Nodes) provide the foundation for navigation within the Expertiza platform. With the role of the user as input, they present to the user all possible options a user of their role can have from the top of each Expertiza screen. The Menu is critical for navigating Expertiza and exposing the correct functionality to the correct users.

====Motivation====
Testing is critical to ensuring that software is functional. A robust test suite which tests the returns of query messages and the side effects of command messages will help expedite development by quickly ensuring nothing has broken when changes are made. While manually testing the behavior of the menu is quite straight-forward, automating the underlying mechanics of the menu, which are abstract and generic, is a good best practice to prove that the system for generating menus is not broken.

===Test Plan===
In order to fully test menu.rb, we composed a total of 29 tests, 12 for the Node class and 17 for the Menu class.
'''Node'''
1. Node#setup - Node#setup appropriately sets a Node's parent_id, name, id, and label to those of the MenuItem passed to it as an argument.
2. Node#setup - When MenuItem has a ControllerAction, Node#setup(MenuItem) makes Node's controller_action_id becomes that ControllerAction's id.
3. Node#setup - When MenuItem has a ControllerAction, Node#setup(MenuItem) makes Node's url become ControllerAction's url_to_use.
4. Node#setup - When MenuItem's ControllerAction has a Controller, Node#setup(MenuItem) makes Node's site_controller_id equal to Controller's id.
5. Node#setup - When MenuItem's ControllerAction has no url_to_use, Node#setup(MenuItem) makes Node's url equal to "/#{controller.name}/#{controller_action.name}", the controller_action's name appended to the controller's name.
6. Node#setup - When MenuItem has a ContentPage, Node#setup(MenuItem) makes Node's content_page_id equal to ContentPage's id.
7. Node#setup - When MenuItem has a ContentPage, Node#setup(MenuItem) makes Node's url equal to ContentPage's name.
8. Node#site_controller - #site_controller sets the @site_controller instance variable.
9. Node#controller_action - #controller_action sets the @controller_action instance variable.
10. Node#content_page - #content_page sets the @content_page instance variable.
11. Node#add_child - #add_child updates Node's children
12. Node#add_child - #add_child adds multiple children to Node's children.
'''Menu'''
1. Menu#select - it returns if select(name) is not in @by_name
2. Menu#select - when name is in @by_name, Menu.selected is equal to name, @crumbs ends with the lowest level node and begins with the highest level node, and #selected? returns true for all nodes from the selected node to the root.
3. Menu#get_item - returns nil when id is not in @by_id
4. Menu#get_item - returns the equivalent item when id is in @by_id (item is not identical, but all components of item are the same).
5. Menu#get_menu - returns nil if level has no children.
6. Menu#get_menu - return children of a level if level has children.
7. Menu#get_menu - return all nodes except root if level is root.
8. Menu#selected - returns root if nothing has been selected.
9. Menu#selected - returns the name of the last selected menu_item.
10. Menu#selected? - if nothing has been selected, selected?(root_node) returns true.
11. Menu#selected? - if a node has been selected, selected? returns true for selected node and all its parents.
12. Menu#selected? - if there are no menu items corresponding to the permission's of the role provided to menu, selected? does not return true.
13. Menu#selected? - if MenuItem returns an empty array, selected? returns false for all input.
14. Menu#crumbs - When top-level menu item is selected, crumbs has length one.
15. Menu#crumbs - When top-level menu item is selected, crumbs has the root node's id.
16. Menu#crumbs - When bottom-level menu item is selected, crumbs has two crumbs (assuming lowest level is two).
17. Menu#crumbs - When bottom-level menu item is selected, crumbs are ordered from child to parent and all are present up to root.

===Design and Impact===

====Design====
Because of the nature of our assignment, our only design decisions were made with respect to making our Rspec tests as clean and readable as possible. We did not modify the application code itself. That being said, the Menu model is highly compositional, and it touches on MenuItem, ControllerAction, Controller, ContentPage, and Role (in addition to Node, which is in the same model). As a result, one of our main objectives was to make sure that we were transparent about all the different models which need to exist and how they interact with each other, in order for the Menu model to work.

We address this issue by neatly creating all of the mock objects that we need in 'let' blocks before the tests, and explaining any of the tricky nuances (like how MenuItems and Roles interact using the role_(user_type).yml file). We also add additional comments to some of the more complex test cases (#select) to explain why we're expecting the particular side effects we're expecting, when our 'it' and 'context' block descriptions cannot easily convey all of the complexities.

Here is a snapshot of the Node unit tests, which shows proper utilization of Rspec best practices. We define all of our necessary mock objects. We utilize short, coherent expectations. We use contexts to provide more information about the branches in a function that we are testing. We avoid binding ourselves to implementation by stubbing methods which are called in other classes.

[[File:Csc517_oss_menu_unit_tests.png]]

====Impact====
In the future, it will be very easy to test whether changes to the menu model have broken the original functionality. It will also be easy to add more tests to raise our test suite's mutant-killing rank, as we have done the hard part of defining all the mock objects and prototyping the relations they all have with each other in this initial set of tests.

File:Csc517 oss menu unit tests.png

2018-10-27T16:33:11Z

Jfgiall2: Snippet of unit test code, demonstrating best practices.

Snippet of unit test code, demonstrating best practices.

E1853 write unit tests for menu

2018-10-27T15:16:11Z

Jfgiall2: /* Task and Results */

E1853 write unit tests for menu

2018-10-27T15:14:32Z

Jfgiall2: Updated motivation bit to explain that menu's underlying mechanics are complicated.

E1853 write unit tests for menu

2018-10-27T15:11:21Z

Jfgiall2: Fixed image formatting, oof.