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

Re: [XP] Re: How use stub (scaffolding) classes with Junit?

Expand Messages
  • Tim Mackinnon
    ... We thought this too - however since adopting this approach our code has much improved. More importantly newcomers to our team (both junior and senior)
    Message 1 of 4 , May 31, 2000
      >However, I don't think you should have an interface for every single
      >interaction between objects. To me that seems like over-kill.

      We thought this too - however since adopting this approach our code has much
      improved. More importantly newcomers to our team (both junior and senior)
      quickly pick up this technique and write code to a "team standard".
      Obviously there are a few small places where we break this rule - but we
      think about this quite carefully and in general do not do it. There are a
      lot of interfaces, but we view an Object, its Interface and its Scaffold as
      one thing.

      We have been so pleased with idea that we wrote a paper on it for XP-2000.
      Yes its an old idea - whats interesting is that in XP (especially with tests
      up front) it really becomes a powerful technique.

      > I agree. It only makes sense when you need to be able to consider the
      > client object independently of the objects it calls. If the client object
      > creates the object it calls with an explicit call to 'new' then they are
      > very closely coupled and it is meaningless to speak of them independently.

      Be careful with this - dividing objects up into small responsibilities can
      greatly simplify your testing. If possible we test independently and pass
      objects in wherever possible. This has the nice side effect of conforming to
      the law of demeter as well.

      >I the example above, class A and B are both needed for the solution,
      >but they are doing different parts. It is of course possible to test
      >them (and more, if the solution is made up of many classes) together,
      >but isn't the point of unit testing to test units individually to
      >see that they work as you want before you put them together?

      I would agree with this point - aim for this wherever possible, however try
      to compose your objects by passing them into each other - this opens the
      possibility to passing in a Mock (or Scaffold) test object that you can put
      assertions on.

      >Not as I understand it. The point of unit testing is to be sure that the
      >code you wrote behaves as you intend it to. If you would never use class A
      >without class B, its behavior without class B is meaningless to your
      >system, so you have no particular reason to test it without class B.
      >Remember that we are interested in pragmatic results, not academic theory.
      >If class B can stand alone, test it alone. Then, when you build class A on
      >top of it, you can pretty much attribute any problems to class A.

      If you have done a CRC session, then you would have class A and B because
      they have different responsibilities and collaborate in some way. Your unit
      tests excercise this. I have also seen A & B emerge due to some refactoring
      (e.g. B is used by some other class as well). In this case we have noticed
      that some unit tests for A will move over as unit tests for B, and A gets
      some simpler test that make sure it delegates to B. Finally, I have also
      noticed that B can emerge becuase the test you want to write is not possible
      when there is some hidden aspect inside A. For example, what happens if my
      Salary calculation gives a negative value? Well the test I would like to
      write is that if I created my BusinessObject with a SalaryCalculator that
      always returned a negative salary then I would expect.... etc.

      >Also, if A and B are developped by different designers (or pairs),
      >then the unit testing would have to be coordinated.

      >If they are as closely coupled as you indicate, it is probably not a good
      >strategy to develop them separately. Also remember that in XP as I
      >understand it, you do not define tasks in terms of "build class A" and
      >"build class B." You are better off assigning tasks to implement a
      >particular testable capability. The pair assigned the task will then build
      >those pieces of class A and class B needed for that capability. In the
      >situation you describe, class A would never be built without class B.

      This is true - what is nice about testing with scaffolding (we call them
      Mocks) is that if the second team does end up using some of the other
      objects, they can easily setup the scaffolding.

    Your message has been successfully submitted and would be delivered to recipients shortly.