Quarkus Dev Services, jOOQ, Flyway, and Testcontainers: A Full Example
I have written a few posts about using Quarkus with Testcontainers, Flyway, and jOOQ. Since posting those, I’ve learned some new tricks that have changed how I integrate the various tools. In this post, I’d like to share a complete example that shows how use Quarkus, Quarkus Dev Services, Testcontainers, and Flyway together for a zero (ish) local config setup.
Testing with Quarkus, jOOQ, and Testcontainers Redux
In a recent post, I showed how one could fairly easily test your Quarkus application against a Testcontainers-managed Postgres database. While that works great, my set up is a little more complex, and I found the solution lacking. In a nutshell, as part of my build, I use Flyway with H2 to create a schema, then jOOQ’s code generation against H2 to create the needed classes. That all worked well enough until I found some types that didn’t quite map correctly against newer versions of H2 (a security issue necessitated the update), so I decided I should finally make use of the same database from start to finish. In this post, I’ll show how I did it.
Testing with Quarkus, jOOQ, and Testcontainers
In a project I’ve been working on, I’ve been targeting PostgreSQL, but testing with H2. While that works, I’m a big fan of having the test environment match production as much as possible. That said, I don’t like to have external system dependencies for tests, such as requiring having a database installed. That’s where Testcontainers comes in. In this post, I’ll look at how I integrated Testcontainers into my Quarkus+jOOQ project
A Quarkus Command Line Application
Most people know Quarkus as a great way to build fast, scalable microservices. What many may not be aware of, however, is that Quarkus can also be used to build command line applications as well. In this post, we’ll take a look at how we can leverage the Quarkus ecosystem we already know to build a command line utility quickly and easily.
Microprofile Fault Tolerance Retry in Action
As part of some of my recent work, I’ve gotten some exposure to some Microprofile specs I’ve not had the opportunity or need to use. One of those is Fault Tolerance. I was curious to see it action, so I’ve cobbled together this simple example that demonstrates some of that spec’s features, namely retries and fallback.
Securing and Testing Quarkus Applications using Keycloak and Wiremock
Obviously, web apps need to be secured. If you’re brave (and some might say foolish), you can roll your own security. Unless you have compelling reasons to do so, however, you probably shouldn’t. Almost as if by design (nyuk nyuk), Quarkus makes it easy to use any OpenID Connect server. One such server is Keycloak, an open source offering also from Red Hat. If your experience is like mine, though, securing endpoints makes testing a touch more complicated. In this post, I’d like to present and walk through a complete example of a secured Quarkus app, using Keycloak, JUnit and Wiremock.