Real World TDD With Spring – Introduction

I’ve been working with teams who use Spring as the basis of their programming for some time now. Spring, many times as a microservices development and runtime framework. Luckily (or not) they want to incorporate TDD (Test driven development) into their development, but they bump into all kinds of problems.

I’ve talked about how architecture decisions usually have an impact on our unit testing strategy, and of course the process of implementation. With TDD things get even uglier, because of the underlying framework (which brings many other benefits) hamper the main benefits of TDD.

Here’s a couple of issues:

• The kick-off phase is slow. If you want to just sit down and start coding, you need to set up the whole framework first. That’s a one time (hopefully) hassle, but a hassle nonetheless.
• The tests seem different than “regular” TDD tests. They are more technical, because they operate an REST APIs, for example. It’s not “our” design, it’s Spring’s design.
• The time running the tests is long, from a few seconds to minutes just to run a single test.
• The time until we have passing test is long. You need to write code, inject it, configure it, connect to the database, and that’s just for a CRUD operation.
• Once the code is there, and we’ve added functionality, we tend to spread the logic in multiple places, because the architecture leads us there. Therefore, the “design” part of TDD loses it’s effectiveness.

And so we “just” add tests (some of them are valuable), but our tests don’t drive the design, they take long to write, then take long to run, and we don’t get the benefit from the ever increasing cycle of feedback.

It’s not that Spring (or any framework we choose in any language) is bad. However, if we let Spring’s architecture drive the design, it is an uphill battle. TDD – meet your kryptonite.

I’ve started thinking about this series trying to look up examples on TDD with Spring, and coming up with the code and coding patterns I mentioned. And while it maybe difficult, I think we can still do better.

So here’s what we’ll do. We’ll create an application, built on REST APIs, and we’ll do it in TDD. Although we’re starting out with a selected architecture, we’ll try to not let it hurt our TDD effort.

We’re going through all the stages of development from requirements analysis, through architecture design, the actual development of the functionality, testing, and refactoring. Spoiler: It’s going to be a while before we’ll actually see Spring in action.

Plus, as we go on, we’ll talk about how we tackle testing of the capabilities that we add, like persistency, supporting multiple users, security, etc. Some of the things will be easy, but a lot may seem foreign to the existing examples and documentation.

That’s ok. We want to get better.

Up next: The requirements.