{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "@id": "https://www.vidyasource.com/blog/not-about-unit-integration-tests-about-confidence/",
  "url": "https://www.vidyasource.com/blog/not-about-unit-integration-tests-about-confidence/",
  "mainEntityOfPage": "https://www.vidyasource.com/blog/not-about-unit-integration-tests-about-confidence/",
  "headline": "It's Not About Unit Or Integration Tests. It's About Confidence",
  "description": "Forget traditional testing categories and focus on what builds confidence. Use AI to generate test data efficiently.",
  "datePublished": "2025-05-30T00:00:00.000Z",
  "author": {
    "@type": "Person",
    "name": "Neil Chaudhuri",
    "jobTitle": "President",
    "url": "https://www.linkedin.com/in/neil-chaudhuri/",
    "sameAs": "https://www.linkedin.com/in/neil-chaudhuri/"
  },
  "publisher": {
    "@id": "https://www.vidyasource.com/#organization"
  },
  "image": "https://www.vidyasource.com/img/blog/testing-microscope.jpg",
  "keywords": [
    "Agile",
    "Java",
    "Spring Boot",
    "Software Engineering",
    "Programming",
    "Testing",
    "Continuous Integration",
    "JUnit"
  ],
  "articleBody": "If you write Java code, you probably know Dan Vega. His talks and YouTube channel have helped countless Java engineers get better. Dan recently offered\nsome pointers for dealing with the challenges of integrating with a new API in your Spring Boot application. I found one of them particularly\nimportant.\n\n> Always test your JSON deserialization separately before diving into HTTP calls\n\nI couldn't agree more, but I think this is really one example of a broader point about testing your code efficiently.\n\nI have never cared for the \"unit test\" vs \"integration test\" distinction. For one thing, it's been like 20 years and we still can't agree on how to define them.\nBut more importantly, I don't love defining a test by its architecture. What matters is its purpose. In other words, we should always be asking two important questions:\n\n* What is the thing I am worried about that this test helps me figure out?\n* What is the simplest and fastest way I can figure it out?\n\nIn Dan's example, there is an issue with how the Spring Boot code processes the response from that new API call. There are multiple possible reasons that can happen.\nThe first one is this: Does the shape of my data model (probably a JavaBean or Record) match the shape of the JSON response? Or more simply, am I actually\ngetting back what I expect to be getting back? It's a deserialization question.\n\nThere are a lot of ways to test this. Many devs would test against the real API. That incorporates the network when you don't need it and makes the test complicated to set up,\nslow to run, and unpredictable because you have introduced network side effects. You may also have to contend with rate limits on the API. Other devs might be a little more clever\nand use [Testcontainers MockServer](https://testcontainers.com/modules/mockserver/) to mock the API, but even that's overkill. After all, you don't need infrastructure of any kind. All you need is JSON.\nUse AI to model as many stub API responses as you want. The best way would be model them on an OpenAPI spec if the API makes one available. If not, prompt your AI\nwith the expected JSON shape to generate test inputs. This allows your tests to be simple, concise, [pure functions](https://docs.scala-lang.org/scala3/book/fp-pure-functions.html) using the bare minimum to verify your deserialization strategy.\n\nThat will very likely be the problem. If it isn't, then you can move on to other possible causes. Think about what those might be. For example, maybe HTTP headers are causing Spring Boot not\nto activate JSON deserialization. No matter what, lazy load complexity as you go. Spring Boot offers [HTTP mocking](https://spring.io/guides/gs/testing-web). If you feel like you need a network and real HTTP, upgrade your test\nto use Testcontainers. If all else fails, then you can test against the real API, but I would personally prefer to improve observability to look for the problem. Then when you\nhave a suspect in the case, write a test for your theory.\n\nBy the way, these ideas go beyond Spring Boot and even Java. They apply to any problem in any stack. Identify the core concern you want to test and do it with as little ceremony as possible.\n\nAnd please forget about [code coverage](https://www.vidyasource.com/blog/code-coverage-is-killing-you/). Unless you have a boss who doesn't know any better."
}