This is a follow up on a series of posts around TDD anti patterns. The first of this series covered: the liar, excessive setup, the giant and slow poke. These four anti patterns are part of 22 more, the anti patterns is a list formalised in James Carr post and also discussed in a stackoverflow thread.

In this blog post we will focus on four more of them: The Stranger, The operating system evangelist, Success against all odds and The free ride. Each one of them focuses on a specific aspect of code that makes testing harder, sometimes it comes from not doing TDD, sometimes it just comes from the lack of knowledge on designing code. Either way, this is an attempt to explore those flaws and avoid them in our own code base

(In the previous links you can see the videos of the sessions on demand. You just have to leave your email and you will be able to access the video of the session).

Takeaways

• Chaining different object calls in the test code can be a smell related to the law of demeter
• Tying up test code with the type of operating system brings portability issues
• Avoid sliding assertions that require a test case for itself
• Focus on having each test case with a single responsibility and not that many assertions

The stranger

In this blog post from java revisited the law of demeter explanation gives us a hint on why The strange is an anti-pattern, we can also relate to the clean code book "talk to friends, not to strangers". In their example, the method chain is the one that exposes more the stranger, the example, is being used in production code. Carlos Caballero in his blog post "Demeter’s Law: Don’t talk to strangers!" also uses production code to depict what is and when the demeter law is not followed, he gives a snippet that ideally would need to be tested, and here we are going to expand that and implement the test code.

To start with, here goes the code that depicts the violation in the production code:

Such code, could potentially lead to The strange in the test code, for example, to test if the person given has a valid zip code, we could potentially write something like the following:

Note that if we want to access the zip code, we need to go all the way down to the ZipCode object, potentially, this could show that what we want to test is the Address itself and not the person.

The test itself has something here that could be improved to avoid this almost one to one test class and production code, for example, the interaction between the person object, address and zip code could be "hidden" in an implementation and test the output of it, instead of going all the way down in the chain.

Before moving on to the next one, remember that The stranger could be also one of the anti-patterns that are related to test smells. There is some indication that you might be facing the stranger:

• It depends on context
• It is related to the xUnit pattern in the section "Test smells"
• It can also be related to mocks

The operating system evangelist

The operating system evangelist is related to how coupled the testing code is to the operating system, the way of coupling can be on different aspects of the code, for example, using a specific path that exists only on windows.

To depict such a case, the snippet that follows was extracted from the open source project Lutris. Lutris, aims to run games that are for windows, on linux, the premise of the project already gives some constraints that are expected in the code base. The result, is the following test case, that launches a linux process:

Another anti-pattern that is related to the Operating System Evangelist is The Local Hero. The Local Hero is known for having everything in place locally to run an application, but as soon as you try to run it on another machine, it will fail.

FLASH BACK - In the episode 2, besides the local hero we discussed the anti patterns the mockery, the inspector and the generous leftovers, the examples used are in javascript, kotlin and php

We already had a discussion about the local hero in the episode 2 of this series, but to reinforce on how they are connected, here goes an example from Jenkins source code:

This snippet is particularly interesting, because whoever wrote it, already noticed that there was some smell going on with the comment: TODO instead remove it from the process env?

Last but not least, katas are usually the ones to catch those kinds of patterns early on, and push for an abstraction during the refactor phase. The WordWrap is an example of kata that aims to break into new lines if the content is greater than the expected. For an explanation on the differences in feed lines and operating systems, check Baeldung.com post.

Success against all odds

Throughout this series, we have seen different anti-patterns that arise from the lack of practising the test first approach, such behaviour leads to different things that makes testing difficult, for example, the excessive setup and the giant, that are related to the god object.

Here, once again we will go over an anti-pattern that is related to the lack of a test first approach, but instead, the developer follows the test first and instead of failing first, it just makes the test pass from the start. When this is the case, the Success against all odds is revealed. As the practice of starting from the test passing from the start leads to the test passing even when the failure is expected.

In order to depict such a scenario, the following snippet is an attempt to implement a repository from SpringBoot which will paginate and query based on a given string.

Once we have a look at the given code that actually performs the access to the database and apply the criteria, the following test code is the one used to test the repository.

Note that since the beginning we are doing some heavy lift operations here to populate the database with different data. Which could be potentially a smell

Note: For the sake of the example, the teardown has been removed in order to keep it simple. The tear down removes all the data inserted in the database used during the test.

With the setup in place, let’s have a look at the first test case in this class. The test case goal is to test that given a sort parameter, the parameter CREATED_AT_ASC (comment number 1) is the one we are looking for, once this has been given, the data should be ordered accordingly.

Let’s dive a bit on what is going on in the code guided by the comments in there:

• The parameter that we send to the repository with the order we want and pagination
• The execution of the code we want to test
• We verify that the page returned from the repository is the first one
• We verify that there are 4 pages in total
• We verify that there are 112 in total
• We verify that the list of items returned is the same as the one asked in the pagination
• We verify that the list returned is in the same as in the list created in the before all setup

The next text case depicts a variant on what we might want to test, which is the reverse order. Instead of ascendent we now will test descendent. Note that the majority of the asserts are the same as the previous test case.

Let’s avoid repeating the previous bullet list and focus on the items that are important.

The first item that is important, is the number of assertions we might not need for each test case, for example from the item 3 through 6, there are assertions that verifies the pagination and the numbers related to the list, reading the test name, our goal is to test the sorting first and not the pagination. In other words, we could have used just the last assertion.

Talking about item 7, let’s dive into it a bit more, because having such an assertion is one of the possible reasons to face success against all odds, and actually in the test code it is one of them, as it asserts on a subset of the list that will always be true.

In the xunit patterns book, a way to avoid such false/positive behaviour the way to go is to have the code as simple as possible, no logic in it, this is called robust test [1].

Refactoring success against all odds

The question here is, what could we do then to avoid such a thing? The proposed alternative for this test case and source code are related to splitting responsibilities in the test case, we could focus on sorting and later on in the pagination.

The first example here would be ordering the list in ascending order, it is worth mentioning that with this approach, we could potentially remove the big setup that was shown previously in the hook setupBeforeAll. For this approach, we instead, set up the data that is required for the test inside it.

Once that is in place, we then move to the descending order test case, which is the same, but the assertion and setup changed:

Next up, is the pagination, now we can start to focus on the pagination and the aspects it brings.

Once we have the sorting in place, we can start to have a look at the pagination, and of course, try to test a specific thing at time. The following example depicts how we could assert that we got the desired number of pages when paging the result.

The approach to decompose the tests in smaller “units” would help the communication between the team members that will be dealing with this code later on as well, and also the already mentioned robust tests.

The free ride

The free ride is one of the least popular anti-patterns that was found in the survey, maybe this is because the name is not that welcoming when the matter is to recall the meaning.

The free ride appears in test cases that usually require a new test case to test the desired behaviour, but instead, another assertion is put in place and sometimes even logic inside the test case is used for that end.

Let’s have a look at the following example that was extracted from the puppeteer project:

As already spoiled, the free ride is right on the if/else statement. There are two test cases in this single test, but probably, the idea was to reuse the same setup code and slide in an assertion in the same test case.

Another approach would be to split the test case in order to focus on a single scenario at time. Puppeteer itself already mitigated this issue using a function to handle such scenario, using that to split the test cases, we would have the first test case focuses on the chrome browser:

And then, the second case for firefox.

Logic inside the test case is already an indication that the free ride is playing a role. The puppeteer example can be improved even further. Now that we split the logic into two test cases, there is more duplicated code (that could be an argument in favour of adopting the free ride). If that is the case, the testing framework can help us here.

To avoid code duplication in this scenario, we could use the hook beforeEach and move the required setup there.

Moving a bit from puppeteer, there are other ways in which the free ride can appears, the following code from the jenkins project:

Another approach to avoid the free ride in this case, would be once again to split the test cases:

As always we hope you enjoyed this new episode and we look forward to seeing you in our last session in which we will talk about two more anti-patterns: The Jumper and The Flash.

Stay tuned and enjoy testing!