Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2021 - E2161. Merge code for role based reviewing with code for topic specific rubrics

2021-12-08T16:12:26Z

Ajshipma: /* Demonstration Videos */

This wiki page contains description of changes designed and implemented for [https://docs.google.com/document/d/1slx4HPIbgTH-psIKMSCF-HDF9brxf-FuYhzVT9ZiIrM/edit#heading=h.8s6o9jnnxj0p E2161. Merge code for role-based reviewing with code for topic-specific rubrics], a Final Project for CSC/ECE 517, Fall 2021.
== Purpose==
In CSC/ECE 517, there are Expertiza-based course projects, Mozilla-based course projects, etc. However, currently, we can only specify one kind of rubric for all kinds of course projects. This means that refactoring projects, testing projects, and Mozilla projects need to use the same rubric. We hope we could specify different rubrics to be used with different kinds of course projects.

The project objective is to merge [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2147._Role-based_reviewing#E2147._Role-based_reviewing E2147]with the existing [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2020_-_E2026._Specialized_rubrics_for_different_topic_types E2026]. While merging, we found out that the code for E2026 has already been merged on Expertiza beta branch and so now the actual implementation is to write test cases for both E2147 and E2026.

==Brief Overview of E2147 and E2026 Projects==
*[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2147._Role-based_reviewing#E2147._Role-based_reviewing E2147(Role based reviewing)]: The project objective was to develop teammate review varying by the roles that each team member has in order to evaluate the particular role that each team member has taken rather than asking a generic questionnaire which was same for all the team members previously. For eg, the instructor would create a separate teammate questionnaire for developer role and for tester role respectively.
*[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2020_-_E2026._Specialized_rubrics_for_different_topic_types E2026(Specialized rubrics for different topics)]: The project objective was to develop specialized rubrics based on project topics, previously we had same type of questionnaire for all the different types of projects. This implementation made sure that we evaluate different projects based on personalised rubrics rather than having same rubrics.

==Testing Plan==

===Test Scenarios for E2147 (Role based reviewing)===
*Only Instructor/TA/Admin should be able to create or update duties: Only the instructor/admin should be able to create or update duties. Also, the corresponding TA of the assignment should be able to create or update duties.
*Create new roles: If the assignment is role based reviewing then the instructor should be able to create new roles for the same and save it in the database using new role functionality.
*Only allow student to update duties in Student View: Only student should be able to update his duties in Student View.
*Edit existing roles: Once the new roles have been created, then the instructor should be able to edit its details such as the maximum number of each role allowed.
*Delete existing roles: The instructor should also be able to delete any roles if he wants.
*Review rubric by role: On Rubrics tab, if the instructor clicks on Review rubric by role, then the corresponding rubric roles based teammate questionnaire should appear and get saved successfully.
*Student View: If the assignment is role based assignment, then the respective students should be able to see the respective teammate questionnaire based on roles for his other team members.
*Selection of Roles: On student login, a student should be able to see the existing roles that he can take up in the project. Only the roles which are available should be shown to the student.

===Test Scenarios for E2026 (Specialized rubrics for different topics)===

As part of our implementation, we modified existing code as well as added new code. To ensure that existing functionality was not broken, and new functionality worked as expected, we used the following Test Strategy (which was also used by previous team):

===Run and pass existing RSpec Tests===
*The following existing RSpec test files have been modified and they pass as part of testing:
**spec/controllers/assignments_controller_spec.rb
**spec/controllers/questionnaires_controller_spec.rb
**spec/controllers/response_controller_spec.rb
**spec/factories/factories.rb
**spec/features/assignment_creation_spec.rb
**spec/features/quiz_spec.rb
**spec/features/staggered_deadline_spec.rb
**spec/models/assignment_form_spec.rb
**spec/models/assignment_spec.rb
**spec/models/on_the_fly_calc_spec.rb
**spec/models/response_spec.rb
**spec/models/review_response_map_spec.rb

===Develop New RSpec Tests===
*spec/helpers/duties_controller_spec.rb
*All these rspec tests passed.

== duties_controller_spec.rb ==
We have created this new test file to unit test the functionality of duties_controller.

The first step was to create mock data so that the test could run on objects created for the tests. The code below shows how the mock data was created for the specific tests that we created to ensure the functionality of the projects.

''
describe DutiesController do
let(:assignment) { build(:assignment, id: 1,course_id: 1,instructor_id: 6, due_dates: [due_date], microtask: true, staggered_deadline: true)}
let(:admin) { build(:admin) }
let(:instructor) { build(:instructor, id: 6) }
let(:instructor2) { build(:instructor, id: 66) }
let(:ta) { build(:teaching_assistant, id: 8) }
let(:duty) { build(:duty, id: 1, duty_name: "Role", max_members_for_duty: 2, assignment_id: 1) }
let(:due_date) { build(:assignment_due_date, deadline_type_id: 1) } ''

We then run the arbitrary code that is needed before each test. We include method stubs here that we can use for each test. We stub the current user to be instructor for now.

''
before(:each) do
allow(Assignment).to receive(:find).with('1').and_return(assignment)
allow(Assignment).to receive(:find).with(1).and_return(assignment)
stub_current_user(instructor, instructor.role.name, instructor.role)
allow(Duty).to receive(:find).with('1').and_return(duty)
end
''

Test scenarios for duties controller:

1) Only admin, superadmin, TA, Instructor can perform edit or update action

'' describe '#action_allowed?' do ''

The whole context that defines if the action allowed is edit or update. We do this by mocking the action to edit. We then run the arbitrary code that is needed before each test in this context. We include method stubs here that we can use for each test. We stub the current user to be instructor for now.

context 'when params action is edit or update' do
before(:each) do
controller.params = {id: '1', action: 'edit'}
end

When the current logged in user role is super admin or admin. We check if the action is allowed by stubbing the current user to admin. We then verify if the controller is able to perform the action for the current admin user

context 'when the role name of current user is super admin or admin' do
it 'allows certain action' do
stub_current_user(admin, admin.role.name, admin.role)
expect(controller.send(:action_allowed?)).to be true
end
end

When the current logged in user role is instructor of the current assignment. We check if the action is allowed by stubbing the current user to instructor. We then verify if the controller is able to perform the action for the current instructor user

context 'when current user is the instructor of current assignment' do
it 'allows certain action' do
expect(controller.send(:action_allowed?)).to be true
end
end

When the current logged in user role is the TA of the course. We check if the action is allowed by stubbing the current user to TA. We then verify if the controller is able to perform the action for the current TA user

context 'when current user is the ta of the course which current assignment belongs to' do
it 'allows certain action' do
stub_current_user(ta, ta.role.name, ta.role)
allow(TaMapping).to receive(:exists?).with(ta_id: 8, course_id: 1).and_return(true)
expect(controller.send(:action_allowed?)).to be true
end
end

When the current logged in user is the instructor of the course. We check if the action is allowed by stubbing the current user to instructor. We then verify if the controller is able to perform the action for the current instructor user

context 'when current user is the instructor of the course which current assignment belongs to' do
it 'allows certain action' do
stub_current_user(instructor2, instructor2.role.name, instructor2.role)
allow(Course).to receive(:find).with(1).and_return(double('Course', instructor_id: 66))
expect(controller.send(:action_allowed?)).to be true
end
end
end

When the parameter action is neither edit nor update, we do this by mocking the action to new(create) in the arbitrary code that runs before each test.

context 'when params action is not edit and update' do
before(:each) do
controller.params = {id: '1', action: 'new'}
end

We now check if super admin/admin/instructor/ta can perform this action which is neither edit nor update. We check if the controller can perform the action 'new' which we mocked in the before each step.

context 'when the role current user is super admin/admin/instructor/ta' do
it 'allows certain action except edit and update' do
expect(controller.send(:action_allowed?)).to be true
end
end
end
end

We also added few tests to test creation/edit/deletion of a duty.

Creation of a duty, we create a duty and check if it is saved successfully

describe '#create' do

We write a test to check if the right page is rendered after successful creation and saving of a new duty in the database. We do this by stubbing the duty object to get saved in the database, and then perform the create action. We also check if the flash message rendered matches to the expected message.

context 'when new duty can be saved successfully' do
it 'sets up a new duty and redirects to assignment#edit page' do
allow(duty).to receive(:save).and_return('OK')
params = {
id: 1,
duty: {
duty_name: 'Scrum Master',
max_members_for_duty: 2,
assignment_id: 1
}
}
post :create, params
expect(response).to redirect_to('/assignments/1/edit')
expect(flash[:notice]).to match(/Role was successfully created.*/)
end
end

Test to check if the right error message is shown if the creation of duty is failed. We stub duty to receive errors, perform the create action, and then check if the right page is rendered and also the check if the flash message matches with the expected error message.

context 'when new duty cannot be saved successfully' do
it 'shows error message and redirects to duty#new page' do
allow(duty).to receive(:errors)
params = {
id: 1,
duty: {
duty_name: 'Scrum Master',
max_members_for_duty: -1,
assignment_id: 1
}
}
post :create, params
expect(flash[:error]).to eq('Max members for duty must be greater than or equal to 1. ')
expect(response).to redirect_to('/duties/new?id=1')
end
end
end

Test to check the edit functionality of a duty.

describe '#update' do

When the duty can be edited successfully, we check if the right page is rendered. We first stub the duty active record find function to return a mocked duty object. We then try to edit the duty object by performing the update action, and then check if the right page is rendered and the flash message matches to the expected message.

context 'when duty can be found' do
it 'updates current duty and redirects to assignment#edit page' do
allow(Duty).to receive(:find).with('1').and_return(build(:duty, id: 1))
params = {
id: 1,
assignment_id: 1,
duty: {
duty_name: 'Scrum Master',
max_members_for_duty: 5,
assignment_id: 1
}
}
post :update, params
expect(response).to redirect_to('/assignments/1/edit')
expect(flash[:notice]).to match(/Role was successfully updated.*/)
end
end

When the duty cannot be updated, we check if the right error message is displayed. We stub the duty object to receive errors. And then we try to save the duty by performing the create action, which results in an unsuccessful attempt, where we check if the right page is rendered and the flash message matches with the expected one.

context 'when new duty cannot be updated successfully' do
it 'shows error message and redirects to duty#new page' do
allow(duty).to receive(:errors)
params = {
id: 1,
duty: {
duty_name: 'SM',
max_members_for_duty: 1,
assignment_id: 1
}
}
post :create, params
expect(flash[:error]).to eq('Duty name is too short (minimum is 3 characters). ')
expect(response).to redirect_to('/duties/new?id=1')
end
end
end

Now finally, we test the delete functionality of the duty. We perform the delete action, and then check if the right page is rendered after the delete action, and also check if the flash message matches with the expected one

describe '#destroy' do
context 'when duty can be found' do
it 'redirects to assignment#edit page' do
params = {id: 1, assignment_id: 1}
post :destroy, params
expect(response).to redirect_to('/assignments/1/edit')
expect(flash[:notice]).to match(/Role was successfully destroyed.*/)
end
end
end

== team_users_controller_spec.rb ==

We have added a test case in this file which tests if the action is allowed only by specific user roles. The first step was to create mock data so that the test could run on objects created for the tests. The code below shows how the mock data was created for the specific tests that we created to ensure the functionality of the projects.

''
describe TeamsUsersController do
let(:assignment) do
build(:assignment, id: 1, name: 'test assignment', instructor_id: 6, staggered_deadline: true, directory_path: 'same path',
participants: [build(:participant)], teams: [build(:assignment_team)], course_id: 1)
end
let(:assignment_form) { double('AssignmentForm', assignment: assignment) }
let(:student) { build(:student) }

before(:each) do
allow(Assignment).to receive(:find).with('1').and_return(assignment)
stub_current_user(student, student.role.name, student.role)
end
''

Then we check if the student can perform the update action for duties. We run an arbitrary code, in before each block, where we mock the action to update duties. In the inner context, we then stub the current user to be a student user, and check if the controller allows the update duties action.

''
describe '#action_allowed?' do
context 'when params action is update duties' do
before(:each) do
controller.params = {id: '1', action: 'update_duties'}
end
context 'when the role current user is student' do
it 'allows certain action' do
stub_current_user(student, student.role.name, student.role)
expect(controller.send(:action_allowed?)).to be true
end
end
end
end
''

This file also contains a test case to ensure the duties can be properly updated. The test case checks this by ensuring that the user is redirected to the student view page. just as with the previous section the first step is to mock the data by creating a team user object.

''
let(:teams_user1) {TeamsUser.new id:1, duty_id:1}
''

Then the data is actually updated and we ensure that the user is redirected to the proper place.

''
describe '#update_duties' do
it 'updates the duties for the participant' do
allow(TeamsUser).to receive(:find).with('1').and_return(teams_user1)
allow(teams_user1).to receive(:update_attribute).with(any_args).and_return('OK')
params = {
teams_user_id: '1',
teams_user: {duty_id: '1'},
participant_id: '1'
}
session = {user: stub_current_user(student, student.role.name, student.role)}
get :update_duties, params, session
expect(response).to redirect_to('/student_teams/view?student_id=1')
end
end
''

== assignment_form_spec.rb ==
The assignemnt_form_spec.rb file contains all the test files for the assignment form, which includes adding object to a queue. The first step was to create mock data so that the test could run on objects created for the tests. The code below shows how the mock data was created for the specific tests that we created to ensure the functionality of the projects.
''
let(:new_assignment_questionnaire) { build(:assignment_questionnaire) }
''
The new_assignment_questionnaire object is used for both test cases in this file. The first test case checks for when the active record cannot be found for a specific assignment id or duty id. This test case ensures no errors will happen when a user is attempting to search for this. This scenario could very easily happen and this test ensures the functionality when it cannot be found.
''
context 'when active record for assignment_questionnaire is not found for a given assignment_id and duty_id' do
it 'returns new instance of assignment_questionnaire with default values' do
allow(assignment).to receive(:questionnaire_varies_by_duty).and_return(true)
allow(AssignmentQuestionnaire).to receive(:where).with(assignment_id: 1, duty_id: anything).and_return([])
allow(AssignmentQuestionnaire).to receive(:where).with(user_id: anything, assignment_id: nil, questionnaire_id: nil).and_return([])
allow(AssignmentQuestionnaire).to receive(:new).and_return(new_assignment_questionnaire)
expect(assignment_form.assignment_questionnaire('TeammateReviewQuestionnaire', nil, nil, 1)).to eq(new_assignment_questionnaire)
end
end
''
The next next test checks when the assignment questionnaire is found given the assignment id and duty id parameters. This test is very similar to the one where the test is not found because the it searches through the active record to find the assignment questionnaire. Ensuring that this test passes will be useful because if the questionnaire cannot be returned then it will not be possible to do role based reviewing.
''
context 'when active record for assignment_questionnaire is found for a given assignment_id and duty_id' do
it 'returns new instance of assignment_questionnaire with default values' do
allow(assignment).to receive(:questionnaire_varies_by_duty).and_return(true)
allow(Questionnaire).to receive(:find).with(1).and_return(questionnaire3)
allow(AssignmentQuestionnaire).to receive(:where).with(assignment_id: 1, duty_id: 1).and_return([assignment_questionnaire2])
allow(AssignmentQuestionnaire).to receive(:where).with(user_id: anything, assignment_id: nil, questionnaire_id: nil).and_return([])
allow(AssignmentQuestionnaire).to receive(:new).and_return(new_assignment_questionnaire)
expect(assignment_form.assignment_questionnaire('TeammateReviewQuestionnaire', nil, nil, 1)).to eq(assignment_questionnaire2)
end
end
''

== duty_spec.rb ==
The main purpose of the duty_spec.rb file is to test any duty to make sure a duty can be assigned to a team member. it also tests if a duty is unavailable to a team member because the max number of people have been assigned that duty. to test this functionality the mock data is created to allow for testing of the object. The mock data is shown below which is used for all tests in this file.
''
let(:assignment) { build(:assignment, id: 1, name: 'no assgt') }
let(:participant) { build(:participant, id:1, user_id: 1) }
let(:participant2) { build(:participant, id:2, user_id: 2) }
let(:participant3) { build(:participant, id:3, user_id: 3) }
let(:user) { build(:student, id: 1, name: 'no name', fullname: 'no one', participants: [participant]) }
let(:user2) { build(:student, id: 2, name: 'no name2', fullname: 'no one2', participants: [participant2]) }
let(:user3) { build(:student, id: 3, name: 'no name3', fullname: 'no one3', participants: [participant3]) }

let(:team1) { build(:assignment_team, id: 1, name: 'no team', users: [user, user2, user3]) }
let(:sample_duty_taken) { build(:duty, id: 1, max_members_for_duty:1, assignment_id:1) }
let(:sample_duty_not_taken) { build(:duty, id: 1, max_members_for_duty:2, assignment_id:1) }

let(:team_user1) { build(:team_user, id: 1, user: user) }
let(:team_user2) { build(:team_user, id: 2, user: user2) }
let(:team_user3) { build(:team_user, id: 3, user: user3, duty_id:1) }
''
An assignment is created on which the duties can be tested. for the testing multiple users and participants are created. Finally we created team users that could be assigned duties through the duty_id field. the next step was to set up the reoccurring steps for each of the tests.
''
before(:each) do
allow(team1).to receive(:participants).and_return([participant, participant2, participant3])
allow(participant).to receive(:get_team_user).and_return(team_user1)
allow(participant2).to receive(:get_team_user).and_return(team_user2)
allow(participant3).to receive(:get_team_user).and_return(team_user3)
end
''
Finally the actual tests were implemented. The tests are fairly simple because they just need to check if the duty can be assigned or not. The first test checks to make sure a duty can be assigned to a student when the role is available. This makes sure the students will not run into a problem when the roles are assigned within the group. If the roles could not be assigned, then the specific rubrics could not be used during the reviewing phase of the project.
''
describe '#can_be_assigned?' do
context 'when users in current team want to assign roles that are available'
it 'returns true' do
expect(sample_duty_not_taken.can_be_assigned?(team1)).to be true
end
The next test case makes sure a duty cannot be assigned if there is already the max number of people assigned that role. This test case is important because if too many people are assigned that role the team dynamic will not be correct.
context 'when users in current team want to assign roles that are unavailable'
it 'returns false' do
expect(sample_duty_taken.can_be_assigned?(team1)).to be false
end
''

== teammate_review_response_map_spec.rb ==
This Rspec testing file tests that a specific questionnaire can be returned when the student has a role assigned to them. This is needed for the role based reviewing because when one student goes to review another they must get the correct questionnaire for their role. We tested this functionality as well as the inverse, when the role could not be found. initially we created the mock data for testing which is shown below.
''
let(:questionnaire) { Questionnaire.new name: "abc", private: 0, min_question_score: 0, max_question_score: 10, instructor_id: 1234 }
let(:assignment) { build(:assignment, id: 1, name: 'no assgt', is_duty_based_assignment: true, questionnaires: [questionnaire]) }
let(:assignment_questionnaire1) { build(:assignment_questionnaire, id: 1, assignment_id: 1, questionnaire_id: 2, duty_id: 1) }
let(:participant) { build(:participant, id: 1, user_id: 6, assignment: assignment) }
let(:teammate_review_response_map) { TeammateReviewResponseMap.new reviewer: participant, reviewer_is_team: true, assignment:assignment }
''
This step created the review response map that we would be testing as well as and assignment which contained a questionnaire. The next step was to actually test the data. First we decided to ensure that the correct questionnaire was returned with the following test. It compares the returned questionnaire with the one we know is correct.
''
it 'returns questionnaire specific to a duty' do
allow(AssignmentQuestionnaire).to receive(:where).with(assignment_id: 1, duty_id: 1).and_return([assignment_questionnaire1])
allow(Questionnaire).to receive(:find).with(assignment_questionnaire1.questionnaire_id).and_return(questionnaire)
expect(teammate_review_response_map.questionnaire_by_duty(1)).to eq questionnaire
end
''
Finally we added the inverse for when there was an error returning the questionnaire. in this case the program should return the default questionnaire.
''
it 'returns default questionnaire when no questionnaire is found for duty' do
allow(AssignmentQuestionnaire).to receive(:where).with(assignment_id: 1, duty_id: 1).and_return([])
allow(assignment.questionnaires).to receive(:find_by).with(type: 'TeammateReviewQuestionnaire').and_return(questionnaire)
expect(teammate_review_response_map.questionnaire_by_duty(1)).to eq questionnaire
end
''

== Manual Testing in Expertiza UI ==
E2161
Here we describe manual UI Testing steps to edit an existing assignment to allow it have to specialized rubrics for different topic types. These steps are also shown in recorded demo video.
*Login to Expertiza using instructor account (For testing, username: '''instructor6''', password: '''password''')
*Click on Manage > Assignments
*Click on Edit option for any assignment, you should get following view. Make sure '''Has topics?''' box is checked.
[[File:Assignment edit 3.png]]
*Click on Rubrics tab. You will see 2 checkboxes ('''Review rubric varies by round?''', '''Review rubric varies by topic?''')
*Check the box for '''Review rubric varies by topic?'''
*Go to Topics tab and verify that there is dropdown menu beside each Topic.
*Select a rubric from dropdown menu, and click '''Save'''
[[File:Topics rubric 2.png]]
*Go back to Home, and select the same assignment to edit. When you click on Topics tab, you should see the rubric you had selected.

==Demonstration Videos==
* Functionality Walk-through: https://youtu.be/FRt3ZyofGf4
* RSpec Testing Video: https://youtu.be/PdlbX5Dlgnw

==Deployments and Pull Requests==
* Our version of expertiza is deployed at : http://152.7.176.120:8080
* Our github repository is : https://github.com/namanshrimali/expertiza/tree/beta
* Our Pull Request : https://github.com/expertiza/expertiza/pull/2137
==Team Information==
* Naman Shrimali
* Kanchan Rawat
* Subodh Thota
* Andrew Shipman
Mentor : Prof. Edward F. Gehringer

CSC/ECE 517 Fall 2021 - E2161. Merge code for role based reviewing with code for topic specific rubrics

2021-11-29T21:27:47Z

Ajshipma:

This wiki page contains description of changes designed and implemented for [https://docs.google.com/document/d/1slx4HPIbgTH-psIKMSCF-HDF9brxf-FuYhzVT9ZiIrM/edit#heading=h.8s6o9jnnxj0p E2161. Merge code for role-based reviewing with code for topic-specific rubrics], a Final Project for CSC/ECE 517, Fall 2021.
== Purpose==
In CSC/ECE 517, there are Expertiza-based course projects, Mozilla-based course projects, etc. However, currently, we can only specify one kind of rubric for all kinds of course projects. This means that refactoring projects, testing projects, and Mozilla projects need to use the same rubric. We hope we could specify different rubrics to be used with different kinds of course projects.

The project objective is to merge E2147-https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2147._Role-based_reviewing#E2147._Role-based_reviewing with the existing E2026-https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2020_-_E2026._Specialized_rubrics_for_different_topic_types. While merging, we found out that the code for E2026 has already been merged on Expertiza beta branch and so now the actual implementation is to write test cases for both E2147 and E2026.

==Brief Overview of E2147 and E2026 Projects==
*E2147(Role based reviewing): The project objective was to develop teammate review varying by the roles that each team member has in order to evaluate the particular role that each team member has taken rather than asking a generic questionnaire which was same for all the team members previously. For eg, the instructor would create a separate teammate questionnaire for developer role and for tester role respectively.
*E2026(Specialized rubrics for different topics): The project objective was to develop specialized rubrics based on project topics, previously we had same type of questionnaire for all the different types of projects. This implementation made sure that we evaluate different projects based on personalised rubrics rather than having same rubrics.

==Testing Plan==

===Test Scenarios for E2147 (Role based reviewing)===
*Only Instructor/TA/Admin should be able to create or update duties: Only the instructor/admin should be able to create or update duties. Also, the corresponding TA of the assignment should be able to create or update duties.
*Create new roles: If the assignment is role based reviewing then the instructor should be able to create new roles for the same and save it in the database using new role functionality.
*Only allow student to update duties in Student View: Only student should be able to update his duties in Student View.
*Edit existing roles: Once the new roles have been created, then the instructor should be able to edit its details such as the maximum number of each role allowed.
*Delete existing roles: The instructor should also be able to delete any roles if he wants.
*Review rubric by role: On Rubrics tab, if the instructor clicks on Review rubric by role, then the corresponding rubric roles based teammate questionnaire should appear and get saved successfully.
*Student View: If the assignment is role based assignment, then the respective students should be able to see the respective teammate questionnaire based on roles for his other team members.
*Selection of Roles: On student login, a student should be able to see the existing roles that he can take up in the project. Only the roles which are available should be shown to the student.

===Test Scenarios for E2026 (Specialized rubrics for different topics)===

As part of our implementation, we modified existing code as well as added new code. To ensure that existing functionality was not broken, and new functionality worked as expected, we used the following Test Strategy (which was also used by previous team):

===Run and pass existing RSpec Tests===
*The following existing RSpec test files have been modified and they pass as part of testing:
**spec/controllers/assignments_controller_spec.rb
**spec/controllers/questionnaires_controller_spec.rb
**spec/controllers/response_controller_spec.rb
**spec/factories/factories.rb
**spec/features/assignment_creation_spec.rb
**spec/features/quiz_spec.rb
**spec/features/staggered_deadline_spec.rb
**spec/models/assignment_form_spec.rb
**spec/models/assignment_spec.rb
**spec/models/on_the_fly_calc_spec.rb
**spec/models/response_spec.rb
**spec/models/review_response_map_spec.rb

===Develop New RSpec Tests===
*spec/helpers/duties_controller_spec.rb
*All these rspec tests passed.

== duties_controller_spec.rb ==
We have created this new test file to unit test the functionality of duties_controller.

The first step was to create mock data so that the test could run on objects created for the tests. The code below shows how the mock data was created for the specific tests that we created to ensure the functionality of the projects.

''
describe DutiesController do
let(:assignment) { build(:assignment, id: 1,course_id: 1,instructor_id: 6, due_dates: [due_date], microtask: true, staggered_deadline: true)}
let(:admin) { build(:admin) }
let(:instructor) { build(:instructor, id: 6) }
let(:instructor2) { build(:instructor, id: 66) }
let(:ta) { build(:teaching_assistant, id: 8) }
let(:duty) { build(:duty, id: 1, duty_name: "Role", max_members_for_duty: 2, assignment_id: 1) }
let(:due_date) { build(:assignment_due_date, deadline_type_id: 1) } ''

We then run the arbitrary code that is needed before each test. We include method stubs here that we can use for each test. We stub the current user to be instructor for now.

''
before(:each) do
allow(Assignment).to receive(:find).with('1').and_return(assignment)
allow(Assignment).to receive(:find).with(1).and_return(assignment)
stub_current_user(instructor, instructor.role.name, instructor.role)
allow(Duty).to receive(:find).with('1').and_return(duty)
end
''

Test scenarios for duties controller:

1) Only admin, superadmin, TA, Instructor can perform edit or update action

'' describe '#action_allowed?' do ''

The whole context that defines if the action allowed is edit or update. We do this by mocking the action to edit. We then run the arbitrary code that is needed before each test in this context. We include method stubs here that we can use for each test. We stub the current user to be instructor for now.

context 'when params action is edit or update' do
before(:each) do
controller.params = {id: '1', action: 'edit'}
end

When the current logged in user role is super admin or admin. We check if the action is allowed by stubbing the current user to admin. We then verify if the controller is able to perform the action for the current admin user

context 'when the role name of current user is super admin or admin' do
it 'allows certain action' do
stub_current_user(admin, admin.role.name, admin.role)
expect(controller.send(:action_allowed?)).to be true
end
end

When the current logged in user role is instructor of the current assignment. We check if the action is allowed by stubbing the current user to instructor. We then verify if the controller is able to perform the action for the current instructor user

context 'when current user is the instructor of current assignment' do
it 'allows certain action' do
expect(controller.send(:action_allowed?)).to be true
end
end

When the current logged in user role is the TA of the course. We check if the action is allowed by stubbing the current user to TA. We then verify if the controller is able to perform the action for the current TA user

context 'when current user is the ta of the course which current assignment belongs to' do
it 'allows certain action' do
stub_current_user(ta, ta.role.name, ta.role)
allow(TaMapping).to receive(:exists?).with(ta_id: 8, course_id: 1).and_return(true)
expect(controller.send(:action_allowed?)).to be true
end
end

When the current logged in user is the instructor of the course. We check if the action is allowed by stubbing the current user to instructor. We then verify if the controller is able to perform the action for the current instructor user

context 'when current user is the instructor of the course which current assignment belongs to' do
it 'allows certain action' do
stub_current_user(instructor2, instructor2.role.name, instructor2.role)
allow(Course).to receive(:find).with(1).and_return(double('Course', instructor_id: 66))
expect(controller.send(:action_allowed?)).to be true
end
end
end

When the parameter action is neither edit nor update, we do this by mocking the action to new(create) in the arbitrary code that runs before each test.

context 'when params action is not edit and update' do
before(:each) do
controller.params = {id: '1', action: 'new'}
end

We now check if super admin/admin/instructor/ta can perform this action which is neither edit nor update. We check if the controller can perform the action 'new' which we mocked in the before each step.

context 'when the role current user is super admin/admin/instructor/ta' do
it 'allows certain action except edit and update' do
expect(controller.send(:action_allowed?)).to be true
end
end
end
end

We also added few tests to test creation/edit/deletion of a duty.

Creation of a duty, we create a duty and check if it is saved successfully

describe '#create' do

We write a test to check if the right page is rendered after successful creation and saving of a new duty in the database. We do this by stubbing the duty object to get saved in the database, and then perform the create action. We also check if the flash message rendered matches to the expected message.

context 'when new duty can be saved successfully' do
it 'sets up a new duty and redirects to assignment#edit page' do
allow(duty).to receive(:save).and_return('OK')
params = {
id: 1,
duty: {
duty_name: 'Scrum Master',
max_members_for_duty: 2,
assignment_id: 1
}
}
post :create, params
expect(response).to redirect_to('/assignments/1/edit')
expect(flash[:notice]).to match(/Role was successfully created.*/)
end
end

Test to check if the right error message is shown if the creation of duty is failed. We stub duty to receive errors, perform the create action, and then check if the right page is rendered and also the check if the flash message matches with the expected error message.

context 'when new duty cannot be saved successfully' do
it 'shows error message and redirects to duty#new page' do
allow(duty).to receive(:errors)
params = {
id: 1,
duty: {
duty_name: 'Scrum Master',
max_members_for_duty: -1,
assignment_id: 1
}
}
post :create, params
expect(flash[:error]).to eq('Max members for duty must be greater than or equal to 1. ')
expect(response).to redirect_to('/duties/new?id=1')
end
end
end

Test to check the edit functionality of a duty.

describe '#update' do

When the duty can be edited successfully, we check if the right page is rendered. We first stub the duty active record find function to return a mocked duty object. We then try to edit the duty object by performing the update action, and then check if the right page is rendered and the flash message matches to the expected message.

context 'when duty can be found' do
it 'updates current duty and redirects to assignment#edit page' do
allow(Duty).to receive(:find).with('1').and_return(build(:duty, id: 1))
params = {
id: 1,
assignment_id: 1,
duty: {
duty_name: 'Scrum Master',
max_members_for_duty: 5,
assignment_id: 1
}
}
post :update, params
expect(response).to redirect_to('/assignments/1/edit')
expect(flash[:notice]).to match(/Role was successfully updated.*/)
end
end

When the duty cannot be updated, we check if the right error message is displayed. We stub the duty object to receive errors. And then we try to save the duty by performing the create action, which results in an unsuccessful attempt, where we check if the right page is rendered and the flash message matches with the expected one.

context 'when new duty cannot be updated successfully' do
it 'shows error message and redirects to duty#new page' do
allow(duty).to receive(:errors)
params = {
id: 1,
duty: {
duty_name: 'SM',
max_members_for_duty: 1,
assignment_id: 1
}
}
post :create, params
expect(flash[:error]).to eq('Duty name is too short (minimum is 3 characters). ')
expect(response).to redirect_to('/duties/new?id=1')
end
end
end

Now finally, we test the delete functionality of the duty. We perform the delete action, and then check if the right page is rendered after the delete action, and also check if the flash message matches with the expected one

describe '#destroy' do
context 'when duty can be found' do
it 'redirects to assignment#edit page' do
params = {id: 1, assignment_id: 1}
post :destroy, params
expect(response).to redirect_to('/assignments/1/edit')
expect(flash[:notice]).to match(/Role was successfully destroyed.*/)
end
end
end

== team_users_controller_spec.rb ==

We have added a test case in this file which tests if the action is allowed only by specific user roles. The first step was to create mock data so that the test could run on objects created for the tests. The code below shows how the mock data was created for the specific tests that we created to ensure the functionality of the projects.

''
describe TeamsUsersController do
let(:assignment) do
build(:assignment, id: 1, name: 'test assignment', instructor_id: 6, staggered_deadline: true, directory_path: 'same path',
participants: [build(:participant)], teams: [build(:assignment_team)], course_id: 1)
end
let(:assignment_form) { double('AssignmentForm', assignment: assignment) }
let(:student) { build(:student) }

before(:each) do
allow(Assignment).to receive(:find).with('1').and_return(assignment)
stub_current_user(student, student.role.name, student.role)
end
''

Then we check if the student can perform the update action for duties. We run an arbitrary code, in before each block, where we mock the action to update duties. In the inner context, we then stub the current user to be a student user, and check if the controller allows the update duties action.

''
describe '#action_allowed?' do
context 'when params action is update duties' do
before(:each) do
controller.params = {id: '1', action: 'update_duties'}
end
context 'when the role current user is student' do
it 'allows certain action' do
stub_current_user(student, student.role.name, student.role)
expect(controller.send(:action_allowed?)).to be true
end
end
end
end
''

This file also contains a test case to ensure the duties can be properly updated. The test case checks this by ensuring that the user is redirected to the student view page. just as with the previous section the first step is to mock the data by creating a team user object.

''
let(:teams_user1) {TeamsUser.new id:1, duty_id:1}
''

Then the data is actually updated and we ensure that the user is redirected to the proper place.

''
describe '#update_duties' do
it 'updates the duties for the participant' do
allow(TeamsUser).to receive(:find).with('1').and_return(teams_user1)
allow(teams_user1).to receive(:update_attribute).with(any_args).and_return('OK')
params = {
teams_user_id: '1',
teams_user: {duty_id: '1'},
participant_id: '1'
}
session = {user: stub_current_user(student, student.role.name, student.role)}
get :update_duties, params, session
expect(response).to redirect_to('/student_teams/view?student_id=1')
end
end
''

== assignment_form_spec.rb ==
The assignemnt_form_spec.rb file contains all the test files for the assignment form, which includes adding object to a queue. The first step was to create mock data so that the test could run on objects created for the tests. The code below shows how the mock data was created for the specific tests that we created to ensure the functionality of the projects.
''
let(:new_assignment_questionnaire) { build(:assignment_questionnaire) }
''
The new_assignment_questionnaire object is used for both test cases in this file. The first test case checks for when the active record cannot be found for a specific assignment id or duty id. This test case ensures no errors will happen when a user is attempting to search for this. This scenario could very easily happen and this test ensures the functionality when it cannot be found.
''
context 'when active record for assignment_questionnaire is not found for a given assignment_id and duty_id' do
it 'returns new instance of assignment_questionnaire with default values' do
allow(assignment).to receive(:questionnaire_varies_by_duty).and_return(true)
allow(AssignmentQuestionnaire).to receive(:where).with(assignment_id: 1, duty_id: anything).and_return([])
allow(AssignmentQuestionnaire).to receive(:where).with(user_id: anything, assignment_id: nil, questionnaire_id: nil).and_return([])
allow(AssignmentQuestionnaire).to receive(:new).and_return(new_assignment_questionnaire)
expect(assignment_form.assignment_questionnaire('TeammateReviewQuestionnaire', nil, nil, 1)).to eq(new_assignment_questionnaire)
end
end
''
The next next test checks when the assignment questionnaire is found given the assignment id and duty id parameters. This test is very similar to the one where the test is not found because the it searches through the active record to find the assignment questionnaire. Ensuring that this test passes will be useful because if the questionnaire cannot be returned then it will not be possible to do role based reviewing.
''
context 'when active record for assignment_questionnaire is found for a given assignment_id and duty_id' do
it 'returns new instance of assignment_questionnaire with default values' do
allow(assignment).to receive(:questionnaire_varies_by_duty).and_return(true)
allow(Questionnaire).to receive(:find).with(1).and_return(questionnaire3)
allow(AssignmentQuestionnaire).to receive(:where).with(assignment_id: 1, duty_id: 1).and_return([assignment_questionnaire2])
allow(AssignmentQuestionnaire).to receive(:where).with(user_id: anything, assignment_id: nil, questionnaire_id: nil).and_return([])
allow(AssignmentQuestionnaire).to receive(:new).and_return(new_assignment_questionnaire)
expect(assignment_form.assignment_questionnaire('TeammateReviewQuestionnaire', nil, nil, 1)).to eq(assignment_questionnaire2)
end
end
''

== duty_spec.rb ==
The main purpose of the duty_spec.rb file is to test any duty to make sure a duty can be assigned to a team member. it also tests if a duty is unavailable to a team member because the max number of people have been assigned that duty. to test this functionality the mock data is created to allow for testing of the object. The mock data is shown below which is used for all tests in this file.
''
let(:assignment) { build(:assignment, id: 1, name: 'no assgt') }
let(:participant) { build(:participant, id:1, user_id: 1) }
let(:participant2) { build(:participant, id:2, user_id: 2) }
let(:participant3) { build(:participant, id:3, user_id: 3) }
let(:user) { build(:student, id: 1, name: 'no name', fullname: 'no one', participants: [participant]) }
let(:user2) { build(:student, id: 2, name: 'no name2', fullname: 'no one2', participants: [participant2]) }
let(:user3) { build(:student, id: 3, name: 'no name3', fullname: 'no one3', participants: [participant3]) }

let(:team1) { build(:assignment_team, id: 1, name: 'no team', users: [user, user2, user3]) }
let(:sample_duty_taken) { build(:duty, id: 1, max_members_for_duty:1, assignment_id:1) }
let(:sample_duty_not_taken) { build(:duty, id: 1, max_members_for_duty:2, assignment_id:1) }

let(:team_user1) { build(:team_user, id: 1, user: user) }
let(:team_user2) { build(:team_user, id: 2, user: user2) }
let(:team_user3) { build(:team_user, id: 3, user: user3, duty_id:1) }
''
An assignment is created on which the duties can be tested. for the testing multiple users and participants are created. Finally we created team users that could be assigned duties through the duty_id field. the next step was to set up the reoccurring steps for each of the tests.
''
before(:each) do
allow(team1).to receive(:participants).and_return([participant, participant2, participant3])
allow(participant).to receive(:get_team_user).and_return(team_user1)
allow(participant2).to receive(:get_team_user).and_return(team_user2)
allow(participant3).to receive(:get_team_user).and_return(team_user3)
end
''
Finally the actual tests were implemented. The tests are fairly simple because they just need to check if the duty can be assigned or not. The first test checks to make sure a duty can be assigned to a student when the role is available. This makes sure the students will not run into a problem when the roles are assigned within the group. If the roles could not be assigned, then the specific rubrics could not be used during the reviewing phase of the project.
''
describe '#can_be_assigned?' do
context 'when users in current team want to assign roles that are available'
it 'returns true' do
expect(sample_duty_not_taken.can_be_assigned?(team1)).to be true
end
The next test case makes sure a duty cannot be assigned if there is already the max number of people assigned that role. This test case is important because if too many people are assigned that role the team dynamic will not be correct.
context 'when users in current team want to assign roles that are unavailable'
it 'returns false' do
expect(sample_duty_taken.can_be_assigned?(team1)).to be false
end
''

== teammate_review_response_map_spec.rb ==
This Rspec testing file tests that a specific questionnaire can be returned when the student has a role assigned to them. This is needed for the role based reviewing because when one student goes to review another they must get the correct questionnaire for their role. We tested this functionality as well as the inverse, when the role could not be found. initially we created the mock data for testing which is shown below.
''
let(:questionnaire) { Questionnaire.new name: "abc", private: 0, min_question_score: 0, max_question_score: 10, instructor_id: 1234 }
let(:assignment) { build(:assignment, id: 1, name: 'no assgt', is_duty_based_assignment: true, questionnaires: [questionnaire]) }
let(:assignment_questionnaire1) { build(:assignment_questionnaire, id: 1, assignment_id: 1, questionnaire_id: 2, duty_id: 1) }
let(:participant) { build(:participant, id: 1, user_id: 6, assignment: assignment) }
let(:teammate_review_response_map) { TeammateReviewResponseMap.new reviewer: participant, reviewer_is_team: true, assignment:assignment }
''
This step created the review response map that we would be testing as well as and assignment which contained a questionnaire. The next step was to actually test the data. First we decided to ensure that the correct questionnaire was returned with the following test. It compares the returned questionnaire with the one we know is correct.
''
it 'returns questionnaire specific to a duty' do
allow(AssignmentQuestionnaire).to receive(:where).with(assignment_id: 1, duty_id: 1).and_return([assignment_questionnaire1])
allow(Questionnaire).to receive(:find).with(assignment_questionnaire1.questionnaire_id).and_return(questionnaire)
expect(teammate_review_response_map.questionnaire_by_duty(1)).to eq questionnaire
end
''
Finally we added the inverse for when there was an error returning the questionnaire. in this case the program should return the default questionnaire.
''
it 'returns default questionnaire when no questionnaire is found for duty' do
allow(AssignmentQuestionnaire).to receive(:where).with(assignment_id: 1, duty_id: 1).and_return([])
allow(assignment.questionnaires).to receive(:find_by).with(type: 'TeammateReviewQuestionnaire').and_return(questionnaire)
expect(teammate_review_response_map.questionnaire_by_duty(1)).to eq questionnaire
end
''

Link to Rspec testing video: https://youtu.be/CVRYYNh49Bk
== Manual Testing in Expertiza UI ==
Here we describe manual UI Testing steps to edit an existing assignment to allow it have to specialized rubrics for different topic types. These steps are also shown in recorded demo video.
*Login to Expertiza using instructor account (For testing, username: '''instructor6''', password: '''password''')
*Click on Manage > Assignments
*Click on Edit option for any assignment, you should get following view. Make sure '''Has topics?''' box is checked.
[[File:Assignment edit 3.png]]
*Click on Rubrics tab. You will see 2 checkboxes ('''Review rubric varies by round?''', '''Review rubric varies by topic?''')
*Check the box for '''Review rubric varies by topic?'''
*Go to Topics tab and verify that there is dropdown menu beside each Topic.
*Select a rubric from dropdown menu, and click '''Save'''
[[File:Topics rubric 2.png]]
*Go back to Home, and select the same assignment to edit. When you click on Topics tab, you should see the rubric you had selected.

==Team Information==
* Naman Shrimali
* Kanchan Rawat
* Subodh Thota
* Andrew Shipman
Mentor : Prof. Edward F. Gehringer

CSC/ECE 517 Fall 2021 - E2161. Merge code for role based reviewing with code for topic specific rubrics

2021-11-29T21:23:33Z

Ajshipma:

This wiki page contains description of changes designed and implemented for [https://docs.google.com/document/d/1slx4HPIbgTH-psIKMSCF-HDF9brxf-FuYhzVT9ZiIrM/edit#heading=h.8s6o9jnnxj0p E2161. Merge code for role-based reviewing with code for topic-specific rubrics], a Final Project for CSC/ECE 517, Fall 2021.
== Purpose==
In CSC/ECE 517, there are Expertiza-based course projects, Mozilla-based course projects, etc. However, currently, we can only specify one kind of rubric for all kinds of course projects. This means that refactoring projects, testing projects, and Mozilla projects need to use the same rubric. We hope we could specify different rubrics to be used with different kinds of course projects.

The project objective is to merge E2147-https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2147._Role-based_reviewing#E2147._Role-based_reviewing with the existing E2026-https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2020_-_E2026._Specialized_rubrics_for_different_topic_types. While merging, we found out that the code for E2026 has already been merged on Expertiza beta branch and so now the actual implementation is to write test cases for both E2147 and E2026.

==Brief Overview of E2147 and E2026 Projects==
*E2147(Role based reviewing): The project objective was to develop teammate review varying by the roles that each team member has in order to evaluate the particular role that each team member has taken rather than asking a generic questionnaire which was same for all the team members previously. For eg, the instructor would create a separate teammate questionnaire for developer role and for tester role respectively.
*E2026(Specialized rubrics for different topics): The project objective was to develop specialized rubrics based on project topics, previously we had same type of questionnaire for all the different types of projects. This implementation made sure that we evaluate different projects based on personalised rubrics rather than having same rubrics.

==Testing Plan==

===Test Scenarios for E2147 (Role based reviewing)===
*Only Instructor/TA/Admin should be able to create or update duties: Only the instructor/admin should be able to create or update duties. Also, the corresponding TA of the assignment should be able to create or update duties.
*Create new roles: If the assignment is role based reviewing then the instructor should be able to create new roles for the same and save it in the database using new role functionality.
*Only allow student to update duties in Student View: Only student should be able to update his duties in Student View.
*Edit existing roles: Once the new roles have been created, then the instructor should be able to edit its details such as the maximum number of each role allowed.
*Delete existing roles: The instructor should also be able to delete any roles if he wants.
*Review rubric by role: On Rubrics tab, if the instructor clicks on Review rubric by role, then the corresponding rubric roles based teammate questionnaire should appear and get saved successfully.
*Student View: If the assignment is role based assignment, then the respective students should be able to see the respective teammate questionnaire based on roles for his other team members.
*Selection of Roles: On student login, a student should be able to see the existing roles that he can take up in the project. Only the roles which are available should be shown to the student.

===Test Scenarios for E2026 (Specialized rubrics for different topics)===

As part of our implementation, we modified existing code as well as added new code. To ensure that existing functionality was not broken, and new functionality worked as expected, we used the following Test Strategy (which was also used by previous team):

===Run and pass existing RSpec Tests===
*The following existing RSpec test files have been modified and they pass as part of testing:
**spec/controllers/assignments_controller_spec.rb
**spec/controllers/questionnaires_controller_spec.rb
**spec/controllers/response_controller_spec.rb
**spec/factories/factories.rb
**spec/features/assignment_creation_spec.rb
**spec/features/quiz_spec.rb
**spec/features/staggered_deadline_spec.rb
**spec/models/assignment_form_spec.rb
**spec/models/assignment_spec.rb
**spec/models/on_the_fly_calc_spec.rb
**spec/models/response_spec.rb
**spec/models/review_response_map_spec.rb

===Develop New RSpec Tests===
*spec/helpers/duties_controller_spec.rb
*All these rspec tests passed.

== duties_controller_spec.rb ==
We have created this new test file to unit test the functionality of duties_controller.

The first step was to create mock data so that the test could run on objects created for the tests. The code below shows how the mock data was created for the specific tests that we created to ensure the functionality of the projects.

''
describe DutiesController do
let(:assignment) { build(:assignment, id: 1,course_id: 1,instructor_id: 6, due_dates: [due_date], microtask: true, staggered_deadline: true)}
let(:admin) { build(:admin) }
let(:instructor) { build(:instructor, id: 6) }
let(:instructor2) { build(:instructor, id: 66) }
let(:ta) { build(:teaching_assistant, id: 8) }
let(:duty) { build(:duty, id: 1, duty_name: "Role", max_members_for_duty: 2, assignment_id: 1) }
let(:due_date) { build(:assignment_due_date, deadline_type_id: 1) } ''

We then run the arbitrary code that is needed before each test. We include method stubs here that we can use for each test. We stub the current user to be instructor for now.

''
before(:each) do
allow(Assignment).to receive(:find).with('1').and_return(assignment)
allow(Assignment).to receive(:find).with(1).and_return(assignment)
stub_current_user(instructor, instructor.role.name, instructor.role)
allow(Duty).to receive(:find).with('1').and_return(duty)
end
''

Test scenarios for duties controller:

1) Only admin, superadmin, TA, Instructor can perform edit or update action

'' describe '#action_allowed?' do ''

The whole context that defines if the action allowed is edit or update. We do this by mocking the action to edit. We then run the arbitrary code that is needed before each test in this context. We include method stubs here that we can use for each test. We stub the current user to be instructor for now.

context 'when params action is edit or update' do
before(:each) do
controller.params = {id: '1', action: 'edit'}
end

When the current logged in user role is super admin or admin. We check if the action is allowed by stubbing the current user to admin. We then verify if the controller is able to perform the action for the current admin user

context 'when the role name of current user is super admin or admin' do
it 'allows certain action' do
stub_current_user(admin, admin.role.name, admin.role)
expect(controller.send(:action_allowed?)).to be true
end
end

When the current logged in user role is instructor of the current assignment. We check if the action is allowed by stubbing the current user to instructor. We then verify if the controller is able to perform the action for the current instructor user

context 'when current user is the instructor of current assignment' do
it 'allows certain action' do
expect(controller.send(:action_allowed?)).to be true
end
end

When the current logged in user role is the TA of the course. We check if the action is allowed by stubbing the current user to TA. We then verify if the controller is able to perform the action for the current TA user

context 'when current user is the ta of the course which current assignment belongs to' do
it 'allows certain action' do
stub_current_user(ta, ta.role.name, ta.role)
allow(TaMapping).to receive(:exists?).with(ta_id: 8, course_id: 1).and_return(true)
expect(controller.send(:action_allowed?)).to be true
end
end

When the current logged in user is the instructor of the course. We check if the action is allowed by stubbing the current user to instructor. We then verify if the controller is able to perform the action for the current instructor user

context 'when current user is the instructor of the course which current assignment belongs to' do
it 'allows certain action' do
stub_current_user(instructor2, instructor2.role.name, instructor2.role)
allow(Course).to receive(:find).with(1).and_return(double('Course', instructor_id: 66))
expect(controller.send(:action_allowed?)).to be true
end
end
end

When the parameter action is neither edit nor update, we do this by mocking the action to new(create) in the arbitrary code that runs before each test.

context 'when params action is not edit and update' do
before(:each) do
controller.params = {id: '1', action: 'new'}
end

We now check if super admin/admin/instructor/ta can perform this action which is neither edit nor update. We check if the controller can perform the action 'new' which we mocked in the before each step.

context 'when the role current user is super admin/admin/instructor/ta' do
it 'allows certain action except edit and update' do
expect(controller.send(:action_allowed?)).to be true
end
end
end
end

We also added few tests to test creation/edit/deletion of a duty.

Creation of a duty, we create a duty and check if it is saved successfully

describe '#create' do

We write a test to check if the right page is rendered after successful creation and saving of a new duty in the database. We do this by stubbing the duty object to get saved in the database, and then perform the create action. We also check if the flash message rendered matches to the expected message.

context 'when new duty can be saved successfully' do
it 'sets up a new duty and redirects to assignment#edit page' do
allow(duty).to receive(:save).and_return('OK')
params = {
id: 1,
duty: {
duty_name: 'Scrum Master',
max_members_for_duty: 2,
assignment_id: 1
}
}
post :create, params
expect(response).to redirect_to('/assignments/1/edit')
expect(flash[:notice]).to match(/Role was successfully created.*/)
end
end

Test to check if the right error message is shown if the creation of duty is failed. We stub duty to receive errors, perform the create action, and then check if the right page is rendered and also the check if the flash message matches with the expected error message.

context 'when new duty cannot be saved successfully' do
it 'shows error message and redirects to duty#new page' do
allow(duty).to receive(:errors)
params = {
id: 1,
duty: {
duty_name: 'Scrum Master',
max_members_for_duty: -1,
assignment_id: 1
}
}
post :create, params
expect(flash[:error]).to eq('Max members for duty must be greater than or equal to 1. ')
expect(response).to redirect_to('/duties/new?id=1')
end
end
end

Test to check the edit functionality of a duty.

describe '#update' do

When the duty can be edited successfully, we check if the right page is rendered. We first stub the duty active record find function to return a mocked duty object. We then try to edit the duty object by performing the update action, and then check if the right page is rendered and the flash message matches to the expected message.

context 'when duty can be found' do
it 'updates current duty and redirects to assignment#edit page' do
allow(Duty).to receive(:find).with('1').and_return(build(:duty, id: 1))
params = {
id: 1,
assignment_id: 1,
duty: {
duty_name: 'Scrum Master',
max_members_for_duty: 5,
assignment_id: 1
}
}
post :update, params
expect(response).to redirect_to('/assignments/1/edit')
expect(flash[:notice]).to match(/Role was successfully updated.*/)
end
end

When the duty cannot be updated, we check if the right error message is displayed. We stub the duty object to receive errors. And then we try to save the duty by performing the create action, which results in an unsuccessful attempt, where we check if the right page is rendered and the flash message matches with the expected one.

context 'when new duty cannot be updated successfully' do
it 'shows error message and redirects to duty#new page' do
allow(duty).to receive(:errors)
params = {
id: 1,
duty: {
duty_name: 'SM',
max_members_for_duty: 1,
assignment_id: 1
}
}
post :create, params
expect(flash[:error]).to eq('Duty name is too short (minimum is 3 characters). ')
expect(response).to redirect_to('/duties/new?id=1')
end
end
end

Now finally, we test the delete functionality of the duty. We perform the delete action, and then check if the right page is rendered after the delete action, and also check if the flash message matches with the expected one

describe '#destroy' do
context 'when duty can be found' do
it 'redirects to assignment#edit page' do
params = {id: 1, assignment_id: 1}
post :destroy, params
expect(response).to redirect_to('/assignments/1/edit')
expect(flash[:notice]).to match(/Role was successfully destroyed.*/)
end
end
end

== team_users_controller_spec.rb ==

We have added a test case in this file which tests if the action is allowed only by specific user roles. The first step was to create mock data so that the test could run on objects created for the tests. The code below shows how the mock data was created for the specific tests that we created to ensure the functionality of the projects.

''
describe TeamsUsersController do
let(:assignment) do
build(:assignment, id: 1, name: 'test assignment', instructor_id: 6, staggered_deadline: true, directory_path: 'same path',
participants: [build(:participant)], teams: [build(:assignment_team)], course_id: 1)
end
let(:assignment_form) { double('AssignmentForm', assignment: assignment) }
let(:student) { build(:student) }

before(:each) do
allow(Assignment).to receive(:find).with('1').and_return(assignment)
stub_current_user(student, student.role.name, student.role)
end
''

Then we check if the student can perform the update action for duties. We run an arbitrary code, in before each block, where we mock the action to update duties. In the inner context, we then stub the current user to be a student user, and check if the controller allows the update duties action.

''
describe '#action_allowed?' do
context 'when params action is update duties' do
before(:each) do
controller.params = {id: '1', action: 'update_duties'}
end
context 'when the role current user is student' do
it 'allows certain action' do
stub_current_user(student, student.role.name, student.role)
expect(controller.send(:action_allowed?)).to be true
end
end
end
end
''

This file also contains a test case to ensure the duties can be properly updated. The test case checks this by ensuring that the user is redirected to the student view page. just as with the previous section the first step is to mock the data by creating a team user object.

''
let(:teams_user1) {TeamsUser.new id:1, duty_id:1}
''

Then the data is actually updated and we ensure that the user is redirected to the proper place.

''
describe '#update_duties' do
it 'updates the duties for the participant' do
allow(TeamsUser).to receive(:find).with('1').and_return(teams_user1)
allow(teams_user1).to receive(:update_attribute).with(any_args).and_return('OK')
params = {
teams_user_id: '1',
teams_user: {duty_id: '1'},
participant_id: '1'
}
session = {user: stub_current_user(student, student.role.name, student.role)}
get :update_duties, params, session
expect(response).to redirect_to('/student_teams/view?student_id=1')
end
end
''

== assignment_form_spec.rb ==
The assignemnt_form_spec.rb file contains all the test files for the assignment form, which includes adding object to a queue. The first step was to create mock data so that the test could run on objects created for the tests. The code below shows how the mock data was created for the specific tests that we created to ensure the functionality of the projects.
''
let(:new_assignment_questionnaire) { build(:assignment_questionnaire) }
''
The new_assignment_questionnaire object is used for both test cases in this file. The first test case checks for when the active record cannot be found for a specific assignment id or duty id. This test case ensures no errors will happen when a user is attempting to search for this. This scenario could very easily happen and this test ensures the functionality when it cannot be found.
''
context 'when active record for assignment_questionnaire is not found for a given assignment_id and duty_id' do
it 'returns new instance of assignment_questionnaire with default values' do
allow(assignment).to receive(:questionnaire_varies_by_duty).and_return(true)
allow(AssignmentQuestionnaire).to receive(:where).with(assignment_id: 1, duty_id: anything).and_return([])
allow(AssignmentQuestionnaire).to receive(:where).with(user_id: anything, assignment_id: nil, questionnaire_id: nil).and_return([])
allow(AssignmentQuestionnaire).to receive(:new).and_return(new_assignment_questionnaire)
expect(assignment_form.assignment_questionnaire('TeammateReviewQuestionnaire', nil, nil, 1)).to eq(new_assignment_questionnaire)
end
end
''
The next next test checks when the assignment questionnaire is found given the assignment id and duty id parameters. This test is very similar to the one where the test is not found because the it searches through the active record to find the assignment questionnaire. Ensuring that this test passes will be useful because if the questionnaire cannot be returned then it will not be possible to do role based reviewing.
''
context 'when active record for assignment_questionnaire is found for a given assignment_id and duty_id' do
it 'returns new instance of assignment_questionnaire with default values' do
allow(assignment).to receive(:questionnaire_varies_by_duty).and_return(true)
allow(Questionnaire).to receive(:find).with(1).and_return(questionnaire3)
allow(AssignmentQuestionnaire).to receive(:where).with(assignment_id: 1, duty_id: 1).and_return([assignment_questionnaire2])
allow(AssignmentQuestionnaire).to receive(:where).with(user_id: anything, assignment_id: nil, questionnaire_id: nil).and_return([])
allow(AssignmentQuestionnaire).to receive(:new).and_return(new_assignment_questionnaire)
expect(assignment_form.assignment_questionnaire('TeammateReviewQuestionnaire', nil, nil, 1)).to eq(assignment_questionnaire2)
end
end
''

== duty_spec.rb ==
The main purpose of the duty_spec.rb file is to test any duty to make sure a duty can be assigned to a team member. it also tests if a duty is unavailable to a team member because the max number of people have been assigned that duty. to test this functionality the mock data is created to allow for testing of the object. The mock data is shown below which is used for all tests in this file.
''
let(:assignment) { build(:assignment, id: 1, name: 'no assgt') }
let(:participant) { build(:participant, id:1, user_id: 1) }
let(:participant2) { build(:participant, id:2, user_id: 2) }
let(:participant3) { build(:participant, id:3, user_id: 3) }
let(:user) { build(:student, id: 1, name: 'no name', fullname: 'no one', participants: [participant]) }
let(:user2) { build(:student, id: 2, name: 'no name2', fullname: 'no one2', participants: [participant2]) }
let(:user3) { build(:student, id: 3, name: 'no name3', fullname: 'no one3', participants: [participant3]) }

let(:team1) { build(:assignment_team, id: 1, name: 'no team', users: [user, user2, user3]) }
let(:sample_duty_taken) { build(:duty, id: 1, max_members_for_duty:1, assignment_id:1) }
let(:sample_duty_not_taken) { build(:duty, id: 1, max_members_for_duty:2, assignment_id:1) }

let(:team_user1) { build(:team_user, id: 1, user: user) }
let(:team_user2) { build(:team_user, id: 2, user: user2) }
let(:team_user3) { build(:team_user, id: 3, user: user3, duty_id:1) }
''
An assignment is created on which the duties can be tested. for the testing multiple users and participants are created. Finally we created team users that could be assigned duties through the duty_id field. the next step was to set up the reoccurring steps for each of the tests.
''
before(:each) do
allow(team1).to receive(:participants).and_return([participant, participant2, participant3])
allow(participant).to receive(:get_team_user).and_return(team_user1)
allow(participant2).to receive(:get_team_user).and_return(team_user2)
allow(participant3).to receive(:get_team_user).and_return(team_user3)
end
''
Finally the actual tests were implemented. The tests are fairly simple because they just need to check if the duty can be assigned or not. The first test checks to make sure a duty can be assigned to a student when the role is available. This makes sure the students will not run into a problem when the roles are assigned within the group. If the roles could not be assigned, then the specific rubrics could not be used during the reviewing phase of the project.
''
describe '#can_be_assigned?' do
context 'when users in current team want to assign roles that are available'
it 'returns true' do
expect(sample_duty_not_taken.can_be_assigned?(team1)).to be true
end
The next test case makes sure a duty cannot be assigned if there is already the max number of people assigned that role. This test case is important because if too many people are assigned that role the team dynamic will not be correct.
context 'when users in current team want to assign roles that are unavailable'
it 'returns false' do
expect(sample_duty_taken.can_be_assigned?(team1)).to be false
end
''

== teammate_review_response_map_spec.rb ==
This Rspec testing file tests that a specific questionnaire can be returned when the student has a role assigned to them. This is needed for the role based reviewing because when one student goes to review another they must get the correct questionnaire for their role. We tested this functionality as well as the inverse, when the role could not be found. initially we created the mock data for testing which is shown below.
''
let(:questionnaire) { Questionnaire.new name: "abc", private: 0, min_question_score: 0, max_question_score: 10, instructor_id: 1234 }
let(:assignment) { build(:assignment, id: 1, name: 'no assgt', is_duty_based_assignment: true, questionnaires: [questionnaire]) }
let(:assignment_questionnaire1) { build(:assignment_questionnaire, id: 1, assignment_id: 1, questionnaire_id: 2, duty_id: 1) }
let(:participant) { build(:participant, id: 1, user_id: 6, assignment: assignment) }
let(:teammate_review_response_map) { TeammateReviewResponseMap.new reviewer: participant, reviewer_is_team: true, assignment:assignment }
''
This step created the review response map that we would be testing as well as and assignment which contained a questionnaire. The next step was to actually test the data. First we decided to ensure that the correct questionnaire was returned with the following test. It compares the returned questionnaire with the one we know is correct.
''
it 'returns questionnaire specific to a duty' do
allow(AssignmentQuestionnaire).to receive(:where).with(assignment_id: 1, duty_id: 1).and_return([assignment_questionnaire1])
allow(Questionnaire).to receive(:find).with(assignment_questionnaire1.questionnaire_id).and_return(questionnaire)
expect(teammate_review_response_map.questionnaire_by_duty(1)).to eq questionnaire
end
''
Finally we added the inverse for when there was an error returning the questionnaire. in this case the program should return the default questionnaire.
''
it 'returns default questionnaire when no questionnaire is found for duty' do
allow(AssignmentQuestionnaire).to receive(:where).with(assignment_id: 1, duty_id: 1).and_return([])
allow(assignment.questionnaires).to receive(:find_by).with(type: 'TeammateReviewQuestionnaire').and_return(questionnaire)
expect(teammate_review_response_map.questionnaire_by_duty(1)).to eq questionnaire
end
''

[[Media:<iframe width="560" height="315" src="https://www.youtube.com/embed/CVRYYNh49Bk" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>]]

== Manual Testing in Expertiza UI ==
Here we describe manual UI Testing steps to edit an existing assignment to allow it have to specialized rubrics for different topic types. These steps are also shown in recorded demo video.
*Login to Expertiza using instructor account (For testing, username: '''instructor6''', password: '''password''')
*Click on Manage > Assignments
*Click on Edit option for any assignment, you should get following view. Make sure '''Has topics?''' box is checked.
[[File:Assignment edit 3.png]]
*Click on Rubrics tab. You will see 2 checkboxes ('''Review rubric varies by round?''', '''Review rubric varies by topic?''')
*Check the box for '''Review rubric varies by topic?'''
*Go to Topics tab and verify that there is dropdown menu beside each Topic.
*Select a rubric from dropdown menu, and click '''Save'''
[[File:Topics rubric 2.png]]
*Go back to Home, and select the same assignment to edit. When you click on Topics tab, you should see the rubric you had selected.

==Team Information==
* Naman Shrimali
* Kanchan Rawat
* Subodh Thota
* Andrew Shipman
Mentor : Prof. Edward F. Gehringer

CSC/ECE 517 Fall 2021 - E2161. Merge code for role based reviewing with code for topic specific rubrics

2021-11-29T21:22:38Z

Ajshipma:

This wiki page contains description of changes designed and implemented for [https://docs.google.com/document/d/1slx4HPIbgTH-psIKMSCF-HDF9brxf-FuYhzVT9ZiIrM/edit#heading=h.8s6o9jnnxj0p E2161. Merge code for role-based reviewing with code for topic-specific rubrics], a Final Project for CSC/ECE 517, Fall 2021.
== Purpose==
In CSC/ECE 517, there are Expertiza-based course projects, Mozilla-based course projects, etc. However, currently, we can only specify one kind of rubric for all kinds of course projects. This means that refactoring projects, testing projects, and Mozilla projects need to use the same rubric. We hope we could specify different rubrics to be used with different kinds of course projects.

The project objective is to merge E2147-https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2147._Role-based_reviewing#E2147._Role-based_reviewing with the existing E2026-https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2020_-_E2026._Specialized_rubrics_for_different_topic_types. While merging, we found out that the code for E2026 has already been merged on Expertiza beta branch and so now the actual implementation is to write test cases for both E2147 and E2026.

==Brief Overview of E2147 and E2026 Projects==
*E2147(Role based reviewing): The project objective was to develop teammate review varying by the roles that each team member has in order to evaluate the particular role that each team member has taken rather than asking a generic questionnaire which was same for all the team members previously. For eg, the instructor would create a separate teammate questionnaire for developer role and for tester role respectively.
*E2026(Specialized rubrics for different topics): The project objective was to develop specialized rubrics based on project topics, previously we had same type of questionnaire for all the different types of projects. This implementation made sure that we evaluate different projects based on personalised rubrics rather than having same rubrics.

==Testing Plan==

===Test Scenarios for E2147 (Role based reviewing)===
*Only Instructor/TA/Admin should be able to create or update duties: Only the instructor/admin should be able to create or update duties. Also, the corresponding TA of the assignment should be able to create or update duties.
*Create new roles: If the assignment is role based reviewing then the instructor should be able to create new roles for the same and save it in the database using new role functionality.
*Only allow student to update duties in Student View: Only student should be able to update his duties in Student View.
*Edit existing roles: Once the new roles have been created, then the instructor should be able to edit its details such as the maximum number of each role allowed.
*Delete existing roles: The instructor should also be able to delete any roles if he wants.
*Review rubric by role: On Rubrics tab, if the instructor clicks on Review rubric by role, then the corresponding rubric roles based teammate questionnaire should appear and get saved successfully.
*Student View: If the assignment is role based assignment, then the respective students should be able to see the respective teammate questionnaire based on roles for his other team members.
*Selection of Roles: On student login, a student should be able to see the existing roles that he can take up in the project. Only the roles which are available should be shown to the student.

===Test Scenarios for E2026 (Specialized rubrics for different topics)===

As part of our implementation, we modified existing code as well as added new code. To ensure that existing functionality was not broken, and new functionality worked as expected, we used the following Test Strategy (which was also used by previous team):

===Run and pass existing RSpec Tests===
*The following existing RSpec test files have been modified and they pass as part of testing:
**spec/controllers/assignments_controller_spec.rb
**spec/controllers/questionnaires_controller_spec.rb
**spec/controllers/response_controller_spec.rb
**spec/factories/factories.rb
**spec/features/assignment_creation_spec.rb
**spec/features/quiz_spec.rb
**spec/features/staggered_deadline_spec.rb
**spec/models/assignment_form_spec.rb
**spec/models/assignment_spec.rb
**spec/models/on_the_fly_calc_spec.rb
**spec/models/response_spec.rb
**spec/models/review_response_map_spec.rb

===Develop New RSpec Tests===
*spec/helpers/duties_controller_spec.rb
*All these rspec tests passed.

== duties_controller_spec.rb ==
We have created this new test file to unit test the functionality of duties_controller.

The first step was to create mock data so that the test could run on objects created for the tests. The code below shows how the mock data was created for the specific tests that we created to ensure the functionality of the projects.

''
describe DutiesController do
let(:assignment) { build(:assignment, id: 1,course_id: 1,instructor_id: 6, due_dates: [due_date], microtask: true, staggered_deadline: true)}
let(:admin) { build(:admin) }
let(:instructor) { build(:instructor, id: 6) }
let(:instructor2) { build(:instructor, id: 66) }
let(:ta) { build(:teaching_assistant, id: 8) }
let(:duty) { build(:duty, id: 1, duty_name: "Role", max_members_for_duty: 2, assignment_id: 1) }
let(:due_date) { build(:assignment_due_date, deadline_type_id: 1) } ''

We then run the arbitrary code that is needed before each test. We include method stubs here that we can use for each test. We stub the current user to be instructor for now.

''
before(:each) do
allow(Assignment).to receive(:find).with('1').and_return(assignment)
allow(Assignment).to receive(:find).with(1).and_return(assignment)
stub_current_user(instructor, instructor.role.name, instructor.role)
allow(Duty).to receive(:find).with('1').and_return(duty)
end
''

Test scenarios for duties controller:

1) Only admin, superadmin, TA, Instructor can perform edit or update action

'' describe '#action_allowed?' do ''

The whole context that defines if the action allowed is edit or update. We do this by mocking the action to edit. We then run the arbitrary code that is needed before each test in this context. We include method stubs here that we can use for each test. We stub the current user to be instructor for now.

context 'when params action is edit or update' do
before(:each) do
controller.params = {id: '1', action: 'edit'}
end

When the current logged in user role is super admin or admin. We check if the action is allowed by stubbing the current user to admin. We then verify if the controller is able to perform the action for the current admin user

context 'when the role name of current user is super admin or admin' do
it 'allows certain action' do
stub_current_user(admin, admin.role.name, admin.role)
expect(controller.send(:action_allowed?)).to be true
end
end

When the current logged in user role is instructor of the current assignment. We check if the action is allowed by stubbing the current user to instructor. We then verify if the controller is able to perform the action for the current instructor user

context 'when current user is the instructor of current assignment' do
it 'allows certain action' do
expect(controller.send(:action_allowed?)).to be true
end
end

When the current logged in user role is the TA of the course. We check if the action is allowed by stubbing the current user to TA. We then verify if the controller is able to perform the action for the current TA user

context 'when current user is the ta of the course which current assignment belongs to' do
it 'allows certain action' do
stub_current_user(ta, ta.role.name, ta.role)
allow(TaMapping).to receive(:exists?).with(ta_id: 8, course_id: 1).and_return(true)
expect(controller.send(:action_allowed?)).to be true
end
end

When the current logged in user is the instructor of the course. We check if the action is allowed by stubbing the current user to instructor. We then verify if the controller is able to perform the action for the current instructor user

context 'when current user is the instructor of the course which current assignment belongs to' do
it 'allows certain action' do
stub_current_user(instructor2, instructor2.role.name, instructor2.role)
allow(Course).to receive(:find).with(1).and_return(double('Course', instructor_id: 66))
expect(controller.send(:action_allowed?)).to be true
end
end
end

When the parameter action is neither edit nor update, we do this by mocking the action to new(create) in the arbitrary code that runs before each test.

context 'when params action is not edit and update' do
before(:each) do
controller.params = {id: '1', action: 'new'}
end

We now check if super admin/admin/instructor/ta can perform this action which is neither edit nor update. We check if the controller can perform the action 'new' which we mocked in the before each step.

context 'when the role current user is super admin/admin/instructor/ta' do
it 'allows certain action except edit and update' do
expect(controller.send(:action_allowed?)).to be true
end
end
end
end

We also added few tests to test creation/edit/deletion of a duty.

Creation of a duty, we create a duty and check if it is saved successfully

describe '#create' do

We write a test to check if the right page is rendered after successful creation and saving of a new duty in the database. We do this by stubbing the duty object to get saved in the database, and then perform the create action. We also check if the flash message rendered matches to the expected message.

context 'when new duty can be saved successfully' do
it 'sets up a new duty and redirects to assignment#edit page' do
allow(duty).to receive(:save).and_return('OK')
params = {
id: 1,
duty: {
duty_name: 'Scrum Master',
max_members_for_duty: 2,
assignment_id: 1
}
}
post :create, params
expect(response).to redirect_to('/assignments/1/edit')
expect(flash[:notice]).to match(/Role was successfully created.*/)
end
end

Test to check if the right error message is shown if the creation of duty is failed. We stub duty to receive errors, perform the create action, and then check if the right page is rendered and also the check if the flash message matches with the expected error message.

context 'when new duty cannot be saved successfully' do
it 'shows error message and redirects to duty#new page' do
allow(duty).to receive(:errors)
params = {
id: 1,
duty: {
duty_name: 'Scrum Master',
max_members_for_duty: -1,
assignment_id: 1
}
}
post :create, params
expect(flash[:error]).to eq('Max members for duty must be greater than or equal to 1. ')
expect(response).to redirect_to('/duties/new?id=1')
end
end
end

Test to check the edit functionality of a duty.

describe '#update' do

When the duty can be edited successfully, we check if the right page is rendered. We first stub the duty active record find function to return a mocked duty object. We then try to edit the duty object by performing the update action, and then check if the right page is rendered and the flash message matches to the expected message.

context 'when duty can be found' do
it 'updates current duty and redirects to assignment#edit page' do
allow(Duty).to receive(:find).with('1').and_return(build(:duty, id: 1))
params = {
id: 1,
assignment_id: 1,
duty: {
duty_name: 'Scrum Master',
max_members_for_duty: 5,
assignment_id: 1
}
}
post :update, params
expect(response).to redirect_to('/assignments/1/edit')
expect(flash[:notice]).to match(/Role was successfully updated.*/)
end
end

When the duty cannot be updated, we check if the right error message is displayed. We stub the duty object to receive errors. And then we try to save the duty by performing the create action, which results in an unsuccessful attempt, where we check if the right page is rendered and the flash message matches with the expected one.

context 'when new duty cannot be updated successfully' do
it 'shows error message and redirects to duty#new page' do
allow(duty).to receive(:errors)
params = {
id: 1,
duty: {
duty_name: 'SM',
max_members_for_duty: 1,
assignment_id: 1
}
}
post :create, params
expect(flash[:error]).to eq('Duty name is too short (minimum is 3 characters). ')
expect(response).to redirect_to('/duties/new?id=1')
end
end
end

Now finally, we test the delete functionality of the duty. We perform the delete action, and then check if the right page is rendered after the delete action, and also check if the flash message matches with the expected one

describe '#destroy' do
context 'when duty can be found' do
it 'redirects to assignment#edit page' do
params = {id: 1, assignment_id: 1}
post :destroy, params
expect(response).to redirect_to('/assignments/1/edit')
expect(flash[:notice]).to match(/Role was successfully destroyed.*/)
end
end
end

== team_users_controller_spec.rb ==

We have added a test case in this file which tests if the action is allowed only by specific user roles. The first step was to create mock data so that the test could run on objects created for the tests. The code below shows how the mock data was created for the specific tests that we created to ensure the functionality of the projects.

''
describe TeamsUsersController do
let(:assignment) do
build(:assignment, id: 1, name: 'test assignment', instructor_id: 6, staggered_deadline: true, directory_path: 'same path',
participants: [build(:participant)], teams: [build(:assignment_team)], course_id: 1)
end
let(:assignment_form) { double('AssignmentForm', assignment: assignment) }
let(:student) { build(:student) }

before(:each) do
allow(Assignment).to receive(:find).with('1').and_return(assignment)
stub_current_user(student, student.role.name, student.role)
end
''

Then we check if the student can perform the update action for duties. We run an arbitrary code, in before each block, where we mock the action to update duties. In the inner context, we then stub the current user to be a student user, and check if the controller allows the update duties action.

''
describe '#action_allowed?' do
context 'when params action is update duties' do
before(:each) do
controller.params = {id: '1', action: 'update_duties'}
end
context 'when the role current user is student' do
it 'allows certain action' do
stub_current_user(student, student.role.name, student.role)
expect(controller.send(:action_allowed?)).to be true
end
end
end
end
''

This file also contains a test case to ensure the duties can be properly updated. The test case checks this by ensuring that the user is redirected to the student view page. just as with the previous section the first step is to mock the data by creating a team user object.

''
let(:teams_user1) {TeamsUser.new id:1, duty_id:1}
''

Then the data is actually updated and we ensure that the user is redirected to the proper place.

''
describe '#update_duties' do
it 'updates the duties for the participant' do
allow(TeamsUser).to receive(:find).with('1').and_return(teams_user1)
allow(teams_user1).to receive(:update_attribute).with(any_args).and_return('OK')
params = {
teams_user_id: '1',
teams_user: {duty_id: '1'},
participant_id: '1'
}
session = {user: stub_current_user(student, student.role.name, student.role)}
get :update_duties, params, session
expect(response).to redirect_to('/student_teams/view?student_id=1')
end
end
''

== assignment_form_spec.rb ==
The assignemnt_form_spec.rb file contains all the test files for the assignment form, which includes adding object to a queue. The first step was to create mock data so that the test could run on objects created for the tests. The code below shows how the mock data was created for the specific tests that we created to ensure the functionality of the projects.
''
let(:new_assignment_questionnaire) { build(:assignment_questionnaire) }
''
The new_assignment_questionnaire object is used for both test cases in this file. The first test case checks for when the active record cannot be found for a specific assignment id or duty id. This test case ensures no errors will happen when a user is attempting to search for this. This scenario could very easily happen and this test ensures the functionality when it cannot be found.
''
context 'when active record for assignment_questionnaire is not found for a given assignment_id and duty_id' do
it 'returns new instance of assignment_questionnaire with default values' do
allow(assignment).to receive(:questionnaire_varies_by_duty).and_return(true)
allow(AssignmentQuestionnaire).to receive(:where).with(assignment_id: 1, duty_id: anything).and_return([])
allow(AssignmentQuestionnaire).to receive(:where).with(user_id: anything, assignment_id: nil, questionnaire_id: nil).and_return([])
allow(AssignmentQuestionnaire).to receive(:new).and_return(new_assignment_questionnaire)
expect(assignment_form.assignment_questionnaire('TeammateReviewQuestionnaire', nil, nil, 1)).to eq(new_assignment_questionnaire)
end
end
''
The next next test checks when the assignment questionnaire is found given the assignment id and duty id parameters. This test is very similar to the one where the test is not found because the it searches through the active record to find the assignment questionnaire. Ensuring that this test passes will be useful because if the questionnaire cannot be returned then it will not be possible to do role based reviewing.
''
context 'when active record for assignment_questionnaire is found for a given assignment_id and duty_id' do
it 'returns new instance of assignment_questionnaire with default values' do
allow(assignment).to receive(:questionnaire_varies_by_duty).and_return(true)
allow(Questionnaire).to receive(:find).with(1).and_return(questionnaire3)
allow(AssignmentQuestionnaire).to receive(:where).with(assignment_id: 1, duty_id: 1).and_return([assignment_questionnaire2])
allow(AssignmentQuestionnaire).to receive(:where).with(user_id: anything, assignment_id: nil, questionnaire_id: nil).and_return([])
allow(AssignmentQuestionnaire).to receive(:new).and_return(new_assignment_questionnaire)
expect(assignment_form.assignment_questionnaire('TeammateReviewQuestionnaire', nil, nil, 1)).to eq(assignment_questionnaire2)
end
end
''

== duty_spec.rb ==
The main purpose of the duty_spec.rb file is to test any duty to make sure a duty can be assigned to a team member. it also tests if a duty is unavailable to a team member because the max number of people have been assigned that duty. to test this functionality the mock data is created to allow for testing of the object. The mock data is shown below which is used for all tests in this file.
''
let(:assignment) { build(:assignment, id: 1, name: 'no assgt') }
let(:participant) { build(:participant, id:1, user_id: 1) }
let(:participant2) { build(:participant, id:2, user_id: 2) }
let(:participant3) { build(:participant, id:3, user_id: 3) }
let(:user) { build(:student, id: 1, name: 'no name', fullname: 'no one', participants: [participant]) }
let(:user2) { build(:student, id: 2, name: 'no name2', fullname: 'no one2', participants: [participant2]) }
let(:user3) { build(:student, id: 3, name: 'no name3', fullname: 'no one3', participants: [participant3]) }

let(:team1) { build(:assignment_team, id: 1, name: 'no team', users: [user, user2, user3]) }
let(:sample_duty_taken) { build(:duty, id: 1, max_members_for_duty:1, assignment_id:1) }
let(:sample_duty_not_taken) { build(:duty, id: 1, max_members_for_duty:2, assignment_id:1) }

let(:team_user1) { build(:team_user, id: 1, user: user) }
let(:team_user2) { build(:team_user, id: 2, user: user2) }
let(:team_user3) { build(:team_user, id: 3, user: user3, duty_id:1) }
''
An assignment is created on which the duties can be tested. for the testing multiple users and participants are created. Finally we created team users that could be assigned duties through the duty_id field. the next step was to set up the reoccurring steps for each of the tests.
''
before(:each) do
allow(team1).to receive(:participants).and_return([participant, participant2, participant3])
allow(participant).to receive(:get_team_user).and_return(team_user1)
allow(participant2).to receive(:get_team_user).and_return(team_user2)
allow(participant3).to receive(:get_team_user).and_return(team_user3)
end
''
Finally the actual tests were implemented. The tests are fairly simple because they just need to check if the duty can be assigned or not. The first test checks to make sure a duty can be assigned to a student when the role is available. This makes sure the students will not run into a problem when the roles are assigned within the group. If the roles could not be assigned, then the specific rubrics could not be used during the reviewing phase of the project.
''
describe '#can_be_assigned?' do
context 'when users in current team want to assign roles that are available'
it 'returns true' do
expect(sample_duty_not_taken.can_be_assigned?(team1)).to be true
end
The next test case makes sure a duty cannot be assigned if there is already the max number of people assigned that role. This test case is important because if too many people are assigned that role the team dynamic will not be correct.
context 'when users in current team want to assign roles that are unavailable'
it 'returns false' do
expect(sample_duty_taken.can_be_assigned?(team1)).to be false
end
''

== teammate_review_response_map_spec.rb ==
This Rspec testing file tests that a specific questionnaire can be returned when the student has a role assigned to them. This is needed for the role based reviewing because when one student goes to review another they must get the correct questionnaire for their role. We tested this functionality as well as the inverse, when the role could not be found. initially we created the mock data for testing which is shown below.
''
let(:questionnaire) { Questionnaire.new name: "abc", private: 0, min_question_score: 0, max_question_score: 10, instructor_id: 1234 }
let(:assignment) { build(:assignment, id: 1, name: 'no assgt', is_duty_based_assignment: true, questionnaires: [questionnaire]) }
let(:assignment_questionnaire1) { build(:assignment_questionnaire, id: 1, assignment_id: 1, questionnaire_id: 2, duty_id: 1) }
let(:participant) { build(:participant, id: 1, user_id: 6, assignment: assignment) }
let(:teammate_review_response_map) { TeammateReviewResponseMap.new reviewer: participant, reviewer_is_team: true, assignment:assignment }
''
This step created the review response map that we would be testing as well as and assignment which contained a questionnaire. The next step was to actually test the data. First we decided to ensure that the correct questionnaire was returned with the following test. It compares the returned questionnaire with the one we know is correct.
''
it 'returns questionnaire specific to a duty' do
allow(AssignmentQuestionnaire).to receive(:where).with(assignment_id: 1, duty_id: 1).and_return([assignment_questionnaire1])
allow(Questionnaire).to receive(:find).with(assignment_questionnaire1.questionnaire_id).and_return(questionnaire)
expect(teammate_review_response_map.questionnaire_by_duty(1)).to eq questionnaire
end
''
Finally we added the inverse for when there was an error returning the questionnaire. in this case the program should return the default questionnaire.
''
it 'returns default questionnaire when no questionnaire is found for duty' do
allow(AssignmentQuestionnaire).to receive(:where).with(assignment_id: 1, duty_id: 1).and_return([])
allow(assignment.questionnaires).to receive(:find_by).with(type: 'TeammateReviewQuestionnaire').and_return(questionnaire)
expect(teammate_review_response_map.questionnaire_by_duty(1)).to eq questionnaire
end
''

== Manual Testing in Expertiza UI ==
Here we describe manual UI Testing steps to edit an existing assignment to allow it have to specialized rubrics for different topic types. These steps are also shown in recorded demo video.
*Login to Expertiza using instructor account (For testing, username: '''instructor6''', password: '''password''')
*Click on Manage > Assignments
*Click on Edit option for any assignment, you should get following view. Make sure '''Has topics?''' box is checked.
[[File:Assignment edit 3.png]]
*Click on Rubrics tab. You will see 2 checkboxes ('''Review rubric varies by round?''', '''Review rubric varies by topic?''')
*Check the box for '''Review rubric varies by topic?'''
*Go to Topics tab and verify that there is dropdown menu beside each Topic.
*Select a rubric from dropdown menu, and click '''Save'''
[[File:Topics rubric 2.png]]
*Go back to Home, and select the same assignment to edit. When you click on Topics tab, you should see the rubric you had selected.

==Team Information==
* Naman Shrimali
* Kanchan Rawat
* Subodh Thota
* Andrew Shipman
Mentor : Prof. Edward F. Gehringer

CSC/ECE 517 Fall 2021 - E2161. Merge code for role based reviewing with code for topic specific rubrics

2021-11-29T21:20:44Z

Ajshipma:

This wiki page contains description of changes designed and implemented for [https://docs.google.com/document/d/1slx4HPIbgTH-psIKMSCF-HDF9brxf-FuYhzVT9ZiIrM/edit#heading=h.8s6o9jnnxj0p E2161. Merge code for role-based reviewing with code for topic-specific rubrics], a Final Project for CSC/ECE 517, Fall 2021.
== Purpose==
In CSC/ECE 517, there are Expertiza-based course projects, Mozilla-based course projects, etc. However, currently, we can only specify one kind of rubric for all kinds of course projects. This means that refactoring projects, testing projects, and Mozilla projects need to use the same rubric. We hope we could specify different rubrics to be used with different kinds of course projects.

The project objective is to merge E2147-https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2147._Role-based_reviewing#E2147._Role-based_reviewing with the existing E2026-https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2020_-_E2026._Specialized_rubrics_for_different_topic_types. While merging, we found out that the code for E2026 has already been merged on Expertiza beta branch and so now the actual implementation is to write test cases for both E2147 and E2026.

==Brief Overview of E2147 and E2026 Projects==
*E2147(Role based reviewing): The project objective was to develop teammate review varying by the roles that each team member has in order to evaluate the particular role that each team member has taken rather than asking a generic questionnaire which was same for all the team members previously. For eg, the instructor would create a separate teammate questionnaire for developer role and for tester role respectively.
*E2026(Specialized rubrics for different topics): The project objective was to develop specialized rubrics based on project topics, previously we had same type of questionnaire for all the different types of projects. This implementation made sure that we evaluate different projects based on personalised rubrics rather than having same rubrics.

==Testing Plan==

===Test Scenarios for E2147 (Role based reviewing)===
*Only Instructor/TA/Admin should be able to create or update duties: Only the instructor/admin should be able to create or update duties. Also, the corresponding TA of the assignment should be able to create or update duties.
*Create new roles: If the assignment is role based reviewing then the instructor should be able to create new roles for the same and save it in the database using new role functionality.
*Only allow student to update duties in Student View: Only student should be able to update his duties in Student View.
*Edit existing roles: Once the new roles have been created, then the instructor should be able to edit its details such as the maximum number of each role allowed.
*Delete existing roles: The instructor should also be able to delete any roles if he wants.
*Review rubric by role: On Rubrics tab, if the instructor clicks on Review rubric by role, then the corresponding rubric roles based teammate questionnaire should appear and get saved successfully.
*Student View: If the assignment is role based assignment, then the respective students should be able to see the respective teammate questionnaire based on roles for his other team members.
*Selection of Roles: On student login, a student should be able to see the existing roles that he can take up in the project. Only the roles which are available should be shown to the student.

===Test Scenarios for E2026 (Specialized rubrics for different topics)===

As part of our implementation, we modified existing code as well as added new code. To ensure that existing functionality was not broken, and new functionality worked as expected, we used the following Test Strategy (which was also used by previous team):

===Run and pass existing RSpec Tests===
*The following existing RSpec test files have been modified and they pass as part of testing:
**spec/controllers/assignments_controller_spec.rb
**spec/controllers/questionnaires_controller_spec.rb
**spec/controllers/response_controller_spec.rb
**spec/factories/factories.rb
**spec/features/assignment_creation_spec.rb
**spec/features/quiz_spec.rb
**spec/features/staggered_deadline_spec.rb
**spec/models/assignment_form_spec.rb
**spec/models/assignment_spec.rb
**spec/models/on_the_fly_calc_spec.rb
**spec/models/response_spec.rb
**spec/models/review_response_map_spec.rb

===Develop New RSpec Tests===
*spec/helpers/duties_controller_spec.rb
*All these rspec tests passed.

== duties_controller_spec.rb ==
We have created this new test file to unit test the functionality of duties_controller.

The first step was to create mock data so that the test could run on objects created for the tests. The code below shows how the mock data was created for the specific tests that we created to ensure the functionality of the projects.

''
describe DutiesController do
let(:assignment) { build(:assignment, id: 1,course_id: 1,instructor_id: 6, due_dates: [due_date], microtask: true, staggered_deadline: true)}
let(:admin) { build(:admin) }
let(:instructor) { build(:instructor, id: 6) }
let(:instructor2) { build(:instructor, id: 66) }
let(:ta) { build(:teaching_assistant, id: 8) }
let(:duty) { build(:duty, id: 1, duty_name: "Role", max_members_for_duty: 2, assignment_id: 1) }
let(:due_date) { build(:assignment_due_date, deadline_type_id: 1) } ''

We then run the arbitrary code that is needed before each test. We include method stubs here that we can use for each test. We stub the current user to be instructor for now.

''
before(:each) do
allow(Assignment).to receive(:find).with('1').and_return(assignment)
allow(Assignment).to receive(:find).with(1).and_return(assignment)
stub_current_user(instructor, instructor.role.name, instructor.role)
allow(Duty).to receive(:find).with('1').and_return(duty)
end
''

Test scenarios for duties controller:

1) Only admin, superadmin, TA, Instructor can perform edit or update action

'' describe '#action_allowed?' do ''

The whole context that defines if the action allowed is edit or update. We do this by mocking the action to edit. We then run the arbitrary code that is needed before each test in this context. We include method stubs here that we can use for each test. We stub the current user to be instructor for now.

context 'when params action is edit or update' do
before(:each) do
controller.params = {id: '1', action: 'edit'}
end

When the current logged in user role is super admin or admin. We check if the action is allowed by stubbing the current user to admin. We then verify if the controller is able to perform the action for the current admin user

context 'when the role name of current user is super admin or admin' do
it 'allows certain action' do
stub_current_user(admin, admin.role.name, admin.role)
expect(controller.send(:action_allowed?)).to be true
end
end

When the current logged in user role is instructor of the current assignment. We check if the action is allowed by stubbing the current user to instructor. We then verify if the controller is able to perform the action for the current instructor user

context 'when current user is the instructor of current assignment' do
it 'allows certain action' do
expect(controller.send(:action_allowed?)).to be true
end
end

When the current logged in user role is the TA of the course. We check if the action is allowed by stubbing the current user to TA. We then verify if the controller is able to perform the action for the current TA user

context 'when current user is the ta of the course which current assignment belongs to' do
it 'allows certain action' do
stub_current_user(ta, ta.role.name, ta.role)
allow(TaMapping).to receive(:exists?).with(ta_id: 8, course_id: 1).and_return(true)
expect(controller.send(:action_allowed?)).to be true
end
end

When the current logged in user is the instructor of the course. We check if the action is allowed by stubbing the current user to instructor. We then verify if the controller is able to perform the action for the current instructor user

context 'when current user is the instructor of the course which current assignment belongs to' do
it 'allows certain action' do
stub_current_user(instructor2, instructor2.role.name, instructor2.role)
allow(Course).to receive(:find).with(1).and_return(double('Course', instructor_id: 66))
expect(controller.send(:action_allowed?)).to be true
end
end
end

When the parameter action is neither edit nor update, we do this by mocking the action to new(create) in the arbitrary code that runs before each test.

context 'when params action is not edit and update' do
before(:each) do
controller.params = {id: '1', action: 'new'}
end

We now check if super admin/admin/instructor/ta can perform this action which is neither edit nor update. We check if the controller can perform the action 'new' which we mocked in the before each step.

context 'when the role current user is super admin/admin/instructor/ta' do
it 'allows certain action except edit and update' do
expect(controller.send(:action_allowed?)).to be true
end
end
end
end

We also added few tests to test creation/edit/deletion of a duty.

Creation of a duty, we create a duty and check if it is saved successfully

describe '#create' do

We write a test to check if the right page is rendered after successful creation and saving of a new duty in the database. We do this by stubbing the duty object to get saved in the database, and then perform the create action. We also check if the flash message rendered matches to the expected message.

context 'when new duty can be saved successfully' do
it 'sets up a new duty and redirects to assignment#edit page' do
allow(duty).to receive(:save).and_return('OK')
params = {
id: 1,
duty: {
duty_name: 'Scrum Master',
max_members_for_duty: 2,
assignment_id: 1
}
}
post :create, params
expect(response).to redirect_to('/assignments/1/edit')
expect(flash[:notice]).to match(/Role was successfully created.*/)
end
end

Test to check if the right error message is shown if the creation of duty is failed. We stub duty to receive errors, perform the create action, and then check if the right page is rendered and also the check if the flash message matches with the expected error message.

context 'when new duty cannot be saved successfully' do
it 'shows error message and redirects to duty#new page' do
allow(duty).to receive(:errors)
params = {
id: 1,
duty: {
duty_name: 'Scrum Master',
max_members_for_duty: -1,
assignment_id: 1
}
}
post :create, params
expect(flash[:error]).to eq('Max members for duty must be greater than or equal to 1. ')
expect(response).to redirect_to('/duties/new?id=1')
end
end
end

Test to check the edit functionality of a duty.

describe '#update' do

When the duty can be edited successfully, we check if the right page is rendered. We first stub the duty active record find function to return a mocked duty object. We then try to edit the duty object by performing the update action, and then check if the right page is rendered and the flash message matches to the expected message.

context 'when duty can be found' do
it 'updates current duty and redirects to assignment#edit page' do
allow(Duty).to receive(:find).with('1').and_return(build(:duty, id: 1))
params = {
id: 1,
assignment_id: 1,
duty: {
duty_name: 'Scrum Master',
max_members_for_duty: 5,
assignment_id: 1
}
}
post :update, params
expect(response).to redirect_to('/assignments/1/edit')
expect(flash[:notice]).to match(/Role was successfully updated.*/)
end
end

When the duty cannot be updated, we check if the right error message is displayed. We stub the duty object to receive errors. And then we try to save the duty by performing the create action, which results in an unsuccessful attempt, where we check if the right page is rendered and the flash message matches with the expected one.

context 'when new duty cannot be updated successfully' do
it 'shows error message and redirects to duty#new page' do
allow(duty).to receive(:errors)
params = {
id: 1,
duty: {
duty_name: 'SM',
max_members_for_duty: 1,
assignment_id: 1
}
}
post :create, params
expect(flash[:error]).to eq('Duty name is too short (minimum is 3 characters). ')
expect(response).to redirect_to('/duties/new?id=1')
end
end
end

Now finally, we test the delete functionality of the duty. We perform the delete action, and then check if the right page is rendered after the delete action, and also check if the flash message matches with the expected one

describe '#destroy' do
context 'when duty can be found' do
it 'redirects to assignment#edit page' do
params = {id: 1, assignment_id: 1}
post :destroy, params
expect(response).to redirect_to('/assignments/1/edit')
expect(flash[:notice]).to match(/Role was successfully destroyed.*/)
end
end
end

== team_users_controller_spec.rb ==

We have added a test case in this file which tests if the action is allowed only by specific user roles. The first step was to create mock data so that the test could run on objects created for the tests. The code below shows how the mock data was created for the specific tests that we created to ensure the functionality of the projects.

''
describe TeamsUsersController do
let(:assignment) do
build(:assignment, id: 1, name: 'test assignment', instructor_id: 6, staggered_deadline: true, directory_path: 'same path',
participants: [build(:participant)], teams: [build(:assignment_team)], course_id: 1)
end
let(:assignment_form) { double('AssignmentForm', assignment: assignment) }
let(:student) { build(:student) }

before(:each) do
allow(Assignment).to receive(:find).with('1').and_return(assignment)
stub_current_user(student, student.role.name, student.role)
end
''

Then we check if the student can perform the update action for duties. We run an arbitrary code, in before each block, where we mock the action to update duties. In the inner context, we then stub the current user to be a student user, and check if the controller allows the update duties action.

''
describe '#action_allowed?' do
context 'when params action is update duties' do
before(:each) do
controller.params = {id: '1', action: 'update_duties'}
end
context 'when the role current user is student' do
it 'allows certain action' do
stub_current_user(student, student.role.name, student.role)
expect(controller.send(:action_allowed?)).to be true
end
end
end
end
''

This file also contains a test case to ensure the duties can be properly updated. The test case checks this by ensuring that the user is redirected to the student view page. just as with the previous section the first step is to mock the data by creating a team user object.

''
let(:teams_user1) {TeamsUser.new id:1, duty_id:1}
''

Then the data is actually updated and we ensure that the user is redirected to the proper place.

''
describe '#update_duties' do
it 'updates the duties for the participant' do
allow(TeamsUser).to receive(:find).with('1').and_return(teams_user1)
allow(teams_user1).to receive(:update_attribute).with(any_args).and_return('OK')
params = {
teams_user_id: '1',
teams_user: {duty_id: '1'},
participant_id: '1'
}
session = {user: stub_current_user(student, student.role.name, student.role)}
get :update_duties, params, session
expect(response).to redirect_to('/student_teams/view?student_id=1')
end
end
''

== assignment_form_spec.rb ==
The assignemnt_form_spec.rb file contains all the test files for the assignment form, which includes adding object to a queue. The first step was to create mock data so that the test could run on objects created for the tests. The code below shows how the mock data was created for the specific tests that we created to ensure the functionality of the projects.
''
let(:new_assignment_questionnaire) { build(:assignment_questionnaire) }
''
The new_assignment_questionnaire object is used for both test cases in this file. The first test case checks for when the active record cannot be found for a specific assignment id or duty id. This test case ensures no errors will happen when a user is attempting to search for this. This scenario could very easily happen and this test ensures the functionality when it cannot be found.
''
context 'when active record for assignment_questionnaire is not found for a given assignment_id and duty_id' do
it 'returns new instance of assignment_questionnaire with default values' do
allow(assignment).to receive(:questionnaire_varies_by_duty).and_return(true)
allow(AssignmentQuestionnaire).to receive(:where).with(assignment_id: 1, duty_id: anything).and_return([])
allow(AssignmentQuestionnaire).to receive(:where).with(user_id: anything, assignment_id: nil, questionnaire_id: nil).and_return([])
allow(AssignmentQuestionnaire).to receive(:new).and_return(new_assignment_questionnaire)
expect(assignment_form.assignment_questionnaire('TeammateReviewQuestionnaire', nil, nil, 1)).to eq(new_assignment_questionnaire)
end
end
''
The next next test checks when the assignment questionnaire is found given the assignment id and duty id parameters. This test is very similar to the one where the test is not found because the it searches through the active record to find the assignment questionnaire. Ensuring that this test passes will be useful because if the questionnaire cannot be returned then it will not be possible to do role based reviewing.
''
context 'when active record for assignment_questionnaire is found for a given assignment_id and duty_id' do
it 'returns new instance of assignment_questionnaire with default values' do
allow(assignment).to receive(:questionnaire_varies_by_duty).and_return(true)
allow(Questionnaire).to receive(:find).with(1).and_return(questionnaire3)
allow(AssignmentQuestionnaire).to receive(:where).with(assignment_id: 1, duty_id: 1).and_return([assignment_questionnaire2])
allow(AssignmentQuestionnaire).to receive(:where).with(user_id: anything, assignment_id: nil, questionnaire_id: nil).and_return([])
allow(AssignmentQuestionnaire).to receive(:new).and_return(new_assignment_questionnaire)
expect(assignment_form.assignment_questionnaire('TeammateReviewQuestionnaire', nil, nil, 1)).to eq(assignment_questionnaire2)
end
end
''

== duty_spec.rb ==
The main purpose of the duty_spec.rb file is to test any duty to make sure a duty can be assigned to a team member. it also tests if a duty is unavailable to a team member because the max number of people have been assigned that duty. to test this functionality the mock data is created to allow for testing of the object. The mock data is shown below which is used for all tests in this file.
''
let(:assignment) { build(:assignment, id: 1, name: 'no assgt') }
let(:participant) { build(:participant, id:1, user_id: 1) }
let(:participant2) { build(:participant, id:2, user_id: 2) }
let(:participant3) { build(:participant, id:3, user_id: 3) }
let(:user) { build(:student, id: 1, name: 'no name', fullname: 'no one', participants: [participant]) }
let(:user2) { build(:student, id: 2, name: 'no name2', fullname: 'no one2', participants: [participant2]) }
let(:user3) { build(:student, id: 3, name: 'no name3', fullname: 'no one3', participants: [participant3]) }

let(:team1) { build(:assignment_team, id: 1, name: 'no team', users: [user, user2, user3]) }
let(:sample_duty_taken) { build(:duty, id: 1, max_members_for_duty:1, assignment_id:1) }
let(:sample_duty_not_taken) { build(:duty, id: 1, max_members_for_duty:2, assignment_id:1) }

let(:team_user1) { build(:team_user, id: 1, user: user) }
let(:team_user2) { build(:team_user, id: 2, user: user2) }
let(:team_user3) { build(:team_user, id: 3, user: user3, duty_id:1) }
''
An assignment is created on which the duties can be tested. for the testing multiple users and participants are created. Finally we created team users that could be assigned duties through the duty_id field. the next step was to set up the reoccurring steps for each of the tests.
''
before(:each) do
allow(team1).to receive(:participants).and_return([participant, participant2, participant3])
allow(participant).to receive(:get_team_user).and_return(team_user1)
allow(participant2).to receive(:get_team_user).and_return(team_user2)
allow(participant3).to receive(:get_team_user).and_return(team_user3)
end
''
Finally the actual tests were implemented. The tests are fairly simple because they just need to check if the duty can be assigned or not. The first test checks to make sure a duty can be assigned to a student when the role is available. This makes sure the students will not run into a problem when the roles are assigned within the group. If the roles could not be assigned, then the specific rubrics could not be used during the reviewing phase of the project.
''
describe '#can_be_assigned?' do
context 'when users in current team want to assign roles that are available'
it 'returns true' do
expect(sample_duty_not_taken.can_be_assigned?(team1)).to be true
end
The next test case makes sure a duty cannot be assigned if there is already the max number of people assigned that role. This test case is important because if too many people are assigned that role the team dynamic will not be correct.
context 'when users in current team want to assign roles that are unavailable'
it 'returns false' do
expect(sample_duty_taken.can_be_assigned?(team1)).to be false
end
''

== teammate_review_response_map_spec.rb ==
This Rspec testing file tests that a specific questionnaire can be returned when the student has a role assigned to them. This is needed for the role based reviewing because when one student goes to review another they must get the correct questionnaire for their role. We tested this functionality as well as the inverse, when the role could not be found. initially we created the mock data for testing which is shown below.
''
let(:questionnaire) { Questionnaire.new name: "abc", private: 0, min_question_score: 0, max_question_score: 10, instructor_id: 1234 }
let(:assignment) { build(:assignment, id: 1, name: 'no assgt', is_duty_based_assignment: true, questionnaires: [questionnaire]) }
let(:assignment_questionnaire1) { build(:assignment_questionnaire, id: 1, assignment_id: 1, questionnaire_id: 2, duty_id: 1) }
let(:participant) { build(:participant, id: 1, user_id: 6, assignment: assignment) }
let(:teammate_review_response_map) { TeammateReviewResponseMap.new reviewer: participant, reviewer_is_team: true, assignment:assignment }
''
This step created the review response map that we would be testing as well as and assignment which contained a questionnaire. The next step was to actually test the data. First we decided to ensure that the correct questionnaire was returned with the following test. It compares the returned questionnaire with the one we know is correct.
''
it 'returns questionnaire specific to a duty' do
allow(AssignmentQuestionnaire).to receive(:where).with(assignment_id: 1, duty_id: 1).and_return([assignment_questionnaire1])
allow(Questionnaire).to receive(:find).with(assignment_questionnaire1.questionnaire_id).and_return(questionnaire)
expect(teammate_review_response_map.questionnaire_by_duty(1)).to eq questionnaire
end
''
Finally we added the inverse for when there was an error returning the questionnaire. in this case the program should return the default questionnaire.
''
it 'returns default questionnaire when no questionnaire is found for duty' do
allow(AssignmentQuestionnaire).to receive(:where).with(assignment_id: 1, duty_id: 1).and_return([])
allow(assignment.questionnaires).to receive(:find_by).with(type: 'TeammateReviewQuestionnaire').and_return(questionnaire)
expect(teammate_review_response_map.questionnaire_by_duty(1)).to eq questionnaire
end
''

<iframe width="560" height="315" src="https://www.youtube.com/embed/CVRYYNh49Bk" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>

== Manual Testing in Expertiza UI ==
Here we describe manual UI Testing steps to edit an existing assignment to allow it have to specialized rubrics for different topic types. These steps are also shown in recorded demo video.
*Login to Expertiza using instructor account (For testing, username: '''instructor6''', password: '''password''')
*Click on Manage > Assignments
*Click on Edit option for any assignment, you should get following view. Make sure '''Has topics?''' box is checked.
[[File:Assignment edit 3.png]]
*Click on Rubrics tab. You will see 2 checkboxes ('''Review rubric varies by round?''', '''Review rubric varies by topic?''')
*Check the box for '''Review rubric varies by topic?'''
*Go to Topics tab and verify that there is dropdown menu beside each Topic.
*Select a rubric from dropdown menu, and click '''Save'''
[[File:Topics rubric 2.png]]
*Go back to Home, and select the same assignment to edit. When you click on Topics tab, you should see the rubric you had selected.

==Team Information==
* Naman Shrimali
* Kanchan Rawat
* Subodh Thota
* Andrew Shipman
Mentor : Prof. Edward F. Gehringer

CSC/ECE 517 Fall 2021 - E2161. Merge code for role based reviewing with code for topic specific rubrics

2021-11-29T14:23:24Z

Ajshipma: /* duty_spec.rb */

This wiki page contains description of changes designed and implemented for [https://docs.google.com/document/d/1slx4HPIbgTH-psIKMSCF-HDF9brxf-FuYhzVT9ZiIrM/edit#heading=h.8s6o9jnnxj0p E2161. Merge code for role-based reviewing with code for topic-specific rubrics], a Final Project for CSC/ECE 517, Fall 2021.
== Purpose==
In CSC/ECE 517, there are Expertiza-based course projects, Mozilla-based course projects, etc. However, currently, we can only specify one kind of rubric for all kinds of course projects. This means that refactoring projects, testing projects, and Mozilla projects need to use the same rubric. We hope we could specify different rubrics to be used with different kinds of course projects.

The project objective is to merge E2147-https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2147._Role-based_reviewing#E2147._Role-based_reviewing with the existing E2026-https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2020_-_E2026._Specialized_rubrics_for_different_topic_types. While merging, we found out that the code for E2026 has already been merged on Expertiza beta branch and so now the actual implementation is to write test cases for both E2147 and E2026.

==Brief Overview of E2147 and E2026 Projects==
*E2147(Role based reviewing): The project objective was to develop teammate review varying by the roles that each team member has in order to evaluate the particular role that each team member has taken rather than asking a generic questionnaire which was same for all the team members previously. For eg, the instructor would create a separate teammate questionnaire for developer role and for tester role respectively.
*E2026(Specialized rubrics for different topics): The project objective was to develop specialized rubrics based on project topics, previously we had same type of questionnaire for all the different types of projects. This implementation made sure that we evaluate different projects based on personalised rubrics rather than having same rubrics.

==Testing Plan==

===Test Scenarios for E2147 (Role based reviewing)===
*Only Instructor/TA/Admin should be able to create or update duties: Only the instructor/admin should be able to create or update duties. Also, the corresponding TA of the assignment should be able to create or update duties.
*Create new roles: If the assignment is role based reviewing then the instructor should be able to create new roles for the same and save it in the database using new role functionality.
*Only allow student to update duties in Student View: Only student should be able to update his duties in Student View.
*Edit existing roles: Once the new roles have been created, then the instructor should be able to edit its details such as the maximum number of each role allowed.
*Delete existing roles: The instructor should also be able to delete any roles if he wants.
*Review rubric by role: On Rubrics tab, if the instructor clicks on Review rubric by role, then the corresponding rubric roles based teammate questionnaire should appear and get saved successfully.
*Student View: If the assignment is role based assignment, then the respective students should be able to see the respective teammate questionnaire based on roles for his other team members.
*Selection of Roles: On student login, a student should be able to see the existing roles that he can take up in the project. Only the roles which are available should be shown to the student.

===Test Scenarios for E2026 (Specialized rubrics for different topics)===

As part of our implementation, we modified existing code as well as added new code. To ensure that existing functionality was not broken, and new functionality worked as expected, we used the following Test Strategy (which was also used by previous team):

===Run and pass existing RSpec Tests===
*The following existing RSpec test files have been modified and they pass as part of testing:
**spec/controllers/assignments_controller_spec.rb
**spec/controllers/questionnaires_controller_spec.rb
**spec/controllers/response_controller_spec.rb
**spec/factories/factories.rb
**spec/features/assignment_creation_spec.rb
**spec/features/quiz_spec.rb
**spec/features/staggered_deadline_spec.rb
**spec/models/assignment_form_spec.rb
**spec/models/assignment_spec.rb
**spec/models/on_the_fly_calc_spec.rb
**spec/models/response_spec.rb
**spec/models/review_response_map_spec.rb

===Develop New RSpec Tests===
*spec/helpers/duties_controller_spec.rb
*All these rspec tests passed.

== duties_controller_spec.rb ==
We have created this new test file to unit test the duties scenarios.

First we mock the data accordingly as needed by the tests.

''
describe DutiesController do
let(:assignment) { build(:assignment, id: 1,course_id: 1,instructor_id: 6, due_dates: [due_date], microtask: true, staggered_deadline: true)}
let(:admin) { build(:admin) }
let(:instructor) { build(:instructor, id: 6) }
let(:instructor2) { build(:instructor, id: 66) }
let(:ta) { build(:teaching_assistant, id: 8) }
let(:duty) { build(:duty, id: 1, duty_name: "Role", max_members_for_duty: 2, assignment_id: 1) }
let(:due_date) { build(:assignment_due_date, deadline_type_id: 1) } ''

We then run the arbitrary code that is needed before each test

''
before(:each) do
allow(Assignment).to receive(:find).with('1').and_return(assignment)
allow(Assignment).to receive(:find).with(1).and_return(assignment)
stub_current_user(instructor, instructor.role.name, instructor.role)
allow(Duty).to receive(:find).with('1').and_return(duty)
end
''

Test scenarios for duties controller:
1) Only admin, superadmin, TA, Instructor can perform edit or update action

'' describe '#action_allowed?' do ''

The whole context that defines if the action allowed is edit or update. We do this by mocking the action to edit

context 'when params action is edit or update' do
before(:each) do
controller.params = {id: '1', action: 'edit'}
end

When the current logged in user role is super admin or admin

context 'when the role name of current user is super admin or admin' do
it 'allows certain action' do
stub_current_user(admin, admin.role.name, admin.role)
expect(controller.send(:action_allowed?)).to be true
end
end

When the current logged in user role is instructor

context 'when current user is the instructor of current assignment' do
it 'allows certain action' do
expect(controller.send(:action_allowed?)).to be true
end
end

When the current logged in user role is the TA of the course

context 'when current user is the ta of the course which current assignment belongs to' do
it 'allows certain action' do
stub_current_user(ta, ta.role.name, ta.role)
allow(TaMapping).to receive(:exists?).with(ta_id: 8, course_id: 1).and_return(true)
expect(controller.send(:action_allowed?)).to be true
end
end

When the current logged in user is the instructor of the course

context 'when current user is the instructor of the course which current assignment belongs to' do
it 'allows certain action' do
stub_current_user(instructor2, instructor2.role.name, instructor2.role)
allow(Course).to receive(:find).with(1).and_return(double('Course', instructor_id: 66))
expect(controller.send(:action_allowed?)).to be true
end
end
end

When the parameter action is neither edit nor update, we do this by mocking the action to new

context 'when params action is not edit and update' do
before(:each) do
controller.params = {id: '1', action: 'new'}
end

We now check if super admin/admin/instructor/ta can perform this action which is neither edit nor update

context 'when the role current user is super admin/admin/instructor/ta' do
it 'allows certain action except edit and update' do
expect(controller.send(:action_allowed?)).to be true
end
end
end
end

And then we added few tests to test creation/edit/deletion of a duty

Creation of a duty, we create a duty and check if it is saved successfully

describe '#create' do

Checking if the right page is rendered after successful creation of a duty

context 'when new duty can be saved successfully' do
it 'sets up a new duty and redirects to assignment#edit page' do
allow(duty).to receive(:save).and_return('OK')
params = {
id: 1,
duty: {
duty_name: 'Scrum Master',
max_members_for_duty: 2,
assignment_id: 1
}
}
post :create, params
expect(response).to redirect_to('/assignments/1/edit')
expect(flash[:notice]).to match(/Role was successfully created.*/)
end
end

Test to check if the right error message is shown if the creation of duty is failed

context 'when new duty cannot be saved successfully' do
it 'shows error message and redirects to duty#new page' do
allow(duty).to receive(:errors)
params = {
id: 1,
duty: {
duty_name: 'Scrum Master',
max_members_for_duty: -1,
assignment_id: 1
}
}
post :create, params
expect(flash[:error]).to eq('Max members for duty must be greater than or equal to 1. ')
expect(response).to redirect_to('/duties/new?id=1')
end
end
end

Test to check the edit functionality of a duty

describe '#update' do

When the duty can be edited successfully, we check if the right page is rendered

context 'when duty can be found' do
it 'updates current duty and redirects to assignment#edit page' do
allow(Duty).to receive(:find).with('1').and_return(build(:duty, id: 1))
params = {
id: 1,
assignment_id: 1,
duty: {
duty_name: 'Scrum Master',
max_members_for_duty: 5,
assignment_id: 1
}
}
post :update, params
expect(response).to redirect_to('/assignments/1/edit')
expect(flash[:notice]).to match(/Role was successfully updated.*/)
end
end

When the duty cannot be updated, we check if the right error message is displayed

context 'when new duty cannot be updated successfully' do
it 'shows error message and redirects to duty#new page' do
allow(duty).to receive(:errors)
params = {
id: 1,
duty: {
duty_name: 'SM',
max_members_for_duty: 1,
assignment_id: 1
}
}
post :create, params
expect(flash[:error]).to eq('Duty name is too short (minimum is 3 characters). ')
expect(response).to redirect_to('/duties/new?id=1')
end
end
end

Now finally, we test the delete functionality of the duty

describe '#destroy' do
context 'when duty can be found' do
it 'redirects to assignment#edit page' do
params = {id: 1, assignment_id: 1}
post :destroy, params
expect(response).to redirect_to('/assignments/1/edit')
expect(flash[:notice]).to match(/Role was successfully destroyed.*/)
end
end
end

== team_users_controller_spec.rb ==

We have added a test case in this file which tests if the action is allowed only by specific user roles

First, we mock the data

''
describe TeamsUsersController do
let(:assignment) do
build(:assignment, id: 1, name: 'test assignment', instructor_id: 6, staggered_deadline: true, directory_path: 'same path',
participants: [build(:participant)], teams: [build(:assignment_team)], course_id: 1)
end
let(:assignment_form) { double('AssignmentForm', assignment: assignment) }
let(:student) { build(:student) }

before(:each) do
allow(Assignment).to receive(:find).with('1').and_return(assignment)
stub_current_user(student, student.role.name, student.role)
end
''

Then we check if the student can perform the update action for duties

''
describe '#action_allowed?' do
context 'when params action is update duties' do
before(:each) do
controller.params = {id: '1', action: 'update_duties'}
end
context 'when the role current user is student' do
it 'allows certain action' do
stub_current_user(student, student.role.name, student.role)
expect(controller.send(:action_allowed?)).to be true
end
end
end
end
''

This file also contains a test case to ensure the duties can be properly updated. The test case checks this by ensuring that the user is redirected to the student view page. just as with the previous section the first step is to mock the data by creating a team user object.

''
let(:teams_user1) {TeamsUser.new id:1, duty_id:1}
''

Then the data is actually updated and we ensure that the user is redirected to the proper place.

''
describe '#update_duties' do
it 'updates the duties for the participant' do
allow(TeamsUser).to receive(:find).with('1').and_return(teams_user1)
allow(teams_user1).to receive(:update_attribute).with(any_args).and_return('OK')
params = {
teams_user_id: '1',
teams_user: {duty_id: '1'},
participant_id: '1'
}
session = {user: stub_current_user(student, student.role.name, student.role)}
get :update_duties, params, session
expect(response).to redirect_to('/student_teams/view?student_id=1')
end
end
''

== assignment_form_spec.rb ==
The assignemnt_form_spec.rb file contains all the test files for the assignment form, which includes adding object to a queue. The first step was to create mock data so that the test could run on objects created for the tests. The code below shows how the mock data was created for the specific tests that we created to ensure the functionality of the projects.
''
let(:new_assignment_questionnaire) { build(:assignment_questionnaire) }
''
The new_assignment_questionnaire object is used for both test cases in this file. The first test case checks for when the active record cannot be found for a specific assignment id or duty id. This test case ensures no errors will happen when a user is attempting to search for this. This scenario could very easily happen and this test ensures the functionality when it cannot be found.
''
context 'when active record for assignment_questionnaire is not found for a given assignment_id and duty_id' do
it 'returns new instance of assignment_questionnaire with default values' do
allow(assignment).to receive(:questionnaire_varies_by_duty).and_return(true)
allow(AssignmentQuestionnaire).to receive(:where).with(assignment_id: 1, duty_id: anything).and_return([])
allow(AssignmentQuestionnaire).to receive(:where).with(user_id: anything, assignment_id: nil, questionnaire_id: nil).and_return([])
allow(AssignmentQuestionnaire).to receive(:new).and_return(new_assignment_questionnaire)
expect(assignment_form.assignment_questionnaire('TeammateReviewQuestionnaire', nil, nil, 1)).to eq(new_assignment_questionnaire)
end
end
''
The next next test checks when the assignment questionnaire is found given the assignment id and duty id parameters. This test is very similar to the one where the test is not found because the it searches through the active record to find the assignment questionnaire. Ensuring that this test passes will be useful because if the questionnaire cannot be returned then it will not be possible to do role based reviewing.
''
context 'when active record for assignment_questionnaire is found for a given assignment_id and duty_id' do
it 'returns new instance of assignment_questionnaire with default values' do
allow(assignment).to receive(:questionnaire_varies_by_duty).and_return(true)
allow(Questionnaire).to receive(:find).with(1).and_return(questionnaire3)
allow(AssignmentQuestionnaire).to receive(:where).with(assignment_id: 1, duty_id: 1).and_return([assignment_questionnaire2])
allow(AssignmentQuestionnaire).to receive(:where).with(user_id: anything, assignment_id: nil, questionnaire_id: nil).and_return([])
allow(AssignmentQuestionnaire).to receive(:new).and_return(new_assignment_questionnaire)
expect(assignment_form.assignment_questionnaire('TeammateReviewQuestionnaire', nil, nil, 1)).to eq(assignment_questionnaire2)
end
end
''

== duty_spec.rb ==
The main purpose of the duty_spec.rb file is to test any duty to make sure a duty can be assigned to a team member. it also tests if a duty is unavailable to a team member because the max number of people have been assigned that duty. to test this functionality the mock data is created to allow for testing of the object. The mock data is shown below which is used for all tests in this file.
''
let(:assignment) { build(:assignment, id: 1, name: 'no assgt') }
let(:participant) { build(:participant, id:1, user_id: 1) }
let(:participant2) { build(:participant, id:2, user_id: 2) }
let(:participant3) { build(:participant, id:3, user_id: 3) }
let(:user) { build(:student, id: 1, name: 'no name', fullname: 'no one', participants: [participant]) }
let(:user2) { build(:student, id: 2, name: 'no name2', fullname: 'no one2', participants: [participant2]) }
let(:user3) { build(:student, id: 3, name: 'no name3', fullname: 'no one3', participants: [participant3]) }

let(:team1) { build(:assignment_team, id: 1, name: 'no team', users: [user, user2, user3]) }
let(:sample_duty_taken) { build(:duty, id: 1, max_members_for_duty:1, assignment_id:1) }
let(:sample_duty_not_taken) { build(:duty, id: 1, max_members_for_duty:2, assignment_id:1) }

let(:team_user1) { build(:team_user, id: 1, user: user) }
let(:team_user2) { build(:team_user, id: 2, user: user2) }
let(:team_user3) { build(:team_user, id: 3, user: user3, duty_id:1) }
''
An assignment is created on which the duties can be tested. for the testing multiple users and participants are created. Finally we created team users that could be assigned duties through the duty_id field. the next step was to set up the reoccurring steps for each of the tests.
''
before(:each) do
allow(team1).to receive(:participants).and_return([participant, participant2, participant3])
allow(participant).to receive(:get_team_user).and_return(team_user1)
allow(participant2).to receive(:get_team_user).and_return(team_user2)
allow(participant3).to receive(:get_team_user).and_return(team_user3)
end
''
Finally the actual tests were implemented. The tests are fairly simple because they just need to check if the duty can be assigned or not. The first test checks to make sure a duty can be assigned to a student when the role is available. This makes sure the students will not run into a problem when the roles are assigned within the group. If the roles could not be assigned, then the specific rubrics could not be used during the reviewing phase of the project.
''
describe '#can_be_assigned?' do
context 'when users in current team want to assign roles that are available'
it 'returns true' do
expect(sample_duty_not_taken.can_be_assigned?(team1)).to be true
end
The next test case makes sure a duty cannot be assigned if there is already the max number of people assigned that role. This test case is important because if too many people are assigned that role the team dynamic will not be correct.
context 'when users in current team want to assign roles that are unavailable'
it 'returns false' do
expect(sample_duty_taken.can_be_assigned?(team1)).to be false
end
''

== teammate_review_response_map_spec.rb ==
This Rspec testing file tests that a specific questionnaire can be returned when the student has a role assigned to them. This is needed for the role based reviewing because when one student goes to review another they must get the correct questionnaire for their role. We tested this functionality as well as the inverse, when the role could not be found. initially we created the mock data for testing which is shown below.
''
let(:questionnaire) { Questionnaire.new name: "abc", private: 0, min_question_score: 0, max_question_score: 10, instructor_id: 1234 }
let(:assignment) { build(:assignment, id: 1, name: 'no assgt', is_duty_based_assignment: true, questionnaires: [questionnaire]) }
let(:assignment_questionnaire1) { build(:assignment_questionnaire, id: 1, assignment_id: 1, questionnaire_id: 2, duty_id: 1) }
let(:participant) { build(:participant, id: 1, user_id: 6, assignment: assignment) }
let(:teammate_review_response_map) { TeammateReviewResponseMap.new reviewer: participant, reviewer_is_team: true, assignment:assignment }
''
This step created the review response map that we would be testing as well as and assignment which contained a questionnaire. The next step was to actually test the data. First we decided to ensure that the correct questionnaire was returned with the following test. It compares the returned questionnaire with the one we know is correct.
''
it 'returns questionnaire specific to a duty' do
allow(AssignmentQuestionnaire).to receive(:where).with(assignment_id: 1, duty_id: 1).and_return([assignment_questionnaire1])
allow(Questionnaire).to receive(:find).with(assignment_questionnaire1.questionnaire_id).and_return(questionnaire)
expect(teammate_review_response_map.questionnaire_by_duty(1)).to eq questionnaire
end
''
Finally we added the inverse for when there was an error returning the questionnaire. in this case the program should return the default questionnaire.
''
it 'returns default questionnaire when no questionnaire is found for duty' do
allow(AssignmentQuestionnaire).to receive(:where).with(assignment_id: 1, duty_id: 1).and_return([])
allow(assignment.questionnaires).to receive(:find_by).with(type: 'TeammateReviewQuestionnaire').and_return(questionnaire)
expect(teammate_review_response_map.questionnaire_by_duty(1)).to eq questionnaire
end
''

== Manual Testing in Expertiza UI ==
Here we describe manual UI Testing steps to edit an existing assignment to allow it have to specialized rubrics for different topic types. These steps are also shown in recorded demo video.
*Login to Expertiza using instructor account (For testing, username: '''instructor6''', password: '''password''')
*Click on Manage > Assignments
*Click on Edit option for any assignment, you should get following view. Make sure '''Has topics?''' box is checked.
[[File:Assignment edit 3.png]]
*Click on Rubrics tab. You will see 2 checkboxes ('''Review rubric varies by round?''', '''Review rubric varies by topic?''')
*Check the box for '''Review rubric varies by topic?'''
*Go to Topics tab and verify that there is dropdown menu beside each Topic.
*Select a rubric from dropdown menu, and click '''Save'''
[[File:Topics rubric 2.png]]
*Go back to Home, and select the same assignment to edit. When you click on Topics tab, you should see the rubric you had selected.

==Team Information==
* Naman Shrimali
* Kanchan Rawat
* Subodh Thota
* Andrew Shipman
Mentor : Prof. Edward F. Gehringer

CSC/ECE 517 Fall 2021 - E2161. Merge code for role based reviewing with code for topic specific rubrics

2021-11-29T14:13:08Z

Ajshipma: /* assignment_form_spec.rb */

This wiki page contains description of changes designed and implemented for [https://docs.google.com/document/d/1slx4HPIbgTH-psIKMSCF-HDF9brxf-FuYhzVT9ZiIrM/edit#heading=h.8s6o9jnnxj0p E2161. Merge code for role-based reviewing with code for topic-specific rubrics], a Final Project for CSC/ECE 517, Fall 2021.
== Purpose==
In CSC/ECE 517, there are Expertiza-based course projects, Mozilla-based course projects, etc. However, currently, we can only specify one kind of rubric for all kinds of course projects. This means that refactoring projects, testing projects, and Mozilla projects need to use the same rubric. We hope we could specify different rubrics to be used with different kinds of course projects.

The project objective is to merge E2147-https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2147._Role-based_reviewing#E2147._Role-based_reviewing with the existing E2026-https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2020_-_E2026._Specialized_rubrics_for_different_topic_types. While merging, we found out that the code for E2026 has already been merged on Expertiza beta branch and so now the actual implementation is to write test cases for both E2147 and E2026.

==Brief Overview of E2147 and E2026 Projects==
*E2147(Role based reviewing): The project objective was to develop teammate review varying by the roles that each team member has in order to evaluate the particular role that each team member has taken rather than asking a generic questionnaire which was same for all the team members previously. For eg, the instructor would create a separate teammate questionnaire for developer role and for tester role respectively.
*E2026(Specialized rubrics for different topics): The project objective was to develop specialized rubrics based on project topics, previously we had same type of questionnaire for all the different types of projects. This implementation made sure that we evaluate different projects based on personalised rubrics rather than having same rubrics.

==Testing Plan==

===Test Scenarios for E2147 (Role based reviewing)===
*Only Instructor/TA/Admin should be able to create or update duties: Only the instructor/admin should be able to create or update duties. Also, the corresponding TA of the assignment should be able to create or update duties.
*Create new roles: If the assignment is role based reviewing then the instructor should be able to create new roles for the same and save it in the database using new role functionality.
*Only allow student to update duties in Student View: Only student should be able to update his duties in Student View.
*Edit existing roles: Once the new roles have been created, then the instructor should be able to edit its details such as the maximum number of each role allowed.
*Delete existing roles: The instructor should also be able to delete any roles if he wants.
*Review rubric by role: On Rubrics tab, if the instructor clicks on Review rubric by role, then the corresponding rubric roles based teammate questionnaire should appear and get saved successfully.
*Student View: If the assignment is role based assignment, then the respective students should be able to see the respective teammate questionnaire based on roles for his other team members.
*Selection of Roles: On student login, a student should be able to see the existing roles that he can take up in the project. Only the roles which are available should be shown to the student.

===Test Scenarios for E2026 (Specialized rubrics for different topics)===

As part of our implementation, we modified existing code as well as added new code. To ensure that existing functionality was not broken, and new functionality worked as expected, we used the following Test Strategy (which was also used by previous team):

===Run and pass existing RSpec Tests===
*The following existing RSpec test files have been modified and they pass as part of testing:
**spec/controllers/assignments_controller_spec.rb
**spec/controllers/questionnaires_controller_spec.rb
**spec/controllers/response_controller_spec.rb
**spec/factories/factories.rb
**spec/features/assignment_creation_spec.rb
**spec/features/quiz_spec.rb
**spec/features/staggered_deadline_spec.rb
**spec/models/assignment_form_spec.rb
**spec/models/assignment_spec.rb
**spec/models/on_the_fly_calc_spec.rb
**spec/models/response_spec.rb
**spec/models/review_response_map_spec.rb

===Develop New RSpec Tests===
*spec/helpers/duties_controller_spec.rb
*All these rspec tests passed.

== duties_controller_spec.rb ==
We have created this new test file to unit test the duties scenarios.

First we mock the data accordingly as needed by the tests.

''
describe DutiesController do
let(:assignment) { build(:assignment, id: 1,course_id: 1,instructor_id: 6, due_dates: [due_date], microtask: true, staggered_deadline: true)}
let(:admin) { build(:admin) }
let(:instructor) { build(:instructor, id: 6) }
let(:instructor2) { build(:instructor, id: 66) }
let(:ta) { build(:teaching_assistant, id: 8) }
let(:duty) { build(:duty, id: 1, duty_name: "Role", max_members_for_duty: 2, assignment_id: 1) }
let(:due_date) { build(:assignment_due_date, deadline_type_id: 1) } ''

We then run the arbitrary code that is needed before each test

''
before(:each) do
allow(Assignment).to receive(:find).with('1').and_return(assignment)
allow(Assignment).to receive(:find).with(1).and_return(assignment)
stub_current_user(instructor, instructor.role.name, instructor.role)
allow(Duty).to receive(:find).with('1').and_return(duty)
end
''

Test scenarios for duties controller:
1) Only admin, superadmin, TA, Instructor can perform edit or update action

'' describe '#action_allowed?' do ''

The whole context that defines if the action allowed is edit or update. We do this by mocking the action to edit

context 'when params action is edit or update' do
before(:each) do
controller.params = {id: '1', action: 'edit'}
end

When the current logged in user role is super admin or admin

context 'when the role name of current user is super admin or admin' do
it 'allows certain action' do
stub_current_user(admin, admin.role.name, admin.role)
expect(controller.send(:action_allowed?)).to be true
end
end

When the current logged in user role is instructor

context 'when current user is the instructor of current assignment' do
it 'allows certain action' do
expect(controller.send(:action_allowed?)).to be true
end
end

When the current logged in user role is the TA of the course

context 'when current user is the ta of the course which current assignment belongs to' do
it 'allows certain action' do
stub_current_user(ta, ta.role.name, ta.role)
allow(TaMapping).to receive(:exists?).with(ta_id: 8, course_id: 1).and_return(true)
expect(controller.send(:action_allowed?)).to be true
end
end

When the current logged in user is the instructor of the course

context 'when current user is the instructor of the course which current assignment belongs to' do
it 'allows certain action' do
stub_current_user(instructor2, instructor2.role.name, instructor2.role)
allow(Course).to receive(:find).with(1).and_return(double('Course', instructor_id: 66))
expect(controller.send(:action_allowed?)).to be true
end
end
end

When the parameter action is neither edit nor update, we do this by mocking the action to new

context 'when params action is not edit and update' do
before(:each) do
controller.params = {id: '1', action: 'new'}
end

We now check if super admin/admin/instructor/ta can perform this action which is neither edit nor update

context 'when the role current user is super admin/admin/instructor/ta' do
it 'allows certain action except edit and update' do
expect(controller.send(:action_allowed?)).to be true
end
end
end
end

And then we added few tests to test creation/edit/deletion of a duty

Creation of a duty, we create a duty and check if it is saved successfully

describe '#create' do

Checking if the right page is rendered after successful creation of a duty

context 'when new duty can be saved successfully' do
it 'sets up a new duty and redirects to assignment#edit page' do
allow(duty).to receive(:save).and_return('OK')
params = {
id: 1,
duty: {
duty_name: 'Scrum Master',
max_members_for_duty: 2,
assignment_id: 1
}
}
post :create, params
expect(response).to redirect_to('/assignments/1/edit')
expect(flash[:notice]).to match(/Role was successfully created.*/)
end
end

Test to check if the right error message is shown if the creation of duty is failed

context 'when new duty cannot be saved successfully' do
it 'shows error message and redirects to duty#new page' do
allow(duty).to receive(:errors)
params = {
id: 1,
duty: {
duty_name: 'Scrum Master',
max_members_for_duty: -1,
assignment_id: 1
}
}
post :create, params
expect(flash[:error]).to eq('Max members for duty must be greater than or equal to 1. ')
expect(response).to redirect_to('/duties/new?id=1')
end
end
end

Test to check the edit functionality of a duty

describe '#update' do

When the duty can be edited successfully, we check if the right page is rendered

context 'when duty can be found' do
it 'updates current duty and redirects to assignment#edit page' do
allow(Duty).to receive(:find).with('1').and_return(build(:duty, id: 1))
params = {
id: 1,
assignment_id: 1,
duty: {
duty_name: 'Scrum Master',
max_members_for_duty: 5,
assignment_id: 1
}
}
post :update, params
expect(response).to redirect_to('/assignments/1/edit')
expect(flash[:notice]).to match(/Role was successfully updated.*/)
end
end

When the duty cannot be updated, we check if the right error message is displayed

context 'when new duty cannot be updated successfully' do
it 'shows error message and redirects to duty#new page' do
allow(duty).to receive(:errors)
params = {
id: 1,
duty: {
duty_name: 'SM',
max_members_for_duty: 1,
assignment_id: 1
}
}
post :create, params
expect(flash[:error]).to eq('Duty name is too short (minimum is 3 characters). ')
expect(response).to redirect_to('/duties/new?id=1')
end
end
end

Now finally, we test the delete functionality of the duty

describe '#destroy' do
context 'when duty can be found' do
it 'redirects to assignment#edit page' do
params = {id: 1, assignment_id: 1}
post :destroy, params
expect(response).to redirect_to('/assignments/1/edit')
expect(flash[:notice]).to match(/Role was successfully destroyed.*/)
end
end
end

== team_users_controller_spec.rb ==

We have added a test case in this file which tests if the action is allowed only by specific user roles

First, we mock the data

''
describe TeamsUsersController do
let(:assignment) do
build(:assignment, id: 1, name: 'test assignment', instructor_id: 6, staggered_deadline: true, directory_path: 'same path',
participants: [build(:participant)], teams: [build(:assignment_team)], course_id: 1)
end
let(:assignment_form) { double('AssignmentForm', assignment: assignment) }
let(:student) { build(:student) }

before(:each) do
allow(Assignment).to receive(:find).with('1').and_return(assignment)
stub_current_user(student, student.role.name, student.role)
end
''

Then we check if the student can perform the update action for duties

''
describe '#action_allowed?' do
context 'when params action is update duties' do
before(:each) do
controller.params = {id: '1', action: 'update_duties'}
end
context 'when the role current user is student' do
it 'allows certain action' do
stub_current_user(student, student.role.name, student.role)
expect(controller.send(:action_allowed?)).to be true
end
end
end
end
''

This file also contains a test case to ensure the duties can be properly updated. The test case checks this by ensuring that the user is redirected to the student view page. just as with the previous section the first step is to mock the data by creating a team user object.

''
let(:teams_user1) {TeamsUser.new id:1, duty_id:1}
''

Then the data is actually updated and we ensure that the user is redirected to the proper place.

''
describe '#update_duties' do
it 'updates the duties for the participant' do
allow(TeamsUser).to receive(:find).with('1').and_return(teams_user1)
allow(teams_user1).to receive(:update_attribute).with(any_args).and_return('OK')
params = {
teams_user_id: '1',
teams_user: {duty_id: '1'},
participant_id: '1'
}
session = {user: stub_current_user(student, student.role.name, student.role)}
get :update_duties, params, session
expect(response).to redirect_to('/student_teams/view?student_id=1')
end
end
''

== assignment_form_spec.rb ==
The assignemnt_form_spec.rb file contains all the test files for the assignment form, which includes adding object to a queue. The first step was to create mock data so that the test could run on objects created for the tests. The code below shows how the mock data was created for the specific tests that we created to ensure the functionality of the projects.
''
let(:new_assignment_questionnaire) { build(:assignment_questionnaire) }
''
The new_assignment_questionnaire object is used for both test cases in this file. The first test case checks for when the active record cannot be found for a specific assignment id or duty id. This test case ensures no errors will happen when a user is attempting to search for this. This scenario could very easily happen and this test ensures the functionality when it cannot be found.
''
context 'when active record for assignment_questionnaire is not found for a given assignment_id and duty_id' do
it 'returns new instance of assignment_questionnaire with default values' do
allow(assignment).to receive(:questionnaire_varies_by_duty).and_return(true)
allow(AssignmentQuestionnaire).to receive(:where).with(assignment_id: 1, duty_id: anything).and_return([])
allow(AssignmentQuestionnaire).to receive(:where).with(user_id: anything, assignment_id: nil, questionnaire_id: nil).and_return([])
allow(AssignmentQuestionnaire).to receive(:new).and_return(new_assignment_questionnaire)
expect(assignment_form.assignment_questionnaire('TeammateReviewQuestionnaire', nil, nil, 1)).to eq(new_assignment_questionnaire)
end
end
''
The next next test checks when the assignment questionnaire is found given the assignment id and duty id parameters. This test is very similar to the one where the test is not found because the it searches through the active record to find the assignment questionnaire. Ensuring that this test passes will be useful because if the questionnaire cannot be returned then it will not be possible to do role based reviewing.
''
context 'when active record for assignment_questionnaire is found for a given assignment_id and duty_id' do
it 'returns new instance of assignment_questionnaire with default values' do
allow(assignment).to receive(:questionnaire_varies_by_duty).and_return(true)
allow(Questionnaire).to receive(:find).with(1).and_return(questionnaire3)
allow(AssignmentQuestionnaire).to receive(:where).with(assignment_id: 1, duty_id: 1).and_return([assignment_questionnaire2])
allow(AssignmentQuestionnaire).to receive(:where).with(user_id: anything, assignment_id: nil, questionnaire_id: nil).and_return([])
allow(AssignmentQuestionnaire).to receive(:new).and_return(new_assignment_questionnaire)
expect(assignment_form.assignment_questionnaire('TeammateReviewQuestionnaire', nil, nil, 1)).to eq(assignment_questionnaire2)
end
end
''

== duty_spec.rb ==
the main purpose of the duty_spec.rb file is to test any duty to make sure a duty can be assigned to a team member. it also tests if a duty is unavailable to a team member because the max number of people have been assigned that duty. to test this functionality the mock data is created to allow for testing of the objcect.
''
let(:assignment) { build(:assignment, id: 1, name: 'no assgt') }
let(:participant) { build(:participant, id:1, user_id: 1) }
let(:participant2) { build(:participant, id:2, user_id: 2) }
let(:participant3) { build(:participant, id:3, user_id: 3) }
let(:user) { build(:student, id: 1, name: 'no name', fullname: 'no one', participants: [participant]) }
let(:user2) { build(:student, id: 2, name: 'no name2', fullname: 'no one2', participants: [participant2]) }
let(:user3) { build(:student, id: 3, name: 'no name3', fullname: 'no one3', participants: [participant3]) }

let(:team1) { build(:assignment_team, id: 1, name: 'no team', users: [user, user2, user3]) }
let(:sample_duty_taken) { build(:duty, id: 1, max_members_for_duty:1, assignment_id:1) }
let(:sample_duty_not_taken) { build(:duty, id: 1, max_members_for_duty:2, assignment_id:1) }

let(:team_user1) { build(:team_user, id: 1, user: user) }
let(:team_user2) { build(:team_user, id: 2, user: user2) }
let(:team_user3) { build(:team_user, id: 3, user: user3, duty_id:1) }
''
an assignment is created on which the duties can be tested. for the testing multiple users and participants are created. Finally we created team users that could be assigned duties through the duty_id field. the next step was to set up the reoccurring steps for each of the tests.
''
before(:each) do
allow(team1).to receive(:participants).and_return([participant, participant2, participant3])
allow(participant).to receive(:get_team_user).and_return(team_user1)
allow(participant2).to receive(:get_team_user).and_return(team_user2)
allow(participant3).to receive(:get_team_user).and_return(team_user3)
end
''
Finally the actual tests were implemented. The tests are fairly simple because they just need to check if the duty can be assigned or not.
''
describe '#can_be_assigned?' do
context 'when users in current team want to assign roles that are available'
it 'returns true' do
expect(sample_duty_not_taken.can_be_assigned?(team1)).to be true
end
context 'when users in current team want to assign roles that are unavailable'
it 'returns false' do
expect(sample_duty_taken.can_be_assigned?(team1)).to be false
end
''

== teammate_review_response_map_spec.rb ==
This Rspec testing file tests that a specific questionnaire can be returned when the student has a role assigned to them. This is needed for the role based reviewing because when one student goes to review another they must get the correct questionnaire for their role. We tested this functionality as well as the inverse, when the role could not be found. initially we created the mock data for testing which is shown below.
''
let(:questionnaire) { Questionnaire.new name: "abc", private: 0, min_question_score: 0, max_question_score: 10, instructor_id: 1234 }
let(:assignment) { build(:assignment, id: 1, name: 'no assgt', is_duty_based_assignment: true, questionnaires: [questionnaire]) }
let(:assignment_questionnaire1) { build(:assignment_questionnaire, id: 1, assignment_id: 1, questionnaire_id: 2, duty_id: 1) }
let(:participant) { build(:participant, id: 1, user_id: 6, assignment: assignment) }
let(:teammate_review_response_map) { TeammateReviewResponseMap.new reviewer: participant, reviewer_is_team: true, assignment:assignment }
''
This step created the review response map that we would be testing as well as and assignment which contained a questionnaire. The next step was to actually test the data. First we decided to ensure that the correct questionnaire was returned with the following test. It compares the returned questionnaire with the one we know is correct.
''
it 'returns questionnaire specific to a duty' do
allow(AssignmentQuestionnaire).to receive(:where).with(assignment_id: 1, duty_id: 1).and_return([assignment_questionnaire1])
allow(Questionnaire).to receive(:find).with(assignment_questionnaire1.questionnaire_id).and_return(questionnaire)
expect(teammate_review_response_map.questionnaire_by_duty(1)).to eq questionnaire
end
''
Finally we added the inverse for when there was an error returning the questionnaire. in this case the program should return the default questionnaire.
''
it 'returns default questionnaire when no questionnaire is found for duty' do
allow(AssignmentQuestionnaire).to receive(:where).with(assignment_id: 1, duty_id: 1).and_return([])
allow(assignment.questionnaires).to receive(:find_by).with(type: 'TeammateReviewQuestionnaire').and_return(questionnaire)
expect(teammate_review_response_map.questionnaire_by_duty(1)).to eq questionnaire
end
''

== Manual Testing in Expertiza UI ==
Here we describe manual UI Testing steps to edit an existing assignment to allow it have to specialized rubrics for different topic types. These steps are also shown in recorded demo video.
*Login to Expertiza using instructor account (For testing, username: '''instructor6''', password: '''password''')
*Click on Manage > Assignments
*Click on Edit option for any assignment, you should get following view. Make sure '''Has topics?''' box is checked.
[[File:Assignment edit 3.png]]
*Click on Rubrics tab. You will see 2 checkboxes ('''Review rubric varies by round?''', '''Review rubric varies by topic?''')
*Check the box for '''Review rubric varies by topic?'''
*Go to Topics tab and verify that there is dropdown menu beside each Topic.
*Select a rubric from dropdown menu, and click '''Save'''
[[File:Topics rubric 2.png]]
*Go back to Home, and select the same assignment to edit. When you click on Topics tab, you should see the rubric you had selected.

==Team Information==
* Naman Shrimali
* Kanchan Rawat
* Subodh Thota
* Andrew Shipman
Mentor : Prof. Edward F. Gehringer

CSC/ECE 517 Fall 2021 - E2161. Merge code for role based reviewing with code for topic specific rubrics

2021-11-29T14:05:59Z

Ajshipma: /* assignment_form_spec.rb */

This wiki page contains description of changes designed and implemented for [https://docs.google.com/document/d/1slx4HPIbgTH-psIKMSCF-HDF9brxf-FuYhzVT9ZiIrM/edit#heading=h.8s6o9jnnxj0p E2161. Merge code for role-based reviewing with code for topic-specific rubrics], a Final Project for CSC/ECE 517, Fall 2021.
== Purpose==
In CSC/ECE 517, there are Expertiza-based course projects, Mozilla-based course projects, etc. However, currently, we can only specify one kind of rubric for all kinds of course projects. This means that refactoring projects, testing projects, and Mozilla projects need to use the same rubric. We hope we could specify different rubrics to be used with different kinds of course projects.

The project objective is to merge E2147-https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2147._Role-based_reviewing#E2147._Role-based_reviewing with the existing E2026-https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2020_-_E2026._Specialized_rubrics_for_different_topic_types. While merging, we found out that the code for E2026 has already been merged on Expertiza beta branch and so now the actual implementation is to write test cases for both E2147 and E2026.

==Brief Overview of E2147 and E2026 Projects==
*E2147(Role based reviewing): The project objective was to develop teammate review varying by the roles that each team member has in order to evaluate the particular role that each team member has taken rather than asking a generic questionnaire which was same for all the team members previously. For eg, the instructor would create a separate teammate questionnaire for developer role and for tester role respectively.
*E2026(Specialized rubrics for different topics): The project objective was to develop specialized rubrics based on project topics, previously we had same type of questionnaire for all the different types of projects. This implementation made sure that we evaluate different projects based on personalised rubrics rather than having same rubrics.

==Testing Plan==

===Test Scenarios for E2147 (Role based reviewing)===
*Only Instructor/TA/Admin should be able to create or update duties: Only the instructor/admin should be able to create or update duties. Also, the corresponding TA of the assignment should be able to create or update duties.
*Create new roles: If the assignment is role based reviewing then the instructor should be able to create new roles for the same and save it in the database using new role functionality.
*Only allow student to update duties in Student View: Only student should be able to update his duties in Student View.
*Edit existing roles: Once the new roles have been created, then the instructor should be able to edit its details such as the maximum number of each role allowed.
*Delete existing roles: The instructor should also be able to delete any roles if he wants.
*Review rubric by role: On Rubrics tab, if the instructor clicks on Review rubric by role, then the corresponding rubric roles based teammate questionnaire should appear and get saved successfully.
*Student View: If the assignment is role based assignment, then the respective students should be able to see the respective teammate questionnaire based on roles for his other team members.
*Selection of Roles: On student login, a student should be able to see the existing roles that he can take up in the project. Only the roles which are available should be shown to the student.

===Test Scenarios for E2026 (Specialized rubrics for different topics)===

As part of our implementation, we modified existing code as well as added new code. To ensure that existing functionality was not broken, and new functionality worked as expected, we used the following Test Strategy (which was also used by previous team):

===Run and pass existing RSpec Tests===
*The following existing RSpec test files have been modified and they pass as part of testing:
**spec/controllers/assignments_controller_spec.rb
**spec/controllers/questionnaires_controller_spec.rb
**spec/controllers/response_controller_spec.rb
**spec/factories/factories.rb
**spec/features/assignment_creation_spec.rb
**spec/features/quiz_spec.rb
**spec/features/staggered_deadline_spec.rb
**spec/models/assignment_form_spec.rb
**spec/models/assignment_spec.rb
**spec/models/on_the_fly_calc_spec.rb
**spec/models/response_spec.rb
**spec/models/review_response_map_spec.rb

===Develop New RSpec Tests===
*spec/helpers/duties_controller_spec.rb
*All these rspec tests passed.

== duties_controller_spec.rb ==
We have created this new test file to unit test the duties scenarios.

First we mock the data accordingly as needed by the tests.

''
describe DutiesController do
let(:assignment) { build(:assignment, id: 1,course_id: 1,instructor_id: 6, due_dates: [due_date], microtask: true, staggered_deadline: true)}
let(:admin) { build(:admin) }
let(:instructor) { build(:instructor, id: 6) }
let(:instructor2) { build(:instructor, id: 66) }
let(:ta) { build(:teaching_assistant, id: 8) }
let(:duty) { build(:duty, id: 1, duty_name: "Role", max_members_for_duty: 2, assignment_id: 1) }
let(:due_date) { build(:assignment_due_date, deadline_type_id: 1) } ''

We then run the arbitrary code that is needed before each test

''
before(:each) do
allow(Assignment).to receive(:find).with('1').and_return(assignment)
allow(Assignment).to receive(:find).with(1).and_return(assignment)
stub_current_user(instructor, instructor.role.name, instructor.role)
allow(Duty).to receive(:find).with('1').and_return(duty)
end
''

Test scenarios for duties controller:
1) Only admin, superadmin, TA, Instructor can perform edit or update action

'' describe '#action_allowed?' do ''

The whole context that defines if the action allowed is edit or update. We do this by mocking the action to edit

context 'when params action is edit or update' do
before(:each) do
controller.params = {id: '1', action: 'edit'}
end

When the current logged in user role is super admin or admin

context 'when the role name of current user is super admin or admin' do
it 'allows certain action' do
stub_current_user(admin, admin.role.name, admin.role)
expect(controller.send(:action_allowed?)).to be true
end
end

When the current logged in user role is instructor

context 'when current user is the instructor of current assignment' do
it 'allows certain action' do
expect(controller.send(:action_allowed?)).to be true
end
end

When the current logged in user role is the TA of the course

context 'when current user is the ta of the course which current assignment belongs to' do
it 'allows certain action' do
stub_current_user(ta, ta.role.name, ta.role)
allow(TaMapping).to receive(:exists?).with(ta_id: 8, course_id: 1).and_return(true)
expect(controller.send(:action_allowed?)).to be true
end
end

When the current logged in user is the instructor of the course

context 'when current user is the instructor of the course which current assignment belongs to' do
it 'allows certain action' do
stub_current_user(instructor2, instructor2.role.name, instructor2.role)
allow(Course).to receive(:find).with(1).and_return(double('Course', instructor_id: 66))
expect(controller.send(:action_allowed?)).to be true
end
end
end

When the parameter action is neither edit nor update, we do this by mocking the action to new

context 'when params action is not edit and update' do
before(:each) do
controller.params = {id: '1', action: 'new'}
end

We now check if super admin/admin/instructor/ta can perform this action which is neither edit nor update

context 'when the role current user is super admin/admin/instructor/ta' do
it 'allows certain action except edit and update' do
expect(controller.send(:action_allowed?)).to be true
end
end
end
end

And then we added few tests to test creation/edit/deletion of a duty

Creation of a duty, we create a duty and check if it is saved successfully

describe '#create' do

Checking if the right page is rendered after successful creation of a duty

context 'when new duty can be saved successfully' do
it 'sets up a new duty and redirects to assignment#edit page' do
allow(duty).to receive(:save).and_return('OK')
params = {
id: 1,
duty: {
duty_name: 'Scrum Master',
max_members_for_duty: 2,
assignment_id: 1
}
}
post :create, params
expect(response).to redirect_to('/assignments/1/edit')
expect(flash[:notice]).to match(/Role was successfully created.*/)
end
end

Test to check if the right error message is shown if the creation of duty is failed

context 'when new duty cannot be saved successfully' do
it 'shows error message and redirects to duty#new page' do
allow(duty).to receive(:errors)
params = {
id: 1,
duty: {
duty_name: 'Scrum Master',
max_members_for_duty: -1,
assignment_id: 1
}
}
post :create, params
expect(flash[:error]).to eq('Max members for duty must be greater than or equal to 1. ')
expect(response).to redirect_to('/duties/new?id=1')
end
end
end

Test to check the edit functionality of a duty

describe '#update' do

When the duty can be edited successfully, we check if the right page is rendered

context 'when duty can be found' do
it 'updates current duty and redirects to assignment#edit page' do
allow(Duty).to receive(:find).with('1').and_return(build(:duty, id: 1))
params = {
id: 1,
assignment_id: 1,
duty: {
duty_name: 'Scrum Master',
max_members_for_duty: 5,
assignment_id: 1
}
}
post :update, params
expect(response).to redirect_to('/assignments/1/edit')
expect(flash[:notice]).to match(/Role was successfully updated.*/)
end
end

When the duty cannot be updated, we check if the right error message is displayed

context 'when new duty cannot be updated successfully' do
it 'shows error message and redirects to duty#new page' do
allow(duty).to receive(:errors)
params = {
id: 1,
duty: {
duty_name: 'SM',
max_members_for_duty: 1,
assignment_id: 1
}
}
post :create, params
expect(flash[:error]).to eq('Duty name is too short (minimum is 3 characters). ')
expect(response).to redirect_to('/duties/new?id=1')
end
end
end

Now finally, we test the delete functionality of the duty

describe '#destroy' do
context 'when duty can be found' do
it 'redirects to assignment#edit page' do
params = {id: 1, assignment_id: 1}
post :destroy, params
expect(response).to redirect_to('/assignments/1/edit')
expect(flash[:notice]).to match(/Role was successfully destroyed.*/)
end
end
end

== team_users_controller_spec.rb ==

We have added a test case in this file which tests if the action is allowed only by specific user roles

First, we mock the data

''
describe TeamsUsersController do
let(:assignment) do
build(:assignment, id: 1, name: 'test assignment', instructor_id: 6, staggered_deadline: true, directory_path: 'same path',
participants: [build(:participant)], teams: [build(:assignment_team)], course_id: 1)
end
let(:assignment_form) { double('AssignmentForm', assignment: assignment) }
let(:student) { build(:student) }

before(:each) do
allow(Assignment).to receive(:find).with('1').and_return(assignment)
stub_current_user(student, student.role.name, student.role)
end
''

Then we check if the student can perform the update action for duties

''
describe '#action_allowed?' do
context 'when params action is update duties' do
before(:each) do
controller.params = {id: '1', action: 'update_duties'}
end
context 'when the role current user is student' do
it 'allows certain action' do
stub_current_user(student, student.role.name, student.role)
expect(controller.send(:action_allowed?)).to be true
end
end
end
end
''

This file also contains a test case to ensure the duties can be properly updated. The test case checks this by ensuring that the user is redirected to the student view page. just as with the previous section the first step is to mock the data by creating a team user object.

''
let(:teams_user1) {TeamsUser.new id:1, duty_id:1}
''

Then the data is actually updated and we ensure that the user is redirected to the proper place.

''
describe '#update_duties' do
it 'updates the duties for the participant' do
allow(TeamsUser).to receive(:find).with('1').and_return(teams_user1)
allow(teams_user1).to receive(:update_attribute).with(any_args).and_return('OK')
params = {
teams_user_id: '1',
teams_user: {duty_id: '1'},
participant_id: '1'
}
session = {user: stub_current_user(student, student.role.name, student.role)}
get :update_duties, params, session
expect(response).to redirect_to('/student_teams/view?student_id=1')
end
end
''

== assignment_form_spec.rb ==
The assignemnt_form_spec.rb file contains all the test files for the assignment form, which includes adding object to a queue. The first step was to create mock data so that the test could run on objects created for the tests. The code below shows how the mock data was created for the specific tests that we created to ensure the functionality of the projects.
''
let(:new_assignment_questionnaire) { build(:assignment_questionnaire) }
''
The new_assignment_questionnaire object is used for both test cases in this file. The first test case checks for when the active record cannot be found for a specific assignment id or duty id.
''
context 'when active record for assignment_questionnaire is not found for a given assignment_id and duty_id' do
it 'returns new instance of assignment_questionnaire with default values' do
allow(assignment).to receive(:questionnaire_varies_by_duty).and_return(true)
allow(AssignmentQuestionnaire).to receive(:where).with(assignment_id: 1, duty_id: anything).and_return([])
allow(AssignmentQuestionnaire).to receive(:where).with(user_id: anything, assignment_id: nil, questionnaire_id: nil).and_return([])
allow(AssignmentQuestionnaire).to receive(:new).and_return(new_assignment_questionnaire)
expect(assignment_form.assignment_questionnaire('TeammateReviewQuestionnaire', nil, nil, 1)).to eq(new_assignment_questionnaire)
end
end
''
The next next test checks when the assignment questionnaire is found given the assignment id and duty id parameters. This test is very similar to the one where the test is not found because the it searches through the active record to find the assignment questionnaire.
''
context 'when active record for assignment_questionnaire is found for a given assignment_id and duty_id' do
it 'returns new instance of assignment_questionnaire with default values' do
allow(assignment).to receive(:questionnaire_varies_by_duty).and_return(true)
allow(Questionnaire).to receive(:find).with(1).and_return(questionnaire3)
allow(AssignmentQuestionnaire).to receive(:where).with(assignment_id: 1, duty_id: 1).and_return([assignment_questionnaire2])
allow(AssignmentQuestionnaire).to receive(:where).with(user_id: anything, assignment_id: nil, questionnaire_id: nil).and_return([])
allow(AssignmentQuestionnaire).to receive(:new).and_return(new_assignment_questionnaire)
expect(assignment_form.assignment_questionnaire('TeammateReviewQuestionnaire', nil, nil, 1)).to eq(assignment_questionnaire2)
end
end
''

== duty_spec.rb ==
the main purpose of the duty_spec.rb file is to test any duty to make sure a duty can be assigned to a team member. it also tests if a duty is unavailable to a team member because the max number of people have been assigned that duty. to test this functionality the mock data is created to allow for testing of the objcect.
''
let(:assignment) { build(:assignment, id: 1, name: 'no assgt') }
let(:participant) { build(:participant, id:1, user_id: 1) }
let(:participant2) { build(:participant, id:2, user_id: 2) }
let(:participant3) { build(:participant, id:3, user_id: 3) }
let(:user) { build(:student, id: 1, name: 'no name', fullname: 'no one', participants: [participant]) }
let(:user2) { build(:student, id: 2, name: 'no name2', fullname: 'no one2', participants: [participant2]) }
let(:user3) { build(:student, id: 3, name: 'no name3', fullname: 'no one3', participants: [participant3]) }

let(:team1) { build(:assignment_team, id: 1, name: 'no team', users: [user, user2, user3]) }
let(:sample_duty_taken) { build(:duty, id: 1, max_members_for_duty:1, assignment_id:1) }
let(:sample_duty_not_taken) { build(:duty, id: 1, max_members_for_duty:2, assignment_id:1) }

let(:team_user1) { build(:team_user, id: 1, user: user) }
let(:team_user2) { build(:team_user, id: 2, user: user2) }
let(:team_user3) { build(:team_user, id: 3, user: user3, duty_id:1) }
''
an assignment is created on which the duties can be tested. for the testing multiple users and participants are created. Finally we created team users that could be assigned duties through the duty_id field. the next step was to set up the reoccurring steps for each of the tests.
''
before(:each) do
allow(team1).to receive(:participants).and_return([participant, participant2, participant3])
allow(participant).to receive(:get_team_user).and_return(team_user1)
allow(participant2).to receive(:get_team_user).and_return(team_user2)
allow(participant3).to receive(:get_team_user).and_return(team_user3)
end
''
Finally the actual tests were implemented. The tests are fairly simple because they just need to check if the duty can be assigned or not.
''
describe '#can_be_assigned?' do
context 'when users in current team want to assign roles that are available'
it 'returns true' do
expect(sample_duty_not_taken.can_be_assigned?(team1)).to be true
end
context 'when users in current team want to assign roles that are unavailable'
it 'returns false' do
expect(sample_duty_taken.can_be_assigned?(team1)).to be false
end
''

== teammate_review_response_map_spec.rb ==
This Rspec testing file tests that a specific questionnaire can be returned when the student has a role assigned to them. This is needed for the role based reviewing because when one student goes to review another they must get the correct questionnaire for their role. We tested this functionality as well as the inverse, when the role could not be found. initially we created the mock data for testing which is shown below.
''
let(:questionnaire) { Questionnaire.new name: "abc", private: 0, min_question_score: 0, max_question_score: 10, instructor_id: 1234 }
let(:assignment) { build(:assignment, id: 1, name: 'no assgt', is_duty_based_assignment: true, questionnaires: [questionnaire]) }
let(:assignment_questionnaire1) { build(:assignment_questionnaire, id: 1, assignment_id: 1, questionnaire_id: 2, duty_id: 1) }
let(:participant) { build(:participant, id: 1, user_id: 6, assignment: assignment) }
let(:teammate_review_response_map) { TeammateReviewResponseMap.new reviewer: participant, reviewer_is_team: true, assignment:assignment }
''
This step created the review response map that we would be testing as well as and assignment which contained a questionnaire. The next step was to actually test the data. First we decided to ensure that the correct questionnaire was returned with the following test. It compares the returned questionnaire with the one we know is correct.
''
it 'returns questionnaire specific to a duty' do
allow(AssignmentQuestionnaire).to receive(:where).with(assignment_id: 1, duty_id: 1).and_return([assignment_questionnaire1])
allow(Questionnaire).to receive(:find).with(assignment_questionnaire1.questionnaire_id).and_return(questionnaire)
expect(teammate_review_response_map.questionnaire_by_duty(1)).to eq questionnaire
end
''
Finally we added the inverse for when there was an error returning the questionnaire. in this case the program should return the default questionnaire.
''
it 'returns default questionnaire when no questionnaire is found for duty' do
allow(AssignmentQuestionnaire).to receive(:where).with(assignment_id: 1, duty_id: 1).and_return([])
allow(assignment.questionnaires).to receive(:find_by).with(type: 'TeammateReviewQuestionnaire').and_return(questionnaire)
expect(teammate_review_response_map.questionnaire_by_duty(1)).to eq questionnaire
end
''

== Manual Testing in Expertiza UI ==
Here we describe manual UI Testing steps to edit an existing assignment to allow it have to specialized rubrics for different topic types. These steps are also shown in recorded demo video.
*Login to Expertiza using instructor account (For testing, username: '''instructor6''', password: '''password''')
*Click on Manage > Assignments
*Click on Edit option for any assignment, you should get following view. Make sure '''Has topics?''' box is checked.
[[File:Assignment edit 3.png]]
*Click on Rubrics tab. You will see 2 checkboxes ('''Review rubric varies by round?''', '''Review rubric varies by topic?''')
*Check the box for '''Review rubric varies by topic?'''
*Go to Topics tab and verify that there is dropdown menu beside each Topic.
*Select a rubric from dropdown menu, and click '''Save'''
[[File:Topics rubric 2.png]]
*Go back to Home, and select the same assignment to edit. When you click on Topics tab, you should see the rubric you had selected.

==Team Information==
* Naman Shrimali
* Kanchan Rawat
* Subodh Thota
* Andrew Shipman
Mentor : Prof. Edward F. Gehringer

CSC/ECE 517 Fall 2021 - E2161. Merge code for role based reviewing with code for topic specific rubrics

2021-11-28T20:07:50Z

Ajshipma:

This wiki page contains description of changes designed and implemented for [https://docs.google.com/document/d/1slx4HPIbgTH-psIKMSCF-HDF9brxf-FuYhzVT9ZiIrM/edit#heading=h.8s6o9jnnxj0p E2161. Merge code for role-based reviewing with code for topic-specific rubrics], a Final Project for CSC/ECE 517, Fall 2021.
== Purpose==
In CSC/ECE 517, there are Expertiza-based course projects, Mozilla-based course projects, etc. However, currently, we can only specify one kind of rubric for all kinds of course projects. This means that refactoring projects, testing projects, and Mozilla projects need to use the same rubric. We hope we could specify different rubrics to be used with different kinds of course projects.

The project objective is to merge E2147-https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2147._Role-based_reviewing#E2147._Role-based_reviewing with the existing E2026-https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2020_-_E2026._Specialized_rubrics_for_different_topic_types. While merging, we found out that the code for E2026 has already been merged on Expertiza beta branch and so now the actual implementation is to write test cases for both E2147 and E2026.

==Brief Overview of E2147 and E2026 Projects==
*E2147(Role based reviewing): The project objective was to develop teammate review varying by the roles that each team member has in order to evaluate the particular role that each team member has taken rather than asking a generic questionnaire which was same for all the team members previously. For eg, the instructor would create a separate teammate questionnaire for developer role and for tester role respectively.
*E2026(Specialized rubrics for different topics): The project objective was to develop specialized rubrics based on project topics, previously we had same type of questionnaire for all the different types of projects. This implementation made sure that we evaluate different projects based on personalised rubrics rather than having same rubrics.

==Testing Plan==

===Test Scenarios for E2147 (Role based reviewing)===
*Only Instructor/TA/Admin should be able to create or update duties: Only the instructor/admin should be able to create or update duties. Also, the corresponding TA of the assignment should be able to create or update duties.
*Create new roles: If the assignment is role based reviewing then the instructor should be able to create new roles for the same and save it in the database using new role functionality.
*Only allow student to update duties in Student View: Only student should be able to update his duties in Student View.
*Edit existing roles: Once the new roles have been created, then the instructor should be able to edit its details such as the maximum number of each role allowed.
*Delete existing roles: The instructor should also be able to delete any roles if he wants.
*Review rubric by role: On Rubrics tab, if the instructor clicks on Review rubric by role, then the corresponding rubric roles based teammate questionnaire should appear and get saved successfully.
*Student View: If the assignment is role based assignment, then the respective students should be able to see the respective teammate questionnaire based on roles for his other team members.
*Selection of Roles: On student login, a student should be able to see the existing roles that he can take up in the project. Only the roles which are available should be shown to the student.

===Test Scenarios for E2026 (Specialized rubrics for different topics)===

As part of our implementation, we modified existing code as well as added new code. To ensure that existing functionality was not broken, and new functionality worked as expected, we used the following Test Strategy (which was also used by previous team):

===Run and pass existing RSpec Tests===
*The following existing RSpec test files have been modified and they pass as part of testing:
**spec/controllers/assignments_controller_spec.rb
**spec/controllers/questionnaires_controller_spec.rb
**spec/controllers/response_controller_spec.rb
**spec/factories/factories.rb
**spec/features/assignment_creation_spec.rb
**spec/features/quiz_spec.rb
**spec/features/staggered_deadline_spec.rb
**spec/models/assignment_form_spec.rb
**spec/models/assignment_spec.rb
**spec/models/on_the_fly_calc_spec.rb
**spec/models/response_spec.rb
**spec/models/review_response_map_spec.rb

===Develop New RSpec Tests===
*spec/helpers/duties_controller_spec.rb
*All these rspec tests passed.

== duties_controller_spec.rb ==
We have created this new test file to unit test the duties scenarios.

First we mock the data accordingly as needed by the tests.

''
describe DutiesController do
let(:assignment) { build(:assignment, id: 1,course_id: 1,instructor_id: 6, due_dates: [due_date], microtask: true, staggered_deadline: true)}
let(:admin) { build(:admin) }
let(:instructor) { build(:instructor, id: 6) }
let(:instructor2) { build(:instructor, id: 66) }
let(:ta) { build(:teaching_assistant, id: 8) }
let(:duty) { build(:duty, id: 1, duty_name: "Role", max_members_for_duty: 2, assignment_id: 1) }
let(:due_date) { build(:assignment_due_date, deadline_type_id: 1) } ''

We then run the arbitrary code that is needed before each test

''
before(:each) do
allow(Assignment).to receive(:find).with('1').and_return(assignment)
allow(Assignment).to receive(:find).with(1).and_return(assignment)
stub_current_user(instructor, instructor.role.name, instructor.role)
allow(Duty).to receive(:find).with('1').and_return(duty)
end
''

Test scenarios for duties controller:
1) Only admin, superadmin, TA, Instructor can perform edit or update action

'' describe '#action_allowed?' do ''

The whole context that defines if the action allowed is edit or update. We do this by mocking the action to edit

context 'when params action is edit or update' do
before(:each) do
controller.params = {id: '1', action: 'edit'}
end

When the current logged in user role is super admin or admin

context 'when the role name of current user is super admin or admin' do
it 'allows certain action' do
stub_current_user(admin, admin.role.name, admin.role)
expect(controller.send(:action_allowed?)).to be true
end
end

When the current logged in user role is instructor

context 'when current user is the instructor of current assignment' do
it 'allows certain action' do
expect(controller.send(:action_allowed?)).to be true
end
end

When the current logged in user role is the TA of the course

context 'when current user is the ta of the course which current assignment belongs to' do
it 'allows certain action' do
stub_current_user(ta, ta.role.name, ta.role)
allow(TaMapping).to receive(:exists?).with(ta_id: 8, course_id: 1).and_return(true)
expect(controller.send(:action_allowed?)).to be true
end
end

When the current logged in user is the instructor of the course

context 'when current user is the instructor of the course which current assignment belongs to' do
it 'allows certain action' do
stub_current_user(instructor2, instructor2.role.name, instructor2.role)
allow(Course).to receive(:find).with(1).and_return(double('Course', instructor_id: 66))
expect(controller.send(:action_allowed?)).to be true
end
end
end

When the parameter action is neither edit nor update, we do this by mocking the action to new

context 'when params action is not edit and update' do
before(:each) do
controller.params = {id: '1', action: 'new'}
end

We now check if super admin/admin/instructor/ta can perform this action which is neither edit nor update

context 'when the role current user is super admin/admin/instructor/ta' do
it 'allows certain action except edit and update' do
expect(controller.send(:action_allowed?)).to be true
end
end
end
end

And then we added few tests to test creation/edit/deletion of a duty

Creation of a duty, we create a duty and check if it is saved successfully

describe '#create' do

Checking if the right page is rendered after successful creation of a duty

context 'when new duty can be saved successfully' do
it 'sets up a new duty and redirects to assignment#edit page' do
allow(duty).to receive(:save).and_return('OK')
params = {
id: 1,
duty: {
duty_name: 'Scrum Master',
max_members_for_duty: 2,
assignment_id: 1
}
}
post :create, params
expect(response).to redirect_to('/assignments/1/edit')
expect(flash[:notice]).to match(/Role was successfully created.*/)
end
end

Test to check if the right error message is shown if the creation of duty is failed

context 'when new duty cannot be saved successfully' do
it 'shows error message and redirects to duty#new page' do
allow(duty).to receive(:errors)
params = {
id: 1,
duty: {
duty_name: 'Scrum Master',
max_members_for_duty: -1,
assignment_id: 1
}
}
post :create, params
expect(flash[:error]).to eq('Max members for duty must be greater than or equal to 1. ')
expect(response).to redirect_to('/duties/new?id=1')
end
end
end

Test to check the edit functionality of a duty

describe '#update' do

When the duty can be edited successfully, we check if the right page is rendered

context 'when duty can be found' do
it 'updates current duty and redirects to assignment#edit page' do
allow(Duty).to receive(:find).with('1').and_return(build(:duty, id: 1))
params = {
id: 1,
assignment_id: 1,
duty: {
duty_name: 'Scrum Master',
max_members_for_duty: 5,
assignment_id: 1
}
}
post :update, params
expect(response).to redirect_to('/assignments/1/edit')
expect(flash[:notice]).to match(/Role was successfully updated.*/)
end
end

When the duty cannot be updated, we check if the right error message is displayed

context 'when new duty cannot be updated successfully' do
it 'shows error message and redirects to duty#new page' do
allow(duty).to receive(:errors)
params = {
id: 1,
duty: {
duty_name: 'SM',
max_members_for_duty: 1,
assignment_id: 1
}
}
post :create, params
expect(flash[:error]).to eq('Duty name is too short (minimum is 3 characters). ')
expect(response).to redirect_to('/duties/new?id=1')
end
end
end

Now finally, we test the delete functionality of the duty

describe '#destroy' do
context 'when duty can be found' do
it 'redirects to assignment#edit page' do
params = {id: 1, assignment_id: 1}
post :destroy, params
expect(response).to redirect_to('/assignments/1/edit')
expect(flash[:notice]).to match(/Role was successfully destroyed.*/)
end
end
end

== team_users_controller_spec.rb ==

We have added a test case in this file which tests if the action is allowed only by specific user roles

First, we mock the data

''
describe TeamsUsersController do
let(:assignment) do
build(:assignment, id: 1, name: 'test assignment', instructor_id: 6, staggered_deadline: true, directory_path: 'same path',
participants: [build(:participant)], teams: [build(:assignment_team)], course_id: 1)
end
let(:assignment_form) { double('AssignmentForm', assignment: assignment) }
let(:student) { build(:student) }

before(:each) do
allow(Assignment).to receive(:find).with('1').and_return(assignment)
stub_current_user(student, student.role.name, student.role)
end
''

Then we check if the student can perform the update action for duties

''
describe '#action_allowed?' do
context 'when params action is update duties' do
before(:each) do
controller.params = {id: '1', action: 'update_duties'}
end
context 'when the role current user is student' do
it 'allows certain action' do
stub_current_user(student, student.role.name, student.role)
expect(controller.send(:action_allowed?)).to be true
end
end
end
end
''

This file also contains a test case to ensure the duties can be properly updated. The test case checks this by ensuring that the user is redirected to the student view page. just as with the previous section the first step is to mock the data by creating a team user object.

''
let(:teams_user1) {TeamsUser.new id:1, duty_id:1}
''

Then the data is actually updated and we ensure that the user is redirected to the proper place.

''
describe '#update_duties' do
it 'updates the duties for the participant' do
allow(TeamsUser).to receive(:find).with('1').and_return(teams_user1)
allow(teams_user1).to receive(:update_attribute).with(any_args).and_return('OK')
params = {
teams_user_id: '1',
teams_user: {duty_id: '1'},
participant_id: '1'
}
session = {user: stub_current_user(student, student.role.name, student.role)}
get :update_duties, params, session
expect(response).to redirect_to('/student_teams/view?student_id=1')
end
end
''

== assignment_form_spec.rb ==
The assignemnt_form_spec.rb file contains all the test files for the assignment form, which includes adding object to a queue. the first step was to create mock data so that the test could run on objects created for the tests. the code below shows how the mock data was created for the specific tests that we created to ensure the functionality of the projects.
''
let(:new_assignment_questionnaire) { build(:assignment_questionnaire) }
''
The new_assignment_questionnaire object is used for both test cases in this file. the first test case checks for when the active record cannot be found for a specific assignment id or duty id.
''
context 'when active record for assignment_questionnaire is not found for a given assignment_id and duty_id' do
it 'returns new instance of assignment_questionnaire with default values' do
allow(assignment).to receive(:questionnaire_varies_by_duty).and_return(true)
allow(AssignmentQuestionnaire).to receive(:where).with(assignment_id: 1, duty_id: anything).and_return([])
allow(AssignmentQuestionnaire).to receive(:where).with(user_id: anything, assignment_id: nil, questionnaire_id: nil).and_return([])
allow(AssignmentQuestionnaire).to receive(:new).and_return(new_assignment_questionnaire)
expect(assignment_form.assignment_questionnaire('TeammateReviewQuestionnaire', nil, nil, 1)).to eq(new_assignment_questionnaire)
end
end
''
The next next test checks when the assignment questionnaire is found given the assignment id and duty id parameters. this test is very similar to the one where the test is not found because the it searches through the active record to find the assignment questionnaire.
''
context 'when active record for assignment_questionnaire is found for a given assignment_id and duty_id' do
it 'returns new instance of assignment_questionnaire with default values' do
allow(assignment).to receive(:questionnaire_varies_by_duty).and_return(true)
allow(Questionnaire).to receive(:find).with(1).and_return(questionnaire3)
allow(AssignmentQuestionnaire).to receive(:where).with(assignment_id: 1, duty_id: 1).and_return([assignment_questionnaire2])
allow(AssignmentQuestionnaire).to receive(:where).with(user_id: anything, assignment_id: nil, questionnaire_id: nil).and_return([])
allow(AssignmentQuestionnaire).to receive(:new).and_return(new_assignment_questionnaire)
expect(assignment_form.assignment_questionnaire('TeammateReviewQuestionnaire', nil, nil, 1)).to eq(assignment_questionnaire2)
end
end
''

== duty_spec.rb ==
the main purpose of the duty_spec.rb file is to test any duty to make sure a duty can be assigned to a team member. it also tests if a duty is unavailable to a team member because the max number of people have been assigned that duty. to test this functionality the mock data is created to allow for testing of the objcect.
''
let(:assignment) { build(:assignment, id: 1, name: 'no assgt') }
let(:participant) { build(:participant, id:1, user_id: 1) }
let(:participant2) { build(:participant, id:2, user_id: 2) }
let(:participant3) { build(:participant, id:3, user_id: 3) }
let(:user) { build(:student, id: 1, name: 'no name', fullname: 'no one', participants: [participant]) }
let(:user2) { build(:student, id: 2, name: 'no name2', fullname: 'no one2', participants: [participant2]) }
let(:user3) { build(:student, id: 3, name: 'no name3', fullname: 'no one3', participants: [participant3]) }

let(:team1) { build(:assignment_team, id: 1, name: 'no team', users: [user, user2, user3]) }
let(:sample_duty_taken) { build(:duty, id: 1, max_members_for_duty:1, assignment_id:1) }
let(:sample_duty_not_taken) { build(:duty, id: 1, max_members_for_duty:2, assignment_id:1) }

let(:team_user1) { build(:team_user, id: 1, user: user) }
let(:team_user2) { build(:team_user, id: 2, user: user2) }
let(:team_user3) { build(:team_user, id: 3, user: user3, duty_id:1) }
''
an assignment is created on which the duties can be tested. for the testing multiple users and participants are created. Finally we created team users that could be assigned duties through the duty_id field. the next step was to set up the reoccurring steps for each of the tests.
''
before(:each) do
allow(team1).to receive(:participants).and_return([participant, participant2, participant3])
allow(participant).to receive(:get_team_user).and_return(team_user1)
allow(participant2).to receive(:get_team_user).and_return(team_user2)
allow(participant3).to receive(:get_team_user).and_return(team_user3)
end
''
Finally the actual tests were implemented. The tests are fairly simple because they just need to check if the duty can be assigned or not.
''
describe '#can_be_assigned?' do
context 'when users in current team want to assign roles that are available'
it 'returns true' do
expect(sample_duty_not_taken.can_be_assigned?(team1)).to be true
end
context 'when users in current team want to assign roles that are unavailable'
it 'returns false' do
expect(sample_duty_taken.can_be_assigned?(team1)).to be false
end
''

== teammate_review_response_map_spec.rb ==
This Rspec testing file tests that a specific questionnaire can be returned when the student has a role assigned to them. This is needed for the role based reviewing because when one student goes to review another they must get the correct questionnaire for their role. We tested this functionality as well as the inverse, when the role could not be found. initially we created the mock data for testing which is shown below.
''
let(:questionnaire) { Questionnaire.new name: "abc", private: 0, min_question_score: 0, max_question_score: 10, instructor_id: 1234 }
let(:assignment) { build(:assignment, id: 1, name: 'no assgt', is_duty_based_assignment: true, questionnaires: [questionnaire]) }
let(:assignment_questionnaire1) { build(:assignment_questionnaire, id: 1, assignment_id: 1, questionnaire_id: 2, duty_id: 1) }
let(:participant) { build(:participant, id: 1, user_id: 6, assignment: assignment) }
let(:teammate_review_response_map) { TeammateReviewResponseMap.new reviewer: participant, reviewer_is_team: true, assignment:assignment }
''
This step created the review response map that we would be testing as well as and assignment which contained a questionnaire. The next step was to actually test the data. First we decided to ensure that the correct questionnaire was returned with the following test. It compares the returned questionnaire with the one we know is correct.
''
it 'returns questionnaire specific to a duty' do
allow(AssignmentQuestionnaire).to receive(:where).with(assignment_id: 1, duty_id: 1).and_return([assignment_questionnaire1])
allow(Questionnaire).to receive(:find).with(assignment_questionnaire1.questionnaire_id).and_return(questionnaire)
expect(teammate_review_response_map.questionnaire_by_duty(1)).to eq questionnaire
end
''
Finally we added the inverse for when there was an error returning the questionnaire. in this case the program should return the default questionnaire.
''
it 'returns default questionnaire when no questionnaire is found for duty' do
allow(AssignmentQuestionnaire).to receive(:where).with(assignment_id: 1, duty_id: 1).and_return([])
allow(assignment.questionnaires).to receive(:find_by).with(type: 'TeammateReviewQuestionnaire').and_return(questionnaire)
expect(teammate_review_response_map.questionnaire_by_duty(1)).to eq questionnaire
end
''

== Manual Testing in Expertiza UI ==
Here we describe manual UI Testing steps to edit an existing assignment to allow it have to specialized rubrics for different topic types. These steps are also shown in recorded demo video.
*Login to Expertiza using instructor account (For testing, username: '''instructor6''', password: '''password''')
*Click on Manage > Assignments
*Click on Edit option for any assignment, you should get following view. Make sure '''Has topics?''' box is checked.
[[File:Assignment edit 3.png]]
*Click on Rubrics tab. You will see 2 checkboxes ('''Review rubric varies by round?''', '''Review rubric varies by topic?''')
*Check the box for '''Review rubric varies by topic?'''
*Go to Topics tab and verify that there is dropdown menu beside each Topic.
*Select a rubric from dropdown menu, and click '''Save'''
[[File:Topics rubric 2.png]]
*Go back to Home, and select the same assignment to edit. When you click on Topics tab, you should see the rubric you had selected.

==Team Information==
* Naman Shrimali
* Kanchan Rawat
* Subodh Thota
* Andrew Shipman
Mentor : Prof. Edward F. Gehringer

CSC/ECE 517 Fall 2021 - E2161. Merge code for role based reviewing with code for topic specific rubrics

2021-11-28T20:07:24Z

Ajshipma:

This wiki page contains description of changes designed and implemented for [https://docs.google.com/document/d/1slx4HPIbgTH-psIKMSCF-HDF9brxf-FuYhzVT9ZiIrM/edit#heading=h.8s6o9jnnxj0p E2161. Merge code for role-based reviewing with code for topic-specific rubrics], a Final Project for CSC/ECE 517, Fall 2021.
== Purpose==
In CSC/ECE 517, there are Expertiza-based course projects, Mozilla-based course projects, etc. However, currently, we can only specify one kind of rubric for all kinds of course projects. This means that refactoring projects, testing projects, and Mozilla projects need to use the same rubric. We hope we could specify different rubrics to be used with different kinds of course projects.

The project objective is to merge E2147-https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2147._Role-based_reviewing#E2147._Role-based_reviewing with the existing E2026-https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2020_-_E2026._Specialized_rubrics_for_different_topic_types. While merging, we found out that the code for E2026 has already been merged on Expertiza beta branch and so now the actual implementation is to write test cases for both E2147 and E2026.

==Brief Overview of E2147 and E2026 Projects==
*E2147(Role based reviewing): The project objective was to develop teammate review varying by the roles that each team member has in order to evaluate the particular role that each team member has taken rather than asking a generic questionnaire which was same for all the team members previously. For eg, the instructor would create a separate teammate questionnaire for developer role and for tester role respectively.
*E2026(Specialized rubrics for different topics): The project objective was to develop specialized rubrics based on project topics, previously we had same type of questionnaire for all the different types of projects. This implementation made sure that we evaluate different projects based on personalised rubrics rather than having same rubrics.

==Testing Plan==

===Test Scenarios for E2147 (Role based reviewing)===
*Only Instructor/TA/Admin should be able to create or update duties: Only the instructor/admin should be able to create or update duties. Also, the corresponding TA of the assignment should be able to create or update duties.
*Create new roles: If the assignment is role based reviewing then the instructor should be able to create new roles for the same and save it in the database using new role functionality.
*Only allow student to update duties in Student View: Only student should be able to update his duties in Student View.
*Edit existing roles: Once the new roles have been created, then the instructor should be able to edit its details such as the maximum number of each role allowed.
*Delete existing roles: The instructor should also be able to delete any roles if he wants.
*Review rubric by role: On Rubrics tab, if the instructor clicks on Review rubric by role, then the corresponding rubric roles based teammate questionnaire should appear and get saved successfully.
*Student View: If the assignment is role based assignment, then the respective students should be able to see the respective teammate questionnaire based on roles for his other team members.
*Selection of Roles: On student login, a student should be able to see the existing roles that he can take up in the project. Only the roles which are available should be shown to the student.

===Test Scenarios for E2026 (Specialized rubrics for different topics)===

As part of our implementation, we modified existing code as well as added new code. To ensure that existing functionality was not broken, and new functionality worked as expected, we used the following Test Strategy (which was also used by previous team):

===Run and pass existing RSpec Tests===
*The following existing RSpec test files have been modified and they pass as part of testing:
**spec/controllers/assignments_controller_spec.rb
**spec/controllers/questionnaires_controller_spec.rb
**spec/controllers/response_controller_spec.rb
**spec/factories/factories.rb
**spec/features/assignment_creation_spec.rb
**spec/features/quiz_spec.rb
**spec/features/staggered_deadline_spec.rb
**spec/models/assignment_form_spec.rb
**spec/models/assignment_spec.rb
**spec/models/on_the_fly_calc_spec.rb
**spec/models/response_spec.rb
**spec/models/review_response_map_spec.rb

===Develop New RSpec Tests===
*spec/helpers/duties_controller_spec.rb
*All these rspec tests passed.

== duties_controller_spec.rb ==
We have created this new test file to unit test the duties scenarios.

First we mock the data accordingly as needed by the tests.

''
describe DutiesController do
let(:assignment) { build(:assignment, id: 1,course_id: 1,instructor_id: 6, due_dates: [due_date], microtask: true, staggered_deadline: true)}
let(:admin) { build(:admin) }
let(:instructor) { build(:instructor, id: 6) }
let(:instructor2) { build(:instructor, id: 66) }
let(:ta) { build(:teaching_assistant, id: 8) }
let(:duty) { build(:duty, id: 1, duty_name: "Role", max_members_for_duty: 2, assignment_id: 1) }
let(:due_date) { build(:assignment_due_date, deadline_type_id: 1) } ''

We then run the arbitrary code that is needed before each test

''
before(:each) do
allow(Assignment).to receive(:find).with('1').and_return(assignment)
allow(Assignment).to receive(:find).with(1).and_return(assignment)
stub_current_user(instructor, instructor.role.name, instructor.role)
allow(Duty).to receive(:find).with('1').and_return(duty)
end
''

Test scenarios for duties controller:
1) Only admin, superadmin, TA, Instructor can perform edit or update action

'' describe '#action_allowed?' do ''

The whole context that defines if the action allowed is edit or update. We do this by mocking the action to edit

context 'when params action is edit or update' do
before(:each) do
controller.params = {id: '1', action: 'edit'}
end

When the current logged in user role is super admin or admin

context 'when the role name of current user is super admin or admin' do
it 'allows certain action' do
stub_current_user(admin, admin.role.name, admin.role)
expect(controller.send(:action_allowed?)).to be true
end
end

When the current logged in user role is instructor

context 'when current user is the instructor of current assignment' do
it 'allows certain action' do
expect(controller.send(:action_allowed?)).to be true
end
end

When the current logged in user role is the TA of the course

context 'when current user is the ta of the course which current assignment belongs to' do
it 'allows certain action' do
stub_current_user(ta, ta.role.name, ta.role)
allow(TaMapping).to receive(:exists?).with(ta_id: 8, course_id: 1).and_return(true)
expect(controller.send(:action_allowed?)).to be true
end
end

When the current logged in user is the instructor of the course

context 'when current user is the instructor of the course which current assignment belongs to' do
it 'allows certain action' do
stub_current_user(instructor2, instructor2.role.name, instructor2.role)
allow(Course).to receive(:find).with(1).and_return(double('Course', instructor_id: 66))
expect(controller.send(:action_allowed?)).to be true
end
end
end

When the parameter action is neither edit nor update, we do this by mocking the action to new

context 'when params action is not edit and update' do
before(:each) do
controller.params = {id: '1', action: 'new'}
end

We now check if super admin/admin/instructor/ta can perform this action which is neither edit nor update

context 'when the role current user is super admin/admin/instructor/ta' do
it 'allows certain action except edit and update' do
expect(controller.send(:action_allowed?)).to be true
end
end
end
end

And then we added few tests to test creation/edit/deletion of a duty

Creation of a duty, we create a duty and check if it is saved successfully

describe '#create' do

Checking if the right page is rendered after successful creation of a duty

context 'when new duty can be saved successfully' do
it 'sets up a new duty and redirects to assignment#edit page' do
allow(duty).to receive(:save).and_return('OK')
params = {
id: 1,
duty: {
duty_name: 'Scrum Master',
max_members_for_duty: 2,
assignment_id: 1
}
}
post :create, params
expect(response).to redirect_to('/assignments/1/edit')
expect(flash[:notice]).to match(/Role was successfully created.*/)
end
end

Test to check if the right error message is shown if the creation of duty is failed

context 'when new duty cannot be saved successfully' do
it 'shows error message and redirects to duty#new page' do
allow(duty).to receive(:errors)
params = {
id: 1,
duty: {
duty_name: 'Scrum Master',
max_members_for_duty: -1,
assignment_id: 1
}
}
post :create, params
expect(flash[:error]).to eq('Max members for duty must be greater than or equal to 1. ')
expect(response).to redirect_to('/duties/new?id=1')
end
end
end

Test to check the edit functionality of a duty

describe '#update' do

When the duty can be edited successfully, we check if the right page is rendered

context 'when duty can be found' do
it 'updates current duty and redirects to assignment#edit page' do
allow(Duty).to receive(:find).with('1').and_return(build(:duty, id: 1))
params = {
id: 1,
assignment_id: 1,
duty: {
duty_name: 'Scrum Master',
max_members_for_duty: 5,
assignment_id: 1
}
}
post :update, params
expect(response).to redirect_to('/assignments/1/edit')
expect(flash[:notice]).to match(/Role was successfully updated.*/)
end
end

When the duty cannot be updated, we check if the right error message is displayed

context 'when new duty cannot be updated successfully' do
it 'shows error message and redirects to duty#new page' do
allow(duty).to receive(:errors)
params = {
id: 1,
duty: {
duty_name: 'SM',
max_members_for_duty: 1,
assignment_id: 1
}
}
post :create, params
expect(flash[:error]).to eq('Duty name is too short (minimum is 3 characters). ')
expect(response).to redirect_to('/duties/new?id=1')
end
end
end

Now finally, we test the delete functionality of the duty

describe '#destroy' do
context 'when duty can be found' do
it 'redirects to assignment#edit page' do
params = {id: 1, assignment_id: 1}
post :destroy, params
expect(response).to redirect_to('/assignments/1/edit')
expect(flash[:notice]).to match(/Role was successfully destroyed.*/)
end
end
end

== team_users_controller_spec.rb ==

We have added a test case in this file which tests if the action is allowed only by specific user roles

First, we mock the data

''
describe TeamsUsersController do
let(:assignment) do
build(:assignment, id: 1, name: 'test assignment', instructor_id: 6, staggered_deadline: true, directory_path: 'same path',
participants: [build(:participant)], teams: [build(:assignment_team)], course_id: 1)
end
let(:assignment_form) { double('AssignmentForm', assignment: assignment) }
let(:student) { build(:student) }

before(:each) do
allow(Assignment).to receive(:find).with('1').and_return(assignment)
stub_current_user(student, student.role.name, student.role)
end
''

Then we check if the student can perform the update action for duties

''
describe '#action_allowed?' do
context 'when params action is update duties' do
before(:each) do
controller.params = {id: '1', action: 'update_duties'}
end
context 'when the role current user is student' do
it 'allows certain action' do
stub_current_user(student, student.role.name, student.role)
expect(controller.send(:action_allowed?)).to be true
end
end
end
end
''

This file also contains a test case to ensure the duties can be properly updated. The test case checks this by ensuring that the user is redirected to the student view page. just as with the previous section the first step is to mock the data by creating a team user object.

''
let(:teams_user1) {TeamsUser.new id:1, duty_id:1}
''

Then the data is actually updated and we ensure that the user is redirected to the proper place.

''
describe '#update_duties' do
it 'updates the duties for the participant' do
allow(TeamsUser).to receive(:find).with('1').and_return(teams_user1)
allow(teams_user1).to receive(:update_attribute).with(any_args).and_return('OK')
params = {
teams_user_id: '1',
teams_user: {duty_id: '1'},
participant_id: '1'
}
session = {user: stub_current_user(student, student.role.name, student.role)}
get :update_duties, params, session
expect(response).to redirect_to('/student_teams/view?student_id=1')
end
end
''

== assignment_form_spec.rb ==
The assignemnt_form_spec.rb file contains all the test files for the assignment form, which includes adding object to a queue. the first step was to create mock data so that the test could run on objects created for the tests. the code below shows how the mock data was created for the specific tests that we created to ensure the functionality of the projects.
''
let(:new_assignment_questionnaire) { build(:assignment_questionnaire) }
''
The new_assignment_questionnaire object is used for both test cases in this file. the first test case checks for when the active record cannot be found for a specific assignment id or duty id.
''
context 'when active record for assignment_questionnaire is not found for a given assignment_id and duty_id' do
it 'returns new instance of assignment_questionnaire with default values' do
allow(assignment).to receive(:questionnaire_varies_by_duty).and_return(true)
allow(AssignmentQuestionnaire).to receive(:where).with(assignment_id: 1, duty_id: anything).and_return([])
allow(AssignmentQuestionnaire).to receive(:where).with(user_id: anything, assignment_id: nil, questionnaire_id: nil).and_return([])
allow(AssignmentQuestionnaire).to receive(:new).and_return(new_assignment_questionnaire)
expect(assignment_form.assignment_questionnaire('TeammateReviewQuestionnaire', nil, nil, 1)).to eq(new_assignment_questionnaire)
end
end
''
The next next test checks when the assignment questionnaire is found given the assignment id and duty id parameters. this test is very similar to the one where the test is not found because the it searches through the active record to find the assignment questionnaire.
''
context 'when active record for assignment_questionnaire is found for a given assignment_id and duty_id' do
it 'returns new instance of assignment_questionnaire with default values' do
allow(assignment).to receive(:questionnaire_varies_by_duty).and_return(true)
allow(Questionnaire).to receive(:find).with(1).and_return(questionnaire3)
allow(AssignmentQuestionnaire).to receive(:where).with(assignment_id: 1, duty_id: 1).and_return([assignment_questionnaire2])
allow(AssignmentQuestionnaire).to receive(:where).with(user_id: anything, assignment_id: nil, questionnaire_id: nil).and_return([])
allow(AssignmentQuestionnaire).to receive(:new).and_return(new_assignment_questionnaire)
expect(assignment_form.assignment_questionnaire('TeammateReviewQuestionnaire', nil, nil, 1)).to eq(assignment_questionnaire2)
end
end
''

== duty_spec.rb ==
the main purpose of the duty_spec.rb file is to test any duty to make sure a duty can be assigned to a team member. it also tests if a duty is unavailable to a team member because the max number of people have been assigned that duty. to test this functionality the mock data is created to allow for testing of the objcect.
''
let(:assignment) { build(:assignment, id: 1, name: 'no assgt') }
let(:participant) { build(:participant, id:1, user_id: 1) }
let(:participant2) { build(:participant, id:2, user_id: 2) }
let(:participant3) { build(:participant, id:3, user_id: 3) }
let(:user) { build(:student, id: 1, name: 'no name', fullname: 'no one', participants: [participant]) }
let(:user2) { build(:student, id: 2, name: 'no name2', fullname: 'no one2', participants: [participant2]) }
let(:user3) { build(:student, id: 3, name: 'no name3', fullname: 'no one3', participants: [participant3]) }

let(:team1) { build(:assignment_team, id: 1, name: 'no team', users: [user, user2, user3]) }
let(:sample_duty_taken) { build(:duty, id: 1, max_members_for_duty:1, assignment_id:1) }
let(:sample_duty_not_taken) { build(:duty, id: 1, max_members_for_duty:2, assignment_id:1) }

let(:team_user1) { build(:team_user, id: 1, user: user) }
let(:team_user2) { build(:team_user, id: 2, user: user2) }
let(:team_user3) { build(:team_user, id: 3, user: user3, duty_id:1) }
''
an assignment is created on which the duties can be tested. for the testing multiple users and participants are created. Finally we created team users that could be assigned duties through the duty_id field. the next step was to set up the reoccurring steps for each of the tests.
''
before(:each) do
allow(team1).to receive(:participants).and_return([participant, participant2, participant3])
allow(participant).to receive(:get_team_user).and_return(team_user1)
allow(participant2).to receive(:get_team_user).and_return(team_user2)
allow(participant3).to receive(:get_team_user).and_return(team_user3)
end
''
Finally the actual tests were implemented. The tests are fairly simple because they just need to check if the duty can be assigned or not.
''
describe '#can_be_assigned?' do
context 'when users in current team want to assign roles that are available'
it 'returns true' do
expect(sample_duty_not_taken.can_be_assigned?(team1)).to be true
end
context 'when users in current team want to assign roles that are unavailable'
it 'returns false' do
expect(sample_duty_taken.can_be_assigned?(team1)).to be false
end
''

== teammate_review_response_map_spec.rb ==
This Rspec testing file tests that a specific questionnaire can be returned when the student has a role assigned to them. This is needed for the role based reviewing because when one student goes to review another they must get the correct questionnaire for their role. We tested this functionality as well as the inverse, when the role could not be found. initially we created the mock data for testing which is shown below.
''
let(:questionnaire) { Questionnaire.new name: "abc", private: 0, min_question_score: 0, max_question_score: 10, instructor_id: 1234 }
let(:assignment) { build(:assignment, id: 1, name: 'no assgt', is_duty_based_assignment: true, questionnaires: [questionnaire]) }
let(:assignment_questionnaire1) { build(:assignment_questionnaire, id: 1, assignment_id: 1, questionnaire_id: 2, duty_id: 1) }
let(:participant) { build(:participant, id: 1, user_id: 6, assignment: assignment) }
let(:teammate_review_response_map) { TeammateReviewResponseMap.new reviewer: participant, reviewer_is_team: true, assignment:assignment }
''
This step created the review response map that we would be testing as well as and assignment which contained a questionnaire. The next step was to actually test the data. First we decided to ensure that the correct questionnaire was returned with the following test. It compares the returned questionnaire with the one we know is correct.
''
it 'returns questionnaire specific to a duty' do
allow(AssignmentQuestionnaire).to receive(:where).with(assignment_id: 1, duty_id: 1).and_return([assignment_questionnaire1])
allow(Questionnaire).to receive(:find).with(assignment_questionnaire1.questionnaire_id).and_return(questionnaire)
expect(teammate_review_response_map.questionnaire_by_duty(1)).to eq questionnaire
end
''
Finally we added the inverse for when there was an error returning the questionnaire. in this case the program should return the default questionnaire.
''
it 'returns default questionnaire when no questionnaire is found for duty' do
allow(AssignmentQuestionnaire).to receive(:where).with(assignment_id: 1, duty_id: 1).and_return([])
allow(assignment.questionnaires).to receive(:find_by).with(type: 'TeammateReviewQuestionnaire').and_return(questionnaire)
expect(teammate_review_response_map.questionnaire_by_duty(1)).to eq questionnaire
end
''

== Manual Testing in Expertiza UI ==
Here we describe manual UI Testing steps to edit an existing assignment to allow it have to specialized rubrics for different topic types. These steps are also shown in recorded demo video.
*Login to Expertiza using instructor account (For testing, username: '''instructor6''', password: '''password''')
*Click on Manage > Assignments
*Click on Edit option for any assignment, you should get following view. Make sure '''Has topics?''' box is checked.
[[File:Assignment edit 3.png]]
*Click on Rubrics tab. You will see 2 checkboxes ('''Review rubric varies by round?''', '''Review rubric varies by topic?''')
*Check the box for '''Review rubric varies by topic?'''
*Go to Topics tab and verify that there is dropdown menu beside each Topic.
*Select a rubric from dropdown menu, and click '''Save'''
[[File:Topics rubric 2.png]]
*Go back to Home, and select the same assignment to edit. When you click on Topics tab, you should see the rubric you had selected.

==Team Information==
* Naman Shrimali
* Kanchan Rawat
* Subodh Thota
* Andrew Shipman
Mentor : Prof. Edward F. Gehringer

CSC/ECE 517 Fall 2021 - E2161. Merge code for role based reviewing with code for topic specific rubrics

2021-11-28T19:57:00Z

Ajshipma:

This wiki page contains description of changes designed and implemented for [https://docs.google.com/document/d/1slx4HPIbgTH-psIKMSCF-HDF9brxf-FuYhzVT9ZiIrM/edit#heading=h.8s6o9jnnxj0p E2161. Merge code for role-based reviewing with code for topic-specific rubrics], a Final Project for CSC/ECE 517, Fall 2021.
== Purpose==
In CSC/ECE 517, there are Expertiza-based course projects, Mozilla-based course projects, etc. However, currently, we can only specify one kind of rubric for all kinds of course projects. This means that refactoring projects, testing projects, and Mozilla projects need to use the same rubric. We hope we could specify different rubrics to be used with different kinds of course projects.

The project objective is to merge E2147-https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2147._Role-based_reviewing#E2147._Role-based_reviewing with the existing E2026-https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2020_-_E2026._Specialized_rubrics_for_different_topic_types. While merging, we found out that the code for E2026 has already been merged on Expertiza beta branch and so now the actual implementation is to write test cases for both E2147 and E2026.

==Brief Overview of E2147 and E2026 Projects==
*E2147(Role based reviewing): The project objective was to develop teammate review varying by the roles that each team member has in order to evaluate the particular role that each team member has taken rather than asking a generic questionnaire which was same for all the team members previously. For eg, the instructor would create a separate teammate questionnaire for developer role and for tester role respectively.
*E2026(Specialized rubrics for different topics): The project objective was to develop specialized rubrics based on project topics, previously we had same type of questionnaire for all the different types of projects. This implementation made sure that we evaluate different projects based on personalised rubrics rather than having same rubrics.

==Testing Plan==

===Test Scenarios for E2147(Role based reviewing)===
*Only Instructor/TA/Admin should be able to create or update duties: Only the instructor/admin should be able to create or update duties. Also, the corresponding TA of the assignment should be able to create or update duties.
*Create new roles: If the assignment is role based reviewing then the instructor should be able to create new roles for the same and save it in the database using new role functionality.
*Only allow student to update duties in Student View: Only student should be able to update his duties in Student View.
*Edit existing roles: Once the new roles have been created, then the instructor should be able to edit its details such as the maximum number of each role allowed.
*Delete existing roles: The instructor should also be able to delete any roles if he wants.
*Review rubric by role: On Rubrics tab, if the instructor clicks on Review rubric by role, then the corresponding rubric roles based teammate questionnaire should appear and get saved successfully.
*Student View: If the assignment is role based assignment, then the respective students should be able to see the respective teammate questionnaire based on roles for his other team members.
*Selection of Roles: On student login, a student should be able to see the existing roles that he can take up in the project. Only the roles which are available should be shown to the student.

===Test Scenarios for E2026(Specialized rubrics for different topics)===

As part of our implementation, we modified existing code as well as added new code. To ensure that existing functionality was not broken, and new functionality worked as expected, we used the following Test Strategy (which was also used by previous team):

===Run and pass existing RSpec Tests===
*The following existing RSpec test files have been modified and they pass as part of testing:
**spec/controllers/assignments_controller_spec.rb
**spec/controllers/questionnaires_controller_spec.rb
**spec/controllers/response_controller_spec.rb
**spec/factories/factories.rb
**spec/features/assignment_creation_spec.rb
**spec/features/quiz_spec.rb
**spec/features/staggered_deadline_spec.rb
**spec/models/assignment_form_spec.rb
**spec/models/assignment_spec.rb
**spec/models/on_the_fly_calc_spec.rb
**spec/models/response_spec.rb
**spec/models/review_response_map_spec.rb

===Develop New RSpec Tests===
*spec/helpers/duties_controller_spec.rb
*All these rspec tests passed.

== duties_controller_spec.rb ==
We have created this new test file to unit test the duties scenarios.

First we mock the data accordingly as needed by the tests.

''
describe DutiesController do
let(:assignment) { build(:assignment, id: 1,course_id: 1,instructor_id: 6, due_dates: [due_date], microtask: true, staggered_deadline: true)}
let(:admin) { build(:admin) }
let(:instructor) { build(:instructor, id: 6) }
let(:instructor2) { build(:instructor, id: 66) }
let(:ta) { build(:teaching_assistant, id: 8) }
let(:duty) { build(:duty, id: 1, duty_name: "Role", max_members_for_duty: 2, assignment_id: 1) }
let(:due_date) { build(:assignment_due_date, deadline_type_id: 1) } ''

We then run the arbitrary code that is needed before each test

''
before(:each) do
allow(Assignment).to receive(:find).with('1').and_return(assignment)
allow(Assignment).to receive(:find).with(1).and_return(assignment)
stub_current_user(instructor, instructor.role.name, instructor.role)
allow(Duty).to receive(:find).with('1').and_return(duty)
end
''

Test scenarios for duties controller:
1) Only admin, superadmin, TA, Instructor can perform edit or update action

'' describe '#action_allowed?' do ''

The whole context that defines if the action allowed is edit or update. We do this by mocking the action to edit

context 'when params action is edit or update' do
before(:each) do
controller.params = {id: '1', action: 'edit'}
end

When the current logged in user role is super admin or admin

context 'when the role name of current user is super admin or admin' do
it 'allows certain action' do
stub_current_user(admin, admin.role.name, admin.role)
expect(controller.send(:action_allowed?)).to be true
end
end

When the current logged in user role is instructor

context 'when current user is the instructor of current assignment' do
it 'allows certain action' do
expect(controller.send(:action_allowed?)).to be true
end
end

When the current logged in user role is the TA of the course

context 'when current user is the ta of the course which current assignment belongs to' do
it 'allows certain action' do
stub_current_user(ta, ta.role.name, ta.role)
allow(TaMapping).to receive(:exists?).with(ta_id: 8, course_id: 1).and_return(true)
expect(controller.send(:action_allowed?)).to be true
end
end

When the current logged in user is the instructor of the course

context 'when current user is the instructor of the course which current assignment belongs to' do
it 'allows certain action' do
stub_current_user(instructor2, instructor2.role.name, instructor2.role)
allow(Course).to receive(:find).with(1).and_return(double('Course', instructor_id: 66))
expect(controller.send(:action_allowed?)).to be true
end
end
end

When the parameter action is neither edit nor update, we do this by mocking the action to new

context 'when params action is not edit and update' do
before(:each) do
controller.params = {id: '1', action: 'new'}
end

We now check if super admin/admin/instructor/ta can perform this action which is neither edit nor update

context 'when the role current user is super admin/admin/instructor/ta' do
it 'allows certain action except edit and update' do
expect(controller.send(:action_allowed?)).to be true
end
end
end
end

And then we added few tests to test creation/edit/deletion of a duty

Creation of a duty, we create a duty and check if it is saved successfully

describe '#create' do

Checking if the right page is rendered after successful creation of a duty

context 'when new duty can be saved successfully' do
it 'sets up a new duty and redirects to assignment#edit page' do
allow(duty).to receive(:save).and_return('OK')
params = {
id: 1,
duty: {
duty_name: 'Scrum Master',
max_members_for_duty: 2,
assignment_id: 1
}
}
post :create, params
expect(response).to redirect_to('/assignments/1/edit')
expect(flash[:notice]).to match(/Role was successfully created.*/)
end
end

Test to check if the right error message is shown if the creation of duty is failed

context 'when new duty cannot be saved successfully' do
it 'shows error message and redirects to duty#new page' do
allow(duty).to receive(:errors)
params = {
id: 1,
duty: {
duty_name: 'Scrum Master',
max_members_for_duty: -1,
assignment_id: 1
}
}
post :create, params
expect(flash[:error]).to eq('Max members for duty must be greater than or equal to 1. ')
expect(response).to redirect_to('/duties/new?id=1')
end
end
end

Test to check the edit functionality of a duty

describe '#update' do

When the duty can be edited successfully, we check if the right page is rendered

context 'when duty can be found' do
it 'updates current duty and redirects to assignment#edit page' do
allow(Duty).to receive(:find).with('1').and_return(build(:duty, id: 1))
params = {
id: 1,
assignment_id: 1,
duty: {
duty_name: 'Scrum Master',
max_members_for_duty: 5,
assignment_id: 1
}
}
post :update, params
expect(response).to redirect_to('/assignments/1/edit')
expect(flash[:notice]).to match(/Role was successfully updated.*/)
end
end

When the duty cannot be updated, we check if the right error message is displayed

context 'when new duty cannot be updated successfully' do
it 'shows error message and redirects to duty#new page' do
allow(duty).to receive(:errors)
params = {
id: 1,
duty: {
duty_name: 'SM',
max_members_for_duty: 1,
assignment_id: 1
}
}
post :create, params
expect(flash[:error]).to eq('Duty name is too short (minimum is 3 characters). ')
expect(response).to redirect_to('/duties/new?id=1')
end
end
end

Now finally, we test the delete functionality of the duty

describe '#destroy' do
context 'when duty can be found' do
it 'redirects to assignment#edit page' do
params = {id: 1, assignment_id: 1}
post :destroy, params
expect(response).to redirect_to('/assignments/1/edit')
expect(flash[:notice]).to match(/Role was successfully destroyed.*/)
end
end
end

== team_users_controller_spec.rb ==

We have added a test case in this file which tests if the action is allowed only by specific user roles

First, we mock the data

''
describe TeamsUsersController do
let(:assignment) do
build(:assignment, id: 1, name: 'test assignment', instructor_id: 6, staggered_deadline: true, directory_path: 'same path',
participants: [build(:participant)], teams: [build(:assignment_team)], course_id: 1)
end
let(:assignment_form) { double('AssignmentForm', assignment: assignment) }
let(:student) { build(:student) }

before(:each) do
allow(Assignment).to receive(:find).with('1').and_return(assignment)
stub_current_user(student, student.role.name, student.role)
end
''

Then we check if the student can perform the update action for duties

''
describe '#action_allowed?' do
context 'when params action is update duties' do
before(:each) do
controller.params = {id: '1', action: 'update_duties'}
end
context 'when the role current user is student' do
it 'allows certain action' do
stub_current_user(student, student.role.name, student.role)
expect(controller.send(:action_allowed?)).to be true
end
end
end
end
''

This file also contains a test case to ensure the duties can be properly updated. The test case checks this by ensuring that the user is redirected to the student view page. just as with the previous section the first step is to mock the data by creating a team user object.

''
let(:teams_user1) {TeamsUser.new id:1, duty_id:1}
''

Then the data is actually updated and we ensure that the user is redirected to the proper place.

''
describe '#update_duties' do
it 'updates the duties for the participant' do
allow(TeamsUser).to receive(:find).with('1').and_return(teams_user1)
allow(teams_user1).to receive(:update_attribute).with(any_args).and_return('OK')
params = {
teams_user_id: '1',
teams_user: {duty_id: '1'},
participant_id: '1'
}
session = {user: stub_current_user(student, student.role.name, student.role)}
get :update_duties, params, session
expect(response).to redirect_to('/student_teams/view?student_id=1')
end
end
''

== assignment_form_spec.rb ==
The assignemnt_form_spec.rb file contains all the test files for the assignment form, which includes adding object to a queue. the first step was to create mock data so that the test could run on objects created for the tests. the code below shows how the mock data was created for the specific tests that we created to ensure the functionality of the projects.
''
let(:new_assignment_questionnaire) { build(:assignment_questionnaire) }
''
The new_assignment_questionnaire object is used for both test cases in this file. the first test case checks for when the active record cannot be found for a specific assignment id or duty id.
''
context 'when active record for assignment_questionnaire is not found for a given assignment_id and duty_id' do
it 'returns new instance of assignment_questionnaire with default values' do
allow(assignment).to receive(:questionnaire_varies_by_duty).and_return(true)
allow(AssignmentQuestionnaire).to receive(:where).with(assignment_id: 1, duty_id: anything).and_return([])
allow(AssignmentQuestionnaire).to receive(:where).with(user_id: anything, assignment_id: nil, questionnaire_id: nil).and_return([])
allow(AssignmentQuestionnaire).to receive(:new).and_return(new_assignment_questionnaire)
expect(assignment_form.assignment_questionnaire('TeammateReviewQuestionnaire', nil, nil, 1)).to eq(new_assignment_questionnaire)
end
end
''
The next next test checks when the assignment questionnaire is found given the assignment id and duty id parameters. this test is very similar to the one where the test is not found because the it searches through the active record to find the assignment questionnaire.
''
context 'when active record for assignment_questionnaire is found for a given assignment_id and duty_id' do
it 'returns new instance of assignment_questionnaire with default values' do
allow(assignment).to receive(:questionnaire_varies_by_duty).and_return(true)
allow(Questionnaire).to receive(:find).with(1).and_return(questionnaire3)
allow(AssignmentQuestionnaire).to receive(:where).with(assignment_id: 1, duty_id: 1).and_return([assignment_questionnaire2])
allow(AssignmentQuestionnaire).to receive(:where).with(user_id: anything, assignment_id: nil, questionnaire_id: nil).and_return([])
allow(AssignmentQuestionnaire).to receive(:new).and_return(new_assignment_questionnaire)
expect(assignment_form.assignment_questionnaire('TeammateReviewQuestionnaire', nil, nil, 1)).to eq(assignment_questionnaire2)
end
end
''

== duty_spec.rb ==
the main purpose of the duty_spec.rb file is to test any duty to make sure a duty can be assigned to a team member. it also tests if a duty is unavailable to a team member because the max number of people have been assigned that duty. to test this functionality the mock data is created to allow for testing of the objcect.
''
let(:assignment) { build(:assignment, id: 1, name: 'no assgt') }
let(:participant) { build(:participant, id:1, user_id: 1) }
let(:participant2) { build(:participant, id:2, user_id: 2) }
let(:participant3) { build(:participant, id:3, user_id: 3) }
let(:user) { build(:student, id: 1, name: 'no name', fullname: 'no one', participants: [participant]) }
let(:user2) { build(:student, id: 2, name: 'no name2', fullname: 'no one2', participants: [participant2]) }
let(:user3) { build(:student, id: 3, name: 'no name3', fullname: 'no one3', participants: [participant3]) }

let(:team1) { build(:assignment_team, id: 1, name: 'no team', users: [user, user2, user3]) }
let(:sample_duty_taken) { build(:duty, id: 1, max_members_for_duty:1, assignment_id:1) }
let(:sample_duty_not_taken) { build(:duty, id: 1, max_members_for_duty:2, assignment_id:1) }

let(:team_user1) { build(:team_user, id: 1, user: user) }
let(:team_user2) { build(:team_user, id: 2, user: user2) }
let(:team_user3) { build(:team_user, id: 3, user: user3, duty_id:1) }
''
an assignment is created on which the duties can be tested. for the testing multiple users and participants are created. Finally we created team users that could be assigned duties through the duty_id field. the next step was to set up the reoccurring steps for each of the tests.
''
before(:each) do
allow(team1).to receive(:participants).and_return([participant, participant2, participant3])
allow(participant).to receive(:get_team_user).and_return(team_user1)
allow(participant2).to receive(:get_team_user).and_return(team_user2)
allow(participant3).to receive(:get_team_user).and_return(team_user3)
end
''
Finally the actual tests were implemented. The tests are fairly simple because they just need to check if the duty can be assigned or not.
''
describe '#can_be_assigned?' do
context 'when users in current team want to assign roles that are available'
it 'returns true' do
expect(sample_duty_not_taken.can_be_assigned?(team1)).to be true
end
context 'when users in current team want to assign roles that are unavailable'
it 'returns false' do
expect(sample_duty_taken.can_be_assigned?(team1)).to be false
end
''

== teammate_review_response_map_spec.rb ==
This Rspec testing file tests that a specific questionnaire can be returned when the student has a role assigned to them. This is needed for the role based reviewing because when one student goes to review another they must get the correct questionnaire for their role. We tested this functionality as well as the inverse, when the role could not be found. initially we created the mock data for testing which is shown below.
''
let(:questionnaire) { Questionnaire.new name: "abc", private: 0, min_question_score: 0, max_question_score: 10, instructor_id: 1234 }
let(:assignment) { build(:assignment, id: 1, name: 'no assgt', is_duty_based_assignment: true, questionnaires: [questionnaire]) }
let(:assignment_questionnaire1) { build(:assignment_questionnaire, id: 1, assignment_id: 1, questionnaire_id: 2, duty_id: 1) }
let(:participant) { build(:participant, id: 1, user_id: 6, assignment: assignment) }
let(:teammate_review_response_map) { TeammateReviewResponseMap.new reviewer: participant, reviewer_is_team: true, assignment:assignment }
''
This step created the review response map that we would be testing as well as and assignment which contained a questionnaire. The next step was to actually test the data. First we decided to ensure that the correct questionnaire was returned with the following test. It compares the returned questionnaire with the one we know is correct.
''
it 'returns questionnaire specific to a duty' do
allow(AssignmentQuestionnaire).to receive(:where).with(assignment_id: 1, duty_id: 1).and_return([assignment_questionnaire1])
allow(Questionnaire).to receive(:find).with(assignment_questionnaire1.questionnaire_id).and_return(questionnaire)
expect(teammate_review_response_map.questionnaire_by_duty(1)).to eq questionnaire
end
''
Finally we added the inverse for when there was an error returning the questionnaire. in this case the program should return the default questionnaire.
''
it 'returns default questionnaire when no questionnaire is found for duty' do
allow(AssignmentQuestionnaire).to receive(:where).with(assignment_id: 1, duty_id: 1).and_return([])
allow(assignment.questionnaires).to receive(:find_by).with(type: 'TeammateReviewQuestionnaire').and_return(questionnaire)
expect(teammate_review_response_map.questionnaire_by_duty(1)).to eq questionnaire
end
''

== Manual Testing in Expertiza UI ==
Here we describe manual UI Testing steps to edit an existing assignment to allow it have to specialized rubrics for different topic types. These steps are also shown in recorded demo video.
*Login to Expertiza using instructor account (For testing, username: '''instructor6''', password: '''password''')
*Click on Manage > Assignments
*Click on Edit option for any assignment, you should get following view. Make sure '''Has topics?''' box is checked.
[[File:Assignment edit 3.png]]
*Click on Rubrics tab. You will see 2 checkboxes ('''Review rubric varies by round?''', '''Review rubric varies by topic?''')
*Check the box for '''Review rubric varies by topic?'''
*Go to Topics tab and verify that there is dropdown menu beside each Topic.
*Select a rubric from dropdown menu, and click '''Save'''
[[File:Topics rubric 2.png]]
*Go back to Home, and select the same assignment to edit. When you click on Topics tab, you should see the rubric you had selected.

==Team Information==
* Naman Shrimali
* Kanchan Rawat
* Subodh Thota
* Andrew Shipman
Mentor : Prof. Edward F. Gehringer

CSC/ECE 517 Fall 2021 - E2161. Merge code for role based reviewing with code for topic specific rubrics

2021-11-28T14:54:55Z

Ajshipma: /* duties_controller_spec.rb */

This wiki page contains description of changes designed and implemented for [https://docs.google.com/document/d/1slx4HPIbgTH-psIKMSCF-HDF9brxf-FuYhzVT9ZiIrM/edit#heading=h.8s6o9jnnxj0p E2161. Merge code for role-based reviewing with code for topic-specific rubrics], a Final Project for CSC/ECE 517, Fall 2021.
== Purpose==
In CSC/ECE 517, there are Expertiza-based course projects, Mozilla-based course projects, etc. However, currently, we can only specify one kind of rubric for all kinds of course projects. This means that refactoring projects, testing projects, and Mozilla projects need to use the same rubric. We hope we could specify different rubrics to be used with different kinds of course projects.

The project objective is to merge E2147-https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2147._Role-based_reviewing#E2147._Role-based_reviewing with the existing E2026-https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2020_-_E2026._Specialized_rubrics_for_different_topic_types. While merging, we found out that the code for E2026 has already been merged on Expertiza beta branch and so now the actual implementation is to write test cases for both E2147 and E2026.

==Brief Overview of E2147 and E2026 Projects==
*E2147(Role based reviewing): The project objective was to develop teammate review varying by the roles that each team member has in order to evaluate the particular role that each team member has taken rather than asking a generic questionnaire which was same for all the team members previously. For eg, the instructor would create a separate teammate questionnaire for developer role and for tester role respectively.
*E2026(Specialized rubrics for different topics): The project objective was to develop specialized rubrics based on project topics, previously we had same type of questionnaire for all the different types of projects. This implementation made sure that we evaluate different projects based on personalised rubrics rather than having same rubrics.

==Testing Plan==

===Test Scenarios for E2147(Role based reviewing)===
*Only Instructor/TA/Admin should be able to create or update duties: Only the instructor/admin should be able to create or update duties. Also, the corresponding TA of the assignment should be able to create or update duties.
*Create new roles: If the assignment is role based reviewing then the instructor should be able to create new roles for the same and save it in the database using new role functionality.
*Only allow student to update duties in Student View: Only student should be able to update his duties in Student View.
*Edit existing roles: Once the new roles have been created, then the instructor should be able to edit its details such as the maximum number of each role allowed.
*Delete existing roles: The instructor should also be able to delete any roles if he wants.
*Review rubric by role: On Rubrics tab, if the instructor clicks on Review rubric by role, then the corresponding rubric roles based teammate questionnaire should appear and get saved successfully.
*Student View: If the assignment is role based assignment, then the respective students should be able to see the respective teammate questionnaire based on roles for his other team members.
*Selection of Roles: On student login, a student should be able to see the existing roles that he can take up in the project. Only the roles which are available should be shown to the student.

===Test Scenarios for E2026(Specialized rubrics for different topics)===

As part of our implementation, we modified existing code as well as added new code. To ensure that existing functionality was not broken, and new functionality worked as expected, we used the following Test Strategy (which was also used by previous team):

===Run and pass existing RSpec Tests===
*The following existing RSpec test files have been modified and they pass as part of testing:
**spec/controllers/assignments_controller_spec.rb
**spec/controllers/questionnaires_controller_spec.rb
**spec/controllers/response_controller_spec.rb
**spec/factories/factories.rb
**spec/features/assignment_creation_spec.rb
**spec/features/quiz_spec.rb
**spec/features/staggered_deadline_spec.rb
**spec/models/assignment_form_spec.rb
**spec/models/assignment_spec.rb
**spec/models/on_the_fly_calc_spec.rb
**spec/models/response_spec.rb
**spec/models/review_response_map_spec.rb

===Develop New RSpec Tests===
*spec/helpers/duties_controller_spec.rb
*All these rspec tests passed.

== duties_controller_spec.rb ==
We have created this new test file to unit test the duties scenarios.

First we mock the data accordingly as needed by the tests.

''
describe DutiesController do
let(:assignment) { build(:assignment, id: 1,course_id: 1,instructor_id: 6, due_dates: [due_date], microtask: true, staggered_deadline: true)}
let(:admin) { build(:admin) }
let(:instructor) { build(:instructor, id: 6) }
let(:instructor2) { build(:instructor, id: 66) }
let(:ta) { build(:teaching_assistant, id: 8) }
let(:duty) { build(:duty, id: 1, duty_name: "Role", max_members_for_duty: 2, assignment_id: 1) }
let(:due_date) { build(:assignment_due_date, deadline_type_id: 1) } ''

We then run the arbitrary code that is needed before each test

''
before(:each) do
allow(Assignment).to receive(:find).with('1').and_return(assignment)
allow(Assignment).to receive(:find).with(1).and_return(assignment)
stub_current_user(instructor, instructor.role.name, instructor.role)
allow(Duty).to receive(:find).with('1').and_return(duty)
end
''

Test scenarios for duties controller:
1) Only admin, superadmin, TA, Instructor can perform edit or update action

'' describe '#action_allowed?' do ''

The whole context that defines if the action allowed is edit or update. We do this by mocking the action to edit

context 'when params action is edit or update' do
before(:each) do
controller.params = {id: '1', action: 'edit'}
end

When the current logged in user role is super admin or admin

context 'when the role name of current user is super admin or admin' do
it 'allows certain action' do
stub_current_user(admin, admin.role.name, admin.role)
expect(controller.send(:action_allowed?)).to be true
end
end

When the current logged in user role is instructor

context 'when current user is the instructor of current assignment' do
it 'allows certain action' do
expect(controller.send(:action_allowed?)).to be true
end
end

When the current logged in user role is the TA of the course

context 'when current user is the ta of the course which current assignment belongs to' do
it 'allows certain action' do
stub_current_user(ta, ta.role.name, ta.role)
allow(TaMapping).to receive(:exists?).with(ta_id: 8, course_id: 1).and_return(true)
expect(controller.send(:action_allowed?)).to be true
end
end

When the current logged in user is the instructor of the course

context 'when current user is the instructor of the course which current assignment belongs to' do
it 'allows certain action' do
stub_current_user(instructor2, instructor2.role.name, instructor2.role)
allow(Course).to receive(:find).with(1).and_return(double('Course', instructor_id: 66))
expect(controller.send(:action_allowed?)).to be true
end
end
end

When the parameter action is neither edit nor update, we do this by mocking the action to new

context 'when params action is not edit and update' do
before(:each) do
controller.params = {id: '1', action: 'new'}
end

We now check if super admin/admin/instructor/ta can perform this action which is neither edit nor update

context 'when the role current user is super admin/admin/instructor/ta' do
it 'allows certain action except edit and update' do
expect(controller.send(:action_allowed?)).to be true
end
end
end
end

And then we added few tests to test creation/edit/deletion of a duty

Creation of a duty, we create a duty and check if it is saved successfully

describe '#create' do

Checking if the right page is rendered after successful creation of a duty

context 'when new duty can be saved successfully' do
it 'sets up a new duty and redirects to assignment#edit page' do
allow(duty).to receive(:save).and_return('OK')
params = {
id: 1,
duty: {
duty_name: 'Scrum Master',
max_members_for_duty: 2,
assignment_id: 1
}
}
post :create, params
expect(response).to redirect_to('/assignments/1/edit')
expect(flash[:notice]).to match(/Role was successfully created.*/)
end
end

Test to check if the right error message is shown if the creation of duty is failed

context 'when new duty cannot be saved successfully' do
it 'shows error message and redirects to duty#new page' do
allow(duty).to receive(:errors)
params = {
id: 1,
duty: {
duty_name: 'Scrum Master',
max_members_for_duty: -1,
assignment_id: 1
}
}
post :create, params
expect(flash[:error]).to eq('Max members for duty must be greater than or equal to 1. ')
expect(response).to redirect_to('/duties/new?id=1')
end
end
end

Test to check the edit functionality of a duty

describe '#update' do

When the duty can be edited successfully, we check if the right page is rendered

context 'when duty can be found' do
it 'updates current duty and redirects to assignment#edit page' do
allow(Duty).to receive(:find).with('1').and_return(build(:duty, id: 1))
params = {
id: 1,
assignment_id: 1,
duty: {
duty_name: 'Scrum Master',
max_members_for_duty: 5,
assignment_id: 1
}
}
post :update, params
expect(response).to redirect_to('/assignments/1/edit')
expect(flash[:notice]).to match(/Role was successfully updated.*/)
end
end

When the duty cannot be updated, we check if the right error message is displayed

context 'when new duty cannot be updated successfully' do
it 'shows error message and redirects to duty#new page' do
allow(duty).to receive(:errors)
params = {
id: 1,
duty: {
duty_name: 'SM',
max_members_for_duty: 1,
assignment_id: 1
}
}
post :create, params
expect(flash[:error]).to eq('Duty name is too short (minimum is 3 characters). ')
expect(response).to redirect_to('/duties/new?id=1')
end
end
end

Now finally, we test the delete functionality of the duty

describe '#destroy' do
context 'when duty can be found' do
it 'redirects to assignment#edit page' do
params = {id: 1, assignment_id: 1}
post :destroy, params
expect(response).to redirect_to('/assignments/1/edit')
expect(flash[:notice]).to match(/Role was successfully destroyed.*/)
end
end
end

== team_users_controller_spec.rb ==

We have added a test case in this file which tests if the action is allowed only by specific user roles

First, we mock the data

''
describe TeamsUsersController do
let(:assignment) do
build(:assignment, id: 1, name: 'test assignment', instructor_id: 6, staggered_deadline: true, directory_path: 'same path',
participants: [build(:participant)], teams: [build(:assignment_team)], course_id: 1)
end
let(:assignment_form) { double('AssignmentForm', assignment: assignment) }
let(:student) { build(:student) }

before(:each) do
allow(Assignment).to receive(:find).with('1').and_return(assignment)
stub_current_user(student, student.role.name, student.role)
end
''

Then we check if the student can perform the update action for duties

''
describe '#action_allowed?' do
context 'when params action is update duties' do
before(:each) do
controller.params = {id: '1', action: 'update_duties'}
end
context 'when the role current user is student' do
it 'allows certain action' do
stub_current_user(student, student.role.name, student.role)
expect(controller.send(:action_allowed?)).to be true
end
end
end
end
''

This file also contains a test case to ensure the duties can be properly updated. The test case checks this by ensuring that the user is redirected to the student view page. just as with the previous section the first step is to mock the data by creating a team user object.

''
let(:teams_user1) {TeamsUser.new id:1, duty_id:1}
''

Then the data is actually updated and we ensure that the user is redirected to the proper place.

''
describe '#update_duties' do
it 'updates the duties for the participant' do
allow(TeamsUser).to receive(:find).with('1').and_return(teams_user1)
allow(teams_user1).to receive(:update_attribute).with(any_args).and_return('OK')
params = {
teams_user_id: '1',
teams_user: {duty_id: '1'},
participant_id: '1'
}
session = {user: stub_current_user(student, student.role.name, student.role)}
get :update_duties, params, session
expect(response).to redirect_to('/student_teams/view?student_id=1')
end
end
''

== assignment_form_spec.rb ==
The assignemnt_form_spec.rb file contains all the test files for the assignment form, which includes adding object to a queue. the first step was to create mock data so that the test could run on objects created for the tests. the code below shows how the mock data was created for the specific tests that we created to ensure the functionality of the projects.
''
let(:new_assignment_questionnaire) { build(:assignment_questionnaire) }
''
The new_assignment_questionnaire object is used for both test cases in this file. the first test case checks for when the active record cannot be found for a specific assignment id or duty id.
''
context 'when active record for assignment_questionnaire is not found for a given assignment_id and duty_id' do
it 'returns new instance of assignment_questionnaire with default values' do
allow(assignment).to receive(:questionnaire_varies_by_duty).and_return(true)
allow(AssignmentQuestionnaire).to receive(:where).with(assignment_id: 1, duty_id: anything).and_return([])
allow(AssignmentQuestionnaire).to receive(:where).with(user_id: anything, assignment_id: nil, questionnaire_id: nil).and_return([])
allow(AssignmentQuestionnaire).to receive(:new).and_return(new_assignment_questionnaire)
expect(assignment_form.assignment_questionnaire('TeammateReviewQuestionnaire', nil, nil, 1)).to eq(new_assignment_questionnaire)
end
end
''
The next next test checks when the assignment questionnaire is found given the assignment id and duty id parameters. this test is very similar to the one where the test is not found because the it searches through the active record to find the assignment questionnaire.
''
context 'when active record for assignment_questionnaire is found for a given assignment_id and duty_id' do
it 'returns new instance of assignment_questionnaire with default values' do
allow(assignment).to receive(:questionnaire_varies_by_duty).and_return(true)
allow(Questionnaire).to receive(:find).with(1).and_return(questionnaire3)
allow(AssignmentQuestionnaire).to receive(:where).with(assignment_id: 1, duty_id: 1).and_return([assignment_questionnaire2])
allow(AssignmentQuestionnaire).to receive(:where).with(user_id: anything, assignment_id: nil, questionnaire_id: nil).and_return([])
allow(AssignmentQuestionnaire).to receive(:new).and_return(new_assignment_questionnaire)
expect(assignment_form.assignment_questionnaire('TeammateReviewQuestionnaire', nil, nil, 1)).to eq(assignment_questionnaire2)
end
end
''

== duty_spec.rb ==
the main purpose of the duty_spec.rb file is to test any duty to make sure a duty can be assigned to a team member. it also tests if a duty is unavailable to a team member because the max number of people have been assigned that duty. to test this functionality the mock data is created to allow for testing of the objcect.
''
let(:assignment) { build(:assignment, id: 1, name: 'no assgt') }
let(:participant) { build(:participant, id:1, user_id: 1) }
let(:participant2) { build(:participant, id:2, user_id: 2) }
let(:participant3) { build(:participant, id:3, user_id: 3) }
let(:user) { build(:student, id: 1, name: 'no name', fullname: 'no one', participants: [participant]) }
let(:user2) { build(:student, id: 2, name: 'no name2', fullname: 'no one2', participants: [participant2]) }
let(:user3) { build(:student, id: 3, name: 'no name3', fullname: 'no one3', participants: [participant3]) }

let(:team1) { build(:assignment_team, id: 1, name: 'no team', users: [user, user2, user3]) }
let(:sample_duty_taken) { build(:duty, id: 1, max_members_for_duty:1, assignment_id:1) }
let(:sample_duty_not_taken) { build(:duty, id: 1, max_members_for_duty:2, assignment_id:1) }

let(:team_user1) { build(:team_user, id: 1, user: user) }
let(:team_user2) { build(:team_user, id: 2, user: user2) }
let(:team_user3) { build(:team_user, id: 3, user: user3, duty_id:1) }
''
an assignment is created on which the duties can be tested. for the testing multiple users and participants are created. Finally we created team users that could be assigned duties through the duty_id field. the next step was to set up the reoccurring steps for each of the tests.
''
before(:each) do
allow(team1).to receive(:participants).and_return([participant, participant2, participant3])
allow(participant).to receive(:get_team_user).and_return(team_user1)
allow(participant2).to receive(:get_team_user).and_return(team_user2)
allow(participant3).to receive(:get_team_user).and_return(team_user3)
end
''
Finally the actual tests were implemented. The tests are fairly simple because they just need to check if the duty can be assigned or not.
''
describe '#can_be_assigned?' do
context 'when users in current team want to assign roles that are available'
it 'returns true' do
expect(sample_duty_not_taken.can_be_assigned?(team1)).to be true
end
context 'when users in current team want to assign roles that are unavailable'
it 'returns false' do
expect(sample_duty_taken.can_be_assigned?(team1)).to be false
end
''

== teammate_review_response_map_spec.rb ==
This Rspec testing file tests that a specific questionnaire can be returned when the student has a role assigned to them. This is needed for the role based reviewing because when one student goes to review another they must get the correct questionnaire for their role. We tested this functionality as well as the inverse, when the role could not be found. initially we created the mock data for testing which is shown below.
''
let(:questionnaire) { Questionnaire.new name: "abc", private: 0, min_question_score: 0, max_question_score: 10, instructor_id: 1234 }
let(:assignment) { build(:assignment, id: 1, name: 'no assgt', is_duty_based_assignment: true, questionnaires: [questionnaire]) }
let(:assignment_questionnaire1) { build(:assignment_questionnaire, id: 1, assignment_id: 1, questionnaire_id: 2, duty_id: 1) }
let(:participant) { build(:participant, id: 1, user_id: 6, assignment: assignment) }
let(:teammate_review_response_map) { TeammateReviewResponseMap.new reviewer: participant, reviewer_is_team: true, assignment:assignment }
''
This step created the review response map that we would be testing as well as and assignment which contained a questionnaire. The next step was to actually test the data. First we decided to ensure that the correct questionnaire was returned with the following test. It compares the returned questionnaire with the one we know is correct.
''
it 'returns questionnaire specific to a duty' do
allow(AssignmentQuestionnaire).to receive(:where).with(assignment_id: 1, duty_id: 1).and_return([assignment_questionnaire1])
allow(Questionnaire).to receive(:find).with(assignment_questionnaire1.questionnaire_id).and_return(questionnaire)
expect(teammate_review_response_map.questionnaire_by_duty(1)).to eq questionnaire
end
''
Finally we added the inverse for when there was an error returning the questionnaire. in this case the program should return the default questionnaire.
''
it 'returns default questionnaire when no questionnaire is found for duty' do
allow(AssignmentQuestionnaire).to receive(:where).with(assignment_id: 1, duty_id: 1).and_return([])
allow(assignment.questionnaires).to receive(:find_by).with(type: 'TeammateReviewQuestionnaire').and_return(questionnaire)
expect(teammate_review_response_map.questionnaire_by_duty(1)).to eq questionnaire
end
''

== duties_controller_spec.rb ==
the duties_controller_spec.rb file tested the functionality of the duties themselves which was the main part of our project. For this reason this was probably the longest testing file that we wrote. It needed to contain many test cases for duties as it tested everything about them. Firstly we began by creating the mock data that would be used throughout all the tests. This included and admin, an assignment, instructors, a teaching assistant, a duty, and a due date.
''
let(:assignment) { build(:assignment, id: 1,course_id: 1,instructor_id: 6, due_dates: [due_date], microtask: true, staggered_deadline: true)}
let(:admin) { build(:admin) }
let(:instructor) { build(:instructor, id: 6) }
let(:instructor2) { build(:instructor, id: 66) }
let(:ta) { build(:teaching_assistant, id: 8) }
let(:duty) { build(:duty, id: 1, duty_name: "Role", max_members_for_duty: 2, assignment_id: 1) }
let(:due_date) { build(:assignment_due_date, deadline_type_id: 1) }
''
next the before each block initializing all the tests.
''
before(:each) do
allow(Assignment).to receive(:find).with('1').and_return(assignment)
allow(Assignment).to receive(:find).with(1).and_return(assignment)
stub_current_user(instructor, instructor.role.name, instructor.role)
allow(Duty).to receive(:find).with('1').and_return(duty)
end
''
After this it was time to begin the actual testing. the first test was a test on the #action_allowed? method to ensure that the permissions worked and only people with the correct account type could change the data. only instructors and tas should be able to create roles and questionnaires for the roles. Students should be the ones who assign the roles within their group. We wrote 6 tests to test this functionality.
''
describe '#action_allowed?' do
context 'when params action is edit or update' do
before(:each) do
controller.params = {id: '1', action: 'edit'}
end

context 'when the role name of current user is super admin or admin' do
it 'allows certain action' do
stub_current_user(admin, admin.role.name, admin.role)
expect(controller.send(:action_allowed?)).to be true
end
end

context 'when current user is the instructor of current assignment' do
it 'allows certain action' do
expect(controller.send(:action_allowed?)).to be true
end
end

context 'when current user is the ta of the course which current assignment belongs to' do
it 'allows certain action' do
stub_current_user(ta, ta.role.name, ta.role)
allow(TaMapping).to receive(:exists?).with(ta_id: 8, course_id: 1).and_return(true)
expect(controller.send(:action_allowed?)).to be true
end
end

context 'when current user is the instructor of the course which current assignment belongs to' do
it 'allows certain action' do
stub_current_user(instructor2, instructor2.role.name, instructor2.role)
allow(Course).to receive(:find).with(1).and_return(double('Course', instructor_id: 66))
expect(controller.send(:action_allowed?)).to be true
end
end
end

context 'when params action is not edit and update' do
before(:each) do
controller.params = {id: '1', action: 'new'}
end

context 'when the role current user is super admin/admin/instructor/ta' do
it 'allows certain action except edit and update' do
expect(controller.send(:action_allowed?)).to be true
end
end
end
end
''
Next we tested the basic functionality of the duty object to make sure the data could be edited as needed. This part of the testing included testing the create, update and destroy methods. First up was the create method which is shown in the code below. The main testing for this is to make sure the correct thing happens when the duty is saved, as well as when there is an error saving it.
''
describe '#create' do
context 'when new duty can be saved successfully' do
it 'sets up a new duty and redirects to assignment#edit page' do
allow(duty).to receive(:save).and_return('OK')
params = {
id: 1,
duty: {
duty_name: 'Scrum Master',
max_members_for_duty: 2,
assignment_id: 1
}
}
post :create, params
expect(response).to redirect_to('/assignments/1/edit')
expect(flash[:notice]).to match(/Role was successfully created.*/)
end
end

context 'when new duty cannot be saved successfully' do
it 'shows error message and redirects to duty#new page' do
allow(duty).to receive(:errors)
params = {
id: 1,
duty: {
duty_name: 'Scrum Master',
max_members_for_duty: -1,
assignment_id: 1
}
}
post :create, params
expect(flash[:error]).to eq('Max members for duty must be greater than or equal to 1. ')
expect(response).to redirect_to('/duties/new?id=1')
end
end
end
''

== Manual Testing in Expertiza UI ==
Here we describe manual UI Testing steps to edit an existing assignment to allow it have to specialized rubrics for different topic types. These steps are also shown in recorded demo video.
*Login to Expertiza using instructor account (For testing, username: '''instructor6''', password: '''password''')
*Click on Manage > Assignments
*Click on Edit option for any assignment, you should get following view. Make sure '''Has topics?''' box is checked.
[[File:Assignment edit 3.png]]
*Click on Rubrics tab. You will see 2 checkboxes ('''Review rubric varies by round?''', '''Review rubric varies by topic?''')
*Check the box for '''Review rubric varies by topic?'''
*Go to Topics tab and verify that there is dropdown menu beside each Topic.
*Select a rubric from dropdown menu, and click '''Save'''
[[File:Topics rubric 2.png]]
*Go back to Home, and select the same assignment to edit. When you click on Topics tab, you should see the rubric you had selected.

==Team Information==
* Naman Shrimali
* Kanchan Rawat
* Subodh Thota
* Andrew Shipman
Mentor : Prof. Edward F. Gehringer

CSC/ECE 517 Fall 2021 - E2161. Merge code for role based reviewing with code for topic specific rubrics

2021-11-28T14:53:13Z

Ajshipma: /* duties_controller_spec.rb */

This wiki page contains description of changes designed and implemented for [https://docs.google.com/document/d/1slx4HPIbgTH-psIKMSCF-HDF9brxf-FuYhzVT9ZiIrM/edit#heading=h.8s6o9jnnxj0p E2161. Merge code for role-based reviewing with code for topic-specific rubrics], a Final Project for CSC/ECE 517, Fall 2021.
== Purpose==
In CSC/ECE 517, there are Expertiza-based course projects, Mozilla-based course projects, etc. However, currently, we can only specify one kind of rubric for all kinds of course projects. This means that refactoring projects, testing projects, and Mozilla projects need to use the same rubric. We hope we could specify different rubrics to be used with different kinds of course projects.

The project objective is to merge E2147-https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2147._Role-based_reviewing#E2147._Role-based_reviewing with the existing E2026-https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2020_-_E2026._Specialized_rubrics_for_different_topic_types. While merging, we found out that the code for E2026 has already been merged on Expertiza beta branch and so now the actual implementation is to write test cases for both E2147 and E2026.

==Brief Overview of E2147 and E2026 Projects==
*E2147(Role based reviewing): The project objective was to develop teammate review varying by the roles that each team member has in order to evaluate the particular role that each team member has taken rather than asking a generic questionnaire which was same for all the team members previously. For eg, the instructor would create a separate teammate questionnaire for developer role and for tester role respectively.
*E2026(Specialized rubrics for different topics): The project objective was to develop specialized rubrics based on project topics, previously we had same type of questionnaire for all the different types of projects. This implementation made sure that we evaluate different projects based on personalised rubrics rather than having same rubrics.

==Testing Plan==

===Test Scenarios for E2147(Role based reviewing)===
*Only Instructor/TA/Admin should be able to create or update duties: Only the instructor/admin should be able to create or update duties. Also, the corresponding TA of the assignment should be able to create or update duties.
*Create new roles: If the assignment is role based reviewing then the instructor should be able to create new roles for the same and save it in the database using new role functionality.
*Only allow student to update duties in Student View: Only student should be able to update his duties in Student View.
*Edit existing roles: Once the new roles have been created, then the instructor should be able to edit its details such as the maximum number of each role allowed.
*Delete existing roles: The instructor should also be able to delete any roles if he wants.
*Review rubric by role: On Rubrics tab, if the instructor clicks on Review rubric by role, then the corresponding rubric roles based teammate questionnaire should appear and get saved successfully.
*Student View: If the assignment is role based assignment, then the respective students should be able to see the respective teammate questionnaire based on roles for his other team members.
*Selection of Roles: On student login, a student should be able to see the existing roles that he can take up in the project. Only the roles which are available should be shown to the student.

===Test Scenarios for E2026(Specialized rubrics for different topics)===

As part of our implementation, we modified existing code as well as added new code. To ensure that existing functionality was not broken, and new functionality worked as expected, we used the following Test Strategy (which was also used by previous team):

===Run and pass existing RSpec Tests===
*The following existing RSpec test files have been modified and they pass as part of testing:
**spec/controllers/assignments_controller_spec.rb
**spec/controllers/questionnaires_controller_spec.rb
**spec/controllers/response_controller_spec.rb
**spec/factories/factories.rb
**spec/features/assignment_creation_spec.rb
**spec/features/quiz_spec.rb
**spec/features/staggered_deadline_spec.rb
**spec/models/assignment_form_spec.rb
**spec/models/assignment_spec.rb
**spec/models/on_the_fly_calc_spec.rb
**spec/models/response_spec.rb
**spec/models/review_response_map_spec.rb

===Develop New RSpec Tests===
*spec/helpers/duties_controller_spec.rb
*All these rspec tests passed.

== duties_controller_spec.rb ==
We have created this new test file to unit test the duties scenarios.

First we mock the data accordingly as needed by the tests.

''
describe DutiesController do
let(:assignment) { build(:assignment, id: 1,course_id: 1,instructor_id: 6, due_dates: [due_date], microtask: true, staggered_deadline: true)}
let(:admin) { build(:admin) }
let(:instructor) { build(:instructor, id: 6) }
let(:instructor2) { build(:instructor, id: 66) }
let(:ta) { build(:teaching_assistant, id: 8) }
let(:duty) { build(:duty, id: 1, duty_name: "Role", max_members_for_duty: 2, assignment_id: 1) }
let(:due_date) { build(:assignment_due_date, deadline_type_id: 1) } ''

We then run the arbitrary code that is needed before each test

''
before(:each) do
allow(Assignment).to receive(:find).with('1').and_return(assignment)
allow(Assignment).to receive(:find).with(1).and_return(assignment)
stub_current_user(instructor, instructor.role.name, instructor.role)
allow(Duty).to receive(:find).with('1').and_return(duty)
end
''

Test scenarios for duties controller:
1) Only admin, superadmin, TA, Instructor can perform edit or update action

'' describe '#action_allowed?' do ''

The whole context that defines if the action allowed is edit or update. We do this by mocking the action to edit

context 'when params action is edit or update' do
before(:each) do
controller.params = {id: '1', action: 'edit'}
end

When the current logged in user role is super admin or admin

context 'when the role name of current user is super admin or admin' do
it 'allows certain action' do
stub_current_user(admin, admin.role.name, admin.role)
expect(controller.send(:action_allowed?)).to be true
end
end

When the current logged in user role is instructor

context 'when current user is the instructor of current assignment' do
it 'allows certain action' do
expect(controller.send(:action_allowed?)).to be true
end
end

When the current logged in user role is the TA of the course

context 'when current user is the ta of the course which current assignment belongs to' do
it 'allows certain action' do
stub_current_user(ta, ta.role.name, ta.role)
allow(TaMapping).to receive(:exists?).with(ta_id: 8, course_id: 1).and_return(true)
expect(controller.send(:action_allowed?)).to be true
end
end

When the current logged in user is the instructor of the course

context 'when current user is the instructor of the course which current assignment belongs to' do
it 'allows certain action' do
stub_current_user(instructor2, instructor2.role.name, instructor2.role)
allow(Course).to receive(:find).with(1).and_return(double('Course', instructor_id: 66))
expect(controller.send(:action_allowed?)).to be true
end
end
end

When the parameter action is neither edit nor update, we do this by mocking the action to new

context 'when params action is not edit and update' do
before(:each) do
controller.params = {id: '1', action: 'new'}
end

We now check if super admin/admin/instructor/ta can perform this action which is neither edit nor update

context 'when the role current user is super admin/admin/instructor/ta' do
it 'allows certain action except edit and update' do
expect(controller.send(:action_allowed?)).to be true
end
end
end
end

And then we added few tests to test creation/edit/deletion of a duty

Creation of a duty, we create a duty and check if it is saved successfully

describe '#create' do

Checking if the right page is rendered after successful creation of a duty

context 'when new duty can be saved successfully' do
it 'sets up a new duty and redirects to assignment#edit page' do
allow(duty).to receive(:save).and_return('OK')
params = {
id: 1,
duty: {
duty_name: 'Scrum Master',
max_members_for_duty: 2,
assignment_id: 1
}
}
post :create, params
expect(response).to redirect_to('/assignments/1/edit')
expect(flash[:notice]).to match(/Role was successfully created.*/)
end
end

Test to check if the right error message is shown if the creation of duty is failed

context 'when new duty cannot be saved successfully' do
it 'shows error message and redirects to duty#new page' do
allow(duty).to receive(:errors)
params = {
id: 1,
duty: {
duty_name: 'Scrum Master',
max_members_for_duty: -1,
assignment_id: 1
}
}
post :create, params
expect(flash[:error]).to eq('Max members for duty must be greater than or equal to 1. ')
expect(response).to redirect_to('/duties/new?id=1')
end
end
end

Test to check the edit functionality of a duty

describe '#update' do

When the duty can be edited successfully, we check if the right page is rendered

context 'when duty can be found' do
it 'updates current duty and redirects to assignment#edit page' do
allow(Duty).to receive(:find).with('1').and_return(build(:duty, id: 1))
params = {
id: 1,
assignment_id: 1,
duty: {
duty_name: 'Scrum Master',
max_members_for_duty: 5,
assignment_id: 1
}
}
post :update, params
expect(response).to redirect_to('/assignments/1/edit')
expect(flash[:notice]).to match(/Role was successfully updated.*/)
end
end

When the duty cannot be updated, we check if the right error message is displayed

context 'when new duty cannot be updated successfully' do
it 'shows error message and redirects to duty#new page' do
allow(duty).to receive(:errors)
params = {
id: 1,
duty: {
duty_name: 'SM',
max_members_for_duty: 1,
assignment_id: 1
}
}
post :create, params
expect(flash[:error]).to eq('Duty name is too short (minimum is 3 characters). ')
expect(response).to redirect_to('/duties/new?id=1')
end
end
end

Now finally, we test the delete functionality of the duty

describe '#destroy' do
context 'when duty can be found' do
it 'redirects to assignment#edit page' do
params = {id: 1, assignment_id: 1}
post :destroy, params
expect(response).to redirect_to('/assignments/1/edit')
expect(flash[:notice]).to match(/Role was successfully destroyed.*/)
end
end
end

== team_users_controller_spec.rb ==

We have added a test case in this file which tests if the action is allowed only by specific user roles

First, we mock the data

''
describe TeamsUsersController do
let(:assignment) do
build(:assignment, id: 1, name: 'test assignment', instructor_id: 6, staggered_deadline: true, directory_path: 'same path',
participants: [build(:participant)], teams: [build(:assignment_team)], course_id: 1)
end
let(:assignment_form) { double('AssignmentForm', assignment: assignment) }
let(:student) { build(:student) }

before(:each) do
allow(Assignment).to receive(:find).with('1').and_return(assignment)
stub_current_user(student, student.role.name, student.role)
end
''

Then we check if the student can perform the update action for duties

''
describe '#action_allowed?' do
context 'when params action is update duties' do
before(:each) do
controller.params = {id: '1', action: 'update_duties'}
end
context 'when the role current user is student' do
it 'allows certain action' do
stub_current_user(student, student.role.name, student.role)
expect(controller.send(:action_allowed?)).to be true
end
end
end
end
''

This file also contains a test case to ensure the duties can be properly updated. The test case checks this by ensuring that the user is redirected to the student view page. just as with the previous section the first step is to mock the data by creating a team user object.

''
let(:teams_user1) {TeamsUser.new id:1, duty_id:1}
''

Then the data is actually updated and we ensure that the user is redirected to the proper place.

''
describe '#update_duties' do
it 'updates the duties for the participant' do
allow(TeamsUser).to receive(:find).with('1').and_return(teams_user1)
allow(teams_user1).to receive(:update_attribute).with(any_args).and_return('OK')
params = {
teams_user_id: '1',
teams_user: {duty_id: '1'},
participant_id: '1'
}
session = {user: stub_current_user(student, student.role.name, student.role)}
get :update_duties, params, session
expect(response).to redirect_to('/student_teams/view?student_id=1')
end
end
''

== assignment_form_spec.rb ==
The assignemnt_form_spec.rb file contains all the test files for the assignment form, which includes adding object to a queue. the first step was to create mock data so that the test could run on objects created for the tests. the code below shows how the mock data was created for the specific tests that we created to ensure the functionality of the projects.
''
let(:new_assignment_questionnaire) { build(:assignment_questionnaire) }
''
The new_assignment_questionnaire object is used for both test cases in this file. the first test case checks for when the active record cannot be found for a specific assignment id or duty id.
''
context 'when active record for assignment_questionnaire is not found for a given assignment_id and duty_id' do
it 'returns new instance of assignment_questionnaire with default values' do
allow(assignment).to receive(:questionnaire_varies_by_duty).and_return(true)
allow(AssignmentQuestionnaire).to receive(:where).with(assignment_id: 1, duty_id: anything).and_return([])
allow(AssignmentQuestionnaire).to receive(:where).with(user_id: anything, assignment_id: nil, questionnaire_id: nil).and_return([])
allow(AssignmentQuestionnaire).to receive(:new).and_return(new_assignment_questionnaire)
expect(assignment_form.assignment_questionnaire('TeammateReviewQuestionnaire', nil, nil, 1)).to eq(new_assignment_questionnaire)
end
end
''
The next next test checks when the assignment questionnaire is found given the assignment id and duty id parameters. this test is very similar to the one where the test is not found because the it searches through the active record to find the assignment questionnaire.
''
context 'when active record for assignment_questionnaire is found for a given assignment_id and duty_id' do
it 'returns new instance of assignment_questionnaire with default values' do
allow(assignment).to receive(:questionnaire_varies_by_duty).and_return(true)
allow(Questionnaire).to receive(:find).with(1).and_return(questionnaire3)
allow(AssignmentQuestionnaire).to receive(:where).with(assignment_id: 1, duty_id: 1).and_return([assignment_questionnaire2])
allow(AssignmentQuestionnaire).to receive(:where).with(user_id: anything, assignment_id: nil, questionnaire_id: nil).and_return([])
allow(AssignmentQuestionnaire).to receive(:new).and_return(new_assignment_questionnaire)
expect(assignment_form.assignment_questionnaire('TeammateReviewQuestionnaire', nil, nil, 1)).to eq(assignment_questionnaire2)
end
end
''

== duty_spec.rb ==
the main purpose of the duty_spec.rb file is to test any duty to make sure a duty can be assigned to a team member. it also tests if a duty is unavailable to a team member because the max number of people have been assigned that duty. to test this functionality the mock data is created to allow for testing of the objcect.
''
let(:assignment) { build(:assignment, id: 1, name: 'no assgt') }
let(:participant) { build(:participant, id:1, user_id: 1) }
let(:participant2) { build(:participant, id:2, user_id: 2) }
let(:participant3) { build(:participant, id:3, user_id: 3) }
let(:user) { build(:student, id: 1, name: 'no name', fullname: 'no one', participants: [participant]) }
let(:user2) { build(:student, id: 2, name: 'no name2', fullname: 'no one2', participants: [participant2]) }
let(:user3) { build(:student, id: 3, name: 'no name3', fullname: 'no one3', participants: [participant3]) }

let(:team1) { build(:assignment_team, id: 1, name: 'no team', users: [user, user2, user3]) }
let(:sample_duty_taken) { build(:duty, id: 1, max_members_for_duty:1, assignment_id:1) }
let(:sample_duty_not_taken) { build(:duty, id: 1, max_members_for_duty:2, assignment_id:1) }

let(:team_user1) { build(:team_user, id: 1, user: user) }
let(:team_user2) { build(:team_user, id: 2, user: user2) }
let(:team_user3) { build(:team_user, id: 3, user: user3, duty_id:1) }
''
an assignment is created on which the duties can be tested. for the testing multiple users and participants are created. Finally we created team users that could be assigned duties through the duty_id field. the next step was to set up the reoccurring steps for each of the tests.
''
before(:each) do
allow(team1).to receive(:participants).and_return([participant, participant2, participant3])
allow(participant).to receive(:get_team_user).and_return(team_user1)
allow(participant2).to receive(:get_team_user).and_return(team_user2)
allow(participant3).to receive(:get_team_user).and_return(team_user3)
end
''
Finally the actual tests were implemented. The tests are fairly simple because they just need to check if the duty can be assigned or not.
''
describe '#can_be_assigned?' do
context 'when users in current team want to assign roles that are available'
it 'returns true' do
expect(sample_duty_not_taken.can_be_assigned?(team1)).to be true
end
context 'when users in current team want to assign roles that are unavailable'
it 'returns false' do
expect(sample_duty_taken.can_be_assigned?(team1)).to be false
end
''

== teammate_review_response_map_spec.rb ==
This Rspec testing file tests that a specific questionnaire can be returned when the student has a role assigned to them. This is needed for the role based reviewing because when one student goes to review another they must get the correct questionnaire for their role. We tested this functionality as well as the inverse, when the role could not be found. initially we created the mock data for testing which is shown below.
''
let(:questionnaire) { Questionnaire.new name: "abc", private: 0, min_question_score: 0, max_question_score: 10, instructor_id: 1234 }
let(:assignment) { build(:assignment, id: 1, name: 'no assgt', is_duty_based_assignment: true, questionnaires: [questionnaire]) }
let(:assignment_questionnaire1) { build(:assignment_questionnaire, id: 1, assignment_id: 1, questionnaire_id: 2, duty_id: 1) }
let(:participant) { build(:participant, id: 1, user_id: 6, assignment: assignment) }
let(:teammate_review_response_map) { TeammateReviewResponseMap.new reviewer: participant, reviewer_is_team: true, assignment:assignment }
''
This step created the review response map that we would be testing as well as and assignment which contained a questionnaire. The next step was to actually test the data. First we decided to ensure that the correct questionnaire was returned with the following test. It compares the returned questionnaire with the one we know is correct.
''
it 'returns questionnaire specific to a duty' do
allow(AssignmentQuestionnaire).to receive(:where).with(assignment_id: 1, duty_id: 1).and_return([assignment_questionnaire1])
allow(Questionnaire).to receive(:find).with(assignment_questionnaire1.questionnaire_id).and_return(questionnaire)
expect(teammate_review_response_map.questionnaire_by_duty(1)).to eq questionnaire
end
''
Finally we added the inverse for when there was an error returning the questionnaire. in this case the program should return the default questionnaire.
''
it 'returns default questionnaire when no questionnaire is found for duty' do
allow(AssignmentQuestionnaire).to receive(:where).with(assignment_id: 1, duty_id: 1).and_return([])
allow(assignment.questionnaires).to receive(:find_by).with(type: 'TeammateReviewQuestionnaire').and_return(questionnaire)
expect(teammate_review_response_map.questionnaire_by_duty(1)).to eq questionnaire
end
''

== duties_controller_spec.rb ==
the duties_controller_spec.rb file tested the functionality of the duties themselves which was the main part of our project. For this reason this was probably the longest testing file that we wrote. It needed to contain many test cases for duties as it tested everything about them. Firstly we began by creating the mock data that would be used throughout all the tests. This included and admin, an assignment, instructors, a teaching assistant, a duty, and a due date.
''
let(:assignment) { build(:assignment, id: 1,course_id: 1,instructor_id: 6, due_dates: [due_date], microtask: true, staggered_deadline: true)}
let(:admin) { build(:admin) }
let(:instructor) { build(:instructor, id: 6) }
let(:instructor2) { build(:instructor, id: 66) }
let(:ta) { build(:teaching_assistant, id: 8) }
let(:duty) { build(:duty, id: 1, duty_name: "Role", max_members_for_duty: 2, assignment_id: 1) }
let(:due_date) { build(:assignment_due_date, deadline_type_id: 1) }
''
next the before each block initializing all the tests.
''
before(:each) do
allow(Assignment).to receive(:find).with('1').and_return(assignment)
allow(Assignment).to receive(:find).with(1).and_return(assignment)
stub_current_user(instructor, instructor.role.name, instructor.role)
allow(Duty).to receive(:find).with('1').and_return(duty)
end
''
After this it was time to begin the actual testing. the first test was a test on the #action_allowed? method to ensure that the permissions worked and only people with the correct account type could change the data. only instructors and tas should be able to create roles and questionnaires for the roles. Students should be the ones who assign the roles within their group. We wrote 6 tests to test this functionality.
''
describe '#action_allowed?' do
context 'when params action is edit or update' do
before(:each) do
controller.params = {id: '1', action: 'edit'}
end

context 'when the role name of current user is super admin or admin' do
it 'allows certain action' do
stub_current_user(admin, admin.role.name, admin.role)
expect(controller.send(:action_allowed?)).to be true
end
end

context 'when current user is the instructor of current assignment' do
it 'allows certain action' do
expect(controller.send(:action_allowed?)).to be true
end
end

context 'when current user is the ta of the course which current assignment belongs to' do
it 'allows certain action' do
stub_current_user(ta, ta.role.name, ta.role)
allow(TaMapping).to receive(:exists?).with(ta_id: 8, course_id: 1).and_return(true)
expect(controller.send(:action_allowed?)).to be true
end
end

context 'when current user is the instructor of the course which current assignment belongs to' do
it 'allows certain action' do
stub_current_user(instructor2, instructor2.role.name, instructor2.role)
allow(Course).to receive(:find).with(1).and_return(double('Course', instructor_id: 66))
expect(controller.send(:action_allowed?)).to be true
end
end
end

context 'when params action is not edit and update' do
before(:each) do
controller.params = {id: '1', action: 'new'}
end

context 'when the role current user is super admin/admin/instructor/ta' do
it 'allows certain action except edit and update' do
expect(controller.send(:action_allowed?)).to be true
end
end
end
end
''
Next we tested the basic functionality of the duty object to make sure the data could be edited as needed. This part of the testing included testing the create, update and destroy methods.
''
describe '#create' do
context 'when new duty can be saved successfully' do
it 'sets up a new duty and redirects to assignment#edit page' do
allow(duty).to receive(:save).and_return('OK')
params = {
id: 1,
duty: {
duty_name: 'Scrum Master',
max_members_for_duty: 2,
assignment_id: 1
}
}
post :create, params
expect(response).to redirect_to('/assignments/1/edit')
expect(flash[:notice]).to match(/Role was successfully created.*/)
end
end

context 'when new duty cannot be saved successfully' do
it 'shows error message and redirects to duty#new page' do
allow(duty).to receive(:errors)
params = {
id: 1,
duty: {
duty_name: 'Scrum Master',
max_members_for_duty: -1,
assignment_id: 1
}
}
post :create, params
expect(flash[:error]).to eq('Max members for duty must be greater than or equal to 1. ')
expect(response).to redirect_to('/duties/new?id=1')
end
end
end
''

== Manual Testing in Expertiza UI ==
Here we describe manual UI Testing steps to edit an existing assignment to allow it have to specialized rubrics for different topic types. These steps are also shown in recorded demo video.
*Login to Expertiza using instructor account (For testing, username: '''instructor6''', password: '''password''')
*Click on Manage > Assignments
*Click on Edit option for any assignment, you should get following view. Make sure '''Has topics?''' box is checked.
[[File:Assignment edit 3.png]]
*Click on Rubrics tab. You will see 2 checkboxes ('''Review rubric varies by round?''', '''Review rubric varies by topic?''')
*Check the box for '''Review rubric varies by topic?'''
*Go to Topics tab and verify that there is dropdown menu beside each Topic.
*Select a rubric from dropdown menu, and click '''Save'''
[[File:Topics rubric 2.png]]
*Go back to Home, and select the same assignment to edit. When you click on Topics tab, you should see the rubric you had selected.

==Team Information==
* Naman Shrimali
* Kanchan Rawat
* Subodh Thota
* Andrew Shipman
Mentor : Prof. Edward F. Gehringer

CSC/ECE 517 Fall 2021 - E2161. Merge code for role based reviewing with code for topic specific rubrics

2021-11-28T14:46:45Z

Ajshipma: /* duties_controller_spec.rb */

This wiki page contains description of changes designed and implemented for [https://docs.google.com/document/d/1slx4HPIbgTH-psIKMSCF-HDF9brxf-FuYhzVT9ZiIrM/edit#heading=h.8s6o9jnnxj0p E2161. Merge code for role-based reviewing with code for topic-specific rubrics], a Final Project for CSC/ECE 517, Fall 2021.
== Purpose==
In CSC/ECE 517, there are Expertiza-based course projects, Mozilla-based course projects, etc. However, currently, we can only specify one kind of rubric for all kinds of course projects. This means that refactoring projects, testing projects, and Mozilla projects need to use the same rubric. We hope we could specify different rubrics to be used with different kinds of course projects.

The project objective is to merge E2147-https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2147._Role-based_reviewing#E2147._Role-based_reviewing with the existing E2026-https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2020_-_E2026._Specialized_rubrics_for_different_topic_types. While merging, we found out that the code for E2026 has already been merged on Expertiza beta branch and so now the actual implementation is to write test cases for both E2147 and E2026.

==Brief Overview of E2147 and E2026 Projects==
*E2147(Role based reviewing): The project objective was to develop teammate review varying by the roles that each team member has in order to evaluate the particular role that each team member has taken rather than asking a generic questionnaire which was same for all the team members previously. For eg, the instructor would create a separate teammate questionnaire for developer role and for tester role respectively.
*E2026(Specialized rubrics for different topics): The project objective was to develop specialized rubrics based on project topics, previously we had same type of questionnaire for all the different types of projects. This implementation made sure that we evaluate different projects based on personalised rubrics rather than having same rubrics.

==Testing Plan==

===Test Scenarios for E2147(Role based reviewing)===
*Only Instructor/TA/Admin should be able to create or update duties: Only the instructor/admin should be able to create or update duties. Also, the corresponding TA of the assignment should be able to create or update duties.
*Create new roles: If the assignment is role based reviewing then the instructor should be able to create new roles for the same and save it in the database using new role functionality.
*Only allow student to update duties in Student View: Only student should be able to update his duties in Student View.
*Edit existing roles: Once the new roles have been created, then the instructor should be able to edit its details such as the maximum number of each role allowed.
*Delete existing roles: The instructor should also be able to delete any roles if he wants.
*Review rubric by role: On Rubrics tab, if the instructor clicks on Review rubric by role, then the corresponding rubric roles based teammate questionnaire should appear and get saved successfully.
*Student View: If the assignment is role based assignment, then the respective students should be able to see the respective teammate questionnaire based on roles for his other team members.
*Selection of Roles: On student login, a student should be able to see the existing roles that he can take up in the project. Only the roles which are available should be shown to the student.

===Test Scenarios for E2026(Specialized rubrics for different topics)===

As part of our implementation, we modified existing code as well as added new code. To ensure that existing functionality was not broken, and new functionality worked as expected, we used the following Test Strategy (which was also used by previous team):

===Run and pass existing RSpec Tests===
*The following existing RSpec test files have been modified and they pass as part of testing:
**spec/controllers/assignments_controller_spec.rb
**spec/controllers/questionnaires_controller_spec.rb
**spec/controllers/response_controller_spec.rb
**spec/factories/factories.rb
**spec/features/assignment_creation_spec.rb
**spec/features/quiz_spec.rb
**spec/features/staggered_deadline_spec.rb
**spec/models/assignment_form_spec.rb
**spec/models/assignment_spec.rb
**spec/models/on_the_fly_calc_spec.rb
**spec/models/response_spec.rb
**spec/models/review_response_map_spec.rb

===Develop New RSpec Tests===
*spec/helpers/duties_controller_spec.rb
*All these rspec tests passed.

== duties_controller_spec.rb ==
We have created this new test file to unit test the duties scenarios.

First we mock the data accordingly as needed by the tests.

''
describe DutiesController do
let(:assignment) { build(:assignment, id: 1,course_id: 1,instructor_id: 6, due_dates: [due_date], microtask: true, staggered_deadline: true)}
let(:admin) { build(:admin) }
let(:instructor) { build(:instructor, id: 6) }
let(:instructor2) { build(:instructor, id: 66) }
let(:ta) { build(:teaching_assistant, id: 8) }
let(:duty) { build(:duty, id: 1, duty_name: "Role", max_members_for_duty: 2, assignment_id: 1) }
let(:due_date) { build(:assignment_due_date, deadline_type_id: 1) } ''

We then run the arbitrary code that is needed before each test

''
before(:each) do
allow(Assignment).to receive(:find).with('1').and_return(assignment)
allow(Assignment).to receive(:find).with(1).and_return(assignment)
stub_current_user(instructor, instructor.role.name, instructor.role)
allow(Duty).to receive(:find).with('1').and_return(duty)
end
''

Test scenarios for duties controller:
1) Only admin, superadmin, TA, Instructor can perform edit or update action

'' describe '#action_allowed?' do ''

The whole context that defines if the action allowed is edit or update. We do this by mocking the action to edit

context 'when params action is edit or update' do
before(:each) do
controller.params = {id: '1', action: 'edit'}
end

When the current logged in user role is super admin or admin

context 'when the role name of current user is super admin or admin' do
it 'allows certain action' do
stub_current_user(admin, admin.role.name, admin.role)
expect(controller.send(:action_allowed?)).to be true
end
end

When the current logged in user role is instructor

context 'when current user is the instructor of current assignment' do
it 'allows certain action' do
expect(controller.send(:action_allowed?)).to be true
end
end

When the current logged in user role is the TA of the course

context 'when current user is the ta of the course which current assignment belongs to' do
it 'allows certain action' do
stub_current_user(ta, ta.role.name, ta.role)
allow(TaMapping).to receive(:exists?).with(ta_id: 8, course_id: 1).and_return(true)
expect(controller.send(:action_allowed?)).to be true
end
end

When the current logged in user is the instructor of the course

context 'when current user is the instructor of the course which current assignment belongs to' do
it 'allows certain action' do
stub_current_user(instructor2, instructor2.role.name, instructor2.role)
allow(Course).to receive(:find).with(1).and_return(double('Course', instructor_id: 66))
expect(controller.send(:action_allowed?)).to be true
end
end
end

When the parameter action is neither edit nor update, we do this by mocking the action to new

context 'when params action is not edit and update' do
before(:each) do
controller.params = {id: '1', action: 'new'}
end

We now check if super admin/admin/instructor/ta can perform this action which is neither edit nor update

context 'when the role current user is super admin/admin/instructor/ta' do
it 'allows certain action except edit and update' do
expect(controller.send(:action_allowed?)).to be true
end
end
end
end

And then we added few tests to test creation/edit/deletion of a duty

Creation of a duty, we create a duty and check if it is saved successfully

describe '#create' do

Checking if the right page is rendered after successful creation of a duty

context 'when new duty can be saved successfully' do
it 'sets up a new duty and redirects to assignment#edit page' do
allow(duty).to receive(:save).and_return('OK')
params = {
id: 1,
duty: {
duty_name: 'Scrum Master',
max_members_for_duty: 2,
assignment_id: 1
}
}
post :create, params
expect(response).to redirect_to('/assignments/1/edit')
expect(flash[:notice]).to match(/Role was successfully created.*/)
end
end

Test to check if the right error message is shown if the creation of duty is failed

context 'when new duty cannot be saved successfully' do
it 'shows error message and redirects to duty#new page' do
allow(duty).to receive(:errors)
params = {
id: 1,
duty: {
duty_name: 'Scrum Master',
max_members_for_duty: -1,
assignment_id: 1
}
}
post :create, params
expect(flash[:error]).to eq('Max members for duty must be greater than or equal to 1. ')
expect(response).to redirect_to('/duties/new?id=1')
end
end
end

Test to check the edit functionality of a duty

describe '#update' do

When the duty can be edited successfully, we check if the right page is rendered

context 'when duty can be found' do
it 'updates current duty and redirects to assignment#edit page' do
allow(Duty).to receive(:find).with('1').and_return(build(:duty, id: 1))
params = {
id: 1,
assignment_id: 1,
duty: {
duty_name: 'Scrum Master',
max_members_for_duty: 5,
assignment_id: 1
}
}
post :update, params
expect(response).to redirect_to('/assignments/1/edit')
expect(flash[:notice]).to match(/Role was successfully updated.*/)
end
end

When the duty cannot be updated, we check if the right error message is displayed

context 'when new duty cannot be updated successfully' do
it 'shows error message and redirects to duty#new page' do
allow(duty).to receive(:errors)
params = {
id: 1,
duty: {
duty_name: 'SM',
max_members_for_duty: 1,
assignment_id: 1
}
}
post :create, params
expect(flash[:error]).to eq('Duty name is too short (minimum is 3 characters). ')
expect(response).to redirect_to('/duties/new?id=1')
end
end
end

Now finally, we test the delete functionality of the duty

describe '#destroy' do
context 'when duty can be found' do
it 'redirects to assignment#edit page' do
params = {id: 1, assignment_id: 1}
post :destroy, params
expect(response).to redirect_to('/assignments/1/edit')
expect(flash[:notice]).to match(/Role was successfully destroyed.*/)
end
end
end

== team_users_controller_spec.rb ==

We have added a test case in this file which tests if the action is allowed only by specific user roles

First, we mock the data

''
describe TeamsUsersController do
let(:assignment) do
build(:assignment, id: 1, name: 'test assignment', instructor_id: 6, staggered_deadline: true, directory_path: 'same path',
participants: [build(:participant)], teams: [build(:assignment_team)], course_id: 1)
end
let(:assignment_form) { double('AssignmentForm', assignment: assignment) }
let(:student) { build(:student) }

before(:each) do
allow(Assignment).to receive(:find).with('1').and_return(assignment)
stub_current_user(student, student.role.name, student.role)
end
''

Then we check if the student can perform the update action for duties

''
describe '#action_allowed?' do
context 'when params action is update duties' do
before(:each) do
controller.params = {id: '1', action: 'update_duties'}
end
context 'when the role current user is student' do
it 'allows certain action' do
stub_current_user(student, student.role.name, student.role)
expect(controller.send(:action_allowed?)).to be true
end
end
end
end
''

This file also contains a test case to ensure the duties can be properly updated. The test case checks this by ensuring that the user is redirected to the student view page. just as with the previous section the first step is to mock the data by creating a team user object.

''
let(:teams_user1) {TeamsUser.new id:1, duty_id:1}
''

Then the data is actually updated and we ensure that the user is redirected to the proper place.

''
describe '#update_duties' do
it 'updates the duties for the participant' do
allow(TeamsUser).to receive(:find).with('1').and_return(teams_user1)
allow(teams_user1).to receive(:update_attribute).with(any_args).and_return('OK')
params = {
teams_user_id: '1',
teams_user: {duty_id: '1'},
participant_id: '1'
}
session = {user: stub_current_user(student, student.role.name, student.role)}
get :update_duties, params, session
expect(response).to redirect_to('/student_teams/view?student_id=1')
end
end
''

== assignment_form_spec.rb ==
The assignemnt_form_spec.rb file contains all the test files for the assignment form, which includes adding object to a queue. the first step was to create mock data so that the test could run on objects created for the tests. the code below shows how the mock data was created for the specific tests that we created to ensure the functionality of the projects.
''
let(:new_assignment_questionnaire) { build(:assignment_questionnaire) }
''
The new_assignment_questionnaire object is used for both test cases in this file. the first test case checks for when the active record cannot be found for a specific assignment id or duty id.
''
context 'when active record for assignment_questionnaire is not found for a given assignment_id and duty_id' do
it 'returns new instance of assignment_questionnaire with default values' do
allow(assignment).to receive(:questionnaire_varies_by_duty).and_return(true)
allow(AssignmentQuestionnaire).to receive(:where).with(assignment_id: 1, duty_id: anything).and_return([])
allow(AssignmentQuestionnaire).to receive(:where).with(user_id: anything, assignment_id: nil, questionnaire_id: nil).and_return([])
allow(AssignmentQuestionnaire).to receive(:new).and_return(new_assignment_questionnaire)
expect(assignment_form.assignment_questionnaire('TeammateReviewQuestionnaire', nil, nil, 1)).to eq(new_assignment_questionnaire)
end
end
''
The next next test checks when the assignment questionnaire is found given the assignment id and duty id parameters. this test is very similar to the one where the test is not found because the it searches through the active record to find the assignment questionnaire.
''
context 'when active record for assignment_questionnaire is found for a given assignment_id and duty_id' do
it 'returns new instance of assignment_questionnaire with default values' do
allow(assignment).to receive(:questionnaire_varies_by_duty).and_return(true)
allow(Questionnaire).to receive(:find).with(1).and_return(questionnaire3)
allow(AssignmentQuestionnaire).to receive(:where).with(assignment_id: 1, duty_id: 1).and_return([assignment_questionnaire2])
allow(AssignmentQuestionnaire).to receive(:where).with(user_id: anything, assignment_id: nil, questionnaire_id: nil).and_return([])
allow(AssignmentQuestionnaire).to receive(:new).and_return(new_assignment_questionnaire)
expect(assignment_form.assignment_questionnaire('TeammateReviewQuestionnaire', nil, nil, 1)).to eq(assignment_questionnaire2)
end
end
''

== duty_spec.rb ==
the main purpose of the duty_spec.rb file is to test any duty to make sure a duty can be assigned to a team member. it also tests if a duty is unavailable to a team member because the max number of people have been assigned that duty. to test this functionality the mock data is created to allow for testing of the objcect.
''
let(:assignment) { build(:assignment, id: 1, name: 'no assgt') }
let(:participant) { build(:participant, id:1, user_id: 1) }
let(:participant2) { build(:participant, id:2, user_id: 2) }
let(:participant3) { build(:participant, id:3, user_id: 3) }
let(:user) { build(:student, id: 1, name: 'no name', fullname: 'no one', participants: [participant]) }
let(:user2) { build(:student, id: 2, name: 'no name2', fullname: 'no one2', participants: [participant2]) }
let(:user3) { build(:student, id: 3, name: 'no name3', fullname: 'no one3', participants: [participant3]) }

let(:team1) { build(:assignment_team, id: 1, name: 'no team', users: [user, user2, user3]) }
let(:sample_duty_taken) { build(:duty, id: 1, max_members_for_duty:1, assignment_id:1) }
let(:sample_duty_not_taken) { build(:duty, id: 1, max_members_for_duty:2, assignment_id:1) }

let(:team_user1) { build(:team_user, id: 1, user: user) }
let(:team_user2) { build(:team_user, id: 2, user: user2) }
let(:team_user3) { build(:team_user, id: 3, user: user3, duty_id:1) }
''
an assignment is created on which the duties can be tested. for the testing multiple users and participants are created. Finally we created team users that could be assigned duties through the duty_id field. the next step was to set up the reoccurring steps for each of the tests.
''
before(:each) do
allow(team1).to receive(:participants).and_return([participant, participant2, participant3])
allow(participant).to receive(:get_team_user).and_return(team_user1)
allow(participant2).to receive(:get_team_user).and_return(team_user2)
allow(participant3).to receive(:get_team_user).and_return(team_user3)
end
''
Finally the actual tests were implemented. The tests are fairly simple because they just need to check if the duty can be assigned or not.
''
describe '#can_be_assigned?' do
context 'when users in current team want to assign roles that are available'
it 'returns true' do
expect(sample_duty_not_taken.can_be_assigned?(team1)).to be true
end
context 'when users in current team want to assign roles that are unavailable'
it 'returns false' do
expect(sample_duty_taken.can_be_assigned?(team1)).to be false
end
''

== teammate_review_response_map_spec.rb ==
This Rspec testing file tests that a specific questionnaire can be returned when the student has a role assigned to them. This is needed for the role based reviewing because when one student goes to review another they must get the correct questionnaire for their role. We tested this functionality as well as the inverse, when the role could not be found. initially we created the mock data for testing which is shown below.
''
let(:questionnaire) { Questionnaire.new name: "abc", private: 0, min_question_score: 0, max_question_score: 10, instructor_id: 1234 }
let(:assignment) { build(:assignment, id: 1, name: 'no assgt', is_duty_based_assignment: true, questionnaires: [questionnaire]) }
let(:assignment_questionnaire1) { build(:assignment_questionnaire, id: 1, assignment_id: 1, questionnaire_id: 2, duty_id: 1) }
let(:participant) { build(:participant, id: 1, user_id: 6, assignment: assignment) }
let(:teammate_review_response_map) { TeammateReviewResponseMap.new reviewer: participant, reviewer_is_team: true, assignment:assignment }
''
This step created the review response map that we would be testing as well as and assignment which contained a questionnaire. The next step was to actually test the data. First we decided to ensure that the correct questionnaire was returned with the following test. It compares the returned questionnaire with the one we know is correct.
''
it 'returns questionnaire specific to a duty' do
allow(AssignmentQuestionnaire).to receive(:where).with(assignment_id: 1, duty_id: 1).and_return([assignment_questionnaire1])
allow(Questionnaire).to receive(:find).with(assignment_questionnaire1.questionnaire_id).and_return(questionnaire)
expect(teammate_review_response_map.questionnaire_by_duty(1)).to eq questionnaire
end
''
Finally we added the inverse for when there was an error returning the questionnaire. in this case the program should return the default questionnaire.
''
it 'returns default questionnaire when no questionnaire is found for duty' do
allow(AssignmentQuestionnaire).to receive(:where).with(assignment_id: 1, duty_id: 1).and_return([])
allow(assignment.questionnaires).to receive(:find_by).with(type: 'TeammateReviewQuestionnaire').and_return(questionnaire)
expect(teammate_review_response_map.questionnaire_by_duty(1)).to eq questionnaire
end
''

== duties_controller_spec.rb ==
the duties_controller_spec.rb file tested the functionality of the duties themselves which was the main part of our project. For this reason this was probably the longest testing file that we wrote. It needed to contain many test cases for duties as it tested everything about them. Firstly we began by creating the mock data that would be used throughout all the tests. This included and admin, an assignment, instructors, a teaching assistant, a duty, and a due date.
''
let(:assignment) { build(:assignment, id: 1,course_id: 1,instructor_id: 6, due_dates: [due_date], microtask: true, staggered_deadline: true)}
let(:admin) { build(:admin) }
let(:instructor) { build(:instructor, id: 6) }
let(:instructor2) { build(:instructor, id: 66) }
let(:ta) { build(:teaching_assistant, id: 8) }
let(:duty) { build(:duty, id: 1, duty_name: "Role", max_members_for_duty: 2, assignment_id: 1) }
let(:due_date) { build(:assignment_due_date, deadline_type_id: 1) }
''
next the before each block initializing all the tests.
''
before(:each) do
allow(Assignment).to receive(:find).with('1').and_return(assignment)
allow(Assignment).to receive(:find).with(1).and_return(assignment)
stub_current_user(instructor, instructor.role.name, instructor.role)
allow(Duty).to receive(:find).with('1').and_return(duty)
end
''
After this it was time to begin the actual testing. the first test was a test on the #action_allowed? method to ensure that the permissions worked and only people with the correct account type could change the data. only instructors and tas should be able to create roles and questionnaires for the roles. Students should be the ones who assign the roles within their group. We wrote 7 tests to test this functionality.
''
describe '#action_allowed?' do
context 'when params action is edit or update' do
before(:each) do
controller.params = {id: '1', action: 'edit'}
end

context 'when the role name of current user is super admin or admin' do
it 'allows certain action' do
stub_current_user(admin, admin.role.name, admin.role)
expect(controller.send(:action_allowed?)).to be true
end
end

context 'when current user is the instructor of current assignment' do
it 'allows certain action' do
expect(controller.send(:action_allowed?)).to be true
end
end

context 'when current user is the ta of the course which current assignment belongs to' do
it 'allows certain action' do
stub_current_user(ta, ta.role.name, ta.role)
allow(TaMapping).to receive(:exists?).with(ta_id: 8, course_id: 1).and_return(true)
expect(controller.send(:action_allowed?)).to be true
end
end

context 'when current user is the instructor of the course which current assignment belongs to' do
it 'allows certain action' do
stub_current_user(instructor2, instructor2.role.name, instructor2.role)
allow(Course).to receive(:find).with(1).and_return(double('Course', instructor_id: 66))
expect(controller.send(:action_allowed?)).to be true
end
end
end

context 'when params action is not edit and update' do
before(:each) do
controller.params = {id: '1', action: 'new'}
end

context 'when the role current user is super admin/admin/instructor/ta' do
it 'allows certain action except edit and update' do
expect(controller.send(:action_allowed?)).to be true
end
end
end
end
''

== Manual Testing in Expertiza UI ==
Here we describe manual UI Testing steps to edit an existing assignment to allow it have to specialized rubrics for different topic types. These steps are also shown in recorded demo video.
*Login to Expertiza using instructor account (For testing, username: '''instructor6''', password: '''password''')
*Click on Manage > Assignments
*Click on Edit option for any assignment, you should get following view. Make sure '''Has topics?''' box is checked.
[[File:Assignment edit 3.png]]
*Click on Rubrics tab. You will see 2 checkboxes ('''Review rubric varies by round?''', '''Review rubric varies by topic?''')
*Check the box for '''Review rubric varies by topic?'''
*Go to Topics tab and verify that there is dropdown menu beside each Topic.
*Select a rubric from dropdown menu, and click '''Save'''
[[File:Topics rubric 2.png]]
*Go back to Home, and select the same assignment to edit. When you click on Topics tab, you should see the rubric you had selected.

==Team Information==
* Naman Shrimali
* Kanchan Rawat
* Subodh Thota
* Andrew Shipman
Mentor : Prof. Edward F. Gehringer

CSC/ECE 517 Fall 2021 - E2161. Merge code for role based reviewing with code for topic specific rubrics

2021-11-28T14:40:50Z

Ajshipma: /* duties_controller_spec.rb */

This wiki page contains description of changes designed and implemented for [https://docs.google.com/document/d/1slx4HPIbgTH-psIKMSCF-HDF9brxf-FuYhzVT9ZiIrM/edit#heading=h.8s6o9jnnxj0p E2161. Merge code for role-based reviewing with code for topic-specific rubrics], a Final Project for CSC/ECE 517, Fall 2021.
== Purpose==
In CSC/ECE 517, there are Expertiza-based course projects, Mozilla-based course projects, etc. However, currently, we can only specify one kind of rubric for all kinds of course projects. This means that refactoring projects, testing projects, and Mozilla projects need to use the same rubric. We hope we could specify different rubrics to be used with different kinds of course projects.

The project objective is to merge E2147-https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2147._Role-based_reviewing#E2147._Role-based_reviewing with the existing E2026-https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2020_-_E2026._Specialized_rubrics_for_different_topic_types. While merging, we found out that the code for E2026 has already been merged on Expertiza beta branch and so now the actual implementation is to write test cases for both E2147 and E2026.

==Brief Overview of E2147 and E2026 Projects==
*E2147(Role based reviewing): The project objective was to develop teammate review varying by the roles that each team member has in order to evaluate the particular role that each team member has taken rather than asking a generic questionnaire which was same for all the team members previously. For eg, the instructor would create a separate teammate questionnaire for developer role and for tester role respectively.
*E2026(Specialized rubrics for different topics): The project objective was to develop specialized rubrics based on project topics, previously we had same type of questionnaire for all the different types of projects. This implementation made sure that we evaluate different projects based on personalised rubrics rather than having same rubrics.

==Testing Plan==

===Test Scenarios for E2147(Role based reviewing)===
*Only Instructor/TA/Admin should be able to create or update duties: Only the instructor/admin should be able to create or update duties. Also, the corresponding TA of the assignment should be able to create or update duties.
*Create new roles: If the assignment is role based reviewing then the instructor should be able to create new roles for the same and save it in the database using new role functionality.
*Only allow student to update duties in Student View: Only student should be able to update his duties in Student View.
*Edit existing roles: Once the new roles have been created, then the instructor should be able to edit its details such as the maximum number of each role allowed.
*Delete existing roles: The instructor should also be able to delete any roles if he wants.
*Review rubric by role: On Rubrics tab, if the instructor clicks on Review rubric by role, then the corresponding rubric roles based teammate questionnaire should appear and get saved successfully.
*Student View: If the assignment is role based assignment, then the respective students should be able to see the respective teammate questionnaire based on roles for his other team members.
*Selection of Roles: On student login, a student should be able to see the existing roles that he can take up in the project. Only the roles which are available should be shown to the student.

===Test Scenarios for E2026(Specialized rubrics for different topics)===

As part of our implementation, we modified existing code as well as added new code. To ensure that existing functionality was not broken, and new functionality worked as expected, we used the following Test Strategy (which was also used by previous team):

===Run and pass existing RSpec Tests===
*The following existing RSpec test files have been modified and they pass as part of testing:
**spec/controllers/assignments_controller_spec.rb
**spec/controllers/questionnaires_controller_spec.rb
**spec/controllers/response_controller_spec.rb
**spec/factories/factories.rb
**spec/features/assignment_creation_spec.rb
**spec/features/quiz_spec.rb
**spec/features/staggered_deadline_spec.rb
**spec/models/assignment_form_spec.rb
**spec/models/assignment_spec.rb
**spec/models/on_the_fly_calc_spec.rb
**spec/models/response_spec.rb
**spec/models/review_response_map_spec.rb

===Develop New RSpec Tests===
*spec/helpers/duties_controller_spec.rb
*All these rspec tests passed.

== duties_controller_spec.rb ==
We have created this new test file to unit test the duties scenarios.

First we mock the data accordingly as needed by the tests.

''
describe DutiesController do
let(:assignment) { build(:assignment, id: 1,course_id: 1,instructor_id: 6, due_dates: [due_date], microtask: true, staggered_deadline: true)}
let(:admin) { build(:admin) }
let(:instructor) { build(:instructor, id: 6) }
let(:instructor2) { build(:instructor, id: 66) }
let(:ta) { build(:teaching_assistant, id: 8) }
let(:duty) { build(:duty, id: 1, duty_name: "Role", max_members_for_duty: 2, assignment_id: 1) }
let(:due_date) { build(:assignment_due_date, deadline_type_id: 1) } ''

We then run the arbitrary code that is needed before each test

''
before(:each) do
allow(Assignment).to receive(:find).with('1').and_return(assignment)
allow(Assignment).to receive(:find).with(1).and_return(assignment)
stub_current_user(instructor, instructor.role.name, instructor.role)
allow(Duty).to receive(:find).with('1').and_return(duty)
end
''

Test scenarios for duties controller:
1) Only admin, superadmin, TA, Instructor can perform edit or update action

'' describe '#action_allowed?' do ''

The whole context that defines if the action allowed is edit or update. We do this by mocking the action to edit

context 'when params action is edit or update' do
before(:each) do
controller.params = {id: '1', action: 'edit'}
end

When the current logged in user role is super admin or admin

context 'when the role name of current user is super admin or admin' do
it 'allows certain action' do
stub_current_user(admin, admin.role.name, admin.role)
expect(controller.send(:action_allowed?)).to be true
end
end

When the current logged in user role is instructor

context 'when current user is the instructor of current assignment' do
it 'allows certain action' do
expect(controller.send(:action_allowed?)).to be true
end
end

When the current logged in user role is the TA of the course

context 'when current user is the ta of the course which current assignment belongs to' do
it 'allows certain action' do
stub_current_user(ta, ta.role.name, ta.role)
allow(TaMapping).to receive(:exists?).with(ta_id: 8, course_id: 1).and_return(true)
expect(controller.send(:action_allowed?)).to be true
end
end

When the current logged in user is the instructor of the course

context 'when current user is the instructor of the course which current assignment belongs to' do
it 'allows certain action' do
stub_current_user(instructor2, instructor2.role.name, instructor2.role)
allow(Course).to receive(:find).with(1).and_return(double('Course', instructor_id: 66))
expect(controller.send(:action_allowed?)).to be true
end
end
end

When the parameter action is neither edit nor update, we do this by mocking the action to new

context 'when params action is not edit and update' do
before(:each) do
controller.params = {id: '1', action: 'new'}
end

We now check if super admin/admin/instructor/ta can perform this action which is neither edit nor update

context 'when the role current user is super admin/admin/instructor/ta' do
it 'allows certain action except edit and update' do
expect(controller.send(:action_allowed?)).to be true
end
end
end
end

And then we added few tests to test creation/edit/deletion of a duty

Creation of a duty, we create a duty and check if it is saved successfully

describe '#create' do

Checking if the right page is rendered after successful creation of a duty

context 'when new duty can be saved successfully' do
it 'sets up a new duty and redirects to assignment#edit page' do
allow(duty).to receive(:save).and_return('OK')
params = {
id: 1,
duty: {
duty_name: 'Scrum Master',
max_members_for_duty: 2,
assignment_id: 1
}
}
post :create, params
expect(response).to redirect_to('/assignments/1/edit')
expect(flash[:notice]).to match(/Role was successfully created.*/)
end
end

Test to check if the right error message is shown if the creation of duty is failed

context 'when new duty cannot be saved successfully' do
it 'shows error message and redirects to duty#new page' do
allow(duty).to receive(:errors)
params = {
id: 1,
duty: {
duty_name: 'Scrum Master',
max_members_for_duty: -1,
assignment_id: 1
}
}
post :create, params
expect(flash[:error]).to eq('Max members for duty must be greater than or equal to 1. ')
expect(response).to redirect_to('/duties/new?id=1')
end
end
end

Test to check the edit functionality of a duty

describe '#update' do

When the duty can be edited successfully, we check if the right page is rendered

context 'when duty can be found' do
it 'updates current duty and redirects to assignment#edit page' do
allow(Duty).to receive(:find).with('1').and_return(build(:duty, id: 1))
params = {
id: 1,
assignment_id: 1,
duty: {
duty_name: 'Scrum Master',
max_members_for_duty: 5,
assignment_id: 1
}
}
post :update, params
expect(response).to redirect_to('/assignments/1/edit')
expect(flash[:notice]).to match(/Role was successfully updated.*/)
end
end

When the duty cannot be updated, we check if the right error message is displayed

context 'when new duty cannot be updated successfully' do
it 'shows error message and redirects to duty#new page' do
allow(duty).to receive(:errors)
params = {
id: 1,
duty: {
duty_name: 'SM',
max_members_for_duty: 1,
assignment_id: 1
}
}
post :create, params
expect(flash[:error]).to eq('Duty name is too short (minimum is 3 characters). ')
expect(response).to redirect_to('/duties/new?id=1')
end
end
end

Now finally, we test the delete functionality of the duty

describe '#destroy' do
context 'when duty can be found' do
it 'redirects to assignment#edit page' do
params = {id: 1, assignment_id: 1}
post :destroy, params
expect(response).to redirect_to('/assignments/1/edit')
expect(flash[:notice]).to match(/Role was successfully destroyed.*/)
end
end
end

== team_users_controller_spec.rb ==

We have added a test case in this file which tests if the action is allowed only by specific user roles

First, we mock the data

''
describe TeamsUsersController do
let(:assignment) do
build(:assignment, id: 1, name: 'test assignment', instructor_id: 6, staggered_deadline: true, directory_path: 'same path',
participants: [build(:participant)], teams: [build(:assignment_team)], course_id: 1)
end
let(:assignment_form) { double('AssignmentForm', assignment: assignment) }
let(:student) { build(:student) }

before(:each) do
allow(Assignment).to receive(:find).with('1').and_return(assignment)
stub_current_user(student, student.role.name, student.role)
end
''

Then we check if the student can perform the update action for duties

''
describe '#action_allowed?' do
context 'when params action is update duties' do
before(:each) do
controller.params = {id: '1', action: 'update_duties'}
end
context 'when the role current user is student' do
it 'allows certain action' do
stub_current_user(student, student.role.name, student.role)
expect(controller.send(:action_allowed?)).to be true
end
end
end
end
''

This file also contains a test case to ensure the duties can be properly updated. The test case checks this by ensuring that the user is redirected to the student view page. just as with the previous section the first step is to mock the data by creating a team user object.

''
let(:teams_user1) {TeamsUser.new id:1, duty_id:1}
''

Then the data is actually updated and we ensure that the user is redirected to the proper place.

''
describe '#update_duties' do
it 'updates the duties for the participant' do
allow(TeamsUser).to receive(:find).with('1').and_return(teams_user1)
allow(teams_user1).to receive(:update_attribute).with(any_args).and_return('OK')
params = {
teams_user_id: '1',
teams_user: {duty_id: '1'},
participant_id: '1'
}
session = {user: stub_current_user(student, student.role.name, student.role)}
get :update_duties, params, session
expect(response).to redirect_to('/student_teams/view?student_id=1')
end
end
''

== assignment_form_spec.rb ==
The assignemnt_form_spec.rb file contains all the test files for the assignment form, which includes adding object to a queue. the first step was to create mock data so that the test could run on objects created for the tests. the code below shows how the mock data was created for the specific tests that we created to ensure the functionality of the projects.
''
let(:new_assignment_questionnaire) { build(:assignment_questionnaire) }
''
The new_assignment_questionnaire object is used for both test cases in this file. the first test case checks for when the active record cannot be found for a specific assignment id or duty id.
''
context 'when active record for assignment_questionnaire is not found for a given assignment_id and duty_id' do
it 'returns new instance of assignment_questionnaire with default values' do
allow(assignment).to receive(:questionnaire_varies_by_duty).and_return(true)
allow(AssignmentQuestionnaire).to receive(:where).with(assignment_id: 1, duty_id: anything).and_return([])
allow(AssignmentQuestionnaire).to receive(:where).with(user_id: anything, assignment_id: nil, questionnaire_id: nil).and_return([])
allow(AssignmentQuestionnaire).to receive(:new).and_return(new_assignment_questionnaire)
expect(assignment_form.assignment_questionnaire('TeammateReviewQuestionnaire', nil, nil, 1)).to eq(new_assignment_questionnaire)
end
end
''
The next next test checks when the assignment questionnaire is found given the assignment id and duty id parameters. this test is very similar to the one where the test is not found because the it searches through the active record to find the assignment questionnaire.
''
context 'when active record for assignment_questionnaire is found for a given assignment_id and duty_id' do
it 'returns new instance of assignment_questionnaire with default values' do
allow(assignment).to receive(:questionnaire_varies_by_duty).and_return(true)
allow(Questionnaire).to receive(:find).with(1).and_return(questionnaire3)
allow(AssignmentQuestionnaire).to receive(:where).with(assignment_id: 1, duty_id: 1).and_return([assignment_questionnaire2])
allow(AssignmentQuestionnaire).to receive(:where).with(user_id: anything, assignment_id: nil, questionnaire_id: nil).and_return([])
allow(AssignmentQuestionnaire).to receive(:new).and_return(new_assignment_questionnaire)
expect(assignment_form.assignment_questionnaire('TeammateReviewQuestionnaire', nil, nil, 1)).to eq(assignment_questionnaire2)
end
end
''

== duty_spec.rb ==
the main purpose of the duty_spec.rb file is to test any duty to make sure a duty can be assigned to a team member. it also tests if a duty is unavailable to a team member because the max number of people have been assigned that duty. to test this functionality the mock data is created to allow for testing of the objcect.
''
let(:assignment) { build(:assignment, id: 1, name: 'no assgt') }
let(:participant) { build(:participant, id:1, user_id: 1) }
let(:participant2) { build(:participant, id:2, user_id: 2) }
let(:participant3) { build(:participant, id:3, user_id: 3) }
let(:user) { build(:student, id: 1, name: 'no name', fullname: 'no one', participants: [participant]) }
let(:user2) { build(:student, id: 2, name: 'no name2', fullname: 'no one2', participants: [participant2]) }
let(:user3) { build(:student, id: 3, name: 'no name3', fullname: 'no one3', participants: [participant3]) }

let(:team1) { build(:assignment_team, id: 1, name: 'no team', users: [user, user2, user3]) }
let(:sample_duty_taken) { build(:duty, id: 1, max_members_for_duty:1, assignment_id:1) }
let(:sample_duty_not_taken) { build(:duty, id: 1, max_members_for_duty:2, assignment_id:1) }

let(:team_user1) { build(:team_user, id: 1, user: user) }
let(:team_user2) { build(:team_user, id: 2, user: user2) }
let(:team_user3) { build(:team_user, id: 3, user: user3, duty_id:1) }
''
an assignment is created on which the duties can be tested. for the testing multiple users and participants are created. Finally we created team users that could be assigned duties through the duty_id field. the next step was to set up the reoccurring steps for each of the tests.
''
before(:each) do
allow(team1).to receive(:participants).and_return([participant, participant2, participant3])
allow(participant).to receive(:get_team_user).and_return(team_user1)
allow(participant2).to receive(:get_team_user).and_return(team_user2)
allow(participant3).to receive(:get_team_user).and_return(team_user3)
end
''
Finally the actual tests were implemented. The tests are fairly simple because they just need to check if the duty can be assigned or not.
''
describe '#can_be_assigned?' do
context 'when users in current team want to assign roles that are available'
it 'returns true' do
expect(sample_duty_not_taken.can_be_assigned?(team1)).to be true
end
context 'when users in current team want to assign roles that are unavailable'
it 'returns false' do
expect(sample_duty_taken.can_be_assigned?(team1)).to be false
end
''

== teammate_review_response_map_spec.rb ==
This Rspec testing file tests that a specific questionnaire can be returned when the student has a role assigned to them. This is needed for the role based reviewing because when one student goes to review another they must get the correct questionnaire for their role. We tested this functionality as well as the inverse, when the role could not be found. initially we created the mock data for testing which is shown below.
''
let(:questionnaire) { Questionnaire.new name: "abc", private: 0, min_question_score: 0, max_question_score: 10, instructor_id: 1234 }
let(:assignment) { build(:assignment, id: 1, name: 'no assgt', is_duty_based_assignment: true, questionnaires: [questionnaire]) }
let(:assignment_questionnaire1) { build(:assignment_questionnaire, id: 1, assignment_id: 1, questionnaire_id: 2, duty_id: 1) }
let(:participant) { build(:participant, id: 1, user_id: 6, assignment: assignment) }
let(:teammate_review_response_map) { TeammateReviewResponseMap.new reviewer: participant, reviewer_is_team: true, assignment:assignment }
''
This step created the review response map that we would be testing as well as and assignment which contained a questionnaire. The next step was to actually test the data. First we decided to ensure that the correct questionnaire was returned with the following test. It compares the returned questionnaire with the one we know is correct.
''
it 'returns questionnaire specific to a duty' do
allow(AssignmentQuestionnaire).to receive(:where).with(assignment_id: 1, duty_id: 1).and_return([assignment_questionnaire1])
allow(Questionnaire).to receive(:find).with(assignment_questionnaire1.questionnaire_id).and_return(questionnaire)
expect(teammate_review_response_map.questionnaire_by_duty(1)).to eq questionnaire
end
''
Finally we added the inverse for when there was an error returning the questionnaire. in this case the program should return the default questionnaire.
''
it 'returns default questionnaire when no questionnaire is found for duty' do
allow(AssignmentQuestionnaire).to receive(:where).with(assignment_id: 1, duty_id: 1).and_return([])
allow(assignment.questionnaires).to receive(:find_by).with(type: 'TeammateReviewQuestionnaire').and_return(questionnaire)
expect(teammate_review_response_map.questionnaire_by_duty(1)).to eq questionnaire
end
''

== duties_controller_spec.rb ==
the duties_controller_spec.rb file tested the functionality of the duties themselves which was the main part of our project. For this reason this was probably the longest testing file that we wrote. It needed to contain many test cases for duties as it tested everything about them. Firstly we began by creating the mock data that would be used throughout all the tests. This included and admin, an assignment, instructors, a teaching assistant, a duty, and a due date.
''
let(:assignment) { build(:assignment, id: 1,course_id: 1,instructor_id: 6, due_dates: [due_date], microtask: true, staggered_deadline: true)}
let(:admin) { build(:admin) }
let(:instructor) { build(:instructor, id: 6) }
let(:instructor2) { build(:instructor, id: 66) }
let(:ta) { build(:teaching_assistant, id: 8) }
let(:duty) { build(:duty, id: 1, duty_name: "Role", max_members_for_duty: 2, assignment_id: 1) }
let(:due_date) { build(:assignment_due_date, deadline_type_id: 1) }
''
next the before each block initializing all the tests.
''
before(:each) do
allow(Assignment).to receive(:find).with('1').and_return(assignment)
allow(Assignment).to receive(:find).with(1).and_return(assignment)
stub_current_user(instructor, instructor.role.name, instructor.role)
allow(Duty).to receive(:find).with('1').and_return(duty)
end
''

== Manual Testing in Expertiza UI ==
Here we describe manual UI Testing steps to edit an existing assignment to allow it have to specialized rubrics for different topic types. These steps are also shown in recorded demo video.
*Login to Expertiza using instructor account (For testing, username: '''instructor6''', password: '''password''')
*Click on Manage > Assignments
*Click on Edit option for any assignment, you should get following view. Make sure '''Has topics?''' box is checked.
[[File:Assignment edit 3.png]]
*Click on Rubrics tab. You will see 2 checkboxes ('''Review rubric varies by round?''', '''Review rubric varies by topic?''')
*Check the box for '''Review rubric varies by topic?'''
*Go to Topics tab and verify that there is dropdown menu beside each Topic.
*Select a rubric from dropdown menu, and click '''Save'''
[[File:Topics rubric 2.png]]
*Go back to Home, and select the same assignment to edit. When you click on Topics tab, you should see the rubric you had selected.

==Team Information==
* Naman Shrimali
* Kanchan Rawat
* Subodh Thota
* Andrew Shipman
Mentor : Prof. Edward F. Gehringer

CSC/ECE 517 Fall 2021 - E2161. Merge code for role based reviewing with code for topic specific rubrics

2021-11-28T14:34:39Z

Ajshipma: /* duties_controller_spec.rb */

This wiki page contains description of changes designed and implemented for [https://docs.google.com/document/d/1slx4HPIbgTH-psIKMSCF-HDF9brxf-FuYhzVT9ZiIrM/edit#heading=h.8s6o9jnnxj0p E2161. Merge code for role-based reviewing with code for topic-specific rubrics], a Final Project for CSC/ECE 517, Fall 2021.
== Purpose==
In CSC/ECE 517, there are Expertiza-based course projects, Mozilla-based course projects, etc. However, currently, we can only specify one kind of rubric for all kinds of course projects. This means that refactoring projects, testing projects, and Mozilla projects need to use the same rubric. We hope we could specify different rubrics to be used with different kinds of course projects.

The project objective is to merge E2147-https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2147._Role-based_reviewing#E2147._Role-based_reviewing with the existing E2026-https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2020_-_E2026._Specialized_rubrics_for_different_topic_types. While merging, we found out that the code for E2026 has already been merged on Expertiza beta branch and so now the actual implementation is to write test cases for both E2147 and E2026.

==Brief Overview of E2147 and E2026 Projects==
*E2147(Role based reviewing): The project objective was to develop teammate review varying by the roles that each team member has in order to evaluate the particular role that each team member has taken rather than asking a generic questionnaire which was same for all the team members previously. For eg, the instructor would create a separate teammate questionnaire for developer role and for tester role respectively.
*E2026(Specialized rubrics for different topics): The project objective was to develop specialized rubrics based on project topics, previously we had same type of questionnaire for all the different types of projects. This implementation made sure that we evaluate different projects based on personalised rubrics rather than having same rubrics.

==Testing Plan==

===Test Scenarios for E2147(Role based reviewing)===
*Only Instructor/TA/Admin should be able to create or update duties: Only the instructor/admin should be able to create or update duties. Also, the corresponding TA of the assignment should be able to create or update duties.
*Create new roles: If the assignment is role based reviewing then the instructor should be able to create new roles for the same and save it in the database using new role functionality.
*Only allow student to update duties in Student View: Only student should be able to update his duties in Student View.
*Edit existing roles: Once the new roles have been created, then the instructor should be able to edit its details such as the maximum number of each role allowed.
*Delete existing roles: The instructor should also be able to delete any roles if he wants.
*Review rubric by role: On Rubrics tab, if the instructor clicks on Review rubric by role, then the corresponding rubric roles based teammate questionnaire should appear and get saved successfully.
*Student View: If the assignment is role based assignment, then the respective students should be able to see the respective teammate questionnaire based on roles for his other team members.
*Selection of Roles: On student login, a student should be able to see the existing roles that he can take up in the project. Only the roles which are available should be shown to the student.

===Test Scenarios for E2026(Specialized rubrics for different topics)===

As part of our implementation, we modified existing code as well as added new code. To ensure that existing functionality was not broken, and new functionality worked as expected, we used the following Test Strategy (which was also used by previous team):

===Run and pass existing RSpec Tests===
*The following existing RSpec test files have been modified and they pass as part of testing:
**spec/controllers/assignments_controller_spec.rb
**spec/controllers/questionnaires_controller_spec.rb
**spec/controllers/response_controller_spec.rb
**spec/factories/factories.rb
**spec/features/assignment_creation_spec.rb
**spec/features/quiz_spec.rb
**spec/features/staggered_deadline_spec.rb
**spec/models/assignment_form_spec.rb
**spec/models/assignment_spec.rb
**spec/models/on_the_fly_calc_spec.rb
**spec/models/response_spec.rb
**spec/models/review_response_map_spec.rb

===Develop New RSpec Tests===
*spec/helpers/duties_controller_spec.rb
*All these rspec tests passed.

== duties_controller_spec.rb ==
We have created this new test file to unit test the duties scenarios.

First we mock the data accordingly as needed by the tests.

''
describe DutiesController do
let(:assignment) { build(:assignment, id: 1,course_id: 1,instructor_id: 6, due_dates: [due_date], microtask: true, staggered_deadline: true)}
let(:admin) { build(:admin) }
let(:instructor) { build(:instructor, id: 6) }
let(:instructor2) { build(:instructor, id: 66) }
let(:ta) { build(:teaching_assistant, id: 8) }
let(:duty) { build(:duty, id: 1, duty_name: "Role", max_members_for_duty: 2, assignment_id: 1) }
let(:due_date) { build(:assignment_due_date, deadline_type_id: 1) } ''

We then run the arbitrary code that is needed before each test

''
before(:each) do
allow(Assignment).to receive(:find).with('1').and_return(assignment)
allow(Assignment).to receive(:find).with(1).and_return(assignment)
stub_current_user(instructor, instructor.role.name, instructor.role)
allow(Duty).to receive(:find).with('1').and_return(duty)
end
''

Test scenarios for duties controller:
1) Only admin, superadmin, TA, Instructor can perform edit or update action

'' describe '#action_allowed?' do ''

The whole context that defines if the action allowed is edit or update. We do this by mocking the action to edit

context 'when params action is edit or update' do
before(:each) do
controller.params = {id: '1', action: 'edit'}
end

When the current logged in user role is super admin or admin

context 'when the role name of current user is super admin or admin' do
it 'allows certain action' do
stub_current_user(admin, admin.role.name, admin.role)
expect(controller.send(:action_allowed?)).to be true
end
end

When the current logged in user role is instructor

context 'when current user is the instructor of current assignment' do
it 'allows certain action' do
expect(controller.send(:action_allowed?)).to be true
end
end

When the current logged in user role is the TA of the course

context 'when current user is the ta of the course which current assignment belongs to' do
it 'allows certain action' do
stub_current_user(ta, ta.role.name, ta.role)
allow(TaMapping).to receive(:exists?).with(ta_id: 8, course_id: 1).and_return(true)
expect(controller.send(:action_allowed?)).to be true
end
end

When the current logged in user is the instructor of the course

context 'when current user is the instructor of the course which current assignment belongs to' do
it 'allows certain action' do
stub_current_user(instructor2, instructor2.role.name, instructor2.role)
allow(Course).to receive(:find).with(1).and_return(double('Course', instructor_id: 66))
expect(controller.send(:action_allowed?)).to be true
end
end
end

When the parameter action is neither edit nor update, we do this by mocking the action to new

context 'when params action is not edit and update' do
before(:each) do
controller.params = {id: '1', action: 'new'}
end

We now check if super admin/admin/instructor/ta can perform this action which is neither edit nor update

context 'when the role current user is super admin/admin/instructor/ta' do
it 'allows certain action except edit and update' do
expect(controller.send(:action_allowed?)).to be true
end
end
end
end

And then we added few tests to test creation/edit/deletion of a duty

Creation of a duty, we create a duty and check if it is saved successfully

describe '#create' do

Checking if the right page is rendered after successful creation of a duty

context 'when new duty can be saved successfully' do
it 'sets up a new duty and redirects to assignment#edit page' do
allow(duty).to receive(:save).and_return('OK')
params = {
id: 1,
duty: {
duty_name: 'Scrum Master',
max_members_for_duty: 2,
assignment_id: 1
}
}
post :create, params
expect(response).to redirect_to('/assignments/1/edit')
expect(flash[:notice]).to match(/Role was successfully created.*/)
end
end

Test to check if the right error message is shown if the creation of duty is failed

context 'when new duty cannot be saved successfully' do
it 'shows error message and redirects to duty#new page' do
allow(duty).to receive(:errors)
params = {
id: 1,
duty: {
duty_name: 'Scrum Master',
max_members_for_duty: -1,
assignment_id: 1
}
}
post :create, params
expect(flash[:error]).to eq('Max members for duty must be greater than or equal to 1. ')
expect(response).to redirect_to('/duties/new?id=1')
end
end
end

Test to check the edit functionality of a duty

describe '#update' do

When the duty can be edited successfully, we check if the right page is rendered

context 'when duty can be found' do
it 'updates current duty and redirects to assignment#edit page' do
allow(Duty).to receive(:find).with('1').and_return(build(:duty, id: 1))
params = {
id: 1,
assignment_id: 1,
duty: {
duty_name: 'Scrum Master',
max_members_for_duty: 5,
assignment_id: 1
}
}
post :update, params
expect(response).to redirect_to('/assignments/1/edit')
expect(flash[:notice]).to match(/Role was successfully updated.*/)
end
end

When the duty cannot be updated, we check if the right error message is displayed

context 'when new duty cannot be updated successfully' do
it 'shows error message and redirects to duty#new page' do
allow(duty).to receive(:errors)
params = {
id: 1,
duty: {
duty_name: 'SM',
max_members_for_duty: 1,
assignment_id: 1
}
}
post :create, params
expect(flash[:error]).to eq('Duty name is too short (minimum is 3 characters). ')
expect(response).to redirect_to('/duties/new?id=1')
end
end
end

Now finally, we test the delete functionality of the duty

describe '#destroy' do
context 'when duty can be found' do
it 'redirects to assignment#edit page' do
params = {id: 1, assignment_id: 1}
post :destroy, params
expect(response).to redirect_to('/assignments/1/edit')
expect(flash[:notice]).to match(/Role was successfully destroyed.*/)
end
end
end

== team_users_controller_spec.rb ==

We have added a test case in this file which tests if the action is allowed only by specific user roles

First, we mock the data

''
describe TeamsUsersController do
let(:assignment) do
build(:assignment, id: 1, name: 'test assignment', instructor_id: 6, staggered_deadline: true, directory_path: 'same path',
participants: [build(:participant)], teams: [build(:assignment_team)], course_id: 1)
end
let(:assignment_form) { double('AssignmentForm', assignment: assignment) }
let(:student) { build(:student) }

before(:each) do
allow(Assignment).to receive(:find).with('1').and_return(assignment)
stub_current_user(student, student.role.name, student.role)
end
''

Then we check if the student can perform the update action for duties

''
describe '#action_allowed?' do
context 'when params action is update duties' do
before(:each) do
controller.params = {id: '1', action: 'update_duties'}
end
context 'when the role current user is student' do
it 'allows certain action' do
stub_current_user(student, student.role.name, student.role)
expect(controller.send(:action_allowed?)).to be true
end
end
end
end
''

This file also contains a test case to ensure the duties can be properly updated. The test case checks this by ensuring that the user is redirected to the student view page. just as with the previous section the first step is to mock the data by creating a team user object.

''
let(:teams_user1) {TeamsUser.new id:1, duty_id:1}
''

Then the data is actually updated and we ensure that the user is redirected to the proper place.

''
describe '#update_duties' do
it 'updates the duties for the participant' do
allow(TeamsUser).to receive(:find).with('1').and_return(teams_user1)
allow(teams_user1).to receive(:update_attribute).with(any_args).and_return('OK')
params = {
teams_user_id: '1',
teams_user: {duty_id: '1'},
participant_id: '1'
}
session = {user: stub_current_user(student, student.role.name, student.role)}
get :update_duties, params, session
expect(response).to redirect_to('/student_teams/view?student_id=1')
end
end
''

== assignment_form_spec.rb ==
The assignemnt_form_spec.rb file contains all the test files for the assignment form, which includes adding object to a queue. the first step was to create mock data so that the test could run on objects created for the tests. the code below shows how the mock data was created for the specific tests that we created to ensure the functionality of the projects.
''
let(:new_assignment_questionnaire) { build(:assignment_questionnaire) }
''
The new_assignment_questionnaire object is used for both test cases in this file. the first test case checks for when the active record cannot be found for a specific assignment id or duty id.
''
context 'when active record for assignment_questionnaire is not found for a given assignment_id and duty_id' do
it 'returns new instance of assignment_questionnaire with default values' do
allow(assignment).to receive(:questionnaire_varies_by_duty).and_return(true)
allow(AssignmentQuestionnaire).to receive(:where).with(assignment_id: 1, duty_id: anything).and_return([])
allow(AssignmentQuestionnaire).to receive(:where).with(user_id: anything, assignment_id: nil, questionnaire_id: nil).and_return([])
allow(AssignmentQuestionnaire).to receive(:new).and_return(new_assignment_questionnaire)
expect(assignment_form.assignment_questionnaire('TeammateReviewQuestionnaire', nil, nil, 1)).to eq(new_assignment_questionnaire)
end
end
''
The next next test checks when the assignment questionnaire is found given the assignment id and duty id parameters. this test is very similar to the one where the test is not found because the it searches through the active record to find the assignment questionnaire.
''
context 'when active record for assignment_questionnaire is found for a given assignment_id and duty_id' do
it 'returns new instance of assignment_questionnaire with default values' do
allow(assignment).to receive(:questionnaire_varies_by_duty).and_return(true)
allow(Questionnaire).to receive(:find).with(1).and_return(questionnaire3)
allow(AssignmentQuestionnaire).to receive(:where).with(assignment_id: 1, duty_id: 1).and_return([assignment_questionnaire2])
allow(AssignmentQuestionnaire).to receive(:where).with(user_id: anything, assignment_id: nil, questionnaire_id: nil).and_return([])
allow(AssignmentQuestionnaire).to receive(:new).and_return(new_assignment_questionnaire)
expect(assignment_form.assignment_questionnaire('TeammateReviewQuestionnaire', nil, nil, 1)).to eq(assignment_questionnaire2)
end
end
''

== duty_spec.rb ==
the main purpose of the duty_spec.rb file is to test any duty to make sure a duty can be assigned to a team member. it also tests if a duty is unavailable to a team member because the max number of people have been assigned that duty. to test this functionality the mock data is created to allow for testing of the objcect.
''
let(:assignment) { build(:assignment, id: 1, name: 'no assgt') }
let(:participant) { build(:participant, id:1, user_id: 1) }
let(:participant2) { build(:participant, id:2, user_id: 2) }
let(:participant3) { build(:participant, id:3, user_id: 3) }
let(:user) { build(:student, id: 1, name: 'no name', fullname: 'no one', participants: [participant]) }
let(:user2) { build(:student, id: 2, name: 'no name2', fullname: 'no one2', participants: [participant2]) }
let(:user3) { build(:student, id: 3, name: 'no name3', fullname: 'no one3', participants: [participant3]) }

let(:team1) { build(:assignment_team, id: 1, name: 'no team', users: [user, user2, user3]) }
let(:sample_duty_taken) { build(:duty, id: 1, max_members_for_duty:1, assignment_id:1) }
let(:sample_duty_not_taken) { build(:duty, id: 1, max_members_for_duty:2, assignment_id:1) }

let(:team_user1) { build(:team_user, id: 1, user: user) }
let(:team_user2) { build(:team_user, id: 2, user: user2) }
let(:team_user3) { build(:team_user, id: 3, user: user3, duty_id:1) }
''
an assignment is created on which the duties can be tested. for the testing multiple users and participants are created. Finally we created team users that could be assigned duties through the duty_id field. the next step was to set up the reoccurring steps for each of the tests.
''
before(:each) do
allow(team1).to receive(:participants).and_return([participant, participant2, participant3])
allow(participant).to receive(:get_team_user).and_return(team_user1)
allow(participant2).to receive(:get_team_user).and_return(team_user2)
allow(participant3).to receive(:get_team_user).and_return(team_user3)
end
''
Finally the actual tests were implemented. The tests are fairly simple because they just need to check if the duty can be assigned or not.
''
describe '#can_be_assigned?' do
context 'when users in current team want to assign roles that are available'
it 'returns true' do
expect(sample_duty_not_taken.can_be_assigned?(team1)).to be true
end
context 'when users in current team want to assign roles that are unavailable'
it 'returns false' do
expect(sample_duty_taken.can_be_assigned?(team1)).to be false
end
''

== teammate_review_response_map_spec.rb ==
This Rspec testing file tests that a specific questionnaire can be returned when the student has a role assigned to them. This is needed for the role based reviewing because when one student goes to review another they must get the correct questionnaire for their role. We tested this functionality as well as the inverse, when the role could not be found. initially we created the mock data for testing which is shown below.
''
let(:questionnaire) { Questionnaire.new name: "abc", private: 0, min_question_score: 0, max_question_score: 10, instructor_id: 1234 }
let(:assignment) { build(:assignment, id: 1, name: 'no assgt', is_duty_based_assignment: true, questionnaires: [questionnaire]) }
let(:assignment_questionnaire1) { build(:assignment_questionnaire, id: 1, assignment_id: 1, questionnaire_id: 2, duty_id: 1) }
let(:participant) { build(:participant, id: 1, user_id: 6, assignment: assignment) }
let(:teammate_review_response_map) { TeammateReviewResponseMap.new reviewer: participant, reviewer_is_team: true, assignment:assignment }
''
This step created the review response map that we would be testing as well as and assignment which contained a questionnaire. The next step was to actually test the data. First we decided to ensure that the correct questionnaire was returned with the following test. It compares the returned questionnaire with the one we know is correct.
''
it 'returns questionnaire specific to a duty' do
allow(AssignmentQuestionnaire).to receive(:where).with(assignment_id: 1, duty_id: 1).and_return([assignment_questionnaire1])
allow(Questionnaire).to receive(:find).with(assignment_questionnaire1.questionnaire_id).and_return(questionnaire)
expect(teammate_review_response_map.questionnaire_by_duty(1)).to eq questionnaire
end
''
Finally we added the inverse for when there was an error returning the questionnaire. in this case the program should return the default questionnaire.
''
it 'returns default questionnaire when no questionnaire is found for duty' do
allow(AssignmentQuestionnaire).to receive(:where).with(assignment_id: 1, duty_id: 1).and_return([])
allow(assignment.questionnaires).to receive(:find_by).with(type: 'TeammateReviewQuestionnaire').and_return(questionnaire)
expect(teammate_review_response_map.questionnaire_by_duty(1)).to eq questionnaire
end
''

== duties_controller_spec.rb ==
the duties_controller_spec.rb file tested the functionality of the duties themselves which was the main part of our project. For this reason this was probably the longest testing file that we wrote. It needed to contain many test cases for duties as it tested everything about them.

== Manual Testing in Expertiza UI ==
Here we describe manual UI Testing steps to edit an existing assignment to allow it have to specialized rubrics for different topic types. These steps are also shown in recorded demo video.
*Login to Expertiza using instructor account (For testing, username: '''instructor6''', password: '''password''')
*Click on Manage > Assignments
*Click on Edit option for any assignment, you should get following view. Make sure '''Has topics?''' box is checked.
[[File:Assignment edit 3.png]]
*Click on Rubrics tab. You will see 2 checkboxes ('''Review rubric varies by round?''', '''Review rubric varies by topic?''')
*Check the box for '''Review rubric varies by topic?'''
*Go to Topics tab and verify that there is dropdown menu beside each Topic.
*Select a rubric from dropdown menu, and click '''Save'''
[[File:Topics rubric 2.png]]
*Go back to Home, and select the same assignment to edit. When you click on Topics tab, you should see the rubric you had selected.

==Team Information==
* Naman Shrimali
* Kanchan Rawat
* Subodh Thota
* Andrew Shipman
Mentor : Prof. Edward F. Gehringer

CSC/ECE 517 Fall 2021 - E2161. Merge code for role based reviewing with code for topic specific rubrics

2021-11-28T14:23:26Z

Ajshipma: /* duties_controller_test.rb */

This wiki page contains description of changes designed and implemented for [https://docs.google.com/document/d/1slx4HPIbgTH-psIKMSCF-HDF9brxf-FuYhzVT9ZiIrM/edit#heading=h.8s6o9jnnxj0p E2161. Merge code for role-based reviewing with code for topic-specific rubrics], a Final Project for CSC/ECE 517, Fall 2021.
== Purpose==
In CSC/ECE 517, there are Expertiza-based course projects, Mozilla-based course projects, etc. However, currently, we can only specify one kind of rubric for all kinds of course projects. This means that refactoring projects, testing projects, and Mozilla projects need to use the same rubric. We hope we could specify different rubrics to be used with different kinds of course projects.

The project objective is to merge E2147-https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2147._Role-based_reviewing#E2147._Role-based_reviewing with the existing E2026-https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2020_-_E2026._Specialized_rubrics_for_different_topic_types. While merging, we found out that the code for E2026 has already been merged on Expertiza beta branch and so now the actual implementation is to write test cases for both E2147 and E2026.

==Brief Overview of E2147 and E2026 Projects==
*E2147(Role based reviewing): The project objective was to develop teammate review varying by the roles that each team member has in order to evaluate the particular role that each team member has taken rather than asking a generic questionnaire which was same for all the team members previously. For eg, the instructor would create a separate teammate questionnaire for developer role and for tester role respectively.
*E2026(Specialized rubrics for different topics): The project objective was to develop specialized rubrics based on project topics, previously we had same type of questionnaire for all the different types of projects. This implementation made sure that we evaluate different projects based on personalised rubrics rather than having same rubrics.

==Testing Plan==

===Test Scenarios for E2147(Role based reviewing)===
*Only Instructor/TA/Admin should be able to create or update duties: Only the instructor/admin should be able to create or update duties. Also, the corresponding TA of the assignment should be able to create or update duties.
*Create new roles: If the assignment is role based reviewing then the instructor should be able to create new roles for the same and save it in the database using new role functionality.
*Only allow student to update duties in Student View: Only student should be able to update his duties in Student View.
*Edit existing roles: Once the new roles have been created, then the instructor should be able to edit its details such as the maximum number of each role allowed.
*Delete existing roles: The instructor should also be able to delete any roles if he wants.
*Review rubric by role: On Rubrics tab, if the instructor clicks on Review rubric by role, then the corresponding rubric roles based teammate questionnaire should appear and get saved successfully.
*Student View: If the assignment is role based assignment, then the respective students should be able to see the respective teammate questionnaire based on roles for his other team members.
*Selection of Roles: On student login, a student should be able to see the existing roles that he can take up in the project. Only the roles which are available should be shown to the student.

===Test Scenarios for E2026(Specialized rubrics for different topics)===

As part of our implementation, we modified existing code as well as added new code. To ensure that existing functionality was not broken, and new functionality worked as expected, we used the following Test Strategy (which was also used by previous team):

===Run and pass existing RSpec Tests===
*The following existing RSpec test files have been modified and they pass as part of testing:
**spec/controllers/assignments_controller_spec.rb
**spec/controllers/questionnaires_controller_spec.rb
**spec/controllers/response_controller_spec.rb
**spec/factories/factories.rb
**spec/features/assignment_creation_spec.rb
**spec/features/quiz_spec.rb
**spec/features/staggered_deadline_spec.rb
**spec/models/assignment_form_spec.rb
**spec/models/assignment_spec.rb
**spec/models/on_the_fly_calc_spec.rb
**spec/models/response_spec.rb
**spec/models/review_response_map_spec.rb

===Develop New RSpec Tests===
*spec/helpers/duties_controller_spec.rb
*All these rspec tests passed.

== duties_controller_spec.rb ==
We have created this new test file to unit test the duties scenarios.

First we mock the data accordingly as needed by the tests.

''
describe DutiesController do
let(:assignment) { build(:assignment, id: 1,course_id: 1,instructor_id: 6, due_dates: [due_date], microtask: true, staggered_deadline: true)}
let(:admin) { build(:admin) }
let(:instructor) { build(:instructor, id: 6) }
let(:instructor2) { build(:instructor, id: 66) }
let(:ta) { build(:teaching_assistant, id: 8) }
let(:duty) { build(:duty, id: 1, duty_name: "Role", max_members_for_duty: 2, assignment_id: 1) }
let(:due_date) { build(:assignment_due_date, deadline_type_id: 1) } ''

We then run the arbitrary code that is needed before each test

''
before(:each) do
allow(Assignment).to receive(:find).with('1').and_return(assignment)
allow(Assignment).to receive(:find).with(1).and_return(assignment)
stub_current_user(instructor, instructor.role.name, instructor.role)
allow(Duty).to receive(:find).with('1').and_return(duty)
end
''

Test scenarios for duties controller:
1) Only admin, superadmin, TA, Instructor can perform edit or update action

'' describe '#action_allowed?' do ''

The whole context that defines if the action allowed is edit or update. We do this by mocking the action to edit

context 'when params action is edit or update' do
before(:each) do
controller.params = {id: '1', action: 'edit'}
end

When the current logged in user role is super admin or admin

context 'when the role name of current user is super admin or admin' do
it 'allows certain action' do
stub_current_user(admin, admin.role.name, admin.role)
expect(controller.send(:action_allowed?)).to be true
end
end

When the current logged in user role is instructor

context 'when current user is the instructor of current assignment' do
it 'allows certain action' do
expect(controller.send(:action_allowed?)).to be true
end
end

When the current logged in user role is the TA of the course

context 'when current user is the ta of the course which current assignment belongs to' do
it 'allows certain action' do
stub_current_user(ta, ta.role.name, ta.role)
allow(TaMapping).to receive(:exists?).with(ta_id: 8, course_id: 1).and_return(true)
expect(controller.send(:action_allowed?)).to be true
end
end

When the current logged in user is the instructor of the course

context 'when current user is the instructor of the course which current assignment belongs to' do
it 'allows certain action' do
stub_current_user(instructor2, instructor2.role.name, instructor2.role)
allow(Course).to receive(:find).with(1).and_return(double('Course', instructor_id: 66))
expect(controller.send(:action_allowed?)).to be true
end
end
end

When the parameter action is neither edit nor update, we do this by mocking the action to new

context 'when params action is not edit and update' do
before(:each) do
controller.params = {id: '1', action: 'new'}
end

We now check if super admin/admin/instructor/ta can perform this action which is neither edit nor update

context 'when the role current user is super admin/admin/instructor/ta' do
it 'allows certain action except edit and update' do
expect(controller.send(:action_allowed?)).to be true
end
end
end
end

And then we added few tests to test creation/edit/deletion of a duty

Creation of a duty, we create a duty and check if it is saved successfully

describe '#create' do

Checking if the right page is rendered after successful creation of a duty

context 'when new duty can be saved successfully' do
it 'sets up a new duty and redirects to assignment#edit page' do
allow(duty).to receive(:save).and_return('OK')
params = {
id: 1,
duty: {
duty_name: 'Scrum Master',
max_members_for_duty: 2,
assignment_id: 1
}
}
post :create, params
expect(response).to redirect_to('/assignments/1/edit')
expect(flash[:notice]).to match(/Role was successfully created.*/)
end
end

Test to check if the right error message is shown if the creation of duty is failed

context 'when new duty cannot be saved successfully' do
it 'shows error message and redirects to duty#new page' do
allow(duty).to receive(:errors)
params = {
id: 1,
duty: {
duty_name: 'Scrum Master',
max_members_for_duty: -1,
assignment_id: 1
}
}
post :create, params
expect(flash[:error]).to eq('Max members for duty must be greater than or equal to 1. ')
expect(response).to redirect_to('/duties/new?id=1')
end
end
end

Test to check the edit functionality of a duty

describe '#update' do

When the duty can be edited successfully, we check if the right page is rendered

context 'when duty can be found' do
it 'updates current duty and redirects to assignment#edit page' do
allow(Duty).to receive(:find).with('1').and_return(build(:duty, id: 1))
params = {
id: 1,
assignment_id: 1,
duty: {
duty_name: 'Scrum Master',
max_members_for_duty: 5,
assignment_id: 1
}
}
post :update, params
expect(response).to redirect_to('/assignments/1/edit')
expect(flash[:notice]).to match(/Role was successfully updated.*/)
end
end

When the duty cannot be updated, we check if the right error message is displayed

context 'when new duty cannot be updated successfully' do
it 'shows error message and redirects to duty#new page' do
allow(duty).to receive(:errors)
params = {
id: 1,
duty: {
duty_name: 'SM',
max_members_for_duty: 1,
assignment_id: 1
}
}
post :create, params
expect(flash[:error]).to eq('Duty name is too short (minimum is 3 characters). ')
expect(response).to redirect_to('/duties/new?id=1')
end
end
end

Now finally, we test the delete functionality of the duty

describe '#destroy' do
context 'when duty can be found' do
it 'redirects to assignment#edit page' do
params = {id: 1, assignment_id: 1}
post :destroy, params
expect(response).to redirect_to('/assignments/1/edit')
expect(flash[:notice]).to match(/Role was successfully destroyed.*/)
end
end
end

== team_users_controller_spec.rb ==

We have added a test case in this file which tests if the action is allowed only by specific user roles

First, we mock the data

''
describe TeamsUsersController do
let(:assignment) do
build(:assignment, id: 1, name: 'test assignment', instructor_id: 6, staggered_deadline: true, directory_path: 'same path',
participants: [build(:participant)], teams: [build(:assignment_team)], course_id: 1)
end
let(:assignment_form) { double('AssignmentForm', assignment: assignment) }
let(:student) { build(:student) }

before(:each) do
allow(Assignment).to receive(:find).with('1').and_return(assignment)
stub_current_user(student, student.role.name, student.role)
end
''

Then we check if the student can perform the update action for duties

''
describe '#action_allowed?' do
context 'when params action is update duties' do
before(:each) do
controller.params = {id: '1', action: 'update_duties'}
end
context 'when the role current user is student' do
it 'allows certain action' do
stub_current_user(student, student.role.name, student.role)
expect(controller.send(:action_allowed?)).to be true
end
end
end
end
''

This file also contains a test case to ensure the duties can be properly updated. The test case checks this by ensuring that the user is redirected to the student view page. just as with the previous section the first step is to mock the data by creating a team user object.

''
let(:teams_user1) {TeamsUser.new id:1, duty_id:1}
''

Then the data is actually updated and we ensure that the user is redirected to the proper place.

''
describe '#update_duties' do
it 'updates the duties for the participant' do
allow(TeamsUser).to receive(:find).with('1').and_return(teams_user1)
allow(teams_user1).to receive(:update_attribute).with(any_args).and_return('OK')
params = {
teams_user_id: '1',
teams_user: {duty_id: '1'},
participant_id: '1'
}
session = {user: stub_current_user(student, student.role.name, student.role)}
get :update_duties, params, session
expect(response).to redirect_to('/student_teams/view?student_id=1')
end
end
''

== assignment_form_spec.rb ==
The assignemnt_form_spec.rb file contains all the test files for the assignment form, which includes adding object to a queue. the first step was to create mock data so that the test could run on objects created for the tests. the code below shows how the mock data was created for the specific tests that we created to ensure the functionality of the projects.
''
let(:new_assignment_questionnaire) { build(:assignment_questionnaire) }
''
The new_assignment_questionnaire object is used for both test cases in this file. the first test case checks for when the active record cannot be found for a specific assignment id or duty id.
''
context 'when active record for assignment_questionnaire is not found for a given assignment_id and duty_id' do
it 'returns new instance of assignment_questionnaire with default values' do
allow(assignment).to receive(:questionnaire_varies_by_duty).and_return(true)
allow(AssignmentQuestionnaire).to receive(:where).with(assignment_id: 1, duty_id: anything).and_return([])
allow(AssignmentQuestionnaire).to receive(:where).with(user_id: anything, assignment_id: nil, questionnaire_id: nil).and_return([])
allow(AssignmentQuestionnaire).to receive(:new).and_return(new_assignment_questionnaire)
expect(assignment_form.assignment_questionnaire('TeammateReviewQuestionnaire', nil, nil, 1)).to eq(new_assignment_questionnaire)
end
end
''
The next next test checks when the assignment questionnaire is found given the assignment id and duty id parameters. this test is very similar to the one where the test is not found because the it searches through the active record to find the assignment questionnaire.
''
context 'when active record for assignment_questionnaire is found for a given assignment_id and duty_id' do
it 'returns new instance of assignment_questionnaire with default values' do
allow(assignment).to receive(:questionnaire_varies_by_duty).and_return(true)
allow(Questionnaire).to receive(:find).with(1).and_return(questionnaire3)
allow(AssignmentQuestionnaire).to receive(:where).with(assignment_id: 1, duty_id: 1).and_return([assignment_questionnaire2])
allow(AssignmentQuestionnaire).to receive(:where).with(user_id: anything, assignment_id: nil, questionnaire_id: nil).and_return([])
allow(AssignmentQuestionnaire).to receive(:new).and_return(new_assignment_questionnaire)
expect(assignment_form.assignment_questionnaire('TeammateReviewQuestionnaire', nil, nil, 1)).to eq(assignment_questionnaire2)
end
end
''

== duty_spec.rb ==
the main purpose of the duty_spec.rb file is to test any duty to make sure a duty can be assigned to a team member. it also tests if a duty is unavailable to a team member because the max number of people have been assigned that duty. to test this functionality the mock data is created to allow for testing of the objcect.
''
let(:assignment) { build(:assignment, id: 1, name: 'no assgt') }
let(:participant) { build(:participant, id:1, user_id: 1) }
let(:participant2) { build(:participant, id:2, user_id: 2) }
let(:participant3) { build(:participant, id:3, user_id: 3) }
let(:user) { build(:student, id: 1, name: 'no name', fullname: 'no one', participants: [participant]) }
let(:user2) { build(:student, id: 2, name: 'no name2', fullname: 'no one2', participants: [participant2]) }
let(:user3) { build(:student, id: 3, name: 'no name3', fullname: 'no one3', participants: [participant3]) }

let(:team1) { build(:assignment_team, id: 1, name: 'no team', users: [user, user2, user3]) }
let(:sample_duty_taken) { build(:duty, id: 1, max_members_for_duty:1, assignment_id:1) }
let(:sample_duty_not_taken) { build(:duty, id: 1, max_members_for_duty:2, assignment_id:1) }

let(:team_user1) { build(:team_user, id: 1, user: user) }
let(:team_user2) { build(:team_user, id: 2, user: user2) }
let(:team_user3) { build(:team_user, id: 3, user: user3, duty_id:1) }
''
an assignment is created on which the duties can be tested. for the testing multiple users and participants are created. Finally we created team users that could be assigned duties through the duty_id field. the next step was to set up the reoccurring steps for each of the tests.
''
before(:each) do
allow(team1).to receive(:participants).and_return([participant, participant2, participant3])
allow(participant).to receive(:get_team_user).and_return(team_user1)
allow(participant2).to receive(:get_team_user).and_return(team_user2)
allow(participant3).to receive(:get_team_user).and_return(team_user3)
end
''
Finally the actual tests were implemented. The tests are fairly simple because they just need to check if the duty can be assigned or not.
''
describe '#can_be_assigned?' do
context 'when users in current team want to assign roles that are available'
it 'returns true' do
expect(sample_duty_not_taken.can_be_assigned?(team1)).to be true
end
context 'when users in current team want to assign roles that are unavailable'
it 'returns false' do
expect(sample_duty_taken.can_be_assigned?(team1)).to be false
end
''

== teammate_review_response_map_spec.rb ==
This Rspec testing file tests that a specific questionnaire can be returned when the student has a role assigned to them. This is needed for the role based reviewing because when one student goes to review another they must get the correct questionnaire for their role. We tested this functionality as well as the inverse, when the role could not be found. initially we created the mock data for testing which is shown below.
''
let(:questionnaire) { Questionnaire.new name: "abc", private: 0, min_question_score: 0, max_question_score: 10, instructor_id: 1234 }
let(:assignment) { build(:assignment, id: 1, name: 'no assgt', is_duty_based_assignment: true, questionnaires: [questionnaire]) }
let(:assignment_questionnaire1) { build(:assignment_questionnaire, id: 1, assignment_id: 1, questionnaire_id: 2, duty_id: 1) }
let(:participant) { build(:participant, id: 1, user_id: 6, assignment: assignment) }
let(:teammate_review_response_map) { TeammateReviewResponseMap.new reviewer: participant, reviewer_is_team: true, assignment:assignment }
''
This step created the review response map that we would be testing as well as and assignment which contained a questionnaire. The next step was to actually test the data. First we decided to ensure that the correct questionnaire was returned with the following test. It compares the returned questionnaire with the one we know is correct.
''
it 'returns questionnaire specific to a duty' do
allow(AssignmentQuestionnaire).to receive(:where).with(assignment_id: 1, duty_id: 1).and_return([assignment_questionnaire1])
allow(Questionnaire).to receive(:find).with(assignment_questionnaire1.questionnaire_id).and_return(questionnaire)
expect(teammate_review_response_map.questionnaire_by_duty(1)).to eq questionnaire
end
''
Finally we added the inverse for when there was an error returning the questionnaire. in this case the program should return the default questionnaire.
''
it 'returns default questionnaire when no questionnaire is found for duty' do
allow(AssignmentQuestionnaire).to receive(:where).with(assignment_id: 1, duty_id: 1).and_return([])
allow(assignment.questionnaires).to receive(:find_by).with(type: 'TeammateReviewQuestionnaire').and_return(questionnaire)
expect(teammate_review_response_map.questionnaire_by_duty(1)).to eq questionnaire
end
''

== duties_controller_spec.rb ==

== Manual Testing in Expertiza UI ==
Here we describe manual UI Testing steps to edit an existing assignment to allow it have to specialized rubrics for different topic types. These steps are also shown in recorded demo video.
*Login to Expertiza using instructor account (For testing, username: '''instructor6''', password: '''password''')
*Click on Manage > Assignments
*Click on Edit option for any assignment, you should get following view. Make sure '''Has topics?''' box is checked.
[[File:Assignment edit 3.png]]
*Click on Rubrics tab. You will see 2 checkboxes ('''Review rubric varies by round?''', '''Review rubric varies by topic?''')
*Check the box for '''Review rubric varies by topic?'''
*Go to Topics tab and verify that there is dropdown menu beside each Topic.
*Select a rubric from dropdown menu, and click '''Save'''
[[File:Topics rubric 2.png]]
*Go back to Home, and select the same assignment to edit. When you click on Topics tab, you should see the rubric you had selected.

==Team Information==
* Naman Shrimali
* Kanchan Rawat
* Subodh Thota
* Andrew Shipman
Mentor : Prof. Edward F. Gehringer

CSC/ECE 517 Fall 2021 - E2161. Merge code for role based reviewing with code for topic specific rubrics

2021-11-28T14:15:42Z

Ajshipma: /* teammate_review_response_map_spec.rb */

This wiki page contains description of changes designed and implemented for [https://docs.google.com/document/d/1slx4HPIbgTH-psIKMSCF-HDF9brxf-FuYhzVT9ZiIrM/edit#heading=h.8s6o9jnnxj0p E2161. Merge code for role-based reviewing with code for topic-specific rubrics], a Final Project for CSC/ECE 517, Fall 2021.
== Purpose==
In CSC/ECE 517, there are Expertiza-based course projects, Mozilla-based course projects, etc. However, currently, we can only specify one kind of rubric for all kinds of course projects. This means that refactoring projects, testing projects, and Mozilla projects need to use the same rubric. We hope we could specify different rubrics to be used with different kinds of course projects.

The project objective is to merge E2147-https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2147._Role-based_reviewing#E2147._Role-based_reviewing with the existing E2026-https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2020_-_E2026._Specialized_rubrics_for_different_topic_types. While merging, we found out that the code for E2026 has already been merged on Expertiza beta branch and so now the actual implementation is to write test cases for both E2147 and E2026.

==Brief Overview of E2147 and E2026 Projects==
*E2147(Role based reviewing): The project objective was to develop teammate review varying by the roles that each team member has in order to evaluate the particular role that each team member has taken rather than asking a generic questionnaire which was same for all the team members previously. For eg, the instructor would create a separate teammate questionnaire for developer role and for tester role respectively.
*E2026(Specialized rubrics for different topics): The project objective was to develop specialized rubrics based on project topics, previously we had same type of questionnaire for all the different types of projects. This implementation made sure that we evaluate different projects based on personalised rubrics rather than having same rubrics.

==Testing Plan==

===Test Scenarios for E2147(Role based reviewing)===
*Only Instructor/TA/Admin should be able to create or update duties: Only the instructor/admin should be able to create or update duties. Also, the corresponding TA of the assignment should be able to create or update duties.
*Create new roles: If the assignment is role based reviewing then the instructor should be able to create new roles for the same and save it in the database using new role functionality.
*Only allow student to update duties in Student View: Only student should be able to update his duties in Student View.
*Edit existing roles: Once the new roles have been created, then the instructor should be able to edit its details such as the maximum number of each role allowed.
*Delete existing roles: The instructor should also be able to delete any roles if he wants.
*Review rubric by role: On Rubrics tab, if the instructor clicks on Review rubric by role, then the corresponding rubric roles based teammate questionnaire should appear and get saved successfully.
*Student View: If the assignment is role based assignment, then the respective students should be able to see the respective teammate questionnaire based on roles for his other team members.
*Selection of Roles: On student login, a student should be able to see the existing roles that he can take up in the project. Only the roles which are available should be shown to the student.

===Test Scenarios for E2026(Specialized rubrics for different topics)===

As part of our implementation, we modified existing code as well as added new code. To ensure that existing functionality was not broken, and new functionality worked as expected, we used the following Test Strategy (which was also used by previous team):

===Run and pass existing RSpec Tests===
*The following existing RSpec test files have been modified and they pass as part of testing:
**spec/controllers/assignments_controller_spec.rb
**spec/controllers/questionnaires_controller_spec.rb
**spec/controllers/response_controller_spec.rb
**spec/factories/factories.rb
**spec/features/assignment_creation_spec.rb
**spec/features/quiz_spec.rb
**spec/features/staggered_deadline_spec.rb
**spec/models/assignment_form_spec.rb
**spec/models/assignment_spec.rb
**spec/models/on_the_fly_calc_spec.rb
**spec/models/response_spec.rb
**spec/models/review_response_map_spec.rb

===Develop New RSpec Tests===
*spec/helpers/duties_controller_spec.rb
*All these rspec tests passed.

== duties_controller_spec.rb ==
We have created this new test file to unit test the duties scenarios.

First we mock the data accordingly as needed by the tests.

''
describe DutiesController do
let(:assignment) { build(:assignment, id: 1,course_id: 1,instructor_id: 6, due_dates: [due_date], microtask: true, staggered_deadline: true)}
let(:admin) { build(:admin) }
let(:instructor) { build(:instructor, id: 6) }
let(:instructor2) { build(:instructor, id: 66) }
let(:ta) { build(:teaching_assistant, id: 8) }
let(:duty) { build(:duty, id: 1, duty_name: "Role", max_members_for_duty: 2, assignment_id: 1) }
let(:due_date) { build(:assignment_due_date, deadline_type_id: 1) } ''

We then run the arbitrary code that is needed before each test

''
before(:each) do
allow(Assignment).to receive(:find).with('1').and_return(assignment)
allow(Assignment).to receive(:find).with(1).and_return(assignment)
stub_current_user(instructor, instructor.role.name, instructor.role)
allow(Duty).to receive(:find).with('1').and_return(duty)
end
''

Test scenarios for duties controller:
1) Only admin, superadmin, TA, Instructor can perform edit or update action

'' describe '#action_allowed?' do ''

The whole context that defines if the action allowed is edit or update. We do this by mocking the action to edit

context 'when params action is edit or update' do
before(:each) do
controller.params = {id: '1', action: 'edit'}
end

When the current logged in user role is super admin or admin

context 'when the role name of current user is super admin or admin' do
it 'allows certain action' do
stub_current_user(admin, admin.role.name, admin.role)
expect(controller.send(:action_allowed?)).to be true
end
end

When the current logged in user role is instructor

context 'when current user is the instructor of current assignment' do
it 'allows certain action' do
expect(controller.send(:action_allowed?)).to be true
end
end

When the current logged in user role is the TA of the course

context 'when current user is the ta of the course which current assignment belongs to' do
it 'allows certain action' do
stub_current_user(ta, ta.role.name, ta.role)
allow(TaMapping).to receive(:exists?).with(ta_id: 8, course_id: 1).and_return(true)
expect(controller.send(:action_allowed?)).to be true
end
end

When the current logged in user is the instructor of the course

context 'when current user is the instructor of the course which current assignment belongs to' do
it 'allows certain action' do
stub_current_user(instructor2, instructor2.role.name, instructor2.role)
allow(Course).to receive(:find).with(1).and_return(double('Course', instructor_id: 66))
expect(controller.send(:action_allowed?)).to be true
end
end
end

When the parameter action is neither edit nor update, we do this by mocking the action to new

context 'when params action is not edit and update' do
before(:each) do
controller.params = {id: '1', action: 'new'}
end

We now check if super admin/admin/instructor/ta can perform this action which is neither edit nor update

context 'when the role current user is super admin/admin/instructor/ta' do
it 'allows certain action except edit and update' do
expect(controller.send(:action_allowed?)).to be true
end
end
end
end

And then we added few tests to test creation/edit/deletion of a duty

Creation of a duty, we create a duty and check if it is saved successfully

describe '#create' do

Checking if the right page is rendered after successful creation of a duty

context 'when new duty can be saved successfully' do
it 'sets up a new duty and redirects to assignment#edit page' do
allow(duty).to receive(:save).and_return('OK')
params = {
id: 1,
duty: {
duty_name: 'Scrum Master',
max_members_for_duty: 2,
assignment_id: 1
}
}
post :create, params
expect(response).to redirect_to('/assignments/1/edit')
expect(flash[:notice]).to match(/Role was successfully created.*/)
end
end

Test to check if the right error message is shown if the creation of duty is failed

context 'when new duty cannot be saved successfully' do
it 'shows error message and redirects to duty#new page' do
allow(duty).to receive(:errors)
params = {
id: 1,
duty: {
duty_name: 'Scrum Master',
max_members_for_duty: -1,
assignment_id: 1
}
}
post :create, params
expect(flash[:error]).to eq('Max members for duty must be greater than or equal to 1. ')
expect(response).to redirect_to('/duties/new?id=1')
end
end
end

Test to check the edit functionality of a duty

describe '#update' do

When the duty can be edited successfully, we check if the right page is rendered

context 'when duty can be found' do
it 'updates current duty and redirects to assignment#edit page' do
allow(Duty).to receive(:find).with('1').and_return(build(:duty, id: 1))
params = {
id: 1,
assignment_id: 1,
duty: {
duty_name: 'Scrum Master',
max_members_for_duty: 5,
assignment_id: 1
}
}
post :update, params
expect(response).to redirect_to('/assignments/1/edit')
expect(flash[:notice]).to match(/Role was successfully updated.*/)
end
end

When the duty cannot be updated, we check if the right error message is displayed

context 'when new duty cannot be updated successfully' do
it 'shows error message and redirects to duty#new page' do
allow(duty).to receive(:errors)
params = {
id: 1,
duty: {
duty_name: 'SM',
max_members_for_duty: 1,
assignment_id: 1
}
}
post :create, params
expect(flash[:error]).to eq('Duty name is too short (minimum is 3 characters). ')
expect(response).to redirect_to('/duties/new?id=1')
end
end
end

Now finally, we test the delete functionality of the duty

describe '#destroy' do
context 'when duty can be found' do
it 'redirects to assignment#edit page' do
params = {id: 1, assignment_id: 1}
post :destroy, params
expect(response).to redirect_to('/assignments/1/edit')
expect(flash[:notice]).to match(/Role was successfully destroyed.*/)
end
end
end

== team_users_controller_spec.rb ==

We have added a test case in this file which tests if the action is allowed only by specific user roles

First, we mock the data

''
describe TeamsUsersController do
let(:assignment) do
build(:assignment, id: 1, name: 'test assignment', instructor_id: 6, staggered_deadline: true, directory_path: 'same path',
participants: [build(:participant)], teams: [build(:assignment_team)], course_id: 1)
end
let(:assignment_form) { double('AssignmentForm', assignment: assignment) }
let(:student) { build(:student) }

before(:each) do
allow(Assignment).to receive(:find).with('1').and_return(assignment)
stub_current_user(student, student.role.name, student.role)
end
''

Then we check if the student can perform the update action for duties

''
describe '#action_allowed?' do
context 'when params action is update duties' do
before(:each) do
controller.params = {id: '1', action: 'update_duties'}
end
context 'when the role current user is student' do
it 'allows certain action' do
stub_current_user(student, student.role.name, student.role)
expect(controller.send(:action_allowed?)).to be true
end
end
end
end
''

This file also contains a test case to ensure the duties can be properly updated. The test case checks this by ensuring that the user is redirected to the student view page. just as with the previous section the first step is to mock the data by creating a team user object.

''
let(:teams_user1) {TeamsUser.new id:1, duty_id:1}
''

Then the data is actually updated and we ensure that the user is redirected to the proper place.

''
describe '#update_duties' do
it 'updates the duties for the participant' do
allow(TeamsUser).to receive(:find).with('1').and_return(teams_user1)
allow(teams_user1).to receive(:update_attribute).with(any_args).and_return('OK')
params = {
teams_user_id: '1',
teams_user: {duty_id: '1'},
participant_id: '1'
}
session = {user: stub_current_user(student, student.role.name, student.role)}
get :update_duties, params, session
expect(response).to redirect_to('/student_teams/view?student_id=1')
end
end
''

== assignment_form_spec.rb ==
The assignemnt_form_spec.rb file contains all the test files for the assignment form, which includes adding object to a queue. the first step was to create mock data so that the test could run on objects created for the tests. the code below shows how the mock data was created for the specific tests that we created to ensure the functionality of the projects.
''
let(:new_assignment_questionnaire) { build(:assignment_questionnaire) }
''
The new_assignment_questionnaire object is used for both test cases in this file. the first test case checks for when the active record cannot be found for a specific assignment id or duty id.
''
context 'when active record for assignment_questionnaire is not found for a given assignment_id and duty_id' do
it 'returns new instance of assignment_questionnaire with default values' do
allow(assignment).to receive(:questionnaire_varies_by_duty).and_return(true)
allow(AssignmentQuestionnaire).to receive(:where).with(assignment_id: 1, duty_id: anything).and_return([])
allow(AssignmentQuestionnaire).to receive(:where).with(user_id: anything, assignment_id: nil, questionnaire_id: nil).and_return([])
allow(AssignmentQuestionnaire).to receive(:new).and_return(new_assignment_questionnaire)
expect(assignment_form.assignment_questionnaire('TeammateReviewQuestionnaire', nil, nil, 1)).to eq(new_assignment_questionnaire)
end
end
''
The next next test checks when the assignment questionnaire is found given the assignment id and duty id parameters. this test is very similar to the one where the test is not found because the it searches through the active record to find the assignment questionnaire.
''
context 'when active record for assignment_questionnaire is found for a given assignment_id and duty_id' do
it 'returns new instance of assignment_questionnaire with default values' do
allow(assignment).to receive(:questionnaire_varies_by_duty).and_return(true)
allow(Questionnaire).to receive(:find).with(1).and_return(questionnaire3)
allow(AssignmentQuestionnaire).to receive(:where).with(assignment_id: 1, duty_id: 1).and_return([assignment_questionnaire2])
allow(AssignmentQuestionnaire).to receive(:where).with(user_id: anything, assignment_id: nil, questionnaire_id: nil).and_return([])
allow(AssignmentQuestionnaire).to receive(:new).and_return(new_assignment_questionnaire)
expect(assignment_form.assignment_questionnaire('TeammateReviewQuestionnaire', nil, nil, 1)).to eq(assignment_questionnaire2)
end
end
''

== duty_spec.rb ==
the main purpose of the duty_spec.rb file is to test any duty to make sure a duty can be assigned to a team member. it also tests if a duty is unavailable to a team member because the max number of people have been assigned that duty. to test this functionality the mock data is created to allow for testing of the objcect.
''
let(:assignment) { build(:assignment, id: 1, name: 'no assgt') }
let(:participant) { build(:participant, id:1, user_id: 1) }
let(:participant2) { build(:participant, id:2, user_id: 2) }
let(:participant3) { build(:participant, id:3, user_id: 3) }
let(:user) { build(:student, id: 1, name: 'no name', fullname: 'no one', participants: [participant]) }
let(:user2) { build(:student, id: 2, name: 'no name2', fullname: 'no one2', participants: [participant2]) }
let(:user3) { build(:student, id: 3, name: 'no name3', fullname: 'no one3', participants: [participant3]) }

let(:team1) { build(:assignment_team, id: 1, name: 'no team', users: [user, user2, user3]) }
let(:sample_duty_taken) { build(:duty, id: 1, max_members_for_duty:1, assignment_id:1) }
let(:sample_duty_not_taken) { build(:duty, id: 1, max_members_for_duty:2, assignment_id:1) }

let(:team_user1) { build(:team_user, id: 1, user: user) }
let(:team_user2) { build(:team_user, id: 2, user: user2) }
let(:team_user3) { build(:team_user, id: 3, user: user3, duty_id:1) }
''
an assignment is created on which the duties can be tested. for the testing multiple users and participants are created. Finally we created team users that could be assigned duties through the duty_id field. the next step was to set up the reoccurring steps for each of the tests.
''
before(:each) do
allow(team1).to receive(:participants).and_return([participant, participant2, participant3])
allow(participant).to receive(:get_team_user).and_return(team_user1)
allow(participant2).to receive(:get_team_user).and_return(team_user2)
allow(participant3).to receive(:get_team_user).and_return(team_user3)
end
''
Finally the actual tests were implemented. The tests are fairly simple because they just need to check if the duty can be assigned or not.
''
describe '#can_be_assigned?' do
context 'when users in current team want to assign roles that are available'
it 'returns true' do
expect(sample_duty_not_taken.can_be_assigned?(team1)).to be true
end
context 'when users in current team want to assign roles that are unavailable'
it 'returns false' do
expect(sample_duty_taken.can_be_assigned?(team1)).to be false
end
''

== teammate_review_response_map_spec.rb ==
This Rspec testing file tests that a specific questionnaire can be returned when the student has a role assigned to them. This is needed for the role based reviewing because when one student goes to review another they must get the correct questionnaire for their role. We tested this functionality as well as the inverse, when the role could not be found. initially we created the mock data for testing which is shown below.
''
let(:questionnaire) { Questionnaire.new name: "abc", private: 0, min_question_score: 0, max_question_score: 10, instructor_id: 1234 }
let(:assignment) { build(:assignment, id: 1, name: 'no assgt', is_duty_based_assignment: true, questionnaires: [questionnaire]) }
let(:assignment_questionnaire1) { build(:assignment_questionnaire, id: 1, assignment_id: 1, questionnaire_id: 2, duty_id: 1) }
let(:participant) { build(:participant, id: 1, user_id: 6, assignment: assignment) }
let(:teammate_review_response_map) { TeammateReviewResponseMap.new reviewer: participant, reviewer_is_team: true, assignment:assignment }
''
This step created the review response map that we would be testing as well as and assignment which contained a questionnaire. The next step was to actually test the data. First we decided to ensure that the correct questionnaire was returned with the following test. It compares the returned questionnaire with the one we know is correct.
''
it 'returns questionnaire specific to a duty' do
allow(AssignmentQuestionnaire).to receive(:where).with(assignment_id: 1, duty_id: 1).and_return([assignment_questionnaire1])
allow(Questionnaire).to receive(:find).with(assignment_questionnaire1.questionnaire_id).and_return(questionnaire)
expect(teammate_review_response_map.questionnaire_by_duty(1)).to eq questionnaire
end
''
Finally we added the inverse for when there was an error returning the questionnaire. in this case the program should return the default questionnaire.
''
it 'returns default questionnaire when no questionnaire is found for duty' do
allow(AssignmentQuestionnaire).to receive(:where).with(assignment_id: 1, duty_id: 1).and_return([])
allow(assignment.questionnaires).to receive(:find_by).with(type: 'TeammateReviewQuestionnaire').and_return(questionnaire)
expect(teammate_review_response_map.questionnaire_by_duty(1)).to eq questionnaire
end
''

== duties_controller_test.rb ==

== Manual Testing in Expertiza UI ==
Here we describe manual UI Testing steps to edit an existing assignment to allow it have to specialized rubrics for different topic types. These steps are also shown in recorded demo video.
*Login to Expertiza using instructor account (For testing, username: '''instructor6''', password: '''password''')
*Click on Manage > Assignments
*Click on Edit option for any assignment, you should get following view. Make sure '''Has topics?''' box is checked.
[[File:Assignment edit 3.png]]
*Click on Rubrics tab. You will see 2 checkboxes ('''Review rubric varies by round?''', '''Review rubric varies by topic?''')
*Check the box for '''Review rubric varies by topic?'''
*Go to Topics tab and verify that there is dropdown menu beside each Topic.
*Select a rubric from dropdown menu, and click '''Save'''
[[File:Topics rubric 2.png]]
*Go back to Home, and select the same assignment to edit. When you click on Topics tab, you should see the rubric you had selected.

==Team Information==
* Naman Shrimali
* Kanchan Rawat
* Subodh Thota
* Andrew Shipman
Mentor : Prof. Edward F. Gehringer

CSC/ECE 517 Fall 2021 - E2161. Merge code for role based reviewing with code for topic specific rubrics

2021-11-28T14:11:47Z

Ajshipma: /* teammate_review_response_map_spec.rb */

This wiki page contains description of changes designed and implemented for [https://docs.google.com/document/d/1slx4HPIbgTH-psIKMSCF-HDF9brxf-FuYhzVT9ZiIrM/edit#heading=h.8s6o9jnnxj0p E2161. Merge code for role-based reviewing with code for topic-specific rubrics], a Final Project for CSC/ECE 517, Fall 2021.
== Purpose==
In CSC/ECE 517, there are Expertiza-based course projects, Mozilla-based course projects, etc. However, currently, we can only specify one kind of rubric for all kinds of course projects. This means that refactoring projects, testing projects, and Mozilla projects need to use the same rubric. We hope we could specify different rubrics to be used with different kinds of course projects.

The project objective is to merge E2147-https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2147._Role-based_reviewing#E2147._Role-based_reviewing with the existing E2026-https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2020_-_E2026._Specialized_rubrics_for_different_topic_types. While merging, we found out that the code for E2026 has already been merged on Expertiza beta branch and so now the actual implementation is to write test cases for both E2147 and E2026.

==Brief Overview of E2147 and E2026 Projects==
*E2147(Role based reviewing): The project objective was to develop teammate review varying by the roles that each team member has in order to evaluate the particular role that each team member has taken rather than asking a generic questionnaire which was same for all the team members previously. For eg, the instructor would create a separate teammate questionnaire for developer role and for tester role respectively.
*E2026(Specialized rubrics for different topics): The project objective was to develop specialized rubrics based on project topics, previously we had same type of questionnaire for all the different types of projects. This implementation made sure that we evaluate different projects based on personalised rubrics rather than having same rubrics.

==Testing Plan==

===Test Scenarios for E2147(Role based reviewing)===
*Only Instructor/TA/Admin should be able to create or update duties: Only the instructor/admin should be able to create or update duties. Also, the corresponding TA of the assignment should be able to create or update duties.
*Create new roles: If the assignment is role based reviewing then the instructor should be able to create new roles for the same and save it in the database using new role functionality.
*Only allow student to update duties in Student View: Only student should be able to update his duties in Student View.
*Edit existing roles: Once the new roles have been created, then the instructor should be able to edit its details such as the maximum number of each role allowed.
*Delete existing roles: The instructor should also be able to delete any roles if he wants.
*Review rubric by role: On Rubrics tab, if the instructor clicks on Review rubric by role, then the corresponding rubric roles based teammate questionnaire should appear and get saved successfully.
*Student View: If the assignment is role based assignment, then the respective students should be able to see the respective teammate questionnaire based on roles for his other team members.
*Selection of Roles: On student login, a student should be able to see the existing roles that he can take up in the project. Only the roles which are available should be shown to the student.

===Test Scenarios for E2026(Specialized rubrics for different topics)===

As part of our implementation, we modified existing code as well as added new code. To ensure that existing functionality was not broken, and new functionality worked as expected, we used the following Test Strategy (which was also used by previous team):

===Run and pass existing RSpec Tests===
*The following existing RSpec test files have been modified and they pass as part of testing:
**spec/controllers/assignments_controller_spec.rb
**spec/controllers/questionnaires_controller_spec.rb
**spec/controllers/response_controller_spec.rb
**spec/factories/factories.rb
**spec/features/assignment_creation_spec.rb
**spec/features/quiz_spec.rb
**spec/features/staggered_deadline_spec.rb
**spec/models/assignment_form_spec.rb
**spec/models/assignment_spec.rb
**spec/models/on_the_fly_calc_spec.rb
**spec/models/response_spec.rb
**spec/models/review_response_map_spec.rb

===Develop New RSpec Tests===
*spec/helpers/duties_controller_spec.rb
*All these rspec tests passed.

== duties_controller_spec.rb ==
We have created this new test file to unit test the duties scenarios.

First we mock the data accordingly as needed by the tests.

''
describe DutiesController do
let(:assignment) { build(:assignment, id: 1,course_id: 1,instructor_id: 6, due_dates: [due_date], microtask: true, staggered_deadline: true)}
let(:admin) { build(:admin) }
let(:instructor) { build(:instructor, id: 6) }
let(:instructor2) { build(:instructor, id: 66) }
let(:ta) { build(:teaching_assistant, id: 8) }
let(:duty) { build(:duty, id: 1, duty_name: "Role", max_members_for_duty: 2, assignment_id: 1) }
let(:due_date) { build(:assignment_due_date, deadline_type_id: 1) } ''

We then run the arbitrary code that is needed before each test

''
before(:each) do
allow(Assignment).to receive(:find).with('1').and_return(assignment)
allow(Assignment).to receive(:find).with(1).and_return(assignment)
stub_current_user(instructor, instructor.role.name, instructor.role)
allow(Duty).to receive(:find).with('1').and_return(duty)
end
''

Test scenarios for duties controller:
1) Only admin, superadmin, TA, Instructor can perform edit or update action

'' describe '#action_allowed?' do ''

The whole context that defines if the action allowed is edit or update. We do this by mocking the action to edit

context 'when params action is edit or update' do
before(:each) do
controller.params = {id: '1', action: 'edit'}
end

When the current logged in user role is super admin or admin

context 'when the role name of current user is super admin or admin' do
it 'allows certain action' do
stub_current_user(admin, admin.role.name, admin.role)
expect(controller.send(:action_allowed?)).to be true
end
end

When the current logged in user role is instructor

context 'when current user is the instructor of current assignment' do
it 'allows certain action' do
expect(controller.send(:action_allowed?)).to be true
end
end

When the current logged in user role is the TA of the course

context 'when current user is the ta of the course which current assignment belongs to' do
it 'allows certain action' do
stub_current_user(ta, ta.role.name, ta.role)
allow(TaMapping).to receive(:exists?).with(ta_id: 8, course_id: 1).and_return(true)
expect(controller.send(:action_allowed?)).to be true
end
end

When the current logged in user is the instructor of the course

context 'when current user is the instructor of the course which current assignment belongs to' do
it 'allows certain action' do
stub_current_user(instructor2, instructor2.role.name, instructor2.role)
allow(Course).to receive(:find).with(1).and_return(double('Course', instructor_id: 66))
expect(controller.send(:action_allowed?)).to be true
end
end
end

When the parameter action is neither edit nor update, we do this by mocking the action to new

context 'when params action is not edit and update' do
before(:each) do
controller.params = {id: '1', action: 'new'}
end

We now check if super admin/admin/instructor/ta can perform this action which is neither edit nor update

context 'when the role current user is super admin/admin/instructor/ta' do
it 'allows certain action except edit and update' do
expect(controller.send(:action_allowed?)).to be true
end
end
end
end

And then we added few tests to test creation/edit/deletion of a duty

Creation of a duty, we create a duty and check if it is saved successfully

describe '#create' do

Checking if the right page is rendered after successful creation of a duty

context 'when new duty can be saved successfully' do
it 'sets up a new duty and redirects to assignment#edit page' do
allow(duty).to receive(:save).and_return('OK')
params = {
id: 1,
duty: {
duty_name: 'Scrum Master',
max_members_for_duty: 2,
assignment_id: 1
}
}
post :create, params
expect(response).to redirect_to('/assignments/1/edit')
expect(flash[:notice]).to match(/Role was successfully created.*/)
end
end

Test to check if the right error message is shown if the creation of duty is failed

context 'when new duty cannot be saved successfully' do
it 'shows error message and redirects to duty#new page' do
allow(duty).to receive(:errors)
params = {
id: 1,
duty: {
duty_name: 'Scrum Master',
max_members_for_duty: -1,
assignment_id: 1
}
}
post :create, params
expect(flash[:error]).to eq('Max members for duty must be greater than or equal to 1. ')
expect(response).to redirect_to('/duties/new?id=1')
end
end
end

Test to check the edit functionality of a duty

describe '#update' do

When the duty can be edited successfully, we check if the right page is rendered

context 'when duty can be found' do
it 'updates current duty and redirects to assignment#edit page' do
allow(Duty).to receive(:find).with('1').and_return(build(:duty, id: 1))
params = {
id: 1,
assignment_id: 1,
duty: {
duty_name: 'Scrum Master',
max_members_for_duty: 5,
assignment_id: 1
}
}
post :update, params
expect(response).to redirect_to('/assignments/1/edit')
expect(flash[:notice]).to match(/Role was successfully updated.*/)
end
end

When the duty cannot be updated, we check if the right error message is displayed

context 'when new duty cannot be updated successfully' do
it 'shows error message and redirects to duty#new page' do
allow(duty).to receive(:errors)
params = {
id: 1,
duty: {
duty_name: 'SM',
max_members_for_duty: 1,
assignment_id: 1
}
}
post :create, params
expect(flash[:error]).to eq('Duty name is too short (minimum is 3 characters). ')
expect(response).to redirect_to('/duties/new?id=1')
end
end
end

Now finally, we test the delete functionality of the duty

describe '#destroy' do
context 'when duty can be found' do
it 'redirects to assignment#edit page' do
params = {id: 1, assignment_id: 1}
post :destroy, params
expect(response).to redirect_to('/assignments/1/edit')
expect(flash[:notice]).to match(/Role was successfully destroyed.*/)
end
end
end

== team_users_controller_spec.rb ==

We have added a test case in this file which tests if the action is allowed only by specific user roles

First, we mock the data

''
describe TeamsUsersController do
let(:assignment) do
build(:assignment, id: 1, name: 'test assignment', instructor_id: 6, staggered_deadline: true, directory_path: 'same path',
participants: [build(:participant)], teams: [build(:assignment_team)], course_id: 1)
end
let(:assignment_form) { double('AssignmentForm', assignment: assignment) }
let(:student) { build(:student) }

before(:each) do
allow(Assignment).to receive(:find).with('1').and_return(assignment)
stub_current_user(student, student.role.name, student.role)
end
''

Then we check if the student can perform the update action for duties

''
describe '#action_allowed?' do
context 'when params action is update duties' do
before(:each) do
controller.params = {id: '1', action: 'update_duties'}
end
context 'when the role current user is student' do
it 'allows certain action' do
stub_current_user(student, student.role.name, student.role)
expect(controller.send(:action_allowed?)).to be true
end
end
end
end
''

This file also contains a test case to ensure the duties can be properly updated. The test case checks this by ensuring that the user is redirected to the student view page. just as with the previous section the first step is to mock the data by creating a team user object.

''
let(:teams_user1) {TeamsUser.new id:1, duty_id:1}
''

Then the data is actually updated and we ensure that the user is redirected to the proper place.

''
describe '#update_duties' do
it 'updates the duties for the participant' do
allow(TeamsUser).to receive(:find).with('1').and_return(teams_user1)
allow(teams_user1).to receive(:update_attribute).with(any_args).and_return('OK')
params = {
teams_user_id: '1',
teams_user: {duty_id: '1'},
participant_id: '1'
}
session = {user: stub_current_user(student, student.role.name, student.role)}
get :update_duties, params, session
expect(response).to redirect_to('/student_teams/view?student_id=1')
end
end
''

== assignment_form_spec.rb ==
The assignemnt_form_spec.rb file contains all the test files for the assignment form, which includes adding object to a queue. the first step was to create mock data so that the test could run on objects created for the tests. the code below shows how the mock data was created for the specific tests that we created to ensure the functionality of the projects.
''
let(:new_assignment_questionnaire) { build(:assignment_questionnaire) }
''
The new_assignment_questionnaire object is used for both test cases in this file. the first test case checks for when the active record cannot be found for a specific assignment id or duty id.
''
context 'when active record for assignment_questionnaire is not found for a given assignment_id and duty_id' do
it 'returns new instance of assignment_questionnaire with default values' do
allow(assignment).to receive(:questionnaire_varies_by_duty).and_return(true)
allow(AssignmentQuestionnaire).to receive(:where).with(assignment_id: 1, duty_id: anything).and_return([])
allow(AssignmentQuestionnaire).to receive(:where).with(user_id: anything, assignment_id: nil, questionnaire_id: nil).and_return([])
allow(AssignmentQuestionnaire).to receive(:new).and_return(new_assignment_questionnaire)
expect(assignment_form.assignment_questionnaire('TeammateReviewQuestionnaire', nil, nil, 1)).to eq(new_assignment_questionnaire)
end
end
''
The next next test checks when the assignment questionnaire is found given the assignment id and duty id parameters. this test is very similar to the one where the test is not found because the it searches through the active record to find the assignment questionnaire.
''
context 'when active record for assignment_questionnaire is found for a given assignment_id and duty_id' do
it 'returns new instance of assignment_questionnaire with default values' do
allow(assignment).to receive(:questionnaire_varies_by_duty).and_return(true)
allow(Questionnaire).to receive(:find).with(1).and_return(questionnaire3)
allow(AssignmentQuestionnaire).to receive(:where).with(assignment_id: 1, duty_id: 1).and_return([assignment_questionnaire2])
allow(AssignmentQuestionnaire).to receive(:where).with(user_id: anything, assignment_id: nil, questionnaire_id: nil).and_return([])
allow(AssignmentQuestionnaire).to receive(:new).and_return(new_assignment_questionnaire)
expect(assignment_form.assignment_questionnaire('TeammateReviewQuestionnaire', nil, nil, 1)).to eq(assignment_questionnaire2)
end
end
''

== duty_spec.rb ==
the main purpose of the duty_spec.rb file is to test any duty to make sure a duty can be assigned to a team member. it also tests if a duty is unavailable to a team member because the max number of people have been assigned that duty. to test this functionality the mock data is created to allow for testing of the objcect.
''
let(:assignment) { build(:assignment, id: 1, name: 'no assgt') }
let(:participant) { build(:participant, id:1, user_id: 1) }
let(:participant2) { build(:participant, id:2, user_id: 2) }
let(:participant3) { build(:participant, id:3, user_id: 3) }
let(:user) { build(:student, id: 1, name: 'no name', fullname: 'no one', participants: [participant]) }
let(:user2) { build(:student, id: 2, name: 'no name2', fullname: 'no one2', participants: [participant2]) }
let(:user3) { build(:student, id: 3, name: 'no name3', fullname: 'no one3', participants: [participant3]) }

let(:team1) { build(:assignment_team, id: 1, name: 'no team', users: [user, user2, user3]) }
let(:sample_duty_taken) { build(:duty, id: 1, max_members_for_duty:1, assignment_id:1) }
let(:sample_duty_not_taken) { build(:duty, id: 1, max_members_for_duty:2, assignment_id:1) }

let(:team_user1) { build(:team_user, id: 1, user: user) }
let(:team_user2) { build(:team_user, id: 2, user: user2) }
let(:team_user3) { build(:team_user, id: 3, user: user3, duty_id:1) }
''
an assignment is created on which the duties can be tested. for the testing multiple users and participants are created. Finally we created team users that could be assigned duties through the duty_id field. the next step was to set up the reoccurring steps for each of the tests.
''
before(:each) do
allow(team1).to receive(:participants).and_return([participant, participant2, participant3])
allow(participant).to receive(:get_team_user).and_return(team_user1)
allow(participant2).to receive(:get_team_user).and_return(team_user2)
allow(participant3).to receive(:get_team_user).and_return(team_user3)
end
''
Finally the actual tests were implemented. The tests are fairly simple because they just need to check if the duty can be assigned or not.
''
describe '#can_be_assigned?' do
context 'when users in current team want to assign roles that are available'
it 'returns true' do
expect(sample_duty_not_taken.can_be_assigned?(team1)).to be true
end
context 'when users in current team want to assign roles that are unavailable'
it 'returns false' do
expect(sample_duty_taken.can_be_assigned?(team1)).to be false
end
''

== teammate_review_response_map_spec.rb ==
This Rspec testing file tests that a specific questionnaire can be returned when the student has a role assigned to them. This is needed for the role based reviewing because when one student goes to review another they must get the correct questionnaire for their role. We tested this functionality as well as the inverse, when the role could not be found. initially we created the mock data for testing which is shown below.
''
let(:questionnaire) { Questionnaire.new name: "abc", private: 0, min_question_score: 0, max_question_score: 10, instructor_id: 1234 }
let(:assignment) { build(:assignment, id: 1, name: 'no assgt', is_duty_based_assignment: true, questionnaires: [questionnaire]) }
let(:assignment_questionnaire1) { build(:assignment_questionnaire, id: 1, assignment_id: 1, questionnaire_id: 2, duty_id: 1) }
let(:participant) { build(:participant, id: 1, user_id: 6, assignment: assignment) }
let(:teammate_review_response_map) { TeammateReviewResponseMap.new reviewer: participant, reviewer_is_team: true, assignment:assignment }
''

== duties_controller_test.rb ==

== Manual Testing in Expertiza UI ==
Here we describe manual UI Testing steps to edit an existing assignment to allow it have to specialized rubrics for different topic types. These steps are also shown in recorded demo video.
*Login to Expertiza using instructor account (For testing, username: '''instructor6''', password: '''password''')
*Click on Manage > Assignments
*Click on Edit option for any assignment, you should get following view. Make sure '''Has topics?''' box is checked.
[[File:Assignment edit 3.png]]
*Click on Rubrics tab. You will see 2 checkboxes ('''Review rubric varies by round?''', '''Review rubric varies by topic?''')
*Check the box for '''Review rubric varies by topic?'''
*Go to Topics tab and verify that there is dropdown menu beside each Topic.
*Select a rubric from dropdown menu, and click '''Save'''
[[File:Topics rubric 2.png]]
*Go back to Home, and select the same assignment to edit. When you click on Topics tab, you should see the rubric you had selected.

==Team Information==
* Naman Shrimali
* Kanchan Rawat
* Subodh Thota
* Andrew Shipman
Mentor : Prof. Edward F. Gehringer

CSC/ECE 517 Fall 2021 - E2161. Merge code for role based reviewing with code for topic specific rubrics

2021-11-28T14:09:31Z

Ajshipma: /* teammate_review_response_map_spec.rb */

This wiki page contains description of changes designed and implemented for [https://docs.google.com/document/d/1slx4HPIbgTH-psIKMSCF-HDF9brxf-FuYhzVT9ZiIrM/edit#heading=h.8s6o9jnnxj0p E2161. Merge code for role-based reviewing with code for topic-specific rubrics], a Final Project for CSC/ECE 517, Fall 2021.
== Purpose==
In CSC/ECE 517, there are Expertiza-based course projects, Mozilla-based course projects, etc. However, currently, we can only specify one kind of rubric for all kinds of course projects. This means that refactoring projects, testing projects, and Mozilla projects need to use the same rubric. We hope we could specify different rubrics to be used with different kinds of course projects.

The project objective is to merge E2147-https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2147._Role-based_reviewing#E2147._Role-based_reviewing with the existing E2026-https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2020_-_E2026._Specialized_rubrics_for_different_topic_types. While merging, we found out that the code for E2026 has already been merged on Expertiza beta branch and so now the actual implementation is to write test cases for both E2147 and E2026.

==Brief Overview of E2147 and E2026 Projects==
*E2147(Role based reviewing): The project objective was to develop teammate review varying by the roles that each team member has in order to evaluate the particular role that each team member has taken rather than asking a generic questionnaire which was same for all the team members previously. For eg, the instructor would create a separate teammate questionnaire for developer role and for tester role respectively.
*E2026(Specialized rubrics for different topics): The project objective was to develop specialized rubrics based on project topics, previously we had same type of questionnaire for all the different types of projects. This implementation made sure that we evaluate different projects based on personalised rubrics rather than having same rubrics.

==Testing Plan==

===Test Scenarios for E2147(Role based reviewing)===
*Only Instructor/TA/Admin should be able to create or update duties: Only the instructor/admin should be able to create or update duties. Also, the corresponding TA of the assignment should be able to create or update duties.
*Create new roles: If the assignment is role based reviewing then the instructor should be able to create new roles for the same and save it in the database using new role functionality.
*Only allow student to update duties in Student View: Only student should be able to update his duties in Student View.
*Edit existing roles: Once the new roles have been created, then the instructor should be able to edit its details such as the maximum number of each role allowed.
*Delete existing roles: The instructor should also be able to delete any roles if he wants.
*Review rubric by role: On Rubrics tab, if the instructor clicks on Review rubric by role, then the corresponding rubric roles based teammate questionnaire should appear and get saved successfully.
*Student View: If the assignment is role based assignment, then the respective students should be able to see the respective teammate questionnaire based on roles for his other team members.
*Selection of Roles: On student login, a student should be able to see the existing roles that he can take up in the project. Only the roles which are available should be shown to the student.

===Test Scenarios for E2026(Specialized rubrics for different topics)===

As part of our implementation, we modified existing code as well as added new code. To ensure that existing functionality was not broken, and new functionality worked as expected, we used the following Test Strategy (which was also used by previous team):

===Run and pass existing RSpec Tests===
*The following existing RSpec test files have been modified and they pass as part of testing:
**spec/controllers/assignments_controller_spec.rb
**spec/controllers/questionnaires_controller_spec.rb
**spec/controllers/response_controller_spec.rb
**spec/factories/factories.rb
**spec/features/assignment_creation_spec.rb
**spec/features/quiz_spec.rb
**spec/features/staggered_deadline_spec.rb
**spec/models/assignment_form_spec.rb
**spec/models/assignment_spec.rb
**spec/models/on_the_fly_calc_spec.rb
**spec/models/response_spec.rb
**spec/models/review_response_map_spec.rb

===Develop New RSpec Tests===
*spec/helpers/duties_controller_spec.rb
*All these rspec tests passed.

== duties_controller_spec.rb ==
We have created this new test file to unit test the duties scenarios.

First we mock the data accordingly as needed by the tests.

''
describe DutiesController do
let(:assignment) { build(:assignment, id: 1,course_id: 1,instructor_id: 6, due_dates: [due_date], microtask: true, staggered_deadline: true)}
let(:admin) { build(:admin) }
let(:instructor) { build(:instructor, id: 6) }
let(:instructor2) { build(:instructor, id: 66) }
let(:ta) { build(:teaching_assistant, id: 8) }
let(:duty) { build(:duty, id: 1, duty_name: "Role", max_members_for_duty: 2, assignment_id: 1) }
let(:due_date) { build(:assignment_due_date, deadline_type_id: 1) } ''

We then run the arbitrary code that is needed before each test

''
before(:each) do
allow(Assignment).to receive(:find).with('1').and_return(assignment)
allow(Assignment).to receive(:find).with(1).and_return(assignment)
stub_current_user(instructor, instructor.role.name, instructor.role)
allow(Duty).to receive(:find).with('1').and_return(duty)
end
''

Test scenarios for duties controller:
1) Only admin, superadmin, TA, Instructor can perform edit or update action

'' describe '#action_allowed?' do ''

The whole context that defines if the action allowed is edit or update. We do this by mocking the action to edit

context 'when params action is edit or update' do
before(:each) do
controller.params = {id: '1', action: 'edit'}
end

When the current logged in user role is super admin or admin

context 'when the role name of current user is super admin or admin' do
it 'allows certain action' do
stub_current_user(admin, admin.role.name, admin.role)
expect(controller.send(:action_allowed?)).to be true
end
end

When the current logged in user role is instructor

context 'when current user is the instructor of current assignment' do
it 'allows certain action' do
expect(controller.send(:action_allowed?)).to be true
end
end

When the current logged in user role is the TA of the course

context 'when current user is the ta of the course which current assignment belongs to' do
it 'allows certain action' do
stub_current_user(ta, ta.role.name, ta.role)
allow(TaMapping).to receive(:exists?).with(ta_id: 8, course_id: 1).and_return(true)
expect(controller.send(:action_allowed?)).to be true
end
end

When the current logged in user is the instructor of the course

context 'when current user is the instructor of the course which current assignment belongs to' do
it 'allows certain action' do
stub_current_user(instructor2, instructor2.role.name, instructor2.role)
allow(Course).to receive(:find).with(1).and_return(double('Course', instructor_id: 66))
expect(controller.send(:action_allowed?)).to be true
end
end
end

When the parameter action is neither edit nor update, we do this by mocking the action to new

context 'when params action is not edit and update' do
before(:each) do
controller.params = {id: '1', action: 'new'}
end

We now check if super admin/admin/instructor/ta can perform this action which is neither edit nor update

context 'when the role current user is super admin/admin/instructor/ta' do
it 'allows certain action except edit and update' do
expect(controller.send(:action_allowed?)).to be true
end
end
end
end

And then we added few tests to test creation/edit/deletion of a duty

Creation of a duty, we create a duty and check if it is saved successfully

describe '#create' do

Checking if the right page is rendered after successful creation of a duty

context 'when new duty can be saved successfully' do
it 'sets up a new duty and redirects to assignment#edit page' do
allow(duty).to receive(:save).and_return('OK')
params = {
id: 1,
duty: {
duty_name: 'Scrum Master',
max_members_for_duty: 2,
assignment_id: 1
}
}
post :create, params
expect(response).to redirect_to('/assignments/1/edit')
expect(flash[:notice]).to match(/Role was successfully created.*/)
end
end

Test to check if the right error message is shown if the creation of duty is failed

context 'when new duty cannot be saved successfully' do
it 'shows error message and redirects to duty#new page' do
allow(duty).to receive(:errors)
params = {
id: 1,
duty: {
duty_name: 'Scrum Master',
max_members_for_duty: -1,
assignment_id: 1
}
}
post :create, params
expect(flash[:error]).to eq('Max members for duty must be greater than or equal to 1. ')
expect(response).to redirect_to('/duties/new?id=1')
end
end
end

Test to check the edit functionality of a duty

describe '#update' do

When the duty can be edited successfully, we check if the right page is rendered

context 'when duty can be found' do
it 'updates current duty and redirects to assignment#edit page' do
allow(Duty).to receive(:find).with('1').and_return(build(:duty, id: 1))
params = {
id: 1,
assignment_id: 1,
duty: {
duty_name: 'Scrum Master',
max_members_for_duty: 5,
assignment_id: 1
}
}
post :update, params
expect(response).to redirect_to('/assignments/1/edit')
expect(flash[:notice]).to match(/Role was successfully updated.*/)
end
end

When the duty cannot be updated, we check if the right error message is displayed

context 'when new duty cannot be updated successfully' do
it 'shows error message and redirects to duty#new page' do
allow(duty).to receive(:errors)
params = {
id: 1,
duty: {
duty_name: 'SM',
max_members_for_duty: 1,
assignment_id: 1
}
}
post :create, params
expect(flash[:error]).to eq('Duty name is too short (minimum is 3 characters). ')
expect(response).to redirect_to('/duties/new?id=1')
end
end
end

Now finally, we test the delete functionality of the duty

describe '#destroy' do
context 'when duty can be found' do
it 'redirects to assignment#edit page' do
params = {id: 1, assignment_id: 1}
post :destroy, params
expect(response).to redirect_to('/assignments/1/edit')
expect(flash[:notice]).to match(/Role was successfully destroyed.*/)
end
end
end

== team_users_controller_spec.rb ==

We have added a test case in this file which tests if the action is allowed only by specific user roles

First, we mock the data

''
describe TeamsUsersController do
let(:assignment) do
build(:assignment, id: 1, name: 'test assignment', instructor_id: 6, staggered_deadline: true, directory_path: 'same path',
participants: [build(:participant)], teams: [build(:assignment_team)], course_id: 1)
end
let(:assignment_form) { double('AssignmentForm', assignment: assignment) }
let(:student) { build(:student) }

before(:each) do
allow(Assignment).to receive(:find).with('1').and_return(assignment)
stub_current_user(student, student.role.name, student.role)
end
''

Then we check if the student can perform the update action for duties

''
describe '#action_allowed?' do
context 'when params action is update duties' do
before(:each) do
controller.params = {id: '1', action: 'update_duties'}
end
context 'when the role current user is student' do
it 'allows certain action' do
stub_current_user(student, student.role.name, student.role)
expect(controller.send(:action_allowed?)).to be true
end
end
end
end
''

This file also contains a test case to ensure the duties can be properly updated. The test case checks this by ensuring that the user is redirected to the student view page. just as with the previous section the first step is to mock the data by creating a team user object.

''
let(:teams_user1) {TeamsUser.new id:1, duty_id:1}
''

Then the data is actually updated and we ensure that the user is redirected to the proper place.

''
describe '#update_duties' do
it 'updates the duties for the participant' do
allow(TeamsUser).to receive(:find).with('1').and_return(teams_user1)
allow(teams_user1).to receive(:update_attribute).with(any_args).and_return('OK')
params = {
teams_user_id: '1',
teams_user: {duty_id: '1'},
participant_id: '1'
}
session = {user: stub_current_user(student, student.role.name, student.role)}
get :update_duties, params, session
expect(response).to redirect_to('/student_teams/view?student_id=1')
end
end
''

== assignment_form_spec.rb ==
The assignemnt_form_spec.rb file contains all the test files for the assignment form, which includes adding object to a queue. the first step was to create mock data so that the test could run on objects created for the tests. the code below shows how the mock data was created for the specific tests that we created to ensure the functionality of the projects.
''
let(:new_assignment_questionnaire) { build(:assignment_questionnaire) }
''
The new_assignment_questionnaire object is used for both test cases in this file. the first test case checks for when the active record cannot be found for a specific assignment id or duty id.
''
context 'when active record for assignment_questionnaire is not found for a given assignment_id and duty_id' do
it 'returns new instance of assignment_questionnaire with default values' do
allow(assignment).to receive(:questionnaire_varies_by_duty).and_return(true)
allow(AssignmentQuestionnaire).to receive(:where).with(assignment_id: 1, duty_id: anything).and_return([])
allow(AssignmentQuestionnaire).to receive(:where).with(user_id: anything, assignment_id: nil, questionnaire_id: nil).and_return([])
allow(AssignmentQuestionnaire).to receive(:new).and_return(new_assignment_questionnaire)
expect(assignment_form.assignment_questionnaire('TeammateReviewQuestionnaire', nil, nil, 1)).to eq(new_assignment_questionnaire)
end
end
''
The next next test checks when the assignment questionnaire is found given the assignment id and duty id parameters. this test is very similar to the one where the test is not found because the it searches through the active record to find the assignment questionnaire.
''
context 'when active record for assignment_questionnaire is found for a given assignment_id and duty_id' do
it 'returns new instance of assignment_questionnaire with default values' do
allow(assignment).to receive(:questionnaire_varies_by_duty).and_return(true)
allow(Questionnaire).to receive(:find).with(1).and_return(questionnaire3)
allow(AssignmentQuestionnaire).to receive(:where).with(assignment_id: 1, duty_id: 1).and_return([assignment_questionnaire2])
allow(AssignmentQuestionnaire).to receive(:where).with(user_id: anything, assignment_id: nil, questionnaire_id: nil).and_return([])
allow(AssignmentQuestionnaire).to receive(:new).and_return(new_assignment_questionnaire)
expect(assignment_form.assignment_questionnaire('TeammateReviewQuestionnaire', nil, nil, 1)).to eq(assignment_questionnaire2)
end
end
''

== duty_spec.rb ==
the main purpose of the duty_spec.rb file is to test any duty to make sure a duty can be assigned to a team member. it also tests if a duty is unavailable to a team member because the max number of people have been assigned that duty. to test this functionality the mock data is created to allow for testing of the objcect.
''
let(:assignment) { build(:assignment, id: 1, name: 'no assgt') }
let(:participant) { build(:participant, id:1, user_id: 1) }
let(:participant2) { build(:participant, id:2, user_id: 2) }
let(:participant3) { build(:participant, id:3, user_id: 3) }
let(:user) { build(:student, id: 1, name: 'no name', fullname: 'no one', participants: [participant]) }
let(:user2) { build(:student, id: 2, name: 'no name2', fullname: 'no one2', participants: [participant2]) }
let(:user3) { build(:student, id: 3, name: 'no name3', fullname: 'no one3', participants: [participant3]) }

let(:team1) { build(:assignment_team, id: 1, name: 'no team', users: [user, user2, user3]) }
let(:sample_duty_taken) { build(:duty, id: 1, max_members_for_duty:1, assignment_id:1) }
let(:sample_duty_not_taken) { build(:duty, id: 1, max_members_for_duty:2, assignment_id:1) }

let(:team_user1) { build(:team_user, id: 1, user: user) }
let(:team_user2) { build(:team_user, id: 2, user: user2) }
let(:team_user3) { build(:team_user, id: 3, user: user3, duty_id:1) }
''
an assignment is created on which the duties can be tested. for the testing multiple users and participants are created. Finally we created team users that could be assigned duties through the duty_id field. the next step was to set up the reoccurring steps for each of the tests.
''
before(:each) do
allow(team1).to receive(:participants).and_return([participant, participant2, participant3])
allow(participant).to receive(:get_team_user).and_return(team_user1)
allow(participant2).to receive(:get_team_user).and_return(team_user2)
allow(participant3).to receive(:get_team_user).and_return(team_user3)
end
''
Finally the actual tests were implemented. The tests are fairly simple because they just need to check if the duty can be assigned or not.
''
describe '#can_be_assigned?' do
context 'when users in current team want to assign roles that are available'
it 'returns true' do
expect(sample_duty_not_taken.can_be_assigned?(team1)).to be true
end
context 'when users in current team want to assign roles that are unavailable'
it 'returns false' do
expect(sample_duty_taken.can_be_assigned?(team1)).to be false
end
''

== teammate_review_response_map_spec.rb ==
This Rspec testing file tests that a specific questionnaire can be returned when the student has a role assigned to them. This is needed for the role based reviewing because

== duties_controller_test.rb ==

== Manual Testing in Expertiza UI ==
Here we describe manual UI Testing steps to edit an existing assignment to allow it have to specialized rubrics for different topic types. These steps are also shown in recorded demo video.
*Login to Expertiza using instructor account (For testing, username: '''instructor6''', password: '''password''')
*Click on Manage > Assignments
*Click on Edit option for any assignment, you should get following view. Make sure '''Has topics?''' box is checked.
[[File:Assignment edit 3.png]]
*Click on Rubrics tab. You will see 2 checkboxes ('''Review rubric varies by round?''', '''Review rubric varies by topic?''')
*Check the box for '''Review rubric varies by topic?'''
*Go to Topics tab and verify that there is dropdown menu beside each Topic.
*Select a rubric from dropdown menu, and click '''Save'''
[[File:Topics rubric 2.png]]
*Go back to Home, and select the same assignment to edit. When you click on Topics tab, you should see the rubric you had selected.

==Team Information==
* Naman Shrimali
* Kanchan Rawat
* Subodh Thota
* Andrew Shipman
Mentor : Prof. Edward F. Gehringer

CSC/ECE 517 Fall 2021 - E2161. Merge code for role based reviewing with code for topic specific rubrics

2021-11-28T04:36:59Z

Ajshipma: /* duty_spec.rb */

This wiki page contains description of changes designed and implemented for [https://docs.google.com/document/d/1slx4HPIbgTH-psIKMSCF-HDF9brxf-FuYhzVT9ZiIrM/edit#heading=h.8s6o9jnnxj0p E2161. Merge code for role-based reviewing with code for topic-specific rubrics], a Final Project for CSC/ECE 517, Fall 2021.
== Purpose==
In CSC/ECE 517, there are Expertiza-based course projects, Mozilla-based course projects, etc. However, currently, we can only specify one kind of rubric for all kinds of course projects. This means that refactoring projects, testing projects, and Mozilla projects need to use the same rubric. We hope we could specify different rubrics to be used with different kinds of course projects.

The project objective is to merge E2147-https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2147._Role-based_reviewing#E2147._Role-based_reviewing with the existing E2026-https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2020_-_E2026._Specialized_rubrics_for_different_topic_types. While merging, we found out that the code for E2026 has already been merged on Expertiza beta branch and so now the actual implementation is to write test cases for both E2147 and E2026.

==Brief Overview of E2147 and E2026 Projects==
*E2147(Role based reviewing): The project objective was to develop teammate review varying by the roles that each team member has in order to evaluate the particular role that each team member has taken rather than asking a generic questionnaire which was same for all the team members previously. For eg, the instructor would create a separate teammate questionnaire for developer role and for tester role respectively.
*E2026(Specialized rubrics for different topics): The project objective was to develop specialized rubrics based on project topics, previously we had same type of questionnaire for all the different types of projects. This implementation made sure that we evaluate different projects based on personalised rubrics rather than having same rubrics.

==Testing Plan==

===Test Scenarios for E2147(Role based reviewing)===
*Only Instructor/TA/Admin should be able to create or update duties: Only the instructor/admin should be able to create or update duties. Also, the corresponding TA of the assignment should be able to create or update duties.
*Create new roles: If the assignment is role based reviewing then the instructor should be able to create new roles for the same and save it in the database using new role functionality.
*Only allow student to update duties in Student View: Only student should be able to update his duties in Student View.
*Edit existing roles: Once the new roles have been created, then the instructor should be able to edit its details such as the maximum number of each role allowed.
*Delete existing roles: The instructor should also be able to delete any roles if he wants.
*Review rubric by role: On Rubrics tab, if the instructor clicks on Review rubric by role, then the corresponding rubric roles based teammate questionnaire should appear and get saved successfully.
*Student View: If the assignment is role based assignment, then the respective students should be able to see the respective teammate questionnaire based on roles for his other team members.
*Selection of Roles: On student login, a student should be able to see the existing roles that he can take up in the project. Only the roles which are available should be shown to the student.

===Test Scenarios for E2026(Specialized rubrics for different topics)===

As part of our implementation, we modified existing code as well as added new code. To ensure that existing functionality was not broken, and new functionality worked as expected, we used the following Test Strategy (which was also used by previous team):

===Run and pass existing RSpec Tests===
*The following existing RSpec test files have been modified and they pass as part of testing:
**spec/controllers/assignments_controller_spec.rb
**spec/controllers/questionnaires_controller_spec.rb
**spec/controllers/response_controller_spec.rb
**spec/factories/factories.rb
**spec/features/assignment_creation_spec.rb
**spec/features/quiz_spec.rb
**spec/features/staggered_deadline_spec.rb
**spec/models/assignment_form_spec.rb
**spec/models/assignment_spec.rb
**spec/models/on_the_fly_calc_spec.rb
**spec/models/response_spec.rb
**spec/models/review_response_map_spec.rb

===Develop New RSpec Tests===
*spec/helpers/duties_controller_spec.rb
*All these rspec tests passed.

== duties_controller_spec.rb ==
We have created this new test file to unit test the duties scenarios.

First we mock the data accordingly as needed by the tests.

''
describe DutiesController do
let(:assignment) { build(:assignment, id: 1,course_id: 1,instructor_id: 6, due_dates: [due_date], microtask: true, staggered_deadline: true)}
let(:admin) { build(:admin) }
let(:instructor) { build(:instructor, id: 6) }
let(:instructor2) { build(:instructor, id: 66) }
let(:ta) { build(:teaching_assistant, id: 8) }
let(:duty) { build(:duty, id: 1, duty_name: "Role", max_members_for_duty: 2, assignment_id: 1) }
let(:due_date) { build(:assignment_due_date, deadline_type_id: 1) } ''

We then run the arbitrary code that is needed before each test

''
before(:each) do
allow(Assignment).to receive(:find).with('1').and_return(assignment)
allow(Assignment).to receive(:find).with(1).and_return(assignment)
stub_current_user(instructor, instructor.role.name, instructor.role)
allow(Duty).to receive(:find).with('1').and_return(duty)
end
''

Test scenarios for duties controller:
1) Only admin, superadmin, TA, Instructor can perform edit or update action

'' describe '#action_allowed?' do ''

The whole context that defines if the action allowed is edit or update. We do this by mocking the action to edit

context 'when params action is edit or update' do
before(:each) do
controller.params = {id: '1', action: 'edit'}
end

When the current logged in user role is super admin or admin

context 'when the role name of current user is super admin or admin' do
it 'allows certain action' do
stub_current_user(admin, admin.role.name, admin.role)
expect(controller.send(:action_allowed?)).to be true
end
end

When the current logged in user role is instructor

context 'when current user is the instructor of current assignment' do
it 'allows certain action' do
expect(controller.send(:action_allowed?)).to be true
end
end

When the current logged in user role is the TA of the course

context 'when current user is the ta of the course which current assignment belongs to' do
it 'allows certain action' do
stub_current_user(ta, ta.role.name, ta.role)
allow(TaMapping).to receive(:exists?).with(ta_id: 8, course_id: 1).and_return(true)
expect(controller.send(:action_allowed?)).to be true
end
end

When the current logged in user is the instructor of the course

context 'when current user is the instructor of the course which current assignment belongs to' do
it 'allows certain action' do
stub_current_user(instructor2, instructor2.role.name, instructor2.role)
allow(Course).to receive(:find).with(1).and_return(double('Course', instructor_id: 66))
expect(controller.send(:action_allowed?)).to be true
end
end
end

When the parameter action is neither edit nor update, we do this by mocking the action to new

context 'when params action is not edit and update' do
before(:each) do
controller.params = {id: '1', action: 'new'}
end

We now check if super admin/admin/instructor/ta can perform this action which is neither edit nor update

context 'when the role current user is super admin/admin/instructor/ta' do
it 'allows certain action except edit and update' do
expect(controller.send(:action_allowed?)).to be true
end
end
end
end

And then we added few tests to test creation/edit/deletion of a duty

Creation of a duty, we create a duty and check if it is saved successfully

describe '#create' do

Checking if the right page is rendered after successful creation of a duty

context 'when new duty can be saved successfully' do
it 'sets up a new duty and redirects to assignment#edit page' do
allow(duty).to receive(:save).and_return('OK')
params = {
id: 1,
duty: {
duty_name: 'Scrum Master',
max_members_for_duty: 2,
assignment_id: 1
}
}
post :create, params
expect(response).to redirect_to('/assignments/1/edit')
expect(flash[:notice]).to match(/Role was successfully created.*/)
end
end

Test to check if the right error message is shown if the creation of duty is failed

context 'when new duty cannot be saved successfully' do
it 'shows error message and redirects to duty#new page' do
allow(duty).to receive(:errors)
params = {
id: 1,
duty: {
duty_name: 'Scrum Master',
max_members_for_duty: -1,
assignment_id: 1
}
}
post :create, params
expect(flash[:error]).to eq('Max members for duty must be greater than or equal to 1. ')
expect(response).to redirect_to('/duties/new?id=1')
end
end
end

Test to check the edit functionality of a duty

describe '#update' do

When the duty can be edited successfully, we check if the right page is rendered

context 'when duty can be found' do
it 'updates current duty and redirects to assignment#edit page' do
allow(Duty).to receive(:find).with('1').and_return(build(:duty, id: 1))
params = {
id: 1,
assignment_id: 1,
duty: {
duty_name: 'Scrum Master',
max_members_for_duty: 5,
assignment_id: 1
}
}
post :update, params
expect(response).to redirect_to('/assignments/1/edit')
expect(flash[:notice]).to match(/Role was successfully updated.*/)
end
end

When the duty cannot be updated, we check if the right error message is displayed

context 'when new duty cannot be updated successfully' do
it 'shows error message and redirects to duty#new page' do
allow(duty).to receive(:errors)
params = {
id: 1,
duty: {
duty_name: 'SM',
max_members_for_duty: 1,
assignment_id: 1
}
}
post :create, params
expect(flash[:error]).to eq('Duty name is too short (minimum is 3 characters). ')
expect(response).to redirect_to('/duties/new?id=1')
end
end
end

Now finally, we test the delete functionality of the duty

describe '#destroy' do
context 'when duty can be found' do
it 'redirects to assignment#edit page' do
params = {id: 1, assignment_id: 1}
post :destroy, params
expect(response).to redirect_to('/assignments/1/edit')
expect(flash[:notice]).to match(/Role was successfully destroyed.*/)
end
end
end

== team_users_controller_spec.rb ==

We have added a test case in this file which tests if the action is allowed only by specific user roles

First, we mock the data

''
describe TeamsUsersController do
let(:assignment) do
build(:assignment, id: 1, name: 'test assignment', instructor_id: 6, staggered_deadline: true, directory_path: 'same path',
participants: [build(:participant)], teams: [build(:assignment_team)], course_id: 1)
end
let(:assignment_form) { double('AssignmentForm', assignment: assignment) }
let(:student) { build(:student) }

before(:each) do
allow(Assignment).to receive(:find).with('1').and_return(assignment)
stub_current_user(student, student.role.name, student.role)
end
''

Then we check if the student can perform the update action for duties

''
describe '#action_allowed?' do
context 'when params action is update duties' do
before(:each) do
controller.params = {id: '1', action: 'update_duties'}
end
context 'when the role current user is student' do
it 'allows certain action' do
stub_current_user(student, student.role.name, student.role)
expect(controller.send(:action_allowed?)).to be true
end
end
end
end
''

This file also contains a test case to ensure the duties can be properly updated. The test case checks this by ensuring that the user is redirected to the student view page. just as with the previous section the first step is to mock the data by creating a team user object.

''
let(:teams_user1) {TeamsUser.new id:1, duty_id:1}
''

Then the data is actually updated and we ensure that the user is redirected to the proper place.

''
describe '#update_duties' do
it 'updates the duties for the participant' do
allow(TeamsUser).to receive(:find).with('1').and_return(teams_user1)
allow(teams_user1).to receive(:update_attribute).with(any_args).and_return('OK')
params = {
teams_user_id: '1',
teams_user: {duty_id: '1'},
participant_id: '1'
}
session = {user: stub_current_user(student, student.role.name, student.role)}
get :update_duties, params, session
expect(response).to redirect_to('/student_teams/view?student_id=1')
end
end
''

== assignment_form_spec.rb ==
The assignemnt_form_spec.rb file contains all the test files for the assignment form, which includes adding object to a queue. the first step was to create mock data so that the test could run on objects created for the tests. the code below shows how the mock data was created for the specific tests that we created to ensure the functionality of the projects.
''
let(:new_assignment_questionnaire) { build(:assignment_questionnaire) }
''
The new_assignment_questionnaire object is used for both test cases in this file. the first test case checks for when the active record cannot be found for a specific assignment id or duty id.
''
context 'when active record for assignment_questionnaire is not found for a given assignment_id and duty_id' do
it 'returns new instance of assignment_questionnaire with default values' do
allow(assignment).to receive(:questionnaire_varies_by_duty).and_return(true)
allow(AssignmentQuestionnaire).to receive(:where).with(assignment_id: 1, duty_id: anything).and_return([])
allow(AssignmentQuestionnaire).to receive(:where).with(user_id: anything, assignment_id: nil, questionnaire_id: nil).and_return([])
allow(AssignmentQuestionnaire).to receive(:new).and_return(new_assignment_questionnaire)
expect(assignment_form.assignment_questionnaire('TeammateReviewQuestionnaire', nil, nil, 1)).to eq(new_assignment_questionnaire)
end
end
''
The next next test checks when the assignment questionnaire is found given the assignment id and duty id parameters. this test is very similar to the one where the test is not found because the it searches through the active record to find the assignment questionnaire.
''
context 'when active record for assignment_questionnaire is found for a given assignment_id and duty_id' do
it 'returns new instance of assignment_questionnaire with default values' do
allow(assignment).to receive(:questionnaire_varies_by_duty).and_return(true)
allow(Questionnaire).to receive(:find).with(1).and_return(questionnaire3)
allow(AssignmentQuestionnaire).to receive(:where).with(assignment_id: 1, duty_id: 1).and_return([assignment_questionnaire2])
allow(AssignmentQuestionnaire).to receive(:where).with(user_id: anything, assignment_id: nil, questionnaire_id: nil).and_return([])
allow(AssignmentQuestionnaire).to receive(:new).and_return(new_assignment_questionnaire)
expect(assignment_form.assignment_questionnaire('TeammateReviewQuestionnaire', nil, nil, 1)).to eq(assignment_questionnaire2)
end
end
''

== duty_spec.rb ==
the main purpose of the duty_spec.rb file is to test any duty to make sure a duty can be assigned to a team member. it also tests if a duty is unavailable to a team member because the max number of people have been assigned that duty. to test this functionality the mock data is created to allow for testing of the objcect.
''
let(:assignment) { build(:assignment, id: 1, name: 'no assgt') }
let(:participant) { build(:participant, id:1, user_id: 1) }
let(:participant2) { build(:participant, id:2, user_id: 2) }
let(:participant3) { build(:participant, id:3, user_id: 3) }
let(:user) { build(:student, id: 1, name: 'no name', fullname: 'no one', participants: [participant]) }
let(:user2) { build(:student, id: 2, name: 'no name2', fullname: 'no one2', participants: [participant2]) }
let(:user3) { build(:student, id: 3, name: 'no name3', fullname: 'no one3', participants: [participant3]) }

let(:team1) { build(:assignment_team, id: 1, name: 'no team', users: [user, user2, user3]) }
let(:sample_duty_taken) { build(:duty, id: 1, max_members_for_duty:1, assignment_id:1) }
let(:sample_duty_not_taken) { build(:duty, id: 1, max_members_for_duty:2, assignment_id:1) }

let(:team_user1) { build(:team_user, id: 1, user: user) }
let(:team_user2) { build(:team_user, id: 2, user: user2) }
let(:team_user3) { build(:team_user, id: 3, user: user3, duty_id:1) }
''
an assignment is created on which the duties can be tested. for the testing multiple users and participants are created. Finally we created team users that could be assigned duties through the duty_id field. the next step was to set up the reoccurring steps for each of the tests.
''
before(:each) do
allow(team1).to receive(:participants).and_return([participant, participant2, participant3])
allow(participant).to receive(:get_team_user).and_return(team_user1)
allow(participant2).to receive(:get_team_user).and_return(team_user2)
allow(participant3).to receive(:get_team_user).and_return(team_user3)
end
''
Finally the actual tests were implemented. The tests are fairly simple because they just need to check if the duty can be assigned or not.
''
describe '#can_be_assigned?' do
context 'when users in current team want to assign roles that are available'
it 'returns true' do
expect(sample_duty_not_taken.can_be_assigned?(team1)).to be true
end
context 'when users in current team want to assign roles that are unavailable'
it 'returns false' do
expect(sample_duty_taken.can_be_assigned?(team1)).to be false
end
''

== teammate_review_response_map_spec.rb ==

== duties_controller_test.rb ==

== Manual Testing in Expertiza UI ==
Here we describe manual UI Testing steps to edit an existing assignment to allow it have to specialized rubrics for different topic types. These steps are also shown in recorded demo video.
*Login to Expertiza using instructor account (For testing, username: '''instructor6''', password: '''password''')
*Click on Manage > Assignments
*Click on Edit option for any assignment, you should get following view. Make sure '''Has topics?''' box is checked.
[[File:Assignment edit 3.png]]
*Click on Rubrics tab. You will see 2 checkboxes ('''Review rubric varies by round?''', '''Review rubric varies by topic?''')
*Check the box for '''Review rubric varies by topic?'''
*Go to Topics tab and verify that there is dropdown menu beside each Topic.
*Select a rubric from dropdown menu, and click '''Save'''
[[File:Topics rubric 2.png]]
*Go back to Home, and select the same assignment to edit. When you click on Topics tab, you should see the rubric you had selected.

==Team Information==
* Naman Shrimali
* Kanchan Rawat
* Subodh Thota
* Andrew Shipman
Mentor : Prof. Edward F. Gehringer

CSC/ECE 517 Fall 2021 - E2161. Merge code for role based reviewing with code for topic specific rubrics

2021-11-28T04:35:37Z

Ajshipma: /* duty_spec.rb */

This wiki page contains description of changes designed and implemented for [https://docs.google.com/document/d/1slx4HPIbgTH-psIKMSCF-HDF9brxf-FuYhzVT9ZiIrM/edit#heading=h.8s6o9jnnxj0p E2161. Merge code for role-based reviewing with code for topic-specific rubrics], a Final Project for CSC/ECE 517, Fall 2021.
== Purpose==
In CSC/ECE 517, there are Expertiza-based course projects, Mozilla-based course projects, etc. However, currently, we can only specify one kind of rubric for all kinds of course projects. This means that refactoring projects, testing projects, and Mozilla projects need to use the same rubric. We hope we could specify different rubrics to be used with different kinds of course projects.

The project objective is to merge E2147-https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2147._Role-based_reviewing#E2147._Role-based_reviewing with the existing E2026-https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2020_-_E2026._Specialized_rubrics_for_different_topic_types. While merging, we found out that the code for E2026 has already been merged on Expertiza beta branch and so now the actual implementation is to write test cases for both E2147 and E2026.

==Brief Overview of E2147 and E2026 Projects==
*E2147(Role based reviewing): The project objective was to develop teammate review varying by the roles that each team member has in order to evaluate the particular role that each team member has taken rather than asking a generic questionnaire which was same for all the team members previously. For eg, the instructor would create a separate teammate questionnaire for developer role and for tester role respectively.
*E2026(Specialized rubrics for different topics): The project objective was to develop specialized rubrics based on project topics, previously we had same type of questionnaire for all the different types of projects. This implementation made sure that we evaluate different projects based on personalised rubrics rather than having same rubrics.

==Testing Plan==

===Test Scenarios for E2147(Role based reviewing)===
*Only Instructor/TA/Admin should be able to create or update duties: Only the instructor/admin should be able to create or update duties. Also, the corresponding TA of the assignment should be able to create or update duties.
*Create new roles: If the assignment is role based reviewing then the instructor should be able to create new roles for the same and save it in the database using new role functionality.
*Only allow student to update duties in Student View: Only student should be able to update his duties in Student View.
*Edit existing roles: Once the new roles have been created, then the instructor should be able to edit its details such as the maximum number of each role allowed.
*Delete existing roles: The instructor should also be able to delete any roles if he wants.
*Review rubric by role: On Rubrics tab, if the instructor clicks on Review rubric by role, then the corresponding rubric roles based teammate questionnaire should appear and get saved successfully.
*Student View: If the assignment is role based assignment, then the respective students should be able to see the respective teammate questionnaire based on roles for his other team members.
*Selection of Roles: On student login, a student should be able to see the existing roles that he can take up in the project. Only the roles which are available should be shown to the student.

===Test Scenarios for E2026(Specialized rubrics for different topics)===

As part of our implementation, we modified existing code as well as added new code. To ensure that existing functionality was not broken, and new functionality worked as expected, we used the following Test Strategy (which was also used by previous team):

===Run and pass existing RSpec Tests===
*The following existing RSpec test files have been modified and they pass as part of testing:
**spec/controllers/assignments_controller_spec.rb
**spec/controllers/questionnaires_controller_spec.rb
**spec/controllers/response_controller_spec.rb
**spec/factories/factories.rb
**spec/features/assignment_creation_spec.rb
**spec/features/quiz_spec.rb
**spec/features/staggered_deadline_spec.rb
**spec/models/assignment_form_spec.rb
**spec/models/assignment_spec.rb
**spec/models/on_the_fly_calc_spec.rb
**spec/models/response_spec.rb
**spec/models/review_response_map_spec.rb

===Develop New RSpec Tests===
*spec/helpers/duties_controller_spec.rb
*All these rspec tests passed.

== duties_controller_spec.rb ==
We have created this new test file to unit test the duties scenarios.

First we mock the data accordingly as needed by the tests.

''
describe DutiesController do
let(:assignment) { build(:assignment, id: 1,course_id: 1,instructor_id: 6, due_dates: [due_date], microtask: true, staggered_deadline: true)}
let(:admin) { build(:admin) }
let(:instructor) { build(:instructor, id: 6) }
let(:instructor2) { build(:instructor, id: 66) }
let(:ta) { build(:teaching_assistant, id: 8) }
let(:duty) { build(:duty, id: 1, duty_name: "Role", max_members_for_duty: 2, assignment_id: 1) }
let(:due_date) { build(:assignment_due_date, deadline_type_id: 1) } ''

We then run the arbitrary code that is needed before each test

''
before(:each) do
allow(Assignment).to receive(:find).with('1').and_return(assignment)
allow(Assignment).to receive(:find).with(1).and_return(assignment)
stub_current_user(instructor, instructor.role.name, instructor.role)
allow(Duty).to receive(:find).with('1').and_return(duty)
end
''

Test scenarios for duties controller:
1) Only admin, superadmin, TA, Instructor can perform edit or update action

'' describe '#action_allowed?' do ''

The whole context that defines if the action allowed is edit or update. We do this by mocking the action to edit

context 'when params action is edit or update' do
before(:each) do
controller.params = {id: '1', action: 'edit'}
end

When the current logged in user role is super admin or admin

context 'when the role name of current user is super admin or admin' do
it 'allows certain action' do
stub_current_user(admin, admin.role.name, admin.role)
expect(controller.send(:action_allowed?)).to be true
end
end

When the current logged in user role is instructor

context 'when current user is the instructor of current assignment' do
it 'allows certain action' do
expect(controller.send(:action_allowed?)).to be true
end
end

When the current logged in user role is the TA of the course

context 'when current user is the ta of the course which current assignment belongs to' do
it 'allows certain action' do
stub_current_user(ta, ta.role.name, ta.role)
allow(TaMapping).to receive(:exists?).with(ta_id: 8, course_id: 1).and_return(true)
expect(controller.send(:action_allowed?)).to be true
end
end

When the current logged in user is the instructor of the course

context 'when current user is the instructor of the course which current assignment belongs to' do
it 'allows certain action' do
stub_current_user(instructor2, instructor2.role.name, instructor2.role)
allow(Course).to receive(:find).with(1).and_return(double('Course', instructor_id: 66))
expect(controller.send(:action_allowed?)).to be true
end
end
end

When the parameter action is neither edit nor update, we do this by mocking the action to new

context 'when params action is not edit and update' do
before(:each) do
controller.params = {id: '1', action: 'new'}
end

We now check if super admin/admin/instructor/ta can perform this action which is neither edit nor update

context 'when the role current user is super admin/admin/instructor/ta' do
it 'allows certain action except edit and update' do
expect(controller.send(:action_allowed?)).to be true
end
end
end
end

And then we added few tests to test creation/edit/deletion of a duty

Creation of a duty, we create a duty and check if it is saved successfully

describe '#create' do

Checking if the right page is rendered after successful creation of a duty

context 'when new duty can be saved successfully' do
it 'sets up a new duty and redirects to assignment#edit page' do
allow(duty).to receive(:save).and_return('OK')
params = {
id: 1,
duty: {
duty_name: 'Scrum Master',
max_members_for_duty: 2,
assignment_id: 1
}
}
post :create, params
expect(response).to redirect_to('/assignments/1/edit')
expect(flash[:notice]).to match(/Role was successfully created.*/)
end
end

Test to check if the right error message is shown if the creation of duty is failed

context 'when new duty cannot be saved successfully' do
it 'shows error message and redirects to duty#new page' do
allow(duty).to receive(:errors)
params = {
id: 1,
duty: {
duty_name: 'Scrum Master',
max_members_for_duty: -1,
assignment_id: 1
}
}
post :create, params
expect(flash[:error]).to eq('Max members for duty must be greater than or equal to 1. ')
expect(response).to redirect_to('/duties/new?id=1')
end
end
end

Test to check the edit functionality of a duty

describe '#update' do

When the duty can be edited successfully, we check if the right page is rendered

context 'when duty can be found' do
it 'updates current duty and redirects to assignment#edit page' do
allow(Duty).to receive(:find).with('1').and_return(build(:duty, id: 1))
params = {
id: 1,
assignment_id: 1,
duty: {
duty_name: 'Scrum Master',
max_members_for_duty: 5,
assignment_id: 1
}
}
post :update, params
expect(response).to redirect_to('/assignments/1/edit')
expect(flash[:notice]).to match(/Role was successfully updated.*/)
end
end

When the duty cannot be updated, we check if the right error message is displayed

context 'when new duty cannot be updated successfully' do
it 'shows error message and redirects to duty#new page' do
allow(duty).to receive(:errors)
params = {
id: 1,
duty: {
duty_name: 'SM',
max_members_for_duty: 1,
assignment_id: 1
}
}
post :create, params
expect(flash[:error]).to eq('Duty name is too short (minimum is 3 characters). ')
expect(response).to redirect_to('/duties/new?id=1')
end
end
end

Now finally, we test the delete functionality of the duty

describe '#destroy' do
context 'when duty can be found' do
it 'redirects to assignment#edit page' do
params = {id: 1, assignment_id: 1}
post :destroy, params
expect(response).to redirect_to('/assignments/1/edit')
expect(flash[:notice]).to match(/Role was successfully destroyed.*/)
end
end
end

== team_users_controller_spec.rb ==

We have added a test case in this file which tests if the action is allowed only by specific user roles

First, we mock the data

''
describe TeamsUsersController do
let(:assignment) do
build(:assignment, id: 1, name: 'test assignment', instructor_id: 6, staggered_deadline: true, directory_path: 'same path',
participants: [build(:participant)], teams: [build(:assignment_team)], course_id: 1)
end
let(:assignment_form) { double('AssignmentForm', assignment: assignment) }
let(:student) { build(:student) }

before(:each) do
allow(Assignment).to receive(:find).with('1').and_return(assignment)
stub_current_user(student, student.role.name, student.role)
end
''

Then we check if the student can perform the update action for duties

''
describe '#action_allowed?' do
context 'when params action is update duties' do
before(:each) do
controller.params = {id: '1', action: 'update_duties'}
end
context 'when the role current user is student' do
it 'allows certain action' do
stub_current_user(student, student.role.name, student.role)
expect(controller.send(:action_allowed?)).to be true
end
end
end
end
''

This file also contains a test case to ensure the duties can be properly updated. The test case checks this by ensuring that the user is redirected to the student view page. just as with the previous section the first step is to mock the data by creating a team user object.

''
let(:teams_user1) {TeamsUser.new id:1, duty_id:1}
''

Then the data is actually updated and we ensure that the user is redirected to the proper place.

''
describe '#update_duties' do
it 'updates the duties for the participant' do
allow(TeamsUser).to receive(:find).with('1').and_return(teams_user1)
allow(teams_user1).to receive(:update_attribute).with(any_args).and_return('OK')
params = {
teams_user_id: '1',
teams_user: {duty_id: '1'},
participant_id: '1'
}
session = {user: stub_current_user(student, student.role.name, student.role)}
get :update_duties, params, session
expect(response).to redirect_to('/student_teams/view?student_id=1')
end
end
''

== assignment_form_spec.rb ==
The assignemnt_form_spec.rb file contains all the test files for the assignment form, which includes adding object to a queue. the first step was to create mock data so that the test could run on objects created for the tests. the code below shows how the mock data was created for the specific tests that we created to ensure the functionality of the projects.
''
let(:new_assignment_questionnaire) { build(:assignment_questionnaire) }
''
The new_assignment_questionnaire object is used for both test cases in this file. the first test case checks for when the active record cannot be found for a specific assignment id or duty id.
''
context 'when active record for assignment_questionnaire is not found for a given assignment_id and duty_id' do
it 'returns new instance of assignment_questionnaire with default values' do
allow(assignment).to receive(:questionnaire_varies_by_duty).and_return(true)
allow(AssignmentQuestionnaire).to receive(:where).with(assignment_id: 1, duty_id: anything).and_return([])
allow(AssignmentQuestionnaire).to receive(:where).with(user_id: anything, assignment_id: nil, questionnaire_id: nil).and_return([])
allow(AssignmentQuestionnaire).to receive(:new).and_return(new_assignment_questionnaire)
expect(assignment_form.assignment_questionnaire('TeammateReviewQuestionnaire', nil, nil, 1)).to eq(new_assignment_questionnaire)
end
end
''
The next next test checks when the assignment questionnaire is found given the assignment id and duty id parameters. this test is very similar to the one where the test is not found because the it searches through the active record to find the assignment questionnaire.
''
context 'when active record for assignment_questionnaire is found for a given assignment_id and duty_id' do
it 'returns new instance of assignment_questionnaire with default values' do
allow(assignment).to receive(:questionnaire_varies_by_duty).and_return(true)
allow(Questionnaire).to receive(:find).with(1).and_return(questionnaire3)
allow(AssignmentQuestionnaire).to receive(:where).with(assignment_id: 1, duty_id: 1).and_return([assignment_questionnaire2])
allow(AssignmentQuestionnaire).to receive(:where).with(user_id: anything, assignment_id: nil, questionnaire_id: nil).and_return([])
allow(AssignmentQuestionnaire).to receive(:new).and_return(new_assignment_questionnaire)
expect(assignment_form.assignment_questionnaire('TeammateReviewQuestionnaire', nil, nil, 1)).to eq(assignment_questionnaire2)
end
end
''

== duty_spec.rb ==
the main purpose of the duty_spec.rb file is to test any duty to make sure a duty can be assigned to a team member. it also tests if a duty is unavailable to a team member because the max number of people have been assigned that duty. to test this functionality the mock data is created to allow for testing of the objcect.
''
let(:assignment) { build(:assignment, id: 1, name: 'no assgt') }
let(:participant) { build(:participant, id:1, user_id: 1) }
let(:participant2) { build(:participant, id:2, user_id: 2) }
let(:participant3) { build(:participant, id:3, user_id: 3) }
let(:user) { build(:student, id: 1, name: 'no name', fullname: 'no one', participants: [participant]) }
let(:user2) { build(:student, id: 2, name: 'no name2', fullname: 'no one2', participants: [participant2]) }
let(:user3) { build(:student, id: 3, name: 'no name3', fullname: 'no one3', participants: [participant3]) }

let(:team1) { build(:assignment_team, id: 1, name: 'no team', users: [user, user2, user3]) }
let(:sample_duty_taken) { build(:duty, id: 1, max_members_for_duty:1, assignment_id:1) }
let(:sample_duty_not_taken) { build(:duty, id: 1, max_members_for_duty:2, assignment_id:1) }

let(:team_user1) { build(:team_user, id: 1, user: user) }
let(:team_user2) { build(:team_user, id: 2, user: user2) }
let(:team_user3) { build(:team_user, id: 3, user: user3, duty_id:1) }
''
an assignment is created on which the duties can be tested. for the testing multiple users and participants are created. Finally we created team users that could be assigned duties through the duty_id field. the next step was to set up the reoccurring steps for each of the tests.
''
before(:each) do
allow(team1).to receive(:participants).and_return([participant, participant2, participant3])
allow(participant).to receive(:get_team_user).and_return(team_user1)
allow(participant2).to receive(:get_team_user).and_return(team_user2)
allow(participant3).to receive(:get_team_user).and_return(team_user3)
end
''

== teammate_review_response_map_spec.rb ==

== duties_controller_test.rb ==

== Manual Testing in Expertiza UI ==
Here we describe manual UI Testing steps to edit an existing assignment to allow it have to specialized rubrics for different topic types. These steps are also shown in recorded demo video.
*Login to Expertiza using instructor account (For testing, username: '''instructor6''', password: '''password''')
*Click on Manage > Assignments
*Click on Edit option for any assignment, you should get following view. Make sure '''Has topics?''' box is checked.
[[File:Assignment edit 3.png]]
*Click on Rubrics tab. You will see 2 checkboxes ('''Review rubric varies by round?''', '''Review rubric varies by topic?''')
*Check the box for '''Review rubric varies by topic?'''
*Go to Topics tab and verify that there is dropdown menu beside each Topic.
*Select a rubric from dropdown menu, and click '''Save'''
[[File:Topics rubric 2.png]]
*Go back to Home, and select the same assignment to edit. When you click on Topics tab, you should see the rubric you had selected.

==Team Information==
* Naman Shrimali
* Kanchan Rawat
* Subodh Thota
* Andrew Shipman
Mentor : Prof. Edward F. Gehringer

CSC/ECE 517 Fall 2021 - E2161. Merge code for role based reviewing with code for topic specific rubrics

2021-11-28T04:33:41Z

Ajshipma: /* duty_spec.rb */

This wiki page contains description of changes designed and implemented for [https://docs.google.com/document/d/1slx4HPIbgTH-psIKMSCF-HDF9brxf-FuYhzVT9ZiIrM/edit#heading=h.8s6o9jnnxj0p E2161. Merge code for role-based reviewing with code for topic-specific rubrics], a Final Project for CSC/ECE 517, Fall 2021.
== Purpose==
In CSC/ECE 517, there are Expertiza-based course projects, Mozilla-based course projects, etc. However, currently, we can only specify one kind of rubric for all kinds of course projects. This means that refactoring projects, testing projects, and Mozilla projects need to use the same rubric. We hope we could specify different rubrics to be used with different kinds of course projects.

The project objective is to merge E2147-https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2147._Role-based_reviewing#E2147._Role-based_reviewing with the existing E2026-https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2020_-_E2026._Specialized_rubrics_for_different_topic_types. While merging, we found out that the code for E2026 has already been merged on Expertiza beta branch and so now the actual implementation is to write test cases for both E2147 and E2026.

==Brief Overview of E2147 and E2026 Projects==
*E2147(Role based reviewing): The project objective was to develop teammate review varying by the roles that each team member has in order to evaluate the particular role that each team member has taken rather than asking a generic questionnaire which was same for all the team members previously. For eg, the instructor would create a separate teammate questionnaire for developer role and for tester role respectively.
*E2026(Specialized rubrics for different topics): The project objective was to develop specialized rubrics based on project topics, previously we had same type of questionnaire for all the different types of projects. This implementation made sure that we evaluate different projects based on personalised rubrics rather than having same rubrics.

==Testing Plan==

===Test Scenarios for E2147(Role based reviewing)===
*Only Instructor/TA/Admin should be able to create or update duties: Only the instructor/admin should be able to create or update duties. Also, the corresponding TA of the assignment should be able to create or update duties.
*Create new roles: If the assignment is role based reviewing then the instructor should be able to create new roles for the same and save it in the database using new role functionality.
*Only allow student to update duties in Student View: Only student should be able to update his duties in Student View.
*Edit existing roles: Once the new roles have been created, then the instructor should be able to edit its details such as the maximum number of each role allowed.
*Delete existing roles: The instructor should also be able to delete any roles if he wants.
*Review rubric by role: On Rubrics tab, if the instructor clicks on Review rubric by role, then the corresponding rubric roles based teammate questionnaire should appear and get saved successfully.
*Student View: If the assignment is role based assignment, then the respective students should be able to see the respective teammate questionnaire based on roles for his other team members.
*Selection of Roles: On student login, a student should be able to see the existing roles that he can take up in the project. Only the roles which are available should be shown to the student.

===Test Scenarios for E2026(Specialized rubrics for different topics)===

As part of our implementation, we modified existing code as well as added new code. To ensure that existing functionality was not broken, and new functionality worked as expected, we used the following Test Strategy (which was also used by previous team):

===Run and pass existing RSpec Tests===
*The following existing RSpec test files have been modified and they pass as part of testing:
**spec/controllers/assignments_controller_spec.rb
**spec/controllers/questionnaires_controller_spec.rb
**spec/controllers/response_controller_spec.rb
**spec/factories/factories.rb
**spec/features/assignment_creation_spec.rb
**spec/features/quiz_spec.rb
**spec/features/staggered_deadline_spec.rb
**spec/models/assignment_form_spec.rb
**spec/models/assignment_spec.rb
**spec/models/on_the_fly_calc_spec.rb
**spec/models/response_spec.rb
**spec/models/review_response_map_spec.rb

===Develop New RSpec Tests===
*spec/helpers/duties_controller_spec.rb
*All these rspec tests passed.

== duties_controller_spec.rb ==
We have created this new test file to unit test the duties scenarios.

First we mock the data accordingly as needed by the tests.

''
describe DutiesController do
let(:assignment) { build(:assignment, id: 1,course_id: 1,instructor_id: 6, due_dates: [due_date], microtask: true, staggered_deadline: true)}
let(:admin) { build(:admin) }
let(:instructor) { build(:instructor, id: 6) }
let(:instructor2) { build(:instructor, id: 66) }
let(:ta) { build(:teaching_assistant, id: 8) }
let(:duty) { build(:duty, id: 1, duty_name: "Role", max_members_for_duty: 2, assignment_id: 1) }
let(:due_date) { build(:assignment_due_date, deadline_type_id: 1) } ''

We then run the arbitrary code that is needed before each test

''
before(:each) do
allow(Assignment).to receive(:find).with('1').and_return(assignment)
allow(Assignment).to receive(:find).with(1).and_return(assignment)
stub_current_user(instructor, instructor.role.name, instructor.role)
allow(Duty).to receive(:find).with('1').and_return(duty)
end
''

Test scenarios for duties controller:
1) Only admin, superadmin, TA, Instructor can perform edit or update action

'' describe '#action_allowed?' do ''

The whole context that defines if the action allowed is edit or update. We do this by mocking the action to edit

context 'when params action is edit or update' do
before(:each) do
controller.params = {id: '1', action: 'edit'}
end

When the current logged in user role is super admin or admin

context 'when the role name of current user is super admin or admin' do
it 'allows certain action' do
stub_current_user(admin, admin.role.name, admin.role)
expect(controller.send(:action_allowed?)).to be true
end
end

When the current logged in user role is instructor

context 'when current user is the instructor of current assignment' do
it 'allows certain action' do
expect(controller.send(:action_allowed?)).to be true
end
end

When the current logged in user role is the TA of the course

context 'when current user is the ta of the course which current assignment belongs to' do
it 'allows certain action' do
stub_current_user(ta, ta.role.name, ta.role)
allow(TaMapping).to receive(:exists?).with(ta_id: 8, course_id: 1).and_return(true)
expect(controller.send(:action_allowed?)).to be true
end
end

When the current logged in user is the instructor of the course

context 'when current user is the instructor of the course which current assignment belongs to' do
it 'allows certain action' do
stub_current_user(instructor2, instructor2.role.name, instructor2.role)
allow(Course).to receive(:find).with(1).and_return(double('Course', instructor_id: 66))
expect(controller.send(:action_allowed?)).to be true
end
end
end

When the parameter action is neither edit nor update, we do this by mocking the action to new

context 'when params action is not edit and update' do
before(:each) do
controller.params = {id: '1', action: 'new'}
end

We now check if super admin/admin/instructor/ta can perform this action which is neither edit nor update

context 'when the role current user is super admin/admin/instructor/ta' do
it 'allows certain action except edit and update' do
expect(controller.send(:action_allowed?)).to be true
end
end
end
end

And then we added few tests to test creation/edit/deletion of a duty

Creation of a duty, we create a duty and check if it is saved successfully

describe '#create' do

Checking if the right page is rendered after successful creation of a duty

context 'when new duty can be saved successfully' do
it 'sets up a new duty and redirects to assignment#edit page' do
allow(duty).to receive(:save).and_return('OK')
params = {
id: 1,
duty: {
duty_name: 'Scrum Master',
max_members_for_duty: 2,
assignment_id: 1
}
}
post :create, params
expect(response).to redirect_to('/assignments/1/edit')
expect(flash[:notice]).to match(/Role was successfully created.*/)
end
end

Test to check if the right error message is shown if the creation of duty is failed

context 'when new duty cannot be saved successfully' do
it 'shows error message and redirects to duty#new page' do
allow(duty).to receive(:errors)
params = {
id: 1,
duty: {
duty_name: 'Scrum Master',
max_members_for_duty: -1,
assignment_id: 1
}
}
post :create, params
expect(flash[:error]).to eq('Max members for duty must be greater than or equal to 1. ')
expect(response).to redirect_to('/duties/new?id=1')
end
end
end

Test to check the edit functionality of a duty

describe '#update' do

When the duty can be edited successfully, we check if the right page is rendered

context 'when duty can be found' do
it 'updates current duty and redirects to assignment#edit page' do
allow(Duty).to receive(:find).with('1').and_return(build(:duty, id: 1))
params = {
id: 1,
assignment_id: 1,
duty: {
duty_name: 'Scrum Master',
max_members_for_duty: 5,
assignment_id: 1
}
}
post :update, params
expect(response).to redirect_to('/assignments/1/edit')
expect(flash[:notice]).to match(/Role was successfully updated.*/)
end
end

When the duty cannot be updated, we check if the right error message is displayed

context 'when new duty cannot be updated successfully' do
it 'shows error message and redirects to duty#new page' do
allow(duty).to receive(:errors)
params = {
id: 1,
duty: {
duty_name: 'SM',
max_members_for_duty: 1,
assignment_id: 1
}
}
post :create, params
expect(flash[:error]).to eq('Duty name is too short (minimum is 3 characters). ')
expect(response).to redirect_to('/duties/new?id=1')
end
end
end

Now finally, we test the delete functionality of the duty

describe '#destroy' do
context 'when duty can be found' do
it 'redirects to assignment#edit page' do
params = {id: 1, assignment_id: 1}
post :destroy, params
expect(response).to redirect_to('/assignments/1/edit')
expect(flash[:notice]).to match(/Role was successfully destroyed.*/)
end
end
end

== team_users_controller_spec.rb ==

We have added a test case in this file which tests if the action is allowed only by specific user roles

First, we mock the data

''
describe TeamsUsersController do
let(:assignment) do
build(:assignment, id: 1, name: 'test assignment', instructor_id: 6, staggered_deadline: true, directory_path: 'same path',
participants: [build(:participant)], teams: [build(:assignment_team)], course_id: 1)
end
let(:assignment_form) { double('AssignmentForm', assignment: assignment) }
let(:student) { build(:student) }

before(:each) do
allow(Assignment).to receive(:find).with('1').and_return(assignment)
stub_current_user(student, student.role.name, student.role)
end
''

Then we check if the student can perform the update action for duties

''
describe '#action_allowed?' do
context 'when params action is update duties' do
before(:each) do
controller.params = {id: '1', action: 'update_duties'}
end
context 'when the role current user is student' do
it 'allows certain action' do
stub_current_user(student, student.role.name, student.role)
expect(controller.send(:action_allowed?)).to be true
end
end
end
end
''

This file also contains a test case to ensure the duties can be properly updated. The test case checks this by ensuring that the user is redirected to the student view page. just as with the previous section the first step is to mock the data by creating a team user object.

''
let(:teams_user1) {TeamsUser.new id:1, duty_id:1}
''

Then the data is actually updated and we ensure that the user is redirected to the proper place.

''
describe '#update_duties' do
it 'updates the duties for the participant' do
allow(TeamsUser).to receive(:find).with('1').and_return(teams_user1)
allow(teams_user1).to receive(:update_attribute).with(any_args).and_return('OK')
params = {
teams_user_id: '1',
teams_user: {duty_id: '1'},
participant_id: '1'
}
session = {user: stub_current_user(student, student.role.name, student.role)}
get :update_duties, params, session
expect(response).to redirect_to('/student_teams/view?student_id=1')
end
end
''

== assignment_form_spec.rb ==
The assignemnt_form_spec.rb file contains all the test files for the assignment form, which includes adding object to a queue. the first step was to create mock data so that the test could run on objects created for the tests. the code below shows how the mock data was created for the specific tests that we created to ensure the functionality of the projects.
''
let(:new_assignment_questionnaire) { build(:assignment_questionnaire) }
''
The new_assignment_questionnaire object is used for both test cases in this file. the first test case checks for when the active record cannot be found for a specific assignment id or duty id.
''
context 'when active record for assignment_questionnaire is not found for a given assignment_id and duty_id' do
it 'returns new instance of assignment_questionnaire with default values' do
allow(assignment).to receive(:questionnaire_varies_by_duty).and_return(true)
allow(AssignmentQuestionnaire).to receive(:where).with(assignment_id: 1, duty_id: anything).and_return([])
allow(AssignmentQuestionnaire).to receive(:where).with(user_id: anything, assignment_id: nil, questionnaire_id: nil).and_return([])
allow(AssignmentQuestionnaire).to receive(:new).and_return(new_assignment_questionnaire)
expect(assignment_form.assignment_questionnaire('TeammateReviewQuestionnaire', nil, nil, 1)).to eq(new_assignment_questionnaire)
end
end
''
The next next test checks when the assignment questionnaire is found given the assignment id and duty id parameters. this test is very similar to the one where the test is not found because the it searches through the active record to find the assignment questionnaire.
''
context 'when active record for assignment_questionnaire is found for a given assignment_id and duty_id' do
it 'returns new instance of assignment_questionnaire with default values' do
allow(assignment).to receive(:questionnaire_varies_by_duty).and_return(true)
allow(Questionnaire).to receive(:find).with(1).and_return(questionnaire3)
allow(AssignmentQuestionnaire).to receive(:where).with(assignment_id: 1, duty_id: 1).and_return([assignment_questionnaire2])
allow(AssignmentQuestionnaire).to receive(:where).with(user_id: anything, assignment_id: nil, questionnaire_id: nil).and_return([])
allow(AssignmentQuestionnaire).to receive(:new).and_return(new_assignment_questionnaire)
expect(assignment_form.assignment_questionnaire('TeammateReviewQuestionnaire', nil, nil, 1)).to eq(assignment_questionnaire2)
end
end
''

== duty_spec.rb ==
the main purpose of the duty_spec.rb file is to test any duty to make sure a duty can be assigned to a team member. it also tests if a duty is unavailable to a team member because the max number of people have been assigned that duty. to test this functionality the mock data is created to allow for testing of the objcect.
''
let(:assignment) { build(:assignment, id: 1, name: 'no assgt') }
let(:participant) { build(:participant, id:1, user_id: 1) }
let(:participant2) { build(:participant, id:2, user_id: 2) }
let(:participant3) { build(:participant, id:3, user_id: 3) }
let(:user) { build(:student, id: 1, name: 'no name', fullname: 'no one', participants: [participant]) }
let(:user2) { build(:student, id: 2, name: 'no name2', fullname: 'no one2', participants: [participant2]) }
let(:user3) { build(:student, id: 3, name: 'no name3', fullname: 'no one3', participants: [participant3]) }

let(:team1) { build(:assignment_team, id: 1, name: 'no team', users: [user, user2, user3]) }
let(:sample_duty_taken) { build(:duty, id: 1, max_members_for_duty:1, assignment_id:1) }
let(:sample_duty_not_taken) { build(:duty, id: 1, max_members_for_duty:2, assignment_id:1) }

let(:team_user1) { build(:team_user, id: 1, user: user) }
let(:team_user2) { build(:team_user, id: 2, user: user2) }
let(:team_user3) { build(:team_user, id: 3, user: user3, duty_id:1) }
''
an assignment is created on which the duties can be tested. for the testing multiple users and participants are created. Finally we created team users that could be assigned duties through the duty_id field. the next step was to set up the reoccurring steps for each of the tests.
''
before(:each) do
allow(team1).to receive(:participants).and_return([participant, participant2, participant3])
allow(participant).to receive(:get_team_user).and_return(team_user1)
allow(participant2).to receive(:get_team_user).and_return(team_user2)
allow(participant3).to receive(:get_team_user).and_return(team_user3)
end
''

== teammate_review_response_map_spec.rb ==

== duties_controller_test.rb ==

== Manual Testing in Expertiza UI ==
Here we describe manual UI Testing steps to edit an existing assignment to allow it have to specialized rubrics for different topic types. These steps are also shown in recorded demo video.
*Login to Expertiza using instructor account (For testing, username: '''instructor6''', password: '''password''')
*Click on Manage > Assignments
*Click on Edit option for any assignment, you should get following view. Make sure '''Has topics?''' box is checked.
[[File:Assignment edit 3.png]]
*Click on Rubrics tab. You will see 2 checkboxes ('''Review rubric varies by round?''', '''Review rubric varies by topic?''')
*Check the box for '''Review rubric varies by topic?'''
*Go to Topics tab and verify that there is dropdown menu beside each Topic.
*Select a rubric from dropdown menu, and click '''Save'''
[[File:Topics rubric 2.png]]
*Go back to Home, and select the same assignment to edit. When you click on Topics tab, you should see the rubric you had selected.

==Team Information==
* Naman Shrimali
* Kanchan Rawat
* Subodh Thota
* Andrew Shipman
Mentor : Prof. Edward F. Gehringer

CSC/ECE 517 Fall 2021 - E2161. Merge code for role based reviewing with code for topic specific rubrics

2021-11-28T04:23:17Z

Ajshipma: /* assignment_form_spec.rb */

CSC/ECE 517 Fall 2021 - E2161. Merge code for role based reviewing with code for topic specific rubrics

2021-11-28T04:17:28Z

Ajshipma: /* assignment_form_spec.rb */

CSC/ECE 517 Fall 2021 - E2161. Merge code for role based reviewing with code for topic specific rubrics

2021-11-28T04:16:53Z

Ajshipma: /* assignment_form_spec.rb */

CSC/ECE 517 Fall 2021 - E2161. Merge code for role based reviewing with code for topic specific rubrics

2021-11-28T03:57:52Z

Ajshipma: /* assignment_form_spec.rb */

CSC/ECE 517 Fall 2021 - E2161. Merge code for role based reviewing with code for topic specific rubrics

2021-11-28T03:55:59Z

Ajshipma: /* assignment_form_spec.rb */

CSC/ECE 517 Fall 2021 - E2161. Merge code for role based reviewing with code for topic specific rubrics

2021-11-28T03:55:46Z

Ajshipma: /* assignment_form_spec.rb */

CSC/ECE 517 Fall 2021 - E2161. Merge code for role based reviewing with code for topic specific rubrics

2021-11-28T03:55:29Z

Ajshipma: /* assignment_form_spec.rb */

CSC/ECE 517 Fall 2021 - E2161. Merge code for role based reviewing with code for topic specific rubrics

2021-11-28T03:47:09Z

Ajshipma:

CSC/ECE 517 Fall 2021 - E2161. Merge code for role based reviewing with code for topic specific rubrics

2021-11-28T03:43:39Z

Ajshipma:

CSC/ECE 517 Fall 2021 - E2161. Merge code for role based reviewing with code for topic specific rubrics

2021-11-28T02:54:58Z

Ajshipma:

CSC/ECE 517 Fall 2021 - E2161. Merge code for role based reviewing with code for topic specific rubrics

2021-11-28T02:54:09Z

Ajshipma:

CSC/ECE 517 Fall 2021 - E2161. Merge code for role based reviewing with code for topic specific rubrics

2021-11-28T02:53:33Z

Ajshipma: /* team_users_controller_spec.rb */

CSC/ECE 517 Fall 2021 - E2161. Merge code for role based reviewing with code for topic specific rubrics

2021-11-28T02:48:42Z

Ajshipma:

CSC/ECE 517 Fall 2021 - E2161. Merge code for role based reviewing with code for topic specific rubrics

2021-11-07T22:57:52Z

Ajshipma:

__TOC__

==About Expertiza==
Expertiza is a web application through which students can submit and peer-review learning objects (articles, code, web sites, etc). The Expertiza project is supported by the National Science Foundation.

===Peer Review Information===
Login credentials for peer review.

* Instructor login:
** Username: instructor6
** Password: password

* Student login:
** Username: student4340
** Password: password

==Problem Statement==
In various agile methodologies, such as Scrum, different team members take on different roles, such as architect, facilitator, and implementer. One might want to use a different rubric for evaluating the contribution of members with different roles. Thus, this would not be separate from teammate review, but it would be a specialization of teammate review.

The following tasks were accomplished in this project:

* Created a new database table, model, view, and controller for duties.
* Allow assignments to be marked for role-based reviewing.
* Certain users can add and edit roles for assignments.

Due to naming issues all of the backend components for role-based reviewing are known as duty or duties. When referring to the backend this documentation will refer to them as duty or duties and when referring to frontend components they will be called role or roles.

==About Current Reviewing==
Currently reviewing does not allow students to have different rubrics for an assignment based on their role in the team.

CSC/ECE 517 Fall 2021 - E2161. Merge code for role based reviewing with code for topic specific rubrics

2021-11-07T22:57:31Z

Ajshipma:

__TOC__

==About Expertiza==
Expertiza is a web application through which students can submit and peer-review learning objects (articles, code, web sites, etc). The Expertiza project is supported by the National Science Foundation.

===Peer Review Information===
Login credentials for peer review.

* Instructor login:
** Username: instructor6
** Password: password

* Student login:
** Username: student4340
** Password: password

==Problem Statement==
In various agile methodologies, such as Scrum, different team members take on different roles, such as architect, facilitator, and implementer. One might want to use a different rubric for evaluating the contribution of members with different roles. Thus, this would not be separate from teammate review, but it would be a specialization of teammate review.

The following tasks were accomplished in this project:

* Created a new database table, model, view, and controller for duties.
* Allow assignments to be marked for role-based reviewing.
* Certain users can add and edit roles for assignments.

Due to naming issues all of the backend components for role-based reviewing are known as duty or duties. When referring to the backend this documentation will refer to them as duty or duties and when referring to frontend components they will be called role or roles.

==About Current Reviewing
Currently reviewing does not allow students to have different rubrics for an assignment based on their role in the team.

==

CSC/ECE 517 Fall 2021 - E2161. Merge code for role based reviewing with code for topic specific rubrics

2021-11-07T22:52:06Z

Ajshipma:

CSC/ECE 517 Fall 2021 - E2161. Merge code for role based reviewing with code for topic specific rubrics

2021-11-07T22:51:41Z

Ajshipma:

CSC/ECE 517 Fall 2021 - E2161. Merge code for role based reviewing with code for topic specific rubrics

2021-11-07T22:51:02Z

Ajshipma:

CSC/ECE 517 Fall 2021 - E2161. Merge code for role based reviewing with code for topic specific rubrics

2021-11-07T22:50:13Z

Ajshipma:

CSC/ECE 517 Fall 2021 - E2161. Merge code for role based reviewing with code for topic specific rubrics

2021-11-07T22:24:17Z

Ajshipma:

CSC/ECE 517 Fall 2021 - E2161. Merge code for role based reviewing with code for topic specific rubrics

2021-11-07T22:22:30Z

Ajshipma:

__TOC__

==Problem Statement==

CSC/ECE 517 Fall 2021

2021-11-07T22:21:01Z

Ajshipma:

== OSS Projects ==

* [[CSC/ECE 517 Fall 2021 - E2117. Refactor questionaires_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2128. Refactor student_quizzes_controller.rb & late_policies_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2129. Refactor auth_controller.rb & password_retrieval_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2132. Add tests cases for review mapping helper.rb]]
* [[CSC/ECE 517 Fall 2021 - E2134. Write unit tests for admin_controller.rb and institution_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2138. Auto-generate submission directory names based on assignment]]
* [[CSC/ECE 517 Fall 2021 - E2142. Improve e-mail notifications]]
* [[CSC/ECE 517 Fall 2021 - E2133. Write tests for popup_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2120. Refactor reputation_web_service_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2139. Remove multiple topics at a time]]
* [[CSC/ECE 517 Fall 2021 - E2131. Improve assessment360_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2121. Refactor suggestion_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2122. Refactor impersonate_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2123. Refactor sign_up_sheet_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2126. Refactor account_request_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2124. Refactor review_mapping_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2125. Refactor review_mapping_helper.rb]]
* [[CSC/ECE 517 Fall 2021 - E2127. Refactor teams_controller]]
* [[CSC/ECE 517 Fall 2021 - E2130. Refactor submitted_content_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2140. Create new late policy successfully and fix Bank link]]
* [[CSC/ECE 517 Fall 2021 - E2141. OSS project Finklestein: Instructors & Institutions]]
* [[CSC/ECE 517 Fall 2021 - E2144. Refactor delayed mailer and scheduled task]]
* [[CSC/ECE 517 Fall 2021 - E2147. Role-based reviewing]]
* [[CSC/ECE 517 Fall 2021 - E2145. OSS Project Beige]]
* [[CSC/ECE 517 Fall 2021 - E2146. Introduce a Student View for instructors]]
* [[CSC/ECE 517 Fall 2021 - Refactor Evaluation of SQL Queries]]
* [[CSC/ECE 517 Fall 2021 - E2135. Email notification to reviewers and instructors]]
* [[CSC/ECE 517 Fall 2021 - E2149. Finish Github metrics integration - Reputations]]

== Final Projects ==
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2166._Testing_-_Scoring_%26_Grades#Description_about_project CSC/ECE 517 Fall 2021 - E2166. Testing - Scoring_and_Grades]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2150._Integrate_suggestion_detection_algorithm#Description_about_project CSC/ECE 517 Fall 2021 - E2150. Integrate suggestion detection algorithm]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2151._Allow_reviewers_to_bid_on_what_to_review CSC/ECE 517 Fall 2021 - E2151. Allow reviewers to bid on what to review]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2152._Revision_planning_tool#Description_about_project CSC/ECE 517 Fall 2021 - E2152. Revision_planning_tool]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2170._Testing_-_Response_Maps#Description_about_project CSC/ECE 517 Fall 2021 - E2170. Testing - Response Maps]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2153._Improving_search_facility_in_Expertiza#Description_about_project CSC/ECE 517 Fall 2021 - E2153. Improving search facility in Expertiza]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2162._Further_refactoring_and_improvement_of_review_mapping_helper CSC/ECE 517 Fall 2021 - E2162. Further refactoring and improvement of review mapping helper]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2163._Refactor_waitlist_functionality CSC/ECE 517 Fall 2021 - E2163. Refactor waitlist functionality]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2165._Fix_teammate-review_view CSC/ECE 517 Fall 2021 - E2165. Fix teammate review view ]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2155._Calibration_submissions_should_be_copied_along_with_calibration_assignments CSC/ECE 517 Fall 2021 - E2155. Calibration submissions should be copied along with calibration assignments]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2148._Completion/Progress_View CSC/ECE 517 Fall 2021 - E2148. Completion/Progress view]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2158._Grading_audit_trail CSC/ECE 517 Fall 2021 - E2158. Grading audit trail ]
*[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2159._Expertiza_internationalization CSC/ECE 517 Fall 2021 - E2159. Expertiza internationalization]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2160._Implementing_and_testing_import_export_controllers#Description_about_project CSC/ECE 517 Fall 2021 - E2160. Implementing and testing import and export controllers]
*[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2161._Merge_code_for_role_based_reviewing_with_code_for_topic_specific_rubrics CSC/ECE 517 Fall 2021 - E2161. Merge code for role based reviewing with code for topic specific rubrics]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2164._Heatgrid_fixes_and_improvements#Description_about_project CSC/ECE 517 Fall 2021 - E2164. Heatgrid fixes and improvements]
* [[CSC/ECE 517 Fall 2021 - E2168. Testing - Reputations]]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2126._Testing_-_Team_Related_Files#Description_about_project CSC/ECE 517 Fall 2021 - E2126. Testing - Team Related Files]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2156._Issues_related_to_meta-reviewing#Description_about_project CSC/ECE 517 Fall 2021 - E2156. Issues related to meta-reviewing]
* [[CSC/ECE 517 Fall 2021 - E2169. Testing - Answer Tagging]]
* [[E2157. Fix issues related to deadlines and late policies]]

CSC/ECE 517 Fall 2021 - E2161. Merge code for role based reviewing with code for topic specific rubrics

2021-11-07T22:18:05Z

Ajshipma: Created page with "Problem Statement"

Problem Statement

CSC/ECE 517 Fall 2021 - Refactor Evaluation of SQL Queries

2021-10-27T00:56:36Z

Ajshipma:

__TOC__

===About SQL File Evaluation===

SQL File Evaluation is a program developed by DR. Paul Wagner to help with the grading of SQL exams given to students in a database systems class. The program parses through tests given to the students and compares their answer queries to the correct answers for the questions. This tool allows the professor to have tests graded in a matter of seconds that could traditionally take hours to grade. When the software is started it provides a GUI with options to connect to either an Oracle or MySQL database to run the answers against and grade the tests. Instructions must create their own assignment properties files which allows them to distribute points accordingly. Once all the inputs have been entered the software will run all of the tests answers, giving points according to the instructor's assignment properties file and produces an output file for each test as well as an overall summary file that tracks all of the students grades.

[[File:SQLFESS.png|600px]]

===Project Goal===
The goal of this project was to refactor the code of the back end of the software to improve clarity and readability. the main focus was on the refactoring of the evaluate method, which was part of the BackEnd class. The original version of the evaluate method was almost 200 lines of code and involved many different processes. Dr. Wagner said the method started out as a few lines but as the code evolved, it grew much larger and needed to be refactored. Our plan for the refactoring of the code involved a few key tasks which were:
*Breaking up sections of code that were focusing on the same task into separate methods
*Create checking functions for conditionals that contained a lot of ANDs and ORs
*Change names of variables that are only a single letter or a few letters to more descriptive names
*Add comments to describe what every section of code is doing
*Add comments to methods we created to state their purpose and keep the same styling.
*Ensure all code complies with SOLID principles
Following the refactoring, we also created junit tests to ensure the code was still working with the changes we had made to the code. The testing ensured the proper files were created as well as that all the necessary files were created. additionally the testing checks the summary file and compares it to a summary file that is known to be correct to ensure the summary (and all of the files within it are created properly.

===Refactoring===

===Testing===
Testing was a necessary step in working on the open source software because when we received the code it was working and we needed to ensure it still worked after we made the changes in refactoring. Java has a testing frame work called junit that allowed us to create unit tests and verify the code worked. we implemented these tests on the the Backend method, which was the section of code that we refactored.

The first step in creating the test was to set up both a front and and a back end object so the code was able to run. This allowed for the tests to emulate the program when it was actually running. We manually set up all of the information needed for the code to connect to the the proper MySQL database so it could grade the exams. The code below shows how the unit test was set up to begin testing the back end class. The JFXPanel is needed to make sure the test runs properly as if a user was using the software. At the end of the code the evaluate method is called which is what we refactored.
<pre>
class BackEndTests extends AbstractTest {

@Test
void test() {
try {
// initialize jfx for test to run
JFXPanel fxPanel = new JFXPanel();

// set default values for testing an input
// values will need to be changed for information used in personal testing database
String dbmsChoice = "MySQL 8.0";
String dbmsHost = "localhost";
String dbmsPort = "3306";
String dbmsSystemID = "evaltest";
String dbmsUsername = "root";
String dbmsPassword = "****";
String evaluationFolder = "C:\\Users\\andrewshipman\\eclipse-workspace\\SQLFE_project";
String assignPropFile = "assignmentProperties-MySQL";
FrontEnd f = new FrontEnd();

// set values for the front end used for testing
f.setDbmsChoice(dbmsChoice);
f.setDbmsHost(dbmsHost);
f.setDbmsPort(dbmsPort);
f.setDbmsSystemID(dbmsSystemID);
f.setDbmsUsername(dbmsUsername);
f.setDbmsPassword(dbmsPassword);
f.setEvaluationFolder(evaluationFolder);
f.setAssignPropFile(assignPropFile);

// setup back end and run evaluation
BackEnd b = new BackEnd(f);
f.setABackEnd(b);
b.transferData(f);
b.evaluate();
</Pre>

After the evaluate method is completed the testing is ready to begin to validate that the evaluate method did its job correctly. This is done in a few ways. The first way is that the program checks to make sure the summary file was created. This provides proof that the evaluate method at least ran and tried to create something. the code for this test is fairly simple:
<pre>
// test if output file was created
File testFile = new File(f.getEvaluationFolder() + "\\evaluations\\AAA_grade_summary.out");
assertTrue(testFile.exists());
</pre>
The next test checks to see that the program created the proper number of output files. This should be 1 for each exam that was submitted into the files folder for evaluation plus an additional 3 files one for the summary, one for any problems that were found in the parser, and one containing the student comments. The code for this test is:
<pre>
// test if there is the proper number of files
File inputFiles = new File(f.getEvaluationFolder() + "\\files");
File outputFiles = new File(f.getEvaluationFolder() + "\\Evaluations");
assertEquals(inputFiles.list().length, (outputFiles.list().length - 3));
</pre>
The final test checked the output summary of the program against a file that was known to be correct for the first 5 sample files that came with the java code. This test used an API for comparing the contents of 2 files to see if they are the same or different. The correct file is located in another folder in the project called TestingFiles. The code for this test is below:
<pre>
// test if grade summary output is correct for 5 files
// uses file in testing file to assert output is correct for 5 evaluations
File compareFile = new File(f.getEvaluationFolder() + "\\TestingFiles\\Correct_5_evals_summary.out");
assertTrue(FileUtils.contentEquals(testFile, compareFile));
</pre>
all of the tests passed along with manual testing and checking of all 66 sample files included with the project. This meant our refactoring achieved the same goal of the original program.

===Usage===
The software can be downloaded either as an executable or as a the source code which can be run through Java Eclipse or Intelij IDE. The documentation on how to download and run the program be found in the docs folder on the github repository.

CSC/ECE 517 Fall 2021 - Refactor Evaluation of SQL Queries

2021-10-27T00:56:12Z

Ajshipma:

CSC/ECE 517 Fall 2021 - Refactor Evaluation of SQL Queries

2021-10-27T00:25:25Z

Ajshipma:

__TOC__

===About SQL File Evaluation===

SQL File Evaluation is a program developed by DR. Paul Wagner to help with the grading of SQL exams given to students in a database systems class. The program parses through tests given to the students and compares their answer queries to the correct answers for the questions. This tool allows the professor to have tests graded in a matter of seconds that could traditionally take hours to grade. When the software is started it provides a GUI with options to connect to either an Oracle or MySQL database to run the answers against and grade the tests. Instructions must create their own assignment properties files which allows them to distribute points accordingly. Once all the inputs have been entered the software will run all of the tests answers, giving points according to the instructor's assignment properties file and produces an output file for each test as well as an overall summary file that tracks all of the students grades.

[[File:SQLFESS.png|600px]]

===Project Goal===
The goal of this project was to refactor the code of the back end of the software to improve clarity and readability. the main focus was on the refactoring of the evaluate method, which was part of the BackEnd class. The original version of the evaluate method was almost 200 lines of code and involved many different processes. Dr. Wagner said the method started out as a few lines but as the code evolved, it grew much larger and needed to be refactored. Our plan for the refactoring of the code involved a few key tasks which were:
*Breaking up sections of code that were focusing on the same task into separate methods
*Create checking functions for conditionals that contained a lot of ANDs and ORs
*Change names of variables that are only a single letter or a few letters to more descriptive names
*Add comments to describe what every section of code is doing
*Add comments to methods we created to state their purpose and keep the same styling.
*Ensure all code complies with SOLID principles
Following the refactoring, we also created junit tests to ensure the code was still working with the changes we had made to the code. The testing ensured the proper files were created as well as that all the necessary files were created. additionally the testing checks the summary file and compares it to a summary file that is known to be correct to ensure the summary (and all of the files within it are created properly.

===Refactoring===

===Testing===
Testing was a necessary step in working on the open source software because when we received the code it was working and we needed to ensure it still worked after we made the changes in refactoring. Java has a testing frame work called junit that allowed us to create unit tests and verify the code worked. we implemented these tests on the the Backend method, which was the section of code that we refactored.

The first step in creating the test was to set up both a front and and a back end object so the code was able to run. This allowed for the tests to emulate the program when it was actually running. We manually set up all of the information needed for the code to connect to the the proper MySQL database so it could grade the exams. The code below shows how the unit test was set up to begin testing the back end class. The JFXPanel is needed to make sure the test runs properly as if a user was using the software. At the end of the code the evaluate method is called which is what we refactored.
<pre>
class BackEndTests extends AbstractTest {

@Test
void test() {
try {
// initialize jfx for test to run
JFXPanel fxPanel = new JFXPanel();

// set default values for testing an input
// values will need to be changed for information used in personal testing database
String dbmsChoice = "MySQL 8.0";
String dbmsHost = "localhost";
String dbmsPort = "3306";
String dbmsSystemID = "evaltest";
String dbmsUsername = "root";
String dbmsPassword = "****";
String evaluationFolder = "C:\\Users\\andrewshipman\\eclipse-workspace\\SQLFE_project";
String assignPropFile = "assignmentProperties-MySQL";
FrontEnd f = new FrontEnd();

// set values for the front end used for testing
f.setDbmsChoice(dbmsChoice);
f.setDbmsHost(dbmsHost);
f.setDbmsPort(dbmsPort);
f.setDbmsSystemID(dbmsSystemID);
f.setDbmsUsername(dbmsUsername);
f.setDbmsPassword(dbmsPassword);
f.setEvaluationFolder(evaluationFolder);
f.setAssignPropFile(assignPropFile);

// setup back end and run evaluation
BackEnd b = new BackEnd(f);
f.setABackEnd(b);
b.transferData(f);
b.evaluate();
</Pre>

After the evaluate method is completed the testing is ready to begin to validate that the evaluate method did its job correctly. This is done in a few ways. The first way is that the program checks to make sure the summary file was created. This provides proof that the evaluate method at least ran and tried to create something. the code for this test is fairly simple:
<pre>
// test if output file was created
File testFile = new File(f.getEvaluationFolder() + "\\evaluations\\AAA_grade_summary.out");
assertTrue(testFile.exists());
</pre>
The next test checks to see that the program created the proper number of output files. This should be 1 for each exam that was submitted into the files folder for evaluation plus an additional 3 files one for the summary, one for any problems that were found in the parser, and one containing the student comments. The code for this test is:
<pre>
// test if there is the proper number of files
File inputFiles = new File(f.getEvaluationFolder() + "\\files");
File outputFiles = new File(f.getEvaluationFolder() + "\\Evaluations");
assertEquals(inputFiles.list().length, (outputFiles.list().length - 3));
</pre>
The final test checked the output summary of the program against a file that was known to be correct for the first 5 sample files that came with the java code. This test used an API for comparing the contents of 2 files to see if they are the same or different. The correct file is located in another folder in the project called TestingFiles. The code for this test is below:
<pre>
// test if grade summary output is correct for 5 files
// uses file in testing file to assert output is correct for 5 evaluations
File compareFile = new File(f.getEvaluationFolder() + "\\TestingFiles\\Correct_5_evals_summary.out");
assertTrue(FileUtils.contentEquals(testFile, compareFile));
</pre>
all of the tests passed along with manual testing and checking of all 66 sample files included with the project. This meant our refactoring achieved the same goal of the original program.

===Usage===
The software can be downloaded either as an executable or as a the source code which can be run through Java Eclipse or Intelij IDE. Below is the documentation on how to download and run the software.

CSC/ECE 517 Fall 2021 - Refactor Evaluation of SQL Queries

2021-10-26T23:41:33Z

Ajshipma: