Document possible scenarios (happy paths and unhappy paths)

[sfaigan]

We need to define a list of possible scenarios in order to identify any unhandled scenarios and implement tests. We cannot define every possible set of inputs that could be used, but we can generalize in order to define the possible scenarios. This list should include both happy paths and unhappy paths. If it is an unhappy path (i.e., no feasible schedule found), please define a specific error message. Error messages should be consistent in their wording and formatting, and each one should indicate the reason and if not obvious, how the input can be changed to avoid it.

These scenarios should be written in BDD format (Gherkin), as it will make implementing tests a lot easier. It’s okay if you would rather use a different format, just be consistent and make sure scenarios are described clearly and the inputs and expected output are included. Inputs should be described generally (e.g., “” instead of “Fall”), but be specific enough that a mock input can be generated. Feel free to include mock inputs if it makes the scenario more clear.

Example Scenario A course offering requires a PENG in a semester for which no professors with a PENG are available

Given a valid schedule object with a course offering in that requires a PENG And a list of professors with no PENG professor available in When I call generate_schedule Then no schedule should be returned And the error should be “No schedule found. requires a PENG in , but there are no professors with a PENG available in .”

Acceptance Criteria:

• [ ] All possible scenarios of the algorithm (happy paths and unhappy paths) are documented
• [ ] For every scenario, it is easy to generate mock inputs for generate_schedule that test the scenario
• [ ] Every scenario has an expected outcome that defines the output of generate_schedule
• [ ] For every scenario that does not result in a feasible schedule being generated and returned, an error message is defined
• [ ] Error messages are consistent in their language and formatting
• [ ] Every error message indicates the reason for the error and if not obvious, how the input can be changed to avoid the error

Related documentation: Possible Paths and Error Cases Document

[sfaigan]

Good starting point: https://github.com/seng499-company2/algorithm1/blob/696209659f814e01182968106a350fba520595e7/test-cases.txt

If you use these, please ensure they meet the acceptance criteria in this ticket

[sfaigan]

Please ensure there is a scenario to cover the requirement that the algorithm returns within the required amount of time. It's 2 hours in the SRS, but I doubt front-end waits 2 hours before timing out the request, so you might want to consult with them.