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.
For a quick intro to testing, you'll build and test a class that could've been used for your OOP Adventure Game.
ex47
. Rename all the instances of yourproject
to ex47
. If you don't remember, follow the instructions in the README.game.py
and add this code.tests
directory called test_game.py
. Here is the code for the tests.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:
test_
and should be named for the module they are testing. Make one for each module you write.tests
directory or pytest won't find them.test_
and should be named for what the test is trying to check.Try making this Room class more advanced. Make it do something new and see if you can write a test for it.
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:
ex48
. Run the tests to make sure the skeleton was created properly.ex48/tests/
directory.ex48/ex48/
package.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:
TODO