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

Re: [XP] how much to unit test function that calls well-tested functions?

Expand Messages
  • John A. De Goes
    Hi Victor, The point is that if your code *relies* on a method to behave a certain way, then your intention and the consequent code dependencies should be
    Message 1 of 60 , Sep 2, 2008
      Hi Victor,

      The point is that if your code *relies* on a method to behave a
      certain way, then your intention and the consequent code dependencies
      should be documented in an automated test.

      Otherwise, if the code changes, running automated tests will not
      detect the broken assumption, nor the affected code.

      If you don't care how a method behaves (with respect to a certain
      aspect), then by all means, stop testing. But if you've written 40% of
      your tests and suddenly come to believe that the code will pass the
      other 60% without any additional effort, you should NOT stop writing
      tests until the behavior you need and will come to depend on is
      captured in automated tests.

      Whether or not you call that "TDD" is up to you.

      Note you don't have to be subjective, if you'd rather not. Tools like
      Jumble will mutate your code and run the automated tests, and tell you
      how many mutations are detected by one or more failed test cases.

      Regards,

      John A. De Goes
      N-BRAIN, Inc.
      http://www.n-brain.net
      [n minds are better than n-1]

      On Sep 1, 2008, at 4:41 AM, Victor wrote:

      > Hi John,
      >
      > Here is the way I see it.
      > 1. The developer knows what the software should(n't) be doing for
      > the current development cycle.
      > 2. Developer writes the tests.
      > 3. The tests first fail and eventually pass.
      > 4. Refactoring is considered and acted upon the considerations.
      > 5. End of development or back to 1.
      >
      > The way I understand it, what we are discussing now is outside this
      > cycle. It's about the insecurity of the developer on whether enough
      > test have been written. My point is that it doesn't seem to be a
      > good idea to let these insecurities freeze the development. Because
      > we run the automated tests all the time and the test coverage is
      > quite thorough, and we consider refactoring after each successful
      > test run, if there is something we missed, it will eventually
      > surface with enough hints of where it's to be taken care that no
      > meaningful debt will be incurred.
      >
      > On the other hand, if we base our decisions on fear and ignorance,
      > there is no guarantee as related to the quality of our decisions.
      > This doesn't mean to impose a prohibition about pondering on whether
      > the test coverage is enough. Pondering is always good, but this
      > should be a parallel activity, not one in series within the
      > development process, because if it is in series it threatens the
      > progress of the project. Additionally, each refactoring opportunity
      > is also an opportunity to reconsider the test coverage at the
      > current development point. However, in this case adding or deleting
      > tests should be based on the clear perception of a need, not a vague
      > pondering. The pondering is the motivator for critical observation,
      > the clear perception of the need is the trigger for action.
      >
      > Victor
      >
    • John A. De Goes
      Yes, but in the case of a competition, there is no change. It s truly a write-once, throwaway scenario, for which there is no investment to protect. Regards,
      Message 60 of 60 , Sep 13, 2008
        Yes, but in the case of a competition, there is no change. It's truly
        a write-once, throwaway scenario, for which there is no investment to
        protect.

        Regards,

        John A. De Goes
        N-BRAIN, Inc.
        http://www.n-brain.net
        [n minds are better than n-1]

        On Sep 13, 2008, at 9:59 AM, Marty Nelson wrote:

        > > > Let's hold a contest, where the winner is the first one to
        > complete
        > > > the assignment. The assignment is to write a program that prints
        > > > "Hello World". You code a solution with TDD, and I'll code the
        > > > solution with "print "Hello World";"
        > >
        > > > Which one of us will win the competition?
        >
        > To show how horrible wrong even a hello world app can go(and assume
        > this is .NET, not sure how other languages handle this), imagine that
        > for v2 of the app, our customers are raving for it to
        > say "Hello\Goodbye World".
        >
        > So TDD is not just about the solution, but protecting that investment
        > against change...
        >
        >
        >



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