It is hard to believe that JUnit 5 has been out for five months! Already we have our first feature release. There are quite a few changes in 5.1 and you can see them all in the release notes. In this article, we focus on a few of the changes that I think are the most impactful to the day-to-day tasks of writing automated tests…
I’m in the middle of several talks on JUnit 5, so it’s safe to say that JUnit has been on my mind lately. In the last article in this series, we covered how to use test interfaces to encourage good behavior.
In this article, we look at the improvements the JUnit team has made to filtering and conditionally disabling tests in JUnit 5….
JUnit 5, released in September of 2017, is the first major release for the popular JUnit testing framework in a little over a decade. I recently presented on JUnit 5 at Lava One Conf in Hawaii in January. If you have heard about JUnit 5, but are not yet familiar with it, you can check out my presentation here, as well as the JUnit 5 User Guides.
While researching for my presentation, one new feature in JUnit 5 really caught my eye was the ability to declare tests on default methods in interfaces. This feature caught my eye because two issues I frequently face are encouraging developers to write automated tests and promoting consistent patterns across the enterprise. In this article we are going to look at how test interfaces can help accomplish both of these goals.
Attention: The following article was published over 3 years ago, and the information provided may be aged or outdated. Please keep that in mind as you read the post.This article is part of my blog series on automated testing promoting my new Pluralsight course Effective Automated Testing with Spring. Automated testing is an essential step in the development process (as …
It seems that quite often we read stories in the news about computer systems being cracked and data being compromised. It’s a growing concern that should be a consideration for everyone in Information Technology. There is probably not just one solution that will keep all data safe, but hopefully small efforts in many areas will provide us with the best possible solution.
In this post, I show a solution for encrypting sensitive files for local use with Java’s Encryption library & tying directly into Spring Batch readers and writers.
Recently we began writing a Spring Batch application that would handle sensitive data. The application servers were set up with some very good, basic security, but we felt the data could use some extra protection.
The data would be delivered to the company on a well-protected and secure FTP server. Mark Fricke did an excellent post recently on Spring Integration and Spring Batch in which he discusses downloading an encrypted file from a FTP server and decrypting it. Unfortunately, this was not exactly the problem we had. We needed to download a unencrypted file, but never write it to the Application Server unencrypted. But, we needed to be able to read that file and process it in Spring Batch.
Using Java’s built-in cryptography, we are able to extend Spring Batch to encrypt the file on the disk and then read that file in a Spring Batch Reader. In addition, we can write the results out as an encrypted file then transfer that file back to the secure FTP server as clean text.
Wow, that sounds like a lot and will be a really complex solution. Actually the code turned out to not be all that complex. This solution relies partly on the Delegate Pattern I wrote about before, so I will be using the same code I developed for that and just showing the changes here. Please refer back to the original post…