CSC/ECE 517 Spring 2023 E2342: Reimplement Participants Model and Controller: Difference between revisions

From Expertiza_Wiki
Jump to navigation Jump to search
 
(24 intermediate revisions by 3 users not shown)
Line 5: Line 5:


== Project Purpose ==
== Project Purpose ==
The aim of our project is to integrate the reimplemented versions of Participants Model and Participants Controller while maintaining the existing functionality of the feature. We plan on restricting all the business logic to the model, which will also handle all of the interactions with the database. The controller, on the other hand, will be responsible only for accepting appropriate input and returning the results in a JSON format. The controller will also query the database but write operations would only be done in the model.
The aim of our project is to integrate the reimplemented version of participants_controller with the Participant Model while maintaining the existing functionality of the feature. We plan on restricting all the business logic to the model, which will also handle all of the interactions with the database. The controller, on the other hand, will be responsible only for accepting appropriate input and returning the results in a JSON format. The test suite will be updated accordingly to accommodate the above-mentioned development plan.
The test suite will also be updated to reflect the above-mentioned development plan as we develop a comprehensive test plan for both the model as well as the controller.


== Project Design ==
== Project Design ==


=== High-level Design Diagram ===  
=== High-level Design Diagram ===  
The architecture diagram shown below serves the purpose of our high-level design diagram. As seen in the figure, the user interacts with the web client i.e. browser which sends an HTTP request to the web server available in the back-end. The web server is responsible for handling the rails routes corresponding to the RESTful endpoints of the APIs that we have developed. The endpoints then route to the corresponding method in the participants controller where the intended functionality is carried out. For certain APIs, such as inherit, this involves interacting with the participants model and the database to update the state of the system. For other simpler features, such as index, the controller method handles all the processing. The method responds with a JSON structure which is sent back as an HTTP response to the front-end and then returned back to the client.<br>
The diagram lays out the general workflow of a user interacting with the system and helps the viewer understand the responsibilities of the model, controller, and view in our system. Models are responsible for dealing with the business logic of the features and interact with the database for all data operations. Controllers are responsible for taking appropriate input and returning JSON-formatted output without changing any data or the state of the system. Lastly, views are responsible for rendering the output in a user-friendly interface for the client.
[[File:Participants_workflow.jpg]]
[[File:Participants_workflow.jpg]]


===Use Case Diagram===
===Use Case Diagram===
The following Use Case Diagram demonstrates the primary functionality relevant to participants for different types of users in the system.
The following Use Case Diagram demonstrates the primary functionality relevant to participants for different types of users in the system.
We've highlighted three primary users of our system who might use the participants features - instructors/TAs, participants (who are expected to be students), and admins.
[[File:Participants_usecase.jpg]]
[[File:Participants_usecase.jpg]]


== Implementation ==
== Implementation ==
As part of the re-implementation, the objective is to employ an API-first approach while maintaining all the existing functionality in an efficient, robust and simple manner. Specifically for the participants controller, we've added seven different API endpoints to extend the current functionalities while modifying the code to support these APIs. The details for these endpoints can be found below.
This project has been split up in two phases, with phase 1 being the re-implementation of the participants model and controller. The second phase of the project focuses on the integration of the newly implemented versions of participants model and controller. <br>
During the first phase, the controller employed an API-first approach while maintaining all the existing functionality in an efficient, robust and simple manner. Specifically for the participants controller, we added seven different API endpoints to extend the current functionalities while modifying the code to support these APIs. For the participants model, we removed all unnecessary functionality and retained only the core business logic for participants. The details for the model changes and new endpoints have been discussed later in this section. <br>
For the second phase, we plan on maintaining the ideology of restricting business logic to the model and API logic to the controller. We will fill in the missing gaps and modify the code after re-implementation to enable integration of the new code. The proposed changes for this phase have been discussed later in this section. <br>


=== Assumptions ===  
=== Assumptions ===  
#The CourseParticipant and AssignmentParticipant models implement the <code>copy</code> method which copies participants from the course to assignment and vice-versa. This functionality is used in the inherit and bequeath methods.
#The CourseParticipant and AssignmentParticipant models implement the <code>copy</code> method which copies participants from the course to assignment and vice-versa. This functionality is used in the inherit and bequeath methods.


=== Model documentation ===
=== Phase 1a: Reimplementation of Participants Model ===
The participants model file <code>participant.rb</code> was re-implemented to include only the necessary business logic and remove unnecessary functionality.
The participants model file <code>participant.rb</code> was re-implemented to include only the necessary business logic and remove unnecessary functionality. <br>
'''Note: More details on this can be found [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2317:_Reimplement_participant.rb here].'''


==== Replaced force_delete Method with leave_team Method ====
{| class="wikitable" style="width: 100%;
The original 'force_delete' method would delete the participant from the team and if there is only one participant in the team then it would delete the team. 
! Task !! Status !! Testing
[[File:E2317_force_delete.jpg | 800px]]
|-
 
| [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2317:_Reimplement_participant.rb#Replaced_force_delete_Method_with_leave_team_Method Replaced force_delete method with leave_team method] || Implemented || Completed
A new method 'leave_team' was introduced in place of 'force_delete' as 'force_delete' method is supposed to be present in the teams.rb and not participant.rb. The difference between force_delete method and this is that even if there is only one participant it wouldn't delete the team.
|-
 
| [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2317:_Reimplement_participant.rb#mail_assigned_reviewers_Method_was_Removed mail_assigned_reviewers method was removed] || Implemented || N/A
[[File:E2317__leave_team.jpg | 800px]]
|-
 
| [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2317:_Reimplement_participant.rb#able_to_review_Method_was_Removed able_to_review method was eliminated] || Implemented || N/A
==== mail_assigned_reviewers Method was Removed ====
|-
The method 'Mail_assigned_reviewers' is responsible for sending an email to the assigned reviewer whenever a new submission is made. It would be more appropriate for this method to be included in teams.rb rather than participant.rb. Hence, this method was removed.
| [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2317:_Reimplement_participant.rb#email_Method_was_Removed email method was removed] || Implemented || N/A
 
|}
==== able_to_review Method was Removed ====
'able_to_review' method is just using can_review value. This method can be eliminated.
 
==== email Method was Removed ====
'email' method was removed as it was not required.
 
==== Merged export and export_fields Methods ====
We didn't implement this task as merging two functions became a hassle for debugging and testing and fixing errors present in the code. Instead, it is generally considered good programming practice to break down large functions into smaller, more manageable ones. This principle is commonly known as the "Single Responsibility Principle," which states that a function or module should have only one reason to change. By breaking down a large function into smaller functions, made our code more modular and easier to read, understand, and maintain.
 
[[File:E2317__export_exportfield.jpg | 800px]]


=== Controller API documentation ===  
=== Phase 1b: Reimplementation of Participants Controller ===  
The endpoints implemented as part of this phase have been summarized here. The code for these can be found in the <code>participants_controller.rb</code> file.<br>
'''Note: Detailed API documentation and other details for these can be found [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_E2318:_Reimplement_Participants_Controller here].
'''


{| class="wikitable" style="width: 100%;
{| class="wikitable" style="width: 100%;
Line 89: Line 88:
|}
|}


==== Index ====
=== Current Work ===
'''Description''': This endpoint allows the user to request a list of all participants for the provided assignment ID or course ID. A success response renders a JSON with a list of participants that can be parsed by the front-end.
 
'''Path''': GET <code>/participants/index/:model/:id</code>


'''Parameters''':
{| class="wikitable" style="width: 100%;
{| class="wikitable" style="width: 100%;
! &nbsp;#&nbsp; !! Parameter !! Expected Value
|-
|-
|1
! Task !! Notes
|<code>model</code>
|One of these two strings: <code>['Assignment', 'Course']</code>
|-
|-
|2
| Modify the team method in Participants model || The team method uses TeamsParticipant instead of TeamsUser based on E2304
|<code>id</code>
|The unique identifier for an assignment or a course depending on the value of <code>:model</code>
|}
 
'''Response''':
<pre>
{
  "model_object": model_object,
  "participants": participants,
}
status: :ok
 
{
  error: "Missing or invalid required parameters"
}
status: :unprocessable_entity
</pre>
 
==== Create ====
'''Description''': This endpoint allows the user to create a new participant for the provided assignment ID or course ID. A success response renders a JSON with the participant details. The user is required to provide a valid username as well as the appropriate permissions for the new participant. These permissions are <code>[can_submit, can_review, can_take_quiz]</code>. Depending on whether the request is for an <code>Assignment</code> or a <code>Course</code>, a participant type is determined between an <code>AssignmentParticipant</code> or a <code>CourseParticipant</code> and an entry is made into the database accordingly.
 
'''Path''': POST <code>/participants/:model/:id</code>
 
'''Parameters''':
{| class="wikitable" style="width: 100%;
! &nbsp;#&nbsp; !! Parameter !! Expected Value
|-
|-
|1
| Replace sort_by_name method with sort_participants method in Participants model || sort_participants can either sort by id of the participants or name of the corresponding user depending on the parameter passed
|<code>model</code>
|One of <code>['Assignment', 'Course']</code>
|-
|-
|2
| Modify destroy in participants_controller || The destroy method uses the delete method from the Participants model to check if the participant is on a team or assigned as a reviewer or reviewee before destroying
|<code>id</code>
|The id of the course or assignment
|}
 
'''Request Body''':
<pre>
content:
  application/json:
    schema:
      type: object
      properties:
        user:
          type: object
          properties:
          name: string
        participant:
          type: object
          properties:
            can_submit:
              type: boolean
            can_review:
              type: boolean
            can_take_quiz:
              type: boolean
</pre>
 
'''Response''':
<pre>
Success
{
  "participant": participant,
}
status: :created
 
When user does not exist
{
  error: "User #{params[:user][:name]} does not exist"
}
status: :not_found
 
When participant already exists in the assignment/course
{
  error: "Participant #{params[:user][:name]} already exists for this #{params[:model]}"
}
status: :unprocessable_entity
</pre>
 
==== Update Handle ====
'''Description''': This endpoint allows the user to change their handle name for a given <code>AssignmentParticipant</code>. An <code>AssignmentParticipant</code> is one who is already enrolled in the assignment. A success response renders a JSON with the updated participant details. The user is required to provide a valid and available handle name.
 
'''Path''': POST <code>/participants/change_handle/:id</code>
 
'''Parameters''':
{| class="wikitable" style="width: 100%;
! &nbsp;#&nbsp; !! Parameter !! Expected Value
|-
|-
|1
| Fill testing gaps || Tests were updated after the integration of Participant model with participants_controller
|<code>id</code>
|The id of the <code>AssignmentParticipant</code>
|}
 
'''Request Body''':
<pre>
content:
  application/json:
    schema:
      type: object
      properties:
        participant:
          type: object
          properties:
          handle:
            type: integer
</pre>
 
'''Response''':
 
<pre>
When handle change was successful
{
  "participant": participant,
}
status: :ok
 
When handle is already in use
{
  note: "Handle already in use"
}
status: :ok
 
Failure
{
  error: participant.errors
}
status: :unprocessable_entity
</pre>
 
==== Update authorizations ====
'''Description''': This endpoint allows the user to change the permissions for a given <code>Participant</code>. The appropriate permissions for any participant are <code>[can_submit, can_review, can_take_quiz]</code>. A <code>Participant</code> is one who is already enrolled in an assignment or a course. A success response renders a JSON with the updated participant details and permissions.
 
'''Path''': POST <code>/participants/update_authorizations/:id</code>
 
'''Parameters''':
{| class="wikitable" style="width: 100%;
! &nbsp;#&nbsp; !! Parameter !! Expected Value
|-
|-
|1
| Add comments || Clear and concise comments to explain what each section of the code is doing, why it is doing it, and how it fits into the overall task
|<code>id</code>
|The id of the <code>Participant</code>
|}
|}


'''Request Body''':
== Test Plan ==
<pre>
content:
  application/json:
    schema:
      type: object
      properties:
        participant:
          type: object
          properties:
            can_submit:
              type: boolean
            can_review:
              type: boolean
            can_take_quiz:
              type: boolean
</pre>
 
'''Response''':
 
<pre>
Success
{
  "participant": participant,
}
status: :ok
 
Failure
{
  error: participant.errors
}
status: :unprocessable_entity
</pre>
 
==== Delete ====
'''Description''': This endpoint allows the user to delete an existing participant from an assignment or a course. The user is expected to provide the valid participant ID. The participant is only deleted if they are not part of another team for a different assignment/course. This is to ensure that a participant enrolled in two different teams is not deleted from the list of participants. Deletion is only possible if the participant is only enrolled in only one team. A success response renders a JSON with a confirmation of the deletion.


'''Path''': DELETE <code>/participants/:id</code>
So far we've written individual tests for the model and controller files of the participants functionality. With the goal of this project being the integration of the two, we will look to add some tests which facilitate the combined working of the two files. This might include modifying existing test scenarios as well as writing new ones. We expect the number of tests to go up as well as the overall code coverage to improve after this project.  
 
The existing test suites for the model and controller can be found below.
'''Parameters''':
{| class="wikitable" style="width: 100%;
! &nbsp;#&nbsp; !! Parameter !! Expected Value
|-
|1
|<code>id</code>
|The id of the <code>Participant</code>
|}
 
'''Response''':
 
<pre>
Success
{
  message: "#{participant.user.name} was successfully removed as a participant"
}
status: :ok
 
When the participant is on another team
{
  error: "This participant is on a team"
}
status: :unprocessable_entity
 
Failure
{
  error: "Failed to remove participant"
}
status: :unprocessable_entity
</pre>
 
==== Inherit ====
'''Description''': This endpoint allows the user to copy the existing participants from a course to the provided assignment in a single operation. Before this is carried out, validations are performed on 1) the existence of a course for the provided assignment and 2) non-empty list of participants already registered in the course. After these checks, the participants are copied from the course to the given assignment with the help of a private method <code>copy_participants_from_source_to_target</code>. A success response renders a JSON with a confirmation of the copy.
 
'''Path''': GET <code>/participants/inherit/:id</code>
 
'''Parameters''':
{| class="wikitable" style="width: 100%;
! &nbsp;#&nbsp; !! Parameter !! Expected Value
|-
|1
|<code>id</code>
|The id of the <code>Assignment</code>
|}
 
'''Response''':
 
<pre>
When copy was successful
{
  message: "The participants from #{source.name} were copied to #{target.name}"
}
status: :created
 
When all the participants already existed in the assignment(no-op)
{
  note: "All of #{source.name} participants are already in #{target.name}"
}
status: :ok
 
When there were no participants for the course
{
  note: "No participants were found for this #{source.name}"
}
status: :ok
 
When there is no course for the given assignment
{
  error: "No course was found for this assignment"
}
status: :unprocessable_entity
</pre>
 
==== Bequeath ====
'''Description''': This endpoint allows the user to copy the existing participants from the provided assignment to its associated course in a single operation. Before this is carried out, validations are performed on 1) the existence of a course for the provided assignment and 2) non-empty list of participants already registered in the assignment. After these checks, the participants are copied from the given assignment to its course with the help of a private method <code>copy_participants_from_source_to_target</code>. A success response renders a JSON with a confirmation of the copy.
 
'''Path''': GET <code>/participants/bequeath/:id</code>
 
'''Parameters''':
{| class="wikitable" style="width: 100%;
! &nbsp;#&nbsp; !! Parameter !! Expected Value
|-
|1
|<code>id</code>
|The id of the <code>Assignment</code>
|}
 
'''Response''':
 
<pre>
When copy was successful
{
  message: "The participants from #{source.name} were copied to #{target.name}"
}
status: :created
 
When all the participants already existed in the course(no-op)
{
  note: "All of #{source.name} participants are already in #{target.name}"
}
status: :ok
 
When there were no participants for the assignment
{
  note: "No participants were found for this #{source.name}"
}
status: :ok
 
When there is no course for the given assignment
{
  error: "No course was found for this assignment"
}
status: :unprocessable_entity
</pre>
 
== Test Plan ==


=== Model test suite ===
=== Model test suite ===
Line 413: Line 121:
4. <code>bundle exec rspec spec/models/participants_spec.rb</code><br>
4. <code>bundle exec rspec spec/models/participants_spec.rb</code><br>


More details on the individual tests can be found [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2317:_Reimplement_participant.rb#Testing_Plan here]
====Tests====
 
{| class="wikitable" style="margin-left:40px"
|-
! Test No. !! Description
|-
| 1 || Tests if the team method returns the team of the participant
|-
| 2 || Tests if the name method returns the name of the participant
|-
| 3 || Tests if the fullname method returns the full name of the participant
|-
| 4 || Tests if the handle method returns the handle of the participant
|-
| 5 || Tests if the sort_participants method returns a sorted list of participants in alphabetical order
|-
| 6 || Tests if the sort_participants method returns a sorted list of participants in id order
|-
| 7 || Tests if the topic_name method returns the participant topic name when nil
|-
| 8 || Tests if the topic_name method returns the participant topic name when not nil.
|-
| 9 || Tests if the authorization method returns participant when no arguments are passed.
|-
| 10 || Tests if the authorization method returns reader when no arguments are passed.
|-
| 11 || Tests if the authorization method returns submitter when no arguments are passed.
|-
| 12 || Tests if the authorization method returns reviewer when no arguments are passed.
|-
| 13 || Tests if it returns participant data in the correct format.
|-
| 14 || Test if it exports the details of the participant correctly.
 
|}
 
Previous Participant Model Test Implementation: [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2317:_Reimplement_participant.rb#Testing_Plan here]


=== Controller test suite ===  
=== Controller test suite ===  
Line 466: Line 210:
| 18 || Test to bequeath participants from an Assignment to a Course - Successful inherit from Course to Assignment
| 18 || Test to bequeath participants from an Assignment to a Course - Successful inherit from Course to Assignment
|-
|-
| 19 || Test to destroy participant - Failure as participant to be deleted is on a team
| 19 || Test to destroy participant - Failed to remove participant
|-
|-
| 20 || Test to destroy participant - Successful deletion of a participant
| 20 || Test to destroy participant - Successful deletion of a participant
|-
| 21 || Test to destroy participant - Failure if there is an error in "participant.destroy"
|}
|}


==== Test Screenshot ====
 
[[File:Test.png]]
Previous Participants Controller Test Implementation: [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_E2318:_Reimplement_Participants_Controller#Test_Plan here]
==== Swagger UI Screenshot ====
[[File:Swagger.png]]


== Contributors ==
== Contributors ==
Line 487: Line 227:


== Relevant Links ==
== Relevant Links ==
* '''Github Repository for controller code:''' https://github.com/devashish-vachhani/reimplementation-back-end
* '''Pull Request:''' https://github.com/expertiza/reimplementation-back-end/pull/22
* '''Github Repository for model code:''' https://github.com/amarthyasa/reimplementation-back-end
* '''Testing Walkthrough:''' https://youtu.be/2GeA8PTtzSk
* '''Controller Pull Request:''' https://github.com/expertiza/reimplementation-back-end/pull/22
 
* '''Model Pull Request:''' https://github.com/expertiza/reimplementation-back-end/pull/5
* '''Testing Video:''' https://youtu.be/e8OAOrLi3Cc
* '''Controller Testing video:''' https://drive.google.com/file/d/1gUz2brHpN7ay_YRK6TjdqeifDeUtGQQj/view?usp=share_link
* '''Model Testing video:''' https://drive.google.com/file/d/1VXMF8dbJgjcj68Y9pRTgXg2cJrfL9-_6/view?usp=sharing
* '''VCL Server:''' http://152.7.176.119

Latest revision as of 16:15, 28 April 2023

Background

In expertiza, there are two different models: Course and Assignment. Although an Assignment is a part of a Course, students can participate in a Course or an Assignment independently.

The ParticipantsController provides functionalities for listing the participants of a course or an assignment, adding a participant to a course or an assignment, updating the authorizations of a participant (can_submit, can_review, can_take_quiz), updating the handle of a participant for an assignment, inheriting course participants to its assignment, bequeathing assignment participants to its course and deleting a participant from a course or an assignment.

Project Purpose

The aim of our project is to integrate the reimplemented version of participants_controller with the Participant Model while maintaining the existing functionality of the feature. We plan on restricting all the business logic to the model, which will also handle all of the interactions with the database. The controller, on the other hand, will be responsible only for accepting appropriate input and returning the results in a JSON format. The test suite will be updated accordingly to accommodate the above-mentioned development plan.

Project Design

High-level Design Diagram

The architecture diagram shown below serves the purpose of our high-level design diagram. As seen in the figure, the user interacts with the web client i.e. browser which sends an HTTP request to the web server available in the back-end. The web server is responsible for handling the rails routes corresponding to the RESTful endpoints of the APIs that we have developed. The endpoints then route to the corresponding method in the participants controller where the intended functionality is carried out. For certain APIs, such as inherit, this involves interacting with the participants model and the database to update the state of the system. For other simpler features, such as index, the controller method handles all the processing. The method responds with a JSON structure which is sent back as an HTTP response to the front-end and then returned back to the client.
The diagram lays out the general workflow of a user interacting with the system and helps the viewer understand the responsibilities of the model, controller, and view in our system. Models are responsible for dealing with the business logic of the features and interact with the database for all data operations. Controllers are responsible for taking appropriate input and returning JSON-formatted output without changing any data or the state of the system. Lastly, views are responsible for rendering the output in a user-friendly interface for the client.

Use Case Diagram

The following Use Case Diagram demonstrates the primary functionality relevant to participants for different types of users in the system. We've highlighted three primary users of our system who might use the participants features - instructors/TAs, participants (who are expected to be students), and admins.

Implementation

This project has been split up in two phases, with phase 1 being the re-implementation of the participants model and controller. The second phase of the project focuses on the integration of the newly implemented versions of participants model and controller.
During the first phase, the controller employed an API-first approach while maintaining all the existing functionality in an efficient, robust and simple manner. Specifically for the participants controller, we added seven different API endpoints to extend the current functionalities while modifying the code to support these APIs. For the participants model, we removed all unnecessary functionality and retained only the core business logic for participants. The details for the model changes and new endpoints have been discussed later in this section.
For the second phase, we plan on maintaining the ideology of restricting business logic to the model and API logic to the controller. We will fill in the missing gaps and modify the code after re-implementation to enable integration of the new code. The proposed changes for this phase have been discussed later in this section.

Assumptions

  1. The CourseParticipant and AssignmentParticipant models implement the copy method which copies participants from the course to assignment and vice-versa. This functionality is used in the inherit and bequeath methods.

Phase 1a: Reimplementation of Participants Model

The participants model file participant.rb was re-implemented to include only the necessary business logic and remove unnecessary functionality.
Note: More details on this can be found here.

Task Status Testing
Replaced force_delete method with leave_team method Implemented Completed
mail_assigned_reviewers method was removed Implemented N/A
able_to_review method was eliminated Implemented N/A
email method was removed Implemented N/A

Phase 1b: Reimplementation of Participants Controller

The endpoints implemented as part of this phase have been summarized here. The code for these can be found in the participants_controller.rb file.
Note: Detailed API documentation and other details for these can be found here.

 #  Method Endpoint Description
1 index GET /participants/index/:model/:id returns a list of participants of an assignment or a course
2 create POST /participants/:model/:id creates a participant in an assignment or a course
3 update_handle PATCH /participants/change_handle/:id updates the participant's handle for an assignment
4 update_authorizations PATCH /participants/update_authorizations/:id updates the participant's permissions for an assignment or a course depending on the role
5 delete DELETE /participants/:id deletes a participant from an assignment or a course
6 inherit GET /participants/inherit/:id copies existing participants from a course down to its assignment
7 bequeath GET /participants/bequeath/:id copies existing participants from an assignment up to its course

Current Work

Task Notes
Modify the team method in Participants model The team method uses TeamsParticipant instead of TeamsUser based on E2304
Replace sort_by_name method with sort_participants method in Participants model sort_participants can either sort by id of the participants or name of the corresponding user depending on the parameter passed
Modify destroy in participants_controller The destroy method uses the delete method from the Participants model to check if the participant is on a team or assigned as a reviewer or reviewee before destroying
Fill testing gaps Tests were updated after the integration of Participant model with participants_controller
Add comments Clear and concise comments to explain what each section of the code is doing, why it is doing it, and how it fits into the overall task

Test Plan

So far we've written individual tests for the model and controller files of the participants functionality. With the goal of this project being the integration of the two, we will look to add some tests which facilitate the combined working of the two files. This might include modifying existing test scenarios as well as writing new ones. We expect the number of tests to go up as well as the overall code coverage to improve after this project. The existing test suites for the model and controller can be found below.

Model test suite

The testing framework used here is RSpec. The participants.rb contains many methods and associations with other models. Hence, to test the methods in participants, the other dependent methods have to be stubbed. To deal with the models, dummy models/dummy app can be created which will act as the associated classes. We have created all the required dummy classes by scaffolding them.

To create test fixtures and to build the required models, Factory Bot has been used. Two separate files, factories.rb and factory_bot.rb was created to build the factories. Four participants and other required fields were created as fixtures after which the tests were written.

To run the tests:
1. git clone https://github.com/amarthyasa/reimplementation-back-end/tree/testing_files
2. cd reimplementation-back-end/
3. bundle install
4. bundle exec rspec spec/models/participants_spec.rb

Tests

Test No. Description
1 Tests if the team method returns the team of the participant
2 Tests if the name method returns the name of the participant
3 Tests if the fullname method returns the full name of the participant
4 Tests if the handle method returns the handle of the participant
5 Tests if the sort_participants method returns a sorted list of participants in alphabetical order
6 Tests if the sort_participants method returns a sorted list of participants in id order
7 Tests if the topic_name method returns the participant topic name when nil
8 Tests if the topic_name method returns the participant topic name when not nil.
9 Tests if the authorization method returns participant when no arguments are passed.
10 Tests if the authorization method returns reader when no arguments are passed.
11 Tests if the authorization method returns submitter when no arguments are passed.
12 Tests if the authorization method returns reviewer when no arguments are passed.
13 Tests if it returns participant data in the correct format.
14 Test if it exports the details of the participant correctly.

Previous Participant Model Test Implementation: here

Controller test suite

The testing framework used here is RSpec. The participants_controller.rb has dependencies on models and methods which are yet to be implemented. In the meantime, to test the API, we have used stubs and mocks. We have created some new models and added some associations in them which were required for stubbing.

To run the tests:
1. git clone https://github.com/devashish-vachhani/reimplementation-back-end
2. cd reimplementation-back-end/
3. bundle install
4. bundle exec rspec spec/requests/api/v1/participants_spec.rb

Tests

Test ID Test Description
1 Test to check index with Assignment model and id - Lists Participants
2 Test to check index with Assignment model and id - Invalid Parameters
3 Test to create a new participant - With non existing User
4 Test to create a new participant - When participant already exists
5 Test to create a new participant - Successful creation of participant
6 Test to update handle request for a participant - When handle name already exists
7 Test to update handle request for a participant - Successful update of participant handle
8 Test to update handle request for a participant - Failed update of participant handle
9 Test to update authorizations request for a participant - Successful update of authorizations of a participant
10 Test to update authorizations request for a participant - Failed update of authorizations of a participant
11 Test to inherit participants from a Course to an Assignment - Failure in inherit because Assignment has no Course
12 Test to inherit participants from a Course to an Assignment - Failure for when there are no participants to inherit
13 Test to inherit participants from a Course to an Assignment - Checks if participants in Assignment is already in Course
14 Test to inherit participants from a Course to an Assignment - Successful inherit from Course to Assignment
15 Test to bequeath participants from an Assignment to a Course - Failure in bequeath because Course has no Assignment
16 Test to bequeath participants from an Assignment to a Course - Failure for when there are no participants to inherit
17 Test to bequeath participants from an Assignment to a Course - Checks if participants in Course is already in Assignment
18 Test to bequeath participants from an Assignment to a Course - Successful inherit from Course to Assignment
19 Test to destroy participant - Failed to remove participant
20 Test to destroy participant - Successful deletion of a participant


Previous Participants Controller Test Implementation: here

Contributors

  1. Saksham Pandey (spandey5@ncsu.edu)
  2. Devashish Vachhani (dvachha@ncsu.edu)
  3. Karthik K Jayakumar (kkunnum@ncsu.edu)

Mentor: Rucha Kolekar (rbkoleka@ncsu.edu)

Thanks to participants model re-implementation team

Relevant Links

Retrieved from "https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2023_E2342:_Reimplement_Participants_Model_and_Controller&oldid=150253"