Even though it’s been several years, I still remember being a Spring newbie very clearly.
(2003, me (far right blue sweater) in the computer lab where I wrote my first Java application).
I’d be working on some big fat legacy system which was more akin to archaeology than software engineering, digging through ancient layers of muck set down in years gone past, translating arcane symbols into some sort of meaningful narrative.
And then would come the worst part. Testing.
Back then I secretly hated testing. I loved writing “the code that actually does stuff” and was bored to my core by having to prove that in some isolated simulation of the real world it actually works.
I’d be lost, for hours, in this confused trance that “Spring Boot Magic” had got me in.
Several years later and I’m teaching younger developers how to write better code, and you know what? Nothing has changed. I still see the same confusion and bewilderment that I experienced.
Look familiar?
A mass of Spring annotations that somehow, through some dark magic, make the tests (that subclass this) work.
But that’s the thing. Spring isn’t magic. On internet platforms I frequently see people say things like Spring “does too much for you” and that there’s “too much magic”.
In reality, Spring has fantastic documentation (for the most part), hundreds of thousands of Stack Overflow posts and it’s open source. You can literally just read what it’s doing if there is no spoon-fed answer available within the top 4 posts of a Google search result.
That was also the case when I was younger and struggling but it didn’t help me all that much. For someone just starting out there’s a lot of information to take in. For me, too much. I had to learn by doing and the best thing was sitting next to someone who knew what they were doing and was thoughtful enough to explain it to me.
That’s why I decided to make a workshop about Spring Testing.
Confidently and proficiently testing a Spring application requires all the knowledge it took to build it plus a bit more.
To give you the highlights, at the time of writing this is more or less the curriculum:
- Unit testing
- Mock
- Spy
- Captor
- Integration testing
- Data JPA
- Mock Web MVC
- Spring Boot Test
- Spring Cloud Contract
It starts from a small-grained Unit test level where we test individual classes, builds up to integrate slices through handy things like Spring Data JPA tests, moves into customizing our Spring test context through traditional @SpringBootTest tests and then ends, with a somewhat niche testing concept, Consumer-Driven Contract testing.
It’s all the things I wish I knew when I was starting out plus anything that I find myself repeatedly teaching.
Last Friday, Sourcelabs had its monthly internal meetup and I was fortunate enough to be able to use my colleagues as guinea pigs and test my testing workshop.
All in all, it was a great success.
I got quite a few things right: the build-up from Unit to E2E test worked great, I was prepared to answer the difficult questions I knew my colleagues wouldn’t be able to resist asking me and the decision to remain completely practical and non-evangelical in my approach was also the right one.
I also messed up a bunch. I showed a lot of code, which was good. But what would have been way better is showing a lot of code and then having the participants to solve code challenges using the tools they’re learning about. I also realised that I could have spent a lot longer on the @SpringBootTest part and gone into detail on things like @MockBean, @TestConfiguration, @TestRestTemplate, etc. Knowing about these shortcomings was the whole point of the trial run after all. And in that sense, I’m very happy to have a direction to evolve this workshop into.
Having a bunch of experienced senior colleagues willing to spend a day “learning” stuff they already know, paying me hours of focussed attention and giving me constructive feedback is something I’m very grateful to have.
Watch this space. For more information on the workshop please contact me at
d.campbell@sourcelabs.nl