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

92787Re: Re[2]: Why preserve TDD tests anyway (was RE: [XP] Testing Leftover)

Expand Messages
  • Keith Ray
    Jun 2 8:30 AM
      Look, B is just a "container" with extra functionality. Containers have
      putters and getters. It makes sense for B to have a public "isThere"
      function.

      On Jun 1, 2004, at 11:35 PM, Lior Fridman wrote:

      >
      > since I see a lot of confusion here I think id better explain again
      > (and better) the example I gave
      >
      > In short we have 2 classes: A,B
      > B is the class I want to check. One of its interfaces is a register
      > function (which is used by A to register himself to B)
      > The registering mechanism (to keep the example simple) add the object
      > which is passed to him (of type B) into his private data structure (in
      > our case a list).
      >
      > The test I want to compose goes like this:
      > 1) B.Register(*A)
      > 2) check if A is in B.list.
      >
      > Problem I don't have a B.isThere(A) function or a B.getList(). since I
      > don't really need it (other than for the testing part)
      >
      > So replacing B wouldn't help too much since I want to check B.
      > I can create a mock A but than again it wont help me too much since I
      > would still need access to private members of B and were back at square
      > 1.
      >
      > Hope this makes things clearer
      >
      > Lior
      >
      > -----Original Message-----
      > From: Michael Feathers [mailto:mfeathers@...]
      >
      > Sent: Tuesday, June 01, 2004 2:42 PM
      > To: Lior Fridman
      > Subject: Re[2]: Why preserve TDD tests anyway (was RE: [XP] Testing
      > Leftover)
      >
      > Hello Lior,
      >
      > Tuesday, June 1, 2004, 3:03:58 AM, you wrote:
      >
      >
      > LF> I want to focus on the point several people have made about the
      >
      > LF> ability to test all the classes by using only public interfaces.
      >
      > LF> I agree!
      >
      > LF> If the behavior of all the interfaces is correct than I do not care
      >
      > LF> what the class does inside.
      > LF> However if I go back to my case it all started out as you said I
      >
      > LF> wrote down the tests I thought needed to test the class behavior
      >
      > LF> (via using the interfaces only) And than I started coding. At some
      >
      > LF> point ive got all the tests working and I said "ok now lets make
      > the
      >
      > LF> code cleaner" I don't want to use the refacturing term cause I
      >
      > LF> don't really think I truly used any refacturing mechanisms, but the
      >
      > LF> intention was the same.
      >
      > LF> So after doing this for a while ive got to the point when one of my
      >
      > LF> tests broke The reason was that I made a stupid mistake in changing
      >
      > LF> the registration method a mistake that was only caught later on by
      > a
      >
      > LF> test to the monitoring part.
      >
      > LF> Now it took me a while to find this out so I wanted to make sure
      >
      > LF> that this wont happen again And here is were this thread came into
      >
      > LF> being. I didn't have a way to check it.
      >
      > LF> So ive added a function that searched the list of the registered
      >
      > LF> components to check if after I register a component it is there.
      > LF> Now I needed to place this function. So ok it's a basic
      >
      > LF> getter/finder function lets add it to the class.
      > LF> But wait no one outside the testing actually need it so I don't
      > want
      >
      > LF> to add a chunk of unused code into the class so lets put it in the
      >
      > LF> test class and make the test class a friend, It actually stayed
      > this
      >
      > LF> way for a couple of weeks until I wanted to publicate the whole
      >
      > LF> thing and I noticed I just did something very bad. Left testing
      > code
      >
      > LF> in the operational code.
      > LF> And this is the story of this thread.
      >
      > Lior, I know this has been mentioned before but I didn't see you
      > respond. If you have a class A which registers components with B why
      > not have a mock B which allows you to search and use it under test?
      > That way, you don't have this finder in your production code and you
      > are
      > able to see A's impact on B.
      >
      > Michael Feathers
      > www.objectmentor.com
      >
      >
      >
      > To Post a message, send it to: extremeprogramming@...
      >
      > To Unsubscribe, send a blank message to:
      > extremeprogramming-unsubscribe@...
      >
      > ad-free courtesy of objectmentor.com
      > Yahoo! Groups Links
      >
      >
      >
      >
      >
      >
      >
      >
      >
      > The information contained in this message is proprietary of Amdocs,
      > protected from disclosure, and may be privileged.
      > The information is intended to be conveyed only to the designated
      > recipient(s)
      > of the message. If the reader of this message is not the intended
      > recipient,
      > you are hereby notified that any dissemination, use, distribution or
      > copying of
      >
      > this communication is strictly prohibited and may be unlawful.
      >
      > If you have received this communication in error, please notify us
      > immediately
      > by replying to the message and deleting it from your computer.
      > Thank you.
      >
      >
      > To Post a message, send it to: extremeprogramming@...
      >
      > To Unsubscribe, send a blank message to:
      > extremeprogramming-unsubscribe@...
      >
      > ad-free courtesy of objectmentor.com
      > Yahoo! Groups Links
      >
      >
      >
      >
      >
      >
      --
      C. Keith Ray
      <http://homepage.mac.com/keithray/blog/index.html>
      <http://homepage.mac.com/keithray/xpminifaq.html>
      <http://homepage.mac.com/keithray/resume2.html>
    • Show all 12 messages in this topic