[Clam-devel] Typed Controls Tests

[Pau Arumí Albó]

El dc 30 de 04 del 2008 a les 11:21 -0300, en/na Hernán Ordiales va
escriure:
> On Tue, Apr 29, 2008 at 7:32 PM, Francisco Tufró <nictuku at gmail.com> wrote:
> > As explained on the Data Flow Patterns pdf sent to me by pau (and taking
> > some examples from the InPort.hxx and OutPort.hxx), i've been trying to
> > create the template classes TInControl<T> and TOutControl<T>.
> >  NOTICE: I have to say that the code i'm sending is not functional.
> > I have some problems that i'll describe here.
> >
> > 1) We have to do something with the remove link and related functions to
> > work. mLinks is not accessible from the TOutControl class (because is a
> > OutControl private member). right now i commented the mLinks occurencies
> > just to test it.
> >
> > 2) When trying to compile my test processing (TypedOutControl.hxx and cxx)
> > I get this error:
> >   TOutControl.hxx:84: error: cannot dynamic_cast 'in' (of type 'class
> > CLAM::InControl') to type 'struct CLAM::TInControl<int>' (target is not
> > pointer or reference)
> >  I don't get the key of why this is happening.
> >
> > If you think i'm going in a wrong direction on something please tell me.
> 
> We have to have care implementing typed controls, let me first
> introduce you a bit in test driven development (even we might ending
> writing test first and the actual code then) and proceed step by step
> (with smaller goals). BTW, if you don't have one already, i recommend
> you to work with at least two sandboxes, one more general and other
> only for implementing the typed controls feature.

Totally agree. TypedControls are not trivial at all. And are core
infrastructure, thus it needs unit-testing. Starting from a copy of
current (float)Controls doesn't seem a good idea -- I think we don't
even need all the implemented features like the callback-methods
associated to incontrols.

To give an example of smaller goals that Hernan mentioned when doing
TDD:
A test that connects two TypedIn/OutControl<int>, sends a 1 and checks
that it have reached the in control
Then choose the next simple goal for another test, and so on...

In TDD, you must put the simplest design that passes the test. In this
case base classes are not needed. Connection from a base class would be
a future test. 

BTW, the Ken Beck's TDD book is excellent. But there are many resources
in the web 
http://en.wikipedia.org/wiki/Test-driven_development


I think it's important to keep the TypedControls development separated
from the rest (even from MIDI) till its functionality is totally proved
and ready to integrate with processing base classe (and others maybe).
(From this perspective having separate sandboxes is not really
mandatory, but yes, can help for doing diffs and patches)


> PS: let's try to meet together with Pau at irc

Yes. Though this week will be difficult -- i plan to be off from
tomorrow.

Pau