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

Re: [XP] Testing Leftover

Expand Messages
  • Nancy Van Schooenderwoert
    ... Your mention of the software logging technique reminded me of something I ve been thinking about lately - I used a group of testing techniques for embedded
    Message 1 of 48 , Jun 1, 2004
    • 0 Attachment
      On Tue, 2004-06-01 at 07:51, Douglas Philips wrote:
      > On Jun 1, 2004, at 2:33 AM, Lior Fridman wrote:
      > > BTW I did do it TDD. I had the test there before I started coding, and
      > > somehow the need to access private data structures seemed very natural
      > > to me. I still think it's the only sure way to check that a method
      > > performed its operation in the right way without depending on other
      > > methods from the class to work properly.
      >
      > Its a holiday, so I'm not colocated with my library, but I seem to
      > recall Kent Beck addresses this very issue in Test-Driven Design.
      > Probably also addressed in at least one of the XP books, though I can't
      > recall. Perhaps someone else can chime in, but my recollection without
      > having TDD to consult, is that he advocated creating a log (perhaps
      > just a string that you concatenate to), if you need to trace that the
      > right things are happening in the right order. I've used this technique
      > a lot. Sometimes I log just the function names, sometimes parameters
      > and results, though that often isn't necessary (i.e. I can transmute my
      > fear into boredom with just the function names being logged).
      >
      Your mention of the software logging technique reminded me of
      something I've been thinking about lately - I used a group of testing
      techniques for embedded software work I've done. "Test First" was just
      one of them (I hadn't heard of TDD then). The logging helped a lot,
      especially for visibility inside classes as you mention here. Another
      technique was "dual-targetting", i.e. keeping the code runnable on a
      desktop PC as well as on the target microprocessor.

      If I may be allowed a shameless plug;-) I'll be presenting a talk
      called "Taming the Embedded Tiger: Agile Test Techniques for Embedded
      Software" at the Agile Development Conference in Salt Lake City, June 22
      - 26, 2004. Details at
      http://www.agiledevelopmentconference.com/schedule/expreports.html

      Another technique that I found very useful was to build only one of
      the system's domains and be able to execute that on either platform,
      along with a tester class as a mock for the rest of the system.

      This multi-technique testing strategy was exactly what I needed for
      that situation (and I'd use it for most larger embedded software
      systems). I'm not sure if this approach is in line with what the TDD
      authorities recommend for non-embedded software, or if it's a departure.
      I do agree with the principle of not putting code into the production
      set if it's purely for test. I did end up doing some of that though. I'm
      not yet sure if it was necessary or if current TDD thinking has a better
      idea (I say not sure "yet" cause I'm working my way thru my TDD reading
      list:-)
      - Nancy V.

      -----------------------------------------------------------------------
      Nancy Van Schooenderwoert Agile Rules
      nancyv@... http://www.agilerules.com
      -----------------------------------------------------------------------
    • 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.