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

124223Re: Re[2]: [XP] Does C++ unit testing become easier ?

Expand Messages
  • Steven Woody
    Dec 3, 2006
    • 0 Attachment
      On 12/3/06, John A. De Goes <john@...> wrote:
      >
      >
      >
      >
      >
      >
      >
      >
      > Hi Steven,
      >
      > > thank you very much, i begin to understan. but i still want to
      > > question: how about working with other members in a team? here,
      > > you can image C1, C2, C3 are not simple classses, they are actually
      > > subsystem consisting many of classes to do a meanful job. we do a
      > > rough front-design and have Tom to implement C1, and Jack to
      > > implement C2 which will support the implementation of the C1. you
      > > see the problem?
      >
      > I see you're trying to concurrently implement a collection of subsystems that depend on each other, based on an initial design. The problem with this approach is one of waste:
      >
      > 1. Your initial design is going to have some features it doesn't need;
      >
      > 2. Because you can't anticipate everything you *will* need, some features you forgot will probably not fit into your architecture, and will force you to do substantial architectural revisions;
      >
      > 3. Different teams will have different ideas about how the interfaces between the subsystems are supposed to operate, resulting in incompatibilities that need to be smoothed over;
      >
      > 4. The design is constrained to fit your initial model, and while it may be possible to solve the problem in a way that fits the model, it may not be the most efficient way of solving the problem.
      >
      > One way to reduce waste, and avoid mock objects, is to practice 'vertical slice development.' In this approach, instead of coding individual subsystems (concurrently or sequentially), which you then try to glue together at the end, you divide the problem into 'features', each of which has some value to the 'customer'.
      >
      > The features generally cut through multiple subsystems. Team A takes feature 1, Team B takes feature 2, and Team C takes feature 3. If everyone is practicing continuous integration, checking their code in every few hours, then coherent subsystems will form naturally, through the process of refactoring.
      >
      > Regards,
      >
      > John
      >

      thank you John. if i still has something to ask on this subject, i
      think that is what is the essential difference between feature and
      tasks. can you show some examples?

      thank you.

      -
      woody
    • Show all 29 messages in this topic