Checkpoint 20.8.1.
Run the code below to see what it prints.
Section 20.8 Unit Tests
Now that you have learned about classes and inheritance we can explain how to write your own unit tests.
Subsection 20.8.1 Testing your Code
How do you test that your program worked? You may put in print statements about what you expect the output to be and compare that to what you actually get to see if your code is correct.
In fact in test-driven development you should write test cases before you start writing any code. That way you will know when your code works.
This type of test is better than just printing out actual output because then you have to think about what the correct value should be. It lets you quickly compare the expected value and the actual value. However, you have to visually compare the two, which takes some time and you could miss something that doesn't match.
Note 20.8.2.
The tests above are using a f-string which is an easier way to create a string with expression results in the string. Just add
f before the start of the string and {expression} in the string.Another way to write the code above would be to use a list comprehension. These are a quick way to return a new list by applying some logic to each element of the list.
result_list = [returned_value for item in list logic]
Checkpoint 20.8.3.
Run the code below to see what it prints.
Subsection 20.8.2 Creating Test Cases
What types of tests should you create? You should create tests that check that the function works for a variety of normal input. You should also think about how to handle unusual input such as checking that
total_even works even for an empty list or a list with only one item.Subsection 20.8.3 Understanding Unit Tests
Another way to test your code is to write unit tests. You have already been using hidden unit tests in this ebook to check your code as shown below. You probably quickly realized that you wanted all the tests to “pass” which is highlighted in green. This gives you an even quicker visual indication that your code is working than having to compare the expected output to the actual.
Let's look at the unit tests that have usually been hidden.
Checkpoint 20.8.4.
Run the code below to see the unit tests again. See the unit tests after the code. The last unit test compares the result of
recPerimeter(3.0, 2) to wrong value. Fix the value so that all of the tests pass.Look at the unit tests above and answer the questions below.
Checkpoint 20.8.5.
Q-4: What is the class that is defined in the unit test code?
Checkpoint 20.8.6.
Q-5: What class does the defined class inherit from?
Checkpoint 20.8.7.
Run the code below to see what the unit tests do and then add another test to test the result when x is higher than y.
Checkpoint 20.8.8.
Fix the function below to return the middle characters from the passed string. If the string has an odd length then return the middle character. If the string has an even length return the two middle characters. For example,
get_middle('abc') returns 'b' and get_middle('abcd') returns 'bc'. Also add tests cases to test the result when str has only one or two characters in it.Add tests to check the result when
str has one or two letters.Note 20.8.9.
Unit tests in this ebook must include the line
from unittest.gui import TestCaseGui and inherit from TestCaseGui. Outside of this ebook you should include the line import unittest and inherit from unittest.TestCase.Unit tests inherit from a class that includes several methods. As you can see from the code above one of the methods is
assertEqual which returns the result of a == b.Checkpoint 20.8.10.
Note 20.8.11.
All of the assert methods can take a third parameter which is a message (string) that explains what was tested.
Subsection 20.8.4 Writing Unit Tests
To write a unit test you need to do the following.
- Import the library (
from unittest.gui import TestCaseGuiin this ebook andimport unittestelsewhere) - Create a class that inherits from the correct class (
TestCaseGuiin this ebook andunittest.TestCaseelsewhere ) - Optionally create a
setUpmethod which is called before every test method is run. -
Create one or more methods that start with
testto test different things in your code- Test one or more results using
assertmethods such asself.assertEqual
- Optionally create a
tearDownmethod which is called after every test method is run - Run the tests using
ClassName.main()in the ebook and otherwiseunittest.main()
Note 20.8.12.
The order that the tests run is not the order they are defined.
Checkpoint 20.8.13.
Fix the code below to run and notice the test results.
Modify the code above to add a method in the
Car class to set (change) the model name and add a test method to test that the new method works.Checkpoint 20.8.14.
Put the code in order to create tests for a Person class initials method that returns the first letter from the first name followed by the first letter of the last name. The Person class initializer takes the person's first name and last name. First define a
setUp method to create two Person objects and then define the test_initials method.
