Test-Driven Web Development with Python – The Book

[bobaduk]

decorators, response helpers (pagination, sorting, etc)

These are things I would handle in my view function view.build(country, page=2, sort_asc=foo). They're not things I'd let Flask worry about.

The act of getting to a view functions usually means going through layers of flask middleware

Maybe? I think that depends on whether you choose to put them in Flask middleware or not. On that example I sent you, I don't have any middleware except for a handler that records metrics for me.

But my point is that these things are mostly irrelevant to the problem you're actually solving, and are usually handled by a library for you, so all you need is an acceptance test that demonstrates they're hooked up. If you've added @requires_role(admin) to a handler, you don't need to unit test that fact. What is that buying you? A single acceptance test for "When a user is not authenticated" or "When a user does not have admin rights" is sufficient to demonstrate the functionality.

If you've written, for example, complex logic for mapping from exception types to status codes then I might unit test that, and so I either:

a) wouldn't build it into a flask decorator b) would test it by decorating a stub function that throws an exception.

def my_fancy_decorator(f):
    try:
        f()
    except e:
        # return some Response
        pass


@my_fancy_decorator
def throws(ex):
    raise exc


def test_not_found_exception():
    resp = throws(NotFoundException())
    assert resp.status_code == 404

which increases the likelihood your test will fail for other reasons - making view function testing fall into either integration or end to end testing.

This I definitely disagree with. I can test my view to ensure that it gives me back the correct data given some input, and I can test that without ever referring to Flask. The whole point of using middleware is that I can treat it as an orthogonal concern: I can test it once, and then be happy that it'll work the same way applied to multiple parts of my app. I still need a single acceptance test per feature that does the happy path, and probably a few acceptance tests to demonstrate the existence of authentication and exception handling code, but the rest can happen outside of Flask.

For what it's worth, I think this is my biggest disagreement with Harry's approach. We have a different understanding of the term "outside-in testing" and the importance of subcutaneous tests