Code Smell 204 - Tests Depending on Dates

Maxi ContieriMaxi Contieri
2 min read

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

Problems

  • Fragile Tests

  • CI/CD Breaks

Solutions

  1. Tests should be always in full environmental control.

  2. Create a time source

Context

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

Wrong

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

Right

class DateTest {
    @Test
    void testNoFeatureFlags() {   
        Assertions.assertFalse(featureFlag.isOn());
    }
}

Detection

[X] Semi-Automatic

We can check assertions based on time on our tests.

Tags

  • Testing

Conclusion

Proceed with caution with tests and dates.

They are often a cause of mistakes.

Relations

More Info

Disclaimer

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.

10
Subscribe to my newsletter

Read articles from Maxi Contieri directly inside your inbox. Subscribe to the newsletter, and don't miss out.

Written by

Maxi Contieri
Maxi Contieri

I’m a senior software engineer loving clean code, and declarative designs. S.O.L.I.D. and agile methodologies fan.