CSC/ECE 517 Spring 2022 - E2237: Grading audit trail

Topic Overview & Prior Work (E2158)

Feature Overview

E2158 contains detailed information on the previous team's work with this feature.

A summary of the desired functionality is presented below:

Any instructor can assign or edit a grade freely.

There should be a way to track which instructor assigned or edited a grade, along with any comments they wrote justifying that grade.

These things must be recorded in the grading audit trail any time an instructor assigns or edits a grade and its comments:

• id of the instructor
• timestamp

Additionally, any comments written by other instructors should be preserved.

Overview of Major Changes By Previous Team

• A new table was added to the database (grading_history), along with the corresponding model (grading_history.rb) and controller (grading_history_controller.rb).
  • Whenever an instructor submits a new grade, or edits an existing grade, the grading_history_controller saves a new history entry to the database.

• Two models for specific types of histories were added: review_grading_history.rb, and submission_grading_history.rb.

• A view for displaying the grading history of a particular assignment or review was added (grading_histories/index.html.erb).

Files Modified By Previous Team

• \app\controllers\grades_controller.rb
• \app\controllers\grading_histories_controller.rb
• \app\controllers\review_mapping_controller.rb
• \app\helpers\grading_histories_helper.rb
• \app\models\grading_history.rb
• \app\models\review_grading_history.rb
• \app\models\submission_grading_history.rb
• \app\views\assignments\list_submissions.html.erb
• \app\views\grading_histories\index.html.erb
• \app\views\reports\_review_report.html.erb
• \config\routes.rb
• \app\views\assignments\list_submissions.html.erb

Testing By Previous Team

Functional tests were added.

functional tests added to these files
: spec/controllers/review_mapping_controller_spec.rb
: spec/models/grading_history.rb
: spec/controllers/grading_history_controller.rb

A feature test ensuring that a submission's grading history is shown completely, and in chronological order, was added.

feature test handled by these two files
: spec/features/grade_histories_spec.rb
: spec/features/helpers/grade_histories_helper.rb

Issues with Existing Tests

Only review_mapping_controller_spec.rb runs successfully--every other spec file mentioned above crashes.

Problem Statement

There are three areas of focus for our team's project (E2237):

System Crashes and Object Creation

1. We must ensure that the unit tests no longer crash, and that they pass with appropriate coverage.
2. We must ensure that the creation of testing objects, namely, Assignments, and Project Bids, does not cause crashing.

Changes to Grading History View

The grading history table in the view is earmarked for certain changes:

1. Student ID is a redundant field--move it to the page header.
2. Assignment ID is a redundant field--move it to the page header.

Code and Documentation Goals

We must explain changes made to files with diagrams and justifications.

Explanations will be provided from these perspectives:

• data flow
• functions
• code comments

Data Flow and Functionality

Old Data Flow

The existing data flow for the grading history feature for reviews is shown below:

The related table from the database is review_scores.

New Data Flow

The latest flow for the Grading History functionality is shown below:

The primary function of this change is to DRY out the current implementation. The flow shown below tracks the tables where grades and comments(that comprise grading history) are recorded into already existing tables. The newly created table grading_history is linked to the teams table from which comments and grades are drawn. This table then displays these values, thereby completing the functionality when the user clicks on display history. The grading_history table contains the team id and instructor_name

Planned and Completed Work

General Design Goals

Changes to the Grading History Table

The images below reference grading history view issues mentioned above in the Problem Statement.

To DRY the code, we will remove the redundant table data boxed below...

...and we'll move it to the page header:

Behavior Driven Development
BDD Scenarios
Due to the nature of the functionalities that we will be implementing, we will be following a BDD methodology - Our primary intention with this is to focus our refactoring, development and database design efforts to ensure that end-user functionality is implemented fully.
In order to demonstrate this, we have provided our tests ahead of time and will be using them to guide our development efforts.

System Stability: Strategies

The source of crashing issues is currently unknown. To debug this, we will pursue the following:

• Refactor the specs and controllers
  • Ensure DRY principle is followed
  • Improve readability and maintainability
  • Add code comments as needed
• Ensure testing objects do not cause crashes

Documentation

1. Changes to any files will be documented on this page; the programmatical reasoning behind the changes shall be explained, and will be in accordance with the DRY principle.
2. Any changes to the overall program logic and data flow will be illustrated with UML diagrams in this document, along with the reasoning for any such changes.
3. A pull request of the fixed code, fully commented, will be provided in this document.

Implementation

The following is a code snippet of the new view only, the grading history view. Other changes can be seen from the Pull Request linked at the end.

• /app/views/grading_histories/index.html.erb

<% record = @grading_histories[0]
  if record == nil
    receiver = ""
    assignment = ""
  else
    if record.grading_type == "Submission"
      receiver = "of " + Team.where(id: record.grade_receiver_id).pluck(:name).first
      assignment = "for the submission " + Assignment.where(id: record.assignment_id).pluck(:name).first
    else
      receiver = "of " + User.where(id: record.grade_receiver_id).pluck(:fullname).first
      assignment = "for review in " + Assignment.where(id: record.assignment_id).pluck(:name).first
    end

  end
%>
<h1 class="center">Grade History <%= receiver %> <%= assignment %></h1>

<table style="border-collapse:collapse; table-layout:fixed; width:1500px;">
  <thead>
  <tr>
    <th style="padding:10px; border:solid 1.5px black; width:50px; word-wrap:break-word;">Instructor</th>
    <th style="padding:10px; border:solid 1.5px black; width:50px; word-wrap:break-word;">Grade</th>
    <th style="padding:10px; border:solid 1.5px black; width:50px; word-wrap:break-word;">Comment</th>
    <th style="padding:10px; border:solid 1.5px black; width:50px; word-wrap:break-word;">Graded At</th>
  </tr>

  <!--This is the main view of the table. This will add table with either hyperlink or the content nased on the operation. -->
  <tbody>
  <% @grading_histories.each do |record| %>
    <tr>
      <td style="padding:10px; border:solid 1.5px black; width:50px; word-wrap:break-word;"><%= User.where(id: record.instructor_id).pluck(:fullname).first %></td>
      <td style="padding:10px; border:solid 1.5px black; width:50px; word-wrap:break-word;"><%= record.grade %></td>
      <td style="padding:10px; border:solid 1.5px black; width:60px; word-wrap:break-word;"><%= record.comment %></td>
      <td style="padding:10px; border:solid 1.5px black; width:50px; word-wrap:break-word;"><%= record.created_at %></td>
    </tr>
  <% end %>
  </tbody>
</table>

• Screenshot of the Grading History Table

The student ID and the Assignment ID have been moved to the header in accordance with the DRY principle. The redundant fields present in the table have also been removed. We have created a factory for testing grading histories controller and included tests for grading_histories_controller, grades_controller and review_mapping_controller.

Testing

Video Demonstration

Live Demo: Functionality
RSpec Test Demo

Testing Goals and Test Objects

Drawing from the project objectives:

1. Verify that Assignments can be created and are saved to the database.
2. Ensure that Student ID is shown in the header, and verify via manual UI testing
3. Ensure that Assignment ID is shown in the header, and verify via manual UI testing
4. Finally, verify that tests can be run without crashing the system.

RSpec Unit Tests

Test cases provided here, will add RSpec code blocks for the final submission

• Factory

#Used for Grading Histories Controller Spec
factory :grading_history, class: GradingHistory do
    id 1
    instructor_id 6
    assignment_id 1
    grading_type 'Submission'
    grade_receiver_id 1
    grade 100
    comment 'Good work!'
end

• Assignments

Scenario: Assignment Creation with all fields 
 Given: Logged in as an Instructor/Admin
  When: Create Assignment with all the necessary fields
   Then: Assignment is saved in the database

Scenario: Duplicate Assignment Creation with all fields 
 Given: Logged in as an Instructor/Admin
  When: Create Assignment with all the necessary fields
   Then: Assignment already exists message is shown

Scenario: Assignment Creation without all fields 
 Given: Logged in as an Instructor/Admin
  When: Create Assignment without all the necessary fields
   Then: Message to input fields is shown

• Grading Histories

Scenario: Grading History creation
Given: A team exists for a particular assignment and has a submission
When: An instructor assigns a grade for that submission
Then: The grading history entry is created

• Review Mapping

Scenario: Save Reviewer Grade and Comment
Given: A student has given a review for a submission
When: An instructor assigns a grade for the review
Then: The assigned grade and the accompanying comment are saved

• Grade

Scenario: Save Grade and Comment for Submission
Given: A team has made a submission for an assignment
When: An instructor assigns a grade for the submission
Then: The assigned grade and the accompanying comment are saved

Manual UI Tests

• Student ID in header

Scenario: Student ID/Team ID (Receiver_ID) in grading history view 
Logged in as an Instructor/Admin
  On Assignment page, click on Grading History
   Resulting Grading History Table is shown
    Receiver ID appears in the header, not in any table columns

• Assignment ID in header

Scenario: Assignment ID in grading history view 
Logged in as an Instructor/Admin
  On Assignment page, click on Grading History
   Resulting Grading History Table is shown
    Assignment ID appears in the header, not in any table columns

Regression Testing

In order to ensure complete coverage, testing of the changes done between the end of last semester and this project will be done to ensure that old test cases still pass.

1. Get the specific format requirement for the title, and assert that it's there. Ensure that this doesn't appear anywhere else (possible via ensuring count is 1)
2. Procure specific required column width, and assert that this is the value in the file (the constant)

Conclusions and Future Work

Comprehensive Testing and Scope

• Initial Thoughts: Current code coverage cannot be determined due to a combination of missing tests and simulation crashes. This will need to be fixed to enable monitoring of regular metrics, and adding comprehensive tests that target full code coverage.
• TA Grade Editing Problems: The current version of beta branch has an issue wherein grades that have already been assigned cannot be changed by any TAs. This issue has been brought to the attention of the Expertiza team.

Conclusion

• Functionality: The functionality regarding grading changes/trails has been demonstrably completed; Instructors can change grades for their assignment submissions, and the changes are reflected in the enw created Grading History Table.
• Appearance: The requested layout of the Grading History table, with the student/teamID & the assignmentID at the header, along with the instructorID in it's own column on the left, is done, and is shown in the screenshots in this document.
• Testing: Tests have been added into Expertiza that ensure that the positive flows work as intended. More tests need to be added for completeness, as stated below.
• Future Work: More testing is required - with over 650 changes, more work is needed to add tests that ensure comprehensive coverage.

Useful Links

Previous team's Expertiza GitHub pull request

Previous team's wiki write-up

E1934 implementation video walkthrough

Live Demo: Functionality

RSpec Test Demo

Pull Request

Contributors

Students

• Bhuwan Bhatt (brbhatt)
• Soumyadeep Chatterjee (schatte5)
• Kelly Fleming (kflemin3)
• Karthik Gopala Sundaresan (kgopala3)

Mentor

• Kai Xiao (yxiao28)