While implementing a new feature, I came across the flag parameter anti-pattern in two unrelated places. I would like to take this as an opportunity to take a closer look at this anti-pattern.
Lets assume we want to load all PDF documents via an API method. This could look like this:
public interface DocumentService { Document[] loadDocuments(); }
When you as a developer hear that you should write unit tests, it sounds like more effort at first. The code you have written works, as you have already seen by trying it.
However, the world around it is constantly changing. And how can you be sure that the code still works despite changes from the outside?
Let's assume that in our program there is a function to parse strings as dates.
/** * @param input a date with format "dd.MM.yy HH:mm" */ public static Date parseDate(String input) throws ParseException { return DateFormat.getInstance().parse(input); }
We use a class from the JDK here and even describe in the Javadoc which format the input parameter should have.
Once we have tried this, what else can go wrong?
Surely this will work forever.
Even after updating from Java 8 to Java 11, everyone would assume that the function still works as described, right? After all, we are only using a class from the JDK.
We as developers write many unit tests. The CI pipeline will run all tests with every build. We trust that, if the status is green, everything should be okay.
But what if the unit tests should have failed? I recently learned that Maven does not execute all tests by default.
Consider this simple class:
public class MyTests { @Test public void firstTest() { assertEquals(2, 1 + 1); } public static class NestedTests { @Test public void secondTest() { assertEquals(3, 1 + 1); } } }
We see that firstTest should succeed and secondTest should fail.