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

Re: [scrumdevelopment] Re:Pointers to ATDD applied in a Legacy environment

Expand Messages
  • Jussi Mononen
    ... Hmm, ~2-300 000 LoC without unit tests, mixed platform and UI written in C/C++/Java/PHP/Perl ... ... Sounds like the path I/we have envisaged. At certain
    Message 1 of 11 , Sep 1, 2010
    • 0 Attachment
      On 08/31/2010 03:44 PM, alexis.hui@... wrote:
      >
      > How legacy is "legacy"? I have successfully done ATDD in three
      > environments that can be considered legacy depending on your definition:

      Hmm, ~2-300 000 LoC without unit tests, mixed platform and UI written in
      C/C++/Java/PHP/Perl ...

      > The critical enablers I found to make it successful were:
      > - Refactor mercilessly and move towards dependency injection where
      > possible, most legacy code self initializes dependencies which make any
      > stubbing or mocking impossible (suggest reading Michael Feathers book on
      > legacy code)
      > - Leverage open source testing frameworks where possible, I used a
      > combination of Junit, DBunit, jMock and Spring to get what I needed
      > - Be creative and invest, I have custom built my own ATDD framework to
      > test complex unix shell scripts for ETL by using a combination of regex,
      > sql and light shell scripts, also done the same for MIPS assemble before
      >
      > One big challenge I find is getting a suitable environment. Often you
      > need to think about data and external system integration dependencies.
      > Fortunately, I have either had control to own the data environment and
      > had easy to stub external dependencies in my situations. Trick here is
      > often finding a way to get your own slice of the data environment
      > (separate schema dedicated to acceptance tests perhaps or even modifying
      > table names with something like _AT), and creatively stubbing/wrapping
      > dependencies.

      Sounds like the path I/we have envisaged.

      At certain parts of our code we are currently bound to so old compilers
      (due to large and old customer base) that we for example can't use the
      lates test frameworks for C/C++ (we would love to take Boost test into use).

      So, I think we are generally on the right path with our thinking. Now
      there's only the biggest hurdle left, convicing The Management that the
      pain and time it takes to fix things now, will lessen the work in future.

      Thanks!

      Br,

      --
      - Agile Poodle
      - http://www.jussimononen.info/
      - http://www.twitter.com/agilepoodle
    • George Dinwiddie
      Jussi, ... Automating the tests in /parallel/ still counts as ATDD, in my opinion, if * The acceptance criteria examples are chosen ahead of time and known to
      Message 2 of 11 , Sep 1, 2010
      • 0 Attachment
        Jussi,

        On 9/2/10 3:34 AM, Jussi Mononen wrote:
        > Hi George,
        >
        > On 08/31/2010 02:33 AM, George Dinwiddie wrote:
        >>
        >> My experience is that it depends greatly on the particular legacy code,
        >> but my usual strategy is to
        >> * Do ATDD for new work
        >
        > We do have automated tests in our DoD for everything we do. But 99% of
        > them are done in parallel or afterwards and thus do not count as ATDD.

        Automating the tests in /parallel/ still counts as ATDD, in my opinion, if
        * The acceptance criteria examples are chosen ahead of time and known
        to the PO, the programmer, and the tester.
        * The story is not considered done until both the code and tests are
        done and passing.

        > Our (huge) system contains quite much legacy, in M.Feathers sense, as in
        > code without tests
        >
        >> * Cover existing functionality with characterization tests
        >
        > I gues we /could/ rely on our regression test suites and put more effort
        > in them when brand new features need to be developed. Much work ahead,
        > that is :)

        But incremental work. You can do characterization tests that cover
        large amounts of code with minimal testing. It won't necessarily detect
        small changes, but will alert you to major breakage. It /is/ a long
        road, but consists of simply putting one foot in front of the other, and
        doing that every day.

        > (Hm, I'm thinking I could write an experience report if we manage to
        > start doing ATDD.)

        Please do! In fact, write an experience report of your attempts even if
        you don't get all the way there. Others will find it valuable, and I
        think you'll learn lessons for the future, also.

        - George

        --
        ----------------------------------------------------------------------
        * George Dinwiddie * http://blog.gdinwiddie.com
        Software Development http://www.idiacomputing.com
        Consultant and Coach http://www.agilemaryland.org
        ----------------------------------------------------------------------
      • Jussi Mononen
        ... Mental note already made :-) -- - Agile Poodle - http://www.jussimononen.info/ - http://www.twitter.com/agilepoodle
        Message 3 of 11 , Sep 2, 2010
        • 0 Attachment
          On 09/02/2010 03:14 AM, George Dinwiddie wrote:
          >
          >> (Hm, I'm thinking I could write an experience report if we manage to
          >> start doing ATDD.)
          >
          > Please do! In fact, write an experience report of your attempts even if
          > you don't get all the way there. Others will find it valuable, and I
          > think you'll learn lessons for the future, also.

          Mental note already made :-)

          --
          - Agile Poodle
          - http://www.jussimononen.info/
          - http://www.twitter.com/agilepoodle
        • markus_hjort
          ... From test automation point of view the question is whether the current architecture allows you to write tests through some API instead of GUI. ATDD works
          Message 4 of 11 , Sep 7, 2010
          • 0 Attachment
            --- In scrumdevelopment@yahoogroups.com, Jussi Mononen <jussi.mononen@...> wrote:
            >
            > On 08/31/2010 03:44 PM, alexis.hui@... wrote:
            > >
            > > How legacy is "legacy"? I have successfully done ATDD in three
            > > environments that can be considered legacy depending on your definition:
            >
            > Hmm, ~2-300 000 LoC without unit tests, mixed platform and UI written in
            > C/C++/Java/PHP/Perl ...

            From test automation point of view the question is whether the current architecture allows you to write tests through some API instead of GUI. ATDD works best if you can write most of tests agains some API and only write some tests through UI.

            However, in many legacy systems UI and domain code is so badly mixed together that you end up writing all your tests through fragile UI. I have seen this path too many times. It usually does not work. The solution is to eventually refactor the architecture in a way it allows you to write more and more tests without UI.

            -Markus
          Your message has been successfully submitted and would be delivered to recipients shortly.