Hacker News Reader

Comment by danpalmer | Hacker News Reader

Pytest is pretty nice, especially when you get it configured with a bunch of plugins for the libraries/framework you're using, and write your own stack of injectors to test your application in different ways. The very lightweight dependency injection is a joy to use once you get used to it. Add in nice output formatting from the built in asserts, and plugins like pytest-randomly that encourage good test writing, and it's really a great setup for almost all Python testing needs. I'd even suggest that it's a great setup for non-Python testing if you want automation around running binaries that you're treating as a black box.

View on HN

I love pytest, and use it with Hypothesis[0] for property based testing. I also enjoy using pytest-bdd[1]

[0] - https://hypothesis.readthedocs.io/en/latest/

[1] - https://github.com/pytest-dev/pytest-bdd

If you like pytest and BDD I'd encourage you to check out my pytest library: https://github.com/hitchdev/hitchstory

With it you can write integration tests with typesafe YAML which double as user friendly documentation.

It also has inheritance (which gherkin doesnt) - e.g. a "buy golf clubs" story can inherit from "put golf clubs in shopping basket" story which can inherit from a "log in" story, etc.

Thank you. Your library seems nice.

Unfortunately, I have to say it... I hate YAML with a passion, k8s, github actions/gitlab ci, ansible, etc... When I'm doing ops jobs, I feel like I'm coding in YAML.

Btw, this hate for YAML birthed https://linkdd.github.io/tricorder/ :P

I understand the hate. I created StrictYAML, which this tool uses, because of it (see the Norway problem - that was me). Type safety is paramount and regular YAML does not have any type safety.

I also understand the hate from the perspective of tools which misuse YAML - putting loops, variables, conditionals, etc. in like ansible or CI tools do, like your tool complains about. I hate that too and haven't done it. I was somewhat inspired by ansible in the beginning but Ive come to understand that it was the wrong approach for configuration management and that a turing complete language is a better approach (i.e. like your rust tool).

I dont want to throw the baby out with the bathwater though. The syntax is a very clean way of displaying hierarchical data, which high level stories need. Nothing else matches - Gherkin is awful at that.

> I created StrictYAML, which this tool uses, because of it

I'll look more closely into it then :)

> Gherkin is awful at that.

When I use BDD, it's because I'm handed down scenarii written by non-tech people. And it's always in the Gherkin format, then I chose the right Gherkin engine for the right tech stack. That might be cucumber, or another.

>When I use BDD, it's because I'm handed down scenarii written by non-tech people. And it's always in the Gherkin format

Thats interesting. You're the first person I've heard of who actually did that rather than just talking about it.

I was under the impression that this worked ok for simple scenarios but with complex scenarios I think the syntax buckles - either you end up with very long, repetitive scenarios or vague scenarios. Or even both.

> you end up with very long, repetitive scenarios or vague scenarios. Or even both.

Almost correct :D

The BDD scenarii also act as "user stories" in a Scrum/Agile workflow. It was a nice way to re-use what the product owner requested.

PyTest is great and I love combining it with Hypothesis-Auto

https://timothycrosley.github.io/hypothesis-auto/

I really like the fixture system where fixtures can "expand" to multiple values. This is a great way to test combinations of configurations.

Exactly. I love writing tests that generate themselves. Things like expanding every value in an enum into a new test case so that new enum values are tested automatically.

This stuff isn't a silver bullet, but it can go a long way to commoditising certain kinds of code change such that the dev resource necessary for them mostly disappears. At my previous place of work we had quite a few non-engineers semi-regularly contributing actual Python code. It was mostly things like adding new enum values, or tweaking properties on classes, but we had robust testing that verified all of those sorts of changes in generic ways and automatically generated tests for new pieces, and it was basically hands-off from engineering.

Reply on news.ycombinator.com