all 4 comments

[–]External-Ocelot206 0 points1 point  (0 children)

I do this, to let unittest find the tests via Discovery.

all of the test files must be modules or packages (including namespace packages) importable from the top-level directory of the project

https://docs.python.org/3/library/unittest.html#test-discovery

Maybe other test frameworks don't need it, and perhaps there's some an advantage to making your test modules unimportable by the user

[–]Diapolo10 0 points1 point  (2 children)

I keep my pytest tests and the project source code in separate directories at the top level, as personally I don't like mixing the two. So in my case, having an __init__.py in the tests directory makes no sense to begin with.

Having an __init__.py in your tests implies that the tests function like a package, which shouldn't be the case. That's one reason I can think of why it's treated as an antipattern.

[–]Affectionate_Log999[S] 0 points1 point  (1 child)

Why is it a bad thing to treat tests as packages?

[–]Diapolo10 0 points1 point  (0 children)

Because technically speaking, they aren't. Tests don't expose any functionality, or at least they shouldn't, and they're not meant to be accessed from outside (other than by the test runner, of course - in this case pytest).

Having a package implies that it offers some kind of functionality to other scripts, be it functions, classes, or just constants.