> I don't understand the mentality of posts like this.
The purpose is simply to put my opinions and experience into writing. I chose to share in case it is useful to others, which it turned out to be. The intention is also to inspire teams to formalize their own list like this, and to establish a culture around how to write tests.
> I don't think it's true, but if it's true, make an argument.
That wasn't my purpose of this post. Every listed item in the article is a choice, for each of those there are alternatives with trade-offs.
> I don't think you know what a good test is.
Likewise, from what you describe as a "powerful" test sounds to me like nightmare to maintain and it saddens me to think about what you have left behind for posterity over the course of 30 years. I don't think tests should be powerful, I think they should be dumb and dead-simple to understand, and that they rather build usefulness in numbers.
Aiven | On-site Helsinki or remote (area varies per role) | full-time
Aiven is a DBaaS company, delivering among others fully managed PostgreSQL, MySQL, Kafka, Redis, and Clickhouse, as well as some ancillary services like connectors and Flink for Kafka.
We have a number of roles open in different domains and regions, my team specifically is looking for Senior Software Engineers who want to work with Kafka and Flink.
I think Aiven is a pretty exciting company to work for, where one can have quite large impact, and work on actually interesting problems. If it sounds interesting, check out our job postings:
I was interest in a position at Aiven some time back. Did a recruiter screen and then a manager screen and then got asked to do a 20 hour take home assignment in Python that was to be completed in a single week. I politely declined at that point. Is that still part of the hiring pipeline?
From the docs:
extras_require
A dictionary mapping names of “extras” (optional features of your project) to strings or lists of strings specifying what other distributions must be installed to support those features. See the section below on Declaring Dependencies for details and examples of the format of this argument.
The purpose is simply to put my opinions and experience into writing. I chose to share in case it is useful to others, which it turned out to be. The intention is also to inspire teams to formalize their own list like this, and to establish a culture around how to write tests.
> I don't think it's true, but if it's true, make an argument.
That wasn't my purpose of this post. Every listed item in the article is a choice, for each of those there are alternatives with trade-offs.
> I don't think you know what a good test is.
Likewise, from what you describe as a "powerful" test sounds to me like nightmare to maintain and it saddens me to think about what you have left behind for posterity over the course of 30 years. I don't think tests should be powerful, I think they should be dumb and dead-simple to understand, and that they rather build usefulness in numbers.