Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Spring 2022 - E2242. Fix teammate-review view

2022-04-11T22:28:34Z

Sbansal6: /* Design Patterns */

==Problem Statement==
After the deadline to submit a project is crossed and the work is reviewed, both students and instructors can view teammate reviews. Students view them from the heatgrid at the bottom of the “Your scores” page. Instructors view them from “View scores”, then clicking on a particular team, then clicking on the Teammate Reviews tab. In both cases, a single heatgrid is shown. It is not clear if the heatgrid shows the reviews that the student has given to his/her teammates or the reviews that the student has received from his/her teammates?

For instructors, the problem is compounded. Instructors can choose from a list of students in the team, but there is no way to tell whether the heatgrid shows the reviews done by or done for the selected team member. Also, there's no checkbox/option for the instructor to allow/disallow students to check the reviews received from their teammates, for their contribution to the project.

==Explanation of Feature==

===Existing functionality of teammate-review view===
Used login details from factories.rb and logged in as an instructor and student to retrieve corresponding views. 
 
'''1. Instructor's view of teammate review''': As we can see below, under the Teammate Reviews tab, the heatgrid for student 7185 doesn't clearly state if it is a review given by the student 7185 or is it the review score received by the student 7185.
 
[[File:old_instructor.png|700px]]

 
'''2. Student's view of teammate review''': As we can see below, the student's view of your scores doesn't show the teammate reviews. We need to implement the feature by invoking the pre-existing code for displaying a heatgrid, so that a student will be able to view the teammate reviews.
 

[[File:old_student.jpg|700px]]
 

===Changes to be made to teammate-review view===

1. Distinguish reviews done for a student by rendering separate heat grids for each student. Both reviews by the student and reviews of the student’s contribution should be shown separately.

2. Include a checkbox(Show teammate reviews?) on the edit assignment page, so that instructor can enable/disable visibility of heat grid to students.

[[File:Show_teammate_reviews.png|700px]]

3. In addition to the individual reviews, show a composite score derived from all reviews. The code should invoke the pre-existing code for displaying a heat grid, so other kinds of heat grid views could use it.

4. The code must also be cognizant that the display may be in an anonymized view, where no names are to be shown, but only “Student nnn”, “Instructor mmm”, etc.

=== Code changes ===

The following files will be changed to fulfill the requirements

'''Controllers''':
*app/controllers/grades_controller.rb
*app/helpers/grades_helper.rb
*app/controllers/assignments_controller.rb

'''Models''':
*app/models/vm_question_response_score_cell.rb
*app/models/vm_question_response.rb
*app/models/assignment_form.rb
*app/models/assignment.rb

'''Views''':
*app/views/grades/_view_heatgrid.html.erb
*app/views/grades/view_team.html.erb
*app/views/assignments/new.html.erb

'''Rspec''':
*spec/controllers/grades_controller_spec.rb
*spec/helpers/grades_helper_spec.rb
*spec/models/assignment_spec.rb
*spec/models/assignment_form_spec.rb
*spec/features/assignment_creation_page_spec.rb

'''Refactor Code to follow good coding practices''' 
Example: 
# Rename method names more meaningfully and intuitive.
# Add comments to the existing functions.

===Use Case Diagram===
For the view_team page of Expertiza the actors are instructor and student. Use cases are to access view_team page and to view teammate reviews of all students in a team for the instructor. Whereas, the use case for student is to access view_team page and to view teammate reviews for themselves subject to the condition that the instructor allows it.

[[File:Use_case_diagram_teammate_review_view.png|700px]]

==Design Patterns==
The task is to fix the teammate_review view and requires changes to be made to an existing view associated with the user interface of Expertaza. Though we will be following the DRY principle when making the changes, there is no design pattern itself present in the teammate_review view.

==User Stories==
# As a student, I can view the reviews given to me by my teammates.
# As an instructor, I can view the reviews a student has given to their teammates.
# As an instructor, I can choose to view only one student's teammate reviews or to view all students' teammate reviews together.
# As an instructor, I can view the name of the reviewers for a student's reviews.
# As a student and a TA for another subject, I cannot view an instructor's view to the view_team page.

== Testing ==
=== Video Demonstration ===
''will be added for the final submission''
=== Testing Goals and Test Objects ===

''Drawing from the project objectives:''
# Verify that reviews by the student and reviews of the student’s contribution are shown.
# Verify that instructor can uncheck the “Show teammate reviews?” checkbox to disallow students to see teammate reviews.
# Verify that instructor can check the “Show teammate reviews?” checkbox to allow students to see teammate reviews.
# Verify the composite score derived from all individual reviews in a heat grid.
# Ensure that no names of students or instructors are shown in the anonymized view.
# Increase the test coverage for grades controller by adding Rspec unit tests.

=== RSpec Unit Tests ===
'''''Test cases provided here, will add RSpec code blocks for the final submission'''''
*Student Account or Instructor acting as a student
<pre>
Scenario: Choose to view "Your scores"
Given: the user is logged in as a student or instructor acting as a student
And: “Show teammate reviews?” is allowed by instructor
When: user clicks on "your scores" link in student task page
Then: display heatgrids for student's contribution provided by student's team and heatgrid of peer reviews.
</pre>

*Instructor Account
<pre>
Scenario: Choose to view "View scores"
Given: the user is logged in as an instructor
When: instructor clicks on "view scores" link
Then: can view the reviews a student has given to their teammates without ambiguity
</pre>

<pre>
Scenario: Choose to view "View scores"
Given: the user is logged in as an instructor
When: instructor clicks on "view scores" link
Then: can choose to view only one student's teammate reviews or to view all students' teammate reviews together.
</pre>

'''Grades Controller Rspec to increase test coverage:''' 
Currently the test coverage for grades controller [https://coveralls.io/builds/48139154/source?filename=app%2Fcontrollers%2Fgrades_controller.rb here] is 88.24% on beta branch. We will add testcases to increase the coverage further and also to test the additional functionality that we are going to add.

==Github and Related Link==
The forked git repository for this project can be found [https://github.com/sbansal1097/expertiza.git here].

== Contributors ==
=== Mentor ===
*Naman Shrimali (''nshrima'')

=== Students ===
*Rachana Kondabala(''rkondab'')
*Rahul Shukla (''rshukla3'')
*Shubham Bansal (''sbansal6'')
*Sravanth Reddy Bommana (''sbomman'')

CSC/ECE 517 Spring 2022 - E2242. Fix teammate-review view

2022-04-11T22:17:58Z

Sbansal6: /* Design Patterns */

==Problem Statement==
After the deadline to submit a project is crossed and the work is reviewed, both students and instructors can view teammate reviews. Students view them from the heatgrid at the bottom of the “Your scores” page. Instructors view them from “View scores”, then clicking on a particular team, then clicking on the Teammate Reviews tab. In both cases, a single heatgrid is shown. It is not clear if the heatgrid shows the reviews that the student has given to his/her teammates or the reviews that the student has received from his/her teammates?

For instructors, the problem is compounded. Instructors can choose from a list of students in the team, but there is no way to tell whether the heatgrid shows the reviews done by or done for the selected team member. Also, there's no checkbox/option for the instructor to allow/disallow students to check the reviews received from their teammates, for their contribution to the project.

==Explanation of Feature==

===Existing functionality of teammate-review view===
Used login details from factories.rb and logged in as an instructor and student to retrieve corresponding views. 
 
'''1. Instructor's view of teammate review''': As we can see below, under the Teammate Reviews tab, the heatgrid for student 7185 doesn't clearly state if it is a review given by the student 7185 or is it the review score received by the student 7185.
 
[[File:old_instructor.png|700px]]

 
'''2. Student's view of teammate review''': As we can see below, the student's view of your scores doesn't show the teammate reviews. We need to implement the feature by invoking the pre-existing code for displaying a heatgrid, so that a student will be able to view the teammate reviews.
 

[[File:old_student.jpg|700px]]
 

===Changes to be made to teammate-review view===

1. Distinguish reviews done for a student by rendering separate heat grids for each student. Both reviews by the student and reviews of the student’s contribution should be shown separately.

2. Include a checkbox(Show teammate reviews?) on the edit assignment page, so that instructor can enable/disable visibility of heat grid to students.

[[File:Show_teammate_reviews.png|700px]]

3. In addition to the individual reviews, show a composite score derived from all reviews. The code should invoke the pre-existing code for displaying a heat grid, so other kinds of heat grid views could use it.

4. The code must also be cognizant that the display may be in an anonymized view, where no names are to be shown, but only “Student nnn”, “Instructor mmm”, etc.

=== Code changes ===

The following files will be changed to fulfill the requirements

'''Controllers''':
*app/controllers/grades_controller.rb
*app/helpers/grades_helper.rb
*app/controllers/assignments_controller.rb

'''Models''':
*app/models/vm_question_response_score_cell.rb
*app/models/vm_question_response.rb
*app/models/assignment_form.rb
*app/models/assignment.rb

'''Views''':
*app/views/grades/_view_heatgrid.html.erb
*app/views/grades/view_team.html.erb
*app/views/assignments/new.html.erb

'''Rspec''':
*spec/controllers/grades_controller_spec.rb
*spec/helpers/grades_helper_spec.rb
*spec/models/assignment_spec.rb
*spec/models/assignment_form_spec.rb
*spec/features/assignment_creation_page_spec.rb

'''Refactor Code to follow good coding practices''' 
Example: 
# Rename method names more meaningfully and intuitive.
# Add comments to the existing functions.

===Use Case Diagram===
For the view_team page of Expertiza the actors are instructor and student. Use cases are to access view_team page and to view teammate reviews of all students in a team for the instructor. Whereas, the use case for student is to access view_team page and to view teammate reviews for themselves subject to the condition that the instructor allows it.

[[File:Use_case_diagram_teammate_review_view.png|700px]]

==Design Patterns==
The task is to fix the teammate_review view and requires changes to be made to an existing view. Though we will be following the DRY principle when making the changes, there is no design pattern itself present in the teammate_review view.

==User Stories==
# As a student, I can view the reviews given to me by my teammates.
# As an instructor, I can view the reviews a student has given to their teammates.
# As an instructor, I can choose to view only one student's teammate reviews or to view all students' teammate reviews together.
# As an instructor, I can view the name of the reviewers for a student's reviews.
# As a student and a TA for another subject, I cannot view an instructor's view to the view_team page.

== Testing ==
=== Video Demonstration ===
''will be added for the final submission''
=== Testing Goals and Test Objects ===

''Drawing from the project objectives:''
# Verify that reviews by the student and reviews of the student’s contribution are shown.
# Verify that instructor can uncheck the “Show teammate reviews?” checkbox to disallow students to see teammate reviews.
# Verify that instructor can check the “Show teammate reviews?” checkbox to allow students to see teammate reviews.
# Verify the composite score derived from all individual reviews in a heat grid.
# Ensure that no names of students or instructors are shown in the anonymized view.
# Increase the test coverage for grades controller by adding Rspec unit tests.

=== RSpec Unit Tests ===
'''''Test cases provided here, will add RSpec code blocks for the final submission'''''
*Student Account or Instructor acting as a student
<pre>
Scenario: Choose to view "Your scores"
Given: the user is logged in as a student or instructor acting as a student
And: “Show teammate reviews?” is allowed by instructor
When: user clicks on "your scores" link in student task page
Then: display heatgrids for student's contribution provided by student's team and heatgrid of peer reviews.
</pre>

*Instructor Account
<pre>
Scenario: Choose to view "View scores"
Given: the user is logged in as an instructor
When: instructor clicks on "view scores" link
Then: can view the reviews a student has given to their teammates without ambiguity
</pre>

<pre>
Scenario: Choose to view "View scores"
Given: the user is logged in as an instructor
When: instructor clicks on "view scores" link
Then: can choose to view only one student's teammate reviews or to view all students' teammate reviews together.
</pre>

'''Grades Controller Rspec to increase test coverage:''' 
Currently the test coverage for grades controller [https://coveralls.io/builds/48139154/source?filename=app%2Fcontrollers%2Fgrades_controller.rb here] is 88.24% on beta branch. We will add testcases to increase the coverage further and also to test the additional functionality that we are going to add.

==Github and Related Link==
The forked git repository for this project can be found [https://github.com/sbansal1097/expertiza.git here].

== Contributors ==
=== Mentor ===
*Naman Shrimali (''nshrima'')

=== Students ===
*Rachana Kondabala(''rkondab'')
*Rahul Shukla (''rshukla3'')
*Shubham Bansal (''sbansal6'')
*Sravanth Reddy Bommana (''sbomman'')

CSC/ECE 517 Spring 2022 - E2242. Fix teammate-review view

2022-04-11T22:06:17Z

Sbansal6: /* Use Case Diagram */

==Problem Statement==
After the deadline to submit a project is crossed and the work is reviewed, both students and instructors can view teammate reviews. Students view them from the heatgrid at the bottom of the “Your scores” page. Instructors view them from “View scores”, then clicking on a particular team, then clicking on the Teammate Reviews tab. In both cases, a single heatgrid is shown. It is not clear if the heatgrid shows the reviews that the student has given to his/her teammates or the reviews that the student has received from his/her teammates?

For instructors, the problem is compounded. Instructors can choose from a list of students in the team, but there is no way to tell whether the heatgrid shows the reviews done by or done for the selected team member. Also, there's no checkbox/option for the instructor to allow/disallow students to check the reviews received from their teammates, for their contribution to the project.

==Explanation of Feature==

===Existing functionality of teammate-review view===
Used login details from factories.rb and logged in as an instructor and student to retrieve corresponding views. 
 
'''1. Instructor's view of teammate review''': As we can see below, under the Teammate Reviews tab, the heatgrid for student 7185 doesn't clearly state if it is a review given by the student 7185 or is it the review score received by the student 7185.
 
[[File:old_instructor.png|700px]]

 
'''2. Student's view of teammate review''': As we can see below, the student's view of your scores doesn't show the teammate reviews. We need to implement the feature by invoking the pre-existing code for displaying a heatgrid, so that a student will be able to view the teammate reviews.
 

[[File:old_student.jpg|700px]]
 

===Changes to be made to teammate-review view===

1. Distinguish reviews done for a student by rendering separate heat grids for each student. Both reviews by the student and reviews of the student’s contribution should be shown separately.

2. Include a checkbox(Show teammate reviews?) on the edit assignment page, so that instructor can enable/disable visibility of heat grid to students.

[[File:Show_teammate_reviews.png|700px]]

3. In addition to the individual reviews, show a composite score derived from all reviews. The code should invoke the pre-existing code for displaying a heat grid, so other kinds of heat grid views could use it.

4. The code must also be cognizant that the display may be in an anonymized view, where no names are to be shown, but only “Student nnn”, “Instructor mmm”, etc.

=== Code changes ===

The following files will be changed to fulfill the requirements

'''Controllers''':
*app/controllers/grades_controller.rb
*app/helpers/grades_helper.rb
*app/controllers/assignments_controller.rb

'''Models''':
*app/models/vm_question_response_score_cell.rb
*app/models/vm_question_response.rb
*app/models/assignment_form.rb
*app/models/assignment.rb

'''Views''':
*app/views/grades/_view_heatgrid.html.erb
*app/views/grades/view_team.html.erb
*app/views/assignments/new.html.erb

'''Rspec''':
*spec/controllers/grades_controller_spec.rb
*spec/helpers/grades_helper_spec.rb
*spec/models/assignment_spec.rb
*spec/models/assignment_form_spec.rb
*spec/features/assignment_creation_page_spec.rb

'''Refactor Code to follow good coding practices''' 
Example: 
# Rename method names more meaningfully and intuitive.
# Add comments to the existing functions.

===Use Case Diagram===
For the view_team page of Expertiza the actors are instructor and student. Use cases are to access view_team page and to view teammate reviews of all students in a team for the instructor. Whereas, the use case for student is to access view_team page and to view teammate reviews for themselves subject to the condition that the instructor allows it.

[[File:Use_case_diagram_teammate_review_view.png|700px]]

==Design Patterns==
We will be using Abstract Factory design pattern for our implementation.

==User Stories==
# As a student, I can view the reviews given to me by my teammates.
# As an instructor, I can view the reviews a student has given to their teammates.
# As an instructor, I can choose to view only one student's teammate reviews or to view all students' teammate reviews together.
# As an instructor, I can view the name of the reviewers for a student's reviews.
# As a student and a TA for another subject, I cannot view an instructor's view to the view_team page.

== Testing ==
=== Video Demonstration ===
''will be added for the final submission''
=== Testing Goals and Test Objects ===

''Drawing from the project objectives:''
# Verify that reviews by the student and reviews of the student’s contribution are shown.
# Verify that instructor can uncheck the “Show teammate reviews?” checkbox to disallow students to see teammate reviews.
# Verify that instructor can check the “Show teammate reviews?” checkbox to allow students to see teammate reviews.
# Verify the composite score derived from all individual reviews in a heat grid.
# Ensure that no names of students or instructors are shown in the anonymized view.
# Increase the test coverage for grades controller by adding Rspec unit tests.

=== RSpec Unit Tests ===
'''''Test cases provided here, will add RSpec code blocks for the final submission'''''
*Student Account or Instructor acting as a student
<pre>
Scenario: Choose to view "Your scores"
Given: the user is logged in as a student or instructor acting as a student
And: “Show teammate reviews?” is allowed by instructor
When: user clicks on "your scores" link in student task page
Then: display heatgrids for student's contribution provided by student's team and heatgrid of peer reviews.
</pre>

*Instructor Account
<pre>
Scenario: Choose to view "View scores"
Given: the user is logged in as an instructor
When: instructor clicks on "view scores" link
Then: can view the reviews a student has given to their teammates without ambiguity
</pre>

<pre>
Scenario: Choose to view "View scores"
Given: the user is logged in as an instructor
When: instructor clicks on "view scores" link
Then: can choose to view only one student's teammate reviews or to view all students' teammate reviews together.
</pre>

'''Grades Controller Rspec to increase test coverage:''' 
Currently the test coverage for grades controller [https://coveralls.io/builds/48139154/source?filename=app%2Fcontrollers%2Fgrades_controller.rb here] is 88.24% on beta branch. We will add testcases to increase the coverage further and also to test the additional functionality that we are going to add.

==Github and Related Link==
The forked git repository for this project can be found [https://github.com/sbansal1097/expertiza.git here].

== Contributors ==
=== Mentor ===
*Naman Shrimali (''nshrima'')

=== Students ===
*Rachana Kondabala(''rkondab'')
*Rahul Shukla (''rshukla3'')
*Shubham Bansal (''sbansal6'')
*Sravanth Reddy Bommana (''sbomman'')

CSC/ECE 517 Spring 2022 - E2242. Fix teammate-review view

2022-04-06T04:05:05Z

Sbansal6: /* Testing */

CSC/ECE 517 Spring 2022 - E2242. Fix teammate-review view

2022-04-06T04:03:00Z

Sbansal6: /* User Stories */

CSC/ECE 517 Spring 2022 - E2242. Fix teammate-review view

2022-04-06T03:48:43Z

Sbansal6: /* Design Patterns */

CSC/ECE 517 Spring 2022 - E2242. Fix teammate-review view

2022-04-05T03:45:30Z

Sbansal6:

File:Use case diagram teammate review view.png

2022-04-05T03:39:33Z

Sbansal6:

CSC/ECE 517 Spring 2022 - E2242. Fix teammate-review view

2022-04-05T02:52:15Z

Sbansal6: /* Problem Statement */

CSC/ECE 517 Spring 2022 - E2242. Fix teammate-review view

2022-04-05T02:39:53Z

Sbansal6:

==Problem Statement==

==Explanation of Feature==

===Existing functionality of teammate-review view===

===Desired functionality of teammate-review view===

===Use Case Diagram===

==Design Patterns==

==User Stories==

==Testing==
We will be using RSpec and Capybara for unit and functional testing. UI testing will be done manually.

==Github and Related Link==
The forked git repository for this project can be found [https://github.com/sbansal1097/expertiza.git here].

==Contributors==
'''Mentor:''' Naman Shrimali
* Rachana Kondabala (rkondab)
* Rahul Shukla (rshukla3)
* Shubham Bansal (sbansal6)
* Sravanth Reddy Bommana (sbomman)

CSC/ECE 517 Spring 2022 - E2206: Testing for users controller

2022-03-22T00:44:28Z

Sbansal6: /* Related Links */

== About Expertiza ==

[http://expertiza.ncsu.edu/ Expertiza] is the software benefits for both instructors and students by supporting various types of submissions and providing reusable objects for peer review. It is an open-source project based on [http://rubyonrails.org/ Ruby on Rails] framework. It allows the instructors not only to create and customize new or existing assignments but also to create a list of topics the students can sign up for. Students can form teams to work on various projects and assignments. Expertiza also lets students peer-review other students' submissions, enabling them to work together to improve others' learning experiences.

== Current Project Description ==

This Expertiza OSS project "E2206: Testing for users_controller" is focused on adding unit tests for users_controller.rb.

=== Files Involved ===

* users_controller.rb
* users_controller_spec.rb

=== Running Tests ===

<pre>
rspec ./spec/controllers/users_controller_spec.rb
</pre>

== Testing ==

users_controller had 5 methods for which unit tests were missing as seen in this [https://coveralls.io/builds/46937123/source?filename=app/controllers/users_controller.rb coverall]. The RSpec unit tests added for these methods in the spec file 'users_controller_spec.rb' are discussed below.

=== action_allowed? ===
This method checks if a particular action is allowed when it is called for the current user. The action is passed in the params. In this case we are testing the action list_pending_requested.
We stub a student, an instructor and an admin, and we test if only the admin has the right to perform this action.

<pre>
context '#set_anonymized_view' do
it 'admin list_pending_requested' do
params = { action: 'list_pending_requested' }
allow(controller).to receive(:params).and_return(params)
expect(controller.action_allowed?).to be false
stub_current_user(student7, student7.role.name, student7.role)
allow(controller).to receive(:params).and_return(params)
expect(controller.action_allowed?).to be false
stub_current_user(instructor, instructor.role.name, instructor.role)
allow(controller).to receive(:params).and_return(params)
expect(controller.action_allowed?).to be false
stub_current_user(admin, admin.role.name, admin.role)
allow(controller).to receive(:params).and_return(params)
expect(controller.action_allowed?).to be true
end
end
</pre>

=== auto_complete_for_user_name ===
For auto_complete_for_user_name method there is another method auto_complete_result being called in the controller. This method does not exist, and thus when auto_complete_for_user_name method is called, it raises ActionView::Template::Error. In the first test case, it is being checked if the correct error is being thrown. While, in the second test case the method is being called with a GET request and is expected to redirect us to the home page.
<pre>
context '#auto_complete_for_user_name' do
it 'checks if auto_complete returns actionview error' do
stub_current_user(student1, student1.role.name, student1.role)
session = { user: student1 }
@params = {user: student1}
allow(controller).to receive(:params).and_return(@params)
expect{controller.auto_complete_for_user_name}.to raise_error(ActionView::Template::Error)
end

it 'checks if get auto_complete redirects to test host' do
stub_current_user(student1, student1.role.name, student1.role)
session = { user: student1 }
@params = {user: student1}
allow(controller).to receive(:params).and_return(@params)
get :auto_complete_for_user_name, @params, session
expect(response).to redirect_to("http://test.host/")
end
end
</pre>

=== destroy ===
This action is called in the process of deleting a user. When this action is successfully executed or user is successfully destroyed (when User is passed a valid value 'student1') a note alert is flashed, whereas in case user is not destroyed (when User is passed an invalid value 'nil') an error is flashed. Further, it is being tested that at the end in both cases it redirects to list action.
<pre>
context '#destroy' do
it 'check if user was successfully destroyed' do
allow(User).to receive(:find).with(any_args).and_return(student1)
allow(AssignmentParticipant).to receive(:delete).with(any_args).and_return(true)
allow(TeamsUser).to receive(:delete).with(any_args).and_return(true)
allow(AssignmentQuestionnaire).to receive(:destroy).with(any_args).and_return(true)
allow(User).to receive(:destroy).with(any_args).and_return(true)
post :destroy
expect(flash[:note]).to be_present
end

it 'check if user was not successfully destroyed' do
allow(User).to receive(:find).with(any_args).and_return(nil)
allow(AssignmentParticipant).to receive(:delete).with(any_args).and_return(true)
allow(TeamsUser).to receive(:delete).with(any_args).and_return(true)
allow(AssignmentQuestionnaire).to receive(:destroy).with(any_args).and_return(true)
allow(User).to receive(:destroy).with(any_args).and_return(true)
post :destroy
expect(flash[:error]).to be_present
end

it 'check if successful destroy leads to redirect' do
allow(User).to receive(:find).with(any_args).and_return(student1)
allow(AssignmentParticipant).to receive(:delete).with(any_args).and_return(true)
allow(TeamsUser).to receive(:delete).with(any_args).and_return(true)
allow(AssignmentQuestionnaire).to receive(:destroy).with(any_args).and_return(true)
allow(User).to receive(:destroy).with(any_args).and_return(true)
post :destroy
expect(response).to redirect_to :action=> :list
end

it 'check if error during destroy leads to redirect' do
allow(User).to receive(:find).with(any_args).and_return(nil)
allow(AssignmentParticipant).to receive(:delete).with(any_args).and_return(true)
allow(TeamsUser).to receive(:delete).with(any_args).and_return(true)
allow(AssignmentQuestionnaire).to receive(:destroy).with(any_args).and_return(true)
allow(User).to receive(:destroy).with(any_args).and_return(true)
post :destroy
expect(response).to redirect_to :action=> :list
end
end
</pre>

=== role ===
This method is private and returns the role of the user as per their role_id. In case role_id is nil a new role with name '(none)' is created and returned. We test if this function is successfully called through the edit action even when the user's role_id is nil, or, the template is successfully rendered for edit and no error is raised.

<pre>
context '#edit' do
it 'checks if role renders through edit' do
new_student = User.new
new_student = student1
new_student.role_id = nil
allow(User).to receive(:find).with(any_args).and_return(new_student)
get :edit
expect(response).to render_template(:edit)
end

it 'checks if role fails through edit' do
new_student = User.new
new_student = student1
new_student.role_id = nil
allow(User).to receive(:find).with(any_args).and_return(new_student)
expect{controller.edit}.not_to raise_error
end
end
</pre>

=== paginate_list ===
This method is also private and needs to be tested through list action. The parameter paginate_options which decides the execution of statement we need to test is predefined in the paginate_list, and thus the required statement cannot be accessed or tested. So, we tested the other statements in the method.

<pre>
context '#list' do
it 'checks that paginate_list does not fail with controller' do
expect{controller.list}.not_to raise_error
end

it 'checks that paginate_list does not fail with post' do
post :list
expect(response.status).to eq(200)
end
end
</pre>

== Conclusion ==
The users_controller has been thoroughly tested in its present state. The auto_complete_result method in auto_complete_for_user_name method needs to be defined. Further, the paginate_list method needs to be refactored so that all statements in the method are accessible and may be tested.

== Related Links ==

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

The forked git repository for this project can be found [https://github.com/Harshil-Shah99/expertiza/tree/beta here].

A video of all tests running can be seen [https://drive.google.com/file/d/1rpMtT_sEtHmTHOUvq4Qw4lLyrpbVWU5Q/view?usp=sharing here].

CSC/ECE 517 Spring 2022 - E2206: Testing for users controller

2022-03-21T23:07:26Z

Sbansal6: /* Related Links */

CSC/ECE 517 Spring 2022 - E2206: Testing for users controller

2022-03-21T23:03:29Z

Sbansal6: /* Conclusion */

CSC/ECE 517 Spring 2022 - E2206: Testing for users controller

2022-03-21T22:47:52Z

Sbansal6:

CSC/ECE 517 Spring 2022 - E2206: Testing for users controller

2022-03-21T22:42:35Z

Sbansal6: /* paginate_list */

CSC/ECE 517 Spring 2022 - E2206: Testing for users controller

2022-03-21T22:42:23Z

Sbansal6: /* paginate_list */

== About Expertiza ==

[http://expertiza.ncsu.edu/ Expertiza] is the software benefits for both instructors and students by supporting various types of submissions and providing reusable objects for peer review. It is an open-source project based on [http://rubyonrails.org/ Ruby on Rails] framework. It allows the instructors not only to create and customize new or existing assignments but also to create a list of topics the students can sign up for. Students can form teams to work on various projects and assignments. Expertiza also lets students peer-review other students' submissions, enabling them to work together to improve others' learning experiences.

== Current Project Description ==

This Expertiza OSS project "E2206: Testing for users_controller" is focused on adding unit tests for users_controller.rb.

=== Files Involved ===

* users_controller.rb
* users_controller_spec.rb

=== Running Tests ===

<pre>
rspec ./spec/controllers/users_controller_spec.rb
</pre>

== Testing ==

users_controller had 5 methods for which unit tests were missing as seen in this [https://coveralls.io/builds/46937123/source?filename=app/controllers/users_controller.rb coverall]. The RSpec unit tests added for these methods in the spec file 'users_controller_spec.rb' are discussed below.

=== action_allowed? ===
This method checks if a particular action is allowed when it is called for the current user. The action is passed in the params. In this case we are testing the action list_pending_requested.
We stub a student, an instructor and an admin, and we test if only the admin has the right to perform this action.

<pre>
context '#set_anonymized_view' do
it 'admin list_pending_requested' do
params = { action: 'list_pending_requested' }
allow(controller).to receive(:params).and_return(params)
expect(controller.action_allowed?).to be false
stub_current_user(student7, student7.role.name, student7.role)
allow(controller).to receive(:params).and_return(params)
expect(controller.action_allowed?).to be false
stub_current_user(instructor, instructor.role.name, instructor.role)
allow(controller).to receive(:params).and_return(params)
expect(controller.action_allowed?).to be false
stub_current_user(admin, admin.role.name, admin.role)
allow(controller).to receive(:params).and_return(params)
expect(controller.action_allowed?).to be true
end
end
</pre>

=== auto_complete_for_user_name ===
For auto_complete_for_user_name method there is another method auto_complete_result being called in the controller. This method does not exist, and thus when auto_complete_for_user_name method is called, it raises ActionView::Template::Error. In the first test case, it is being checked if the correct error is being thrown. While, in the second test case the method is being called with a GET request and is expected to redirect us to the home page.
<pre>
context '#auto_complete_for_user_name' do
it 'checks if auto_complete returns actionview error' do
stub_current_user(student1, student1.role.name, student1.role)
session = { user: student1 }
@params = {user: student1}
allow(controller).to receive(:params).and_return(@params)
expect{controller.auto_complete_for_user_name}.to raise_error(ActionView::Template::Error)
end

it 'checks if get auto_complete redirects to test host' do
stub_current_user(student1, student1.role.name, student1.role)
session = { user: student1 }
@params = {user: student1}
allow(controller).to receive(:params).and_return(@params)
get :auto_complete_for_user_name, @params, session
expect(response).to redirect_to("http://test.host/")
end
end
</pre>

=== destroy ===
This action is called in the process of deleting a user. When this action is successfully executed or user is successfully destroyed (when User is passed a valid value 'student1') a note alert is flashed, whereas in case user is not destroyed (when User is passed an invalid value 'nil') an error is flashed. Further, it is being tested that at the end in both cases it redirects to list action.
<pre>
context '#destroy' do
it 'check if user was successfully destroyed' do
allow(User).to receive(:find).with(any_args).and_return(student1)
allow(AssignmentParticipant).to receive(:delete).with(any_args).and_return(true)
allow(TeamsUser).to receive(:delete).with(any_args).and_return(true)
allow(AssignmentQuestionnaire).to receive(:destroy).with(any_args).and_return(true)
allow(User).to receive(:destroy).with(any_args).and_return(true)
post :destroy
expect(flash[:note]).to be_present
end

it 'check if user was not successfully destroyed' do
allow(User).to receive(:find).with(any_args).and_return(nil)
allow(AssignmentParticipant).to receive(:delete).with(any_args).and_return(true)
allow(TeamsUser).to receive(:delete).with(any_args).and_return(true)
allow(AssignmentQuestionnaire).to receive(:destroy).with(any_args).and_return(true)
allow(User).to receive(:destroy).with(any_args).and_return(true)
post :destroy
expect(flash[:error]).to be_present
end

it 'check if successful destroy leads to redirect' do
allow(User).to receive(:find).with(any_args).and_return(student1)
allow(AssignmentParticipant).to receive(:delete).with(any_args).and_return(true)
allow(TeamsUser).to receive(:delete).with(any_args).and_return(true)
allow(AssignmentQuestionnaire).to receive(:destroy).with(any_args).and_return(true)
allow(User).to receive(:destroy).with(any_args).and_return(true)
post :destroy
expect(response).to redirect_to :action=> :list
end

it 'check if error during destroy leads to redirect' do
allow(User).to receive(:find).with(any_args).and_return(nil)
allow(AssignmentParticipant).to receive(:delete).with(any_args).and_return(true)
allow(TeamsUser).to receive(:delete).with(any_args).and_return(true)
allow(AssignmentQuestionnaire).to receive(:destroy).with(any_args).and_return(true)
allow(User).to receive(:destroy).with(any_args).and_return(true)
post :destroy
expect(response).to redirect_to :action=> :list
end
end
</pre>

=== role ===
This method is private and returns the role of the user as per their role_id. In case role_id is nil a new role with name '(none)' is created and returned. We test if this function is successfully called through the edit action even when the user's role_id is nil, or, the template is successfully rendered for edit and no error is raised.

<pre>
context '#edit' do
it 'checks if role renders through edit' do
new_student = User.new
new_student = student1
new_student.role_id = nil
allow(User).to receive(:find).with(any_args).and_return(new_student)
get :edit
expect(response).to render_template(:edit)
end

it 'checks if role fails through edit' do
new_student = User.new
new_student = student1
new_student.role_id = nil
allow(User).to receive(:find).with(any_args).and_return(new_student)
expect{controller.edit}.not_to raise_error
end
end
</pre>

=== paginate_list ===
This method is also private and needs to be tested through list action. The parameter paginate_options which decides the execution of statement we need to test is predefined in the paginate_list, and thus the required statement cannot be accessed or tested.So, we tested the other statements in the method.

<pre>
context '#list' do
it 'checks that paginate_list does not fail with controller' do
expect{controller.list}.not_to raise_error
end

it 'checks that paginate_list does not fail with post' do
post :list
expect(response.status).to eq(200)
end
end
</pre>

CSC/ECE 517 Spring 2022 - E2206: Testing for users controller

2022-03-21T21:54:33Z

Sbansal6: /* Testing */

== About Expertiza ==

[http://expertiza.ncsu.edu/ Expertiza] is the software benefits for both instructors and students by supporting various types of submissions and providing reusable objects for peer review. It is an open-source project based on [http://rubyonrails.org/ Ruby on Rails] framework. It allows the instructors not only to create and customize new or existing assignments but also to create a list of topics the students can sign up for. Students can form teams to work on various projects and assignments. Expertiza also lets students peer-review other students' submissions, enabling them to work together to improve others' learning experiences.

== Current Project Description ==

This Expertiza OSS project "E2206: Testing for users_controller" is focused on adding unit tests for users_controller.rb.

=== Files Involved ===

* users_controller.rb
* users_controller_spec.rb

=== Running Tests ===

<pre>
rspec ./spec/controllers/users_controller_spec.rb
</pre>

== Testing ==

users_controller had 5 methods for which unit tests were missing as seen in this [https://coveralls.io/builds/46937123/source?filename=app/controllers/users_controller.rb coverall]. The RSpec unit tests added for these methods in the spec file 'users_controller_spec.rb' are discussed below.

=== action_allowed? ===
This method checks if a particular action is allowed when it is called for the current user. The action is passed in the params. In this case we are testing the action list_pending_requested.
We stub a student, an instructor and an admin, and we test if only the admin has the right to perform this action.

<pre>
context '#set_anonymized_view' do
it 'admin list_pending_requested' do
params = { action: 'list_pending_requested' }
allow(controller).to receive(:params).and_return(params)
expect(controller.action_allowed?).to be false
stub_current_user(student7, student7.role.name, student7.role)
allow(controller).to receive(:params).and_return(params)
expect(controller.action_allowed?).to be false
stub_current_user(instructor, instructor.role.name, instructor.role)
allow(controller).to receive(:params).and_return(params)
expect(controller.action_allowed?).to be false
stub_current_user(admin, admin.role.name, admin.role)
allow(controller).to receive(:params).and_return(params)
expect(controller.action_allowed?).to be true
end
end
</pre>

=== auto_complete_for_user_name ===
For auto_complete_for_user_name method there is another method auto_complete_result being called in the controller. This method does not exist, and thus when auto_complete_for_user_name method is called, it raises ActionView::Template::Error. In the first test case, it is being checked if the correct error is being thrown. While, in the second test case the method is being called with a GET request and is expected to redirect us to the home page.
<pre>
context '#auto_complete_for_user_name' do
it 'checks if auto_complete returns actionview error' do
stub_current_user(student1, student1.role.name, student1.role)
session = { user: student1 }
@params = {user: student1}
allow(controller).to receive(:params).and_return(@params)
expect{controller.auto_complete_for_user_name}.to raise_error(ActionView::Template::Error)
end

it 'checks if get auto_complete redirects to test host' do
stub_current_user(student1, student1.role.name, student1.role)
session = { user: student1 }
@params = {user: student1}
allow(controller).to receive(:params).and_return(@params)
get :auto_complete_for_user_name, @params, session
expect(response).to redirect_to("http://test.host/")
end
end
</pre>

=== destroy ===
This action is called in the process of deleting a user. When this action is successfully executed or user is successfully destroyed (when User is passed a valid value 'student1') a note alert is flashed, whereas in case user is not destroyed (when User is passed an invalid value 'nil') an error is flashed. Further, it is being tested that at the end in both cases it redirects to list action.
<pre>
context '#destroy' do
it 'check if user was successfully destroyed' do
allow(User).to receive(:find).with(any_args).and_return(student1)
allow(AssignmentParticipant).to receive(:delete).with(any_args).and_return(true)
allow(TeamsUser).to receive(:delete).with(any_args).and_return(true)
allow(AssignmentQuestionnaire).to receive(:destroy).with(any_args).and_return(true)
allow(User).to receive(:destroy).with(any_args).and_return(true)
post :destroy
expect(flash[:note]).to be_present
end

it 'check if user was not successfully destroyed' do
allow(User).to receive(:find).with(any_args).and_return(nil)
allow(AssignmentParticipant).to receive(:delete).with(any_args).and_return(true)
allow(TeamsUser).to receive(:delete).with(any_args).and_return(true)
allow(AssignmentQuestionnaire).to receive(:destroy).with(any_args).and_return(true)
allow(User).to receive(:destroy).with(any_args).and_return(true)
post :destroy
expect(flash[:error]).to be_present
end

it 'check if successful destroy leads to redirect' do
allow(User).to receive(:find).with(any_args).and_return(student1)
allow(AssignmentParticipant).to receive(:delete).with(any_args).and_return(true)
allow(TeamsUser).to receive(:delete).with(any_args).and_return(true)
allow(AssignmentQuestionnaire).to receive(:destroy).with(any_args).and_return(true)
allow(User).to receive(:destroy).with(any_args).and_return(true)
post :destroy
expect(response).to redirect_to :action=> :list
end

it 'check if error during destroy leads to redirect' do
allow(User).to receive(:find).with(any_args).and_return(nil)
allow(AssignmentParticipant).to receive(:delete).with(any_args).and_return(true)
allow(TeamsUser).to receive(:delete).with(any_args).and_return(true)
allow(AssignmentQuestionnaire).to receive(:destroy).with(any_args).and_return(true)
allow(User).to receive(:destroy).with(any_args).and_return(true)
post :destroy
expect(response).to redirect_to :action=> :list
end
end
</pre>

=== role ===
This method is private and returns the role of the user as per their role_id. In case role_id is nil a new role with name '(none)' is created and returned. We test if this function is successfully called through the edit action even when the user's role_id is nil, or, the template is successfully rendered for edit and no error is raised.

<pre>
context '#edit' do
it 'checks if role renders through edit' do
new_student = User.new
new_student = student1
new_student.role_id = nil
allow(User).to receive(:find).with(any_args).and_return(new_student)
get :edit
expect(response).to render_template(:edit)
end

it 'checks if role fails through edit' do
new_student = User.new
new_student = student1
new_student.role_id = nil
allow(User).to receive(:find).with(any_args).and_return(new_student)
expect{controller.edit}.not_to raise_error
end
end
</pre>

=== paginate_list ===
<pre>
context '#list' do

it 'checks that paginate_list does not fail with controller' do
expect{controller.list}.not_to raise_error
end

it 'checks that paginate_list does not fail with post' do
post :list
expect(response.status).to eq(200)
end
end
</pre>

CSC/ECE 517 Spring 2022 - E2206: Testing for users controller

2022-03-21T21:50:15Z

Sbansal6: /* role */

== About Expertiza ==

[http://expertiza.ncsu.edu/ Expertiza] is the software benefits for both instructors and students by supporting various types of submissions and providing reusable objects for peer review. It is an open-source project based on [http://rubyonrails.org/ Ruby on Rails] framework. It allows the instructors not only to create and customize new or existing assignments but also to create a list of topics the students can sign up for. Students can form teams to work on various projects and assignments. Expertiza also lets students peer-review other students' submissions, enabling them to work together to improve others' learning experiences.

== Current Project Description ==

This Expertiza OSS project "E2206: Testing for users_controller" is focused on adding unit tests for users_controller.rb.

=== Files Involved ===

* users_controller.rb
* users_controller_spec.rb

=== Running Tests ===

<pre>
rspec ./spec/controllers/users_controller_spec.rb
</pre>

== Testing ==

users_controller had 5 methods for which unit tests were missing. The RSpec unit tests added for these methods in the spec file 'users_controller_spec.rb' are discussed below.

=== action_allowed? ===
This method checks if a particular action is allowed when it is called for the current user. The action is passed in the params. In this case we are testing the action list_pending_requested.
We stub a student, an instructor and an admin, and we test if only the admin has the right to perform this action.

<pre>
context '#set_anonymized_view' do
it 'admin list_pending_requested' do
params = { action: 'list_pending_requested' }
allow(controller).to receive(:params).and_return(params)
expect(controller.action_allowed?).to be false
stub_current_user(student7, student7.role.name, student7.role)
allow(controller).to receive(:params).and_return(params)
expect(controller.action_allowed?).to be false
stub_current_user(instructor, instructor.role.name, instructor.role)
allow(controller).to receive(:params).and_return(params)
expect(controller.action_allowed?).to be false
stub_current_user(admin, admin.role.name, admin.role)
allow(controller).to receive(:params).and_return(params)
expect(controller.action_allowed?).to be true
end
end
</pre>

=== auto_complete_for_user_name ===
For auto_complete_for_user_name method there is another method auto_complete_result being called in the controller. This method does not exist, and thus when auto_complete_for_user_name method is called, it raises ActionView::Template::Error. In the first test case, it is being checked if the correct error is being thrown. While, in the second test case the method is being called with a GET request and is expected to redirect us to the home page.
<pre>
context '#auto_complete_for_user_name' do
it 'checks if auto_complete returns actionview error' do
stub_current_user(student1, student1.role.name, student1.role)
session = { user: student1 }
@params = {user: student1}
allow(controller).to receive(:params).and_return(@params)
expect{controller.auto_complete_for_user_name}.to raise_error(ActionView::Template::Error)
end

it 'checks if get auto_complete redirects to test host' do
stub_current_user(student1, student1.role.name, student1.role)
session = { user: student1 }
@params = {user: student1}
allow(controller).to receive(:params).and_return(@params)
get :auto_complete_for_user_name, @params, session
expect(response).to redirect_to("http://test.host/")
end
end
</pre>

=== destroy ===
This action is called in the process of deleting a user. When this action is successfully executed or user is successfully destroyed (when User is passed a valid value 'student1') a note alert is flashed, whereas in case user is not destroyed (when User is passed an invalid value 'nil') an error is flashed. Further, it is being tested that at the end in both cases it redirects to list action.
<pre>
context '#destroy' do
it 'check if user was successfully destroyed' do
allow(User).to receive(:find).with(any_args).and_return(student1)
allow(AssignmentParticipant).to receive(:delete).with(any_args).and_return(true)
allow(TeamsUser).to receive(:delete).with(any_args).and_return(true)
allow(AssignmentQuestionnaire).to receive(:destroy).with(any_args).and_return(true)
allow(User).to receive(:destroy).with(any_args).and_return(true)
post :destroy
expect(flash[:note]).to be_present
end

it 'check if user was not successfully destroyed' do
allow(User).to receive(:find).with(any_args).and_return(nil)
allow(AssignmentParticipant).to receive(:delete).with(any_args).and_return(true)
allow(TeamsUser).to receive(:delete).with(any_args).and_return(true)
allow(AssignmentQuestionnaire).to receive(:destroy).with(any_args).and_return(true)
allow(User).to receive(:destroy).with(any_args).and_return(true)
post :destroy
expect(flash[:error]).to be_present
end

it 'check if successful destroy leads to redirect' do
allow(User).to receive(:find).with(any_args).and_return(student1)
allow(AssignmentParticipant).to receive(:delete).with(any_args).and_return(true)
allow(TeamsUser).to receive(:delete).with(any_args).and_return(true)
allow(AssignmentQuestionnaire).to receive(:destroy).with(any_args).and_return(true)
allow(User).to receive(:destroy).with(any_args).and_return(true)
post :destroy
expect(response).to redirect_to :action=> :list
end

it 'check if error during destroy leads to redirect' do
allow(User).to receive(:find).with(any_args).and_return(nil)
allow(AssignmentParticipant).to receive(:delete).with(any_args).and_return(true)
allow(TeamsUser).to receive(:delete).with(any_args).and_return(true)
allow(AssignmentQuestionnaire).to receive(:destroy).with(any_args).and_return(true)
allow(User).to receive(:destroy).with(any_args).and_return(true)
post :destroy
expect(response).to redirect_to :action=> :list
end
end
</pre>

=== role ===
This method is private and returns the role of the user as per their role_id. In case role_id is nil a new role with name '(none)' is created and returned. We test if this function is successfully called through the edit action even when the user's role_id is nil, or, the template is successfully rendered for edit and no error is raised.

<pre>
context '#edit' do
it 'checks if role renders through edit' do
new_student = User.new
new_student = student1
new_student.role_id = nil
allow(User).to receive(:find).with(any_args).and_return(new_student)
get :edit
expect(response).to render_template(:edit)
end

it 'checks if role fails through edit' do
new_student = User.new
new_student = student1
new_student.role_id = nil
allow(User).to receive(:find).with(any_args).and_return(new_student)
expect{controller.edit}.not_to raise_error
end
end
</pre>

=== paginate_list ===
<pre>
context '#list' do

it 'checks that paginate_list does not fail with controller' do
expect{controller.list}.not_to raise_error
end

it 'checks that paginate_list does not fail with post' do
post :list
expect(response.status).to eq(200)
end
end
</pre>

CSC/ECE 517 Spring 2022 - E2206: Testing for users controller

2022-03-21T21:49:51Z

Sbansal6: /* role */

== About Expertiza ==

[http://expertiza.ncsu.edu/ Expertiza] is the software benefits for both instructors and students by supporting various types of submissions and providing reusable objects for peer review. It is an open-source project based on [http://rubyonrails.org/ Ruby on Rails] framework. It allows the instructors not only to create and customize new or existing assignments but also to create a list of topics the students can sign up for. Students can form teams to work on various projects and assignments. Expertiza also lets students peer-review other students' submissions, enabling them to work together to improve others' learning experiences.

== Current Project Description ==

This Expertiza OSS project "E2206: Testing for users_controller" is focused on adding unit tests for users_controller.rb.

=== Files Involved ===

* users_controller.rb
* users_controller_spec.rb

=== Running Tests ===

<pre>
rspec ./spec/controllers/users_controller_spec.rb
</pre>

== Testing ==

users_controller had 5 methods for which unit tests were missing. The RSpec unit tests added for these methods in the spec file 'users_controller_spec.rb' are discussed below.

=== action_allowed? ===
This method checks if a particular action is allowed when it is called for the current user. The action is passed in the params. In this case we are testing the action list_pending_requested.
We stub a student, an instructor and an admin, and we test if only the admin has the right to perform this action.

<pre>
context '#set_anonymized_view' do
it 'admin list_pending_requested' do
params = { action: 'list_pending_requested' }
allow(controller).to receive(:params).and_return(params)
expect(controller.action_allowed?).to be false
stub_current_user(student7, student7.role.name, student7.role)
allow(controller).to receive(:params).and_return(params)
expect(controller.action_allowed?).to be false
stub_current_user(instructor, instructor.role.name, instructor.role)
allow(controller).to receive(:params).and_return(params)
expect(controller.action_allowed?).to be false
stub_current_user(admin, admin.role.name, admin.role)
allow(controller).to receive(:params).and_return(params)
expect(controller.action_allowed?).to be true
end
end
</pre>

=== auto_complete_for_user_name ===
For auto_complete_for_user_name method there is another method auto_complete_result being called in the controller. This method does not exist, and thus when auto_complete_for_user_name method is called, it raises ActionView::Template::Error. In the first test case, it is being checked if the correct error is being thrown. While, in the second test case the method is being called with a GET request and is expected to redirect us to the home page.
<pre>
context '#auto_complete_for_user_name' do
it 'checks if auto_complete returns actionview error' do
stub_current_user(student1, student1.role.name, student1.role)
session = { user: student1 }
@params = {user: student1}
allow(controller).to receive(:params).and_return(@params)
expect{controller.auto_complete_for_user_name}.to raise_error(ActionView::Template::Error)
end

it 'checks if get auto_complete redirects to test host' do
stub_current_user(student1, student1.role.name, student1.role)
session = { user: student1 }
@params = {user: student1}
allow(controller).to receive(:params).and_return(@params)
get :auto_complete_for_user_name, @params, session
expect(response).to redirect_to("http://test.host/")
end
end
</pre>

=== destroy ===
This action is called in the process of deleting a user. When this action is successfully executed or user is successfully destroyed (when User is passed a valid value 'student1') a note alert is flashed, whereas in case user is not destroyed (when User is passed an invalid value 'nil') an error is flashed. Further, it is being tested that at the end in both cases it redirects to list action.
<pre>
context '#destroy' do
it 'check if user was successfully destroyed' do
allow(User).to receive(:find).with(any_args).and_return(student1)
allow(AssignmentParticipant).to receive(:delete).with(any_args).and_return(true)
allow(TeamsUser).to receive(:delete).with(any_args).and_return(true)
allow(AssignmentQuestionnaire).to receive(:destroy).with(any_args).and_return(true)
allow(User).to receive(:destroy).with(any_args).and_return(true)
post :destroy
expect(flash[:note]).to be_present
end

it 'check if user was not successfully destroyed' do
allow(User).to receive(:find).with(any_args).and_return(nil)
allow(AssignmentParticipant).to receive(:delete).with(any_args).and_return(true)
allow(TeamsUser).to receive(:delete).with(any_args).and_return(true)
allow(AssignmentQuestionnaire).to receive(:destroy).with(any_args).and_return(true)
allow(User).to receive(:destroy).with(any_args).and_return(true)
post :destroy
expect(flash[:error]).to be_present
end

it 'check if successful destroy leads to redirect' do
allow(User).to receive(:find).with(any_args).and_return(student1)
allow(AssignmentParticipant).to receive(:delete).with(any_args).and_return(true)
allow(TeamsUser).to receive(:delete).with(any_args).and_return(true)
allow(AssignmentQuestionnaire).to receive(:destroy).with(any_args).and_return(true)
allow(User).to receive(:destroy).with(any_args).and_return(true)
post :destroy
expect(response).to redirect_to :action=> :list
end

it 'check if error during destroy leads to redirect' do
allow(User).to receive(:find).with(any_args).and_return(nil)
allow(AssignmentParticipant).to receive(:delete).with(any_args).and_return(true)
allow(TeamsUser).to receive(:delete).with(any_args).and_return(true)
allow(AssignmentQuestionnaire).to receive(:destroy).with(any_args).and_return(true)
allow(User).to receive(:destroy).with(any_args).and_return(true)
post :destroy
expect(response).to redirect_to :action=> :list
end
end
</pre>

=== role ===
This method is private and returns the role of the user as per their role_id. In case role_id is nil a new role with name '(none)' is created and returned. We test if this function is successfully called through the edit action even when the user's role_id is nil, or, the template is successfully rendered for edit and no error is raised.

<pre>
context '#edit' do

it 'checks if role renders through edit' do
new_student = User.new
new_student = student1
new_student.role_id = nil
allow(User).to receive(:find).with(any_args).and_return(new_student)
get :edit
expect(response).to render_template(:edit)
end

it 'checks if role fails through edit' do
new_student = User.new
new_student = student1
new_student.role_id = nil
allow(User).to receive(:find).with(any_args).and_return(new_student)
expect{controller.edit}.not_to raise_error
end
end
</pre>

=== paginate_list ===
<pre>
context '#list' do

it 'checks that paginate_list does not fail with controller' do
expect{controller.list}.not_to raise_error
end

it 'checks that paginate_list does not fail with post' do
post :list
expect(response.status).to eq(200)
end
end
</pre>

CSC/ECE 517 Spring 2022 - E2206: Testing for users controller

2022-03-21T21:37:29Z

Sbansal6: /* destroy */

== About Expertiza ==

[http://expertiza.ncsu.edu/ Expertiza] is the software benefits for both instructors and students by supporting various types of submissions and providing reusable objects for peer review. It is an open-source project based on [http://rubyonrails.org/ Ruby on Rails] framework. It allows the instructors not only to create and customize new or existing assignments but also to create a list of topics the students can sign up for. Students can form teams to work on various projects and assignments. Expertiza also lets students peer-review other students' submissions, enabling them to work together to improve others' learning experiences.

== Current Project Description ==

This Expertiza OSS project "E2206: Testing for users_controller" is focused on adding unit tests for users_controller.rb.

=== Files Involved ===

* users_controller.rb
* users_controller_spec.rb

=== Running Tests ===

<pre>
rspec ./spec/controllers/users_controller_spec.rb
</pre>

== Testing ==

users_controller had 5 methods for which unit tests were missing. The RSpec unit tests added for these methods in the spec file 'users_controller_spec.rb' are discussed below.

=== action_allowed? ===
This method checks if a particular action is allowed when it is called for the current user. The action is passed in the params. In this case we are testing the action list_pending_requested.
We stub a student, an instructor and an admin, and we test if only the admin has the right to perform this action.

<pre>
context '#set_anonymized_view' do
it 'admin list_pending_requested' do
params = { action: 'list_pending_requested' }
allow(controller).to receive(:params).and_return(params)
expect(controller.action_allowed?).to be false
stub_current_user(student7, student7.role.name, student7.role)
allow(controller).to receive(:params).and_return(params)
expect(controller.action_allowed?).to be false
stub_current_user(instructor, instructor.role.name, instructor.role)
allow(controller).to receive(:params).and_return(params)
expect(controller.action_allowed?).to be false
stub_current_user(admin, admin.role.name, admin.role)
allow(controller).to receive(:params).and_return(params)
expect(controller.action_allowed?).to be true
end
end
</pre>

=== auto_complete_for_user_name ===
For auto_complete_for_user_name method there is another method auto_complete_result being called in the controller. This method does not exist, and thus when auto_complete_for_user_name method is called, it raises ActionView::Template::Error. In the first test case, it is being checked if the correct error is being thrown. While, in the second test case the method is being called with a GET request and is expected to redirect us to the home page.
<pre>
context '#auto_complete_for_user_name' do
it 'checks if auto_complete returns actionview error' do
stub_current_user(student1, student1.role.name, student1.role)
session = { user: student1 }
@params = {user: student1}
allow(controller).to receive(:params).and_return(@params)
expect{controller.auto_complete_for_user_name}.to raise_error(ActionView::Template::Error)
end

it 'checks if get auto_complete redirects to test host' do
stub_current_user(student1, student1.role.name, student1.role)
session = { user: student1 }
@params = {user: student1}
allow(controller).to receive(:params).and_return(@params)
get :auto_complete_for_user_name, @params, session
expect(response).to redirect_to("http://test.host/")
end
end
</pre>

=== destroy ===
This action is called in the process of deleting a user. When this action is successfully executed or user is successfully destroyed (when User is passed a valid value 'student1') a note alert is flashed, whereas in case user is not destroyed (when User is passed an invalid value 'nil') an error is flashed. Further, it is being tested that at the end in both cases it redirects to list action.
<pre>
context '#destroy' do
it 'check if user was successfully destroyed' do
allow(User).to receive(:find).with(any_args).and_return(student1)
allow(AssignmentParticipant).to receive(:delete).with(any_args).and_return(true)
allow(TeamsUser).to receive(:delete).with(any_args).and_return(true)
allow(AssignmentQuestionnaire).to receive(:destroy).with(any_args).and_return(true)
allow(User).to receive(:destroy).with(any_args).and_return(true)
post :destroy
expect(flash[:note]).to be_present
end

it 'check if user was not successfully destroyed' do
allow(User).to receive(:find).with(any_args).and_return(nil)
allow(AssignmentParticipant).to receive(:delete).with(any_args).and_return(true)
allow(TeamsUser).to receive(:delete).with(any_args).and_return(true)
allow(AssignmentQuestionnaire).to receive(:destroy).with(any_args).and_return(true)
allow(User).to receive(:destroy).with(any_args).and_return(true)
post :destroy
expect(flash[:error]).to be_present
end

it 'check if successful destroy leads to redirect' do
allow(User).to receive(:find).with(any_args).and_return(student1)
allow(AssignmentParticipant).to receive(:delete).with(any_args).and_return(true)
allow(TeamsUser).to receive(:delete).with(any_args).and_return(true)
allow(AssignmentQuestionnaire).to receive(:destroy).with(any_args).and_return(true)
allow(User).to receive(:destroy).with(any_args).and_return(true)
post :destroy
expect(response).to redirect_to :action=> :list
end

it 'check if error during destroy leads to redirect' do
allow(User).to receive(:find).with(any_args).and_return(nil)
allow(AssignmentParticipant).to receive(:delete).with(any_args).and_return(true)
allow(TeamsUser).to receive(:delete).with(any_args).and_return(true)
allow(AssignmentQuestionnaire).to receive(:destroy).with(any_args).and_return(true)
allow(User).to receive(:destroy).with(any_args).and_return(true)
post :destroy
expect(response).to redirect_to :action=> :list
end
end
</pre>

=== role ===
<pre>
context '#edit' do

it 'checks if role renders through edit' do
new_student = User.new
new_student = student1
new_student.role_id = nil
allow(User).to receive(:find).with(any_args).and_return(new_student)
get :edit
expect(response).to render_template(:edit)
end

it 'checks if role fails through edit' do
new_student = User.new
new_student = student1
new_student.role_id = nil
allow(User).to receive(:find).with(any_args).and_return(new_student)
expect{controller.edit}.not_to raise_error
end
end
</pre>

=== paginate_list ===
<pre>
context '#list' do

it 'checks that paginate_list does not fail with controller' do
expect{controller.list}.not_to raise_error
end

it 'checks that paginate_list does not fail with post' do
post :list
expect(response.status).to eq(200)
end
end
</pre>

CSC/ECE 517 Spring 2022 - E2206: Testing for users controller

2022-03-21T21:24:29Z

Sbansal6: /* Testing */

== About Expertiza ==

[http://expertiza.ncsu.edu/ Expertiza] is the software benefits for both instructors and students by supporting various types of submissions and providing reusable objects for peer review. It is an open-source project based on [http://rubyonrails.org/ Ruby on Rails] framework. It allows the instructors not only to create and customize new or existing assignments but also to create a list of topics the students can sign up for. Students can form teams to work on various projects and assignments. Expertiza also lets students peer-review other students' submissions, enabling them to work together to improve others' learning experiences.

== Current Project Description ==

This Expertiza OSS project "E2206: Testing for users_controller" is focused on adding unit tests for users_controller.rb.

=== Files Involved ===

* users_controller.rb
* users_controller_spec.rb

=== Running Tests ===

<pre>
rspec ./spec/controllers/users_controller_spec.rb
</pre>

== Testing ==

users_controller had 5 methods for which unit tests were missing. The RSpec unit tests added for these methods in the spec file 'users_controller_spec.rb' are discussed below.

=== action_allowed? ===
This method checks if a particular action is allowed when it is called for the current user. The action is passed in the params. In this case we are testing the action list_pending_requested.
We stub a student, an instructor and an admin, and we test if only the admin has the right to perform this action.

<pre>
context '#set_anonymized_view' do
it 'admin list_pending_requested' do
params = { action: 'list_pending_requested' }
allow(controller).to receive(:params).and_return(params)
expect(controller.action_allowed?).to be false
stub_current_user(student7, student7.role.name, student7.role)
allow(controller).to receive(:params).and_return(params)
expect(controller.action_allowed?).to be false
stub_current_user(instructor, instructor.role.name, instructor.role)
allow(controller).to receive(:params).and_return(params)
expect(controller.action_allowed?).to be false
stub_current_user(admin, admin.role.name, admin.role)
allow(controller).to receive(:params).and_return(params)
expect(controller.action_allowed?).to be true
end
end
</pre>

=== auto_complete_for_user_name ===
For auto_complete_for_user_name method there is another method auto_complete_result being called in the controller. This method does not exist, and thus when auto_complete_for_user_name method is called, it raises ActionView::Template::Error. In the first test case, it is being checked if the correct error is being thrown. While, in the second test case the method is being called with a GET request and is expected to redirect us to the home page.
<pre>
context '#auto_complete_for_user_name' do
it 'checks if auto_complete returns actionview error' do
stub_current_user(student1, student1.role.name, student1.role)
session = { user: student1 }
@params = {user: student1}
allow(controller).to receive(:params).and_return(@params)
expect{controller.auto_complete_for_user_name}.to raise_error(ActionView::Template::Error)
end

it 'checks if get auto_complete redirects to test host' do
stub_current_user(student1, student1.role.name, student1.role)
session = { user: student1 }
@params = {user: student1}
allow(controller).to receive(:params).and_return(@params)
get :auto_complete_for_user_name, @params, session
expect(response).to redirect_to("http://test.host/")
end
end
</pre>

=== destroy ===
<pre>
context '#destroy' do

it 'check if user was successfully destroyed' do
allow(User).to receive(:find).with(any_args).and_return(student1)
allow(AssignmentParticipant).to receive(:delete).with(any_args).and_return(true)
allow(TeamsUser).to receive(:delete).with(any_args).and_return(true)
allow(AssignmentQuestionnaire).to receive(:destroy).with(any_args).and_return(true)
allow(User).to receive(:destroy).with(any_args).and_return(true)
post :destroy
expect(flash[:note]).to be_present
end

it 'check if user was not successfully destroyed' do
allow(User).to receive(:find).with(any_args).and_return(nil)
allow(AssignmentParticipant).to receive(:delete).with(any_args).and_return(true)
allow(TeamsUser).to receive(:delete).with(any_args).and_return(true)
allow(AssignmentQuestionnaire).to receive(:destroy).with(any_args).and_return(true)
allow(User).to receive(:destroy).with(any_args).and_return(true)
post :destroy
expect(flash[:error]).to be_present
end

it 'check if successful destroy leads to redirect' do
allow(User).to receive(:find).with(any_args).and_return(student1)
allow(AssignmentParticipant).to receive(:delete).with(any_args).and_return(true)
allow(TeamsUser).to receive(:delete).with(any_args).and_return(true)
allow(AssignmentQuestionnaire).to receive(:destroy).with(any_args).and_return(true)
allow(User).to receive(:destroy).with(any_args).and_return(true)
post :destroy
expect(response).to redirect_to :action=> :list
end

it 'check if error during destroy leads to redirect' do
allow(User).to receive(:find).with(any_args).and_return(nil)
allow(AssignmentParticipant).to receive(:delete).with(any_args).and_return(true)
allow(TeamsUser).to receive(:delete).with(any_args).and_return(true)
allow(AssignmentQuestionnaire).to receive(:destroy).with(any_args).and_return(true)
allow(User).to receive(:destroy).with(any_args).and_return(true)
post :destroy
expect(response).to redirect_to :action=> :list
end
end
</pre>

=== role ===
<pre>
context '#edit' do

it 'checks if role renders through edit' do
new_student = User.new
new_student = student1
new_student.role_id = nil
allow(User).to receive(:find).with(any_args).and_return(new_student)
get :edit
expect(response).to render_template(:edit)
end

it 'checks if role fails through edit' do
new_student = User.new
new_student = student1
new_student.role_id = nil
allow(User).to receive(:find).with(any_args).and_return(new_student)
expect{controller.edit}.not_to raise_error
end
end
</pre>

=== paginate_list ===
<pre>
context '#list' do

it 'checks that paginate_list does not fail with controller' do
expect{controller.list}.not_to raise_error
end

it 'checks that paginate_list does not fail with post' do
post :list
expect(response.status).to eq(200)
end
end
</pre>

CSC/ECE 517 Spring 2022 - E2206: Testing for users controller

2022-03-21T21:19:47Z

Sbansal6: /* auto_complete_for_user_name */

== About Expertiza ==

[http://expertiza.ncsu.edu/ Expertiza] is the software benefits for both instructors and students by supporting various types of submissions and providing reusable objects for peer review. It is an open-source project based on [http://rubyonrails.org/ Ruby on Rails] framework. It allows the instructors not only to create and customize new or existing assignments but also to create a list of topics the students can sign up for. Students can form teams to work on various projects and assignments. Expertiza also lets students peer-review other students' submissions, enabling them to work together to improve others' learning experiences.

== Current Project Description ==

This Expertiza OSS project "E2206: Testing for users_controller" is focused on adding unit tests for users_controller.rb.

=== Files Involved ===

* users_controller.rb
* users_controller_spec.rb

=== Running Tests ===

<pre>
rspec ./spec/controllers/users_controller_spec.rb
</pre>

== Testing ==

users_controller had 5 methods for which unit tests were missing. The unit tests added for these methods in the spec file 'users_controller_spec.rb' are discussed below.

=== action_allowed? ===
This method checks if a particular action is allowed when it is called for the current user. The action is passed in the params. In this case we are testing the action list_pending_requested.
We stub a student, an instructor and an admin, and we test if only the admin has the right to perform this action.

<pre>
context '#set_anonymized_view' do
it 'admin list_pending_requested' do
params = { action: 'list_pending_requested' }
allow(controller).to receive(:params).and_return(params)
expect(controller.action_allowed?).to be false
stub_current_user(student7, student7.role.name, student7.role)
allow(controller).to receive(:params).and_return(params)
expect(controller.action_allowed?).to be false
stub_current_user(instructor, instructor.role.name, instructor.role)
allow(controller).to receive(:params).and_return(params)
expect(controller.action_allowed?).to be false
stub_current_user(admin, admin.role.name, admin.role)
allow(controller).to receive(:params).and_return(params)
expect(controller.action_allowed?).to be true
end
end
</pre>

=== auto_complete_for_user_name ===
For auto_complete_for_user_name method there is another method auto_complete_result being called in the controller. This method does not exist, and thus when auto_complete_for_user_name method is called, it raises ActionView::Template::Error. In the first test case, it is being checked if the correct error is being thrown. While, in the second test case the method is being called with a GET request and is expected to redirect us to the home page.
<pre>
context '#auto_complete_for_user_name' do
it 'checks if auto_complete returns actionview error' do
stub_current_user(student1, student1.role.name, student1.role)
session = { user: student1 }
@params = {user: student1}
allow(controller).to receive(:params).and_return(@params)
expect{controller.auto_complete_for_user_name}.to raise_error(ActionView::Template::Error)
end

it 'checks if get auto_complete redirects to test host' do
stub_current_user(student1, student1.role.name, student1.role)
session = { user: student1 }
@params = {user: student1}
allow(controller).to receive(:params).and_return(@params)
get :auto_complete_for_user_name, @params, session
expect(response).to redirect_to("http://test.host/")
end
end
</pre>

=== destroy ===
<pre>
context '#destroy' do

it 'check if user was successfully destroyed' do
allow(User).to receive(:find).with(any_args).and_return(student1)
allow(AssignmentParticipant).to receive(:delete).with(any_args).and_return(true)
allow(TeamsUser).to receive(:delete).with(any_args).and_return(true)
allow(AssignmentQuestionnaire).to receive(:destroy).with(any_args).and_return(true)
allow(User).to receive(:destroy).with(any_args).and_return(true)
post :destroy
expect(flash[:note]).to be_present
end

it 'check if user was not successfully destroyed' do
allow(User).to receive(:find).with(any_args).and_return(nil)
allow(AssignmentParticipant).to receive(:delete).with(any_args).and_return(true)
allow(TeamsUser).to receive(:delete).with(any_args).and_return(true)
allow(AssignmentQuestionnaire).to receive(:destroy).with(any_args).and_return(true)
allow(User).to receive(:destroy).with(any_args).and_return(true)
post :destroy
expect(flash[:error]).to be_present
end

it 'check if successful destroy leads to redirect' do
allow(User).to receive(:find).with(any_args).and_return(student1)
allow(AssignmentParticipant).to receive(:delete).with(any_args).and_return(true)
allow(TeamsUser).to receive(:delete).with(any_args).and_return(true)
allow(AssignmentQuestionnaire).to receive(:destroy).with(any_args).and_return(true)
allow(User).to receive(:destroy).with(any_args).and_return(true)
post :destroy
expect(response).to redirect_to :action=> :list
end

it 'check if error during destroy leads to redirect' do
allow(User).to receive(:find).with(any_args).and_return(nil)
allow(AssignmentParticipant).to receive(:delete).with(any_args).and_return(true)
allow(TeamsUser).to receive(:delete).with(any_args).and_return(true)
allow(AssignmentQuestionnaire).to receive(:destroy).with(any_args).and_return(true)
allow(User).to receive(:destroy).with(any_args).and_return(true)
post :destroy
expect(response).to redirect_to :action=> :list
end
end
</pre>

=== role ===
<pre>
context '#edit' do

it 'checks if role renders through edit' do
new_student = User.new
new_student = student1
new_student.role_id = nil
allow(User).to receive(:find).with(any_args).and_return(new_student)
get :edit
expect(response).to render_template(:edit)
end

it 'checks if role fails through edit' do
new_student = User.new
new_student = student1
new_student.role_id = nil
allow(User).to receive(:find).with(any_args).and_return(new_student)
expect{controller.edit}.not_to raise_error
end
end
</pre>

=== paginate_list ===
<pre>
context '#list' do

it 'checks that paginate_list does not fail with controller' do
expect{controller.list}.not_to raise_error
end

it 'checks that paginate_list does not fail with post' do
post :list
expect(response.status).to eq(200)
end
end
</pre>

CSC/ECE 517 Spring 2022 - E2206: Testing for users controller

2022-03-21T20:37:41Z

Sbansal6: /* action_allowed? */

== About Expertiza ==

[http://expertiza.ncsu.edu/ Expertiza] is the software benefits for both instructors and students by supporting various types of submissions and providing reusable objects for peer review. It is an open-source project based on [http://rubyonrails.org/ Ruby on Rails] framework. It allows the instructors not only to create and customize new or existing assignments but also to create a list of topics the students can sign up for. Students can form teams to work on various projects and assignments. Expertiza also lets students peer-review other students' submissions, enabling them to work together to improve others' learning experiences.

== Current Project Description ==

This Expertiza OSS project "E2206: Testing for users_controller" is focused on adding unit tests for users_controller.rb.

=== Files Involved ===

* users_controller.rb
* users_controller_spec.rb

=== Running Tests ===

<pre>
rspec ./spec/controllers/users_controller_spec.rb
</pre>

== Testing ==

users_controller had 5 methods for which unit tests were missing. The unit tests added for these methods in the spec file 'users_controller_spec.rb' are discussed below.

=== action_allowed? ===
This method checks if a particular action is allowed when it is called for the current user. The action is passed in the params. In this case we are testing the action list_pending_requested.
We stub a student, an instructor and an admin, and we test if only the admin has the right to perform this action.

<pre>
context '#set_anonymized_view' do
it 'admin list_pending_requested' do
params = { action: 'list_pending_requested' }
allow(controller).to receive(:params).and_return(params)
expect(controller.action_allowed?).to be false
stub_current_user(student7, student7.role.name, student7.role)
allow(controller).to receive(:params).and_return(params)
expect(controller.action_allowed?).to be false
stub_current_user(instructor, instructor.role.name, instructor.role)
allow(controller).to receive(:params).and_return(params)
expect(controller.action_allowed?).to be false
stub_current_user(admin, admin.role.name, admin.role)
allow(controller).to receive(:params).and_return(params)
expect(controller.action_allowed?).to be true
end
end
</pre>

=== auto_complete_for_user_name ===
<pre>
context '#auto_complete_for_user_name' do

it 'checks if auto_complete returns actionview error' do
stub_current_user(student1, student1.role.name, student1.role)
session = { user: student1 }
@params = {user: student1}
allow(controller).to receive(:params).and_return(@params)
expect{controller.auto_complete_for_user_name}.to raise_error(ActionView::Template::Error)
end

it 'checks if get auto_complete redirects to test host' do
stub_current_user(student1, student1.role.name, student1.role)
session = { user: student1 }
@params = {user: student1}
allow(controller).to receive(:params).and_return(@params)
get :auto_complete_for_user_name, @params, session
expect(response).to redirect_to("http://test.host/")
end
end
</pre>

=== destroy ===
<pre>
context '#destroy' do

it 'check if user was successfully destroyed' do
allow(User).to receive(:find).with(any_args).and_return(student1)
allow(AssignmentParticipant).to receive(:delete).with(any_args).and_return(true)
allow(TeamsUser).to receive(:delete).with(any_args).and_return(true)
allow(AssignmentQuestionnaire).to receive(:destroy).with(any_args).and_return(true)
allow(User).to receive(:destroy).with(any_args).and_return(true)
post :destroy
expect(flash[:note]).to be_present
end

it 'check if user was not successfully destroyed' do
allow(User).to receive(:find).with(any_args).and_return(nil)
allow(AssignmentParticipant).to receive(:delete).with(any_args).and_return(true)
allow(TeamsUser).to receive(:delete).with(any_args).and_return(true)
allow(AssignmentQuestionnaire).to receive(:destroy).with(any_args).and_return(true)
allow(User).to receive(:destroy).with(any_args).and_return(true)
post :destroy
expect(flash[:error]).to be_present
end

it 'check if successful destroy leads to redirect' do
allow(User).to receive(:find).with(any_args).and_return(student1)
allow(AssignmentParticipant).to receive(:delete).with(any_args).and_return(true)
allow(TeamsUser).to receive(:delete).with(any_args).and_return(true)
allow(AssignmentQuestionnaire).to receive(:destroy).with(any_args).and_return(true)
allow(User).to receive(:destroy).with(any_args).and_return(true)
post :destroy
expect(response).to redirect_to :action=> :list
end

it 'check if error during destroy leads to redirect' do
allow(User).to receive(:find).with(any_args).and_return(nil)
allow(AssignmentParticipant).to receive(:delete).with(any_args).and_return(true)
allow(TeamsUser).to receive(:delete).with(any_args).and_return(true)
allow(AssignmentQuestionnaire).to receive(:destroy).with(any_args).and_return(true)
allow(User).to receive(:destroy).with(any_args).and_return(true)
post :destroy
expect(response).to redirect_to :action=> :list
end
end
</pre>

=== role ===
<pre>
context '#edit' do

it 'checks if role renders through edit' do
new_student = User.new
new_student = student1
new_student.role_id = nil
allow(User).to receive(:find).with(any_args).and_return(new_student)
get :edit
expect(response).to render_template(:edit)
end

it 'checks if role fails through edit' do
new_student = User.new
new_student = student1
new_student.role_id = nil
allow(User).to receive(:find).with(any_args).and_return(new_student)
expect{controller.edit}.not_to raise_error
end
end
</pre>

=== paginate_list ===
<pre>
context '#list' do

it 'checks that paginate_list does not fail with controller' do
expect{controller.list}.not_to raise_error
end

it 'checks that paginate_list does not fail with post' do
post :list
expect(response.status).to eq(200)
end
end
</pre>

CSC/ECE 517 Spring 2022 - E2206: Testing for users controller

2022-03-21T20:31:32Z

Sbansal6: /* paginate_list */

== About Expertiza ==

[http://expertiza.ncsu.edu/ Expertiza] is the software benefits for both instructors and students by supporting various types of submissions and providing reusable objects for peer review. It is an open-source project based on [http://rubyonrails.org/ Ruby on Rails] framework. It allows the instructors not only to create and customize new or existing assignments but also to create a list of topics the students can sign up for. Students can form teams to work on various projects and assignments. Expertiza also lets students peer-review other students' submissions, enabling them to work together to improve others' learning experiences.

== Current Project Description ==

This Expertiza OSS project "E2206: Testing for users_controller" is focused on adding unit tests for users_controller.rb.

=== Files Involved ===

* users_controller.rb
* users_controller_spec.rb

=== Running Tests ===

<pre>
rspec ./spec/controllers/users_controller_spec.rb
</pre>

== Testing ==

users_controller had 5 methods for which unit tests were missing. The unit tests added for these methods in the spec file 'users_controller_spec.rb' are discussed below.

=== action_allowed? ===
Checks if a particular action is allowed when an action is called for the current user. Action is passed in the params. We stub a student, an instructor and an admin, and we check if only the admin has the right to perform that action. In this case we are testing the action list_pending_requested.

<pre>
context '#set_anonymized_view' do

it 'admin list_pending_requested' do
params = { action: 'list_pending_requested' }
allow(controller).to receive(:params).and_return(params)
expect(controller.action_allowed?).to be false
stub_current_user(student7, student7.role.name, student7.role)
allow(controller).to receive(:params).and_return(params)
expect(controller.action_allowed?).to be false
stub_current_user(instructor, instructor.role.name, instructor.role)
allow(controller).to receive(:params).and_return(params)
expect(controller.action_allowed?).to be false
stub_current_user(admin, admin.role.name, admin.role)
allow(controller).to receive(:params).and_return(params)
expect(controller.action_allowed?).to be true
end
end
</pre>

=== auto_complete_for_user_name ===
<pre>
context '#auto_complete_for_user_name' do

it 'checks if auto_complete returns actionview error' do
stub_current_user(student1, student1.role.name, student1.role)
session = { user: student1 }
@params = {user: student1}
allow(controller).to receive(:params).and_return(@params)
expect{controller.auto_complete_for_user_name}.to raise_error(ActionView::Template::Error)
end

it 'checks if get auto_complete redirects to test host' do
stub_current_user(student1, student1.role.name, student1.role)
session = { user: student1 }
@params = {user: student1}
allow(controller).to receive(:params).and_return(@params)
get :auto_complete_for_user_name, @params, session
expect(response).to redirect_to("http://test.host/")
end
end
</pre>

=== destroy ===
<pre>
context '#destroy' do

it 'check if user was successfully destroyed' do
allow(User).to receive(:find).with(any_args).and_return(student1)
allow(AssignmentParticipant).to receive(:delete).with(any_args).and_return(true)
allow(TeamsUser).to receive(:delete).with(any_args).and_return(true)
allow(AssignmentQuestionnaire).to receive(:destroy).with(any_args).and_return(true)
allow(User).to receive(:destroy).with(any_args).and_return(true)
post :destroy
expect(flash[:note]).to be_present
end

it 'check if user was not successfully destroyed' do
allow(User).to receive(:find).with(any_args).and_return(nil)
allow(AssignmentParticipant).to receive(:delete).with(any_args).and_return(true)
allow(TeamsUser).to receive(:delete).with(any_args).and_return(true)
allow(AssignmentQuestionnaire).to receive(:destroy).with(any_args).and_return(true)
allow(User).to receive(:destroy).with(any_args).and_return(true)
post :destroy
expect(flash[:error]).to be_present
end

it 'check if successful destroy leads to redirect' do
allow(User).to receive(:find).with(any_args).and_return(student1)
allow(AssignmentParticipant).to receive(:delete).with(any_args).and_return(true)
allow(TeamsUser).to receive(:delete).with(any_args).and_return(true)
allow(AssignmentQuestionnaire).to receive(:destroy).with(any_args).and_return(true)
allow(User).to receive(:destroy).with(any_args).and_return(true)
post :destroy
expect(response).to redirect_to :action=> :list
end

it 'check if error during destroy leads to redirect' do
allow(User).to receive(:find).with(any_args).and_return(nil)
allow(AssignmentParticipant).to receive(:delete).with(any_args).and_return(true)
allow(TeamsUser).to receive(:delete).with(any_args).and_return(true)
allow(AssignmentQuestionnaire).to receive(:destroy).with(any_args).and_return(true)
allow(User).to receive(:destroy).with(any_args).and_return(true)
post :destroy
expect(response).to redirect_to :action=> :list
end
end
</pre>

=== role ===
<pre>
context '#edit' do

it 'checks if role renders through edit' do
new_student = User.new
new_student = student1
new_student.role_id = nil
allow(User).to receive(:find).with(any_args).and_return(new_student)
get :edit
expect(response).to render_template(:edit)
end

it 'checks if role fails through edit' do
new_student = User.new
new_student = student1
new_student.role_id = nil
allow(User).to receive(:find).with(any_args).and_return(new_student)
expect{controller.edit}.not_to raise_error
end
end
</pre>

=== paginate_list ===
<pre>
context '#list' do

it 'checks that paginate_list does not fail with controller' do
expect{controller.list}.not_to raise_error
end

it 'checks that paginate_list does not fail with post' do
post :list
expect(response.status).to eq(200)
end
end
</pre>

CSC/ECE 517 Spring 2022 - E2206: Testing for users controller

2022-03-21T20:03:45Z

Sbansal6: /* action_allowed? */

CSC/ECE 517 Spring 2022 - E2206: Testing for users controller

2022-03-21T07:24:09Z

Sbansal6:

CSC/ECE 517 Spring 2022 - E2206: Testing for users controller

2022-03-21T05:31:54Z

Sbansal6: Created page with "== About Expertiza == [http://expertiza.ncsu.edu/ Expertiza] is the software benefits for both instructors and students by supporting various types of submissions and providi..."

CSC/ECE 517 Spring 2022

2022-03-21T04:32:41Z

Sbansal6: /* OSS Projects */

== OSS Projects ==

* [[CSC/ECE 517 Spring 2022 - E2203: Adding tests for courses_controller, eula_controller]]
* [[CSC/ECE 517 Spring 2022 - E2204: Adding tests for markup_styles_controller, lock_controller]]
* [[CSC/ECE 517 Spring 2022 - E2218: Refactor response_controller]]
* [[CSC/ECE 517 Spring 2022 - E2217: Refactor questionnaires_controller]]
* [[CSC/ECE 517 Spring 2022 - E2216: Refactor late_policies_controller]]
* [[CSC/ECE 517 Spring 2022 - E2215: Refactor student_quizzes_controller]]
* [[CSC/ECE 517 Spring 2022 - E2214: Refactor teams_controller]]
* [[CSC/ECE 517 Spring 2022 - E2219: Improve assessment360_controller.rb]]
* [[CSC/ECE 517 Spring 2022 - E2211: Testing for summary_helper]]
* [[CSC/ECE 517 Spring 2022 - E2214: Refactor review_mapping_helper.rb]]
* [[CSC/ECE 517 Spring 2022 - E2221: Refactor submitted content controller.rb]]
* [[CSC/ECE 517 Spring 2022 - E2206: Testing for users_controller]]

== Final Projects ==