In the past, I’ve implemented couple of tests that aimed to verify naming conventions or some other practices team agreed upon. And presented a way how to ensure they are followed. When I’ve been writing those I was not aware that there is a library that aims to test architecture conventions - ArchUnit in this post I’ll write a simple test case to check what’s possible out of the box.
Recently I’ve found a very interesting project which allows to spin up docker containers for test purposes. Writing tests checking integration with external services is not an easy task. With testcontainers library it gets simpler because you can have external service up and running just for your test in a couple of lines of code.
Recently I had to set up some extra logic to be executed before running tests. I had two options - create yet another abstract class with some behavior or somehow extend Spock and introduce extra logic to be executed just before actual test starts. As we already have enough of abstract classes I decided to try and do the second option.
How to introduce automated checks that will guarantee that conventions are followed in an example of test naming convention. I’m going to focus on creating automated process that will verify if test names do match conventions. Automation will allow us to forget about the rule because the computer will ensure it’s followed. Test that I’m going to introduce will be living documentation inside the project and ensure no one will miss nor forget about the way we group tests.
Most of java web applications is built on top of the Spring Framework. Spring has pretty good support for testing and it is a mistake not to take advantage of features it offers. I’ve been developing various applications using Spring MVC for some time and I’ve noticed few patterns for testing that do work.
I do like to write tests in Spock. I’m not sure if I know every feature available but until lately I felt comfortable with my knowledge. Obviously, I should not. There is always something that can catch you off guard. The question is how long will it take to figure out what’s happen.
I’ve been using springboot for some time now, but there was that one thing that bugged me a lot. While writing integration tests with mocks you are forced to use mockito as the mocking library. That’s great and easy to understand if you are not using spock. The problem is that in spock there are better ways to mock stuff…
When the project gets bigger and bigger there should be more and more tests. In the perfect world, all tests should be executed really fast, but life is far from perfect and sometimes some tests are slow. When using Gradle + Spock combination we have few ways of deciding how to group tests. I’m going to explore junit @Category in combination with Spock and grade.