Testing
Two threads run through these articles. One is about tests that describe behaviour: why behaviour-driven design is more than test syntax, why mocks often check implementation details, and a small library that makes tests read as given, when, then. The other is practical setup: running the same tests against several configurations, starting real dependencies in containers, and checking that message formats stay compatible. For testing event-sourced code, see the Testing guide.
7 articles
Announcing Strictland - new contract testing library for message compatibility
I just released something. It’s called Strictland. And it’s a contract testing library. Why did I do it? Before I go further, if you can’t…
How to configure a custom Test Container on the EventStoreDB example
Testcontainers became a popular way of setting up dependencies for integration testing. They’re not ideal, as configuring them to run your…
Mocking the native Node.js Test Runner
Last week, we discussed an overused but applicable pattern: in-memory bus. This time, we’ll continue with the leitmotif and talk about…
Behaviour-Driven Design is more than tests
Why did I name the testing library Ogooreck? Between my friends, I’m well known for my lame jokes. Ogooreck is one of them. Ogooreck is a…
How to set global setting for XUnit tests
XUnit is not my favourite testing tool; I already mentioned that in How to set up a test matrix in XUnit?. To be fair, none of the .NET test…
Ogooreck, a sneaky testing library in BDD style
Some time ago, I saw an excellent presentation of Dylan’s Beattie presentation - The Art of Code. It reminds us of what we are here for. By…
How to set up a test matrix in XUnit?
Each country has the go-to place for hiding from daily struggles. In Poland, we have Bieszczady. It’s a mountain range that’s also the…
