4 ms·

> On the other hand, I've seen plenty of assertion based tests in other languages that report inane things like "1 != 2" or "true != false" when they fail. In

> On the other hand, I've seen plenty of assertion based tests in other languages that report inane things like "1 != 2" or "true != false" when they fail. In Python, one would need to supply the message argument to avoid that. But Go seems no different, really; you still have to supply the message. My understanding of the testing package is that Python's: self.assertEqual(expect, actual, f'expected ({expect!r} != actual ({actual!r})') is approximately: if expect != actual { test.Errorf("expected (%s) != actual (%s)", expect, actual) } I'm honestly not sure which is "better". I do wish Python could figure out something better than "1 != 2", s.t. the assert would just do The Right Thing™ in a graceful way, but doing so would require facilities the language hasn't got (e.g., some macro capability). There are some packages that do some black magic stack walking to do slightly better, IIRC. To me, Go's error handling falls a bit short because it is possible to forget to handle an error (though thankfully that unused variables is an error makes this more difficult), and you don't get an error or a result, you always get an error and result. (The language lacks a sum type, so it can't really do much better here.) It's on the programmer to not use the result, and to me that felt and still feels weird. The constant do-something, check, propagate is thing, too … I had hoped C had beat that out of language design as too tedious, frankly. (C.f. Rust, where even though error propagation is always explicit, it was `try!(foo)` early on, and `foo?` more recently.)

it 9y ago
I think the if-statement one is clearer, but in terms of results they're both fine. At the same time, I usually don't see people put in the extra work to add these helpful messages to their assertions. Maybe one reason is because they make the code a little harder to read.
Erwin 9y ago
py.test does the magic walking, and it does indeed make for much less verbose tests -- no need to remember which self.assertSomething method to call either: x = 1 y = 2 items = [4,5,6] assert (x+y) in items Outputs this, replacing the variable names with values test.py:4: in <module> assert (x+y) in items E assert (1 + 2) in [4, 5, 6]
- techdragon 9y ago
  If you aren't using pytest, you don't know what your missing. It cleans up so much of the testing boilerplate for python.
  - bpicolo 9y ago
    Though the magical global dependency injection is still somewhat obtuse, and not overly new-team-member friendly

it 9y ago

I think the if-statement one is clearer, but in terms of results they're both fine. At the same time, I usually don't see people put in the extra work to add these helpful messages to their assertions. Maybe one reason is because they make the code a little harder to read.

Erwin 9y ago

py.test does the magic walking, and it does indeed make for much less verbose tests -- no need to remember which self.assertSomething method to call either: x = 1 y = 2 items = [4,5,6] assert (x+y) in items Outputs this, replacing the variable names with values test.py:4: in <module> assert (x+y) in items E assert (1 + 2) in [4, 5, 6]

techdragon 9y ago
If you aren't using pytest, you don't know what your missing. It cleans up so much of the testing boilerplate for python.
- bpicolo 9y ago
  Though the magical global dependency injection is still somewhat obtuse, and not overly new-team-member friendly