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

Topic Overview & Prior Work

Feature Overview

E2158 contains detailed information regarding this feature. A summary of the desired functionality is presented below:

After an instructor assigns a grade to an assignment, there should be a way to track who gave the grade. Any instructor can assign/edit a grade freely; a grading audit trail must be created and the following information needs to be stored:

• When a grade is assigned by an instructor, there must be an indication of the InstructorID and a timestamp of the change.
• Comments previously provided by other instructors must be preserved.
• This information needs to be stored every time an instructor edits a grade/comment and clicks the save button.

Overview of Major Changes

• A new table was added to the database (grading_history), along with the corresponding model (grading_history.rb) and controller (grading_history_controller.rb).

• 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 (index_html.erb).

Files Involved

• \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

As per E2158, - Functional tests ensuring specific method calls are made were added.

functional tests added to these files
: spec/controllers/grades_controller_spec.rb
: spec/controllers/review_mapping_controller_spec.rb
: spec/controllers/grading_histories_controller_test.rb

Additionally, a feature test ensuring that correct grading history is shown 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

Whenever an instructor submits a new grade, or edits an existing grade, the grading_history_controller saves a new history entry to the database.

Issues with Existing Tests

1. Running these tests causes failures - in fact, only the Spec files for review_mapping_controller runs.
2. As per E2158, running all tests leads to the simulation crashing

Statement of Problem

There are three areas of focus for this project:

System Crashes and Object Creation

1. The work done by the previous team results in the system crashing when the tests are being executed; as a result, automated unit testing does not succeed. Our goal in this regard is to ensure that the tests are successfully executed for all test cases, with the appropriate outcome and coverage reports visible to the user.
2. Testing efforts to this point have used static, pre-created objects; this is due to issues with object creation. Our goal in this aspect is to ensure that the creation of new test objects, namely Student Accounts, Assignments, and Project Bids is successful.

Changes to Grading History Table

The grading history table is earmarked for certain changes:

1. Extract Student ID from the table, and ensure that it is shown in the header.
2. Extract Assignment ID from the table, and ensure that it is shown in the header

Code and Documentation Goals

Add reasonings and data flow structures/UML diagrams that detail the changes that have been made, as well as any comments on why certain files needed to be modified. These will be completed from these perspectives:

1. From a data flow point of view
2. From a function point of view
3. With comment in code

Plan and List of Work Done

General Design Goals

Changes to the Grading History Table

The highlighted code here is to be removed in order to remove redundant data from the table

The data is to be moved to the header, as shown below:

System Stability: Strategies

The source of this issue is currently unknown. Therefore, we will pursue the following to debug this:

1. Refactoring: We will explore refactoring both the test cases and the controllers (mentioned in section 2.2) to enforce the DRY principle where needed, and comment the code to enhance readability & maintainability
2. Test data: Currently, there is an existing issue with the test methodology - testing is all being done using pre-existing, static data. This will be fixed as a result of our work on Object Creation.

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.

Specific Tasks Completed

will be added for the final submission

Implementation

will be added for the final submission

Testing

Video Demonstration

will be added for the final submission

Testing Goals and Test Objects

Drawing from the project objectives:

1. Verify that Student Accounts can be created and are saved to the database.
2. Verify that Assignments can be created and are saved to the database.
3. Verify that Project Bids can be created and are saved to the database.
4. Ensure that Student ID is shown in the header, and verify via manual UI testing
5. Ensure that Assignment ID is shown in the header, and verify via manual UI testing
6. 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

• Student Account

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

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

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

• 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

• Project Bids

Scenario: Project Bid creation
 Given: Logged in as a Student
  When: Complete Project Bid for open Project
   Then: Project Bid is saved in the database

Scenario: Duplicate Project Bid  
 Given: Logged in as a Student
  When: Click on bid for open Project
   Then Message stating already selected shown

Manual UI Tests

Discussion with mentor in progress to determine if UI Automation testing is in scope

• Student ID in header

Scenario: Student ID in grading history view 
Logged in as an Instructor/Admin
  On Assignment page, click on Grading History
   Resulting Grading History Table is shown
    Student 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.
• will be added for final submission

Conclusion

will be added for final submission

Useful Links

Previous team's Expertiza GitHub pull request

Previous team's wiki write-up

E1934 implementation video walkthrough

Contributors

Students

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

Mentor

• Kai Xiao (yxiao28)