Instancio: Random Test Data Generator for Java (Part 1)

By now hopefully all of us, developers, have embraced unit testing. Good test coverage of our codebase, combined with that green checkmark after running the tests, gives us a warm fuzzy feeling that everything is in order. While we all like that warm fuzzy feeling, writing tests usually requires some plumbing. This is the "boring part", where you create your test objects and manually set them up with dummy data. Oftentimes the values themselves don't even matter. A typical example of this is testing "converter" logic. For example, we might be converting a JPA entity to a DTO, or a JAXB class to something else. Such a test might look something like this:

Java
 
@Test
void verifyCustomer() {
  Customer customer = new Customer();
  customer.setFirstName("John");
  customer.setLastName("Doe");
  customer.setAddress(new Address("123 Main St", "Seattle", "US"));
  customer.setPhoneNumbers(List.of(
    new Phone(PhoneType.HOME, "+1", "123-44-55"),
    new Phone(PhoneType.WORK, "+1", "555-77-88")));
  // ... etc
  
  CustomerDTO customerDto = customerMapper.toDto(customer);
  
  assertThat(customerDto.getFirstName()).isEqualTo(customer.getFirstName());
  assertThat(customerDto.getLastName()).isEqualTo(customer.getLastName());
  // ... etc
}


Testcontainers: Containers for Testing

I’ve always been more of a fan of unit tests than integration tests, mainly for one reason: I don’t need anything external to be able to run them. I don’t need to have a database started, an external service to connect to, or a Kafka running to be able to run the tests and therefore to be able to develop. 

That’s in the development environment, but if we’re talking about the integration environment, then I won’t even start. For example, in the case of databases, we have the option of doing the tests with H2. But it is also true that depending on the type of project, it could be that something which works perfectly in H2 does not work in the database for which we are developing: As sure as we have often relied on:

The Problem With Annotation Processors

For reasons unknown, broaching the subject of annotation processors seems to elicit some primordial fear in developers. People tend to associate annotation processing with borderline witchcraft and sorcery performable only by the most adept of basement wizards. It doesn’t have to be that way. Annotation processing doesn’t have to be the big scary monster hiding under the bed.

Monster Under the Bed
Image taken from https://sourcesofinsight.com/monsters-under-the-bed/


Spring Boot – Unit Test your project architecture with ArchUnit

When building software, it's common for development teams to define a set of guidelines and code conventions that are considered best practices.

These are practices that are generally documented and communicated to the entire development team that has accepted them. However, during development, developers can violate these guidelines which are discovered during code reviews or with code quality checking tools.

Microservices in Publish-Subscribe Communication Using Apache Kafka

Publish-Subscribe Communication Using Apache Kafka.
You may also like: Comparing Publish-Subscribe Messaging and Message Queuing

Publish-Subscribe Messaging systems play an important role in any enterprise architecture as it enables reliable integration without tightly coupling the applications. The ability to share data between decoupled systems is not a problem that is easily tackled.

Consider an enterprise with multiple applications that are being built independently, with different languages and platforms. It needs to share data and processes responsively. We can achieve this using Messaging to transfer packets of data frequently, immediately, reliably, and asynchronously, using customizable formats. Asynchronous messaging is fundamentally a pragmatic reaction to the problems of distributed systems. Sending a message does not require both systems to be up and ready at the same time.

Constructor Value Vs. Observer in Java

Who wins in the battle between Constructor Values and the Observer? Well, it depends.

Who Belongs to Whom?

It is common to connect two components using constructor parameters. This procedure can be seen very clearly, for example, in the construction of graphic surfaces. Take the following source code:

public class SubView {
  private MainView mainView;
  public SubView(MainView mainView) {
    this.mainView = mainView;
  }
  public void buttonClicked(String input) {
    mainView.setInputValue(input);
  }
}


Integration Test With Multiple Databases

Multiple databases

Recently, I worked on a generic JDBC component that is able to execute SQL queries to read/load data from/to any database supporting JDBC specification and providing a driver for it.

As a part of this development, I needed to ensure that the component can run correctly with multiple databases. So, what I needed was to have multiple database environments and integration tests that can be parameterized and executed on all the environments.

Changing the Order of Tests in JUnit5

Multiple tests within a suite are expected to be independent in most cases. If changing the order that the tests are run subsequently causes a different outcome, such as a failed test or different failed tests, it is possible, or even likely, a sign of an underlying bug in the test class or application under test.

A test could cause an inconsistency in the database that is only detected when tests are executed in a different order. Another possibility is that a test positioned at the end could inadvertently take into account a change in the data from an earlier test and fail when it is run in isolation or at the beginning of the suite.

Unit Testing of jBPM Process Flows

Unit testing is an important step in the software development life cycle to ensure that your product works the way it is intended to work. Back in the day, it used to be just a step that developers had to perform to evaluate their work. In today’s world, it has become an essential part of the CI/CD pipeline as it is not just used to determine quality based on functionality but also to determine code promotion eligibility based on various numbers (pass/fail ratio or code coverage percentage).

jBPM, being one of the most modern, open-source bpm products, provides rich capabilities for unit testing BPM processes. This allows jBPM processes to be treated just like any other Java-based artifact. The jBPM tool kit provides an extension of JUnit test classes that allow one to easily unit test business processes defined in BPMN2.