CSC/ECE 517 Spring 2023 E2310

About Expertiza

Expertiza is an assignment/project management portal that can be used by both instructors and students for collaborative learning and feedback. It is an open-source project based on Ruby on Rails framework. It allows the instructors not only to create and customize new or existing assignments but also to create a list of topics the students can sign up for. Students can form teams to work on various projects and assignments. Expertiza also lets students peer-review other students' submissions, enabling them to work together to improve others' learning experiences.

Team

Mentor

• Jialin Cui

Team Members

• Aman Waoo
• Girish Wangikar
• Pranavi Sharma Sanganabhatla

Description and Testing

Our project deals with refactoring the answer.rb file. The code is responsible for doing the following tasks:

• Get all answers for each question and send them to summarization WS.
• Get average scores and a summary for each question in a review by a reviewer.

Files Involved

• answer.rb
• answer_spec

Running Tests

To successfully run answer_spec on the local machine, please run the below rspec command.

  rspec spec/helpers/answer_spec.rb

Project Description

The objective of the project is to refactor the following Ruby on Rails model classes in the existing project:- SignUpTeam, SignUpTopic and SignUpSheet. SignUpTeam model class represents a signed-up team for a particular sign-up topic in a specific assignment. SignUpTopic model class represents a topic that can be signed up for in a course assignment. SignUpSheet class stores the logic for creating a signed_up_team for a topic for a particular assignment. This class is being used as a module having all class methods.

The task is to refactor the existing code present in these model files and implement them in a new repository. Since the project is implemented from scratch, there are various aspects of the project that have to be implemented and therefore unit test cases are implemented to test the implementation.

Issue Description

• The SignedUpTeam class has methods that handle multiple responsibilities, including finding participants and teams, releasing topics, and removing signed up teams. This violates the single responsibility principle and makes the class harder to understand and maintain.
• Some of the queries in the class use complex SQL statements and multiple joins, which can make them hard to read and understand. These complex SQL queries in the code could be simplified and made more readable by using ActiveRecord's query interface instead.
• The same code is repeated in multiple methods, such as the code to find signed up teams for a given topic. This violates the Don't Repeat Yourself (DRY) principle and can make the code harder to maintain.

• answers_by_question_for_reviewee_in_round:

 1. This method joins the responses, answers, response_maps, and questions table. 
 2. Then it applies a where clause to filter the results based on the given assignment_id, reviewee_id, q_id, and round parameters. 
 3. It retrieves answers and comments columns from the combined table. 

Code Snippet: scope :by_question_for_reviewee_in_round, -> (assignment_id, reviewee_id, q_id, round) do

   joins(response: {map: :reviewer})
     .joins(:question)
     .where("review_maps.reviewed_object_id = ? AND
             review_maps.reviewee_id = ? AND
             answers.question_id = ? AND
             responses.round = ?", assignment_id, reviewee_id, q_id, round)
     .select(:answer, :comments)
 end

• answers_by_question:

 This method joins the questions, answers, responses, and response_maps table. 
 Then it applies a where clause to filter the results based on the given q_id and assignment_id. 
 It retrieves the distinct answers and comments columns from the combined table. 

Code Snippet: scope :by_question, -> (assignment_id, q_id) do

   joins(response: {map: :reviewer})
     .joins(:question)
     .where("review_maps.reviewed_object_id = ? AND
             answers.question_id = ?", assignment_id, q_id)
     .select(:answer, :comments)
     .distinct
 end

• answers_by_question:

 This method joins the responses, answers, response_maps, and questions table.  
 Then it applies a where clause to filter the results based on the given assignment_id, reviewee_id and q_id.  
 It retrieves answers and comments columns from the combined table.

Code Snippet: scope :by_question, -> (assignment_id, q_id) do

   joins(response: {map: :reviewer})
     .joins(:question)
     .where("review_maps.reviewed_object_id = ? AND
             answers.question_id = ?", assignment_id, q_id)
     .select(:answer, :comments)
     .distinct
 end

The test is to see when the criteria input is not nil, the method gives the right output, which is to get a two-digit round score. The criteria input was defined as question in mock section. Code Snippet:

   context 'when criteria not nil' do
     it 'get 2 round_score  ' do
       expect(@summary.calculate_round_score(avg_scores_by_criterion, question)).to be_within(0.01).of(2.345)
     end
   end
 end

• calculate_avg_score_by_round

This test is to see the method round an average number up to Two-digit. The input of avg_scores_by_criterion was given as 2.345, and we tested here that it gives two-digit round number as 2.35. Code Snippet:

  describe '#calculate_avg_score_by_round'do
   context 'when avg_scores_by_criterion available' do
     it 'gives 2 round value' do
       expect(@summary.calculate_avg_score_by_round(avg_scores_by_criterion, question)).to eq(2.35)
     end
   end
  end

Test Execution

We divided the work among the teammates and started tackling the problems. We stubbed the data using factory and mocked the method calls which were being done internally to get the desired output from the methods that were calling other methods internally.

Test Coverage

The summary helper spec file is newly created. This project increased testing coverage by 72.86% according to simplecov test.

Test Plan

We have implemented test cases using RSpec for different validation checks for both sign_up_team.rb and sign_up_topic.rb. The other test cases include 'create' tests that validate whether the utility methods can create the records in the table as expected. Moreover, 'update' test cases are included to validate whether the modifications are updated in the table. Finally, we perform 'destroy' tests to validate whether the record is deleted from the table. We also added unit tests that validate other instance methods, such as format_for_display, in both SignUpTeam and SignUpTopic model classes. We created helper stubs for the new methods yet to be implemented to perform the testing process smoothly. We have attached the unit test assessment video as shown here

Future Plan

The future scope of this project is to implement waitlist.rb model class that handles the functions related to adding/removing sign up teams to the waitlist for each topic. There are other instance methods in both sign_up_team.rb and sign_up_topic.rb that requires implementation. But, since they are dependent on other model classes, we have added them to our TODO list to implement them in the future.

Conclusion

While we tried to test all the methods in the summary_helper.rb class, we faced some blockers. All the blockers are described below:-

• summarize_sentences method

summary_webservice_url: 'http://peerlogic.csc.ncsu.edu/sum/v1.0/summary/8/lsa' This URL is being used in the summary_helper.rb file and we were not able to mock it. It's giving us bad gateway error while we try to hit that url.

• summarize_reviews_by_reviewee method

In this method we found out in the loop, questions[round] is not the correct way of passing the individual question since questions is an array and use 0 based indexing. Whereas in the above logic it is being treated as a hash.

• summarize_reviews_by_reviewee_question method

This method uses the instance variables from a different method(summarize_reviews_by_reviewee) which are not being passed as arguments to this method. Technically this type of initialization is bad coding practice and hence needs refactoring.

We tested all other remaining methods in the summary_helper.rb class. All the unit tests passed and the methods were working as expected. We tried to cover corner cases but there is room for some improvement.

Test Plan

We have implemented test cases using RSpec for different validation checks for answer.rb. The other test cases include 'create' tests that validate whether the utility methods can create the records in the table as expected. Moreover, 'update' test cases are included to validate whether the modifications are updated in the table. Finally, we perform 'destroy' tests to validate whether the record is deleted from the table. We also added unit tests that validate other instance methods, such as format_for_display, in both SignUpTeam and SignUpTopic model classes. We created helper stubs for the new methods yet to be implemented to perform the testing process smoothly. We have attached the unit test assessment video as shown here

Future Plan

The future scope of this project is to implement waitlist.rb model class that handles the functions related to adding/removing sign up teams to the waitlist for each topic. There are other instance methods in both sign_up_team.rb and sign_up_topic.rb that requires implementation. But, since they are dependent on other model classes, we have added them to our TODO list to implement them in the future.