Loading ...
Sorry, an error occurred while loading the content.

Re: [junit] assertTrue(true)

Expand Messages
  • John Smith
    Even in the JUnit FAQ they use assertTrue(true). http://junit.sourceforge.net/doc/faq/faq.htm#tests_9 The editors of this FAQ should not write such an example.
    Message 1 of 52 , Jun 1, 2005
    • 0 Attachment
      Even in the JUnit FAQ they use assertTrue(true).

      http://junit.sourceforge.net/doc/faq/faq.htm#tests_9

      The editors of this FAQ should not write such an example.

      If Beck and Gamma would recommend using assertTrue(true), they would have added a method like pass() or succeed() to TestCase.

      __________________________________________________
      Do You Yahoo!?
      Tired of spam? Yahoo! Mail has the best spam protection around
      http://mail.yahoo.com

      [Non-text portions of this message have been removed]
    • J. B. Rainsberger
      ... This is veering off topic, but I don t mind, because at least it s good conversation. As a user, I don t like this UI design. Specifically, when I make a
      Message 52 of 52 , Jun 3, 2005
      • 0 Attachment
        Erik Husby wrote:
        >
        > Elliotte Harold wrote:
        >
        > > Kevin Lawrence wrote:
        > >
        > >> "Social security number should match the pattern 999-99-9999.
        > >> AB-1234-XY
        > >> is not a valid social security number."
        > >>
        > >
        > > You're still thinking like a programmer. "Match the pattern
        > > 999-99-9999". What's that? "Match the pattern" is programmer speak.
        >
        > Ah, but both of you are missing the real point. The user should not
        > have been able to input an invalid social security number. The only
        > case where this could happen is when the user is inputting data from
        > a text file. In a properly designed GUI, the user should have been
        > presented with 3 fields that only accept numeric digits. The first
        > field accepts 3 digits, the 2nd 2 digits, and the last field 4
        > digits. And focus should have been move automatically between the
        > fields.

        This is veering off topic, but I don't mind, because at least it's good
        conversation.

        As a user, I don't like this UI design. Specifically, when I make a
        keying error, I usually have to use Shift+Tab to go back to input field
        #1 and correct the data there. Perhaps Novice users (think Dreyfus
        Model) benefit from such a constrained UI, but it works against me. The
        one I'm especially annoyed with is drop-down lists for month/year
        (credit card expiry date) or worse, month/day/year. I much prefer a text
        field and a calendar widget. (Why isn't there are month/year widget?!)

        So while this UI design can avoid certain input errors, I don't like to
        use it. Which is worse: bad UI or bad error messages? I'm not sure.

        <snip />

        > Since unit tests are for programmers, they should catch expected
        > exceptions and let all others through to be displayed by the Unit
        > Test runner.

        This guideline has certainly served me well.
        --
        J. B. (Joe) Rainsberger
        Diaspar Software Services
        http://www.diasparsoftware.com
        Author, JUnit Recipes: Practical Methods for Programmer Testing
      Your message has been successfully submitted and would be delivered to recipients shortly.