This is about behavior and not structure indeed. Put the focus at the right place otherwise your tests will quickly become expensive to update.
Calls a bit too much everything mocks while the term test double would have done the job. Still it stresses fairly well the importance of being as close to reality as possible and the tradeoffs we have to make.
Where does this style of tests shine? A few elements to consider.
In praise of property based testing. This definitely completes well the tests you write by hand.
Especially important in the context of tests indeed. As soon as you depend on some form of elapsed time you get into the territory of flaky tests.
Kind of sad to see asserts misused so much in the Python community. Still that's a good lesson for everyone: when using an assert, expect it won't get executed when in production.
Interesting way to reason about tests and classify them. I think it can be more useful than the strict "unit" vs "integration" that is way too widespread.
Nothing really new but well written. This highlights fairly well the importance of decomposing projects, having at least the broad strokes of the architecture laid down and how automated tests help drive the progress. It's nice to see it all put together.
Looks like a really neat tool for testing low level and kernel dependent details in a reproducible way.
Neat, short and simple post highlighting the important traits of TDD.
Often overlooked in test cases. Still it's not that complicated to setup.
Looks like a nice Faker alternative for Java projects. Turns out I was looking for something like that.
Interesting new compression format around the corner. Might turn out useful in some cases. I could definitely have used it last year for a test harness with very large reference data (so no, not gaming).
Looks like an interesting tool to deal with dependencies in some tests.
This what we should strive for with our tests. I like how he keeps it flexible though, again it's likely a trade-off so you can't have all the properties fully all the time. Still you need to know what you give up, how much of it and why.
Good piece. I like how it frames the debate, asking the right questions on where might be the assumptions on how testing is done.
Looks like an interesting tool when you need to diff databases. Definitely something I'd see myself using for large pin tests.
Indeed, I encounter that same idea in some people. I'm unsure where it comes from, it feels like reading and extrapolating from something more reasonable (it's like the "one test per line" I sometimes hear about). Bad idea indeed, it's fine to have several assertions, it's probably often required to avoid complexity explosion in your tests. This of course doesn't mean your test should become unfocused.
Interesting bug in SQLite. In particular look for the conclusion regarding tests and coverage. It's something I often have to remind people of.
Lots of very good points, I'm a proponent of TDD but I strongly agree with this. If it's painful and not fun, find a way to do it differently. There's likely a tool or some API you miss. Manage your effort.