Good reference to get an idea about what we should be considering when we talk about unit tests.

At some point the complexity is high enough that you indeed need more tools than only handcrafted tests to discover bugs.

Of your tests are friend with implementation classes in C++, then something is wrong. Such tight coupling between tests and implementation is not welcome.

Definitely be careful when using mocks. You can end up introducing too much coupling between your tests and the application code. Use alternative test doubles instead and reduce duplication.

This is a nice little experiment. Not statistically relevant (there are other papers for that), but shows in the details how introducing Rust can impact the way people work. This is interesting because it means the safety gains are not only strictly coming from the (now infamous) borrow checker. We can't rely on everyone applying all the techniques necessary but for sure they're cheaper to put in place than with C.

Indeed a good reminder that TDD might not be possible to properly apply at the physical boundaries of the system.

Struggling with TDD? Really feel like you need to write the implementation first? This is a fine approach. One caveat though, you have to be very disciplined in the way you uncomment the code, otherwise you'll quickly loose the benefits.

Pointing out an important dilemma indeed. Which tests to keep over time? What to do with redundancies?

Definitely a nice trick for testing if an email is really sent by a system under test.

Very interesting research. Property-Based Testing made quite some progress the past few years but indeed it still needs to improve in term of usability. Looking forward to some of that research to get available in existing testing tools.

Another rebuttal of Clean Code. Most of it makes sense if not overdone. There's the usual confusion around the "unit tests" term though, so take that section with a pinch of salt.

A nice list of the techniques used to render shadows in games.

Indeed a good way to reason about tests and the value they bring.

Another example of why pytest is really a nice test runner. I really miss it on projects which don't have it.

This is an important trait to have for a developer. If you're content of things working without knowing why and how they work, you're looking for a world of pain later.

This could be a game changer to collaborative editing. Clearly a good competitor to CRDTs, should make it easier to build such features without a central server.

That sounds like a very interesting tool to simulate and test potential data loss scenarios. This is generally a bit difficult to do, should make it easier.

Interesting reason which would explain the Selenium flakiness. It's just harder to write tests with race conditions using Playwright.

This can definitely come in handy. I can see myself using it for testing behaviors in the past or the future on a real application. This should also help writing automated tests in some cases.

Three good advices on writing automated tests. This is necessary but not sufficient though.