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

Pointers to ATDD applied in a Legacy environment

Expand Messages
  • Jussi Mononen
    Hi all, I m going to introduce the concept of Acceptance Test Driven Development to my unit and I am looking for any material, blogs, articles and experiences
    Message 1 of 11 , Aug 30 11:09 AM
    • 0 Attachment
      Hi all,

      I'm going to introduce the concept of Acceptance Test Driven Development
      to my unit and I am looking for any material, blogs, articles and
      experiences of applying ATDD to a legacy code base.

      Br,

      --
      - Agile Poodle
      - http://www.jussimononen.info/
      - http://www.twitter.com/agilepoodle
    • Malcolm Anderson
      I asked Mr. Google about this whole ATDD thing and found this deck http://www.slideshare.net/nashjain/acceptance-test-driven-development-350264 I find it
      Message 2 of 11 , Aug 30 11:53 AM
      • 0 Attachment
        I asked Mr. Google about this whole ATDD thing and found this deck

        http://www.slideshare.net/nashjain/acceptance-test-driven-development-350264

        I find it interesting and I also would love to hear some stories about implementation in the wild.

        Malcolm




        On Mon, Aug 30, 2010 at 2:09 PM, Jussi Mononen <jussi.mononen@...> wrote:
         

        Hi all,

        I'm going to introduce the concept of Acceptance Test Driven Development
        to my unit and I am looking for any material, blogs, articles and
        experiences of applying ATDD to a legacy code base.

        Br,

        --
        - Agile Poodle
        - http://www.jussimononen.info/
        - http://www.twitter.com/agilepoodle


      • Jussi Mononen
        ... (sorry, forgot to mention that I ve googled around for a while) Mr. Google is good but I hope that this list can provide better pointers since I am
        Message 3 of 11 , Aug 30 12:50 PM
        • 0 Attachment
          On 08/30/2010 09:53 PM, Malcolm Anderson wrote:
          >
          > I asked Mr. Google about this whole ATDD thing and found this deck
          >
          > http://www.slideshare.net/nashjain/acceptance-test-driven-development-350264

          (sorry, forgot to mention that I've googled around for a while)

          Mr. Google is good but I hope that this list can provide better pointers
          since I am specifically looking for legacy code implementations of ATDD.

          All pointers are welcome :)

          Br,

          --
          - Agile Poodle
          - http://www.jussimononen.info/
          - http://www.twitter.com/agilepoodle
        • David Roncancio
          Wel this isnt about ATDD in legacy, but to alternatives for it http://jamesshore.com/Blog/Alternatives-to-Acceptance-Testing.html
          Message 4 of 11 , Aug 30 1:22 PM
          • 0 Attachment
            Wel this isnt about ATDD in legacy, but to alternatives for it


            it might help you


            David Roncancio
            (+57) 3014311354


            On Mon, Aug 30, 2010 at 2:50 PM, Jussi Mononen <jussi.mononen@...> wrote:
            On 08/30/2010 09:53 PM, Malcolm Anderson wrote:
            >
            > I asked Mr. Google about this whole ATDD thing and found this deck
            >
            > http://www.slideshare.net/nashjain/acceptance-test-driven-development-350264

            (sorry, forgot to mention that I've googled around for a while)

            Mr. Google is good but I hope that this list can provide better pointers
            since I am specifically looking for legacy code implementations of ATDD.

            All pointers are welcome :)
            ------------------------------------

            To Post a message, send it to:   scrumdevelopment@...
            To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links

            <*> To visit your group on the web, go to:
               http://groups.yahoo.com/group/scrumdevelopment/

            <*> Your email settings:
               Individual Email | Traditional

            <*> To change settings online go to:
               http://groups.yahoo.com/group/scrumdevelopment/join
               (Yahoo! ID required)

            <*> To change settings via email:
               scrumdevelopment-digest@yahoogroups.com
               scrumdevelopment-fullfeatured@yahoogroups.com

            <*> To unsubscribe from this group, send an email to:
               scrumdevelopment-unsubscribe@yahoogroups.com

            <*> Your use of Yahoo! Groups is subject to:
               http://docs.yahoo.com/info/terms/


          • George Dinwiddie
            Jussi, ... My experience is that it depends greatly on the particular legacy code, but my usual strategy is to * Do ATDD for new work * Cover existing
            Message 5 of 11 , Aug 30 4:33 PM
            • 0 Attachment
              Jussi,

              On 8/31/10 3:50 AM, Jussi Mononen wrote:
              > On 08/30/2010 09:53 PM, Malcolm Anderson wrote:
              >>
              >> I asked Mr. Google about this whole ATDD thing and found this deck
              >>
              >> http://www.slideshare.net/nashjain/acceptance-test-driven-development-350264
              >
              > (sorry, forgot to mention that I've googled around for a while)
              >
              > Mr. Google is good but I hope that this list can provide better pointers
              > since I am specifically looking for legacy code implementations of ATDD.

              My experience is that it depends greatly on the particular legacy code,
              but my usual strategy is to
              * Do ATDD for new work
              * Cover existing functionality with characterization tests
              * When existing functionality is modified, consider what, and how
              much, additional testing will be helpful and cost-effective.

              - George

              --
              ----------------------------------------------------------------------
              * George Dinwiddie * http://blog.gdinwiddie.com
              Software Development http://www.idiacomputing.com
              Consultant and Coach http://www.agilemaryland.org
              ----------------------------------------------------------------------
            • alexis.hui@gmail.com
              How legacy is legacy ? I have successfully done ATDD in three environments that can be considered legacy depending on your definition: - Legacy J2EE code
              Message 6 of 11 , Aug 31 5:44 AM
              • 0 Attachment
                How legacy is "legacy"? I have successfully done ATDD in three environments that can be considered legacy depending on your definition:

                - Legacy J2EE code using EJB 2.0, CORBA, Struts 1.1 with large portions of monolithic code written by different folks (onshore/offshore/etc.) over time
                - Unix shell scripting for DB2 ETL Datawarehousing
                - MIPS assembly language

                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.
                Sent on the TELUS Mobility network with BlackBerry
              • Jussi Mononen
                Hi George, ... 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.
                Message 7 of 11 , Sep 1, 2010
                • 0 Attachment
                  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.

                  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 :)

                  > * When existing functionality is modified, consider what, and how
                  > much, additional testing will be helpful and cost-effective.

                  We will.

                  Thanks for everyone who replied!

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

                  Br,

                  --
                  - Agile Poodle
                  - http://www.jussimononen.info/
                  - http://www.twitter.com/agilepoodle
                • 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 8 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 9 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 10 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 11 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.