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

Re: [XP] Testing Leftover

Expand Messages
  • yahoogroups@jhrothjr.com
    From: Gert Kello Sent: Monday, May 31, 2004 2:51 PM Subject: Re: [XP] Testing Leftover ... question ...
    Message 1 of 48 , May 31, 2004
    • 0 Attachment
      From: "Gert Kello" <Gert.Kello.at.mail.ee@...>
      Sent: Monday, May 31, 2004 2:51 PM
      Subject: Re: [XP] Testing Leftover


      > >
      > >>Actually, if we look at the class as black box, they do not even exist
      > >>:) And how do you test something that do not exist?
      > >
      > >
      > > This is an amusing notion but an odd one. I believe the original
      question
      > > was what to do about private methods. If no private methods exist, then
      > > whatever is to be done can be done trivially.
      > >
      > > If private methods do exist, but are in some sense meaningless, then we
      > > could delete them, converting the problem to one previously solved.
      >
      > Well, I did not say that "they do not exist". They do not exist for the
      > world outside of the class where they are declared. They only have
      > internal meaning, which may change (according to needs of more visible
      > methods) I feel that I do not need test them...
      >
      > I belive that when I need to test private parts of class, I'm starting
      > to test how the class is implemented. But I belive that I should not do
      > that. I should test whether the class provides the functionality it
      > promises to provide.

      I've seen this comment enough that I think it deserves an
      answer. I think it's wrong. It's based on an inappropriate
      model of testing.

      Design covers everything from the big picture overall structure
      of the application to the least little detail. If I'm going to restrict
      my tests to only the published external interface (that is, public
      and package visibility,) then there are aspects of the design that
      are not covered in the test.

      Sure, the lower level details can (and probably will) change,
      and this is what I think the people who originally promulgated
      that viewpoint were getting at: don't write expensive tests for
      ephemeria.

      That's a viewpoint that's foreign to XP, however. One of the
      goals of XP is to insure that all aspects of the program are
      malleable, not just the insides of the classes.

      Looked at another way, everything in the program that isn't
      an interface tested by the acceptance tests is, basically,
      implementation, so this view would say we shouldn't write
      unit tests at all.

      Reducto ad absurdum.

      John Roth
    • J. B. Rainsberger
      ... If A behaves correctly, and if testing B with a real A is painful, then consider mocking A when testing B. Simple. -- J. B. Rainsberger, Diaspar Software
      Message 48 of 48 , Jun 2, 2004
      • 0 Attachment
        Lior Fridman wrote:

        > But I want to test class B and not A
        >
        > I know that A behaves correctly (it has its own tests)
        >
        > So I don't think that replacing B with a mock class willl help me test
        > class B.

        If A behaves correctly, and if testing B with a real A is painful, then
        consider mocking A when testing B. Simple.
        --
        J. B. Rainsberger,
        Diaspar Software Services
        http://www.diasparsoftware.com :: +1 416 791-8603
        Let's write software that people understand
      Your message has been successfully submitted and would be delivered to recipients shortly.