Boundary/Contract Testing 101

Boundary/Contract Testing 101

This blog post covers: why boundaries constitute the structure, why E2E/Integration tests are not enough, what does it even mean "Boundary/Contract tests", who should create such tests & why and how to match expectations of more than one consumer.P.S. All the contracts covered here are supposed to be internal. No multi-tenancy, no general-purpose APIs. Nada. Having a modular split within an application/system is absolutely crucial (beyond some scale), but ... like everything in this world, this comes with certain price to pay & challenges to tackle: boundary correctness - are boundaries set reasonable (to maximize the…

Read More

Distributed responsibility for Architecture - is it even possible?

Distributed responsibility for Architecture - is it even possible?

I've encountered a very similar situation in so many companies: their IT landscape grew all the time (while nothing was decommissioned), layers they've initially got became more complicated or even split into sub-layers: sometimes parallel, sometimes stacked. Obviously, different components frequently utilize different technologies, so the skill-set required to develop & maintain all that got significantly broader. Consequences are numerous: architecture is complex & hard to govern (kept consistent, maintainable and manageable) developing a single, meaningful, end-to-end scenario requires a spike through many layers - various skills & some coordination are needed IT managers are usually far more afraid of…

Read More

Few test-related tricks for (even) the old dogs

Few test-related tricks for (even) the old dogs

Just some random thoughts / stuff I've bumped into recently. Enjoy. Interweave tests in support I love this legacy code rule (it's supposed to help fighting the technical debt): When you touch any existing piece of code, always leave it in at least slightly better shape than it was before. It makes sense, sounds golden, but it's quite intangible (or ephemeral) by its nature. What does it mean "slightly better shape"? ReSharper's auto-format is just fine? :P Fortunately, there's another rule - it's quite ancient, but someone has reminded it to me quite recently (for which I am very…

Read More

What if I told you ... that automating tests may change nothing?

What if I told you ... that automating tests may change nothing?

The prose of life Test automation ain't trivial & there are several reasons for that, including: need for scalable structure (hierarchy, naming, etc.) dealing with dependencies (coupling) insufficient speed of execution affecting dev agility shared resources impairing isolation inertia of data (incl. configuration, parameterization, etc.) But there are two even bigger issues I'd like to mention (& elaborate more about one of them): it's tricky to say whether you've automated much enough of what actually should be automated it's even harder to determined that it has been automated in a proper way (prevents bugs from happening, instead of just covering…

Read More