Database Integration Tests with Docker Sidecar in Jenkins

More often than not, developers want to test the source code against a real database instead of Fakes or Test Doubles during a CI job in order to verify the code works as expected. Therefore a clean database is needed for every CI-job. One solution is to use a shared instance of the database in your existing test-environment which get cleaned before and after a job. But this suffers from being “shared” and you never can run multiple CI-jobs in parallel without jobs interfering with each other....

May 9, 2021 · 2 min · Daniel Gerlach

Writing better Code

In Joel Spolsky’s blog post “The Joel Test: 12 Steps to better Code”, he describes a test composed of twelve simple yes-no questions. For a yes you get one point. 10 points are acceptable and 12 are perfect. If you have less than 10 points, you will get in trouble with your software – sooner or later. For a quick self-check, these are the original questions: Do you use source control?...

August 16, 2020 · 15 min · Daniel Gerlach

Google Testing Toilet Collection

In my one of my previous posts i wrote about Good Unit Tests. During my research i discovered the famous Google Testing on the Toilet posts which provide great advice. The Testing-on-the-Toilet articles are short (~3min reads) and give hands-on examples, ready to be applied immediately. Here are my favorites: Testing on the Toilet Tests Too DRY? Make Them DAMP! Exercise Service Call Contracts in Tests...

May 23, 2020 · 2 min · Daniel Gerlach

Programming Quotes

Over the years i collected some (funny) programming quotes. Lean back and enjoy: Everyone knows that debugging is twice as hard as writing a program in the first place. So if you’re as clever as you can be when you write it, how will you ever debug it? Brian W. Kernighan Don’t comment bad code—rewrite it. Brian W. Kernighan The most effective debugging tool is still careful thought, coupled with judiciously placed print statements....

May 17, 2020 · 7 min · Daniel Gerlach

Why and How to write better Unit Tests

TL;DR Good unit tests build the foundation of a maintainable and high-quality codebase Unit Tests should help developers to be productive Unit Tests should be fast Unit Tests should be isolated Unit Tests should be deterministic Unit Tests should focus on a single unit Unit Tests should be enduring Unit Tests should be clear, concise and complete Avoid complex control flow logic like nested ifs or loops Unit Tests should follow a consistent naming pattern like UnitName_StateUnderTest_ExpectedBehavior Unit Tests should comply to a consistent structure Unit Tests should be DAMP not DRY Unit Tests should give developers confidence to deploy and to refactor Test Doubles help to make tests fast and deterministic The overuse of Mocking makes test hard to read and brittle Prefer state verification over interaction verification Prevent brittle tests Prevent flaky tests Read more: Software Engineering at Google Kent Becks’s Programmer Test Principles Microsoft’s Best Practices for Unit testing All Your Tests are Terrible TDD, Where Did It All Go Wrong (Ian Cooper) Why good unit tests are important TDD and test engineering culture is considered best practice these days....

May 4, 2020 · 20 min · Daniel Gerlach

ESlint + Prettier + Typescript = Consistency

Consistency is one of the most important factors in a codebase. It gives new developers an orientation and direction how to write new code. It keeps the code understandable, clear and free from bikeshedding, so developers can focus on real problems instead of indulging in discussions on their preferred codestyle and individual taste. Consistency can be pertained by strict discipline but if possible you should enforce good style and formatting via opinionated code formatters like Prettier which makes development and collaboration a breeze....

March 24, 2020 · 7 min · Daniel Gerlach

Things to consider with microservices

Introduction Some years ago i was involved in migrating a big IBM Websphere monolith into a microservice landscape. We had a lot of problems with the monolith. Our development speed slowed down. We had many merge conflicts because of too many dependencies in the codebase. We outgrew the monolithic design and decided to introduce microservices. We extracted different domains like payment, booking, user and search. The teams were restructured into two-pizza teams....

March 30, 2019 · 7 min · Daniel Gerlach