3 ms·
> One assert per test I read that as "one operation per test". Specifically, both: assertEqual(complex(1, 2) + complex(3, 5), complex(4, 7
by rhdunn 5y ago
> One assert per test
I read that as "one operation per test". Specifically, both:
assertEqual(complex(1, 2) + complex(3, 5),
complex(4, 7));
and:
auto c = complex(1, 2) + complex(3, 5);
assertEqual(c.re(), 4);
assertEqual(c.im(), 7);
would both satisfy that requirement, but:
assertEqual(complex(1, 2) + complex(3, 5),
complex(4, 7));
assertEqual(complex(1, 2) + complex(-3, -5),
complex(-2, -2));
would not. -- In that case, Clean Code is advocating having something like a "test adding positive complex numbers" and "test adding a positive complex number to a negative one". This makes it clear in the test failure report which of the operations and conditions has failed.
- foofye 5y agoAnd then you get a release mode warning about maybe unused c, unless you stick c in your code.
- SideburnsOfDoom 5y agoassertEqual(c.re(), 4); assertEqual(c.im(), 7); This is "logically" one assert, on two lines. So I would welcome it In cases like this I find myself extracting a helper assert method if it gets used 3 or more times. e.g. assertEqualComplex(c, 4, 7); which contains assertEqual(c.re(), x); assertEqual(c.im(), y); Which makes that a bit clearer. This is not the best example but you can get the idea. I might have 5-10 lines in an assertTransactionSuceeded(txn) method.
- pydry 5y ago>I read that as "one operation per test". This replaces a clear, well defined thing (assert) with a vague, ill defined thing. What constitutes an "operation"? There's almost no point to the rule if it isnt trivial to distinguish one operation from a group.
- ziml77 5y agoYour interpretation is a saner way to write tests, but I saw no indication that's what he meant. If it was what he meant, then he should have made it clearer. It's not like he couldn't have added an extra couple pages with an explanation and examples.