This is a good explanation of why you should limit your use of mocks. It also highlights some of the alternatives.

Very interesting tools for testing and verifying concurrent code.

Nice talks, debunks very well quite a bit of the fallacies around people wrongly practicing TDD. I never realized how the root cause of those fallacies was the misusing of the "unit tests" term instead of "developers test". This was indeed the wrong term, knew it, but first time I realize how profound the effects were.

Interesting story about using unit tests by someone who thought it was a waste of time... until, they helped uncover a bug which was widespread. Also it was in an embedded context which comes with its own challenges.

This is apparently a much needed clarification. Let's get back to basics.

Interesting approach to reduce the amount of undocumented features because we simply forgot to update the documentation. Shows a few inspiring tricks to get there.

What are the outcomes of TDD? Do you want them? If yes, is the context compatible?

There will always be some design and some testing. The intensity of both activities needs to be properly managed over time though.

This can come in handy for automated tests which need to be ran from within a shell.

Definitely this, the message is often coming across lacking nuance. TDD can help you towards good design, but it's not ensuring you'll have a good design.

A little article which serves as a good introduction to the pytest fixtures. They are indeed very useful I think.

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.