English is currently available.
Software Engineering DISCUSSION
I wrote a test for a function that parses the timestamp 2026-09-30T14:05:00Z and returns an object with year, month, day, hour and minute fields. The test checks all five fields. A reviewer rejected it, citing the rule that a unit test should contain exactly one assertion, and asked for five separate tests.
That gives five nearly identical tests with the same setup and the same call. Is the one-assertion rule meant to be taken literally, and what is the reasoning behind it?
The useful form of the rule is one behaviour per test, not one assert statement per test. Parsing a timestamp into its fields is a single behaviour with a single result; checking five properties of that result is still one logical assertion. Splitting it into five tests repeats the arrangement five times and makes the intent harder to see.
What the rule is aimed at is the test that calls the code, checks something, calls it again with other input, checks something else, and so on. When that fails you cannot tell from the name what broke, and everything after the first failure is never executed.
The real drawback of several plain asserts is that the first failure stops the test, so you learn that the year was wrong but not whether the month was too. There are two clean ways around that. One is to compare whole values: build the expected object and assert equality once, as in assert parse(text) == Timestamp(2026, 9, 30, 14, 5). A good test framework prints a field-by-field difference.
The other is grouped or soft assertions, which run every check and report all failures together: assertAll in JUnit 5, Assert.Multiple in NUnit, and similar features elsewhere.
Where you do want separate test cases is for separate inputs, and parameterised tests give you that without copying code. One test body, a table of inputs and expected results: a leap day, midnight, a timestamp with a +05:00 offset instead of Z, month 13, an empty string. Each row is reported as its own pass or fail. In pytest that is @pytest.mark.parametrize, in NUnit [TestCase], in xUnit [Theory] with [InlineData].
That gives the diagnostic benefit the reviewer is after, a precise failure report, where it actually helps.
Some checks you can apply instead of counting asserts. Can you name the test with one statement that has no and in it, such as parses UTC timestamp into fields? Is there exactly one call to the code under test, with setup before and checks after? If the test fails, does the message alone tell you what is wrong without opening a debugger?
If the answers are yes, the number of assert lines is irrelevant. If a test needs a second action after the first assertion, that second action is a second test.
Back to Software Engineering community
