Testing Spring Repositories with Flyway
With my recent job change, I’ve gotten a chance to use Spring Boot in anger a bit. It’s been fun, and I’ve learned a fair bit about the current state of Spring (I still love you, Jakarta EE!). One of my tasks involved adding a query method to a repository, and I wanted to make sure the query worked before I pushed it upstream. To do that confidently, of course, required a unit test. In this post, I’ll show how remarkably simple it is to test Spring Repositories using Flyway to set up schemas and test data.
When Testing with a Different Database Chokes on Your DDL
I recently found myself writing a test that needed a database. Unfortunately, our testing database, H2, doesn’t support all of the features of our production database, PostgreSQL. This meant that the Flyway migrates used to manage the production database broke in the testing environment. The fix for this turned out to be pretty simple.
Gradle Tip: Running a Single Test
Using Maven, to run a single test (class), you would issue
mvn -Dtest=MyTest. Gradle has similar functionality (
gradle -Dtest.single=MyTest), though it seems to be much more powerful. You can get all the details here.
Gradle Tip: Better Test Debugging
In a recent post, I showed how to attach a debugger to tests run from the command line via Gradle. While it worked, it turns out that it’s a bit over kill. Try this instead:
1 2 3 4 5 6 7 8 9
$ gradle -Dtest.debug test :compileJava :processResources UP-TO-DATE :classes :compileTestJava :processTestResources :testClasses :test Listening for transport dt_socket at address: 5005
Attach your debugger to port 5005, and off you go. No need to modify your build. Kudos to the NetBeans debugger output for helping me find that. ;)
Gradle + Arquillian + GlassFish Embedded
I’ve recently been migrating all of my personal projects to Gradle. Since I use Arquillian, that means migrating that part of the build as well. However, being still fairly new to Gradle, how to handle that integration wasn’t immediately obvious. Thanks to Benjamin Muschko and Aslak Knutsen, I’ve finally gotten a working setup.
Gradle Tip: Attaching a Debugger
Maven offers a nice script to allow for attaching a debugger to your build,
mvnDebug. Gradle does not. Again, though, Gradle makes it pretty easy to add this to your build.
Grabbing Screenshots of Failed Selenium Tests
For the GlassFish Administration Console, we have quite a few tests (about 133 at last count). Given the nature and architecture of the application, we’ve chosen Selenium to drive our tests. One of the problems we’ve faced, though, is understanding why a test failed due to the length of time the tests take (roughly 1.5 hours to run the whole suite). Sometimes, we can look at the log and know exactly what failed, but not the why. Did the screen render correctly? Did, perhaps, the click, etc. not get performed (we’ve seen instances of that) leaving the application in a state not expected by the test? Since I usually start the tests and move on to something else, we had no way of knowing. Until now. I finally sat down and figured out how to grab a screen shot when a test fails. I’ve distilled that technique down to its essentials, which I’ll share here.
Testing Android Applications with Maven, Android-x86 and VirtualBox
For a few months now, I’ve been working on a small application called Cub Tracker which is designed to help Cub Scout den and pack leaders track the progress of the scouts assigned them. I’m a big fan of testing, so I’ve done my best to follow TDD as I’ve worked on the app. Early on, it became clear that I needed a better way to test, as the official Android app is slow and unreliable at times. Via Twitter, I was turned on to Android-x86 and after a couple nights of hacking, I think I have a usable installation of Android-x86 under VirtualBox that has sped up my testing considerably. In this article, I’ll show you how I did it.
- Book Review: Real World Java EE Night Hacks - Dissecting the Business Tier
Running a Single JUnit Test
Part of my job as a developer is writing unit tests. Lately, though, I’ve been spending more and more of my time in our tests, which take a long, long time to run. For example, to run the GlassFish Admin Console’s StandaloneTest class, the last run took 17 minutes and 36 seconds. Clearly, something needs to be done to speed that up overall, but I have to wait for the entire class to run just so that I can see if my one new/changed test works. Try as I might, I have not been able to find a way to make the surefire Maven plugin run just that one test method. This morning, though, I happened to stumble across a new feature of JUnit (as of 4.7, if I read correctly) that did the trick for me, which I’ll share here.
Writing Selenium Tests for the GlassFish Admin Console
One of the results of the Oracle purchase of Sun has been an increased focus on testing — not that we didn’t test GlassFish before, but it was mostly manual in my area of the server. The task of automating this fell to me, and, after a little — ahem — testing, I settled on Selenium.
FacesTester 0.3 Has Been Released
After a lot of changes and a long delay, I’m pleased to announce that we have released FacesTester 0.3 tonight. This version has a large number of new features. Read on the for details.
FacesTester 0.2 Has Been Released
Today we released FacesTester 0.2. While this release has a number of bug fixes and more minor enhancements, one of the biggest new features is injection support. Leveraging the
InjectionProviderService Provider Interface (SPI) provided by Mojarra, FacesTester now supports the automagic injection of mock/test objects. For example, the following managed bean:
FacesTester Can Now Test State Saving
In my experience, a pretty common bug with custom components is improper state saving. Since JSF components are, currently, stateful, it’s important that custom components integrate with the frameworks state saving mechanism correctly. Unfortunately, it can be an error-prone process, as it’s a manual effort. Now, however, custom component authors can use FacesTester to exercise this aspect of their components to help insure proper state handling. This article will show how to use this new feature of FacesTester.
FacesTester 0.1 Released
About a month ago, I announced a new project, FacesTester, a JUnit-based testing tool for JSF that my good friend Rod Coffin and I have undertaken. Since then, Rod posted a very nice introduction to FacesTester usage. Today, we made our first official release, FacesTester 0.1. The version number should indicate that it’s still a work in progress, but it is already quite functional (I, for one, have been using it to build a test suite for Mojarra Scales, which has helped drive out features and resolve bugs very quickly). We wanted to push out a release to encourage people to download it, use it, and give us feedback.
So what does FacesTester currently support? Quite a bit. In this entry, we’ll take a quick look at what FacesTester offers, and what we have planned.
One of the issues that has always troubled me with regard to writing JSF applications (or any web application, really) is how hard it is to test them. Some time ago, while discussing various Java web frameworks, I stumbled across a class called
WicketTester, which is part of the Wicket project. Using this class, as best as I can tell, Wicket authors can easily test their applications very quickly. Having taken the advice of Dale Hanchey, and old college professor of mine, "Never be too proud to steal a good idea," FacesTester was born.
Unit Testing EJBs
As we’ve done more and more EJB development, we’ve had to think pretty hard about how to unit test our beans. We’ve tried a couple of different approaches (including not testing, which I don’t recommend ;), but weren’t ever just real comfortable with the results. I’m pretty happy with the method we’re using now, and it’s so simple, I’m a bit embarrassed that we didn’t think of it earlier.