Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2024 - E2476. Reimplement student teams controller.rb

2024-12-04T05:37:45Z

Akoul2: /* Testing Plan */

===Introduction===
[http://expertiza.ncsu.edu/ Expertiza] is an open-source system built on [http://rubyonrails.org/ Ruby on Rails], collaboratively maintained by students and faculty at NC State. This platform gives instructors extensive control over assignments, enabling them to add topics, create assignment groups, and manage peer reviews for various types of coursework. Expertiza is well-equipped to handle submissions across multiple formats, including URLs and wiki pages, and it offers a peer review system that facilitates constructive feedback among students.

A key focus of recent development in Expertiza has been the shift to a client-server architecture, where Ruby on Rails functions as the backend and React is utilized for the frontend. This architectural update requires reworking existing modules into RESTful API endpoints, allowing React components to interact efficiently with the backend. By adopting this approach, Expertiza aims to enhance modularity, performance, and scalability.

===Project Description===

The project mainly focuses on reimplementing the StudentTeamsController in Expertiza's backend, which is designed for student-facing operations where students participate in teams. This includes actions that directly affect individual team members, such as adding or removing students from teams, viewing team details, and managing their participation.

The TeamsController, on the other hand, is focused on instructor-driven operations that handle high-level team management across different contexts, such as courses and assignments. It manages operations like team creation, deletion, randomization, and bulk management actions.

===Problem Statement===

The current implementation of the StudentTeamsController in the Expertiza system is overly complex and tightly coupled, leading to difficulties in maintaining and extending the codebase. The controller is responsible for managing student teams in assignments, handling tasks like team creation, editing, management, and the integration of topics in assignments that require team-based decisions. However, it suffers from issues such as:
* Code redundancy and inefficiency due to business logic being embedded directly in the controller.
* Lack of modularity and poor separation of concerns, violating the Single Responsibility Principle (SRP). For example, it also handles the integration with topics when assignments involve choosing topics, complicating the team’s logic.
* Difficult-to-understand methods and tightly coupled logic for handling assignment-specific conditions, such as team-topic associations.
* Poor user feedback that does not provide clear or actionable information after critical operations.

These problems create a system that is hard to scale, maintain, and extend, especially as new features are added. To address these challenges, the goal is to reimplement the StudentTeamsController in the newer Expertiza backend codebase by adhering to object-oriented design principles, specifically focusing on maintainability, scalability, and modularity. The new design will improve the user experience by simplifying controller logic, providing clearer feedback, and ensuring that the system is easier to extend and maintain in the future.

===Objectives===

The main objective is to migrate the Student Task controller logic from serving HTML responses in the Ruby on Rails MVC model to returning JSON responses as a RESTful API, as part of the backend implementation. While reimplementing the controller, the following considerations will be incorporated to ensure a clean, maintainable, and scalable API:

*Reimplement the controller logic and write methods which appropriately follow the Single Responsibility Principle (SRP).
*Move business logic from the controller to appropriate model classes like Team or AssignmentTeam.
*Ensure all method names clearly describe their purpose and represent actions.
*Reimplement a Prototype pattern for creating mentored teams, leveraging the AssignmentTeam class.
*Automatically generate team names when a team is first referred to unless the user has specified a name when requesting team creation.
*Handle team requirements with better abstraction:
*Try to eliminate direct logic in the controller that checks for specific assignment requirements such as topic handling.
*Rename student_team_requirements_met? to something more descriptive and break it into smaller methods checking individual conditions.
*Aim to decouple topics from this controller entirely, ensuring better abstraction, that can involve changes to other classes or introducing service objects to handle specific requirements.
* Improve feedback to users and ensure that the user receives clear and actionable feedback after operations like team creation, removal of users, and other key actions.
* Add comprehensive comments throughout the controller, clearly explaining the purpose and functionality of custom methods.

===Development Strategy===

Our development strategy centers around Test-Driven Development (TDD) principles applied to refactoring the student_teams_controller.rb and other related classes such as Team or AssignmentTeam model. We design out test cases and iteratively refactor code to address identified inefficiencies while ensuring successful test outcomes.
Additionally, we emphasize on the strict adoption of SRP and DRY principles as per the object-oriented programming conventions. Our goal is to reimplement the existing functionalities
In the newly designed back-end foundation to foster a more efficient and organized codebase utilizing newer technologies. This approach will significantly enhance reusability and scalability across all the application while maintaining clean codebase.

Files Modified:
* Created ==>
** app/controllers/api/v1/student_teams_controller.rb
** app/models/assignment_team.rb
** app/models/team.rb
** spec/requests/api/v1/student_teams_controller_spec.rb
** db/migrate/20241201203840_create_assignment_teams.rb
** db/migrate/20241201220020_add_auto_assign_mentor_to_assignments.rb
** db/migrate/20241201221122_add_type_to_teams.rb
** db/migrate/20241202002102_add_name_to_teams.rb

* Updated ==>
** app/models/team.rb
** config/routes.rb
** db/schema.rb
** db/seeds.rb
** spec/swagger_helper.rb

===Project Design and Implementation===

The main approach to be followed throughout this project is to embrace the Prototyping Pattern within the controller while taking into account the current functionalities to be reimplemented within the student_teams_controller.rb that can capitalize its capability to encapsulate distinct controller actions. This strategic implementation aims to ensure seamless extensibility and enhanced usability. By employing this pattern, we establish a structured framework for defining and managing the diverse operations the controller handles, promoting a more organized and manageable code structure.

[[File:2476_UML.drawio.png]]

==== Functionality ====

1. Reimplement the Controller to Follow SRP:
* Break down large, complex methods into smaller, focused methods that adhere to the Single Responsibility Principle (SRP).
* Reimplement existing methods and logic while ensuring that each class and method have a clear, well-defined responsibility.
* Move business logic and complex operations out of the controller and into the appropriate model classes (e.g., Team, AssignmentTeam), ensuring the controller only handles HTTP-specific concerns (e.g., request handling, responses).

2. Improve Method Naming and Clarity:
* Ensure all method names are descriptive and represent the intent of the operation (e.g., renaming methods like student_team_requirements_met? to something more specific like validate_topic_requirements_for_team_creation).
* Adopt consistent naming conventions to improve the readability of the codebase.

3. Implement the Prototype Pattern for Team Creation:
* Leverage the Prototype pattern to create mentored teams through the AssignmentTeam class, allowing for easier management and creation of teams with a mentored structure.
* Automatically generate team names when a team is first created, unless a user has specified a custom name to improve the user experience and simplify team management.

4. Abstract Assignment-Specific Logic:
* Move logic related to assignment-specific requirements (e.g., topic handling) away from the controller, reducing complexity and increasing modularity.
* Introduce service objects or model methods to handle specific requirements like topic assignment, thereby decoupling assignment-related logic from the controller.
* Break down the student_team_requirements_met? method into smaller, more specific checks for different requirements (e.g., topic validation, minimum team size, etc.).

5. Improve User Feedback:
* Enhance the clarity and actionability of feedback messages after key operations (e.g., team creation, user removal, etc.).
* Provide users with clear, helpful notifications on the success or failure of their actions, including any necessary next steps or troubleshooting guidance.
* Ensure error handling is robust, and feedback is specific (e.g., specify which conditions were not met when creating or modifying teams).

6. Commenting and Documentation:
* Add comprehensive comments throughout the controller to clearly explain the purpose and functionality of custom methods and refactored logic.
* Ensure that code is well-documented, making it easier for future developers to understand and extend the functionality of the controller.

===Tasks Completed===

Methods:
* AssignmentTeam Model:
** To access every participant connected to an assignment, the assignment_participants method was added.
** For including a user in the assignment as a participant, the add_participant method was added.
** To see if the team has gotten any peer reviews, the received_any_peer_review? method was put into practice.
** Using a placeholder for future mentor assignment logic, the upgrade_to_mentored_team method was put into practice to replicate the present team and get it ready for mentoring.
** In order to ensure deep duplication of associated records (such as signed_up_teams, teams_users, and participants), the dup method was added to duplicate a team and its associations.

* Team Model:
** Improved the whole procedure to determine if a team has reached its maximum number of members.
** Counted the number of team members using the size approach, removing those with "(Mentor)" in their names.
** In order to eliminate duplicate members and check for team capacity, the add_member method was improved.
** To remove a user from the team, the remove_team_user method was put into place. If the team becomes empty and hasn't been subjected to any peer reviews, the team will be deleted.

* Controller - StudentTeamsController.rb
** index: Implemented in order to retrieve and restore every student team together with all of its members.
** show: Created to retrieve and provide information about a certain student team and its members.
** create: Added logic to create a new team for a student, using AssignmentTeam#upgraded_to_mentored_team for mentor-eligible teams and checking for existing team names.
** update: Implemented to enable team details, especially the team name, to be updated while ensuring unique team names through validations.
** destroy: To remove a certain team this was added and, if successful, deliver a 204 No Content response.
** remove_participant: Check if the user is part of the given team and removes from that team, also handles corner cases where no more participants are there in a team.
** add_participant: Added this to add the given participant to respective team.

===Testing Plan===

We have performed comprehensive testing of the student_teams_controller.rb and related classes using RSPEC and Swagger to construct the required test fixtures for testing extensive scenarios. Our approach involves reimplementing the existing test cases provided to the older code base and make sure that it is enhanced by covering more test scenarios to minimize code smells. We aim to verify the reimplemented functionality, validate the restructured code in the student_teams_controller.rb and reduce any design or code smell.
Below are the test scenarios for each of API endpoints -

1. List all Student Teams

*Description: List all student teams.
*Response: 200 OK
*Test Case Scenarios:
*Scenario 1: List all Student Teams
*Expectation: Successfully retrieves a list of all student teams. The response status is 200, the content type is `application/json`, and the response body contains 3 student teams.

RSpec.describe 'Student Teams API', type: :request do
path '/api/v1/student_teams' do
# List all Student Teams
get('List all Student Teams') do
tags 'Student Teams'
produces 'application/json'
security [Bearer: {}]
response(200, 'successful') do
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test!
end
end
*Postman Screenshot
[[File:Akoul2Index.jpg]]

2. Create a Student Team
*Description: Create a new student team.
*Response: 201 Created
*Test Data prep:
post 'Create a Student Team' do
tags 'Student Teams'
consumes 'application/json'
let(:institution) do
Institution.create!(
name: 'North Carolina State University'
)
end
let!(:instructor_role) { Role.find_or_create_by(name: 'Instructor') }
let!(:student_role) { Role.find_or_create_by(name: 'Student') }
let(:instructor_user) do
User.create!(
name: 'Dr. Ed Gehringer1',
email: 'gehringer@example.com',
password: 'password123',
full_name: 'admin admin',
institution_id: institution.id,
role_id: instructor_role.id,
handle: 'instructor'
)
end
let(:course) do
Course.create!(
name: '2476. Refactor',
directory_path: '/',
info: 'OODD',
private: false,
instructor_id: instructor_user.id,
institution_id: institution.id
)
end
let(:assignment) do
Assignment.create!(
title: 'Project 4 BRO',
description: '2476. Reimplementing',
course_id: course.id,
instructor_id: instructor_user.id
)
end
let!(:students) do
created_students = []
3.times do |i|
student = User.create!(
name: "Student #{i + 1}",
email: "Student#{i + 1}@gmail.com",
password: 'password123',
full_name: "Student #{i + 1}",
institution_id: institution.id,
role_id: student_role.id,
handle: "Student #{i + 1}"
)
AssignmentParticipant.create!(
assignment: assignment,
user: student,
handle: "Student #{i + 1}"
)
created_students << student
end
created_students
end
parameter name: :student_team_request, in: :body, schema: {
type: :object,
properties: {
team: {
type: :object,
properties: {
name: {type: :string}
}
},
student_id: { type: :integer}
}
}
security [Bearer: {}]
*Scenarios:
*Scenario 1: Successfully create a team
*Expectation: Successfully creates a new student team with a valid name and student ID. The response status is 201, and the response body includes the team name.
*Scenario 2: Team name is already in use (conflict)
*Attempts to create a student team with a name that is already in use.
*Expectation: The response status is 422, and the response body includes an error message indicating that the team name is already in use.
*Scenario 3: Invalid team creation (empty name)
*Expectation: Attempts to create a student team with an empty string name. The response status is 201, with team name autogenerated.

# Scenario 1: Successfully create a team
response(201, 'created') do
let(:student_team_request) do
{ team: {name: "HelloThere"}, student_id: students.first.id}
end
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test! do
expect(response.status).to eq(201)
end
end
# Scenario 2: Team name is already in use (conflict)
response(422, 'unprocessable entity') do
let(:existing_team) { create(:team, name: 'ABCD10', assignment_id: assignment.id) }
let(:team) do
post '/api/v1/student_teams', params: { team: { name: 'ABCD10' }, student_id: students.first.id }, as: :json
end
run_test! do
expect(response.status).to eq(422)
expect(response.body).to include('"error":"That team name is already in use."')
end
end
# Scenario 3: Invalid team creation (empty name)
response(422, 'unprocessable entity') do
let(:student_team_request) do
{ team: {name: ""}, student_id: students.first.id}
end
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test! do
expect(response.status).to eq(422)
expect(response.body).to include('error')
end
end
response(404, 'not_found') do
let(:team) do
post '/api/v1/student_teams', params: { team: { name: 'ABCD10' }, student_id: 0 }, as: :json
end
run_test! do
expect(response.status).to eq(404)
expect(response.body).to include('not found')
end
end
end
*Postman
*Scenario 1:
[[File:Akoul2Create.jpg]]
*Scenario 2:
[[File:Akoul2Create2.jpg]]
*Scenario 3:
[[File:Akoul2Create3.jpg]]

3. Update a Student Team
*Description: Update the details of a student team.
*Response: 200 OK
*Scenarios:
*Scenario 1: Team name updated successfully
*Expectation: Successfully updates the name of a student team. The response status is 200, and the response body includes the updated team name.
*Scenario 2: Invalid team update (empty name)
*Expectation: Attempts to update a student team with an empty name. The response status is 422, and the response body includes an error message indicating that the team name should not be empty.
*Scenario 3: Team name already in use
*Expectation: Attempts to update a student team with a name that is already in use. The response status is 422, and the response body includes an error message indicating that the team name is already in use.
*Scenario 4: Invalid team ID
*Expectation: Attempts to update a student team with a non-existent team ID. The response status is 404, and the response body includes an error message indicating that the team was not found.

patch('Update a Student Team') do
tags 'Student Teams'
consumes 'application/json'
produces 'application/json'
security [Bearer: {}]
parameter name: :student_team_request, in: :body, schema: {
type: :object,
properties: {
team: {
type: :object,
properties: {
name: {type: :string}
}
},
team_id: { type: :integer}
}
}
# Scenario 1: Team name updated successfully
response(200, 'successful') do
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test! do
expect(response.status).to eq(200)
end
end
# Scenario 2: Invalid team updation (empty name)
response(422, 'unprocessable entity') do
let(:student_team_request) do
{ team: {name: ""}, team_id: 2}
end
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test! do
expect(response.status).to eq(422)
expect(response.body).to include('Team name should not be empty')
end
end
# Scenario 3: Team Name already present
response(422, 'unprocessable entity') do
let(:existing_team) { create(:team, name: 'ABCD10', team_id: 3) }
let(:team) do
post '/api/v1/student_teams', params: { team: { name: 'ABCD10' }, team_id: 2 }, as: :json
end
run_test! do
expect(response.status).to eq(422)
expect(response.body).to include('"error":"That team name is already in use."')
end
end
#Scenario 4 : Invalid Team ID
response(404, 'not_found') do
let(:team) do
post '/api/v1/student_teams', params: { team: { name: 'ABCD10' }, team_id: 0 }, as: :json
end
run_test! do
expect(response.status).to eq(404)
expect(response.body).to include('not found')
end
end
end
end
*Postman
**Scenario 1:
**[[File:Akoul2Update1.jpg]]
**Scenario 2:
[[File:Akoul2Update2.jpg]]
**Scenario 3:
[[File:Akoul2Update3.jpg]]
**Scenario 4:
[[File:Akoul2Update4.jpg]]

4. Show a Student Team
*Description: Retrieve the details of a student team by its ID.
*Response: 200 OK
*Scenarios:
*Scenario 1: Show Student Team
*Expectation: Successfully retrieves the details of a student team by its ID. The response status is 200, and the response body includes the details of the student team.
*Scenario 2: Team not found
*Expectation: Attempts to retrieve the details of a student team with an invalid ID. The response status is 404, and the response body includes an error message indicating that the team was not found.
path '/api/v1/student_teams/{id}' do
parameter name: 'id', in: :path, type: :integer
# Get request on /api/v1/student_teams/{id} returns the response 200 succesful - when correct id passed is present in the database
get('Show a Student Team') do
tags 'Student Teams'
produces 'application/json'
security [Bearer: {}]
response(200, 'successful') do
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test! do
expect(response.status).to eq(200)
end
end
# Get request on /api/v1/student_teams/{id} returns the response 404 not found - when correct id passed is not present in the database
response(404, 'not_found') do
let(:id) { 'invalid' }
run_test! do
expect(response.status).to eq(404)
end
end
end

*Postman:
**Scenario 1:
[[File:Akoul2Show.jpg]]
**Scenario 2:
[[File:Akoul2Show not.jpg]]

5. Delete a Student Team
*Description: Delete a student team by its ID.
*Response: 204 No Content
*Scenarios:
*Scenario 1: Successfully delete a student team
*Expectation: Successfully deletes a student team by its ID. The response status is 204, and the student team is no longer present in the database.
*Scenario 2: Team not found
*Expectation: Attempts to delete a student team with an invalid ID. The response status is 404, and the response body includes an error message indicating that the team was not found.

delete('Delete a Student Team') do
tags 'Student Teams'
produces 'application/json'
security [Bearer: {}]
# delete request on /api/v1/student_teams/{id} returns 204 succesful response when id present in the database is deleted successfully
response(204, 'successful') do
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: ''
}
}
end
run_test! do
expect(response.status).to eq(204)
end
end
# delete request on /api/v1/student_teams/{id} returns 404 not found response, when id is not present in the database
response(404, 'not found') do
let(:id) { 0 }
run_test! do
expect(response.status).to eq(404)
end
end
end
end

*Postman:
**Scenario 1:
[[File:2476_delete_1.png]]

**Scenario 2:
[[File:2476_delete_2.png]]

6. Add a Participant in Student Team
*Description: Add a participant to a student team.
*Response: 200 OK
*Test Data Prep
path '/api/v1/student_teams/{id}/add_participant' do
parameter name: 'id', in: :path, type: :integer, description: 'ID of Team'
parameter name: 'student_id', in: :query, type: :integer, description: 'ID of the Student'
let(:student) { create(:user, :student) }
let(:assignment) { create(:assignment) }
let(:student_participant) { create(:assignment_participant, user: student, assignment: assignment) }
let(:team) { create(:assignment_team, assignment: assignment) }
let(:id) { team.id }
let(:student_id) { student.id }
*Scenarios:
*Scenario 1: Successfully add a participant to a student team
*Expectation: Successfully adds a participant to a student team by their ID. The response status is 200, and the participant is added to the team.
patch('Add a participant to Student Team') do
tags 'Student Teams'
consumes 'application/json'
produces 'application/json'
security [Bearer: {}]
before do
team.add_member(student, assignment.id)
end
response(200, 'successful') do
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test!
end
end
end
*Postman:
[[File:Akoul2Add participant.jpg]]

7. Remove a Participant in Student Team
*Description: Remove a participant from a student team.
*Response: 204 No Content
*Test data prep:

path '/api/v1/student_teams/{id}/remove_participant' do
parameter name: 'id', in: :path, type: :integer, description: 'ID of Team'
parameter name: 'student_id', in: :query, type: :integer, description: 'ID of the Student'
let(:student) { create(:user, :student) }
let(:assignment) { create(:assignment) }
let(:student_participant) { create(:assignment_participant, user: student, assignment: assignment) }
let(:team) { create(:assignment_team, assignment: assignment) }
let(:id) { team.id }
let(:student_id) { student.id }
before do
team.add_member(student, assignment.id)
end
*Scenarios:
*Scenario 1: Successfully remove a participant from a student team
*Expectation: Successfully removes a participant from a student team by their ID. The response status is 204, and the participant is no longer a member of the team.
*Scenario 2: Team not found
*Expectation: Attempts to remove a participant from a student team with an invalid team ID. The response status is 404, and the response body includes an error message indicating that the team was not found.
*Scenario 3: User not found
*Expectation: Attempts to remove a participant from a student team with an invalid user ID. The response status is 404, and the response body includes an error message indicating that the user was not found.

delete('remove participant') do
tags 'Student Teams'
produces 'application/json'
security [Bearer: {}]
response(204, 'successful') do
let(:Authorization) { "Bearer #{@token}" }
run_test! do
expect(response.status).to eq(204)
expect(team.members).not_to include(student)
end
end
response(404, 'team not found') do
let(:id) { -1 } # Invalid ID
run_test! do
expect(response.status).to eq(404)
expect(JSON.parse(response.body)['error']).to eq('Team not found.')
end
end
response(404, 'user not found') do
let(:student_id) { -1 } # Invalid student ID
run_test! do
expect(response.status).to eq(404)
expect(JSON.parse(response.body)['error']).to eq('User not found.')
end
end
end
end

===GitHub Pull Request===

https://github.com/expertiza/reimplementation-back-end/pull/136

===Demo Video===

https://www.youtube.com/watch?v=8_d_Y9EcgHc

===Mentor===

* Ammana, Sahithi <sammana@ncsu.edu>

===Team Members===

* Eathamukkala, Akarsh Reddy <aeatham@ncsu.edu>
* Koul, Anmol <akoul2@ncsu.edu>
* More, Harsh Manoj <hmore@ncsu.edu>

CSC/ECE 517 Fall 2024 - E2476. Reimplement student teams controller.rb

2024-12-04T05:36:38Z

Akoul2: /* Testing Plan */

===Introduction===
[http://expertiza.ncsu.edu/ Expertiza] is an open-source system built on [http://rubyonrails.org/ Ruby on Rails], collaboratively maintained by students and faculty at NC State. This platform gives instructors extensive control over assignments, enabling them to add topics, create assignment groups, and manage peer reviews for various types of coursework. Expertiza is well-equipped to handle submissions across multiple formats, including URLs and wiki pages, and it offers a peer review system that facilitates constructive feedback among students.

A key focus of recent development in Expertiza has been the shift to a client-server architecture, where Ruby on Rails functions as the backend and React is utilized for the frontend. This architectural update requires reworking existing modules into RESTful API endpoints, allowing React components to interact efficiently with the backend. By adopting this approach, Expertiza aims to enhance modularity, performance, and scalability.

===Project Description===

The project mainly focuses on reimplementing the StudentTeamsController in Expertiza's backend, which is designed for student-facing operations where students participate in teams. This includes actions that directly affect individual team members, such as adding or removing students from teams, viewing team details, and managing their participation.

The TeamsController, on the other hand, is focused on instructor-driven operations that handle high-level team management across different contexts, such as courses and assignments. It manages operations like team creation, deletion, randomization, and bulk management actions.

===Problem Statement===

The current implementation of the StudentTeamsController in the Expertiza system is overly complex and tightly coupled, leading to difficulties in maintaining and extending the codebase. The controller is responsible for managing student teams in assignments, handling tasks like team creation, editing, management, and the integration of topics in assignments that require team-based decisions. However, it suffers from issues such as:
* Code redundancy and inefficiency due to business logic being embedded directly in the controller.
* Lack of modularity and poor separation of concerns, violating the Single Responsibility Principle (SRP). For example, it also handles the integration with topics when assignments involve choosing topics, complicating the team’s logic.
* Difficult-to-understand methods and tightly coupled logic for handling assignment-specific conditions, such as team-topic associations.
* Poor user feedback that does not provide clear or actionable information after critical operations.

These problems create a system that is hard to scale, maintain, and extend, especially as new features are added. To address these challenges, the goal is to reimplement the StudentTeamsController in the newer Expertiza backend codebase by adhering to object-oriented design principles, specifically focusing on maintainability, scalability, and modularity. The new design will improve the user experience by simplifying controller logic, providing clearer feedback, and ensuring that the system is easier to extend and maintain in the future.

===Objectives===

The main objective is to migrate the Student Task controller logic from serving HTML responses in the Ruby on Rails MVC model to returning JSON responses as a RESTful API, as part of the backend implementation. While reimplementing the controller, the following considerations will be incorporated to ensure a clean, maintainable, and scalable API:

*Reimplement the controller logic and write methods which appropriately follow the Single Responsibility Principle (SRP).
*Move business logic from the controller to appropriate model classes like Team or AssignmentTeam.
*Ensure all method names clearly describe their purpose and represent actions.
*Reimplement a Prototype pattern for creating mentored teams, leveraging the AssignmentTeam class.
*Automatically generate team names when a team is first referred to unless the user has specified a name when requesting team creation.
*Handle team requirements with better abstraction:
*Try to eliminate direct logic in the controller that checks for specific assignment requirements such as topic handling.
*Rename student_team_requirements_met? to something more descriptive and break it into smaller methods checking individual conditions.
*Aim to decouple topics from this controller entirely, ensuring better abstraction, that can involve changes to other classes or introducing service objects to handle specific requirements.
* Improve feedback to users and ensure that the user receives clear and actionable feedback after operations like team creation, removal of users, and other key actions.
* Add comprehensive comments throughout the controller, clearly explaining the purpose and functionality of custom methods.

===Development Strategy===

Our development strategy centers around Test-Driven Development (TDD) principles applied to refactoring the student_teams_controller.rb and other related classes such as Team or AssignmentTeam model. We design out test cases and iteratively refactor code to address identified inefficiencies while ensuring successful test outcomes.
Additionally, we emphasize on the strict adoption of SRP and DRY principles as per the object-oriented programming conventions. Our goal is to reimplement the existing functionalities
In the newly designed back-end foundation to foster a more efficient and organized codebase utilizing newer technologies. This approach will significantly enhance reusability and scalability across all the application while maintaining clean codebase.

Files Modified:
* Created ==>
** app/controllers/api/v1/student_teams_controller.rb
** app/models/assignment_team.rb
** app/models/team.rb
** spec/requests/api/v1/student_teams_controller_spec.rb
** db/migrate/20241201203840_create_assignment_teams.rb
** db/migrate/20241201220020_add_auto_assign_mentor_to_assignments.rb
** db/migrate/20241201221122_add_type_to_teams.rb
** db/migrate/20241202002102_add_name_to_teams.rb

* Updated ==>
** app/models/team.rb
** config/routes.rb
** db/schema.rb
** db/seeds.rb
** spec/swagger_helper.rb

===Project Design and Implementation===

The main approach to be followed throughout this project is to embrace the Prototyping Pattern within the controller while taking into account the current functionalities to be reimplemented within the student_teams_controller.rb that can capitalize its capability to encapsulate distinct controller actions. This strategic implementation aims to ensure seamless extensibility and enhanced usability. By employing this pattern, we establish a structured framework for defining and managing the diverse operations the controller handles, promoting a more organized and manageable code structure.

[[File:2476_UML.drawio.png]]

==== Functionality ====

1. Reimplement the Controller to Follow SRP:
* Break down large, complex methods into smaller, focused methods that adhere to the Single Responsibility Principle (SRP).
* Reimplement existing methods and logic while ensuring that each class and method have a clear, well-defined responsibility.
* Move business logic and complex operations out of the controller and into the appropriate model classes (e.g., Team, AssignmentTeam), ensuring the controller only handles HTTP-specific concerns (e.g., request handling, responses).

2. Improve Method Naming and Clarity:
* Ensure all method names are descriptive and represent the intent of the operation (e.g., renaming methods like student_team_requirements_met? to something more specific like validate_topic_requirements_for_team_creation).
* Adopt consistent naming conventions to improve the readability of the codebase.

3. Implement the Prototype Pattern for Team Creation:
* Leverage the Prototype pattern to create mentored teams through the AssignmentTeam class, allowing for easier management and creation of teams with a mentored structure.
* Automatically generate team names when a team is first created, unless a user has specified a custom name to improve the user experience and simplify team management.

4. Abstract Assignment-Specific Logic:
* Move logic related to assignment-specific requirements (e.g., topic handling) away from the controller, reducing complexity and increasing modularity.
* Introduce service objects or model methods to handle specific requirements like topic assignment, thereby decoupling assignment-related logic from the controller.
* Break down the student_team_requirements_met? method into smaller, more specific checks for different requirements (e.g., topic validation, minimum team size, etc.).

5. Improve User Feedback:
* Enhance the clarity and actionability of feedback messages after key operations (e.g., team creation, user removal, etc.).
* Provide users with clear, helpful notifications on the success or failure of their actions, including any necessary next steps or troubleshooting guidance.
* Ensure error handling is robust, and feedback is specific (e.g., specify which conditions were not met when creating or modifying teams).

6. Commenting and Documentation:
* Add comprehensive comments throughout the controller to clearly explain the purpose and functionality of custom methods and refactored logic.
* Ensure that code is well-documented, making it easier for future developers to understand and extend the functionality of the controller.

===Tasks Completed===

Methods:
* AssignmentTeam Model:
** To access every participant connected to an assignment, the assignment_participants method was added.
** For including a user in the assignment as a participant, the add_participant method was added.
** To see if the team has gotten any peer reviews, the received_any_peer_review? method was put into practice.
** Using a placeholder for future mentor assignment logic, the upgrade_to_mentored_team method was put into practice to replicate the present team and get it ready for mentoring.
** In order to ensure deep duplication of associated records (such as signed_up_teams, teams_users, and participants), the dup method was added to duplicate a team and its associations.

* Team Model:
** Improved the whole procedure to determine if a team has reached its maximum number of members.
** Counted the number of team members using the size approach, removing those with "(Mentor)" in their names.
** In order to eliminate duplicate members and check for team capacity, the add_member method was improved.
** To remove a user from the team, the remove_team_user method was put into place. If the team becomes empty and hasn't been subjected to any peer reviews, the team will be deleted.

* Controller - StudentTeamsController.rb
** index: Implemented in order to retrieve and restore every student team together with all of its members.
** show: Created to retrieve and provide information about a certain student team and its members.
** create: Added logic to create a new team for a student, using AssignmentTeam#upgraded_to_mentored_team for mentor-eligible teams and checking for existing team names.
** update: Implemented to enable team details, especially the team name, to be updated while ensuring unique team names through validations.
** destroy: To remove a certain team this was added and, if successful, deliver a 204 No Content response.
** remove_participant: Check if the user is part of the given team and removes from that team, also handles corner cases where no more participants are there in a team.
** add_participant: Added this to add the given participant to respective team.

===Testing Plan===

We have performed comprehensive testing of the student_teams_controller.rb and related classes using RSPEC and Swagger to construct the required test fixtures for testing extensive scenarios. Our approach involves reimplementing the existing test cases provided to the older code base and make sure that it is enhanced by covering more test scenarios to minimize code smells. We aim to verify the reimplemented functionality, validate the restructured code in the student_teams_controller.rb and reduce any design or code smell.
Below are the test scenarios for each of API endpoints -

1. List all Student Teams

*Description: List all student teams.
*Response: 200 OK
*Test Case Scenarios:
*Scenario 1: List all Student Teams
*Expectation: Successfully retrieves a list of all student teams. The response status is 200, the content type is `application/json`, and the response body contains 3 student teams.

RSpec.describe 'Student Teams API', type: :request do
path '/api/v1/student_teams' do
# List all Student Teams
get('List all Student Teams') do
tags 'Student Teams'
produces 'application/json'
security [Bearer: {}]
response(200, 'successful') do
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test!
end
end
*Postman Screenshot
[[File:Akoul2Index.jpg]]

2. Create a Student Team
*Description: Create a new student team.
*Response: 201 Created
*Test Data prep:
post 'Create a Student Team' do
tags 'Student Teams'
consumes 'application/json'
let(:institution) do
Institution.create!(
name: 'North Carolina State University'
)
end
let!(:instructor_role) { Role.find_or_create_by(name: 'Instructor') }
let!(:student_role) { Role.find_or_create_by(name: 'Student') }
let(:instructor_user) do
User.create!(
name: 'Dr. Ed Gehringer1',
email: 'gehringer@example.com',
password: 'password123',
full_name: 'admin admin',
institution_id: institution.id,
role_id: instructor_role.id,
handle: 'instructor'
)
end
let(:course) do
Course.create!(
name: '2476. Refactor',
directory_path: '/',
info: 'OODD',
private: false,
instructor_id: instructor_user.id,
institution_id: institution.id
)
end
let(:assignment) do
Assignment.create!(
title: 'Project 4 BRO',
description: '2476. Reimplementing',
course_id: course.id,
instructor_id: instructor_user.id
)
end
let!(:students) do
created_students = []
3.times do |i|
student = User.create!(
name: "Student #{i + 1}",
email: "Student#{i + 1}@gmail.com",
password: 'password123',
full_name: "Student #{i + 1}",
institution_id: institution.id,
role_id: student_role.id,
handle: "Student #{i + 1}"
)
AssignmentParticipant.create!(
assignment: assignment,
user: student,
handle: "Student #{i + 1}"
)
created_students << student
end
created_students
end
parameter name: :student_team_request, in: :body, schema: {
type: :object,
properties: {
team: {
type: :object,
properties: {
name: {type: :string}
}
},
student_id: { type: :integer}
}
}
security [Bearer: {}]
*Scenarios:
*Scenario 1: Successfully create a team
*Expectation: Successfully creates a new student team with a valid name and student ID. The response status is 201, and the response body includes the team name.
*Scenario 2: Team name is already in use (conflict)
*Attempts to create a student team with a name that is already in use.
*Expectation: The response status is 422, and the response body includes an error message indicating that the team name is already in use.
*Scenario 3: Invalid team creation (empty name)
*Expectation: Attempts to create a student team with an empty string name. The response status is 201, with team name autogenerated.

# Scenario 1: Successfully create a team
response(201, 'created') do
let(:student_team_request) do
{ team: {name: "HelloThere"}, student_id: students.first.id}
end
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test! do
expect(response.status).to eq(201)
end
end
# Scenario 2: Team name is already in use (conflict)
response(422, 'unprocessable entity') do
let(:existing_team) { create(:team, name: 'ABCD10', assignment_id: assignment.id) }
let(:team) do
post '/api/v1/student_teams', params: { team: { name: 'ABCD10' }, student_id: students.first.id }, as: :json
end
run_test! do
expect(response.status).to eq(422)
expect(response.body).to include('"error":"That team name is already in use."')
end
end
# Scenario 3: Invalid team creation (empty name)
response(422, 'unprocessable entity') do
let(:student_team_request) do
{ team: {name: ""}, student_id: students.first.id}
end
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test! do
expect(response.status).to eq(422)
expect(response.body).to include('error')
end
end
response(404, 'not_found') do
let(:team) do
post '/api/v1/student_teams', params: { team: { name: 'ABCD10' }, student_id: 0 }, as: :json
end
run_test! do
expect(response.status).to eq(404)
expect(response.body).to include('not found')
end
end
end
*Postman
*Scenario 1:
[[File:Akoul2Create.jpg]]
*Scenario 2:
[[File:Akoul2Create2.jpg]]
*Scenario 3:
[[File:Akoul2Create3.jpg]]

3. Update a Student Team
*Description: Update the details of a student team.
*Response: 200 OK
*Scenarios:
*Scenario 1: Team name updated successfully
*Expectation: Successfully updates the name of a student team. The response status is 200, and the response body includes the updated team name.
*Scenario 2: Invalid team update (empty name)
*Expectation: Attempts to update a student team with an empty name. The response status is 422, and the response body includes an error message indicating that the team name should not be empty.
*Scenario 3: Team name already in use
*Expectation: Attempts to update a student team with a name that is already in use. The response status is 422, and the response body includes an error message indicating that the team name is already in use.
*Scenario 4: Invalid team ID
*Expectation: Attempts to update a student team with a non-existent team ID. The response status is 404, and the response body includes an error message indicating that the team was not found.

patch('Update a Student Team') do
tags 'Student Teams'
consumes 'application/json'
produces 'application/json'
security [Bearer: {}]
parameter name: :student_team_request, in: :body, schema: {
type: :object,
properties: {
team: {
type: :object,
properties: {
name: {type: :string}
}
},
team_id: { type: :integer}
}
}
# Scenario 1: Team name updated successfully
response(200, 'successful') do
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test! do
expect(response.status).to eq(200)
end
end
# Scenario 2: Invalid team updation (empty name)
response(422, 'unprocessable entity') do
let(:student_team_request) do
{ team: {name: ""}, team_id: 2}
end
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test! do
expect(response.status).to eq(422)
expect(response.body).to include('Team name should not be empty')
end
end
# Scenario 3: Team Name already present
response(422, 'unprocessable entity') do
let(:existing_team) { create(:team, name: 'ABCD10', team_id: 3) }
let(:team) do
post '/api/v1/student_teams', params: { team: { name: 'ABCD10' }, team_id: 2 }, as: :json
end
run_test! do
expect(response.status).to eq(422)
expect(response.body).to include('"error":"That team name is already in use."')
end
end
#Scenario 4 : Invalid Team ID
response(404, 'not_found') do
let(:team) do
post '/api/v1/student_teams', params: { team: { name: 'ABCD10' }, team_id: 0 }, as: :json
end
run_test! do
expect(response.status).to eq(404)
expect(response.body).to include('not found')
end
end
end
end
*Postman
**Scenario 1:
**[[File:Akoul2Update1.jpg]]
**Scenario 2:
[[File:Akoul2Update2.jpg]]
**Scenario 3:
[[File:Akoul2Update3.jpg]]
**Scenario 4:
[[File:Akoul2Update4.jpg]]

4. Show a Student Team
*Description: Retrieve the details of a student team by its ID.
*Response: 200 OK
*Scenarios:
*Scenario 1: Show Student Team
*Expectation: Successfully retrieves the details of a student team by its ID. The response status is 200, and the response body includes the details of the student team.
*Scenario 2: Team not found
*Expectation: Attempts to retrieve the details of a student team with an invalid ID. The response status is 404, and the response body includes an error message indicating that the team was not found.
path '/api/v1/student_teams/{id}' do
parameter name: 'id', in: :path, type: :integer
# Get request on /api/v1/student_teams/{id} returns the response 200 succesful - when correct id passed is present in the database
get('Show a Student Team') do
tags 'Student Teams'
produces 'application/json'
security [Bearer: {}]
response(200, 'successful') do
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test! do
expect(response.status).to eq(200)
end
end
# Get request on /api/v1/student_teams/{id} returns the response 404 not found - when correct id passed is not present in the database
response(404, 'not_found') do
let(:id) { 'invalid' }
run_test! do
expect(response.status).to eq(404)
end
end
end

*Postman:
**Scenario 1:
[[File:Akoul2Show.jpg]]
**Scenario 2:
[[File:Akoul2Show not.jpg]]

5. Delete a Student Team
*Description: Delete a student team by its ID.
*Response: 204 No Content
*Scenarios:
*Scenario 1: Successfully delete a student team
*Expectation: Successfully deletes a student team by its ID. The response status is 204, and the student team is no longer present in the database.
*Scenario 2: Team not found
*Expectation: Attempts to delete a student team with an invalid ID. The response status is 404, and the response body includes an error message indicating that the team was not found.

delete('Delete a Student Team') do
tags 'Student Teams'
produces 'application/json'
security [Bearer: {}]
# delete request on /api/v1/student_teams/{id} returns 204 succesful response when id present in the database is deleted successfully
response(204, 'successful') do
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: ''
}
}
end
run_test! do
expect(response.status).to eq(204)
end
end
# delete request on /api/v1/student_teams/{id} returns 404 not found response, when id is not present in the database
response(404, 'not found') do
let(:id) { 0 }
run_test! do
expect(response.status).to eq(404)
end
end
end
end

*Postman:
*Scenario 1: [[File:2476_delete_1.png]]
*Scenario 2: [[File:2476_delete_2.png]]

6. Add a Participant in Student Team
*Description: Add a participant to a student team.
*Response: 200 OK
*Test Data Prep
path '/api/v1/student_teams/{id}/add_participant' do
parameter name: 'id', in: :path, type: :integer, description: 'ID of Team'
parameter name: 'student_id', in: :query, type: :integer, description: 'ID of the Student'
let(:student) { create(:user, :student) }
let(:assignment) { create(:assignment) }
let(:student_participant) { create(:assignment_participant, user: student, assignment: assignment) }
let(:team) { create(:assignment_team, assignment: assignment) }
let(:id) { team.id }
let(:student_id) { student.id }
*Scenarios:
*Scenario 1: Successfully add a participant to a student team
*Expectation: Successfully adds a participant to a student team by their ID. The response status is 200, and the participant is added to the team.
patch('Add a participant to Student Team') do
tags 'Student Teams'
consumes 'application/json'
produces 'application/json'
security [Bearer: {}]
before do
team.add_member(student, assignment.id)
end
response(200, 'successful') do
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test!
end
end
end
*Postman:
[[File:Akoul2Add participant.jpg]]
7. Remove a Participant in Student Team
*Description: Remove a participant from a student team.
*Response: 204 No Content
*Test data prep:

path '/api/v1/student_teams/{id}/remove_participant' do
parameter name: 'id', in: :path, type: :integer, description: 'ID of Team'
parameter name: 'student_id', in: :query, type: :integer, description: 'ID of the Student'
let(:student) { create(:user, :student) }
let(:assignment) { create(:assignment) }
let(:student_participant) { create(:assignment_participant, user: student, assignment: assignment) }
let(:team) { create(:assignment_team, assignment: assignment) }
let(:id) { team.id }
let(:student_id) { student.id }
before do
team.add_member(student, assignment.id)
end
*Scenarios:
*Scenario 1: Successfully remove a participant from a student team
*Expectation: Successfully removes a participant from a student team by their ID. The response status is 204, and the participant is no longer a member of the team.
*Scenario 2: Team not found
*Expectation: Attempts to remove a participant from a student team with an invalid team ID. The response status is 404, and the response body includes an error message indicating that the team was not found.
*Scenario 3: User not found
*Expectation: Attempts to remove a participant from a student team with an invalid user ID. The response status is 404, and the response body includes an error message indicating that the user was not found.

delete('remove participant') do
tags 'Student Teams'
produces 'application/json'
security [Bearer: {}]
response(204, 'successful') do
let(:Authorization) { "Bearer #{@token}" }
run_test! do
expect(response.status).to eq(204)
expect(team.members).not_to include(student)
end
end
response(404, 'team not found') do
let(:id) { -1 } # Invalid ID
run_test! do
expect(response.status).to eq(404)
expect(JSON.parse(response.body)['error']).to eq('Team not found.')
end
end
response(404, 'user not found') do
let(:student_id) { -1 } # Invalid student ID
run_test! do
expect(response.status).to eq(404)
expect(JSON.parse(response.body)['error']).to eq('User not found.')
end
end
end
end

===GitHub Pull Request===

https://github.com/expertiza/reimplementation-back-end/pull/136

===Demo Video===

https://www.youtube.com/watch?v=8_d_Y9EcgHc

===Mentor===

* Ammana, Sahithi <sammana@ncsu.edu>

===Team Members===

* Eathamukkala, Akarsh Reddy <aeatham@ncsu.edu>
* Koul, Anmol <akoul2@ncsu.edu>
* More, Harsh Manoj <hmore@ncsu.edu>

CSC/ECE 517 Fall 2024 - E2476. Reimplement student teams controller.rb

2024-12-04T05:34:06Z

Akoul2: /* Testing Plan */

===Introduction===
[http://expertiza.ncsu.edu/ Expertiza] is an open-source system built on [http://rubyonrails.org/ Ruby on Rails], collaboratively maintained by students and faculty at NC State. This platform gives instructors extensive control over assignments, enabling them to add topics, create assignment groups, and manage peer reviews for various types of coursework. Expertiza is well-equipped to handle submissions across multiple formats, including URLs and wiki pages, and it offers a peer review system that facilitates constructive feedback among students.

A key focus of recent development in Expertiza has been the shift to a client-server architecture, where Ruby on Rails functions as the backend and React is utilized for the frontend. This architectural update requires reworking existing modules into RESTful API endpoints, allowing React components to interact efficiently with the backend. By adopting this approach, Expertiza aims to enhance modularity, performance, and scalability.

===Project Description===

The project mainly focuses on reimplementing the StudentTeamsController in Expertiza's backend, which is designed for student-facing operations where students participate in teams. This includes actions that directly affect individual team members, such as adding or removing students from teams, viewing team details, and managing their participation.

The TeamsController, on the other hand, is focused on instructor-driven operations that handle high-level team management across different contexts, such as courses and assignments. It manages operations like team creation, deletion, randomization, and bulk management actions.

===Problem Statement===

The current implementation of the StudentTeamsController in the Expertiza system is overly complex and tightly coupled, leading to difficulties in maintaining and extending the codebase. The controller is responsible for managing student teams in assignments, handling tasks like team creation, editing, management, and the integration of topics in assignments that require team-based decisions. However, it suffers from issues such as:
* Code redundancy and inefficiency due to business logic being embedded directly in the controller.
* Lack of modularity and poor separation of concerns, violating the Single Responsibility Principle (SRP). For example, it also handles the integration with topics when assignments involve choosing topics, complicating the team’s logic.
* Difficult-to-understand methods and tightly coupled logic for handling assignment-specific conditions, such as team-topic associations.
* Poor user feedback that does not provide clear or actionable information after critical operations.

These problems create a system that is hard to scale, maintain, and extend, especially as new features are added. To address these challenges, the goal is to reimplement the StudentTeamsController in the newer Expertiza backend codebase by adhering to object-oriented design principles, specifically focusing on maintainability, scalability, and modularity. The new design will improve the user experience by simplifying controller logic, providing clearer feedback, and ensuring that the system is easier to extend and maintain in the future.

===Objectives===

The main objective is to migrate the Student Task controller logic from serving HTML responses in the Ruby on Rails MVC model to returning JSON responses as a RESTful API, as part of the backend implementation. While reimplementing the controller, the following considerations will be incorporated to ensure a clean, maintainable, and scalable API:

*Reimplement the controller logic and write methods which appropriately follow the Single Responsibility Principle (SRP).
*Move business logic from the controller to appropriate model classes like Team or AssignmentTeam.
*Ensure all method names clearly describe their purpose and represent actions.
*Reimplement a Prototype pattern for creating mentored teams, leveraging the AssignmentTeam class.
*Automatically generate team names when a team is first referred to unless the user has specified a name when requesting team creation.
*Handle team requirements with better abstraction:
*Try to eliminate direct logic in the controller that checks for specific assignment requirements such as topic handling.
*Rename student_team_requirements_met? to something more descriptive and break it into smaller methods checking individual conditions.
*Aim to decouple topics from this controller entirely, ensuring better abstraction, that can involve changes to other classes or introducing service objects to handle specific requirements.
* Improve feedback to users and ensure that the user receives clear and actionable feedback after operations like team creation, removal of users, and other key actions.
* Add comprehensive comments throughout the controller, clearly explaining the purpose and functionality of custom methods.

===Development Strategy===

Our development strategy centers around Test-Driven Development (TDD) principles applied to refactoring the student_teams_controller.rb and other related classes such as Team or AssignmentTeam model. We design out test cases and iteratively refactor code to address identified inefficiencies while ensuring successful test outcomes.
Additionally, we emphasize on the strict adoption of SRP and DRY principles as per the object-oriented programming conventions. Our goal is to reimplement the existing functionalities
In the newly designed back-end foundation to foster a more efficient and organized codebase utilizing newer technologies. This approach will significantly enhance reusability and scalability across all the application while maintaining clean codebase.

Files Modified:
* Created ==>
** app/controllers/api/v1/student_teams_controller.rb
** app/models/assignment_team.rb
** app/models/team.rb
** spec/requests/api/v1/student_teams_controller_spec.rb
** db/migrate/20241201203840_create_assignment_teams.rb
** db/migrate/20241201220020_add_auto_assign_mentor_to_assignments.rb
** db/migrate/20241201221122_add_type_to_teams.rb
** db/migrate/20241202002102_add_name_to_teams.rb

* Updated ==>
** app/models/team.rb
** config/routes.rb
** db/schema.rb
** db/seeds.rb
** spec/swagger_helper.rb

===Project Design and Implementation===

The main approach to be followed throughout this project is to embrace the Prototyping Pattern within the controller while taking into account the current functionalities to be reimplemented within the student_teams_controller.rb that can capitalize its capability to encapsulate distinct controller actions. This strategic implementation aims to ensure seamless extensibility and enhanced usability. By employing this pattern, we establish a structured framework for defining and managing the diverse operations the controller handles, promoting a more organized and manageable code structure.

[[File:2476_UML.drawio.png]]

==== Functionality ====

1. Reimplement the Controller to Follow SRP:
* Break down large, complex methods into smaller, focused methods that adhere to the Single Responsibility Principle (SRP).
* Reimplement existing methods and logic while ensuring that each class and method have a clear, well-defined responsibility.
* Move business logic and complex operations out of the controller and into the appropriate model classes (e.g., Team, AssignmentTeam), ensuring the controller only handles HTTP-specific concerns (e.g., request handling, responses).

2. Improve Method Naming and Clarity:
* Ensure all method names are descriptive and represent the intent of the operation (e.g., renaming methods like student_team_requirements_met? to something more specific like validate_topic_requirements_for_team_creation).
* Adopt consistent naming conventions to improve the readability of the codebase.

3. Implement the Prototype Pattern for Team Creation:
* Leverage the Prototype pattern to create mentored teams through the AssignmentTeam class, allowing for easier management and creation of teams with a mentored structure.
* Automatically generate team names when a team is first created, unless a user has specified a custom name to improve the user experience and simplify team management.

4. Abstract Assignment-Specific Logic:
* Move logic related to assignment-specific requirements (e.g., topic handling) away from the controller, reducing complexity and increasing modularity.
* Introduce service objects or model methods to handle specific requirements like topic assignment, thereby decoupling assignment-related logic from the controller.
* Break down the student_team_requirements_met? method into smaller, more specific checks for different requirements (e.g., topic validation, minimum team size, etc.).

5. Improve User Feedback:
* Enhance the clarity and actionability of feedback messages after key operations (e.g., team creation, user removal, etc.).
* Provide users with clear, helpful notifications on the success or failure of their actions, including any necessary next steps or troubleshooting guidance.
* Ensure error handling is robust, and feedback is specific (e.g., specify which conditions were not met when creating or modifying teams).

6. Commenting and Documentation:
* Add comprehensive comments throughout the controller to clearly explain the purpose and functionality of custom methods and refactored logic.
* Ensure that code is well-documented, making it easier for future developers to understand and extend the functionality of the controller.

===Tasks Completed===

Methods:
* AssignmentTeam Model:
** To access every participant connected to an assignment, the assignment_participants method was added.
** For including a user in the assignment as a participant, the add_participant method was added.
** To see if the team has gotten any peer reviews, the received_any_peer_review? method was put into practice.
** Using a placeholder for future mentor assignment logic, the upgrade_to_mentored_team method was put into practice to replicate the present team and get it ready for mentoring.
** In order to ensure deep duplication of associated records (such as signed_up_teams, teams_users, and participants), the dup method was added to duplicate a team and its associations.

* Team Model:
** Improved the whole procedure to determine if a team has reached its maximum number of members.
** Counted the number of team members using the size approach, removing those with "(Mentor)" in their names.
** In order to eliminate duplicate members and check for team capacity, the add_member method was improved.
** To remove a user from the team, the remove_team_user method was put into place. If the team becomes empty and hasn't been subjected to any peer reviews, the team will be deleted.

* Controller - StudentTeamsController.rb
** index: Implemented in order to retrieve and restore every student team together with all of its members.
** show: Created to retrieve and provide information about a certain student team and its members.
** create: Added logic to create a new team for a student, using AssignmentTeam#upgraded_to_mentored_team for mentor-eligible teams and checking for existing team names.
** update: Implemented to enable team details, especially the team name, to be updated while ensuring unique team names through validations.
** destroy: To remove a certain team this was added and, if successful, deliver a 204 No Content response.
** remove_participant: Check if the user is part of the given team and removes from that team, also handles corner cases where no more participants are there in a team.
** add_participant: Added this to add the given participant to respective team.

===Testing Plan===

We have performed comprehensive testing of the student_teams_controller.rb and related classes using RSPEC and Swagger to construct the required test fixtures for testing extensive scenarios. Our approach involves reimplementing the existing test cases provided to the older code base and make sure that it is enhanced by covering more test scenarios to minimize code smells. We aim to verify the reimplemented functionality, validate the restructured code in the student_teams_controller.rb and reduce any design or code smell.
Below are the test scenarios for each of API endpoints -

1. List all Student Teams

*Description: List all student teams.
*Response: 200 OK
*Test Case Scenarios:
*Scenario 1: List all Student Teams
*Expectation: Successfully retrieves a list of all student teams. The response status is 200, the content type is `application/json`, and the response body contains 3 student teams.

RSpec.describe 'Student Teams API', type: :request do
path '/api/v1/student_teams' do
# List all Student Teams
get('List all Student Teams') do
tags 'Student Teams'
produces 'application/json'
security [Bearer: {}]
response(200, 'successful') do
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test!
end
end
*Postman Screenshot
[[File:Akoul2Index.jpg]]

2. Create a Student Team
*Description: Create a new student team.
*Response: 201 Created
*Test Data prep:
post 'Create a Student Team' do
tags 'Student Teams'
consumes 'application/json'
let(:institution) do
Institution.create!(
name: 'North Carolina State University'
)
end
let!(:instructor_role) { Role.find_or_create_by(name: 'Instructor') }
let!(:student_role) { Role.find_or_create_by(name: 'Student') }
let(:instructor_user) do
User.create!(
name: 'Dr. Ed Gehringer1',
email: 'gehringer@example.com',
password: 'password123',
full_name: 'admin admin',
institution_id: institution.id,
role_id: instructor_role.id,
handle: 'instructor'
)
end
let(:course) do
Course.create!(
name: '2476. Refactor',
directory_path: '/',
info: 'OODD',
private: false,
instructor_id: instructor_user.id,
institution_id: institution.id
)
end
let(:assignment) do
Assignment.create!(
title: 'Project 4 BRO',
description: '2476. Reimplementing',
course_id: course.id,
instructor_id: instructor_user.id
)
end
let!(:students) do
created_students = []
3.times do |i|
student = User.create!(
name: "Student #{i + 1}",
email: "Student#{i + 1}@gmail.com",
password: 'password123',
full_name: "Student #{i + 1}",
institution_id: institution.id,
role_id: student_role.id,
handle: "Student #{i + 1}"
)
AssignmentParticipant.create!(
assignment: assignment,
user: student,
handle: "Student #{i + 1}"
)
created_students << student
end
created_students
end
parameter name: :student_team_request, in: :body, schema: {
type: :object,
properties: {
team: {
type: :object,
properties: {
name: {type: :string}
}
},
student_id: { type: :integer}
}
}
security [Bearer: {}]
*Scenarios:
*Scenario 1: Successfully create a team
*Expectation: Successfully creates a new student team with a valid name and student ID. The response status is 201, and the response body includes the team name.
*Scenario 2: Team name is already in use (conflict)
*Attempts to create a student team with a name that is already in use.
*Expectation: The response status is 422, and the response body includes an error message indicating that the team name is already in use.
*Scenario 3: Invalid team creation (empty name)
*Expectation: Attempts to create a student team with an empty string name. The response status is 201, with team name autogenerated.

# Scenario 1: Successfully create a team
response(201, 'created') do
let(:student_team_request) do
{ team: {name: "HelloThere"}, student_id: students.first.id}
end
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test! do
expect(response.status).to eq(201)
end
end
# Scenario 2: Team name is already in use (conflict)
response(422, 'unprocessable entity') do
let(:existing_team) { create(:team, name: 'ABCD10', assignment_id: assignment.id) }
let(:team) do
post '/api/v1/student_teams', params: { team: { name: 'ABCD10' }, student_id: students.first.id }, as: :json
end
run_test! do
expect(response.status).to eq(422)
expect(response.body).to include('"error":"That team name is already in use."')
end
end
# Scenario 3: Invalid team creation (empty name)
response(422, 'unprocessable entity') do
let(:student_team_request) do
{ team: {name: ""}, student_id: students.first.id}
end
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test! do
expect(response.status).to eq(422)
expect(response.body).to include('error')
end
end
response(404, 'not_found') do
let(:team) do
post '/api/v1/student_teams', params: { team: { name: 'ABCD10' }, student_id: 0 }, as: :json
end
run_test! do
expect(response.status).to eq(404)
expect(response.body).to include('not found')
end
end
end
*Postman
*Scenario 1:
[[File:Akoul2Create.jpg]]
*Scenario 2:
[[File:Akoul2Create2.jpg]]
*Scenario 3:
[[File:Akoul2Create3.jpg]]

3. Update a Student Team
*Description: Update the details of a student team.
*Response: 200 OK
*Scenarios:
*Scenario 1: Team name updated successfully
*Expectation: Successfully updates the name of a student team. The response status is 200, and the response body includes the updated team name.
*Scenario 2: Invalid team update (empty name)
*Expectation: Attempts to update a student team with an empty name. The response status is 422, and the response body includes an error message indicating that the team name should not be empty.
*Scenario 3: Team name already in use
*Expectation: Attempts to update a student team with a name that is already in use. The response status is 422, and the response body includes an error message indicating that the team name is already in use.
*Scenario 4: Invalid team ID
*Expectation: Attempts to update a student team with a non-existent team ID. The response status is 404, and the response body includes an error message indicating that the team was not found.

patch('Update a Student Team') do
tags 'Student Teams'
consumes 'application/json'
produces 'application/json'
security [Bearer: {}]
parameter name: :student_team_request, in: :body, schema: {
type: :object,
properties: {
team: {
type: :object,
properties: {
name: {type: :string}
}
},
team_id: { type: :integer}
}
}
# Scenario 1: Team name updated successfully
response(200, 'successful') do
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test! do
expect(response.status).to eq(200)
end
end
# Scenario 2: Invalid team updation (empty name)
response(422, 'unprocessable entity') do
let(:student_team_request) do
{ team: {name: ""}, team_id: 2}
end
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test! do
expect(response.status).to eq(422)
expect(response.body).to include('Team name should not be empty')
end
end
# Scenario 3: Team Name already present
response(422, 'unprocessable entity') do
let(:existing_team) { create(:team, name: 'ABCD10', team_id: 3) }
let(:team) do
post '/api/v1/student_teams', params: { team: { name: 'ABCD10' }, team_id: 2 }, as: :json
end
run_test! do
expect(response.status).to eq(422)
expect(response.body).to include('"error":"That team name is already in use."')
end
end
#Scenario 4 : Invalid Team ID
response(404, 'not_found') do
let(:team) do
post '/api/v1/student_teams', params: { team: { name: 'ABCD10' }, team_id: 0 }, as: :json
end
run_test! do
expect(response.status).to eq(404)
expect(response.body).to include('not found')
end
end
end
end
*Postman
Scenario 1:
[[File:Akoul2Update1.jpg]]
Scenario 2:
[[File:Akoul2Update2.jpg]]
Scenario 3:
[[File:Akoul2Update3.jpg]]
Scenario 4:
[[File:Akoul2Update4.jpg]]

4. Show a Student Team
*Description: Retrieve the details of a student team by its ID.
*Response: 200 OK
*Scenarios:
*Scenario 1: Show Student Team
*Expectation: Successfully retrieves the details of a student team by its ID. The response status is 200, and the response body includes the details of the student team.
*Scenario 2: Team not found
*Expectation: Attempts to retrieve the details of a student team with an invalid ID. The response status is 404, and the response body includes an error message indicating that the team was not found.
path '/api/v1/student_teams/{id}' do
parameter name: 'id', in: :path, type: :integer
# Get request on /api/v1/student_teams/{id} returns the response 200 succesful - when correct id passed is present in the database
get('Show a Student Team') do
tags 'Student Teams'
produces 'application/json'
security [Bearer: {}]
response(200, 'successful') do
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test! do
expect(response.status).to eq(200)
end
end
# Get request on /api/v1/student_teams/{id} returns the response 404 not found - when correct id passed is not present in the database
response(404, 'not_found') do
let(:id) { 'invalid' }
run_test! do
expect(response.status).to eq(404)
end
end
end

*Postman:
**Scenario 1:
[[File:Akoul2Show.jpg]]
**Scenario 2:
[[File:Akoul2Show not.jpg]]

5. Delete a Student Team
*Description: Delete a student team by its ID.
*Response: 204 No Content
*Scenarios:
*Scenario 1: Successfully delete a student team
*Expectation: Successfully deletes a student team by its ID. The response status is 204, and the student team is no longer present in the database.
*Scenario 2: Team not found
*Expectation: Attempts to delete a student team with an invalid ID. The response status is 404, and the response body includes an error message indicating that the team was not found.

delete('Delete a Student Team') do
tags 'Student Teams'
produces 'application/json'
security [Bearer: {}]
# delete request on /api/v1/student_teams/{id} returns 204 succesful response when id present in the database is deleted successfully
response(204, 'successful') do
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: ''
}
}
end
run_test! do
expect(response.status).to eq(204)
end
end
# delete request on /api/v1/student_teams/{id} returns 404 not found response, when id is not present in the database
response(404, 'not found') do
let(:id) { 0 }
run_test! do
expect(response.status).to eq(404)
end
end
end
end

*Postman:
*Scenario 1: [[File:2476_delete_1.png]]
*Scenario 2: [[File:2476_delete_1.png]]

6. Add a Participant in Student Team
*Description: Add a participant to a student team.
*Response: 200 OK
*Test Data Prep
path '/api/v1/student_teams/{id}/add_participant' do
parameter name: 'id', in: :path, type: :integer, description: 'ID of Team'
parameter name: 'student_id', in: :query, type: :integer, description: 'ID of the Student'
let(:student) { create(:user, :student) }
let(:assignment) { create(:assignment) }
let(:student_participant) { create(:assignment_participant, user: student, assignment: assignment) }
let(:team) { create(:assignment_team, assignment: assignment) }
let(:id) { team.id }
let(:student_id) { student.id }
*Scenarios:
*Scenario 1: Successfully add a participant to a student team
*Expectation: Successfully adds a participant to a student team by their ID. The response status is 200, and the participant is added to the team.
patch('Add a participant to Student Team') do
tags 'Student Teams'
consumes 'application/json'
produces 'application/json'
security [Bearer: {}]
before do
team.add_member(student, assignment.id)
end
response(200, 'successful') do
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test!
end
end
end
*Postman:
[[File:Akoul2Add participant.jpg]]
7. Remove a Participant in Student Team
*Description: Remove a participant from a student team.
*Response: 204 No Content
*Test data prep:

path '/api/v1/student_teams/{id}/remove_participant' do
parameter name: 'id', in: :path, type: :integer, description: 'ID of Team'
parameter name: 'student_id', in: :query, type: :integer, description: 'ID of the Student'
let(:student) { create(:user, :student) }
let(:assignment) { create(:assignment) }
let(:student_participant) { create(:assignment_participant, user: student, assignment: assignment) }
let(:team) { create(:assignment_team, assignment: assignment) }
let(:id) { team.id }
let(:student_id) { student.id }
before do
team.add_member(student, assignment.id)
end
*Scenarios:
*Scenario 1: Successfully remove a participant from a student team
*Expectation: Successfully removes a participant from a student team by their ID. The response status is 204, and the participant is no longer a member of the team.
*Scenario 2: Team not found
*Expectation: Attempts to remove a participant from a student team with an invalid team ID. The response status is 404, and the response body includes an error message indicating that the team was not found.
*Scenario 3: User not found
*Expectation: Attempts to remove a participant from a student team with an invalid user ID. The response status is 404, and the response body includes an error message indicating that the user was not found.

delete('remove participant') do
tags 'Student Teams'
produces 'application/json'
security [Bearer: {}]
response(204, 'successful') do
let(:Authorization) { "Bearer #{@token}" }
run_test! do
expect(response.status).to eq(204)
expect(team.members).not_to include(student)
end
end
response(404, 'team not found') do
let(:id) { -1 } # Invalid ID
run_test! do
expect(response.status).to eq(404)
expect(JSON.parse(response.body)['error']).to eq('Team not found.')
end
end
response(404, 'user not found') do
let(:student_id) { -1 } # Invalid student ID
run_test! do
expect(response.status).to eq(404)
expect(JSON.parse(response.body)['error']).to eq('User not found.')
end
end
end
end

===GitHub Pull Request===

https://github.com/expertiza/reimplementation-back-end/pull/136

===Demo Video===

https://www.youtube.com/watch?v=8_d_Y9EcgHc

===Mentor===

* Ammana, Sahithi <sammana@ncsu.edu>

===Team Members===

* Eathamukkala, Akarsh Reddy <aeatham@ncsu.edu>
* Koul, Anmol <akoul2@ncsu.edu>
* More, Harsh Manoj <hmore@ncsu.edu>

File:Akoul2Update4.jpg

2024-12-04T05:33:09Z

Akoul2:

File:Akoul2Update3.jpg

2024-12-04T05:32:57Z

Akoul2:

File:Akoul2Update2.jpg

2024-12-04T05:32:49Z

Akoul2:

File:Akoul2Update1.jpg

2024-12-04T05:32:35Z

Akoul2:

CSC/ECE 517 Fall 2024 - E2476. Reimplement student teams controller.rb

2024-12-04T05:27:42Z

Akoul2: /* Testing Plan */

===Introduction===
[http://expertiza.ncsu.edu/ Expertiza] is an open-source system built on [http://rubyonrails.org/ Ruby on Rails], collaboratively maintained by students and faculty at NC State. This platform gives instructors extensive control over assignments, enabling them to add topics, create assignment groups, and manage peer reviews for various types of coursework. Expertiza is well-equipped to handle submissions across multiple formats, including URLs and wiki pages, and it offers a peer review system that facilitates constructive feedback among students.

A key focus of recent development in Expertiza has been the shift to a client-server architecture, where Ruby on Rails functions as the backend and React is utilized for the frontend. This architectural update requires reworking existing modules into RESTful API endpoints, allowing React components to interact efficiently with the backend. By adopting this approach, Expertiza aims to enhance modularity, performance, and scalability.

===Project Description===

The project mainly focuses on reimplementing the StudentTeamsController in Expertiza's backend, which is designed for student-facing operations where students participate in teams. This includes actions that directly affect individual team members, such as adding or removing students from teams, viewing team details, and managing their participation.

The TeamsController, on the other hand, is focused on instructor-driven operations that handle high-level team management across different contexts, such as courses and assignments. It manages operations like team creation, deletion, randomization, and bulk management actions.

===Problem Statement===

The current implementation of the StudentTeamsController in the Expertiza system is overly complex and tightly coupled, leading to difficulties in maintaining and extending the codebase. The controller is responsible for managing student teams in assignments, handling tasks like team creation, editing, management, and the integration of topics in assignments that require team-based decisions. However, it suffers from issues such as:
* Code redundancy and inefficiency due to business logic being embedded directly in the controller.
* Lack of modularity and poor separation of concerns, violating the Single Responsibility Principle (SRP). For example, it also handles the integration with topics when assignments involve choosing topics, complicating the team’s logic.
* Difficult-to-understand methods and tightly coupled logic for handling assignment-specific conditions, such as team-topic associations.
* Poor user feedback that does not provide clear or actionable information after critical operations.

These problems create a system that is hard to scale, maintain, and extend, especially as new features are added. To address these challenges, the goal is to reimplement the StudentTeamsController in the newer Expertiza backend codebase by adhering to object-oriented design principles, specifically focusing on maintainability, scalability, and modularity. The new design will improve the user experience by simplifying controller logic, providing clearer feedback, and ensuring that the system is easier to extend and maintain in the future.

===Objectives===

The main objective is to migrate the Student Task controller logic from serving HTML responses in the Ruby on Rails MVC model to returning JSON responses as a RESTful API, as part of the backend implementation. While reimplementing the controller, the following considerations will be incorporated to ensure a clean, maintainable, and scalable API:

*Reimplement the controller logic and write methods which appropriately follow the Single Responsibility Principle (SRP).
*Move business logic from the controller to appropriate model classes like Team or AssignmentTeam.
*Ensure all method names clearly describe their purpose and represent actions.
*Reimplement a Prototype pattern for creating mentored teams, leveraging the AssignmentTeam class.
*Automatically generate team names when a team is first referred to unless the user has specified a name when requesting team creation.
*Handle team requirements with better abstraction:
*Try to eliminate direct logic in the controller that checks for specific assignment requirements such as topic handling.
*Rename student_team_requirements_met? to something more descriptive and break it into smaller methods checking individual conditions.
*Aim to decouple topics from this controller entirely, ensuring better abstraction, that can involve changes to other classes or introducing service objects to handle specific requirements.
* Improve feedback to users and ensure that the user receives clear and actionable feedback after operations like team creation, removal of users, and other key actions.
* Add comprehensive comments throughout the controller, clearly explaining the purpose and functionality of custom methods.

===Development Strategy===

Our development strategy centers around Test-Driven Development (TDD) principles applied to refactoring the student_teams_controller.rb and other related classes such as Team or AssignmentTeam model. We design out test cases and iteratively refactor code to address identified inefficiencies while ensuring successful test outcomes.
Additionally, we emphasize on the strict adoption of SRP and DRY principles as per the object-oriented programming conventions. Our goal is to reimplement the existing functionalities
In the newly designed back-end foundation to foster a more efficient and organized codebase utilizing newer technologies. This approach will significantly enhance reusability and scalability across all the application while maintaining clean codebase.

Files Modified:
* Created ==>
** app/controllers/api/v1/student_teams_controller.rb
** app/models/assignment_team.rb
** app/models/team.rb
** spec/requests/api/v1/student_teams_controller_spec.rb
** db/migrate/20241201203840_create_assignment_teams.rb
** db/migrate/20241201220020_add_auto_assign_mentor_to_assignments.rb
** db/migrate/20241201221122_add_type_to_teams.rb
** db/migrate/20241202002102_add_name_to_teams.rb

* Updated ==>
** app/models/team.rb
** config/routes.rb
** db/schema.rb
** db/seeds.rb
** spec/swagger_helper.rb

===Project Design and Implementation===

The main approach to be followed throughout this project is to embrace the Prototyping Pattern within the controller while taking into account the current functionalities to be reimplemented within the student_teams_controller.rb that can capitalize its capability to encapsulate distinct controller actions. This strategic implementation aims to ensure seamless extensibility and enhanced usability. By employing this pattern, we establish a structured framework for defining and managing the diverse operations the controller handles, promoting a more organized and manageable code structure.

[[File:2476_UML.drawio.png]]

==== Functionality ====

1. Reimplement the Controller to Follow SRP:
* Break down large, complex methods into smaller, focused methods that adhere to the Single Responsibility Principle (SRP).
* Reimplement existing methods and logic while ensuring that each class and method have a clear, well-defined responsibility.
* Move business logic and complex operations out of the controller and into the appropriate model classes (e.g., Team, AssignmentTeam), ensuring the controller only handles HTTP-specific concerns (e.g., request handling, responses).

2. Improve Method Naming and Clarity:
* Ensure all method names are descriptive and represent the intent of the operation (e.g., renaming methods like student_team_requirements_met? to something more specific like validate_topic_requirements_for_team_creation).
* Adopt consistent naming conventions to improve the readability of the codebase.

3. Implement the Prototype Pattern for Team Creation:
* Leverage the Prototype pattern to create mentored teams through the AssignmentTeam class, allowing for easier management and creation of teams with a mentored structure.
* Automatically generate team names when a team is first created, unless a user has specified a custom name to improve the user experience and simplify team management.

4. Abstract Assignment-Specific Logic:
* Move logic related to assignment-specific requirements (e.g., topic handling) away from the controller, reducing complexity and increasing modularity.
* Introduce service objects or model methods to handle specific requirements like topic assignment, thereby decoupling assignment-related logic from the controller.
* Break down the student_team_requirements_met? method into smaller, more specific checks for different requirements (e.g., topic validation, minimum team size, etc.).

5. Improve User Feedback:
* Enhance the clarity and actionability of feedback messages after key operations (e.g., team creation, user removal, etc.).
* Provide users with clear, helpful notifications on the success or failure of their actions, including any necessary next steps or troubleshooting guidance.
* Ensure error handling is robust, and feedback is specific (e.g., specify which conditions were not met when creating or modifying teams).

6. Commenting and Documentation:
* Add comprehensive comments throughout the controller to clearly explain the purpose and functionality of custom methods and refactored logic.
* Ensure that code is well-documented, making it easier for future developers to understand and extend the functionality of the controller.

===Tasks Completed===

Methods:
* AssignmentTeam Model:
** To access every participant connected to an assignment, the assignment_participants method was added.
** For including a user in the assignment as a participant, the add_participant method was added.
** To see if the team has gotten any peer reviews, the received_any_peer_review? method was put into practice.
** Using a placeholder for future mentor assignment logic, the upgrade_to_mentored_team method was put into practice to replicate the present team and get it ready for mentoring.
** In order to ensure deep duplication of associated records (such as signed_up_teams, teams_users, and participants), the dup method was added to duplicate a team and its associations.

* Team Model:
** Improved the whole procedure to determine if a team has reached its maximum number of members.
** Counted the number of team members using the size approach, removing those with "(Mentor)" in their names.
** In order to eliminate duplicate members and check for team capacity, the add_member method was improved.
** To remove a user from the team, the remove_team_user method was put into place. If the team becomes empty and hasn't been subjected to any peer reviews, the team will be deleted.

* Controller - StudentTeamsController.rb
** index: Implemented in order to retrieve and restore every student team together with all of its members.
** show: Created to retrieve and provide information about a certain student team and its members.
** create: Added logic to create a new team for a student, using AssignmentTeam#upgraded_to_mentored_team for mentor-eligible teams and checking for existing team names.
** update: Implemented to enable team details, especially the team name, to be updated while ensuring unique team names through validations.
** destroy: To remove a certain team this was added and, if successful, deliver a 204 No Content response.
** remove_participant: Check if the user is part of the given team and removes from that team, also handles corner cases where no more participants are there in a team.
** add_participant: Added this to add the given participant to respective team.

===Testing Plan===

We have performed comprehensive testing of the student_teams_controller.rb and related classes using RSPEC and Swagger to construct the required test fixtures for testing extensive scenarios. Our approach involves reimplementing the existing test cases provided to the older code base and make sure that it is enhanced by covering more test scenarios to minimize code smells. We aim to verify the reimplemented functionality, validate the restructured code in the student_teams_controller.rb and reduce any design or code smell.
Below are the test scenarios for each of API endpoints -

1. List all Student Teams

*Description: List all student teams.
*Response: 200 OK
*Test Case Scenarios:
*Scenario 1: List all Student Teams
*Expectation: Successfully retrieves a list of all student teams. The response status is 200, the content type is `application/json`, and the response body contains 3 student teams.

RSpec.describe 'Student Teams API', type: :request do
path '/api/v1/student_teams' do
# List all Student Teams
get('List all Student Teams') do
tags 'Student Teams'
produces 'application/json'
security [Bearer: {}]
response(200, 'successful') do
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test!
end
end
*Postman Screenshot
[[File:Akoul2Index.jpg]]

2. Create a Student Team
*Description: Create a new student team.
*Response: 201 Created
*Test Data prep:
post 'Create a Student Team' do
tags 'Student Teams'
consumes 'application/json'
let(:institution) do
Institution.create!(
name: 'North Carolina State University'
)
end
let!(:instructor_role) { Role.find_or_create_by(name: 'Instructor') }
let!(:student_role) { Role.find_or_create_by(name: 'Student') }
let(:instructor_user) do
User.create!(
name: 'Dr. Ed Gehringer1',
email: 'gehringer@example.com',
password: 'password123',
full_name: 'admin admin',
institution_id: institution.id,
role_id: instructor_role.id,
handle: 'instructor'
)
end
let(:course) do
Course.create!(
name: '2476. Refactor',
directory_path: '/',
info: 'OODD',
private: false,
instructor_id: instructor_user.id,
institution_id: institution.id
)
end
let(:assignment) do
Assignment.create!(
title: 'Project 4 BRO',
description: '2476. Reimplementing',
course_id: course.id,
instructor_id: instructor_user.id
)
end
let!(:students) do
created_students = []
3.times do |i|
student = User.create!(
name: "Student #{i + 1}",
email: "Student#{i + 1}@gmail.com",
password: 'password123',
full_name: "Student #{i + 1}",
institution_id: institution.id,
role_id: student_role.id,
handle: "Student #{i + 1}"
)
AssignmentParticipant.create!(
assignment: assignment,
user: student,
handle: "Student #{i + 1}"
)
created_students << student
end
created_students
end
parameter name: :student_team_request, in: :body, schema: {
type: :object,
properties: {
team: {
type: :object,
properties: {
name: {type: :string}
}
},
student_id: { type: :integer}
}
}
security [Bearer: {}]
*Scenarios:
*Scenario 1: Successfully create a team
*Expectation: Successfully creates a new student team with a valid name and student ID. The response status is 201, and the response body includes the team name.
*Scenario 2: Team name is already in use (conflict)
*Attempts to create a student team with a name that is already in use.
*Expectation: The response status is 422, and the response body includes an error message indicating that the team name is already in use.
*Scenario 3: Invalid team creation (empty name)
*Expectation: Attempts to create a student team with an empty string name. The response status is 201, with team name autogenerated.

# Scenario 1: Successfully create a team
response(201, 'created') do
let(:student_team_request) do
{ team: {name: "HelloThere"}, student_id: students.first.id}
end
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test! do
expect(response.status).to eq(201)
end
end
# Scenario 2: Team name is already in use (conflict)
response(422, 'unprocessable entity') do
let(:existing_team) { create(:team, name: 'ABCD10', assignment_id: assignment.id) }
let(:team) do
post '/api/v1/student_teams', params: { team: { name: 'ABCD10' }, student_id: students.first.id }, as: :json
end
run_test! do
expect(response.status).to eq(422)
expect(response.body).to include('"error":"That team name is already in use."')
end
end
# Scenario 3: Invalid team creation (empty name)
response(422, 'unprocessable entity') do
let(:student_team_request) do
{ team: {name: ""}, student_id: students.first.id}
end
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test! do
expect(response.status).to eq(422)
expect(response.body).to include('error')
end
end
response(404, 'not_found') do
let(:team) do
post '/api/v1/student_teams', params: { team: { name: 'ABCD10' }, student_id: 0 }, as: :json
end
run_test! do
expect(response.status).to eq(404)
expect(response.body).to include('not found')
end
end
end
*Postman
*Scenario 1:
[[File:Akoul2Create.jpg]]
*Scenario 2:
[[File:Akoul2Create2.jpg]]
*Scenario 3:
[[File:Akoul2Create3.jpg]]

3. Update a Student Team
*Description: Update the details of a student team.
*Response: 200 OK
*Scenarios:
*Scenario 1: Team name updated successfully
*Expectation: Successfully updates the name of a student team. The response status is 200, and the response body includes the updated team name.
*Scenario 2: Invalid team update (empty name)
*Expectation: Attempts to update a student team with an empty name. The response status is 422, and the response body includes an error message indicating that the team name should not be empty.
*Scenario 3: Team name already in use
*Expectation: Attempts to update a student team with a name that is already in use. The response status is 422, and the response body includes an error message indicating that the team name is already in use.
*Scenario 4: Invalid team ID
*Expectation: Attempts to update a student team with a non-existent team ID. The response status is 404, and the response body includes an error message indicating that the team was not found.

patch('Update a Student Team') do
tags 'Student Teams'
consumes 'application/json'
produces 'application/json'
security [Bearer: {}]
parameter name: :student_team_request, in: :body, schema: {
type: :object,
properties: {
team: {
type: :object,
properties: {
name: {type: :string}
}
},
team_id: { type: :integer}
}
}
# Scenario 1: Team name updated successfully
response(200, 'successful') do
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test! do
expect(response.status).to eq(200)
end
end
# Scenario 2: Invalid team updation (empty name)
response(422, 'unprocessable entity') do
let(:student_team_request) do
{ team: {name: ""}, team_id: 2}
end
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test! do
expect(response.status).to eq(422)
expect(response.body).to include('Team name should not be empty')
end
end
# Scenario 3: Team Name already present
response(422, 'unprocessable entity') do
let(:existing_team) { create(:team, name: 'ABCD10', team_id: 3) }
let(:team) do
post '/api/v1/student_teams', params: { team: { name: 'ABCD10' }, team_id: 2 }, as: :json
end
run_test! do
expect(response.status).to eq(422)
expect(response.body).to include('"error":"That team name is already in use."')
end
end
#Scenario 4 : Invalid Team ID
response(404, 'not_found') do
let(:team) do
post '/api/v1/student_teams', params: { team: { name: 'ABCD10' }, team_id: 0 }, as: :json
end
run_test! do
expect(response.status).to eq(404)
expect(response.body).to include('not found')
end
end
end
end

4. Show a Student Team
*Description: Retrieve the details of a student team by its ID.
*Response: 200 OK
*Scenarios:
*Scenario 1: Show Student Team
*Expectation: Successfully retrieves the details of a student team by its ID. The response status is 200, and the response body includes the details of the student team.
*Scenario 2: Team not found
*Expectation: Attempts to retrieve the details of a student team with an invalid ID. The response status is 404, and the response body includes an error message indicating that the team was not found.
path '/api/v1/student_teams/{id}' do
parameter name: 'id', in: :path, type: :integer
# Get request on /api/v1/student_teams/{id} returns the response 200 succesful - when correct id passed is present in the database
get('Show a Student Team') do
tags 'Student Teams'
produces 'application/json'
security [Bearer: {}]
response(200, 'successful') do
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test! do
expect(response.status).to eq(200)
end
end
# Get request on /api/v1/student_teams/{id} returns the response 404 not found - when correct id passed is not present in the database
response(404, 'not_found') do
let(:id) { 'invalid' }
run_test! do
expect(response.status).to eq(404)
end
end
end

*Postman:
**Scenario 1:
[[File:Akoul2Show.jpg]]
**Scenario 2:
[[File:Akoul2Show not.jpg]]

5. Delete a Student Team
*Description: Delete a student team by its ID.
*Response: 204 No Content
*Scenarios:
*Scenario 1: Successfully delete a student team
*Expectation: Successfully deletes a student team by its ID. The response status is 204, and the student team is no longer present in the database.
*Scenario 2: Team not found
*Expectation: Attempts to delete a student team with an invalid ID. The response status is 404, and the response body includes an error message indicating that the team was not found.

delete('Delete a Student Team') do
tags 'Student Teams'
produces 'application/json'
security [Bearer: {}]
# delete request on /api/v1/student_teams/{id} returns 204 succesful response when id present in the database is deleted successfully
response(204, 'successful') do
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: ''
}
}
end
run_test! do
expect(response.status).to eq(204)
end
end
# delete request on /api/v1/student_teams/{id} returns 404 not found response, when id is not present in the database
response(404, 'not found') do
let(:id) { 0 }
run_test! do
expect(response.status).to eq(404)
end
end
end
end

*Postman:
*Scenarios:
*Scenario 1: [[File:2476_delete_1.png]]
*Scenario 2: [[File:2476_delete_1.png]]

6. Add a Participant in Student Team
*Description: Add a participant to a student team.
*Response: 200 OK
*Test Data Prep
path '/api/v1/student_teams/{id}/add_participant' do
parameter name: 'id', in: :path, type: :integer, description: 'ID of Team'
parameter name: 'student_id', in: :query, type: :integer, description: 'ID of the Student'
let(:student) { create(:user, :student) }
let(:assignment) { create(:assignment) }
let(:student_participant) { create(:assignment_participant, user: student, assignment: assignment) }
let(:team) { create(:assignment_team, assignment: assignment) }
let(:id) { team.id }
let(:student_id) { student.id }
*Scenarios:
*Scenario 1: Successfully add a participant to a student team
*Expectation: Successfully adds a participant to a student team by their ID. The response status is 200, and the participant is added to the team.
patch('Add a participant to Student Team') do
tags 'Student Teams'
consumes 'application/json'
produces 'application/json'
security [Bearer: {}]
before do
team.add_member(student, assignment.id)
end
response(200, 'successful') do
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test!
end
end
end
*Postman:
[[File:Akoul2Add participant.jpg]]
7. Remove a Participant in Student Team
*Description: Remove a participant from a student team.
*Response: 204 No Content
*Test data prep:

path '/api/v1/student_teams/{id}/remove_participant' do
parameter name: 'id', in: :path, type: :integer, description: 'ID of Team'
parameter name: 'student_id', in: :query, type: :integer, description: 'ID of the Student'
let(:student) { create(:user, :student) }
let(:assignment) { create(:assignment) }
let(:student_participant) { create(:assignment_participant, user: student, assignment: assignment) }
let(:team) { create(:assignment_team, assignment: assignment) }
let(:id) { team.id }
let(:student_id) { student.id }
before do
team.add_member(student, assignment.id)
end
*Scenarios:
*Scenario 1: Successfully remove a participant from a student team
*Expectation: Successfully removes a participant from a student team by their ID. The response status is 204, and the participant is no longer a member of the team.
*Scenario 2: Team not found
*Expectation: Attempts to remove a participant from a student team with an invalid team ID. The response status is 404, and the response body includes an error message indicating that the team was not found.
*Scenario 3: User not found
*Expectation: Attempts to remove a participant from a student team with an invalid user ID. The response status is 404, and the response body includes an error message indicating that the user was not found.

delete('remove participant') do
tags 'Student Teams'
produces 'application/json'
security [Bearer: {}]
response(204, 'successful') do
let(:Authorization) { "Bearer #{@token}" }
run_test! do
expect(response.status).to eq(204)
expect(team.members).not_to include(student)
end
end
response(404, 'team not found') do
let(:id) { -1 } # Invalid ID
run_test! do
expect(response.status).to eq(404)
expect(JSON.parse(response.body)['error']).to eq('Team not found.')
end
end
response(404, 'user not found') do
let(:student_id) { -1 } # Invalid student ID
run_test! do
expect(response.status).to eq(404)
expect(JSON.parse(response.body)['error']).to eq('User not found.')
end
end
end
end

===GitHub Pull Request===

https://github.com/expertiza/reimplementation-back-end/pull/136

===Demo Video===

https://www.youtube.com/watch?v=8_d_Y9EcgHc

===Mentor===

* Ammana, Sahithi <sammana@ncsu.edu>

===Team Members===

* Eathamukkala, Akarsh Reddy <aeatham@ncsu.edu>
* Koul, Anmol <akoul2@ncsu.edu>
* More, Harsh Manoj <hmore@ncsu.edu>

CSC/ECE 517 Fall 2024 - E2476. Reimplement student teams controller.rb

2024-12-04T05:26:30Z

Akoul2: /* Testing Plan */

===Introduction===
[http://expertiza.ncsu.edu/ Expertiza] is an open-source system built on [http://rubyonrails.org/ Ruby on Rails], collaboratively maintained by students and faculty at NC State. This platform gives instructors extensive control over assignments, enabling them to add topics, create assignment groups, and manage peer reviews for various types of coursework. Expertiza is well-equipped to handle submissions across multiple formats, including URLs and wiki pages, and it offers a peer review system that facilitates constructive feedback among students.

A key focus of recent development in Expertiza has been the shift to a client-server architecture, where Ruby on Rails functions as the backend and React is utilized for the frontend. This architectural update requires reworking existing modules into RESTful API endpoints, allowing React components to interact efficiently with the backend. By adopting this approach, Expertiza aims to enhance modularity, performance, and scalability.

===Project Description===

The project mainly focuses on reimplementing the StudentTeamsController in Expertiza's backend, which is designed for student-facing operations where students participate in teams. This includes actions that directly affect individual team members, such as adding or removing students from teams, viewing team details, and managing their participation.

The TeamsController, on the other hand, is focused on instructor-driven operations that handle high-level team management across different contexts, such as courses and assignments. It manages operations like team creation, deletion, randomization, and bulk management actions.

===Problem Statement===

The current implementation of the StudentTeamsController in the Expertiza system is overly complex and tightly coupled, leading to difficulties in maintaining and extending the codebase. The controller is responsible for managing student teams in assignments, handling tasks like team creation, editing, management, and the integration of topics in assignments that require team-based decisions. However, it suffers from issues such as:
* Code redundancy and inefficiency due to business logic being embedded directly in the controller.
* Lack of modularity and poor separation of concerns, violating the Single Responsibility Principle (SRP). For example, it also handles the integration with topics when assignments involve choosing topics, complicating the team’s logic.
* Difficult-to-understand methods and tightly coupled logic for handling assignment-specific conditions, such as team-topic associations.
* Poor user feedback that does not provide clear or actionable information after critical operations.

These problems create a system that is hard to scale, maintain, and extend, especially as new features are added. To address these challenges, the goal is to reimplement the StudentTeamsController in the newer Expertiza backend codebase by adhering to object-oriented design principles, specifically focusing on maintainability, scalability, and modularity. The new design will improve the user experience by simplifying controller logic, providing clearer feedback, and ensuring that the system is easier to extend and maintain in the future.

===Objectives===

The main objective is to migrate the Student Task controller logic from serving HTML responses in the Ruby on Rails MVC model to returning JSON responses as a RESTful API, as part of the backend implementation. While reimplementing the controller, the following considerations will be incorporated to ensure a clean, maintainable, and scalable API:

*Reimplement the controller logic and write methods which appropriately follow the Single Responsibility Principle (SRP).
*Move business logic from the controller to appropriate model classes like Team or AssignmentTeam.
*Ensure all method names clearly describe their purpose and represent actions.
*Reimplement a Prototype pattern for creating mentored teams, leveraging the AssignmentTeam class.
*Automatically generate team names when a team is first referred to unless the user has specified a name when requesting team creation.
*Handle team requirements with better abstraction:
*Try to eliminate direct logic in the controller that checks for specific assignment requirements such as topic handling.
*Rename student_team_requirements_met? to something more descriptive and break it into smaller methods checking individual conditions.
*Aim to decouple topics from this controller entirely, ensuring better abstraction, that can involve changes to other classes or introducing service objects to handle specific requirements.
* Improve feedback to users and ensure that the user receives clear and actionable feedback after operations like team creation, removal of users, and other key actions.
* Add comprehensive comments throughout the controller, clearly explaining the purpose and functionality of custom methods.

===Development Strategy===

Our development strategy centers around Test-Driven Development (TDD) principles applied to refactoring the student_teams_controller.rb and other related classes such as Team or AssignmentTeam model. We design out test cases and iteratively refactor code to address identified inefficiencies while ensuring successful test outcomes.
Additionally, we emphasize on the strict adoption of SRP and DRY principles as per the object-oriented programming conventions. Our goal is to reimplement the existing functionalities
In the newly designed back-end foundation to foster a more efficient and organized codebase utilizing newer technologies. This approach will significantly enhance reusability and scalability across all the application while maintaining clean codebase.

Files Modified:
* Created ==>
** app/controllers/api/v1/student_teams_controller.rb
** app/models/assignment_team.rb
** app/models/team.rb
** spec/requests/api/v1/student_teams_controller_spec.rb
** db/migrate/20241201203840_create_assignment_teams.rb
** db/migrate/20241201220020_add_auto_assign_mentor_to_assignments.rb
** db/migrate/20241201221122_add_type_to_teams.rb
** db/migrate/20241202002102_add_name_to_teams.rb

* Updated ==>
** app/models/team.rb
** config/routes.rb
** db/schema.rb
** db/seeds.rb
** spec/swagger_helper.rb

===Project Design and Implementation===

The main approach to be followed throughout this project is to embrace the Prototyping Pattern within the controller while taking into account the current functionalities to be reimplemented within the student_teams_controller.rb that can capitalize its capability to encapsulate distinct controller actions. This strategic implementation aims to ensure seamless extensibility and enhanced usability. By employing this pattern, we establish a structured framework for defining and managing the diverse operations the controller handles, promoting a more organized and manageable code structure.

[[File:2476_UML.drawio.png]]

==== Functionality ====

1. Reimplement the Controller to Follow SRP:
* Break down large, complex methods into smaller, focused methods that adhere to the Single Responsibility Principle (SRP).
* Reimplement existing methods and logic while ensuring that each class and method have a clear, well-defined responsibility.
* Move business logic and complex operations out of the controller and into the appropriate model classes (e.g., Team, AssignmentTeam), ensuring the controller only handles HTTP-specific concerns (e.g., request handling, responses).

2. Improve Method Naming and Clarity:
* Ensure all method names are descriptive and represent the intent of the operation (e.g., renaming methods like student_team_requirements_met? to something more specific like validate_topic_requirements_for_team_creation).
* Adopt consistent naming conventions to improve the readability of the codebase.

3. Implement the Prototype Pattern for Team Creation:
* Leverage the Prototype pattern to create mentored teams through the AssignmentTeam class, allowing for easier management and creation of teams with a mentored structure.
* Automatically generate team names when a team is first created, unless a user has specified a custom name to improve the user experience and simplify team management.

4. Abstract Assignment-Specific Logic:
* Move logic related to assignment-specific requirements (e.g., topic handling) away from the controller, reducing complexity and increasing modularity.
* Introduce service objects or model methods to handle specific requirements like topic assignment, thereby decoupling assignment-related logic from the controller.
* Break down the student_team_requirements_met? method into smaller, more specific checks for different requirements (e.g., topic validation, minimum team size, etc.).

5. Improve User Feedback:
* Enhance the clarity and actionability of feedback messages after key operations (e.g., team creation, user removal, etc.).
* Provide users with clear, helpful notifications on the success or failure of their actions, including any necessary next steps or troubleshooting guidance.
* Ensure error handling is robust, and feedback is specific (e.g., specify which conditions were not met when creating or modifying teams).

6. Commenting and Documentation:
* Add comprehensive comments throughout the controller to clearly explain the purpose and functionality of custom methods and refactored logic.
* Ensure that code is well-documented, making it easier for future developers to understand and extend the functionality of the controller.

===Tasks Completed===

Methods:
* AssignmentTeam Model:
** To access every participant connected to an assignment, the assignment_participants method was added.
** For including a user in the assignment as a participant, the add_participant method was added.
** To see if the team has gotten any peer reviews, the received_any_peer_review? method was put into practice.
** Using a placeholder for future mentor assignment logic, the upgrade_to_mentored_team method was put into practice to replicate the present team and get it ready for mentoring.
** In order to ensure deep duplication of associated records (such as signed_up_teams, teams_users, and participants), the dup method was added to duplicate a team and its associations.

* Team Model:
** Improved the whole procedure to determine if a team has reached its maximum number of members.
** Counted the number of team members using the size approach, removing those with "(Mentor)" in their names.
** In order to eliminate duplicate members and check for team capacity, the add_member method was improved.
** To remove a user from the team, the remove_team_user method was put into place. If the team becomes empty and hasn't been subjected to any peer reviews, the team will be deleted.

* Controller - StudentTeamsController.rb
** index: Implemented in order to retrieve and restore every student team together with all of its members.
** show: Created to retrieve and provide information about a certain student team and its members.
** create: Added logic to create a new team for a student, using AssignmentTeam#upgraded_to_mentored_team for mentor-eligible teams and checking for existing team names.
** update: Implemented to enable team details, especially the team name, to be updated while ensuring unique team names through validations.
** destroy: To remove a certain team this was added and, if successful, deliver a 204 No Content response.
** remove_participant: Check if the user is part of the given team and removes from that team, also handles corner cases where no more participants are there in a team.
** add_participant: Added this to add the given participant to respective team.

===Testing Plan===

We have performed comprehensive testing of the student_teams_controller.rb and related classes using RSPEC and Swagger to construct the required test fixtures for testing extensive scenarios. Our approach involves reimplementing the existing test cases provided to the older code base and make sure that it is enhanced by covering more test scenarios to minimize code smells. We aim to verify the reimplemented functionality, validate the restructured code in the student_teams_controller.rb and reduce any design or code smell.
Below are the test scenarios for each of API endpoints -

1. List all Student Teams

*Description: List all student teams.
*Response: 200 OK
*Test Case Scenarios:
*Scenario 1: List all Student Teams
*Expectation: Successfully retrieves a list of all student teams. The response status is 200, the content type is `application/json`, and the response body contains 3 student teams.

RSpec.describe 'Student Teams API', type: :request do
path '/api/v1/student_teams' do
# List all Student Teams
get('List all Student Teams') do
tags 'Student Teams'
produces 'application/json'
security [Bearer: {}]
response(200, 'successful') do
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test!
end
end
*Postman Screenshot
[[File:Akoul2Index.jpg]]

2. Create a Student Team
*Description: Create a new student team.
*Response: 201 Created
*Test Data prep:
post 'Create a Student Team' do
tags 'Student Teams'
consumes 'application/json'
let(:institution) do
Institution.create!(
name: 'North Carolina State University'
)
end
let!(:instructor_role) { Role.find_or_create_by(name: 'Instructor') }
let!(:student_role) { Role.find_or_create_by(name: 'Student') }
let(:instructor_user) do
User.create!(
name: 'Dr. Ed Gehringer1',
email: 'gehringer@example.com',
password: 'password123',
full_name: 'admin admin',
institution_id: institution.id,
role_id: instructor_role.id,
handle: 'instructor'
)
end
let(:course) do
Course.create!(
name: '2476. Refactor',
directory_path: '/',
info: 'OODD',
private: false,
instructor_id: instructor_user.id,
institution_id: institution.id
)
end
let(:assignment) do
Assignment.create!(
title: 'Project 4 BRO',
description: '2476. Reimplementing',
course_id: course.id,
instructor_id: instructor_user.id
)
end
let!(:students) do
created_students = []
3.times do |i|
student = User.create!(
name: "Student #{i + 1}",
email: "Student#{i + 1}@gmail.com",
password: 'password123',
full_name: "Student #{i + 1}",
institution_id: institution.id,
role_id: student_role.id,
handle: "Student #{i + 1}"
)
AssignmentParticipant.create!(
assignment: assignment,
user: student,
handle: "Student #{i + 1}"
)
created_students << student
end
created_students
end
parameter name: :student_team_request, in: :body, schema: {
type: :object,
properties: {
team: {
type: :object,
properties: {
name: {type: :string}
}
},
student_id: { type: :integer}
}
}
security [Bearer: {}]
*Scenarios:
*Scenario 1: Successfully create a team
*Expectation: Successfully creates a new student team with a valid name and student ID. The response status is 201, and the response body includes the team name.
*Scenario 2: Team name is already in use (conflict)
*Attempts to create a student team with a name that is already in use.
*Expectation: The response status is 422, and the response body includes an error message indicating that the team name is already in use.
*Scenario 3: Invalid team creation (empty name)
*Expectation: Attempts to create a student team with an empty string name. The response status is 201, with team name autogenerated.

# Scenario 1: Successfully create a team
response(201, 'created') do
let(:student_team_request) do
{ team: {name: "HelloThere"}, student_id: students.first.id}
end
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test! do
expect(response.status).to eq(201)
end
end
# Scenario 2: Team name is already in use (conflict)
response(422, 'unprocessable entity') do
let(:existing_team) { create(:team, name: 'ABCD10', assignment_id: assignment.id) }
let(:team) do
post '/api/v1/student_teams', params: { team: { name: 'ABCD10' }, student_id: students.first.id }, as: :json
end
run_test! do
expect(response.status).to eq(422)
expect(response.body).to include('"error":"That team name is already in use."')
end
end
# Scenario 3: Invalid team creation (empty name)
response(422, 'unprocessable entity') do
let(:student_team_request) do
{ team: {name: ""}, student_id: students.first.id}
end
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test! do
expect(response.status).to eq(422)
expect(response.body).to include('error')
end
end
response(404, 'not_found') do
let(:team) do
post '/api/v1/student_teams', params: { team: { name: 'ABCD10' }, student_id: 0 }, as: :json
end
run_test! do
expect(response.status).to eq(404)
expect(response.body).to include('not found')
end
end
end
*Postman
*Scenario 1:
[[File:Akoul2Create.jpg]]
*Scenario 2:
[[File:Akoul2Create2.jpg]]
*Scenario 3:
[[File:Akoul2Create3.jpg]]
3. Update a Student Team
*Description: Update the details of a student team.
*Response: 200 OK
*Scenarios:
*Scenario 1: Team name updated successfully
*Expectation: Successfully updates the name of a student team. The response status is 200, and the response body includes the updated team name.
*Scenario 2: Invalid team update (empty name)
*Expectation: Attempts to update a student team with an empty name. The response status is 422, and the response body includes an error message indicating that the team name should not be empty.
*Scenario 3: Team name already in use
*Expectation: Attempts to update a student team with a name that is already in use. The response status is 422, and the response body includes an error message indicating that the team name is already in use.
*Scenario 4: Invalid team ID
*Expectation: Attempts to update a student team with a non-existent team ID. The response status is 404, and the response body includes an error message indicating that the team was not found.

patch('Update a Student Team') do
tags 'Student Teams'
consumes 'application/json'
produces 'application/json'
security [Bearer: {}]
parameter name: :student_team_request, in: :body, schema: {
type: :object,
properties: {
team: {
type: :object,
properties: {
name: {type: :string}
}
},
team_id: { type: :integer}
}
}
# Scenario 1: Team name updated successfully
response(200, 'successful') do
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test! do
expect(response.status).to eq(200)
end
end
# Scenario 2: Invalid team updation (empty name)
response(422, 'unprocessable entity') do
let(:student_team_request) do
{ team: {name: ""}, team_id: 2}
end
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test! do
expect(response.status).to eq(422)
expect(response.body).to include('Team name should not be empty')
end
end
# Scenario 3: Team Name already present
response(422, 'unprocessable entity') do
let(:existing_team) { create(:team, name: 'ABCD10', team_id: 3) }
let(:team) do
post '/api/v1/student_teams', params: { team: { name: 'ABCD10' }, team_id: 2 }, as: :json
end
run_test! do
expect(response.status).to eq(422)
expect(response.body).to include('"error":"That team name is already in use."')
end
end
#Scenario 4 : Invalid Team ID
response(404, 'not_found') do
let(:team) do
post '/api/v1/student_teams', params: { team: { name: 'ABCD10' }, team_id: 0 }, as: :json
end
run_test! do
expect(response.status).to eq(404)
expect(response.body).to include('not found')
end
end
end
end

4. Show a Student Team
*Description: Retrieve the details of a student team by its ID.
*Response: 200 OK
*Scenarios:
*Scenario 1: Show Student Team
*Expectation: Successfully retrieves the details of a student team by its ID. The response status is 200, and the response body includes the details of the student team.
*Scenario 2: Team not found
*Expectation: Attempts to retrieve the details of a student team with an invalid ID. The response status is 404, and the response body includes an error message indicating that the team was not found.
path '/api/v1/student_teams/{id}' do
parameter name: 'id', in: :path, type: :integer
# Get request on /api/v1/student_teams/{id} returns the response 200 succesful - when correct id passed is present in the database
get('Show a Student Team') do
tags 'Student Teams'
produces 'application/json'
security [Bearer: {}]
response(200, 'successful') do
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test! do
expect(response.status).to eq(200)
end
end
# Get request on /api/v1/student_teams/{id} returns the response 404 not found - when correct id passed is not present in the database
response(404, 'not_found') do
let(:id) { 'invalid' }
run_test! do
expect(response.status).to eq(404)
end
end
end

*Postman:
**Scenario 1:
[[File:Akoul2Show.jpg]]
**Scenario 2:
[[File:Akoul2Show not.jpg]]

5. Delete a Student Team
*Description: Delete a student team by its ID.
*Response: 204 No Content
*Scenarios:
*Scenario 1: Successfully delete a student team
*Expectation: Successfully deletes a student team by its ID. The response status is 204, and the student team is no longer present in the database.
*Scenario 2: Team not found
*Expectation: Attempts to delete a student team with an invalid ID. The response status is 404, and the response body includes an error message indicating that the team was not found.

delete('Delete a Student Team') do
tags 'Student Teams'
produces 'application/json'
security [Bearer: {}]
# delete request on /api/v1/student_teams/{id} returns 204 succesful response when id present in the database is deleted successfully
response(204, 'successful') do
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: ''
}
}
end
run_test! do
expect(response.status).to eq(204)
end
end
# delete request on /api/v1/student_teams/{id} returns 404 not found response, when id is not present in the database
response(404, 'not found') do
let(:id) { 0 }
run_test! do
expect(response.status).to eq(404)
end
end
end
end

6. Add a Participant in Student Team
*Description: Add a participant to a student team.
*Response: 200 OK
*Test Data Prep
path '/api/v1/student_teams/{id}/add_participant' do
parameter name: 'id', in: :path, type: :integer, description: 'ID of Team'
parameter name: 'student_id', in: :query, type: :integer, description: 'ID of the Student'
let(:student) { create(:user, :student) }
let(:assignment) { create(:assignment) }
let(:student_participant) { create(:assignment_participant, user: student, assignment: assignment) }
let(:team) { create(:assignment_team, assignment: assignment) }
let(:id) { team.id }
let(:student_id) { student.id }
*Scenarios:
*Scenario 1: Successfully add a participant to a student team
*Expectation: Successfully adds a participant to a student team by their ID. The response status is 200, and the participant is added to the team.
patch('Add a participant to Student Team') do
tags 'Student Teams'
consumes 'application/json'
produces 'application/json'
security [Bearer: {}]
before do
team.add_member(student, assignment.id)
end
response(200, 'successful') do
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test!
end
end
end
*Postman:
[[File:Akoul2Add participant.jpg]]
7. Remove a Participant in Student Team
*Description: Remove a participant from a student team.
*Response: 204 No Content
*Test data prep:

path '/api/v1/student_teams/{id}/remove_participant' do
parameter name: 'id', in: :path, type: :integer, description: 'ID of Team'
parameter name: 'student_id', in: :query, type: :integer, description: 'ID of the Student'
let(:student) { create(:user, :student) }
let(:assignment) { create(:assignment) }
let(:student_participant) { create(:assignment_participant, user: student, assignment: assignment) }
let(:team) { create(:assignment_team, assignment: assignment) }
let(:id) { team.id }
let(:student_id) { student.id }
before do
team.add_member(student, assignment.id)
end
*Scenarios:
*Scenario 1: Successfully remove a participant from a student team
*Expectation: Successfully removes a participant from a student team by their ID. The response status is 204, and the participant is no longer a member of the team.
*Scenario 2: Team not found
*Expectation: Attempts to remove a participant from a student team with an invalid team ID. The response status is 404, and the response body includes an error message indicating that the team was not found.
*Scenario 3: User not found
*Expectation: Attempts to remove a participant from a student team with an invalid user ID. The response status is 404, and the response body includes an error message indicating that the user was not found.

delete('remove participant') do
tags 'Student Teams'
produces 'application/json'
security [Bearer: {}]
response(204, 'successful') do
let(:Authorization) { "Bearer #{@token}" }
run_test! do
expect(response.status).to eq(204)
expect(team.members).not_to include(student)
end
end
response(404, 'team not found') do
let(:id) { -1 } # Invalid ID
run_test! do
expect(response.status).to eq(404)
expect(JSON.parse(response.body)['error']).to eq('Team not found.')
end
end
response(404, 'user not found') do
let(:student_id) { -1 } # Invalid student ID
run_test! do
expect(response.status).to eq(404)
expect(JSON.parse(response.body)['error']).to eq('User not found.')
end
end
end
end

===GitHub Pull Request===

https://github.com/expertiza/reimplementation-back-end/pull/136

===Demo Video===

https://www.youtube.com/watch?v=8_d_Y9EcgHc

===Mentor===

* Ammana, Sahithi <sammana@ncsu.edu>

===Team Members===

* Eathamukkala, Akarsh Reddy <aeatham@ncsu.edu>
* Koul, Anmol <akoul2@ncsu.edu>
* More, Harsh Manoj <hmore@ncsu.edu>

CSC/ECE 517 Fall 2024 - E2476. Reimplement student teams controller.rb

2024-12-04T05:26:02Z

Akoul2: /* Testing Plan */

===Introduction===
[http://expertiza.ncsu.edu/ Expertiza] is an open-source system built on [http://rubyonrails.org/ Ruby on Rails], collaboratively maintained by students and faculty at NC State. This platform gives instructors extensive control over assignments, enabling them to add topics, create assignment groups, and manage peer reviews for various types of coursework. Expertiza is well-equipped to handle submissions across multiple formats, including URLs and wiki pages, and it offers a peer review system that facilitates constructive feedback among students.

A key focus of recent development in Expertiza has been the shift to a client-server architecture, where Ruby on Rails functions as the backend and React is utilized for the frontend. This architectural update requires reworking existing modules into RESTful API endpoints, allowing React components to interact efficiently with the backend. By adopting this approach, Expertiza aims to enhance modularity, performance, and scalability.

===Project Description===

The project mainly focuses on reimplementing the StudentTeamsController in Expertiza's backend, which is designed for student-facing operations where students participate in teams. This includes actions that directly affect individual team members, such as adding or removing students from teams, viewing team details, and managing their participation.

The TeamsController, on the other hand, is focused on instructor-driven operations that handle high-level team management across different contexts, such as courses and assignments. It manages operations like team creation, deletion, randomization, and bulk management actions.

===Problem Statement===

The current implementation of the StudentTeamsController in the Expertiza system is overly complex and tightly coupled, leading to difficulties in maintaining and extending the codebase. The controller is responsible for managing student teams in assignments, handling tasks like team creation, editing, management, and the integration of topics in assignments that require team-based decisions. However, it suffers from issues such as:
* Code redundancy and inefficiency due to business logic being embedded directly in the controller.
* Lack of modularity and poor separation of concerns, violating the Single Responsibility Principle (SRP). For example, it also handles the integration with topics when assignments involve choosing topics, complicating the team’s logic.
* Difficult-to-understand methods and tightly coupled logic for handling assignment-specific conditions, such as team-topic associations.
* Poor user feedback that does not provide clear or actionable information after critical operations.

These problems create a system that is hard to scale, maintain, and extend, especially as new features are added. To address these challenges, the goal is to reimplement the StudentTeamsController in the newer Expertiza backend codebase by adhering to object-oriented design principles, specifically focusing on maintainability, scalability, and modularity. The new design will improve the user experience by simplifying controller logic, providing clearer feedback, and ensuring that the system is easier to extend and maintain in the future.

===Objectives===

The main objective is to migrate the Student Task controller logic from serving HTML responses in the Ruby on Rails MVC model to returning JSON responses as a RESTful API, as part of the backend implementation. While reimplementing the controller, the following considerations will be incorporated to ensure a clean, maintainable, and scalable API:

*Reimplement the controller logic and write methods which appropriately follow the Single Responsibility Principle (SRP).
*Move business logic from the controller to appropriate model classes like Team or AssignmentTeam.
*Ensure all method names clearly describe their purpose and represent actions.
*Reimplement a Prototype pattern for creating mentored teams, leveraging the AssignmentTeam class.
*Automatically generate team names when a team is first referred to unless the user has specified a name when requesting team creation.
*Handle team requirements with better abstraction:
*Try to eliminate direct logic in the controller that checks for specific assignment requirements such as topic handling.
*Rename student_team_requirements_met? to something more descriptive and break it into smaller methods checking individual conditions.
*Aim to decouple topics from this controller entirely, ensuring better abstraction, that can involve changes to other classes or introducing service objects to handle specific requirements.
* Improve feedback to users and ensure that the user receives clear and actionable feedback after operations like team creation, removal of users, and other key actions.
* Add comprehensive comments throughout the controller, clearly explaining the purpose and functionality of custom methods.

===Development Strategy===

Our development strategy centers around Test-Driven Development (TDD) principles applied to refactoring the student_teams_controller.rb and other related classes such as Team or AssignmentTeam model. We design out test cases and iteratively refactor code to address identified inefficiencies while ensuring successful test outcomes.
Additionally, we emphasize on the strict adoption of SRP and DRY principles as per the object-oriented programming conventions. Our goal is to reimplement the existing functionalities
In the newly designed back-end foundation to foster a more efficient and organized codebase utilizing newer technologies. This approach will significantly enhance reusability and scalability across all the application while maintaining clean codebase.

Files Modified:
* Created ==>
** app/controllers/api/v1/student_teams_controller.rb
** app/models/assignment_team.rb
** app/models/team.rb
** spec/requests/api/v1/student_teams_controller_spec.rb
** db/migrate/20241201203840_create_assignment_teams.rb
** db/migrate/20241201220020_add_auto_assign_mentor_to_assignments.rb
** db/migrate/20241201221122_add_type_to_teams.rb
** db/migrate/20241202002102_add_name_to_teams.rb

* Updated ==>
** app/models/team.rb
** config/routes.rb
** db/schema.rb
** db/seeds.rb
** spec/swagger_helper.rb

===Project Design and Implementation===

The main approach to be followed throughout this project is to embrace the Prototyping Pattern within the controller while taking into account the current functionalities to be reimplemented within the student_teams_controller.rb that can capitalize its capability to encapsulate distinct controller actions. This strategic implementation aims to ensure seamless extensibility and enhanced usability. By employing this pattern, we establish a structured framework for defining and managing the diverse operations the controller handles, promoting a more organized and manageable code structure.

[[File:2476_UML.drawio.png]]

==== Functionality ====

1. Reimplement the Controller to Follow SRP:
* Break down large, complex methods into smaller, focused methods that adhere to the Single Responsibility Principle (SRP).
* Reimplement existing methods and logic while ensuring that each class and method have a clear, well-defined responsibility.
* Move business logic and complex operations out of the controller and into the appropriate model classes (e.g., Team, AssignmentTeam), ensuring the controller only handles HTTP-specific concerns (e.g., request handling, responses).

2. Improve Method Naming and Clarity:
* Ensure all method names are descriptive and represent the intent of the operation (e.g., renaming methods like student_team_requirements_met? to something more specific like validate_topic_requirements_for_team_creation).
* Adopt consistent naming conventions to improve the readability of the codebase.

3. Implement the Prototype Pattern for Team Creation:
* Leverage the Prototype pattern to create mentored teams through the AssignmentTeam class, allowing for easier management and creation of teams with a mentored structure.
* Automatically generate team names when a team is first created, unless a user has specified a custom name to improve the user experience and simplify team management.

4. Abstract Assignment-Specific Logic:
* Move logic related to assignment-specific requirements (e.g., topic handling) away from the controller, reducing complexity and increasing modularity.
* Introduce service objects or model methods to handle specific requirements like topic assignment, thereby decoupling assignment-related logic from the controller.
* Break down the student_team_requirements_met? method into smaller, more specific checks for different requirements (e.g., topic validation, minimum team size, etc.).

5. Improve User Feedback:
* Enhance the clarity and actionability of feedback messages after key operations (e.g., team creation, user removal, etc.).
* Provide users with clear, helpful notifications on the success or failure of their actions, including any necessary next steps or troubleshooting guidance.
* Ensure error handling is robust, and feedback is specific (e.g., specify which conditions were not met when creating or modifying teams).

6. Commenting and Documentation:
* Add comprehensive comments throughout the controller to clearly explain the purpose and functionality of custom methods and refactored logic.
* Ensure that code is well-documented, making it easier for future developers to understand and extend the functionality of the controller.

===Tasks Completed===

Methods:
* AssignmentTeam Model:
** To access every participant connected to an assignment, the assignment_participants method was added.
** For including a user in the assignment as a participant, the add_participant method was added.
** To see if the team has gotten any peer reviews, the received_any_peer_review? method was put into practice.
** Using a placeholder for future mentor assignment logic, the upgrade_to_mentored_team method was put into practice to replicate the present team and get it ready for mentoring.
** In order to ensure deep duplication of associated records (such as signed_up_teams, teams_users, and participants), the dup method was added to duplicate a team and its associations.

* Team Model:
** Improved the whole procedure to determine if a team has reached its maximum number of members.
** Counted the number of team members using the size approach, removing those with "(Mentor)" in their names.
** In order to eliminate duplicate members and check for team capacity, the add_member method was improved.
** To remove a user from the team, the remove_team_user method was put into place. If the team becomes empty and hasn't been subjected to any peer reviews, the team will be deleted.

* Controller - StudentTeamsController.rb
** index: Implemented in order to retrieve and restore every student team together with all of its members.
** show: Created to retrieve and provide information about a certain student team and its members.
** create: Added logic to create a new team for a student, using AssignmentTeam#upgraded_to_mentored_team for mentor-eligible teams and checking for existing team names.
** update: Implemented to enable team details, especially the team name, to be updated while ensuring unique team names through validations.
** destroy: To remove a certain team this was added and, if successful, deliver a 204 No Content response.
** remove_participant: Check if the user is part of the given team and removes from that team, also handles corner cases where no more participants are there in a team.
** add_participant: Added this to add the given participant to respective team.

===Testing Plan===

We have performed comprehensive testing of the student_teams_controller.rb and related classes using RSPEC and Swagger to construct the required test fixtures for testing extensive scenarios. Our approach involves reimplementing the existing test cases provided to the older code base and make sure that it is enhanced by covering more test scenarios to minimize code smells. We aim to verify the reimplemented functionality, validate the restructured code in the student_teams_controller.rb and reduce any design or code smell.
Below are the test scenarios for each of API endpoints -

1. List all Student Teams

*Description: List all student teams.
*Response: 200 OK
*Test Case Scenarios:
*Scenario 1: List all Student Teams
*Expectation: Successfully retrieves a list of all student teams. The response status is 200, the content type is `application/json`, and the response body contains 3 student teams.

RSpec.describe 'Student Teams API', type: :request do
path '/api/v1/student_teams' do
# List all Student Teams
get('List all Student Teams') do
tags 'Student Teams'
produces 'application/json'
security [Bearer: {}]
response(200, 'successful') do
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test!
end
end
*Postman Screenshot
[[File:Akoul2Index.jpg]]

2. Create a Student Team
*Description: Create a new student team.
*Response: 201 Created
*Test Data prep:
post 'Create a Student Team' do
tags 'Student Teams'
consumes 'application/json'
let(:institution) do
Institution.create!(
name: 'North Carolina State University'
)
end
let!(:instructor_role) { Role.find_or_create_by(name: 'Instructor') }
let!(:student_role) { Role.find_or_create_by(name: 'Student') }
let(:instructor_user) do
User.create!(
name: 'Dr. Ed Gehringer1',
email: 'gehringer@example.com',
password: 'password123',
full_name: 'admin admin',
institution_id: institution.id,
role_id: instructor_role.id,
handle: 'instructor'
)
end
let(:course) do
Course.create!(
name: '2476. Refactor',
directory_path: '/',
info: 'OODD',
private: false,
instructor_id: instructor_user.id,
institution_id: institution.id
)
end
let(:assignment) do
Assignment.create!(
title: 'Project 4 BRO',
description: '2476. Reimplementing',
course_id: course.id,
instructor_id: instructor_user.id
)
end
let!(:students) do
created_students = []
3.times do |i|
student = User.create!(
name: "Student #{i + 1}",
email: "Student#{i + 1}@gmail.com",
password: 'password123',
full_name: "Student #{i + 1}",
institution_id: institution.id,
role_id: student_role.id,
handle: "Student #{i + 1}"
)
AssignmentParticipant.create!(
assignment: assignment,
user: student,
handle: "Student #{i + 1}"
)
created_students << student
end
created_students
end
parameter name: :student_team_request, in: :body, schema: {
type: :object,
properties: {
team: {
type: :object,
properties: {
name: {type: :string}
}
},
student_id: { type: :integer}
}
}
security [Bearer: {}]
*Scenarios:
*Scenario 1: Successfully create a team
*Expectation: Successfully creates a new student team with a valid name and student ID. The response status is 201, and the response body includes the team name.
*Scenario 2: Team name is already in use (conflict)
*Attempts to create a student team with a name that is already in use.
*Expectation: The response status is 422, and the response body includes an error message indicating that the team name is already in use.
*Scenario 3: Invalid team creation (empty name)
*Expectation: Attempts to create a student team with an empty string name. The response status is 201, with team name autogenerated.

# Scenario 1: Successfully create a team
response(201, 'created') do
let(:student_team_request) do
{ team: {name: "HelloThere"}, student_id: students.first.id}
end
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test! do
expect(response.status).to eq(201)
end
end
# Scenario 2: Team name is already in use (conflict)
response(422, 'unprocessable entity') do
let(:existing_team) { create(:team, name: 'ABCD10', assignment_id: assignment.id) }
let(:team) do
post '/api/v1/student_teams', params: { team: { name: 'ABCD10' }, student_id: students.first.id }, as: :json
end
run_test! do
expect(response.status).to eq(422)
expect(response.body).to include('"error":"That team name is already in use."')
end
end
# Scenario 3: Invalid team creation (empty name)
response(422, 'unprocessable entity') do
let(:student_team_request) do
{ team: {name: ""}, student_id: students.first.id}
end
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test! do
expect(response.status).to eq(422)
expect(response.body).to include('error')
end
end
response(404, 'not_found') do
let(:team) do
post '/api/v1/student_teams', params: { team: { name: 'ABCD10' }, student_id: 0 }, as: :json
end
run_test! do
expect(response.status).to eq(404)
expect(response.body).to include('not found')
end
end
end
*Postman
Scenario 1:
[[File:Akoul2Create.jpg]]
Scenario 2:
[[File:Akoul2Create2.jpg]]
Scenario 3:
[[File:Akoul2Create3.jpg]]
3. Update a Student Team
*Description: Update the details of a student team.
*Response: 200 OK
*Scenarios:
*Scenario 1: Team name updated successfully
*Expectation: Successfully updates the name of a student team. The response status is 200, and the response body includes the updated team name.
*Scenario 2: Invalid team update (empty name)
*Expectation: Attempts to update a student team with an empty name. The response status is 422, and the response body includes an error message indicating that the team name should not be empty.
*Scenario 3: Team name already in use
*Expectation: Attempts to update a student team with a name that is already in use. The response status is 422, and the response body includes an error message indicating that the team name is already in use.
*Scenario 4: Invalid team ID
*Expectation: Attempts to update a student team with a non-existent team ID. The response status is 404, and the response body includes an error message indicating that the team was not found.

patch('Update a Student Team') do
tags 'Student Teams'
consumes 'application/json'
produces 'application/json'
security [Bearer: {}]
parameter name: :student_team_request, in: :body, schema: {
type: :object,
properties: {
team: {
type: :object,
properties: {
name: {type: :string}
}
},
team_id: { type: :integer}
}
}
# Scenario 1: Team name updated successfully
response(200, 'successful') do
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test! do
expect(response.status).to eq(200)
end
end
# Scenario 2: Invalid team updation (empty name)
response(422, 'unprocessable entity') do
let(:student_team_request) do
{ team: {name: ""}, team_id: 2}
end
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test! do
expect(response.status).to eq(422)
expect(response.body).to include('Team name should not be empty')
end
end
# Scenario 3: Team Name already present
response(422, 'unprocessable entity') do
let(:existing_team) { create(:team, name: 'ABCD10', team_id: 3) }
let(:team) do
post '/api/v1/student_teams', params: { team: { name: 'ABCD10' }, team_id: 2 }, as: :json
end
run_test! do
expect(response.status).to eq(422)
expect(response.body).to include('"error":"That team name is already in use."')
end
end
#Scenario 4 : Invalid Team ID
response(404, 'not_found') do
let(:team) do
post '/api/v1/student_teams', params: { team: { name: 'ABCD10' }, team_id: 0 }, as: :json
end
run_test! do
expect(response.status).to eq(404)
expect(response.body).to include('not found')
end
end
end
end

4. Show a Student Team
*Description: Retrieve the details of a student team by its ID.
*Response: 200 OK
*Scenarios:
*Scenario 1: Show Student Team
*Expectation: Successfully retrieves the details of a student team by its ID. The response status is 200, and the response body includes the details of the student team.
*Scenario 2: Team not found
*Expectation: Attempts to retrieve the details of a student team with an invalid ID. The response status is 404, and the response body includes an error message indicating that the team was not found.
path '/api/v1/student_teams/{id}' do
parameter name: 'id', in: :path, type: :integer
# Get request on /api/v1/student_teams/{id} returns the response 200 succesful - when correct id passed is present in the database
get('Show a Student Team') do
tags 'Student Teams'
produces 'application/json'
security [Bearer: {}]
response(200, 'successful') do
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test! do
expect(response.status).to eq(200)
end
end
# Get request on /api/v1/student_teams/{id} returns the response 404 not found - when correct id passed is not present in the database
response(404, 'not_found') do
let(:id) { 'invalid' }
run_test! do
expect(response.status).to eq(404)
end
end
end

*Postman:
**Scenario 1:
[[File:Akoul2Show.jpg]]
**Scenario 2:
[[File:Akoul2Show not.jpg]]

5. Delete a Student Team
*Description: Delete a student team by its ID.
*Response: 204 No Content
*Scenarios:
*Scenario 1: Successfully delete a student team
*Expectation: Successfully deletes a student team by its ID. The response status is 204, and the student team is no longer present in the database.
*Scenario 2: Team not found
*Expectation: Attempts to delete a student team with an invalid ID. The response status is 404, and the response body includes an error message indicating that the team was not found.

delete('Delete a Student Team') do
tags 'Student Teams'
produces 'application/json'
security [Bearer: {}]
# delete request on /api/v1/student_teams/{id} returns 204 succesful response when id present in the database is deleted successfully
response(204, 'successful') do
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: ''
}
}
end
run_test! do
expect(response.status).to eq(204)
end
end
# delete request on /api/v1/student_teams/{id} returns 404 not found response, when id is not present in the database
response(404, 'not found') do
let(:id) { 0 }
run_test! do
expect(response.status).to eq(404)
end
end
end
end

6. Add a Participant in Student Team
*Description: Add a participant to a student team.
*Response: 200 OK
*Test Data Prep
path '/api/v1/student_teams/{id}/add_participant' do
parameter name: 'id', in: :path, type: :integer, description: 'ID of Team'
parameter name: 'student_id', in: :query, type: :integer, description: 'ID of the Student'
let(:student) { create(:user, :student) }
let(:assignment) { create(:assignment) }
let(:student_participant) { create(:assignment_participant, user: student, assignment: assignment) }
let(:team) { create(:assignment_team, assignment: assignment) }
let(:id) { team.id }
let(:student_id) { student.id }
*Scenarios:
*Scenario 1: Successfully add a participant to a student team
*Expectation: Successfully adds a participant to a student team by their ID. The response status is 200, and the participant is added to the team.
patch('Add a participant to Student Team') do
tags 'Student Teams'
consumes 'application/json'
produces 'application/json'
security [Bearer: {}]
before do
team.add_member(student, assignment.id)
end
response(200, 'successful') do
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test!
end
end
end
*Postman:
[[File:Akoul2Add participant.jpg]]
7. Remove a Participant in Student Team
*Description: Remove a participant from a student team.
*Response: 204 No Content
*Test data prep:

path '/api/v1/student_teams/{id}/remove_participant' do
parameter name: 'id', in: :path, type: :integer, description: 'ID of Team'
parameter name: 'student_id', in: :query, type: :integer, description: 'ID of the Student'
let(:student) { create(:user, :student) }
let(:assignment) { create(:assignment) }
let(:student_participant) { create(:assignment_participant, user: student, assignment: assignment) }
let(:team) { create(:assignment_team, assignment: assignment) }
let(:id) { team.id }
let(:student_id) { student.id }
before do
team.add_member(student, assignment.id)
end
*Scenarios:
*Scenario 1: Successfully remove a participant from a student team
*Expectation: Successfully removes a participant from a student team by their ID. The response status is 204, and the participant is no longer a member of the team.
*Scenario 2: Team not found
*Expectation: Attempts to remove a participant from a student team with an invalid team ID. The response status is 404, and the response body includes an error message indicating that the team was not found.
*Scenario 3: User not found
*Expectation: Attempts to remove a participant from a student team with an invalid user ID. The response status is 404, and the response body includes an error message indicating that the user was not found.

delete('remove participant') do
tags 'Student Teams'
produces 'application/json'
security [Bearer: {}]
response(204, 'successful') do
let(:Authorization) { "Bearer #{@token}" }
run_test! do
expect(response.status).to eq(204)
expect(team.members).not_to include(student)
end
end
response(404, 'team not found') do
let(:id) { -1 } # Invalid ID
run_test! do
expect(response.status).to eq(404)
expect(JSON.parse(response.body)['error']).to eq('Team not found.')
end
end
response(404, 'user not found') do
let(:student_id) { -1 } # Invalid student ID
run_test! do
expect(response.status).to eq(404)
expect(JSON.parse(response.body)['error']).to eq('User not found.')
end
end
end
end

===GitHub Pull Request===

https://github.com/expertiza/reimplementation-back-end/pull/136

===Demo Video===

https://www.youtube.com/watch?v=8_d_Y9EcgHc

===Mentor===

* Ammana, Sahithi <sammana@ncsu.edu>

===Team Members===

* Eathamukkala, Akarsh Reddy <aeatham@ncsu.edu>
* Koul, Anmol <akoul2@ncsu.edu>
* More, Harsh Manoj <hmore@ncsu.edu>

File:Akoul2Create3.jpg

2024-12-04T05:21:24Z

Akoul2:

File:Akoul2Create2.jpg

2024-12-04T05:21:00Z

Akoul2:

File:Akoul2Create.jpg

2024-12-04T05:20:49Z

Akoul2:

CSC/ECE 517 Fall 2024 - E2476. Reimplement student teams controller.rb

2024-12-04T05:17:49Z

Akoul2: /* Testing Plan */

===Introduction===
[http://expertiza.ncsu.edu/ Expertiza] is an open-source system built on [http://rubyonrails.org/ Ruby on Rails], collaboratively maintained by students and faculty at NC State. This platform gives instructors extensive control over assignments, enabling them to add topics, create assignment groups, and manage peer reviews for various types of coursework. Expertiza is well-equipped to handle submissions across multiple formats, including URLs and wiki pages, and it offers a peer review system that facilitates constructive feedback among students.

A key focus of recent development in Expertiza has been the shift to a client-server architecture, where Ruby on Rails functions as the backend and React is utilized for the frontend. This architectural update requires reworking existing modules into RESTful API endpoints, allowing React components to interact efficiently with the backend. By adopting this approach, Expertiza aims to enhance modularity, performance, and scalability.

===Project Description===

The project mainly focuses on reimplementing the StudentTeamsController in Expertiza's backend, which is designed for student-facing operations where students participate in teams. This includes actions that directly affect individual team members, such as adding or removing students from teams, viewing team details, and managing their participation.

The TeamsController, on the other hand, is focused on instructor-driven operations that handle high-level team management across different contexts, such as courses and assignments. It manages operations like team creation, deletion, randomization, and bulk management actions.

===Problem Statement===

The current implementation of the StudentTeamsController in the Expertiza system is overly complex and tightly coupled, leading to difficulties in maintaining and extending the codebase. The controller is responsible for managing student teams in assignments, handling tasks like team creation, editing, management, and the integration of topics in assignments that require team-based decisions. However, it suffers from issues such as:
* Code redundancy and inefficiency due to business logic being embedded directly in the controller.
* Lack of modularity and poor separation of concerns, violating the Single Responsibility Principle (SRP). For example, it also handles the integration with topics when assignments involve choosing topics, complicating the team’s logic.
* Difficult-to-understand methods and tightly coupled logic for handling assignment-specific conditions, such as team-topic associations.
* Poor user feedback that does not provide clear or actionable information after critical operations.

These problems create a system that is hard to scale, maintain, and extend, especially as new features are added. To address these challenges, the goal is to reimplement the StudentTeamsController in the newer Expertiza backend codebase by adhering to object-oriented design principles, specifically focusing on maintainability, scalability, and modularity. The new design will improve the user experience by simplifying controller logic, providing clearer feedback, and ensuring that the system is easier to extend and maintain in the future.

===Objectives===

The main objective is to migrate the Student Task controller logic from serving HTML responses in the Ruby on Rails MVC model to returning JSON responses as a RESTful API, as part of the backend implementation. While reimplementing the controller, the following considerations will be incorporated to ensure a clean, maintainable, and scalable API:

*Reimplement the controller logic and write methods which appropriately follow the Single Responsibility Principle (SRP).
*Move business logic from the controller to appropriate model classes like Team or AssignmentTeam.
*Ensure all method names clearly describe their purpose and represent actions.
*Reimplement a Prototype pattern for creating mentored teams, leveraging the AssignmentTeam class.
*Automatically generate team names when a team is first referred to unless the user has specified a name when requesting team creation.
*Handle team requirements with better abstraction:
*Try to eliminate direct logic in the controller that checks for specific assignment requirements such as topic handling.
*Rename student_team_requirements_met? to something more descriptive and break it into smaller methods checking individual conditions.
*Aim to decouple topics from this controller entirely, ensuring better abstraction, that can involve changes to other classes or introducing service objects to handle specific requirements.
* Improve feedback to users and ensure that the user receives clear and actionable feedback after operations like team creation, removal of users, and other key actions.
* Add comprehensive comments throughout the controller, clearly explaining the purpose and functionality of custom methods.

===Development Strategy===

Our development strategy centers around Test-Driven Development (TDD) principles applied to refactoring the student_teams_controller.rb and other related classes such as Team or AssignmentTeam model. We design out test cases and iteratively refactor code to address identified inefficiencies while ensuring successful test outcomes.
Additionally, we emphasize on the strict adoption of SRP and DRY principles as per the object-oriented programming conventions. Our goal is to reimplement the existing functionalities
In the newly designed back-end foundation to foster a more efficient and organized codebase utilizing newer technologies. This approach will significantly enhance reusability and scalability across all the application while maintaining clean codebase.

Files Modified:
* Created ==>
** app/controllers/api/v1/student_teams_controller.rb
** app/models/assignment_team.rb
** app/models/team.rb
** spec/requests/api/v1/student_teams_controller_spec.rb
** db/migrate/20241201203840_create_assignment_teams.rb
** db/migrate/20241201220020_add_auto_assign_mentor_to_assignments.rb
** db/migrate/20241201221122_add_type_to_teams.rb
** db/migrate/20241202002102_add_name_to_teams.rb

* Updated ==>
** app/models/team.rb
** config/routes.rb
** db/schema.rb
** db/seeds.rb
** spec/swagger_helper.rb

===Project Design and Implementation===

The main approach to be followed throughout this project is to embrace the Prototyping Pattern within the controller while taking into account the current functionalities to be reimplemented within the student_teams_controller.rb that can capitalize its capability to encapsulate distinct controller actions. This strategic implementation aims to ensure seamless extensibility and enhanced usability. By employing this pattern, we establish a structured framework for defining and managing the diverse operations the controller handles, promoting a more organized and manageable code structure.

[[File:2476_UML.drawio.png]]

==== Functionality ====

1. Reimplement the Controller to Follow SRP:
* Break down large, complex methods into smaller, focused methods that adhere to the Single Responsibility Principle (SRP).
* Reimplement existing methods and logic while ensuring that each class and method have a clear, well-defined responsibility.
* Move business logic and complex operations out of the controller and into the appropriate model classes (e.g., Team, AssignmentTeam), ensuring the controller only handles HTTP-specific concerns (e.g., request handling, responses).

2. Improve Method Naming and Clarity:
* Ensure all method names are descriptive and represent the intent of the operation (e.g., renaming methods like student_team_requirements_met? to something more specific like validate_topic_requirements_for_team_creation).
* Adopt consistent naming conventions to improve the readability of the codebase.

3. Implement the Prototype Pattern for Team Creation:
* Leverage the Prototype pattern to create mentored teams through the AssignmentTeam class, allowing for easier management and creation of teams with a mentored structure.
* Automatically generate team names when a team is first created, unless a user has specified a custom name to improve the user experience and simplify team management.

4. Abstract Assignment-Specific Logic:
* Move logic related to assignment-specific requirements (e.g., topic handling) away from the controller, reducing complexity and increasing modularity.
* Introduce service objects or model methods to handle specific requirements like topic assignment, thereby decoupling assignment-related logic from the controller.
* Break down the student_team_requirements_met? method into smaller, more specific checks for different requirements (e.g., topic validation, minimum team size, etc.).

5. Improve User Feedback:
* Enhance the clarity and actionability of feedback messages after key operations (e.g., team creation, user removal, etc.).
* Provide users with clear, helpful notifications on the success or failure of their actions, including any necessary next steps or troubleshooting guidance.
* Ensure error handling is robust, and feedback is specific (e.g., specify which conditions were not met when creating or modifying teams).

6. Commenting and Documentation:
* Add comprehensive comments throughout the controller to clearly explain the purpose and functionality of custom methods and refactored logic.
* Ensure that code is well-documented, making it easier for future developers to understand and extend the functionality of the controller.

===Tasks Completed===

Methods:
* AssignmentTeam Model:
** To access every participant connected to an assignment, the assignment_participants method was added.
** For including a user in the assignment as a participant, the add_participant method was added.
** To see if the team has gotten any peer reviews, the received_any_peer_review? method was put into practice.
** Using a placeholder for future mentor assignment logic, the upgrade_to_mentored_team method was put into practice to replicate the present team and get it ready for mentoring.
** In order to ensure deep duplication of associated records (such as signed_up_teams, teams_users, and participants), the dup method was added to duplicate a team and its associations.

* Team Model:
** Improved the whole procedure to determine if a team has reached its maximum number of members.
** Counted the number of team members using the size approach, removing those with "(Mentor)" in their names.
** In order to eliminate duplicate members and check for team capacity, the add_member method was improved.
** To remove a user from the team, the remove_team_user method was put into place. If the team becomes empty and hasn't been subjected to any peer reviews, the team will be deleted.

* Controller - StudentTeamsController.rb
** index: Implemented in order to retrieve and restore every student team together with all of its members.
** show: Created to retrieve and provide information about a certain student team and its members.
** create: Added logic to create a new team for a student, using AssignmentTeam#upgraded_to_mentored_team for mentor-eligible teams and checking for existing team names.
** update: Implemented to enable team details, especially the team name, to be updated while ensuring unique team names through validations.
** destroy: To remove a certain team this was added and, if successful, deliver a 204 No Content response.
** remove_participant: Check if the user is part of the given team and removes from that team, also handles corner cases where no more participants are there in a team.
** add_participant: Added this to add the given participant to respective team.

===Testing Plan===

We have performed comprehensive testing of the student_teams_controller.rb and related classes using RSPEC and Swagger to construct the required test fixtures for testing extensive scenarios. Our approach involves reimplementing the existing test cases provided to the older code base and make sure that it is enhanced by covering more test scenarios to minimize code smells. We aim to verify the reimplemented functionality, validate the restructured code in the student_teams_controller.rb and reduce any design or code smell.
Below are the test scenarios for each of API endpoints -

1. List all Student Teams

*Description: List all student teams.
*Response: 200 OK
*Test Case Scenarios:
*Scenario 1: List all Student Teams
*Expectation: Successfully retrieves a list of all student teams. The response status is 200, the content type is `application/json`, and the response body contains 3 student teams.

RSpec.describe 'Student Teams API', type: :request do
path '/api/v1/student_teams' do
# List all Student Teams
get('List all Student Teams') do
tags 'Student Teams'
produces 'application/json'
security [Bearer: {}]
response(200, 'successful') do
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test!
end
end
*Postman Screenshot
[[File:Akoul2Index.jpg]]

2. Create a Student Team
*Description: Create a new student team.
*Response: 201 Created
*Test Data prep:
post 'Create a Student Team' do
tags 'Student Teams'
consumes 'application/json'
let(:institution) do
Institution.create!(
name: 'North Carolina State University'
)
end
let!(:instructor_role) { Role.find_or_create_by(name: 'Instructor') }
let!(:student_role) { Role.find_or_create_by(name: 'Student') }
let(:instructor_user) do
User.create!(
name: 'Dr. Ed Gehringer1',
email: 'gehringer@example.com',
password: 'password123',
full_name: 'admin admin',
institution_id: institution.id,
role_id: instructor_role.id,
handle: 'instructor'
)
end
let(:course) do
Course.create!(
name: '2476. Refactor',
directory_path: '/',
info: 'OODD',
private: false,
instructor_id: instructor_user.id,
institution_id: institution.id
)
end
let(:assignment) do
Assignment.create!(
title: 'Project 4 BRO',
description: '2476. Reimplementing',
course_id: course.id,
instructor_id: instructor_user.id
)
end
let!(:students) do
created_students = []
3.times do |i|
student = User.create!(
name: "Student #{i + 1}",
email: "Student#{i + 1}@gmail.com",
password: 'password123',
full_name: "Student #{i + 1}",
institution_id: institution.id,
role_id: student_role.id,
handle: "Student #{i + 1}"
)
AssignmentParticipant.create!(
assignment: assignment,
user: student,
handle: "Student #{i + 1}"
)
created_students << student
end
created_students
end
parameter name: :student_team_request, in: :body, schema: {
type: :object,
properties: {
team: {
type: :object,
properties: {
name: {type: :string}
}
},
student_id: { type: :integer}
}
}
security [Bearer: {}]
*Scenarios:
*Scenario 1: Successfully create a team
*Expectation: Successfully creates a new student team with a valid name and student ID. The response status is 201, and the response body includes the team name.
*Scenario 2: Team name is already in use (conflict)
*Attempts to create a student team with a name that is already in use.
*Expectation: The response status is 422, and the response body includes an error message indicating that the team name is already in use.
*Scenario 3: Invalid team creation (empty name)
*Expectation: Attempts to create a student team with an empty name. The response status is 422, and the response body includes an error message.

# Scenario 1: Successfully create a team
response(201, 'created') do
let(:student_team_request) do
{ team: {name: "HelloThere"}, student_id: students.first.id}
end
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test! do
expect(response.status).to eq(201)
end
end
# Scenario 2: Team name is already in use (conflict)
response(422, 'unprocessable entity') do
let(:existing_team) { create(:team, name: 'ABCD10', assignment_id: assignment.id) }
let(:team) do
post '/api/v1/student_teams', params: { team: { name: 'ABCD10' }, student_id: students.first.id }, as: :json
end
run_test! do
expect(response.status).to eq(422)
expect(response.body).to include('"error":"That team name is already in use."')
end
end
# Scenario 3: Invalid team creation (empty name)
response(422, 'unprocessable entity') do
let(:student_team_request) do
{ team: {name: ""}, student_id: students.first.id}
end
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test! do
expect(response.status).to eq(422)
expect(response.body).to include('error')
end
end
response(404, 'not_found') do
let(:team) do
post '/api/v1/student_teams', params: { team: { name: 'ABCD10' }, student_id: 0 }, as: :json
end
run_test! do
expect(response.status).to eq(404)
expect(response.body).to include('not found')
end
end
end

3. Update a Student Team
*Description: Update the details of a student team.
*Response: 200 OK
*Scenarios:
*Scenario 1: Team name updated successfully
*Expectation: Successfully updates the name of a student team. The response status is 200, and the response body includes the updated team name.
*Scenario 2: Invalid team update (empty name)
*Expectation: Attempts to update a student team with an empty name. The response status is 422, and the response body includes an error message indicating that the team name should not be empty.
*Scenario 3: Team name already in use
*Expectation: Attempts to update a student team with a name that is already in use. The response status is 422, and the response body includes an error message indicating that the team name is already in use.
*Scenario 4: Invalid team ID
*Expectation: Attempts to update a student team with a non-existent team ID. The response status is 404, and the response body includes an error message indicating that the team was not found.

patch('Update a Student Team') do
tags 'Student Teams'
consumes 'application/json'
produces 'application/json'
security [Bearer: {}]
parameter name: :student_team_request, in: :body, schema: {
type: :object,
properties: {
team: {
type: :object,
properties: {
name: {type: :string}
}
},
team_id: { type: :integer}
}
}
# Scenario 1: Team name updated successfully
response(200, 'successful') do
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test! do
expect(response.status).to eq(200)
end
end
# Scenario 2: Invalid team updation (empty name)
response(422, 'unprocessable entity') do
let(:student_team_request) do
{ team: {name: ""}, team_id: 2}
end
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test! do
expect(response.status).to eq(422)
expect(response.body).to include('Team name should not be empty')
end
end
# Scenario 3: Team Name already present
response(422, 'unprocessable entity') do
let(:existing_team) { create(:team, name: 'ABCD10', team_id: 3) }
let(:team) do
post '/api/v1/student_teams', params: { team: { name: 'ABCD10' }, team_id: 2 }, as: :json
end
run_test! do
expect(response.status).to eq(422)
expect(response.body).to include('"error":"That team name is already in use."')
end
end
#Scenario 4 : Invalid Team ID
response(404, 'not_found') do
let(:team) do
post '/api/v1/student_teams', params: { team: { name: 'ABCD10' }, team_id: 0 }, as: :json
end
run_test! do
expect(response.status).to eq(404)
expect(response.body).to include('not found')
end
end
end
end

4. Show a Student Team
*Description: Retrieve the details of a student team by its ID.
*Response: 200 OK
*Scenarios:
*Scenario 1: Show Student Team
*Expectation: Successfully retrieves the details of a student team by its ID. The response status is 200, and the response body includes the details of the student team.
*Scenario 2: Team not found
*Expectation: Attempts to retrieve the details of a student team with an invalid ID. The response status is 404, and the response body includes an error message indicating that the team was not found.
path '/api/v1/student_teams/{id}' do
parameter name: 'id', in: :path, type: :integer
# Get request on /api/v1/student_teams/{id} returns the response 200 succesful - when correct id passed is present in the database
get('Show a Student Team') do
tags 'Student Teams'
produces 'application/json'
security [Bearer: {}]
response(200, 'successful') do
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test! do
expect(response.status).to eq(200)
end
end
# Get request on /api/v1/student_teams/{id} returns the response 404 not found - when correct id passed is not present in the database
response(404, 'not_found') do
let(:id) { 'invalid' }
run_test! do
expect(response.status).to eq(404)
end
end
end

*Postman:
**Scenario 1:
[[File:Akoul2Show.jpg]]
**Scenario 2:
[[File:Akoul2Show not.jpg]]

5. Delete a Student Team
*Description: Delete a student team by its ID.
*Response: 204 No Content
*Scenarios:
*Scenario 1: Successfully delete a student team
*Expectation: Successfully deletes a student team by its ID. The response status is 204, and the student team is no longer present in the database.
*Scenario 2: Team not found
*Expectation: Attempts to delete a student team with an invalid ID. The response status is 404, and the response body includes an error message indicating that the team was not found.

delete('Delete a Student Team') do
tags 'Student Teams'
produces 'application/json'
security [Bearer: {}]
# delete request on /api/v1/student_teams/{id} returns 204 succesful response when id present in the database is deleted successfully
response(204, 'successful') do
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: ''
}
}
end
run_test! do
expect(response.status).to eq(204)
end
end
# delete request on /api/v1/student_teams/{id} returns 404 not found response, when id is not present in the database
response(404, 'not found') do
let(:id) { 0 }
run_test! do
expect(response.status).to eq(404)
end
end
end
end

6. Add a Participant in Student Team
*Description: Add a participant to a student team.
*Response: 200 OK
*Test Data Prep
path '/api/v1/student_teams/{id}/add_participant' do
parameter name: 'id', in: :path, type: :integer, description: 'ID of Team'
parameter name: 'student_id', in: :query, type: :integer, description: 'ID of the Student'
let(:student) { create(:user, :student) }
let(:assignment) { create(:assignment) }
let(:student_participant) { create(:assignment_participant, user: student, assignment: assignment) }
let(:team) { create(:assignment_team, assignment: assignment) }
let(:id) { team.id }
let(:student_id) { student.id }
*Scenarios:
*Scenario 1: Successfully add a participant to a student team
*Expectation: Successfully adds a participant to a student team by their ID. The response status is 200, and the participant is added to the team.
patch('Add a participant to Student Team') do
tags 'Student Teams'
consumes 'application/json'
produces 'application/json'
security [Bearer: {}]
before do
team.add_member(student, assignment.id)
end
response(200, 'successful') do
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test!
end
end
end
*Postman:
[[File:Akoul2Add participant.jpg]]
7. Remove a Participant in Student Team
*Description: Remove a participant from a student team.
*Response: 204 No Content
*Test data prep:

path '/api/v1/student_teams/{id}/remove_participant' do
parameter name: 'id', in: :path, type: :integer, description: 'ID of Team'
parameter name: 'student_id', in: :query, type: :integer, description: 'ID of the Student'
let(:student) { create(:user, :student) }
let(:assignment) { create(:assignment) }
let(:student_participant) { create(:assignment_participant, user: student, assignment: assignment) }
let(:team) { create(:assignment_team, assignment: assignment) }
let(:id) { team.id }
let(:student_id) { student.id }
before do
team.add_member(student, assignment.id)
end
*Scenarios:
*Scenario 1: Successfully remove a participant from a student team
*Expectation: Successfully removes a participant from a student team by their ID. The response status is 204, and the participant is no longer a member of the team.
*Scenario 2: Team not found
*Expectation: Attempts to remove a participant from a student team with an invalid team ID. The response status is 404, and the response body includes an error message indicating that the team was not found.
*Scenario 3: User not found
*Expectation: Attempts to remove a participant from a student team with an invalid user ID. The response status is 404, and the response body includes an error message indicating that the user was not found.

delete('remove participant') do
tags 'Student Teams'
produces 'application/json'
security [Bearer: {}]
response(204, 'successful') do
let(:Authorization) { "Bearer #{@token}" }
run_test! do
expect(response.status).to eq(204)
expect(team.members).not_to include(student)
end
end
response(404, 'team not found') do
let(:id) { -1 } # Invalid ID
run_test! do
expect(response.status).to eq(404)
expect(JSON.parse(response.body)['error']).to eq('Team not found.')
end
end
response(404, 'user not found') do
let(:student_id) { -1 } # Invalid student ID
run_test! do
expect(response.status).to eq(404)
expect(JSON.parse(response.body)['error']).to eq('User not found.')
end
end
end
end

===GitHub Pull Request===

https://github.com/expertiza/reimplementation-back-end/pull/136

===Demo Video===

https://www.youtube.com/watch?v=8_d_Y9EcgHc

===Mentor===

* Ammana, Sahithi <sammana@ncsu.edu>

===Team Members===

* Eathamukkala, Akarsh Reddy <aeatham@ncsu.edu>
* Koul, Anmol <akoul2@ncsu.edu>
* More, Harsh Manoj <hmore@ncsu.edu>

File:Akoul2Add participant.jpg

2024-12-04T05:17:41Z

Akoul2:

CSC/ECE 517 Fall 2024 - E2476. Reimplement student teams controller.rb

2024-12-04T05:12:09Z

Akoul2: /* Testing Plan */

===Introduction===
[http://expertiza.ncsu.edu/ Expertiza] is an open-source system built on [http://rubyonrails.org/ Ruby on Rails], collaboratively maintained by students and faculty at NC State. This platform gives instructors extensive control over assignments, enabling them to add topics, create assignment groups, and manage peer reviews for various types of coursework. Expertiza is well-equipped to handle submissions across multiple formats, including URLs and wiki pages, and it offers a peer review system that facilitates constructive feedback among students.

A key focus of recent development in Expertiza has been the shift to a client-server architecture, where Ruby on Rails functions as the backend and React is utilized for the frontend. This architectural update requires reworking existing modules into RESTful API endpoints, allowing React components to interact efficiently with the backend. By adopting this approach, Expertiza aims to enhance modularity, performance, and scalability.

===Project Description===

The project mainly focuses on reimplementing the StudentTeamsController in Expertiza's backend, which is designed for student-facing operations where students participate in teams. This includes actions that directly affect individual team members, such as adding or removing students from teams, viewing team details, and managing their participation.

The TeamsController, on the other hand, is focused on instructor-driven operations that handle high-level team management across different contexts, such as courses and assignments. It manages operations like team creation, deletion, randomization, and bulk management actions.

===Problem Statement===

The current implementation of the StudentTeamsController in the Expertiza system is overly complex and tightly coupled, leading to difficulties in maintaining and extending the codebase. The controller is responsible for managing student teams in assignments, handling tasks like team creation, editing, management, and the integration of topics in assignments that require team-based decisions. However, it suffers from issues such as:
* Code redundancy and inefficiency due to business logic being embedded directly in the controller.
* Lack of modularity and poor separation of concerns, violating the Single Responsibility Principle (SRP). For example, it also handles the integration with topics when assignments involve choosing topics, complicating the team’s logic.
* Difficult-to-understand methods and tightly coupled logic for handling assignment-specific conditions, such as team-topic associations.
* Poor user feedback that does not provide clear or actionable information after critical operations.

These problems create a system that is hard to scale, maintain, and extend, especially as new features are added. To address these challenges, the goal is to reimplement the StudentTeamsController in the newer Expertiza backend codebase by adhering to object-oriented design principles, specifically focusing on maintainability, scalability, and modularity. The new design will improve the user experience by simplifying controller logic, providing clearer feedback, and ensuring that the system is easier to extend and maintain in the future.

===Objectives===

The main objective is to migrate the Student Task controller logic from serving HTML responses in the Ruby on Rails MVC model to returning JSON responses as a RESTful API, as part of the backend implementation. While reimplementing the controller, the following considerations will be incorporated to ensure a clean, maintainable, and scalable API:

*Reimplement the controller logic and write methods which appropriately follow the Single Responsibility Principle (SRP).
*Move business logic from the controller to appropriate model classes like Team or AssignmentTeam.
*Ensure all method names clearly describe their purpose and represent actions.
*Reimplement a Prototype pattern for creating mentored teams, leveraging the AssignmentTeam class.
*Automatically generate team names when a team is first referred to unless the user has specified a name when requesting team creation.
*Handle team requirements with better abstraction:
*Try to eliminate direct logic in the controller that checks for specific assignment requirements such as topic handling.
*Rename student_team_requirements_met? to something more descriptive and break it into smaller methods checking individual conditions.
*Aim to decouple topics from this controller entirely, ensuring better abstraction, that can involve changes to other classes or introducing service objects to handle specific requirements.
* Improve feedback to users and ensure that the user receives clear and actionable feedback after operations like team creation, removal of users, and other key actions.
* Add comprehensive comments throughout the controller, clearly explaining the purpose and functionality of custom methods.

===Development Strategy===

Our development strategy centers around Test-Driven Development (TDD) principles applied to refactoring the student_teams_controller.rb and other related classes such as Team or AssignmentTeam model. We design out test cases and iteratively refactor code to address identified inefficiencies while ensuring successful test outcomes.
Additionally, we emphasize on the strict adoption of SRP and DRY principles as per the object-oriented programming conventions. Our goal is to reimplement the existing functionalities
In the newly designed back-end foundation to foster a more efficient and organized codebase utilizing newer technologies. This approach will significantly enhance reusability and scalability across all the application while maintaining clean codebase.

Files Modified:
* Created ==>
** app/controllers/api/v1/student_teams_controller.rb
** app/models/assignment_team.rb
** app/models/team.rb
** spec/requests/api/v1/student_teams_controller_spec.rb
** db/migrate/20241201203840_create_assignment_teams.rb
** db/migrate/20241201220020_add_auto_assign_mentor_to_assignments.rb
** db/migrate/20241201221122_add_type_to_teams.rb
** db/migrate/20241202002102_add_name_to_teams.rb

* Updated ==>
** app/models/team.rb
** config/routes.rb
** db/schema.rb
** db/seeds.rb
** spec/swagger_helper.rb

===Project Design and Implementation===

The main approach to be followed throughout this project is to embrace the Prototyping Pattern within the controller while taking into account the current functionalities to be reimplemented within the student_teams_controller.rb that can capitalize its capability to encapsulate distinct controller actions. This strategic implementation aims to ensure seamless extensibility and enhanced usability. By employing this pattern, we establish a structured framework for defining and managing the diverse operations the controller handles, promoting a more organized and manageable code structure.

[[File:2476_UML.drawio.png]]

==== Functionality ====

1. Reimplement the Controller to Follow SRP:
* Break down large, complex methods into smaller, focused methods that adhere to the Single Responsibility Principle (SRP).
* Reimplement existing methods and logic while ensuring that each class and method have a clear, well-defined responsibility.
* Move business logic and complex operations out of the controller and into the appropriate model classes (e.g., Team, AssignmentTeam), ensuring the controller only handles HTTP-specific concerns (e.g., request handling, responses).

2. Improve Method Naming and Clarity:
* Ensure all method names are descriptive and represent the intent of the operation (e.g., renaming methods like student_team_requirements_met? to something more specific like validate_topic_requirements_for_team_creation).
* Adopt consistent naming conventions to improve the readability of the codebase.

3. Implement the Prototype Pattern for Team Creation:
* Leverage the Prototype pattern to create mentored teams through the AssignmentTeam class, allowing for easier management and creation of teams with a mentored structure.
* Automatically generate team names when a team is first created, unless a user has specified a custom name to improve the user experience and simplify team management.

4. Abstract Assignment-Specific Logic:
* Move logic related to assignment-specific requirements (e.g., topic handling) away from the controller, reducing complexity and increasing modularity.
* Introduce service objects or model methods to handle specific requirements like topic assignment, thereby decoupling assignment-related logic from the controller.
* Break down the student_team_requirements_met? method into smaller, more specific checks for different requirements (e.g., topic validation, minimum team size, etc.).

5. Improve User Feedback:
* Enhance the clarity and actionability of feedback messages after key operations (e.g., team creation, user removal, etc.).
* Provide users with clear, helpful notifications on the success or failure of their actions, including any necessary next steps or troubleshooting guidance.
* Ensure error handling is robust, and feedback is specific (e.g., specify which conditions were not met when creating or modifying teams).

6. Commenting and Documentation:
* Add comprehensive comments throughout the controller to clearly explain the purpose and functionality of custom methods and refactored logic.
* Ensure that code is well-documented, making it easier for future developers to understand and extend the functionality of the controller.

===Tasks Completed===

Methods:
* AssignmentTeam Model:
** To access every participant connected to an assignment, the assignment_participants method was added.
** For including a user in the assignment as a participant, the add_participant method was added.
** To see if the team has gotten any peer reviews, the received_any_peer_review? method was put into practice.
** Using a placeholder for future mentor assignment logic, the upgrade_to_mentored_team method was put into practice to replicate the present team and get it ready for mentoring.
** In order to ensure deep duplication of associated records (such as signed_up_teams, teams_users, and participants), the dup method was added to duplicate a team and its associations.

* Team Model:
** Improved the whole procedure to determine if a team has reached its maximum number of members.
** Counted the number of team members using the size approach, removing those with "(Mentor)" in their names.
** In order to eliminate duplicate members and check for team capacity, the add_member method was improved.
** To remove a user from the team, the remove_team_user method was put into place. If the team becomes empty and hasn't been subjected to any peer reviews, the team will be deleted.

* Controller - StudentTeamsController.rb
** index: Implemented in order to retrieve and restore every student team together with all of its members.
** show: Created to retrieve and provide information about a certain student team and its members.
** create: Added logic to create a new team for a student, using AssignmentTeam#upgraded_to_mentored_team for mentor-eligible teams and checking for existing team names.
** update: Implemented to enable team details, especially the team name, to be updated while ensuring unique team names through validations.
** destroy: To remove a certain team this was added and, if successful, deliver a 204 No Content response.
** remove_participant: Check if the user is part of the given team and removes from that team, also handles corner cases where no more participants are there in a team.
** add_participant: Added this to add the given participant to respective team.

===Testing Plan===

We have performed comprehensive testing of the student_teams_controller.rb and related classes using RSPEC and Swagger to construct the required test fixtures for testing extensive scenarios. Our approach involves reimplementing the existing test cases provided to the older code base and make sure that it is enhanced by covering more test scenarios to minimize code smells. We aim to verify the reimplemented functionality, validate the restructured code in the student_teams_controller.rb and reduce any design or code smell.
Below are the test scenarios for each of API endpoints -

1. List all Student Teams

*Description: List all student teams.
*Response: 200 OK
*Test Case Scenarios:
*Scenario 1: List all Student Teams
*Expectation: Successfully retrieves a list of all student teams. The response status is 200, the content type is `application/json`, and the response body contains 3 student teams.

RSpec.describe 'Student Teams API', type: :request do
path '/api/v1/student_teams' do
# List all Student Teams
get('List all Student Teams') do
tags 'Student Teams'
produces 'application/json'
security [Bearer: {}]
response(200, 'successful') do
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test!
end
end
*Postman Screenshot
[[File:Akoul2Index.jpg]]

2. Create a Student Team
*Description: Create a new student team.
*Response: 201 Created
*Test Data prep:
post 'Create a Student Team' do
tags 'Student Teams'
consumes 'application/json'
let(:institution) do
Institution.create!(
name: 'North Carolina State University'
)
end
let!(:instructor_role) { Role.find_or_create_by(name: 'Instructor') }
let!(:student_role) { Role.find_or_create_by(name: 'Student') }
let(:instructor_user) do
User.create!(
name: 'Dr. Ed Gehringer1',
email: 'gehringer@example.com',
password: 'password123',
full_name: 'admin admin',
institution_id: institution.id,
role_id: instructor_role.id,
handle: 'instructor'
)
end
let(:course) do
Course.create!(
name: '2476. Refactor',
directory_path: '/',
info: 'OODD',
private: false,
instructor_id: instructor_user.id,
institution_id: institution.id
)
end
let(:assignment) do
Assignment.create!(
title: 'Project 4 BRO',
description: '2476. Reimplementing',
course_id: course.id,
instructor_id: instructor_user.id
)
end
let!(:students) do
created_students = []
3.times do |i|
student = User.create!(
name: "Student #{i + 1}",
email: "Student#{i + 1}@gmail.com",
password: 'password123',
full_name: "Student #{i + 1}",
institution_id: institution.id,
role_id: student_role.id,
handle: "Student #{i + 1}"
)
AssignmentParticipant.create!(
assignment: assignment,
user: student,
handle: "Student #{i + 1}"
)
created_students << student
end
created_students
end
parameter name: :student_team_request, in: :body, schema: {
type: :object,
properties: {
team: {
type: :object,
properties: {
name: {type: :string}
}
},
student_id: { type: :integer}
}
}
security [Bearer: {}]
*Scenarios:
*Scenario 1: Successfully create a team
*Expectation: Successfully creates a new student team with a valid name and student ID. The response status is 201, and the response body includes the team name.
*Scenario 2: Team name is already in use (conflict)
*Attempts to create a student team with a name that is already in use.
*Expectation: The response status is 422, and the response body includes an error message indicating that the team name is already in use.
*Scenario 3: Invalid team creation (empty name)
*Expectation: Attempts to create a student team with an empty name. The response status is 422, and the response body includes an error message.

# Scenario 1: Successfully create a team
response(201, 'created') do
let(:student_team_request) do
{ team: {name: "HelloThere"}, student_id: students.first.id}
end
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test! do
expect(response.status).to eq(201)
end
end
# Scenario 2: Team name is already in use (conflict)
response(422, 'unprocessable entity') do
let(:existing_team) { create(:team, name: 'ABCD10', assignment_id: assignment.id) }
let(:team) do
post '/api/v1/student_teams', params: { team: { name: 'ABCD10' }, student_id: students.first.id }, as: :json
end
run_test! do
expect(response.status).to eq(422)
expect(response.body).to include('"error":"That team name is already in use."')
end
end
# Scenario 3: Invalid team creation (empty name)
response(422, 'unprocessable entity') do
let(:student_team_request) do
{ team: {name: ""}, student_id: students.first.id}
end
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test! do
expect(response.status).to eq(422)
expect(response.body).to include('error')
end
end
response(404, 'not_found') do
let(:team) do
post '/api/v1/student_teams', params: { team: { name: 'ABCD10' }, student_id: 0 }, as: :json
end
run_test! do
expect(response.status).to eq(404)
expect(response.body).to include('not found')
end
end
end

3. Update a Student Team
*Description: Update the details of a student team.
*Response: 200 OK
*Scenarios:
*Scenario 1: Team name updated successfully
*Expectation: Successfully updates the name of a student team. The response status is 200, and the response body includes the updated team name.
*Scenario 2: Invalid team update (empty name)
*Expectation: Attempts to update a student team with an empty name. The response status is 422, and the response body includes an error message indicating that the team name should not be empty.
*Scenario 3: Team name already in use
*Expectation: Attempts to update a student team with a name that is already in use. The response status is 422, and the response body includes an error message indicating that the team name is already in use.
*Scenario 4: Invalid team ID
*Expectation: Attempts to update a student team with a non-existent team ID. The response status is 404, and the response body includes an error message indicating that the team was not found.

patch('Update a Student Team') do
tags 'Student Teams'
consumes 'application/json'
produces 'application/json'
security [Bearer: {}]
parameter name: :student_team_request, in: :body, schema: {
type: :object,
properties: {
team: {
type: :object,
properties: {
name: {type: :string}
}
},
team_id: { type: :integer}
}
}
# Scenario 1: Team name updated successfully
response(200, 'successful') do
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test! do
expect(response.status).to eq(200)
end
end
# Scenario 2: Invalid team updation (empty name)
response(422, 'unprocessable entity') do
let(:student_team_request) do
{ team: {name: ""}, team_id: 2}
end
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test! do
expect(response.status).to eq(422)
expect(response.body).to include('Team name should not be empty')
end
end
# Scenario 3: Team Name already present
response(422, 'unprocessable entity') do
let(:existing_team) { create(:team, name: 'ABCD10', team_id: 3) }
let(:team) do
post '/api/v1/student_teams', params: { team: { name: 'ABCD10' }, team_id: 2 }, as: :json
end
run_test! do
expect(response.status).to eq(422)
expect(response.body).to include('"error":"That team name is already in use."')
end
end
#Scenario 4 : Invalid Team ID
response(404, 'not_found') do
let(:team) do
post '/api/v1/student_teams', params: { team: { name: 'ABCD10' }, team_id: 0 }, as: :json
end
run_test! do
expect(response.status).to eq(404)
expect(response.body).to include('not found')
end
end
end
end

4. Show a Student Team
*Description: Retrieve the details of a student team by its ID.
*Response: 200 OK
*Scenarios:
*Scenario 1: Show Student Team
*Expectation: Successfully retrieves the details of a student team by its ID. The response status is 200, and the response body includes the details of the student team.
*Scenario 2: Team not found
*Expectation: Attempts to retrieve the details of a student team with an invalid ID. The response status is 404, and the response body includes an error message indicating that the team was not found.
path '/api/v1/student_teams/{id}' do
parameter name: 'id', in: :path, type: :integer
# Get request on /api/v1/student_teams/{id} returns the response 200 succesful - when correct id passed is present in the database
get('Show a Student Team') do
tags 'Student Teams'
produces 'application/json'
security [Bearer: {}]
response(200, 'successful') do
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test! do
expect(response.status).to eq(200)
end
end
# Get request on /api/v1/student_teams/{id} returns the response 404 not found - when correct id passed is not present in the database
response(404, 'not_found') do
let(:id) { 'invalid' }
run_test! do
expect(response.status).to eq(404)
end
end
end

*Postman:
**Scenario 1:
[[File:Akoul2Show.jpg]]
**Scenario 2:
[[File:Akoul2Show not.jpg]]

5. Delete a Student Team
*Description: Delete a student team by its ID.
*Response: 204 No Content
*Scenarios:
*Scenario 1: Successfully delete a student team
*Expectation: Successfully deletes a student team by its ID. The response status is 204, and the student team is no longer present in the database.
*Scenario 2: Team not found
*Expectation: Attempts to delete a student team with an invalid ID. The response status is 404, and the response body includes an error message indicating that the team was not found.

delete('Delete a Student Team') do
tags 'Student Teams'
produces 'application/json'
security [Bearer: {}]
# delete request on /api/v1/student_teams/{id} returns 204 succesful response when id present in the database is deleted successfully
response(204, 'successful') do
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: ''
}
}
end
run_test! do
expect(response.status).to eq(204)
end
end
# delete request on /api/v1/student_teams/{id} returns 404 not found response, when id is not present in the database
response(404, 'not found') do
let(:id) { 0 }
run_test! do
expect(response.status).to eq(404)
end
end
end
end

6. Add a Participant in Student Team
*Description: Add a participant to a student team.
*Response: 200 OK
*Test Data Prep
path '/api/v1/student_teams/{id}/add_participant' do
parameter name: 'id', in: :path, type: :integer, description: 'ID of Team'
parameter name: 'student_id', in: :query, type: :integer, description: 'ID of the Student'
let(:student) { create(:user, :student) }
let(:assignment) { create(:assignment) }
let(:student_participant) { create(:assignment_participant, user: student, assignment: assignment) }
let(:team) { create(:assignment_team, assignment: assignment) }
let(:id) { team.id }
let(:student_id) { student.id }
*Scenarios:
*Scenario 1: Successfully add a participant to a student team
*Expectation: Successfully adds a participant to a student team by their ID. The response status is 200, and the participant is added to the team.
patch('Add a participant to Student Team') do
tags 'Student Teams'
consumes 'application/json'
produces 'application/json'
security [Bearer: {}]
before do
team.add_member(student, assignment.id)
end
response(200, 'successful') do
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test!
end
end
end
7. Remove a Participant in Student Team
*Description: Remove a participant from a student team.
*Response: 204 No Content
*Test data prep:

path '/api/v1/student_teams/{id}/remove_participant' do
parameter name: 'id', in: :path, type: :integer, description: 'ID of Team'
parameter name: 'student_id', in: :query, type: :integer, description: 'ID of the Student'
let(:student) { create(:user, :student) }
let(:assignment) { create(:assignment) }
let(:student_participant) { create(:assignment_participant, user: student, assignment: assignment) }
let(:team) { create(:assignment_team, assignment: assignment) }
let(:id) { team.id }
let(:student_id) { student.id }
before do
team.add_member(student, assignment.id)
end
*Scenarios:
*Scenario 1: Successfully remove a participant from a student team
*Expectation: Successfully removes a participant from a student team by their ID. The response status is 204, and the participant is no longer a member of the team.
*Scenario 2: Team not found
*Expectation: Attempts to remove a participant from a student team with an invalid team ID. The response status is 404, and the response body includes an error message indicating that the team was not found.
*Scenario 3: User not found
*Expectation: Attempts to remove a participant from a student team with an invalid user ID. The response status is 404, and the response body includes an error message indicating that the user was not found.

delete('remove participant') do
tags 'Student Teams'
produces 'application/json'
security [Bearer: {}]
response(204, 'successful') do
let(:Authorization) { "Bearer #{@token}" }
run_test! do
expect(response.status).to eq(204)
expect(team.members).not_to include(student)
end
end
response(404, 'team not found') do
let(:id) { -1 } # Invalid ID
run_test! do
expect(response.status).to eq(404)
expect(JSON.parse(response.body)['error']).to eq('Team not found.')
end
end
response(404, 'user not found') do
let(:student_id) { -1 } # Invalid student ID
run_test! do
expect(response.status).to eq(404)
expect(JSON.parse(response.body)['error']).to eq('User not found.')
end
end
end
end

===GitHub Pull Request===

https://github.com/expertiza/reimplementation-back-end/pull/136

===Demo Video===

https://www.youtube.com/watch?v=8_d_Y9EcgHc

===Mentor===

* Ammana, Sahithi <sammana@ncsu.edu>

===Team Members===

* Eathamukkala, Akarsh Reddy <aeatham@ncsu.edu>
* Koul, Anmol <akoul2@ncsu.edu>
* More, Harsh Manoj <hmore@ncsu.edu>

File:Akoul2Show not.jpg

2024-12-04T05:09:52Z

Akoul2:

CSC/ECE 517 Fall 2024 - E2476. Reimplement student teams controller.rb

2024-12-04T05:06:56Z

Akoul2: /* Added Index Postman */

===Introduction===
[http://expertiza.ncsu.edu/ Expertiza] is an open-source system built on [http://rubyonrails.org/ Ruby on Rails], collaboratively maintained by students and faculty at NC State. This platform gives instructors extensive control over assignments, enabling them to add topics, create assignment groups, and manage peer reviews for various types of coursework. Expertiza is well-equipped to handle submissions across multiple formats, including URLs and wiki pages, and it offers a peer review system that facilitates constructive feedback among students.

A key focus of recent development in Expertiza has been the shift to a client-server architecture, where Ruby on Rails functions as the backend and React is utilized for the frontend. This architectural update requires reworking existing modules into RESTful API endpoints, allowing React components to interact efficiently with the backend. By adopting this approach, Expertiza aims to enhance modularity, performance, and scalability.

===Project Description===

The project mainly focuses on reimplementing the StudentTeamsController in Expertiza's backend, which is designed for student-facing operations where students participate in teams. This includes actions that directly affect individual team members, such as adding or removing students from teams, viewing team details, and managing their participation.

The TeamsController, on the other hand, is focused on instructor-driven operations that handle high-level team management across different contexts, such as courses and assignments. It manages operations like team creation, deletion, randomization, and bulk management actions.

===Problem Statement===

The current implementation of the StudentTeamsController in the Expertiza system is overly complex and tightly coupled, leading to difficulties in maintaining and extending the codebase. The controller is responsible for managing student teams in assignments, handling tasks like team creation, editing, management, and the integration of topics in assignments that require team-based decisions. However, it suffers from issues such as:
* Code redundancy and inefficiency due to business logic being embedded directly in the controller.
* Lack of modularity and poor separation of concerns, violating the Single Responsibility Principle (SRP). For example, it also handles the integration with topics when assignments involve choosing topics, complicating the team’s logic.
* Difficult-to-understand methods and tightly coupled logic for handling assignment-specific conditions, such as team-topic associations.
* Poor user feedback that does not provide clear or actionable information after critical operations.

These problems create a system that is hard to scale, maintain, and extend, especially as new features are added. To address these challenges, the goal is to reimplement the StudentTeamsController in the newer Expertiza backend codebase by adhering to object-oriented design principles, specifically focusing on maintainability, scalability, and modularity. The new design will improve the user experience by simplifying controller logic, providing clearer feedback, and ensuring that the system is easier to extend and maintain in the future.

===Objectives===

The main objective is to migrate the Student Task controller logic from serving HTML responses in the Ruby on Rails MVC model to returning JSON responses as a RESTful API, as part of the backend implementation. While reimplementing the controller, the following considerations will be incorporated to ensure a clean, maintainable, and scalable API:

*Reimplement the controller logic and write methods which appropriately follow the Single Responsibility Principle (SRP).
*Move business logic from the controller to appropriate model classes like Team or AssignmentTeam.
*Ensure all method names clearly describe their purpose and represent actions.
*Reimplement a Prototype pattern for creating mentored teams, leveraging the AssignmentTeam class.
*Automatically generate team names when a team is first referred to unless the user has specified a name when requesting team creation.
*Handle team requirements with better abstraction:
*Try to eliminate direct logic in the controller that checks for specific assignment requirements such as topic handling.
*Rename student_team_requirements_met? to something more descriptive and break it into smaller methods checking individual conditions.
*Aim to decouple topics from this controller entirely, ensuring better abstraction, that can involve changes to other classes or introducing service objects to handle specific requirements.
* Improve feedback to users and ensure that the user receives clear and actionable feedback after operations like team creation, removal of users, and other key actions.
* Add comprehensive comments throughout the controller, clearly explaining the purpose and functionality of custom methods.

===Development Strategy===

Our development strategy centers around Test-Driven Development (TDD) principles applied to refactoring the student_teams_controller.rb and other related classes such as Team or AssignmentTeam model. We design out test cases and iteratively refactor code to address identified inefficiencies while ensuring successful test outcomes.
Additionally, we emphasize on the strict adoption of SRP and DRY principles as per the object-oriented programming conventions. Our goal is to reimplement the existing functionalities
In the newly designed back-end foundation to foster a more efficient and organized codebase utilizing newer technologies. This approach will significantly enhance reusability and scalability across all the application while maintaining clean codebase.

Files Modified:
* Created ==>
** app/controllers/api/v1/student_teams_controller.rb
** app/models/assignment_team.rb
** app/models/team.rb
** spec/requests/api/v1/student_teams_controller_spec.rb
** db/migrate/20241201203840_create_assignment_teams.rb
** db/migrate/20241201220020_add_auto_assign_mentor_to_assignments.rb
** db/migrate/20241201221122_add_type_to_teams.rb
** db/migrate/20241202002102_add_name_to_teams.rb

* Updated ==>
** app/models/team.rb
** config/routes.rb
** db/schema.rb
** db/seeds.rb
** spec/swagger_helper.rb

===Project Design and Implementation===

The main approach to be followed throughout this project is to embrace the Prototyping Pattern within the controller while taking into account the current functionalities to be reimplemented within the student_teams_controller.rb that can capitalize its capability to encapsulate distinct controller actions. This strategic implementation aims to ensure seamless extensibility and enhanced usability. By employing this pattern, we establish a structured framework for defining and managing the diverse operations the controller handles, promoting a more organized and manageable code structure.

[[File:2476_UML.drawio.png]]

==== Functionality ====

1. Reimplement the Controller to Follow SRP:
* Break down large, complex methods into smaller, focused methods that adhere to the Single Responsibility Principle (SRP).
* Reimplement existing methods and logic while ensuring that each class and method have a clear, well-defined responsibility.
* Move business logic and complex operations out of the controller and into the appropriate model classes (e.g., Team, AssignmentTeam), ensuring the controller only handles HTTP-specific concerns (e.g., request handling, responses).

2. Improve Method Naming and Clarity:
* Ensure all method names are descriptive and represent the intent of the operation (e.g., renaming methods like student_team_requirements_met? to something more specific like validate_topic_requirements_for_team_creation).
* Adopt consistent naming conventions to improve the readability of the codebase.

3. Implement the Prototype Pattern for Team Creation:
* Leverage the Prototype pattern to create mentored teams through the AssignmentTeam class, allowing for easier management and creation of teams with a mentored structure.
* Automatically generate team names when a team is first created, unless a user has specified a custom name to improve the user experience and simplify team management.

4. Abstract Assignment-Specific Logic:
* Move logic related to assignment-specific requirements (e.g., topic handling) away from the controller, reducing complexity and increasing modularity.
* Introduce service objects or model methods to handle specific requirements like topic assignment, thereby decoupling assignment-related logic from the controller.
* Break down the student_team_requirements_met? method into smaller, more specific checks for different requirements (e.g., topic validation, minimum team size, etc.).

5. Improve User Feedback:
* Enhance the clarity and actionability of feedback messages after key operations (e.g., team creation, user removal, etc.).
* Provide users with clear, helpful notifications on the success or failure of their actions, including any necessary next steps or troubleshooting guidance.
* Ensure error handling is robust, and feedback is specific (e.g., specify which conditions were not met when creating or modifying teams).

6. Commenting and Documentation:
* Add comprehensive comments throughout the controller to clearly explain the purpose and functionality of custom methods and refactored logic.
* Ensure that code is well-documented, making it easier for future developers to understand and extend the functionality of the controller.

===Tasks Completed===

Methods:
* AssignmentTeam Model:
** To access every participant connected to an assignment, the assignment_participants method was added.
** For including a user in the assignment as a participant, the add_participant method was added.
** To see if the team has gotten any peer reviews, the received_any_peer_review? method was put into practice.
** Using a placeholder for future mentor assignment logic, the upgrade_to_mentored_team method was put into practice to replicate the present team and get it ready for mentoring.
** In order to ensure deep duplication of associated records (such as signed_up_teams, teams_users, and participants), the dup method was added to duplicate a team and its associations.

* Team Model:
** Improved the whole procedure to determine if a team has reached its maximum number of members.
** Counted the number of team members using the size approach, removing those with "(Mentor)" in their names.
** In order to eliminate duplicate members and check for team capacity, the add_member method was improved.
** To remove a user from the team, the remove_team_user method was put into place. If the team becomes empty and hasn't been subjected to any peer reviews, the team will be deleted.

* Controller - StudentTeamsController.rb
** index: Implemented in order to retrieve and restore every student team together with all of its members.
** show: Created to retrieve and provide information about a certain student team and its members.
** create: Added logic to create a new team for a student, using AssignmentTeam#upgraded_to_mentored_team for mentor-eligible teams and checking for existing team names.
** update: Implemented to enable team details, especially the team name, to be updated while ensuring unique team names through validations.
** destroy: To remove a certain team this was added and, if successful, deliver a 204 No Content response.
** remove_participant: Check if the user is part of the given team and removes from that team, also handles corner cases where no more participants are there in a team.
** add_participant: Added this to add the given participant to respective team.

===Testing Plan===

We have performed comprehensive testing of the student_teams_controller.rb and related classes using RSPEC and Swagger to construct the required test fixtures for testing extensive scenarios. Our approach involves reimplementing the existing test cases provided to the older code base and make sure that it is enhanced by covering more test scenarios to minimize code smells. We aim to verify the reimplemented functionality, validate the restructured code in the student_teams_controller.rb and reduce any design or code smell.
Below are the test scenarios for each of API endpoints -

1. List all Student Teams

*Description: List all student teams.
*Response: 200 OK
*Test Case Scenarios:
*Scenario 1: List all Student Teams
*Expectation: Successfully retrieves a list of all student teams. The response status is 200, the content type is `application/json`, and the response body contains 3 student teams.

RSpec.describe 'Student Teams API', type: :request do
path '/api/v1/student_teams' do
# List all Student Teams
get('List all Student Teams') do
tags 'Student Teams'
produces 'application/json'
security [Bearer: {}]
response(200, 'successful') do
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test!
end
end
*Postman Screenshot
[[File:Akoul2Index.jpg]]

2. Create a Student Team
*Description: Create a new student team.
*Response: 201 Created
*Test Data prep:
post 'Create a Student Team' do
tags 'Student Teams'
consumes 'application/json'
let(:institution) do
Institution.create!(
name: 'North Carolina State University'
)
end
let!(:instructor_role) { Role.find_or_create_by(name: 'Instructor') }
let!(:student_role) { Role.find_or_create_by(name: 'Student') }
let(:instructor_user) do
User.create!(
name: 'Dr. Ed Gehringer1',
email: 'gehringer@example.com',
password: 'password123',
full_name: 'admin admin',
institution_id: institution.id,
role_id: instructor_role.id,
handle: 'instructor'
)
end
let(:course) do
Course.create!(
name: '2476. Refactor',
directory_path: '/',
info: 'OODD',
private: false,
instructor_id: instructor_user.id,
institution_id: institution.id
)
end
let(:assignment) do
Assignment.create!(
title: 'Project 4 BRO',
description: '2476. Reimplementing',
course_id: course.id,
instructor_id: instructor_user.id
)
end
let!(:students) do
created_students = []
3.times do |i|
student = User.create!(
name: "Student #{i + 1}",
email: "Student#{i + 1}@gmail.com",
password: 'password123',
full_name: "Student #{i + 1}",
institution_id: institution.id,
role_id: student_role.id,
handle: "Student #{i + 1}"
)
AssignmentParticipant.create!(
assignment: assignment,
user: student,
handle: "Student #{i + 1}"
)
created_students << student
end
created_students
end
parameter name: :student_team_request, in: :body, schema: {
type: :object,
properties: {
team: {
type: :object,
properties: {
name: {type: :string}
}
},
student_id: { type: :integer}
}
}
security [Bearer: {}]
*Scenarios:
*Scenario 1: Successfully create a team
*Expectation: Successfully creates a new student team with a valid name and student ID. The response status is 201, and the response body includes the team name.
*Scenario 2: Team name is already in use (conflict)
*Attempts to create a student team with a name that is already in use.
*Expectation: The response status is 422, and the response body includes an error message indicating that the team name is already in use.
*Scenario 3: Invalid team creation (empty name)
*Expectation: Attempts to create a student team with an empty name. The response status is 422, and the response body includes an error message.

# Scenario 1: Successfully create a team
response(201, 'created') do
let(:student_team_request) do
{ team: {name: "HelloThere"}, student_id: students.first.id}
end
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test! do
expect(response.status).to eq(201)
end
end
# Scenario 2: Team name is already in use (conflict)
response(422, 'unprocessable entity') do
let(:existing_team) { create(:team, name: 'ABCD10', assignment_id: assignment.id) }
let(:team) do
post '/api/v1/student_teams', params: { team: { name: 'ABCD10' }, student_id: students.first.id }, as: :json
end
run_test! do
expect(response.status).to eq(422)
expect(response.body).to include('"error":"That team name is already in use."')
end
end
# Scenario 3: Invalid team creation (empty name)
response(422, 'unprocessable entity') do
let(:student_team_request) do
{ team: {name: ""}, student_id: students.first.id}
end
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test! do
expect(response.status).to eq(422)
expect(response.body).to include('error')
end
end
response(404, 'not_found') do
let(:team) do
post '/api/v1/student_teams', params: { team: { name: 'ABCD10' }, student_id: 0 }, as: :json
end
run_test! do
expect(response.status).to eq(404)
expect(response.body).to include('not found')
end
end
end

3. Update a Student Team
*Description: Update the details of a student team.
*Response: 200 OK
*Scenarios:
*Scenario 1: Team name updated successfully
*Expectation: Successfully updates the name of a student team. The response status is 200, and the response body includes the updated team name.
*Scenario 2: Invalid team update (empty name)
*Expectation: Attempts to update a student team with an empty name. The response status is 422, and the response body includes an error message indicating that the team name should not be empty.
*Scenario 3: Team name already in use
*Expectation: Attempts to update a student team with a name that is already in use. The response status is 422, and the response body includes an error message indicating that the team name is already in use.
*Scenario 4: Invalid team ID
*Expectation: Attempts to update a student team with a non-existent team ID. The response status is 404, and the response body includes an error message indicating that the team was not found.

patch('Update a Student Team') do
tags 'Student Teams'
consumes 'application/json'
produces 'application/json'
security [Bearer: {}]
parameter name: :student_team_request, in: :body, schema: {
type: :object,
properties: {
team: {
type: :object,
properties: {
name: {type: :string}
}
},
team_id: { type: :integer}
}
}
# Scenario 1: Team name updated successfully
response(200, 'successful') do
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test! do
expect(response.status).to eq(200)
end
end
# Scenario 2: Invalid team updation (empty name)
response(422, 'unprocessable entity') do
let(:student_team_request) do
{ team: {name: ""}, team_id: 2}
end
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test! do
expect(response.status).to eq(422)
expect(response.body).to include('Team name should not be empty')
end
end
# Scenario 3: Team Name already present
response(422, 'unprocessable entity') do
let(:existing_team) { create(:team, name: 'ABCD10', team_id: 3) }
let(:team) do
post '/api/v1/student_teams', params: { team: { name: 'ABCD10' }, team_id: 2 }, as: :json
end
run_test! do
expect(response.status).to eq(422)
expect(response.body).to include('"error":"That team name is already in use."')
end
end
#Scenario 4 : Invalid Team ID
response(404, 'not_found') do
let(:team) do
post '/api/v1/student_teams', params: { team: { name: 'ABCD10' }, team_id: 0 }, as: :json
end
run_test! do
expect(response.status).to eq(404)
expect(response.body).to include('not found')
end
end
end
end

4. Show a Student Team
*Description: Retrieve the details of a student team by its ID.
*Response: 200 OK
*Scenarios:
*Scenario 1: Show Student Team
*Expectation: Successfully retrieves the details of a student team by its ID. The response status is 200, and the response body includes the details of the student team.
*Scenario 2: Team not found
*Expectation: Attempts to retrieve the details of a student team with an invalid ID. The response status is 404, and the response body includes an error message indicating that the team was not found.
path '/api/v1/student_teams/{id}' do
parameter name: 'id', in: :path, type: :integer
# Get request on /api/v1/student_teams/{id} returns the response 200 succesful - when correct id passed is present in the database
get('Show a Student Team') do
tags 'Student Teams'
produces 'application/json'
security [Bearer: {}]
response(200, 'successful') do
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test! do
expect(response.status).to eq(200)
end
end
# Get request on /api/v1/student_teams/{id} returns the response 404 not found - when correct id passed is not present in the database
response(404, 'not_found') do
let(:id) { 'invalid' }
run_test! do
expect(response.status).to eq(404)
end
end
end

5. Delete a Student Team
*Description: Delete a student team by its ID.
*Response: 204 No Content
*Scenarios:
*Scenario 1: Successfully delete a student team
*Expectation: Successfully deletes a student team by its ID. The response status is 204, and the student team is no longer present in the database.
*Scenario 2: Team not found
*Expectation: Attempts to delete a student team with an invalid ID. The response status is 404, and the response body includes an error message indicating that the team was not found.

delete('Delete a Student Team') do
tags 'Student Teams'
produces 'application/json'
security [Bearer: {}]
# delete request on /api/v1/student_teams/{id} returns 204 succesful response when id present in the database is deleted successfully
response(204, 'successful') do
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: ''
}
}
end
run_test! do
expect(response.status).to eq(204)
end
end
# delete request on /api/v1/student_teams/{id} returns 404 not found response, when id is not present in the database
response(404, 'not found') do
let(:id) { 0 }
run_test! do
expect(response.status).to eq(404)
end
end
end
end

6. Add a Participant in Student Team
*Description: Add a participant to a student team.
*Response: 200 OK
*Test Data Prep
path '/api/v1/student_teams/{id}/add_participant' do
parameter name: 'id', in: :path, type: :integer, description: 'ID of Team'
parameter name: 'student_id', in: :query, type: :integer, description: 'ID of the Student'
let(:student) { create(:user, :student) }
let(:assignment) { create(:assignment) }
let(:student_participant) { create(:assignment_participant, user: student, assignment: assignment) }
let(:team) { create(:assignment_team, assignment: assignment) }
let(:id) { team.id }
let(:student_id) { student.id }
*Scenarios:
*Scenario 1: Successfully add a participant to a student team
*Expectation: Successfully adds a participant to a student team by their ID. The response status is 200, and the participant is added to the team.
patch('Add a participant to Student Team') do
tags 'Student Teams'
consumes 'application/json'
produces 'application/json'
security [Bearer: {}]
before do
team.add_member(student, assignment.id)
end
response(200, 'successful') do
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test!
end
end
end
7. Remove a Participant in Student Team
*Description: Remove a participant from a student team.
*Response: 204 No Content
*Test data prep:

path '/api/v1/student_teams/{id}/remove_participant' do
parameter name: 'id', in: :path, type: :integer, description: 'ID of Team'
parameter name: 'student_id', in: :query, type: :integer, description: 'ID of the Student'
let(:student) { create(:user, :student) }
let(:assignment) { create(:assignment) }
let(:student_participant) { create(:assignment_participant, user: student, assignment: assignment) }
let(:team) { create(:assignment_team, assignment: assignment) }
let(:id) { team.id }
let(:student_id) { student.id }
before do
team.add_member(student, assignment.id)
end
*Scenarios:
*Scenario 1: Successfully remove a participant from a student team
*Expectation: Successfully removes a participant from a student team by their ID. The response status is 204, and the participant is no longer a member of the team.
*Scenario 2: Team not found
*Expectation: Attempts to remove a participant from a student team with an invalid team ID. The response status is 404, and the response body includes an error message indicating that the team was not found.
*Scenario 3: User not found
*Expectation: Attempts to remove a participant from a student team with an invalid user ID. The response status is 404, and the response body includes an error message indicating that the user was not found.

delete('remove participant') do
tags 'Student Teams'
produces 'application/json'
security [Bearer: {}]
response(204, 'successful') do
let(:Authorization) { "Bearer #{@token}" }
run_test! do
expect(response.status).to eq(204)
expect(team.members).not_to include(student)
end
end
response(404, 'team not found') do
let(:id) { -1 } # Invalid ID
run_test! do
expect(response.status).to eq(404)
expect(JSON.parse(response.body)['error']).to eq('Team not found.')
end
end
response(404, 'user not found') do
let(:student_id) { -1 } # Invalid student ID
run_test! do
expect(response.status).to eq(404)
expect(JSON.parse(response.body)['error']).to eq('User not found.')
end
end
end
end

===GitHub Pull Request===

https://github.com/expertiza/reimplementation-back-end/pull/136

===Demo Video===

https://www.youtube.com/watch?v=8_d_Y9EcgHc

===Mentor===

* Ammana, Sahithi <sammana@ncsu.edu>

===Team Members===

* Eathamukkala, Akarsh Reddy <aeatham@ncsu.edu>
* Koul, Anmol <akoul2@ncsu.edu>
* More, Harsh Manoj <hmore@ncsu.edu>

File:Akoul2Show.jpg

2024-12-04T05:01:48Z

Akoul2:

File:Akoul2Index.jpg

2024-12-04T05:01:37Z

Akoul2:

File:Akoul2Delete.jpg

2024-12-04T05:01:22Z

Akoul2:

File:Create.jpg

2024-12-04T05:00:09Z

Akoul2: Akoul2 uploaded a new version of File:Create.jpg

CSC/ECE 517 Fall 2024 - E2476. Reimplement student teams controller.rb

2024-12-04T04:48:59Z

Akoul2: /* Tasks Completed */

===Introduction===
[http://expertiza.ncsu.edu/ Expertiza] is an open-source system built on [http://rubyonrails.org/ Ruby on Rails], collaboratively maintained by students and faculty at NC State. This platform gives instructors extensive control over assignments, enabling them to add topics, create assignment groups, and manage peer reviews for various types of coursework. Expertiza is well-equipped to handle submissions across multiple formats, including URLs and wiki pages, and it offers a peer review system that facilitates constructive feedback among students.

A key focus of recent development in Expertiza has been the shift to a client-server architecture, where Ruby on Rails functions as the backend and React is utilized for the frontend. This architectural update requires reworking existing modules into RESTful API endpoints, allowing React components to interact efficiently with the backend. By adopting this approach, Expertiza aims to enhance modularity, performance, and scalability.

===Project Description===

The project mainly focuses on reimplementing the StudentTeamsController in Expertiza's backend, which is designed for student-facing operations where students participate in teams. This includes actions that directly affect individual team members, such as adding or removing students from teams, viewing team details, and managing their participation.

The TeamsController, on the other hand, is focused on instructor-driven operations that handle high-level team management across different contexts, such as courses and assignments. It manages operations like team creation, deletion, randomization, and bulk management actions.

===Problem Statement===

The current implementation of the StudentTeamsController in the Expertiza system is overly complex and tightly coupled, leading to difficulties in maintaining and extending the codebase. The controller is responsible for managing student teams in assignments, handling tasks like team creation, editing, management, and the integration of topics in assignments that require team-based decisions. However, it suffers from issues such as:
* Code redundancy and inefficiency due to business logic being embedded directly in the controller.
* Lack of modularity and poor separation of concerns, violating the Single Responsibility Principle (SRP). For example, it also handles the integration with topics when assignments involve choosing topics, complicating the team’s logic.
* Difficult-to-understand methods and tightly coupled logic for handling assignment-specific conditions, such as team-topic associations.
* Poor user feedback that does not provide clear or actionable information after critical operations.

These problems create a system that is hard to scale, maintain, and extend, especially as new features are added. To address these challenges, the goal is to reimplement the StudentTeamsController in the newer Expertiza backend codebase by adhering to object-oriented design principles, specifically focusing on maintainability, scalability, and modularity. The new design will improve the user experience by simplifying controller logic, providing clearer feedback, and ensuring that the system is easier to extend and maintain in the future.

===Objectives===

The main objective is to migrate the Student Task controller logic from serving HTML responses in the Ruby on Rails MVC model to returning JSON responses as a RESTful API, as part of the backend implementation. While reimplementing the controller, the following considerations will be incorporated to ensure a clean, maintainable, and scalable API:

*Reimplement the controller logic and write methods which appropriately follow the Single Responsibility Principle (SRP).
*Move business logic from the controller to appropriate model classes like Team or AssignmentTeam.
*Ensure all method names clearly describe their purpose and represent actions.
*Reimplement a Prototype pattern for creating mentored teams, leveraging the AssignmentTeam class.
*Automatically generate team names when a team is first referred to unless the user has specified a name when requesting team creation.
*Handle team requirements with better abstraction:
*Try to eliminate direct logic in the controller that checks for specific assignment requirements such as topic handling.
*Rename student_team_requirements_met? to something more descriptive and break it into smaller methods checking individual conditions.
*Aim to decouple topics from this controller entirely, ensuring better abstraction, that can involve changes to other classes or introducing service objects to handle specific requirements.
* Improve feedback to users and ensure that the user receives clear and actionable feedback after operations like team creation, removal of users, and other key actions.
* Add comprehensive comments throughout the controller, clearly explaining the purpose and functionality of custom methods.

===Development Strategy===

Our development strategy centers around Test-Driven Development (TDD) principles applied to refactoring the student_teams_controller.rb and other related classes such as Team or AssignmentTeam model. We design out test cases and iteratively refactor code to address identified inefficiencies while ensuring successful test outcomes.
Additionally, we emphasize on the strict adoption of SRP and DRY principles as per the object-oriented programming conventions. Our goal is to reimplement the existing functionalities
In the newly designed back-end foundation to foster a more efficient and organized codebase utilizing newer technologies. This approach will significantly enhance reusability and scalability across all the application while maintaining clean codebase.

Files Modified:
* Created ==>
** app/controllers/api/v1/student_teams_controller.rb
** app/models/assignment_team.rb
** app/models/team.rb
** spec/requests/api/v1/student_teams_controller_spec.rb
** db/migrate/20241201203840_create_assignment_teams.rb
** db/migrate/20241201220020_add_auto_assign_mentor_to_assignments.rb
** db/migrate/20241201221122_add_type_to_teams.rb
** db/migrate/20241202002102_add_name_to_teams.rb

* Updated ==>
** app/models/team.rb
** config/routes.rb
** db/schema.rb
** db/seeds.rb
** spec/swagger_helper.rb

===Project Design and Implementation===

The main approach to be followed throughout this project is to embrace the Prototyping Pattern within the controller while taking into account the current functionalities to be reimplemented within the student_teams_controller.rb that can capitalize its capability to encapsulate distinct controller actions. This strategic implementation aims to ensure seamless extensibility and enhanced usability. By employing this pattern, we establish a structured framework for defining and managing the diverse operations the controller handles, promoting a more organized and manageable code structure.

[[File:2476_UML.drawio.png]]

==== Functionality ====

1. Reimplement the Controller to Follow SRP:
* Break down large, complex methods into smaller, focused methods that adhere to the Single Responsibility Principle (SRP).
* Reimplement existing methods and logic while ensuring that each class and method have a clear, well-defined responsibility.
* Move business logic and complex operations out of the controller and into the appropriate model classes (e.g., Team, AssignmentTeam), ensuring the controller only handles HTTP-specific concerns (e.g., request handling, responses).

2. Improve Method Naming and Clarity:
* Ensure all method names are descriptive and represent the intent of the operation (e.g., renaming methods like student_team_requirements_met? to something more specific like validate_topic_requirements_for_team_creation).
* Adopt consistent naming conventions to improve the readability of the codebase.

3. Implement the Prototype Pattern for Team Creation:
* Leverage the Prototype pattern to create mentored teams through the AssignmentTeam class, allowing for easier management and creation of teams with a mentored structure.
* Automatically generate team names when a team is first created, unless a user has specified a custom name to improve the user experience and simplify team management.

4. Abstract Assignment-Specific Logic:
* Move logic related to assignment-specific requirements (e.g., topic handling) away from the controller, reducing complexity and increasing modularity.
* Introduce service objects or model methods to handle specific requirements like topic assignment, thereby decoupling assignment-related logic from the controller.
* Break down the student_team_requirements_met? method into smaller, more specific checks for different requirements (e.g., topic validation, minimum team size, etc.).

5. Improve User Feedback:
* Enhance the clarity and actionability of feedback messages after key operations (e.g., team creation, user removal, etc.).
* Provide users with clear, helpful notifications on the success or failure of their actions, including any necessary next steps or troubleshooting guidance.
* Ensure error handling is robust, and feedback is specific (e.g., specify which conditions were not met when creating or modifying teams).

6. Commenting and Documentation:
* Add comprehensive comments throughout the controller to clearly explain the purpose and functionality of custom methods and refactored logic.
* Ensure that code is well-documented, making it easier for future developers to understand and extend the functionality of the controller.

===Tasks Completed===

Methods:
* AssignmentTeam Model:
** To access every participant connected to an assignment, the assignment_participants method was added.
** For including a user in the assignment as a participant, the add_participant method was added.
** To see if the team has gotten any peer reviews, the received_any_peer_review? method was put into practice.
** Using a placeholder for future mentor assignment logic, the upgrade_to_mentored_team method was put into practice to replicate the present team and get it ready for mentoring.
** In order to ensure deep duplication of associated records (such as signed_up_teams, teams_users, and participants), the dup method was added to duplicate a team and its associations.

* Team Model:
** Improved the whole procedure to determine if a team has reached its maximum number of members.
** Counted the number of team members using the size approach, removing those with "(Mentor)" in their names.
** In order to eliminate duplicate members and check for team capacity, the add_member method was improved.
** To remove a user from the team, the remove_team_user method was put into place. If the team becomes empty and hasn't been subjected to any peer reviews, the team will be deleted.

* Controller - StudentTeamsController.rb
** index: Implemented in order to retrieve and restore every student team together with all of its members.
** show: Created to retrieve and provide information about a certain student team and its members.
** create: Added logic to create a new team for a student, using AssignmentTeam#upgraded_to_mentored_team for mentor-eligible teams and checking for existing team names.
** update: Implemented to enable team details, especially the team name, to be updated while ensuring unique team names through validations.
** destroy: To remove a certain team this was added and, if successful, deliver a 204 No Content response.
** remove_participant: Check if the user is part of the given team and removes from that team, also handles corner cases where no more participants are there in a team.
** add_participant: Added this to add the given participant to respective team.

===Testing Plan===

We have performed comprehensive testing of the student_teams_controller.rb and related classes using RSPEC and Swagger to construct the required test fixtures for testing extensive scenarios. Our approach involves reimplementing the existing test cases provided to the older code base and make sure that it is enhanced by covering more test scenarios to minimize code smells. We aim to verify the reimplemented functionality, validate the restructured code in the student_teams_controller.rb and reduce any design or code smell.
Below are the test scenarios for each of API endpoints -

1. List all Student Teams

*Description: List all student teams.
*Response: 200 OK
*Test Case Scenarios:
*Scenario 1: List all Student Teams
*Expectation: Successfully retrieves a list of all student teams. The response status is 200, the content type is `application/json`, and the response body contains 3 student teams.

RSpec.describe 'Student Teams API', type: :request do
path '/api/v1/student_teams' do
# List all Student Teams
get('List all Student Teams') do
tags 'Student Teams'
produces 'application/json'
security [Bearer: {}]
response(200, 'successful') do
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test!
end
end

2. Create a Student Team
*Description: Create a new student team.
*Response: 201 Created
*Test Data prep:
post 'Create a Student Team' do
tags 'Student Teams'
consumes 'application/json'
let(:institution) do
Institution.create!(
name: 'North Carolina State University'
)
end
let!(:instructor_role) { Role.find_or_create_by(name: 'Instructor') }
let!(:student_role) { Role.find_or_create_by(name: 'Student') }
let(:instructor_user) do
User.create!(
name: 'Dr. Ed Gehringer1',
email: 'gehringer@example.com',
password: 'password123',
full_name: 'admin admin',
institution_id: institution.id,
role_id: instructor_role.id,
handle: 'instructor'
)
end
let(:course) do
Course.create!(
name: '2476. Refactor',
directory_path: '/',
info: 'OODD',
private: false,
instructor_id: instructor_user.id,
institution_id: institution.id
)
end
let(:assignment) do
Assignment.create!(
title: 'Project 4 BRO',
description: '2476. Reimplementing',
course_id: course.id,
instructor_id: instructor_user.id
)
end
let!(:students) do
created_students = []
3.times do |i|
student = User.create!(
name: "Student #{i + 1}",
email: "Student#{i + 1}@gmail.com",
password: 'password123',
full_name: "Student #{i + 1}",
institution_id: institution.id,
role_id: student_role.id,
handle: "Student #{i + 1}"
)
AssignmentParticipant.create!(
assignment: assignment,
user: student,
handle: "Student #{i + 1}"
)
created_students << student
end
created_students
end
parameter name: :student_team_request, in: :body, schema: {
type: :object,
properties: {
team: {
type: :object,
properties: {
name: {type: :string}
}
},
student_id: { type: :integer}
}
}
security [Bearer: {}]
*Scenarios:
*Scenario 1: Successfully create a team
*Expectation: Successfully creates a new student team with a valid name and student ID. The response status is 201, and the response body includes the team name.
*Scenario 2: Team name is already in use (conflict)
*Attempts to create a student team with a name that is already in use.
*Expectation: The response status is 422, and the response body includes an error message indicating that the team name is already in use.
*Scenario 3: Invalid team creation (empty name)
*Expectation: Attempts to create a student team with an empty name. The response status is 422, and the response body includes an error message.

# Scenario 1: Successfully create a team
response(201, 'created') do
let(:student_team_request) do
{ team: {name: "HelloThere"}, student_id: students.first.id}
end
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test! do
expect(response.status).to eq(201)
end
end
# Scenario 2: Team name is already in use (conflict)
response(422, 'unprocessable entity') do
let(:existing_team) { create(:team, name: 'ABCD10', assignment_id: assignment.id) }
let(:team) do
post '/api/v1/student_teams', params: { team: { name: 'ABCD10' }, student_id: students.first.id }, as: :json
end
run_test! do
expect(response.status).to eq(422)
expect(response.body).to include('"error":"That team name is already in use."')
end
end
# Scenario 3: Invalid team creation (empty name)
response(422, 'unprocessable entity') do
let(:student_team_request) do
{ team: {name: ""}, student_id: students.first.id}
end
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test! do
expect(response.status).to eq(422)
expect(response.body).to include('error')
end
end
response(404, 'not_found') do
let(:team) do
post '/api/v1/student_teams', params: { team: { name: 'ABCD10' }, student_id: 0 }, as: :json
end
run_test! do
expect(response.status).to eq(404)
expect(response.body).to include('not found')
end
end
end

3. Update a Student Team
*Description: Update the details of a student team.
*Response: 200 OK
*Scenarios:
*Scenario 1: Team name updated successfully
*Expectation: Successfully updates the name of a student team. The response status is 200, and the response body includes the updated team name.
*Scenario 2: Invalid team update (empty name)
*Expectation: Attempts to update a student team with an empty name. The response status is 422, and the response body includes an error message indicating that the team name should not be empty.
*Scenario 3: Team name already in use
*Expectation: Attempts to update a student team with a name that is already in use. The response status is 422, and the response body includes an error message indicating that the team name is already in use.
*Scenario 4: Invalid team ID
*Expectation: Attempts to update a student team with a non-existent team ID. The response status is 404, and the response body includes an error message indicating that the team was not found.

patch('Update a Student Team') do
tags 'Student Teams'
consumes 'application/json'
produces 'application/json'
security [Bearer: {}]
parameter name: :student_team_request, in: :body, schema: {
type: :object,
properties: {
team: {
type: :object,
properties: {
name: {type: :string}
}
},
team_id: { type: :integer}
}
}
# Scenario 1: Team name updated successfully
response(200, 'successful') do
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test! do
expect(response.status).to eq(200)
end
end
# Scenario 2: Invalid team updation (empty name)
response(422, 'unprocessable entity') do
let(:student_team_request) do
{ team: {name: ""}, team_id: 2}
end
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test! do
expect(response.status).to eq(422)
expect(response.body).to include('Team name should not be empty')
end
end
# Scenario 3: Team Name already present
response(422, 'unprocessable entity') do
let(:existing_team) { create(:team, name: 'ABCD10', team_id: 3) }
let(:team) do
post '/api/v1/student_teams', params: { team: { name: 'ABCD10' }, team_id: 2 }, as: :json
end
run_test! do
expect(response.status).to eq(422)
expect(response.body).to include('"error":"That team name is already in use."')
end
end
#Scenario 4 : Invalid Team ID
response(404, 'not_found') do
let(:team) do
post '/api/v1/student_teams', params: { team: { name: 'ABCD10' }, team_id: 0 }, as: :json
end
run_test! do
expect(response.status).to eq(404)
expect(response.body).to include('not found')
end
end
end
end

4. Show a Student Team
*Description: Retrieve the details of a student team by its ID.
*Response: 200 OK
*Scenarios:
*Scenario 1: Show Student Team
*Expectation: Successfully retrieves the details of a student team by its ID. The response status is 200, and the response body includes the details of the student team.
*Scenario 2: Team not found
*Expectation: Attempts to retrieve the details of a student team with an invalid ID. The response status is 404, and the response body includes an error message indicating that the team was not found.
path '/api/v1/student_teams/{id}' do
parameter name: 'id', in: :path, type: :integer
# Get request on /api/v1/student_teams/{id} returns the response 200 succesful - when correct id passed is present in the database
get('Show a Student Team') do
tags 'Student Teams'
produces 'application/json'
security [Bearer: {}]
response(200, 'successful') do
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test! do
expect(response.status).to eq(200)
end
end
# Get request on /api/v1/student_teams/{id} returns the response 404 not found - when correct id passed is not present in the database
response(404, 'not_found') do
let(:id) { 'invalid' }
run_test! do
expect(response.status).to eq(404)
end
end
end

5. Delete a Student Team
*Description: Delete a student team by its ID.
*Response: 204 No Content
*Scenarios:
*Scenario 1: Successfully delete a student team
*Expectation: Successfully deletes a student team by its ID. The response status is 204, and the student team is no longer present in the database.
*Scenario 2: Team not found
*Expectation: Attempts to delete a student team with an invalid ID. The response status is 404, and the response body includes an error message indicating that the team was not found.

delete('Delete a Student Team') do
tags 'Student Teams'
produces 'application/json'
security [Bearer: {}]
# delete request on /api/v1/student_teams/{id} returns 204 succesful response when id present in the database is deleted successfully
response(204, 'successful') do
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: ''
}
}
end
run_test! do
expect(response.status).to eq(204)
end
end
# delete request on /api/v1/student_teams/{id} returns 404 not found response, when id is not present in the database
response(404, 'not found') do
let(:id) { 0 }
run_test! do
expect(response.status).to eq(404)
end
end
end
end

6. Add a Participant in Student Team
*Description: Add a participant to a student team.
*Response: 200 OK
*Test Data Prep
path '/api/v1/student_teams/{id}/add_participant' do
parameter name: 'id', in: :path, type: :integer, description: 'ID of Team'
parameter name: 'student_id', in: :query, type: :integer, description: 'ID of the Student'
let(:student) { create(:user, :student) }
let(:assignment) { create(:assignment) }
let(:student_participant) { create(:assignment_participant, user: student, assignment: assignment) }
let(:team) { create(:assignment_team, assignment: assignment) }
let(:id) { team.id }
let(:student_id) { student.id }
*Scenarios:
*Scenario 1: Successfully add a participant to a student team
*Expectation: Successfully adds a participant to a student team by their ID. The response status is 200, and the participant is added to the team.
patch('Add a participant to Student Team') do
tags 'Student Teams'
consumes 'application/json'
produces 'application/json'
security [Bearer: {}]
before do
team.add_member(student, assignment.id)
end
response(200, 'successful') do
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test!
end
end
end
7. Remove a Participant in Student Team
*Description: Remove a participant from a student team.
*Response: 204 No Content
*Test data prep:

path '/api/v1/student_teams/{id}/remove_participant' do
parameter name: 'id', in: :path, type: :integer, description: 'ID of Team'
parameter name: 'student_id', in: :query, type: :integer, description: 'ID of the Student'
let(:student) { create(:user, :student) }
let(:assignment) { create(:assignment) }
let(:student_participant) { create(:assignment_participant, user: student, assignment: assignment) }
let(:team) { create(:assignment_team, assignment: assignment) }
let(:id) { team.id }
let(:student_id) { student.id }
before do
team.add_member(student, assignment.id)
end
*Scenarios:
*Scenario 1: Successfully remove a participant from a student team
*Expectation: Successfully removes a participant from a student team by their ID. The response status is 204, and the participant is no longer a member of the team.
*Scenario 2: Team not found
*Expectation: Attempts to remove a participant from a student team with an invalid team ID. The response status is 404, and the response body includes an error message indicating that the team was not found.
*Scenario 3: User not found
*Expectation: Attempts to remove a participant from a student team with an invalid user ID. The response status is 404, and the response body includes an error message indicating that the user was not found.

delete('remove participant') do
tags 'Student Teams'
produces 'application/json'
security [Bearer: {}]
response(204, 'successful') do
let(:Authorization) { "Bearer #{@token}" }
run_test! do
expect(response.status).to eq(204)
expect(team.members).not_to include(student)
end
end
response(404, 'team not found') do
let(:id) { -1 } # Invalid ID
run_test! do
expect(response.status).to eq(404)
expect(JSON.parse(response.body)['error']).to eq('Team not found.')
end
end
response(404, 'user not found') do
let(:student_id) { -1 } # Invalid student ID
run_test! do
expect(response.status).to eq(404)
expect(JSON.parse(response.body)['error']).to eq('User not found.')
end
end
end
end

===GitHub Pull Request===

https://github.com/expertiza/reimplementation-back-end/pull/136

===Demo Video===

https://www.youtube.com/watch?v=8_d_Y9EcgHc

===Mentor===

* Ammana, Sahithi <sammana@ncsu.edu>

===Team Members===

* Eathamukkala, Akarsh Reddy <aeatham@ncsu.edu>
* Koul, Anmol <akoul2@ncsu.edu>
* More, Harsh Manoj <hmore@ncsu.edu>

CSC/ECE 517 Fall 2024 - E2476. Reimplement student teams controller.rb

2024-12-04T04:48:43Z

Akoul2: /* Tasks Completed */

===Introduction===
[http://expertiza.ncsu.edu/ Expertiza] is an open-source system built on [http://rubyonrails.org/ Ruby on Rails], collaboratively maintained by students and faculty at NC State. This platform gives instructors extensive control over assignments, enabling them to add topics, create assignment groups, and manage peer reviews for various types of coursework. Expertiza is well-equipped to handle submissions across multiple formats, including URLs and wiki pages, and it offers a peer review system that facilitates constructive feedback among students.

A key focus of recent development in Expertiza has been the shift to a client-server architecture, where Ruby on Rails functions as the backend and React is utilized for the frontend. This architectural update requires reworking existing modules into RESTful API endpoints, allowing React components to interact efficiently with the backend. By adopting this approach, Expertiza aims to enhance modularity, performance, and scalability.

===Project Description===

The project mainly focuses on reimplementing the StudentTeamsController in Expertiza's backend, which is designed for student-facing operations where students participate in teams. This includes actions that directly affect individual team members, such as adding or removing students from teams, viewing team details, and managing their participation.

The TeamsController, on the other hand, is focused on instructor-driven operations that handle high-level team management across different contexts, such as courses and assignments. It manages operations like team creation, deletion, randomization, and bulk management actions.

===Problem Statement===

The current implementation of the StudentTeamsController in the Expertiza system is overly complex and tightly coupled, leading to difficulties in maintaining and extending the codebase. The controller is responsible for managing student teams in assignments, handling tasks like team creation, editing, management, and the integration of topics in assignments that require team-based decisions. However, it suffers from issues such as:
* Code redundancy and inefficiency due to business logic being embedded directly in the controller.
* Lack of modularity and poor separation of concerns, violating the Single Responsibility Principle (SRP). For example, it also handles the integration with topics when assignments involve choosing topics, complicating the team’s logic.
* Difficult-to-understand methods and tightly coupled logic for handling assignment-specific conditions, such as team-topic associations.
* Poor user feedback that does not provide clear or actionable information after critical operations.

These problems create a system that is hard to scale, maintain, and extend, especially as new features are added. To address these challenges, the goal is to reimplement the StudentTeamsController in the newer Expertiza backend codebase by adhering to object-oriented design principles, specifically focusing on maintainability, scalability, and modularity. The new design will improve the user experience by simplifying controller logic, providing clearer feedback, and ensuring that the system is easier to extend and maintain in the future.

===Objectives===

The main objective is to migrate the Student Task controller logic from serving HTML responses in the Ruby on Rails MVC model to returning JSON responses as a RESTful API, as part of the backend implementation. While reimplementing the controller, the following considerations will be incorporated to ensure a clean, maintainable, and scalable API:

*Reimplement the controller logic and write methods which appropriately follow the Single Responsibility Principle (SRP).
*Move business logic from the controller to appropriate model classes like Team or AssignmentTeam.
*Ensure all method names clearly describe their purpose and represent actions.
*Reimplement a Prototype pattern for creating mentored teams, leveraging the AssignmentTeam class.
*Automatically generate team names when a team is first referred to unless the user has specified a name when requesting team creation.
*Handle team requirements with better abstraction:
*Try to eliminate direct logic in the controller that checks for specific assignment requirements such as topic handling.
*Rename student_team_requirements_met? to something more descriptive and break it into smaller methods checking individual conditions.
*Aim to decouple topics from this controller entirely, ensuring better abstraction, that can involve changes to other classes or introducing service objects to handle specific requirements.
* Improve feedback to users and ensure that the user receives clear and actionable feedback after operations like team creation, removal of users, and other key actions.
* Add comprehensive comments throughout the controller, clearly explaining the purpose and functionality of custom methods.

===Development Strategy===

Our development strategy centers around Test-Driven Development (TDD) principles applied to refactoring the student_teams_controller.rb and other related classes such as Team or AssignmentTeam model. We design out test cases and iteratively refactor code to address identified inefficiencies while ensuring successful test outcomes.
Additionally, we emphasize on the strict adoption of SRP and DRY principles as per the object-oriented programming conventions. Our goal is to reimplement the existing functionalities
In the newly designed back-end foundation to foster a more efficient and organized codebase utilizing newer technologies. This approach will significantly enhance reusability and scalability across all the application while maintaining clean codebase.

Files Modified:
* Created ==>
** app/controllers/api/v1/student_teams_controller.rb
** app/models/assignment_team.rb
** app/models/team.rb
** spec/requests/api/v1/student_teams_controller_spec.rb
** db/migrate/20241201203840_create_assignment_teams.rb
** db/migrate/20241201220020_add_auto_assign_mentor_to_assignments.rb
** db/migrate/20241201221122_add_type_to_teams.rb
** db/migrate/20241202002102_add_name_to_teams.rb

* Updated ==>
** app/models/team.rb
** config/routes.rb
** db/schema.rb
** db/seeds.rb
** spec/swagger_helper.rb

===Project Design and Implementation===

The main approach to be followed throughout this project is to embrace the Prototyping Pattern within the controller while taking into account the current functionalities to be reimplemented within the student_teams_controller.rb that can capitalize its capability to encapsulate distinct controller actions. This strategic implementation aims to ensure seamless extensibility and enhanced usability. By employing this pattern, we establish a structured framework for defining and managing the diverse operations the controller handles, promoting a more organized and manageable code structure.

[[File:2476_UML.drawio.png]]

==== Functionality ====

1. Reimplement the Controller to Follow SRP:
* Break down large, complex methods into smaller, focused methods that adhere to the Single Responsibility Principle (SRP).
* Reimplement existing methods and logic while ensuring that each class and method have a clear, well-defined responsibility.
* Move business logic and complex operations out of the controller and into the appropriate model classes (e.g., Team, AssignmentTeam), ensuring the controller only handles HTTP-specific concerns (e.g., request handling, responses).

2. Improve Method Naming and Clarity:
* Ensure all method names are descriptive and represent the intent of the operation (e.g., renaming methods like student_team_requirements_met? to something more specific like validate_topic_requirements_for_team_creation).
* Adopt consistent naming conventions to improve the readability of the codebase.

3. Implement the Prototype Pattern for Team Creation:
* Leverage the Prototype pattern to create mentored teams through the AssignmentTeam class, allowing for easier management and creation of teams with a mentored structure.
* Automatically generate team names when a team is first created, unless a user has specified a custom name to improve the user experience and simplify team management.

4. Abstract Assignment-Specific Logic:
* Move logic related to assignment-specific requirements (e.g., topic handling) away from the controller, reducing complexity and increasing modularity.
* Introduce service objects or model methods to handle specific requirements like topic assignment, thereby decoupling assignment-related logic from the controller.
* Break down the student_team_requirements_met? method into smaller, more specific checks for different requirements (e.g., topic validation, minimum team size, etc.).

5. Improve User Feedback:
* Enhance the clarity and actionability of feedback messages after key operations (e.g., team creation, user removal, etc.).
* Provide users with clear, helpful notifications on the success or failure of their actions, including any necessary next steps or troubleshooting guidance.
* Ensure error handling is robust, and feedback is specific (e.g., specify which conditions were not met when creating or modifying teams).

6. Commenting and Documentation:
* Add comprehensive comments throughout the controller to clearly explain the purpose and functionality of custom methods and refactored logic.
* Ensure that code is well-documented, making it easier for future developers to understand and extend the functionality of the controller.

===Tasks Completed===

Methods:
* AssignmentTeam Model:
** To access every participant connected to an assignment, the assignment_participants method was added.
** For including a user in the assignment as a participant, the add_participant method was added.
** To see if the team has gotten any peer reviews, the received_any_peer_review? method was put into practice.
** Using a placeholder for future mentor assignment logic, the upgrade_to_mentored_team method was put into practice to replicate the present team and get it ready for mentoring.
** In order to ensure deep duplication of associated records (such as signed_up_teams, teams_users, and participants), the dup method was added to duplicate a team and its associations.

* Team Model:
** Improved the whole procedure to determine if a team has reached its maximum number of members.
** Counted the number of team members using the size approach, removing those with "(Mentor)" in their names.
** In order to eliminate duplicate members and check for team capacity, the add_member method was improved.
** To remove a user from the team, the remove_team_user method was put into place. If the team becomes empty and hasn't been subjected to any peer reviews, the team will be deleted.

* Controller - StudentTeamsController.rb
* index: Implemented in order to retrieve and restore every student team together with all of its members.
* show: Created to retrieve and provide information about a certain student team and its members.
* create: Added logic to create a new team for a student, using AssignmentTeam#upgraded_to_mentored_team for mentor-eligible teams and checking for existing team names.
* update: Implemented to enable team details, especially the team name, to be updated while ensuring unique team names through validations.
* destroy: To remove a certain team this was added and, if successful, deliver a 204 No Content response.
* remove_participant: Check if the user is part of the given team and removes from that team, also handles corner cases where no more participants are there in a team.
* add_participant: Added this to add the given participant to respective team.

===Testing Plan===

We have performed comprehensive testing of the student_teams_controller.rb and related classes using RSPEC and Swagger to construct the required test fixtures for testing extensive scenarios. Our approach involves reimplementing the existing test cases provided to the older code base and make sure that it is enhanced by covering more test scenarios to minimize code smells. We aim to verify the reimplemented functionality, validate the restructured code in the student_teams_controller.rb and reduce any design or code smell.
Below are the test scenarios for each of API endpoints -

1. List all Student Teams

*Description: List all student teams.
*Response: 200 OK
*Test Case Scenarios:
*Scenario 1: List all Student Teams
*Expectation: Successfully retrieves a list of all student teams. The response status is 200, the content type is `application/json`, and the response body contains 3 student teams.

RSpec.describe 'Student Teams API', type: :request do
path '/api/v1/student_teams' do
# List all Student Teams
get('List all Student Teams') do
tags 'Student Teams'
produces 'application/json'
security [Bearer: {}]
response(200, 'successful') do
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test!
end
end

2. Create a Student Team
*Description: Create a new student team.
*Response: 201 Created
*Test Data prep:
post 'Create a Student Team' do
tags 'Student Teams'
consumes 'application/json'
let(:institution) do
Institution.create!(
name: 'North Carolina State University'
)
end
let!(:instructor_role) { Role.find_or_create_by(name: 'Instructor') }
let!(:student_role) { Role.find_or_create_by(name: 'Student') }
let(:instructor_user) do
User.create!(
name: 'Dr. Ed Gehringer1',
email: 'gehringer@example.com',
password: 'password123',
full_name: 'admin admin',
institution_id: institution.id,
role_id: instructor_role.id,
handle: 'instructor'
)
end
let(:course) do
Course.create!(
name: '2476. Refactor',
directory_path: '/',
info: 'OODD',
private: false,
instructor_id: instructor_user.id,
institution_id: institution.id
)
end
let(:assignment) do
Assignment.create!(
title: 'Project 4 BRO',
description: '2476. Reimplementing',
course_id: course.id,
instructor_id: instructor_user.id
)
end
let!(:students) do
created_students = []
3.times do |i|
student = User.create!(
name: "Student #{i + 1}",
email: "Student#{i + 1}@gmail.com",
password: 'password123',
full_name: "Student #{i + 1}",
institution_id: institution.id,
role_id: student_role.id,
handle: "Student #{i + 1}"
)
AssignmentParticipant.create!(
assignment: assignment,
user: student,
handle: "Student #{i + 1}"
)
created_students << student
end
created_students
end
parameter name: :student_team_request, in: :body, schema: {
type: :object,
properties: {
team: {
type: :object,
properties: {
name: {type: :string}
}
},
student_id: { type: :integer}
}
}
security [Bearer: {}]
*Scenarios:
*Scenario 1: Successfully create a team
*Expectation: Successfully creates a new student team with a valid name and student ID. The response status is 201, and the response body includes the team name.
*Scenario 2: Team name is already in use (conflict)
*Attempts to create a student team with a name that is already in use.
*Expectation: The response status is 422, and the response body includes an error message indicating that the team name is already in use.
*Scenario 3: Invalid team creation (empty name)
*Expectation: Attempts to create a student team with an empty name. The response status is 422, and the response body includes an error message.

# Scenario 1: Successfully create a team
response(201, 'created') do
let(:student_team_request) do
{ team: {name: "HelloThere"}, student_id: students.first.id}
end
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test! do
expect(response.status).to eq(201)
end
end
# Scenario 2: Team name is already in use (conflict)
response(422, 'unprocessable entity') do
let(:existing_team) { create(:team, name: 'ABCD10', assignment_id: assignment.id) }
let(:team) do
post '/api/v1/student_teams', params: { team: { name: 'ABCD10' }, student_id: students.first.id }, as: :json
end
run_test! do
expect(response.status).to eq(422)
expect(response.body).to include('"error":"That team name is already in use."')
end
end
# Scenario 3: Invalid team creation (empty name)
response(422, 'unprocessable entity') do
let(:student_team_request) do
{ team: {name: ""}, student_id: students.first.id}
end
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test! do
expect(response.status).to eq(422)
expect(response.body).to include('error')
end
end
response(404, 'not_found') do
let(:team) do
post '/api/v1/student_teams', params: { team: { name: 'ABCD10' }, student_id: 0 }, as: :json
end
run_test! do
expect(response.status).to eq(404)
expect(response.body).to include('not found')
end
end
end

3. Update a Student Team
*Description: Update the details of a student team.
*Response: 200 OK
*Scenarios:
*Scenario 1: Team name updated successfully
*Expectation: Successfully updates the name of a student team. The response status is 200, and the response body includes the updated team name.
*Scenario 2: Invalid team update (empty name)
*Expectation: Attempts to update a student team with an empty name. The response status is 422, and the response body includes an error message indicating that the team name should not be empty.
*Scenario 3: Team name already in use
*Expectation: Attempts to update a student team with a name that is already in use. The response status is 422, and the response body includes an error message indicating that the team name is already in use.
*Scenario 4: Invalid team ID
*Expectation: Attempts to update a student team with a non-existent team ID. The response status is 404, and the response body includes an error message indicating that the team was not found.

patch('Update a Student Team') do
tags 'Student Teams'
consumes 'application/json'
produces 'application/json'
security [Bearer: {}]
parameter name: :student_team_request, in: :body, schema: {
type: :object,
properties: {
team: {
type: :object,
properties: {
name: {type: :string}
}
},
team_id: { type: :integer}
}
}
# Scenario 1: Team name updated successfully
response(200, 'successful') do
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test! do
expect(response.status).to eq(200)
end
end
# Scenario 2: Invalid team updation (empty name)
response(422, 'unprocessable entity') do
let(:student_team_request) do
{ team: {name: ""}, team_id: 2}
end
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test! do
expect(response.status).to eq(422)
expect(response.body).to include('Team name should not be empty')
end
end
# Scenario 3: Team Name already present
response(422, 'unprocessable entity') do
let(:existing_team) { create(:team, name: 'ABCD10', team_id: 3) }
let(:team) do
post '/api/v1/student_teams', params: { team: { name: 'ABCD10' }, team_id: 2 }, as: :json
end
run_test! do
expect(response.status).to eq(422)
expect(response.body).to include('"error":"That team name is already in use."')
end
end
#Scenario 4 : Invalid Team ID
response(404, 'not_found') do
let(:team) do
post '/api/v1/student_teams', params: { team: { name: 'ABCD10' }, team_id: 0 }, as: :json
end
run_test! do
expect(response.status).to eq(404)
expect(response.body).to include('not found')
end
end
end
end

4. Show a Student Team
*Description: Retrieve the details of a student team by its ID.
*Response: 200 OK
*Scenarios:
*Scenario 1: Show Student Team
*Expectation: Successfully retrieves the details of a student team by its ID. The response status is 200, and the response body includes the details of the student team.
*Scenario 2: Team not found
*Expectation: Attempts to retrieve the details of a student team with an invalid ID. The response status is 404, and the response body includes an error message indicating that the team was not found.
path '/api/v1/student_teams/{id}' do
parameter name: 'id', in: :path, type: :integer
# Get request on /api/v1/student_teams/{id} returns the response 200 succesful - when correct id passed is present in the database
get('Show a Student Team') do
tags 'Student Teams'
produces 'application/json'
security [Bearer: {}]
response(200, 'successful') do
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test! do
expect(response.status).to eq(200)
end
end
# Get request on /api/v1/student_teams/{id} returns the response 404 not found - when correct id passed is not present in the database
response(404, 'not_found') do
let(:id) { 'invalid' }
run_test! do
expect(response.status).to eq(404)
end
end
end

5. Delete a Student Team
*Description: Delete a student team by its ID.
*Response: 204 No Content
*Scenarios:
*Scenario 1: Successfully delete a student team
*Expectation: Successfully deletes a student team by its ID. The response status is 204, and the student team is no longer present in the database.
*Scenario 2: Team not found
*Expectation: Attempts to delete a student team with an invalid ID. The response status is 404, and the response body includes an error message indicating that the team was not found.

delete('Delete a Student Team') do
tags 'Student Teams'
produces 'application/json'
security [Bearer: {}]
# delete request on /api/v1/student_teams/{id} returns 204 succesful response when id present in the database is deleted successfully
response(204, 'successful') do
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: ''
}
}
end
run_test! do
expect(response.status).to eq(204)
end
end
# delete request on /api/v1/student_teams/{id} returns 404 not found response, when id is not present in the database
response(404, 'not found') do
let(:id) { 0 }
run_test! do
expect(response.status).to eq(404)
end
end
end
end

6. Add a Participant in Student Team
*Description: Add a participant to a student team.
*Response: 200 OK
*Test Data Prep
path '/api/v1/student_teams/{id}/add_participant' do
parameter name: 'id', in: :path, type: :integer, description: 'ID of Team'
parameter name: 'student_id', in: :query, type: :integer, description: 'ID of the Student'
let(:student) { create(:user, :student) }
let(:assignment) { create(:assignment) }
let(:student_participant) { create(:assignment_participant, user: student, assignment: assignment) }
let(:team) { create(:assignment_team, assignment: assignment) }
let(:id) { team.id }
let(:student_id) { student.id }
*Scenarios:
*Scenario 1: Successfully add a participant to a student team
*Expectation: Successfully adds a participant to a student team by their ID. The response status is 200, and the participant is added to the team.
patch('Add a participant to Student Team') do
tags 'Student Teams'
consumes 'application/json'
produces 'application/json'
security [Bearer: {}]
before do
team.add_member(student, assignment.id)
end
response(200, 'successful') do
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test!
end
end
end
7. Remove a Participant in Student Team
*Description: Remove a participant from a student team.
*Response: 204 No Content
*Test data prep:

path '/api/v1/student_teams/{id}/remove_participant' do
parameter name: 'id', in: :path, type: :integer, description: 'ID of Team'
parameter name: 'student_id', in: :query, type: :integer, description: 'ID of the Student'
let(:student) { create(:user, :student) }
let(:assignment) { create(:assignment) }
let(:student_participant) { create(:assignment_participant, user: student, assignment: assignment) }
let(:team) { create(:assignment_team, assignment: assignment) }
let(:id) { team.id }
let(:student_id) { student.id }
before do
team.add_member(student, assignment.id)
end
*Scenarios:
*Scenario 1: Successfully remove a participant from a student team
*Expectation: Successfully removes a participant from a student team by their ID. The response status is 204, and the participant is no longer a member of the team.
*Scenario 2: Team not found
*Expectation: Attempts to remove a participant from a student team with an invalid team ID. The response status is 404, and the response body includes an error message indicating that the team was not found.
*Scenario 3: User not found
*Expectation: Attempts to remove a participant from a student team with an invalid user ID. The response status is 404, and the response body includes an error message indicating that the user was not found.

delete('remove participant') do
tags 'Student Teams'
produces 'application/json'
security [Bearer: {}]
response(204, 'successful') do
let(:Authorization) { "Bearer #{@token}" }
run_test! do
expect(response.status).to eq(204)
expect(team.members).not_to include(student)
end
end
response(404, 'team not found') do
let(:id) { -1 } # Invalid ID
run_test! do
expect(response.status).to eq(404)
expect(JSON.parse(response.body)['error']).to eq('Team not found.')
end
end
response(404, 'user not found') do
let(:student_id) { -1 } # Invalid student ID
run_test! do
expect(response.status).to eq(404)
expect(JSON.parse(response.body)['error']).to eq('User not found.')
end
end
end
end

===GitHub Pull Request===

https://github.com/expertiza/reimplementation-back-end/pull/136

===Demo Video===

https://www.youtube.com/watch?v=8_d_Y9EcgHc

===Mentor===

* Ammana, Sahithi <sammana@ncsu.edu>

===Team Members===

* Eathamukkala, Akarsh Reddy <aeatham@ncsu.edu>
* Koul, Anmol <akoul2@ncsu.edu>
* More, Harsh Manoj <hmore@ncsu.edu>

CSC/ECE 517 Fall 2024 - E2476. Reimplement student teams controller.rb

2024-12-04T04:46:07Z

Akoul2: /* Testing Plan */

===Introduction===
[http://expertiza.ncsu.edu/ Expertiza] is an open-source system built on [http://rubyonrails.org/ Ruby on Rails], collaboratively maintained by students and faculty at NC State. This platform gives instructors extensive control over assignments, enabling them to add topics, create assignment groups, and manage peer reviews for various types of coursework. Expertiza is well-equipped to handle submissions across multiple formats, including URLs and wiki pages, and it offers a peer review system that facilitates constructive feedback among students.

A key focus of recent development in Expertiza has been the shift to a client-server architecture, where Ruby on Rails functions as the backend and React is utilized for the frontend. This architectural update requires reworking existing modules into RESTful API endpoints, allowing React components to interact efficiently with the backend. By adopting this approach, Expertiza aims to enhance modularity, performance, and scalability.

===Project Description===

The project mainly focuses on reimplementing the StudentTeamsController in Expertiza's backend, which is designed for student-facing operations where students participate in teams. This includes actions that directly affect individual team members, such as adding or removing students from teams, viewing team details, and managing their participation.

The TeamsController, on the other hand, is focused on instructor-driven operations that handle high-level team management across different contexts, such as courses and assignments. It manages operations like team creation, deletion, randomization, and bulk management actions.

===Problem Statement===

The current implementation of the StudentTeamsController in the Expertiza system is overly complex and tightly coupled, leading to difficulties in maintaining and extending the codebase. The controller is responsible for managing student teams in assignments, handling tasks like team creation, editing, management, and the integration of topics in assignments that require team-based decisions. However, it suffers from issues such as:
* Code redundancy and inefficiency due to business logic being embedded directly in the controller.
* Lack of modularity and poor separation of concerns, violating the Single Responsibility Principle (SRP). For example, it also handles the integration with topics when assignments involve choosing topics, complicating the team’s logic.
* Difficult-to-understand methods and tightly coupled logic for handling assignment-specific conditions, such as team-topic associations.
* Poor user feedback that does not provide clear or actionable information after critical operations.

These problems create a system that is hard to scale, maintain, and extend, especially as new features are added. To address these challenges, the goal is to reimplement the StudentTeamsController in the newer Expertiza backend codebase by adhering to object-oriented design principles, specifically focusing on maintainability, scalability, and modularity. The new design will improve the user experience by simplifying controller logic, providing clearer feedback, and ensuring that the system is easier to extend and maintain in the future.

===Objectives===

The main objective is to migrate the Student Task controller logic from serving HTML responses in the Ruby on Rails MVC model to returning JSON responses as a RESTful API, as part of the backend implementation. While reimplementing the controller, the following considerations will be incorporated to ensure a clean, maintainable, and scalable API:

*Reimplement the controller logic and write methods which appropriately follow the Single Responsibility Principle (SRP).
*Move business logic from the controller to appropriate model classes like Team or AssignmentTeam.
*Ensure all method names clearly describe their purpose and represent actions.
*Reimplement a Prototype pattern for creating mentored teams, leveraging the AssignmentTeam class.
*Automatically generate team names when a team is first referred to unless the user has specified a name when requesting team creation.
*Handle team requirements with better abstraction:
*Try to eliminate direct logic in the controller that checks for specific assignment requirements such as topic handling.
*Rename student_team_requirements_met? to something more descriptive and break it into smaller methods checking individual conditions.
*Aim to decouple topics from this controller entirely, ensuring better abstraction, that can involve changes to other classes or introducing service objects to handle specific requirements.
* Improve feedback to users and ensure that the user receives clear and actionable feedback after operations like team creation, removal of users, and other key actions.
* Add comprehensive comments throughout the controller, clearly explaining the purpose and functionality of custom methods.

===Development Strategy===

Our development strategy centers around Test-Driven Development (TDD) principles applied to refactoring the student_teams_controller.rb and other related classes such as Team or AssignmentTeam model. We design out test cases and iteratively refactor code to address identified inefficiencies while ensuring successful test outcomes.
Additionally, we emphasize on the strict adoption of SRP and DRY principles as per the object-oriented programming conventions. Our goal is to reimplement the existing functionalities
In the newly designed back-end foundation to foster a more efficient and organized codebase utilizing newer technologies. This approach will significantly enhance reusability and scalability across all the application while maintaining clean codebase.

Files Modified:
* Created ==>
** app/controllers/api/v1/student_teams_controller.rb
** app/models/assignment_team.rb
** app/models/team.rb
** spec/requests/api/v1/student_teams_controller_spec.rb
** db/migrate/20241201203840_create_assignment_teams.rb
** db/migrate/20241201220020_add_auto_assign_mentor_to_assignments.rb
** db/migrate/20241201221122_add_type_to_teams.rb
** db/migrate/20241202002102_add_name_to_teams.rb

* Updated ==>
** app/models/team.rb
** config/routes.rb
** db/schema.rb
** db/seeds.rb
** spec/swagger_helper.rb

===Project Design and Implementation===

The main approach to be followed throughout this project is to embrace the Prototyping Pattern within the controller while taking into account the current functionalities to be reimplemented within the student_teams_controller.rb that can capitalize its capability to encapsulate distinct controller actions. This strategic implementation aims to ensure seamless extensibility and enhanced usability. By employing this pattern, we establish a structured framework for defining and managing the diverse operations the controller handles, promoting a more organized and manageable code structure.

[[File:2476_UML.drawio.png]]

==== Functionality ====

1. Reimplement the Controller to Follow SRP:
* Break down large, complex methods into smaller, focused methods that adhere to the Single Responsibility Principle (SRP).
* Reimplement existing methods and logic while ensuring that each class and method have a clear, well-defined responsibility.
* Move business logic and complex operations out of the controller and into the appropriate model classes (e.g., Team, AssignmentTeam), ensuring the controller only handles HTTP-specific concerns (e.g., request handling, responses).

2. Improve Method Naming and Clarity:
* Ensure all method names are descriptive and represent the intent of the operation (e.g., renaming methods like student_team_requirements_met? to something more specific like validate_topic_requirements_for_team_creation).
* Adopt consistent naming conventions to improve the readability of the codebase.

3. Implement the Prototype Pattern for Team Creation:
* Leverage the Prototype pattern to create mentored teams through the AssignmentTeam class, allowing for easier management and creation of teams with a mentored structure.
* Automatically generate team names when a team is first created, unless a user has specified a custom name to improve the user experience and simplify team management.

4. Abstract Assignment-Specific Logic:
* Move logic related to assignment-specific requirements (e.g., topic handling) away from the controller, reducing complexity and increasing modularity.
* Introduce service objects or model methods to handle specific requirements like topic assignment, thereby decoupling assignment-related logic from the controller.
* Break down the student_team_requirements_met? method into smaller, more specific checks for different requirements (e.g., topic validation, minimum team size, etc.).

5. Improve User Feedback:
* Enhance the clarity and actionability of feedback messages after key operations (e.g., team creation, user removal, etc.).
* Provide users with clear, helpful notifications on the success or failure of their actions, including any necessary next steps or troubleshooting guidance.
* Ensure error handling is robust, and feedback is specific (e.g., specify which conditions were not met when creating or modifying teams).

6. Commenting and Documentation:
* Add comprehensive comments throughout the controller to clearly explain the purpose and functionality of custom methods and refactored logic.
* Ensure that code is well-documented, making it easier for future developers to understand and extend the functionality of the controller.

===Tasks Completed===

Methods:
* AssignmentTeam Model:
** To access every participant connected to an assignment, the assignment_participants method was added.
** For including a user in the assignment as a participant, the add_participant method was added.
** To see if the team has gotten any peer reviews, the received_any_peer_review? method was put into practice.
** Using a placeholder for future mentor assignment logic, the upgrade_to_mentored_team method was put into practice to replicate the present team and get it ready for mentoring.
** In order to ensure deep duplication of associated records (such as signed_up_teams, teams_users, and participants), the dup method was added to duplicate a team and its associations.

* Team Model:
** Improved the whole procedure to determine if a team has reached its maximum number of members.
** Counted the number of team members using the size approach, removing those with "(Mentor)" in their names.
** In order to eliminate duplicate members and check for team capacity, the add_member method was improved.
** To remove a user from the team, the remove_team_user method was put into place. If the team becomes empty and hasn't been subjected to any peer reviews, the team will be deleted.

Controller - StudentTeamsController.rb
* index: Implemented in order to retrieve and restore every student team together with all of its members.
* show: Created to retrieve and provide information about a certain student team and its members.
* create: Added logic to create a new team for a student, using AssignmentTeam#upgraded_to_mentored_team for mentor-eligible teams and checking for existing team names.
* update: Implemented to enable team details, especially the team name, to be updated while ensuring unique team names through validations.
* destroy: To remove a certain team this was added and, if successful, deliver a 204 No Content response.
* remove_participant: Check if the user is part of the given team and removes from that team, also handles corner cases where no more participants are there in a team.
* add_participant: Added this to add the given participant to respective team.

===Testing Plan===

We have performed comprehensive testing of the student_teams_controller.rb and related classes using RSPEC and Swagger to construct the required test fixtures for testing extensive scenarios. Our approach involves reimplementing the existing test cases provided to the older code base and make sure that it is enhanced by covering more test scenarios to minimize code smells. We aim to verify the reimplemented functionality, validate the restructured code in the student_teams_controller.rb and reduce any design or code smell.
Below are the test scenarios for each of API endpoints -

1. List all Student Teams

*Description: List all student teams.
*Response: 200 OK
*Test Case Scenarios:
*Scenario 1: List all Student Teams
*Expectation: Successfully retrieves a list of all student teams. The response status is 200, the content type is `application/json`, and the response body contains 3 student teams.

RSpec.describe 'Student Teams API', type: :request do
path '/api/v1/student_teams' do
# List all Student Teams
get('List all Student Teams') do
tags 'Student Teams'
produces 'application/json'
security [Bearer: {}]
response(200, 'successful') do
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test!
end
end

2. Create a Student Team
*Description: Create a new student team.
*Response: 201 Created
*Test Data prep:
post 'Create a Student Team' do
tags 'Student Teams'
consumes 'application/json'
let(:institution) do
Institution.create!(
name: 'North Carolina State University'
)
end
let!(:instructor_role) { Role.find_or_create_by(name: 'Instructor') }
let!(:student_role) { Role.find_or_create_by(name: 'Student') }
let(:instructor_user) do
User.create!(
name: 'Dr. Ed Gehringer1',
email: 'gehringer@example.com',
password: 'password123',
full_name: 'admin admin',
institution_id: institution.id,
role_id: instructor_role.id,
handle: 'instructor'
)
end
let(:course) do
Course.create!(
name: '2476. Refactor',
directory_path: '/',
info: 'OODD',
private: false,
instructor_id: instructor_user.id,
institution_id: institution.id
)
end
let(:assignment) do
Assignment.create!(
title: 'Project 4 BRO',
description: '2476. Reimplementing',
course_id: course.id,
instructor_id: instructor_user.id
)
end
let!(:students) do
created_students = []
3.times do |i|
student = User.create!(
name: "Student #{i + 1}",
email: "Student#{i + 1}@gmail.com",
password: 'password123',
full_name: "Student #{i + 1}",
institution_id: institution.id,
role_id: student_role.id,
handle: "Student #{i + 1}"
)
AssignmentParticipant.create!(
assignment: assignment,
user: student,
handle: "Student #{i + 1}"
)
created_students << student
end
created_students
end
parameter name: :student_team_request, in: :body, schema: {
type: :object,
properties: {
team: {
type: :object,
properties: {
name: {type: :string}
}
},
student_id: { type: :integer}
}
}
security [Bearer: {}]
*Scenarios:
*Scenario 1: Successfully create a team
*Expectation: Successfully creates a new student team with a valid name and student ID. The response status is 201, and the response body includes the team name.
*Scenario 2: Team name is already in use (conflict)
*Attempts to create a student team with a name that is already in use.
*Expectation: The response status is 422, and the response body includes an error message indicating that the team name is already in use.
*Scenario 3: Invalid team creation (empty name)
*Expectation: Attempts to create a student team with an empty name. The response status is 422, and the response body includes an error message.

# Scenario 1: Successfully create a team
response(201, 'created') do
let(:student_team_request) do
{ team: {name: "HelloThere"}, student_id: students.first.id}
end
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test! do
expect(response.status).to eq(201)
end
end
# Scenario 2: Team name is already in use (conflict)
response(422, 'unprocessable entity') do
let(:existing_team) { create(:team, name: 'ABCD10', assignment_id: assignment.id) }
let(:team) do
post '/api/v1/student_teams', params: { team: { name: 'ABCD10' }, student_id: students.first.id }, as: :json
end
run_test! do
expect(response.status).to eq(422)
expect(response.body).to include('"error":"That team name is already in use."')
end
end
# Scenario 3: Invalid team creation (empty name)
response(422, 'unprocessable entity') do
let(:student_team_request) do
{ team: {name: ""}, student_id: students.first.id}
end
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test! do
expect(response.status).to eq(422)
expect(response.body).to include('error')
end
end
response(404, 'not_found') do
let(:team) do
post '/api/v1/student_teams', params: { team: { name: 'ABCD10' }, student_id: 0 }, as: :json
end
run_test! do
expect(response.status).to eq(404)
expect(response.body).to include('not found')
end
end
end

3. Update a Student Team
*Description: Update the details of a student team.
*Response: 200 OK
*Scenarios:
*Scenario 1: Team name updated successfully
*Expectation: Successfully updates the name of a student team. The response status is 200, and the response body includes the updated team name.
*Scenario 2: Invalid team update (empty name)
*Expectation: Attempts to update a student team with an empty name. The response status is 422, and the response body includes an error message indicating that the team name should not be empty.
*Scenario 3: Team name already in use
*Expectation: Attempts to update a student team with a name that is already in use. The response status is 422, and the response body includes an error message indicating that the team name is already in use.
*Scenario 4: Invalid team ID
*Expectation: Attempts to update a student team with a non-existent team ID. The response status is 404, and the response body includes an error message indicating that the team was not found.

patch('Update a Student Team') do
tags 'Student Teams'
consumes 'application/json'
produces 'application/json'
security [Bearer: {}]
parameter name: :student_team_request, in: :body, schema: {
type: :object,
properties: {
team: {
type: :object,
properties: {
name: {type: :string}
}
},
team_id: { type: :integer}
}
}
# Scenario 1: Team name updated successfully
response(200, 'successful') do
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test! do
expect(response.status).to eq(200)
end
end
# Scenario 2: Invalid team updation (empty name)
response(422, 'unprocessable entity') do
let(:student_team_request) do
{ team: {name: ""}, team_id: 2}
end
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test! do
expect(response.status).to eq(422)
expect(response.body).to include('Team name should not be empty')
end
end
# Scenario 3: Team Name already present
response(422, 'unprocessable entity') do
let(:existing_team) { create(:team, name: 'ABCD10', team_id: 3) }
let(:team) do
post '/api/v1/student_teams', params: { team: { name: 'ABCD10' }, team_id: 2 }, as: :json
end
run_test! do
expect(response.status).to eq(422)
expect(response.body).to include('"error":"That team name is already in use."')
end
end
#Scenario 4 : Invalid Team ID
response(404, 'not_found') do
let(:team) do
post '/api/v1/student_teams', params: { team: { name: 'ABCD10' }, team_id: 0 }, as: :json
end
run_test! do
expect(response.status).to eq(404)
expect(response.body).to include('not found')
end
end
end
end

4. Show a Student Team
*Description: Retrieve the details of a student team by its ID.
*Response: 200 OK
*Scenarios:
*Scenario 1: Show Student Team
*Expectation: Successfully retrieves the details of a student team by its ID. The response status is 200, and the response body includes the details of the student team.
*Scenario 2: Team not found
*Expectation: Attempts to retrieve the details of a student team with an invalid ID. The response status is 404, and the response body includes an error message indicating that the team was not found.
path '/api/v1/student_teams/{id}' do
parameter name: 'id', in: :path, type: :integer
# Get request on /api/v1/student_teams/{id} returns the response 200 succesful - when correct id passed is present in the database
get('Show a Student Team') do
tags 'Student Teams'
produces 'application/json'
security [Bearer: {}]
response(200, 'successful') do
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test! do
expect(response.status).to eq(200)
end
end
# Get request on /api/v1/student_teams/{id} returns the response 404 not found - when correct id passed is not present in the database
response(404, 'not_found') do
let(:id) { 'invalid' }
run_test! do
expect(response.status).to eq(404)
end
end
end

5. Delete a Student Team
*Description: Delete a student team by its ID.
*Response: 204 No Content
*Scenarios:
*Scenario 1: Successfully delete a student team
*Expectation: Successfully deletes a student team by its ID. The response status is 204, and the student team is no longer present in the database.
*Scenario 2: Team not found
*Expectation: Attempts to delete a student team with an invalid ID. The response status is 404, and the response body includes an error message indicating that the team was not found.

delete('Delete a Student Team') do
tags 'Student Teams'
produces 'application/json'
security [Bearer: {}]
# delete request on /api/v1/student_teams/{id} returns 204 succesful response when id present in the database is deleted successfully
response(204, 'successful') do
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: ''
}
}
end
run_test! do
expect(response.status).to eq(204)
end
end
# delete request on /api/v1/student_teams/{id} returns 404 not found response, when id is not present in the database
response(404, 'not found') do
let(:id) { 0 }
run_test! do
expect(response.status).to eq(404)
end
end
end
end

6. Add a Participant in Student Team
*Description: Add a participant to a student team.
*Response: 200 OK
*Test Data Prep
path '/api/v1/student_teams/{id}/add_participant' do
parameter name: 'id', in: :path, type: :integer, description: 'ID of Team'
parameter name: 'student_id', in: :query, type: :integer, description: 'ID of the Student'
let(:student) { create(:user, :student) }
let(:assignment) { create(:assignment) }
let(:student_participant) { create(:assignment_participant, user: student, assignment: assignment) }
let(:team) { create(:assignment_team, assignment: assignment) }
let(:id) { team.id }
let(:student_id) { student.id }
*Scenarios:
*Scenario 1: Successfully add a participant to a student team
*Expectation: Successfully adds a participant to a student team by their ID. The response status is 200, and the participant is added to the team.
patch('Add a participant to Student Team') do
tags 'Student Teams'
consumes 'application/json'
produces 'application/json'
security [Bearer: {}]
before do
team.add_member(student, assignment.id)
end
response(200, 'successful') do
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test!
end
end
end
7. Remove a Participant in Student Team
*Description: Remove a participant from a student team.
*Response: 204 No Content
*Test data prep:

path '/api/v1/student_teams/{id}/remove_participant' do
parameter name: 'id', in: :path, type: :integer, description: 'ID of Team'
parameter name: 'student_id', in: :query, type: :integer, description: 'ID of the Student'
let(:student) { create(:user, :student) }
let(:assignment) { create(:assignment) }
let(:student_participant) { create(:assignment_participant, user: student, assignment: assignment) }
let(:team) { create(:assignment_team, assignment: assignment) }
let(:id) { team.id }
let(:student_id) { student.id }
before do
team.add_member(student, assignment.id)
end
*Scenarios:
*Scenario 1: Successfully remove a participant from a student team
*Expectation: Successfully removes a participant from a student team by their ID. The response status is 204, and the participant is no longer a member of the team.
*Scenario 2: Team not found
*Expectation: Attempts to remove a participant from a student team with an invalid team ID. The response status is 404, and the response body includes an error message indicating that the team was not found.
*Scenario 3: User not found
*Expectation: Attempts to remove a participant from a student team with an invalid user ID. The response status is 404, and the response body includes an error message indicating that the user was not found.

delete('remove participant') do
tags 'Student Teams'
produces 'application/json'
security [Bearer: {}]
response(204, 'successful') do
let(:Authorization) { "Bearer #{@token}" }
run_test! do
expect(response.status).to eq(204)
expect(team.members).not_to include(student)
end
end
response(404, 'team not found') do
let(:id) { -1 } # Invalid ID
run_test! do
expect(response.status).to eq(404)
expect(JSON.parse(response.body)['error']).to eq('Team not found.')
end
end
response(404, 'user not found') do
let(:student_id) { -1 } # Invalid student ID
run_test! do
expect(response.status).to eq(404)
expect(JSON.parse(response.body)['error']).to eq('User not found.')
end
end
end
end

===GitHub Pull Request===

https://github.com/expertiza/reimplementation-back-end/pull/136

===Demo Video===

https://www.youtube.com/watch?v=8_d_Y9EcgHc

===Mentor===

* Ammana, Sahithi <sammana@ncsu.edu>

===Team Members===

* Eathamukkala, Akarsh Reddy <aeatham@ncsu.edu>
* Koul, Anmol <akoul2@ncsu.edu>
* More, Harsh Manoj <hmore@ncsu.edu>

CSC/ECE 517 Fall 2024 - E2476. Reimplement student teams controller.rb

2024-12-04T04:44:13Z

Akoul2: /* Testing Plan */

===Introduction===
[http://expertiza.ncsu.edu/ Expertiza] is an open-source system built on [http://rubyonrails.org/ Ruby on Rails], collaboratively maintained by students and faculty at NC State. This platform gives instructors extensive control over assignments, enabling them to add topics, create assignment groups, and manage peer reviews for various types of coursework. Expertiza is well-equipped to handle submissions across multiple formats, including URLs and wiki pages, and it offers a peer review system that facilitates constructive feedback among students.

A key focus of recent development in Expertiza has been the shift to a client-server architecture, where Ruby on Rails functions as the backend and React is utilized for the frontend. This architectural update requires reworking existing modules into RESTful API endpoints, allowing React components to interact efficiently with the backend. By adopting this approach, Expertiza aims to enhance modularity, performance, and scalability.

===Project Description===

The project mainly focuses on reimplementing the StudentTeamsController in Expertiza's backend, which is designed for student-facing operations where students participate in teams. This includes actions that directly affect individual team members, such as adding or removing students from teams, viewing team details, and managing their participation.

The TeamsController, on the other hand, is focused on instructor-driven operations that handle high-level team management across different contexts, such as courses and assignments. It manages operations like team creation, deletion, randomization, and bulk management actions.

===Problem Statement===

The current implementation of the StudentTeamsController in the Expertiza system is overly complex and tightly coupled, leading to difficulties in maintaining and extending the codebase. The controller is responsible for managing student teams in assignments, handling tasks like team creation, editing, management, and the integration of topics in assignments that require team-based decisions. However, it suffers from issues such as:
* Code redundancy and inefficiency due to business logic being embedded directly in the controller.
* Lack of modularity and poor separation of concerns, violating the Single Responsibility Principle (SRP). For example, it also handles the integration with topics when assignments involve choosing topics, complicating the team’s logic.
* Difficult-to-understand methods and tightly coupled logic for handling assignment-specific conditions, such as team-topic associations.
* Poor user feedback that does not provide clear or actionable information after critical operations.

These problems create a system that is hard to scale, maintain, and extend, especially as new features are added. To address these challenges, the goal is to reimplement the StudentTeamsController in the newer Expertiza backend codebase by adhering to object-oriented design principles, specifically focusing on maintainability, scalability, and modularity. The new design will improve the user experience by simplifying controller logic, providing clearer feedback, and ensuring that the system is easier to extend and maintain in the future.

===Objectives===

The main objective is to migrate the Student Task controller logic from serving HTML responses in the Ruby on Rails MVC model to returning JSON responses as a RESTful API, as part of the backend implementation. While reimplementing the controller, the following considerations will be incorporated to ensure a clean, maintainable, and scalable API:

*Reimplement the controller logic and write methods which appropriately follow the Single Responsibility Principle (SRP).
*Move business logic from the controller to appropriate model classes like Team or AssignmentTeam.
*Ensure all method names clearly describe their purpose and represent actions.
*Reimplement a Prototype pattern for creating mentored teams, leveraging the AssignmentTeam class.
*Automatically generate team names when a team is first referred to unless the user has specified a name when requesting team creation.
*Handle team requirements with better abstraction:
*Try to eliminate direct logic in the controller that checks for specific assignment requirements such as topic handling.
*Rename student_team_requirements_met? to something more descriptive and break it into smaller methods checking individual conditions.
*Aim to decouple topics from this controller entirely, ensuring better abstraction, that can involve changes to other classes or introducing service objects to handle specific requirements.
* Improve feedback to users and ensure that the user receives clear and actionable feedback after operations like team creation, removal of users, and other key actions.
* Add comprehensive comments throughout the controller, clearly explaining the purpose and functionality of custom methods.

===Development Strategy===

Our development strategy centers around Test-Driven Development (TDD) principles applied to refactoring the student_teams_controller.rb and other related classes such as Team or AssignmentTeam model. We design out test cases and iteratively refactor code to address identified inefficiencies while ensuring successful test outcomes.
Additionally, we emphasize on the strict adoption of SRP and DRY principles as per the object-oriented programming conventions. Our goal is to reimplement the existing functionalities
In the newly designed back-end foundation to foster a more efficient and organized codebase utilizing newer technologies. This approach will significantly enhance reusability and scalability across all the application while maintaining clean codebase.

Files Modified:
* Created ==>
** app/controllers/api/v1/student_teams_controller.rb
** app/models/assignment_team.rb
** app/models/team.rb
** spec/requests/api/v1/student_teams_controller_spec.rb
** db/migrate/20241201203840_create_assignment_teams.rb
** db/migrate/20241201220020_add_auto_assign_mentor_to_assignments.rb
** db/migrate/20241201221122_add_type_to_teams.rb
** db/migrate/20241202002102_add_name_to_teams.rb

* Updated ==>
** app/models/team.rb
** config/routes.rb
** db/schema.rb
** db/seeds.rb
** spec/swagger_helper.rb

===Project Design and Implementation===

The main approach to be followed throughout this project is to embrace the Prototyping Pattern within the controller while taking into account the current functionalities to be reimplemented within the student_teams_controller.rb that can capitalize its capability to encapsulate distinct controller actions. This strategic implementation aims to ensure seamless extensibility and enhanced usability. By employing this pattern, we establish a structured framework for defining and managing the diverse operations the controller handles, promoting a more organized and manageable code structure.

[[File:2476_UML.drawio.png]]

==== Functionality ====

1. Reimplement the Controller to Follow SRP:
* Break down large, complex methods into smaller, focused methods that adhere to the Single Responsibility Principle (SRP).
* Reimplement existing methods and logic while ensuring that each class and method have a clear, well-defined responsibility.
* Move business logic and complex operations out of the controller and into the appropriate model classes (e.g., Team, AssignmentTeam), ensuring the controller only handles HTTP-specific concerns (e.g., request handling, responses).

2. Improve Method Naming and Clarity:
* Ensure all method names are descriptive and represent the intent of the operation (e.g., renaming methods like student_team_requirements_met? to something more specific like validate_topic_requirements_for_team_creation).
* Adopt consistent naming conventions to improve the readability of the codebase.

3. Implement the Prototype Pattern for Team Creation:
* Leverage the Prototype pattern to create mentored teams through the AssignmentTeam class, allowing for easier management and creation of teams with a mentored structure.
* Automatically generate team names when a team is first created, unless a user has specified a custom name to improve the user experience and simplify team management.

4. Abstract Assignment-Specific Logic:
* Move logic related to assignment-specific requirements (e.g., topic handling) away from the controller, reducing complexity and increasing modularity.
* Introduce service objects or model methods to handle specific requirements like topic assignment, thereby decoupling assignment-related logic from the controller.
* Break down the student_team_requirements_met? method into smaller, more specific checks for different requirements (e.g., topic validation, minimum team size, etc.).

5. Improve User Feedback:
* Enhance the clarity and actionability of feedback messages after key operations (e.g., team creation, user removal, etc.).
* Provide users with clear, helpful notifications on the success or failure of their actions, including any necessary next steps or troubleshooting guidance.
* Ensure error handling is robust, and feedback is specific (e.g., specify which conditions were not met when creating or modifying teams).

6. Commenting and Documentation:
* Add comprehensive comments throughout the controller to clearly explain the purpose and functionality of custom methods and refactored logic.
* Ensure that code is well-documented, making it easier for future developers to understand and extend the functionality of the controller.

===Tasks Completed===

Methods:
* AssignmentTeam Model:
** To access every participant connected to an assignment, the assignment_participants method was added.
** For including a user in the assignment as a participant, the add_participant method was added.
** To see if the team has gotten any peer reviews, the received_any_peer_review? method was put into practice.
** Using a placeholder for future mentor assignment logic, the upgrade_to_mentored_team method was put into practice to replicate the present team and get it ready for mentoring.
** In order to ensure deep duplication of associated records (such as signed_up_teams, teams_users, and participants), the dup method was added to duplicate a team and its associations.

* Team Model:
** Improved the whole procedure to determine if a team has reached its maximum number of members.
** Counted the number of team members using the size approach, removing those with "(Mentor)" in their names.
** In order to eliminate duplicate members and check for team capacity, the add_member method was improved.
** To remove a user from the team, the remove_team_user method was put into place. If the team becomes empty and hasn't been subjected to any peer reviews, the team will be deleted.

Controller - StudentTeamsController.rb
* index: Implemented in order to retrieve and restore every student team together with all of its members.
* show: Created to retrieve and provide information about a certain student team and its members.
* create: Added logic to create a new team for a student, using AssignmentTeam#upgraded_to_mentored_team for mentor-eligible teams and checking for existing team names.
* update: Implemented to enable team details, especially the team name, to be updated while ensuring unique team names through validations.
* destroy: To remove a certain team this was added and, if successful, deliver a 204 No Content response.
* remove_participant: Check if the user is part of the given team and removes from that team, also handles corner cases where no more participants are there in a team.
* add_participant: Added this to add the given participant to respective team.

===Testing Plan===

We have performed comprehensive testing of the student_teams_controller.rb and related classes using RSPEC and Swagger to construct the required test fixtures for testing extensive scenarios. Our approach involves reimplementing the existing test cases provided to the older code base and make sure that it is enhanced by covering more test scenarios to minimize code smells. We aim to verify the reimplemented functionality, validate the restructured code in the student_teams_controller.rb and reduce any design or code smell.
Below are the test scenarios for each of API endpoints -

1. List all Student Teams

*Description: List all student teams.
*Response: 200 OK
*Test Case Scenarios:
*Scenario 1: List all Student Teams
*Successfully retrieves a list of all student teams.
*Expectation: The response status is 200, the content type is `application/json`, and the response body contains 3 student teams.

RSpec.describe 'Student Teams API', type: :request do
path '/api/v1/student_teams' do
# List all Student Teams
get('List all Student Teams') do
tags 'Student Teams'
produces 'application/json'
security [Bearer: {}]
response(200, 'successful') do
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test!
end
end

2. Create a Student Team
*Description: Create a new student team.
*Response: 201 Created
*Test Data prep:
post 'Create a Student Team' do
tags 'Student Teams'
consumes 'application/json'
let(:institution) do
Institution.create!(
name: 'North Carolina State University'
)
end
let!(:instructor_role) { Role.find_or_create_by(name: 'Instructor') }
let!(:student_role) { Role.find_or_create_by(name: 'Student') }
let(:instructor_user) do
User.create!(
name: 'Dr. Ed Gehringer1',
email: 'gehringer@example.com',
password: 'password123',
full_name: 'admin admin',
institution_id: institution.id,
role_id: instructor_role.id,
handle: 'instructor'
)
end
let(:course) do
Course.create!(
name: '2476. Refactor',
directory_path: '/',
info: 'OODD',
private: false,
instructor_id: instructor_user.id,
institution_id: institution.id
)
end
let(:assignment) do
Assignment.create!(
title: 'Project 4 BRO',
description: '2476. Reimplementing',
course_id: course.id,
instructor_id: instructor_user.id
)
end
let!(:students) do
created_students = []
3.times do |i|
student = User.create!(
name: "Student #{i + 1}",
email: "Student#{i + 1}@gmail.com",
password: 'password123',
full_name: "Student #{i + 1}",
institution_id: institution.id,
role_id: student_role.id,
handle: "Student #{i + 1}"
)
AssignmentParticipant.create!(
assignment: assignment,
user: student,
handle: "Student #{i + 1}"
)
created_students << student
end
created_students
end
parameter name: :student_team_request, in: :body, schema: {
type: :object,
properties: {
team: {
type: :object,
properties: {
name: {type: :string}
}
},
student_id: { type: :integer}
}
}
security [Bearer: {}]
*Scenarios:
*Scenario 1: Successfully create a team
*Expectation: Successfully creates a new student team with a valid name and student ID. The response status is 201, and the response body includes the team name.
*Scenario 2: Team name is already in use (conflict)
*Attempts to create a student team with a name that is already in use.
*Expectation: The response status is 422, and the response body includes an error message indicating that the team name is already in use.
*Scenario 3: Invalid team creation (empty name)
*Expectation: Attempts to create a student team with an empty name. The response status is 422, and the response body includes an error message.

# Scenario 1: Successfully create a team
response(201, 'created') do
let(:student_team_request) do
{ team: {name: "HelloThere"}, student_id: students.first.id}
end
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test! do
expect(response.status).to eq(201)
end
end
# Scenario 2: Team name is already in use (conflict)
response(422, 'unprocessable entity') do
let(:existing_team) { create(:team, name: 'ABCD10', assignment_id: assignment.id) }
let(:team) do
post '/api/v1/student_teams', params: { team: { name: 'ABCD10' }, student_id: students.first.id }, as: :json
end
run_test! do
expect(response.status).to eq(422)
expect(response.body).to include('"error":"That team name is already in use."')
end
end
# Scenario 3: Invalid team creation (empty name)
response(422, 'unprocessable entity') do
let(:student_team_request) do
{ team: {name: ""}, student_id: students.first.id}
end
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test! do
expect(response.status).to eq(422)
expect(response.body).to include('error')
end
end
response(404, 'not_found') do
let(:team) do
post '/api/v1/student_teams', params: { team: { name: 'ABCD10' }, student_id: 0 }, as: :json
end
run_test! do
expect(response.status).to eq(404)
expect(response.body).to include('not found')
end
end
end

3. Update a Student Team
*Description: Update the details of a student team.
*Response: 200 OK
*Scenarios:
*Scenario 1: Team name updated successfully
*Expectation: Successfully updates the name of a student team. The response status is 200, and the response body includes the updated team name.
*Scenario 2: Invalid team update (empty name)
*Expectation: Attempts to update a student team with an empty name. The response status is 422, and the response body includes an error message indicating that the team name should not be empty.
*Scenario 3: Team name already in use
*Expectation: Attempts to update a student team with a name that is already in use. The response status is 422, and the response body includes an error message indicating that the team name is already in use.
*Scenario 4: Invalid team ID
*Expectation: Attempts to update a student team with a non-existent team ID. The response status is 404, and the response body includes an error message indicating that the team was not found.

patch('Update a Student Team') do
tags 'Student Teams'
consumes 'application/json'
produces 'application/json'
security [Bearer: {}]
parameter name: :student_team_request, in: :body, schema: {
type: :object,
properties: {
team: {
type: :object,
properties: {
name: {type: :string}
}
},
team_id: { type: :integer}
}
}
# Scenario 1: Team name updated successfully
response(200, 'successful') do
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test! do
expect(response.status).to eq(200)
end
end
# Scenario 2: Invalid team updation (empty name)
response(422, 'unprocessable entity') do
let(:student_team_request) do
{ team: {name: ""}, team_id: 2}
end
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test! do
expect(response.status).to eq(422)
expect(response.body).to include('Team name should not be empty')
end
end
# Scenario 3: Team Name already present
response(422, 'unprocessable entity') do
let(:existing_team) { create(:team, name: 'ABCD10', team_id: 3) }
let(:team) do
post '/api/v1/student_teams', params: { team: { name: 'ABCD10' }, team_id: 2 }, as: :json
end
run_test! do
expect(response.status).to eq(422)
expect(response.body).to include('"error":"That team name is already in use."')
end
end
#Scenario 4 : Invalid Team ID
response(404, 'not_found') do
let(:team) do
post '/api/v1/student_teams', params: { team: { name: 'ABCD10' }, team_id: 0 }, as: :json
end
run_test! do
expect(response.status).to eq(404)
expect(response.body).to include('not found')
end
end
end
end

4. Show a Student Team
*Description: Retrieve the details of a student team by its ID.
*Response: 200 OK
*Scenarios:
*Scenario 1: Show Student Team
*Expectation: Successfully retrieves the details of a student team by its ID. The response status is 200, and the response body includes the details of the student team.
*Scenario 2: Team not found
*Expectation: Attempts to retrieve the details of a student team with an invalid ID. The response status is 404, and the response body includes an error message indicating that the team was not found.
path '/api/v1/student_teams/{id}' do
parameter name: 'id', in: :path, type: :integer
# Get request on /api/v1/student_teams/{id} returns the response 200 succesful - when correct id passed is present in the database
get('Show a Student Team') do
tags 'Student Teams'
produces 'application/json'
security [Bearer: {}]
response(200, 'successful') do
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test! do
expect(response.status).to eq(200)
end
end
# Get request on /api/v1/student_teams/{id} returns the response 404 not found - when correct id passed is not present in the database
response(404, 'not_found') do
let(:id) { 'invalid' }
run_test! do
expect(response.status).to eq(404)
end
end
end

5. Delete a Student Team
*Description: Delete a student team by its ID.
*Response: 204 No Content
*Scenarios:
*Scenario 1: Successfully delete a student team
*Expectation: Successfully deletes a student team by its ID. The response status is 204, and the student team is no longer present in the database.
*Scenario 2: Team not found
*Expectation: Attempts to delete a student team with an invalid ID. The response status is 404, and the response body includes an error message indicating that the team was not found.

delete('Delete a Student Team') do
tags 'Student Teams'
produces 'application/json'
security [Bearer: {}]
# delete request on /api/v1/student_teams/{id} returns 204 succesful response when id present in the database is deleted successfully
response(204, 'successful') do
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: ''
}
}
end
run_test! do
expect(response.status).to eq(204)
end
end
# delete request on /api/v1/student_teams/{id} returns 404 not found response, when id is not present in the database
response(404, 'not found') do
let(:id) { 0 }
run_test! do
expect(response.status).to eq(404)
end
end
end
end

6. Add a Participant in Student Team
*Description: Add a participant to a student team.
*Response: 200 OK
*Test Data Prep
path '/api/v1/student_teams/{id}/add_participant' do
parameter name: 'id', in: :path, type: :integer, description: 'ID of Team'
parameter name: 'student_id', in: :query, type: :integer, description: 'ID of the Student'
let(:student) { create(:user, :student) }
let(:assignment) { create(:assignment) }
let(:student_participant) { create(:assignment_participant, user: student, assignment: assignment) }
let(:team) { create(:assignment_team, assignment: assignment) }
let(:id) { team.id }
let(:student_id) { student.id }
*Scenarios:
*Scenario 1: Successfully add a participant to a student team
*Expectation: Successfully adds a participant to a student team by their ID. The response status is 200, and the participant is added to the team.
patch('Add a participant to Student Team') do
tags 'Student Teams'
consumes 'application/json'
produces 'application/json'
security [Bearer: {}]
before do
team.add_member(student, assignment.id)
end
response(200, 'successful') do
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test!
end
end
end
7. Remove a Participant in Student Team
*Description: Remove a participant from a student team.
*Response: 204 No Content
*Test data prep:

path '/api/v1/student_teams/{id}/remove_participant' do
parameter name: 'id', in: :path, type: :integer, description: 'ID of Team'
parameter name: 'student_id', in: :query, type: :integer, description: 'ID of the Student'
let(:student) { create(:user, :student) }
let(:assignment) { create(:assignment) }
let(:student_participant) { create(:assignment_participant, user: student, assignment: assignment) }
let(:team) { create(:assignment_team, assignment: assignment) }
let(:id) { team.id }
let(:student_id) { student.id }
before do
team.add_member(student, assignment.id)
end
*Scenarios:
*Scenario 1: Successfully remove a participant from a student team
*Expectation: Successfully removes a participant from a student team by their ID. The response status is 204, and the participant is no longer a member of the team.
*Scenario 2: Team not found
*Expectation: Attempts to remove a participant from a student team with an invalid team ID. The response status is 404, and the response body includes an error message indicating that the team was not found.
*Scenario 3: User not found
*Expectation: Attempts to remove a participant from a student team with an invalid user ID. The response status is 404, and the response body includes an error message indicating that the user was not found.

delete('remove participant') do
tags 'Student Teams'
produces 'application/json'
security [Bearer: {}]
response(204, 'successful') do
let(:Authorization) { "Bearer #{@token}" }
run_test! do
expect(response.status).to eq(204)
expect(team.members).not_to include(student)
end
end
response(404, 'team not found') do
let(:id) { -1 } # Invalid ID
run_test! do
expect(response.status).to eq(404)
expect(JSON.parse(response.body)['error']).to eq('Team not found.')
end
end
response(404, 'user not found') do
let(:student_id) { -1 } # Invalid student ID
run_test! do
expect(response.status).to eq(404)
expect(JSON.parse(response.body)['error']).to eq('User not found.')
end
end
end
end

===GitHub Pull Request===

https://github.com/expertiza/reimplementation-back-end/pull/136

===Demo Video===

https://www.youtube.com/watch?v=8_d_Y9EcgHc

===Mentor===

* Ammana, Sahithi <sammana@ncsu.edu>

===Team Members===

* Eathamukkala, Akarsh Reddy <aeatham@ncsu.edu>
* Koul, Anmol <akoul2@ncsu.edu>
* More, Harsh Manoj <hmore@ncsu.edu>

CSC/ECE 517 Fall 2024 - E2476. Reimplement student teams controller.rb

2024-12-04T04:34:09Z

Akoul2: /* Testing Plan */

===Introduction===
[http://expertiza.ncsu.edu/ Expertiza] is an open-source system built on [http://rubyonrails.org/ Ruby on Rails], collaboratively maintained by students and faculty at NC State. This platform gives instructors extensive control over assignments, enabling them to add topics, create assignment groups, and manage peer reviews for various types of coursework. Expertiza is well-equipped to handle submissions across multiple formats, including URLs and wiki pages, and it offers a peer review system that facilitates constructive feedback among students.

A key focus of recent development in Expertiza has been the shift to a client-server architecture, where Ruby on Rails functions as the backend and React is utilized for the frontend. This architectural update requires reworking existing modules into RESTful API endpoints, allowing React components to interact efficiently with the backend. By adopting this approach, Expertiza aims to enhance modularity, performance, and scalability.

===Project Description===

The project mainly focuses on reimplementing the StudentTeamsController in Expertiza's backend, which is designed for student-facing operations where students participate in teams. This includes actions that directly affect individual team members, such as adding or removing students from teams, viewing team details, and managing their participation.

The TeamsController, on the other hand, is focused on instructor-driven operations that handle high-level team management across different contexts, such as courses and assignments. It manages operations like team creation, deletion, randomization, and bulk management actions.

===Problem Statement===

The current implementation of the StudentTeamsController in the Expertiza system is overly complex and tightly coupled, leading to difficulties in maintaining and extending the codebase. The controller is responsible for managing student teams in assignments, handling tasks like team creation, editing, management, and the integration of topics in assignments that require team-based decisions. However, it suffers from issues such as:
* Code redundancy and inefficiency due to business logic being embedded directly in the controller.
* Lack of modularity and poor separation of concerns, violating the Single Responsibility Principle (SRP). For example, it also handles the integration with topics when assignments involve choosing topics, complicating the team’s logic.
* Difficult-to-understand methods and tightly coupled logic for handling assignment-specific conditions, such as team-topic associations.
* Poor user feedback that does not provide clear or actionable information after critical operations.

These problems create a system that is hard to scale, maintain, and extend, especially as new features are added. To address these challenges, the goal is to reimplement the StudentTeamsController in the newer Expertiza backend codebase by adhering to object-oriented design principles, specifically focusing on maintainability, scalability, and modularity. The new design will improve the user experience by simplifying controller logic, providing clearer feedback, and ensuring that the system is easier to extend and maintain in the future.

===Objectives===

The main objective is to migrate the Student Task controller logic from serving HTML responses in the Ruby on Rails MVC model to returning JSON responses as a RESTful API, as part of the backend implementation. While reimplementing the controller, the following considerations will be incorporated to ensure a clean, maintainable, and scalable API:

*Reimplement the controller logic and write methods which appropriately follow the Single Responsibility Principle (SRP).
*Move business logic from the controller to appropriate model classes like Team or AssignmentTeam.
*Ensure all method names clearly describe their purpose and represent actions.
*Reimplement a Prototype pattern for creating mentored teams, leveraging the AssignmentTeam class.
*Automatically generate team names when a team is first referred to unless the user has specified a name when requesting team creation.
*Handle team requirements with better abstraction:
*Try to eliminate direct logic in the controller that checks for specific assignment requirements such as topic handling.
*Rename student_team_requirements_met? to something more descriptive and break it into smaller methods checking individual conditions.
*Aim to decouple topics from this controller entirely, ensuring better abstraction, that can involve changes to other classes or introducing service objects to handle specific requirements.
* Improve feedback to users and ensure that the user receives clear and actionable feedback after operations like team creation, removal of users, and other key actions.
* Add comprehensive comments throughout the controller, clearly explaining the purpose and functionality of custom methods.

===Development Strategy===

Our development strategy centers around Test-Driven Development (TDD) principles applied to refactoring the student_teams_controller.rb and other related classes such as Team or AssignmentTeam model. We design out test cases and iteratively refactor code to address identified inefficiencies while ensuring successful test outcomes.
Additionally, we emphasize on the strict adoption of SRP and DRY principles as per the object-oriented programming conventions. Our goal is to reimplement the existing functionalities
In the newly designed back-end foundation to foster a more efficient and organized codebase utilizing newer technologies. This approach will significantly enhance reusability and scalability across all the application while maintaining clean codebase.

Files Modified:
* Created ==>
** app/controllers/api/v1/student_teams_controller.rb
** app/models/assignment_team.rb
** app/models/team.rb
** spec/requests/api/v1/student_teams_controller_spec.rb
** db/migrate/20241201203840_create_assignment_teams.rb
** db/migrate/20241201220020_add_auto_assign_mentor_to_assignments.rb
** db/migrate/20241201221122_add_type_to_teams.rb
** db/migrate/20241202002102_add_name_to_teams.rb

* Updated ==>
** app/models/team.rb
** config/routes.rb
** db/schema.rb
** db/seeds.rb
** spec/swagger_helper.rb

===Project Design and Implementation===

The main approach to be followed throughout this project is to embrace the Prototyping Pattern within the controller while taking into account the current functionalities to be reimplemented within the student_teams_controller.rb that can capitalize its capability to encapsulate distinct controller actions. This strategic implementation aims to ensure seamless extensibility and enhanced usability. By employing this pattern, we establish a structured framework for defining and managing the diverse operations the controller handles, promoting a more organized and manageable code structure.

[[File:2476_UML.drawio.png]]

==== Functionality ====

1. Reimplement the Controller to Follow SRP:
* Break down large, complex methods into smaller, focused methods that adhere to the Single Responsibility Principle (SRP).
* Reimplement existing methods and logic while ensuring that each class and method have a clear, well-defined responsibility.
* Move business logic and complex operations out of the controller and into the appropriate model classes (e.g., Team, AssignmentTeam), ensuring the controller only handles HTTP-specific concerns (e.g., request handling, responses).

2. Improve Method Naming and Clarity:
* Ensure all method names are descriptive and represent the intent of the operation (e.g., renaming methods like student_team_requirements_met? to something more specific like validate_topic_requirements_for_team_creation).
* Adopt consistent naming conventions to improve the readability of the codebase.

3. Implement the Prototype Pattern for Team Creation:
* Leverage the Prototype pattern to create mentored teams through the AssignmentTeam class, allowing for easier management and creation of teams with a mentored structure.
* Automatically generate team names when a team is first created, unless a user has specified a custom name to improve the user experience and simplify team management.

4. Abstract Assignment-Specific Logic:
* Move logic related to assignment-specific requirements (e.g., topic handling) away from the controller, reducing complexity and increasing modularity.
* Introduce service objects or model methods to handle specific requirements like topic assignment, thereby decoupling assignment-related logic from the controller.
* Break down the student_team_requirements_met? method into smaller, more specific checks for different requirements (e.g., topic validation, minimum team size, etc.).

5. Improve User Feedback:
* Enhance the clarity and actionability of feedback messages after key operations (e.g., team creation, user removal, etc.).
* Provide users with clear, helpful notifications on the success or failure of their actions, including any necessary next steps or troubleshooting guidance.
* Ensure error handling is robust, and feedback is specific (e.g., specify which conditions were not met when creating or modifying teams).

6. Commenting and Documentation:
* Add comprehensive comments throughout the controller to clearly explain the purpose and functionality of custom methods and refactored logic.
* Ensure that code is well-documented, making it easier for future developers to understand and extend the functionality of the controller.

===Tasks Completed===

Methods:
* AssignmentTeam Model:
** To access every participant connected to an assignment, the assignment_participants method was added.
** For including a user in the assignment as a participant, the add_participant method was added.
** To see if the team has gotten any peer reviews, the received_any_peer_review? method was put into practice.
** Using a placeholder for future mentor assignment logic, the upgrade_to_mentored_team method was put into practice to replicate the present team and get it ready for mentoring.
** In order to ensure deep duplication of associated records (such as signed_up_teams, teams_users, and participants), the dup method was added to duplicate a team and its associations.

* Team Model:
** Improved the whole procedure to determine if a team has reached its maximum number of members.
** Counted the number of team members using the size approach, removing those with "(Mentor)" in their names.
** In order to eliminate duplicate members and check for team capacity, the add_member method was improved.
** To remove a user from the team, the remove_team_user method was put into place. If the team becomes empty and hasn't been subjected to any peer reviews, the team will be deleted.

Controller - StudentTeamsController.rb
* index: Implemented in order to retrieve and restore every student team together with all of its members.
* show: Created to retrieve and provide information about a certain student team and its members.
* create: Added logic to create a new team for a student, using AssignmentTeam#upgraded_to_mentored_team for mentor-eligible teams and checking for existing team names.
* update: Implemented to enable team details, especially the team name, to be updated while ensuring unique team names through validations.
* destroy: To remove a certain team this was added and, if successful, deliver a 204 No Content response.
* remove_participant: Check if the user is part of the given team and removes from that team, also handles corner cases where no more participants are there in a team.
* add_participant: Added this to add the given participant to respective team.

===Testing Plan===

We have performed comprehensive testing of the student_teams_controller.rb and related classes using RSPEC and Swagger to construct the required test fixtures for testing extensive scenarios. Our approach involves reimplementing the existing test cases provided to the older code base and make sure that it is enhanced by covering more test scenarios to minimize code smells. We aim to verify the reimplemented functionality, validate the restructured code in the student_teams_controller.rb and reduce any design or code smell.
Below are the test scenarios for each of API endpoints -

1. List all Student Teams

*Description: List all student teams.
*Response: 200 OK
*Test Case Scenarios:
*Scenario 1: List all Student Teams
*Description: Successfully retrieves a list of all student teams.
*Expectation: The response status is 200, the content type is `application/json`, and the response body contains 3 student teams.

RSpec.describe 'Student Teams API', type: :request do
path '/api/v1/student_teams' do
# List all Student Teams
get('List all Student Teams') do
tags 'Student Teams'
produces 'application/json'
security [Bearer: {}]
response(200, 'successful') do
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test!
end
end

2. Create a Student Team
*Description: Create a new student team.
*Response: 201 Created
*2.1 Test Data prep:
post 'Create a Student Team' do
tags 'Student Teams'
consumes 'application/json'
let(:institution) do
Institution.create!(
name: 'North Carolina State University'
)
end
let!(:instructor_role) { Role.find_or_create_by(name: 'Instructor') }
let!(:student_role) { Role.find_or_create_by(name: 'Student') }
let(:instructor_user) do
User.create!(
name: 'Dr. Ed Gehringer1',
email: 'gehringer@example.com',
password: 'password123',
full_name: 'admin admin',
institution_id: institution.id,
role_id: instructor_role.id,
handle: 'instructor'
)
end
let(:course) do
Course.create!(
name: '2476. Refactor',
directory_path: '/',
info: 'OODD',
private: false,
instructor_id: instructor_user.id,
institution_id: institution.id
)
end
let(:assignment) do
Assignment.create!(
title: 'Project 4 BRO',
description: '2476. Reimplementing',
course_id: course.id,
instructor_id: instructor_user.id
)
end
let!(:students) do
created_students = []
3.times do |i|
student = User.create!(
name: "Student #{i + 1}",
email: "Student#{i + 1}@gmail.com",
password: 'password123',
full_name: "Student #{i + 1}",
institution_id: institution.id,
role_id: student_role.id,
handle: "Student #{i + 1}"
)
AssignmentParticipant.create!(
assignment: assignment,
user: student,
handle: "Student #{i + 1}"
)
created_students << student
end
created_students
end
parameter name: :student_team_request, in: :body, schema: {
type: :object,
properties: {
team: {
type: :object,
properties: {
name: {type: :string}
}
},
student_id: { type: :integer}
}
}
security [Bearer: {}]
2.2 Scenarios:
*Scenario 1: Successfully create a team
*Description: Successfully creates a new student team with a valid name and student ID.
*Expectation: The response status is 201, and the response body includes the team name.
*Scenario 2: Team name is already in use (conflict)
*Description: Attempts to create a student team with a name that is already in use.
*Expectation: The response status is 422, and the response body includes an error message indicating that the team name is already in use.
*Scenario 3: Invalid team creation (empty name)
*Description: Attempts to create a student team with an empty name.
*Expectation: The response status is 422, and the response body includes an error message.

# Scenario 1: Successfully create a team
response(201, 'created') do
let(:student_team_request) do
{ team: {name: "HelloThere"}, student_id: students.first.id}
end
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test! do
expect(response.status).to eq(201)
end
end
# Scenario 2: Team name is already in use (conflict)
response(422, 'unprocessable entity') do
let(:existing_team) { create(:team, name: 'ABCD10', assignment_id: assignment.id) }
let(:team) do
post '/api/v1/student_teams', params: { team: { name: 'ABCD10' }, student_id: students.first.id }, as: :json
end
run_test! do
expect(response.status).to eq(422)
expect(response.body).to include('"error":"That team name is already in use."')
end
end
# Scenario 3: Invalid team creation (empty name)
response(422, 'unprocessable entity') do
let(:student_team_request) do
{ team: {name: ""}, student_id: students.first.id}
end
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test! do
expect(response.status).to eq(422)
expect(response.body).to include('error')
end
end
response(404, 'not_found') do
let(:team) do
post '/api/v1/student_teams', params: { team: { name: 'ABCD10' }, student_id: 0 }, as: :json
end
run_test! do
expect(response.status).to eq(404)
expect(response.body).to include('not found')
end
end
end

3. Update a Student Team
*Description: Update the details of a student team.
*Response: 200 OK
*Scenarios:
*Scenario 1: Team name updated successfully
*Expectation: Successfully updates the name of a student team. The response status is 200, and the response body includes the updated team name.
*Scenario 2: Invalid team update (empty name)
*Expectation: Attempts to update a student team with an empty name. The response status is 422, and the response body includes an error message indicating that the team name should not be empty.
*Scenario 3: Team name already in use
*Expectation: Attempts to update a student team with a name that is already in use. The response status is 422, and the response body includes an error message indicating that the team name is already in use.
*Scenario 4: Invalid team ID
*Expectation: Attempts to update a student team with a non-existent team ID. The response status is 404, and the response body includes an error message indicating that the team was not found.

patch('Update a Student Team') do
tags 'Student Teams'
consumes 'application/json'
produces 'application/json'
security [Bearer: {}]
parameter name: :student_team_request, in: :body, schema: {
type: :object,
properties: {
team: {
type: :object,
properties: {
name: {type: :string}
}
},
team_id: { type: :integer}
}
}
# Scenario 1: Team name updated successfully
response(200, 'successful') do
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test! do
expect(response.status).to eq(200)
end
end
# Scenario 2: Invalid team updation (empty name)
response(422, 'unprocessable entity') do
let(:student_team_request) do
{ team: {name: ""}, team_id: 2}
end
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test! do
expect(response.status).to eq(422)
expect(response.body).to include('Team name should not be empty')
end
end
# Scenario 3: Team Name already present
response(422, 'unprocessable entity') do
let(:existing_team) { create(:team, name: 'ABCD10', team_id: 3) }
let(:team) do
post '/api/v1/student_teams', params: { team: { name: 'ABCD10' }, team_id: 2 }, as: :json
end
run_test! do
expect(response.status).to eq(422)
expect(response.body).to include('"error":"That team name is already in use."')
end
end
#Scenario 4 : Invalid Team ID
response(404, 'not_found') do
let(:team) do
post '/api/v1/student_teams', params: { team: { name: 'ABCD10' }, team_id: 0 }, as: :json
end
run_test! do
expect(response.status).to eq(404)
expect(response.body).to include('not found')
end
end
end
end

4. Show a Student Team
*Description: Retrieve the details of a student team by its ID.
*Response: 200 OK
*4.1 Test Case Scenarios:
*Scenario 1: Show Student Team
*Description: Successfully retrieves the details of a student team by its ID.
*Expectation: The response status is 200, and the response body includes the details of the student team.
*Scenario 2: Team not found
*Description: Attempts to retrieve the details of a student team with an invalid ID.
*Expectation: The response status is 404, and the response body includes an error message indicating that the team was not found.
path '/api/v1/student_teams/{id}' do
parameter name: 'id', in: :path, type: :integer
# Get request on /api/v1/student_teams/{id} returns the response 200 succesful - when correct id passed is present in the database
get('Show a Student Team') do
tags 'Student Teams'
produces 'application/json'
security [Bearer: {}]
response(200, 'successful') do
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test! do
expect(response.status).to eq(200)
end
end
# Get request on /api/v1/student_teams/{id} returns the response 404 not found - when correct id passed is not present in the database
response(404, 'not_found') do
let(:id) { 'invalid' }
run_test! do
expect(response.status).to eq(404)
end
end
end

5. Delete a Student Team
*Description: Delete a student team by its ID.
*Response: 204 No Content
*5.1 Scenarios:
*Scenario 1: Successfully delete a student team
*Description: Successfully deletes a student team by its ID.
*Expectation: The response status is 204, and the student team is no longer present in the database.
*Scenario 2: Team not found
*Description: Attempts to delete a student team with an invalid ID.
*Expectation: The response status is 404, and the response body includes an error message indicating that the team was not found.

delete('Delete a Student Team') do
tags 'Student Teams'
produces 'application/json'
security [Bearer: {}]
# delete request on /api/v1/student_teams/{id} returns 204 succesful response when id present in the database is deleted successfully
response(204, 'successful') do
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: ''
}
}
end
run_test! do
expect(response.status).to eq(204)
end
end
# delete request on /api/v1/student_teams/{id} returns 404 not found response, when id is not present in the database
response(404, 'not found') do
let(:id) { 0 }
run_test! do
expect(response.status).to eq(404)
end
end
end
end

6. Add a Participant in Student Team
6.1 Test Data Prep
path '/api/v1/student_teams/{id}/add_participant' do
parameter name: 'id', in: :path, type: :integer, description: 'ID of Team'
parameter name: 'student_id', in: :query, type: :integer, description: 'ID of the Student'
let(:student) { create(:user, :student) }
let(:assignment) { create(:assignment) }
let(:student_participant) { create(:assignment_participant, user: student, assignment: assignment) }
let(:team) { create(:assignment_team, assignment: assignment) }
let(:id) { team.id }
let(:student_id) { student.id }
6.2 Scenarios:
patch('Add a participant to Student Team') do
tags 'Student Teams'
consumes 'application/json'
produces 'application/json'
security [Bearer: {}]
before do
team.add_member(student, assignment.id)
end
response(200, 'successful') do
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test!
end
end
end
7. Remove a Participant in Student Team
7.1 Test data prep:

path '/api/v1/student_teams/{id}/remove_participant' do
parameter name: 'id', in: :path, type: :integer, description: 'ID of Team'
parameter name: 'student_id', in: :query, type: :integer, description: 'ID of the Student'
let(:student) { create(:user, :student) }
let(:assignment) { create(:assignment) }
let(:student_participant) { create(:assignment_participant, user: student, assignment: assignment) }
let(:team) { create(:assignment_team, assignment: assignment) }
let(:id) { team.id }
let(:student_id) { student.id }
before do
team.add_member(student, assignment.id)
end
Scenarios:
delete('remove participant') do
tags 'Student Teams'
produces 'application/json'
security [Bearer: {}]
response(204, 'successful') do
let(:Authorization) { "Bearer #{@token}" }
run_test! do
expect(response.status).to eq(204)
expect(team.members).not_to include(student)
end
end
response(404, 'team not found') do
let(:id) { -1 } # Invalid ID
run_test! do
expect(response.status).to eq(404)
expect(JSON.parse(response.body)['error']).to eq('Team not found.')
end
end
response(404, 'user not found') do
let(:student_id) { -1 } # Invalid student ID
run_test! do
expect(response.status).to eq(404)
expect(JSON.parse(response.body)['error']).to eq('User not found.')
end
end
end
end

===GitHub Pull Request===

https://github.com/expertiza/reimplementation-back-end/pull/136

===Mentor===

* Ammana, Sahithi <sammana@ncsu.edu>

===Team Members===

* Eathamukkala, Akarsh Reddy <aeatham@ncsu.edu>
* Koul, Anmol <akoul2@ncsu.edu>
* More, Harsh Manoj <hmore@ncsu.edu>

CSC/ECE 517 Fall 2024 - E2476. Reimplement student teams controller.rb

2024-12-04T04:21:21Z

Akoul2: /* Testing Plan */

===Introduction===
[http://expertiza.ncsu.edu/ Expertiza] is an open-source system built on [http://rubyonrails.org/ Ruby on Rails], collaboratively maintained by students and faculty at NC State. This platform gives instructors extensive control over assignments, enabling them to add topics, create assignment groups, and manage peer reviews for various types of coursework. Expertiza is well-equipped to handle submissions across multiple formats, including URLs and wiki pages, and it offers a peer review system that facilitates constructive feedback among students.

A key focus of recent development in Expertiza has been the shift to a client-server architecture, where Ruby on Rails functions as the backend and React is utilized for the frontend. This architectural update requires reworking existing modules into RESTful API endpoints, allowing React components to interact efficiently with the backend. By adopting this approach, Expertiza aims to enhance modularity, performance, and scalability.

===Project Description===

The project mainly focuses on reimplementing the StudentTeamsController in Expertiza's backend, which is designed for student-facing operations where students participate in teams. This includes actions that directly affect individual team members, such as adding or removing students from teams, viewing team details, and managing their participation.

The TeamsController, on the other hand, is focused on instructor-driven operations that handle high-level team management across different contexts, such as courses and assignments. It manages operations like team creation, deletion, randomization, and bulk management actions.

===Problem Statement===

The current implementation of the StudentTeamsController in the Expertiza system is overly complex and tightly coupled, leading to difficulties in maintaining and extending the codebase. The controller is responsible for managing student teams in assignments, handling tasks like team creation, editing, management, and the integration of topics in assignments that require team-based decisions. However, it suffers from issues such as:
* Code redundancy and inefficiency due to business logic being embedded directly in the controller.
* Lack of modularity and poor separation of concerns, violating the Single Responsibility Principle (SRP). For example, it also handles the integration with topics when assignments involve choosing topics, complicating the team’s logic.
* Difficult-to-understand methods and tightly coupled logic for handling assignment-specific conditions, such as team-topic associations.
* Poor user feedback that does not provide clear or actionable information after critical operations.

These problems create a system that is hard to scale, maintain, and extend, especially as new features are added. To address these challenges, the goal is to reimplement the StudentTeamsController in the newer Expertiza backend codebase by adhering to object-oriented design principles, specifically focusing on maintainability, scalability, and modularity. The new design will improve the user experience by simplifying controller logic, providing clearer feedback, and ensuring that the system is easier to extend and maintain in the future.

===Objectives===

The main objective is to migrate the Student Task controller logic from serving HTML responses in the Ruby on Rails MVC model to returning JSON responses as a RESTful API, as part of the backend implementation. While reimplementing the controller, the following considerations will be incorporated to ensure a clean, maintainable, and scalable API:

*Reimplement the controller logic and write methods which appropriately follow the Single Responsibility Principle (SRP).
*Move business logic from the controller to appropriate model classes like Team or AssignmentTeam.
*Ensure all method names clearly describe their purpose and represent actions.
*Reimplement a Prototype pattern for creating mentored teams, leveraging the AssignmentTeam class.
*Automatically generate team names when a team is first referred to unless the user has specified a name when requesting team creation.
*Handle team requirements with better abstraction:
*Try to eliminate direct logic in the controller that checks for specific assignment requirements such as topic handling.
*Rename student_team_requirements_met? to something more descriptive and break it into smaller methods checking individual conditions.
*Aim to decouple topics from this controller entirely, ensuring better abstraction, that can involve changes to other classes or introducing service objects to handle specific requirements.
* Improve feedback to users and ensure that the user receives clear and actionable feedback after operations like team creation, removal of users, and other key actions.
* Add comprehensive comments throughout the controller, clearly explaining the purpose and functionality of custom methods.

===Development Strategy===

Our development strategy centers around Test-Driven Development (TDD) principles applied to refactoring the student_teams_controller.rb and other related classes such as Team or AssignmentTeam model. We design out test cases and iteratively refactor code to address identified inefficiencies while ensuring successful test outcomes.
Additionally, we emphasize on the strict adoption of SRP and DRY principles as per the object-oriented programming conventions. Our goal is to reimplement the existing functionalities
In the newly designed back-end foundation to foster a more efficient and organized codebase utilizing newer technologies. This approach will significantly enhance reusability and scalability across all the application while maintaining clean codebase.

Files Modified:
* Created ==>
** app/controllers/api/v1/student_teams_controller.rb
** app/models/assignment_team.rb
** app/models/team.rb
** spec/requests/api/v1/student_teams_controller_spec.rb
** db/migrate/20241201203840_create_assignment_teams.rb
** db/migrate/20241201220020_add_auto_assign_mentor_to_assignments.rb
** db/migrate/20241201221122_add_type_to_teams.rb
** db/migrate/20241202002102_add_name_to_teams.rb

* Updated ==>
** app/models/team.rb
** config/routes.rb
** db/schema.rb
** db/seeds.rb
** spec/swagger_helper.rb

===Project Design and Implementation===

The main approach to be followed throughout this project is to embrace the Prototyping Pattern within the controller while taking into account the current functionalities to be reimplemented within the student_teams_controller.rb that can capitalize its capability to encapsulate distinct controller actions. This strategic implementation aims to ensure seamless extensibility and enhanced usability. By employing this pattern, we establish a structured framework for defining and managing the diverse operations the controller handles, promoting a more organized and manageable code structure.

[[File:2476_UML.drawio.png]]

==== Functionality ====

1. Reimplement the Controller to Follow SRP:
* Break down large, complex methods into smaller, focused methods that adhere to the Single Responsibility Principle (SRP).
* Reimplement existing methods and logic while ensuring that each class and method have a clear, well-defined responsibility.
* Move business logic and complex operations out of the controller and into the appropriate model classes (e.g., Team, AssignmentTeam), ensuring the controller only handles HTTP-specific concerns (e.g., request handling, responses).

2. Improve Method Naming and Clarity:
* Ensure all method names are descriptive and represent the intent of the operation (e.g., renaming methods like student_team_requirements_met? to something more specific like validate_topic_requirements_for_team_creation).
* Adopt consistent naming conventions to improve the readability of the codebase.

3. Implement the Prototype Pattern for Team Creation:
* Leverage the Prototype pattern to create mentored teams through the AssignmentTeam class, allowing for easier management and creation of teams with a mentored structure.
* Automatically generate team names when a team is first created, unless a user has specified a custom name to improve the user experience and simplify team management.

4. Abstract Assignment-Specific Logic:
* Move logic related to assignment-specific requirements (e.g., topic handling) away from the controller, reducing complexity and increasing modularity.
* Introduce service objects or model methods to handle specific requirements like topic assignment, thereby decoupling assignment-related logic from the controller.
* Break down the student_team_requirements_met? method into smaller, more specific checks for different requirements (e.g., topic validation, minimum team size, etc.).

5. Improve User Feedback:
* Enhance the clarity and actionability of feedback messages after key operations (e.g., team creation, user removal, etc.).
* Provide users with clear, helpful notifications on the success or failure of their actions, including any necessary next steps or troubleshooting guidance.
* Ensure error handling is robust, and feedback is specific (e.g., specify which conditions were not met when creating or modifying teams).

6. Commenting and Documentation:
* Add comprehensive comments throughout the controller to clearly explain the purpose and functionality of custom methods and refactored logic.
* Ensure that code is well-documented, making it easier for future developers to understand and extend the functionality of the controller.

===Tasks Completed===

Methods:
* AssignmentTeam Model:
** To access every participant connected to an assignment, the assignment_participants method was added.
** For including a user in the assignment as a participant, the add_participant method was added.
** To see if the team has gotten any peer reviews, the received_any_peer_review? method was put into practice.
** Using a placeholder for future mentor assignment logic, the upgrade_to_mentored_team method was put into practice to replicate the present team and get it ready for mentoring.
** In order to ensure deep duplication of associated records (such as signed_up_teams, teams_users, and participants), the dup method was added to duplicate a team and its associations.

* Team Model:
** Improved the whole procedure to determine if a team has reached its maximum number of members.
** Counted the number of team members using the size approach, removing those with "(Mentor)" in their names.
** In order to eliminate duplicate members and check for team capacity, the add_member method was improved.
** To remove a user from the team, the remove_team_user method was put into place. If the team becomes empty and hasn't been subjected to any peer reviews, the team will be deleted.

Controller - StudentTeamsController.rb
* index: Implemented in order to retrieve and restore every student team together with all of its members.
* show: Created to retrieve and provide information about a certain student team and its members.
* create: Added logic to create a new team for a student, using AssignmentTeam#upgraded_to_mentored_team for mentor-eligible teams and checking for existing team names.
* update: Implemented to enable team details, especially the team name, to be updated while ensuring unique team names through validations.
* destroy: To remove a certain team this was added and, if successful, deliver a 204 No Content response.
* remove_participant: Check if the user is part of the given team and removes from that team, also handles corner cases where no more participants are there in a team.
* add_participant: Added this to add the given participant to respective team.

===Testing Plan===

We have performed comprehensive testing of the student_teams_controller.rb and related classes using RSPEC and Swagger to construct the required test fixtures for testing extensive scenarios. Our approach involves reimplementing the existing test cases provided to the older code base and make sure that it is enhanced by covering more test scenarios to minimize code smells. We aim to verify the reimplemented functionality, validate the restructured code in the student_teams_controller.rb and reduce any design or code smell.
Below are the test scenarios for each of API endpoints -

1. List all Student Teams

*Description: List all student teams.
*Response: 200 OK
*Test Case Scenarios:
*Scenario 1: List all Student Teams
*Description: Successfully retrieves a list of all student teams.
*Expectation: The response status is 200, the content type is `application/json`, and the response body contains 3 student teams.

RSpec.describe 'Student Teams API', type: :request do
path '/api/v1/student_teams' do
# List all Student Teams
get('List all Student Teams') do
tags 'Student Teams'
produces 'application/json'
security [Bearer: {}]
response(200, 'successful') do
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test!
end
end

2. Create a Student Team
*Description: Create a new student team.
*Response: 201 Created
*2.1 Test Data prep:
post 'Create a Student Team' do
tags 'Student Teams'
consumes 'application/json'
let(:institution) do
Institution.create!(
name: 'North Carolina State University'
)
end
let!(:instructor_role) { Role.find_or_create_by(name: 'Instructor') }
let!(:student_role) { Role.find_or_create_by(name: 'Student') }
let(:instructor_user) do
User.create!(
name: 'Dr. Ed Gehringer1',
email: 'gehringer@example.com',
password: 'password123',
full_name: 'admin admin',
institution_id: institution.id,
role_id: instructor_role.id,
handle: 'instructor'
)
end
let(:course) do
Course.create!(
name: '2476. Refactor',
directory_path: '/',
info: 'OODD',
private: false,
instructor_id: instructor_user.id,
institution_id: institution.id
)
end
let(:assignment) do
Assignment.create!(
title: 'Project 4 BRO',
description: '2476. Reimplementing',
course_id: course.id,
instructor_id: instructor_user.id
)
end
let!(:students) do
created_students = []
3.times do |i|
student = User.create!(
name: "Student #{i + 1}",
email: "Student#{i + 1}@gmail.com",
password: 'password123',
full_name: "Student #{i + 1}",
institution_id: institution.id,
role_id: student_role.id,
handle: "Student #{i + 1}"
)
AssignmentParticipant.create!(
assignment: assignment,
user: student,
handle: "Student #{i + 1}"
)
created_students << student
end
created_students
end
parameter name: :student_team_request, in: :body, schema: {
type: :object,
properties: {
team: {
type: :object,
properties: {
name: {type: :string}
}
},
student_id: { type: :integer}
}
}
security [Bearer: {}]
2.2 Scenarios:
*Scenario 1: Successfully create a team
*Description: Successfully creates a new student team with a valid name and student ID.
*Expectation: The response status is 201, and the response body includes the team name.
*Scenario 2: Team name is already in use (conflict)
*Description: Attempts to create a student team with a name that is already in use.
*Expectation: The response status is 422, and the response body includes an error message indicating that the team name is already in use.
*Scenario 3: Invalid team creation (empty name)
*Description: Attempts to create a student team with an empty name.
*Expectation: The response status is 422, and the response body includes an error message.

# Scenario 1: Successfully create a team
response(201, 'created') do
let(:student_team_request) do
{ team: {name: "HelloThere"}, student_id: students.first.id}
end
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test! do
expect(response.status).to eq(201)
end
end
# Scenario 2: Team name is already in use (conflict)
response(422, 'unprocessable entity') do
let(:existing_team) { create(:team, name: 'ABCD10', assignment_id: assignment.id) }
let(:team) do
post '/api/v1/student_teams', params: { team: { name: 'ABCD10' }, student_id: students.first.id }, as: :json
end
run_test! do
expect(response.status).to eq(422)
expect(response.body).to include('"error":"That team name is already in use."')
end
end
# Scenario 3: Invalid team creation (empty name)
response(422, 'unprocessable entity') do
let(:student_team_request) do
{ team: {name: ""}, student_id: students.first.id}
end
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test! do
expect(response.status).to eq(422)
expect(response.body).to include('error')
end
end
response(404, 'not_found') do
let(:team) do
post '/api/v1/student_teams', params: { team: { name: 'ABCD10' }, student_id: 0 }, as: :json
end
run_test! do
expect(response.status).to eq(404)
expect(response.body).to include('not found')
end
end
end

3. Update a Student Team
Description: Update the details of a student team.
Response: 200 OK
Test Case Scenarios:
Scenario 1: Update Student Team
Description: Successfully updates the details of a student team.
Expectation: The response status is 200, and the response body includes the updated details of the student team.

patch('Update a Student Team') do
tags 'Student Teams'
consumes 'application/json'
produces 'application/json'
security [Bearer: {}]
parameter name: :student_team_request, in: :body, schema: {
type: :object,
properties: {
team: {
type: :object,
properties: {
name: {type: :string}
}
},
team_id: { type: :integer}
}
}
# Scenario 1: Team name updated successfully
response(200, 'successful') do
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test! do
expect(response.status).to eq(200)
end
end
# Scenario 2: Invalid team updation (empty name)
response(422, 'unprocessable entity') do
let(:student_team_request) do
{ team: {name: ""}, team_id: 2}
end
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test! do
expect(response.status).to eq(422)
expect(response.body).to include('Team name should not be empty')
end
end
# Scenario 3: Team Name already present
response(422, 'unprocessable entity') do
let(:existing_team) { create(:team, name: 'ABCD10', team_id: 3) }
let(:team) do
post '/api/v1/student_teams', params: { team: { name: 'ABCD10' }, team_id: 2 }, as: :json
end
run_test! do
expect(response.status).to eq(422)
expect(response.body).to include('"error":"That team name is already in use."')
end
end
#Scenario 4 : Invalid Team ID
response(404, 'not_found') do
let(:team) do
post '/api/v1/student_teams', params: { team: { name: 'ABCD10' }, team_id: 0 }, as: :json
end
run_test! do
expect(response.status).to eq(404)
expect(response.body).to include('not found')
end
end
end
end

4. Show a Student Team
Description: Retrieve the details of a student team by its ID.
Response: 200 OK
4.1 Test Case Scenarios:
Scenario 1: Show Student Team
Description: Successfully retrieves the details of a student team by its ID.
Expectation: The response status is 200, and the response body includes the details of the student team.
Scenario 2: Team not found
Description: Attempts to retrieve the details of a student team with an invalid ID.
Expectation: The response status is 404, and the response body includes an error message indicating that the team was not found.
path '/api/v1/student_teams/{id}' do
parameter name: 'id', in: :path, type: :integer
# Get request on /api/v1/student_teams/{id} returns the response 200 succesful - when correct id passed is present in the database
get('Show a Student Team') do
tags 'Student Teams'
produces 'application/json'
security [Bearer: {}]
response(200, 'successful') do
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test! do
expect(response.status).to eq(200)
end
end
# Get request on /api/v1/student_teams/{id} returns the response 404 not found - when correct id passed is not present in the database
response(404, 'not_found') do
let(:id) { 'invalid' }
run_test! do
expect(response.status).to eq(404)
end
end
end

5. Delete a Student Team
Description: Delete a student team by its ID.
Response: 204 No Content
5.1 Scenarios:
Scenario 1: Successfully delete a student team
Description: Successfully deletes a student team by its ID.
Expectation: The response status is 204, and the student team is no longer present in the database.
Scenario 2: Team not found
Description: Attempts to delete a student team with an invalid ID.
Expectation: The response status is 404, and the response body includes an error message indicating that the team was not found.

delete('Delete a Student Team') do
tags 'Student Teams'
produces 'application/json'
security [Bearer: {}]
# delete request on /api/v1/student_teams/{id} returns 204 succesful response when id present in the database is deleted successfully
response(204, 'successful') do
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: ''
}
}
end
run_test! do
expect(response.status).to eq(204)
end
end
# delete request on /api/v1/student_teams/{id} returns 404 not found response, when id is not present in the database
response(404, 'not found') do
let(:id) { 0 }
run_test! do
expect(response.status).to eq(404)
end
end
end
end

6. Add a Participant in Student Team
6.1 Test Data Prep
path '/api/v1/student_teams/{id}/add_participant' do
parameter name: 'id', in: :path, type: :integer, description: 'ID of Team'
parameter name: 'student_id', in: :query, type: :integer, description: 'ID of the Student'
let(:student) { create(:user, :student) }
let(:assignment) { create(:assignment) }
let(:student_participant) { create(:assignment_participant, user: student, assignment: assignment) }
let(:team) { create(:assignment_team, assignment: assignment) }
let(:id) { team.id }
let(:student_id) { student.id }
6.2 Scenarios:
patch('Add a participant to Student Team') do
tags 'Student Teams'
consumes 'application/json'
produces 'application/json'
security [Bearer: {}]
before do
team.add_member(student, assignment.id)
end
response(200, 'successful') do
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test!
end
end
end
7. Remove a Participant in Student Team
7.1 Test data prep:

path '/api/v1/student_teams/{id}/remove_participant' do
parameter name: 'id', in: :path, type: :integer, description: 'ID of Team'
parameter name: 'student_id', in: :query, type: :integer, description: 'ID of the Student'
let(:student) { create(:user, :student) }
let(:assignment) { create(:assignment) }
let(:student_participant) { create(:assignment_participant, user: student, assignment: assignment) }
let(:team) { create(:assignment_team, assignment: assignment) }
let(:id) { team.id }
let(:student_id) { student.id }
before do
team.add_member(student, assignment.id)
end
Scenarios:
delete('remove participant') do
tags 'Student Teams'
produces 'application/json'
security [Bearer: {}]
response(204, 'successful') do
let(:Authorization) { "Bearer #{@token}" }
run_test! do
expect(response.status).to eq(204)
expect(team.members).not_to include(student)
end
end
response(404, 'team not found') do
let(:id) { -1 } # Invalid ID
run_test! do
expect(response.status).to eq(404)
expect(JSON.parse(response.body)['error']).to eq('Team not found.')
end
end
response(404, 'user not found') do
let(:student_id) { -1 } # Invalid student ID
run_test! do
expect(response.status).to eq(404)
expect(JSON.parse(response.body)['error']).to eq('User not found.')
end
end
end
end

===GitHub Pull Request===

https://github.com/expertiza/reimplementation-back-end/pull/136

===Mentor===

* Ammana, Sahithi <sammana@ncsu.edu>

===Team Members===

* Eathamukkala, Akarsh Reddy <aeatham@ncsu.edu>
* Koul, Anmol <akoul2@ncsu.edu>
* More, Harsh Manoj <hmore@ncsu.edu>

CSC/ECE 517 Fall 2024 - E2476. Reimplement student teams controller.rb

2024-12-04T04:20:19Z

Akoul2: /* Testing Plan */

===Introduction===
[http://expertiza.ncsu.edu/ Expertiza] is an open-source system built on [http://rubyonrails.org/ Ruby on Rails], collaboratively maintained by students and faculty at NC State. This platform gives instructors extensive control over assignments, enabling them to add topics, create assignment groups, and manage peer reviews for various types of coursework. Expertiza is well-equipped to handle submissions across multiple formats, including URLs and wiki pages, and it offers a peer review system that facilitates constructive feedback among students.

A key focus of recent development in Expertiza has been the shift to a client-server architecture, where Ruby on Rails functions as the backend and React is utilized for the frontend. This architectural update requires reworking existing modules into RESTful API endpoints, allowing React components to interact efficiently with the backend. By adopting this approach, Expertiza aims to enhance modularity, performance, and scalability.

===Project Description===

The project mainly focuses on reimplementing the StudentTeamsController in Expertiza's backend, which is designed for student-facing operations where students participate in teams. This includes actions that directly affect individual team members, such as adding or removing students from teams, viewing team details, and managing their participation.

The TeamsController, on the other hand, is focused on instructor-driven operations that handle high-level team management across different contexts, such as courses and assignments. It manages operations like team creation, deletion, randomization, and bulk management actions.

===Problem Statement===

The current implementation of the StudentTeamsController in the Expertiza system is overly complex and tightly coupled, leading to difficulties in maintaining and extending the codebase. The controller is responsible for managing student teams in assignments, handling tasks like team creation, editing, management, and the integration of topics in assignments that require team-based decisions. However, it suffers from issues such as:
* Code redundancy and inefficiency due to business logic being embedded directly in the controller.
* Lack of modularity and poor separation of concerns, violating the Single Responsibility Principle (SRP). For example, it also handles the integration with topics when assignments involve choosing topics, complicating the team’s logic.
* Difficult-to-understand methods and tightly coupled logic for handling assignment-specific conditions, such as team-topic associations.
* Poor user feedback that does not provide clear or actionable information after critical operations.

These problems create a system that is hard to scale, maintain, and extend, especially as new features are added. To address these challenges, the goal is to reimplement the StudentTeamsController in the newer Expertiza backend codebase by adhering to object-oriented design principles, specifically focusing on maintainability, scalability, and modularity. The new design will improve the user experience by simplifying controller logic, providing clearer feedback, and ensuring that the system is easier to extend and maintain in the future.

===Objectives===

The main objective is to migrate the Student Task controller logic from serving HTML responses in the Ruby on Rails MVC model to returning JSON responses as a RESTful API, as part of the backend implementation. While reimplementing the controller, the following considerations will be incorporated to ensure a clean, maintainable, and scalable API:

*Reimplement the controller logic and write methods which appropriately follow the Single Responsibility Principle (SRP).
*Move business logic from the controller to appropriate model classes like Team or AssignmentTeam.
*Ensure all method names clearly describe their purpose and represent actions.
*Reimplement a Prototype pattern for creating mentored teams, leveraging the AssignmentTeam class.
*Automatically generate team names when a team is first referred to unless the user has specified a name when requesting team creation.
*Handle team requirements with better abstraction:
*Try to eliminate direct logic in the controller that checks for specific assignment requirements such as topic handling.
*Rename student_team_requirements_met? to something more descriptive and break it into smaller methods checking individual conditions.
*Aim to decouple topics from this controller entirely, ensuring better abstraction, that can involve changes to other classes or introducing service objects to handle specific requirements.
* Improve feedback to users and ensure that the user receives clear and actionable feedback after operations like team creation, removal of users, and other key actions.
* Add comprehensive comments throughout the controller, clearly explaining the purpose and functionality of custom methods.

===Development Strategy===

Our development strategy centers around Test-Driven Development (TDD) principles applied to refactoring the student_teams_controller.rb and other related classes such as Team or AssignmentTeam model. We design out test cases and iteratively refactor code to address identified inefficiencies while ensuring successful test outcomes.
Additionally, we emphasize on the strict adoption of SRP and DRY principles as per the object-oriented programming conventions. Our goal is to reimplement the existing functionalities
In the newly designed back-end foundation to foster a more efficient and organized codebase utilizing newer technologies. This approach will significantly enhance reusability and scalability across all the application while maintaining clean codebase.

Files Modified:
* Created ==>
** app/controllers/api/v1/student_teams_controller.rb
** app/models/assignment_team.rb
** app/models/team.rb
** spec/requests/api/v1/student_teams_controller_spec.rb
** db/migrate/20241201203840_create_assignment_teams.rb
** db/migrate/20241201220020_add_auto_assign_mentor_to_assignments.rb
** db/migrate/20241201221122_add_type_to_teams.rb
** db/migrate/20241202002102_add_name_to_teams.rb

* Updated ==>
** app/models/team.rb
** config/routes.rb
** db/schema.rb
** db/seeds.rb
** spec/swagger_helper.rb

===Project Design and Implementation===

The main approach to be followed throughout this project is to embrace the Prototyping Pattern within the controller while taking into account the current functionalities to be reimplemented within the student_teams_controller.rb that can capitalize its capability to encapsulate distinct controller actions. This strategic implementation aims to ensure seamless extensibility and enhanced usability. By employing this pattern, we establish a structured framework for defining and managing the diverse operations the controller handles, promoting a more organized and manageable code structure.

[[File:2476_UML.drawio.png]]

==== Functionality ====

1. Reimplement the Controller to Follow SRP:
* Break down large, complex methods into smaller, focused methods that adhere to the Single Responsibility Principle (SRP).
* Reimplement existing methods and logic while ensuring that each class and method have a clear, well-defined responsibility.
* Move business logic and complex operations out of the controller and into the appropriate model classes (e.g., Team, AssignmentTeam), ensuring the controller only handles HTTP-specific concerns (e.g., request handling, responses).

2. Improve Method Naming and Clarity:
* Ensure all method names are descriptive and represent the intent of the operation (e.g., renaming methods like student_team_requirements_met? to something more specific like validate_topic_requirements_for_team_creation).
* Adopt consistent naming conventions to improve the readability of the codebase.

3. Implement the Prototype Pattern for Team Creation:
* Leverage the Prototype pattern to create mentored teams through the AssignmentTeam class, allowing for easier management and creation of teams with a mentored structure.
* Automatically generate team names when a team is first created, unless a user has specified a custom name to improve the user experience and simplify team management.

4. Abstract Assignment-Specific Logic:
* Move logic related to assignment-specific requirements (e.g., topic handling) away from the controller, reducing complexity and increasing modularity.
* Introduce service objects or model methods to handle specific requirements like topic assignment, thereby decoupling assignment-related logic from the controller.
* Break down the student_team_requirements_met? method into smaller, more specific checks for different requirements (e.g., topic validation, minimum team size, etc.).

5. Improve User Feedback:
* Enhance the clarity and actionability of feedback messages after key operations (e.g., team creation, user removal, etc.).
* Provide users with clear, helpful notifications on the success or failure of their actions, including any necessary next steps or troubleshooting guidance.
* Ensure error handling is robust, and feedback is specific (e.g., specify which conditions were not met when creating or modifying teams).

6. Commenting and Documentation:
* Add comprehensive comments throughout the controller to clearly explain the purpose and functionality of custom methods and refactored logic.
* Ensure that code is well-documented, making it easier for future developers to understand and extend the functionality of the controller.

===Tasks Completed===

Methods:
* AssignmentTeam Model:
** To access every participant connected to an assignment, the assignment_participants method was added.
** For including a user in the assignment as a participant, the add_participant method was added.
** To see if the team has gotten any peer reviews, the received_any_peer_review? method was put into practice.
** Using a placeholder for future mentor assignment logic, the upgrade_to_mentored_team method was put into practice to replicate the present team and get it ready for mentoring.
** In order to ensure deep duplication of associated records (such as signed_up_teams, teams_users, and participants), the dup method was added to duplicate a team and its associations.

* Team Model:
** Improved the whole procedure to determine if a team has reached its maximum number of members.
** Counted the number of team members using the size approach, removing those with "(Mentor)" in their names.
** In order to eliminate duplicate members and check for team capacity, the add_member method was improved.
** To remove a user from the team, the remove_team_user method was put into place. If the team becomes empty and hasn't been subjected to any peer reviews, the team will be deleted.

Controller - StudentTeamsController.rb
* index: Implemented in order to retrieve and restore every student team together with all of its members.
* show: Created to retrieve and provide information about a certain student team and its members.
* create: Added logic to create a new team for a student, using AssignmentTeam#upgraded_to_mentored_team for mentor-eligible teams and checking for existing team names.
* update: Implemented to enable team details, especially the team name, to be updated while ensuring unique team names through validations.
* destroy: To remove a certain team this was added and, if successful, deliver a 204 No Content response.
* remove_participant: Check if the user is part of the given team and removes from that team, also handles corner cases where no more participants are there in a team.
* add_participant: Added this to add the given participant to respective team.

===Testing Plan===

We have performed comprehensive testing of the student_teams_controller.rb and related classes using RSPEC and Swagger to construct the required test fixtures for testing extensive scenarios. Our approach involves reimplementing the existing test cases provided to the older code base and make sure that it is enhanced by covering more test scenarios to minimize code smells. We aim to verify the reimplemented functionality, validate the restructured code in the student_teams_controller.rb and reduce any design or code smell.
Below are the test scenarios for each of API endpoints -

1. List all Student Teams

Description: List all student teams.
Response: 200 OK
Test Case Scenarios:
Scenario 1: List all Student Teams
Description: Successfully retrieves a list of all student teams.
Expectation: The response status is 200, the content type is `application/json`, and the response body contains 3 student teams.

RSpec.describe 'Student Teams API', type: :request do
path '/api/v1/student_teams' do
# List all Student Teams
get('List all Student Teams') do
tags 'Student Teams'
produces 'application/json'
security [Bearer: {}]
response(200, 'successful') do
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test!
end
end

2. Create a Student Team
Description: Create a new student team.
Response: 201 Created
2.1 Test Data prep:
post 'Create a Student Team' do
tags 'Student Teams'
consumes 'application/json'
let(:institution) do
Institution.create!(
name: 'North Carolina State University'
)
end
let!(:instructor_role) { Role.find_or_create_by(name: 'Instructor') }
let!(:student_role) { Role.find_or_create_by(name: 'Student') }
let(:instructor_user) do
User.create!(
name: 'Dr. Ed Gehringer1',
email: 'gehringer@example.com',
password: 'password123',
full_name: 'admin admin',
institution_id: institution.id,
role_id: instructor_role.id,
handle: 'instructor'
)
end
let(:course) do
Course.create!(
name: '2476. Refactor',
directory_path: '/',
info: 'OODD',
private: false,
instructor_id: instructor_user.id,
institution_id: institution.id
)
end
let(:assignment) do
Assignment.create!(
title: 'Project 4 BRO',
description: '2476. Reimplementing',
course_id: course.id,
instructor_id: instructor_user.id
)
end
let!(:students) do
created_students = []
3.times do |i|
student = User.create!(
name: "Student #{i + 1}",
email: "Student#{i + 1}@gmail.com",
password: 'password123',
full_name: "Student #{i + 1}",
institution_id: institution.id,
role_id: student_role.id,
handle: "Student #{i + 1}"
)
AssignmentParticipant.create!(
assignment: assignment,
user: student,
handle: "Student #{i + 1}"
)
created_students << student
end
created_students
end
parameter name: :student_team_request, in: :body, schema: {
type: :object,
properties: {
team: {
type: :object,
properties: {
name: {type: :string}
}
},
student_id: { type: :integer}
}
}
security [Bearer: {}]
2.2 Scenarios:
Scenario 1: Successfully create a team
Description: Successfully creates a new student team with a valid name and student ID.
Expectation: The response status is 201, and the response body includes the team name.
Scenario 2: Team name is already in use (conflict)
Description: Attempts to create a student team with a name that is already in use.
Expectation: The response status is 422, and the response body includes an error message indicating that the team name is already in use.
Scenario 3: Invalid team creation (empty name)
Description: Attempts to create a student team with an empty name.
Expectation: The response status is 422, and the response body includes an error message.

# Scenario 1: Successfully create a team
response(201, 'created') do
let(:student_team_request) do
{ team: {name: "HelloThere"}, student_id: students.first.id}
end
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test! do
expect(response.status).to eq(201)
end
end
# Scenario 2: Team name is already in use (conflict)
response(422, 'unprocessable entity') do
let(:existing_team) { create(:team, name: 'ABCD10', assignment_id: assignment.id) }
let(:team) do
post '/api/v1/student_teams', params: { team: { name: 'ABCD10' }, student_id: students.first.id }, as: :json
end
run_test! do
expect(response.status).to eq(422)
expect(response.body).to include('"error":"That team name is already in use."')
end
end
# Scenario 3: Invalid team creation (empty name)
response(422, 'unprocessable entity') do
let(:student_team_request) do
{ team: {name: ""}, student_id: students.first.id}
end
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test! do
expect(response.status).to eq(422)
expect(response.body).to include('error')
end
end
response(404, 'not_found') do
let(:team) do
post '/api/v1/student_teams', params: { team: { name: 'ABCD10' }, student_id: 0 }, as: :json
end
run_test! do
expect(response.status).to eq(404)
expect(response.body).to include('not found')
end
end
end

3. Update a Student Team
Description: Update the details of a student team.
Response: 200 OK
Test Case Scenarios:
Scenario 1: Update Student Team
Description: Successfully updates the details of a student team.
Expectation: The response status is 200, and the response body includes the updated details of the student team.

patch('Update a Student Team') do
tags 'Student Teams'
consumes 'application/json'
produces 'application/json'
security [Bearer: {}]
parameter name: :student_team_request, in: :body, schema: {
type: :object,
properties: {
team: {
type: :object,
properties: {
name: {type: :string}
}
},
team_id: { type: :integer}
}
}
# Scenario 1: Team name updated successfully
response(200, 'successful') do
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test! do
expect(response.status).to eq(200)
end
end
# Scenario 2: Invalid team updation (empty name)
response(422, 'unprocessable entity') do
let(:student_team_request) do
{ team: {name: ""}, team_id: 2}
end
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test! do
expect(response.status).to eq(422)
expect(response.body).to include('Team name should not be empty')
end
end
# Scenario 3: Team Name already present
response(422, 'unprocessable entity') do
let(:existing_team) { create(:team, name: 'ABCD10', team_id: 3) }
let(:team) do
post '/api/v1/student_teams', params: { team: { name: 'ABCD10' }, team_id: 2 }, as: :json
end
run_test! do
expect(response.status).to eq(422)
expect(response.body).to include('"error":"That team name is already in use."')
end
end
#Scenario 4 : Invalid Team ID
response(404, 'not_found') do
let(:team) do
post '/api/v1/student_teams', params: { team: { name: 'ABCD10' }, team_id: 0 }, as: :json
end
run_test! do
expect(response.status).to eq(404)
expect(response.body).to include('not found')
end
end
end
end

4. Show a Student Team
Description: Retrieve the details of a student team by its ID.
Response: 200 OK
4.1 Test Case Scenarios:
Scenario 1: Show Student Team
Description: Successfully retrieves the details of a student team by its ID.
Expectation: The response status is 200, and the response body includes the details of the student team.
Scenario 2: Team not found
Description: Attempts to retrieve the details of a student team with an invalid ID.
Expectation: The response status is 404, and the response body includes an error message indicating that the team was not found.
path '/api/v1/student_teams/{id}' do
parameter name: 'id', in: :path, type: :integer
# Get request on /api/v1/student_teams/{id} returns the response 200 succesful - when correct id passed is present in the database
get('Show a Student Team') do
tags 'Student Teams'
produces 'application/json'
security [Bearer: {}]
response(200, 'successful') do
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test! do
expect(response.status).to eq(200)
end
end
# Get request on /api/v1/student_teams/{id} returns the response 404 not found - when correct id passed is not present in the database
response(404, 'not_found') do
let(:id) { 'invalid' }
run_test! do
expect(response.status).to eq(404)
end
end
end

5. Delete a Student Team
Description: Delete a student team by its ID.
Response: 204 No Content
5.1 Scenarios:
Scenario 1: Successfully delete a student team
Description: Successfully deletes a student team by its ID.
Expectation: The response status is 204, and the student team is no longer present in the database.
Scenario 2: Team not found
Description: Attempts to delete a student team with an invalid ID.
Expectation: The response status is 404, and the response body includes an error message indicating that the team was not found.

delete('Delete a Student Team') do
tags 'Student Teams'
produces 'application/json'
security [Bearer: {}]
# delete request on /api/v1/student_teams/{id} returns 204 succesful response when id present in the database is deleted successfully
response(204, 'successful') do
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: ''
}
}
end
run_test! do
expect(response.status).to eq(204)
end
end
# delete request on /api/v1/student_teams/{id} returns 404 not found response, when id is not present in the database
response(404, 'not found') do
let(:id) { 0 }
run_test! do
expect(response.status).to eq(404)
end
end
end
end

6. Add a Participant in Student Team
6.1 Test Data Prep
path '/api/v1/student_teams/{id}/add_participant' do
parameter name: 'id', in: :path, type: :integer, description: 'ID of Team'
parameter name: 'student_id', in: :query, type: :integer, description: 'ID of the Student'
let(:student) { create(:user, :student) }
let(:assignment) { create(:assignment) }
let(:student_participant) { create(:assignment_participant, user: student, assignment: assignment) }
let(:team) { create(:assignment_team, assignment: assignment) }
let(:id) { team.id }
let(:student_id) { student.id }
6.2 Scenarios:
patch('Add a participant to Student Team') do
tags 'Student Teams'
consumes 'application/json'
produces 'application/json'
security [Bearer: {}]
before do
team.add_member(student, assignment.id)
end
response(200, 'successful') do
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test!
end
end
end
7. Remove a Participant in Student Team
7.1 Test data prep:

path '/api/v1/student_teams/{id}/remove_participant' do
parameter name: 'id', in: :path, type: :integer, description: 'ID of Team'
parameter name: 'student_id', in: :query, type: :integer, description: 'ID of the Student'
let(:student) { create(:user, :student) }
let(:assignment) { create(:assignment) }
let(:student_participant) { create(:assignment_participant, user: student, assignment: assignment) }
let(:team) { create(:assignment_team, assignment: assignment) }
let(:id) { team.id }
let(:student_id) { student.id }
before do
team.add_member(student, assignment.id)
end
Scenarios:
delete('remove participant') do
tags 'Student Teams'
produces 'application/json'
security [Bearer: {}]
response(204, 'successful') do
let(:Authorization) { "Bearer #{@token}" }
run_test! do
expect(response.status).to eq(204)
expect(team.members).not_to include(student)
end
end
response(404, 'team not found') do
let(:id) { -1 } # Invalid ID
run_test! do
expect(response.status).to eq(404)
expect(JSON.parse(response.body)['error']).to eq('Team not found.')
end
end
response(404, 'user not found') do
let(:student_id) { -1 } # Invalid student ID
run_test! do
expect(response.status).to eq(404)
expect(JSON.parse(response.body)['error']).to eq('User not found.')
end
end
end
end

===Mentor===

* Ammana, Sahithi <sammana@ncsu.edu>

===Team Members===

* Eathamukkala, Akarsh Reddy <aeatham@ncsu.edu>
* Koul, Anmol <akoul2@ncsu.edu>
* More, Harsh Manoj <hmore@ncsu.edu>

CSC/ECE 517 Fall 2024 - E2476. Reimplement student teams controller.rb

2024-12-04T03:45:23Z

Akoul2: /* Testing Plan */

===Introduction===
[http://expertiza.ncsu.edu/ Expertiza] is an open-source system built on [http://rubyonrails.org/ Ruby on Rails], collaboratively maintained by students and faculty at NC State. This platform gives instructors extensive control over assignments, enabling them to add topics, create assignment groups, and manage peer reviews for various types of coursework. Expertiza is well-equipped to handle submissions across multiple formats, including URLs and wiki pages, and it offers a peer review system that facilitates constructive feedback among students.

A key focus of recent development in Expertiza has been the shift to a client-server architecture, where Ruby on Rails functions as the backend and React is utilized for the frontend. This architectural update requires reworking existing modules into RESTful API endpoints, allowing React components to interact efficiently with the backend. By adopting this approach, Expertiza aims to enhance modularity, performance, and scalability.

===Project Description===

The project mainly focuses on reimplementing the StudentTeamsController in Expertiza's backend, which is designed for student-facing operations where students participate in teams. This includes actions that directly affect individual team members, such as adding or removing students from teams, viewing team details, and managing their participation.

The TeamsController, on the other hand, is focused on instructor-driven operations that handle high-level team management across different contexts, such as courses and assignments. It manages operations like team creation, deletion, randomization, and bulk management actions.

===Problem Statement===

The current implementation of the StudentTeamsController in the Expertiza system is overly complex and tightly coupled, leading to difficulties in maintaining and extending the codebase. The controller is responsible for managing student teams in assignments, handling tasks like team creation, editing, management, and the integration of topics in assignments that require team-based decisions. However, it suffers from issues such as:
* Code redundancy and inefficiency due to business logic being embedded directly in the controller.
* Lack of modularity and poor separation of concerns, violating the Single Responsibility Principle (SRP). For example, it also handles the integration with topics when assignments involve choosing topics, complicating the team’s logic.
* Difficult-to-understand methods and tightly coupled logic for handling assignment-specific conditions, such as team-topic associations.
* Poor user feedback that does not provide clear or actionable information after critical operations.

These problems create a system that is hard to scale, maintain, and extend, especially as new features are added. To address these challenges, the goal is to reimplement the StudentTeamsController in the newer Expertiza backend codebase by adhering to object-oriented design principles, specifically focusing on maintainability, scalability, and modularity. The new design will improve the user experience by simplifying controller logic, providing clearer feedback, and ensuring that the system is easier to extend and maintain in the future.

===Objectives===

The main objective is to migrate the Student Task controller logic from serving HTML responses in the Ruby on Rails MVC model to returning JSON responses as a RESTful API, as part of the backend implementation. While reimplementing the controller, the following considerations will be incorporated to ensure a clean, maintainable, and scalable API:

*Reimplement the controller logic and write methods which appropriately follow the Single Responsibility Principle (SRP).
*Move business logic from the controller to appropriate model classes like Team or AssignmentTeam.
*Ensure all method names clearly describe their purpose and represent actions.
*Reimplement a Prototype pattern for creating mentored teams, leveraging the AssignmentTeam class.
*Automatically generate team names when a team is first referred to unless the user has specified a name when requesting team creation.
*Handle team requirements with better abstraction:
*Try to eliminate direct logic in the controller that checks for specific assignment requirements such as topic handling.
*Rename student_team_requirements_met? to something more descriptive and break it into smaller methods checking individual conditions.
*Aim to decouple topics from this controller entirely, ensuring better abstraction, that can involve changes to other classes or introducing service objects to handle specific requirements.
* Improve feedback to users and ensure that the user receives clear and actionable feedback after operations like team creation, removal of users, and other key actions.
* Add comprehensive comments throughout the controller, clearly explaining the purpose and functionality of custom methods.

===Development Strategy===

Our development strategy centers around Test-Driven Development (TDD) principles applied to refactoring the student_teams_controller.rb and other related classes such as Team or AssignmentTeam model. We design out test cases and iteratively refactor code to address identified inefficiencies while ensuring successful test outcomes.
Additionally, we emphasize on the strict adoption of SRP and DRY principles as per the object-oriented programming conventions. Our goal is to reimplement the existing functionalities
In the newly designed back-end foundation to foster a more efficient and organized codebase utilizing newer technologies. This approach will significantly enhance reusability and scalability across all the application while maintaining clean codebase.

===Project Design and Implementation===

The main approach to be followed throughout this project is to embrace the Prototyping Pattern within the controller while taking into account the current functionalities to be reimplemented within the student_teams_controller.rb that can capitalize its capability to encapsulate distinct controller actions. This strategic implementation aims to ensure seamless extensibility and enhanced usability. By employing this pattern, we establish a structured framework for defining and managing the diverse operations the controller handles, promoting a more organized and manageable code structure.

[[File:2476_UML.drawio.png]]

==== Functionality ====

1. Reimplement the Controller to Follow SRP:
* Break down large, complex methods into smaller, focused methods that adhere to the Single Responsibility Principle (SRP).
* Reimplement existing methods and logic while ensuring that each class and method have a clear, well-defined responsibility.
* Move business logic and complex operations out of the controller and into the appropriate model classes (e.g., Team, AssignmentTeam), ensuring the controller only handles HTTP-specific concerns (e.g., request handling, responses).

2. Improve Method Naming and Clarity:
* Ensure all method names are descriptive and represent the intent of the operation (e.g., renaming methods like student_team_requirements_met? to something more specific like validate_topic_requirements_for_team_creation).
* Adopt consistent naming conventions to improve the readability of the codebase.

3. Implement the Prototype Pattern for Team Creation:
* Leverage the Prototype pattern to create mentored teams through the AssignmentTeam class, allowing for easier management and creation of teams with a mentored structure.
* Automatically generate team names when a team is first created, unless a user has specified a custom name to improve the user experience and simplify team management.

4. Abstract Assignment-Specific Logic:
* Move logic related to assignment-specific requirements (e.g., topic handling) away from the controller, reducing complexity and increasing modularity.
* Introduce service objects or model methods to handle specific requirements like topic assignment, thereby decoupling assignment-related logic from the controller.
* Break down the student_team_requirements_met? method into smaller, more specific checks for different requirements (e.g., topic validation, minimum team size, etc.).

5. Improve User Feedback:
* Enhance the clarity and actionability of feedback messages after key operations (e.g., team creation, user removal, etc.).
* Provide users with clear, helpful notifications on the success or failure of their actions, including any necessary next steps or troubleshooting guidance.
* Ensure error handling is robust, and feedback is specific (e.g., specify which conditions were not met when creating or modifying teams).

6. Commenting and Documentation:
* Add comprehensive comments throughout the controller to clearly explain the purpose and functionality of custom methods and refactored logic.
* Ensure that code is well-documented, making it easier for future developers to understand and extend the functionality of the controller.

===Testing Plan===

We have performed comprehensive testing of the student_teams_controller.rb and related classes using RSPEC and Swagger to construct the required test fixtures for testing extensive scenarios. Our approach involves reimplementing the existing test cases provided to the older code base and make sure that it is enhanced by covering more test scenarios to minimize code smells. We aim to verify the reimplemented functionality, validate the restructured code in the student_teams_controller.rb and reduce any design or code smell.
Below are the test scenarios for each of API endpoints -

1. List all Student Teams
RSpec.describe 'Student Teams API', type: :request do
path '/api/v1/student_teams' do
# List all Student Teams
get('List all Student Teams') do
tags 'Student Teams'
produces 'application/json'
security [Bearer: {}]
response(200, 'successful') do
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test!
end
end

2. Create a Student Team
post 'Create a Student Team' do
tags 'Student Teams'
consumes 'application/json'
let(:institution) do
Institution.create!(
name: 'North Carolina State University'
)
end
let!(:instructor_role) { Role.find_or_create_by(name: 'Instructor') }
let!(:student_role) { Role.find_or_create_by(name: 'Student') }
let(:instructor_user) do
User.create!(
name: 'Dr. Ed Gehringer1',
email: 'gehringer@example.com',
password: 'password123',
full_name: 'admin admin',
institution_id: institution.id,
role_id: instructor_role.id,
handle: 'instructor'
)
end
let(:course) do
Course.create!(
name: '2476. Refactor',
directory_path: '/',
info: 'OODD',
private: false,
instructor_id: instructor_user.id,
institution_id: institution.id
)
end
let(:assignment) do
Assignment.create!(
title: 'Project 4 BRO',
description: '2476. Reimplementing',
course_id: course.id,
instructor_id: instructor_user.id
)
end
let!(:students) do
created_students = []
3.times do |i|
student = User.create!(
name: "Student #{i + 1}",
email: "Student#{i + 1}@gmail.com",
password: 'password123',
full_name: "Student #{i + 1}",
institution_id: institution.id,
role_id: student_role.id,
handle: "Student #{i + 1}"
)
AssignmentParticipant.create!(
assignment: assignment,
user: student,
handle: "Student #{i + 1}"
)
created_students << student
end
created_students
end

parameter name: :student_team_request, in: :body, schema: {
type: :object,
properties: {
team: {
type: :object,
properties: {
name: {type: :string}
}
},
student_id: { type: :integer}
}
}
security [Bearer: {}]
# Scenario 1: Successfully create a team
response(201, 'created') do
let(:student_team_request) do
{ team: {name: "HelloThere"}, student_id: students.first.id}
end
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test! do
expect(response.status).to eq(201)
end
end
# Scenario 2: Team name is already in use (conflict)
response(422, 'unprocessable entity') do
let(:existing_team) { create(:team, name: 'ABCD10', assignment_id: assignment.id) }
let(:team) do
post '/api/v1/student_teams', params: { team: { name: 'ABCD10' }, student_id: students.first.id }, as: :json
end
run_test! do
expect(response.status).to eq(422)
expect(response.body).to include('"error":"That team name is already in use."')
end
end
# Scenario 3: Invalid team creation (empty name)
response(422, 'unprocessable entity') do
let(:student_team_request) do
{ team: {name: ""}, student_id: students.first.id}
end
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test! do
expect(response.status).to eq(422)
expect(response.body).to include('error')
end
end
response(404, 'not_found') do
let(:team) do
post '/api/v1/student_teams', params: { team: { name: 'ABCD10' }, student_id: 0 }, as: :json
end
run_test! do
expect(response.status).to eq(404)
expect(response.body).to include('not found')
end
end
end

3. Update a Student Team
patch('Update a Student Team') do
tags 'Student Teams'
consumes 'application/json'
produces 'application/json'
security [Bearer: {}]
parameter name: :student_team_request, in: :body, schema: {
type: :object,
properties: {
team: {
type: :object,
properties: {
name: {type: :string}
}
},
team_id: { type: :integer}
}
}
# Scenario 1: Team name updated successfully
response(200, 'successful') do
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test! do
expect(response.status).to eq(200)
end
end
# Scenario 2: Invalid team updation (empty name)
response(422, 'unprocessable entity') do
let(:student_team_request) do
{ team: {name: ""}, team_id: 2}
end
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test! do
expect(response.status).to eq(422)
expect(response.body).to include('Team name should not be empty')
end
end
# Scenario 3: Team Name already present
response(422, 'unprocessable entity') do
let(:existing_team) { create(:team, name: 'ABCD10', team_id: 3) }
let(:team) do
post '/api/v1/student_teams', params: { team: { name: 'ABCD10' }, team_id: 2 }, as: :json
end
run_test! do
expect(response.status).to eq(422)
expect(response.body).to include('"error":"That team name is already in use."')
end
end
#Scenario 4 : Invalid Team ID
response(404, 'not_found') do
let(:team) do
post '/api/v1/student_teams', params: { team: { name: 'ABCD10' }, team_id: 0 }, as: :json
end
run_test! do
expect(response.status).to eq(404)
expect(response.body).to include('not found')
end
end
end
end

4. Show a Student Team
path '/api/v1/student_teams/{id}' do
parameter name: 'id', in: :path, type: :integer
# Get request on /api/v1/student_teams/{id} returns the response 200 succesful - when correct id passed is present in the database
get('Show a Student Team') do
tags 'Student Teams'
produces 'application/json'
security [Bearer: {}]
response(200, 'successful') do
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test! do
expect(response.status).to eq(200)
end
end
# Get request on /api/v1/student_teams/{id} returns the response 404 not found - when correct id passed is not present in the database
response(404, 'not_found') do
let(:id) { 'invalid' }
run_test! do
expect(response.status).to eq(404)
end
end
end

5. Delete a Student Team
delete('Delete a Student Team') do
tags 'Student Teams'
produces 'application/json'
security [Bearer: {}]
# delete request on /api/v1/student_teams/{id} returns 204 succesful response when id present in the database is deleted successfully
response(204, 'successful') do
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: ''
}
}
end
run_test! do
expect(response.status).to eq(204)
end
end
# delete request on /api/v1/student_teams/{id} returns 404 not found response, when id is not present in the database
response(404, 'not found') do
let(:id) { 0 }
run_test! do
expect(response.status).to eq(404)
end
end
end
end

6. Add a Participant in Student Team
path '/api/v1/student_teams/{id}/add_participant' do
parameter name: 'id', in: :path, type: :integer, description: 'ID of Team'
parameter name: 'student_id', in: :query, type: :integer, description: 'ID of the Student'
let(:student) { create(:user, :student) }
let(:assignment) { create(:assignment) }
let(:student_participant) { create(:assignment_participant, user: student, assignment: assignment) }
let(:team) { create(:assignment_team, assignment: assignment) }
let(:id) { team.id }
let(:student_id) { student.id }
patch('Add a participant to Student Team') do
tags 'Student Teams'
consumes 'application/json'
produces 'application/json'
security [Bearer: {}]
before do
team.add_member(student, assignment.id)
end
response(200, 'successful') do
after do |example|
example.metadata[:response][:content] = {
'application/json' => {
example: JSON.parse(response.body, symbolize_names: true)
}
}
end
run_test!
end
end
end
7. Remove a Participant in Student Team
path '/api/v1/student_teams/{id}/remove_participant' do
parameter name: 'id', in: :path, type: :integer, description: 'ID of Team'
parameter name: 'student_id', in: :query, type: :integer, description: 'ID of the Student'
let(:student) { create(:user, :student) }
let(:assignment) { create(:assignment) }
let(:student_participant) { create(:assignment_participant, user: student, assignment: assignment) }
let(:team) { create(:assignment_team, assignment: assignment) }
let(:id) { team.id }
let(:student_id) { student.id }
before do
team.add_member(student, assignment.id)
end
delete('remove participant') do
tags 'Student Teams'
produces 'application/json'
security [Bearer: {}]
response(204, 'successful') do
let(:Authorization) { "Bearer #{@token}" }
run_test! do
expect(response.status).to eq(204)
expect(team.members).not_to include(student)
end
end
response(404, 'team not found') do
let(:id) { -1 } # Invalid ID
run_test! do
expect(response.status).to eq(404)
expect(JSON.parse(response.body)['error']).to eq('Team not found.')
end
end
response(404, 'user not found') do
let(:student_id) { -1 } # Invalid student ID
run_test! do
expect(response.status).to eq(404)
expect(JSON.parse(response.body)['error']).to eq('User not found.')
end
end
end
end

===Mentor===

* Ammana, Sahithi <sammana@ncsu.edu>

===Team Members===

* Eathamukkala, Akarsh Reddy <aeatham@ncsu.edu>
* Koul, Anmol <akoul2@ncsu.edu>
* More, Harsh Manoj <hmore@ncsu.edu>

CSC/ECE 517 Fall 2024 - E2476. Reimplement student teams controller.rb

2024-12-04T03:40:26Z

Akoul2: /* Adding All Testing Plans */

CSC/ECE 517 Fall 2024 - E2476. Reimplement student teams controller.rb

2024-11-12T21:00:42Z

Akoul2: /* Objectives */

===Project Description===

The project mainly focusses on reimplementing StudentTeamsController that is designed for student-facing operations where students are participants in teams. This includes actions that directly affect individual team members, such as adding or removing students from teams, viewing team details, and managing their participation.
TeamsController is focused on instructor-driven operations that deal with the high-level management of teams across different contexts like courses and assignments. It handles operations such as team creation, deletion, randomization, and bulk management actions.

===Problem Statement===

The current implementation of the StudentTeamsController in the Expertiza system is overly complex and tightly coupled, leading to difficulties in maintaining and extending the codebase. The controller is responsible for managing student teams in assignments, handling tasks like team creation, editing, management, and the integration of topics in assignments that require team-based decisions. However, it suffers from issues such as:
* Code redundancy and inefficiency due to business logic being embedded directly in the controller.
* Lack of modularity and poor separation of concerns, violating the Single Responsibility Principle (SRP).
* Difficult-to-understand methods and tightly coupled logic for handling assignment-specific conditions, such as team-topic associations.
* Poor user feedback that does not provide clear or actionable information after critical operations.

These problems create a system that is hard to scale, maintain, and extend, especially as new features are added. To address these challenges, the goal is to reimplement the StudentTeamsController in the newer Expertiza backend codebase by adhering to object-oriented design principles, specifically focusing on maintainability, scalability, and modularity. The new design will improve the user experience by simplifying controller logic, providing clearer feedback, and ensuring that the system is easier to extend and maintain in the future.

===Objectives===

*Reimplement the controller logic and write methods which appropriately follow the Single Responsibility Principle (SRP).
*Move business logic from the controller to appropriate model classes like Team or AssignmentTeam.
*Ensure all method names clearly describe their purpose and represent actions.
*Reimplement a Prototype pattern for creating mentored teams, leveraging the AssignmentTeam class.
*Automatically generate team names when a team is first referred to unless the user has specified a name when requesting team creation.
*Handle team requirements with better abstraction:
*Try to eliminate direct logic in the controller that checks for specific assignment requirements such as topic handling.
*Rename student_team_requirements_met? to something more descriptive and break it into smaller methods checking individual conditions.
*Aim to decouple topics from this controller entirely, ensuring better abstraction, that can involve changes to other classes or introducing service objects to handle specific requirements.
* Improve feedback to users and ensure that the user receives clear and actionable feedback after operations like team creation, removal of users, and other key actions.
* Add comprehensive comments throughout the controller, clearly explaining the purpose and functionality of custom methods.

===Development Strategy===

Our development strategy centers around Test-Driven Development (TDD) principles applied to refactoring the student_teams_controller.rb and other related classes such as Team or AssignmentTeam model. We design out test cases and iteratively refactor code to address identified inefficiencies while ensuring successful test outcomes.
Additionally, we emphasize on the strict adoption of SRP and DRY principles as per the object-oriented programming conventions. Our goal is to reimplement the existing functionalities
In the newly designed back-end foundation to foster a more efficient and organized codebase utilizing newer technologies. This approach will significantly enhance reusability and scalability across all the application while maintaining clean codebase.

===Project Design and Implementation===

The main approach to be followed throughout this project is to embrace the Prototyping Pattern within the controller while taking into account the current functionalities to be reimplemented within the student_teams_controller.rb that can capitalize its capability to encapsulate distinct controller actions. This strategic implementation aims to ensure seamless extensibility and enhanced usability. By employing this pattern, we establish a structured framework for defining and managing the diverse operations the controller handles, promoting a more organized and manageable code structure.

==== Functionality ====

1. Reimplement the Controller to Follow SRP:
* Break down large, complex methods into smaller, focused methods that adhere to the Single Responsibility Principle (SRP).
* Reimplement existing methods and logic while ensuring that each class and method have a clear, well-defined responsibility.
* Move business logic and complex operations out of the controller and into the appropriate model classes (e.g., Team, AssignmentTeam), ensuring the controller only handles HTTP-specific concerns (e.g., request handling, responses).

2. Improve Method Naming and Clarity:
* Ensure all method names are descriptive and represent the intent of the operation (e.g., renaming methods like student_team_requirements_met? to something more specific like validate_topic_requirements_for_team_creation).
* Adopt consistent naming conventions to improve the readability of the codebase.

3. Implement the Prototype Pattern for Team Creation:
* Leverage the Prototype pattern to create mentored teams through the AssignmentTeam class, allowing for easier management and creation of teams with a mentored structure.
* Automatically generate team names when a team is first created, unless a user has specified a custom name to improve the user experience and simplify team management.

4. Abstract Assignment-Specific Logic:
* Move logic related to assignment-specific requirements (e.g., topic handling) away from the controller, reducing complexity and increasing modularity.
* Introduce service objects or model methods to handle specific requirements like topic assignment, thereby decoupling assignment-related logic from the controller.
* Break down the student_team_requirements_met? method into smaller, more specific checks for different requirements (e.g., topic validation, minimum team size, etc.).

5. Improve User Feedback:
* Enhance the clarity and actionability of feedback messages after key operations (e.g., team creation, user removal, etc.).
* Provide users with clear, helpful notifications on the success or failure of their actions, including any necessary next steps or troubleshooting guidance.
* Ensure error handling is robust, and feedback is specific (e.g., specify which conditions were not met when creating or modifying teams).

6. Commenting and Documentation:
* Add comprehensive comments throughout the controller to clearly explain the purpose and functionality of custom methods and refactored logic.
* Ensure that code is well-documented, making it easier for future developers to understand and extend the functionality of the controller.

===Testing Plan===

We plan to perform comprehensive testing of the student_teams_controller.rb and related classes using RSPEC and leverage FactoryBot to construct the required test fixtures for testing extensive scenarios. Our approach involves reimplementing the existing test cases provided to the older code base and make sure that it is enhanced by covering more test scenarios to minimize code smells. We aim to verify the reimplemented functionality, validate the restructured code in the student_teams_controller.rb and reduce any design or code smell.

===Mentor===

* Ammana, Sahithi <sammana@ncsu.edu>

===Team Members===

* Eathamukkala, Akarsh Reddy <aeatham@ncsu.edu>
* Koul, Anmol <akoul2@ncsu.edu>
* More, Harsh Manoj <hmore@ncsu.edu>

CSC/ECE 517 Fall 2024 - E2476. Reimplement student teams controller.rb

2024-11-12T21:00:07Z

Akoul2: minor update

===Project Description===

The project mainly focusses on reimplementing StudentTeamsController that is designed for student-facing operations where students are participants in teams. This includes actions that directly affect individual team members, such as adding or removing students from teams, viewing team details, and managing their participation.
TeamsController is focused on instructor-driven operations that deal with the high-level management of teams across different contexts like courses and assignments. It handles operations such as team creation, deletion, randomization, and bulk management actions.

===Problem Statement===

The current implementation of the StudentTeamsController in the Expertiza system is overly complex and tightly coupled, leading to difficulties in maintaining and extending the codebase. The controller is responsible for managing student teams in assignments, handling tasks like team creation, editing, management, and the integration of topics in assignments that require team-based decisions. However, it suffers from issues such as:
* Code redundancy and inefficiency due to business logic being embedded directly in the controller.
* Lack of modularity and poor separation of concerns, violating the Single Responsibility Principle (SRP).
* Difficult-to-understand methods and tightly coupled logic for handling assignment-specific conditions, such as team-topic associations.
* Poor user feedback that does not provide clear or actionable information after critical operations.

These problems create a system that is hard to scale, maintain, and extend, especially as new features are added. To address these challenges, the goal is to reimplement the StudentTeamsController in the newer Expertiza backend codebase by adhering to object-oriented design principles, specifically focusing on maintainability, scalability, and modularity. The new design will improve the user experience by simplifying controller logic, providing clearer feedback, and ensuring that the system is easier to extend and maintain in the future.

===Objectives===

*Reimplement the controller logic and write methods which appropriately follow the Single Responsibility Principle (SRP).
*Move business logic from the controller to appropriate model classes like Team or AssignmentTeam.
*Ensure all method names clearly describe their purpose and represent actions.
*Reimplement a Prototype pattern for creating mentored teams, leveraging the AssignmentTeam class.
*Automatically generate team names when a team is first referred to unless the user has specified a name when requesting team creation.
*Handle team requirements with better abstraction:
*Try to eliminate direct logic in the controller that checks for specific assignment requirements such as topic handling.
*Rename student_team_requirements_met? to something more descriptive and break it into smaller methods checking individual conditions.
*Aim to decouple topics from this controller entirely, ensuring better abstraction, that can involve changes to other classes or introducing service objects to handle specific requirements.
* Improve feedback to users:
Ensure that the user receives clear and actionable feedback after operations like team creation, removal of users, and other key actions.
* Add comprehensive comments throughout the controller, clearly explaining the purpose and functionality of custom methods.

===Development Strategy===

Our development strategy centers around Test-Driven Development (TDD) principles applied to refactoring the student_teams_controller.rb and other related classes such as Team or AssignmentTeam model. We design out test cases and iteratively refactor code to address identified inefficiencies while ensuring successful test outcomes.
Additionally, we emphasize on the strict adoption of SRP and DRY principles as per the object-oriented programming conventions. Our goal is to reimplement the existing functionalities
In the newly designed back-end foundation to foster a more efficient and organized codebase utilizing newer technologies. This approach will significantly enhance reusability and scalability across all the application while maintaining clean codebase.

===Project Design and Implementation===

The main approach to be followed throughout this project is to embrace the Prototyping Pattern within the controller while taking into account the current functionalities to be reimplemented within the student_teams_controller.rb that can capitalize its capability to encapsulate distinct controller actions. This strategic implementation aims to ensure seamless extensibility and enhanced usability. By employing this pattern, we establish a structured framework for defining and managing the diverse operations the controller handles, promoting a more organized and manageable code structure.

==== Functionality ====

1. Reimplement the Controller to Follow SRP:
* Break down large, complex methods into smaller, focused methods that adhere to the Single Responsibility Principle (SRP).
* Reimplement existing methods and logic while ensuring that each class and method have a clear, well-defined responsibility.
* Move business logic and complex operations out of the controller and into the appropriate model classes (e.g., Team, AssignmentTeam), ensuring the controller only handles HTTP-specific concerns (e.g., request handling, responses).

2. Improve Method Naming and Clarity:
* Ensure all method names are descriptive and represent the intent of the operation (e.g., renaming methods like student_team_requirements_met? to something more specific like validate_topic_requirements_for_team_creation).
* Adopt consistent naming conventions to improve the readability of the codebase.

3. Implement the Prototype Pattern for Team Creation:
* Leverage the Prototype pattern to create mentored teams through the AssignmentTeam class, allowing for easier management and creation of teams with a mentored structure.
* Automatically generate team names when a team is first created, unless a user has specified a custom name to improve the user experience and simplify team management.

4. Abstract Assignment-Specific Logic:
* Move logic related to assignment-specific requirements (e.g., topic handling) away from the controller, reducing complexity and increasing modularity.
* Introduce service objects or model methods to handle specific requirements like topic assignment, thereby decoupling assignment-related logic from the controller.
* Break down the student_team_requirements_met? method into smaller, more specific checks for different requirements (e.g., topic validation, minimum team size, etc.).

5. Improve User Feedback:
* Enhance the clarity and actionability of feedback messages after key operations (e.g., team creation, user removal, etc.).
* Provide users with clear, helpful notifications on the success or failure of their actions, including any necessary next steps or troubleshooting guidance.
* Ensure error handling is robust, and feedback is specific (e.g., specify which conditions were not met when creating or modifying teams).

6. Commenting and Documentation:
* Add comprehensive comments throughout the controller to clearly explain the purpose and functionality of custom methods and refactored logic.
* Ensure that code is well-documented, making it easier for future developers to understand and extend the functionality of the controller.

===Testing Plan===

We plan to perform comprehensive testing of the student_teams_controller.rb and related classes using RSPEC and leverage FactoryBot to construct the required test fixtures for testing extensive scenarios. Our approach involves reimplementing the existing test cases provided to the older code base and make sure that it is enhanced by covering more test scenarios to minimize code smells. We aim to verify the reimplemented functionality, validate the restructured code in the student_teams_controller.rb and reduce any design or code smell.

===Mentor===

* Ammana, Sahithi <sammana@ncsu.edu>

===Team Members===

* Eathamukkala, Akarsh Reddy <aeatham@ncsu.edu>
* Koul, Anmol <akoul2@ncsu.edu>
* More, Harsh Manoj <hmore@ncsu.edu>

CSC/ECE 517 Fall 2024 - E2476. Reimplement student teams controller.rb

2024-11-12T20:46:19Z

Akoul2: /* Problem Statement */

===Project Description===

The project mainly focusses on reimplementing StudentTeamsController that is designed for student-facing operations where students are participants in teams. This includes actions that directly affect individual team members, such as adding or removing students from teams, viewing team details, and managing their participation.
TeamsController is focused on instructor-driven operations that deal with the high-level management of teams across different contexts like courses and assignments. It handles operations such as team creation, deletion, randomization, and bulk management actions.

===Problem Statement===

The current implementation of the StudentTeamsController in the Expertiza system is overly complex and tightly coupled, leading to difficulties in maintaining and extending the codebase. The controller is responsible for managing student teams in assignments, handling tasks like team creation, editing, management, and the integration of topics in assignments that require team-based decisions. However, it suffers from issues such as:
* Code redundancy and inefficiency due to business logic being embedded directly in the controller.
* Lack of modularity and poor separation of concerns, violating the Single Responsibility Principle (SRP).
* Difficult-to-understand methods and tightly coupled logic for handling assignment-specific conditions, such as team-topic associations.
* Poor user feedback that does not provide clear or actionable information after critical operations.

These problems create a system that is hard to scale, maintain, and extend, especially as new features are added. To address these challenges, the goal is to reimplement the StudentTeamsController in the newer Expertiza backend codebase by adhering to object-oriented design principles, specifically focusing on maintainability, scalability, and modularity. The new design will improve the user experience by simplifying controller logic, providing clearer feedback, and ensuring that the system is easier to extend and maintain in the future.

===Objectives===

*Reimplement the controller logic and write methods which appropriately follow the Single Responsibility Principle (SRP).
*Move business logic from the controller to appropriate model classes like Team or AssignmentTeam.
*Ensure all method names clearly describe their purpose and represent actions.
*Reimplement a Prototype pattern for creating mentored teams, leveraging the AssignmentTeam class.
*Automatically generate team names when a team is first referred to unless the user has specified a name when requesting team creation.
*Handle team requirements with better abstraction:
*Try to eliminate direct logic in the controller that checks for specific assignment requirements such as topic handling.
*Rename student_team_requirements_met? to something more descriptive and break it into smaller methods checking individual conditions.
*Aim to decouple topics from this controller entirely, ensuring better abstraction, that can involve changes to other classes or introducing service objects to handle specific requirements.
* Improve feedback to users:
Ensure that the user receives clear and actionable feedback after operations like team creation, removal of users, and other key actions.
* Add comprehensive comments throughout the controller, clearly explaining the purpose and functionality of custom methods.

===Development Strategy===

Our development strategy centers around Test-Driven Development (TDD) principles applied to refactoring the student_teams_controller.rb and other related classes such as Team or AssignmentTeam model. We design out test cases and iteratively refactor code to address identified inefficiencies while ensuring successful test outcomes.
Additionally, we emphasize on the strict adoption of SRP and DRY principles as per the object-oriented programming conventions. Our goal is to reimplement the existing functionalities
In the newly designed back-end foundation to foster a more efficient and organized codebase utilizing newer technologies. This approach will significantly enhance reusability and scalability across all the application while maintaining clean codebase.

===Project Design and Implementation===

The main approach to be followed throughout this project is to embrace the Prototyping Pattern within the controller while taking into account the current functionalities to be reimplemented within the student_teams_controller.rb that can capitalize its capability to encapsulate distinct controller actions. This strategic implementation aims to ensure seamless extensibility and enhanced usability. By employing this pattern, we establish a structured framework for defining and managing the diverse operations the controller handles, promoting a more organized and manageable code structure.

==== Functionality ====

1. Reimplement the Controller to Follow SRP:
* Break down large, complex methods into smaller, focused methods that adhere to the Single Responsibility Principle (SRP).
* Reimplement existing methods and logic while ensuring that each class and method have a clear, well-defined responsibility.
* Move business logic and complex operations out of the controller and into the appropriate model classes (e.g., Team, AssignmentTeam), ensuring the controller only handles
HTTP-specific concerns (e.g., request handling, responses).

2. Improve Method Naming and Clarity:
* Ensure all method names are descriptive and represent the intent of the operation (e.g., renaming methods like student_team_requirements_met? to something more specific
like validate_topic_requirements_for_team_creation).
* Adopt consistent naming conventions to improve the readability of the codebase.

3. Implement the Prototype Pattern for Team Creation:
* Leverage the Prototype pattern to create mentored teams through the AssignmentTeam class, allowing for easier management and creation of teams with a mentored structure.
* Automatically generate team names when a team is first created, unless a user has specified a custom name to improve the user experience and simplify team management.

4. Abstract Assignment-Specific Logic:
* Move logic related to assignment-specific requirements (e.g., topic handling) away from the controller, reducing complexity and increasing modularity.
* Introduce service objects or model methods to handle specific requirements like topic assignment, thereby decoupling assignment-related logic from the controller.
* Break down the student_team_requirements_met? method into smaller, more specific checks for different requirements (e.g., topic validation, minimum team size, etc.).

5. Improve User Feedback:
* Enhance the clarity and actionability of feedback messages after key operations (e.g., team creation, user removal, etc.).
* Provide users with clear, helpful notifications on the success or failure of their actions, including any necessary next steps or troubleshooting guidance.
* Ensure error handling is robust, and feedback is specific (e.g., specify which conditions were not met when creating or modifying teams).

6. Commenting and Documentation:
* Add comprehensive comments throughout the controller to clearly explain the purpose and functionality of custom methods and refactored logic.
* Ensure that code is well-documented, making it easier for future developers to understand and extend the functionality of the controller.

===Testing Plan===

We plan to perform comprehensive testing of the student_teams_controller.rb and related classes using RSPEC and leverage FactoryBot to construct the required test fixtures for testing extensive scenarios. Our approach involves reimplementing the existing test cases provided to the older code base and make sure that it is enhanced by covering more test scenarios to minimize code smells. We aim to verify the reimplemented functionality, validate the restructured code in the student_teams_controller.rb and reduce any design or code smell.

===Mentor===

* Ammana, Sahithi <sammana@ncsu.edu>

===Team Members===

* Eathamukkala, Akarsh Reddy <aeatham@ncsu.edu>
* Koul, Anmol <akoul2@ncsu.edu>
* More, Harsh Manoj <hmore@ncsu.edu>

CSC/ECE 517 Fall 2024 - E2476. Reimplement student teams controller.rb

2024-11-12T20:38:10Z

Akoul2: /* Functionality */

===Project Description===

The project mainly focusses on reimplementing StudentTeamsController that is designed for student-facing operations where students are participants in teams. This includes actions that directly affect individual team members, such as adding or removing students from teams, viewing team details, and managing their participation.
TeamsController is focused on instructor-driven operations that deal with the high-level management of teams across different contexts like courses and assignments. It handles operations such as team creation, deletion, randomization, and bulk management actions.

===Problem Statement===

The current implementation of the StudentTeamsController in the Expertiza system is overly complex and tightly coupled, leading to difficulties in maintaining and extending the codebase. The controller is responsible for managing student teams in assignments, handling tasks like team creation, editing, management, and the integration of topics in assignments that require team-based decisions. However, it suffers from issues such as:
* Code redundancy and inefficiency due to business logic being embedded directly in the controller.
* Lack of modularity and poor separation of concerns, violating the Single Responsibility Principle (SRP).
* Difficult-to-understand methods and tightly coupled logic for handling assignment-specific conditions, such as team-topic associations.
* Poor user feedback that does not provide clear or actionable information after critical operations.

These problems creates a system that is hard to scale, maintain, and extend, especially as new features are added. To address these challenges, the goal is to refactor the StudentTeamsController by adhering to object-oriented design principles, specifically focusing on maintainability, scalability, and modularity. The new design will improve the user experience by simplifying controller logic, providing clearer feedback, and ensuring that the system is easier to extend and maintain in the future.

===Objectives===

*Reimplement the controller logic and write methods which appropriately follow the Single Responsibility Principle (SRP).
*Move business logic from the controller to appropriate model classes like Team or AssignmentTeam.
*Ensure all method names clearly describe their purpose and represent actions.
*Reimplement a Prototype pattern for creating mentored teams, leveraging the AssignmentTeam class.
*Automatically generate team names when a team is first referred to unless the user has specified a name when requesting team creation.
*Handle team requirements with better abstraction:
*Try to eliminate direct logic in the controller that checks for specific assignment requirements such as topic handling.
*Rename student_team_requirements_met? to something more descriptive and break it into smaller methods checking individual conditions.
*Aim to decouple topics from this controller entirely, ensuring better abstraction, that can involve changes to other classes or introducing service objects to handle specific requirements.
* Improve feedback to users:
Ensure that the user receives clear and actionable feedback after operations like team creation, removal of users, and other key actions.
* Add comprehensive comments throughout the controller, clearly explaining the purpose and functionality of custom methods.

===Development Strategy===

Our development strategy centers around Test-Driven Development (TDD) principles applied to refactoring the student_teams_controller.rb and other related classes such as Team or AssignmentTeam model. We design out test cases and iteratively refactor code to address identified inefficiencies while ensuring successful test outcomes.
Additionally, we emphasize on the strict adoption of SRP and DRY principles as per the object-oriented programming conventions. Our goal is to reimplement the existing functionalities
In the newly designed back-end foundation to foster a more efficient and organized codebase utilizing newer technologies. This approach will significantly enhance reusability and scalability across all the application while maintaining clean codebase.

===Project Design and Implementation===

The main approach to be followed throughout this project is to embrace the Prototyping Pattern within the controller while taking into account the current functionalities to be reimplemented within the student_teams_controller.rb that can capitalize its capability to encapsulate distinct controller actions. This strategic implementation aims to ensure seamless extensibility and enhanced usability. By employing this pattern, we establish a structured framework for defining and managing the diverse operations the controller handles, promoting a more organized and manageable code structure.

==== Functionality ====

1. Reimplement the Controller to Follow SRP:
* Break down large, complex methods into smaller, focused methods that adhere to the Single Responsibility Principle (SRP).
* Reimplement existing methods and logic while ensuring that each class and method have a clear, well-defined responsibility.
* Move business logic and complex operations out of the controller and into the appropriate model classes (e.g., Team, AssignmentTeam), ensuring the controller only handles
HTTP-specific concerns (e.g., request handling, responses).

2. Improve Method Naming and Clarity:
* Ensure all method names are descriptive and represent the intent of the operation (e.g., renaming methods like student_team_requirements_met? to something more specific
like validate_topic_requirements_for_team_creation).
* Adopt consistent naming conventions to improve the readability of the codebase.

3. Implement the Prototype Pattern for Team Creation:
* Leverage the Prototype pattern to create mentored teams through the AssignmentTeam class, allowing for easier management and creation of teams with a mentored structure.
* Automatically generate team names when a team is first created, unless a user has specified a custom name to improve the user experience and simplify team management.

4. Abstract Assignment-Specific Logic:
* Move logic related to assignment-specific requirements (e.g., topic handling) away from the controller, reducing complexity and increasing modularity.
* Introduce service objects or model methods to handle specific requirements like topic assignment, thereby decoupling assignment-related logic from the controller.
* Break down the student_team_requirements_met? method into smaller, more specific checks for different requirements (e.g., topic validation, minimum team size, etc.).

5. Improve User Feedback:
* Enhance the clarity and actionability of feedback messages after key operations (e.g., team creation, user removal, etc.).
* Provide users with clear, helpful notifications on the success or failure of their actions, including any necessary next steps or troubleshooting guidance.
* Ensure error handling is robust, and feedback is specific (e.g., specify which conditions were not met when creating or modifying teams).

6. Commenting and Documentation:
* Add comprehensive comments throughout the controller to clearly explain the purpose and functionality of custom methods and refactored logic.
* Ensure that code is well-documented, making it easier for future developers to understand and extend the functionality of the controller.

===Testing Plan===

We plan to perform comprehensive testing of the student_teams_controller.rb and related classes using RSPEC and leverage FactoryBot to construct the required test fixtures for testing extensive scenarios. Our approach involves reimplementing the existing test cases provided to the older code base and make sure that it is enhanced by covering more test scenarios to minimize code smells. We aim to verify the reimplemented functionality, validate the restructured code in the student_teams_controller.rb and reduce any design or code smell.

===Mentor===

* Ammana, Sahithi <sammana@ncsu.edu>

===Team Members===

* Eathamukkala, Akarsh Reddy <aeatham@ncsu.edu>
* Koul, Anmol <akoul2@ncsu.edu>
* More, Harsh Manoj <hmore@ncsu.edu>

CSC/ECE 517 Fall 2024 - E2476. Reimplement student teams controller.rb

2024-11-12T06:34:17Z

Akoul2: /* Development Strategy */

===Project Description===

The project mainly focusses on reimplementing StudentTeamsController that is designed for student-facing operations where students are participants in teams. This includes actions that directly affect individual team members, such as adding or removing students from teams, viewing team details, and managing their participation.
TeamsController is focused on instructor-driven operations that deal with the high-level management of teams across different contexts like courses and assignments. It handles operations such as team creation, deletion, randomization, and bulk management actions.

===Problem Statement===

The problem statement provides the notion of reimplementing the StudentTeamsController to redesigning the new back-end code for Expertiza. The aim is to improve the code quality by adhering to object-oriented design principles and improving maintainability and scalability. The main focus is to eliminate code redundancy, ensure efficient handling of edge cases, and restructure methods so that they are placed appropriately in the respective classes.
The StudentTeamsController manages teams in student assignments, allowing users to create, edit, and manage teams for assignments. It also handles the integration with topics when assignments involve choosing topics, complicating the team’s logic. The design of this logic should prioritize interactions that are user-facing, easy to understand and maintainable. By reimplementing this controller, the project aims to streamline its functionality and improving the code's overall efficiency and modularity.

===Objectives===

*Reimplement the controller logic and write methods which appropriately follow the Single Responsibility Principle (SRP).
*Move business logic from the controller to appropriate model classes like Team or AssignmentTeam.
*Ensure all method names clearly describe their purpose and represent actions.
*Reimplement a Prototype pattern for creating mentored teams, leveraging the AssignmentTeam class.
*Automatically generate team names when a team is first referred to unless the user has specified a name when requesting team creation.
*Handle team requirements with better abstraction:
*Try to eliminate direct logic in the controller that checks for specific assignment requirements such as topic handling.
*Rename student_team_requirements_met? to something more descriptive and break it into smaller methods checking individual conditions.
*Aim to decouple topics from this controller entirely, ensuring better abstraction, that can involve changes to other classes or introducing service objects to handle specific requirements.
* Improve feedback to users:
Ensure that the user receives clear and actionable feedback after operations like team creation, removal of users, and other key actions.
* Add comprehensive comments throughout the controller, clearly explaining the purpose and functionality of custom methods.

===Development Strategy===

Our development strategy centers around Test-Driven Development (TDD) principles applied to refactoring the student_teams_controller.rb and other related classes such as Team or AssignmentTeam model. We design out test cases and iteratively refactor code to address identified inefficiencies while ensuring successful test outcomes.
Additionally, we emphasize on the strict adoption of SRP and DRY principles as per the object-oriented programming conventions. Our goal is to reimplement the existing functionalities
In the newly designed back-end foundation to foster a more efficient and organized codebase utilizing newer technologies. This approach will significantly enhance reusability and scalability across all the application while maintaining clean codebase.

===Project Design and Implementation===

The main approach to be followed throughout this project is to embrace the Prototyping Pattern within the controller while taking into account the current functionalities to be reimplemented within the student_teams_controller.rb that can capitalize its capability to encapsulate distinct controller actions. This strategic implementation aims to ensure seamless extensibility and enhanced usability. By employing this pattern, we establish a structured framework for defining and managing the diverse operations the controller handles, promoting a more organized and manageable code structure.

==== Functionality ====

*Reimplement the controller logic and write methods which appropriately follow the Single Responsibility Principle (SRP).
*Move business logic from the controller to appropriate model classes like Team or AssignmentTeam.
*Ensure all method names clearly describe their purpose and represent actions.
*Reimplement a Prototype pattern for creating mentored teams, leveraging the AssignmentTeam class.
*Automatically generate team names when a team is first referred to unless the user has specified a name when requesting team creation.
*Handle team requirements with better abstraction:
*Try to eliminate direct logic in the controller that checks for specific assignment requirements such as topic handling.
*Rename student_team_requirements_met? to something more descriptive and break it into smaller methods checking individual conditions.
*Aim to decouple topics from this controller entirely, ensuring better abstraction, that can involve changes to other classes or introducing service objects to handle specific requirements.
* Improve feedback to users:
Ensure that the user receives clear and actionable feedback after operations like team creation, removal of users, and other key actions.
* Add comprehensive comments throughout the controller, clearly explaining the purpose and functionality of custom methods.

===Testing Plan===

We plan to perform comprehensive testing of the student_teams_controller.rb and related classes using RSPEC and leverage FactoryBot to construct the required test fixtures for testing extensive scenarios. Our approach involves reimplementing the existing test cases provided to the older code base and make sure that it is enhanced by covering more test scenarios to minimize code smells. We aim to verify the reimplemented functionality, validate the restructured code in the student_teams_controller.rb and reduce any design or code smell.

===Mentor===

* Ammana, Sahithi <sammana@ncsu.edu>

===Team Members===

* Eathamukkala, Akarsh Reddy <aeatham@ncsu.edu>
* Koul, Anmol <akoul2@ncsu.edu>
* More, Harsh <hmore@ncsu.edu>

CSC/ECE 517 Fall 2024 - E2476. Reimplement student teams controller.rb

2024-11-12T06:34:04Z

Akoul2: First draft

===Project Description===

The project mainly focusses on reimplementing StudentTeamsController that is designed for student-facing operations where students are participants in teams. This includes actions that directly affect individual team members, such as adding or removing students from teams, viewing team details, and managing their participation.
TeamsController is focused on instructor-driven operations that deal with the high-level management of teams across different contexts like courses and assignments. It handles operations such as team creation, deletion, randomization, and bulk management actions.

===Problem Statement===

The problem statement provides the notion of reimplementing the StudentTeamsController to redesigning the new back-end code for Expertiza. The aim is to improve the code quality by adhering to object-oriented design principles and improving maintainability and scalability. The main focus is to eliminate code redundancy, ensure efficient handling of edge cases, and restructure methods so that they are placed appropriately in the respective classes.
The StudentTeamsController manages teams in student assignments, allowing users to create, edit, and manage teams for assignments. It also handles the integration with topics when assignments involve choosing topics, complicating the team’s logic. The design of this logic should prioritize interactions that are user-facing, easy to understand and maintainable. By reimplementing this controller, the project aims to streamline its functionality and improving the code's overall efficiency and modularity.

===Objectives===

*Reimplement the controller logic and write methods which appropriately follow the Single Responsibility Principle (SRP).
*Move business logic from the controller to appropriate model classes like Team or AssignmentTeam.
*Ensure all method names clearly describe their purpose and represent actions.
*Reimplement a Prototype pattern for creating mentored teams, leveraging the AssignmentTeam class.
*Automatically generate team names when a team is first referred to unless the user has specified a name when requesting team creation.
*Handle team requirements with better abstraction:
*Try to eliminate direct logic in the controller that checks for specific assignment requirements such as topic handling.
*Rename student_team_requirements_met? to something more descriptive and break it into smaller methods checking individual conditions.
*Aim to decouple topics from this controller entirely, ensuring better abstraction, that can involve changes to other classes or introducing service objects to handle specific requirements.
* Improve feedback to users:
Ensure that the user receives clear and actionable feedback after operations like team creation, removal of users, and other key actions.
* Add comprehensive comments throughout the controller, clearly explaining the purpose and functionality of custom methods.

===Development Strategy===

Our development strategy centers around Test-Driven Development (TDD) principles applied to refactoring the student_teams_controller.rb and other related classes such as Team or AssignmentTeam model. We design out test cases and iteratively refactor code to address identified inefficiencies while ensuring successful test outcomes.
Additionally, we emphasize on the strict adoption of SRP and DRY principles as per the object-oriented programming conventions. Our goal is to reimplement the existing functionalities
in the newly designed back-end foundation to foster a more efficient and organized codebase utilizing newer technologies. This approach will significantly enhance reusability and scalability across all the application while maintaining clean codebase.

===Project Design and Implementation===

The main approach to be followed throughout this project is to embrace the Prototyping Pattern within the controller while taking into account the current functionalities to be reimplemented within the student_teams_controller.rb that can capitalize its capability to encapsulate distinct controller actions. This strategic implementation aims to ensure seamless extensibility and enhanced usability. By employing this pattern, we establish a structured framework for defining and managing the diverse operations the controller handles, promoting a more organized and manageable code structure.

==== Functionality ====

*Reimplement the controller logic and write methods which appropriately follow the Single Responsibility Principle (SRP).
*Move business logic from the controller to appropriate model classes like Team or AssignmentTeam.
*Ensure all method names clearly describe their purpose and represent actions.
*Reimplement a Prototype pattern for creating mentored teams, leveraging the AssignmentTeam class.
*Automatically generate team names when a team is first referred to unless the user has specified a name when requesting team creation.
*Handle team requirements with better abstraction:
*Try to eliminate direct logic in the controller that checks for specific assignment requirements such as topic handling.
*Rename student_team_requirements_met? to something more descriptive and break it into smaller methods checking individual conditions.
*Aim to decouple topics from this controller entirely, ensuring better abstraction, that can involve changes to other classes or introducing service objects to handle specific requirements.
* Improve feedback to users:
Ensure that the user receives clear and actionable feedback after operations like team creation, removal of users, and other key actions.
* Add comprehensive comments throughout the controller, clearly explaining the purpose and functionality of custom methods.

===Testing Plan===

We plan to perform comprehensive testing of the student_teams_controller.rb and related classes using RSPEC and leverage FactoryBot to construct the required test fixtures for testing extensive scenarios. Our approach involves reimplementing the existing test cases provided to the older code base and make sure that it is enhanced by covering more test scenarios to minimize code smells. We aim to verify the reimplemented functionality, validate the restructured code in the student_teams_controller.rb and reduce any design or code smell.

===Mentor===

* Ammana, Sahithi <sammana@ncsu.edu>

===Team Members===

* Eathamukkala, Akarsh Reddy <aeatham@ncsu.edu>
* Koul, Anmol <akoul2@ncsu.edu>
* More, Harsh <hmore@ncsu.edu>

CSC/ECE 517 Fall 2024

2024-11-12T05:55:17Z

Akoul2: adding E.2476

* [[CSC/ECE 517 Fall 2024 - E2450. Refactor assignments_controller.rb]]
* [[CSC/ECE 517 Fall 2024 - E2451. Reimplement feedback_response_map.rb]]
* [[CSC/ECE 517 Fall 2024 - E2452. Refactor review_mapping_controller.rb]]
* [[CSC/ECE 517 Fall 2024 - E2453. Refactor review_mapping_helper.rb]]
* [[CSC/ECE 517 Fall 2024 - E2454. Refactor student_task.rb]]
* [[CSC/ECE 517 Fall 2024 - E2455. Refactor sign_up_sheet_controller.rb]]
* [[CSC/ECE 517 Fall 2024 - E2456. Refactor teams_user.rb]]
* [[CSC/ECE 517 Fall 2024 - E2456. Refactor teams_user.rb (Phase 2 - Design Document)]]
* [[CSC/ECE 517 Fall 2024 - E2458. User management and users table]]
* [[CSC/ECE 517 Fall 2024 - E2459. View for results of bidding]]
* [[CSC/ECE 517 Fall 2024 - E2460 Mentor-Meeting Management]]
* [[CSC/ECE 517 Fall 2024 - E2461. UI for Courses]]
* [https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2024_-_E2462._UI_for_Questionnaires CSC/ECE 517 Fall 2024 - E2462. UI for Questionnaire.rb]
* [https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2024_-_E2463_Implement_Front_End_for_Student_Task_List CSC/ECE 517 Fall 2024 - E2463. UI for Student Task List]
* [[CSC/ECE 517 Fall 2024 - E2464 UI for Project Topics (was: Sign_up_Topics)]]
* [[CSC/ECE 517 Fall 2024 - E2465. UI for Institutions and Notification]]
* [[CSC/ECE 517 Fall 2024 - E2466. UI for Impersonate User]]
* [[CSC/ECE 517 Fall 2024 - E2467. UI for View Submissions]]
* [[CSC/ECE 517 Fall 2024 - E2468. Reimplement due_date]]
* [[CSC/ECE 517 Fall 2024 - E2469. Reimplement grades/view_team]]
* [[CSC/ECE 517 Fall 2024 - E2470. Reimplement grades_controller]]
* [[CSC/ECE 517 Fall 2024 - E2471. Reimplement logger]]
* [[CSC/ECE 517 Fall 2024 - E2472. Reimplement responses_controller.rb]]
* [[CSC/ECE 517 Fall 2024 - E2474. Reimplement student_quizzes_controller.rb]]
* [[CSC/ECE 517 Fall 2024 - E2475. Reimplement student_task view]]
* [[CSC/ECE 517 Fall 2024 - E2476. Reimplement student_teams_controller.rb]]
* [[CSC/ECE 517 Fall 2024 - E2478. Reimplement the Question hierarchy as Item hierarchy]]
* [[CSC/ECE 517 Fall 2024 - E2479. Reimplement teams_users_controller.rb]]
* [[CSC/ECE 517 Fall 2024 - E2480. Implement testing for new Bookmarks Controller]]
* [[CSC/ECE 517 Fall 2024 - E2481 Reimplement response_map.rb]]
* [[CSC/ECE 517 Fall 2024 - E2482. Reimplement heatgrid for reviews]]
* [[CSC/ECE 517 Fall 2024 - E2483. Reimplement Notification Controller and Model]]
* [[CSC/ECE 517 Fall 2024 - E2484. Reimplement participants_controller.rb]]
* [[CSC/ECE 517 Fall 2024 - E2485. Allow reviewers to bid on what to review]]
* [[CSC/ECE 517 Fall 2024 - E2487. Reimplement authorization_helper.rb]]
* [[CSC/ECE 517 Fall 2024 - E2492. UI for View submissions/assign grades (except heatgrid)]]
* [[CSC/ECE 517 Fall 2024 - E2493. UI for Assign Reviewers]]
* [[CSC/ECE 517 Fall 2024 - G2401 Refactor Graphql API endpoint for contribution metrics]]
* [[CSC/ECE 517 Fall 2024 - G2402 Refactor Graphql API endpoint for repositories]]

CSC/ECE 517 Fall 2024 - E2454. Refactor student task.rb

2024-10-30T03:59:23Z

Akoul2: /* Login Details */

==Expertiza==

Expertiza is a web application through which students can submit and peer-review learning objects (articles, code, web sites, etc).
The National Science Foundation supports the Expertiza project.
It is used in select courses at NC State and by professors at several other colleges and universities.

[http://expertiza.ncsu.edu/ Expertiza] is a [http://rubyonrails.org/ Ruby on Rails] based open source project.

==Problem Statement==

====Background====
This project focuses on refactoring the StudentTask class to improve the organization, functionality, and separation of concerns. Currently, the class contains a mix of utility and class methods, many of which are static and should be moved into helper modules or relevant model classes, or broken down into separate, more maintainable methods. The goal is to make the class more efficient and follow best practices in object-oriented programming.

The StudentTask model is a significant part of the Expertiza website which maintains and handles student data who are participants under an assignment. Each assignment has a team, individual user participant and submission deadlines. The motive here is to refactor static methods called in the student_task.rb file and move them to helper classes for better object-oriented code design.

==About StudentTask Model==
The StudentTask model handles the tracking and organizes of student assignments, encapsulating key information about a student’s current progress, deadlines, and associated tasks. It provides different functional methods for task creation, checking completion status, and timeline generation, ensuring a streamlined and detailed view of a student's assignment timelines. The model interacts closely with assignment participants and topics to display their task completion stages, reviews, and deadlines.

===Functionality===
The StudentTask model manages student assignments with the help of functional methods to initialize tasks, track deadlines, and task assessment. It includes class method from_participant, which creates a task based on a participant’s data, and from_user, that generates a sorted list of tasks by deadline for a particular user. Task status is determined through methods such as complete?, incomplete?, and started?. Additionally The revision? method checks for ongoing updates based on current stage and submissions. The model also incorporates methods (such as get_due_date_data, get_submission_data, etc.) that compile task events in chronological order, enabling a clear overview of assignment deadlines, submissions, and peer reviews. Through encapsulation, delegation, and adherence to SRP, StudentTask ensures efficient and modular task tracking aligned with the required educational processes.

==Functionality of StudentTaskHelper Module==
The StudentTaskHelper module facilitates efficient task management by handling operations such as timeline generation, teammate grouping, and task initialization for participants. It includes generate_timeline, which combines due date, peer review, and author feedback timelines, as well as create_student_task_for_participant to initialize tasks based on participant data. The module introduces iterator patterns through methods such as for_each_due_date_of_assignment, for_each_peer_review, and for_each_author_feedback, which yield data to enhance flexibility and modularity within the codebase.

Helper methods like group_teammates_by_course_for_user efficiently organize teammates by course, while methods like parse_due_date_to_timeline and parse_response_to_timeline encapsulate logic for structuring timeline events. Using private helper methods such as fetch_response_from, and utility functions like calibration_assignment? and valid_assignment_team?, StudentTaskHelper optimizes data handling, improves readability, and adheres to object-oriented design principles by reducing the need for static methods in the StudentTask model.

====Refactor====

The StudentTask model do not strictly follow the SRP and DRY principles and needed a lot of refactoring to make them more manageable in following Object-Oriented design and development.

Files modified:
* student_task.rb
* student_task_controller.rb
* student_task_helper.rb
* student_task_spec.rb
* assessment360_controller.rb
* assessment360_controller_spec.rb

New files added:
* student_task_helper_spec.rb

==Login Details==

* [http://152.7.177.54:8080/ Expertiza VCL Server]
* username = instructor6
* password = password

===Note===
Switch from instructor view to student view, you can find it at the top of website.

==Refactoring==

====self.from_participant(participant)====
Creates a StudentTask instance for a given participant, populating it with relevant assignment and stage data.

Before:

[[File:Akoul2 from participant before.jpg]]

After:

[[File:Akoul from participant after1.jpg]]

[[File:Akoul from participant after2.jpg]]

====self.from_participantid(id)====
It searches and fetches an active participant by its id.

Before:

[[File:Akoul2 from participant id before.jpg]]

After:

This method is depreciated during the refactoring process. It no longer served its purpose and was removed from the codebase.

====self.from_user(user)====
Retrieves tasks associated with a user by iterating over the user's assignment participants and sorting them by their stage deadlines.

Before:

[[File:Akoul2 from user before.jpg]]

After:

[[File:Akoul2 from user after.jpg]]

====self.get_author_feedback_data(participant_id, timeline_list)====
Generates a timeline of author feedback for a participant by mapping each feedback response through a parsing function.

Before:

[[File:Akoul2 get author feedback data before.jpg]]

After:

[[File:Akoul2 get author feedback data after.jpg]]

====self.get_due_date_data(assignment, timeline_list)====
Generates a timeline of due dates for an assignment by mapping each due date through a parsing function.

Before:

[[File:Akoul2 get due date data before.jpg]]

After:

[[File:Akoul2 get due date after.jpg]]

====self.peer_review_data(participant_id, timeline_list)====
Iterates through each peer review for a participant, yielding each review to a provided block.

Before:

[[File:Akoul2 peer review data before.jpg]]

After:

[[File:Akoul2 get peer review data after.jpg]]

====self.get_submission_data(participant_id, team_id, timeline_list)====

Before:

[[File:Akoul2 get submission data before.jpg]]

After:

This method, similar to from_participantid(), didn't showcase its usefulness during the refactoring process and was removed from the codebase.

====self.get_timeline_data(assignment, participant, _team)====
Generates a timeline of events related to the assignment for the participant, including due dates, peer reviews, and author feedback, sorted by update time.

Before:

[[File:Akoul2 get timeline data before.jpg]]

After:

[[File:Akoul2 get timeline data after.jpg]]

====self.teamed_student(user, ip_address=nil)====
Groups teammates by course for a user and returns a hash where keys are course IDs and values are lists of teammate names.

Before:

[[File:Akoul2 teamed student before.jpg]]

After:

[[File:Akoul2 teamed student after.jpg]]

Additional methods added:

[[File:Akoul2 additional methods.jpg]]

==Test Cases for StudentTask Model, Controller and helper classes==

====Descriptive test cases====

* '''Accessing the Assignments Page'''
- Objective: Verify that the assignments page is accessible and displays all available assignments.
- Steps: Navigate to the **Assignments** tab and confirm that it loads without errors, displaying the list of assignments.

* '''Selecting an Assignment'''
- Objective: Confirm that selecting an assignment redirects the user to the detailed view.
- Steps: From the **Assignments** page, click on any assignment and verify that you are redirected to the respective **StudentTask** page for that assignment.

* '''Viewing Assignment Details'''
- Objective: Ensure that the **StudentTask** page displays assignment details, such as course, topic, and current stage.
- Steps: On the **StudentTask** page, verify the presence of fields like course, topic, and current stage, ensuring accuracy in the information displayed.

* '''Navigating "Your Work" and "Others' Work" Links'''
- Objective: Test the links to "Your Work" and "Others' Work" sections to confirm they display relevant information.
- Steps: Click the **Your Work** link to confirm it shows the student's submissions; then click the **Others' Work** link to verify it shows other students’ work or available feedback options, as applicable.

* '''Checking Review Grade Information'''
- Objective: Verify that the review grade, if available, is displayed along with any awarded badges.
- Steps: Confirm the **Review Grade** section displays either a numeric grade or "N/A" if no grade is available, and ensure any badges appear with accurate images and tooltips.

* '''Assignment Timelines and Deadline Tasks'''
- Objective: Verify that each assignment timeline and associated deadlines are listed on the StudentTask page.
- Steps: Navigate to the **Assignment Timelines** section and confirm that each task is listed in order with relevant due dates.

* '''Checking and Sending Reviewer Emails'''
- Objective: Test the "Send Email to Reviewers" feature to ensure it functions as expected.
- Steps: On the **StudentTask** page, select the **Send Email to Reviewers** option and confirm the email interface opens, allowing the student to message reviewers.

* '''Revisions and Unstarted Tasks'''
- Objective: Verify that any revisions and unstarted tasks for the assignment are displayed accurately.
- Steps: Check for sections labeled **Revisions** and **Tasks Not Yet Started**, and confirm that each section lists the student’s pending tasks correctly.

* '''Viewing Teammates and Course Association'''
- Objective: Confirm that teammates and course association are accurately displayed for assignments.
- Steps: In the **Students Who Are Teamed with You** section, ensure teammates’ names and roles are displayed. Check that the assignment shows an association with a course name if applicable, or confirms if it is not associated with any course.

====New RSpec Test Cases====

1. To check each due date of assignment:

describe '#for_each_due_date_of_assignment' do
let(:due_date_modifier) do
lambda { |dd|
{ label: (dd.deadline_type.name + ' Deadline').humanize,
updated_at: dd.due_at.strftime('%a, %d %b %Y %H:%M') }
}
end
context 'when called with assignment having empty due dates' do
it 'return empty time_list array' do
timeline_list = []
student_task_helper.for_each_due_date_of_assignment(assignment) do |due_date|
timeline_list << due_date_modifier.call(due_date)
end
expect(timeline_list).to eq([])
end
end
context 'when called with assignment having due date' do
context 'and due_at value nil' do
it 'return empty time_list array' do
allow(due_date).to receive(:deadline_type).and_return(deadline_type)
timeline_list = []
due_date.due_at = nil
assignment.due_dates = [due_date]
student_task_helper.for_each_due_date_of_assignment(assignment) { |due_date| timeline_list << due_date_modifier.call(due_date) }
expect(timeline_list).to eq([])
end
end
context 'and due_at value not nil' do
it 'return time_list array' do
allow(due_date).to receive(:deadline_type).and_return(deadline_type)
timeline_list = []
assignment.due_dates = [due_date]
student_task_helper.for_each_due_date_of_assignment(assignment) do |due_date|
timeline_list << due_date_modifier.call(due_date)
end
expect(timeline_list).to eq([{
label: (due_date.deadline_type.name + ' Deadline').humanize,
updated_at: due_date.due_at.strftime('%a, %d %b %Y %H:%M')
}])
end
end
end
end

2. To check for peer reviews

describe '#for_each_peer_review' do
context 'when no review response mapped' do
it 'returns empty' do
timeline_list = []
for_each_peer_review(user2) do |response|
timeline_list << response_modifier.call(response, "Round #{response.round} Peer Review".humanize)
end
expect(timeline_list).to eq([])
end
end
context 'when mapped to review response map' do
it 'returns timeline array' do
timeline_list = []
allow(ReviewResponseMap).to receive_message_chain(:where, :find_each).with(reviewer_id: 1).with(no_args).and_yield(review_response_map)
allow(review_response_map).to receive(:id).and_return(1)
allow(Response).to receive_message_chain(:where, :last).with(map_id: 1).with(no_args).and_return(response)
allow(response).to receive(:round).and_return(1)
allow(response).to receive(:updated_at).and_return(Time.new(2019))
timevalue = Time.new(2019).strftime('%a, %d %b %Y %H:%M')
for_each_peer_review(1) do |resp|
timeline_list << response_modifier.call(resp, "Round #{resp.round} Peer Review".humanize)
end
expect(timeline_list).to eq([{ id: 1, label: 'Round 1 peer review', updated_at: timevalue }])
end
end
end

3. To check and validate author feedbacks

describe '#for_each_author_feedback' do
context 'when no feedback response mapped' do
it 'returns empty' do
timeline_list = []
for_each_author_feedback(user2) do |response|
timeline_list << response_modifier.call(response, 'Author feedback')
end
expect(timeline_list).to eq([])
end
end
context 'when mapped to feedback response map' do
it 'returns timeline array' do
timeline_list = []
allow(FeedbackResponseMap).to receive_message_chain(:where, :find_each).with(reviewer_id: 1).with(no_args).and_yield(review_response_map)
allow(review_response_map).to receive(:id).and_return(1)
allow(Response).to receive_message_chain(:where, :last).with(map_id: 1).with(no_args).and_return(response)
allow(response).to receive(:updated_at).and_return(Time.now)
timevalue = Time.now.strftime('%a, %d %b %Y %H:%M')
timeline_list = []
for_each_author_feedback(1) do |response|
timeline_list << response_modifier.call(response, 'Author feedback')
end
expect(timeline_list).to eq([{ id: 1, label: 'Author feedback', updated_at: timevalue }])
end
end
end

4. To create and validate generated timelines

describe '#generate_timeline' do
context 'when no timeline data mapped' do
it 'returns nil' do
allow(participant).to receive(:get_reviewer).and_return(participant)
expect(student_task_helper.generate_timeline(assignment, participant)).to eq([])
end
end
end

5. Check if StudentTask obeject is created properly

describe '#create_student_task_for_participant' do
it 'creates a StudentTask with the correct attributes' do
student_task = student_task_helper.create_student_task_for_participant(participant3)
expect(student_task).to be_an_instance_of(StudentTask)
expect(student_task.participant).to eq(participant3)
expect(student_task.assignment).to eq(assignment)
expect(student_task.topic).to eq(topic)
expect(student_task.current_stage).to eq('submission')
expect(student_task.stage_deadline).to eq(Time.parse('2024-12-31 12:00:00'))
end
end

6. To check the retrieved tasks for users

describe '#retrieve_tasks_for_user' do
before do
allow(user).to receive_message_chain(:assignment_participants, :includes).and_return([participant4, participant5])
end

it 'retrieves and sorts tasks by stage_deadline' do
tasks = student_task_helper.retrieve_tasks_for_user(user)
expect(tasks.size).to eq(2)
expect(tasks.first.stage_deadline).to eq(Time.parse('2024-11-01 12:00:00'))
expect(tasks.last.stage_deadline).to eq(Time.parse('2024-12-01 12:00:00'))
end

it 'creates StudentTask objects for each participant' do
tasks = student_task_helper.retrieve_tasks_for_user(user)
tasks.each do |task|
expect(task).to be_an_instance_of(StudentTask)
expect(task.participant).to be_in([participant4, participant5])
expect(task.assignment).to eq(assignment)
expect(task.topic).to eq(topic)
end
end
end

7. To check if deadlines are parsed properly

describe '#parse_stage_deadline' do
context 'If a valid time value is given' do
it 'parse the provided time correctly' do
given_time = '2024-12-31 12:00:00'
parsed_time = student_task_helper.parse_stage_deadline(given_time)
expect(parsed_time).to eq(Time.parse(given_time))
end
end

context 'If given time string is invalid' do
it 'return current time plus 1 year' do
given_time = 'invalid-time-string'
overhead_time = Time.now + 1.year
parsed_time = student_task_helper.parse_stage_deadline(given_time)
expect(parsed_time).to be_within(1.second).of(overhead_time)
end
end
end

8. To check various conditions of users tagged as teammates

describe '#group_teammates_by_course_for_user' do
context 'when not in any team' do
it 'returns empty' do
expect(student_task_helper.group_teammates_by_course_for_user(user3)).to eq({})
end
end
context 'when assigned in a course_team ' do
it 'returns empty' do
allow(user).to receive(:teams).and_return([course_team])
expect(student_task_helper.group_teammates_by_course_for_user(user)).to eq({})
end
end
context 'when assigned in a assignment_team ' do
it 'returns the students they are teamed with' do
allow(user).to receive(:teams).and_return([team])
allow(AssignmentParticipant).to receive(:find_by).with(user_id: 1, parent_id: assignment.id).and_return(participant)
allow(AssignmentParticipant).to receive(:find_by).with(user_id: 5, parent_id: assignment.id).and_return(participant2)
allow(Assignment).to receive(:find_by).with(id: team.parent_id).and_return(assignment)
expect(student_task_helper.group_teammates_by_course_for_user(user)).to eq(assignment.course_id => [user2.fullname])
end
end
end

==Team==

====Mentor====

* Ammana, Sahithi <sammana@ncsu.edu>

====Members====

* Eathamukkala, Akarsh Reddy <aeatham@ncsu.edu>
* Koul, Anmol <akoul2@ncsu.edu>
* More, Harsh <hmore@ncsu.edu>

==References==

# [https://expertiza.ncsu.edu/ Expertiza]
# [https://docs.google.com/document/d/1fB9nHsop_yptjcj3CFn80BcZjXcSDbzcWwKvBDUTVrQ/edit?tab=t.0 OSS Projects on Expertiza]
# [https://github.com/expertiza/expertiza Github]
# [https://github.com/expertiza/expertiza/pull/2859 Pull Request]

CSC/ECE 517 Fall 2024 - E2454. Refactor student task.rb

2024-10-30T03:58:12Z

Akoul2: /* References */

==Expertiza==

Expertiza is a web application through which students can submit and peer-review learning objects (articles, code, web sites, etc).
The National Science Foundation supports the Expertiza project.
It is used in select courses at NC State and by professors at several other colleges and universities.

[http://expertiza.ncsu.edu/ Expertiza] is a [http://rubyonrails.org/ Ruby on Rails] based open source project.

==Problem Statement==

====Background====
This project focuses on refactoring the StudentTask class to improve the organization, functionality, and separation of concerns. Currently, the class contains a mix of utility and class methods, many of which are static and should be moved into helper modules or relevant model classes, or broken down into separate, more maintainable methods. The goal is to make the class more efficient and follow best practices in object-oriented programming.

The StudentTask model is a significant part of the Expertiza website which maintains and handles student data who are participants under an assignment. Each assignment has a team, individual user participant and submission deadlines. The motive here is to refactor static methods called in the student_task.rb file and move them to helper classes for better object-oriented code design.

==About StudentTask Model==
The StudentTask model handles the tracking and organizes of student assignments, encapsulating key information about a student’s current progress, deadlines, and associated tasks. It provides different functional methods for task creation, checking completion status, and timeline generation, ensuring a streamlined and detailed view of a student's assignment timelines. The model interacts closely with assignment participants and topics to display their task completion stages, reviews, and deadlines.

===Functionality===
The StudentTask model manages student assignments with the help of functional methods to initialize tasks, track deadlines, and task assessment. It includes class method from_participant, which creates a task based on a participant’s data, and from_user, that generates a sorted list of tasks by deadline for a particular user. Task status is determined through methods such as complete?, incomplete?, and started?. Additionally The revision? method checks for ongoing updates based on current stage and submissions. The model also incorporates methods (such as get_due_date_data, get_submission_data, etc.) that compile task events in chronological order, enabling a clear overview of assignment deadlines, submissions, and peer reviews. Through encapsulation, delegation, and adherence to SRP, StudentTask ensures efficient and modular task tracking aligned with the required educational processes.

==Functionality of StudentTaskHelper Module==
The StudentTaskHelper module facilitates efficient task management by handling operations such as timeline generation, teammate grouping, and task initialization for participants. It includes generate_timeline, which combines due date, peer review, and author feedback timelines, as well as create_student_task_for_participant to initialize tasks based on participant data. The module introduces iterator patterns through methods such as for_each_due_date_of_assignment, for_each_peer_review, and for_each_author_feedback, which yield data to enhance flexibility and modularity within the codebase.

Helper methods like group_teammates_by_course_for_user efficiently organize teammates by course, while methods like parse_due_date_to_timeline and parse_response_to_timeline encapsulate logic for structuring timeline events. Using private helper methods such as fetch_response_from, and utility functions like calibration_assignment? and valid_assignment_team?, StudentTaskHelper optimizes data handling, improves readability, and adheres to object-oriented design principles by reducing the need for static methods in the StudentTask model.

====Refactor====

The StudentTask model do not strictly follow the SRP and DRY principles and needed a lot of refactoring to make them more manageable in following Object-Oriented design and development.

Files modified:
* student_task.rb
* student_task_controller.rb
* student_task_helper.rb
* student_task_spec.rb
* assessment360_controller.rb
* assessment360_controller_spec.rb

New files added:
* student_task_helper_spec.rb

==Login Details==

* [http://152.7.177.54:8080/ Expertiza VCL Server]
* username = instructor6
* password = password

==Refactoring==

====self.from_participant(participant)====
Creates a StudentTask instance for a given participant, populating it with relevant assignment and stage data.

Before:

[[File:Akoul2 from participant before.jpg]]

After:

[[File:Akoul from participant after1.jpg]]

[[File:Akoul from participant after2.jpg]]

====self.from_participantid(id)====
It searches and fetches an active participant by its id.

Before:

[[File:Akoul2 from participant id before.jpg]]

After:

This method is depreciated during the refactoring process. It no longer served its purpose and was removed from the codebase.

====self.from_user(user)====
Retrieves tasks associated with a user by iterating over the user's assignment participants and sorting them by their stage deadlines.

Before:

[[File:Akoul2 from user before.jpg]]

After:

[[File:Akoul2 from user after.jpg]]

====self.get_author_feedback_data(participant_id, timeline_list)====
Generates a timeline of author feedback for a participant by mapping each feedback response through a parsing function.

Before:

[[File:Akoul2 get author feedback data before.jpg]]

After:

[[File:Akoul2 get author feedback data after.jpg]]

====self.get_due_date_data(assignment, timeline_list)====
Generates a timeline of due dates for an assignment by mapping each due date through a parsing function.

Before:

[[File:Akoul2 get due date data before.jpg]]

After:

[[File:Akoul2 get due date after.jpg]]

====self.peer_review_data(participant_id, timeline_list)====
Iterates through each peer review for a participant, yielding each review to a provided block.

Before:

[[File:Akoul2 peer review data before.jpg]]

After:

[[File:Akoul2 get peer review data after.jpg]]

====self.get_submission_data(participant_id, team_id, timeline_list)====

Before:

[[File:Akoul2 get submission data before.jpg]]

After:

This method, similar to from_participantid(), didn't showcase its usefulness during the refactoring process and was removed from the codebase.

====self.get_timeline_data(assignment, participant, _team)====
Generates a timeline of events related to the assignment for the participant, including due dates, peer reviews, and author feedback, sorted by update time.

Before:

[[File:Akoul2 get timeline data before.jpg]]

After:

[[File:Akoul2 get timeline data after.jpg]]

====self.teamed_student(user, ip_address=nil)====
Groups teammates by course for a user and returns a hash where keys are course IDs and values are lists of teammate names.

Before:

[[File:Akoul2 teamed student before.jpg]]

After:

[[File:Akoul2 teamed student after.jpg]]

Additional methods added:

[[File:Akoul2 additional methods.jpg]]

==Test Cases for StudentTask Model, Controller and helper classes==

====Descriptive test cases====

* '''Accessing the Assignments Page'''
- Objective: Verify that the assignments page is accessible and displays all available assignments.
- Steps: Navigate to the **Assignments** tab and confirm that it loads without errors, displaying the list of assignments.

* '''Selecting an Assignment'''
- Objective: Confirm that selecting an assignment redirects the user to the detailed view.
- Steps: From the **Assignments** page, click on any assignment and verify that you are redirected to the respective **StudentTask** page for that assignment.

* '''Viewing Assignment Details'''
- Objective: Ensure that the **StudentTask** page displays assignment details, such as course, topic, and current stage.
- Steps: On the **StudentTask** page, verify the presence of fields like course, topic, and current stage, ensuring accuracy in the information displayed.

* '''Navigating "Your Work" and "Others' Work" Links'''
- Objective: Test the links to "Your Work" and "Others' Work" sections to confirm they display relevant information.
- Steps: Click the **Your Work** link to confirm it shows the student's submissions; then click the **Others' Work** link to verify it shows other students’ work or available feedback options, as applicable.

* '''Checking Review Grade Information'''
- Objective: Verify that the review grade, if available, is displayed along with any awarded badges.
- Steps: Confirm the **Review Grade** section displays either a numeric grade or "N/A" if no grade is available, and ensure any badges appear with accurate images and tooltips.

* '''Assignment Timelines and Deadline Tasks'''
- Objective: Verify that each assignment timeline and associated deadlines are listed on the StudentTask page.
- Steps: Navigate to the **Assignment Timelines** section and confirm that each task is listed in order with relevant due dates.

* '''Checking and Sending Reviewer Emails'''
- Objective: Test the "Send Email to Reviewers" feature to ensure it functions as expected.
- Steps: On the **StudentTask** page, select the **Send Email to Reviewers** option and confirm the email interface opens, allowing the student to message reviewers.

* '''Revisions and Unstarted Tasks'''
- Objective: Verify that any revisions and unstarted tasks for the assignment are displayed accurately.
- Steps: Check for sections labeled **Revisions** and **Tasks Not Yet Started**, and confirm that each section lists the student’s pending tasks correctly.

* '''Viewing Teammates and Course Association'''
- Objective: Confirm that teammates and course association are accurately displayed for assignments.
- Steps: In the **Students Who Are Teamed with You** section, ensure teammates’ names and roles are displayed. Check that the assignment shows an association with a course name if applicable, or confirms if it is not associated with any course.

====New RSpec Test Cases====

1. To check each due date of assignment:

describe '#for_each_due_date_of_assignment' do
let(:due_date_modifier) do
lambda { |dd|
{ label: (dd.deadline_type.name + ' Deadline').humanize,
updated_at: dd.due_at.strftime('%a, %d %b %Y %H:%M') }
}
end
context 'when called with assignment having empty due dates' do
it 'return empty time_list array' do
timeline_list = []
student_task_helper.for_each_due_date_of_assignment(assignment) do |due_date|
timeline_list << due_date_modifier.call(due_date)
end
expect(timeline_list).to eq([])
end
end
context 'when called with assignment having due date' do
context 'and due_at value nil' do
it 'return empty time_list array' do
allow(due_date).to receive(:deadline_type).and_return(deadline_type)
timeline_list = []
due_date.due_at = nil
assignment.due_dates = [due_date]
student_task_helper.for_each_due_date_of_assignment(assignment) { |due_date| timeline_list << due_date_modifier.call(due_date) }
expect(timeline_list).to eq([])
end
end
context 'and due_at value not nil' do
it 'return time_list array' do
allow(due_date).to receive(:deadline_type).and_return(deadline_type)
timeline_list = []
assignment.due_dates = [due_date]
student_task_helper.for_each_due_date_of_assignment(assignment) do |due_date|
timeline_list << due_date_modifier.call(due_date)
end
expect(timeline_list).to eq([{
label: (due_date.deadline_type.name + ' Deadline').humanize,
updated_at: due_date.due_at.strftime('%a, %d %b %Y %H:%M')
}])
end
end
end
end

2. To check for peer reviews

describe '#for_each_peer_review' do
context 'when no review response mapped' do
it 'returns empty' do
timeline_list = []
for_each_peer_review(user2) do |response|
timeline_list << response_modifier.call(response, "Round #{response.round} Peer Review".humanize)
end
expect(timeline_list).to eq([])
end
end
context 'when mapped to review response map' do
it 'returns timeline array' do
timeline_list = []
allow(ReviewResponseMap).to receive_message_chain(:where, :find_each).with(reviewer_id: 1).with(no_args).and_yield(review_response_map)
allow(review_response_map).to receive(:id).and_return(1)
allow(Response).to receive_message_chain(:where, :last).with(map_id: 1).with(no_args).and_return(response)
allow(response).to receive(:round).and_return(1)
allow(response).to receive(:updated_at).and_return(Time.new(2019))
timevalue = Time.new(2019).strftime('%a, %d %b %Y %H:%M')
for_each_peer_review(1) do |resp|
timeline_list << response_modifier.call(resp, "Round #{resp.round} Peer Review".humanize)
end
expect(timeline_list).to eq([{ id: 1, label: 'Round 1 peer review', updated_at: timevalue }])
end
end
end

3. To check and validate author feedbacks

describe '#for_each_author_feedback' do
context 'when no feedback response mapped' do
it 'returns empty' do
timeline_list = []
for_each_author_feedback(user2) do |response|
timeline_list << response_modifier.call(response, 'Author feedback')
end
expect(timeline_list).to eq([])
end
end
context 'when mapped to feedback response map' do
it 'returns timeline array' do
timeline_list = []
allow(FeedbackResponseMap).to receive_message_chain(:where, :find_each).with(reviewer_id: 1).with(no_args).and_yield(review_response_map)
allow(review_response_map).to receive(:id).and_return(1)
allow(Response).to receive_message_chain(:where, :last).with(map_id: 1).with(no_args).and_return(response)
allow(response).to receive(:updated_at).and_return(Time.now)
timevalue = Time.now.strftime('%a, %d %b %Y %H:%M')
timeline_list = []
for_each_author_feedback(1) do |response|
timeline_list << response_modifier.call(response, 'Author feedback')
end
expect(timeline_list).to eq([{ id: 1, label: 'Author feedback', updated_at: timevalue }])
end
end
end

4. To create and validate generated timelines

describe '#generate_timeline' do
context 'when no timeline data mapped' do
it 'returns nil' do
allow(participant).to receive(:get_reviewer).and_return(participant)
expect(student_task_helper.generate_timeline(assignment, participant)).to eq([])
end
end
end

5. Check if StudentTask obeject is created properly

describe '#create_student_task_for_participant' do
it 'creates a StudentTask with the correct attributes' do
student_task = student_task_helper.create_student_task_for_participant(participant3)
expect(student_task).to be_an_instance_of(StudentTask)
expect(student_task.participant).to eq(participant3)
expect(student_task.assignment).to eq(assignment)
expect(student_task.topic).to eq(topic)
expect(student_task.current_stage).to eq('submission')
expect(student_task.stage_deadline).to eq(Time.parse('2024-12-31 12:00:00'))
end
end

6. To check the retrieved tasks for users

describe '#retrieve_tasks_for_user' do
before do
allow(user).to receive_message_chain(:assignment_participants, :includes).and_return([participant4, participant5])
end

it 'retrieves and sorts tasks by stage_deadline' do
tasks = student_task_helper.retrieve_tasks_for_user(user)
expect(tasks.size).to eq(2)
expect(tasks.first.stage_deadline).to eq(Time.parse('2024-11-01 12:00:00'))
expect(tasks.last.stage_deadline).to eq(Time.parse('2024-12-01 12:00:00'))
end

it 'creates StudentTask objects for each participant' do
tasks = student_task_helper.retrieve_tasks_for_user(user)
tasks.each do |task|
expect(task).to be_an_instance_of(StudentTask)
expect(task.participant).to be_in([participant4, participant5])
expect(task.assignment).to eq(assignment)
expect(task.topic).to eq(topic)
end
end
end

7. To check if deadlines are parsed properly

describe '#parse_stage_deadline' do
context 'If a valid time value is given' do
it 'parse the provided time correctly' do
given_time = '2024-12-31 12:00:00'
parsed_time = student_task_helper.parse_stage_deadline(given_time)
expect(parsed_time).to eq(Time.parse(given_time))
end
end

context 'If given time string is invalid' do
it 'return current time plus 1 year' do
given_time = 'invalid-time-string'
overhead_time = Time.now + 1.year
parsed_time = student_task_helper.parse_stage_deadline(given_time)
expect(parsed_time).to be_within(1.second).of(overhead_time)
end
end
end

8. To check various conditions of users tagged as teammates

describe '#group_teammates_by_course_for_user' do
context 'when not in any team' do
it 'returns empty' do
expect(student_task_helper.group_teammates_by_course_for_user(user3)).to eq({})
end
end
context 'when assigned in a course_team ' do
it 'returns empty' do
allow(user).to receive(:teams).and_return([course_team])
expect(student_task_helper.group_teammates_by_course_for_user(user)).to eq({})
end
end
context 'when assigned in a assignment_team ' do
it 'returns the students they are teamed with' do
allow(user).to receive(:teams).and_return([team])
allow(AssignmentParticipant).to receive(:find_by).with(user_id: 1, parent_id: assignment.id).and_return(participant)
allow(AssignmentParticipant).to receive(:find_by).with(user_id: 5, parent_id: assignment.id).and_return(participant2)
allow(Assignment).to receive(:find_by).with(id: team.parent_id).and_return(assignment)
expect(student_task_helper.group_teammates_by_course_for_user(user)).to eq(assignment.course_id => [user2.fullname])
end
end
end

==Team==

====Mentor====

* Ammana, Sahithi <sammana@ncsu.edu>

====Members====

* Eathamukkala, Akarsh Reddy <aeatham@ncsu.edu>
* Koul, Anmol <akoul2@ncsu.edu>
* More, Harsh <hmore@ncsu.edu>

==References==

# [https://expertiza.ncsu.edu/ Expertiza]
# [https://docs.google.com/document/d/1fB9nHsop_yptjcj3CFn80BcZjXcSDbzcWwKvBDUTVrQ/edit?tab=t.0 OSS Projects on Expertiza]
# [https://github.com/expertiza/expertiza Github]
# [https://github.com/expertiza/expertiza/pull/2859 Pull Request]

CSC/ECE 517 Fall 2024 - E2454. Refactor student task.rb

2024-10-30T03:57:55Z

Akoul2: /* Login Details */

==Expertiza==

Expertiza is a web application through which students can submit and peer-review learning objects (articles, code, web sites, etc).
The National Science Foundation supports the Expertiza project.
It is used in select courses at NC State and by professors at several other colleges and universities.

[http://expertiza.ncsu.edu/ Expertiza] is a [http://rubyonrails.org/ Ruby on Rails] based open source project.

==Problem Statement==

====Background====
This project focuses on refactoring the StudentTask class to improve the organization, functionality, and separation of concerns. Currently, the class contains a mix of utility and class methods, many of which are static and should be moved into helper modules or relevant model classes, or broken down into separate, more maintainable methods. The goal is to make the class more efficient and follow best practices in object-oriented programming.

The StudentTask model is a significant part of the Expertiza website which maintains and handles student data who are participants under an assignment. Each assignment has a team, individual user participant and submission deadlines. The motive here is to refactor static methods called in the student_task.rb file and move them to helper classes for better object-oriented code design.

==About StudentTask Model==
The StudentTask model handles the tracking and organizes of student assignments, encapsulating key information about a student’s current progress, deadlines, and associated tasks. It provides different functional methods for task creation, checking completion status, and timeline generation, ensuring a streamlined and detailed view of a student's assignment timelines. The model interacts closely with assignment participants and topics to display their task completion stages, reviews, and deadlines.

===Functionality===
The StudentTask model manages student assignments with the help of functional methods to initialize tasks, track deadlines, and task assessment. It includes class method from_participant, which creates a task based on a participant’s data, and from_user, that generates a sorted list of tasks by deadline for a particular user. Task status is determined through methods such as complete?, incomplete?, and started?. Additionally The revision? method checks for ongoing updates based on current stage and submissions. The model also incorporates methods (such as get_due_date_data, get_submission_data, etc.) that compile task events in chronological order, enabling a clear overview of assignment deadlines, submissions, and peer reviews. Through encapsulation, delegation, and adherence to SRP, StudentTask ensures efficient and modular task tracking aligned with the required educational processes.

==Functionality of StudentTaskHelper Module==
The StudentTaskHelper module facilitates efficient task management by handling operations such as timeline generation, teammate grouping, and task initialization for participants. It includes generate_timeline, which combines due date, peer review, and author feedback timelines, as well as create_student_task_for_participant to initialize tasks based on participant data. The module introduces iterator patterns through methods such as for_each_due_date_of_assignment, for_each_peer_review, and for_each_author_feedback, which yield data to enhance flexibility and modularity within the codebase.

Helper methods like group_teammates_by_course_for_user efficiently organize teammates by course, while methods like parse_due_date_to_timeline and parse_response_to_timeline encapsulate logic for structuring timeline events. Using private helper methods such as fetch_response_from, and utility functions like calibration_assignment? and valid_assignment_team?, StudentTaskHelper optimizes data handling, improves readability, and adheres to object-oriented design principles by reducing the need for static methods in the StudentTask model.

====Refactor====

The StudentTask model do not strictly follow the SRP and DRY principles and needed a lot of refactoring to make them more manageable in following Object-Oriented design and development.

Files modified:
* student_task.rb
* student_task_controller.rb
* student_task_helper.rb
* student_task_spec.rb
* assessment360_controller.rb
* assessment360_controller_spec.rb

New files added:
* student_task_helper_spec.rb

==Login Details==

* [http://152.7.177.54:8080/ Expertiza VCL Server]
* username = instructor6
* password = password

==Refactoring==

====self.from_participant(participant)====
Creates a StudentTask instance for a given participant, populating it with relevant assignment and stage data.

Before:

[[File:Akoul2 from participant before.jpg]]

After:

[[File:Akoul from participant after1.jpg]]

[[File:Akoul from participant after2.jpg]]

====self.from_participantid(id)====
It searches and fetches an active participant by its id.

Before:

[[File:Akoul2 from participant id before.jpg]]

After:

This method is depreciated during the refactoring process. It no longer served its purpose and was removed from the codebase.

====self.from_user(user)====
Retrieves tasks associated with a user by iterating over the user's assignment participants and sorting them by their stage deadlines.

Before:

[[File:Akoul2 from user before.jpg]]

After:

[[File:Akoul2 from user after.jpg]]

====self.get_author_feedback_data(participant_id, timeline_list)====
Generates a timeline of author feedback for a participant by mapping each feedback response through a parsing function.

Before:

[[File:Akoul2 get author feedback data before.jpg]]

After:

[[File:Akoul2 get author feedback data after.jpg]]

====self.get_due_date_data(assignment, timeline_list)====
Generates a timeline of due dates for an assignment by mapping each due date through a parsing function.

Before:

[[File:Akoul2 get due date data before.jpg]]

After:

[[File:Akoul2 get due date after.jpg]]

====self.peer_review_data(participant_id, timeline_list)====
Iterates through each peer review for a participant, yielding each review to a provided block.

Before:

[[File:Akoul2 peer review data before.jpg]]

After:

[[File:Akoul2 get peer review data after.jpg]]

====self.get_submission_data(participant_id, team_id, timeline_list)====

Before:

[[File:Akoul2 get submission data before.jpg]]

After:

This method, similar to from_participantid(), didn't showcase its usefulness during the refactoring process and was removed from the codebase.

====self.get_timeline_data(assignment, participant, _team)====
Generates a timeline of events related to the assignment for the participant, including due dates, peer reviews, and author feedback, sorted by update time.

Before:

[[File:Akoul2 get timeline data before.jpg]]

After:

[[File:Akoul2 get timeline data after.jpg]]

====self.teamed_student(user, ip_address=nil)====
Groups teammates by course for a user and returns a hash where keys are course IDs and values are lists of teammate names.

Before:

[[File:Akoul2 teamed student before.jpg]]

After:

[[File:Akoul2 teamed student after.jpg]]

Additional methods added:

[[File:Akoul2 additional methods.jpg]]

==Test Cases for StudentTask Model, Controller and helper classes==

====Descriptive test cases====

* '''Accessing the Assignments Page'''
- Objective: Verify that the assignments page is accessible and displays all available assignments.
- Steps: Navigate to the **Assignments** tab and confirm that it loads without errors, displaying the list of assignments.

* '''Selecting an Assignment'''
- Objective: Confirm that selecting an assignment redirects the user to the detailed view.
- Steps: From the **Assignments** page, click on any assignment and verify that you are redirected to the respective **StudentTask** page for that assignment.

* '''Viewing Assignment Details'''
- Objective: Ensure that the **StudentTask** page displays assignment details, such as course, topic, and current stage.
- Steps: On the **StudentTask** page, verify the presence of fields like course, topic, and current stage, ensuring accuracy in the information displayed.

* '''Navigating "Your Work" and "Others' Work" Links'''
- Objective: Test the links to "Your Work" and "Others' Work" sections to confirm they display relevant information.
- Steps: Click the **Your Work** link to confirm it shows the student's submissions; then click the **Others' Work** link to verify it shows other students’ work or available feedback options, as applicable.

* '''Checking Review Grade Information'''
- Objective: Verify that the review grade, if available, is displayed along with any awarded badges.
- Steps: Confirm the **Review Grade** section displays either a numeric grade or "N/A" if no grade is available, and ensure any badges appear with accurate images and tooltips.

* '''Assignment Timelines and Deadline Tasks'''
- Objective: Verify that each assignment timeline and associated deadlines are listed on the StudentTask page.
- Steps: Navigate to the **Assignment Timelines** section and confirm that each task is listed in order with relevant due dates.

* '''Checking and Sending Reviewer Emails'''
- Objective: Test the "Send Email to Reviewers" feature to ensure it functions as expected.
- Steps: On the **StudentTask** page, select the **Send Email to Reviewers** option and confirm the email interface opens, allowing the student to message reviewers.

* '''Revisions and Unstarted Tasks'''
- Objective: Verify that any revisions and unstarted tasks for the assignment are displayed accurately.
- Steps: Check for sections labeled **Revisions** and **Tasks Not Yet Started**, and confirm that each section lists the student’s pending tasks correctly.

* '''Viewing Teammates and Course Association'''
- Objective: Confirm that teammates and course association are accurately displayed for assignments.
- Steps: In the **Students Who Are Teamed with You** section, ensure teammates’ names and roles are displayed. Check that the assignment shows an association with a course name if applicable, or confirms if it is not associated with any course.

====New RSpec Test Cases====

1. To check each due date of assignment:

describe '#for_each_due_date_of_assignment' do
let(:due_date_modifier) do
lambda { |dd|
{ label: (dd.deadline_type.name + ' Deadline').humanize,
updated_at: dd.due_at.strftime('%a, %d %b %Y %H:%M') }
}
end
context 'when called with assignment having empty due dates' do
it 'return empty time_list array' do
timeline_list = []
student_task_helper.for_each_due_date_of_assignment(assignment) do |due_date|
timeline_list << due_date_modifier.call(due_date)
end
expect(timeline_list).to eq([])
end
end
context 'when called with assignment having due date' do
context 'and due_at value nil' do
it 'return empty time_list array' do
allow(due_date).to receive(:deadline_type).and_return(deadline_type)
timeline_list = []
due_date.due_at = nil
assignment.due_dates = [due_date]
student_task_helper.for_each_due_date_of_assignment(assignment) { |due_date| timeline_list << due_date_modifier.call(due_date) }
expect(timeline_list).to eq([])
end
end
context 'and due_at value not nil' do
it 'return time_list array' do
allow(due_date).to receive(:deadline_type).and_return(deadline_type)
timeline_list = []
assignment.due_dates = [due_date]
student_task_helper.for_each_due_date_of_assignment(assignment) do |due_date|
timeline_list << due_date_modifier.call(due_date)
end
expect(timeline_list).to eq([{
label: (due_date.deadline_type.name + ' Deadline').humanize,
updated_at: due_date.due_at.strftime('%a, %d %b %Y %H:%M')
}])
end
end
end
end

2. To check for peer reviews

describe '#for_each_peer_review' do
context 'when no review response mapped' do
it 'returns empty' do
timeline_list = []
for_each_peer_review(user2) do |response|
timeline_list << response_modifier.call(response, "Round #{response.round} Peer Review".humanize)
end
expect(timeline_list).to eq([])
end
end
context 'when mapped to review response map' do
it 'returns timeline array' do
timeline_list = []
allow(ReviewResponseMap).to receive_message_chain(:where, :find_each).with(reviewer_id: 1).with(no_args).and_yield(review_response_map)
allow(review_response_map).to receive(:id).and_return(1)
allow(Response).to receive_message_chain(:where, :last).with(map_id: 1).with(no_args).and_return(response)
allow(response).to receive(:round).and_return(1)
allow(response).to receive(:updated_at).and_return(Time.new(2019))
timevalue = Time.new(2019).strftime('%a, %d %b %Y %H:%M')
for_each_peer_review(1) do |resp|
timeline_list << response_modifier.call(resp, "Round #{resp.round} Peer Review".humanize)
end
expect(timeline_list).to eq([{ id: 1, label: 'Round 1 peer review', updated_at: timevalue }])
end
end
end

3. To check and validate author feedbacks

describe '#for_each_author_feedback' do
context 'when no feedback response mapped' do
it 'returns empty' do
timeline_list = []
for_each_author_feedback(user2) do |response|
timeline_list << response_modifier.call(response, 'Author feedback')
end
expect(timeline_list).to eq([])
end
end
context 'when mapped to feedback response map' do
it 'returns timeline array' do
timeline_list = []
allow(FeedbackResponseMap).to receive_message_chain(:where, :find_each).with(reviewer_id: 1).with(no_args).and_yield(review_response_map)
allow(review_response_map).to receive(:id).and_return(1)
allow(Response).to receive_message_chain(:where, :last).with(map_id: 1).with(no_args).and_return(response)
allow(response).to receive(:updated_at).and_return(Time.now)
timevalue = Time.now.strftime('%a, %d %b %Y %H:%M')
timeline_list = []
for_each_author_feedback(1) do |response|
timeline_list << response_modifier.call(response, 'Author feedback')
end
expect(timeline_list).to eq([{ id: 1, label: 'Author feedback', updated_at: timevalue }])
end
end
end

4. To create and validate generated timelines

describe '#generate_timeline' do
context 'when no timeline data mapped' do
it 'returns nil' do
allow(participant).to receive(:get_reviewer).and_return(participant)
expect(student_task_helper.generate_timeline(assignment, participant)).to eq([])
end
end
end

5. Check if StudentTask obeject is created properly

describe '#create_student_task_for_participant' do
it 'creates a StudentTask with the correct attributes' do
student_task = student_task_helper.create_student_task_for_participant(participant3)
expect(student_task).to be_an_instance_of(StudentTask)
expect(student_task.participant).to eq(participant3)
expect(student_task.assignment).to eq(assignment)
expect(student_task.topic).to eq(topic)
expect(student_task.current_stage).to eq('submission')
expect(student_task.stage_deadline).to eq(Time.parse('2024-12-31 12:00:00'))
end
end

6. To check the retrieved tasks for users

describe '#retrieve_tasks_for_user' do
before do
allow(user).to receive_message_chain(:assignment_participants, :includes).and_return([participant4, participant5])
end

it 'retrieves and sorts tasks by stage_deadline' do
tasks = student_task_helper.retrieve_tasks_for_user(user)
expect(tasks.size).to eq(2)
expect(tasks.first.stage_deadline).to eq(Time.parse('2024-11-01 12:00:00'))
expect(tasks.last.stage_deadline).to eq(Time.parse('2024-12-01 12:00:00'))
end

it 'creates StudentTask objects for each participant' do
tasks = student_task_helper.retrieve_tasks_for_user(user)
tasks.each do |task|
expect(task).to be_an_instance_of(StudentTask)
expect(task.participant).to be_in([participant4, participant5])
expect(task.assignment).to eq(assignment)
expect(task.topic).to eq(topic)
end
end
end

7. To check if deadlines are parsed properly

describe '#parse_stage_deadline' do
context 'If a valid time value is given' do
it 'parse the provided time correctly' do
given_time = '2024-12-31 12:00:00'
parsed_time = student_task_helper.parse_stage_deadline(given_time)
expect(parsed_time).to eq(Time.parse(given_time))
end
end

context 'If given time string is invalid' do
it 'return current time plus 1 year' do
given_time = 'invalid-time-string'
overhead_time = Time.now + 1.year
parsed_time = student_task_helper.parse_stage_deadline(given_time)
expect(parsed_time).to be_within(1.second).of(overhead_time)
end
end
end

8. To check various conditions of users tagged as teammates

describe '#group_teammates_by_course_for_user' do
context 'when not in any team' do
it 'returns empty' do
expect(student_task_helper.group_teammates_by_course_for_user(user3)).to eq({})
end
end
context 'when assigned in a course_team ' do
it 'returns empty' do
allow(user).to receive(:teams).and_return([course_team])
expect(student_task_helper.group_teammates_by_course_for_user(user)).to eq({})
end
end
context 'when assigned in a assignment_team ' do
it 'returns the students they are teamed with' do
allow(user).to receive(:teams).and_return([team])
allow(AssignmentParticipant).to receive(:find_by).with(user_id: 1, parent_id: assignment.id).and_return(participant)
allow(AssignmentParticipant).to receive(:find_by).with(user_id: 5, parent_id: assignment.id).and_return(participant2)
allow(Assignment).to receive(:find_by).with(id: team.parent_id).and_return(assignment)
expect(student_task_helper.group_teammates_by_course_for_user(user)).to eq(assignment.course_id => [user2.fullname])
end
end
end

==Team==

====Mentor====

* Ammana, Sahithi <sammana@ncsu.edu>

====Members====

* Eathamukkala, Akarsh Reddy <aeatham@ncsu.edu>
* Koul, Anmol <akoul2@ncsu.edu>
* More, Harsh <hmore@ncsu.edu>

==References==

# [https://expertiza.ncsu.edu/ Expertiza]
# [https://docs.google.com/document/d/1fB9nHsop_yptjcj3CFn80BcZjXcSDbzcWwKvBDUTVrQ/edit?tab=t.0 OSS Projects on Expertiza]
# [https://github.com/expertiza/expertiza Github]
# [https://github.com/expertiza/expertiza/pull/2859 Pull Request]
# [http://152.7.177.54:8080/ Expertiza VCL Server]

CSC/ECE 517 Fall 2024 - E2454. Refactor student task.rb

2024-10-30T03:57:11Z

Akoul2: /* Refactoring */

==Expertiza==

Expertiza is a web application through which students can submit and peer-review learning objects (articles, code, web sites, etc).
The National Science Foundation supports the Expertiza project.
It is used in select courses at NC State and by professors at several other colleges and universities.

[http://expertiza.ncsu.edu/ Expertiza] is a [http://rubyonrails.org/ Ruby on Rails] based open source project.

==Problem Statement==

====Background====
This project focuses on refactoring the StudentTask class to improve the organization, functionality, and separation of concerns. Currently, the class contains a mix of utility and class methods, many of which are static and should be moved into helper modules or relevant model classes, or broken down into separate, more maintainable methods. The goal is to make the class more efficient and follow best practices in object-oriented programming.

The StudentTask model is a significant part of the Expertiza website which maintains and handles student data who are participants under an assignment. Each assignment has a team, individual user participant and submission deadlines. The motive here is to refactor static methods called in the student_task.rb file and move them to helper classes for better object-oriented code design.

==About StudentTask Model==
The StudentTask model handles the tracking and organizes of student assignments, encapsulating key information about a student’s current progress, deadlines, and associated tasks. It provides different functional methods for task creation, checking completion status, and timeline generation, ensuring a streamlined and detailed view of a student's assignment timelines. The model interacts closely with assignment participants and topics to display their task completion stages, reviews, and deadlines.

===Functionality===
The StudentTask model manages student assignments with the help of functional methods to initialize tasks, track deadlines, and task assessment. It includes class method from_participant, which creates a task based on a participant’s data, and from_user, that generates a sorted list of tasks by deadline for a particular user. Task status is determined through methods such as complete?, incomplete?, and started?. Additionally The revision? method checks for ongoing updates based on current stage and submissions. The model also incorporates methods (such as get_due_date_data, get_submission_data, etc.) that compile task events in chronological order, enabling a clear overview of assignment deadlines, submissions, and peer reviews. Through encapsulation, delegation, and adherence to SRP, StudentTask ensures efficient and modular task tracking aligned with the required educational processes.

==Functionality of StudentTaskHelper Module==
The StudentTaskHelper module facilitates efficient task management by handling operations such as timeline generation, teammate grouping, and task initialization for participants. It includes generate_timeline, which combines due date, peer review, and author feedback timelines, as well as create_student_task_for_participant to initialize tasks based on participant data. The module introduces iterator patterns through methods such as for_each_due_date_of_assignment, for_each_peer_review, and for_each_author_feedback, which yield data to enhance flexibility and modularity within the codebase.

Helper methods like group_teammates_by_course_for_user efficiently organize teammates by course, while methods like parse_due_date_to_timeline and parse_response_to_timeline encapsulate logic for structuring timeline events. Using private helper methods such as fetch_response_from, and utility functions like calibration_assignment? and valid_assignment_team?, StudentTaskHelper optimizes data handling, improves readability, and adheres to object-oriented design principles by reducing the need for static methods in the StudentTask model.

====Refactor====

The StudentTask model do not strictly follow the SRP and DRY principles and needed a lot of refactoring to make them more manageable in following Object-Oriented design and development.

Files modified:
* student_task.rb
* student_task_controller.rb
* student_task_helper.rb
* student_task_spec.rb
* assessment360_controller.rb
* assessment360_controller_spec.rb

New files added:
* student_task_helper_spec.rb

==Login Details==

* username = instructor6
* password = password

==Refactoring==

====self.from_participant(participant)====
Creates a StudentTask instance for a given participant, populating it with relevant assignment and stage data.

Before:

[[File:Akoul2 from participant before.jpg]]

After:

[[File:Akoul from participant after1.jpg]]

[[File:Akoul from participant after2.jpg]]

====self.from_participantid(id)====
It searches and fetches an active participant by its id.

Before:

[[File:Akoul2 from participant id before.jpg]]

After:

This method is depreciated during the refactoring process. It no longer served its purpose and was removed from the codebase.

====self.from_user(user)====
Retrieves tasks associated with a user by iterating over the user's assignment participants and sorting them by their stage deadlines.

Before:

[[File:Akoul2 from user before.jpg]]

After:

[[File:Akoul2 from user after.jpg]]

====self.get_author_feedback_data(participant_id, timeline_list)====
Generates a timeline of author feedback for a participant by mapping each feedback response through a parsing function.

Before:

[[File:Akoul2 get author feedback data before.jpg]]

After:

[[File:Akoul2 get author feedback data after.jpg]]

====self.get_due_date_data(assignment, timeline_list)====
Generates a timeline of due dates for an assignment by mapping each due date through a parsing function.

Before:

[[File:Akoul2 get due date data before.jpg]]

After:

[[File:Akoul2 get due date after.jpg]]

====self.peer_review_data(participant_id, timeline_list)====
Iterates through each peer review for a participant, yielding each review to a provided block.

Before:

[[File:Akoul2 peer review data before.jpg]]

After:

[[File:Akoul2 get peer review data after.jpg]]

====self.get_submission_data(participant_id, team_id, timeline_list)====

Before:

[[File:Akoul2 get submission data before.jpg]]

After:

This method, similar to from_participantid(), didn't showcase its usefulness during the refactoring process and was removed from the codebase.

====self.get_timeline_data(assignment, participant, _team)====
Generates a timeline of events related to the assignment for the participant, including due dates, peer reviews, and author feedback, sorted by update time.

Before:

[[File:Akoul2 get timeline data before.jpg]]

After:

[[File:Akoul2 get timeline data after.jpg]]

====self.teamed_student(user, ip_address=nil)====
Groups teammates by course for a user and returns a hash where keys are course IDs and values are lists of teammate names.

Before:

[[File:Akoul2 teamed student before.jpg]]

After:

[[File:Akoul2 teamed student after.jpg]]

Additional methods added:

[[File:Akoul2 additional methods.jpg]]

==Test Cases for StudentTask Model, Controller and helper classes==

====Descriptive test cases====

* '''Accessing the Assignments Page'''
- Objective: Verify that the assignments page is accessible and displays all available assignments.
- Steps: Navigate to the **Assignments** tab and confirm that it loads without errors, displaying the list of assignments.

* '''Selecting an Assignment'''
- Objective: Confirm that selecting an assignment redirects the user to the detailed view.
- Steps: From the **Assignments** page, click on any assignment and verify that you are redirected to the respective **StudentTask** page for that assignment.

* '''Viewing Assignment Details'''
- Objective: Ensure that the **StudentTask** page displays assignment details, such as course, topic, and current stage.
- Steps: On the **StudentTask** page, verify the presence of fields like course, topic, and current stage, ensuring accuracy in the information displayed.

* '''Navigating "Your Work" and "Others' Work" Links'''
- Objective: Test the links to "Your Work" and "Others' Work" sections to confirm they display relevant information.
- Steps: Click the **Your Work** link to confirm it shows the student's submissions; then click the **Others' Work** link to verify it shows other students’ work or available feedback options, as applicable.

* '''Checking Review Grade Information'''
- Objective: Verify that the review grade, if available, is displayed along with any awarded badges.
- Steps: Confirm the **Review Grade** section displays either a numeric grade or "N/A" if no grade is available, and ensure any badges appear with accurate images and tooltips.

* '''Assignment Timelines and Deadline Tasks'''
- Objective: Verify that each assignment timeline and associated deadlines are listed on the StudentTask page.
- Steps: Navigate to the **Assignment Timelines** section and confirm that each task is listed in order with relevant due dates.

* '''Checking and Sending Reviewer Emails'''
- Objective: Test the "Send Email to Reviewers" feature to ensure it functions as expected.
- Steps: On the **StudentTask** page, select the **Send Email to Reviewers** option and confirm the email interface opens, allowing the student to message reviewers.

* '''Revisions and Unstarted Tasks'''
- Objective: Verify that any revisions and unstarted tasks for the assignment are displayed accurately.
- Steps: Check for sections labeled **Revisions** and **Tasks Not Yet Started**, and confirm that each section lists the student’s pending tasks correctly.

* '''Viewing Teammates and Course Association'''
- Objective: Confirm that teammates and course association are accurately displayed for assignments.
- Steps: In the **Students Who Are Teamed with You** section, ensure teammates’ names and roles are displayed. Check that the assignment shows an association with a course name if applicable, or confirms if it is not associated with any course.

====New RSpec Test Cases====

1. To check each due date of assignment:

describe '#for_each_due_date_of_assignment' do
let(:due_date_modifier) do
lambda { |dd|
{ label: (dd.deadline_type.name + ' Deadline').humanize,
updated_at: dd.due_at.strftime('%a, %d %b %Y %H:%M') }
}
end
context 'when called with assignment having empty due dates' do
it 'return empty time_list array' do
timeline_list = []
student_task_helper.for_each_due_date_of_assignment(assignment) do |due_date|
timeline_list << due_date_modifier.call(due_date)
end
expect(timeline_list).to eq([])
end
end
context 'when called with assignment having due date' do
context 'and due_at value nil' do
it 'return empty time_list array' do
allow(due_date).to receive(:deadline_type).and_return(deadline_type)
timeline_list = []
due_date.due_at = nil
assignment.due_dates = [due_date]
student_task_helper.for_each_due_date_of_assignment(assignment) { |due_date| timeline_list << due_date_modifier.call(due_date) }
expect(timeline_list).to eq([])
end
end
context 'and due_at value not nil' do
it 'return time_list array' do
allow(due_date).to receive(:deadline_type).and_return(deadline_type)
timeline_list = []
assignment.due_dates = [due_date]
student_task_helper.for_each_due_date_of_assignment(assignment) do |due_date|
timeline_list << due_date_modifier.call(due_date)
end
expect(timeline_list).to eq([{
label: (due_date.deadline_type.name + ' Deadline').humanize,
updated_at: due_date.due_at.strftime('%a, %d %b %Y %H:%M')
}])
end
end
end
end

2. To check for peer reviews

describe '#for_each_peer_review' do
context 'when no review response mapped' do
it 'returns empty' do
timeline_list = []
for_each_peer_review(user2) do |response|
timeline_list << response_modifier.call(response, "Round #{response.round} Peer Review".humanize)
end
expect(timeline_list).to eq([])
end
end
context 'when mapped to review response map' do
it 'returns timeline array' do
timeline_list = []
allow(ReviewResponseMap).to receive_message_chain(:where, :find_each).with(reviewer_id: 1).with(no_args).and_yield(review_response_map)
allow(review_response_map).to receive(:id).and_return(1)
allow(Response).to receive_message_chain(:where, :last).with(map_id: 1).with(no_args).and_return(response)
allow(response).to receive(:round).and_return(1)
allow(response).to receive(:updated_at).and_return(Time.new(2019))
timevalue = Time.new(2019).strftime('%a, %d %b %Y %H:%M')
for_each_peer_review(1) do |resp|
timeline_list << response_modifier.call(resp, "Round #{resp.round} Peer Review".humanize)
end
expect(timeline_list).to eq([{ id: 1, label: 'Round 1 peer review', updated_at: timevalue }])
end
end
end

3. To check and validate author feedbacks

describe '#for_each_author_feedback' do
context 'when no feedback response mapped' do
it 'returns empty' do
timeline_list = []
for_each_author_feedback(user2) do |response|
timeline_list << response_modifier.call(response, 'Author feedback')
end
expect(timeline_list).to eq([])
end
end
context 'when mapped to feedback response map' do
it 'returns timeline array' do
timeline_list = []
allow(FeedbackResponseMap).to receive_message_chain(:where, :find_each).with(reviewer_id: 1).with(no_args).and_yield(review_response_map)
allow(review_response_map).to receive(:id).and_return(1)
allow(Response).to receive_message_chain(:where, :last).with(map_id: 1).with(no_args).and_return(response)
allow(response).to receive(:updated_at).and_return(Time.now)
timevalue = Time.now.strftime('%a, %d %b %Y %H:%M')
timeline_list = []
for_each_author_feedback(1) do |response|
timeline_list << response_modifier.call(response, 'Author feedback')
end
expect(timeline_list).to eq([{ id: 1, label: 'Author feedback', updated_at: timevalue }])
end
end
end

4. To create and validate generated timelines

describe '#generate_timeline' do
context 'when no timeline data mapped' do
it 'returns nil' do
allow(participant).to receive(:get_reviewer).and_return(participant)
expect(student_task_helper.generate_timeline(assignment, participant)).to eq([])
end
end
end

5. Check if StudentTask obeject is created properly

describe '#create_student_task_for_participant' do
it 'creates a StudentTask with the correct attributes' do
student_task = student_task_helper.create_student_task_for_participant(participant3)
expect(student_task).to be_an_instance_of(StudentTask)
expect(student_task.participant).to eq(participant3)
expect(student_task.assignment).to eq(assignment)
expect(student_task.topic).to eq(topic)
expect(student_task.current_stage).to eq('submission')
expect(student_task.stage_deadline).to eq(Time.parse('2024-12-31 12:00:00'))
end
end

6. To check the retrieved tasks for users

describe '#retrieve_tasks_for_user' do
before do
allow(user).to receive_message_chain(:assignment_participants, :includes).and_return([participant4, participant5])
end

it 'retrieves and sorts tasks by stage_deadline' do
tasks = student_task_helper.retrieve_tasks_for_user(user)
expect(tasks.size).to eq(2)
expect(tasks.first.stage_deadline).to eq(Time.parse('2024-11-01 12:00:00'))
expect(tasks.last.stage_deadline).to eq(Time.parse('2024-12-01 12:00:00'))
end

it 'creates StudentTask objects for each participant' do
tasks = student_task_helper.retrieve_tasks_for_user(user)
tasks.each do |task|
expect(task).to be_an_instance_of(StudentTask)
expect(task.participant).to be_in([participant4, participant5])
expect(task.assignment).to eq(assignment)
expect(task.topic).to eq(topic)
end
end
end

7. To check if deadlines are parsed properly

describe '#parse_stage_deadline' do
context 'If a valid time value is given' do
it 'parse the provided time correctly' do
given_time = '2024-12-31 12:00:00'
parsed_time = student_task_helper.parse_stage_deadline(given_time)
expect(parsed_time).to eq(Time.parse(given_time))
end
end

context 'If given time string is invalid' do
it 'return current time plus 1 year' do
given_time = 'invalid-time-string'
overhead_time = Time.now + 1.year
parsed_time = student_task_helper.parse_stage_deadline(given_time)
expect(parsed_time).to be_within(1.second).of(overhead_time)
end
end
end

8. To check various conditions of users tagged as teammates

describe '#group_teammates_by_course_for_user' do
context 'when not in any team' do
it 'returns empty' do
expect(student_task_helper.group_teammates_by_course_for_user(user3)).to eq({})
end
end
context 'when assigned in a course_team ' do
it 'returns empty' do
allow(user).to receive(:teams).and_return([course_team])
expect(student_task_helper.group_teammates_by_course_for_user(user)).to eq({})
end
end
context 'when assigned in a assignment_team ' do
it 'returns the students they are teamed with' do
allow(user).to receive(:teams).and_return([team])
allow(AssignmentParticipant).to receive(:find_by).with(user_id: 1, parent_id: assignment.id).and_return(participant)
allow(AssignmentParticipant).to receive(:find_by).with(user_id: 5, parent_id: assignment.id).and_return(participant2)
allow(Assignment).to receive(:find_by).with(id: team.parent_id).and_return(assignment)
expect(student_task_helper.group_teammates_by_course_for_user(user)).to eq(assignment.course_id => [user2.fullname])
end
end
end

==Team==

====Mentor====

* Ammana, Sahithi <sammana@ncsu.edu>

====Members====

* Eathamukkala, Akarsh Reddy <aeatham@ncsu.edu>
* Koul, Anmol <akoul2@ncsu.edu>
* More, Harsh <hmore@ncsu.edu>

==References==

# [https://expertiza.ncsu.edu/ Expertiza]
# [https://docs.google.com/document/d/1fB9nHsop_yptjcj3CFn80BcZjXcSDbzcWwKvBDUTVrQ/edit?tab=t.0 OSS Projects on Expertiza]
# [https://github.com/expertiza/expertiza Github]
# [https://github.com/expertiza/expertiza/pull/2859 Pull Request]
# [http://152.7.177.54:8080/ Expertiza VCL Server]

CSC/ECE 517 Fall 2024 - E2454. Refactor student task.rb

2024-10-30T03:55:35Z

Akoul2: /* Descriptive test cases */

==Expertiza==

Expertiza is a web application through which students can submit and peer-review learning objects (articles, code, web sites, etc).
The National Science Foundation supports the Expertiza project.
It is used in select courses at NC State and by professors at several other colleges and universities.

[http://expertiza.ncsu.edu/ Expertiza] is a [http://rubyonrails.org/ Ruby on Rails] based open source project.

==Problem Statement==

====Background====
This project focuses on refactoring the StudentTask class to improve the organization, functionality, and separation of concerns. Currently, the class contains a mix of utility and class methods, many of which are static and should be moved into helper modules or relevant model classes, or broken down into separate, more maintainable methods. The goal is to make the class more efficient and follow best practices in object-oriented programming.

The StudentTask model is a significant part of the Expertiza website which maintains and handles student data who are participants under an assignment. Each assignment has a team, individual user participant and submission deadlines. The motive here is to refactor static methods called in the student_task.rb file and move them to helper classes for better object-oriented code design.

==About StudentTask Model==
The StudentTask model handles the tracking and organizes of student assignments, encapsulating key information about a student’s current progress, deadlines, and associated tasks. It provides different functional methods for task creation, checking completion status, and timeline generation, ensuring a streamlined and detailed view of a student's assignment timelines. The model interacts closely with assignment participants and topics to display their task completion stages, reviews, and deadlines.

===Functionality===
The StudentTask model manages student assignments with the help of functional methods to initialize tasks, track deadlines, and task assessment. It includes class method from_participant, which creates a task based on a participant’s data, and from_user, that generates a sorted list of tasks by deadline for a particular user. Task status is determined through methods such as complete?, incomplete?, and started?. Additionally The revision? method checks for ongoing updates based on current stage and submissions. The model also incorporates methods (such as get_due_date_data, get_submission_data, etc.) that compile task events in chronological order, enabling a clear overview of assignment deadlines, submissions, and peer reviews. Through encapsulation, delegation, and adherence to SRP, StudentTask ensures efficient and modular task tracking aligned with the required educational processes.

==Functionality of StudentTaskHelper Module==
The StudentTaskHelper module facilitates efficient task management by handling operations such as timeline generation, teammate grouping, and task initialization for participants. It includes generate_timeline, which combines due date, peer review, and author feedback timelines, as well as create_student_task_for_participant to initialize tasks based on participant data. The module introduces iterator patterns through methods such as for_each_due_date_of_assignment, for_each_peer_review, and for_each_author_feedback, which yield data to enhance flexibility and modularity within the codebase.

Helper methods like group_teammates_by_course_for_user efficiently organize teammates by course, while methods like parse_due_date_to_timeline and parse_response_to_timeline encapsulate logic for structuring timeline events. Using private helper methods such as fetch_response_from, and utility functions like calibration_assignment? and valid_assignment_team?, StudentTaskHelper optimizes data handling, improves readability, and adheres to object-oriented design principles by reducing the need for static methods in the StudentTask model.

====Refactor====

The StudentTask model do not strictly follow the SRP and DRY principles and needed a lot of refactoring to make them more manageable in following Object-Oriented design and development.

Files modified:
* student_task.rb
* student_task_controller.rb
* student_task_helper.rb
* student_task_spec.rb
* assessment360_controller.rb
* assessment360_controller_spec.rb

New files added:
* student_task_helper_spec.rb

==Refactoring==

====self.from_participant(participant)====
Creates a StudentTask instance for a given participant, populating it with relevant assignment and stage data.

Before:

[[File:Akoul2 from participant before.jpg]]

After:

[[File:Akoul from participant after1.jpg]]

[[File:Akoul from participant after2.jpg]]

====self.from_participantid(id)====
It searches and fetches an active participant by its id.

Before:

[[File:Akoul2 from participant id before.jpg]]

After:

This method is depreciated during the refactoring process. It no longer served its purpose and was removed from the codebase.

====self.from_user(user)====
Retrieves tasks associated with a user by iterating over the user's assignment participants and sorting them by their stage deadlines.

Before:

[[File:Akoul2 from user before.jpg]]

After:

[[File:Akoul2 from user after.jpg]]

====self.get_author_feedback_data(participant_id, timeline_list)====
Generates a timeline of author feedback for a participant by mapping each feedback response through a parsing function.

Before:

[[File:Akoul2 get author feedback data before.jpg]]

After:

[[File:Akoul2 get author feedback data after.jpg]]

====self.get_due_date_data(assignment, timeline_list)====
Generates a timeline of due dates for an assignment by mapping each due date through a parsing function.

Before:

[[File:Akoul2 get due date data before.jpg]]

After:

[[File:Akoul2 get due date after.jpg]]

====self.peer_review_data(participant_id, timeline_list)====
Iterates through each peer review for a participant, yielding each review to a provided block.

Before:

[[File:Akoul2 peer review data before.jpg]]

After:

[[File:Akoul2 get peer review data after.jpg]]

====self.get_submission_data(participant_id, team_id, timeline_list)====

Before:

[[File:Akoul2 get submission data before.jpg]]

After:

This method, similar to from_participantid(), didn't showcase its usefulness during the refactoring process and was removed from the codebase.

====self.get_timeline_data(assignment, participant, _team)====
Generates a timeline of events related to the assignment for the participant, including due dates, peer reviews, and author feedback, sorted by update time.

Before:

[[File:Akoul2 get timeline data before.jpg]]

After:

[[File:Akoul2 get timeline data after.jpg]]

====self.teamed_student(user, ip_address=nil)====
Groups teammates by course for a user and returns a hash where keys are course IDs and values are lists of teammate names.

Before:

[[File:Akoul2 teamed student before.jpg]]

After:

[[File:Akoul2 teamed student after.jpg]]

Additional methods added:

[[File:Akoul2 additional methods.jpg]]

==Test Cases for StudentTask Model, Controller and helper classes==

====Descriptive test cases====

* '''Accessing the Assignments Page'''
- Objective: Verify that the assignments page is accessible and displays all available assignments.
- Steps: Navigate to the **Assignments** tab and confirm that it loads without errors, displaying the list of assignments.

* '''Selecting an Assignment'''
- Objective: Confirm that selecting an assignment redirects the user to the detailed view.
- Steps: From the **Assignments** page, click on any assignment and verify that you are redirected to the respective **StudentTask** page for that assignment.

* '''Viewing Assignment Details'''
- Objective: Ensure that the **StudentTask** page displays assignment details, such as course, topic, and current stage.
- Steps: On the **StudentTask** page, verify the presence of fields like course, topic, and current stage, ensuring accuracy in the information displayed.

* '''Navigating "Your Work" and "Others' Work" Links'''
- Objective: Test the links to "Your Work" and "Others' Work" sections to confirm they display relevant information.
- Steps: Click the **Your Work** link to confirm it shows the student's submissions; then click the **Others' Work** link to verify it shows other students’ work or available feedback options, as applicable.

* '''Checking Review Grade Information'''
- Objective: Verify that the review grade, if available, is displayed along with any awarded badges.
- Steps: Confirm the **Review Grade** section displays either a numeric grade or "N/A" if no grade is available, and ensure any badges appear with accurate images and tooltips.

* '''Assignment Timelines and Deadline Tasks'''
- Objective: Verify that each assignment timeline and associated deadlines are listed on the StudentTask page.
- Steps: Navigate to the **Assignment Timelines** section and confirm that each task is listed in order with relevant due dates.

* '''Checking and Sending Reviewer Emails'''
- Objective: Test the "Send Email to Reviewers" feature to ensure it functions as expected.
- Steps: On the **StudentTask** page, select the **Send Email to Reviewers** option and confirm the email interface opens, allowing the student to message reviewers.

* '''Revisions and Unstarted Tasks'''
- Objective: Verify that any revisions and unstarted tasks for the assignment are displayed accurately.
- Steps: Check for sections labeled **Revisions** and **Tasks Not Yet Started**, and confirm that each section lists the student’s pending tasks correctly.

* '''Viewing Teammates and Course Association'''
- Objective: Confirm that teammates and course association are accurately displayed for assignments.
- Steps: In the **Students Who Are Teamed with You** section, ensure teammates’ names and roles are displayed. Check that the assignment shows an association with a course name if applicable, or confirms if it is not associated with any course.

====New RSpec Test Cases====

1. To check each due date of assignment:

describe '#for_each_due_date_of_assignment' do
let(:due_date_modifier) do
lambda { |dd|
{ label: (dd.deadline_type.name + ' Deadline').humanize,
updated_at: dd.due_at.strftime('%a, %d %b %Y %H:%M') }
}
end
context 'when called with assignment having empty due dates' do
it 'return empty time_list array' do
timeline_list = []
student_task_helper.for_each_due_date_of_assignment(assignment) do |due_date|
timeline_list << due_date_modifier.call(due_date)
end
expect(timeline_list).to eq([])
end
end
context 'when called with assignment having due date' do
context 'and due_at value nil' do
it 'return empty time_list array' do
allow(due_date).to receive(:deadline_type).and_return(deadline_type)
timeline_list = []
due_date.due_at = nil
assignment.due_dates = [due_date]
student_task_helper.for_each_due_date_of_assignment(assignment) { |due_date| timeline_list << due_date_modifier.call(due_date) }
expect(timeline_list).to eq([])
end
end
context 'and due_at value not nil' do
it 'return time_list array' do
allow(due_date).to receive(:deadline_type).and_return(deadline_type)
timeline_list = []
assignment.due_dates = [due_date]
student_task_helper.for_each_due_date_of_assignment(assignment) do |due_date|
timeline_list << due_date_modifier.call(due_date)
end
expect(timeline_list).to eq([{
label: (due_date.deadline_type.name + ' Deadline').humanize,
updated_at: due_date.due_at.strftime('%a, %d %b %Y %H:%M')
}])
end
end
end
end

2. To check for peer reviews

describe '#for_each_peer_review' do
context 'when no review response mapped' do
it 'returns empty' do
timeline_list = []
for_each_peer_review(user2) do |response|
timeline_list << response_modifier.call(response, "Round #{response.round} Peer Review".humanize)
end
expect(timeline_list).to eq([])
end
end
context 'when mapped to review response map' do
it 'returns timeline array' do
timeline_list = []
allow(ReviewResponseMap).to receive_message_chain(:where, :find_each).with(reviewer_id: 1).with(no_args).and_yield(review_response_map)
allow(review_response_map).to receive(:id).and_return(1)
allow(Response).to receive_message_chain(:where, :last).with(map_id: 1).with(no_args).and_return(response)
allow(response).to receive(:round).and_return(1)
allow(response).to receive(:updated_at).and_return(Time.new(2019))
timevalue = Time.new(2019).strftime('%a, %d %b %Y %H:%M')
for_each_peer_review(1) do |resp|
timeline_list << response_modifier.call(resp, "Round #{resp.round} Peer Review".humanize)
end
expect(timeline_list).to eq([{ id: 1, label: 'Round 1 peer review', updated_at: timevalue }])
end
end
end

3. To check and validate author feedbacks

describe '#for_each_author_feedback' do
context 'when no feedback response mapped' do
it 'returns empty' do
timeline_list = []
for_each_author_feedback(user2) do |response|
timeline_list << response_modifier.call(response, 'Author feedback')
end
expect(timeline_list).to eq([])
end
end
context 'when mapped to feedback response map' do
it 'returns timeline array' do
timeline_list = []
allow(FeedbackResponseMap).to receive_message_chain(:where, :find_each).with(reviewer_id: 1).with(no_args).and_yield(review_response_map)
allow(review_response_map).to receive(:id).and_return(1)
allow(Response).to receive_message_chain(:where, :last).with(map_id: 1).with(no_args).and_return(response)
allow(response).to receive(:updated_at).and_return(Time.now)
timevalue = Time.now.strftime('%a, %d %b %Y %H:%M')
timeline_list = []
for_each_author_feedback(1) do |response|
timeline_list << response_modifier.call(response, 'Author feedback')
end
expect(timeline_list).to eq([{ id: 1, label: 'Author feedback', updated_at: timevalue }])
end
end
end

4. To create and validate generated timelines

describe '#generate_timeline' do
context 'when no timeline data mapped' do
it 'returns nil' do
allow(participant).to receive(:get_reviewer).and_return(participant)
expect(student_task_helper.generate_timeline(assignment, participant)).to eq([])
end
end
end

5. Check if StudentTask obeject is created properly

describe '#create_student_task_for_participant' do
it 'creates a StudentTask with the correct attributes' do
student_task = student_task_helper.create_student_task_for_participant(participant3)
expect(student_task).to be_an_instance_of(StudentTask)
expect(student_task.participant).to eq(participant3)
expect(student_task.assignment).to eq(assignment)
expect(student_task.topic).to eq(topic)
expect(student_task.current_stage).to eq('submission')
expect(student_task.stage_deadline).to eq(Time.parse('2024-12-31 12:00:00'))
end
end

6. To check the retrieved tasks for users

describe '#retrieve_tasks_for_user' do
before do
allow(user).to receive_message_chain(:assignment_participants, :includes).and_return([participant4, participant5])
end

it 'retrieves and sorts tasks by stage_deadline' do
tasks = student_task_helper.retrieve_tasks_for_user(user)
expect(tasks.size).to eq(2)
expect(tasks.first.stage_deadline).to eq(Time.parse('2024-11-01 12:00:00'))
expect(tasks.last.stage_deadline).to eq(Time.parse('2024-12-01 12:00:00'))
end

it 'creates StudentTask objects for each participant' do
tasks = student_task_helper.retrieve_tasks_for_user(user)
tasks.each do |task|
expect(task).to be_an_instance_of(StudentTask)
expect(task.participant).to be_in([participant4, participant5])
expect(task.assignment).to eq(assignment)
expect(task.topic).to eq(topic)
end
end
end

7. To check if deadlines are parsed properly

describe '#parse_stage_deadline' do
context 'If a valid time value is given' do
it 'parse the provided time correctly' do
given_time = '2024-12-31 12:00:00'
parsed_time = student_task_helper.parse_stage_deadline(given_time)
expect(parsed_time).to eq(Time.parse(given_time))
end
end

context 'If given time string is invalid' do
it 'return current time plus 1 year' do
given_time = 'invalid-time-string'
overhead_time = Time.now + 1.year
parsed_time = student_task_helper.parse_stage_deadline(given_time)
expect(parsed_time).to be_within(1.second).of(overhead_time)
end
end
end

8. To check various conditions of users tagged as teammates

describe '#group_teammates_by_course_for_user' do
context 'when not in any team' do
it 'returns empty' do
expect(student_task_helper.group_teammates_by_course_for_user(user3)).to eq({})
end
end
context 'when assigned in a course_team ' do
it 'returns empty' do
allow(user).to receive(:teams).and_return([course_team])
expect(student_task_helper.group_teammates_by_course_for_user(user)).to eq({})
end
end
context 'when assigned in a assignment_team ' do
it 'returns the students they are teamed with' do
allow(user).to receive(:teams).and_return([team])
allow(AssignmentParticipant).to receive(:find_by).with(user_id: 1, parent_id: assignment.id).and_return(participant)
allow(AssignmentParticipant).to receive(:find_by).with(user_id: 5, parent_id: assignment.id).and_return(participant2)
allow(Assignment).to receive(:find_by).with(id: team.parent_id).and_return(assignment)
expect(student_task_helper.group_teammates_by_course_for_user(user)).to eq(assignment.course_id => [user2.fullname])
end
end
end

==Team==

====Mentor====

* Ammana, Sahithi <sammana@ncsu.edu>

====Members====

* Eathamukkala, Akarsh Reddy <aeatham@ncsu.edu>
* Koul, Anmol <akoul2@ncsu.edu>
* More, Harsh <hmore@ncsu.edu>

==References==

# [https://expertiza.ncsu.edu/ Expertiza]
# [https://docs.google.com/document/d/1fB9nHsop_yptjcj3CFn80BcZjXcSDbzcWwKvBDUTVrQ/edit?tab=t.0 OSS Projects on Expertiza]
# [https://github.com/expertiza/expertiza Github]
# [https://github.com/expertiza/expertiza/pull/2859 Pull Request]
# [http://152.7.177.54:8080/ Expertiza VCL Server]

CSC/ECE 517 Fall 2024 - E2454. Refactor student task.rb

2024-10-30T03:55:27Z

Akoul2: /* Descriptive test cases */

==Expertiza==

Expertiza is a web application through which students can submit and peer-review learning objects (articles, code, web sites, etc).
The National Science Foundation supports the Expertiza project.
It is used in select courses at NC State and by professors at several other colleges and universities.

[http://expertiza.ncsu.edu/ Expertiza] is a [http://rubyonrails.org/ Ruby on Rails] based open source project.

==Problem Statement==

====Background====
This project focuses on refactoring the StudentTask class to improve the organization, functionality, and separation of concerns. Currently, the class contains a mix of utility and class methods, many of which are static and should be moved into helper modules or relevant model classes, or broken down into separate, more maintainable methods. The goal is to make the class more efficient and follow best practices in object-oriented programming.

The StudentTask model is a significant part of the Expertiza website which maintains and handles student data who are participants under an assignment. Each assignment has a team, individual user participant and submission deadlines. The motive here is to refactor static methods called in the student_task.rb file and move them to helper classes for better object-oriented code design.

==About StudentTask Model==
The StudentTask model handles the tracking and organizes of student assignments, encapsulating key information about a student’s current progress, deadlines, and associated tasks. It provides different functional methods for task creation, checking completion status, and timeline generation, ensuring a streamlined and detailed view of a student's assignment timelines. The model interacts closely with assignment participants and topics to display their task completion stages, reviews, and deadlines.

===Functionality===
The StudentTask model manages student assignments with the help of functional methods to initialize tasks, track deadlines, and task assessment. It includes class method from_participant, which creates a task based on a participant’s data, and from_user, that generates a sorted list of tasks by deadline for a particular user. Task status is determined through methods such as complete?, incomplete?, and started?. Additionally The revision? method checks for ongoing updates based on current stage and submissions. The model also incorporates methods (such as get_due_date_data, get_submission_data, etc.) that compile task events in chronological order, enabling a clear overview of assignment deadlines, submissions, and peer reviews. Through encapsulation, delegation, and adherence to SRP, StudentTask ensures efficient and modular task tracking aligned with the required educational processes.

==Functionality of StudentTaskHelper Module==
The StudentTaskHelper module facilitates efficient task management by handling operations such as timeline generation, teammate grouping, and task initialization for participants. It includes generate_timeline, which combines due date, peer review, and author feedback timelines, as well as create_student_task_for_participant to initialize tasks based on participant data. The module introduces iterator patterns through methods such as for_each_due_date_of_assignment, for_each_peer_review, and for_each_author_feedback, which yield data to enhance flexibility and modularity within the codebase.

Helper methods like group_teammates_by_course_for_user efficiently organize teammates by course, while methods like parse_due_date_to_timeline and parse_response_to_timeline encapsulate logic for structuring timeline events. Using private helper methods such as fetch_response_from, and utility functions like calibration_assignment? and valid_assignment_team?, StudentTaskHelper optimizes data handling, improves readability, and adheres to object-oriented design principles by reducing the need for static methods in the StudentTask model.

====Refactor====

The StudentTask model do not strictly follow the SRP and DRY principles and needed a lot of refactoring to make them more manageable in following Object-Oriented design and development.

Files modified:
* student_task.rb
* student_task_controller.rb
* student_task_helper.rb
* student_task_spec.rb
* assessment360_controller.rb
* assessment360_controller_spec.rb

New files added:
* student_task_helper_spec.rb

==Refactoring==

====self.from_participant(participant)====
Creates a StudentTask instance for a given participant, populating it with relevant assignment and stage data.

Before:

[[File:Akoul2 from participant before.jpg]]

After:

[[File:Akoul from participant after1.jpg]]

[[File:Akoul from participant after2.jpg]]

====self.from_participantid(id)====
It searches and fetches an active participant by its id.

Before:

[[File:Akoul2 from participant id before.jpg]]

After:

This method is depreciated during the refactoring process. It no longer served its purpose and was removed from the codebase.

====self.from_user(user)====
Retrieves tasks associated with a user by iterating over the user's assignment participants and sorting them by their stage deadlines.

Before:

[[File:Akoul2 from user before.jpg]]

After:

[[File:Akoul2 from user after.jpg]]

====self.get_author_feedback_data(participant_id, timeline_list)====
Generates a timeline of author feedback for a participant by mapping each feedback response through a parsing function.

Before:

[[File:Akoul2 get author feedback data before.jpg]]

After:

[[File:Akoul2 get author feedback data after.jpg]]

====self.get_due_date_data(assignment, timeline_list)====
Generates a timeline of due dates for an assignment by mapping each due date through a parsing function.

Before:

[[File:Akoul2 get due date data before.jpg]]

After:

[[File:Akoul2 get due date after.jpg]]

====self.peer_review_data(participant_id, timeline_list)====
Iterates through each peer review for a participant, yielding each review to a provided block.

Before:

[[File:Akoul2 peer review data before.jpg]]

After:

[[File:Akoul2 get peer review data after.jpg]]

====self.get_submission_data(participant_id, team_id, timeline_list)====

Before:

[[File:Akoul2 get submission data before.jpg]]

After:

This method, similar to from_participantid(), didn't showcase its usefulness during the refactoring process and was removed from the codebase.

====self.get_timeline_data(assignment, participant, _team)====
Generates a timeline of events related to the assignment for the participant, including due dates, peer reviews, and author feedback, sorted by update time.

Before:

[[File:Akoul2 get timeline data before.jpg]]

After:

[[File:Akoul2 get timeline data after.jpg]]

====self.teamed_student(user, ip_address=nil)====
Groups teammates by course for a user and returns a hash where keys are course IDs and values are lists of teammate names.

Before:

[[File:Akoul2 teamed student before.jpg]]

After:

[[File:Akoul2 teamed student after.jpg]]

Additional methods added:

[[File:Akoul2 additional methods.jpg]]

==Test Cases for StudentTask Model, Controller and helper classes==

====Descriptive test cases====

* '''Accessing the Assignments Page'''
- Objective: Verify that the assignments page is accessible and displays all available assignments.
- Steps: Navigate to the **Assignments** tab and confirm that it loads without errors, displaying the list of assignments.

* '''Selecting an Assignment'''
- Objective: Confirm that selecting an assignment redirects the user to the detailed view.
- Steps: From the **Assignments** page, click on any assignment and verify that you are redirected to the respective **StudentTask** page for that assignment.

* '''Viewing Assignment Details'''
- Objective: Ensure that the **StudentTask** page displays assignment details, such as course, topic, and current stage.
- Steps: On the **StudentTask** page, verify the presence of fields like course, topic, and current stage, ensuring accuracy in the information displayed.

* '''Navigating "Your Work" and "Others' Work" Links'''
- Objective: Test the links to "Your Work" and "Others' Work" sections to confirm they display relevant information.
- Steps: Click the **Your Work** link to confirm it shows the student's submissions; then click the **Others' Work** link to verify it shows other students’ work or available feedback options, as applicable.

* '''Checking Review Grade Information'''
- Objective: Verify that the review grade, if available, is displayed along with any awarded badges.
- Steps: Confirm the **Review Grade** section displays either a numeric grade or "N/A" if no grade is available, and ensure any badges appear with accurate images and tooltips.

* '''Assignment Timelines and Deadline Tasks'''
- Objective: Verify that each assignment timeline and associated deadlines are listed on the StudentTask page.
- Steps: Navigate to the **Assignment Timelines** section and confirm that each task is listed in order with relevant due dates.

* '''Checking and Sending Reviewer Emails'''
- Objective: Test the "Send Email to Reviewers" feature to ensure it functions as expected.
- Steps: On the **StudentTask** page, select the **Send Email to Reviewers** option and confirm the email interface opens, allowing the student to message reviewers.

* '''Revisions and Unstarted Tasks'''
- Objective: Verify that any revisions and unstarted tasks for the assignment are displayed accurately.
- Steps: Check for sections labeled **Revisions** and **Tasks Not Yet Started**, and confirm that each section lists the student’s pending tasks correctly.

* '''Viewing Teammates and Course Association'''
- Objective: Confirm that teammates and course association are accurately displayed for assignments.
- Steps: In the **Students Who Are Teamed with You** section, ensure teammates’ names and roles are displayed. Check that the assignment shows an association with a course name if applicable, or confirms if it is not associated with any course.

====New RSpec Test Cases====

1. To check each due date of assignment:

describe '#for_each_due_date_of_assignment' do
let(:due_date_modifier) do
lambda { |dd|
{ label: (dd.deadline_type.name + ' Deadline').humanize,
updated_at: dd.due_at.strftime('%a, %d %b %Y %H:%M') }
}
end
context 'when called with assignment having empty due dates' do
it 'return empty time_list array' do
timeline_list = []
student_task_helper.for_each_due_date_of_assignment(assignment) do |due_date|
timeline_list << due_date_modifier.call(due_date)
end
expect(timeline_list).to eq([])
end
end
context 'when called with assignment having due date' do
context 'and due_at value nil' do
it 'return empty time_list array' do
allow(due_date).to receive(:deadline_type).and_return(deadline_type)
timeline_list = []
due_date.due_at = nil
assignment.due_dates = [due_date]
student_task_helper.for_each_due_date_of_assignment(assignment) { |due_date| timeline_list << due_date_modifier.call(due_date) }
expect(timeline_list).to eq([])
end
end
context 'and due_at value not nil' do
it 'return time_list array' do
allow(due_date).to receive(:deadline_type).and_return(deadline_type)
timeline_list = []
assignment.due_dates = [due_date]
student_task_helper.for_each_due_date_of_assignment(assignment) do |due_date|
timeline_list << due_date_modifier.call(due_date)
end
expect(timeline_list).to eq([{
label: (due_date.deadline_type.name + ' Deadline').humanize,
updated_at: due_date.due_at.strftime('%a, %d %b %Y %H:%M')
}])
end
end
end
end

2. To check for peer reviews

describe '#for_each_peer_review' do
context 'when no review response mapped' do
it 'returns empty' do
timeline_list = []
for_each_peer_review(user2) do |response|
timeline_list << response_modifier.call(response, "Round #{response.round} Peer Review".humanize)
end
expect(timeline_list).to eq([])
end
end
context 'when mapped to review response map' do
it 'returns timeline array' do
timeline_list = []
allow(ReviewResponseMap).to receive_message_chain(:where, :find_each).with(reviewer_id: 1).with(no_args).and_yield(review_response_map)
allow(review_response_map).to receive(:id).and_return(1)
allow(Response).to receive_message_chain(:where, :last).with(map_id: 1).with(no_args).and_return(response)
allow(response).to receive(:round).and_return(1)
allow(response).to receive(:updated_at).and_return(Time.new(2019))
timevalue = Time.new(2019).strftime('%a, %d %b %Y %H:%M')
for_each_peer_review(1) do |resp|
timeline_list << response_modifier.call(resp, "Round #{resp.round} Peer Review".humanize)
end
expect(timeline_list).to eq([{ id: 1, label: 'Round 1 peer review', updated_at: timevalue }])
end
end
end

3. To check and validate author feedbacks

describe '#for_each_author_feedback' do
context 'when no feedback response mapped' do
it 'returns empty' do
timeline_list = []
for_each_author_feedback(user2) do |response|
timeline_list << response_modifier.call(response, 'Author feedback')
end
expect(timeline_list).to eq([])
end
end
context 'when mapped to feedback response map' do
it 'returns timeline array' do
timeline_list = []
allow(FeedbackResponseMap).to receive_message_chain(:where, :find_each).with(reviewer_id: 1).with(no_args).and_yield(review_response_map)
allow(review_response_map).to receive(:id).and_return(1)
allow(Response).to receive_message_chain(:where, :last).with(map_id: 1).with(no_args).and_return(response)
allow(response).to receive(:updated_at).and_return(Time.now)
timevalue = Time.now.strftime('%a, %d %b %Y %H:%M')
timeline_list = []
for_each_author_feedback(1) do |response|
timeline_list << response_modifier.call(response, 'Author feedback')
end
expect(timeline_list).to eq([{ id: 1, label: 'Author feedback', updated_at: timevalue }])
end
end
end

4. To create and validate generated timelines

describe '#generate_timeline' do
context 'when no timeline data mapped' do
it 'returns nil' do
allow(participant).to receive(:get_reviewer).and_return(participant)
expect(student_task_helper.generate_timeline(assignment, participant)).to eq([])
end
end
end

5. Check if StudentTask obeject is created properly

describe '#create_student_task_for_participant' do
it 'creates a StudentTask with the correct attributes' do
student_task = student_task_helper.create_student_task_for_participant(participant3)
expect(student_task).to be_an_instance_of(StudentTask)
expect(student_task.participant).to eq(participant3)
expect(student_task.assignment).to eq(assignment)
expect(student_task.topic).to eq(topic)
expect(student_task.current_stage).to eq('submission')
expect(student_task.stage_deadline).to eq(Time.parse('2024-12-31 12:00:00'))
end
end

6. To check the retrieved tasks for users

describe '#retrieve_tasks_for_user' do
before do
allow(user).to receive_message_chain(:assignment_participants, :includes).and_return([participant4, participant5])
end

it 'retrieves and sorts tasks by stage_deadline' do
tasks = student_task_helper.retrieve_tasks_for_user(user)
expect(tasks.size).to eq(2)
expect(tasks.first.stage_deadline).to eq(Time.parse('2024-11-01 12:00:00'))
expect(tasks.last.stage_deadline).to eq(Time.parse('2024-12-01 12:00:00'))
end

it 'creates StudentTask objects for each participant' do
tasks = student_task_helper.retrieve_tasks_for_user(user)
tasks.each do |task|
expect(task).to be_an_instance_of(StudentTask)
expect(task.participant).to be_in([participant4, participant5])
expect(task.assignment).to eq(assignment)
expect(task.topic).to eq(topic)
end
end
end

7. To check if deadlines are parsed properly

describe '#parse_stage_deadline' do
context 'If a valid time value is given' do
it 'parse the provided time correctly' do
given_time = '2024-12-31 12:00:00'
parsed_time = student_task_helper.parse_stage_deadline(given_time)
expect(parsed_time).to eq(Time.parse(given_time))
end
end

context 'If given time string is invalid' do
it 'return current time plus 1 year' do
given_time = 'invalid-time-string'
overhead_time = Time.now + 1.year
parsed_time = student_task_helper.parse_stage_deadline(given_time)
expect(parsed_time).to be_within(1.second).of(overhead_time)
end
end
end

8. To check various conditions of users tagged as teammates

describe '#group_teammates_by_course_for_user' do
context 'when not in any team' do
it 'returns empty' do
expect(student_task_helper.group_teammates_by_course_for_user(user3)).to eq({})
end
end
context 'when assigned in a course_team ' do
it 'returns empty' do
allow(user).to receive(:teams).and_return([course_team])
expect(student_task_helper.group_teammates_by_course_for_user(user)).to eq({})
end
end
context 'when assigned in a assignment_team ' do
it 'returns the students they are teamed with' do
allow(user).to receive(:teams).and_return([team])
allow(AssignmentParticipant).to receive(:find_by).with(user_id: 1, parent_id: assignment.id).and_return(participant)
allow(AssignmentParticipant).to receive(:find_by).with(user_id: 5, parent_id: assignment.id).and_return(participant2)
allow(Assignment).to receive(:find_by).with(id: team.parent_id).and_return(assignment)
expect(student_task_helper.group_teammates_by_course_for_user(user)).to eq(assignment.course_id => [user2.fullname])
end
end
end

==Team==

====Mentor====

* Ammana, Sahithi <sammana@ncsu.edu>

====Members====

* Eathamukkala, Akarsh Reddy <aeatham@ncsu.edu>
* Koul, Anmol <akoul2@ncsu.edu>
* More, Harsh <hmore@ncsu.edu>

==References==

# [https://expertiza.ncsu.edu/ Expertiza]
# [https://docs.google.com/document/d/1fB9nHsop_yptjcj3CFn80BcZjXcSDbzcWwKvBDUTVrQ/edit?tab=t.0 OSS Projects on Expertiza]
# [https://github.com/expertiza/expertiza Github]
# [https://github.com/expertiza/expertiza/pull/2859 Pull Request]
# [http://152.7.177.54:8080/ Expertiza VCL Server]

CSC/ECE 517 Fall 2024 - E2454. Refactor student task.rb

2024-10-30T03:55:13Z

Akoul2:

==Expertiza==

Expertiza is a web application through which students can submit and peer-review learning objects (articles, code, web sites, etc).
The National Science Foundation supports the Expertiza project.
It is used in select courses at NC State and by professors at several other colleges and universities.

[http://expertiza.ncsu.edu/ Expertiza] is a [http://rubyonrails.org/ Ruby on Rails] based open source project.

==Problem Statement==

====Background====
This project focuses on refactoring the StudentTask class to improve the organization, functionality, and separation of concerns. Currently, the class contains a mix of utility and class methods, many of which are static and should be moved into helper modules or relevant model classes, or broken down into separate, more maintainable methods. The goal is to make the class more efficient and follow best practices in object-oriented programming.

The StudentTask model is a significant part of the Expertiza website which maintains and handles student data who are participants under an assignment. Each assignment has a team, individual user participant and submission deadlines. The motive here is to refactor static methods called in the student_task.rb file and move them to helper classes for better object-oriented code design.

==About StudentTask Model==
The StudentTask model handles the tracking and organizes of student assignments, encapsulating key information about a student’s current progress, deadlines, and associated tasks. It provides different functional methods for task creation, checking completion status, and timeline generation, ensuring a streamlined and detailed view of a student's assignment timelines. The model interacts closely with assignment participants and topics to display their task completion stages, reviews, and deadlines.

===Functionality===
The StudentTask model manages student assignments with the help of functional methods to initialize tasks, track deadlines, and task assessment. It includes class method from_participant, which creates a task based on a participant’s data, and from_user, that generates a sorted list of tasks by deadline for a particular user. Task status is determined through methods such as complete?, incomplete?, and started?. Additionally The revision? method checks for ongoing updates based on current stage and submissions. The model also incorporates methods (such as get_due_date_data, get_submission_data, etc.) that compile task events in chronological order, enabling a clear overview of assignment deadlines, submissions, and peer reviews. Through encapsulation, delegation, and adherence to SRP, StudentTask ensures efficient and modular task tracking aligned with the required educational processes.

==Functionality of StudentTaskHelper Module==
The StudentTaskHelper module facilitates efficient task management by handling operations such as timeline generation, teammate grouping, and task initialization for participants. It includes generate_timeline, which combines due date, peer review, and author feedback timelines, as well as create_student_task_for_participant to initialize tasks based on participant data. The module introduces iterator patterns through methods such as for_each_due_date_of_assignment, for_each_peer_review, and for_each_author_feedback, which yield data to enhance flexibility and modularity within the codebase.

Helper methods like group_teammates_by_course_for_user efficiently organize teammates by course, while methods like parse_due_date_to_timeline and parse_response_to_timeline encapsulate logic for structuring timeline events. Using private helper methods such as fetch_response_from, and utility functions like calibration_assignment? and valid_assignment_team?, StudentTaskHelper optimizes data handling, improves readability, and adheres to object-oriented design principles by reducing the need for static methods in the StudentTask model.

====Refactor====

The StudentTask model do not strictly follow the SRP and DRY principles and needed a lot of refactoring to make them more manageable in following Object-Oriented design and development.

Files modified:
* student_task.rb
* student_task_controller.rb
* student_task_helper.rb
* student_task_spec.rb
* assessment360_controller.rb
* assessment360_controller_spec.rb

New files added:
* student_task_helper_spec.rb

==Refactoring==

====self.from_participant(participant)====
Creates a StudentTask instance for a given participant, populating it with relevant assignment and stage data.

Before:

[[File:Akoul2 from participant before.jpg]]

After:

[[File:Akoul from participant after1.jpg]]

[[File:Akoul from participant after2.jpg]]

====self.from_participantid(id)====
It searches and fetches an active participant by its id.

Before:

[[File:Akoul2 from participant id before.jpg]]

After:

This method is depreciated during the refactoring process. It no longer served its purpose and was removed from the codebase.

====self.from_user(user)====
Retrieves tasks associated with a user by iterating over the user's assignment participants and sorting them by their stage deadlines.

Before:

[[File:Akoul2 from user before.jpg]]

After:

[[File:Akoul2 from user after.jpg]]

====self.get_author_feedback_data(participant_id, timeline_list)====
Generates a timeline of author feedback for a participant by mapping each feedback response through a parsing function.

Before:

[[File:Akoul2 get author feedback data before.jpg]]

After:

[[File:Akoul2 get author feedback data after.jpg]]

====self.get_due_date_data(assignment, timeline_list)====
Generates a timeline of due dates for an assignment by mapping each due date through a parsing function.

Before:

[[File:Akoul2 get due date data before.jpg]]

After:

[[File:Akoul2 get due date after.jpg]]

====self.peer_review_data(participant_id, timeline_list)====
Iterates through each peer review for a participant, yielding each review to a provided block.

Before:

[[File:Akoul2 peer review data before.jpg]]

After:

[[File:Akoul2 get peer review data after.jpg]]

====self.get_submission_data(participant_id, team_id, timeline_list)====

Before:

[[File:Akoul2 get submission data before.jpg]]

After:

This method, similar to from_participantid(), didn't showcase its usefulness during the refactoring process and was removed from the codebase.

====self.get_timeline_data(assignment, participant, _team)====
Generates a timeline of events related to the assignment for the participant, including due dates, peer reviews, and author feedback, sorted by update time.

Before:

[[File:Akoul2 get timeline data before.jpg]]

After:

[[File:Akoul2 get timeline data after.jpg]]

====self.teamed_student(user, ip_address=nil)====
Groups teammates by course for a user and returns a hash where keys are course IDs and values are lists of teammate names.

Before:

[[File:Akoul2 teamed student before.jpg]]

After:

[[File:Akoul2 teamed student after.jpg]]

Additional methods added:

[[File:Akoul2 additional methods.jpg]]

==Test Cases for StudentTask Model, Controller and helper classes==

====Descriptive test cases====

'''Test Cases:'''

* '''Accessing the Assignments Page'''
- Objective: Verify that the assignments page is accessible and displays all available assignments.
- Steps: Navigate to the **Assignments** tab and confirm that it loads without errors, displaying the list of assignments.

* '''Selecting an Assignment'''
- Objective: Confirm that selecting an assignment redirects the user to the detailed view.
- Steps: From the **Assignments** page, click on any assignment and verify that you are redirected to the respective **StudentTask** page for that assignment.

* '''Viewing Assignment Details'''
- Objective: Ensure that the **StudentTask** page displays assignment details, such as course, topic, and current stage.
- Steps: On the **StudentTask** page, verify the presence of fields like course, topic, and current stage, ensuring accuracy in the information displayed.

* '''Navigating "Your Work" and "Others' Work" Links'''
- Objective: Test the links to "Your Work" and "Others' Work" sections to confirm they display relevant information.
- Steps: Click the **Your Work** link to confirm it shows the student's submissions; then click the **Others' Work** link to verify it shows other students’ work or available feedback options, as applicable.

* '''Checking Review Grade Information'''
- Objective: Verify that the review grade, if available, is displayed along with any awarded badges.
- Steps: Confirm the **Review Grade** section displays either a numeric grade or "N/A" if no grade is available, and ensure any badges appear with accurate images and tooltips.

* '''Assignment Timelines and Deadline Tasks'''
- Objective: Verify that each assignment timeline and associated deadlines are listed on the StudentTask page.
- Steps: Navigate to the **Assignment Timelines** section and confirm that each task is listed in order with relevant due dates.

* '''Checking and Sending Reviewer Emails'''
- Objective: Test the "Send Email to Reviewers" feature to ensure it functions as expected.
- Steps: On the **StudentTask** page, select the **Send Email to Reviewers** option and confirm the email interface opens, allowing the student to message reviewers.

* '''Revisions and Unstarted Tasks'''
- Objective: Verify that any revisions and unstarted tasks for the assignment are displayed accurately.
- Steps: Check for sections labeled **Revisions** and **Tasks Not Yet Started**, and confirm that each section lists the student’s pending tasks correctly.

* '''Viewing Teammates and Course Association'''
- Objective: Confirm that teammates and course association are accurately displayed for assignments.
- Steps: In the **Students Who Are Teamed with You** section, ensure teammates’ names and roles are displayed. Check that the assignment shows an association with a course name if applicable, or confirms if it is not associated with any course.

====New RSpec Test Cases====

1. To check each due date of assignment:

describe '#for_each_due_date_of_assignment' do
let(:due_date_modifier) do
lambda { |dd|
{ label: (dd.deadline_type.name + ' Deadline').humanize,
updated_at: dd.due_at.strftime('%a, %d %b %Y %H:%M') }
}
end
context 'when called with assignment having empty due dates' do
it 'return empty time_list array' do
timeline_list = []
student_task_helper.for_each_due_date_of_assignment(assignment) do |due_date|
timeline_list << due_date_modifier.call(due_date)
end
expect(timeline_list).to eq([])
end
end
context 'when called with assignment having due date' do
context 'and due_at value nil' do
it 'return empty time_list array' do
allow(due_date).to receive(:deadline_type).and_return(deadline_type)
timeline_list = []
due_date.due_at = nil
assignment.due_dates = [due_date]
student_task_helper.for_each_due_date_of_assignment(assignment) { |due_date| timeline_list << due_date_modifier.call(due_date) }
expect(timeline_list).to eq([])
end
end
context 'and due_at value not nil' do
it 'return time_list array' do
allow(due_date).to receive(:deadline_type).and_return(deadline_type)
timeline_list = []
assignment.due_dates = [due_date]
student_task_helper.for_each_due_date_of_assignment(assignment) do |due_date|
timeline_list << due_date_modifier.call(due_date)
end
expect(timeline_list).to eq([{
label: (due_date.deadline_type.name + ' Deadline').humanize,
updated_at: due_date.due_at.strftime('%a, %d %b %Y %H:%M')
}])
end
end
end
end

2. To check for peer reviews

describe '#for_each_peer_review' do
context 'when no review response mapped' do
it 'returns empty' do
timeline_list = []
for_each_peer_review(user2) do |response|
timeline_list << response_modifier.call(response, "Round #{response.round} Peer Review".humanize)
end
expect(timeline_list).to eq([])
end
end
context 'when mapped to review response map' do
it 'returns timeline array' do
timeline_list = []
allow(ReviewResponseMap).to receive_message_chain(:where, :find_each).with(reviewer_id: 1).with(no_args).and_yield(review_response_map)
allow(review_response_map).to receive(:id).and_return(1)
allow(Response).to receive_message_chain(:where, :last).with(map_id: 1).with(no_args).and_return(response)
allow(response).to receive(:round).and_return(1)
allow(response).to receive(:updated_at).and_return(Time.new(2019))
timevalue = Time.new(2019).strftime('%a, %d %b %Y %H:%M')
for_each_peer_review(1) do |resp|
timeline_list << response_modifier.call(resp, "Round #{resp.round} Peer Review".humanize)
end
expect(timeline_list).to eq([{ id: 1, label: 'Round 1 peer review', updated_at: timevalue }])
end
end
end

3. To check and validate author feedbacks

describe '#for_each_author_feedback' do
context 'when no feedback response mapped' do
it 'returns empty' do
timeline_list = []
for_each_author_feedback(user2) do |response|
timeline_list << response_modifier.call(response, 'Author feedback')
end
expect(timeline_list).to eq([])
end
end
context 'when mapped to feedback response map' do
it 'returns timeline array' do
timeline_list = []
allow(FeedbackResponseMap).to receive_message_chain(:where, :find_each).with(reviewer_id: 1).with(no_args).and_yield(review_response_map)
allow(review_response_map).to receive(:id).and_return(1)
allow(Response).to receive_message_chain(:where, :last).with(map_id: 1).with(no_args).and_return(response)
allow(response).to receive(:updated_at).and_return(Time.now)
timevalue = Time.now.strftime('%a, %d %b %Y %H:%M')
timeline_list = []
for_each_author_feedback(1) do |response|
timeline_list << response_modifier.call(response, 'Author feedback')
end
expect(timeline_list).to eq([{ id: 1, label: 'Author feedback', updated_at: timevalue }])
end
end
end

4. To create and validate generated timelines

describe '#generate_timeline' do
context 'when no timeline data mapped' do
it 'returns nil' do
allow(participant).to receive(:get_reviewer).and_return(participant)
expect(student_task_helper.generate_timeline(assignment, participant)).to eq([])
end
end
end

5. Check if StudentTask obeject is created properly

describe '#create_student_task_for_participant' do
it 'creates a StudentTask with the correct attributes' do
student_task = student_task_helper.create_student_task_for_participant(participant3)
expect(student_task).to be_an_instance_of(StudentTask)
expect(student_task.participant).to eq(participant3)
expect(student_task.assignment).to eq(assignment)
expect(student_task.topic).to eq(topic)
expect(student_task.current_stage).to eq('submission')
expect(student_task.stage_deadline).to eq(Time.parse('2024-12-31 12:00:00'))
end
end

6. To check the retrieved tasks for users

describe '#retrieve_tasks_for_user' do
before do
allow(user).to receive_message_chain(:assignment_participants, :includes).and_return([participant4, participant5])
end

it 'retrieves and sorts tasks by stage_deadline' do
tasks = student_task_helper.retrieve_tasks_for_user(user)
expect(tasks.size).to eq(2)
expect(tasks.first.stage_deadline).to eq(Time.parse('2024-11-01 12:00:00'))
expect(tasks.last.stage_deadline).to eq(Time.parse('2024-12-01 12:00:00'))
end

it 'creates StudentTask objects for each participant' do
tasks = student_task_helper.retrieve_tasks_for_user(user)
tasks.each do |task|
expect(task).to be_an_instance_of(StudentTask)
expect(task.participant).to be_in([participant4, participant5])
expect(task.assignment).to eq(assignment)
expect(task.topic).to eq(topic)
end
end
end

7. To check if deadlines are parsed properly

describe '#parse_stage_deadline' do
context 'If a valid time value is given' do
it 'parse the provided time correctly' do
given_time = '2024-12-31 12:00:00'
parsed_time = student_task_helper.parse_stage_deadline(given_time)
expect(parsed_time).to eq(Time.parse(given_time))
end
end

context 'If given time string is invalid' do
it 'return current time plus 1 year' do
given_time = 'invalid-time-string'
overhead_time = Time.now + 1.year
parsed_time = student_task_helper.parse_stage_deadline(given_time)
expect(parsed_time).to be_within(1.second).of(overhead_time)
end
end
end

8. To check various conditions of users tagged as teammates

describe '#group_teammates_by_course_for_user' do
context 'when not in any team' do
it 'returns empty' do
expect(student_task_helper.group_teammates_by_course_for_user(user3)).to eq({})
end
end
context 'when assigned in a course_team ' do
it 'returns empty' do
allow(user).to receive(:teams).and_return([course_team])
expect(student_task_helper.group_teammates_by_course_for_user(user)).to eq({})
end
end
context 'when assigned in a assignment_team ' do
it 'returns the students they are teamed with' do
allow(user).to receive(:teams).and_return([team])
allow(AssignmentParticipant).to receive(:find_by).with(user_id: 1, parent_id: assignment.id).and_return(participant)
allow(AssignmentParticipant).to receive(:find_by).with(user_id: 5, parent_id: assignment.id).and_return(participant2)
allow(Assignment).to receive(:find_by).with(id: team.parent_id).and_return(assignment)
expect(student_task_helper.group_teammates_by_course_for_user(user)).to eq(assignment.course_id => [user2.fullname])
end
end
end

==Team==

====Mentor====

* Ammana, Sahithi <sammana@ncsu.edu>

====Members====

* Eathamukkala, Akarsh Reddy <aeatham@ncsu.edu>
* Koul, Anmol <akoul2@ncsu.edu>
* More, Harsh <hmore@ncsu.edu>

==References==

# [https://expertiza.ncsu.edu/ Expertiza]
# [https://docs.google.com/document/d/1fB9nHsop_yptjcj3CFn80BcZjXcSDbzcWwKvBDUTVrQ/edit?tab=t.0 OSS Projects on Expertiza]
# [https://github.com/expertiza/expertiza Github]
# [https://github.com/expertiza/expertiza/pull/2859 Pull Request]
# [http://152.7.177.54:8080/ Expertiza VCL Server]

CSC/ECE 517 Fall 2024 - E2454. Refactor student task.rb

2024-10-30T03:34:57Z

Akoul2:

==Expertiza==

Expertiza is a web application through which students can submit and peer-review learning objects (articles, code, web sites, etc).
The National Science Foundation supports the Expertiza project.
It is used in select courses at NC State and by professors at several other colleges and universities.

[http://expertiza.ncsu.edu/ Expertiza] is a [http://rubyonrails.org/ Ruby on Rails] based open source project.

==Problem Statement==

====Background====
This project focuses on refactoring the StudentTask class to improve the organization, functionality, and separation of concerns. Currently, the class contains a mix of utility and class methods, many of which are static and should be moved into helper modules or relevant model classes, or broken down into separate, more maintainable methods. The goal is to make the class more efficient and follow best practices in object-oriented programming.

The StudentTask model is a significant part of the Expertiza website which maintains and handles student data who are participants under an assignment. Each assignment has a team, individual user participant and submission deadlines. The motive here is to refactor static methods called in the student_task.rb file and move them to helper classes for better object-oriented code design.

==About StudentTask Model==
The StudentTask model handles the tracking and organizes of student assignments, encapsulating key information about a student’s current progress, deadlines, and associated tasks. It provides different functional methods for task creation, checking completion status, and timeline generation, ensuring a streamlined and detailed view of a student's assignment timelines. The model interacts closely with assignment participants and topics to display their task completion stages, reviews, and deadlines.

===Functionality===
The StudentTask model manages student assignments with the help of functional methods to initialize tasks, track deadlines, and task assessment. It includes class method from_participant, which creates a task based on a participant’s data, and from_user, that generates a sorted list of tasks by deadline for a particular user. Task status is determined through methods such as complete?, incomplete?, and started?. Additionally The revision? method checks for ongoing updates based on current stage and submissions. The model also incorporates methods (such as get_due_date_data, get_submission_data, etc.) that compile task events in chronological order, enabling a clear overview of assignment deadlines, submissions, and peer reviews. Through encapsulation, delegation, and adherence to SRP, StudentTask ensures efficient and modular task tracking aligned with the required educational processes.

==Functionality of StudentTaskHelper Module==
The StudentTaskHelper module facilitates efficient task management by handling operations such as timeline generation, teammate grouping, and task initialization for participants. It includes generate_timeline, which combines due date, peer review, and author feedback timelines, as well as create_student_task_for_participant to initialize tasks based on participant data. The module introduces iterator patterns through methods such as for_each_due_date_of_assignment, for_each_peer_review, and for_each_author_feedback, which yield data to enhance flexibility and modularity within the codebase.

Helper methods like group_teammates_by_course_for_user efficiently organize teammates by course, while methods like parse_due_date_to_timeline and parse_response_to_timeline encapsulate logic for structuring timeline events. Using private helper methods such as fetch_response_from, and utility functions like calibration_assignment? and valid_assignment_team?, StudentTaskHelper optimizes data handling, improves readability, and adheres to object-oriented design principles by reducing the need for static methods in the StudentTask model.

====Refactor====

The StudentTask model do not strictly follow the SRP and DRY principles and needed a lot of refactoring to make them more manageable in following Object-Oriented design and development.

Files modified:
* student_task.rb
* student_task_controller.rb
* student_task_helper.rb
* student_task_spec.rb
* assessment360_controller.rb
* assessment360_controller_spec.rb

New files added:
* student_task_helper_spec.rb

==Refactoring==

====self.from_participant(participant)====
Creates a StudentTask instance for a given participant, populating it with relevant assignment and stage data.

Before:

[[File:Akoul2 from participant before.jpg]]

After:

[[File:Akoul from participant after1.jpg]]

[[File:Akoul from participant after2.jpg]]

====self.from_participantid(id)====
It searches and fetches an active participant by its id.

Before:

[[File:Akoul2 from participant id before.jpg]]

After:

This method is depreciated during the refactoring process. It no longer served its purpose and was removed from the codebase.

====self.from_user(user)====
Retrieves tasks associated with a user by iterating over the user's assignment participants and sorting them by their stage deadlines.

Before:

[[File:Akoul2 from user before.jpg]]

After:

[[File:Akoul2 from user after.jpg]]

====self.get_author_feedback_data(participant_id, timeline_list)====
Generates a timeline of author feedback for a participant by mapping each feedback response through a parsing function.

Before:

[[File:Akoul2 get author feedback data before.jpg]]

After:

[[File:Akoul2 get author feedback data after.jpg]]

====self.get_due_date_data(assignment, timeline_list)====
Generates a timeline of due dates for an assignment by mapping each due date through a parsing function.

Before:

[[File:Akoul2 get due date data before.jpg]]

After:

[[File:Akoul2 get due date after.jpg]]

====self.peer_review_data(participant_id, timeline_list)====
Iterates through each peer review for a participant, yielding each review to a provided block.

Before:

[[File:Akoul2 peer review data before.jpg]]

After:

[[File:Akoul2 get peer review data after.jpg]]

====self.get_submission_data(participant_id, team_id, timeline_list)====

Before:

[[File:Akoul2 get submission data before.jpg]]

After:

This method, similar to from_participantid(), didn't showcase its usefulness during the refactoring process and was removed from the codebase.

====self.get_timeline_data(assignment, participant, _team)====
Generates a timeline of events related to the assignment for the participant, including due dates, peer reviews, and author feedback, sorted by update time.

Before:

[[File:Akoul2 get timeline data before.jpg]]

After:

[[File:Akoul2 get timeline data after.jpg]]

====self.teamed_student(user, ip_address=nil)====
Groups teammates by course for a user and returns a hash where keys are course IDs and values are lists of teammate names.

Before:

[[File:Akoul2 teamed student before.jpg]]

After:

[[File:Akoul2 teamed student after.jpg]]

Additional methods added:

[[File:Akoul2 additional methods.jpg]]

==Test Cases for StudentTask Model, Controller and helper classes==

====New Test Cases====

1. To check each due date of assignment:

describe '#for_each_due_date_of_assignment' do
let(:due_date_modifier) do
lambda { |dd|
{ label: (dd.deadline_type.name + ' Deadline').humanize,
updated_at: dd.due_at.strftime('%a, %d %b %Y %H:%M') }
}
end
context 'when called with assignment having empty due dates' do
it 'return empty time_list array' do
timeline_list = []
student_task_helper.for_each_due_date_of_assignment(assignment) do |due_date|
timeline_list << due_date_modifier.call(due_date)
end
expect(timeline_list).to eq([])
end
end
context 'when called with assignment having due date' do
context 'and due_at value nil' do
it 'return empty time_list array' do
allow(due_date).to receive(:deadline_type).and_return(deadline_type)
timeline_list = []
due_date.due_at = nil
assignment.due_dates = [due_date]
student_task_helper.for_each_due_date_of_assignment(assignment) { |due_date| timeline_list << due_date_modifier.call(due_date) }
expect(timeline_list).to eq([])
end
end
context 'and due_at value not nil' do
it 'return time_list array' do
allow(due_date).to receive(:deadline_type).and_return(deadline_type)
timeline_list = []
assignment.due_dates = [due_date]
student_task_helper.for_each_due_date_of_assignment(assignment) do |due_date|
timeline_list << due_date_modifier.call(due_date)
end
expect(timeline_list).to eq([{
label: (due_date.deadline_type.name + ' Deadline').humanize,
updated_at: due_date.due_at.strftime('%a, %d %b %Y %H:%M')
}])
end
end
end
end

2. To check for peer reviews

describe '#for_each_peer_review' do
context 'when no review response mapped' do
it 'returns empty' do
timeline_list = []
for_each_peer_review(user2) do |response|
timeline_list << response_modifier.call(response, "Round #{response.round} Peer Review".humanize)
end
expect(timeline_list).to eq([])
end
end
context 'when mapped to review response map' do
it 'returns timeline array' do
timeline_list = []
allow(ReviewResponseMap).to receive_message_chain(:where, :find_each).with(reviewer_id: 1).with(no_args).and_yield(review_response_map)
allow(review_response_map).to receive(:id).and_return(1)
allow(Response).to receive_message_chain(:where, :last).with(map_id: 1).with(no_args).and_return(response)
allow(response).to receive(:round).and_return(1)
allow(response).to receive(:updated_at).and_return(Time.new(2019))
timevalue = Time.new(2019).strftime('%a, %d %b %Y %H:%M')
for_each_peer_review(1) do |resp|
timeline_list << response_modifier.call(resp, "Round #{resp.round} Peer Review".humanize)
end
expect(timeline_list).to eq([{ id: 1, label: 'Round 1 peer review', updated_at: timevalue }])
end
end
end

3. To check and validate author feedbacks

describe '#for_each_author_feedback' do
context 'when no feedback response mapped' do
it 'returns empty' do
timeline_list = []
for_each_author_feedback(user2) do |response|
timeline_list << response_modifier.call(response, 'Author feedback')
end
expect(timeline_list).to eq([])
end
end
context 'when mapped to feedback response map' do
it 'returns timeline array' do
timeline_list = []
allow(FeedbackResponseMap).to receive_message_chain(:where, :find_each).with(reviewer_id: 1).with(no_args).and_yield(review_response_map)
allow(review_response_map).to receive(:id).and_return(1)
allow(Response).to receive_message_chain(:where, :last).with(map_id: 1).with(no_args).and_return(response)
allow(response).to receive(:updated_at).and_return(Time.now)
timevalue = Time.now.strftime('%a, %d %b %Y %H:%M')
timeline_list = []
for_each_author_feedback(1) do |response|
timeline_list << response_modifier.call(response, 'Author feedback')
end
expect(timeline_list).to eq([{ id: 1, label: 'Author feedback', updated_at: timevalue }])
end
end
end

4. To create and validate generated timelines

describe '#generate_timeline' do
context 'when no timeline data mapped' do
it 'returns nil' do
allow(participant).to receive(:get_reviewer).and_return(participant)
expect(student_task_helper.generate_timeline(assignment, participant)).to eq([])
end
end
end

5. Check if StudentTask obeject is created properly

describe '#create_student_task_for_participant' do
it 'creates a StudentTask with the correct attributes' do
student_task = student_task_helper.create_student_task_for_participant(participant3)
expect(student_task).to be_an_instance_of(StudentTask)
expect(student_task.participant).to eq(participant3)
expect(student_task.assignment).to eq(assignment)
expect(student_task.topic).to eq(topic)
expect(student_task.current_stage).to eq('submission')
expect(student_task.stage_deadline).to eq(Time.parse('2024-12-31 12:00:00'))
end
end

6. To check the retrieved tasks for users

describe '#retrieve_tasks_for_user' do
before do
allow(user).to receive_message_chain(:assignment_participants, :includes).and_return([participant4, participant5])
end

it 'retrieves and sorts tasks by stage_deadline' do
tasks = student_task_helper.retrieve_tasks_for_user(user)
expect(tasks.size).to eq(2)
expect(tasks.first.stage_deadline).to eq(Time.parse('2024-11-01 12:00:00'))
expect(tasks.last.stage_deadline).to eq(Time.parse('2024-12-01 12:00:00'))
end

it 'creates StudentTask objects for each participant' do
tasks = student_task_helper.retrieve_tasks_for_user(user)
tasks.each do |task|
expect(task).to be_an_instance_of(StudentTask)
expect(task.participant).to be_in([participant4, participant5])
expect(task.assignment).to eq(assignment)
expect(task.topic).to eq(topic)
end
end
end

7. To check if deadlines are parsed properly

describe '#parse_stage_deadline' do
context 'If a valid time value is given' do
it 'parse the provided time correctly' do
given_time = '2024-12-31 12:00:00'
parsed_time = student_task_helper.parse_stage_deadline(given_time)
expect(parsed_time).to eq(Time.parse(given_time))
end
end

context 'If given time string is invalid' do
it 'return current time plus 1 year' do
given_time = 'invalid-time-string'
overhead_time = Time.now + 1.year
parsed_time = student_task_helper.parse_stage_deadline(given_time)
expect(parsed_time).to be_within(1.second).of(overhead_time)
end
end
end

8. To check various conditions of users tagged as teammates

describe '#group_teammates_by_course_for_user' do
context 'when not in any team' do
it 'returns empty' do
expect(student_task_helper.group_teammates_by_course_for_user(user3)).to eq({})
end
end
context 'when assigned in a course_team ' do
it 'returns empty' do
allow(user).to receive(:teams).and_return([course_team])
expect(student_task_helper.group_teammates_by_course_for_user(user)).to eq({})
end
end
context 'when assigned in a assignment_team ' do
it 'returns the students they are teamed with' do
allow(user).to receive(:teams).and_return([team])
allow(AssignmentParticipant).to receive(:find_by).with(user_id: 1, parent_id: assignment.id).and_return(participant)
allow(AssignmentParticipant).to receive(:find_by).with(user_id: 5, parent_id: assignment.id).and_return(participant2)
allow(Assignment).to receive(:find_by).with(id: team.parent_id).and_return(assignment)
expect(student_task_helper.group_teammates_by_course_for_user(user)).to eq(assignment.course_id => [user2.fullname])
end
end
end

==Team==

====Mentor====

* Ammana, Sahithi <sammana@ncsu.edu>

====Members====

* Eathamukkala, Akarsh Reddy <aeatham@ncsu.edu>
* Koul, Anmol <akoul2@ncsu.edu>
* More, Harsh <hmore@ncsu.edu>

==References==

# [https://expertiza.ncsu.edu/ Expertiza]
# [https://docs.google.com/document/d/1fB9nHsop_yptjcj3CFn80BcZjXcSDbzcWwKvBDUTVrQ/edit?tab=t.0 OSS Projects on Expertiza]
# [https://github.com/expertiza/expertiza Github]
# [https://github.com/expertiza/expertiza/pull/2859 Pull Request]
# [http://152.7.177.54:8080/ Expertiza VCL Server]

CSC/ECE 517 Fall 2024 - E2454. Refactor student task.rb

2024-10-30T03:33:51Z

Akoul2: /* self.peer_review_data(participant_id, timeline_list) */

==Expertiza==

Expertiza is a web application through which students can submit and peer-review learning objects (articles, code, web sites, etc).
The National Science Foundation supports the Expertiza project.
It is used in select courses at NC State and by professors at several other colleges and universities.

[http://expertiza.ncsu.edu/ Expertiza] is a [http://rubyonrails.org/ Ruby on Rails] based open source project.

==Problem Statement==

====Background====
This project focuses on refactoring the StudentTask class to improve the organization, functionality, and separation of concerns. Currently, the class contains a mix of utility and class methods, many of which are static and should be moved into helper modules or relevant model classes, or broken down into separate, more maintainable methods. The goal is to make the class more efficient and follow best practices in object-oriented programming.

The StudentTask model is a significant part of the Expertiza website which maintains and handles student data who are participants under an assignment. Each assignment has a team, individual user participant and submission deadlines. The motive here is to refactor static methods called in the student_task.rb file and move them to helper classes for better object-oriented code design.

==About StudentTask Model==
The StudentTask model handles the tracking and organizes of student assignments, encapsulating key information about a student’s current progress, deadlines, and associated tasks. It provides different functional methods for task creation, checking completion status, and timeline generation, ensuring a streamlined and detailed view of a student's assignment timelines. The model interacts closely with assignment participants and topics to display their task completion stages, reviews, and deadlines.

===Functionality===
The StudentTask model manages student assignments with the help of functional methods to initialize tasks, track deadlines, and task assessment. It includes class method from_participant, which creates a task based on a participant’s data, and from_user, that generates a sorted list of tasks by deadline for a particular user. Task status is determined through methods such as complete?, incomplete?, and started?. Additionally The revision? method checks for ongoing updates based on current stage and submissions. The model also incorporates methods (such as get_due_date_data, get_submission_data, etc.) that compile task events in chronological order, enabling a clear overview of assignment deadlines, submissions, and peer reviews. Through encapsulation, delegation, and adherence to SRP, StudentTask ensures efficient and modular task tracking aligned with the required educational processes.

==Functionality of StudentTaskHelper Module==
The StudentTaskHelper module facilitates efficient task management by handling operations such as timeline generation, teammate grouping, and task initialization for participants. It includes generate_timeline, which combines due date, peer review, and author feedback timelines, as well as create_student_task_for_participant to initialize tasks based on participant data. The module introduces iterator patterns through methods such as for_each_due_date_of_assignment, for_each_peer_review, and for_each_author_feedback, which yield data to enhance flexibility and modularity within the codebase.

Helper methods like group_teammates_by_course_for_user efficiently organize teammates by course, while methods like parse_due_date_to_timeline and parse_response_to_timeline encapsulate logic for structuring timeline events. Using private helper methods such as fetch_response_from, and utility functions like calibration_assignment? and valid_assignment_team?, StudentTaskHelper optimizes data handling, improves readability, and adheres to object-oriented design principles by reducing the need for static methods in the StudentTask model.

====Refactor====

The StudentTask model do not strictly follow the SRP and DRY principles and needed a lot of refactoring to make them more manageable in following Object-Oriented design and development.

Files modified:
* student_task.rb
* student_task_controller.rb
* student_task_helper.rb
* student_task_spec.rb
* assessment360_controller.rb
* assessment360_controller_spec.rb

New files added:
* student_task_helper_spec.rb

==Refactoring==

====self.from_participant(participant)====
Creates a StudentTask instance for a given participant, populating it with relevant assignment and stage data.

Before:

[[File:Akoul2 from participant before.jpg]]

After:

[[File:Akoul from participant after1.jpg]]

[[File:Akoul from participant after2.jpg]]

====self.from_participantid(id)====
It searches and fetches an active participant by its id.

Before:

[[File:Akoul2 from participant id before.jpg]]

After:

This method is depreciated during the refactoring process. It no longer served its purpose and was removed from the codebase.

====self.from_user(user)====
Retrieves tasks associated with a user by iterating over the user's assignment participants and sorting them by their stage deadlines.

Before:

[[File:Akoul2 from user before.jpg]]

After:

[[File:Akoul2 from user after.jpg]]

====self.get_author_feedback_data(participant_id, timeline_list)====
Generates a timeline of author feedback for a participant by mapping each feedback response through a parsing function.

Before:

[[File:Akoul2 get author feedback data before.jpg]]

After:

[[File:Akoul2 get author feedback data after.jpg]]

====self.get_due_date_data(assignment, timeline_list)====
Generates a timeline of due dates for an assignment by mapping each due date through a parsing function.

Before:

[[File:Akoul2 get due date data before.jpg]]

After:

[[File:Akoul2 get due date after.jpg]]

====self.peer_review_data(participant_id, timeline_list)====
Iterates through each peer review for a participant, yielding each review to a provided block.

Before:

[[File:Akoul2 peer review data before.jpg]]

After:

[[File:Akoul2 get peer review data after.jpg]]

====self.get_submission_data(participant_id, team_id, timeline_list)====

Before:

[[File:Akoul2 get submission data before.jpg]]

After:

This method, similar to from_participantid(), didn't showcase its usefulness during the refactoring process and was removed from the codebase.

====self.get_timeline_data(assignment, participant, _team)====
Generates a timeline of events related to the assignment for the participant, including due dates, peer reviews, and author feedback, sorted by update time.

Before:

[[File:Akoul2 get timeline data before.jpg]]

After:

[[File:Akoul2 get timeline data after.jpg]]

====self.teamed_student(user, ip_address=nil)====
Groups teammates by course for a user and returns a hash where keys are course IDs and values are lists of teammate names.

Before:

[[File:Akoul2 teamed student before.jpg]]

After:

[[File:Akoul2 teamed student after.jpg]]

Additional methods added:

[[File:Akoul2 additional methods.jpg]]

==Test Cases for StudentTask Model, Controller and helper classes==

====New Test Cases====

1. To check each due date of assignment:

describe '#for_each_due_date_of_assignment' do
let(:due_date_modifier) do
lambda { |dd|
{ label: (dd.deadline_type.name + ' Deadline').humanize,
updated_at: dd.due_at.strftime('%a, %d %b %Y %H:%M') }
}
end
context 'when called with assignment having empty due dates' do
it 'return empty time_list array' do
timeline_list = []
student_task_helper.for_each_due_date_of_assignment(assignment) do |due_date|
timeline_list << due_date_modifier.call(due_date)
end
expect(timeline_list).to eq([])
end
end
context 'when called with assignment having due date' do
context 'and due_at value nil' do
it 'return empty time_list array' do
allow(due_date).to receive(:deadline_type).and_return(deadline_type)
timeline_list = []
due_date.due_at = nil
assignment.due_dates = [due_date]
student_task_helper.for_each_due_date_of_assignment(assignment) { |due_date| timeline_list << due_date_modifier.call(due_date) }
expect(timeline_list).to eq([])
end
end
context 'and due_at value not nil' do
it 'return time_list array' do
allow(due_date).to receive(:deadline_type).and_return(deadline_type)
timeline_list = []
assignment.due_dates = [due_date]
student_task_helper.for_each_due_date_of_assignment(assignment) do |due_date|
timeline_list << due_date_modifier.call(due_date)
end
expect(timeline_list).to eq([{
label: (due_date.deadline_type.name + ' Deadline').humanize,
updated_at: due_date.due_at.strftime('%a, %d %b %Y %H:%M')
}])
end
end
end
end

2. To check for peer reviews

describe '#for_each_peer_review' do
context 'when no review response mapped' do
it 'returns empty' do
timeline_list = []
for_each_peer_review(user2) do |response|
timeline_list << response_modifier.call(response, "Round #{response.round} Peer Review".humanize)
end
expect(timeline_list).to eq([])
end
end
context 'when mapped to review response map' do
it 'returns timeline array' do
timeline_list = []
allow(ReviewResponseMap).to receive_message_chain(:where, :find_each).with(reviewer_id: 1).with(no_args).and_yield(review_response_map)
allow(review_response_map).to receive(:id).and_return(1)
allow(Response).to receive_message_chain(:where, :last).with(map_id: 1).with(no_args).and_return(response)
allow(response).to receive(:round).and_return(1)
allow(response).to receive(:updated_at).and_return(Time.new(2019))
timevalue = Time.new(2019).strftime('%a, %d %b %Y %H:%M')
for_each_peer_review(1) do |resp|
timeline_list << response_modifier.call(resp, "Round #{resp.round} Peer Review".humanize)
end
expect(timeline_list).to eq([{ id: 1, label: 'Round 1 peer review', updated_at: timevalue }])
end
end
end

3. To check and validate author feedbacks

describe '#for_each_author_feedback' do
context 'when no feedback response mapped' do
it 'returns empty' do
timeline_list = []
for_each_author_feedback(user2) do |response|
timeline_list << response_modifier.call(response, 'Author feedback')
end
expect(timeline_list).to eq([])
end
end
context 'when mapped to feedback response map' do
it 'returns timeline array' do
timeline_list = []
allow(FeedbackResponseMap).to receive_message_chain(:where, :find_each).with(reviewer_id: 1).with(no_args).and_yield(review_response_map)
allow(review_response_map).to receive(:id).and_return(1)
allow(Response).to receive_message_chain(:where, :last).with(map_id: 1).with(no_args).and_return(response)
allow(response).to receive(:updated_at).and_return(Time.now)
timevalue = Time.now.strftime('%a, %d %b %Y %H:%M')
timeline_list = []
for_each_author_feedback(1) do |response|
timeline_list << response_modifier.call(response, 'Author feedback')
end
expect(timeline_list).to eq([{ id: 1, label: 'Author feedback', updated_at: timevalue }])
end
end
end

4. To create and validate generated timelines

describe '#generate_timeline' do
context 'when no timeline data mapped' do
it 'returns nil' do
allow(participant).to receive(:get_reviewer).and_return(participant)
expect(student_task_helper.generate_timeline(assignment, participant)).to eq([])
end
end
end

5. Check if StudentTask obeject is created properly

describe '#create_student_task_for_participant' do
it 'creates a StudentTask with the correct attributes' do
student_task = student_task_helper.create_student_task_for_participant(participant3)
expect(student_task).to be_an_instance_of(StudentTask)
expect(student_task.participant).to eq(participant3)
expect(student_task.assignment).to eq(assignment)
expect(student_task.topic).to eq(topic)
expect(student_task.current_stage).to eq('submission')
expect(student_task.stage_deadline).to eq(Time.parse('2024-12-31 12:00:00'))
end
end

6. To check the retrieved tasks for users

describe '#retrieve_tasks_for_user' do
before do
allow(user).to receive_message_chain(:assignment_participants, :includes).and_return([participant4, participant5])
end

it 'retrieves and sorts tasks by stage_deadline' do
tasks = student_task_helper.retrieve_tasks_for_user(user)
expect(tasks.size).to eq(2)
expect(tasks.first.stage_deadline).to eq(Time.parse('2024-11-01 12:00:00'))
expect(tasks.last.stage_deadline).to eq(Time.parse('2024-12-01 12:00:00'))
end

it 'creates StudentTask objects for each participant' do
tasks = student_task_helper.retrieve_tasks_for_user(user)
tasks.each do |task|
expect(task).to be_an_instance_of(StudentTask)
expect(task.participant).to be_in([participant4, participant5])
expect(task.assignment).to eq(assignment)
expect(task.topic).to eq(topic)
end
end
end

7. To check if deadlines are parsed properly

describe '#parse_stage_deadline' do
context 'If a valid time value is given' do
it 'parse the provided time correctly' do
given_time = '2024-12-31 12:00:00'
parsed_time = student_task_helper.parse_stage_deadline(given_time)
expect(parsed_time).to eq(Time.parse(given_time))
end
end

context 'If given time string is invalid' do
it 'return current time plus 1 year' do
given_time = 'invalid-time-string'
overhead_time = Time.now + 1.year
parsed_time = student_task_helper.parse_stage_deadline(given_time)
expect(parsed_time).to be_within(1.second).of(overhead_time)
end
end
end

8. To check various conditions of users tagged as teammates

describe '#group_teammates_by_course_for_user' do
context 'when not in any team' do
it 'returns empty' do
expect(student_task_helper.group_teammates_by_course_for_user(user3)).to eq({})
end
end
context 'when assigned in a course_team ' do
it 'returns empty' do
allow(user).to receive(:teams).and_return([course_team])
expect(student_task_helper.group_teammates_by_course_for_user(user)).to eq({})
end
end
context 'when assigned in a assignment_team ' do
it 'returns the students they are teamed with' do
allow(user).to receive(:teams).and_return([team])
allow(AssignmentParticipant).to receive(:find_by).with(user_id: 1, parent_id: assignment.id).and_return(participant)
allow(AssignmentParticipant).to receive(:find_by).with(user_id: 5, parent_id: assignment.id).and_return(participant2)
allow(Assignment).to receive(:find_by).with(id: team.parent_id).and_return(assignment)
expect(student_task_helper.group_teammates_by_course_for_user(user)).to eq(assignment.course_id => [user2.fullname])
end
end
end

==Next Steps==
We are yet to discuss the scope of this project and whether it can be extended to other functionalities in Expertiza.

==Team==

====Mentor====

* Ammana, Sahithi <sammana@ncsu.edu>

====Members====

* Eathamukkala, Akarsh Reddy <aeatham@ncsu.edu>
* Koul, Anmol <akoul2@ncsu.edu>
* More, Harsh <hmore@ncsu.edu>

==References==

# [https://expertiza.ncsu.edu/ Expertiza]
# [https://docs.google.com/document/d/1fB9nHsop_yptjcj3CFn80BcZjXcSDbzcWwKvBDUTVrQ/edit?tab=t.0 OSS Projects on Expertiza]
# [https://github.com/expertiza/expertiza Github]
# [https://github.com/expertiza/expertiza/pull/2859 Pull Request]
# [http://152.7.177.54:8080/ Expertiza VCL Server]

CSC/ECE 517 Fall 2024 - E2454. Refactor student task.rb

2024-10-30T03:32:33Z

Akoul2: /* Refactoring */

==Expertiza==

Expertiza is a web application through which students can submit and peer-review learning objects (articles, code, web sites, etc).
The National Science Foundation supports the Expertiza project.
It is used in select courses at NC State and by professors at several other colleges and universities.

[http://expertiza.ncsu.edu/ Expertiza] is a [http://rubyonrails.org/ Ruby on Rails] based open source project.

==Problem Statement==

====Background====
This project focuses on refactoring the StudentTask class to improve the organization, functionality, and separation of concerns. Currently, the class contains a mix of utility and class methods, many of which are static and should be moved into helper modules or relevant model classes, or broken down into separate, more maintainable methods. The goal is to make the class more efficient and follow best practices in object-oriented programming.

The StudentTask model is a significant part of the Expertiza website which maintains and handles student data who are participants under an assignment. Each assignment has a team, individual user participant and submission deadlines. The motive here is to refactor static methods called in the student_task.rb file and move them to helper classes for better object-oriented code design.

==About StudentTask Model==
The StudentTask model handles the tracking and organizes of student assignments, encapsulating key information about a student’s current progress, deadlines, and associated tasks. It provides different functional methods for task creation, checking completion status, and timeline generation, ensuring a streamlined and detailed view of a student's assignment timelines. The model interacts closely with assignment participants and topics to display their task completion stages, reviews, and deadlines.

===Functionality===
The StudentTask model manages student assignments with the help of functional methods to initialize tasks, track deadlines, and task assessment. It includes class method from_participant, which creates a task based on a participant’s data, and from_user, that generates a sorted list of tasks by deadline for a particular user. Task status is determined through methods such as complete?, incomplete?, and started?. Additionally The revision? method checks for ongoing updates based on current stage and submissions. The model also incorporates methods (such as get_due_date_data, get_submission_data, etc.) that compile task events in chronological order, enabling a clear overview of assignment deadlines, submissions, and peer reviews. Through encapsulation, delegation, and adherence to SRP, StudentTask ensures efficient and modular task tracking aligned with the required educational processes.

==Functionality of StudentTaskHelper Module==
The StudentTaskHelper module facilitates efficient task management by handling operations such as timeline generation, teammate grouping, and task initialization for participants. It includes generate_timeline, which combines due date, peer review, and author feedback timelines, as well as create_student_task_for_participant to initialize tasks based on participant data. The module introduces iterator patterns through methods such as for_each_due_date_of_assignment, for_each_peer_review, and for_each_author_feedback, which yield data to enhance flexibility and modularity within the codebase.

Helper methods like group_teammates_by_course_for_user efficiently organize teammates by course, while methods like parse_due_date_to_timeline and parse_response_to_timeline encapsulate logic for structuring timeline events. Using private helper methods such as fetch_response_from, and utility functions like calibration_assignment? and valid_assignment_team?, StudentTaskHelper optimizes data handling, improves readability, and adheres to object-oriented design principles by reducing the need for static methods in the StudentTask model.

====Refactor====

The StudentTask model do not strictly follow the SRP and DRY principles and needed a lot of refactoring to make them more manageable in following Object-Oriented design and development.

Files modified:
* student_task.rb
* student_task_controller.rb
* student_task_helper.rb
* student_task_spec.rb
* assessment360_controller.rb
* assessment360_controller_spec.rb

New files added:
* student_task_helper_spec.rb

==Refactoring==

====self.from_participant(participant)====
Creates a StudentTask instance for a given participant, populating it with relevant assignment and stage data.

Before:

[[File:Akoul2 from participant before.jpg]]

After:

[[File:Akoul from participant after1.jpg]]

[[File:Akoul from participant after2.jpg]]

====self.from_participantid(id)====
It searches and fetches an active participant by its id.

Before:

[[File:Akoul2 from participant id before.jpg]]

After:

This method is depreciated during the refactoring process. It no longer served its purpose and was removed from the codebase.

====self.from_user(user)====
Retrieves tasks associated with a user by iterating over the user's assignment participants and sorting them by their stage deadlines.

Before:

[[File:Akoul2 from user before.jpg]]

After:

[[File:Akoul2 from user after.jpg]]

====self.get_author_feedback_data(participant_id, timeline_list)====
Generates a timeline of author feedback for a participant by mapping each feedback response through a parsing function.

Before:

[[File:Akoul2 get author feedback data before.jpg]]

After:

[[File:Akoul2 get author feedback data after.jpg]]

====self.get_due_date_data(assignment, timeline_list)====
Generates a timeline of due dates for an assignment by mapping each due date through a parsing function.

Before:

[[File:Akoul2 get due date data before.jpg]]

After:

[[File:Akoul2 get due date after.jpg]]

====self.peer_review_data(participant_id, timeline_list)====

Before:

[[File:Akoul2 peer review data before.jpg]]

After:

[[File:Akoul2 get peer review data after.jpg]]

====self.get_submission_data(participant_id, team_id, timeline_list)====

Before:

[[File:Akoul2 get submission data before.jpg]]

After:

This method, similar to from_participantid(), didn't showcase its usefulness during the refactoring process and was removed from the codebase.

====self.get_timeline_data(assignment, participant, _team)====
Generates a timeline of events related to the assignment for the participant, including due dates, peer reviews, and author feedback, sorted by update time.

Before:

[[File:Akoul2 get timeline data before.jpg]]

After:

[[File:Akoul2 get timeline data after.jpg]]

====self.teamed_student(user, ip_address=nil)====
Groups teammates by course for a user and returns a hash where keys are course IDs and values are lists of teammate names.

Before:

[[File:Akoul2 teamed student before.jpg]]

After:

[[File:Akoul2 teamed student after.jpg]]

Additional methods added:

[[File:Akoul2 additional methods.jpg]]

==Test Cases for StudentTask Model, Controller and helper classes==

====New Test Cases====

1. To check each due date of assignment:

describe '#for_each_due_date_of_assignment' do
let(:due_date_modifier) do
lambda { |dd|
{ label: (dd.deadline_type.name + ' Deadline').humanize,
updated_at: dd.due_at.strftime('%a, %d %b %Y %H:%M') }
}
end
context 'when called with assignment having empty due dates' do
it 'return empty time_list array' do
timeline_list = []
student_task_helper.for_each_due_date_of_assignment(assignment) do |due_date|
timeline_list << due_date_modifier.call(due_date)
end
expect(timeline_list).to eq([])
end
end
context 'when called with assignment having due date' do
context 'and due_at value nil' do
it 'return empty time_list array' do
allow(due_date).to receive(:deadline_type).and_return(deadline_type)
timeline_list = []
due_date.due_at = nil
assignment.due_dates = [due_date]
student_task_helper.for_each_due_date_of_assignment(assignment) { |due_date| timeline_list << due_date_modifier.call(due_date) }
expect(timeline_list).to eq([])
end
end
context 'and due_at value not nil' do
it 'return time_list array' do
allow(due_date).to receive(:deadline_type).and_return(deadline_type)
timeline_list = []
assignment.due_dates = [due_date]
student_task_helper.for_each_due_date_of_assignment(assignment) do |due_date|
timeline_list << due_date_modifier.call(due_date)
end
expect(timeline_list).to eq([{
label: (due_date.deadline_type.name + ' Deadline').humanize,
updated_at: due_date.due_at.strftime('%a, %d %b %Y %H:%M')
}])
end
end
end
end

2. To check for peer reviews

describe '#for_each_peer_review' do
context 'when no review response mapped' do
it 'returns empty' do
timeline_list = []
for_each_peer_review(user2) do |response|
timeline_list << response_modifier.call(response, "Round #{response.round} Peer Review".humanize)
end
expect(timeline_list).to eq([])
end
end
context 'when mapped to review response map' do
it 'returns timeline array' do
timeline_list = []
allow(ReviewResponseMap).to receive_message_chain(:where, :find_each).with(reviewer_id: 1).with(no_args).and_yield(review_response_map)
allow(review_response_map).to receive(:id).and_return(1)
allow(Response).to receive_message_chain(:where, :last).with(map_id: 1).with(no_args).and_return(response)
allow(response).to receive(:round).and_return(1)
allow(response).to receive(:updated_at).and_return(Time.new(2019))
timevalue = Time.new(2019).strftime('%a, %d %b %Y %H:%M')
for_each_peer_review(1) do |resp|
timeline_list << response_modifier.call(resp, "Round #{resp.round} Peer Review".humanize)
end
expect(timeline_list).to eq([{ id: 1, label: 'Round 1 peer review', updated_at: timevalue }])
end
end
end

3. To check and validate author feedbacks

describe '#for_each_author_feedback' do
context 'when no feedback response mapped' do
it 'returns empty' do
timeline_list = []
for_each_author_feedback(user2) do |response|
timeline_list << response_modifier.call(response, 'Author feedback')
end
expect(timeline_list).to eq([])
end
end
context 'when mapped to feedback response map' do
it 'returns timeline array' do
timeline_list = []
allow(FeedbackResponseMap).to receive_message_chain(:where, :find_each).with(reviewer_id: 1).with(no_args).and_yield(review_response_map)
allow(review_response_map).to receive(:id).and_return(1)
allow(Response).to receive_message_chain(:where, :last).with(map_id: 1).with(no_args).and_return(response)
allow(response).to receive(:updated_at).and_return(Time.now)
timevalue = Time.now.strftime('%a, %d %b %Y %H:%M')
timeline_list = []
for_each_author_feedback(1) do |response|
timeline_list << response_modifier.call(response, 'Author feedback')
end
expect(timeline_list).to eq([{ id: 1, label: 'Author feedback', updated_at: timevalue }])
end
end
end

4. To create and validate generated timelines

describe '#generate_timeline' do
context 'when no timeline data mapped' do
it 'returns nil' do
allow(participant).to receive(:get_reviewer).and_return(participant)
expect(student_task_helper.generate_timeline(assignment, participant)).to eq([])
end
end
end

5. Check if StudentTask obeject is created properly

describe '#create_student_task_for_participant' do
it 'creates a StudentTask with the correct attributes' do
student_task = student_task_helper.create_student_task_for_participant(participant3)
expect(student_task).to be_an_instance_of(StudentTask)
expect(student_task.participant).to eq(participant3)
expect(student_task.assignment).to eq(assignment)
expect(student_task.topic).to eq(topic)
expect(student_task.current_stage).to eq('submission')
expect(student_task.stage_deadline).to eq(Time.parse('2024-12-31 12:00:00'))
end
end

6. To check the retrieved tasks for users

describe '#retrieve_tasks_for_user' do
before do
allow(user).to receive_message_chain(:assignment_participants, :includes).and_return([participant4, participant5])
end

it 'retrieves and sorts tasks by stage_deadline' do
tasks = student_task_helper.retrieve_tasks_for_user(user)
expect(tasks.size).to eq(2)
expect(tasks.first.stage_deadline).to eq(Time.parse('2024-11-01 12:00:00'))
expect(tasks.last.stage_deadline).to eq(Time.parse('2024-12-01 12:00:00'))
end

it 'creates StudentTask objects for each participant' do
tasks = student_task_helper.retrieve_tasks_for_user(user)
tasks.each do |task|
expect(task).to be_an_instance_of(StudentTask)
expect(task.participant).to be_in([participant4, participant5])
expect(task.assignment).to eq(assignment)
expect(task.topic).to eq(topic)
end
end
end

7. To check if deadlines are parsed properly

describe '#parse_stage_deadline' do
context 'If a valid time value is given' do
it 'parse the provided time correctly' do
given_time = '2024-12-31 12:00:00'
parsed_time = student_task_helper.parse_stage_deadline(given_time)
expect(parsed_time).to eq(Time.parse(given_time))
end
end

context 'If given time string is invalid' do
it 'return current time plus 1 year' do
given_time = 'invalid-time-string'
overhead_time = Time.now + 1.year
parsed_time = student_task_helper.parse_stage_deadline(given_time)
expect(parsed_time).to be_within(1.second).of(overhead_time)
end
end
end

8. To check various conditions of users tagged as teammates

describe '#group_teammates_by_course_for_user' do
context 'when not in any team' do
it 'returns empty' do
expect(student_task_helper.group_teammates_by_course_for_user(user3)).to eq({})
end
end
context 'when assigned in a course_team ' do
it 'returns empty' do
allow(user).to receive(:teams).and_return([course_team])
expect(student_task_helper.group_teammates_by_course_for_user(user)).to eq({})
end
end
context 'when assigned in a assignment_team ' do
it 'returns the students they are teamed with' do
allow(user).to receive(:teams).and_return([team])
allow(AssignmentParticipant).to receive(:find_by).with(user_id: 1, parent_id: assignment.id).and_return(participant)
allow(AssignmentParticipant).to receive(:find_by).with(user_id: 5, parent_id: assignment.id).and_return(participant2)
allow(Assignment).to receive(:find_by).with(id: team.parent_id).and_return(assignment)
expect(student_task_helper.group_teammates_by_course_for_user(user)).to eq(assignment.course_id => [user2.fullname])
end
end
end

==Next Steps==
We are yet to discuss the scope of this project and whether it can be extended to other functionalities in Expertiza.

==Team==

====Mentor====

* Ammana, Sahithi <sammana@ncsu.edu>

====Members====

* Eathamukkala, Akarsh Reddy <aeatham@ncsu.edu>
* Koul, Anmol <akoul2@ncsu.edu>
* More, Harsh <hmore@ncsu.edu>

==References==

# [https://expertiza.ncsu.edu/ Expertiza]
# [https://docs.google.com/document/d/1fB9nHsop_yptjcj3CFn80BcZjXcSDbzcWwKvBDUTVrQ/edit?tab=t.0 OSS Projects on Expertiza]
# [https://github.com/expertiza/expertiza Github]
# [https://github.com/expertiza/expertiza/pull/2859 Pull Request]
# [http://152.7.177.54:8080/ Expertiza VCL Server]

CSC/ECE 517 Fall 2024 - E2454. Refactor student task.rb

2024-10-30T03:23:17Z

Akoul2: /* Functionality of StudentTask Model */

==Expertiza==

Expertiza is a web application through which students can submit and peer-review learning objects (articles, code, web sites, etc).
The National Science Foundation supports the Expertiza project.
It is used in select courses at NC State and by professors at several other colleges and universities.

[http://expertiza.ncsu.edu/ Expertiza] is a [http://rubyonrails.org/ Ruby on Rails] based open source project.

==Problem Statement==

====Background====
This project focuses on refactoring the StudentTask class to improve the organization, functionality, and separation of concerns. Currently, the class contains a mix of utility and class methods, many of which are static and should be moved into helper modules or relevant model classes, or broken down into separate, more maintainable methods. The goal is to make the class more efficient and follow best practices in object-oriented programming.

The StudentTask model is a significant part of the Expertiza website which maintains and handles student data who are participants under an assignment. Each assignment has a team, individual user participant and submission deadlines. The motive here is to refactor static methods called in the student_task.rb file and move them to helper classes for better object-oriented code design.

==About StudentTask Model==
The StudentTask model handles the tracking and organizes of student assignments, encapsulating key information about a student’s current progress, deadlines, and associated tasks. It provides different functional methods for task creation, checking completion status, and timeline generation, ensuring a streamlined and detailed view of a student's assignment timelines. The model interacts closely with assignment participants and topics to display their task completion stages, reviews, and deadlines.

===Functionality===
The StudentTask model manages student assignments with the help of functional methods to initialize tasks, track deadlines, and task assessment. It includes class method from_participant, which creates a task based on a participant’s data, and from_user, that generates a sorted list of tasks by deadline for a particular user. Task status is determined through methods such as complete?, incomplete?, and started?. Additionally The revision? method checks for ongoing updates based on current stage and submissions. The model also incorporates methods (such as get_due_date_data, get_submission_data, etc.) that compile task events in chronological order, enabling a clear overview of assignment deadlines, submissions, and peer reviews. Through encapsulation, delegation, and adherence to SRP, StudentTask ensures efficient and modular task tracking aligned with the required educational processes.

==Functionality of StudentTaskHelper Module==
The StudentTaskHelper module facilitates efficient task management by handling operations such as timeline generation, teammate grouping, and task initialization for participants. It includes generate_timeline, which combines due date, peer review, and author feedback timelines, as well as create_student_task_for_participant to initialize tasks based on participant data. The module introduces iterator patterns through methods such as for_each_due_date_of_assignment, for_each_peer_review, and for_each_author_feedback, which yield data to enhance flexibility and modularity within the codebase.

Helper methods like group_teammates_by_course_for_user efficiently organize teammates by course, while methods like parse_due_date_to_timeline and parse_response_to_timeline encapsulate logic for structuring timeline events. Using private helper methods such as fetch_response_from, and utility functions like calibration_assignment? and valid_assignment_team?, StudentTaskHelper optimizes data handling, improves readability, and adheres to object-oriented design principles by reducing the need for static methods in the StudentTask model.

====Refactor====

The StudentTask model do not strictly follow the SRP and DRY principles and needed a lot of refactoring to make them more manageable in following Object-Oriented design and development.

Files modified:
* student_task.rb
* student_task_controller.rb
* student_task_helper.rb
* student_task_spec.rb
* assessment360_controller.rb
* assessment360_controller_spec.rb

New files added:
* student_task_helper_spec.rb

==Refactoring==

self.from_participant(participant)

Before:

[[File:Akoul2 from participant before.jpg]]

After:

[[File:Akoul from participant after1.jpg]]

[[File:Akoul from participant after2.jpg]]

self.from_participantid(id)

Before:

[[File:Akoul2 from participant id before.jpg]]

After:

This method is depreciated during the refactoring process. It no longer served its purpose and was removed from the codebase.

self.from_user(user)

Before:

[[File:Akoul2 from user before.jpg]]

After:

[[File:Akoul2 from user after.jpg]]

self.get_author_feedback_data(participant_id, timeline_list)

Before:

[[File:Akoul2 get author feedback data before.jpg]]

After:

[[File:Akoul2 get author feedback data after.jpg]]

self.get_due_date_data(assignment, timeline_list)

Before:

[[File:Akoul2 get due date data before.jpg]]

After:

[[File:Akoul2 get due date after.jpg]]

self.peer_review_data(participant_id, timeline_list)

Before:

[[File:Akoul2 peer review data before.jpg]]

After:

[[File:Akoul2 get peer review data after.jpg]]

self.get_submission_data(participant_id, team_id, timeline_list)

Before:

[[File:Akoul2 get submission data before.jpg]]

After:

This method, similar to from_participantid(), didn't showcase its usefulness during the refactoring process and was removed from the codebase.

self.get_timeline_data(assignment, participant, _team)

Before:

[[File:Akoul2 get timeline data before.jpg]]

After:

[[File:Akoul2 get timeline data after.jpg]]

self.teamed_student(user, ip_address=nil)

Before:

[[File:Akoul2 teamed student before.jpg]]

After:

[[File:Akoul2 teamed student after.jpg]]

Additional methods added:

[[File:Akoul2 additional methods.jpg]]

==Test Cases for StudentTask Model, Controller and helper classes==

====New Test Cases====

1. To check each due date of assignment:

describe '#for_each_due_date_of_assignment' do
let(:due_date_modifier) do
lambda { |dd|
{ label: (dd.deadline_type.name + ' Deadline').humanize,
updated_at: dd.due_at.strftime('%a, %d %b %Y %H:%M') }
}
end
context 'when called with assignment having empty due dates' do
it 'return empty time_list array' do
timeline_list = []
student_task_helper.for_each_due_date_of_assignment(assignment) do |due_date|
timeline_list << due_date_modifier.call(due_date)
end
expect(timeline_list).to eq([])
end
end
context 'when called with assignment having due date' do
context 'and due_at value nil' do
it 'return empty time_list array' do
allow(due_date).to receive(:deadline_type).and_return(deadline_type)
timeline_list = []
due_date.due_at = nil
assignment.due_dates = [due_date]
student_task_helper.for_each_due_date_of_assignment(assignment) { |due_date| timeline_list << due_date_modifier.call(due_date) }
expect(timeline_list).to eq([])
end
end
context 'and due_at value not nil' do
it 'return time_list array' do
allow(due_date).to receive(:deadline_type).and_return(deadline_type)
timeline_list = []
assignment.due_dates = [due_date]
student_task_helper.for_each_due_date_of_assignment(assignment) do |due_date|
timeline_list << due_date_modifier.call(due_date)
end
expect(timeline_list).to eq([{
label: (due_date.deadline_type.name + ' Deadline').humanize,
updated_at: due_date.due_at.strftime('%a, %d %b %Y %H:%M')
}])
end
end
end
end

2. To check for peer reviews

describe '#for_each_peer_review' do
context 'when no review response mapped' do
it 'returns empty' do
timeline_list = []
for_each_peer_review(user2) do |response|
timeline_list << response_modifier.call(response, "Round #{response.round} Peer Review".humanize)
end
expect(timeline_list).to eq([])
end
end
context 'when mapped to review response map' do
it 'returns timeline array' do
timeline_list = []
allow(ReviewResponseMap).to receive_message_chain(:where, :find_each).with(reviewer_id: 1).with(no_args).and_yield(review_response_map)
allow(review_response_map).to receive(:id).and_return(1)
allow(Response).to receive_message_chain(:where, :last).with(map_id: 1).with(no_args).and_return(response)
allow(response).to receive(:round).and_return(1)
allow(response).to receive(:updated_at).and_return(Time.new(2019))
timevalue = Time.new(2019).strftime('%a, %d %b %Y %H:%M')
for_each_peer_review(1) do |resp|
timeline_list << response_modifier.call(resp, "Round #{resp.round} Peer Review".humanize)
end
expect(timeline_list).to eq([{ id: 1, label: 'Round 1 peer review', updated_at: timevalue }])
end
end
end

3. To check and validate author feedbacks

describe '#for_each_author_feedback' do
context 'when no feedback response mapped' do
it 'returns empty' do
timeline_list = []
for_each_author_feedback(user2) do |response|
timeline_list << response_modifier.call(response, 'Author feedback')
end
expect(timeline_list).to eq([])
end
end
context 'when mapped to feedback response map' do
it 'returns timeline array' do
timeline_list = []
allow(FeedbackResponseMap).to receive_message_chain(:where, :find_each).with(reviewer_id: 1).with(no_args).and_yield(review_response_map)
allow(review_response_map).to receive(:id).and_return(1)
allow(Response).to receive_message_chain(:where, :last).with(map_id: 1).with(no_args).and_return(response)
allow(response).to receive(:updated_at).and_return(Time.now)
timevalue = Time.now.strftime('%a, %d %b %Y %H:%M')
timeline_list = []
for_each_author_feedback(1) do |response|
timeline_list << response_modifier.call(response, 'Author feedback')
end
expect(timeline_list).to eq([{ id: 1, label: 'Author feedback', updated_at: timevalue }])
end
end
end

4. To create and validate generated timelines

describe '#generate_timeline' do
context 'when no timeline data mapped' do
it 'returns nil' do
allow(participant).to receive(:get_reviewer).and_return(participant)
expect(student_task_helper.generate_timeline(assignment, participant)).to eq([])
end
end
end

5. Check if StudentTask obeject is created properly

describe '#create_student_task_for_participant' do
it 'creates a StudentTask with the correct attributes' do
student_task = student_task_helper.create_student_task_for_participant(participant3)
expect(student_task).to be_an_instance_of(StudentTask)
expect(student_task.participant).to eq(participant3)
expect(student_task.assignment).to eq(assignment)
expect(student_task.topic).to eq(topic)
expect(student_task.current_stage).to eq('submission')
expect(student_task.stage_deadline).to eq(Time.parse('2024-12-31 12:00:00'))
end
end

6. To check the retrieved tasks for users

describe '#retrieve_tasks_for_user' do
before do
allow(user).to receive_message_chain(:assignment_participants, :includes).and_return([participant4, participant5])
end

it 'retrieves and sorts tasks by stage_deadline' do
tasks = student_task_helper.retrieve_tasks_for_user(user)
expect(tasks.size).to eq(2)
expect(tasks.first.stage_deadline).to eq(Time.parse('2024-11-01 12:00:00'))
expect(tasks.last.stage_deadline).to eq(Time.parse('2024-12-01 12:00:00'))
end

it 'creates StudentTask objects for each participant' do
tasks = student_task_helper.retrieve_tasks_for_user(user)
tasks.each do |task|
expect(task).to be_an_instance_of(StudentTask)
expect(task.participant).to be_in([participant4, participant5])
expect(task.assignment).to eq(assignment)
expect(task.topic).to eq(topic)
end
end
end

7. To check if deadlines are parsed properly

describe '#parse_stage_deadline' do
context 'If a valid time value is given' do
it 'parse the provided time correctly' do
given_time = '2024-12-31 12:00:00'
parsed_time = student_task_helper.parse_stage_deadline(given_time)
expect(parsed_time).to eq(Time.parse(given_time))
end
end

context 'If given time string is invalid' do
it 'return current time plus 1 year' do
given_time = 'invalid-time-string'
overhead_time = Time.now + 1.year
parsed_time = student_task_helper.parse_stage_deadline(given_time)
expect(parsed_time).to be_within(1.second).of(overhead_time)
end
end
end

8. To check various conditions of users tagged as teammates

describe '#group_teammates_by_course_for_user' do
context 'when not in any team' do
it 'returns empty' do
expect(student_task_helper.group_teammates_by_course_for_user(user3)).to eq({})
end
end
context 'when assigned in a course_team ' do
it 'returns empty' do
allow(user).to receive(:teams).and_return([course_team])
expect(student_task_helper.group_teammates_by_course_for_user(user)).to eq({})
end
end
context 'when assigned in a assignment_team ' do
it 'returns the students they are teamed with' do
allow(user).to receive(:teams).and_return([team])
allow(AssignmentParticipant).to receive(:find_by).with(user_id: 1, parent_id: assignment.id).and_return(participant)
allow(AssignmentParticipant).to receive(:find_by).with(user_id: 5, parent_id: assignment.id).and_return(participant2)
allow(Assignment).to receive(:find_by).with(id: team.parent_id).and_return(assignment)
expect(student_task_helper.group_teammates_by_course_for_user(user)).to eq(assignment.course_id => [user2.fullname])
end
end
end

==Next Steps==
We are yet to discuss the scope of this project and whether it can be extended to other functionalities in Expertiza.

==Team==

====Mentor====

* Ammana, Sahithi <sammana@ncsu.edu>

====Members====

* Eathamukkala, Akarsh Reddy <aeatham@ncsu.edu>
* Koul, Anmol <akoul2@ncsu.edu>
* More, Harsh <hmore@ncsu.edu>

==References==

# [https://expertiza.ncsu.edu/ Expertiza]
# [https://docs.google.com/document/d/1fB9nHsop_yptjcj3CFn80BcZjXcSDbzcWwKvBDUTVrQ/edit?tab=t.0 OSS Projects on Expertiza]
# [https://github.com/expertiza/expertiza Github]
# [https://github.com/expertiza/expertiza/pull/2859 Pull Request]
# [http://152.7.177.54:8080/ Expertiza VCL Server]

CSC/ECE 517 Fall 2024 - E2454. Refactor student task.rb

2024-10-30T03:21:15Z

Akoul2: /* Functionality of StudentTask Model */

==Expertiza==

Expertiza is a web application through which students can submit and peer-review learning objects (articles, code, web sites, etc).
The National Science Foundation supports the Expertiza project.
It is used in select courses at NC State and by professors at several other colleges and universities.

[http://expertiza.ncsu.edu/ Expertiza] is a [http://rubyonrails.org/ Ruby on Rails] based open source project.

==Problem Statement==

====Background====
This project focuses on refactoring the StudentTask class to improve the organization, functionality, and separation of concerns. Currently, the class contains a mix of utility and class methods, many of which are static and should be moved into helper modules or relevant model classes, or broken down into separate, more maintainable methods. The goal is to make the class more efficient and follow best practices in object-oriented programming.

The StudentTask model is a significant part of the Expertiza website which maintains and handles student data who are participants under an assignment. Each assignment has a team, individual user participant and submission deadlines. The motive here is to refactor static methods called in the student_task.rb file and move them to helper classes for better object-oriented code design.

==About StudentTask Model==
The StudentTask model handles the tracking and organizes of student assignments, encapsulating key information about a student’s current progress, deadlines, and associated tasks. It provides different functional methods for task creation, checking completion status, and timeline generation, ensuring a streamlined and detailed view of a student's assignment timelines. The model interacts closely with assignment participants and topics to display their task completion stages, reviews, and deadlines.

===Functionality of StudentTask Model===
The StudentTask model manages student assignments with the help of functional methods to initialize tasks, track deadlines, and task assessment. It includes class method from_participant, which creates a task based on a participant’s data, and from_user, that generates a sorted list of tasks by deadline for a particular user. Task status is determined through methods such as complete?, incomplete?, and started?. Additionally The revision? method checks for ongoing updates based on current stage and submissions. The model also incorporates methods (such as get_due_date_data, get_submission_data, etc.) that compile task events in chronological order, enabling a clear overview of assignment deadlines, submissions, and peer reviews. Through encapsulation, delegation, and adherence to SRP, StudentTask ensures efficient and modular task tracking aligned with the required educational processes.

==Functionality of StudentTaskHelper Module==
The StudentTaskHelper module facilitates efficient task management by handling operations such as timeline generation, teammate grouping, and task initialization for participants. It includes generate_timeline, which combines due date, peer review, and author feedback timelines, as well as create_student_task_for_participant to initialize tasks based on participant data. The module introduces iterator patterns through methods such as for_each_due_date_of_assignment, for_each_peer_review, and for_each_author_feedback, which yield data to enhance flexibility and modularity within the codebase.

Helper methods like group_teammates_by_course_for_user efficiently organize teammates by course, while methods like parse_due_date_to_timeline and parse_response_to_timeline encapsulate logic for structuring timeline events. Using private helper methods such as fetch_response_from, and utility functions like calibration_assignment? and valid_assignment_team?, StudentTaskHelper optimizes data handling, improves readability, and adheres to object-oriented design principles by reducing the need for static methods in the StudentTask model.

====Refactor====

The StudentTask model do not strictly follow the SRP and DRY principles and needed a lot of refactoring to make them more manageable in following Object-Oriented design and development.

Files modified:
* student_task.rb
* student_task_controller.rb
* student_task_helper.rb
* student_task_spec.rb
* assessment360_controller.rb
* assessment360_controller_spec.rb

New files added:
* student_task_helper_spec.rb

==Refactoring==

self.from_participant(participant)

Before:

[[File:Akoul2 from participant before.jpg]]

After:

[[File:Akoul from participant after1.jpg]]

[[File:Akoul from participant after2.jpg]]

self.from_participantid(id)

Before:

[[File:Akoul2 from participant id before.jpg]]

After:

This method is depreciated during the refactoring process. It no longer served its purpose and was removed from the codebase.

self.from_user(user)

Before:

[[File:Akoul2 from user before.jpg]]

After:

[[File:Akoul2 from user after.jpg]]

self.get_author_feedback_data(participant_id, timeline_list)

Before:

[[File:Akoul2 get author feedback data before.jpg]]

After:

[[File:Akoul2 get author feedback data after.jpg]]

self.get_due_date_data(assignment, timeline_list)

Before:

[[File:Akoul2 get due date data before.jpg]]

After:

[[File:Akoul2 get due date after.jpg]]

self.peer_review_data(participant_id, timeline_list)

Before:

[[File:Akoul2 peer review data before.jpg]]

After:

[[File:Akoul2 get peer review data after.jpg]]

self.get_submission_data(participant_id, team_id, timeline_list)

Before:

[[File:Akoul2 get submission data before.jpg]]

After:

This method, similar to from_participantid(), didn't showcase its usefulness during the refactoring process and was removed from the codebase.

self.get_timeline_data(assignment, participant, _team)

Before:

[[File:Akoul2 get timeline data before.jpg]]

After:

[[File:Akoul2 get timeline data after.jpg]]

self.teamed_student(user, ip_address=nil)

Before:

[[File:Akoul2 teamed student before.jpg]]

After:

[[File:Akoul2 teamed student after.jpg]]

Additional methods added:

[[File:Akoul2 additional methods.jpg]]

==Test Cases for StudentTask Model, Controller and helper classes==

====New Test Cases====

1. To check each due date of assignment:

describe '#for_each_due_date_of_assignment' do
let(:due_date_modifier) do
lambda { |dd|
{ label: (dd.deadline_type.name + ' Deadline').humanize,
updated_at: dd.due_at.strftime('%a, %d %b %Y %H:%M') }
}
end
context 'when called with assignment having empty due dates' do
it 'return empty time_list array' do
timeline_list = []
student_task_helper.for_each_due_date_of_assignment(assignment) do |due_date|
timeline_list << due_date_modifier.call(due_date)
end
expect(timeline_list).to eq([])
end
end
context 'when called with assignment having due date' do
context 'and due_at value nil' do
it 'return empty time_list array' do
allow(due_date).to receive(:deadline_type).and_return(deadline_type)
timeline_list = []
due_date.due_at = nil
assignment.due_dates = [due_date]
student_task_helper.for_each_due_date_of_assignment(assignment) { |due_date| timeline_list << due_date_modifier.call(due_date) }
expect(timeline_list).to eq([])
end
end
context 'and due_at value not nil' do
it 'return time_list array' do
allow(due_date).to receive(:deadline_type).and_return(deadline_type)
timeline_list = []
assignment.due_dates = [due_date]
student_task_helper.for_each_due_date_of_assignment(assignment) do |due_date|
timeline_list << due_date_modifier.call(due_date)
end
expect(timeline_list).to eq([{
label: (due_date.deadline_type.name + ' Deadline').humanize,
updated_at: due_date.due_at.strftime('%a, %d %b %Y %H:%M')
}])
end
end
end
end

2. To check for peer reviews

describe '#for_each_peer_review' do
context 'when no review response mapped' do
it 'returns empty' do
timeline_list = []
for_each_peer_review(user2) do |response|
timeline_list << response_modifier.call(response, "Round #{response.round} Peer Review".humanize)
end
expect(timeline_list).to eq([])
end
end
context 'when mapped to review response map' do
it 'returns timeline array' do
timeline_list = []
allow(ReviewResponseMap).to receive_message_chain(:where, :find_each).with(reviewer_id: 1).with(no_args).and_yield(review_response_map)
allow(review_response_map).to receive(:id).and_return(1)
allow(Response).to receive_message_chain(:where, :last).with(map_id: 1).with(no_args).and_return(response)
allow(response).to receive(:round).and_return(1)
allow(response).to receive(:updated_at).and_return(Time.new(2019))
timevalue = Time.new(2019).strftime('%a, %d %b %Y %H:%M')
for_each_peer_review(1) do |resp|
timeline_list << response_modifier.call(resp, "Round #{resp.round} Peer Review".humanize)
end
expect(timeline_list).to eq([{ id: 1, label: 'Round 1 peer review', updated_at: timevalue }])
end
end
end

3. To check and validate author feedbacks

describe '#for_each_author_feedback' do
context 'when no feedback response mapped' do
it 'returns empty' do
timeline_list = []
for_each_author_feedback(user2) do |response|
timeline_list << response_modifier.call(response, 'Author feedback')
end
expect(timeline_list).to eq([])
end
end
context 'when mapped to feedback response map' do
it 'returns timeline array' do
timeline_list = []
allow(FeedbackResponseMap).to receive_message_chain(:where, :find_each).with(reviewer_id: 1).with(no_args).and_yield(review_response_map)
allow(review_response_map).to receive(:id).and_return(1)
allow(Response).to receive_message_chain(:where, :last).with(map_id: 1).with(no_args).and_return(response)
allow(response).to receive(:updated_at).and_return(Time.now)
timevalue = Time.now.strftime('%a, %d %b %Y %H:%M')
timeline_list = []
for_each_author_feedback(1) do |response|
timeline_list << response_modifier.call(response, 'Author feedback')
end
expect(timeline_list).to eq([{ id: 1, label: 'Author feedback', updated_at: timevalue }])
end
end
end

4. To create and validate generated timelines

describe '#generate_timeline' do
context 'when no timeline data mapped' do
it 'returns nil' do
allow(participant).to receive(:get_reviewer).and_return(participant)
expect(student_task_helper.generate_timeline(assignment, participant)).to eq([])
end
end
end

5. Check if StudentTask obeject is created properly

describe '#create_student_task_for_participant' do
it 'creates a StudentTask with the correct attributes' do
student_task = student_task_helper.create_student_task_for_participant(participant3)
expect(student_task).to be_an_instance_of(StudentTask)
expect(student_task.participant).to eq(participant3)
expect(student_task.assignment).to eq(assignment)
expect(student_task.topic).to eq(topic)
expect(student_task.current_stage).to eq('submission')
expect(student_task.stage_deadline).to eq(Time.parse('2024-12-31 12:00:00'))
end
end

6. To check the retrieved tasks for users

describe '#retrieve_tasks_for_user' do
before do
allow(user).to receive_message_chain(:assignment_participants, :includes).and_return([participant4, participant5])
end

it 'retrieves and sorts tasks by stage_deadline' do
tasks = student_task_helper.retrieve_tasks_for_user(user)
expect(tasks.size).to eq(2)
expect(tasks.first.stage_deadline).to eq(Time.parse('2024-11-01 12:00:00'))
expect(tasks.last.stage_deadline).to eq(Time.parse('2024-12-01 12:00:00'))
end

it 'creates StudentTask objects for each participant' do
tasks = student_task_helper.retrieve_tasks_for_user(user)
tasks.each do |task|
expect(task).to be_an_instance_of(StudentTask)
expect(task.participant).to be_in([participant4, participant5])
expect(task.assignment).to eq(assignment)
expect(task.topic).to eq(topic)
end
end
end

7. To check if deadlines are parsed properly

describe '#parse_stage_deadline' do
context 'If a valid time value is given' do
it 'parse the provided time correctly' do
given_time = '2024-12-31 12:00:00'
parsed_time = student_task_helper.parse_stage_deadline(given_time)
expect(parsed_time).to eq(Time.parse(given_time))
end
end

context 'If given time string is invalid' do
it 'return current time plus 1 year' do
given_time = 'invalid-time-string'
overhead_time = Time.now + 1.year
parsed_time = student_task_helper.parse_stage_deadline(given_time)
expect(parsed_time).to be_within(1.second).of(overhead_time)
end
end
end

8. To check various conditions of users tagged as teammates

describe '#group_teammates_by_course_for_user' do
context 'when not in any team' do
it 'returns empty' do
expect(student_task_helper.group_teammates_by_course_for_user(user3)).to eq({})
end
end
context 'when assigned in a course_team ' do
it 'returns empty' do
allow(user).to receive(:teams).and_return([course_team])
expect(student_task_helper.group_teammates_by_course_for_user(user)).to eq({})
end
end
context 'when assigned in a assignment_team ' do
it 'returns the students they are teamed with' do
allow(user).to receive(:teams).and_return([team])
allow(AssignmentParticipant).to receive(:find_by).with(user_id: 1, parent_id: assignment.id).and_return(participant)
allow(AssignmentParticipant).to receive(:find_by).with(user_id: 5, parent_id: assignment.id).and_return(participant2)
allow(Assignment).to receive(:find_by).with(id: team.parent_id).and_return(assignment)
expect(student_task_helper.group_teammates_by_course_for_user(user)).to eq(assignment.course_id => [user2.fullname])
end
end
end

==Next Steps==
We are yet to discuss the scope of this project and whether it can be extended to other functionalities in Expertiza.

==Team==

====Mentor====

* Ammana, Sahithi <sammana@ncsu.edu>

====Members====

* Eathamukkala, Akarsh Reddy <aeatham@ncsu.edu>
* Koul, Anmol <akoul2@ncsu.edu>
* More, Harsh <hmore@ncsu.edu>

==References==

# [https://expertiza.ncsu.edu/ Expertiza]
# [https://docs.google.com/document/d/1fB9nHsop_yptjcj3CFn80BcZjXcSDbzcWwKvBDUTVrQ/edit?tab=t.0 OSS Projects on Expertiza]
# [https://github.com/expertiza/expertiza Github]
# [https://github.com/expertiza/expertiza/pull/2859 Pull Request]
# [http://152.7.177.54:8080/ Expertiza VCL Server]