Assignment 3.b - Meteoric Design, Implementation, and Test
Part B - design, implementation, and test
You will work with your partner(s) to design, implement, and test your solution to Assignment 3, Part A. Download meteoric.py
and test_meteoric.py
to your assignment3/
folder.
You must identify a way to communicate and collaborate on the assignment:
- Meeting in person to work together
- Chatting and sharing code over a tool like Discord, Slack, or Teams. You may use the class Slack workspace.
- Emailing back and forth and texting.
You may only collaborate with your partner(s). You will submit one final solution. Review the section of the course policies on collaboration, cheating, and personal proficiency.
All partners must contribute equally to the assignment. Design will be done collaboratively in class. Implementation and testing tasks must be divided equally among the partners. Make each person responsible for implementing and testing part of the solution.
Design - in class
In class on October 17, discuss the organization of your code with your partner(s). You must come to an agreement on the design.
Follow the 6 low level design rules:
- Separate input/output logic from business logic.
- Functions should have a single responsibility.
- Handle errors at the lowest sensible level, and re-raise/re-throw them otherwise.
- Raise specific errors and define your own if needed.
- Avoid magic literals.
- DRY (Don’t Repeat Yourself) and the Rule of Three.
Rules 3-4 require your judgment. There are many ways to solve this problem while adhering to the design rules. Be prepared to justify your design decisions!
You may evolve your design during Implementation and Test.
By the end of class, show the instructor:
- The function signatures you have decided on in
meteoric.py
- Comments or docstrings that (i) define each function, and (ii) which partner is responsible for implementing and testing the function.
Implementation
- Put your names at the top of
meteoric.py
in the module docstring. - You may create classes and files and use imported libraries, but these things are not necessary.
- You may evolve your design as you go along. This is a natural part of implementation.
- You are free to modify the provided code, including
load_data()
code. - You may use a Python implementation of the haversine formula from the web. If you do, add a comment to the code containing a link to the website.
- Add docstrings following our conventions to any functions, classes, and files you create. Additionally, identify the partner primarily responsible for implementing and testing each function.
- The code must adhere to the PEP8 coding conventions discussed in class. You are free to use a Visual Studio Code extension that helps you achieve compliance.
Testing
- If you are a WSL or Linux user, set up pytest for the project.
- Add test cases to
test_meteoric.py
. Any additional source files you create must also have atest_*.py
test. - All test cases must run from the CLI with
pytest
. - Use
pytest --cov --cov-branch --cov-report=html
to generate a branch coverage HTML report in your project directory. - You must achieve 90% branch coverage in all source files except for
main()
.
Rubric
- (5pts) PEP8 coding conventions followed
- (5pts) Docstring conventions followed for modules (files), classes (if any), and functions.
- (25pts) User commands are correctly implemented, including exception handling of user input errors.
- (10pts) Adherence to our 6 low level design rules.
- (15pts) Multiple test cases with proper test structure for your source code.
pytest
branch coverage HTML report demonstrating ≥90% branch coverage of all source code except formain()
.
Submission due Oct 21
Zip your project directory, including spec.txt
, all Python files, and your coverage report. Upload the .zip
file to Assignment 3, Part B on Canvas.