71–80 of 348 posts
Actual status code: NotFound.
Expected: True
Actual: False> 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…
> 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…
Earlier quoted context omitted.
this has downsides if you're comparing attributes with a method result and checking whether said attrs match what you expect. Either you run each test N times for N attr comparisons, accepting the cost of setup/teardown, or do a loop and fire off an assert error with text on which comparison failed. Since you already have the object right there, why not do the latter approach?
If the setup/teardown is expensive I would do it in reusable fixtures. The reason I wouldn't choose the latter approach is that it would usually be less convenient in the long run. You'd need to replace your asserts with expects to avoid it throwing on the first error (if this isn't what you want), you'll often need to manually add data to the assertion (as GP did) that you would otherwise get for free, and you'll ne…
All the other points you make as negatives are all positives for me. Biggest thing is, if you're making this change that alters things so drastically, is that really a good approach.
Also, fixtures aren't magic. If you can't scope the fixture to module or session, that means by default it runs in function scope, which would be the same thing as having expensive setup/teardown. And untangling fixtures can be a bgger PITA than untangling unexpected circular imports
Earlier quoted context omitted.
Some languages allow a stack trace to be obtained in normal code, which enables position reporting without macros. Python and Go are good examples. If you know the file and line of the assertion, plus the values that are being checked, there's not as much need for a stringified version of the expression.
> If you know the file and line of the assertion, plus the values that are being checked, there's not as much need for a stringified version of the expression. It does save time. With the actual condition reproduced, half the time I don't even need to check the source of the failed test to know what went bad and where to fix it. Consider the difference between: FAILED: Expected 1, got 4 In /src/foo/ApiTest.cpp:123 vs…
FAILED: Expected RESPONSE_NO_DATA, got RESPONSE_INVALID_ARG
In /src/foo/ApiTest.cpp:123
FAILED: Expected ResponseCode(200), got ResponseCode(404)
In /src/foo/ApiTest.cpp:123
Both seem to be driven by misunderstanding through simplification of some otherwise meaningful ideas.
Earlier quoted context omitted.
> Is it weird that not only have I never heard of the "rule" this post argues against This "rule" is known mostly because it is featured in the "Clean Code" book by Robert C. Martin (Uncle Bob). You should have heard of it ;)
Where in that book is the rule stated? I ask because I have heard the author explicitly state that multiple assertions are fine (using essentially the same explanation as TrianguloY did in this comment: https://news.ycombinator.com/item?id=33480120 ).
Earlier quoted context omitted.
I've seen several test frameworks that don't abort a test case after the first failed assertion. When you get many tests each emitting multiple failures because one basic thing broke, the output gets hard to sort through. It's easier when the failures are all eager.
Which ones? I’ve used at least a dozen at this point, across C++, C#, JavaScript, Rust — and all of them throw (the equivalent of) exceptions on assertion failures.
They're used for code like this:
assert_eq(list.len(), 1)
expect_eq(list[0].username, "jdoe")
expect_eq(list[0].uid, 1000)
Earlier quoted context omitted.
Hm. I think my main issue there is not the speed, but rather seeing the whole picture at once. You mentioned you use this pattern to test regular expressions; say you modify the regexp in question with some new feature requirement, and now the very first of a dozen test inputs fails. You fix it, but then each one of the following keeps failing, and you can only find an elegant solution that works for all of them afte…
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…
Of course, ymmv depending on how good your initial intuition is, and how tricky the problem is.
Wait - people are doing real http calls in unit tests, over a network, and complaining about multiple asserts in the test code?
Earlier quoted context omitted.
Where in that book is the rule stated? I ask because I have heard the author explicitly state that multiple assertions are fine (using essentially the same explanation as TrianguloY did in this comment: https://news.ycombinator.com/item?id=33480120 ).
Chapter 9 talks about unit tests and there is a paragraph called 'Single Assert per Test', where he says it is a good concept but that he is not afraid to put more asserts in his tests. That paragraph is followed by 'Single Concept per Test' where he starts with: 'Perhaps a better rule is that we want to test a single concept per test.' So, technically he doesn't say it.
When I first wrote tests years ago, I would try to test everything in one test function. I think juniors have a tendency to do that in functions overall - it's par to see 30-100+ line functions that might be doing just a little too much on their own, and test functions are no different.