.png)
Much like documentation, testing can sometimes feel like a chore. Just another box to tick at the end of a ticket. But what if we thought about it differently? What if testing was the key to moving faster and actually enjoying the code we ship?
To get a realistic perspective on testing, we sat down with two of our full-stack developers, Charlotte Van der Voort and Daphne Deckers. They shared their experiences from different client environments, the tools they can't live without, and some nuggets of wisdom every (junior) developer needs to hear. Let's dive in!
What's the difference between just writing some tests and having a real testing strategy? Generally speaking, it boils down to structure and responsibility. Charlotte and Daphne's current clients are a great example of two possible perspectives.
“At my current client, testing is a team responsibility,” Charlotte explains. “We have guidelines, like making sure all code has unit tests, but the how is up to us. We want to build confidence by mimicking the real-world environment as closely as possible, even if there are limitations.”
Daphne, on the other hand, works in a more structured environment. “At my client, the strategy is very extensive,” she says. “We have clearly defined coverage targets for every level. If you don't meet these targets, your pull request fails. It's all written down in our documentation and baked right into our pipelines.”
In other words: there’s no one-size-fits-all approach. A company’s philosophy on team autonomy will influence its testing strategy. A highly autonomous team might be given the responsibility to test thoroughly, while a large, regulated organisation might (have to) enforce stricter company-wide rules.
At this point you might be wondering: which kinds of tests are there, and how do they relate to each other? A popular way of visualising it is the "testing pyramid." The idea is simple: a wide base of small, fast tests at the bottom, with fewer, more comprehensive tests as you move up. Each layer has a specific job and its own set of tools.
Unit tests are small, isolated tests that check a single piece of logic, like one function. They don't touch databases or external services, making them incredibly fast. You'll write a lot of these to cover different scenarios for each piece of your code.
For this, developers use frameworks like JUnit for Java. On the JavaScript side, you'll see Jest or Vitest in modern apps, and sometimes Karma in older Angular projects.
The next layer up is integration testing. This is where you check if different components of your application work together as expected. For example, when you call an API endpoint, does it correctly interact with the right services and pull data from the database?
This is also where you handle external services. Charlotte explains how her team deals with this for cloud applications: "We use a lot of AWS services, and it’s difficult to test those interactions locally. So, we use tools like LocalStack and Testcontainers. They spin up a mocked version of AWS services on our machines, which lets us run our tests as if we were in the cloud, without needing an actual AWS account."
At the top of the pyramid are end-to-end tests, which automate a real browser to simulate a user's entire journey. Tools like Cypress, Selenium, or Playwright are common choices here.
For Daphne, these tests are about more than just checking if the code works. “You're really trying to mimic what a user does. This helps you find issues that your code-level tests would never catch.”
In some environments, there's one final layer. Daphne describes her client's approach: "Our QA tests run against a live-like environment where all the real services are plugged in together. We’re not mocking anything here. We’re interacting with real AWS services and putting messages on actual Kafka topics. It’s the closest we can get to the real user environment before going live."
Tests act as a form of documentation. Instead of test1, name your test after the function and the expected behaviour... It makes your tests readable and clear.
If you're new to development, all this testing might seem like a lot of work. But building good habits early is one of the best investments you can make. Here are a few key takeaways from our developers.
Don’t think of testing as a yet another chore, but as a safety net that builds confidence. A well-tested codebase is easier to understand, maintain, and build upon, which saves you time in the long run. “When I make a change and run my tests, if they’re all green, I know it’s going to work,” says Daphne. “That confidence is a great feeling, especially on complex applications.”
The goal is always to automate. As Charlotte puts it, “You want to push a button and let it run. Doing everything manually just doesn’t scale.” However, a pair of human eyes is still invaluable. Analysts and business users often perform final checks to ensure business requirements are met and to test complex scenarios like accessibility.
This sounds minor, but it's key for readability. Charlotte recommends a consistent naming convention. “Instead of test1, name your test after the function and the expected behaviour, like shouldThrowExceptionWhenUsernameIsNull. It makes your tests act as a form of documentation.”
When it comes to unit tests, Charlotte’s advice is straightforward: “Keep it short and simple. The smaller and more specific the test, the better. Try to focus on the one thing you really want to test, and don't bring in a hundred other things. That’s what other types of tests are for.”
Don’t be afraid to use modern tools as a brainstorming partner. Both Charlotte and Daphne use AI assistants like Copilot and Gemini to suggest test cases they might have missed, ensuring all edge cases are considered. Just remember that you are still responsible for the final output.
In the end, a great testing strategy isn't just about picking the right tools. It's about knowing when a quick unit test is enough, and when you need to simulate a user clicking through the entire application. More than anything, it's a shift in mindset. You have to look at testing as something that gives you the confidence to make changes and take pride in the quality of what you ship.
A strong testing culture is the foundation of dependable software. Our consultants bring this quality-first mindset to every project.
Contact us to build your next Java and JavaScript application with confidence.
