First, write a failing test:
import unittest
import pandas as pd
class RangeSeriesTest(unittest.TestCase):
def test_it_returns_a_series_from_1_to_10_by_default(self):
actual = range_series()
expected = pd.Series([1, 2, 3, 4, 5, 6, 7, 8, 9, 10])
self.assertTrue(
actual.equals(expected),
msg=f"expected: {expected}, actual: {actual}"
)
if __name__ == '__main__':
unittest.main()Running it straight away gives, unsurprisingly:
Output:
$ python3 test_range_series.py
E
======================================================================
ERROR: test_it_returns_a_series_from_1_to_10_by_default (__main__.RangeSeriesTest)
----------------------------------------------------------------------
Traceback (most recent call last):
File "test_range_series.py", line 6, in test_it_returns_a_series_from_1_to_10_by_default
actual = range_series()
NameError: name 'range_series' is not defined
----------------------------------------------------------------------
Ran 1 test in 0.001s
FAILED (errors=1)
But then we gradually fix the problems: first by introducing a function with the right name and parameters with some dummy implementation to get us past that error (hopefully!) and so on until it's working. The goal in this process is to use feedback from the tests to tell us if we're doing the right thing - if we're surprised by something, we should try and understand that (maybe we made an incorrect assumption, for example).
Writing a test
before doing the implementation is about two things in my mind: focus and clarity.
Focus: even with your simple example, there are often several cases to test. You write a test for one of those at a time and because your goal is to get that test to pass, you're focussed on that one thing and can leave the others for later tests. So, it helps you work in a nice, incremental way, building up in small pieces.
Clarity: spelling out exactly what the code you're going to write is going to do means that you need to understand that and also understand how to tell if you've done it right. As an example, since I'm not a pandas expert, in writing this test I learnt that checking equality of
Series with
== (which is what
assertEquals does) doesn't make sense and I learnt about the
equals method on
Series. Can you describe what you're testing in a sentence (i.e. the test name)? If not, that's probably a sign that you're trying to test too much in one go. This understanding phase also means you might think about assumptions you hold, or discover other cases you might not have thought about at first.
Having automated tests like this also means that if you break any behaviour when you're changing the code, you'll know about it because tests will start failing. Obviously, this implies you're running the tests often as you make changes.
Kent Beck's
Test-Driven Development: By Example is a good introductory read on the subject. The example code is largely in Java if I remember, but the ideas are broadly applicable. Besides, there are likely other sources on the web about this anyway.
