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

Re: [XP] Writing Unit test to existing code

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