In this lesson, you’ll dip your toes into testing your code. To learn more on this topic, check out:
Test Your Code
00:00 Test Your Code Repeatedly. Running your code while you are developing it is a great way to ensure that the code does what you expect. Organizing your code and functions opens up another avenue for staying in control: unit tests. You can add tests that check each of your functions.
00:29 Test-driven development is a popular practice that focuses on automated testing. If you practice TDD, you’ll write tests before you write code. To learn more about this, check out this Real Python tutorial.
00:55 A doctest is a special unit test integrated into your documentation. You write doctests inside docstrings. A docstring is a comment written as a string on the first line inside a function definition.
The docstring is a comment, and it won’t affect how the program runs. But writing this documentation has two immediate advantages. It helps developers, including yourself, understand how to use the function, and it can automatically be tested with
Here you include the
-v flag, which triggers verbose mode. Without this, you wouldn’t see anything unless you had a failing test. In practice, that’s often what you want, but the verbose mode can be instructive to look at, particularly when you first start using
Sometimes you may want to change your code to make it easier to test. You’ve already seen how refactoring
wyrdl.py to use functions made it possible to add a doctest. However, if you were to add a similar test to
get_random_word(), then you’d quickly run into a few challenges.
The return value of the function is random, so which value should be expected? The function implicitly depends on
wordlist.txt, so if you change that file, then the return value of the function will change.
These challenges hint that you could improve the implementation of
get_random_word(). One way to do this is to read the word list outside the function and pass it in as a parameter. To achieve this, alter the function as seen on-screen.
Here, you assume that
word_list will be a list of strings that’s passed to
get_random_(). If you do this, then you need to update
main() correspondingly, with lines which should look familiar, as they’re very similar to the ones that were just removed from
You’ve moved the responsibility of reading the word list to
main(). The advantage of this is that
get_random_word() has a clearer purpose and can be tested more easily. You can now add the following doctest, which checks that
get_random_word() correctly filters out words in the word list with the wrong length or with non-letter characters.
06:37 Adding tests to your code is an important exercise. It will make you more conscious about the assumptions you make, and it will help you debug your code when it’s not working as expected. To keep the scope focused, you won’t work on any more tests in this course, but feel free to add them yourself. At this point, the game should be running, and it has some tests present.
07:00 Remember that if you need a pointer in the right direction, the course materials include the code at this state so you can compare should you need to do so. But in the next section of the course, you can learn how to improve the look and feel of the game even though it runs in the terminal.
Become a Member to join the conversation.