111–120 of 348 posts
Wait - people are doing real http calls in unit tests, over a network, and complaining about multiple asserts in the test code?
Wait - people are doing real http calls in unit tests, over a network, and complaining about multiple asserts in the test code?
tbh unit testing is a balancing act between reaping code quality benefits and bogging yourself down with too much testing updating.
> 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…
xUnit is terrible. It has a horrible culture, the author seems to have a god complex. It is overly complex and opinionated in the worst way possible. Many times I searched for 'how do I do something with xUnit' and found a github issue with people struggling with the same thing, and the author flat out refusing to incorporate the feature as it was against his principles. Other times I found that I needed to do was ov…
"We can't land this tiny fix because we have a release planned within three months" sort of thing.
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 the the rectangle after you have created it?
assert_equal(20, w, …
assert_equal(10, h, …
A dogmatic rule would just lead to an objectively worse test where you assert an expression containing both width and height in a single assert?
assert_true(w == 20 && h == 10,…)
So I can only assume the rule also prohibits any compound/Boolean expressions in the asserts then? Otherwise you can just combine any number of asserts into one (including mutating state within the expression itself to emulate multiple asserts with mutation between)!
What? People really would criticize that code because it has two assertions? How are they ever testing any state changes? And to the author: Your bubble is significantly different from mine. Pretty much every competent developer I've worked with would laugh at you for the idea that the second test case would not be perfectly fine. (But that first iteration would never pass code review either because it does nothing a…
There's a lot of not very competent people in the industry who cling tightly to dogma. Testing (especially unit) is an area of tech weirdly with a lot of dogmatism. I think Uncle Bob is the source of some of it.
Wait - people are doing real http calls in unit tests, over a network, and complaining about multiple asserts in the test code?
Hopefully the responses are stored locally and replayed on subsequent runs.
The one assertion per test doesn't mean you need to use only one assertion call but rather that you only need to do one assertion block. Checking everything after a response is considered 1 assertion, no matter how many assert calls you need. The issue is when you use multiple assertions for multiple logic statements: do > assert > do > assert... In that example imagine that you were also checking that the reservatio…
Sometimes, it takes a lot less code to test a particular code by doing it in a long test with multiple assertions. Migrate up -> assert ok -> rollback 1 -> assert ok -> rollback 2 -> assert ok I don’t see much benefit to breaking it up, and you’re testing state changes between each transition, so the entire test is useful and simpler, shorter, and clearer than the alternative.
Imagine an object which sees numbers, tries to pair up identical numbers, and reports the set of unpaired numbers. A good test would be:
Create object
Assert it has no unpaired numbers
Show it 1, 2, and 3
Assert it has 1, 2, and 3 as the unpaired numbers
Show it 1 and 3
Assert it has 2 as the unpaired number
This test directly illustrates how the state changes over time. You could split it into three tests, but then someone reading the tests would have to read all three and infer what is going on. I consider that strictly worse.
Things I find awkward with unit test (and it might just be me) is Inwant to write a test like def testLotsOfWaysTofail(): d = {"Handle Null": (None, foobar), "Don't allow under 13 to do it": (11, foobar), "or old age pensioner": (77,wobble)} for ... generate a unit test dynamically here I have built metaclasses, I have tried many different options. I am sure there is a near solution. But I never seem to have it right
isn't this just a parametrized test? or do you want to generate the test cases automatically like in property-based testing?