• ray10k (unregistered)

    I'm just sitting here, waiting for the first guy to post that one XKCD comic due to the last line.

  • Senior Dev (unregistered) in reply to ray10k

    I was just sitting here waiting for someone to post "Fisrt!". You disappointed me!

  • DQ (unregistered)

    Now I understand why at CS class they told me to first write a test that fails...

  • 🤷 (unregistered)

    Gru meme!

    We write unit tests! / The tests should fail! / They pass / They pass

  • DQ (unregistered)

    It also reminds me of this little song

    99 little bugs in the code, 99 little bugs in the code
    Track one down, fix it, patch it all around
    102 little bugs in the code, 102 little bugs in the code

  • HdS (unregistered)

    In my opinion, the best testing framework for Python is PyTest. But even if Unittest is perfectly fine...so why?!?

  • ray10k (unregistered) in reply to Senior Dev

    I aim to (dis)please.

  • Bob (unregistered)

    And this is why you test your test framework, including writing negative tests!

  • James (unregistered) in reply to ray10k

    OK, fine: https://xkcd.com/1172/

  • Kashim (unregistered)

    “If ever you fear there are mice in your walls, listen to common wisdom and buy four fine cats. But listen to Zjing also, and release a single mouse among the cats every day—to make certain they have not forgotten how to hunt.” Credit http://thecodelesscode.com/case/182

  • I'm not a robot (unregistered)

    So did all the other test writers call .setFailed(True) for a pass and .setFailed(False) for a failure, or were they using it like a sane person would expect and the tests passed because they were actually broken and the test framework was treating them as successful?

  • (nodebb)

    This is one of the best WTFs I've ever seen come from a copy/paste - and it didn't even come from Stack Overflow!

  • fluppie (unregistered)

    What if the test does not break out of the test case after a fail?

    .setFailed()

    another test that succeeds

    .setPassed()

    And the passed variable is set back to True...

  • Some guy (unregistered)

    I come here daily for the .setFrist(True) memes. Today I am disappoint.

  • Mr Bits (unregistered)

    This is one of the best WTFs in a long time.

  • Eric Gregory (github)

    Ran into a similar issue recently, but with Python itself. I had some code that (basically) did this:

    m = Mock() m() m.assert_not_called()

    The test passed, which felt like a WTF at first. Stepping through it in a debugger the issue was pretty obvious -- the version of Mock we were using didn't have the assert_not_called() method, so it was a no-op. Needless to say, this wasn't the only test that used the non-existent assert method.

    tl;dr -- you don't have to bake your own unit test framework to wind up with misleading unit tests.

    Addendum 2018-04-17 12:27: (Well the formatting in my code is messed up, but you get the idea.)

  • siciac (unregistered)

    At a large corporation that shall remain nameless, there is a developer tools team that provides some recommended Ant config for building Java code.

    All this works just fine, and if you're using regular assertEquals and such methods, you're fine.

    We had a junior dev who thought, "those are ugly, I'll just use the assert statement." And he was entirely reasonable in his assumption that an assert statement should do what it plainly says.

    Of course, in keeping with the Java tradition of fundamental language features being horribly broken, by default the assert statement doesn't do anything. It's removed by the compiler.

    And the dev tools team didn't configure their test framework to set -enableassertions. Okay, fine, it's an oversight.

    We, of course, discovered his tests were passing spuriously the hard way.

    I emailed the dev tools team to alert them to the problem:

    "(Explain the problem...) Please enable -ea on testing frameworks." "You should use the assertEquals() method or raise an exception directly..." "Yes, I understand the thing I explained to you. The issue is that junior devs don't understand this, and this kind of breakage is silent and caused a high severity break in production." "We can't change that, it would break a lot of builds." "Teams trying to deploy to write tests to catch problems before they get to production, we want builds to break. Just roll it out slowly."

    At the mention of effort on their part, radio silence.

  • Sole Purpose of Visit (unregistered)

    I don't suppose it's worth pointing out that the Pythonic way of writing unit tests is to add them at the bottom of the module. You know, "if name == "main"."

    Maybe this is a Python framework, where such simplicity is derided.

    Or maybe, just maybe, this is yeat another case of TDWTF not actually understanding the language they are talking about.

  • Sole Purpose of Visit (unregistered) in reply to Mr Bits

    Apparently your bar is very low on the Kelvin scale.

  • (nodebb)

    Easily fixed:

    class TestStepOutcome(object):
  def setPassed(self, flag=True):
    self.result = flag

  def setFailed(self, flag=True):
    self.result = flag

  def reallySetFailed(self, flag=False):
    self.result = flag
  • (nodebb)

    Bullwinkle variant: reallySetFailedForSure()

  • Little Bobby Tables (unregistered)

    "My module is unit."

    "Huh! My module is unitter!"

    "You're both losers! My module is unittest!"

  • Ugh (unregistered) in reply to CoyneTheDup

    It hurts

Leave a comment on “Breaking Changes”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article