Software testing with Java means: unit testing, integration testing, API testing and UI testing form a pyramid of increasing complexity and runtime. Tools such as JUnit, WireMock, Selenium and Maven cover the individual stages. Behavior Driven Development combines technical tests with natural language descriptions in Given-When-Then format.
Key Takeaways
- Unit tests in Java take milliseconds and are often written by developers themselves, while UI tests with Selenium take minutes and consume significantly more resources.
- Test automation not only costs personnel costs, but also electricity: anyone running 25 browsers in parallel in different versions must consciously weigh up this effort against the actual test requirements.
- Maven not only controls dependencies, but also which tests are executed in which step of the build pipeline, giving testers direct control over the test suite.
- According to Pascal Moll, Behavior Driven Development is also suitable for test data management: data tables can be embedded directly in Gherkin feature files; for large quantities, it is recommended to switch to CSV files.
What testing is really about before Java comes into play
Not all testing is the same. There are dozens of ways to test a system behind the one word, and you can only get started if you make a clear distinction between the basic concepts. Anyone coming from a development background or starting out with no programming background at all will stumble at exactly this point: which test type applies when, and do you need any knowledge of code at all?
The short answer: a basic understanding of test plans is important regardless of the programming language. The concepts can be implemented in Java in the same way as in Python, only the syntax changes. Java remains one of the most widely used languages, so it’s worth trying out the abstract ideas in concrete terms in this world.
The test pyramid in Java: from milliseconds to minutes
The test pyramid organizes test types according to width and runtime, and in the Java environment it looks classic. The widest step is at the bottom, the narrowest at the top, with something floating above it that does not fit into any fixed shape.
Unit tests are at the base. They break down the software into individual units, are written in a few minutes and run in milliseconds. In many projects, developers write these tests themselves, because they are quick and can be applied directly to the code.
Components are put together one level higher. This is where integration testing begins, followed by system testing and, at the top, acceptance testing. The system being tested grows with each level, and with it the runtime. UI tests, the classic at the top, are already in the minute range.
A cloud hovers above the pyramid: exploratory testing. They do not follow a fixed automation structure and supplement what the automated stages cover.
Which tools cover the Java test levels
Each level of the pyramid has its own established tools in Java. JUnit is the standard framework for unit testing and has equivalents in other languages, such as NUnit in C#. The principle remains the same, only the name changes.
For API testing, one level higher, mocking comes into play as soon as an interface is not yet complete. WireMock is a common tool here to simulate missing components. Surface tests run via Selenium. If you want to describe and test the behavior of the software in natural language, you end up with Behavior Driven Development, which can integrate API testing and other stages.
The following overview assigns the most important tools to their tasks:
| Level / Task | Tool |
|---|---|
| Unit tests | JUnit |
| API testing with mocking | WireMock |
| Surface Testing | Selenium |
| Behavior Description | Behavior Driven Development |
| Integrating Libraries | Maven |
Maven is more than a library manager
Maven controls the entire build cycle and makes handling test code easier. The cycle consists of several steps, each of which can be configured. Even a Verify step checks whether the configuration is valid at all before anything continues.
The core is building the code. Maven compiles, checks if everything is configured correctly, and pulls external libraries or parameters. Because most of the testing tools already exist as libraries, they can be integrated directly via this instead of integrating them manually.
In the end, you control which tests are run. The complete suite, only individual tests or only integration testing: everything can be defined via the configuration. This makes Maven a practical tool as soon as the test basis grows.
Testers and developers look at the same code differently
The most important peculiarity when testing Java code is the perspective, not the language itself. Those who write code think first about readability and maintainability. Edge cases and pitfalls are easily overlooked.
A tester turns the question around: What happens with invalid values? Does the software crash or does it catch the error cleanly? This perspective belongs directly in the Java code, for example via exception handling.
Error messages are themselves a test object. You check whether an exception appears at all, whether it appears in the right place and whether something unexpected happens instead. Testing exceptions is therefore a separate field, not a by-product.
How test data is managed in Java
There are several ways to manage test data in Java, and which one fits depends on the scope. In Behavior Driven Development, data can be written directly to the feature files. There, data is formulated in natural language according to the Given-When-Then pattern: given a situation, such as an open browser, when a button is clicked, then an action follows.
Within these Gherkin scenarios, data tables are the most common form of specifying test data. They hang directly in the feature file and are available to the test. This works well as long as the amount of data remains manageable.
If the data exceeds around one hundred lines, tables in the feature file become confusing. CSV files, which the test simply loads, are then more suitable. Databases can also be connected for larger or dynamic data sets.
Sustainability belongs in the test planning
Testing not only costs personnel, but also electricity, and this changes the question of how much you test. Every test case, every build pipeline consumes energy and money. Running lots of test cases has an impact on your own budget and on the environment.
That’s why it’s worth clarifying the goal of each test in advance. In an area where human lives are at stake, the focus is different than when testing a web form. The priorities shift, and with them the question of which test cases are really necessary.
Java comes into play here because it can be resource-hungry. UI testing can be driven to infinity, for example with 25 browsers running in parallel in different versions. That costs money. Thinking about these expansion stages in advance saves resources before they are used up.
There is so much knowledge in it that you can build on it. Once you have read it, you have a basic understanding and can decide which direction to go in.
Pascal Moll
