Testing has been a subject for developers for a while now, the agile Manifesto is more than 20 years old. Before that, we had eXtreme Programming (XP), and XP was the precursor for testing, meaning: having testable code as a practice, shifting left the need for writing the test first. This is not to say that, before, XP developers weren't testing applications - but writing test code became popular. Along those lines came different concerns, for example, any developer that follows TDD (Test Driven Development) or is familiar with that, follows the flow: write a failing test, make it pass with the simplest possible change, and then, refactor. Refactoring is a crucial step. Although practitioners have been practicing TDD for a few years, as there is no formal education, some questions come to mind: Should I use logic inside my tests? Should I use multiple assertions inside my tests? Here, we will focus on the assertions aspect of things as well as the logic inside the tests, using for loops for example. To For Loop or Not? If you think about that at first glance, having logic (of any kind  inside a test case) is something that looks like a smell. Diving a bit on the subject,  the mentions that tests should have no logic inside the test case. xUnit book For example, the classic logic is the if/else statement: if variable X is equal to true, I will assert that X is true, otherwise I will assert that Y is a string. With that, the test has two different reasons to fail. If you do that, you will have to spend some extra time understanding the logic behind the test and dedicate time to debugging which branch failed. In the end, if you have dynamic code in the test case, who will test the test? Therefore, we still have the question “Is it ok to use ?“ there.  Let’s start with some survey data, as it could provide insights into what approach practitioners follow. for loops in test cases The didn't get much attention but, from the ones that answered, it seems that developers don't care much about that (as interesting as it could sound, but in the comments, there are strong opinions). Twitter poll On the one hand, the results show just a minor difference. The "no", you should not use won the poll, but with a difference of 2.5% of the votes compared to “yes”. Not that much difference. for loops, On the other hand, If you take the GitHub repositories used in the , and navigate inside the source code, the probability of seeing a for loop inside the test case is not that high; at least, it wasn't for me. The pattern is the without for loops. TDD anti-patterns series AAA Last but Not Least, What About Multiple Assertions? There is a grey area in the comments on the tweet, but as far as the , there is no rule of having only one assertion per test case; the winner was “As many as I want“. poll data on Twitter goes Developers said that for the testing in place, if you are asserting multiple times the same behavior, why shouldn't you use multiple assertions? Elliotte Rusty Harold lists, as a best practice, to use one assertion per test method: https://youtu.be/fr1E9aVnBxw?t=938 All in all, assertions are a tricky subject to tackle, and it depends on the context in which the test was written, as such the takeaway from this section for me is the following: listen to your tests (Steve Freeman and Nat Pryce). Listening to the tests and the feedback it gives is an indicator of whether you are doing something good or not - good in the sense that it gives your ease of keeping the test running fast and gives the correct feedback when it fails.

The Never-Ending Debate: For Loops in Test Cases or Multiple Assertions

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

How to Retrofit Tests Into a ReactJS Codebases Without Tests

Agile Malaise

An Introduction to Agile Practices: Why Small Release in Scrum?

Extreme Programming: Values, Principles, and Practices

Persuasive Pair Programming

Iterations, not sprints

How to Retrofit Tests Into a ReactJS Codebases Without Tests

Agile Malaise

An Introduction to Agile Practices: Why Small Release in Scrum?

Extreme Programming: Values, Principles, and Practices

Persuasive Pair Programming

Iterations, not sprints

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps