2008/5/19 Andreas Krügersen <
a.kruegersen@...>:
> Hi All,
>
> I've used TDD for some time now but rather in an inside-out fashion, i.e.
instead
> of thinking about user stories encompassing the whole application first, I
used
> TDD to drive small parts. For example I knew "I need that component A now" and
> then wrote tests for it before implementing it.
>
> Now I'd like to start with an outside-in design (i.e. story-based) since my
previous approaches
> proved to be unsatisfying in the long run. But I find it really hard to come
up with the first
> test to get things rolling.
>
> The situation is as follows:
> I'd like to write an application for a mobile device (with Java ME for all of
you who have
> worked with it yet) that renders a certain animation. That is, it should just
have a canvas
> and keep drawing the animation forever.
> As a general design decision, I want to use the Presenter-First technique
> (
http://www.atomicobject.com/pages/Presenter+First) for the whole application.
>
> So I spent some thoughts on this and I finally came up with the idea that I
should
> have a test like "When the next frame is drawn, the view uses the current
coordinates
> stored in the model to draw the outline of the animation". In
presenter-first-speech this
> would result in a model storing coordinates for my animation, a view
representing the
> canvas and a presenter connecting both the view and the model. Thus, the test
would
> be written for the presenter.
>
> But then I realized that this is already "inside" of the application and not
the outside.
> An outside test would probably be something like "When the application starts,
the canvas
> is shown empty". Yet I don't really have a clear picture in my mind of how the
whole thing
> should evolve from there.
>
> I still find it very difficult to think in "application-wide stories" rather
than in
> "component- or class-wide stories". It's much easier to think of how a
specific class fits into an
> existing picture than defining the frame for the whole application with a
single test.
> What do you think how I should start driving this application? What should I
use as the first test and how
> should I go on? For me, the first test in outside-in design to get started is
really the hardest
> part about TDD. Perhaps some of you have experienced similar problems?
>
From my viewpoint, this is TDD done the BDD way. I'm trying to learn
the BDD practice in C#/NUnit. I've been using TDD the way you describe
(bottom-up) for 2 years now, and it's been mostly a _great_
experience. The thing that bothers me most with "classic TDD" is that
sometimes I build too much functionality in my classes, which isn't
used in the end application after all. Even whole objects are wasted
in the worst case.
So I'm going through the same thing, my play-app is a simple console
app: GenTODO.exe. It's supposed to generate an HTML report from
scanning *.cs files searching for // TODO-comments. I find it hard to
go past the first test:
----------------
interface ILister { void List(string path, string pattern); } // recursive!
interface IWriter { void Write(string path, string content); }
public void should_create_report_file() {
string scanPath = "somepath";
DynamicMock lister = Mock(typeof<ILister>);
lister.ExpectAndReturn("List", new string[]{"file1.cs", "file2.cs"},
scanPath, "*.cs");
lister.ExpectAndReturn("Load", "// TODO: implement this function",
"file1.cs");
lister.ExpectAndReturn("Load", "", "file2.cs");
DynamicMock writer = Mock(typeof<IWriter>);
writer.Expect("Write", "Report.html",
"<html><h1>file1.cs</h1><ul><li>Row 1: // TODO: implement this
function</li></ul></html>");
Generator generator = new Generator(lister, writer);
generator.ProduceReport(scanPath, "Report.html");
lister.Verify();
writer.Verity();
}
----------------
Both the ILister and IWriter interfaces will have "system border
implementations" -- direct I/O methods, so they're not really
candidates for further development (well I need them sooner or later,
but they're not candidates for BDDing). I do need some
source-code-analyzing-object, should it be injected too, or an
internal dependency (an implementation detail of generator)? In case I
injected it, it would be a candidate for further development. But the
feeling I get if I inject that dependency too, is "what is stopping my
generator from injecting every single dependency, all the way down to
the smallest class?".
/Olof
> regards
> Andreas Krügersen
>
> _______________________________________________________________________
> EINE FÜR ALLE: die kostenlose WEB.DE-Plattform für Freunde und Deine
> Homepage mit eigenem Namen. Jetzt starten!
http://unddu.de/?kid=kid@mf2
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>
Having problems with message search?
Fill out this form to ensure your group is one of the first to be migrated to the new message search system.
Send Email
