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

Re: Writing Unit test to existing code

Expand Messages
  • 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 1 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 2 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 3 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 4 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.