Architecture, Customer Value, and Integration Tests

Architecture, Customer Value, and Integration Tests

I had an interesting discussion today that I think is worth writing about. I mentioned having a problem with having a very fat component in a system since integration tests usually become a nightmare. The idea was raised that architecture should not be driven by integration tests, but rather by customer requirements and value. While at face value, this seems intuitively correct, is that so?

I’ll start with a tangent. At a keynote in 2019, in a software conference, someone announced that the industry is shifting focus from serving the business and the systems first to serving the customer first.

The big problem I have with these kinds of statements is that they are void. They don’t communicate anything. Let’s think about this.

When was the last time you’ve heard a company focusing on systems first, or on business processes? And not on the customer first?

The same goes with the integration tests versus architecture. Of course, the customer requirements are first; that’s why we write integration tests. Integration tests are simply a mirror of our system. We do them as quality gates to ensure our product does what we think it does.

If we can’t create them, it reflects the operational problems we have, where automation is a problem. It means we can’t have a headless no-brain install, but we need to configure a bunch of things to get an instance.

If they take forever to run, they tell us about the performance issues we have in the application and reflect on how the customers will engage with the application. Also, no one will run them.

It’s the same as with unit tests. Let’s see: Of course, we can build applications without them. People do that all the time and don’t realize it. We also do that, as hard as it is to believe.

But if it’s almost impossible to write a unit test, we know it’s a problem in our code, with validation impossible. No one would go and say, "unit tests shouldn’t drive code structure." What would that even mean, in a world where Test Driven Development exists?

That’s why if integration tests are having a tough time running, or not even existing, they most likely indicate a more systemic problem, and we should probably do something about it. Unit tests are a mirror of the code, and integration tests just a mirror of the system.

Article Photo from Pexels: https://www.pexels.com/de-de/foto/akustisch-audio-aufzeichnen-ausrustung-114820/