This article demonstrates some more advanced test first React practices. Specifically, API calls and mocks.
Stuart 'Stevie' Leitch on Software Development, Java Technologies, Security and Testing
This article demonstrates some more advanced test first React practices. Specifically, API calls and mocks.
React is a great choice for writing test first client side Javascript. The test ecosystem is mature enough to enable test first development of complex components. This article shows how to build a React component test first and introduces supporting test libraries Jest and Enzyme. In the next article we’ll look at more advanced testing including API testing and module mocking.
In previous articles, I’ve described how to test System.out with JUnit and how to test log4j with JUnit. This article describes how to test log4j2…
Following a recent article on how to Test System.out with JUnit, here’s a follow up on how to test log4J with JUnit. This article describes a technique to test log4J output in a JUnit test by adding a custom appender. This allows us to verify that log4j output contains expected Strings.
JSPs compile to Java code at run time. This is helpful if we want to test code changes without a build and deploy. However, if errors are introduced, they may not be spotted till it’s too late. A useful compromise is to validate JSPs at build time to verify that they will compile. The validator catches syntax errors before the application deploys and starts. This speeds up our build and test cycle and prevents silly mistakes slipping through to production code.
Edit: see also the follow up article on how to Test log4j with JUnit if you’re interested in specifically testing log output.
Just occasionally, it can be useful to verify output to System.out in a unit test. For example, if you’re testing application logging or if you’re using log output to sense some other behaviour. It can be tricky to properly mock behaviour of System.out but fortunately, it is possible to test System.out with JUnit.
Spring Boot Actuator provides assistance for application monitoring. Out of the box it provides information on application health, configuration and logging. It’s trivial to enable: simply add the spring-boot-starter-actuator dependency to a Spring Boot project in Maven or Gradle and it just works! The monitoring information is provided as JSON from HTTP endpoints or via JMX.
The Spring Boot Actuator trace endpoint is particularly handy. By default it shows the last 100 HTTP requests made to the application. This article walks through an Actuator demo and shows some of the configuration options to get the best from this feature.
Like a many things in Tomcat, there are a number of ways to enable remote debugging. Here’s the easiest way I’ve found to enable remote debugging in a Docker container running Tomcat.
The wonderful docker-maven-plugin from Spotify is a great way to build Docker images from Maven. If you bind it to Maven phases, it can be used to make a one-step build of a project artifact and its Docker image. For example, if you bind the Docker Maven plugin’s build goal to the Maven package phase, it will create your Docker image when you run a standard
mvn clean install
command. That’s neat, but the drawback is that the build will fail entirely if Docker is not available on the build machine. This somewhat goes against the Maven ideal of portable builds – we don’t want a build that works on my machine but not yours.
We can workaround this problem by making the Docker build optional and enabling only if Docker is available.