CSC/ECE 517 Fall 2022 - E2281. Reimplement Waitlists: Difference between revisions
Line 48: | Line 48: | ||
=== General Design Goals === | === General Design Goals === | ||
'''Behavior Driven Development'''<br> | '''Behavior Driven Development'''<br> | ||
[[CSC/ECE 517 Spring 2022 - E2237: Grading audit trail#RSpec Unit Tests|BDD Scenarios]]<br> | [[CSC/ECE 517 Spring 2022 - E2237: Grading audit trail#RSpec Unit Tests|BDD Scenarios]]<br> |
Revision as of 17:51, 10 November 2022
Topic Overview & Prior Work (E2281)
Feature Overview
E2240 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
Files Modified By Previous Team
- signed_up_team.rb
- waitlist.rb
- sign_up_sheet_controller.rb
- sign_up_sheet.rb
- sign_up_topic.rb
- suggestion_controller.rb
- invitation.rb
Problem Statement
Our goals for this project are as follows:
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
Functionality
Planned Work
General Design Goals
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
- 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.
- 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.
- A pull request of the fixed code, fully commented, will be provided in this document.
Testing
Video Demonstration
Live Demo: Functionality
RSpec Test Demo
Testing Goals and Test Objects
Drawing from the project objectives:
- Verify that Assignments 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
- 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 Name in header
Scenario: Assignment Name in grading history view Logged in as an Instructor/Admin On Assignment page, click on Grading History Resulting Grading History Table is shown Assignment Name appears in the header, not in any table columns
- Color change after Grade is assigned to a submission
Scenario: Team_ID Color changes from blue to brown when grade is assigned Logged in as an Instructor of Course/Admin or TA assigned to Course On Assignment page, click on Etc->View Submissions All submissions for assignment are shown Team name is blue, and grade is not assigned Click on "Assign Grade" under team name Instructor/TA assigns grade, save successfully Back to submissions list, team name is now brown
Conclusion
- Functionality:
- Appearance:
- Testing:
- Future Work:
Useful Links
Contributors
Students
- Nick Aydt (naydt)
- Nagaraj Madamshetti (nmadams)
- Rohan Shiveshwarkar (rsshives)
- Gun Ju Im (gim)
Mentor
- Naman Shrimali (nshrima)