CSC/ECE 517 Fall 2022 - E2281. Reimplement Waitlists: Difference between revisions

From Expertiza_Wiki
Jump to navigation Jump to search
Line 102: Line 102:


=== Conclusion ===
=== Conclusion ===
* '''Functionality:'''  
* '''Functionality:''' The overall functionality is good, it just requires the code be cleaned up in order to meet Ruby Stylistic Guidelines.
* '''Appearance:'''
* '''Testing:''' Some tests will need to be created in order to test the waitlist controller, and other waitlist related functionality.
* '''Testing:'''  
* '''Future Work:'''


== Useful Links ==
== Useful Links ==

Revision as of 18:56, 10 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.

Concerns with current functionality

  • What if a team is currently assigned a different topic and waitlisted for a topic that is now available?
  • How many topics can a student be waitlisted for?
  • 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?

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

Move Waitlist Functionality into Waitlist 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

Planned Test Cases

  • 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

Manual UI Tests

Conclusion

  • Functionality: The overall functionality is good, it just requires the code be cleaned up in order to meet Ruby Stylistic Guidelines.
  • Testing: Some tests will need to be created in order to test the waitlist controller, and other waitlist related functionality.

Useful Links

Our Github Forked Repo

Pull Request

Contributors

Students

  • Nick Aydt (naydt)
  • Nagaraj Madamshetti (nmadams)
  • Rohan Shiveshwarkar (rsshives)
  • Gun Ju Im (gim)

Mentor

  • Naman Shrimali (nshrima)