Day 3

GeneFinder Guest Lecture: Joanne Pratt

Dr. Pratt will provide some additional biological context for the GeneFinder miniproject and introduce us to research tools we will use to investigate candidate protein sequences.

Salmonella slides (PDF)

Going Beyond exercise related to material in the talk and MP1:

Mystery sequence 1:


Mystery sequence 2:


Git, GitHub, and New Reading Journals

We’ll continue talking more about git, developing a mental model of how version control works and how to use it, and getting some practice by setting yourself up with the third Reading Journal, which is available for you to bring to your own Github repository and laptop.


Reading Journal Chats with Different Peers

You will be doing Reading Journals on your own as you complete all of the four Mini-Projects. We change the students who are in each studio room as we transition between each Mini-Project. With the open time that we have during studio, we encourage you to talk with two or three people sitting around you - about recently submitted Reading Journals. You can identify questions or difficulties and try to talk/work through them. You can show what you might think have been an elegant or unorthadoxed approach to a question. You can tell any of the instructors or course assistants what you think would be useful for clarifying common confusions. You can also explore whether others want to work alongside you for completing future Reading Journals.

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 explore unit tests, and help you understand how they are a part of MP1. 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 given some starter unit tests in mini-project 1, and will add your own to this (and future) project(s).

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 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]

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

at the bottom of

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, where my_function is the function with doctests that you want to test, and verbose can be True or False.

Exercise - Designing a Reasonable Test: 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 reasonable set of unit tests for each function.

Caution: unintentional exclusion of certain types of users happens all the time. Attempting to evade issues ahead of time can go a long way. (For example, building in support for UTF-8 international character set instead of defaulting to ASCII american character standards will allow more people to interact with your product.) Adopting an attitude of being willing to address issues that arise after release is part of being responsible programmer. Accordingly, it is our responsibility to show you best practices for making your code not just readable by others, but understandable for an older version of yourself to revisit. If you have unit tests in place, you can have further reassurance that changes you make when returning to a project to address issues won’t break other parts of your system.

Unit Testing in the Wild

Do you have any best practices that you’d like to share with the class from using unit tests in other environments?

Unit Testing Questions

While you are beginning to explore unit testing in class activities and in the Gene Finder starter code, keep in mind a few questions so that you can examine their role in how you might design software.

  1. In what ways, if any, are you finding unit tests to be helpful as you code?
  2. What role does unit testing play in determining whether or not your program is correct? (This may vary depending on the program.)
  3. Which, if any, aspects of the Python module you are using for unit testing do you find unwieldy or suited for a re-design (what could make the tool better)?

Open studio time

Please use instructors and course assistants in the studio for questions and approaches as you work on MP1.