Discussion of the eXtreme Programming practice of TestDrivenDevelopment

Lior Friedman | 4 May 2010 07:41

RE: Re: how would you test Active Objects?

Hi

I'm not sure I made myself clear enough.

The setup looks something like:

Endpoint1 -> queue -> logic handler -> callback.

The queue->handler is an internal implementation detail. From the endpoint1
point of view he sees something like:

Void RequestOperation(param1,param2,param3.., callback);

And what he know is sometime after the request is made he will receive a
callback with the result in it.

(there is  variant in which the callback is putting the result in a queue to
be processed by another such active object)

The real problem is that the entire thing is hidden inside.

We tried dividing the problem to the following tests:

1)      Test that a RequestOperation ends with an appropriate message in the
queue.

2)      Test that given a proper message in the queue is passed to the
correct logic handler

3)      Test that the logic handler "logic" is correct (i.e. result in the

(Continue reading)

headers

gutzofter | 4 May 2010 15:53

Re: how would you test Active Objects?

> At the end this kind of approach felt very artificial to many people and we
> are searching for improved solutions.

In what way?

--- In testdrivendevelopment <at> yahoogroups.com, "Lior Friedman" <lfriedmal <at> ...> wrote:
>
> Hi
> 
>  
> 
> I'm not sure I made myself clear enough.
> 
> The setup looks something like:
> 
> Endpoint1 -> queue -> logic handler -> callback.
> 
>  
> 
> The queue->handler is an internal implementation detail. From the endpoint1
> point of view he sees something like:
> 
>  
> 
> Void RequestOperation(param1,param2,param3.., callback);
> 
> And what he know is sometime after the request is made he will receive a
> callback with the result in it.
> 
> (there is  variant in which the callback is putting the result in a queue to

(Continue reading)

headers

Lior Friedman | 4 May 2010 16:40

Re: Re: how would you test Active Objects?

They felt that they are looking to deeply into the inner working of the
class/unit/component.
they wanted a more "black-box" approach in which they only test the incoming
requests and the resulting "output"

Lior

On Tue, May 4, 2010 at 4:53 PM, gutzofter <gutzofter <at> yahoo.com> wrote:

>
>
> > At the end this kind of approach felt very artificial to many people and
> we
> > are searching for improved solutions.
>
> In what way?
>
>
>

[Non-text portions of this message have been removed]

------------------------------------

Yahoo! Groups Links

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

<*> Your email settings:

(Continue reading)

headers

gutzofter | 4 May 2010 18:39

Re: how would you test Active Objects?

I'm confused then, a more black box approach test then is more of an integration test. Setup inputs then
validate outputs. It seems they want this while also with the problem of the asynchronous aspect of the
queue and handler logic. Am I not correct? I mean that when it comes down to it the endpoint doesn't whether
its async or sync.

Well all I can say then is something has to give. You need to test your endpoints either with the queue or mock/fake/stub.

IMHO, if I don't own the code or it is heavily resourced (file, db, http, asynchronous), then I want to put
those services behind some type of facade. Then inject that facade into my code. That way when testing my
code I can test against the facade and not against the actual service.

You might want to look at 'Working Effectively With legacy Code'. http://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052

 In testdrivendevelopment <at> yahoogroups.com, Lior Friedman <lfriedmal <at> ...> wrote:
>
> They felt that they are looking to deeply into the inner working of the
> class/unit/component.
> they wanted a more "black-box" approach in which they only test the incoming
> requests and the resulting "output"
> 
> Lior
> 
> 
> On Tue, May 4, 2010 at 4:53 PM, gutzofter <gutzofter <at> ...> wrote:
> 
> >
> >
> > > At the end this kind of approach felt very artificial to many people and
> > we
> > > are searching for improved solutions.

(Continue reading)