In the first test, we wrote a very simple test that checked whether a new Stock class has its price attribute initialized to None. We can now think about what requirement we want to implement next.

An observant reader might have caught on to the terminology used in the previous sentence, where I said that we can think about the requirement to implement next, instead of saying that we can think about the test to write next. Both statements are equivalent, because in TDD, tests are nothing but requirements. Each time we write a test and implement code to make it pass, what we actually do is make the code meet some requirement. Looking at it another way, tests are just executable requirement specifications. Requirement documentation often goes out of sync with what is actually implemented, but this is impossible with tests, because the moment they go out of sync, the test will fail.

In the previous chapter, we said that the Stock class will be used to hold price...

Let us start with the first requirement. Here is the test:

    def test_stock_update(self):
        """An update should set the price on the stock object
        We will be using the `datetime` module for the timestamp
        """
        goog = Stock("GOOG")
        goog.update(datetime(2014, 2, 12), price=10)
        self.assertEqual(10, goog.price)

Here we call the update method (which doesn't exist yet) with the timestamp and price and then check that the price has been set correctly. We use the assertEqual method provided in the unittest.TestCase class to assert the value.

Since we are using the datetime module to set the timestamp, we will have to add the line from datetime import datetime to the top of the file before it will run.

This test follows the pattern of Arrange-Act-Assert.

When we run the tests, we get the following output:

.E
==================================================================
ERROR: test_stock_update (__main__.StockTest)
An update should set the price on the stock object
------------------------------------------------------------------
Traceback (most recent call last):
  File "stock_alerter\stock.py", line 22, in test_stock_update
    goog.update(datetime(2014, 2, 12), price=10)
AttributeError: 'Stock' object has no attribute 'update'

------------------------------------------------------------------
Ran 2 tests in 0.001s
FAILED (errors=1)

The test fails as expected, but the interesting thing is that the first line of the docstring is printed out on the fourth line. This is useful because we get some more information on which case is failing. This shows a second way of documenting out tests by using the first line for a short summary, and the rest of the docstring for a more detailed explanation. The detailed explanation...

Another requirement is that the price should not be negative. We would want to raise a ValueError if the price is negative. How would we check for this expectation in a test? Here is one way to do that:

    def test_negative_price_should_throw_ValueError(self):
        goog = Stock("GOOG")
        try:
            goog.update(datetime(2014, 2, 13), -1)
        except ValueError:
            return
        self.fail("ValueError was not raised")

In the preceding code, we call the update method with a negative price. This call is wrapped with a try...except block to catch ValueError. If the exception is raised correctly, then control goes into the except block where we return from the test. Since the test method returned successfully, it is marked as passing. If the exception is not raised, then the fail method gets called. This is another method provided by unittest.TestCase and raises a test failure exception when it is called. We can pass in a message to provide some...

Now we have just one requirement for update remaining:

Let us take the remaining requirement. Here is the test:

    def test_stock_price_should_give_the_latest_price(self):
        goog = Stock("GOOG")
        goog.update(datetime(2014, 2, 12), price=10)
        goog.update(datetime(2014, 2, 13), price=8.4)
        self.assertAlmostEqual(8.4, goog.price, delta=0.0001)

What this test does is to simply call update twice, and when we ask for the price, provide us with the newer one. The interesting point about the test is that we use the assertAlmostEqual method here. This method is often used when checking equality with floating point numbers. Why don't we use plain old assertEqual? The reason is that due to the way floating points are stored, the result may not be exactly the number you expect. There...

One question that might come to your mind is why there are so many different assert methods. Why can't we just use assertTrue instead of the more specific assert, as shown in the following code:

assertInSeq(x, seq)
assertTrue(x in seq)

assertEqual(10, x)
assertTrue(x == 10)

While they are certainly equivalent, one motivation for using a specific assert is that you get a better error message if the assertion fails. When comparing objects like lists and dicts, the error message will show exactly where the difference occurs, making it much easier to understand. Therefore, it is recommended to use the more specific asserts wherever possible.

Let us take a look at the tests that we have done so far:

    def test_price_of_a_new_stock_class_should_be_None(self):
        stock = Stock("GOOG")
        self.assertIsNone(stock.price)

    def test_stock_update(self):
        """An update should set the price on the stock object
        We will be using the `datetime` module for the timestamp
        """
        goog = Stock("GOOG")
        goog.update(datetime(2014, 2, 12), price=10)
        self.assertEqual(10, goog.price)

    def test_negative_price_should_throw_ValueError(self):
        goog = Stock("GOOG")
        with self.assertRaises(ValueError):
            goog.update(datetime(2014, 2, 13), -1)

    def test_stock_price_should_give_the_latest_price(self):
        goog = Stock("GOOG")
        goog.update(datetime(2014, 2, 12), price=10)
        goog.update(datetime(2014, 2, 13), price=8.4)
        self.assertAlmostEqual(8.4, goog.price, delta=0.0001)

If you notice, each test does the same setup by instantiating...

We've implemented the three requirements for the update method:

Now, let us suppose that a new requirement comes up that we had not known about before:

So far, our Stock implementation just stores the latest price. In order to implement this functionality, we need to store some history of past price values. One way to do this is to change the price variable to a list. The problem is that when we change the internals of our implementation, it would break all of our tests, because all of them access the price variable directly and assert that it has specific values.

What we see here is an example of test brittleness.

A test is...