CSC/ECE 517 Spring 2022 - E2237: Grading audit trail
Team
Students
- Bhuwan Bhatt (brbhatt)
- Soumyadeep Chatterjee (schatte5)
- Kelly Fleming (kflemin3)
- Karthik Gopala Sundaresan (kgopala3)
Mentor
- Kai Xiao (yxiao28)
Topic Overview & Prior Work
The previous team's work 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:
1. When a grade is assigned by an instructor, there must be an indication of the InstructorID and a timestamp of the change.
2. 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 (NOTE: should probably remove this from here)
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
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.
Statement of Problem
There are three areas of focus for this project:
System Crashes and Object Creation
First, 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.
Second, 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:
a. Extract Student ID from the table, and ensure that it is shown in the header
b. 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:
a. From a data flow point of view
b. From a function point of view
c. With comment in code
Plan and List of Work Done
General Design Goals
- Changes to the Grading History Table: the following lines are required to be modified to complete this objective:
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
Specific Tasks Completed
Initial Implementation
Final Implementation
Testing
Video Demonstration
will be added for the final submission
Testing Goals and Test Objects
Drawing from the project objectives:
- Verify that Student Accounts can be created and are saved to the database.
- Verify that Assignments can be created and are saved to the database.
- Verify that Project Bids can be created and are saved to the database.
- Ensure that Student ID is shown in the header, and verify via manual UI testing
- Ensure that Assignment ID is shown in the header, and verify via manual UI testing
RSpec Unit Tests
Pseudocode provided here, will be replaced with RSpec code blocks for the final submission
- Student Account
Scenario: Account Creation with all fields As an Instructor/Admin Create student account with all the necessary fields Account is saved in the database Scenario: Duplicate Account Creation with all fields As an Instructor/Admin Create student accounts with all the necessary fields Student already exists message is shown Scenario: Account Creation without all fields As an Instructor/Admin Create student accounts without all the necessary fields Message to input fields is shown
- Assignments
Scenario: Assignment Creation with all fields As an Instructor/Admin Create Assignment with all the necessary fields Assignment is saved in the database Scenario: Duplicate Assignment Creation with all fields As an Instructor/Admin Create Assignment with all the necessary fields Assignment already exists message is shown Scenario: Assignment Creation without all fields As an Instructor/Admin Create Assignment without all the necessary fields Message to input fields is shown
- Project Bids
Scenario: Project Bid creation As a Student Complete Project Bid for open Project Project Bid is saved in the database Scenario: Duplicate Project Bid As a Student Click on bid for open Project Message stating already selected shown
Manual UI Tests
Discussion with mentor in progress to determine if UI Automation testing is in scope
Regression Testing
In order to ensure complete coverage, testing of the changes done between the end of last semester and this project was done.
Note to team: need to edit this after investigation
1. Investigate if this is testable using Capybara
2. 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)
3. Procure specific required column width, and assert that this is the value in the file (the constant)
4. Inquire with mentor about comment requirement and conflicts
5. Inquire with mentor regarding white space constraints
6. Inquire why the revert is needed, what is breaking and why
7. Ask mentor where this file is being called, and if functionality needs to be moved elsewhere.
8. Complete Design Document to reflect these changes.