CSC/ECE 517 Spring 2023 - E2317: Reimplement participant.rb

This wiki page is for the description of changes made under E2317 OSS assignment for Spring 2023, CSC/ECE 517

About Expertiza

Expertiza is an open source project based on Ruby on Rails framework. It is a web application which is maintained collectively by NC State faculty and students which allows instructors to create new assignments and customize new or existing assignments. It also allows the instructors to create a list of topics the students can sign up for. Students can form teams in Expertiza to work on various projects and assignments. Students can also peer review other students' submissions. Expertiza supports submission across various document types, including the URLs and wiki pages.

Overview of the Classes

participant.rb

The participant.rb is a model class that has many associations with other models. There are many methods present in it such as fullname, name, team and handle. There is a method called delete which checks for any associations before performing the delete operation. The other methods include topic_name, mail_assigned_reviewers, able_to_review, email, authorization and self.sort_by_name. There is one more method self.export that returns the information of the participant as a CSV file.

Backgroud of the Project

The participant.rb model has many new changes to be implemented. The reimplementation has to make sense and while checking the original model, we realised that some of the methods were irrelevant to participants model and that it has to be implemented in some other model. The changes mainly dealt with removing, merging and replacing methods to segregate methods with a single functionality relevant to participants model. Tests were written for all of the methods that were introduced and modified. Existing tests for the methods that were unchanged were run to ensure proper functioning of the model. Comments are added to each method to enhance readability. Further information about the reimplementations are discussed below.

Design Decisions

The following changes were reimplemented in the participant.rb

Tasks	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
Merged export and export_fields methods	Implemented	To be completed

Replaced force_delete Method with leave_team Method

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.

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.

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.

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

Merging two functions isn't a good programming practice as by doing so testing and debugging the function became a hassle and made it difficult to fix errors in code. Instead, it is generally considered a best practice to break down larger functions into smaller, more manageable ones, which aligns with the "Single Responsibility Principle". This principle suggests that a function or module should have only one reason to change. By breaking down larger functions into smaller ones, the resulting code became more modular, easier to read, and simpler to maintain.

Testing Plan

The reimplementation codebase originally used Minitest to test the included models: assignment.rb, role.rb, and user.rb. But since Expertiza was originally tested with RSpec, we used RSpec to test out model. 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.

4 participants and other required fields were created as fixtures after which the tests were written.

Note

The dummy classes that were created and other dependencies that were specifically installed for testing have been pushed to a different branch to not let the main codebase clutter with empty models.

To run the tests, kindly pull from the testing_files branch of the repository and run bundle install to install dependencies like RSpec and Factory Bot.

Tests

Test No.	Description
1	Tests if the team method returns the team of the participant
2	Tests if the leave_team method deletes a participant if no associations exist and force is nil
3	Tests if the leave_team method deletes a participant if no associations exist and force is true
4	Tests if the leave_team method deletes a participant with associations and force is true and there are multiple team users
5	Tests if the name method returns the name of the participant
6	Tests if the fullname method returns the full name of the participant
7	Tests if the handle method returns the handle of the participant
8	Tests if the sort_by_name method returns a sorted list of participants in alphabetical order
9	Tests if the topic_name method returns the participant topic name when nil
10	Tests if the topic_name method returns the participant topic name when not nil.
11	Tests if the authorization method returns participant when no arguments are passed.
12	Tests if the authorization method returns reader when no arguments are passed.
13	Tests if the authorization method returns submitter when no arguments are passed.
14	Tests if the authorization method returns reviewer when no arguments are passed.

The test which checks if participant and team is deleted if only one participant is on a team is deleted since that implementation has been removed from the model.

Test 1

The test method ensures that the team method of the Participant class returns the correct team object for a given participant. It does this by mocking the behavior of other objects that the team method relies on, specifically a user object and a team_user object. By mocking these dependencies, the test can focus on testing the behavior of the team method in isolation.'

Tests 2 to 4

This is a set of tests for the leave_team method of a participant object. The first two tests check that a participant can be deleted if there are no associations, with and without the force parameter. The third test checks that a participant can be deleted even if there are associations with multiple team_users, but only if the force parameter is true. We mock the behavior of the team and participant object in the third test.

Test 5

This is a test block for the name method of the participant object. The test checks if calling the name on a participant object returns the expected name of 'Jane'. If the method is working correctly, the test should pass.

Test 6

This is a test block for the fullname method of the participant object. The test checks if calling the name on a participant object returns the expected name of 'Jane Doe'. If the method is working correctly, the test should pass.

Test 7

This code defines a test suite for the handle method of the participant object. The method takes a single parameter (nil in this case). The test case verifies that the handle method returns the string 'handle' when called with a nil argument.

Test 8

This is a test case for the sort_by_name method of the Participant class. The test checks whether the method returns a sorted list of participants in alphabetical order by their names. The test creates an array unsorted of three participant objects with unordered names and creates another array sorted of the same participants with names sorted alphabetically. The sort_by_name method is called with the unsorted array as its argument and the test expects the result to be the sorted array. If the method is implemented correctly, it should return the participants sorted by name in alphabetical order.

Tests 9 to 10

This is a test suite for the #topic_name method of the Participant class. The first example checks that when the participant's topic attribute is nil, the method should return a default string. The second example checks that when the participant's topic attribute is not nil, the method should return the name attribute of the associated topic object. This is done by using the allow method to stub the topic method of the participant object and return a mock topic object with a name attribute of 'Hello world!'. Overall, these examples test the behavior of the #topic_name method in returning the correct string depending on the presence or absence of a topic object associated with the participant.

Tests 11 to 14

This is a test suite for the authorization method defined in a class, which is not shown in the code snippet provided. The purpose of this method is to determine the authorization level of a participant, based on the values returned by three different methods can_submit, can_review, and can_take_quiz, which are presumably defined elsewhere in the class. The test suite has four test cases, each testing a different combination of authorization levels based on the values returned by the three methods. For each test case, the allow method is used to set the return value of each of the three methods to a specific value, and the expect method is used to verify that the correct authorization level is returned by the authorization method. The four possible authorization levels are "participant", "reader", "submitter", and "reviewer". The tests verify that the authorization method returns the expected value for each combination of authorization levels based on the values returned by the three methods. The tests are using the expect method to make assertions about the return value of the authorization method for each combination of authorization levels.

Future Work

1. Testing for the merged method, export, has to be done.

2. Response method has to be tested.

Relevant Links

Github repository: https://github.com/amarthyasa/reimplementation-back-end/tree/main
Github repository branch for testing: https://github.com/amarthyasa/reimplementation-back-end/tree/testing_files
Pull request: https://github.com/expertiza/reimplementation-back-end/pull/5
Testing video: https://drive.google.com/file/d/1F51cv5deyxaw2YIhbbRcUTq_woIpwJle/view?usp=sharing

Team

Mentor

Rucha Kolekar

Student Team

Amarthya Sivakumar Annu (asivaku5@ncsu.edu)
Ajay Krishna Raveendar (araveen@ncsu.edu)
Kiron Jayesh (kjayesh@ncsu.edu)