Cucumber Testing in Spring Batch

Dallas Monson Development Technologies, Spring, Spring Batch, Testing 3 Comments

With the evolution of microservices and the scalable nature of modern distributed architectures, batch processing seems to be falling out of favor. In fact, the term batch processing itself seems to be unfavorably associated with monolithic mainframe applications and thus does not seem to have much appeal.

Unless, of course, you are working on a project that is being designed to replace or modernize one of those mainframe applications. If that is the case, then likely some sort of batch process has come up with a non-functional requirement that needs to be dealt with in the new system.

For this specific concern, a very powerful framework has been provided: Spring Batch. It has many of the same features of a mainframe batch process like restart/recovery, chunk processing, and error handling along with exit codes. This framework allows developers to create powerful batch processing applications in the Spring Framework and enjoy the rich backplane of capabilities that this provides.

Continuing with the modernization thread, you will likely be tasked with providing some assurances to the business that the new, modernized process will produce the same outcome as the one that is being replaced. Here is where testing comes in, and where Cucumber specifically shines.

Cucumber provides behavioral testing support in the Spring universe. This allows developers and business users to collaborate through a common set of conventions and verbiage to validate that the app is behaving how the business intended as well as how the developer coded it.

In this post we will cover the following:
Why use Cucumber with Spring Batch
An overview of Cucumber and an example Cucumber Test
How to start with Cucumber and Spring Batch…

Web Development Business

Pseudo-Static Row Mappers, a Healthy Alternative to Static Row Mapping

Ryan McCullough Java, Spring Leave a Comment

If you know Spring, chances are pretty good that you’ve also worked with RowMappers and everyone’s #1 favorite BeanPropertyRowMapper. Okay, maybe not EVERYONE. But EVERYONE will acknowledge BPRM’s power potential and how wonderfully easy it is to use!

While BeanPropertyRowMapper may be the smartest and most beautiful on the RowMapper block, many in the industry refuse to give it the time of day, and for perfectly justified reasons.

Sometimes, when we can’t have beauty and wisdom, we’re forced to settle for loud and predictable. Yes, I’m talking about hardcoded, unchanging, tell-it-like-it-is, static RowMapper. Hate on them all you like, Static RowMappers are fast, easy to understand, and they seem to replicate like tribbles.

But, as many of you know, an application can grow into a swamp of one-off RowMappers. ESPECIALLY if you are working with a lot of high-throughput batch operations that need to run strictly optimized queries for performance as to avoid any unnecessary marshaling of data.

Recently, I’ve tried a mildly clever alternative to RowMapping I like to call Pseudo-Static Row Mappers. In this post, I introduce the basics of Pseudo-Static Row Mappers. We show how they give the tough rigid optimization and control of hard-coded naming and data typing while retaining BeanPropertyRowMapper’s spirit of freedom.

Fluent Assertions with AssertJ

Billy Korando Effective Automated Testing With Spring Series, Java Leave a Comment

I recently gave a presentation to my Keyhole team members about JUnit 5. I started off the presentation by covering the importance of automated testing, how lack of automated testing affects an organization’s ability to deliver code to production, and how without automated testing you are building legacy.

I pointed out two key benefits of automated testing: confidence you are fixing what you set out to fix, and confidence you are not introducing a new bug. A co-worker however pointed out an important third benefit of automated testing: providing living documentation.

My co-worker made the very good point that automated testing can do more than just checking for code correctness. It can also provide valuable documentation for current and future developers on a project.

In this article, we look at how using AssertJ can make automated tests easier to read and write. We take a look at how AssertJ improves the readability of assertions in test cases, as well as how it helps make the task of comparing complex objects and performing list validations easier to read and write. The goal is that when tests are easier to read and write, it will hopefully encourage developers to write more tests (i.e. documentation).

What’s New in JUnit 5.1

Billy Korando Development Technologies, Effective Automated Testing With Spring Series, Java Leave a Comment

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…

Conditionally Disabling and Filtering Tests in JUnit 5

Billy Korando Development Technologies, Effective Automated Testing With Spring Series, Java, Testing 9 Comments

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….