.png)
This most recent meetup, we gathered in Blue Ash for another Code Craft Community meetup, better known as C3. If you’re unfamiliar with C3, the idea is simple: software developers of all skill levels get together to practice coding together, usually through katas, pair programming, and spirited discussion.
This month was an exercise in integration testing. Integration testing is a bit more involved than standard unit testing. If we define unit tests as making sure that your code is internally consistent, then we can define integration testing as making sure that your code is consistent with code that you integrate with (owned by other people).
The Kata: A gap in unit tests
Our starting point was a small web API that served as a wrapper for JSONplaceholder.typicode.com (which, if you do a Google search for “free an open web APIs for academic demonstrations” is the first result). Our task was to implement a special way to query data. The unit test for this query was already written, complete with a stubbed response from JSONplaceholder.
However, I made a sneaky little mistake in the stub! I intentionally made it so that the stub did not perfectly match the real response from the real JSONplaceholder API. Therefore, when the developer finished writing their implementation and got their unit test to pass, the live version of the application would hit a runtime exception.
My goal was to point out that, sometimes, unit tests can be misleading, especially when they are written by developers who are a little less detail-oriented (like myself!). This is one scenario where integration tests can help, because they closer represent how the application will behave in a live production environment.
In the sample solution that I provided for the group, I implemented WireMock for recording and replaying live http calls so that these integration tests could run in controlled scenarios.
What Jumped Out (For Me, at Least)
Wow! Did you know that developers have opinions on what should and should not be tested?
First of all, we should admit that this integration test was in no way shape or form necessary. A manual test revealed the issue; an automation test does not provide any more insight nor add any value.
Second of all, there are significant caveats to what qualifies as an integration test. We agreed that a “true” integration test would involve making live calls against the live downstream APIs. Anything else (even a recording of a live call that gets replayed on subsequent executions) is not a “true” integration test.
Finally, there are important considerations about what should actually be integration tested. Integration tests are difficult to write and have a significant performance impact on a test suite; therefore, you should write them sparingly. There was a consensus that the contrived scenario in this kata did not merit an integration test.
Why This Matters (Especially Now)
With AI assistance, developers are able to write more code faster than ever before. This gives developers an opportunity to spend more time testing their code. Developers should spend more time learning testing techniques so they can apply them when appropriate.
Join the conversation
If you’re interested in conversations like this:
Join our Discord to stay connected between sessions and come to the next C3 meetup to build, question, and learn alongside the community!
We host C3 regularly at our Blue Ash office, and new faces are always welcome.
