Emphasize test minimalism

[chillenzer]

The book example is not precisely what I consider good testing in that you really can't reason whether the results are correct or not (I personally haven't read that whole book and counted all the words). For that functionality, my tests would look like

def test_word_counts():
    book_text = "hello"
    assert word_count(book_text, "hello") == 1

and so on. It is, however, a good showcase for having some resource you don't want to acquire multiple times. So, I think it would suffice to add a box somewhere saying that this is not an ideal approach for this specific problem. Do you agree?

[edbennett]

Yeah, I think that's reasonable. The alternative would be cooking up an entirely separate example that uses an expensive-to-get resource.

It could even be a challenge—"what might some more minimal tests for this functionality look like?"

[chillenzer]

Ah, cool idea! Yes, I will make it an exercise. I think that one of the key points of (good) unit tests is that they, in fact, shouldn't need to acquire extensive resources. E.g., your function writing to disc should write to an in-memory stream for testing instead and your data base connection should be mocked out etc. So, from the top of my head I couldn't come up with an example that is a necessary, well-written unit test but still needs a big resource. On the other hand, in an integration or end-to-end test that is, of course, different, so it is a valuable technique.

For me, the main incentive of using fixtures was usually to abstract away some more or less complicating and repetitive setup, e.g., defining all the 10 input parameters for the functionality under test or creating an instance and then mocking out some part of it. That could be another motivation we could emphasize instead of sharing resources.

[edbennett]

So, from the top of my head I couldn't come up with an example that is a necessary, well-written unit test but still needs a big resource. On the other hand, in an integration or end-to-end test that is, of course, different, so it is a valuable technique

There's a reason I used "automated testing" rather than "unit testing" in the lesson title :)

For me, the main incentive of using fixtures was usually to abstract away some more or less complicating and repetitive setup, e.g., defining all the 10 input parameters for the functionality under test or creating an instance and then mocking out some part of it. That could be another motivation we could emphasize instead of sharing resources.

We could—in principle a helper function would achieve the same aim in that case, whereas being able to specify if and when fixtures should be cached or regenerated gives some specific advantages to the fixture syntax for heavier fixtures.

[chillenzer]

True, true. Well, played! ;D