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

Re: [TDD] Re: Where to put test code

Expand Messages
  • Brian Button
    ... Edwin, I m still pretty sure I m writing my code test first. I don t have a design on paper for what I m writing, I m writing tests before I write code,
    Message 1 of 33 , Oct 1, 2004
    View Source
    • 0 Attachment
      Edwin Gabriel Castro wrote:
      > All good points.
      >
      > How did you determine you needed a facade? How did you determine the
      > interfaces to the "work-horse" classes? It sounds to me like you have
      > already designed the system. At this point I don't feel like you are doing
      > TDD anymore. You are testing. Put your tests where they make sense.

      Edwin,

      I'm still pretty sure I'm writing my code test first. I don't have a
      design on paper for what I'm writing, I'm writing tests before I write
      code, and I'm eliminating duplication after each test. If I'm missing
      something, please let me know.

      What I am doing, however, is conforming to the requirements that I have.
      We're building a library, so the interface is pretty important. The
      domain experts have told us how clients will use our library, based on
      client feedback and their own experiences, but we are completely free to
      implement anything we want under the covers. We just have to do our best
      to make the given interface work.

      Does that mean that I can't do TDD? Certainly not. It just means that my
      interface to the world is fixed. On larger teams this happens all the
      time, and in one sense, I'm writing software for a team that numbers in
      the tens of thousands (think world's largest software company).

      >
      > If I was TDD a system I would begin TDD the classes as public since my tests
      > need access to them and my tests reflect "user" usage. At a later point I
      > decide the system has become to difficult to use and decide to use a facade
      > to simplify it I would begin at that point by adding another public
      > interface (the facade), writing the tests first reflecting the new "user"
      > usage. If prior to release you need to restrict the end user from accessing
      > the "work-horse" classes then you make them internal (in a .NET environment)
      > and at that point decide how to update your tests so that you can still use
      > them during maintanance. In TDD (and in agile methods in general) you want
      > to make decsions as late as possible. If you are running into problems about
      > where tests should be at an early stage of the game then you are making too
      > many descisions.

      I understand and appreciate how you would do this. I, in fact, have
      developed code like this many times. But part of gaining mastery over
      any of the agile practices is that you're allowed to start modifying it
      to suit your own purposes better. I'm working on a team with two other
      TDD masters, and we're led by the guy who wrote NUnit. Given our
      circumstances, and the overriding need to keep our API as simple and
      unpolluted by implementation details as possible, it is essential for us
      to keep certain classes internal. And it is obvious to us which classes
      those are. During our own development, we have certainly had cases where
      classes that we originally thought were going to be strictly internal
      turned out to need to be public, and we changed them. No big deal.

      But we are still hiding most of our implementation classes by making
      them internal.

      I'd appreciate your opinion on how we're missing the TDD boat. I can
      always get better...

      bab

      --
      Brian Button bbutton@...
      Principal Consultant http://www.agilesolutionsgroup.com
      Agile Solutions Group http://dotnetjunkies.com/weblog/oneagilecoder
      St. Louis, MO 636.399.3146

      Extreme Programming in St Louis - http://groups.yahoo.com/group/xpstl


      [Non-text portions of this message have been removed]
    • Edwin Gabriel Castro
      I tend to think of acceptance tests as system-wide functional tests representing user stories (use cases). The end user (or a representative) of the entire
      Message 33 of 33 , Oct 4, 2004
      View Source
      • 0 Attachment
        I tend to think of acceptance tests as "system-wide" functional tests
        representing user stories (use cases). The end user (or a representative) of
        the entire system would then write the acceptance tests capturing all of the
        requirements (use cases).

        I like to think of unit tests as acceptance tests for units (classes,
        modules, what have you). In that sense the tests should reflect how that
        unit is to be used (interface) and how the unit should respond
        (specification). In this perspective, the end users of the unit are the
        other developers of the entire system (in multi-developer environments).

        I cringe every time I hear people wanting to test internals (not the .NET
        keyword :-) because code should not be written unless there is a test for it
        first. If the test truly exists first then the test is written from the
        perspective of the "user" (some other developer). The purpose of
        encapsulation is to decouple interface and specification from
        implementation. When the test is written with the purpose to test the
        internals I feel that encapsulation is braking at some point. If the test
        represents the interface and specification of the unit, then you are
        verifying that the unit behaves according to specification regardless of the
        implementation and encapsulation is maintained.

        I expect most of the misunderstandings due to my original post are due to
        inconsistent use of terminology. Terminology can be a dangerous thing. I
        can't remember a single role playing session where the game master and at
        least one player did not get into an argument due to different
        interpretations of the same term (or perhaps the interpretation was
        equivalent but the terms used to describe the interpretation meant different
        things to different people).

        Sorry, that was a little off-topic, but I thought the two situations were
        strikingly similar and could help as an example.

        ----- Original Message -----
        From: "George Dinwiddie" <programminglists@...>
        To: <testdrivendevelopment@yahoogroups.com>
        Sent: Friday, October 01, 2004 11:18 AM
        Subject: Re: [TDD] Re: Where to put test code


        > On Fri, Oct 01, 2004 at 09:06:20AM -0700, Edwin Gabriel Castro wrote:
        >>
        >> I personally believe (in the case of libraries) that tests should verify
        >> specifications (ie, promises made by interfaces).
        >
        > Would not that be called an Acceptance Test?
        >
        > - George
        >
        >
        >
        >
        > Yahoo! Groups Links
        >
        >
        >
        >
        >
      Your message has been successfully submitted and would be delivered to recipients shortly.