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

Writing Unit test to existing code

Expand Messages
  • Anders Bendtsen
    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.
    Message 1 of 6 , May 1, 2001
    • 0 Attachment
      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
    • 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 2 of 6 , May 1, 2001
      • 0 Attachment
        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 3 of 6 , May 1, 2001
        • 0 Attachment
          --- 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 4 of 6 , May 1, 2001
          • 0 Attachment
            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 5 of 6 , May 2, 2001
            • 0 Attachment
              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 6 of 6 , May 17, 2001
              • 0 Attachment
                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.