Code Smell 204 - Tests Depending on Dates

Code Smell 204 - Tests Depending on Dates

It is a good idea to assert something has happened in the future

TL;DR: Tests must be in full control and you can't manage time.


  • Fragile Tests

  • CI/CD Breaks


  1. Tests should be always in full environmental control.

  2. Create a time source


I read a Tweet about adding a fixed date to check for the removal of a feature flag (which is another code smell). The test will fail in an unpredictable way preventing releases and breaking CI/CD pipeline. There are also other bad examples we will never reach some date, tests running at midnight, different timezones, etc.

Sample Code


class DateTest {
    void testNoFeatureFlagsAfterFixedDate() {
        LocalDate fixedDate = LocalDate.of(2023, 4, 4);
        LocalDate currentDate =;        
        Assertions.assertTrue(currentDate.isBefore(fixedDate) || !featureFlag.isOn());


class DateTest {
    void testNoFeatureFlags() {   


[X] Semi-Automatic

We can check assertions based on time on our tests.


  • Testing


Proceed with caution with tests and dates.

They are often a cause of mistakes.


More Info


Code Smells are my opinion.

Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice.

Christopher Alexander

This article is part of the CodeSmell Series.