4 ms·
This 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 t
by klenwell 6y ago
This 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.