Put another log on the fire my friends and draw near as I divulge another secret of our long misunderstood artform.
An integration test is nothing but a magical ritual where the oft uttered, "it worked in dev!" is both a battle cry and a lament.
It's a rite of passage, marking the transition from the blissful innocence of coding in a vacuum to the sobering reality of everything is connected, and nothing is simple.
It’s where expectation meets reality and they rarely get along.
— Rajesh Jethwa
The big Seven
Developer
UI Integration
Backend Integration
Smoke
Contract
Non-functional Simulations
Architecture
Key Insights
🔥 Smoke tests are like a gas leak - you can smell it but you might not know where it comes from.
🧩 UI integration tests are a little more expensive to build, but they are still your friend because they are fast and provide a reasonable simulation of the UI.
🧪 The contract tests test everything you would mock or double for a reality check, ensuring that the tests are still following the same rules as reality does.
🧪 Integration tests ensure a wide array components work together as expected.
💡Test no more than necessary, as tests need to be maintained, just like comments in code.
🤖 AI can explain code on the fly, reducing the need for extensive documentation and comments.
🧪 The definition of a unit test can be polarizing, with some defining it as a function or method, while others consider a class or component as a unit.
Audience: “How do you explain what an integration test is so so that your peers will agree with the definition?”
Disclaimer: the original conversation had a humorous stage, some of the responses may be satire. I leave it up to you, dear reader, to pick your favorite.
“my team usually assumes integration testing as validating modules components of the software that are not external to the system. I mean components we don't own. we usually prefer e2e/acceptance tests”
”It's okay to use in-memory DBs for integration testing”“A test that is slow flaky and only tests a set of components that you think need to be "integrated" together but are not the overall behaviour of the systen. So in reality, any random selection of classes and functions that work together that you pick.”
“Using hexagonal terminology: integration test = a test whose SUT involves multiple domains or adapters”
“Placing an order with first name “test” and username “test”.”
“Tests that have friends overseas (so I/O is involved)”
“An integration test is when you charge a real credit card to test the payment processor.”
“There are integration tests. And there are derivative tests
Integration tests will determine how much code you have under the curve. This is how you get good code coverage
Derivative test will test the slope of the curve your code makes. Are you writing a lot of code? Or are you removing more than you write
We always want to be writing as much code as possible
There is a common misconception that we should write tests ourselves
No. If we write tests, that is a manual step. Not an automated one. Let the derivative and integration tools do the testing for you”“It's like expecting a smoothie but forgetting to put the lid on the blender. Integration tests check if you're going to enjoy your drink or spend the afternoon cleaning the ceiling.
I have used this analogy in the past :)”“you know, its when you proudly tell your team you'll gonna tame the legacy monster and get the main line of features covered with unit tests. after a couple of hours you realize that in order to test you need to refactor, but can't do so due to the lack of tests. there was that pal that talked about approval tests but thats nonesense you cant get your head wrapped around. Suddenly the lightning strikes and a brilliant idea is born. E2E tests. which works well until you find yourself searching for a way to reset your whole db after every single test. also you arent sure whats more confusing, css or xpath. the thing you're sure is that neither gets you the selector you've been looking for. finally the thing you end up writing is called integration test. it works, it gets the job done aaaaand next thing you see is still a legacy codebase but now with flaky tests.”
“It’s an old old wooden ship used during the civil war era”
“It's everything but the unit tests.
It's the tests that always break.
It's the test that we don't need.
I have a lot of wrong answers 😂”“An integration test is a test so old you don't understand it so when it goes flaky you just switch it off, but it's also so big you're too scared to delete it in case it's important or you get in trouble.”
“It's a test to see the right time after placing all the hands of a clock together.”
🎙 Comment on “7 Types of Tests”
As always you can also find the episode on Youtube, comment on the Our Tech Journey community forum or pick your favorite platform in the sidebar (web only) 👉
What do you think of the episode?
Agenda Board
Implementation vs. Testing
A well-functioning product engineering team will likely spend 50% / 50% of their time between features and test-writing. Organization that neglect quality or do not have a culture of technical and operational excellence will optimise for 100% untested feature work—or manually tested.
The reality is that all such endeavours go from full-implementation, no testing to full stop and fix things. And that’s merely the best-case scenario. Such short-termism is simply not sustainable, and results in death march loops.
Death March or Excellence?
Share this post