Gojko Adzic | 3 Aug 02:44 2009

tdd as if you meant it - revisited

We repeated Keith Braithwaite's TDD as if you meant it exercise
(mentioned several times before on this list) at the alt.net openspace
conference on saturday. If you were interested in the original one,
you'll probably find a write-up of the repeated exercise interesting as
well, so here goes:

http://gojko.net/2009/08/02/tdd-as-if-you-meant-it-revisited/

also, there was a follow-up open-space discussion. links and books
mentioned during the discussion are listed on

http://gojko.net/2009/08/02/links-from-the-tdd-discussion-at-alt-net-uk/

--
gojko adzic
http://gojko.net

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

Yahoo! Groups Links

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

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/testdrivendevelopment/join
    (Yahoo! ID required)
(Continue reading)

Joseph Gutierrez | 3 Aug 07:19 2009
Picon

Re: why is Presenter First better for TDD?

You might want to check this out.
<http://www.udidahan.com/page/2/?blog=true>

--- In testdrivendevelopment <at> yahoogroups.com, Rob Park
<robert.d.park <at> ...> wrote:
>
> Or wasn't reading carefully enough ;)
> Do you have any examples of what you mean WRT replacing the presenter
with
> lambas?
>
> On Thu, Jul 30, 2009 at 8:58 PM, Joseph Gutierrez gutzofter <at> ...wrote:
>
> >
> >
> >  <at> Rob,
> >
> > Hmmm... I guess I wasn't clear enough...
> >
> >
> > > > The idea behind using a When declaration is that it specifically
allows
> > > > you to write only the code you need to. If you start TDDing with
the
> > > > presenter part of the triad, then it will allow you to develop
the
> > > > interfaces for the domain and view. When you no longer have any
more
> > > > whens then 'done is done'.
> >
(Continue reading)

Alan Baljeu | 3 Aug 16:26 2009
Picon

Re: Re: why is Presenter First better for TDD?

I don't see anything there pertaining to presenter, lambdas MVP, or TDD.  What do you want us to see?

 Alan Baljeu

________________________________
From: Joseph Gutierrez <gutzofter <at> yahoo.com>
To: testdrivendevelopment <at> yahoogroups.com
Sent: Monday, August 3, 2009 1:19:42 AM
Subject: [TDD] Re: why is Presenter First better for TDD?

  
You might want to check this out.
<http://www.udidahan .com/page/ 2/?blog=true>

--- In testdrivendevelopme nt <at> yahoogroups. com, Rob Park
<robert.d.park <at>  ...> wrote:
>
> Or wasn't reading carefully enough ;)
> Do you have any examples of what you mean WRT replacing the presenter
with
> lambas?
>
> On Thu, Jul 30, 2009 at 8:58 PM, Joseph Gutierrez gutzofter <at> .. .wrote:
>
> >
> >
> >  <at> Rob,
> >
> > Hmmm... I guess I wasn't clear enough...
> >
(Continue reading)

Joseph Gutierrez | 4 Aug 08:46 2009
Picon

Re: why is Presenter First better for TDD?

 <at> alan,

To the best of my knowledge the storage of handlers is Actions.

I've spiked a system <http://www.box.net/shared/gq1nbxahgi>  .

Check out IntegrationClosureTester in the Tests directory.

Also of note is the separation of the publisher into a controller,
instead of in the view.

Currently the publish/subscribe is one-to-one. I'm currently working to
use an event aggregator to get a one-to-many.

This is a first-effort so any criticism would be appreciated!

Some other areas that need looking into would be Extension Methods.

--- In testdrivendevelopment <at> yahoogroups.com, Alan Baljeu
<alanbaljeu <at> ...> wrote:
>
> I don't see anything there pertaining to presenter, lambdas MVP, or
TDD.  What do you want us to see?
>
>  Alan Baljeu
>
>
>
>
>
(Continue reading)

Alan Baljeu | 4 Aug 16:44 2009
Picon

Re: Re: why is Presenter First better for TDD?

Looking at IntegrationClosureTester, it seems to me your lambdas can become somewhat complex, at which
point I'm inclined to convert them into named methods.  Do tell if there's a reason not to go there.

So then these named methods ought to go somewhere and that somewhere ought to be a presenter class.  

That's just my inclination of how to refactor complexity.

 Alan Baljeu

________________________________
From: Joseph Gutierrez <gutzofter <at> yahoo.com>
To: testdrivendevelopment <at> yahoogroups.com
Sent: Tuesday, August 4, 2009 2:46:31 AM
Subject: [TDD] Re: why is Presenter First better for TDD?

  
 <at> alan,

To the best of my knowledge the storage of handlers is Actions.

I've spiked a system <http://www.box. net/shared/ gq1nbxahgi>  .

Check out IntegrationClosureT ester in the Tests directory.

Also of note is the separation of the publisher into a controller,
instead of in the view.

Currently the publish/subscribe is one-to-one. I'm currently working to
use an event aggregator to get a one-to-many.

(Continue reading)

Joseph Gutierrez | 4 Aug 17:45 2009
Picon

Re: why is Presenter First better for TDD?

 <at> alan,

It is still a hammer is it not?

The presenter abstraction is still there? Just not matured enough.

--- In testdrivendevelopment <at> yahoogroups.com, Alan Baljeu
<alanbaljeu <at> ...> wrote:
>
> Looking at IntegrationClosureTester, it seems to me your lambdas can
become somewhat complex, at which point I'm inclined to convert them
into named methods.  Do tell if there's a reason not to go there.
>
> So then these named methods ought to go somewhere and that somewhere
ought to be a presenter class.
>
> That's just my inclination of how to refactor complexity.
>
>  Alan Baljeu
>
>
>

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

Yahoo! Groups Links

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

(Continue reading)

Alan Baljeu | 4 Aug 18:02 2009
Picon

Re: Re: why is Presenter First better for TDD?

Joseph, you need to explain yourself better.  I have no idea what you are getting at.

What are you aiming to achieve, and what benefit will come from this technique?  

One thing I notice about your code, which may be accomplishing something new:
 You are passing methods into  your handlers so that your handlers are abstracted.
This appears to be in place of another pattern which uses Event and Delegate 
technology.  I'm not sure if there is something practically different here, or if it's just
a different style of hammer doing exactly the same thing.

 Alan Baljeu

________________________________
From: Joseph Gutierrez <gutzofter <at> yahoo.com>
To: testdrivendevelopment <at> yahoogroups.com
Sent: Tuesday, August 4, 2009 11:45:29 AM
Subject: [TDD] Re: why is Presenter First better for TDD?

  
 <at> alan,

It is still a hammer is it not?

The presenter abstraction is still there? Just not matured enough.

--- In testdrivendevelopme nt <at> yahoogroups. com, Alan Baljeu
<alanbaljeu <at>  ...> wrote:
>
> Looking at IntegrationClosureT ester, it seems to me your lambdas can
become somewhat complex, at which point I'm inclined to convert them
(Continue reading)

Tron Thomas | 4 Aug 23:05 2009
Picon
Picon

TDD for audio development

I need to implement rendering of audio in the Ogg format using C++.

I would like to apply Test Driven Development to this implementation, 
only given the nature of the work it seems this might be tricky.

What tools and techniques exist that would allow me to apply TDD to as 
much of the implementation as possible?

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

Yahoo! Groups Links

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

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/testdrivendevelopment/join
    (Yahoo! ID required)

<*> To change settings via email:
    mailto:testdrivendevelopment-digest <at> yahoogroups.com 
    mailto:testdrivendevelopment-fullfeatured <at> yahoogroups.com

<*> To unsubscribe from this group, send an email to:
    testdrivendevelopment-unsubscribe <at> yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
(Continue reading)

Donaldson, John (GEO | 5 Aug 09:47 2009
Picon

RE: TDD for audio development

Tron,

I'm guessing that you are wondering about this because the only way to know if you've done it correctly is to
listen to it? Everything up to the rendering is normal TDD. But how to know if you've done it correctly.

There are some people on this list who are working close to audio devices, and there are some who worry about
the actual pixels they display. The pixel guys sometimes use a technique called "gold-standard" - take
something which you know to be good, and compare it to your output. 

Of course you will need some kind of acceptance/customer test at the end in addition. And you may be able to
automate some part of that. Do you know how anyone will know if you have done a good job?

John D. 

-----Original Message-----
From: testdrivendevelopment <at> yahoogroups.com [mailto:testdrivendevelopment <at> yahoogroups.com] On
Behalf Of Tron Thomas
Sent: 04 August 2009 23:06
To: testdrivendevelopment <at> yahoogroups.com
Subject: [TDD] TDD for audio development

I need to implement rendering of audio in the Ogg format using C++.

I would like to apply Test Driven Development to this implementation, 
only given the nature of the work it seems this might be tricky.

What tools and techniques exist that would allow me to apply TDD to as 
much of the implementation as possible?

------------------------------------
(Continue reading)

Olof Bjarnason | 5 Aug 15:18 2009
Picon

Re: TDD for audio development

2009/8/4 Tron Thomas <tron.thomas <at> verizon.net>:
>
>
> I need to implement rendering of audio in the Ogg format using C++.
>
> I would like to apply Test Driven Development to this implementation,
> only given the nature of the work it seems this might be tricky.
>
> What tools and techniques exist that would allow me to apply TDD to as
> much of the implementation as possible?

TDDing the "inner workings" or "unit tests" of this software should be
a breeze, since there's lots of mathematics involved, and functions
are one of the most basic and simple things to unit test:

assertAlmostEqual(expectedValueAtPointA, computeValueAtPointA)

Regarding system-level tests, or regression tests, you may want to
develop a "similarity measure" that has the ability to make
audio-similary testing possible.

Now regression tests are not as valueable as unit tests, that is my
opinion, but both are valuable.

Anyway, about the regression testing algorithm: the algorithm should
be able to compare two .ogg files for similarity.
One idea:
1. Convert both .ogg files to some kind of raw format, say 16-bit
integers in a long row
2. Loop through both computing the "sum of differences", per channel
(Continue reading)


Gmane