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

Re: [XP] Packaging of TDD helper classes

Expand Messages
  • Manfred Lange
    Jeff, if you have a multitude of fine-grained classes, and you don t like them, don t introduce them in the first place! If you have good reason to introduce a
    Message 1 of 4 , May 8, 2006
      Jeff,

      if you have a multitude of fine-grained classes, and you don't like
      them, don't introduce them in the first place!

      If you have good reason to introduce a class or an interface, it should
      be easy to give them good names, essentially representing the concepts
      they stand for. Once your classes and interfaces have good names, it
      should be fairly easy to "group" them into different packages.

      If you feel that the classes become too small, say there is only little
      code in them, ask whether they are still needed.

      Also, when you talk about "get some data, process some data, write some
      data" (I'm exaggerating, and this is not a quote from you), it reminds
      me of a procedural approach. Maybe you want to look at combining some of
      the processing with the "data" and turn these things into objects. A
      possible approach to go this direction might be Eric Evans' book on
      Domain-Driven Design.

      What I have observed in one team I was working with is this: Mention a
      concept, and shortly you will find it all over the place. Mention
      interfaces and you'll find interface all over the place, regardless of
      whether they were necessary or not. Mention mocks, and immediately there
      were mocks everywhere even for very simple things. It took them very
      long until they got to the point that they carefully assessed different
      options, experimented, and then settled on a solution.

      While mocking and dependency injection might be a good idea in certain
      situations, I believe they should not be used by default, but only where
      it is appropriate.

      So my suggestion with regards to stubbing/mocking would be: Do you use
      them because someone said it's good to have mocks? Or do you use them
      because they solve a very specific problem, and there is no simpler
      solution possible?

      If you feel you have too many classes and interfaces, you are probably
      right. Try to find ways to simplify. Discuss with your team colleagues,
      1:1 or the entire group. You'll be surprised how many excellent
      suggestions for improvement you will get!

      Kind regards,
      Manfred.
      ---
      Manfred Lange.
      csUnit Lead Developer
      http://www.csunit.org



      jeffz_2002 wrote:

      >>I always like to keep my unit tests and test helpers in seperate
      >>packages that correspond to the packages that contain the classes
      >>being tested
      >>
      >>
      >
      >Hey James, I do this too (my 'test' folder's directory structure
      >mirrors the 'src' folder's).
      >
      >My question might have been unclear... what I'd like to know is how you
      >organized the multitude of fine-grained classes that decouple your
      >design, not just your tests.
      >
      >Thanks,
      >
      >jz
      >
      >
      >
      >
      >
      >
      >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
      >
      >
      >
      >
      >
      >
      >
      >
      >
      >


      [Non-text portions of this message have been removed]
    Your message has been successfully submitted and would be delivered to recipients shortly.