Hacker News Reader

Comment by MrPowers | Hacker News Reader

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

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():

View on HN

I 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.

Do 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.

They'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).

I 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?

This grouping convention reminds me a lot of Better Specs from the Ruby world:

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.

The 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.

You could call it aesthetics, but it's also readability, and that's an important aspect of tests.

My 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.

Reply on news.ycombinator.com