Overview

The goal of this component of your project is to create a command-line app to allow a user to interact with your data via the command line. Your app should also include an automated test suite.

The learning objectives for this subcomponent of your project are to be able to 1) create an automated test suite, 2) create an app with a command line interface, and 3) create code that follows the principles of good function design.

Collaboration

You should work with your team on this portion of the project. You are able to get help from outside sources, as specified in the syllabus, but everything that your team submits should be your own.

You may also try out asking this custom Gemini bot for help, which will hopefully help you on the deliverable without undermining your learning. If you use this, I would appreciate you copying some example interactions with it to a text document and emailing it to me. This is both to give me an idea of whether it is providing correct information and if it is actually being helpful. If you manage to get it to produce solutions or otherwise inappropriate responses, please let me know asap so that I can prevent it from undermining everyone’s learning further.

Due Date

This subcomponent of your project is due Monday Jan 26th at 10pm on GitHub.

What to Submit

Individual

Team

On your team repository, you should have (at least) the following files:

  • command_line.py
  • One or more files in ProductionCode to support command_line.py
  • test_command_line.py in Tests
  • README.md
  • UserStories.md

Your Task

Your team should write a program that:

  • Fulfills the user stories that you originally proposed by supporting at least three independent features; each of these features should enable the user to get information from your datasets via the command line interface
  • Has a usage statement and help information
  • Has an automated test suite with good coverage
  • Follows the function design principles and has generally good style
  • Has documentation through docstrings and in-line comments where appropriate
  • Follows the recommended Python style

  • Your README.md needs to include (at least) an example of how to run your code to demonstrate each of your features, i.e.

    python3 command_line.py --name "Anya"
python3 command_line.py --color "purple"

    These may be repeated in a help command or separate examples. You should have examples in both places.

  • Your README.md also needs to include a clearly labeled section Dependencies which lists all modules/libraries that you are importing and specifically what you are using them to do. You should triple check the imports at the top of all of your files to ensure that you have correct imports for only what you intended to import.

Tips

You may find the csv module useful for dealing with your dataset (assuming it’s a .csv).

Your command line interface can either use the sys.argv list directly or you can use one of the many modules for parsing command line arguments. The argparse module is probably the easiest to use and is standard for all installations of Python. (I recommend against other modules such as Click and Typer since they are more complex than we need.)

You can and should create ‘dummy data’ that allows you to test your production code more easily and quickly. Make sure to include that dummy data in what you submit.

Turning it in

Your team should submit this subcomponent of the project on your team repo with the tag cl by typing the following:

git tag -a cl -m "command line interface"
git push origin cl

If you forgot to tag your comment, you can retroactively tag.

Evaluation

The requirements for “Core” and “Advanced” are below. When evaluating your project, the grader will consult the GitHub action output regarding tests and style. They will also separately pull down your team’s repo, checkout the cl tag, and run both your production code and test suite, and further look through your code for style.

Core

  • Functionality:
    • There is a usage statement in both the README and at the command line
    • The README contains specific runnable examples for each feature (these can be repeated in a help command)
    • The README contains an accurate and clear Dependencies section.
    • There are three independent features controlled by a command line interface that allows the user to get information from the chosen dataset
    • There is an automated test suite that achieves 75% coverage
  • Design:
    • The correct directory structure is used (Tests and ProductionCode)
    • All style checks have a score of at least 5
    • The functions/methods are mostly written at a single layer of abstraction
    • Function names, return values, and parameters generally follow the principles of good design
    • Function/method docstrings generally provide the required information
    • There isn’t an excessive amount of repeated code

Advanced

  • All the Core requirements are satisfied
  • The commit to evaluate is correctly tagged with the tag cl
  • The UserStories.md file contains (at least) three of the user stories from your proposal and information about where their acceptance tests are
    • If you have needed to change your user stories, you need to get approval from Anya
  • Functionality:
    • The test suite has over 90% coverage
    • There is comprehensive instructions on how to use the command-line interface in both the README and with a help command
    • There are acceptance tests for each user story, which are clearly marked
  • Design:
    • All style checks are 9 or above
    • The functions/methods are all written at a single layer of abstraction
    • Function names, return values, and parameters all follow the principles of good design
    • Function/method docstrings all provide the required information
    • There is barely any duplicated code