Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2021 - E2167. Testing - Team Related Files

2021-11-30T05:26:11Z

Asmathew:

__TOC__

= Relevant links =
Github Repo : [https://github.com/MathewAaron/expertiza Repository]

= About Expertiza =
[http://expertiza.ncsu.edu/ Expertiza] is an open source project based on [http://rubyonrails.org/ Ruby on Rails] framework. It is a web based program that allows instructors to create and update/edit assignments/tasks, and then assigns them to students. Students then can submit, edit, and update their assignments, as well as peer review other student's assignments.

= Problem statement and background =
There are many files related to teams that don’t have enough tests: teams_controller, teams_users_controller, student_teams_controller, join_team_requests_controller, and advertise_for_partner_controller. They all need essentially the same kind of fixtures or mocks to enable testing: A team that is created, a couple of students that can be added to the team, an invitation that can be sent from one student to another student to join a particular team

= Approach Chosen & Why? =
In this project we have first identified all the set of scenarios related to team controllers. Each of the scenarios are identified as mentioned above and has been subdivided into a number of ways in which it can be realized. This will ensure that code is robust to any kind of unexpected changes and that the functionality will not be broken when deployed in production.
We have chosen to bring about this robustness of test by writing unit test and functional tests using RSpec and Capybara respectively. Unit Tests will ensure that the particular functionality is being tested in a isolated setup which would even include the edge cases whereas the functional tests will ensure that this teams feature is in resonance with the other features and works coherently.

= Implementation =

=== teams_shared.rb ===

# This controller can be found in spec/support
# It has all shared methods to be included in Teams related files.
==== Method 1- Declared common stubbed objects ====

shared_context 'object initializations' do
let(:superadmin) { build_stubbed(:superadmin) }
let(:admin) { build_stubbed(:admin) }
let(:instructor) { build_stubbed(:instructor, id: 1) }
let(:ta) { build_stubbed(:teaching_assistant) }
let(:student1) { build_stubbed(:student, id: 1, name: 'student2065') }
let(:student2) { build_stubbed(:student, id: 2) }
let(:course1) { build_stubbed(:course, name: 'TestCourse', id:1, instructor_id: instructor.id) }
let(:assignment1) { build_stubbed(:assignment, name: 'TestAssignment', id: 1) }
let(:team1) { build_stubbed(:assignment_team, id: 1, name: 'wolfers',parent_id: assignment1.id) }
let(:team2) { build_stubbed(:assignment_team, id: 2, parent_id: assignment1.id) }
let(:team3) { build_stubbed(:assignment_team, id: 3, parent_id: assignment1.id) }
let(:team4) { build_stubbed(:assignment_team, id: 4, parent_id: assignment1.id) }
let(:team5) { build_stubbed(:course_team, id: 5, parent_id: course1.id) }
let(:team6) { build_stubbed(:course_team, id: 6, parent_id: course1.id) }
let(:team7) { build_stubbed(:assignment_team, name: 'test', parent_id: course1.id) }
let(:join_team_request1) { build_stubbed(:join_team_request, id: 1, team_id: team1.id, status: 'P') }
let(:join_team_request2) { build_stubbed(:join_team_request, id: 2, team_id: team2.id, status: 'P',comments: "Any comment") }
let(:join_team_request3) { build_stubbed(:join_team_request, id: 3, team_id: team2.id, status: 'D',comments: "Updated") }
let(:invalidrequest) { build_stubbed(:join_team_request) }
let(:participant) { build_stubbed(:participant, id: 1) }
let(:node1) { build_stubbed(:assignment_node, node_object_id: 1) }
let(:team_user1) { build_stubbed(:team_user, team_id:1, user_id:1)}

==== Method 2 - Action_allowed?: It gives access permission to different users ====

shared_context 'authorization check', :shared_context => :metadata do
# Testing to check Instructor access
it 'superadmin credentials' do
stub_current_user(superadmin, superadmin.role.name, superadmin.role)
expect(controller.send(:action_allowed?)).to be true
end
# Testing to check Admin access
it 'admin credentials' do
stub_current_user(admin, admin.role.name, admin.role)
expect(controller.send(:action_allowed?)).to be true
end
# Testing to check TA access
it 'ta credentials' do
stub_current_user(ta, ta.role.name, ta.role)
expect(controller.send(:action_allowed?)).to be true
end
# Testing to check Instructor access
it 'instructor credentials' do
stub_current_user(instructor, instructor.role.name, instructor.role)
expect(controller.send(:action_allowed?)).to be true
end

==== How to use this shared file? ====
# Add a require statement:
require './spec/support/teams_shared.rb'
# Add include_context statements in the controller.
include_context "object initializations"
include_context 'authorization check'
# Why this file? - There are a lot of methods common in the Teams Related Files, they basically use similar / same stubbed objects and methods. Implementing the teams_shared.rb file keeps the code DRY and makes use of good design principles.


=== teams_controller.rb ===
==== How to run the test? ====
rspec spec/controllers/teams_controller.rb

==== Scenario 1: Create teams with random names ====

# After checking for the team type and team size, call function to randomize the teams
# Print message "Random teams have been successfully created."
# Redirect to list of teams


describe 'create teams method' do
context 'when everything is right' do
it 'creates teams with random names' do
allow(Object).to receive_message_chain(:const_get, :find).with(any_args).and_return(assignment1)
allow(Version).to receive_message_chain(:where, :last).with(any_args).and_return(0.1)
para = {id: assignment1.id, team_size: 2}
session = {user: instructor, team_type: "Assignment"}
result = get :create_teams, para, session
expect(result.status).to eq 302
expect(result).to redirect_to(:action => 'list', :id => assignment1.id)
end
end
end


==== Scenario 2: List the teams assignment wise or course wise ====

# Check the team type passed in params to see if it is Assignment or Course type
# Get the teams belonging to that Assignment or Course and list them all


describe 'list method' do
before(:each) { allow(Assignment).to receive(:find_by).and_return(assignment1) }
context 'when type is Assignment' do
it 'lists the teams for that Assignment' do
params = {id: assignment1.id, type: 'Assignment'}
session = {user: instructor}
result = get :list, params, session
expect(result.status).to eq 200
expect(controller.instance_variable_get(:@assignment)).to eq assignment1
end
end
context 'when type is Course' do
it 'lists the teams for that Course' do
params = {id: course1.id, type: 'Course'}
session = {user: instructor}
result = get :list, params, session
expect(result.status).to eq 200
expect(controller.instance_variable_get(:@assignment)).to eq nil
end
end
context 'when type is wrong' do
it 'throws error' do
params = {id: 52, type: 'Subject'}
session = {user: instructor}
result = get :list, params, session
expect(result.status).to eq 200
expect(controller.instance_variable_get(:@assignment)).to eq nil
end
end
end


==== Scenario 3: Create a new empty team ====

# Check if a team already exists with the same name
# If it doesn’t, create a new team with a name
# If a team is created, print "The team <team_name> has been successfully created."
# Redirect to list team page
# If error is there, fail to create a new team and redirect to new team form page


describe 'new method' do
it 'creates a new team successfully when all parameters are provided correctly' do
allow(Object).to receive_message_chain(:const_get, :find).with(any_args).and_return(assignment1)
para = {id: assignment1.id}
session = {user: ta, team_type: 'Assignment'}
result = get :new, para, session
expect(result.status).to eq 200
expect(controller.instance_variable_get(:@parent)).to eq assignment1
end
end


==== Scenario 4: Update an existing team ====

# Check if a team with new suggested name already exists
# If it doesn’t, update and save the new team name
# Print "The team <new_team_name> has been successfully updated."
# Redirect to list team page
# If error is there, fail to update team and redirect to edit team form page


describe 'update method' do
it 'updates the team name' do
allow(Team).to receive(:find).and_return(team1)
allow(Assignment).to receive(:find).and_return(assignment1)
para = { id: team1.id, team: {name: 'rando team'}}
session = {user: ta, team_type: 'Assignment'}
result = get :update, para, session
expect(result.status).to eq 302
expect(result).to redirect_to(:action => 'list', :id => assignment1.id)
end
# this test will fail even though it should normally pass, that's because it runs into an error at @team.save
# RumtimeError: stubbed models are not allowed to access the database - AssignmentTeam#save()
end


==== Scenario 5: Delete a team ====

# Check if there is a team in waitlist for the topic that the team to be deleted holds
# If there is a team on the waitlist, assign the topic to that team. If multiple teams are there, assign the topic to the first team in the waitlist.
# Delete the team’s records in team, teams_users and sign_up_team tables
# Print “"The team <team_name> has been successfully deleted."


describe 'delete method' do
before(:each) { request.env['HTTP_REFERER'] = root_url }
context 'when called and team is nil' do
it 'simply redirects' do
allow(Team).to receive(:find_by).and_return(nil)
para = {id: 5}
session = {user: instructor}
result = get :delete, para, session
expect(result.status).to eq 302
expect(result).to redirect_to :back
expect(controller.instance_variable_get(:@team)).to eq nil
end
end
context 'when called and team is not nil and it does not hold a topic' do
it 'deletes the team' do
allow(Team).to receive(:find_by).and_return(team5)
allow(Object).to receive_message_chain(:const_get, :find).and_return(course1)
allow(team5).to receive(:destroy).and_return(nil)
para = {id: 5}
session = {user: instructor, team_type: 'CourseTeam'}
result = get :delete, para, session
expect(result.status).to eq 302
expect(controller.instance_variable_get(:@team)).to eq team5
end
end
end


==== Scenario 6: Copy existing teams from a course down to an assignment ====

# Find the course that the assignment belongs to
# If a course for the assignment doesn’t exist, give the error message "No course was found for this assignment."
# Otherwise fetch all the teams that exist in the course
# If no teams exist, give the error message "No teams were found when trying to inherit."
# Else copy all teams and assign them the new assignment id


describe 'inherit method' do
context 'called when assignment belongs to course and team is not empty' do
it 'runs successfully' do
allow(Assignment).to receive(:find).and_return(assignment1)
allow(Course).to receive(:find).and_return(course1)
allow(course1).to receive(:get_teams).and_return([team5, team6])
para = {id: team5.id}
session = {user: ta}
result = get :inherit, para, session
expect(result.status).to eq 302
expect(result).to redirect_to(:controller => 'teams', :action => 'list', :id => assignment1.id)
end
end
context 'called when assignment belongs to course but team is empty' do
it 'flashes note' do
allow(Assignment).to receive(:find).and_return(assignment1)
allow(Course).to receive(:find).and_return(course1)
para = {id: team5.id}
session = {user: ta}
result = get :inherit, para, session
expect(result.status).to eq 302
expect(result).to redirect_to(:controller => 'teams', :action => 'list', :id => assignment1.id)
end
end
context 'called when assignment belongs to no course' do
let(:fasg) { build_stubbed(:assignment, id: 1074, course_id: -2) }
# a temporary assigment object is created with an abnormal course_id so that we can check the fail condition of the method
it 'flashes error' do
allow(Assignment).to receive(:find).and_return(fasg)
allow(Course).to receive(:find).and_return(course1)
para = {id: team5.id}
session = {user: ta}
result = get :inherit, para, session
expect(result.status).to eq 302
expect(result).to redirect_to(:controller => 'teams', :action => 'list', :id => fasg.id)
end
end
end


==== Scenario 7: Copy existing team from assignment to course ====

# Find the assignment id to which the team belongs
# Find the course to which the assignment belongs
# If assignment doesn’t belong to a course, give the error message "This assignment is not <assignment_name> with a course."
# Otherwise copy team from assignment and assign it the course id
# Print success message "The team <team_name> was successfully copied to <course_name>"
# Redirect to list page


describe 'bequeath method' do
context 'called when assignment has a course' do
it 'runs successfully' do
allow(AssignmentTeam).to receive(:find).and_return(team2)
allow(Assignment).to receive(:find).and_return(assignment1)
allow(Course).to receive(:find).and_return(course1)
para = {id: team2.id}
session = {user: ta}
result = get :bequeath, para, session
expect(result.status).to eq 302
expect(result).to redirect_to(:controller => 'teams', :action => 'list', :id => assignment1.id)
end
end
context 'called when assignment does not have a course' do
let(:fasg) { build_stubbed(:assignment, id: 1074, course_id: -2) }
# a temporary assigment object is created with an abnormal course_id so that we can check the fail condition of the method
it 'fails' do
allow(AssignmentTeam).to receive(:find).and_return(team2)
allow(Assignment).to receive(:find).and_return(fasg)
para = {id: team2.id}
session = {user: ta}
result = get :bequeath, para, session
expect(result.status).to eq 302
expect(result).to redirect_to(:controller => 'teams', :action => 'list', :id => fasg.id)
end
end
end


==== Scenario 8: Edit method ====

# Find the team with the 'id' present in params


describe 'edit method' do
it 'passes the test' do
allow(Team).to receive(:find).and_return(team1)
para = {id: team1.id}
session = {user: ta}
result = get :edit, para, session
expect(result.status).to eq 200
expect(controller.instance_variable_get(:@team)).to eq team1
end
# this method has only 1 line which is just to look up a team with the id present in the params
end


==== Scenario 9: Create an empty team ====

# Find the parent (Assignment or Course) based on the team type which starts the session
# It checks whether a team with the same exists in that category
# If team exists, it throws TeamExistsError and redirects to 'new' team form page
# If team doesn't exist, it creates a new team
# Successful message is displayed and user is redirected to 'list' teams page


describe 'create method' do
context 'when invoked with a team which does not exist' do
it 'creates it' do
allow(Assignment).to receive(:find).and_return(assignment1)
para = { id: assignment1.id, team: {name: 'rando team'}}
session = {user: ta, team_type: 'Assignment'}
result = get :create, para, session
expect(result.status).to eq 302
expect(result).to redirect_to(:action => 'list', :id => assignment1.id)
end
end
end


==== Test Pass/ Fail ====
[[File:E2167 Teams test.PNG]]

==== Coverage ====
[[File:E2167 Teams controller.PNG]]

=== teams_users_controller.rb ===

====Scenario 1: Add new user to the selected team.====

#Given user is not defined: When given user is defined, link is provided to create the user.
#Selected team to which user is being added belongs to an assignment: When user is not a participant of the assignment, link is provided to add the user to the assignment. When the assignment team already has maximum number of users, "Maximum users reached" notification is flashed.
#Selected team to which user is being added belongs to a course: When user is not a participant of the course, link is provided to add the user to the course. When the course team already has maximum number of users, "Maximum users reached" notification is flashed.


[[File:user_create.png|600px]]

====Scenario 2: Delete user from the selected team.====

#User under assignment or course team is deleted: user association to the respective team is deleted and hence user is no longer part of the team.


[[File:user_remove.png]]

[[File:Team stud remove.png]]

=== student_teams_controller.rb ===

==== Scenario 1: Set the variables for view ====

#If the current user is student and their User Ids match, then the following values are set: @send_invs, @received_invs, @current_due_date, @users_on_waiting_list, @teammate_review_allowed
# If the current user is not student or the User Ids do not match, then the return from method.


==== Scenario 2: Create Student teams ====

# If team name is empty, flash an error message saying "Team name missing while creating team" and redirect to view_student_teams_path
# If team name is not empty and team name already in use, "Team name being created was already in use" and redirect to view_student_teams_path
# If team name is not empty and team name not in use, save team data, add logged in student to team and redirect to view_student_teams_path.

[[File:Team stud create.png]]

==== Scenario 3: Update team name: ====

# Find the team that should be updated.
# If there are no matching teams, call team_created_successfully and redirect to view_student_teams_path
# If there is exactly one match, then call team_created_successfully and redirect to view_student_teams_path
# If there are more than one team, then show the following error message "Team name being updated to was already in use" and redirect to edit_student_teams_path.

[[File:Team student update.png]]

==== Scenario 4: Remove team participants ====

# Find the user who has to be removed.
# Remove the user from team.
# If the team does not have any more participants, remove the team record from database.
# If the assignment has sign up sheet, then add the topic back to topics pool or assign the topic to a new team from waitlist
# Remove all the invitations sent and redirect to view_student_teams_path.


=== join_team_requests_controller.rb ===

P = Pending status 
D = Denied status 
A = Accepted status
# Test the controller :
rspec spec/controllers/join_team_request_controller_spec.rb


==== Scenario 1: Creating a team request ====

# If the team id is verified along with user id and assignment id, create a new request and change @join_team_request = 'P' .
# If error occurs, flash error message.


describe "POST #create" do
before(:each) do
# Stubbing participant to receive an object with id = 1
allow(Participant).to receive(:find).with("1").and_return(participant)
end
context "when resource is not saved!" do
it "renders new page" do
allow(JoinTeamRequest).to receive(:new).and_return(invalidrequest)
params = {participant_id: participant.id, team_id: -2}
session = {user: student1}
get :new, params, session
expect(response).to render_template("new")
end
end
# Testing when the object is being saved to the database
context "when resource is saved" do
before(:each) do
allow(JoinTeamRequest).to receive(:new).and_return(join_team_request2)
allow(Team).to receive(:find).with("1").and_return(team1)
allow(Assignment).to receive(:find).with(1).and_return(assignment1)
allow(Participant).to receive(:where).with(user_id: 1,parent_id: '1').and_return([participant])
allow(join_team_request2).to receive(:save).and_return(true)
end
it "valid response" do
allow(join_team_request2).to receive(:save).and_return(true)
params = {
id: 2,
join_team_request2: {
status: 'P'
},
team_id: 1,
assignment_id: 1
}
session = {user: student1}
post :create, params, session
expect(response.status).to eq 302
expect(join_team_request2.status).to eq('P')
end
end
context "when it is not created" do
it "will page for new " do
allow(join_team_request2).to receive(:save).and_return(false)
params = {action: 'new'}
session = {user: student1}
get :new, params, session
expect(response.status).to eq 200
end
end
end

==== Scenario 2: Decline a team request. ====

# After verifying team_user_id, change @join_team_request.status = 'D' .
# Redirect to view_student_teams_path

describe "#decline" do
context "when join team request is declined" do
before(:each) do
allow(JoinTeamRequest).to receive(:find).and_return(join_team_request2)
allow(join_team_request2).to receive(:save).and_return(true)
end
it "will change status to 'D'" do
params = {action: 'decline'}
session = {user: ta}
result = get :decline, params, session
expect(result.status).to eq 302
end
it "will redirect to view student teams path" do
params = {action: 'decline'}
session = {user: ta}
result = get :decline, params, session
expect(result).to redirect_to(view_student_teams_path)
end
end
end



==== Scenario 3: Check team status. ====

# Since this method is private there is no test case written for it.
# If team if full. Print error message "This team is full." .
# If team is not empty, print message "You are already a member of this team."


==== Coverage ====
[[File:E2167 JoinTeamRequest coverage.PNG]]


==== Test Pass/ Fail ====

# All tests, except 1 pass.
# The test that fails is for the "get index" method. We have identified that there is no route the view/index is going to.
def respond_after(request)
respond_to do |format|
format.html
format.xml { render xml: request }
end
end

[[File:E2167 JoinTeamRequest test.PNG]]


=== advertise_partner_controller.rb ===
==== Scenario 1: Creating new advertisement for partners. ====

# We set the advertise_for_partner : True , comments_for_advertisement[param] when the user wants to set a new advertisement for partners in AssignmentTeam model.

describe "POST #create" do

context "when it is valid" do
it "will create an advertisement" do
allow(AssignmentTeam).to receive(:find_by).and_return(team1)
allow(AssignmentParticipant).to receive(:exists?).and_return(true)
allow(team1).to receive(:assignment).and_return(assignment1)
allow(team1).to receive(:update_attributes).and_return(true)
allow(AssignmentParticipant).to receive(:find_by).and_return(participant)

params = {
id: team1.id,
team_id: team1.id,
}
session = {user: ta}
result = get :create, params, session
expect(result.status).to eq 302
expect(result).to redirect_to(view_student_teams_path(:student_id => 1))
end
end
end


[[File:Teams adv1.png]]

==== Scenario 2: Updating the advertisement. ====

# We set the comments_for_advertisement[param] when the user wants to set a new advertisement for partners in AssignmentTeam model.
# Update Unsuccessful : If there is an error during update then the following error message is thrown "An error occurred and your advertisement was not updated." and edit page is rendered.
# Update Successful : If the advertisement is successfully updated in the database then the "Your advertisement was successfully updated!" message is prompted and the user is redirected to the view_student_teams_path.

context "when advertisement is updated" do
it "the advertisement is updated" do
allow(AssignmentTeam).to receive(:find_by).and_return(team1)
allow(AssignmentParticipant).to receive(:exists?).and_return(true)
allow(team1).to receive(:assignment).and_return(assignment1)
allow(team1).to receive(:update_attributes).and_return(true)
allow(AssignmentParticipant).to receive(:find_by).and_return(participant)

params = {
id: team1.id,
team_id: team1.id,
}
session = {user: ta}
result = get :update, params, session
expect(result.status).to eq 302
expect(result).to redirect_to(view_student_teams_path(:student_id => 1))
end
it "the advertisement is not updated due to error" do
allow(AssignmentTeam).to receive(:find_by).and_return(team1)
allow(AssignmentParticipant).to receive(:exists?).and_return(true)
allow(team1).to receive(:assignment).and_return(assignment1)
allow(AssignmentParticipant).to receive(:find_by).and_return(participant)
allow(team1).to receive(:update_attributes).and_raise(StandardError)
params = {
id: team1.id,
team_id: team1.id,
}
session = {user: ta}
result = get :update, params, session
expect(flash[:error]).to eq "An error occurred and your advertisement was not updated!"
expect(result.status).to eq 200
end
end
end



[[File:Teams adv create.png]]

==== Scenario 3: Remove the advertisement. ====

# We set the advertise_for_partner : False , comments_for_advertisement : nil when the user wants to set a new advertisement for partners in AssignmentTeam model.
# Remove Unsuccessful : If there is an error during removing the advertisement then the following error message is thrown "An error occurred and your advertisement was not removed." and the previous page is rendered.
# Remove Successful : If the advertisement is successfully removed in the database then the "Your advertisement was successfully removed!" message is prompted and the user is redirected to the view_student_teams_path.

describe "POST #remove" do

context "when advertisement is removed" do
it "the advertisement is removed" do
allow(AssignmentTeam).to receive(:find_by).and_return(team1)
allow(AssignmentParticipant).to receive(:exists?).and_return(true)
allow(team1).to receive(:assignment).and_return(assignment1)
allow(team1).to receive(:update_attributes).and_return(true)
allow(AssignmentParticipant).to receive(:find_by).and_return(participant)

params = {
id: team1.id,
team_id: team1.id,
}
session = {user: ta}
result = get :remove, params, session
expect(result.status).to eq 302
expect(result).to redirect_to(view_student_teams_path(:student_id => 1))
end
it "the advertisement is not removed due to error" do
allow(AssignmentTeam).to receive(:find_by).and_return(team1)
allow(AssignmentParticipant).to receive(:exists?).and_return(true)
allow(team1).to receive(:assignment).and_return(assignment1)
allow(AssignmentParticipant).to receive(:find_by).and_return(participant)
allow(team1).to receive(:update_attributes).and_raise(StandardError)
params = {
id: team1.id,
team_id: team1.id,
}
session = {user: ta}
result = get :remove, params, session
expect(flash[:error]).to eq "An error occurred and your advertisement was not removed!"
expect(result).to redirect_to(request.env['HTTP_REFERER'] ? :back : (:root))
end
end
end


[[File:Teams adv remove.png]]

==== Coverage. ====
[[File:E2167 AdvertisePartner.PNG]]

==== Coverage ====
[[File:E2127 Advertise run file.PNG]]

= Old Page Link =

We have created a new page due to a title error at the new one.
Link to the old page : https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2126._Testing_-_Team_Related_Files#Description_about_project


==== Github Coverage ====
[[File:E2167 JoinTeamRequest git.PNG]]

= Our Team =

Yi Qiu (mentor) 
Aaron Mathew (asmathew@ncsu.edu) 
Priya Jakhar (pjakhar@ncsu.edu) 
Supriya Krishna (sbkrishn@ncsu.edu) 
Snehapriyaa Mathiyalaghan (smathiy@ncsu.edu)

CSC/ECE 517 Fall 2021 - E2167. Testing - Team Related Files

2021-11-30T05:25:24Z

Asmathew:

__TOC__

= Relevant links =
Github Repo : [https://github.com/MathewAaron/expertiza Repository]

= About Expertiza =
[http://expertiza.ncsu.edu/ Expertiza] is an open source project based on [http://rubyonrails.org/ Ruby on Rails] framework. It is a web based program that allows instructors to create and update/edit assignments/tasks, and then assigns them to students. Students then can submit, edit, and update their assignments, as well as peer review other student's assignments.

= Problem statement and background =
There are many files related to teams that don’t have enough tests: teams_controller, teams_users_controller, student_teams_controller, join_team_requests_controller, and advertise_for_partner_controller. They all need essentially the same kind of fixtures or mocks to enable testing: A team that is created, a couple of students that can be added to the team, an invitation that can be sent from one student to another student to join a particular team

= Approach Chosen & Why? =
In this project we have first identified all the set of scenarios related to team controllers. Each of the scenarios are identified as mentioned above and has been subdivided into a number of ways in which it can be realized. This will ensure that code is robust to any kind of unexpected changes and that the functionality will not be broken when deployed in production.
We have chosen to bring about this robustness of test by writing unit test and functional tests using RSpec and Capybara respectively. Unit Tests will ensure that the particular functionality is being tested in a isolated setup which would even include the edge cases whereas the functional tests will ensure that this teams feature is in resonance with the other features and works coherently.

= Implementation =

=== teams_shared.rb ===

# This controller can be found in spec/support
# It has all shared methods to be included in Teams related files.
==== Method 1- Declared common stubbed objects ====

shared_context 'object initializations' do
let(:superadmin) { build_stubbed(:superadmin) }
let(:admin) { build_stubbed(:admin) }
let(:instructor) { build_stubbed(:instructor, id: 1) }
let(:ta) { build_stubbed(:teaching_assistant) }
let(:student1) { build_stubbed(:student, id: 1, name: 'student2065') }
let(:student2) { build_stubbed(:student, id: 2) }
let(:course1) { build_stubbed(:course, name: 'TestCourse', id:1, instructor_id: instructor.id) }
let(:assignment1) { build_stubbed(:assignment, name: 'TestAssignment', id: 1) }
let(:team1) { build_stubbed(:assignment_team, id: 1, name: 'wolfers',parent_id: assignment1.id) }
let(:team2) { build_stubbed(:assignment_team, id: 2, parent_id: assignment1.id) }
let(:team3) { build_stubbed(:assignment_team, id: 3, parent_id: assignment1.id) }
let(:team4) { build_stubbed(:assignment_team, id: 4, parent_id: assignment1.id) }
let(:team5) { build_stubbed(:course_team, id: 5, parent_id: course1.id) }
let(:team6) { build_stubbed(:course_team, id: 6, parent_id: course1.id) }
let(:team7) { build_stubbed(:assignment_team, name: 'test', parent_id: course1.id) }
let(:join_team_request1) { build_stubbed(:join_team_request, id: 1, team_id: team1.id, status: 'P') }
let(:join_team_request2) { build_stubbed(:join_team_request, id: 2, team_id: team2.id, status: 'P',comments: "Any comment") }
let(:join_team_request3) { build_stubbed(:join_team_request, id: 3, team_id: team2.id, status: 'D',comments: "Updated") }
let(:invalidrequest) { build_stubbed(:join_team_request) }
let(:participant) { build_stubbed(:participant, id: 1) }
let(:node1) { build_stubbed(:assignment_node, node_object_id: 1) }
let(:team_user1) { build_stubbed(:team_user, team_id:1, user_id:1)}

==== Method 2 - Action_allowed?: It gives access permission to different users ====

shared_context 'authorization check', :shared_context => :metadata do
# Testing to check Instructor access
it 'superadmin credentials' do
stub_current_user(superadmin, superadmin.role.name, superadmin.role)
expect(controller.send(:action_allowed?)).to be true
end
# Testing to check Admin access
it 'admin credentials' do
stub_current_user(admin, admin.role.name, admin.role)
expect(controller.send(:action_allowed?)).to be true
end
# Testing to check TA access
it 'ta credentials' do
stub_current_user(ta, ta.role.name, ta.role)
expect(controller.send(:action_allowed?)).to be true
end
# Testing to check Instructor access
it 'instructor credentials' do
stub_current_user(instructor, instructor.role.name, instructor.role)
expect(controller.send(:action_allowed?)).to be true
end

==== How to use this shared file? ====
# Add a require statement:
require './spec/support/teams_shared.rb'
# Add include_context statements in the controller.
include_context "object initializations"
include_context 'authorization check'
# Why this file? - There are a lot of methods common in the Teams Related Files, they basically use similar / same stubbed objects and methods. Implementing the teams_shared.rb file keeps the code DRY and makes use of good design principles.


=== teams_controller.rb ===
==== How to run the test? ====
rspec spec/controllers/teams_controller.rb

==== Scenario 1: Create teams with random names ====

# After checking for the team type and team size, call function to randomize the teams
# Print message "Random teams have been successfully created."
# Redirect to list of teams


describe 'create teams method' do
context 'when everything is right' do
it 'creates teams with random names' do
allow(Object).to receive_message_chain(:const_get, :find).with(any_args).and_return(assignment1)
allow(Version).to receive_message_chain(:where, :last).with(any_args).and_return(0.1)
para = {id: assignment1.id, team_size: 2}
session = {user: instructor, team_type: "Assignment"}
result = get :create_teams, para, session
expect(result.status).to eq 302
expect(result).to redirect_to(:action => 'list', :id => assignment1.id)
end
end
end


==== Scenario 2: List the teams assignment wise or course wise ====

# Check the team type passed in params to see if it is Assignment or Course type
# Get the teams belonging to that Assignment or Course and list them all


describe 'list method' do
before(:each) { allow(Assignment).to receive(:find_by).and_return(assignment1) }
context 'when type is Assignment' do
it 'lists the teams for that Assignment' do
params = {id: assignment1.id, type: 'Assignment'}
session = {user: instructor}
result = get :list, params, session
expect(result.status).to eq 200
expect(controller.instance_variable_get(:@assignment)).to eq assignment1
end
end
context 'when type is Course' do
it 'lists the teams for that Course' do
params = {id: course1.id, type: 'Course'}
session = {user: instructor}
result = get :list, params, session
expect(result.status).to eq 200
expect(controller.instance_variable_get(:@assignment)).to eq nil
end
end
context 'when type is wrong' do
it 'throws error' do
params = {id: 52, type: 'Subject'}
session = {user: instructor}
result = get :list, params, session
expect(result.status).to eq 200
expect(controller.instance_variable_get(:@assignment)).to eq nil
end
end
end


==== Scenario 3: Create a new empty team ====

# Check if a team already exists with the same name
# If it doesn’t, create a new team with a name
# If a team is created, print "The team <team_name> has been successfully created."
# Redirect to list team page
# If error is there, fail to create a new team and redirect to new team form page


describe 'new method' do
it 'creates a new team successfully when all parameters are provided correctly' do
allow(Object).to receive_message_chain(:const_get, :find).with(any_args).and_return(assignment1)
para = {id: assignment1.id}
session = {user: ta, team_type: 'Assignment'}
result = get :new, para, session
expect(result.status).to eq 200
expect(controller.instance_variable_get(:@parent)).to eq assignment1
end
end


==== Scenario 4: Update an existing team ====

# Check if a team with new suggested name already exists
# If it doesn’t, update and save the new team name
# Print "The team <new_team_name> has been successfully updated."
# Redirect to list team page
# If error is there, fail to update team and redirect to edit team form page


describe 'update method' do
it 'updates the team name' do
allow(Team).to receive(:find).and_return(team1)
allow(Assignment).to receive(:find).and_return(assignment1)
para = { id: team1.id, team: {name: 'rando team'}}
session = {user: ta, team_type: 'Assignment'}
result = get :update, para, session
expect(result.status).to eq 302
expect(result).to redirect_to(:action => 'list', :id => assignment1.id)
end
# this test will fail even though it should normally pass, that's because it runs into an error at @team.save
# RumtimeError: stubbed models are not allowed to access the database - AssignmentTeam#save()
end


==== Scenario 5: Delete a team ====

# Check if there is a team in waitlist for the topic that the team to be deleted holds
# If there is a team on the waitlist, assign the topic to that team. If multiple teams are there, assign the topic to the first team in the waitlist.
# Delete the team’s records in team, teams_users and sign_up_team tables
# Print “"The team <team_name> has been successfully deleted."


describe 'delete method' do
before(:each) { request.env['HTTP_REFERER'] = root_url }
context 'when called and team is nil' do
it 'simply redirects' do
allow(Team).to receive(:find_by).and_return(nil)
para = {id: 5}
session = {user: instructor}
result = get :delete, para, session
expect(result.status).to eq 302
expect(result).to redirect_to :back
expect(controller.instance_variable_get(:@team)).to eq nil
end
end
context 'when called and team is not nil and it does not hold a topic' do
it 'deletes the team' do
allow(Team).to receive(:find_by).and_return(team5)
allow(Object).to receive_message_chain(:const_get, :find).and_return(course1)
allow(team5).to receive(:destroy).and_return(nil)
para = {id: 5}
session = {user: instructor, team_type: 'CourseTeam'}
result = get :delete, para, session
expect(result.status).to eq 302
expect(controller.instance_variable_get(:@team)).to eq team5
end
end
end


==== Scenario 6: Copy existing teams from a course down to an assignment ====

# Find the course that the assignment belongs to
# If a course for the assignment doesn’t exist, give the error message "No course was found for this assignment."
# Otherwise fetch all the teams that exist in the course
# If no teams exist, give the error message "No teams were found when trying to inherit."
# Else copy all teams and assign them the new assignment id


describe 'inherit method' do
context 'called when assignment belongs to course and team is not empty' do
it 'runs successfully' do
allow(Assignment).to receive(:find).and_return(assignment1)
allow(Course).to receive(:find).and_return(course1)
allow(course1).to receive(:get_teams).and_return([team5, team6])
para = {id: team5.id}
session = {user: ta}
result = get :inherit, para, session
expect(result.status).to eq 302
expect(result).to redirect_to(:controller => 'teams', :action => 'list', :id => assignment1.id)
end
end
context 'called when assignment belongs to course but team is empty' do
it 'flashes note' do
allow(Assignment).to receive(:find).and_return(assignment1)
allow(Course).to receive(:find).and_return(course1)
para = {id: team5.id}
session = {user: ta}
result = get :inherit, para, session
expect(result.status).to eq 302
expect(result).to redirect_to(:controller => 'teams', :action => 'list', :id => assignment1.id)
end
end
context 'called when assignment belongs to no course' do
let(:fasg) { build_stubbed(:assignment, id: 1074, course_id: -2) }
# a temporary assigment object is created with an abnormal course_id so that we can check the fail condition of the method
it 'flashes error' do
allow(Assignment).to receive(:find).and_return(fasg)
allow(Course).to receive(:find).and_return(course1)
para = {id: team5.id}
session = {user: ta}
result = get :inherit, para, session
expect(result.status).to eq 302
expect(result).to redirect_to(:controller => 'teams', :action => 'list', :id => fasg.id)
end
end
end


==== Scenario 7: Copy existing team from assignment to course ====

# Find the assignment id to which the team belongs
# Find the course to which the assignment belongs
# If assignment doesn’t belong to a course, give the error message "This assignment is not <assignment_name> with a course."
# Otherwise copy team from assignment and assign it the course id
# Print success message "The team <team_name> was successfully copied to <course_name>"
# Redirect to list page


describe 'bequeath method' do
context 'called when assignment has a course' do
it 'runs successfully' do
allow(AssignmentTeam).to receive(:find).and_return(team2)
allow(Assignment).to receive(:find).and_return(assignment1)
allow(Course).to receive(:find).and_return(course1)
para = {id: team2.id}
session = {user: ta}
result = get :bequeath, para, session
expect(result.status).to eq 302
expect(result).to redirect_to(:controller => 'teams', :action => 'list', :id => assignment1.id)
end
end
context 'called when assignment does not have a course' do
let(:fasg) { build_stubbed(:assignment, id: 1074, course_id: -2) }
# a temporary assigment object is created with an abnormal course_id so that we can check the fail condition of the method
it 'fails' do
allow(AssignmentTeam).to receive(:find).and_return(team2)
allow(Assignment).to receive(:find).and_return(fasg)
para = {id: team2.id}
session = {user: ta}
result = get :bequeath, para, session
expect(result.status).to eq 302
expect(result).to redirect_to(:controller => 'teams', :action => 'list', :id => fasg.id)
end
end
end


==== Scenario 8: Edit method ====

# Find the team with the 'id' present in params


describe 'edit method' do
it 'passes the test' do
allow(Team).to receive(:find).and_return(team1)
para = {id: team1.id}
session = {user: ta}
result = get :edit, para, session
expect(result.status).to eq 200
expect(controller.instance_variable_get(:@team)).to eq team1
end
# this method has only 1 line which is just to look up a team with the id present in the params
end


==== Scenario 9: Create an empty team ====

# Find the parent (Assignment or Course) based on the team type which starts the session
# It checks whether a team with the same exists in that category
# If team exists, it throws TeamExistsError and redirects to 'new' team form page
# If team doesn't exist, it creates a new team
# Successful message is displayed and user is redirected to 'list' teams page


describe 'create method' do
context 'when invoked with a team which does not exist' do
it 'creates it' do
allow(Assignment).to receive(:find).and_return(assignment1)
para = { id: assignment1.id, team: {name: 'rando team'}}
session = {user: ta, team_type: 'Assignment'}
result = get :create, para, session
expect(result.status).to eq 302
expect(result).to redirect_to(:action => 'list', :id => assignment1.id)
end
end
end


==== Test Pass/ Fail ====
[[File:E2167 Teams test.PNG]]

==== Coverage ====
[[File:E2167 Teams controller.PNG]]

=== teams_users_controller.rb ===

====Scenario 1: Add new user to the selected team.====

#Given user is not defined: When given user is defined, link is provided to create the user.
#Selected team to which user is being added belongs to an assignment: When user is not a participant of the assignment, link is provided to add the user to the assignment. When the assignment team already has maximum number of users, "Maximum users reached" notification is flashed.
#Selected team to which user is being added belongs to a course: When user is not a participant of the course, link is provided to add the user to the course. When the course team already has maximum number of users, "Maximum users reached" notification is flashed.


[[File:user_create.png|600px]]

====Scenario 2: Delete user from the selected team.====

#User under assignment or course team is deleted: user association to the respective team is deleted and hence user is no longer part of the team.


[[File:user_remove.png]]

[[File:Team stud remove.png]]

=== student_teams_controller.rb ===

==== Scenario 1: Set the variables for view ====

#If the current user is student and their User Ids match, then the following values are set: @send_invs, @received_invs, @current_due_date, @users_on_waiting_list, @teammate_review_allowed
# If the current user is not student or the User Ids do not match, then the return from method.


==== Scenario 2: Create Student teams ====

# If team name is empty, flash an error message saying "Team name missing while creating team" and redirect to view_student_teams_path
# If team name is not empty and team name already in use, "Team name being created was already in use" and redirect to view_student_teams_path
# If team name is not empty and team name not in use, save team data, add logged in student to team and redirect to view_student_teams_path.

[[File:Team stud create.png]]

==== Scenario 3: Update team name: ====

# Find the team that should be updated.
# If there are no matching teams, call team_created_successfully and redirect to view_student_teams_path
# If there is exactly one match, then call team_created_successfully and redirect to view_student_teams_path
# If there are more than one team, then show the following error message "Team name being updated to was already in use" and redirect to edit_student_teams_path.

[[File:Team student update.png]]

==== Scenario 4: Remove team participants ====

# Find the user who has to be removed.
# Remove the user from team.
# If the team does not have any more participants, remove the team record from database.
# If the assignment has sign up sheet, then add the topic back to topics pool or assign the topic to a new team from waitlist
# Remove all the invitations sent and redirect to view_student_teams_path.


=== join_team_requests_controller.rb ===

P = Pending status 
D = Denied status 
A = Accepted status
# Test the controller :
rspec spec/controllers/join_team_request_controller_spec.rb


==== Scenario 1: Creating a team request ====

# If the team id is verified along with user id and assignment id, create a new request and change @join_team_request = 'P' .
# If error occurs, flash error message.


describe "POST #create" do
before(:each) do
# Stubbing participant to receive an object with id = 1
allow(Participant).to receive(:find).with("1").and_return(participant)
end
context "when resource is not saved!" do
it "renders new page" do
allow(JoinTeamRequest).to receive(:new).and_return(invalidrequest)
params = {participant_id: participant.id, team_id: -2}
session = {user: student1}
get :new, params, session
expect(response).to render_template("new")
end
end
# Testing when the object is being saved to the database
context "when resource is saved" do
before(:each) do
allow(JoinTeamRequest).to receive(:new).and_return(join_team_request2)
allow(Team).to receive(:find).with("1").and_return(team1)
allow(Assignment).to receive(:find).with(1).and_return(assignment1)
allow(Participant).to receive(:where).with(user_id: 1,parent_id: '1').and_return([participant])
allow(join_team_request2).to receive(:save).and_return(true)
end
it "valid response" do
allow(join_team_request2).to receive(:save).and_return(true)
params = {
id: 2,
join_team_request2: {
status: 'P'
},
team_id: 1,
assignment_id: 1
}
session = {user: student1}
post :create, params, session
expect(response.status).to eq 302
expect(join_team_request2.status).to eq('P')
end
end
context "when it is not created" do
it "will page for new " do
allow(join_team_request2).to receive(:save).and_return(false)
params = {action: 'new'}
session = {user: student1}
get :new, params, session
expect(response.status).to eq 200
end
end
end

==== Scenario 2: Decline a team request. ====

# After verifying team_user_id, change @join_team_request.status = 'D' .
# Redirect to view_student_teams_path

describe "#decline" do
context "when join team request is declined" do
before(:each) do
allow(JoinTeamRequest).to receive(:find).and_return(join_team_request2)
allow(join_team_request2).to receive(:save).and_return(true)
end
it "will change status to 'D'" do
params = {action: 'decline'}
session = {user: ta}
result = get :decline, params, session
expect(result.status).to eq 302
end
it "will redirect to view student teams path" do
params = {action: 'decline'}
session = {user: ta}
result = get :decline, params, session
expect(result).to redirect_to(view_student_teams_path)
end
end
end



==== Scenario 3: Check team status. ====

# Since this method is private there is no test case written for it.
# If team if full. Print error message "This team is full." .
# If team is not empty, print message "You are already a member of this team."


==== Coverage ====
[[File:E2167 JoinTeamRequest coverage.PNG]]


==== Test Pass/ Fail ====

# All tests, except 1 pass.
# The test that fails is for the "get index" method. We have identified that there is no route the view/index is going to.
def respond_after(request)
respond_to do |format|
format.html
format.xml { render xml: request }
end
end

[[File:E2167 JoinTeamRequest test.PNG]]


=== advertise_partner_controller.rb ===
==== Scenario 1: Creating new advertisement for partners. ====

# We set the advertise_for_partner : True , comments_for_advertisement[param] when the user wants to set a new advertisement for partners in AssignmentTeam model.

describe "POST #create" do

context "when it is valid" do
it "will create an advertisement" do
allow(AssignmentTeam).to receive(:find_by).and_return(team1)
allow(AssignmentParticipant).to receive(:exists?).and_return(true)
allow(team1).to receive(:assignment).and_return(assignment1)
allow(team1).to receive(:update_attributes).and_return(true)
allow(AssignmentParticipant).to receive(:find_by).and_return(participant)

params = {
id: team1.id,
team_id: team1.id,
}
session = {user: ta}
result = get :create, params, session
expect(result.status).to eq 302
expect(result).to redirect_to(view_student_teams_path(:student_id => 1))
end
end
end


[[File:Teams adv1.png]]

==== Scenario 2: Updating the advertisement. ====

# We set the comments_for_advertisement[param] when the user wants to set a new advertisement for partners in AssignmentTeam model.
# Update Unsuccessful : If there is an error during update then the following error message is thrown "An error occurred and your advertisement was not updated." and edit page is rendered.
# Update Successful : If the advertisement is successfully updated in the database then the "Your advertisement was successfully updated!" message is prompted and the user is redirected to the view_student_teams_path.

context "when advertisement is updated" do
it "the advertisement is updated" do
allow(AssignmentTeam).to receive(:find_by).and_return(team1)
allow(AssignmentParticipant).to receive(:exists?).and_return(true)
allow(team1).to receive(:assignment).and_return(assignment1)
allow(team1).to receive(:update_attributes).and_return(true)
allow(AssignmentParticipant).to receive(:find_by).and_return(participant)

params = {
id: team1.id,
team_id: team1.id,
}
session = {user: ta}
result = get :update, params, session
expect(result.status).to eq 302
expect(result).to redirect_to(view_student_teams_path(:student_id => 1))
end
it "the advertisement is not updated due to error" do
allow(AssignmentTeam).to receive(:find_by).and_return(team1)
allow(AssignmentParticipant).to receive(:exists?).and_return(true)
allow(team1).to receive(:assignment).and_return(assignment1)
allow(AssignmentParticipant).to receive(:find_by).and_return(participant)
allow(team1).to receive(:update_attributes).and_raise(StandardError)
params = {
id: team1.id,
team_id: team1.id,
}
session = {user: ta}
result = get :update, params, session
expect(flash[:error]).to eq "An error occurred and your advertisement was not updated!"
expect(result.status).to eq 200
end
end
end



[[File:Teams adv create.png]]

==== Scenario 3: Remove the advertisement. ====

# We set the advertise_for_partner : False , comments_for_advertisement : nil when the user wants to set a new advertisement for partners in AssignmentTeam model.
# Remove Unsuccessful : If there is an error during removing the advertisement then the following error message is thrown "An error occurred and your advertisement was not removed." and the previous page is rendered.
# Remove Successful : If the advertisement is successfully removed in the database then the "Your advertisement was successfully removed!" message is prompted and the user is redirected to the view_student_teams_path.

describe "POST #remove" do

context "when advertisement is removed" do
it "the advertisement is removed" do
allow(AssignmentTeam).to receive(:find_by).and_return(team1)
allow(AssignmentParticipant).to receive(:exists?).and_return(true)
allow(team1).to receive(:assignment).and_return(assignment1)
allow(team1).to receive(:update_attributes).and_return(true)
allow(AssignmentParticipant).to receive(:find_by).and_return(participant)

params = {
id: team1.id,
team_id: team1.id,
}
session = {user: ta}
result = get :remove, params, session
expect(result.status).to eq 302
expect(result).to redirect_to(view_student_teams_path(:student_id => 1))
end
it "the advertisement is not removed due to error" do
allow(AssignmentTeam).to receive(:find_by).and_return(team1)
allow(AssignmentParticipant).to receive(:exists?).and_return(true)
allow(team1).to receive(:assignment).and_return(assignment1)
allow(AssignmentParticipant).to receive(:find_by).and_return(participant)
allow(team1).to receive(:update_attributes).and_raise(StandardError)
params = {
id: team1.id,
team_id: team1.id,
}
session = {user: ta}
result = get :remove, params, session
expect(flash[:error]).to eq "An error occurred and your advertisement was not removed!"
expect(result).to redirect_to(request.env['HTTP_REFERER'] ? :back : (:root))
end
end
end


[[File:Teams adv remove.png]]

==== Coverage. ====
[[File:E2167 AdvertisePartner.PNG]]

==== Coverage ====
[[File:E2127 Advertise run file.PNG]]

= Old Page Link =

We have created a new page due to a title error at the new one.
Link to the old page : https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2126._Testing_-_Team_Related_Files#Description_about_project


==== Test Pass/ Fail ====
[[File:E2167 JoinTeamRequest git.PNG]]

= Our Team =

Yi Qiu (mentor) 
Aaron Mathew (asmathew@ncsu.edu) 
Priya Jakhar (pjakhar@ncsu.edu) 
Supriya Krishna (sbkrishn@ncsu.edu) 
Snehapriyaa Mathiyalaghan (smathiy@ncsu.edu)

CSC/ECE 517 Fall 2021 - E2167. Testing - Team Related Files

2021-11-30T05:24:20Z

Asmathew:

__TOC__

= Relevant links =
Github Repo : [https://github.com/MathewAaron/expertiza Repository]

= About Expertiza =
[http://expertiza.ncsu.edu/ Expertiza] is an open source project based on [http://rubyonrails.org/ Ruby on Rails] framework. It is a web based program that allows instructors to create and update/edit assignments/tasks, and then assigns them to students. Students then can submit, edit, and update their assignments, as well as peer review other student's assignments.

= Problem statement and background =
There are many files related to teams that don’t have enough tests: teams_controller, teams_users_controller, student_teams_controller, join_team_requests_controller, and advertise_for_partner_controller. They all need essentially the same kind of fixtures or mocks to enable testing: A team that is created, a couple of students that can be added to the team, an invitation that can be sent from one student to another student to join a particular team

= Approach Chosen & Why? =
In this project we have first identified all the set of scenarios related to team controllers. Each of the scenarios are identified as mentioned above and has been subdivided into a number of ways in which it can be realized. This will ensure that code is robust to any kind of unexpected changes and that the functionality will not be broken when deployed in production.
We have chosen to bring about this robustness of test by writing unit test and functional tests using RSpec and Capybara respectively. Unit Tests will ensure that the particular functionality is being tested in a isolated setup which would even include the edge cases whereas the functional tests will ensure that this teams feature is in resonance with the other features and works coherently.

= Implementation =

=== teams_shared.rb ===

# This controller can be found in spec/support
# It has all shared methods to be included in Teams related files.
==== Method 1- Declared common stubbed objects ====

shared_context 'object initializations' do
let(:superadmin) { build_stubbed(:superadmin) }
let(:admin) { build_stubbed(:admin) }
let(:instructor) { build_stubbed(:instructor, id: 1) }
let(:ta) { build_stubbed(:teaching_assistant) }
let(:student1) { build_stubbed(:student, id: 1, name: 'student2065') }
let(:student2) { build_stubbed(:student, id: 2) }
let(:course1) { build_stubbed(:course, name: 'TestCourse', id:1, instructor_id: instructor.id) }
let(:assignment1) { build_stubbed(:assignment, name: 'TestAssignment', id: 1) }
let(:team1) { build_stubbed(:assignment_team, id: 1, name: 'wolfers',parent_id: assignment1.id) }
let(:team2) { build_stubbed(:assignment_team, id: 2, parent_id: assignment1.id) }
let(:team3) { build_stubbed(:assignment_team, id: 3, parent_id: assignment1.id) }
let(:team4) { build_stubbed(:assignment_team, id: 4, parent_id: assignment1.id) }
let(:team5) { build_stubbed(:course_team, id: 5, parent_id: course1.id) }
let(:team6) { build_stubbed(:course_team, id: 6, parent_id: course1.id) }
let(:team7) { build_stubbed(:assignment_team, name: 'test', parent_id: course1.id) }
let(:join_team_request1) { build_stubbed(:join_team_request, id: 1, team_id: team1.id, status: 'P') }
let(:join_team_request2) { build_stubbed(:join_team_request, id: 2, team_id: team2.id, status: 'P',comments: "Any comment") }
let(:join_team_request3) { build_stubbed(:join_team_request, id: 3, team_id: team2.id, status: 'D',comments: "Updated") }
let(:invalidrequest) { build_stubbed(:join_team_request) }
let(:participant) { build_stubbed(:participant, id: 1) }
let(:node1) { build_stubbed(:assignment_node, node_object_id: 1) }
let(:team_user1) { build_stubbed(:team_user, team_id:1, user_id:1)}

==== Method 2 - Action_allowed?: It gives access permission to different users ====

shared_context 'authorization check', :shared_context => :metadata do
# Testing to check Instructor access
it 'superadmin credentials' do
stub_current_user(superadmin, superadmin.role.name, superadmin.role)
expect(controller.send(:action_allowed?)).to be true
end
# Testing to check Admin access
it 'admin credentials' do
stub_current_user(admin, admin.role.name, admin.role)
expect(controller.send(:action_allowed?)).to be true
end
# Testing to check TA access
it 'ta credentials' do
stub_current_user(ta, ta.role.name, ta.role)
expect(controller.send(:action_allowed?)).to be true
end
# Testing to check Instructor access
it 'instructor credentials' do
stub_current_user(instructor, instructor.role.name, instructor.role)
expect(controller.send(:action_allowed?)).to be true
end

==== How to use this shared file? ====
# Add a require statement:
require './spec/support/teams_shared.rb'
# Add include_context statements in the controller.
include_context "object initializations"
include_context 'authorization check'
# Why this file? - There are a lot of methods common in the Teams Related Files, they basically use similar / same stubbed objects and methods. Implementing the teams_shared.rb file keeps the code DRY and makes use of good design principles.


=== teams_controller.rb ===
==== How to run the test? ====
rspec spec/controllers/teams_controller.rb

==== Scenario 1: Create teams with random names ====

# After checking for the team type and team size, call function to randomize the teams
# Print message "Random teams have been successfully created."
# Redirect to list of teams


describe 'create teams method' do
context 'when everything is right' do
it 'creates teams with random names' do
allow(Object).to receive_message_chain(:const_get, :find).with(any_args).and_return(assignment1)
allow(Version).to receive_message_chain(:where, :last).with(any_args).and_return(0.1)
para = {id: assignment1.id, team_size: 2}
session = {user: instructor, team_type: "Assignment"}
result = get :create_teams, para, session
expect(result.status).to eq 302
expect(result).to redirect_to(:action => 'list', :id => assignment1.id)
end
end
end


==== Scenario 2: List the teams assignment wise or course wise ====

# Check the team type passed in params to see if it is Assignment or Course type
# Get the teams belonging to that Assignment or Course and list them all


describe 'list method' do
before(:each) { allow(Assignment).to receive(:find_by).and_return(assignment1) }
context 'when type is Assignment' do
it 'lists the teams for that Assignment' do
params = {id: assignment1.id, type: 'Assignment'}
session = {user: instructor}
result = get :list, params, session
expect(result.status).to eq 200
expect(controller.instance_variable_get(:@assignment)).to eq assignment1
end
end
context 'when type is Course' do
it 'lists the teams for that Course' do
params = {id: course1.id, type: 'Course'}
session = {user: instructor}
result = get :list, params, session
expect(result.status).to eq 200
expect(controller.instance_variable_get(:@assignment)).to eq nil
end
end
context 'when type is wrong' do
it 'throws error' do
params = {id: 52, type: 'Subject'}
session = {user: instructor}
result = get :list, params, session
expect(result.status).to eq 200
expect(controller.instance_variable_get(:@assignment)).to eq nil
end
end
end


==== Scenario 3: Create a new empty team ====

# Check if a team already exists with the same name
# If it doesn’t, create a new team with a name
# If a team is created, print "The team <team_name> has been successfully created."
# Redirect to list team page
# If error is there, fail to create a new team and redirect to new team form page


describe 'new method' do
it 'creates a new team successfully when all parameters are provided correctly' do
allow(Object).to receive_message_chain(:const_get, :find).with(any_args).and_return(assignment1)
para = {id: assignment1.id}
session = {user: ta, team_type: 'Assignment'}
result = get :new, para, session
expect(result.status).to eq 200
expect(controller.instance_variable_get(:@parent)).to eq assignment1
end
end


==== Scenario 4: Update an existing team ====

# Check if a team with new suggested name already exists
# If it doesn’t, update and save the new team name
# Print "The team <new_team_name> has been successfully updated."
# Redirect to list team page
# If error is there, fail to update team and redirect to edit team form page


describe 'update method' do
it 'updates the team name' do
allow(Team).to receive(:find).and_return(team1)
allow(Assignment).to receive(:find).and_return(assignment1)
para = { id: team1.id, team: {name: 'rando team'}}
session = {user: ta, team_type: 'Assignment'}
result = get :update, para, session
expect(result.status).to eq 302
expect(result).to redirect_to(:action => 'list', :id => assignment1.id)
end
# this test will fail even though it should normally pass, that's because it runs into an error at @team.save
# RumtimeError: stubbed models are not allowed to access the database - AssignmentTeam#save()
end


==== Scenario 5: Delete a team ====

# Check if there is a team in waitlist for the topic that the team to be deleted holds
# If there is a team on the waitlist, assign the topic to that team. If multiple teams are there, assign the topic to the first team in the waitlist.
# Delete the team’s records in team, teams_users and sign_up_team tables
# Print “"The team <team_name> has been successfully deleted."


describe 'delete method' do
before(:each) { request.env['HTTP_REFERER'] = root_url }
context 'when called and team is nil' do
it 'simply redirects' do
allow(Team).to receive(:find_by).and_return(nil)
para = {id: 5}
session = {user: instructor}
result = get :delete, para, session
expect(result.status).to eq 302
expect(result).to redirect_to :back
expect(controller.instance_variable_get(:@team)).to eq nil
end
end
context 'when called and team is not nil and it does not hold a topic' do
it 'deletes the team' do
allow(Team).to receive(:find_by).and_return(team5)
allow(Object).to receive_message_chain(:const_get, :find).and_return(course1)
allow(team5).to receive(:destroy).and_return(nil)
para = {id: 5}
session = {user: instructor, team_type: 'CourseTeam'}
result = get :delete, para, session
expect(result.status).to eq 302
expect(controller.instance_variable_get(:@team)).to eq team5
end
end
end


==== Scenario 6: Copy existing teams from a course down to an assignment ====

# Find the course that the assignment belongs to
# If a course for the assignment doesn’t exist, give the error message "No course was found for this assignment."
# Otherwise fetch all the teams that exist in the course
# If no teams exist, give the error message "No teams were found when trying to inherit."
# Else copy all teams and assign them the new assignment id


describe 'inherit method' do
context 'called when assignment belongs to course and team is not empty' do
it 'runs successfully' do
allow(Assignment).to receive(:find).and_return(assignment1)
allow(Course).to receive(:find).and_return(course1)
allow(course1).to receive(:get_teams).and_return([team5, team6])
para = {id: team5.id}
session = {user: ta}
result = get :inherit, para, session
expect(result.status).to eq 302
expect(result).to redirect_to(:controller => 'teams', :action => 'list', :id => assignment1.id)
end
end
context 'called when assignment belongs to course but team is empty' do
it 'flashes note' do
allow(Assignment).to receive(:find).and_return(assignment1)
allow(Course).to receive(:find).and_return(course1)
para = {id: team5.id}
session = {user: ta}
result = get :inherit, para, session
expect(result.status).to eq 302
expect(result).to redirect_to(:controller => 'teams', :action => 'list', :id => assignment1.id)
end
end
context 'called when assignment belongs to no course' do
let(:fasg) { build_stubbed(:assignment, id: 1074, course_id: -2) }
# a temporary assigment object is created with an abnormal course_id so that we can check the fail condition of the method
it 'flashes error' do
allow(Assignment).to receive(:find).and_return(fasg)
allow(Course).to receive(:find).and_return(course1)
para = {id: team5.id}
session = {user: ta}
result = get :inherit, para, session
expect(result.status).to eq 302
expect(result).to redirect_to(:controller => 'teams', :action => 'list', :id => fasg.id)
end
end
end


==== Scenario 7: Copy existing team from assignment to course ====

# Find the assignment id to which the team belongs
# Find the course to which the assignment belongs
# If assignment doesn’t belong to a course, give the error message "This assignment is not <assignment_name> with a course."
# Otherwise copy team from assignment and assign it the course id
# Print success message "The team <team_name> was successfully copied to <course_name>"
# Redirect to list page


describe 'bequeath method' do
context 'called when assignment has a course' do
it 'runs successfully' do
allow(AssignmentTeam).to receive(:find).and_return(team2)
allow(Assignment).to receive(:find).and_return(assignment1)
allow(Course).to receive(:find).and_return(course1)
para = {id: team2.id}
session = {user: ta}
result = get :bequeath, para, session
expect(result.status).to eq 302
expect(result).to redirect_to(:controller => 'teams', :action => 'list', :id => assignment1.id)
end
end
context 'called when assignment does not have a course' do
let(:fasg) { build_stubbed(:assignment, id: 1074, course_id: -2) }
# a temporary assigment object is created with an abnormal course_id so that we can check the fail condition of the method
it 'fails' do
allow(AssignmentTeam).to receive(:find).and_return(team2)
allow(Assignment).to receive(:find).and_return(fasg)
para = {id: team2.id}
session = {user: ta}
result = get :bequeath, para, session
expect(result.status).to eq 302
expect(result).to redirect_to(:controller => 'teams', :action => 'list', :id => fasg.id)
end
end
end


==== Scenario 8: Edit method ====

# Find the team with the 'id' present in params


describe 'edit method' do
it 'passes the test' do
allow(Team).to receive(:find).and_return(team1)
para = {id: team1.id}
session = {user: ta}
result = get :edit, para, session
expect(result.status).to eq 200
expect(controller.instance_variable_get(:@team)).to eq team1
end
# this method has only 1 line which is just to look up a team with the id present in the params
end


==== Scenario 9: Create an empty team ====

# Find the parent (Assignment or Course) based on the team type which starts the session
# It checks whether a team with the same exists in that category
# If team exists, it throws TeamExistsError and redirects to 'new' team form page
# If team doesn't exist, it creates a new team
# Successful message is displayed and user is redirected to 'list' teams page


describe 'create method' do
context 'when invoked with a team which does not exist' do
it 'creates it' do
allow(Assignment).to receive(:find).and_return(assignment1)
para = { id: assignment1.id, team: {name: 'rando team'}}
session = {user: ta, team_type: 'Assignment'}
result = get :create, para, session
expect(result.status).to eq 302
expect(result).to redirect_to(:action => 'list', :id => assignment1.id)
end
end
end


==== Test Pass/ Fail ====
[[File:E2167 Teams test.PNG]]

==== Coverage ====
[[File:E2167 Teams controller.PNG]]

=== teams_users_controller.rb ===

====Scenario 1: Add new user to the selected team.====

#Given user is not defined: When given user is defined, link is provided to create the user.
#Selected team to which user is being added belongs to an assignment: When user is not a participant of the assignment, link is provided to add the user to the assignment. When the assignment team already has maximum number of users, "Maximum users reached" notification is flashed.
#Selected team to which user is being added belongs to a course: When user is not a participant of the course, link is provided to add the user to the course. When the course team already has maximum number of users, "Maximum users reached" notification is flashed.


[[File:user_create.png|600px]]

====Scenario 2: Delete user from the selected team.====

#User under assignment or course team is deleted: user association to the respective team is deleted and hence user is no longer part of the team.


[[File:user_remove.png]]

[[File:Team stud remove.png]]

=== student_teams_controller.rb ===

==== Scenario 1: Set the variables for view ====

#If the current user is student and their User Ids match, then the following values are set: @send_invs, @received_invs, @current_due_date, @users_on_waiting_list, @teammate_review_allowed
# If the current user is not student or the User Ids do not match, then the return from method.


==== Scenario 2: Create Student teams ====

# If team name is empty, flash an error message saying "Team name missing while creating team" and redirect to view_student_teams_path
# If team name is not empty and team name already in use, "Team name being created was already in use" and redirect to view_student_teams_path
# If team name is not empty and team name not in use, save team data, add logged in student to team and redirect to view_student_teams_path.

[[File:Team stud create.png]]

==== Scenario 3: Update team name: ====

# Find the team that should be updated.
# If there are no matching teams, call team_created_successfully and redirect to view_student_teams_path
# If there is exactly one match, then call team_created_successfully and redirect to view_student_teams_path
# If there are more than one team, then show the following error message "Team name being updated to was already in use" and redirect to edit_student_teams_path.

[[File:Team student update.png]]

==== Scenario 4: Remove team participants ====

# Find the user who has to be removed.
# Remove the user from team.
# If the team does not have any more participants, remove the team record from database.
# If the assignment has sign up sheet, then add the topic back to topics pool or assign the topic to a new team from waitlist
# Remove all the invitations sent and redirect to view_student_teams_path.


=== join_team_requests_controller.rb ===

P = Pending status 
D = Denied status 
A = Accepted status
# Test the controller :
rspec spec/controllers/join_team_request_controller_spec.rb


==== Scenario 1: Creating a team request ====

# If the team id is verified along with user id and assignment id, create a new request and change @join_team_request = 'P' .
# If error occurs, flash error message.


describe "POST #create" do
before(:each) do
# Stubbing participant to receive an object with id = 1
allow(Participant).to receive(:find).with("1").and_return(participant)
end
context "when resource is not saved!" do
it "renders new page" do
allow(JoinTeamRequest).to receive(:new).and_return(invalidrequest)
params = {participant_id: participant.id, team_id: -2}
session = {user: student1}
get :new, params, session
expect(response).to render_template("new")
end
end
# Testing when the object is being saved to the database
context "when resource is saved" do
before(:each) do
allow(JoinTeamRequest).to receive(:new).and_return(join_team_request2)
allow(Team).to receive(:find).with("1").and_return(team1)
allow(Assignment).to receive(:find).with(1).and_return(assignment1)
allow(Participant).to receive(:where).with(user_id: 1,parent_id: '1').and_return([participant])
allow(join_team_request2).to receive(:save).and_return(true)
end
it "valid response" do
allow(join_team_request2).to receive(:save).and_return(true)
params = {
id: 2,
join_team_request2: {
status: 'P'
},
team_id: 1,
assignment_id: 1
}
session = {user: student1}
post :create, params, session
expect(response.status).to eq 302
expect(join_team_request2.status).to eq('P')
end
end
context "when it is not created" do
it "will page for new " do
allow(join_team_request2).to receive(:save).and_return(false)
params = {action: 'new'}
session = {user: student1}
get :new, params, session
expect(response.status).to eq 200
end
end
end

==== Scenario 2: Decline a team request. ====

# After verifying team_user_id, change @join_team_request.status = 'D' .
# Redirect to view_student_teams_path

describe "#decline" do
context "when join team request is declined" do
before(:each) do
allow(JoinTeamRequest).to receive(:find).and_return(join_team_request2)
allow(join_team_request2).to receive(:save).and_return(true)
end
it "will change status to 'D'" do
params = {action: 'decline'}
session = {user: ta}
result = get :decline, params, session
expect(result.status).to eq 302
end
it "will redirect to view student teams path" do
params = {action: 'decline'}
session = {user: ta}
result = get :decline, params, session
expect(result).to redirect_to(view_student_teams_path)
end
end
end



==== Scenario 3: Check team status. ====

# Since this method is private there is no test case written for it.
# If team if full. Print error message "This team is full." .
# If team is not empty, print message "You are already a member of this team."


==== Coverage ====
[[File:E2167 JoinTeamRequest coverage.PNG]]


==== Test Pass/ Fail ====

# All tests, except 1 pass.
# The test that fails is for the "get index" method. We have identified that there is no route the view/index is going to.
def respond_after(request)
respond_to do |format|
format.html
format.xml { render xml: request }
end
end

[[File:E2167 JoinTeamRequest test.PNG]]


=== advertise_partner_controller.rb ===
==== Scenario 1: Creating new advertisement for partners. ====

# We set the advertise_for_partner : True , comments_for_advertisement[param] when the user wants to set a new advertisement for partners in AssignmentTeam model.

describe "POST #create" do

context "when it is valid" do
it "will create an advertisement" do
allow(AssignmentTeam).to receive(:find_by).and_return(team1)
allow(AssignmentParticipant).to receive(:exists?).and_return(true)
allow(team1).to receive(:assignment).and_return(assignment1)
allow(team1).to receive(:update_attributes).and_return(true)
allow(AssignmentParticipant).to receive(:find_by).and_return(participant)

params = {
id: team1.id,
team_id: team1.id,
}
session = {user: ta}
result = get :create, params, session
expect(result.status).to eq 302
expect(result).to redirect_to(view_student_teams_path(:student_id => 1))
end
end
end


[[File:Teams adv1.png]]

==== Scenario 2: Updating the advertisement. ====

# We set the comments_for_advertisement[param] when the user wants to set a new advertisement for partners in AssignmentTeam model.
# Update Unsuccessful : If there is an error during update then the following error message is thrown "An error occurred and your advertisement was not updated." and edit page is rendered.
# Update Successful : If the advertisement is successfully updated in the database then the "Your advertisement was successfully updated!" message is prompted and the user is redirected to the view_student_teams_path.

context "when advertisement is updated" do
it "the advertisement is updated" do
allow(AssignmentTeam).to receive(:find_by).and_return(team1)
allow(AssignmentParticipant).to receive(:exists?).and_return(true)
allow(team1).to receive(:assignment).and_return(assignment1)
allow(team1).to receive(:update_attributes).and_return(true)
allow(AssignmentParticipant).to receive(:find_by).and_return(participant)

params = {
id: team1.id,
team_id: team1.id,
}
session = {user: ta}
result = get :update, params, session
expect(result.status).to eq 302
expect(result).to redirect_to(view_student_teams_path(:student_id => 1))
end
it "the advertisement is not updated due to error" do
allow(AssignmentTeam).to receive(:find_by).and_return(team1)
allow(AssignmentParticipant).to receive(:exists?).and_return(true)
allow(team1).to receive(:assignment).and_return(assignment1)
allow(AssignmentParticipant).to receive(:find_by).and_return(participant)
allow(team1).to receive(:update_attributes).and_raise(StandardError)
params = {
id: team1.id,
team_id: team1.id,
}
session = {user: ta}
result = get :update, params, session
expect(flash[:error]).to eq "An error occurred and your advertisement was not updated!"
expect(result.status).to eq 200
end
end
end



[[File:Teams adv create.png]]

==== Scenario 3: Remove the advertisement. ====

# We set the advertise_for_partner : False , comments_for_advertisement : nil when the user wants to set a new advertisement for partners in AssignmentTeam model.
# Remove Unsuccessful : If there is an error during removing the advertisement then the following error message is thrown "An error occurred and your advertisement was not removed." and the previous page is rendered.
# Remove Successful : If the advertisement is successfully removed in the database then the "Your advertisement was successfully removed!" message is prompted and the user is redirected to the view_student_teams_path.

describe "POST #remove" do

context "when advertisement is removed" do
it "the advertisement is removed" do
allow(AssignmentTeam).to receive(:find_by).and_return(team1)
allow(AssignmentParticipant).to receive(:exists?).and_return(true)
allow(team1).to receive(:assignment).and_return(assignment1)
allow(team1).to receive(:update_attributes).and_return(true)
allow(AssignmentParticipant).to receive(:find_by).and_return(participant)

params = {
id: team1.id,
team_id: team1.id,
}
session = {user: ta}
result = get :remove, params, session
expect(result.status).to eq 302
expect(result).to redirect_to(view_student_teams_path(:student_id => 1))
end
it "the advertisement is not removed due to error" do
allow(AssignmentTeam).to receive(:find_by).and_return(team1)
allow(AssignmentParticipant).to receive(:exists?).and_return(true)
allow(team1).to receive(:assignment).and_return(assignment1)
allow(AssignmentParticipant).to receive(:find_by).and_return(participant)
allow(team1).to receive(:update_attributes).and_raise(StandardError)
params = {
id: team1.id,
team_id: team1.id,
}
session = {user: ta}
result = get :remove, params, session
expect(flash[:error]).to eq "An error occurred and your advertisement was not removed!"
expect(result).to redirect_to(request.env['HTTP_REFERER'] ? :back : (:root))
end
end
end


[[File:Teams adv remove.png]]

==== Coverage. ====
[[File:E2167 AdvertisePartner.PNG]]

= Old Page Link =

We have created a new page due to a title error at the new one.
Link to the old page : https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2126._Testing_-_Team_Related_Files#Description_about_project


==== Test Pass/ Fail ====
[[File:E2167 JoinTeamRequest git.PNG]]

==== Coverage ====
[[File:E2167 AdvertisePartner.PNG]]

= Our Team =

Yi Qiu (mentor) 
Aaron Mathew (asmathew@ncsu.edu) 
Priya Jakhar (pjakhar@ncsu.edu) 
Supriya Krishna (sbkrishn@ncsu.edu) 
Snehapriyaa Mathiyalaghan (smathiy@ncsu.edu)

File:E2127 Advertise run file.PNG

2021-11-30T05:23:51Z

Asmathew:

File:E2167 AdvertisePartner.PNG

2021-11-30T05:18:42Z

Asmathew:

CSC/ECE 517 Fall 2021 - E2167. Testing - Team Related Files

2021-11-30T05:13:20Z

Asmathew:

__TOC__

= Relevant links =
Github Repo : [https://github.com/MathewAaron/expertiza Repository]

= About Expertiza =
[http://expertiza.ncsu.edu/ Expertiza] is an open source project based on [http://rubyonrails.org/ Ruby on Rails] framework. It is a web based program that allows instructors to create and update/edit assignments/tasks, and then assigns them to students. Students then can submit, edit, and update their assignments, as well as peer review other student's assignments.

= Problem statement and background =
There are many files related to teams that don’t have enough tests: teams_controller, teams_users_controller, student_teams_controller, join_team_requests_controller, and advertise_for_partner_controller. They all need essentially the same kind of fixtures or mocks to enable testing: A team that is created, a couple of students that can be added to the team, an invitation that can be sent from one student to another student to join a particular team

= Approach Chosen & Why? =
In this project we have first identified all the set of scenarios related to team controllers. Each of the scenarios are identified as mentioned above and has been subdivided into a number of ways in which it can be realized. This will ensure that code is robust to any kind of unexpected changes and that the functionality will not be broken when deployed in production.
We have chosen to bring about this robustness of test by writing unit test and functional tests using RSpec and Capybara respectively. Unit Tests will ensure that the particular functionality is being tested in a isolated setup which would even include the edge cases whereas the functional tests will ensure that this teams feature is in resonance with the other features and works coherently.

= Implementation =

=== teams_shared.rb ===

# This controller can be found in spec/support
# It has all shared methods to be included in Teams related files.
==== Method 1- Declared common stubbed objects ====

shared_context 'object initializations' do
let(:superadmin) { build_stubbed(:superadmin) }
let(:admin) { build_stubbed(:admin) }
let(:instructor) { build_stubbed(:instructor, id: 1) }
let(:ta) { build_stubbed(:teaching_assistant) }
let(:student1) { build_stubbed(:student, id: 1, name: 'student2065') }
let(:student2) { build_stubbed(:student, id: 2) }
let(:course1) { build_stubbed(:course, name: 'TestCourse', id:1, instructor_id: instructor.id) }
let(:assignment1) { build_stubbed(:assignment, name: 'TestAssignment', id: 1) }
let(:team1) { build_stubbed(:assignment_team, id: 1, name: 'wolfers',parent_id: assignment1.id) }
let(:team2) { build_stubbed(:assignment_team, id: 2, parent_id: assignment1.id) }
let(:team3) { build_stubbed(:assignment_team, id: 3, parent_id: assignment1.id) }
let(:team4) { build_stubbed(:assignment_team, id: 4, parent_id: assignment1.id) }
let(:team5) { build_stubbed(:course_team, id: 5, parent_id: course1.id) }
let(:team6) { build_stubbed(:course_team, id: 6, parent_id: course1.id) }
let(:team7) { build_stubbed(:assignment_team, name: 'test', parent_id: course1.id) }
let(:join_team_request1) { build_stubbed(:join_team_request, id: 1, team_id: team1.id, status: 'P') }
let(:join_team_request2) { build_stubbed(:join_team_request, id: 2, team_id: team2.id, status: 'P',comments: "Any comment") }
let(:join_team_request3) { build_stubbed(:join_team_request, id: 3, team_id: team2.id, status: 'D',comments: "Updated") }
let(:invalidrequest) { build_stubbed(:join_team_request) }
let(:participant) { build_stubbed(:participant, id: 1) }
let(:node1) { build_stubbed(:assignment_node, node_object_id: 1) }
let(:team_user1) { build_stubbed(:team_user, team_id:1, user_id:1)}

==== Method 2 - Action_allowed?: It gives access permission to different users ====

shared_context 'authorization check', :shared_context => :metadata do
# Testing to check Instructor access
it 'superadmin credentials' do
stub_current_user(superadmin, superadmin.role.name, superadmin.role)
expect(controller.send(:action_allowed?)).to be true
end
# Testing to check Admin access
it 'admin credentials' do
stub_current_user(admin, admin.role.name, admin.role)
expect(controller.send(:action_allowed?)).to be true
end
# Testing to check TA access
it 'ta credentials' do
stub_current_user(ta, ta.role.name, ta.role)
expect(controller.send(:action_allowed?)).to be true
end
# Testing to check Instructor access
it 'instructor credentials' do
stub_current_user(instructor, instructor.role.name, instructor.role)
expect(controller.send(:action_allowed?)).to be true
end

==== How to use this shared file? ====
# Add a require statement:
require './spec/support/teams_shared.rb'
# Add include_context statements in the controller.
include_context "object initializations"
include_context 'authorization check'
# Why this file? - There are a lot of methods common in the Teams Related Files, they basically use similar / same stubbed objects and methods. Implementing the teams_shared.rb file keeps the code DRY and makes use of good design principles.


=== teams_controller.rb ===
==== How to run the test? ====
rspec spec/controllers/teams_controller.rb

==== Scenario 1: Create teams with random names ====

# After checking for the team type and team size, call function to randomize the teams
# Print message "Random teams have been successfully created."
# Redirect to list of teams


describe 'create teams method' do
context 'when everything is right' do
it 'creates teams with random names' do
allow(Object).to receive_message_chain(:const_get, :find).with(any_args).and_return(assignment1)
allow(Version).to receive_message_chain(:where, :last).with(any_args).and_return(0.1)
para = {id: assignment1.id, team_size: 2}
session = {user: instructor, team_type: "Assignment"}
result = get :create_teams, para, session
expect(result.status).to eq 302
expect(result).to redirect_to(:action => 'list', :id => assignment1.id)
end
end
end


==== Scenario 2: List the teams assignment wise or course wise ====

# Check the team type passed in params to see if it is Assignment or Course type
# Get the teams belonging to that Assignment or Course and list them all


describe 'list method' do
before(:each) { allow(Assignment).to receive(:find_by).and_return(assignment1) }
context 'when type is Assignment' do
it 'lists the teams for that Assignment' do
params = {id: assignment1.id, type: 'Assignment'}
session = {user: instructor}
result = get :list, params, session
expect(result.status).to eq 200
expect(controller.instance_variable_get(:@assignment)).to eq assignment1
end
end
context 'when type is Course' do
it 'lists the teams for that Course' do
params = {id: course1.id, type: 'Course'}
session = {user: instructor}
result = get :list, params, session
expect(result.status).to eq 200
expect(controller.instance_variable_get(:@assignment)).to eq nil
end
end
context 'when type is wrong' do
it 'throws error' do
params = {id: 52, type: 'Subject'}
session = {user: instructor}
result = get :list, params, session
expect(result.status).to eq 200
expect(controller.instance_variable_get(:@assignment)).to eq nil
end
end
end


==== Scenario 3: Create a new empty team ====

# Check if a team already exists with the same name
# If it doesn’t, create a new team with a name
# If a team is created, print "The team <team_name> has been successfully created."
# Redirect to list team page
# If error is there, fail to create a new team and redirect to new team form page


describe 'new method' do
it 'creates a new team successfully when all parameters are provided correctly' do
allow(Object).to receive_message_chain(:const_get, :find).with(any_args).and_return(assignment1)
para = {id: assignment1.id}
session = {user: ta, team_type: 'Assignment'}
result = get :new, para, session
expect(result.status).to eq 200
expect(controller.instance_variable_get(:@parent)).to eq assignment1
end
end


==== Scenario 4: Update an existing team ====

# Check if a team with new suggested name already exists
# If it doesn’t, update and save the new team name
# Print "The team <new_team_name> has been successfully updated."
# Redirect to list team page
# If error is there, fail to update team and redirect to edit team form page


describe 'update method' do
it 'updates the team name' do
allow(Team).to receive(:find).and_return(team1)
allow(Assignment).to receive(:find).and_return(assignment1)
para = { id: team1.id, team: {name: 'rando team'}}
session = {user: ta, team_type: 'Assignment'}
result = get :update, para, session
expect(result.status).to eq 302
expect(result).to redirect_to(:action => 'list', :id => assignment1.id)
end
# this test will fail even though it should normally pass, that's because it runs into an error at @team.save
# RumtimeError: stubbed models are not allowed to access the database - AssignmentTeam#save()
end


==== Scenario 5: Delete a team ====

# Check if there is a team in waitlist for the topic that the team to be deleted holds
# If there is a team on the waitlist, assign the topic to that team. If multiple teams are there, assign the topic to the first team in the waitlist.
# Delete the team’s records in team, teams_users and sign_up_team tables
# Print “"The team <team_name> has been successfully deleted."


describe 'delete method' do
before(:each) { request.env['HTTP_REFERER'] = root_url }
context 'when called and team is nil' do
it 'simply redirects' do
allow(Team).to receive(:find_by).and_return(nil)
para = {id: 5}
session = {user: instructor}
result = get :delete, para, session
expect(result.status).to eq 302
expect(result).to redirect_to :back
expect(controller.instance_variable_get(:@team)).to eq nil
end
end
context 'when called and team is not nil and it does not hold a topic' do
it 'deletes the team' do
allow(Team).to receive(:find_by).and_return(team5)
allow(Object).to receive_message_chain(:const_get, :find).and_return(course1)
allow(team5).to receive(:destroy).and_return(nil)
para = {id: 5}
session = {user: instructor, team_type: 'CourseTeam'}
result = get :delete, para, session
expect(result.status).to eq 302
expect(controller.instance_variable_get(:@team)).to eq team5
end
end
end


==== Scenario 6: Copy existing teams from a course down to an assignment ====

# Find the course that the assignment belongs to
# If a course for the assignment doesn’t exist, give the error message "No course was found for this assignment."
# Otherwise fetch all the teams that exist in the course
# If no teams exist, give the error message "No teams were found when trying to inherit."
# Else copy all teams and assign them the new assignment id


describe 'inherit method' do
context 'called when assignment belongs to course and team is not empty' do
it 'runs successfully' do
allow(Assignment).to receive(:find).and_return(assignment1)
allow(Course).to receive(:find).and_return(course1)
allow(course1).to receive(:get_teams).and_return([team5, team6])
para = {id: team5.id}
session = {user: ta}
result = get :inherit, para, session
expect(result.status).to eq 302
expect(result).to redirect_to(:controller => 'teams', :action => 'list', :id => assignment1.id)
end
end
context 'called when assignment belongs to course but team is empty' do
it 'flashes note' do
allow(Assignment).to receive(:find).and_return(assignment1)
allow(Course).to receive(:find).and_return(course1)
para = {id: team5.id}
session = {user: ta}
result = get :inherit, para, session
expect(result.status).to eq 302
expect(result).to redirect_to(:controller => 'teams', :action => 'list', :id => assignment1.id)
end
end
context 'called when assignment belongs to no course' do
let(:fasg) { build_stubbed(:assignment, id: 1074, course_id: -2) }
# a temporary assigment object is created with an abnormal course_id so that we can check the fail condition of the method
it 'flashes error' do
allow(Assignment).to receive(:find).and_return(fasg)
allow(Course).to receive(:find).and_return(course1)
para = {id: team5.id}
session = {user: ta}
result = get :inherit, para, session
expect(result.status).to eq 302
expect(result).to redirect_to(:controller => 'teams', :action => 'list', :id => fasg.id)
end
end
end


==== Scenario 7: Copy existing team from assignment to course ====

# Find the assignment id to which the team belongs
# Find the course to which the assignment belongs
# If assignment doesn’t belong to a course, give the error message "This assignment is not <assignment_name> with a course."
# Otherwise copy team from assignment and assign it the course id
# Print success message "The team <team_name> was successfully copied to <course_name>"
# Redirect to list page


describe 'bequeath method' do
context 'called when assignment has a course' do
it 'runs successfully' do
allow(AssignmentTeam).to receive(:find).and_return(team2)
allow(Assignment).to receive(:find).and_return(assignment1)
allow(Course).to receive(:find).and_return(course1)
para = {id: team2.id}
session = {user: ta}
result = get :bequeath, para, session
expect(result.status).to eq 302
expect(result).to redirect_to(:controller => 'teams', :action => 'list', :id => assignment1.id)
end
end
context 'called when assignment does not have a course' do
let(:fasg) { build_stubbed(:assignment, id: 1074, course_id: -2) }
# a temporary assigment object is created with an abnormal course_id so that we can check the fail condition of the method
it 'fails' do
allow(AssignmentTeam).to receive(:find).and_return(team2)
allow(Assignment).to receive(:find).and_return(fasg)
para = {id: team2.id}
session = {user: ta}
result = get :bequeath, para, session
expect(result.status).to eq 302
expect(result).to redirect_to(:controller => 'teams', :action => 'list', :id => fasg.id)
end
end
end


==== Scenario 8: Edit method ====

# Find the team with the 'id' present in params


describe 'edit method' do
it 'passes the test' do
allow(Team).to receive(:find).and_return(team1)
para = {id: team1.id}
session = {user: ta}
result = get :edit, para, session
expect(result.status).to eq 200
expect(controller.instance_variable_get(:@team)).to eq team1
end
# this method has only 1 line which is just to look up a team with the id present in the params
end


==== Scenario 9: Create an empty team ====

# Find the parent (Assignment or Course) based on the team type which starts the session
# It checks whether a team with the same exists in that category
# If team exists, it throws TeamExistsError and redirects to 'new' team form page
# If team doesn't exist, it creates a new team
# Successful message is displayed and user is redirected to 'list' teams page


describe 'create method' do
context 'when invoked with a team which does not exist' do
it 'creates it' do
allow(Assignment).to receive(:find).and_return(assignment1)
para = { id: assignment1.id, team: {name: 'rando team'}}
session = {user: ta, team_type: 'Assignment'}
result = get :create, para, session
expect(result.status).to eq 302
expect(result).to redirect_to(:action => 'list', :id => assignment1.id)
end
end
end


==== Test Pass/ Fail ====
[[File:E2167 Teams test.PNG]]

==== Coverage ====
[[File:E2167 Teams controller.PNG]]

=== teams_users_controller.rb ===

====Scenario 1: Add new user to the selected team.====

#Given user is not defined: When given user is defined, link is provided to create the user.
#Selected team to which user is being added belongs to an assignment: When user is not a participant of the assignment, link is provided to add the user to the assignment. When the assignment team already has maximum number of users, "Maximum users reached" notification is flashed.
#Selected team to which user is being added belongs to a course: When user is not a participant of the course, link is provided to add the user to the course. When the course team already has maximum number of users, "Maximum users reached" notification is flashed.


[[File:user_create.png|600px]]

====Scenario 2: Delete user from the selected team.====

#User under assignment or course team is deleted: user association to the respective team is deleted and hence user is no longer part of the team.


[[File:user_remove.png]]

[[File:Team stud remove.png]]

=== student_teams_controller.rb ===

==== Scenario 1: Set the variables for view ====

#If the current user is student and their User Ids match, then the following values are set: @send_invs, @received_invs, @current_due_date, @users_on_waiting_list, @teammate_review_allowed
# If the current user is not student or the User Ids do not match, then the return from method.


==== Scenario 2: Create Student teams ====

# If team name is empty, flash an error message saying "Team name missing while creating team" and redirect to view_student_teams_path
# If team name is not empty and team name already in use, "Team name being created was already in use" and redirect to view_student_teams_path
# If team name is not empty and team name not in use, save team data, add logged in student to team and redirect to view_student_teams_path.

[[File:Team stud create.png]]

==== Scenario 3: Update team name: ====

# Find the team that should be updated.
# If there are no matching teams, call team_created_successfully and redirect to view_student_teams_path
# If there is exactly one match, then call team_created_successfully and redirect to view_student_teams_path
# If there are more than one team, then show the following error message "Team name being updated to was already in use" and redirect to edit_student_teams_path.

[[File:Team student update.png]]

==== Scenario 4: Remove team participants ====

# Find the user who has to be removed.
# Remove the user from team.
# If the team does not have any more participants, remove the team record from database.
# If the assignment has sign up sheet, then add the topic back to topics pool or assign the topic to a new team from waitlist
# Remove all the invitations sent and redirect to view_student_teams_path.


=== join_team_requests_controller.rb ===

P = Pending status 
D = Denied status 
A = Accepted status
# Test the controller :
rspec spec/controllers/join_team_request_controller_spec.rb


==== Scenario 1: Creating a team request ====

# If the team id is verified along with user id and assignment id, create a new request and change @join_team_request = 'P' .
# If error occurs, flash error message.


describe "POST #create" do
before(:each) do
# Stubbing participant to receive an object with id = 1
allow(Participant).to receive(:find).with("1").and_return(participant)
end
context "when resource is not saved!" do
it "renders new page" do
allow(JoinTeamRequest).to receive(:new).and_return(invalidrequest)
params = {participant_id: participant.id, team_id: -2}
session = {user: student1}
get :new, params, session
expect(response).to render_template("new")
end
end
# Testing when the object is being saved to the database
context "when resource is saved" do
before(:each) do
allow(JoinTeamRequest).to receive(:new).and_return(join_team_request2)
allow(Team).to receive(:find).with("1").and_return(team1)
allow(Assignment).to receive(:find).with(1).and_return(assignment1)
allow(Participant).to receive(:where).with(user_id: 1,parent_id: '1').and_return([participant])
allow(join_team_request2).to receive(:save).and_return(true)
end
it "valid response" do
allow(join_team_request2).to receive(:save).and_return(true)
params = {
id: 2,
join_team_request2: {
status: 'P'
},
team_id: 1,
assignment_id: 1
}
session = {user: student1}
post :create, params, session
expect(response.status).to eq 302
expect(join_team_request2.status).to eq('P')
end
end
context "when it is not created" do
it "will page for new " do
allow(join_team_request2).to receive(:save).and_return(false)
params = {action: 'new'}
session = {user: student1}
get :new, params, session
expect(response.status).to eq 200
end
end
end

==== Scenario 2: Decline a team request. ====

# After verifying team_user_id, change @join_team_request.status = 'D' .
# Redirect to view_student_teams_path

describe "#decline" do
context "when join team request is declined" do
before(:each) do
allow(JoinTeamRequest).to receive(:find).and_return(join_team_request2)
allow(join_team_request2).to receive(:save).and_return(true)
end
it "will change status to 'D'" do
params = {action: 'decline'}
session = {user: ta}
result = get :decline, params, session
expect(result.status).to eq 302
end
it "will redirect to view student teams path" do
params = {action: 'decline'}
session = {user: ta}
result = get :decline, params, session
expect(result).to redirect_to(view_student_teams_path)
end
end
end



==== Scenario 3: Check team status. ====

# Since this method is private there is no test case written for it.
# If team if full. Print error message "This team is full." .
# If team is not empty, print message "You are already a member of this team."


==== Coverage ====
[[File:E2167 JoinTeamRequest coverage.PNG]]


==== Test Pass/ Fail ====

# All tests, except 1 pass.
# The test that fails is for the "get index" method. We have identified that there is no route the view/index is going to.
def respond_after(request)
respond_to do |format|
format.html
format.xml { render xml: request }
end
end

[[File:E2167 JoinTeamRequest test.PNG]]


=== advertise_partner_controller.rb ===
==== Scenario 1: Creating new advertisement for partners. ====

# We set the advertise_for_partner : True , comments_for_advertisement[param] when the user wants to set a new advertisement for partners in AssignmentTeam model.

describe "POST #create" do

context "when it is valid" do
it "will create an advertisement" do
allow(AssignmentTeam).to receive(:find_by).and_return(team1)
allow(AssignmentParticipant).to receive(:exists?).and_return(true)
allow(team1).to receive(:assignment).and_return(assignment1)
allow(team1).to receive(:update_attributes).and_return(true)
allow(AssignmentParticipant).to receive(:find_by).and_return(participant)

params = {
id: team1.id,
team_id: team1.id,
}
session = {user: ta}
result = get :create, params, session
expect(result.status).to eq 302
expect(result).to redirect_to(view_student_teams_path(:student_id => 1))
end
end
end


[[File:Teams adv1.png]]

==== Scenario 2: Updating the advertisement. ====

# We set the comments_for_advertisement[param] when the user wants to set a new advertisement for partners in AssignmentTeam model.
# Update Unsuccessful : If there is an error during update then the following error message is thrown "An error occurred and your advertisement was not updated." and edit page is rendered.
# Update Successful : If the advertisement is successfully updated in the database then the "Your advertisement was successfully updated!" message is prompted and the user is redirected to the view_student_teams_path.

context "when advertisement is updated" do
it "the advertisement is updated" do
allow(AssignmentTeam).to receive(:find_by).and_return(team1)
allow(AssignmentParticipant).to receive(:exists?).and_return(true)
allow(team1).to receive(:assignment).and_return(assignment1)
allow(team1).to receive(:update_attributes).and_return(true)
allow(AssignmentParticipant).to receive(:find_by).and_return(participant)

params = {
id: team1.id,
team_id: team1.id,
}
session = {user: ta}
result = get :update, params, session
expect(result.status).to eq 302
expect(result).to redirect_to(view_student_teams_path(:student_id => 1))
end
it "the advertisement is not updated due to error" do
allow(AssignmentTeam).to receive(:find_by).and_return(team1)
allow(AssignmentParticipant).to receive(:exists?).and_return(true)
allow(team1).to receive(:assignment).and_return(assignment1)
allow(AssignmentParticipant).to receive(:find_by).and_return(participant)
allow(team1).to receive(:update_attributes).and_raise(StandardError)
params = {
id: team1.id,
team_id: team1.id,
}
session = {user: ta}
result = get :update, params, session
expect(flash[:error]).to eq "An error occurred and your advertisement was not updated!"
expect(result.status).to eq 200
end
end
end



[[File:Teams adv create.png]]

==== Scenario 3: Remove the advertisement. ====

# We set the advertise_for_partner : False , comments_for_advertisement : nil when the user wants to set a new advertisement for partners in AssignmentTeam model.
# Remove Unsuccessful : If there is an error during removing the advertisement then the following error message is thrown "An error occurred and your advertisement was not removed." and the previous page is rendered.
# Remove Successful : If the advertisement is successfully removed in the database then the "Your advertisement was successfully removed!" message is prompted and the user is redirected to the view_student_teams_path.

describe "POST #remove" do

context "when advertisement is removed" do
it "the advertisement is removed" do
allow(AssignmentTeam).to receive(:find_by).and_return(team1)
allow(AssignmentParticipant).to receive(:exists?).and_return(true)
allow(team1).to receive(:assignment).and_return(assignment1)
allow(team1).to receive(:update_attributes).and_return(true)
allow(AssignmentParticipant).to receive(:find_by).and_return(participant)

params = {
id: team1.id,
team_id: team1.id,
}
session = {user: ta}
result = get :remove, params, session
expect(result.status).to eq 302
expect(result).to redirect_to(view_student_teams_path(:student_id => 1))
end
it "the advertisement is not removed due to error" do
allow(AssignmentTeam).to receive(:find_by).and_return(team1)
allow(AssignmentParticipant).to receive(:exists?).and_return(true)
allow(team1).to receive(:assignment).and_return(assignment1)
allow(AssignmentParticipant).to receive(:find_by).and_return(participant)
allow(team1).to receive(:update_attributes).and_raise(StandardError)
params = {
id: team1.id,
team_id: team1.id,
}
session = {user: ta}
result = get :remove, params, session
expect(flash[:error]).to eq "An error occurred and your advertisement was not removed!"
expect(result).to redirect_to(request.env['HTTP_REFERER'] ? :back : (:root))
end
end
end


[[File:Teams adv remove.png]]

= Old Page Link =

We have created a new page due to a title error at the new one.
Link to the old page : https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2126._Testing_-_Team_Related_Files#Description_about_project


==== Github Coverage. ====
[[File:E2167 JoinTeamRequest git.PNG]]

= Our Team =

Yi Qiu (mentor) 
Aaron Mathew (asmathew@ncsu.edu) 
Priya Jakhar (pjakhar@ncsu.edu) 
Supriya Krishna (sbkrishn@ncsu.edu) 
Snehapriyaa Mathiyalaghan (smathiy@ncsu.edu)

CSC/ECE 517 Fall 2021 - E2167. Testing - Team Related Files

2021-11-30T04:11:35Z

Asmathew:

CSC/ECE 517 Fall 2021 - E2167. Testing - Team Related Files

2021-11-30T04:04:56Z

Asmathew:

CSC/ECE 517 Fall 2021 - E2167. Testing - Team Related Files

2021-11-30T04:02:17Z

Asmathew:

File:E2167 Teams test.PNG

2021-11-30T03:56:45Z

Asmathew:

File:E2167 Teams controller.PNG

2021-11-30T03:53:35Z

Asmathew:

CSC/ECE 517 Fall 2021 - E2167. Testing - Team Related Files

2021-11-29T22:14:45Z

Asmathew:

File:E2167 JoinTeamRequest git.PNG

2021-11-29T22:12:15Z

Asmathew:

CSC/ECE 517 Fall 2021 - E2167. Testing - Team Related Files

2021-11-29T21:48:23Z

Asmathew:

File:E2167 JoinTeamRequest test.PNG

2021-11-29T21:43:42Z

Asmathew:

CSC/ECE 517 Fall 2021 - E2167. Testing - Team Related Files

2021-11-29T21:40:38Z

Asmathew:

File:E2167 JoinTeamRequest coverage.PNG

2021-11-29T21:37:19Z

Asmathew:

CSC/ECE 517 Fall 2021 - E2167. Testing - Team Related Files

2021-11-29T21:33:22Z

Asmathew:

CSC/ECE 517 Fall 2021 - E2167. Testing - Team Related Files

2021-11-29T21:18:33Z

Asmathew:

CSC/ECE 517 Fall 2021 - E2167. Testing - Team Related Files

2021-11-29T21:04:17Z

Asmathew: Hello

CSC/ECE 517 Fall 2021 - E2167. Testing - Team Related Files

2021-11-10T02:19:20Z

Asmathew:

CSC/ECE 517 Fall 2021 - E2167. Testing - Team Related Files

2021-11-09T21:50:31Z

Asmathew: Created page with "__TOC__ = Relevant links = Github Repo : [https://github.com/MathewAaron/expertiza Repository] = About Expertiza = [http://expertiza.ncsu.edu/ Expertiza] is an open source p..."

CSC/ECE 517 Fall 2021

2021-11-09T21:49:48Z

Asmathew:

== OSS Projects ==

* [[CSC/ECE 517 Fall 2021 - E2117. Refactor questionaires_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2128. Refactor student_quizzes_controller.rb & late_policies_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2129. Refactor auth_controller.rb & password_retrieval_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2132. Add tests cases for review mapping helper.rb]]
* [[CSC/ECE 517 Fall 2021 - E2134. Write unit tests for admin_controller.rb and institution_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2138. Auto-generate submission directory names based on assignment]]
* [[CSC/ECE 517 Fall 2021 - E2142. Improve e-mail notifications]]
* [[CSC/ECE 517 Fall 2021 - E2133. Write tests for popup_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2120. Refactor reputation_web_service_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2139. Remove multiple topics at a time]]
* [[CSC/ECE 517 Fall 2021 - E2131. Improve assessment360_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2121. Refactor suggestion_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2122. Refactor impersonate_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2123. Refactor sign_up_sheet_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2126. Refactor account_request_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2124. Refactor review_mapping_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2125. Refactor review_mapping_helper.rb]]
* [[CSC/ECE 517 Fall 2021 - E2127. Refactor teams_controller]]
* [[CSC/ECE 517 Fall 2021 - E2130. Refactor submitted_content_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2140. Create new late policy successfully and fix Bank link]]
* [[CSC/ECE 517 Fall 2021 - E2141. OSS project Finklestein: Instructors & Institutions]]
* [[CSC/ECE 517 Fall 2021 - E2144. Refactor delayed mailer and scheduled task]]
* [[CSC/ECE 517 Fall 2021 - E2147. Role-based reviewing]]
* [[CSC/ECE 517 Fall 2021 - E2145. OSS Project Beige]]
* [[CSC/ECE 517 Fall 2021 - E2146. Introduce a Student View for instructors]]
* [[CSC/ECE 517 Fall 2021 - Refactor Evaluation of SQL Queries]]
* [[CSC/ECE 517 Fall 2021 - E2135. Email notification to reviewers and instructors]]

== Final Projects ==
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2166._Testing_-_Scoring_%26_Grades#Description_about_project CSC/ECE 517 Fall 2021 - E2166. Testing - Scoring_and_Grades]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2150._Integrate_suggestion_detection_algorithm#Description_about_project CSC/ECE 517 Fall 2021 - E2150. Integrate suggestion detection algorithm]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2151._Allow_reviewers_to_bid_on_what_to_review CSC/ECE 517 Fall 2021 - E2151. Allow reviewers to bid on what to review]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2152._Revision_planning_tool#Description_about_project CSC/ECE 517 Fall 2021 - E2152. Revision_planning_tool]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2170._Testing_-_Response_Maps#Description_about_project CSC/ECE 517 Fall 2021 - E2170. Testing - Response Maps]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2153._Improving_search_facility_in_Expertiza#Description_about_project CSC/ECE 517 Fall 2021 - E2153. Improving search facility in Expertiza]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2162._Further_refactoring_and_improvement_of_review_mapping_helper CSC/ECE 517 Fall 2021 - E2162. Further refactoring and improvement of review mapping helper]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2163._Refactor_waitlist_functionality CSC/ECE 517 Fall 2021 - E2163. Refactor waitlist functionality]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2165._Fix_teammate-review_view CSC/ECE 517 Fall 2021 - E2165. Fix teammate review view ]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2155._Calibration_submissions_should_be_copied_along_with_calibration_assignments CSC/ECE 517 Fall 2021 - E2155. Calibration submissions should be copied along with calibration assignments]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2148._Completion/Progress_View CSC/ECE 517 Fall 2021 - E2148. Completion/Progress view]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2158._Grading_audit_trail CSC/ECE 517 Fall 2021 - E2158. Grading audit trail ]
*[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2159._Expertiza_internationalization CSC/ECE 517 Fall 2021 - E2159. Expertiza internationalization]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2160._Implementing_and_testing_import_export_controllers#Description_about_project CSC/ECE 517 Fall 2021 - E2160. Implementing and testing import and export controllers]
*[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2161._Merge_code_for_role_based_reviewing_with_code_for_topic_specific_rubrics CSC/ECE 517 Fall 2021 - E2161. Merge code for role based reviewing with code for topic specific rubrics]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2164._Heatgrid_fixes_and_improvements#Description_about_project CSC/ECE 517 Fall 2021 - E2164. Heatgrid fixes and improvements]
* [[CSC/ECE 517 Fall 2021 - E2168. Testing - Reputations]]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2126._Testing_-_Team_Related_Files#Description_about_project CSC/ECE 517 Fall 2021 - E2126. Testing - Team Related Files]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2156._Issues_related_to_meta-reviewing#Description_about_project CSC/ECE 517 Fall 2021 - E2156. Issues related to meta-reviewing]
* [[CSC/ECE 517 Fall 2021 - E2169. Testing - Answer Tagging]]
* [[CSC/ECE 517 Fall 2021 - E2149. Finish Github metrics integration - Reputations]]
* [[E2157. Fix issues related to deadlines and late policies]]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2167._Testing_-_Team_Related_Files CSC/ECE 517 Fall 2021 - E2167. Testing - Team Related Files]

CSC/ECE 517 Fall 2021

2021-11-09T21:48:12Z

Asmathew:

== OSS Projects ==

* [[CSC/ECE 517 Fall 2021 - E2117. Refactor questionaires_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2128. Refactor student_quizzes_controller.rb & late_policies_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2129. Refactor auth_controller.rb & password_retrieval_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2132. Add tests cases for review mapping helper.rb]]
* [[CSC/ECE 517 Fall 2021 - E2134. Write unit tests for admin_controller.rb and institution_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2138. Auto-generate submission directory names based on assignment]]
* [[CSC/ECE 517 Fall 2021 - E2142. Improve e-mail notifications]]
* [[CSC/ECE 517 Fall 2021 - E2133. Write tests for popup_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2120. Refactor reputation_web_service_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2139. Remove multiple topics at a time]]
* [[CSC/ECE 517 Fall 2021 - E2131. Improve assessment360_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2121. Refactor suggestion_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2122. Refactor impersonate_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2123. Refactor sign_up_sheet_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2126. Refactor account_request_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2124. Refactor review_mapping_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2125. Refactor review_mapping_helper.rb]]
* [[CSC/ECE 517 Fall 2021 - E2127. Refactor teams_controller]]
* [[CSC/ECE 517 Fall 2021 - E2130. Refactor submitted_content_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2140. Create new late policy successfully and fix Bank link]]
* [[CSC/ECE 517 Fall 2021 - E2141. OSS project Finklestein: Instructors & Institutions]]
* [[CSC/ECE 517 Fall 2021 - E2144. Refactor delayed mailer and scheduled task]]
* [[CSC/ECE 517 Fall 2021 - E2147. Role-based reviewing]]
* [[CSC/ECE 517 Fall 2021 - E2145. OSS Project Beige]]
* [[CSC/ECE 517 Fall 2021 - E2146. Introduce a Student View for instructors]]
* [[CSC/ECE 517 Fall 2021 - Refactor Evaluation of SQL Queries]]
* [[CSC/ECE 517 Fall 2021 - E2135. Email notification to reviewers and instructors]]

== Final Projects ==
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2166._Testing_-_Scoring_%26_Grades#Description_about_project CSC/ECE 517 Fall 2021 - E2166. Testing - Scoring_and_Grades]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2150._Integrate_suggestion_detection_algorithm#Description_about_project CSC/ECE 517 Fall 2021 - E2150. Integrate suggestion detection algorithm]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2151._Allow_reviewers_to_bid_on_what_to_review CSC/ECE 517 Fall 2021 - E2151. Allow reviewers to bid on what to review]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2152._Revision_planning_tool#Description_about_project CSC/ECE 517 Fall 2021 - E2152. Revision_planning_tool]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2170._Testing_-_Response_Maps#Description_about_project CSC/ECE 517 Fall 2021 - E2170. Testing - Response Maps]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2153._Improving_search_facility_in_Expertiza#Description_about_project CSC/ECE 517 Fall 2021 - E2153. Improving search facility in Expertiza]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2162._Further_refactoring_and_improvement_of_review_mapping_helper CSC/ECE 517 Fall 2021 - E2162. Further refactoring and improvement of review mapping helper]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2163._Refactor_waitlist_functionality CSC/ECE 517 Fall 2021 - E2163. Refactor waitlist functionality]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2165._Fix_teammate-review_view CSC/ECE 517 Fall 2021 - E2165. Fix teammate review view ]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2155._Calibration_submissions_should_be_copied_along_with_calibration_assignments CSC/ECE 517 Fall 2021 - E2155. Calibration submissions should be copied along with calibration assignments]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2148._Completion/Progress_View CSC/ECE 517 Fall 2021 - E2148. Completion/Progress view]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2158._Grading_audit_trail CSC/ECE 517 Fall 2021 - E2158. Grading audit trail ]
*[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2159._Expertiza_internationalization CSC/ECE 517 Fall 2021 - E2159. Expertiza internationalization]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2160._Implementing_and_testing_import_export_controllers#Description_about_project CSC/ECE 517 Fall 2021 - E2160. Implementing and testing import and export controllers]
*[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2161._Merge_code_for_role_based_reviewing_with_code_for_topic_specific_rubrics CSC/ECE 517 Fall 2021 - E2161. Merge code for role based reviewing with code for topic specific rubrics]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2164._Heatgrid_fixes_and_improvements#Description_about_project CSC/ECE 517 Fall 2021 - E2164. Heatgrid fixes and improvements]
* [[CSC/ECE 517 Fall 2021 - E2168. Testing - Reputations]]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2126._Testing_-_Team_Related_Files#Description_about_project CSC/ECE 517 Fall 2021 - E2126. Testing - Team Related Files]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2156._Issues_related_to_meta-reviewing#Description_about_project CSC/ECE 517 Fall 2021 - E2156. Issues related to meta-reviewing]
* [[CSC/ECE 517 Fall 2021 - E2169. Testing - Answer Tagging]]
* [[CSC/ECE 517 Fall 2021 - E2149. Finish Github metrics integration - Reputations]]
* [[E2157. Fix issues related to deadlines and late policies]]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2167._Testing_-_Team_Related_Files#Description_about_project CSC/ECE 517 Fall 2021 - E2167. Testing - Team Related Files]

CSC/ECE 517 Fall 2021 - E2126. Testing - Team Related Files

2021-11-04T01:01:48Z

Asmathew:

__TOC__

= Relevant links =

= About Expertiza =
[http://expertiza.ncsu.edu/ Expertiza] is an open source project based on [http://rubyonrails.org/ Ruby on Rails] framework. It is a web based program that allows instructors to create and update/edit assignments/tasks, and then assigns them to students. Students then can submit, edit, and update their assignments, as well as peer review other student's assignments.

= Problem statement and background =
There are many files related to teams that don’t have enough tests: teams_controller, teams_users_controller, student_teams_controller, join_team_requests_controller, and advertise_for_partner_controller. They all need essentially the same kind of fixtures or mocks to enable testing: A team that is created, a couple of students that can be added to the team, an invitation that can be sent from one student to another student to join a particular team

= Approach Chosen & Why? =
In this project we have first identified all the set of scenarios related to team controllers. Each of the scenarios are identified as mentioned above and has been subdivided into a number of ways in which it can be realized. This will ensure that code is robust to any kind of unexpected changes and that the functionality will not be broken when deployed in production.
We have chosen to bring about this robustness of test by writing unit test and functional tests using RSpec and Capybara respectively. Unit Tests will ensure that the particular functionality is being tested in a isolated setup which would even include the edge cases whereas the functional tests will ensure that this teams feature is in resonance with the other features and works coherently.

= Implementation =

== teams_controller.rb ==

== teams_users_controller.rb ==
=== Scenario 1: Add new user to the selected team.===

* Given user is not defined. 
When given user is defined, link is provided to create the user. 

* Selected team to which user is being added belongs to an assignment: 
When user is not a participant of the assignment, link is provided to add the user to the assignment. 
When the assignment team already has maximum number of users, "Maximum users reached" notification is flashed. 

*Selected team to which user is being added belongs to a course: 
When user is not a participant of the course, link is provided to add the user to the course. 
When the course team already has maximum number of users, "Maximum users reached" notification is flashed. 

[[File:user_create.png|600px]]

=== Scenario 2: Delete user from the selected team.===

*User under assignment or course team is deleted. 
user association to the respective team is deleted and hence user is no longer part of the team. 

[[File:user_remove.png]]

== student_teams_controller.rb ==
 Scenario 1: Set the variables for view 
#If the current user is student and their User Ids match, then the following values are set: @send_invs, @received_invs, @current_due_date, @users_on_waiting_list, @teammate_review_allowed
# If the current user is not student or the User Ids do not match, then the return from method

Scenario 2: Create Student teams
# If team name is empty, flash an error message saying "Team name missing while creating team" and redirect to view_student_teams_path
# If team name is not empty and team name already in use, "Team name being created was already in use" and redirect to view_student_teams_path
# If team name is not empty and team name not in use, save team data, add logged in student to team and redirect to view_student_teams_path.
[[File:Team stud create.png]]

Scenario 3: Update team name:
# Find the team that should be updated.
# If there are no matching teams, call team_created_successfully and redirect to view_student_teams_path
# If there is exactly one match, then call team_created_successfully and redirect to view_student_teams_path
# If there are more than one team, then show the following error message "Team name being updated to was already in use" and redirect to edit_student_teams_path
[[File:Team student update.png]]

Scenario 4: Remove team participants
# Find the user who has to be removed.
# Remove the user from team.
# If the team does not have any more participants, remove the team record from database.
# If the assignment has sign up sheet, then add the topic back to topics pool or assign the topic to a new team from waitlist
# Remove all the invitations sent and redirect to view_student_teams_path
[[File:Team stud remove.png]]

== join_team_requests_controller.rb ==

P = Pending status

D = Denied status

A = Accepted status

Scenario 1: Creating a team request
# If the team id is verified along with user id and assignment id, create a new request and change @join_team_request = 'P' .
# If error occurs, flash error message.

Scenario 2: Decline a team request.
# After verifying team_user_id, change @join_team_request.status = 'D' .
# Redirect to view_student_teams_path

Scenario 3: Check team status.
# If team if full. Print error message "This team is full." .
# If team is not empty, print message "You are already a member of this team." .

== advertise_partner_controller.rb ==
Scenario 1: Creating new advertisement for partners.
# We set the advertise_for_partner : True , comments_for_advertisement[param] when the user wants to set a new advertisement for partners in AssignmentTeam model.
[[File:Teams adv1.png]]

Scenario 2: Updating the advertisement.
# We set the comments_for_advertisement[param] when the user wants to set a new advertisement for partners in AssignmentTeam model.
# Update Unsuccessful : If there is an error during update then the following error message is thrown "An error occurred and your advertisement was not updated." and edit page is rendered.
# Update Successful : If the advertisement is successfully updated in the database then the "Your advertisement was successfully updated!" message is prompted and the user is redirected to the view_student_teams_path .

[[File:Teams adv create.png]]

Scenario 3: Remove the advertisement.
# We set the advertise_for_partner : False , comments_for_advertisement : nil when the user wants to set a new advertisement for partners in AssignmentTeam model.
# Remove Unsuccessful : If there is an error during removing the advertisement then the following error message is thrown "An error occurred and your advertisement was not removed." and the previous page is rendered.
# Remove Successful : If the advertisement is successfully removed in the database then the "Your advertisement was successfully removed!" message is prompted and the user is redirected to the view_student_teams_path .
[[File:Teams adv remove.png]]

CSC/ECE 517 Fall 2021 - E2126. Testing - Team Related Files

2021-11-04T00:57:28Z

Asmathew:

__TOC__

= Relevant links =

= About Expertiza =
[http://expertiza.ncsu.edu/ Expertiza] is an open source project based on [http://rubyonrails.org/ Ruby on Rails] framework. It is a web based program that allows instructors to create and update/edit assignments/tasks, and then assigns them to students. Students then can submit, edit, and update their assignments, as well as peer review other student's assignments.

= Problem statement and background =
There are many files related to teams that don’t have enough tests: teams_controller, teams_users_controller, student_teams_controller, join_team_requests_controller, and advertise_for_partner_controller. They all need essentially the same kind of fixtures or mocks to enable testing: A team that is created, a couple of students that can be added to the team, an invitation that can be sent from one student to another student to join a particular team

= Approach Chosen & Why? =
In this project we have first identified all the set of scenarios related to team controllers. Each of the scenarios are identified as mentioned above and has been subdivided into a number of ways in which it can be realized. This will ensure that code is robust to any kind of unexpected changes and that the functionality will not be broken when deployed in production.
We have chosen to bring about this robustness of test by writing unit test and functional tests using RSpec and Capybara respectively. Unit Tests will ensure that the particular functionality is being tested in a isolated setup which would even include the edge cases whereas the functional tests will ensure that this teams feature is in resonance with the other features and works coherently.

= Implementation =

== teams_controller.rb ==

== teams_users_controller.rb ==
=== Scenario 1: Add new user to the selected team.===

* Given user is not defined. 
When given user is defined, link is provided to create the user. 

* Selected team to which user is being added belongs to an assignment: 
When user is not a participant of the assignment, link is provided to add the user to the assignment. 
When the assignment team already has maximum number of users, "Maximum users reached" notification is flashed. 

*Selected team to which user is being added belongs to a course: 
When user is not a participant of the course, link is provided to add the user to the course. 
When the course team already has maximum number of users, "Maximum users reached" notification is flashed. 

[[File:user_create.png|600px]]

=== Scenario 2: Delete user from the selected team.===

*User under assignment or course team is deleted. 
user association to the respective team is deleted and hence user is no longer part of the team. 

[[File:user_remove.png]]

== student_teams_controller.rb ==
 Scenario 1: Set the variables for view 
#If the current user is student and their User Ids match, then the following values are set: @send_invs, @received_invs, @current_due_date, @users_on_waiting_list, @teammate_review_allowed
# If the current user is not student or the User Ids do not match, then the return from method

Scenario 2: Create Student teams
# If team name is empty, flash an error message saying "Team name missing while creating team" and redirect to view_student_teams_path
# If team name is not empty and team name already in use, "Team name being created was already in use" and redirect to view_student_teams_path
# If team name is not empty and team name not in use, save team data, add logged in student to team and redirect to view_student_teams_path.
[[File:Team stud create.png]]

Scenario 3: Update team name:
# Find the team that should be updated.
# If there are no matching teams, call team_created_successfully and redirect to view_student_teams_path
# If there is exactly one match, then call team_created_successfully and redirect to view_student_teams_path
# If there are more than one team, then show the following error message "Team name being updated to was already in use" and redirect to edit_student_teams_path
[[File:Team student update.png]]

Scenario 4: Remove team participants
# Find the user who has to be removed.
# Remove the user from team.
# If the team does not have any more participants, remove the team record from database.
# If the assignment has sign up sheet, then add the topic back to topics pool or assign the topic to a new team from waitlist
# Remove all the invitations sent and redirect to view_student_teams_path
[[File:Team stud remove.png]]

== join_team_requests_controller.rb ==

P = Pending status

D = Denied status

A = Accepted status

Scenario 1: Creating a team request
# If the team id is verified along with user id and assignment id, create a new request and change @join_team_request = 'P' .
# If error occurs, flash error message.

Scenario 2: Decline a team request.
# After verifying team_user_id, change @join_team_request.status = 'D' .
# Redirect to view_student_teams_path

Scenario 3: Check team status.
# If team if full. Print error message "This team is full." .
# If team is not empty, print message "You are already a member of this team." .

Scenario 4: CRUD for join team request
[Flow]

== advertise_partner_controller.rb ==
Scenario 1: Creating new advertisement for partners.
# We set the advertise_for_partner : True , comments_for_advertisement[param] when the user wants to set a new advertisement for partners in AssignmentTeam model.
[[File:Teams adv1.png]]

Scenario 2: Updating the advertisement.
# We set the comments_for_advertisement[param] when the user wants to set a new advertisement for partners in AssignmentTeam model.
# Update Unsuccessful : If there is an error during update then the following error message is thrown "An error occurred and your advertisement was not updated." and edit page is rendered.
# Update Successful : If the advertisement is successfully updated in the database then the "Your advertisement was successfully updated!" message is prompted and the user is redirected to the view_student_teams_path .

[[File:Teams adv create.png]]

Scenario 3: Remove the advertisement.
# We set the advertise_for_partner : False , comments_for_advertisement : nil when the user wants to set a new advertisement for partners in AssignmentTeam model.
# Remove Unsuccessful : If there is an error during removing the advertisement then the following error message is thrown "An error occurred and your advertisement was not removed." and the previous page is rendered.
# Remove Successful : If the advertisement is successfully removed in the database then the "Your advertisement was successfully removed!" message is prompted and the user is redirected to the view_student_teams_path .
[[File:Teams adv remove.png]]

CSC/ECE 517 Fall 2021 - E2126. Testing - Team Related Files

2021-11-04T00:56:17Z

Asmathew:

__TOC__

= Relevant links =

= About Expertiza =
[http://expertiza.ncsu.edu/ Expertiza] is an open source project based on [http://rubyonrails.org/ Ruby on Rails] framework. It is a web based program that allows instructors to create and update/edit assignments/tasks, and then assigns them to students. Students then can submit, edit, and update their assignments, as well as peer review other student's assignments.

= Problem statement and background =
There are many files related to teams that don’t have enough tests: teams_controller, teams_users_controller, student_teams_controller, join_team_requests_controller, and advertise_for_partner_controller. They all need essentially the same kind of fixtures or mocks to enable testing: A team that is created, a couple of students that can be added to the team, an invitation that can be sent from one student to another student to join a particular team

= Approach Chosen & Why? =
In this project we have first identified all the set of scenarios related to team controllers. Each of the scenarios are identified as mentioned above and has been subdivided into a number of ways in which it can be realized. This will ensure that code is robust to any kind of unexpected changes and that the functionality will not be broken when deployed in production.
We have chosen to bring about this robustness of test by writing unit test and functional tests using RSpec and Capybara respectively. Unit Tests will ensure that the particular functionality is being tested in a isolated setup which would even include the edge cases whereas the functional tests will ensure that this teams feature is in resonance with the other features and works coherently.

= Implementation =

== teams_controller.rb ==

== teams_users_controller.rb ==
=== Scenario 1: Add new user to the selected team.===

* Given user is not defined. 
When given user is defined, link is provided to create the user. 

* Selected team to which user is being added belongs to an assignment: 
When user is not a participant of the assignment, link is provided to add the user to the assignment. 
When the assignment team already has maximum number of users, "Maximum users reached" notification is flashed. 

*Selected team to which user is being added belongs to a course: 
When user is not a participant of the course, link is provided to add the user to the course. 
When the course team already has maximum number of users, "Maximum users reached" notification is flashed. 

[[File:user_create.png|600px]]

=== Scenario 2: Delete user from the selected team.===

*User under assignment or course team is deleted. 
user association to the respective team is deleted and hence user is no longer part of the team. 

[[File:user_remove.png]]

== student_teams_controller.rb ==
Scenario 1: Set the variables for view
#If the current user is student and their User Ids match, then the following values are set: @send_invs, @received_invs, @current_due_date, @users_on_waiting_list, @teammate_review_allowed
# If the current user is not student or the User Ids do not match, then the return from method

Scenario 2: Create Student teams
# If team name is empty, flash an error message saying "Team name missing while creating team" and redirect to view_student_teams_path
# If team name is not empty and team name already in use, "Team name being created was already in use" and redirect to view_student_teams_path
# If team name is not empty and team name not in use, save team data, add logged in student to team and redirect to view_student_teams_path.
[[File:Team stud create.png]]

Scenario 3: Update team name:
# Find the team that should be updated.
# If there are no matching teams, call team_created_successfully and redirect to view_student_teams_path
# If there is exactly one match, then call team_created_successfully and redirect to view_student_teams_path
# If there are more than one team, then show the following error message "Team name being updated to was already in use" and redirect to edit_student_teams_path
[[File:Team student update.png]]

Scenario 4: Remove team participants
# Find the user who has to be removed.
# Remove the user from team.
# If the team does not have any more participants, remove the team record from database.
# If the assignment has sign up sheet, then add the topic back to topics pool or assign the topic to a new team from waitlist
# Remove all the invitations sent and redirect to view_student_teams_path
[[File:Team stud remove.png]]

== join_team_requests_controller.rb ==

P = Pending status

D = Denied status

A = Accepted status

Scenario 1: Creating a team request
# If the team id is verified along with user id and assignment id, create a new request and change @join_team_request = 'P' .
# If error occurs, flash error message.

Scenario 2: Decline a team request.
# After verifying team_user_id, change @join_team_request.status = 'D' .
# Redirect to view_student_teams_path

Scenario 3: Check team status.
# If team if full. Print error message "This team is full." .
# If team is not empty, print message "You are already a member of this team." .

Scenario 4: CRUD for join team request
[Flow]

== advertise_partner_controller.rb ==
Scenario 1: Creating new advertisement for partners.
# We set the advertise_for_partner : True , comments_for_advertisement[param] when the user wants to set a new advertisement for partners in AssignmentTeam model.
[[File:Teams adv1.png]]

Scenario 2: Updating the advertisement.
# We set the comments_for_advertisement[param] when the user wants to set a new advertisement for partners in AssignmentTeam model.
# Update Unsuccessful : If there is an error during update then the following error message is thrown "An error occurred and your advertisement was not updated." and edit page is rendered.
# Update Successful : If the advertisement is successfully updated in the database then the "Your advertisement was successfully updated!" message is prompted and the user is redirected to the view_student_teams_path .

[[File:Teams adv create.png]]

Scenario 3: Remove the advertisement.
# We set the advertise_for_partner : False , comments_for_advertisement : nil when the user wants to set a new advertisement for partners in AssignmentTeam model.
# Remove Unsuccessful : If there is an error during removing the advertisement then the following error message is thrown "An error occurred and your advertisement was not removed." and the previous page is rendered.
# Remove Successful : If the advertisement is successfully removed in the database then the "Your advertisement was successfully removed!" message is prompted and the user is redirected to the view_student_teams_path .
[[File:Teams adv remove.png]]

CSC/ECE 517 Fall 2021 - E2126. Testing - Team Related Files

2021-11-04T00:53:58Z

Asmathew:

__TOC__

= Relevant links =

= About Expertiza =
[http://expertiza.ncsu.edu/ Expertiza] is an open source project based on [http://rubyonrails.org/ Ruby on Rails] framework. It is a web based program that allows instructors to create and update/edit assignments/tasks, and then assigns them to students. Students then can submit, edit, and update their assignments, as well as peer review other student's assignments.

= Problem statement and background =
There are many files related to teams that don’t have enough tests: teams_controller, teams_users_controller, student_teams_controller, join_team_requests_controller, and advertise_for_partner_controller. They all need essentially the same kind of fixtures or mocks to enable testing: A team that is created, a couple of students that can be added to the team, an invitation that can be sent from one student to another student to join a particular team

= Approach Chosen & Why? =
In this project we have first identified all the set of scenarios related to team controllers. Each of the scenarios are identified as mentioned above and has been subdivided into a number of ways in which it can be realized. This will ensure that code is robust to any kind of unexpected changes and that the functionality will not be broken when deployed in production.
We have chosen to bring about this robustness of test by writing unit test and functional tests using RSpec and Capybara respectively. Unit Tests will ensure that the particular functionality is being tested in a isolated setup which would even include the edge cases whereas the functional tests will ensure that this teams feature is in resonance with the other features and works coherently.

= Implementation =

== teams_controller.rb ==

== teams_users_controller.rb ==

== student_teams_controller.rb ==
Scenario 1: Set the variables for view
#If the current user is student and their User Ids match, then the following values are set: @send_invs, @received_invs, @current_due_date, @users_on_waiting_list, @teammate_review_allowed
# If the current user is not student or the User Ids do not match, then the return from method

Scenario 2: Create Student teams
# If team name is empty, flash an error message saying "Team name missing while creating team" and redirect to view_student_teams_path
# If team name is not empty and team name already in use, "Team name being created was already in use" and redirect to view_student_teams_path
# If team name is not empty and team name not in use, save team data, add logged in student to team and redirect to view_student_teams_path.
[[File:Team stud create.png]]

Scenario 3: Update team name:
# Find the team that should be updated.
# If there are no matching teams, call team_created_successfully and redirect to view_student_teams_path
# If there is exactly one match, then call team_created_successfully and redirect to view_student_teams_path
# If there are more than one team, then show the following error message "Team name being updated to was already in use" and redirect to edit_student_teams_path
[[File:Team student update.png]]

Scenario 4: Remove team participants
# Find the user who has to be removed.
# Remove the user from team.
# If the team does not have any more participants, remove the team record from database.
# If the assignment has sign up sheet, then add the topic back to topics pool or assign the topic to a new team from waitlist
# Remove all the invitations sent and redirect to view_student_teams_path
[[File:Team stud remove.png]]

== join_team_requests_controller.rb ==

P = Pending status

D = Denied status

A = Accepted status

Scenario 1: Creating a team request
# If the team id is verified along with user id and assignment id, create a new request and change @join_team_request = 'P' .
# If error occurs, flash error message.

Scenario 2: Decline a team request.
# After verifying team_user_id, change @join_team_request.status = 'D' .
# Redirect to view_student_teams_path

Scenario 3: Check team status.
# If team if full. Print error message "This team is full." .
# If team is not empty, print message "You are already a member of this team." .

Scenario 4: CRUD for join team request
[Flow]

== advertise_partner_controller.rb ==
Scenario 1: Creating new advertisement for partners.
# We set the advertise_for_partner : True , comments_for_advertisement[param] when the user wants to set a new advertisement for partners in AssignmentTeam model.
[[File:Teams adv1.png]]

Scenario 2: Updating the advertisement.
# We set the comments_for_advertisement[param] when the user wants to set a new advertisement for partners in AssignmentTeam model.
# Update Unsuccessful : If there is an error during update then the following error message is thrown "An error occurred and your advertisement was not updated." and edit page is rendered.
# Update Successful : If the advertisement is successfully updated in the database then the "Your advertisement was successfully updated!" message is prompted and the user is redirected to the view_student_teams_path .

[[File:Teams adv create.png]]

Scenario 3: Remove the advertisement.
# We set the advertise_for_partner : False , comments_for_advertisement : nil when the user wants to set a new advertisement for partners in AssignmentTeam model.
# Remove Unsuccessful : If there is an error during removing the advertisement then the following error message is thrown "An error occurred and your advertisement was not removed." and the previous page is rendered.
# Remove Successful : If the advertisement is successfully removed in the database then the "Your advertisement was successfully removed!" message is prompted and the user is redirected to the view_student_teams_path .
[[File:Teams adv remove.png]]

File:Team stud remove.png

2021-11-04T00:53:24Z

Asmathew:

File:Team student update.png

2021-11-04T00:52:27Z

Asmathew:

File:Team stud create.png

2021-11-04T00:51:11Z

Asmathew:

CSC/ECE 517 Fall 2021 - E2126. Testing - Team Related Files

2021-11-04T00:46:55Z

Asmathew:

File:Teams adv remove.png

2021-11-04T00:45:46Z

Asmathew:

File:Teams adv create.png

2021-11-04T00:44:55Z

Asmathew:

CSC/ECE 517 Fall 2021 - E2126. Testing - Team Related Files

2021-11-04T00:42:33Z

Asmathew:

File:Teams adv1.png

2021-11-04T00:39:01Z

Asmathew:

CSC/ECE 517 Fall 2021 - E2126. Testing - Team Related Files

2021-11-03T21:58:27Z

Asmathew: Created page with "__TOC__ = Relevant links = = About Expertiza = [http://expertiza.ncsu.edu/ Expertiza] is an open source project based on [http://rubyonrails.org/ Ruby on Rails] framework...."

CSC/ECE 517 Fall 2021

2021-11-03T21:57:40Z

Asmathew:

== OSS Projects ==

* [[CSC/ECE 517 Fall 2021 - E2117. Refactor questionaires_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2128. Refactor student_quizzes_controller.rb & late_policies_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2129. Refactor auth_controller.rb & password_retrieval_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2132. Add tests cases for review mapping helper.rb]]
* [[CSC/ECE 517 Fall 2021 - E2134. Write unit tests for admin_controller.rb and institution_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2138. Auto-generate submission directory names based on assignment]]
* [[CSC/ECE 517 Fall 2021 - E2142. Improve e-mail notifications]]
* [[CSC/ECE 517 Fall 2021 - E2133. Write tests for popup_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2120. Refactor reputation_web_service_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2139. Remove multiple topics at a time]]
* [[CSC/ECE 517 Fall 2021 - E2131. Improve assessment360_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2121. Refactor suggestion_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2122. Refactor impersonate_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2123. Refactor sign_up_sheet_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2126. Refactor account_request_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2124. Refactor review_mapping_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2125. Refactor review_mapping_helper.rb]]
* [[CSC/ECE 517 Fall 2021 - E2127. Refactor teams_controller]]
* [[CSC/ECE 517 Fall 2021 - E2130. Refactor submitted_content_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2140. Create new late policy successfully and fix Bank link]]
* [[CSC/ECE 517 Fall 2021 - E2141. OSS project Finklestein: Instructors & Institutions]]
* [[CSC/ECE 517 Fall 2021 - E2144. Refactor delayed mailer and scheduled task]]
* [[CSC/ECE 517 Fall 2021 - E2147. Role-based reviewing]]
* [[CSC/ECE 517 Fall 2021 - E2145. OSS Project Beige]]
* [[CSC/ECE 517 Fall 2021 - E2146. Introduce a Student View for instructors]]
* [[CSC/ECE 517 Fall 2021 - Refactor Evaluation of SQL Queries]]
* [[CSC/ECE 517 Fall 2021 - E2135. Email notification to reviewers and instructors]]
* [[CSC/ECE 517 Fall 2021 - E2168. Testing - Reputations]]
* [[CSC/ECE 517 Fall 2021 - E2149. Finish Github metrics integration - Reputations]]

== Final Projects ==
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2166._Testing_-_Scoring_%26_Grades#Description_about_project CSC/ECE 517 Fall 2021 - E2166. Testing - Scoring_and_Grades]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2150._Integrate_suggestion_detection_algorithm#Description_about_project CSC/ECE 517 Fall 2021 - E2150. Integrate suggestion detection algorithm]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2151._Allow_reviewers_to_bid_on_what_to_review CSC/ECE 517 Fall 2021 - E2151. Allow reviewers to bid on what to review]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2152._Revision_planning_tool#Description_about_project CSC/ECE 517 Fall 2021 - E2152. Revision_planning_tool]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2170._Testing_-_Response_Maps#Description_about_project CSC/ECE 517 Fall 2021 - E2170. Testing - Response Maps]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2153._Improving_search_facility_in_Expertiza#Description_about_project CSC/ECE 517 Fall 2021 - E2153. Improving search facility in Expertiza]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2162._Further_refactoring_and_improvement_of_review_mapping_helper CSC/ECE 517 Fall 2021 - E2162. Further refactoring and improvement of review mapping helper]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2163._Refactor_waitlist_functionality CSC/ECE 517 Fall 2021 - E2163. Refactor waitlist functionality]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2165._Fix_teammate-review_view CSC/ECE 517 Fall 2021 - E2165. Fix teammate review view ]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2155._Calibration_submissions_should_be_copied_along_with_calibration_assignments CSC/ECE 517 Fall 2021 - E2155. Calibration submissions should be copied along with calibration assignments]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2148._Completion/Progress_View CSC/ECE 517 Fall 2021 - E2148. Completion/Progress view]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2158._Grading_audit_trail CSC/ECE 517 Fall 2021 - E2158. Grading audit trail ]
*[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2159._Expertiza_internationalization CSC/ECE 517 Fall 2021 - E2159. Expertiza internationalization]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2160._Implementing_and_testing_import_export_controllers#Description_about_project CSC/ECE 517 Fall 2021 - E2160. Implementing and testing import and export controllers]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2164._Heatgrid_fixes_and_improvements#Description_about_project CSC/ECE 517 Fall 2021 - E2164. Heatgrid fixes and improvements]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2126._Testing_-_Team_Related_Files#Description_about_project CSC/ECE 517 Fall 2021 - E2126. Testing - Team Related Files]

CSC/ECE 517 Fall 2021 - E2129. Refactor auth controller.rb & password retrieval controller.rb

2021-10-26T18:58:04Z

Asmathew:

== E2129: Refactor auth_controller.rb & password_retrieval_controller.rb ==

__TOC__

== Relevant links ==
#Github : https://github.com/smanishs175/expertiza.git
#Github pull request: https://github.com/expertiza/expertiza/pull/2084
#VCL Deployment: http://152.7.176.119:8080
##Deployment is scheduled to be available until November 13, 2021
##In the case of a VCL timeout before then, please contact the group so they can reboot the server. This is a known issue with VCL that is out of their control.

== About Expertiza ==
[http://expertiza.ncsu.edu/ Expertiza] is an open source project based on [http://rubyonrails.org/ Ruby on Rails] framework. It is a web based program that allows instructors to create and update/edit assignments/tasks, and then assigns them to students. Students then can submit, edit, and update their assignments, as well as peer review other student's assignments.

== Description Of Current Project ==
Our goal for this project is to refactor certain files (auth_controller.rb and password_retrieval_controller.rb) to follow essential Ruby on Rails design principles. Since this is a refactoring project, all [https://rspec.info/ RSpec] test cases must result in the same behavior as before, with no changes to the overall functionality of the code.

== Files Modified/Added ==
Two controller files were modified for this project: 
# auth_controller.rb (expertiza/app/controllers/auth_controller.rb) 
# password_retrieval_controller.rb (expertiza/app/controllers/password_retrieval_controller.rb) 

One RSpec file was added to help test filters: 
# filters.rb (expertiza/spec/support/matchers/filters.rb) 

=== auth_controller.rb ===
The auth_controller deals with user authentication when they try and login. Spelling needed to be adjusted to American style. Some comments were added and logger call locations were moved to before/after filters.

=====About Filters=====
Rails filters are methods that run before or after a controller's action method is executed. They are helpful when you want to ensure that a given block of code runs with whatever action method is called.

Rails support three types of filter methods:

Before filters- before_action filter is executed before the code in action controller is executed.
After filters- after_action filter is executed after the code in action controller is executed.
Around filters- around_action filter is executed before and after the code in action controller is executed.

=====Reason for the need of Filters in Authentication Controller=====
Calls to logger should be written as filters is that a call to a logger tends to be a full line of code. If we put the full line of code everywhere that the logger needs to be called, the logger text tends to distract from the rest of the work done by the method. It tends to pollute the code. If it is an after_action, then it gets called automatically when the method finishes, without having to appear in the method at all. It is a cleaner way of calling the logger. It is a case of the Separation of Responsibility principle.

Filter loggers are added to prioritize the method calls in function: 
#These filters are added for specific reasons: When the action_allowed? controller deals with authorizing the actions such as login, logout, login failed etc.
1. before_action :action_allowed?, only:[:login,:login_failed,:google_login] 
2. after_action :action_allowed?, only:[:logout] 

=== password_retrieval_controller.rb ===
The password_retrieval_controller deals with the process of updating and resetting the password for users, in case they have forgotten their password. Comments were needed in many places in this file, and some comments that were there before had to be modified. A user alert had to be modified to be more clear, and a hard-coded value had to be moved to a parameter.

=== filters.rb ===
All previous tests for Authentication_Controller are working. Authentication_Controller with filters is working fine. We created filters.rb file in spec/support/matchers/ directory. This was additional functionality which we tried to do.This filters.rb file was to be called from Authentication controller. We were not able to solve error raised for this additional part

== List Of Changes ==

=== auth_controller.rb ===
Spelling was adjusted from authorised to authorized: 
[[File:E2129_Spelling_fix.PNG]] 
[[File:E2129_Spelling_fix_2.PNG]] 

Add a comment to explain the branches of a conjunction: 
[[File:E2129_Branch_conjunction_comment.PNG]] 

Add filters for loggers: 
[[File:E2129_Auth_controller_filters_before.PNG]]
[[File:E2129_Auth_controller_filters_after.png]] 

=== password_retrieval_controller.rb ===

Method check_reset_url was renamed to a more descriptive check_token_validity: 
[[File:E2129_Check_token_validity.PNG]] 

A parameter was created for the token expiration time instead of hardcoding it: 
[[File:E2129_Token_time.PNG]] 

Descriptive comments were added to send_password: 
[[File:E2129_Send_password_comments.PNG]] 

A statement inside the reset_password method that was copied from the forgotten method was replaced with a call to the forgotten method: 
[[File:E2129_Change_to_forgotten.PNG]] 
[[File:E2129_Forgotten.PNG]] 

A code block inside the check_reset_url method that was copied from the reset_password method was replaced with a call to the reset_password method: 
[[File:E2129_Change_to_reset_password.PNG]] 
[[File:E2129_Reset_password.PNG]] 

An error message in the check_reset_url method was updated to be more descriptive to a user: 
[[File:E2129_Invalid_token_user_message.PNG]] 

=== filters.rb ===
The contents of the new file support/matchers/filters.rb is shown below 
[[File:E2129_filters.PNG]]

== Test Plan ==
Since this is just a refactoring project. No test cases have been written.
Although, we wrote a file which will test the functionality of the filters.

== Testing Details ==
=== 1. The auth_controller.rb : ===
The file has been tested using rspec. 
Run the code:
rspec spec/helpers/authorization_helper_spec.rb . All test cases are passing as expected. 
[[File:E2129_testing_auth_controller.png]] 

=== 2. The password_retrieval_controller.rb ===
The file has been tested using rspec. 
Run the code:
rspec spec/helpers/password_retrieval_controller.rb . All test cases are passing as expected.
[[File:E2129_password_retrieval_controller.png]] 

== The Team ==
Aaron Mathew - asmathew@ncsu.edu 
Manish Shinde - msshinde@ncsu.edu 
Quinn Dibble - qdibble@ncsu.edu

CSC/ECE 517 Fall 2021 - E2129. Refactor auth controller.rb & password retrieval controller.rb

2021-10-23T20:50:30Z

Asmathew:

== E2129: Refactor auth_controller.rb & password_retrieval_controller.rb ==

__TOC__

== Relevant links ==
#Github : https://github.com/smanishs175/expertiza.git
#VCL Deployment: http://152.7.176.119:8080
##Deployment is scheduled to be available until November 13, 2021
##In the case of a VCL timeout before then, please contact the group so they can reboot the server. This is a known issue with VCL that is out of their control.

== About Expertiza ==
[http://expertiza.ncsu.edu/ Expertiza] is an open source project based on [http://rubyonrails.org/ Ruby on Rails] framework. It is a web based program that allows instructors to create and update/edit assignments/tasks, and then assigns them to students. Students then can submit, edit, and update their assignments, as well as peer review other student's assignments.

== Description Of Current Project ==
Our goal for this project is to refactor certain files (auth_controller.rb and password_retrieval_controller.rb) to follow essential Ruby on Rails design principles. Since this is a refactoring project, all [https://rspec.info/ RSpec] test cases must result in the same behavior as before, with no changes to the overall functionality of the code.

== Files Modified/Added ==
Two controller files were modified for this project: 
# auth_controller.rb (expertiza/app/controllers/auth_controller.rb) 
# password_retrieval_controller.rb (expertiza/app/controllers/password_retrieval_controller.rb) 

One RSpec file was added to help test filters: 
# filters.rb (expertiza/spec/support/matchers/filters.rb) 

=== auth_controller.rb ===
The auth_controller deals with user authentication when they try and login. Spelling needed to be adjusted to American style. Some comments were added and logger call locations were moved to before/after filters.

=====About Filters=====
Rails filters are methods that run before or after a controller's action method is executed. They are helpful when you want to ensure that a given block of code runs with whatever action method is called.

Rails support three types of filter methods:

Before filters- before_action filter is executed before the code in action controller is executed.
After filters- after_action filter is executed after the code in action controller is executed.
Around filters- around_action filter is executed before and after the code in action controller is executed.

=====Reason for the need of Filters in Authentication Controller=====
Calls to logger should be written as filters is that a call to a logger tends to be a full line of code. If we put the full line of code everywhere that the logger needs to be called, the logger text tends to distract from the rest of the work done by the method. It tends to pollute the code. If it is an after_action, then it gets called automatically when the method finishes, without having to appear in the method at all. It is a cleaner way of calling the logger. It is a case of the Separation of Responsibility principle.

Filter loggers are added to prioritize the method calls in function: 
#These filters are added for specific reasons: When the action_allowed? controller deals with authorizing the actions such as login, logout, login failed etc.
1. before_action :action_allowed?, only:[:login,:login_failed,:google_login] 
2. after_action :action_allowed?, only:[:logout] 

=== password_retrieval_controller.rb ===
The password_retrieval_controller deals with the process of updating and resetting the password for users, in case they have forgotten their password. Comments were needed in many places in this file, and some comments that were there before had to be modified. A user alert had to be modified to be more clear, and a hard-coded value had to be moved to a parameter.

=== filters.rb ===
All previous tests for Authentication_Controller are working. Authentication_Controller with filters is working fine. We created filters.rb file in spec/support/matchers/ directory. This was additional functionality which we tried to do.This filters.rb file was to be called from Authentication controller. We were not able to solve error raised for this additional part

== List Of Changes ==

=== auth_controller.rb ===
Spelling was adjusted from authorised to authorized: 
[[File:E2129_Spelling_fix.PNG]] 
[[File:E2129_Spelling_fix_2.PNG]] 

Add a comment to explain the branches of a conjunction: 
[[File:E2129_Branch_conjunction_comment.PNG]] 

Add filters for loggers: 
[[File:E2129_Auth_controller_filters_before.PNG]]
[[File:E2129_Auth_controller_filters_after.png]] 

=== password_retrieval_controller.rb ===

Method check_reset_url was renamed to a more descriptive check_token_validity: 
[[File:E2129_Check_token_validity.PNG]] 

A parameter was created for the token expiration time instead of hardcoding it: 
[[File:E2129_Token_time.PNG]] 

Descriptive comments were added to send_password: 
[[File:E2129_Send_password_comments.PNG]] 

A statement inside the reset_password method that was copied from the forgotten method was replaced with a call to the forgotten method: 
[[File:E2129_Change_to_forgotten.PNG]] 
[[File:E2129_Forgotten.PNG]] 

A code block inside the check_reset_url method that was copied from the reset_password method was replaced with a call to the reset_password method: 
[[File:E2129_Change_to_reset_password.PNG]] 
[[File:E2129_Reset_password.PNG]] 

An error message in the check_reset_url method was updated to be more descriptive to a user: 
[[File:E2129_Invalid_token_user_message.PNG]] 

=== filters.rb ===
The contents of the new file support/matchers/filters.rb is shown below 
[[File:E2129_filters.PNG]]

== Test Plan ==
Since this is just a refactoring project. No test cases have been written.
Although, we wrote a file which will test the functionality of the filters.

== Testing Details ==
=== 1. The auth_controller.rb : ===
The file has been tested using rspec. 
Run the code:
rspec spec/helpers/authorization_helper_spec.rb . All test cases are passing as expected. 
[[File:E2129_testing_auth_controller.png]] 

=== 2. The password_retrieval_controller.rb ===
The file has been tested using rspec. 
Run the code:
rspec spec/helpers/password_retrieval_controller.rb . All test cases are passing as expected.
[[File:E2129_password_retrieval_controller.png]] 

== The Team ==
Aaron Mathew - asmathew@ncsu.edu 
Manish Shinde - msshinde@ncsu.edu 
Quinn Dibble - qdibble@ncsu.edu

CSC/ECE 517 Fall 2021 - E2129. Refactor auth controller.rb & password retrieval controller.rb

2021-10-23T20:21:47Z

Asmathew:

== E2129: Refactor auth_controller.rb & password_retrieval_controller.rb ==

__TOC__

== Relevant links ==
#Github : https://github.com/smanishs175/expertiza.git
#VCL Deployment: http://152.7.176.119:8080
##Deployment is scheduled to be available until November 13, 2021
##In the case of a VCL timeout before then, please contact the group so they can reboot the server. This is a known issue with VCL that is out of their control.

== About Expertiza ==
[http://expertiza.ncsu.edu/ Expertiza] is an open source project based on [http://rubyonrails.org/ Ruby on Rails] framework. It is a web based program that allows instructors to create and update/edit assignments/tasks, and then assigns them to students. Students then can submit, edit, and update their assignments, as well as peer review other student's assignments.

== Description Of Current Project ==
Our goal for this project is to refactor certain files (auth_controller.rb and password_retrieval_controller.rb) to follow essential Ruby on Rails design principles. Since this is a refactoring project, all [https://rspec.info/ RSpec] test cases must result in the same behavior as before, with no changes to the overall functionality of the code.

== Files Modified/Added ==
Two controller files were modified for this project: 
# auth_controller.rb (expertiza/app/controllers/auth_controller.rb) 
# password_retrieval_controller.rb (expertiza/app/controllers/password_retrieval_controller.rb) 

One RSpec file was added to help test filters: 
# filters.rb (expertiza/spec/support/matchers/filters.rb) 

=== auth_controller.rb ===
The auth_controller deals with user authentication when they try and login. Spelling needed to be adjusted to American style. Some comments were added and logger call locations were moved to before/after filters.

=====About Filters=====
Rails filters are methods that run before or after a controller's action method is executed. They are helpful when you want to ensure that a given block of code runs with whatever action method is called.

Rails support three types of filter methods:

Before filters- before_action filter is executed before the code in action controller is executed.
After filters- after_action filter is executed after the code in action controller is executed.
Around filters- around_action filter is executed before and after the code in action controller is executed.

=====Reason for the need of Filters in Authentication Controller=====
Calls to logger should be written as filters is that a call to a logger tends to be a full line of code. If we put the full line of code everywhere that the logger needs to be called, the logger text tends to distract from the rest of the work done by the method. It tends to pollute the code. If it is an after_action, then it gets called automatically when the method finishes, without having to appear in the method at all. It is a cleaner way of calling the logger. It is a case of the Separation of Responsibility principle.

Filter loggers are added to prioritize the method calls in function: 
#These filters are added for specific reasons: When the action_allowed? controller deals with authorizing the actions such as login, logout, login failed etc.
1. before_action :action_allowed?, only:[:login,:login_failed,:google_login] 
2. after_action :action_allowed?, only:[:logout] 

=== password_retrieval_controller.rb ===
The password_retrieval_controller deals with the process of updating and resetting the password for users, in case they have forgotten their password. Comments were needed in many places in this file, and some comments that were there before had to be modified. A user alert had to be modified to be more clear, and a hard-coded value had to be moved to a parameter.

=== filters.rb ===
All previous tests for Authentication_Controller are working. Authentication_Controller with filters is working fine. We created filters.rb file in spec/support/matchers/ directory. This was additional functionality which we tried to do.This filters.rb file was to be called from Authentication controller. We were not able to solve error raised for this additional part

== List Of Changes ==

=== auth_controller.rb ===
Spelling was adjusted from authorised to authorized: 
[[File:E2129_Spelling_fix.PNG]] 
[[File:E2129_Spelling_fix_2.PNG]] 

Add a comment to explain the branches of a conjunction: 
[[File:E2129_Branch_conjunction_comment.PNG]] 

Add filters for loggers: 
[[File:E2129_Auth_controller_filters_before.PNG]]
[[File:E2129_Auth_controller_filters_after.png]] 

=== password_retrieval_controller.rb ===

Method check_reset_url was renamed to a more descriptive check_token_validity: 
[[File:E2129_Check_token_validity.PNG]] 

A parameter was created for the token expiration time instead of hardcoding it: 
[[File:E2129_Token_time.PNG]] 

Descriptive comments were added to send_password: 
[[File:E2129_Send_password_comments.PNG]] 

A statement inside the reset_password method that was copied from the forgotten method was replaced with a call to the forgotten method: 
[[File:E2129_Change_to_forgotten.PNG]] 
[[File:E2129_Forgotten.PNG]] 

A code block inside the check_reset_url method that was copied from the reset_password method was replaced with a call to the reset_password method: 
[[File:E2129_Change_to_reset_password.PNG]] 
[[File:E2129_Reset_password.PNG]] 

An error message in the check_reset_url method was updated to be more descriptive to a user: 
[[File:E2129_Invalid_token_user_message.PNG]] 

=== filters.rb ===
The contents of the new file support/matchers/filters.rb is shown below 
[[File:E2129_filters.PNG]]

== Test Plan ==
Since this is just a refactoring project. No test cases have been written.
Although, we wrote a file which will test the functionality of the filters.

== Testing Details ==
=== 1. The auth_controller.rb : ===
The file has been tested using rspec. 
rspec spec/helpers/authorization_helper_spec.rb . All test cases are passing as expected. 
[[File:E2129_testing_auth_controller.png]] 

=== 2. The password_retrieval_controller.rb ===
The file has been tested using rspec. 
rspec spec/helpers/password_retrieval_controller.rb . All test cases are passing as expected.
[[File:E2129_password_retrieval_controller.png]] 

== The Team ==
Aaron Mathew - asmathew@ncsu.edu 
Manish Shinde - msshinde@ncsu.edu 
Quinn Dibble - qdibble@ncsu.edu

CSC/ECE 517 Fall 2021 - E2129. Refactor auth controller.rb & password retrieval controller.rb

2021-10-21T03:05:16Z

Asmathew:

== E2129: Refactor auth_controller.rb & password_retrieval_controller.rb ==

__TOC__

== Relevant links ==
#Github : https://github.com/smanishs175/expertiza.git
#VCL Deployment: http://152.7.176.119:8080
##Deployment is scheduled to be available until November 13, 2021
##In the case of a VCL timeout before then, please contact the group so they can reboot the server. This is a known issue with VCL that is out of their control.

== About Expertiza ==
[http://expertiza.ncsu.edu/ Expertiza] is an open source project based on [http://rubyonrails.org/ Ruby on Rails] framework. It is a web based program that allows instructors to create and update/edit assignments/tasks, and then assigns them to students. Students then can submit, edit, and update their assignments, as well as peer review other student's assignments.

== Description Of Current Project ==
Our goal for this project is to refactor certain files (auth_controller.rb and password_retrieval_controller.rb) to follow essential Ruby on Rails design principles. Since this is a refactoring project, all [https://rspec.info/ RSpec] test cases must result in the same behavior as before, with no changes to the overall functionality of the code.

== Files Modified/Added ==
Two controller files were modified for this project: 
# auth_controller.rb (expertiza/app/controllers/auth_controller.rb) 
# password_retrieval_controller.rb (expertiza/app/controllers/password_retrieval_controller.rb) 

One RSpec file was added to help test filters: 
# filters.rb (expertiza/spec/support/matchers/filters.rb) 

=== auth_controller.rb ===
The auth_controller deals with user authentication when they try and login. Spelling needed to be adjusted to American style. Some comments were added and logger call locations were moved to before/after filters.

=====About Filters=====
Rails filters are methods that run before or after a controller's action method is executed. They are helpful when you want to ensure that a given block of code runs with whatever action method is called.

Rails support three types of filter methods:

Before filters- before_action filter is executed before the code in action controller is executed.
After filters- after_action filter is executed after the code in action controller is executed.
Around filters- around_action filter is executed before and after the code in action controller is executed.

=====Reason for the need of Filters in Authentication Controller=====
Calls to logger should be written as filters is that a call to a logger tends to be a full line of code. If we put the full line of code everywhere that the logger needs to be called, the logger text tends to distract from the rest of the work done by the method. It tends to pollute the code. If it is an after_action, then it gets called automatically when the method finishes, without having to appear in the method at all. It is a cleaner way of calling the logger. It is a case of the Separation of Responsibility principle.

Filter loggers are added to prioritize the method calls in function: 
#These filters are added for specific reasons: When the action_allowed? controller deals with authorizing the actions such as login, logout, login failed etc.
1. before_action :action_allowed?, only:[:login,:login_failed,:google_login] 
2. after_action :action_allowed?, only:[:logout] 

=== password_retrieval_controller.rb ===
The password_retrieval_controller deals with the process of updating and resetting the password for users, in case they have forgotten their password. Comments were needed in many places in this file, and some comments that were there before had to be modified. A user alert had to be modified to be more clear, and a hard-coded value had to be moved to a parameter.

=== filters.rb ===
All previous tests for Authentication_Controller are working. Authentication_Controller with filters is working fine. We created filters.rb file in spec/support/matchers/ directory. This was additional functionality which we tried to do.This filters.rb file was to be called from Authentication controller. We were not able to solve error raised for this additional part

== List Of Changes ==

=== auth_controller.rb ===
Spelling was adjusted from authorised to authorized: 
[[File:E2129_Spelling_fix.PNG]] 
[[File:E2129_Spelling_fix_2.PNG]] 

Add a comment to explain the branches of a conjunction: 
[[File:E2129_Branch_conjunction_comment.PNG]] 

Add filters for loggers: 
[[File:E2129_Auth_controller_filters_before.PNG]]
[[File:E2129_Auth_controller_filters_after.png]] 

=== password_retrieval_controller.rb ===

Method check_reset_url was renamed to a more descriptive check_token_validity: 
[[File:E2129_Check_token_validity.PNG]] 

A parameter was created for the token expiration time instead of hardcoding it: 
[[File:E2129_Token_time.PNG]] 

Descriptive comments were added to send_password: 
[[File:E2129_Send_password_comments.PNG]] 

A statement inside the reset_password method that was copied from the forgotten method was replaced with a call to the forgotten method: 
[[File:E2129_Change_to_forgotten.PNG]] 
[[File:E2129_Forgotten.PNG]] 

A code block inside the check_reset_url method that was copied from the reset_password method was replaced with a call to the reset_password method: 
[[File:E2129_Change_to_reset_password.PNG]] 
[[File:E2129_Reset_password.PNG]] 

An error message in the check_reset_url method was updated to be more descriptive to a user: 
[[File:E2129_Invalid_token_user_message.PNG]] 

=== filters.rb ===
The contents of the new file support/matchers/filters.rb is shown below 
[[File:E2129_filters.PNG]]

== Testing Details ==
=== 1. The auth_controller.rb : ===
The file has been tested using rspec. 
rspec spec/helpers/authorization_helper_spec.rb . All test cases are passing as expected. 
[[File:E2129_testing_auth_controller.png]] 

=== 2. The password_retrieval_controller.rb ===
The file has been tested using rspec. 
rspec spec/helpers/password_retrieval_controller.rb . All test cases are passing as expected.
[[File:E2129_password_retrieval_controller.png]] 

== The Team ==
Aaron Mathew - asmathew@ncsu.edu 
Manish Shinde - msshinde@ncsu.edu 
Quinn Dibble - qdibble@ncsu.edu

CSC/ECE 517 Fall 2021 - E2129. Refactor auth controller.rb & password retrieval controller.rb

2021-10-21T01:34:41Z

Asmathew:

== E2129: Refactor auth_controller.rb & password_retrieval_controller.rb ==

__TOC__

== Relevant links ==
#Github : https://github.com/smanishs175/expertiza.git
#VCL Deployment: http://152.7.176.119:8080
##Deployment is scheduled to be available until November 13, 2021
##In the case of a VCL timeout before then, please contact the group so they can reboot the server. This is a known issue with VCL that is out of their control.

== About Expertiza ==
[http://expertiza.ncsu.edu/ Expertiza] is an open source project based on [http://rubyonrails.org/ Ruby on Rails] framework. It is a web based program that allows instructors to create and update/edit assignments/tasks, and then assigns them to students. Students then can submit, edit, and update their assignments, as well as peer review other student's assignments.

== Description Of Current Project ==
Our goal for this project is to refactor certain files (auth_controller.rb and password_retrieval_controller.rb) to follow essential Ruby on Rails design principles. Since this is a refactoring project, all [https://rspec.info/ RSpec] test cases must result in the same behavior as before, with no changes to the overall functionality of the code.

== Files Modified/Added ==
Two controller files were modified for this project: 
# auth_controller.rb (expertiza/app/controllers/auth_controller.rb) 
# password_retrieval_controller.rb (expertiza/app/controllers/password_retrieval_controller.rb) 

One RSpec file was added to help test filters: 
# filters.rb (expertiza/spec/support/matchers/filters.rb) 

=== auth_controller.rb ===
The auth_controller deals with user authentication when they try and login. Spelling needed to be adjusted to American style. Some comments were added and logger call locations were moved to before/after filters.

=====About Filters=====
Rails filters are methods that run before or after a controller's action method is executed. They are helpful when you want to ensure that a given block of code runs with whatever action method is called.

Rails support three types of filter methods:

Before filters- before_action filter is executed before the code in action controller is executed.
After filters- after_action filter is executed after the code in action controller is executed.
Around filters- around_action filter is executed before and after the code in action controller is executed.

=====Reason for the need of Filters in Authentication Controller=====
Calls to logger should be written as filters is that a call to a logger tends to be a full line of code. If we put the full line of code everywhere that the logger needs to be called, the logger text tends to distract from the rest of the work done by the method. It tends to pollute the code. If it is an after_action, then it gets called automatically when the method finishes, without having to appear in the method at all. It is a cleaner way of calling the logger. It is a case of the Separation of Responsibility principle.

Filter loggers are added to prioritize the method calls in function: 
#These filters are added for specific reasons: When the action_allowed? controller deals with authorizing the actions such as login, logout, login failed etc.
1. before_action :action_allowed?, only:[:login,:login_failed,:google_login] 
2. after_action :action_allowed?, only:[:logout] 

=== password_retrieval_controller.rb ===
The password_retrieval_controller deals with the process of updating and resetting the password for users, in case they have forgotten their password. Comments were needed in many places in this file, and some comments that were there before had to be modified. A user alert had to be modified to be more clear, and a hard-coded value had to be moved to a parameter.

=== filters.rb ===
All previous tests for Authentication_Controller are working. Authentication_Controller with filters is working fine. We created filters.rb file in spec/support/matchers/ directory. This was additional functionality which we tried to do.This filters.rb file was to be called from Authentication controller. We were not able to solve error raised for this additional part

== List Of Changes ==

=== auth_controller.rb ===
Spelling was adjusted from authorised to authorized: 
[[File:E2129_Spelling_fix.PNG]] 
[[File:E2129_Spelling_fix_2.PNG]] 

Add a comment to explain the branches of a conjunction: 
[[File:E2129_Branch_conjunction_comment.PNG]] 

Add filters for loggers: 
[[File:E2129_Auth_controller_filters_before.PNG]]
[[File:E2129_Auth_controller_filters_after.png]] 

=== password_retrieval_controller.rb ===

Method check_reset_url was renamed to a more descriptive check_token_validity: 
[[File:E2129_Check_token_validity.PNG]] 

A parameter was created for the token expiration time instead of hardcoding it: 
[[File:E2129_Token_time.PNG]] 

Descriptive comments were added to send_password: 
[[File:E2129_Send_password_comments.PNG]] 

A statement inside the reset_password method that was copied from the forgotten method was replaced with a call to the forgotten method: 
[[File:E2129_Change_to_forgotten.PNG]] 
[[File:E2129_Forgotten.PNG]] 

A code block inside the check_reset_url method that was copied from the reset_password method was replaced with a call to the reset_password method: 
[[File:E2129_Change_to_reset_password.PNG]] 
[[File:E2129_Reset_password.PNG]] 

An error message in the check_reset_url method was updated to be more descriptive to a user: 
[[File:E2129_Invalid_token_user_message.PNG]] 

=== filters.rb ===
The contents of the new file support/matchers/filters.rb is shown below 
[[File:E2129_filters.PNG]]

== Testing Details ==
1. The auth_controller.rb : 
The file has been tested using rspec. 
rspec spec/helpers/authorization_helper_spec.rb . All test cases are passing as expected. 
[[File:E2129_testing_auth_controller.png]] 

2. The password_retrieval_controller.rb
The file has been tested using rspec. 
rspec spec/helpers/password_retrieval_controller.rb . All test cases are passing as expected.
[[File:E2129_password_retrieval_controller.png]]

File:E2129 password retrieval controller.png

2021-10-21T01:32:10Z

Asmathew:

CSC/ECE 517 Fall 2021 - E2129. Refactor auth controller.rb & password retrieval controller.rb

2021-10-21T01:30:46Z

Asmathew:

== E2129: Refactor auth_controller.rb & password_retrieval_controller.rb ==

__TOC__

== Relevant links ==
#Github : https://github.com/smanishs175/expertiza.git
#VCL Deployment: http://152.7.176.119:8080
##Deployment is scheduled to be available until November 13, 2021
##In the case of a VCL timeout before then, please contact the group so they can reboot the server. This is a known issue with VCL that is out of their control.

== About Expertiza ==
[http://expertiza.ncsu.edu/ Expertiza] is an open source project based on [http://rubyonrails.org/ Ruby on Rails] framework. It is a web based program that allows instructors to create and update/edit assignments/tasks, and then assigns them to students. Students then can submit, edit, and update their assignments, as well as peer review other student's assignments.

== Description Of Current Project ==
Our goal for this project is to refactor certain files (auth_controller.rb and password_retrieval_controller.rb) to follow essential Ruby on Rails design principles. Since this is a refactoring project, all [https://rspec.info/ RSpec] test cases must result in the same behavior as before, with no changes to the overall functionality of the code.

== Files Modified/Added ==
Two controller files were modified for this project: 
# auth_controller.rb (expertiza/app/controllers/auth_controller.rb) 
# password_retrieval_controller.rb (expertiza/app/controllers/password_retrieval_controller.rb) 

One RSpec file was added to help test filters: 
# filters.rb (expertiza/spec/support/matchers/filters.rb) 

=== auth_controller.rb ===
The auth_controller deals with user authentication when they try and login. Spelling needed to be adjusted to American style. Some comments were added and logger call locations were moved to before/after filters.

=====About Filters=====
Rails filters are methods that run before or after a controller's action method is executed. They are helpful when you want to ensure that a given block of code runs with whatever action method is called.

Rails support three types of filter methods:

Before filters- before_action filter is executed before the code in action controller is executed.
After filters- after_action filter is executed after the code in action controller is executed.
Around filters- around_action filter is executed before and after the code in action controller is executed.

=====Reason for the need of Filters in Authentication Controller=====
Calls to logger should be written as filters is that a call to a logger tends to be a full line of code. If we put the full line of code everywhere that the logger needs to be called, the logger text tends to distract from the rest of the work done by the method. It tends to pollute the code. If it is an after_action, then it gets called automatically when the method finishes, without having to appear in the method at all. It is a cleaner way of calling the logger. It is a case of the Separation of Responsibility principle.

Filter loggers are added to prioritize the method calls in function: 
#These filters are added for specific reasons: When the action_allowed? controller deals with authorizing the actions such as login, logout, login failed etc.
1. before_action :action_allowed?, only:[:login,:login_failed,:google_login] 
2. after_action :action_allowed?, only:[:logout] 

=== password_retrieval_controller.rb ===
The password_retrieval_controller deals with the process of updating and resetting the password for users, in case they have forgotten their password. Comments were needed in many places in this file, and some comments that were there before had to be modified. A user alert had to be modified to be more clear, and a hard-coded value had to be moved to a parameter.

=== filters.rb ===
All previous tests for Authentication_Controller are working. Authentication_Controller with filters is working fine. We created filters.rb file in spec/support/matchers/ directory. This was additional functionality which we tried to do.This filters.rb file was to be called from Authentication controller. We were not able to solve error raised for this additional part

== List Of Changes ==

=== auth_controller.rb ===
Spelling was adjusted from authorised to authorized: 
[[File:E2129_Spelling_fix.PNG]] 
[[File:E2129_Spelling_fix_2.PNG]] 

Add a comment to explain the branches of a conjunction: 
[[File:E2129_Branch_conjunction_comment.PNG]] 

Add filters for loggers: 
[[File:E2129_Auth_controller_filters_before.PNG]]
[[File:E2129_Auth_controller_filters_after.png]] 

=== password_retrieval_controller.rb ===

Method check_reset_url was renamed to a more descriptive check_token_validity: 
[[File:E2129_Check_token_validity.PNG]] 

A parameter was created for the token expiration time instead of hardcoding it: 
[[File:E2129_Token_time.PNG]] 

Descriptive comments were added to send_password: 
[[File:E2129_Send_password_comments.PNG]] 

A statement inside the reset_password method that was copied from the forgotten method was replaced with a call to the forgotten method: 
[[File:E2129_Change_to_forgotten.PNG]] 
[[File:E2129_Forgotten.PNG]] 

A code block inside the check_reset_url method that was copied from the reset_password method was replaced with a call to the reset_password method: 
[[File:E2129_Change_to_reset_password.PNG]] 
[[File:E2129_Reset_password.PNG]] 

An error message in the check_reset_url method was updated to be more descriptive to a user: 
[[File:E2129_Invalid_token_user_message.PNG]] 

=== filters.rb ===
The contents of the new file support/matchers/filters.rb is shown below 
[[File:E2129_filters.PNG]]

== Testing Details ==
#The auth_controller.rb : 
The file has been tested using rspec. 
rspec spec/helpers/authorization_helper_spec.rb . All test cases are passing as expected. 
[[File:E2129_testing_auth_controller.png]] 

#The password_retrieval_controller.rb
The file has been tested using rspec. 
rspec spec/helpers/password_retrieval_controller.rb . All test cases are passing as expected.

File:E2129 testing auth controller.png

2021-10-21T01:15:44Z

Asmathew:

CSC/ECE 517 Fall 2021 - E2129. Refactor auth controller.rb & password retrieval controller.rb

2021-10-21T01:06:32Z

Asmathew: Added few things about filters

== E2129: Refactor auth_controller.rb & password_retrieval_controller.rb ==

__TOC__

== Relevant links ==
#Github : https://github.com/smanishs175/expertiza.git
#VCL Deployment: 152.7.176.119:8080 (Please note that if incase vcl gives a timeout error contact the authors)

== About Expertiza ==
[http://expertiza.ncsu.edu/ Expertiza] is an open source project based on [http://rubyonrails.org/ Ruby on Rails] framework. It is a web based program that allows instructors to create and update/edit assignments/tasks, and then assigns them to students. Students then can submit, edit, and update their assignments, as well as peer review other student's assignments.

== Description Of Current Project ==
Our goal for this project is to refactor certain files (auth_controller.rb and password_retrieval_controller.rb) to follow essential Ruby on Rails design principles. Since this is a refactoring project, all [https://rspec.info/ RSpec] test cases must result in the same behavior as before, with no changes to the overall functionality of the code.

== Files Modified/Added ==
Two controller files were modified for this project: 
# auth_controller.rb (expertiza/app/controllers/auth_controller.rb) 
# password_retrieval_controller.rb (expertiza/app/controllers/password_retrieval_controller.rb) 

One RSpec file was added to help test filters: 
# filters.rb (expertiza/spec/support/matchers/filters.rb) 

=== auth_controller.rb ===
The auth_controller deals with user authentication when they try and login. Spelling needed to be adjusted to American style. Some comments were added and logger call locations were moved to before/after filters.
=====Problem 1=====
Check for the spelling. Use American spellings. For example, self.authorised? should be self.authorized?. Check for similar spelling issues.
=====Solution1=====
We have made the spelling changes as required. We changes Authorised to Authorized

=====Problem 2=====
In line 79, I don’t understand why both branches of the conjunction are needed; there should be a comment explaining this.
=====Solution2=====
We have added comments as "Checking if both places have same params"

=====Problem 3=====
Calls to logger should be written as before_ or after_filters on a method whenever possible.
=====Solution 3=====
=====About Filters=====
Rails filters are methods that run before or after a controller's action method is executed. They are helpful when you want to ensure that a given block of code runs with whatever action method is called.

Rails support three types of filter methods:

Before filters- before_action filter is executed before the code in action controller is executed.
After filters- after_action filter is executed after the code in action controller is executed.
Around filters- around_action filter is executed before and after the code in action controller is executed.

=====Reason for the need of Filters in Authentication Controller=====
Calls to logger should be written as filters is that a call to a logger tends to be a full line of code. If we put the full line of code everywhere that the logger needs to be called, the logger text tends to distract from the rest of the work done by the method. It tends to pollute the code. If it is an after_action, then it gets called automatically when the method finishes, without having to appear in the method at all. It is a cleaner way of calling the logger. It is a case of the Separation of Responsibility principle.

Filter loggers are added to prioritize the method calls in function: 
#These filters are added for specific reasons: When the action_allowed? controller deals with authorizing the actions such as login, logout, login failed etc.
1. before_action :action_allowed?, only:[:login,:login_failed,:google_login] 
2. after_action :action_allowed?, only:[:logout] 

=== password_retrieval_controller.rb ===
The password_retrieval_controller deals with the process of updating and resetting the password for users, in case they have forgotten their password. Comments were needed in many places in this file, and some comments that were there before had to be modified. A user alert had to be modified to be more clear, and a hard-coded value had to be moved to a parameter.

=== filters.rb ===
@Manish

== List Of Changes ==

=== auth_controller.rb ===
Spelling was adjusted from authorised to authorized: 
[[File:E2129_Spelling_fix.PNG]] 
[[File:E2129_Spelling_fix_2.PNG]] 

Add a comment to explain the branches of a conjunction: 
[[File:E2129_Branch_conjunction_comment.PNG]] 

Add filters for loggers: 
[[File:E2129_Auth_controller_filters_before.PNG]]
[[File:E2129_Auth_controller_filters_after.png]] 

=== password_retrieval_controller.rb ===

Method check_reset_url was renamed to a more descriptive check_token_validity: 
[[File:E2129_Check_token_validity.PNG]] 

A parameter was created for the token expiration time instead of hardcoding it: 
[[File:E2129_Token_time.PNG]] 

Descriptive comments were added to send_password: 
#TODO: send_password_comments.png 

A statement inside the reset_password method that was copied from the forgotten method was replaced with a call to the forgotten method: 
#TODO: change_to_forgotten.png 
#TODO: forgotten.png 

A code block inside the check_reset_url method that was copied from the reset_password method was replaced with a call to the reset_password method: 
#TODO: change_to_reset_password.png 
#TODO: reset_password.png 

An error message in the check_reset_url method was updated to be more descriptive to a user: 
#TODO: invalid_token_user_message.png 

== Testing Details ==

== Future Improvements ==

== Important Links ==

CSC/ECE 517 Fall 2021 - E2129. Refactor auth controller.rb & password retrieval controller.rb

2021-10-21T00:55:57Z

Asmathew: Added Links to github and vcl

== E2129: Refactor auth_controller.rb & password_retrieval_controller.rb ==

__TOC__

== Relevant links ==
#Github : https://github.com/smanishs175/expertiza.git
#VCL Deployment: 152.7.176.119:8080 (Please note that if incase vcl gives a timeout error contact the authors)

== About Expertiza ==
[http://expertiza.ncsu.edu/ Expertiza] is an open source project based on [http://rubyonrails.org/ Ruby on Rails] framework. It is a web based program that allows instructors to create and update/edit assignments/tasks, and then assigns them to students. Students then can submit, edit, and update their assignments, as well as peer review other student's assignments.

== Description Of Current Project ==
Our goal for this project is to refactor certain files (auth_controller.rb and password_retrieval_controller.rb) to follow essential Ruby on Rails design principles. Since this is a refactoring project, all [https://rspec.info/ RSpec] test cases must result in the same behavior as before, with no changes to the overall functionality of the code.

== Files Modified/Added ==
Two controller files were modified for this project: 
# auth_controller.rb (expertiza/app/controllers/auth_controller.rb) 
# password_retrieval_controller.rb (expertiza/app/controllers/password_retrieval_controller.rb) 

One RSpec file was added to help test filters: 
# filters.rb (expertiza/spec/support/matchers/filters.rb) 

=== auth_controller.rb ===
The auth_controller deals with user authentication when they try and login. Spelling needed to be adjusted to American style. Some comments were added and logger call locations were moved to before/after filters.
=====Problem 1=====
Check for the spelling. Use American spellings. For example, self.authorised? should be self.authorized?. Check for similar spelling issues.
=====Solution1=====
We have made the spelling changes as required. We changes Authorised to Authorized

=====Problem 2=====
In line 79, I don’t understand why both branches of the conjunction are needed; there should be a comment explaining this.
=====Solution2=====
We have added comments as "Checking if both places have same params"

=====Problem 3=====
Calls to logger should be written as before_ or after_filters on a method whenever possible.
=====Solution 3=====
=====About Filters=====
Rails filters are methods that run before or after a controller's action method is executed. They are helpful when you want to ensure that a given block of code runs with whatever action method is called.

Rails support three types of filter methods:

Before filters,
After filters,
Around filters

=====Reason for the need of Filters in Authentication Controller=====
Calls to logger should be written as filters is that a call to a logger tends to be a full line of code. If we put the full line of code everywhere that the logger needs to be called, the logger text tends to distract from the rest of the work done by the method. It tends to pollute the code. If it is an after_action, then it gets called automatically when the method finishes, without having to appear in the method at all. It is a cleaner way of calling the logger. It is a case of the Separation of Responsibility principle.

Filter loggers are added to prioritize the method calls in function: 
1. before_action :action_allowed?, only:[:login,:login_failed,:google_login] 
2. after_action :action_allowed?, only:[:logout] 

=== password_retrieval_controller.rb ===
The password_retrieval_controller deals with the process of updating and resetting the password for users, in case they have forgotten their password. Comments were needed in many places in this file, and some comments that were there before had to be modified. A user alert had to be modified to be more clear, and a hard-coded value had to be moved to a parameter.

=== filters.rb ===
@Manish

== List Of Changes ==

=== auth_controller.rb ===
Spelling was adjusted from authorised to authorized: 
#TODO: spelling_fix.png 
#TODO: spelling_fix_2.png 

Add a comment to explain the branches of a conjunction: 
#TODO: branch_conjunction_comment.png 

Add filters for loggers: 
#TODO: auth_controller_filters_before.png 
#TODO: auth_controller_filters_after.png 

=== password_retrieval_controller.rb ===

Method check_reset_url was renamed to a more descriptive check_token_validity: 
#TODO: check_token_validity.png 

A parameter was created for the token expiration time instead of hardcoding it: 
#TODO: token_time.png 

Descriptive comments were added to send_password: 
#TODO: send_password_comments.png 

A statement inside the reset_password method that was copied from the forgotten method was replaced with a call to the forgotten method: 
#TODO: change_to_forgotten.png 
#TODO: forgotten.png 

A code block inside the check_reset_url method that was copied from the reset_password method was replaced with a call to the reset_password method: 
#TODO: change_to_reset_password.png 
#TODO: reset_password.png 

An error message in the check_reset_url method was updated to be more descriptive to a user: 
#TODO: invalid_token_user_message.png 

== Testing Details ==

== Future Improvements ==

== Important Links ==