4 ms·
I've found pytest to encourage tests with really long method names, examples from the post: test_refresh_failure test_refresh_with_timeout These get even
by MrPowers 6y ago
I've found pytest to encourage tests with really long method names, examples from the post:
test_refresh_failure
test_refresh_with_timeout
These get even longer like test_refresh_with_timeout_when_username_is_not_found for example.
pytest-describe allows for a much nicer testing syntax. There's a great comparison here: https://github.com/pytest-dev/pytest-describe#why-bother https://github.com/pytest-dev/pytest-describe#why-bother
TL;DR, this is nicer:
def describe_my_function():
def with_default_arguments():
def with_some_other_arguments():
This isn't as nice:
def test_my_function_with_default_arguments():
def test_my_function_with_some_other_arguments():
- TuringNYC 6y agoI just saw the github readme for this project. How is the describe variant different from just grouping the tests together into a module called test_describe_my_function.py and then having smaller named functions inside?
- klenwell 6y agoThis grouping convention reminds me a lot of Better Specs from the Ruby world: https://www.betterspecs.org/ https://www.betterspecs.org/ With rspec, you use the describe and context keywords. At one level, yes, it's mainly syntactical sugar. As the test-writer, the two approaches may seem interchangeable. Where I find it really helps is when I'm not the test-writer but rather I'm reviewing another developer's tests, say in PR. I find this syntax and hierarchy produces a much more coherent test suite and makes it easier for me to twig different use cases and test quality generally.
- theptip 6y agoThe readme says: > With pytest, it's possible to organize tests in a similar way with classes. However, I think classes are awkward. I don't think the convention of using camel-case names for classes fit very well when testing functions in different cases. In addition, every test function must take a "self" argument that is never used. So there's no reason to do this, aside from aesthetics. I'd recommend against doing un-Pythonic stuff like this, it makes your code harder to pick up for new engineers.
- ben509 6y agoYou could call it aesthetics, but it's also readability, and that's an important aspect of tests.
- theptip 6y agoMy suggestion is that adding a mini-DSL for parsing nested functions as nested tests is less readable for the average Python programmer who has not seen that plugin before. And I've never had a problem with reading class names vs. function names; we do that all the time when reading Python code. I think this is clearly in the realm of subjective preference for what "looks nicer", which I'd call aesthetics. On the other hand, this probably breaks your IDE's pytest integration, which would be an objective material downside. Whatever floats your boat though, definitely not a hill I'd die on.
- w0tintarnation 6y agoDo you have an opinion on grouping pytest tests in classes? class Test_my_function: def with_default_arguments(self): def with_some_other_arguments(self): If you can make your eye stop twitching after seeing snake cased class names, this is at least another option of grouping tests for a single function.
- poooogles 6y agoThey're already grouped by module which normally provides enough granularity (in my experience, I've only scaled this up to 50k LOC apps though so YMMV).
- ben509 6y agoI like the concept, but using the profiler to grab locally declared tests is a bit more magic than I'm comfortable with in my tests. Something like this might be a good compromise: def describe_my_function(register): @register def with_this_thing(): ... I think most Python devs understand that "register" can have a side-effect.