Multiple assertions are fine in a unit test • Hacker News Board

Re: Multiple assertions are fine in a unit test

#181

Post by bluGill » Sat, Nov 05, 2022, 2:36 PM UTC

RHSeeger wrote: post #153

Joeboy wrote: post #136

Earlier quoted context omitted.

I guess you might be talking about a different language / environment than I'm used to, but even in the 100 assertion test case you get useful tracebacks in python. Testing lots of things at the same time means strictly speaking you're writing an integration test rather than a unit test, but still I don't see how it's a bad test . It's easy and stops buggy PRs going into production. The test failures I see that are a…

> Testing lots of things at the same time means strictly speaking you're writing an integration test rather than a unit test There's nothing wrong with integration tests, but they're not unit tests. It's fine to have both, but the requirements for a good unit test and those for a good integration test diverge. The title of this post, at least, was specific to unit tests.

A unit tests tests one unit. And integration tests covers more than one unit. I think everyone agrees with that, but nobody has defined unit.

The longer I program the more I am convinced that the larger your unit the better. The unit tests is a statement that you will never refactor across this line, and that eliminates a lot of flexibility that I want.

It turns out that debugging failed integration tests is easy,the bug is in the last thing you changed. Sure the test covers hundreds of lines, but you only changed one.

Re: Multiple assertions are fine in a unit test

#182

Post by bazoom42 » Sat, Nov 05, 2022, 2:39 PM UTC

Unit tests are one of the many great ideas in our industry which have been undermined by people treating it is a set of rituals rather than a tool.

Re: Multiple assertions are fine in a unit test

#183

Post by bluGill » Sat, Nov 05, 2022, 2:40 PM UTC

mrits wrote: post #174

magic_hamster wrote: post #51

Earlier quoted context omitted.

> How is that even possible in the first place? The entire job of an assertion is to wave a flag saying "here! condition failed!". I envy you for never having seen tests atrocious enough where this is not only possible, but the common case. Depending on language, framework and obviously usage, assertions might not be as informative as providing the basic functionality of failing the test - and that's it. Now imagine…

22 assertions in a test is a lot better than 22 separate tests that fail for the same reason.

They are the same. I don't care, as I'll fix them one at a time, and if the fix happens to fix more than one great.

Re: Multiple assertions are fine in a unit test

#184

Post by jameshart » Sat, Nov 05, 2022, 2:40 PM UTC

The issue here appears to be imperative testing, with assertion failures as an early exit.

If all your assertions are always evaluated, you don’t have this issue?

Re: Multiple assertions are fine in a unit test

#185

Post by tobyhinloopen » Sat, Nov 05, 2022, 2:40 PM UTC

beezlewax wrote: post #171

torginus wrote: post #89

Earlier quoted context omitted.

I remember writing a small .NET test library for that exact problem - You could pass in a lambda with a complex condition, and it evaluated every piece of the expression separately and pretty printed what part of the condition failed. So essentially you could write Assert(()=>width>0 && x + width And you would get: Assertion failed: x is 1500 width is 600 screenWidth is 1920 It used Expression to do the magic. Amazin…

Is there something like this available for javascript?

Not really, no.

I like to use Jest’s toMatchObject to combine multiple assertions in a single assertion. If the assertion fails, the full object on both sides is shown in logs. You can easily debug tests that way.

The only way to make it even possible is to do some eval magic or to use a pre-processor like babel or a typescript compiler plugin.

But if you find something, Lemme know.

Re: Multiple assertions are fine in a unit test

#186

Post by kmac_ » Sat, Nov 05, 2022, 2:44 PM UTC

Multiple asserts are fine, multiple aspects in a single test are not. For example like a transaction test that checks if account balance is ok and if an user gets a notification. It boils down to a single responsibility, so when there are multiple aspects then it means that the class/interface should be refactored.

Re: Multiple assertions are fine in a unit test

#187

Post by scruple » Sat, Nov 05, 2022, 2:49 PM UTC

mollerhoj wrote: post #28

philliphaydon wrote: post #21

Earlier quoted context omitted.

That’s because the example test only requires 1 assertion. Any rule that says there should be only 1 assertion ever is stupid.

OP asked how any state change would be tested with a single 'assertion' and I provided an answer. Absolute rules are stupid, but our codebase has just short of 10k tests, and very few have more than one assertion. The only reason I can really see to have more than one assertion would be to avoid having to run the setup/teardown multiple times. However, its usually a desirable goal to write code that require little se…

Interesting. Our (Rails) codebase is around 25,000 tests and less than half have a single assertion. Personally, there's some calculus in my head when I'm writing a test that determines if/when the scenario I'm testing needs multiple assertions.

Re: Multiple assertions are fine in a unit test

#188

Post by jmount » Sat, Nov 05, 2022, 2:50 PM UTC

torginus wrote: post #89

TeMPOraL wrote: post #16

> The excellent book xUnit Test Patterns describes a test smell named Assertion Roulette. It describes situations where it may be difficult to determine exactly which assertion caused a test failure. How is that even possible in the first place? The entire job of an assertion is to wave a flag saying "here! condition failed!". In programming languages and test frameworks I worked with, this typically includes providi…

I remember writing a small .NET test library for that exact problem - You could pass in a lambda with a complex condition, and it evaluated every piece of the expression separately and pretty printed what part of the condition failed. So essentially you could write Assert(()=>width>0 && x + width And you would get: Assertion failed: x is 1500 width is 600 screenWidth is 1920 It used Expression to do the magic. Amazin…

Nice framework. Also once you allow more than one assertion, there is no need for top-level && in assertions (making them simpler tests).

Re: Multiple assertions are fine in a unit test

#189

Post by torginus » Sat, Nov 05, 2022, 2:53 PM UTC

jmount wrote: post #188

torginus wrote: post #89

Earlier quoted context omitted.

I remember writing a small .NET test library for that exact problem - You could pass in a lambda with a complex condition, and it evaluated every piece of the expression separately and pretty printed what part of the condition failed. So essentially you could write Assert(()=>width>0 && x + width And you would get: Assertion failed: x is 1500 width is 600 screenWidth is 1920 It used Expression to do the magic. Amazin…

Nice framework. Also once you allow more than one assertion, there is no need for top-level && in assertions (making them simpler tests).

While there is no strict need, sometimes assertions logically belong together.

Re: Multiple assertions are fine in a unit test

#190

Post by flavius29663 » Sat, Nov 05, 2022, 2:54 PM UTC

alkonaut wrote: post #116

An assert message says what went wrong, and on which code line. How on earth does it help to make just one? The arrange part might take seconds for a nontrivial test and that would need to be duplicated both in code and execution time to make two asserts. If you painstakingly craft a scenario where you create a rectangle of a specific expected size why wouldn’t it be acceptable to assert both the width and height of…

That can be considered one logical assertion though. You're asserting the size of the rectangle. You can even extract an assert helper function AssertRectangleSize(20,10)