Re: [scrumdevelopment] Re:Pointers to ATDD applied in a Legacy environment
- On 08/31/2010 03:44 PM, alexis.hui@... wrote:
>Hmm, ~2-300 000 LoC without unit tests, mixed platform and UI written in
> How legacy is "legacy"? I have successfully done ATDD in three
> environments that can be considered legacy depending on your definition:
> The critical enablers I found to make it successful were:Sounds like the path I/we have envisaged.
> - 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
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.
- Agile Poodle
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 Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
- On 09/02/2010 03:14 AM, George Dinwiddie wrote:
>Mental note already made :-)
>> (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.
- Agile Poodle
- --- In firstname.lastname@example.org, Jussi Mononen <jussi.mononen@...> wrote:
>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.
> 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 ...
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.