Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Multiple assertions are fine in a unit test

stackoverflow.blog

Post reply on HN
Print view View original

101–110 of 348 posts

Re: Multiple assertions are fine in a unit test

#101

Post by jjgreen »

danuker wrote: post #33
profunctor wrote: post #30

Earlier quoted context omitted.

If you’re using pytest you just paramaterize the tests and it tells you the exact failing case. Seems to be a basic feature I would be surprised to know doesn’t exist across almost all commonly used frameworks.

We are using unittest. But thanks for bringing it up, it seems it also has "subtest" support, which might be easier than interpolating the error message in some cases: https://docs.python.org/3/library/unittest.html#distinguishi...

You mean "subTest", I switched to pytest just to get away from the camel (and it's in the standard library!)

Re: Multiple assertions are fine in a unit test

#102

Post by indymike »

I've seen this pattern often with teams that are out of their normal wheelhouse (i.e. Python shop doing Go or JS shop doing Java) and think they cannot extend a bad test library. The other place you see this a lot is where developer hours are being billed. I can sympathize with devs who are shallow on a test library, but the billing hours one is a dark pattern for optimizing cost plus billing.

Re: Multiple assertions are fine in a unit test

#103

Post by torginus »

superjan wrote: post #93
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 this shared somewhere?

Nah, it was some corporate project. But if you are interested, I could rewrite it. It would be a fun weekend project.

Re: Multiple assertions are fine in a unit test

#104

Post by mannykannot »

dd82 wrote: post #54
mollerhoj wrote: post #28

Earlier quoted context omitted.

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…

one assert per test seems... as you said, indicative of zealotry. if you already have your object there, why not test for the changes you expect? So you have one test that indicates that a log error is outut. then another that tests that the property X in the return from the error is what you expect. then another test to determine that propery Y in return is what you expect? that to me is wasteful, unclear, bloated.…

Furthermore, if you have a one-assertion rule, some bright spark will realize he can write a single assertion that checks for the conjunction of all the individual postconditions.

That's one way to get dogma-driven assertion roulette, as you will not know which particular error occurred.

Re: Multiple assertions are fine in a unit test

#107

Post by mannykannot »

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…

The amount of setup and teardown necessary to test something is a property of the system under test. It is not susceptible to one's opinion as to how things should be.

Re: Multiple assertions are fine in a unit test

#108

Post by robertlagrant »

ramraj07 wrote: post #58
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…

So because some idiot somewhere wrote a 100 assertion unit test we should ban anyone from writing even 2 assertions in one test?

Devious commenter was describing a (normal) scenario where a unit test is not precise. No need to follow up with an aggressive "so what you're saying is".

Re: Multiple assertions are fine in a unit test

#109

Post by masklinn »

johtso wrote: post #100
danuker wrote: post #52

Earlier quoted context omitted.

In my experience, from doing some TDD Katas[0] and timing myself, I found coding slower and more difficult when focusing on multiple examples at once. I usually even comment out all the failing tests but the first one, after translating a bunch of specifications into tests, so I see the "green" when an example starts working. Maybe it would be easier to grok multiple regex examples than algorithmic ones, but at least…

Again pytest makes things so much nicer in this regard. Having to comment things out sucks. With pytest you can use the -x flag to stop after the first test failure. Even better you can use that in combination with -lf to only run the last failed test.

> With pytest you can use the -x flag to stop after the first test failure.

> Even better you can use that in combination with -lf to only run the last failed test.

Fwiw `--sw` is much better for that specific use-case.

`--lf` is more useful to run the entire test suite, then re-run just the failed tests (of the entire suite). IIRC it can have some odd interactions with `-x` or `--maxfail`, because the strange things happen to the cached "selected set".

Though it may also be because I use xdist a fair bit, and the interaction of xdist with early interruptions (x, maxfail, ...) seems less than perfect.

Re: Multiple assertions are fine in a unit test

#110

Post by batiste »

lodovic wrote: post #4

Wait - people are doing real http calls in unit tests, over a network, and complaining about multiple asserts in the test code?

I have met people that thinks HTTP calls are great!

- "But it tests more things!"

Well ok, but those are integration tests, not unit tests... It is unacceptable that a unit tests can fail because of external system...

Post reply on HN