Lab: Automated Testing


In this lab, you'll practice your personal development practice while adding in a new element: unit tests. While working on your OOP Adventure Game, you probably wasted a lot of time playing through your game over and over just to see if some new code worked. You can speed this up by writing code to test small pieces of your game for you.

Because writing code can be hard, writing tests for your code can be even harder. To start out, I'll provide the tests and you'll have to write the code to make the tests pass. This lab has many parts, so take your time and try to understand what's happening before moving on.

Before you start, search around for some good articles to understand Test Driven Development and why we're using it. Also, see if you can find a definition for Unit Tests and see what other types of tests you can write.


Part I

For a quick intro to testing, you'll build and test a class that could've been used for your OOP Adventure Game.

Setup:

  1. Copy the python-skeleton project to make a new one called ex47. Rename all the instances of yourproject to ex47. If you don't remember, follow the instructions in the README.
  2. In your ex47 package, create a new module called game.py and add this code.
  3. Then create a new file in your tests directory called test_game.py. Here is the code for the tests.
  4. If you have activated a virtual environment and installed the dependencies with pip, run the tests with the pytest command. You should see something like the following output:
=========== test session starts ============
platform darwin -- Python 3.7.6, pytest-5...
rootdir: /Users/zach/cset/labs/ex47
collected 3 items

tests/test_game.py ...               [100%]

============ 3 passed in 0.04s =============

The test file imports the Room class in the game module so you can see if it works. The test file has three tests, which are functions, and each is checking a certain behavior. Read the code and the tests and try to understand what is happening.

Next, go read Pytest's documentation to see how it works and what else you can do with it. Read up on the assert statement, too. Here are some important notes:

Practice:

Try making this Room class more advanced. Make it do something new and see if you can write a test for it.


Part II

Did you find it difficult playing someone else's OOP game? You probably had to type very specific commands to do something. Wouldn't it be nice if your game could figure out what the user wanted to do with all sorts of English sentences? Then input like "open door" or "go through the door" could do the same thing.

So let's build it! I'll give you a big list of words your game will know about, called a lexicon, and then you'll write a function to parse sentences entered by a user and turn it into useable commands. You might find the docs for str.split(), tuples, and exceptions to be helpful for this exercise.

Your function should return a list of (type, word) tuples for each word in the input string. That way you know what type of word was entered. For words you don't know, we can return an error type. Here's the lexicon with each type:

Setup:

  1. Copy the project skeleton into a new project called ex48. Run the tests to make sure the skeleton was created properly.
  2. Get the test file and add it to the ex48/tests/ directory.
  3. I'll also give you a helper module that you can import and use to convert strings into numbers. Get the module file and add it to the ex48/ex48/ package.
  4. Finally, create a module called lexicon.py inside your package. You should only write your code within this file.

Try running the tests. They should fail and that is good! A failing test is like a goal, a definition of successful code. The test file is mostly commented out so you'll have small steps to accomplish the goal. This is what you should do:

  1. Uncomment the next small portion of tests.
  2. Run the tests and see the failure.
  3. Write the source code to make it pass. Don't forget your development process:
    1. Write comments to describe the tasks you need to do.
    2. Write the code to accomplish each task.
    3. When stuck, break the comment into more lines but smaller tasks.
  4. Repeat until you're done.

Practice:


Part III

TODO