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.

Some good points in this list although I'm not in full agreement with everything (especially the one about the lack of usefulness for TDD). The importance and the impacts of the tooling is often underestimated indeed. The last two random opinions about mocking and overtesting are very much true as well.

Very interesting musing about the technical terms we often use wrongly and how it difficult it is to be understood.

I don't quite subscribe to some of the terms used (even though I see the point of not calling this API). Still I think this is a very good way to approach design, it's also why I like TDD, the tests force you to see how the code is used. If it ain't pretty there's a problem.

Likewise I'm more and more unconvinced about the unit vs integration tests distinction. It's likely a continuum between them. I like the proposed axes for classification here. I wish they'd be a bit more orthogonal though.

Very good reminder that as an industry we're quick to blame external factors for our own failures. Of course we can be given a bad hand, but sometimes we'd have failed with a good hand as well.

Nice application for testing APIs.

Interesting musing on the skills required, why it's actually hard to apply them... clearly it's because you never find a real place to learn them so that ends up being on the job.

Good guidelines to improve end to end tests. I especially relate to the first one, the test API is very important for those, otherwise they become a chore to maintain and understand.