A good reminder of the reasons why the organization of your tests shouldn't necessarily match the organization of the application code. You don't want fragile tests, do you?

This is one way to frame it I guess. Code is indeed an investment, tests are here to protect it.

A good reminder that the complexity of tests should be as low as possible.

Both TDD and design docs complete each other well indeed. They just don't focus on the same activities in the project. That said, both later provide important insights on all the decisions taken to produce some code.

Even if you do use mocks to isolate your tests, at least don't nest them.

Or why it's hard to truly evaluate performance in complex systems. We often test things in the optimistic case.

A quick summary of the different properties you want in tests. In practice you'll likely have to find a tradeoff among them.

This explains quite well how TDD is made of several cycles of different length.

A bit long and dated for a some advice. Still it does a very good job going through all the different type of tests you'll want to find on your project and how they're structured.

Good proposals to shorten the time spent executing tests. Tighter feedback loops make everyone happy.

Testing sync engines can be especially challenging. This story from Dropbox gives ideas on how to do it well.

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.