TDD, Mocks, and Isolating Legacy Application Components?
-
There seems to be more than quite a few docs out there that teach you how to do TDD from scratch, but I haven't seen much theoretical work done on "mocking out" and testing existing components from legacy apps--for example, if I have a DAL that's already plugged into my four-year old .NET 1.1 app, is there anyway I can apply post-hoc unit tests to the DAL without changing its design? What I'm really looking for is a catalog of "mocking patterns" that give me solutions to various problems so that I can isolate my legacy components and test them without modifying the design--so my question is, has anyone managed to do this yet?
Do you know...LinFu?
-
There seems to be more than quite a few docs out there that teach you how to do TDD from scratch, but I haven't seen much theoretical work done on "mocking out" and testing existing components from legacy apps--for example, if I have a DAL that's already plugged into my four-year old .NET 1.1 app, is there anyway I can apply post-hoc unit tests to the DAL without changing its design? What I'm really looking for is a catalog of "mocking patterns" that give me solutions to various problems so that I can isolate my legacy components and test them without modifying the design--so my question is, has anyone managed to do this yet?
Do you know...LinFu?
-
There seems to be more than quite a few docs out there that teach you how to do TDD from scratch, but I haven't seen much theoretical work done on "mocking out" and testing existing components from legacy apps--for example, if I have a DAL that's already plugged into my four-year old .NET 1.1 app, is there anyway I can apply post-hoc unit tests to the DAL without changing its design? What I'm really looking for is a catalog of "mocking patterns" that give me solutions to various problems so that I can isolate my legacy components and test them without modifying the design--so my question is, has anyone managed to do this yet?
Do you know...LinFu?
Hrmmm I'd be assuming you are kinda boned in that case without some real trickery. Most legacy code of this kind I've seen tends to be fairly rigid - definitely no dependancy injection or even factory patterns. It sounds hard. Possibly you could do something like post-process the compiled DAL, and replace instantiations of certain classes with your mocked instances, and then run the tests. :S
Mark Churchill Director, Dunn & Churchill Pty Ltd Free Download: Diamond Binding: The simple, powerful, reliable, and effective data layer toolkit for Visual Studio.
Alpha release: Entanglar: Transparant multiplayer framework for .Net games. -
Hrmmm I'd be assuming you are kinda boned in that case without some real trickery. Most legacy code of this kind I've seen tends to be fairly rigid - definitely no dependancy injection or even factory patterns. It sounds hard. Possibly you could do something like post-process the compiled DAL, and replace instantiations of certain classes with your mocked instances, and then run the tests. :S
Mark Churchill Director, Dunn & Churchill Pty Ltd Free Download: Diamond Binding: The simple, powerful, reliable, and effective data layer toolkit for Visual Studio.
Alpha release: Entanglar: Transparant multiplayer framework for .Net games.Mark Churchill wrote:
Hrmmm I'd be assuming you are kinda boned in that case without some real trickery. Most legacy code of this kind I've seen tends to be fairly rigid - definitely no dependancy injection or even factory patterns. It sounds hard.
Without a doubt, it is incredibly difficult--you'd have to find a way to isolate the target component and then "extrude" it so that you can test its behavior without pulling it completely out of a compiled assembly--in essence, it's like refactoring in reverse--albeit in a binary form. It's definitely a black art, to say the least.
Mark Churchill wrote:
Possibly you could do something like post-process the compiled DAL, and replace instantiations of certain classes with your mocked instances, and then run the tests. :S
Actually I'm not too worried about how to replace the classes or methods with mocks--what I'm really looking for is a a common set of testing practices that I can programmatically apply to the portion of legacy code that I want to test. Based on the lack of responses to this thread, however, I can only surmise that there aren't that many people out there that specialize in applying automatic regression tests to legacy code without changing the design--so for now it's more of a pipe dream, but I'll have a lot of fun making it a reality. Thanks for the input, Mark!
Do you know...LinFu?
-
Philip Laureano wrote:
so my question is, has anyone managed to do this yet?
These guys seem to think they have.[^] I have no experience with this so I cannot confirm it.
led mike
About NMock / NMock2: the version at nmock.org (NMock) is not actively supported anymore. If you are looking for the latest version based on NMock then have a look at https://sourceforge.net/projects/nmock2[^] (NMock2) Happy mocking Urs
-^-^-^-^-^-^-^- no risk no funk
-
Mark Churchill wrote:
Hrmmm I'd be assuming you are kinda boned in that case without some real trickery. Most legacy code of this kind I've seen tends to be fairly rigid - definitely no dependancy injection or even factory patterns. It sounds hard.
Without a doubt, it is incredibly difficult--you'd have to find a way to isolate the target component and then "extrude" it so that you can test its behavior without pulling it completely out of a compiled assembly--in essence, it's like refactoring in reverse--albeit in a binary form. It's definitely a black art, to say the least.
Mark Churchill wrote:
Possibly you could do something like post-process the compiled DAL, and replace instantiations of certain classes with your mocked instances, and then run the tests. :S
Actually I'm not too worried about how to replace the classes or methods with mocks--what I'm really looking for is a a common set of testing practices that I can programmatically apply to the portion of legacy code that I want to test. Based on the lack of responses to this thread, however, I can only surmise that there aren't that many people out there that specialize in applying automatic regression tests to legacy code without changing the design--so for now it's more of a pipe dream, but I'll have a lot of fun making it a reality. Thanks for the input, Mark!
Do you know...LinFu?
-
Pete O'Hanlon wrote:
Have you looked into Pex[^]? It's an interesting concept, to say the least.
From what I can tell, Pex looks like a brute-force solution to unit testing--it solves some of the coverage problems in TDD by attempting to quantify every possible input and output that might come out of a single method. There's two problems to this approach: 1) Observability, and 2) Isolating the component to be tested. The first problem of observability has a lot to do with the software engineering equivalent of the Uncertainty Principle--how do you observe the behavior of an app without having to modify it? For example, if I wanted to test the DAL of a legacy app and that application has a tightly-coupled architecture, how do you verify the behavior of the DAL without modifying its architecture to support unit testing? With Pex, you can only test the components of an architecture if their behavior can be "observed" by the unit tests generated by Pex; however, in a legacy app, you might not have the luxury of modifying the architecture to support those unit tests. The isolation problem rears its ugly head when you have legacy code that is ridden with "copy & paste" code. In order to use automated unit testing (much less Pex), you would have to refactor out the duplication and then mock out the components around the component to be tested, and then test the component itself. Once you have the component isolated, it is then (and only then) that you can throw Pex at it and have it do its brute-force approach to finding holes in your code. The problem with using Pex with legacy apps is that the approach might be too invasive. In the current state of automated unit testing and TDD, this is akin to giving bypass surgery to a patient who just wants a medical checkup. What I want to do is diagnose the patient (per se) without killing them in the process. IMHO, we're practically in the Dark Ages when it comes to diagnosing legacy apps, and that has to change.
Do you know...LinFu?
-
There seems to be more than quite a few docs out there that teach you how to do TDD from scratch, but I haven't seen much theoretical work done on "mocking out" and testing existing components from legacy apps--for example, if I have a DAL that's already plugged into my four-year old .NET 1.1 app, is there anyway I can apply post-hoc unit tests to the DAL without changing its design? What I'm really looking for is a catalog of "mocking patterns" that give me solutions to various problems so that I can isolate my legacy components and test them without modifying the design--so my question is, has anyone managed to do this yet?
Do you know...LinFu?
If you need to unit test legacy code, code that isn't particularly designed for mockability (or isn't designed for it at all), there is nothing that comes close to the TypeMock Isolator. TypeMock lets you mock absolutely anything, any time, for any reason, regardless of what it is. You can mock statics, replace function calls, whatever you need to. It allows you to fully isolate your unit of interest and actually perform "unit" testing for any code, regardless of whether it actually supports unit testing. Many people will jump on this with a vehement revulsion and provide blanket statements that you should refactor all of your code so its better architected and is properly mockable. In the long run, yes, you should eventually improve your code base. But when your on a budget and need that full safety net of tested code, TypeMock is a godsend. You can, basically, have your cake and eat it too. I hope it helps. :) http://www.typemock.com/
-
If you need to unit test legacy code, code that isn't particularly designed for mockability (or isn't designed for it at all), there is nothing that comes close to the TypeMock Isolator. TypeMock lets you mock absolutely anything, any time, for any reason, regardless of what it is. You can mock statics, replace function calls, whatever you need to. It allows you to fully isolate your unit of interest and actually perform "unit" testing for any code, regardless of whether it actually supports unit testing. Many people will jump on this with a vehement revulsion and provide blanket statements that you should refactor all of your code so its better architected and is properly mockable. In the long run, yes, you should eventually improve your code base. But when your on a budget and need that full safety net of tested code, TypeMock is a godsend. You can, basically, have your cake and eat it too. I hope it helps. :) http://www.typemock.com/
You're right - I am going to jump on this post. In fact, I'm going to jump all over it and say - interesting, I'll go and have a look at it now.
"WPF has many lovers. It's a veritable porn star!" - Josh Smith
-
You're right - I am going to jump on this post. In fact, I'm going to jump all over it and say - interesting, I'll go and have a look at it now.
"WPF has many lovers. It's a veritable porn star!" - Josh Smith
LOL, let me know what you think. ;) I'm still evaluating it myself, but and it does have a couple drawbacks (i.e. the isolator is a 'wrapper' program that must be running for method intercepts and the like to function during execution, and it costs money). When it comes to testing locked-down legacy code, though, its truely unique.