CSC/ECE 517 Fall 2022 - E2281. Reimplement Waitlists: Difference between revisions
Jump to navigation
Jump to search
Line 3: | Line 3: | ||
=== Feature Overview === | === Feature Overview === | ||
[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2022_-_E2240._Re-write_waitlist_functionality E2240] contains detailed information on the previous team's work with this feature. | [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2022_-_E2240._Re-write_waitlist_functionality E2240] contains detailed information on the previous team's work with this feature. | ||
'''A summary of the desired functionality is presented below:''' | '''A summary of the desired functionality is presented below:''' | ||
Line 11: | Line 11: | ||
holding that topic drops the topic, then the team at the top of the waitlist will be assigned the topic. | holding that topic drops the topic, then the team at the top of the waitlist will be assigned the topic. | ||
'''Concerns with | '''Our Concerns with Current Functionality''' | ||
* What if a team is currently assigned a different topic and waitlisted for a topic that is now available? ''Currently assigned a topic, drop from all other waitlists'' | * What if a team is currently assigned a different topic and waitlisted for a topic that is now available? ''Currently assigned a topic, drop from all other waitlists'' | ||
* How many topics can a student be waitlisted for? ''As many as needed'' | * How many topics can a student be waitlisted for? ''As many as needed'' | ||
Line 17: | Line 18: | ||
* How are students notified that they were assigned a new topic? ''Currently no functionality exists in expertiza'' | * How are students notified that they were assigned a new topic? ''Currently no functionality exists in expertiza'' | ||
=== | === Comments on why E2240, was not merged === | ||
# The code for the waitlist is distributed all over the application, which is something could have been placed into a single controller and called through other files | |||
# Although manual testing looked solid, there were not enough automated test cases to back their functionality. | |||
# Too many class methods. | |||
# The code does not follow ruby style design. | |||
# Lack of descriptive code comments | |||
=== Files Modified By Previous Team === | === Files Modified By Previous Team === |
Revision as of 15:12, 14 November 2022
Topic Overview & Prior Work
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 or TA can sign students up for a topic. Students are able to sign themselves up for a topic. If the topic is full then the team will be put on a queue or "waitlist" for the topic. If the current team holding that topic drops the topic, then the team at the top of the waitlist will be assigned the topic.
Our Concerns with Current Functionality
- What if a team is currently assigned a different topic and waitlisted for a topic that is now available? Currently assigned a topic, drop from all other waitlists
- How many topics can a student be waitlisted for? As many as needed
- If two topics become available at the same time and the same student is at the top of both waitlists, which does it choose?
- How are students notified that they were assigned a new topic? Currently no functionality exists in expertiza
Comments on why E2240, was not merged
- The code for the waitlist is distributed all over the application, which is something could have been placed into a single controller and called through other files
- Although manual testing looked solid, there were not enough automated test cases to back their functionality.
- Too many class methods.
- The code does not follow ruby style design.
- Lack of descriptive code comments
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
Planned Work
- Add migration for "remove_column :signed_up_teams, :is_waitlisted"
- Remove all the references of is_waitlist column
- Increase the test coverage by creating new Waitlist tests (Ex. Accept Invitation, Leaving team etc.)
- Add more descriptive code comments
- Update to match Ruby Style Guide
Design Strategy
Ruby Style Guide Basics
- Indentation: Each indentation level should be marked using two spaces.
- Line Length: Each line should contain a maximum of 80 characters.
- End of Line: Each line should have no trailing whitespace and should use UNIX Style line endings (CRLF).
- Expression: Each line should only contain one expression.
Testing
Planned Test Cases
- Waitlist
Scenario: Student leaves a waitlisted team Given: Logged in as an Student When: Student leaves a team Then: Student should be removed from all waitlisted topics associated with that team Scenario: Instructor/TA Removes Student from Class Given: Logged in as an Instructor/Admin When: Student is dropped from class Then: All topics that the student has waitlisted should be freed up Scenario: Student accepts new team invitation Given: Logged in as an Student When: Student accepted invitation to join team on a waitlist Then: Student should be added to the waitlist Scenario: Instructor/TA Removes a topic Given: Logged in as an Student When: Instructor/TA removes a topic containing a waitlist Then: The waitlist should be deleted Scenario: Student is assigned a topic and a waitlisted topic becomes available Given: Logged in as an Student When: A topic that a student has waitlisted becomes available Then: TBD
RSPEC Test Cases
Tests will be added once they've been implemented
Manual UI Testing
Testing as Student
- Login as Student
- Click on Assignments
- Find an Assignment with a Signup Sheet (ex. Final project (and design doc))
- Click Signup Sheet
- Click the Green Check Mark under the Actions Column to add a topic (for testing choose an available topic)
- Ensure when Student is added to Topic that the Available Slots decrements
- To ensure the Waitlist works, login as another student (Follow steps 1-5). For step 5 choose the same topic that you chose with the other student
- Ensure this student should now be added to the waitlist
- Now log back in as the original student and navigate back to the signup sheet
- Now drop your topic. This should cause the available slots to remain the same and only the waitlist to decrement, because the student on the waitlist should've been added to the topic
- Now log back in a the second student an ensure you are assigned the topic
Testing as Instructor
- Login as Instructor
- Click on Assignments
- Find an Assignment with a Signup Sheet (ex. Final project (and design doc))
- Click Signup Sheet
- Begin by adding a Student (we will call them Student A) to an open topic
- Then add another Student (we will call them Student B) to the same topic. Student B should've been added to the waitlist
- Now remove Student A from the topic. Student B should now be assigned the topic and the waitlist should've decremented
Conclusion
- Functionality: The overall functionality is good, it just requires the code be cleaned up in order to meet Ruby Stylistic Guidelines.
- Comments More descriptive comments will need to be added for increased readability.
- Testing: Some tests will need to be created in order to test the waitlist controller, and other waitlist related functionality.
Useful Links
Contributors
Students
- Nick Aydt (naydt)
- Nagaraj Madamshetti (nmadams)
- Rohan Shiveshwarkar (rsshives)
- Gun Ju Im (gim)
Mentor
- Naman Shrimali (nshrima)