Unit Testing

who is chatting on SOLO Chat

The Free Radical

Subscribe or Purchase

Current Issue Contents

Who's new

Poll

What should the government do about ailing financial institutions?

Nothing, except to back off and get out—as any Objectivist knows, intervention is treating the disease with the disease

83%

Intervene judiciously—enough to avert a catastrophe that is otherwise imminent

Intervene massively—as it's doing

Nationalize the whole economy and be done with it. Bring on the USSA!

Something else (specify)

11%

Total votes: 80

Basic Economics by Thomas Sowell

Economics In One Lesson by Henry Hazlitt

Submitted by Duncan Bayne on Thu, 2006-03-02 19:18.

I may as well kick the ball off with a nice controversial topic Smiling I'm busy writing an application that integrates with an in-house application management framework, that uses a combination of multicast IP and .NET Remoting to communicate.

The application in question is a Windows Forms app that monitors and controls the Windows Services that underpin the management framework.

Catch is, there is no testing harness for this architecture. None whatsoever. This will make it difficult to test the objects I'm creating (e.g. to represent individual applications, to discover & manage the connections to the underlying Windows Services, etc.) - effectively I'd have to do manual functional tests against a live system, or make my unit tests assume that such a live system existed, neither of which would work well.

So, I'm writing a series of mock objects to represent the different components with which my Windows Forms app will integrate. They'll be fairly rudimentary: announcing themselves via multicast, then broadcasting hard-coded XML documents when asked. (This is of course a very simple overview; said management framework doesn't use serialization to create the XML docs, there are no schemas for those docs (!), it sends proprietary headers at the start of XML docs over multicast, etc. etc.)

Catch number two: this is likely to take at least a couple of weeks of coding, possibly longer, just to put together the mock objects. They'll be complicated (as far as unit testing objects go), and will have to be maintained in step with the actual objects with each release.

Does anyone here have much experience with this kind of thing - i.e., crafting tests for an app that integrates with an older system sans a test harness?

Login or register to post comments
Printer-friendly version
531 reads

( categories:

SOLO Geek

)

I asume you have used NUnit

Submitted by wngreen on Fri, 2006-03-03 03:52.

I asume you have used NUnit profusely...

The difficulty in modeling the legacy system probably is due to, as you say in you last post, a less then sufficent understanding of the underlying legacy stuff. Legacy systems are tough I wish I could tell you more advice other then don't break anything you don't plan to immediatly re-implement.

You've pretty much got it ...

Submitted by Duncan Bayne on Fri, 2006-03-03 03:06.

... except that by live I mean 'the real live system we have set up in our building for testing' rather than 'production'. So if I do hose anything, it'll only be our internal testbed. Sorry for the poor use of terminology.

What I'm actually learning is that we're doing a poor job of using the .NET Framework technology - there's a lot of stuff that could be done in a *MUCH* nicer way with XML serialization / deserialization of objects, rather than building up strings, e.g.

I think by the time I've finished my testing framework, I'll have a sufficiently good understanding of the underlying legacy stuff to suggest how to re-implement it better Smiling

False alarm...

Submitted by Jody Gomez on Fri, 2006-03-03 03:02.

I saw "unit" testing and thought this was a SoloThrust thread. Eye

Legacy -- ick

Submitted by sjw on Fri, 2006-03-03 01:29.

Duncan,

I'm not understanding your scenario all the way--but given what I do understand your strategy seems quite sound. If I understand you, you're creating a client that interfaces with a legacy server, and in order to bootstrap your coding you're creating a mock server. Which is essentially just the mirror image of the client you have to write in the first place. Have I got it?

If so, I think that's exactly the right strategy. Because when something goes wrong in the initial development, then you know for a fact it's in your code, you don't have to wonder whether it's in the legacy code which is out of your control. Unless there are some mitigating circumstances, your method will likely get you to quicker results even though you'll end up with twice the code because of the ambiguity you're eliminating for a substantial phase of the development.

I don't understand why you're required to test against a live system and that sounds dangerous--why can't you create a duplicate system for development use only?