Unit Test Trial One

OK. Let's start over...

What we are trying to do here is to demonstrate how to go about designing a simple program. In particular how to work with UnitTests. This should give the reader a first look on how ExtremeProgramming works in practice.

Everybody is invited to give his or her opinion to the design!

The problem at hand is the simulation of a telephone switch. This is a real world application I'm working on at the moment. So this is a serious example and not just a toy.

Short Introduction to the domain:

We are talking of telephone switches with 100+ devices attached. These switches have a computer link. This link is used for three purposes:

configuration of the switch (not needed here)
real-time control of the switch. You can give commands to the switch like: create a conference, place a call, pick up a device, disconnect a device .....
the switch sends messages about all the activities that happen. Messages are sent whenever a device is picked up, is being called, is connected to another device or hung up.

This computer link is used to connect the switch to call-center-software (CCS). This software can now 'see' what happens to the phones and can give commands to control the devices. CCS does things like: intelligent call distribution, call campaigns to call 1000+ Customers automatically, incoming customer announcements and wait queue messages/voicebox handling etc.

My company creates CCS. My task is to write a telephone switch simulation that generates the proper messages. The simulator will be controlled by scripts. This give us the possibility to create reproducible test cases to check the behaviour of the CCS.

We have a framework that can handle a model of devices, calls and connections in between. The simulator shall use the framework, cause it's supposed to make things easier and development faster.

First Scenario

When the CCS wants to be informed about the state of a specific device, it sends a command to the switch: "Start monitoring device number XYZ". A response is sent that tells if the command was properly processed or what error occurred. Then the switch sends a message that indicates the current state of the device XYZ. From now on all changes to the device XYZ will result in a message send to the CCS until the CCS sends a command to the switch: "Stop monitoring for device number XYZ".

Now give it a try. What's your idea for the design? Any questions? Any suggestions? Was this the wrong approach in the first place? Let me know what you think.

-- MalteKroeger

"Start monitoring device number XYZ" is where you make your first mistake. Devices must be objects. The first operation should be "Locate device number XYZ". You get back an object that you can observe. You register yourself as an observer of it, and then are notified of any changes. Or maybe each device has an event handler, and you tell the device to use a new event handler, which you provide. In any case, devices must be objects. So, you will have to put a wrapper around the code you are reusing (which doesn't seem like a framework to me) that provides a view of devices as objects.

Since the switch has all the functionality, a Device is really just a proxy that delegates everything to the switch. Or maybe we should think of it as an adaptor, since it doesn't necessarily correspond to any real object. It sounds like it might have state (because you say "the message that indicates the current state of the device" and you will want to store that state somewhere) so maybe it is more of a "half-object" than a proxy.

But what tests are we supposed to make? This is supposed to be a UnitTestTrial, not a DesignBullSession?.

-- RalphJohnson

Ralph is right, this is more of a design session. I just don't know how to fix this "problem". When you want to make a UnitTestTrial, you'll have to make a design for which to write the UnitTests. Maybe we should start out with some sophisticated design? Does anyone have one we could use? -- MalteKroeger

The note below was an idea for the old design.

Thanks for the advice, but the problem is, that the handling of devices is done by a framework where I don't have much possibility to change. And besides, this is just pushing the complexity from one point in the system to another. And it creates a lot of dependencies between the devices. Our idea was, that devices don't know very much about other devices. The telephone switch is there to handle the interconnections between the devices. Just like in the real world. The switch knows about all the devices connected and knows how to handle requests. A single device shouldn't decide that.

Since we decided to start over, you might want to remove this paragraph. Thanks for the advice though. -- MalteKroeger

If the framework is wrong, you are screwed. Don't use wrong frameworks.

Of course the solution was just pushing complexity from one point in the system to another! That is the point of refactoring. You push complexity around, breaking it into smaller and smaller pieces, hiding as many as you can, sometimes getting rid of some, until the system is manageable by a mere human.

It is not clear what this page is trying to do. There is no longer enough detail to make useful suggestions.

I don't want to go too far from the topic of this page but don't see a better place to ask the question at present. My question is how you would write the UserStories that are supposed to help you to design & code the system described above and it's test cases.

Would you need a separate one for each possible type of call made through the telephone switch? I would think that this could amount to hundreds of possibilities by the time that all all the things than can happen to a call in a switch like being transferred, conferences etc, and queueing and ACD functions.

Would you write a separate user story for each possibility you could think of to ensure that it gets tested and written properly, or rely on a some kind of more generic description perhaps referring to another document containing such a list?

I'd write enough different stories to find the commonalities. I'll wager that there aren't really hundreds of different kinds of calls, just tens of things that can happen, cumulatively, in nearly any order. Then I'd switch to stories about the combinations that are, and aren't legal, the orders that can and can't happen, and so on. I don't know what would happen if I did that: I'm just surmising that there really aren't hundreds of different kinds of calls. If that didn't work, I'd do something different, but frankly I expect that to work. -- RonJeffries