by misnome on 2/16/22, 12:03 PM
We work with a rather large upstream scientific codebase in python. They have an innate distrust of anything that isn't written by them.
Their testing system depends on tests printing "OK" after every test. This means that in many cases, tests failing are indicated by the _absence_ of "OK" being printed.
(We've attempted to isolate those parts and write our own stuff testing against upstream in pytest. We once presented a proposal to move them to pytest, offering to do any work and even wrote pytest plugins to seamlessly integrate with their current system. We got a - literal - "Thanks, but no thanks.")
by byteface on 2/16/22, 2:04 PM
by forgotusername6 on 2/16/22, 12:02 PM
I've had unit test suites in the past that failed to run the test if the test failed to compile. Those were the worst. I only found out because I roughly knew how many tests I expected to be run
by dc-programmer on 2/16/22, 2:05 PM
I’ve shipped unit tests that would fail but don’t run by copying the function signature of the previous test then forgetting to change the name of the new one. Only one of the tests will run (the first?).
Maybe unit tests need unit tests? (There’s probably a lint rule to catch what I describe above)
by njharman on 2/16/22, 4:31 PM
Huh? Seems super clear to me that "assertTrue" is asserting Truthyness and not equality. It's right there in the method name! And if you don't know "True" means Truthyness in Python, they you don't know the basics of Python.
A reviewer should catch this error easily. I kind of think many don't give much attention to unittests when reviewing. Which is bad. Good unittests are far harder to write than good code.
There's much more subtle errors of this class (False Negatives / always pass).
by krab on 2/16/22, 11:39 AM
Why Shroeder's test? Does it have anything to do with Gerhard Schroeder? I fail to see what. :-)
by generic-husky on 2/16/22, 3:08 PM
Nobody's going to talk about the cute fursona?
by dragonwriter on 2/16/22, 7:12 PM
Though it's unlikely to get made in the existing testing library because it's hugely breaking, the API would be better if the assertXxx methods’ optional message argument were keyword-only, and assertTrue (and assertFalse) were replaced with assertIsTrue and assertTruthy (and assertIsFalse and assertFalsey.)
by robertlagrant on 2/16/22, 11:58 AM
Good lord I forgot how ugly pre-pytest was.
by boxed on 2/16/22, 7:24 PM
This (and so much more) will be caught by mutation testing. For python that means mutmut.
by pc86 on 2/16/22, 2:51 PM
I'm no Python expert, but why does assertTrue() even accept two arguments?
by charcircuit on 2/16/22, 12:42 PM
Does unittest cause an exception when the second argument isn't a string? That would catch some of these I'd imagine.
by dingosity on 2/16/22, 5:03 PM
well. yeah. they were probably written for 2.x or 3.y and being run in 2.(x+n) or 3(y+n).
by dcdc123 on 2/16/22, 4:45 PM
Only 3 percent?