Covering our Bases
- More practice making test cases and test suites
- Create a new PyCharm project. Remember to use your last name in the
- Download the starter code:
- Please replace ??????? with your name in the :author: tag in
Have a look around
Now that you have a project and some code, explore to see what you have:
- Skim the code in tictactoe_board.py. Notice that some
functions are marked as private (their names start with two underscores).
What functions are public and which are private?
- Use the debugger to determine what internal representation is being
used to store a tictactoe board:
- Set a breakpoint at the beginning of create
- Run main.py in the debugger.
- Step to see how create sets up the board.
- What is the internal representation of the board?
- Create a file called internal_rep.txt and write a short
description of the internal representation of a board.
- Take a look at main.py. Notice the Information Hiding:
- When main wants to create a tictactoe board, it uses
board.create(). So, main doesn't need to know how boards
are stored; create handles that.
- When main wants to modify or show a board, it uses
functions defined in tictactoe_board.py. So, main
doesn't need to know how boards are stored; the functions in
tictactoe_board.py handle that.
- So, if we wanted to change the internal
representation main.py would not need to change.
Look at some tests
Take a look at test_tictactoe_board.py, which uses the helper
functions in testing.py to
test tictactoe_board.get_winner(). There are three tests
in our test suite (i.e. set of tests), and for each test we have:
- A message indicating what we are testing.
- A call to board.get_winner() with a specific board as a
- The result we expect from board.get_winner() assuming
get_winner() is working correctly
Notice that the board we pass to get_winner()
is hard-coded in each of the tests. In regular code, you would
not want to hard-code what could be computed, but in testing code, you
want to hard-code:
- You will know exactly what tests you ran.
- You will be able to re-run the exact tests if you ever make
- For the specific hard-coded examples, you will know the right
answer without having to write general code to figure it out.
Remember, you are testing code that's supposed to figure it out in the
general case; if you write new code to figure it out, you might make
the same mistakes as were made in the code you're testing.
Add some tests
Your job is to add additional tests for get_winner().
Are there situations the existing tests don't cover? Try to
be thorough. One way to think about how to be thorough is to
think about coverage. We say that a test "covers" a line of code
if running that test causes that line of code to be executed. For a test
suite, we say that the test suite covers a line of code if there's at
least one test case in the test suite that covers the line of code.
- Take a look at get_winner() and make sure you create
tests so that all of the lines in get_winner() are covered.
- get_winner() calls __is_winner(). See if you can
create tests for get_winner() that cause all of the lines
of __is_winner() to be covered.
How to turn in this lab
Before turning in any program in this class, remember this mantra:
Just because it works doesn't mean it's good.
Part of your grade will also come from things like how understandable
and readable your code is. You will also be graded on the neatness,
presentation, and style of your program code.
For all labs, turn in only an electronic version. Please compress your
program and email the zip file or tarball to me at firstname.lastname@example.org.
Ask for help if you're having problems!