I have been practising Test-Driven Development for more than 25 years. The red-green-refactor cycle is second nature.
I have of course heard a lot about AI tools and LLMs over the last couple of years. The times I have tried them, I have not been impressed. Their proposals didn't compile. They seemed to solve the wrong problem. This was probably because they lacked the context of the project I'm working on. Honestly, a lot of what I have seen has been rubbish.
Not too long ago I saw a thread on LinkedIn where some people who I know really know what they are doing discussed their experience with AI assistants and specifically Claude Code. I decided to give it a try.
]]>AssertJ is a great assertion framework for Java. It is in my opinion much better than any of the available alternatives. Two areas where AssertJ shines are verifying collections and verifying exceptions. It is also extendable, so you can implement custom assertions for your domain objects.
The way to assert something is done using the method assertThat(). A typical example looks like this:
assertThat(actual).isEqualTo(expected);
isEqualTo() is overloaded and can be used for a lot of comparisons.
It happens that you are working on something and realize that you have to change context. Something urgent popped up and you need to get it into production as soon as possible. However, you have uncommitted changes that doesn't work properly. What do you do now? You can't commit your current changes. They are not done and should not end up in production. And you are smart so you avoid branching. Your current changes are on master and should be on master.
]]>Some time ago I attended a meeting where a developer told us that
The development is done. Wrote som unit tests yesterday. They are not done. I delegated writing them to a colleague.
A statement like that makes me very sad. It also upsets me.
]]>The execution flag must be set on a file for it to be possible to be executed as a script on a Linux system.
]]>Configuring Jenkins is not as easy as one might imagine or want. There are some 1500 plugins available. Selecting the proper plugins and then configuring them is a daunting task.
Jenkins configuration as code doesn't solve the selection problem. But it does solve the problem of having a repeatable setup of Jenkins. The setup is version controlled and thus traceable.
Here is an example where I use this this tool chain:
A working example is available at GitHub.
]]>I have a situation where I want two jobs in Jenkins to have the same definition. They will run a set of tests against two different environments.
I want to name the jobs so it is obvious which environment they target. My naming schema looks like this:
*-dev
The jobs will therefore be named as:
integration-tests-devintegration-tests-sysI had a conversation with a developer this spring about Test-Driven Development, TDD. We both agreed that it is a good habit.
I asked why he doesn't do more TDD than he does. He is not using TDD as his default mode when writing code. His answer fascinated me.
I don't know if it should be a rest api or something else.
If that is the conditions you work under, I can absolutely understand if TDD is the least of your problem. I can definitely understand if you don't use TDD in that context.
There are few problems here that will make it really hard to do TDD
]]>It is easy to agree that baby steps are good when doing something complicated. They allow you to move slowly but steadily. That is why baby steps are recommended when doing software development.
If we agree that baby steps are good, the next question is "How large is a baby step?"
This is where it gets interesting and this is where I see different interpretations.
]]>Defining what Behaviour-Driven Development, BDD, is not easy. It is sometimes described as a bounded context of ideas.
What is rather clear to me is that there are a two properties everyone seems to be able to agree upon.
These are:
In order to get full benefit from these, I want to add
to the list.
]]>