Assert false, return true?

This is probably a pretty quick question. It’s about writing good tests again, and I would really appreciate input from experienced TDDers.

The Java w/ TDD for n00bs book I’m working through suggests writing a test to check a boolean. He instructs us to test like this: Assert.assertFalse(testobject.testCriteriaMethod()); Then he wants us to produce a red result by creating the testCriteriaMethod() and simply returning true.

I love failing tests. I don’t have any objection to making them, but my gut says they should mean something, and this one doesn’t.

I’ve been told that a compilation error counts as a failed test. I think I would have treated it that way, and made the next test pass instead of failing.

Is that a mistake? Is this what teachers mean when they tell me to start with a red test? If so, how does it help?

GeePaw sez…

There are two occasions on which I purposely would type that, compile, and run.

  1. When adding a test to my xUnit rig isn’t trivial. I constantly rotate around between xUnit rigs, so I do this a lot. The resulting red bar says nothing to me about the code aside from “yes, it’s connected”.
  2. When I’m stalling for time. I’m not stalling for time on *passing* the test, though. I’m stalling for time on whether it’s the test I want. Another example of TDD’s distributed design process. Sometimes that extra half-minute is just what I need.

(I have to tell you, the first case is far more embarrassing, because one has to explain about the time one added 17 new passing tests in just a half-hour, by the inadvertent expediency of not telling xUnit they were there.)

6 thoughts on “Assert false, return true?

  1. Angela Post author

    So, looking farther, I can see that it doesn’t really matter much, in this case. I mean, I can get rid of the return true pretty quickly.

    But I don’t want to be doing rote TDD because-somebody-told-me-to. I see real beauty in it, and I want to use it in a way that is vibrant and alive. That is, I want it’s strengths to shine through, and for that, I am really interested in knowing what tests accomplish that.

    I know that “shut up and practice” is one possible response; I really appreciate the patience of folks who are willing to answer my burning questions.

  2. Matt

    The general benefit in testing like that is a sanity check of your own. You called the method that you intended to call.

    The side benefit of it is that normally you start building some actual logic into the method. So it give you a way to test a default assumption.

    It is really a minor quibble to be honest and something a lot of people won’t ding you on in the least. The bigger thing it is really pushing on you is never writing any code without a test asking for it. For instance if you have a method that returns int and your test says that the number it returns will equal 3 then simply return 3 don’t add any further logic until it is necessary.

  3. Sean McMillan

    That shape (assertFalse(true)) will help you weed out the “green bar, zero tests executed” problem. Turning it from red to green validates that you have your tests set up correctly.

  4. Angela Post author

    Yep, I think I see it now. I think it was cheating to want to call the compile error (from attempting to call a non-existent method) the same thing as a red test.

    Now it looks to me like returning true would be a kind of overkill, setting me up for mistakes and a false sense of security.

    Thanks Matt & Sean for helping me get clearer on it.

  5. Angela Post author

    Thanks for the update, Mike. (See the “GeePaw sez” addition, above.)

    So I’m thinking that in real TDD (as opposed to exercises where we’re learning to begin to think test-first) we write meaningful code to pass our tests. Which makes me happy.

    Been thinking a lot about TDD (partly because @kaleidic and I have been talking about how to apply the juice of it to apply it to functional programming). It’s getting harder to write questions for this site, because I get new n00b questions and answer them about a zillion times a day lately. But the bigger, deeper questions last long enough to post. So next up, a doozy, perhaps, about TDD.

    Good thing I’m happy letting the purpose of this blog emerge, instead of needing to plan it all in advance. :)

  6. ask

    A fascinating discussion is worth comment. I think that you should publish more on this subject, it might not be a taboo matter but typically people don’t talk about these issues.
    To the next! Kind regards!!


Leave a Reply to Angela Cancel reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>