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.
The term “technical debt” was coined over a decade ago to help highlight a common problem in software development. Generally you can think of technical debt like this:
The cost of additional rework created by choosing an easy, shortcut solution now instead of the better approach that would take longer.
Delivering software to meet deadlines or functional goals that are wrought with technical debt is like buying items before you can afford them. Both practices can drastically affect your ability to reach your future goals, both long term and short term.
This article is a gentle reminder to recognize, fix, and avoid technical debt in your software projects.
Attention: This article was published over 9 years ago, and the information provided may be aged or outdated. While some topics are evergreen, technology moves fast, so 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 …
I have worked with several different organizations in my career on initiatives to rewrite legacy applications. A common theme for each project was that the organization struggled to deliver both maintainable and “agile” applications.
As developers, we’re curious by nature. I needed to understand exactly why this happens. In my contemplation of this common challenge, I discovered Automated Testing and became fascinated by it. I have since worked to include it as a central step as I write and maintain applications.
In this article particularly, I lay out how automated testing, or rather the lack there of, lies at the heart of many of the struggles we face as developers…