In the last installment (Part II), we walked through creating and executing our very first test. With that out of the way, let’s move on to something slightly more complicated. Elements that cannot be found typically are elements that are initially hidden. In this post, we’ll cover how to test for an element or component that isn’t found.
I am a Spring/Java developer (primarily) and an advocate of unit testing.
There is often a debate over what constitutes a unit test, an integration test, a system test, etc. But, most of us agree that tests keep you from going “off the rails” once a project becomes sufficiently complex.
However, I have found very few discussions on architectural tests. What keeps us from deviating wildly unintentionally from our original, planned architecture? And, after all, how many enterprise projects even keep the same architects from the beginning of the initiative to shelving and replacement?
In this blog, I introduce ArchUnit, a Java architecture test library for specifying and asserting architecture rules in plain Java. We’ll discuss how it works to mitigate architectural risks in developing quality enterprise applications…
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…
Testing has a bad rap. The thought of writing unit tests to exercise code with the goal of 100% code coverage can be overwhelming for many projects. The number of man-hours to set up tests, create mocks when needed, test boundary conditions, contrive odd ball test cases can take some steam out of the project. If this is the definition of test, then yes, writing these types of tests can be tedious and feel meaningless.
I am a proponent of writing tests with a narrow focus. The tests I describe here show the completion of a story or the resolution of a bug. With this narrowness in mind, the task is much less daunting. My goal now is not about code coverage, but more about quality code. With this test, I want to be able to demonstrate to myself (and to whoever is reviewing my changes), that I have successfully resolved my task.
In this blog I will talk about my suggestions for writing meaningful tests in the context of a code review.
In this post, Matthew Brown first discusses why we need unit tests. He then demonstrates writing unit tests for an existing reference Angular application with an eye for how to make good use of testing tools for Angular.