Python outside of a notebook

• Create a folder in the Documents directory
• Open Notepad
• Create a Hello, World! program
  • (Need an input so it doesn’t terminate immediately.)
• Double-click on python program to execute it.
  • Also show how to run on mac
• Add an input call to greet by name.
• This certainly works; but, Notepad is not a great environment to write code in
  • e.g., no syntax highlighting
  • no automatic help with tabs.
• Create a directory, and open it using VS Code.
• Write a quick python program.
• Show how to run directly in VS code.
• Traditional way to write code: Put it in a file.
  • With languages like Python, that program should run on any computer with python installed.
• Challenges:
  • Doesn’t scale well to large programs. (Code is hard to organize / manage)
  • Can be tricky to test.
• Solution:
  • split code over multiple files.
  • These different files are called “modules”
• A module is just a python file.
  • The functions in that file can be accessed by other files using an import statement.

• In general, put related code that might be re-used together into a module.

• Create demo_date.py
  • write days_in_month (use lookup method)
  • write tomorrow
• Write and use driver program

Unit Testing

• How do you know when your program is “done” and bug free?
• You need a better system than just playing with it for awhile and not noticing any bugs.
  • You need a specific test plan.
• What tests should we run for days_in_month?
• how about tomorrow? What do we do when you can’t run every possible input?
• Better yet, you want an automated way of running the tests.
  • Any time you change the code, you want to be able to easily verify that you haven’t introduced any bugs.
  • Doing this manually gets tedious/boring in a hurry.
• Conventional approach is to use a Unit Test Framework.

• There are several; but, in this class we’ll use unittest because it comes with Python.

• Key steps
  • import unittest (this contains code that makes the automated tests work)
  • create a class. We’ll talk more about what exactly classes are later.
  • Write tests.
    • test names must begin with test.
    • must take one parameter named self. (That’s part of the class thing.)
  • Two key concepts: expected and observed values.
    • Need to compute the expected (i.e., “correct”) answer
    • Run your code to get the observed value.
    • Make sure they are equal.
• Having expected and observed variables not necessary, but can be helpful.
• To run the tests: python3 -m unittest demo_date_test.py
  • The -m tells python to run the module as a stand-alone program.
    • This lets you deploy larger programs as modules, if that’s helpful.
    • (python3 -m http.server is a quick and dirty web server if you ever need one.)
• Notice the output when there aren’t any bugs.
• introduce a bug and re-run
• assertEqual takes an optional third parameter if you want a more detailed message.
  • demonstrate
• There are several different assert functions (https://docs.python.org/3/library/unittest.html#unittest.TestCase). The most common are
  • assertEqual
  • assertNotEqual
  • assertTrue
  • assertFalse
  • assertIn
• Notice that by putting functions in demo_date we have separated our “number crunching” functions from the code that interacts with the user. This often makes testing easier.

Designing tests

• How many tests are enough? What tests do we choose when we can’t test everything?
• First step: “Black box tests”.
  • Imagine I give you a handheld electronic device and tell you it determines whether a year is a leap year. Your job is to figure out if it works. What years would you give it?
  • Called “black box” because you treat the function as a black (opaque) box: You don’t know what’s in it.
  • Instead, you rely on the “rules” of the process you are automating — e.g., the rules for leap year.
• Second step “white box” testing. Once your code is written, look inside it (as if it is a transparent box) and make sure each line is tested
  • for example, both halves of an if statement

Git and GitHub

• git is a version control system. It is a tool that keeps track of your changes over time, so if you mess something up, you can go back and get the working version.
• gitHub is a web service that will store you git repos “in the cloud” which allows you to
  1. Share your code with others
  2. Collaborate with others offline. (Not applicable in this class, other than to let me see your code.)
  3. Keep your code safe if your laptop fails.

In this class we are going to use git and GitHub so you can share your code with me. This makes it easy for me to see your code (either for submitting assignments or just asking for help). It also makes it easy for me to send feed back to you.

In general, the code for your projects will go in a GitHub repo that gets shared with me.

GitHub Classroom is a GitHub tool that simplifies the process of setting up a repo. Basically, I’ll give you a URL. When you click on that link, GitHub will create the repo for you, populate it with any “starter code” and add me as a collaborator.

• Walk through setting up Project 1.
• Show git clone

• Show, git add / git commit / git push

• https://docs.python.org/3/library/unittest.html