Starting from a wrong analogy to raise real thinking and questions about TDD.

Interesting tool for diffing database tables. Should come in handy for tests.

Ever wondered where fuzz testing is coming from? This is an important bit of history.

This is a technique which is definitely underestimated. There are plenty of libraries out there allowing to use them.

Good advice indeed. Having asserts using appropriate matchers can go a long way understanding what went wrong.

Maybe a bit dry, but gives a good idea of how a fuzz testing harness works. And also how it can be tweaked.

Interesting use of database templates and memory disks to greatly speed up test executions.

This is indeed too often overlooked. Producing a test list and picking the tests in the right order is definitely a crucial skill to practice TDD. It goes hand in hand with software design skills.

Indeed, don't mindlessly add tests. I find interesting that the doubts raised in this piece are once again concluded using an old quote of Kent Beck. What he was proposing was fine and then over time people became clearly unreasonable.

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.