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

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

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.

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.
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.
15	Tests if it returns participant data in the correct format.
16	Test if it exports the details of the participant correctly.

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

This code is testing a method team and is expected to return the team associated with the participant. It is done 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 delete 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. The allow method is used to set up mock behavior for the team and participant objects in the third test.

Test 5

This is a test block for the name method of the participant object. The test checks if calling 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 full 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 the test suite for the authorization method of the Participant class. The authorization method returns a string representing the participant's authorization level based on their permissions to submit, review, and take quizzes. Each test case checks if the method returns the expected authorization level when certain permissions are allowed or disallowed for the participant. The first test case tests the default authorization level of the participant when no permissions are set. The second and third test cases test for reader and submitter authorization levels, respectively, when the corresponding permissions are set. The fourth test case tests for reviewer authorization level when only the can_review permission is set.

Tests 15 to 16

The first block of code describes a unit test for the export_fields method of the Participant class. It sets up a hash of options for the method and expects it to return an array of field names in a specific order. The second block of code describes a unit test for the export method of the Participant class. It sets up a parent_id variable, a csv array, and some options, and then sets up mock responses for the where and user methods to simulate a participant being found. It expects the export method to return an array of arrays representing the data for the found participant, in the order specified by the export_fields method.

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/1VXMF8dbJgjcj68Y9pRTgXg2cJrfL9-_6/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)