CSC/ECE 517 Fall 2024 - E2474. Reimplement student quizzes controller.rb: Difference between revisions

From Expertiza_Wiki
Jump to navigation Jump to search
Line 44: Line 44:
<strong>Solution:</strong> We will move this method into a separate concern that is included in this controller. This can be used in other controllers as well.
<strong>Solution:</strong> We will move this method into a separate concern that is included in this controller. This can be used in other controllers as well.


[[File:E2474_renaming_variables.png|600px]]
[[File:E2474_calculate_score_new.png|600px]]


=== Renaming Method and Variable Names ===
=== Renaming Method and Variable Names ===

Revision as of 01:31, 12 December 2024

This wiki page is about E2474 Phase 2 for Expertiza.

Background

Expertiza is a Ruby on Rails based open source project. The Expertiza project is software for creating reusable learning objects through peer review. It also supports team projects and the submission of almost any document type, including URLs and wiki pages. The goal is to foster team collaboration through projects and provide a robust way to give feedback for these projects.

Problem Statement

For this project, we are expected to reimplement the student_quizzes_controller.rb file in the reimplementation-backend repository of Expertiza. This controller handles scoring, creating, and recording responses for quizzes that are done by students or reviewers for an assignment. The main issue with the previous implementation is that it violates several Rails design principles such as DRY violations. Along with this, various other issues that need to be addressed include code repetition, unclear method comments, and ambiguous variable names. The overall idea of this project is to ensure that we maintain the previous functionality while adhering to the best design practices.

Specific Issues

  • Single-Responsibility Principle - Various functionalities are done in the student_quizzes_controller.rb that should be deferred to other models or controllers.
  • DRY Violations - There is a good amount of code repetition in the code that could be consolidated to a method.
  • Unclear Method and Variable Names - There are ambiguous methods names and variable names that should be changed. We can also add method comments to help explain functionality.

Design Plan

Single-Responsibility Principle

calculate_score

This method gets a response map and then gets the score from that response map. We can instead ask the ResponseMap model to get this information.

Solution: Instead of response_map.score, we create a get_score method in ResponseMap model.

process_answers

This method attempts to edit the submitted_answer field in ResponseMap. This should be done by ResponseMap model instead of our controller.

Solution: We will fully move the process_answers method into the ResponseMap model.

check_instructor_role

The goal of this method is to get the role ID of the user to make sure they are an instructor. We want to let the Role model check this instead of checking it in the controller.

Solution: Instead of "current_user.role_id == 2", we will make use of the instructor? method in Role to check if the current user is an instructor.

Other methods

  • Several methods could be moved into the model classes in adherence to MVC architecture. This includes build_response_map, etc.

DRY Violations

find_resource_by_id

This is a method that is frequently called in this controller. We plan to separate this functionality into a concern or a shared utility function.

Solution: We will move this method into a separate concern that is included in this controller. This can be used in other controllers as well.

Renaming Method and Variable Names

  • Rename the methods for assign_quiz_to_student and submit_answer to clarify their purpose. We can also add method comments to help with this.
  • Refactor variable names to better reflect their purpose. The image below shows that model is not the best name along with find_resource_by_id

Main Methods to Create or Enhance

 #  Method Purpose Description Commit
1 calculate_score , process_answers Ensure MVC compliance and adherence to the Single-Responsibility Principle Move both calculate_score and process_answers to the ResponseMap model, allowing the controller to focus only on handling requests and delegating logic to models. calculate_score Commit: https://github.com/neerua08/reimplementation-back-end/commit/c1dd8c817d842df0817bde8fa408d760fb0a6fdd

process_answers Commit: https://github.com/neerua08/reimplementation-back-end/commit/dacecb623bbfa8cfff89a3c6deaa8affd8eaf0f5

2 find_resource_by_id Reduce DRY violations Implement this as a shared utility function to eliminate duplicate code and streamline resource retrieval in the controller. Commit: https://github.com/neerua08/reimplementation-back-end/commit/0dc53dd139caa7d18d380c98d51578d98911ef3b
3 check_instructor_role Improve code readability Move the check_instructor_role method to the Role model, ensuring that role-related logic resides within the model rather than the controller. Commit: https://github.com/neerua08/reimplementation-back-end/commit/55d860747ff08506aea134e182d98119eadc58e9
4 build_response_map Improve modularity Transfer these methods from the controller to appropriate model classes, which aligns with the MVC pattern and keeps controller methods concise. Commit: https://github.com/neerua08/reimplementation-back-end/commit/9b3c0342c6a407766e38ea2cb860434cbf10efcd
5 assign_quiz_to_student , submit_answer Improve code readability Rename these methods to more descriptive names and add comments to explain functionality, making the codebase easier to understand and maintain. Commit: https://github.com/neerua08/reimplementation-back-end/commit/865857ea2dcc0eb73d87cff87e1610bf8ba6d142

Implementation

Student quizzes Controller contains APIs which allows the instructor to create a new quiz and perform other CRUD operations on quiz. It allows the students to submit answers to the quizzes and check their scores. Our implementation plan includes reimplementing existing methods and adding new methods. Student quizzes Controller does now adhere to best practices while ensuring that existing functionalities remain unchanged.


Test Plan

As we are reimplementing this file from scratch, we plan to do some manual testing to verify our code. If time permits, we can add some automated tests. Currently, we plan to use a variety of tools to test our code including:

  • Postman - Test our API calls for the controller to ensure their functionality. The main purpose is to validate the behavior of the controller. This can be done by testing all relevant CRUD operations for quiz creation, submission, and scoring, verifying that the controller responds with appropriate status codes, ensure that all input validations are working as expected including edge cases, and validate that the controller adheres to any role-based access restrictions.
  • Automated RSpec Tests - Test the various methods in our controller to determine if they are functioning as expected. The main purpose is to verify the internal logic of the controller and related methods ensuring they are functioning as expected. This can be done by creating unit tests for methods within the controller especially methods that will be refactored or moved to the model, creating model tests for if any logic is moved to the models to verify that the new functionality works correctly, and create controller tests to ensure that the controller actions work as expected like assigning quizzes to students, submitting answers and recording results, and calculating scores correctly.
  • Test Coverage - Using SimpleCov to ensure sufficient test coverage of all key methods and code paths, preventing any untested code from being deployed. We can do this by integrating SimpleCov to measure code coverage across the entire application, create coverage goals and aim for like a high code coverage (e.g., 90% or higher) to ensure all key methods in the controller and related models are thoroughly tested, monitor coverage reports to identify any untested methods or areas of the codebase and add tests for those areas as needed, and refactor based on coverage so if we see significant gaps in test coverage, we can refactor the tests or implementation to ensure better coverage.

We don't plan on adding new scenarios but instead we plan on retesting scenarios: creating a new student quiz, handling invalid student quiz creation, calculating quiz score, assigning quiz to student, submitting quiz answers, and updating a student quiz to see if those scenarios still work when we reimplement student_quizzes_controller.rb as a whole. We might add multiple scenarios as we go.

Team Members

  1. Akhilesh Neeruganti (asneerug@ncsu.edu)
  2. Krishna Pallavalli (kpallav@ncsu.edu)
  3. Aarya Rajoju (arajoju@ncsu.edu)

Mentor: Richard Li (rli14@ncsu.edu)

Relevant Links