Day 3

Reading Journal Debrief

With two people sitting around you, go over your reading journal. Identify any questions / difficulties and try to work through them. We will do a quick report out for lingering confusions along with observations you’d like to share with the rest of the class.

Git, GitHub, and Reading Journals

We’ll be talking more about git, developing a mental model of how version control works and how to use it, and getting some practice by setting up your Reading Journal repository together.

References

Intro to Unit Testing

Testing our functions interactively in the interpreter as we write them is great for quick tests.

As we move to more advanced functions and programs, we’d like to add several more features. We might want to save the tests, to run them again as our implementation changes. We might even want to write the tests ahead of time, an approach known as test-driven design.

Today, we’ll write our first unit tests. These short tests let us verify each piece of a program independently, which makes it more likely the entire program will be correct once we put everything together. You will be writing more unit tests in mini-project 1, and in all the work you do for this class.

We will be using the doctest Python module, which makes code examples in Python docstrings into unit tests automatically.

Running doctests

Doctests can be run in normal mode, in which only failing tests will be reported, or in verbose mode, which reports results from all tests.

Let’s assume you’ve written a program called my_prog.py that contains some doctests. In order to run those tests, there are (at least) three approaches:

Command line

You can test your program directly from the command line by running

$ python3 -m doctest [-v] my_prog.py

where the [-v] means you can either include the -v verbose flag or not.

Within program

You can also run doctests from inside your program, by including:

import doctest
doctest.testmod(verbose=True)

at the bottom of my_prog.py.

You will often see this nested within a block:

if __name__ == "__main__":
    ...

so that the test code is only executed if the program is run directly, and not if it is imported by another program (we’ll talk more about this later).

Single function

It is also possible to run the doctests for just a single function, rather than all doctests in the file. This is sometimes useful in Reading Journals or when doing early development, so you are not flooded with known errors from other parts of your program. Just be sure to go back to running all of the tests in your program before you submit.

To do this, include:

import doctest
doctest.run_docstring_examples(my_function, globals(), verbose=False)

in my_prog.py, where my_function is the function with doctests that you want to test, and verbose can be True or False.

Exercise: Add unit tests to the functions you wrote for the reading journal and verify their correctness. Before you start typing out your unit tests, take a minute to think through what would constitute a good set of unit tests for each function.

Unit Testing questions

You are beginning to explore unit testing in class activities and in the Gene Finder starter code. Now is a good time to ask questions about their role in how you will design software.

  1. In what ways, if any, have you found unit tests helpful so far?
  2. What role does unit testing play in determining whether or not your program is correct? (This may vary depending on the program.)
  3. Any aspects of unit testing that you find unwieldy?
  4. Do you have any best practices that you’d like to share with the class from using unit tests?

Open studio time

Please use instructors and NINJAs in the studio for questions and approaches as you work in MP1.