CSC/ECE 517 Spring 2024 - E2403 Mentor-Meeting Management

From Expertiza_Wiki
Jump to navigation Jump to search

Background

Expertiza is an open-source course management web application, that is maintained by students and teaching staff across NC State and other universities. Specifically, Expertiza is used as a platform to help students learn how to work collaboratively on large Object Oriented Programming Assignments. If you would like to learn more about Expertiza please check either the wiki here, or the GitHub page here. For our project in particular we were tasked with improving the mentor management system on Expertiza.


What is a Mentor?

On Expertiza some users are known as mentors. These mentors can both be added to teams manually and automatically assigned if the assignment moderator chooses to select an option where mentors are automatically assigned to teams above 50% capacity. In practice, this means that if you have a max team size of 3, and 2 teammates have been added to team X then team X will automatically be given a mentor.

Problem Statement

The review_mapping_controller presents a challenge due to its length, complexity, and sparse comments, making it difficult for developers to grasp its functionality efficiently. To address this, the controller should undergo a comprehensive refactoring process aimed at breaking down lengthy methods into smaller, more manageable pieces. This entails decomposing intricate logic into modular components, each responsible for a specific task or subtask within the overall functionality. Moreover, the refactoring effort should target instances of code duplication, consolidating repeated code segments into reusable functions or utility methods to enhance maintainability and reduce the risk of errors. By systematically restructuring the controller codebase and improving its documentation, developers can gain a clearer understanding of its inner workings, facilitating easier maintenance, debugging, and future enhancements.

Tasks

-Refactor the long methods in review_mapping_controller.rb like assign_reviewer_dynamically, add_reviewer, automatic_review_mapping, peer_review_strategy, etc. -Rename variable names to convey what they are used for.
-Replace switch statements with subclasses methods.
-Create models for the subclasses.
-Remove hardcoded parameters.
-Add meaningful comments and edit/remove/do not unnecessary comments.
-Try to increase the test coverage.

Phase 1

For Phase 1 of the project we have focused working on the below mentioned issues.
-Refactor assign_reviewer_dynamically function
-Corresponding changes to the tests for assign_reviewer_dynamically
-Refactor add_reviewer function
-Corresponding changes to the tests for add_reviewer
-Correct comments and add additional comments
-Methods are named descriptively to indicate their purpose
-Fixed Code climate issues

Phase 2

For Phase 2 of the project we plan working on the below mentioned issues.
-Refactor automatic_review_mapping function
-Refactor peer_review_strategy function
-Replace switch statements with subclasses methods
-Increase the test coverage
-Remove hardcoded parameters
-Create models for the subclasses

Implementation

Phase 1

add_reviewer

The changes made to the `add_reviewer` method can be checked in the commit - https://github.com/NidhayPancholi/expertiza/commit/b325810d67da2a03d3ccb15458926d0049fdb9eb. The changes are described descriptively below.:

- Refactored the `add_reviewer` method to focus on single tasks per method, enhancing code readability and maintainability.
- Extracted the functionality to find a user's ID by name into a separate method named `find_user_id_by_name`.
- Separated the logic to check if a user is trying to review their own artifact into its own method named `user_trying_to_review_own_artifact?`.
- Abstracted the process of assigning a reviewer to the assignment into a method named `assign_reviewer`.
- Created a method named `registration_url` to generate the registration URL for the assignment based on provided parameters.
- Divided the code to create a review response map into a separate method named `create_review_response_map`.
- Extracted the logic to redirect to the list mappings page after adding the reviewer into its own method named `redirect_to_list_mappings`.
- Added descriptive comments to each method to explain its purpose and functionality clearly.

assign_reviewer_dynamically

The changes made to the `assign_reviewer_dynamically` method can be checked in the commit - https://github.com/NidhayPancholi/expertiza/commit/30a3625d4188e56a58e4b6472c52b60bbfb83df5. The changes are described descriptively below:

- Restructured the `assign_reviewer_dynamically` method to perform single tasks per method, improving code organization and readability.
- Extracted the functionality to find the assignment participant into a separate method called `find_participant_for_assignment`.
- Abstracted the logic to handle errors when no topic is selected into a method named `topic_selection_error?`.
- Created a method named `dynamically_assign_reviewer` to handle the process of dynamically assigning a reviewer based on the assignment type.
- Separated the logic to assign a reviewer when the assignment has topics into a method named `assign_reviewer_with_topic`.
- Developed a method called `select_topic_to_review` to handle the selection of a topic for review.
- Extracted the logic to assign a reviewer when the assignment has no topics into a method named `assign_reviewer_without_topic`.
- Created a method named `select_assignment_team_to_review` to handle the selection of an assignment team for review.
- Abstracted the process to redirect to the student review list page into a method called `redirect_to_student_review_list`.
- Added clear comments to each method to explain its purpose and functionality effectively.

Changes to the spec file

The changes made to the test files are described below and can be found in the commit - https://github.com/expertiza/expertiza/commit/7c08070f0c2c000e64e55561b882e44fc81bc98f:

- Updated the `ReviewMappingController` spec file.
- Added a test case in the `ReviewMappingController` spec file for the `add_reviewer` method to ensure correct behavior when a team user exists and `get_reviewer` method returns a reviewer.
- Adjusted the expectation in the `assign_reviewer_dynamically` test case to match the corrected error message in the controller. Specifically, removed the extra space from the expected error message to align with the actual error message generated by the controller.
- Ensured that all test cases are descriptive and cover the relevant scenarios for each method.
- Verified that the test cases accurately reflect the behavior of the controller methods after the code changes.

Test Plan

We plan on adding more tests, increasing the test coverage in Project 4.

In our Test-Driven Development (TDD) endeavors, our team would strategically adopt Mustafa Olmez's meticulously crafted test skeletons. These meticulously designed skeletons will serve as invaluable blueprints, delineating the essential tests necessary for our unit. By integrating these meticulously designed test skeletons into our workflow, we conduct comprehensive testing of our controller module. This method would enable us to thoroughly explore the functionality of our controller, ensuring meticulous examination and validation of its behavior. Incorporating these test skeletons will not only establish a sturdy framework for our unit tests but also elevate the overall quality and dependability of our codebase.

Test Plan

Our Test Plan includes test for review_mapping_controller.rb file for the following functions:

1. Test `action_allowed?` method:

  - Test when the action is 'add_dynamic_reviewer'.

  - Test when the action is 'show_available_submissions'.

  - Test when the action is 'assign_reviewer_dynamically'.

  - Test when the action is 'assign_metareviewer_dynamically'.

  - Test when the action is 'assign_quiz_dynamically'.

  - Test when the action is 'start_self_review'.

  - Test when the action is not any of the allowed actions for different roles.

2. Test `add_calibration` method:

  - Test when the participant is already assigned.

  - Test when the participant is not assigned.

  - Test when a calibration map already exists.

  - Test when a calibration map does not exist.

  - Test redirection to the response creation page.

3. Test `select_reviewer` method:

  - Test when called with a valid contributor_id.

  - Test when called with an invalid contributor_id.

4. Test `select_metareviewer` method:

  - Test when given a valid response map id.

  - Test when given an invalid response map id.

5. Test `add_reviewer` method:

  - Test when the reviewer is not assigned to review their own artifact.

  - Test when the reviewer is assigned to review their own artifact.

  - Test when the reviewer is already assigned to the contributor.

6. Test `assign_reviewer_dynamically` method:

  - Test when a topic is selected and review is allowed.

  - Test when no topic is selected and review is allowed.

  - Test when no topic is selected and review is not allowed.

  - Test when a topic is selected and review is not allowed.

  - Test when there are no available topics to review.

  - Test when there are no available artifacts to review.

  - Test when the reviewer has reached the maximum number of outstanding reviews.

7. Test `review_allowed?` method:

  - Test when the reviewer has not reached the maximum number of reviews allowed for the assignment.

  - Test when the reviewer has reached the maximum number of reviews allowed for the assignment.

8. Test `check_outstanding_reviews?` method:

  - Test when there are no review mappings for the assignment and reviewer.

  - Test when there are review mappings for the assignment and reviewer, and all reviews are completed.

  - Test when there are review mappings for the assignment and reviewer, and some reviews are in progress.

9. Test `assign_quiz_dynamically` method:

  - Test when the reviewer has already taken the quiz.

  - Test when the reviewer has not taken the quiz yet.

  - Test when an error occurs during the assignment process.

10. Test `add_metareviewer` method:

   - Test when a metareviewer is successfully added.

   - Test when the metareviewer is already assigned to the reviewer.

   - Test when an error occurs during the process.

11. Test `assign_metareviewer_dynamically` method:

   - Test when there are reviews to Meta review.

   - Test when there are no reviews to Meta review.

   - Test when an error occurs during assignment of metareviewer.

12. Test `get_reviewer` method:

   - Test when the user is a participant in the assignment.

   - Test when the user is not a participant in the assignment.

13. Test `delete_outstanding_reviewers` method:

   - Test when there are outstanding reviewers.

   - Test when there are no outstanding reviewers.

14. Test `delete_all_metareviewers` method:

   - Test when there are metareview mappings to delete.

   - Test when there are unsuccessful deletes.

   - Test when there are no metareview mappings to delete.

15. Test `unsubmit_review` method:

   - Test when the response is successfully unsubmitted.

   - Test when the response fails to be unsubmitted.

16. Test `delete_reviewer` method:

   - Test when the review response map exists and there are no associated responses.

   - Test when the review response map exists but there are associated responses.

   - Test when the review response map does not exist.

17. Test `delete_metareviewer` method:

   - Test when the metareview mapping exists.

   - Test when the metareview mapping does not exist.

19. Test `list_mappings` method.

20. Test `automatic_review_mapping` method.

21. Test `automatic_review_mapping_strategy` method.

22. Test `automatic_review_mapping_staggered` method.

23. Test `save_grade_and_comment_for_reviewer` method.

24. Test `start_self_review` method.

25. Test `assign_reviewers_for_team` method.

26. Test `peer_review_strategy` method.

27. Test `review_mapping_params` method.

Design Pattern

During our code refactoring process, we leveraged various design patterns to enhance readability and maintainability. One commonly applied pattern was "Extract Method," where we identified lengthy and intricate methods and extracted segments of functionality into separate methods. This restructuring made the code more comprehensible and easier to grasp by isolating specific tasks within dedicated methods.

Additionally, we addressed the issue of excessive conditional statements by employing the "Refactoring Conditionals" design pattern. Instead of cluttering the code with numerous conditionals, we refactored by encapsulating the logic within these conditionals into distinct methods. By doing so, we streamlined the code's flow and improved its readability, making it clearer to understand the purpose and execution of each segment.


Relevant Links

Team

Mentor

  • Ananya Mantravadi (amantra)

Team Members

  • Lagani Patel (lpatel)
  • Nidhay Pancholi (nrpancho)
  • Saloni Shah (sshah39)
Retrieved from "https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2024_-_E2403_Mentor-Meeting_Management&oldid=153415"