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

Re: [XP] Writing Unit test to existing code

Expand Messages
  • Phlip
    ... Test-free legacy code has a delicate investment in BigBangTesting. Here s the rules: - Don t Refactor it; treat it as a 3rd party library and just use it.
    Message 1 of 6 , May 1, 2001
      Proclaimed Anders Bendtsen from the mountaintops:

      > I'm working on a project where we are considering using XP. Out project
      > manager one day asked: 'How do you use uni test with our old code?' A
      > good question. Has anyone any experience with writing unit test for
      > existing code.

      Test-free legacy code has a delicate investment in BigBangTesting. Here's the
      rules:

      - Don't Refactor it; treat it as a 3rd party library and just use it.

      - Put Acceptance Tests on it.

      - Adventures into it should leave a trail of 'assert' statements as proto
      UnitTests.

      - These 'assert's could call new test functions that do very aggressive
      investigations.

      - Use ExtractAlgorithmRefactor to re-write from scratch.

      - Rewriting from scratch, following the rules, has to be better than limping
      around if you discover any reason to refactor the code.

      --
      Phlip phlip_cpp@...
      ============== http://phlip.webjump.com ==============
      -- Programming without Tan Lines, LLC --
    • davechaplin@yahoo.co.uk
      ... project ... A ... Yes. I had to take over some seriously poor code written by a total hacker. [A select case statement that was about 20 screens long - I
      Message 2 of 6 , May 1, 2001
        --- In extremeprogramming@y..., Anders Bendtsen <anb@e...> wrote:
        > I'm working on a project where we are considering using XP. Out
        project
        > manager one day asked: 'How do you use uni test with our old code?'
        A
        > good question. Has anyone any experience with writing unit test for
        > existing code.
        >
        >
        >
        > Anders Bendtsen

        Yes. I had to take over some seriously poor code written by a total
        hacker. [A select case statement that was about 20 screens long - I
        kid you not!].

        Anyway - the first thing we did was to ensure we abstracted the front
        end from the middle tier, with it still working. Not to tough since
        it was ASP talking to COM. Then we wrote lots of tests on top of the
        component. Then we refactored the code inside.

        Be diligent when choosing which tests you are going to write. I am
        assuming you are wishing to enhance the system and thus need the
        tests. So, write tests for the areas that work but you think might
        break when you make the changes. When you first start writing unit
        tests it is easy to get carried away writing lots of tests that never
        fail - try not to go down that route if you can.

        Saying that, if you are extending the system, then just write tests
        (upfront) for the new part you are writing.

        Dave Chaplin
      • RobertoQui�onez
        It s a great adventure to start. You needed to begin with gathering old documentacion about this project, inclusively would you need into its control
        Message 3 of 6 , May 1, 2001
          It's a great adventure to start.
          You needed to begin with gathering old documentacion
          about this project, inclusively would you need into
          its control configuration, if exist.
          This is only to understand deeply your old code, then
          perhaps you can start to write unit test.

          --- Anders Bendtsen <anb@...> wrote:
          > I'm working on a project where we are considering
          > using XP. Out project
          > manager one day asked: 'How do you use uni test with
          > our old code?' A
          > good question. Has anyone any experience with
          > writing unit test for
          > existing code.
          >
          >
          >
          > Anders Bendtsen
          >
          >
          > To Post a message, send it to:
          > extremeprogramming@...
          >
          > To Unsubscribe, send a blank message to:
          > extremeprogramming-unsubscribe@...
          >
          > Don't miss XP UNIVERSE, the first US conference on
          > XP and Agile Methods. Early registration discounts
          > EXTENDED until May 1, 2001. www.xpuniverse.com for
          > details and registration.
          >
          > Your use of Yahoo! Groups is subject to
          > http://docs.yahoo.com/info/terms/
          >
          >


          __________________________________________________
          Do You Yahoo!?
          Yahoo! Auctions - buy the things you want at great prices
          http://auctions.yahoo.com/
        • tobysteel@yahoo.ca
          I was part of an experiment into XP for a previous employer that did just as Dave describes. In order to abstract the middle tier from the servlets we had to
          Message 4 of 6 , May 2, 2001
            I was part of an experiment into XP for a previous employer that did
            just as Dave describes. In order to abstract the middle tier from the
            servlets we had to subclass each class we wanted to write tests for
            and then test the subclasses. In the end it told us that the
            application had to be rewritten from scratch in order to be enhanced
            or maintained.
            One key concept was discovered. In retrofitting unit tests to
            existing code it becomes clear which parts of a system requiring
            enhancement need to be refactored in what order. Thus iterations can
            be costed out giving the eventual cost of the desired enhancements.
            I suspect the practice will lead to more than a few projects being
            abandoned. This one was.

            --- In extremeprogramming@y..., davechaplin@y... wrote:
            > Anyway - the first thing we did was to ensure we abstracted the
            front
            > end from the middle tier, with it still working. Not to tough since
            > it was ASP talking to COM. Then we wrote lots of tests on top of
            the
            > component. Then we refactored the code inside.
            >
            > Be diligent when choosing which tests you are going to write. I am
            > assuming you are wishing to enhance the system and thus need the
            > tests. So, write tests for the areas that work but you think might
            > break when you make the changes. When you first start writing unit
            > tests it is easy to get carried away writing lots of tests that
            never
            > fail - try not to go down that route if you can.
            >
            > Saying that, if you are extending the system, then just write tests
            > (upfront) for the new part you are writing.
            >
            > Dave Chaplin
          • John Carter
            ... The answer, as it has been given by many others, is It s bloody difficult! But I have a small but useful suggestion from something I m playing with on
            Message 5 of 6 , May 17, 2001
              On Tue, 1 May 2001, Anders Bendtsen wrote:

              > I'm working on a project where we are considering using XP. Out project
              > manager one day asked: 'How do you use uni test with our old code?' A
              > good question. Has anyone any experience with writing unit test for
              > existing code.

              The answer, as it has been given by many others, is "It's bloody
              difficult!" But I have a small but useful suggestion from something I'm
              playing with on the backburner.

              I call the problem the hairball problem. You want to test a class, but
              can't because it seems to require you lift the whole blooming hairball
              into your test just to compile!

              Madness lies that way....

              So I have been fiddling with an alternative approach....

              This descends into pure C++ (gcc variety) but the principles can be
              extracted and applied in a different manner to other flavoured
              hairballs...

              My idea is we can segment classes into the following categories....

              Category A - Infrastructure
              Things like ostream, string etc. etc. Things that are part of the system
              that we can assume are correct.

              We don't test these. (Warning : stl templates of hairball classes
              probably shouldn't be regarded as entirely harmless...)

              Category B - Primitive classes.
              Classes whose methods do not invoke methods on any class other than
              itself or an Infrastructure class.

              These are pretty simple and we probably could fairly easily tease them
              out of the hairball and test. Start by writing unit tests for these
              classes.

              Category C - MetaPrimitive classes.
              Classes whose methods do not invoke methods on any class other than
              itself or Primitive Class or an Infrastructure class.

              These are less simple and but we probably could fairly easily tease them
              out of the hairball and test. Write unit tests for these
              classes.

              Once you have a unit test for a metaprimitive class, relabel it primitive and
              see if any other classes become metaprimitive. Repeat until you converge.

              Category D - Hairballs.

              The rest. Classes whose call graphs show irreducible loops or invoke
              other hairballs.

              Solution. Umm. Err. Semantic adjustment... Leave these classes as
              untested. Redefine the term "Unit". Declare hairball classes to be a
              "business object" not an implementation "unit".

              Study the call graph, the instance variables etc. etc. to see whether
              you can segment the thing into Metaprimitives. ie. The hairball
              becomes an almost empty shell around a collection of
              metaprimitives. The API to the hairball remains entirely unchanged.


              Getting the call graph...
              ======================

              Getting the who calls who graph is a non trivial problem. Especially
              with a hairball of a syntax like C++. Moral of the story, let the
              compiler do it for you and parse the assembler!

              Now speaking pure linux gcc and gnumake...

              In your makefile add
              CXXFLAGS += -O0 --save-temps

              And then make everything, it will spewed out the assembly files as *.s
              files.

              Then "find src -name '*.s' | xargs cat | grep -E '^(\\.globl|[ \t]+call)\\b' | c++filt"

              And you have a list of method declarations (the .globl's) and method
              calls which you can massage into a "this class calls that class" graph.

              Feed to "dot" from http://www.research.att.com/sw/tools/graphviz
              view in gv and contemplate.


              Problems :-

              1) Virtual calls are lost. They show up in the assembler as
              "call *%eax". Solution? Haven't got one yet....

              2) Relations via direct access to instance variable are ignored....


              ie. The whole idea needs refining, but its a start...

              Here is an example call graph from a large C++ app with the class names
              changed to protect the guilty...

              http://groups.yahoo.com/group/extremeprogramming/files/call_graph.png


              John Carter Phone : (64)(3) 358 6639
              Tait Electronics Fax : (64)(3) 359 4632
              PO Box 1645 Christchurch Email : john.carter@...
              New Zealand

              Time machine feature - A feature that is best implemented by climbing
              into a time machine with an AK-47 and taking out the swine who
              spec'd it.
            Your message has been successfully submitted and would be delivered to recipients shortly.