开云体育

ctrl + shift + ? for shortcuts
© 2025 Groups.io
  1. Testdrivendevelopment
  2. Messages
Expanded Topics Messages Polls
Date
Re: [TDD] Does TDD ask me to 'forget' all I know about software design?

 

On Mon, Jan 21, 2013 at 11:47 AM, sh <shvfn@...> wrote:

Dear Listables,

What are your experiences regarding the evolutional aspect of TDD when
it comes to systems?
And how do you handle your own preconceptions about software design?

I highly recommend Josh Kerievsky's "Refactoring to Patterns" as it talks a
lot about this aspect. I consider that book one of the jewels of the TDD
literature.

-Corey
Re: [TDD] Does TDD ask me to 'forget' all I know about software design?

Bill Wake
 

I like Hill & Charlie's answers...

I figure when I have a pre-conceived idea for the design, it's because at
least some situations have pressures that make the "known" designs a good
idea.

When I have a theory about a pressure existing, I'll choose a test in that
area and see if it reveals the stress point I think exists (and would be
solved by my design idea). (Sometimes I'll find the design idea isn't worth
it, other times it is.)

It pays to be sensitive to the refactoring step, using it to create the
needed concepts/objects/functions/whatevers.

What I think all this does is let the generality I really need emerge, and
leave the rest in reserve should it be needed in the future.

It's not to say I've never just added a class I thought would be needed,
but I think the emergence is interesting to watch & see what drives it. One
of the things I really like about Kent Beck's TDD book is his use of the
basic "currency" example, but he ended up with a different solution than
what he'd usually created.

--Bill Wake

On Mon, Jan 21, 2013 at 12:47 PM, sh <shvfn@...> wrote:

Dear Listables,

first post here. I hope, this hasn't been asked a thousand times... :)

TL,DR first:
What are your experiences regarding the evolutional aspect of TDD when
it comes to systems?
And how do you handle your own preconceptions about software design?
[...]

Since I already coded several small games/experiments I have certain
ideas about how a game engine should be structured.
For example I expect to end up with
- an engine class,
- a scene or context
- a renderer,
- an event- or signal/slot-system,
- an entity/component system
- etc, etc.

--
Bill Wake
Industrial Logic, Inc. @IndustrialLogic
Coaching | Training | Assessment | eLearning
Re: [TDD] Does TDD ask me to 'forget' all I know about software design?

 

I'm not Matteo but I would either first test a score, or for tetris a line
match, or for pong the angle of a bounce.

On Jan 21, 2013 10:44 PM, "sh" <shvfn@...> wrote:

Matteo,

hm, I'm not sure I understand. When you imagine a simple game (Pong,
Tetris), what behaviour/class would you choose?



Michael,

thank you for this insight from your coders life.
Perhaps I do worry to much. I question the method before even starting.
OK, I'll try!



Colin, Dave, Josue,

I'll try to get a copy. "Growing" software sounds a lot like the aspect
I am interested in.
Thanks for the recommendation!







Am 21.01.2013 20:28, schrieb Josue Barbosa dos Santos:
+1


On Mon, Jan 21, 2013 at 5:27 PM, Dave Rooney <daverooneyca@...>
wrote:

**


+1

Dave...


On 13-01-21 2:20 PM, Colin Vipurs wrote:
I can heartily recommend reading "Growing Object Oriented Software:
Guided
by Tests". (

).
It walks you through the entire process, and unlike alot of literature
doesn't shy away from some of the more "hairy" problems. The entire
book
is pretty much an answer to your question

On Mon, Jan 21, 2013 at 6:05 PM, Matteo Vaccari vaccari@...
wrote:
**


On Mon, Jan 21, 2013 at 6:47 PM, sh shvfn@...
wrote:

Dear Listables,

...
For example I expect to end up with
- an engine class,
- a scene or context
- a renderer,
- an event- or signal/slot-system,
- an entity/component system
- etc, etc.

When I now start to write my first tests, I guess I start with the
engine class.
... I would not start with that. I would more likely start with the
test
of a simple behaviour of the completed system. Then I'd build just as
little as possible to make the test pass.

Matteo




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

Yahoo! Groups Links
Re: [TDD] Does TDD ask me to 'forget' all I know about software design?

 

Hi Stefan,

Welcome!

After Mike, there's little else to say but why would I let that stop me? :-)

This may be a bit too philosophical for some people, but I think the
tension you describe
between your preconceptions and TDD is a big part of what makes it work.

I've never started a project without preconceptions, either before I
did TDD or now that
I do it. Having preconceptions is normal and they are sometimes even
useful. TDD does
not rule out preconceptions.

TDD _does_ tell us "Don't act on your preconceptions without first
writing a test."

So, when I start an application, especially in a domain where I've
done work before, it's
very likely that I have some ideas about the eventual structure of the
application. I'm
not wrong at that stage and I can still do TDD.

But when I say "Since I know the eventual structure, I'll set it up
right away" I have
left the world of TDD and substituted a guess for actual knowledge.
Fact is, I _don't_
'know' the eventual structure - I merely have a good, educated guess
about what it
will be. And some percentage of the time, my initial guess won't end
up being the
best way to do it.

So, as I program (i.e. write tests and make them pass) I hold in my
mind the ideas
that I started out with and constantly compare the emerging program
with those ideas.
Inevitably, the ideas change as the program develops. Just as software
is easier to
change than hardware, ideas in my brain should be easier to change
than software.
If they aren't, it's good exercise to try changing them a bit more.

I think of this tension between "what I think I'll end up doing" and
the emerging
program as the twisted-up rubber band that turns my programming propeller. To
keep that tension working for me, I don't want to drop my initial
ideas, but merely
to set them to one side for a while until they either come true or don't.

Charlie

On Mon, Jan 21, 2013 at 9:47 AM, sh <shvfn@...> wrote:
Dear Listables,

first post here. I hope, this hasn't been asked a thousand times... :)

TL,DR first:
What are your experiences regarding the evolutional aspect of TDD when
it comes to systems?
And how do you handle your own preconceptions about software design?

Fulltext:
Since I have some time at hand I want to develop a small game-engine in
Haxe as a hobby project.
I want to use a TDD approach, but I have some questions.

Since I already coded several small games/experiments I have certain
ideas about how a game engine should be structured.
For example I expect to end up with
- an engine class,
- a scene or context
- a renderer,
- an event- or signal/slot-system,
- an entity/component system
- etc, etc.

When I now start to write my first tests, I guess I start with the
engine class. At some point I will introduce vertices and a
render()-method, because I want to draw meshes to the screen.

When it comes to that, how would you approach this task in a test driven
way?

Do you say to yourself "Hey, it will end up like that anyway, I
introduce a new class named Renderer and write the next tests for this
class."?
Or do you take the next smallest step and add a method "renderVertices"
to the engine class and refactor it out to a renderer, when the "rule"
says so? (in this case separation of concerns?)

Same thing for events or messages: I expect I will need a dispatcher and
an interface for objects to register themselves as listeners to certain
events. Do you try to "forget" such expectations when using TDD?

When and how do you decide to introduce a new system?
Do you always do it because "the tests say so" or because you know you
need it?
Does something like an eventSystem with listeners/dispatchers really
"evolve" by just adding the right tests and refactoring?

So:
What are your experiences regarding the evolutional aspect of TDD?
Should I just trust the method?
And how do you handle your own preconceptions about software design?

Best,
Stefan



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

Yahoo! Groups Links
Re: [TDD] Does TDD ask me to 'forget' all I know about software design?

 

The short answer is that yes, you do the next smallest step. I'm always
amazed how nice it is when I completely 'follow the rules' the process
exists cause its useful and works.
On Jan 21, 2013 9:28 PM, "Josue Barbosa dos Santos" <josuesantos@...>
wrote:

+1


On Mon, Jan 21, 2013 at 5:27 PM, Dave Rooney <daverooneyca@...>
wrote:

**


+1

Dave...


On 13-01-21 2:20 PM, Colin Vipurs wrote:

I can heartily recommend reading "Growing Object Oriented Software:
Guided
by Tests". (

).
It walks you through the entire process, and unlike alot of literature
doesn't shy away from some of the more "hairy" problems. The entire
book
is pretty much an answer to your question

On Mon, Jan 21, 2013 at 6:05 PM, Matteo Vaccari vaccari@...
wrote:
**


On Mon, Jan 21, 2013 at 6:47 PM, sh shvfn@...
wrote:

Dear Listables,

...
For example I expect to end up with
- an engine class,
- a scene or context
- a renderer,
- an event- or signal/slot-system,
- an entity/component system
- etc, etc.

When I now start to write my first tests, I guess I start with the
engine class.
... I would not start with that. I would more likely start with the
test
of a simple behaviour of the completed system. Then I'd build just as
little as possible to make the test pass.

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




--
础产谤补莽辞蝉,
闯辞蝉耻茅







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

Yahoo! Groups Links
Re: [TDD] Does TDD ask me to 'forget' all I know about software design?

sh
 

Matteo,

hm, I'm not sure I understand. When you imagine a simple game (Pong, Tetris), what behaviour/class would you choose?



Michael,

thank you for this insight from your coders life.
Perhaps I do worry to much. I question the method before even starting.
OK, I'll try!



Colin, Dave, Josue,

I'll try to get a copy. "Growing" software sounds a lot like the aspect I am interested in.
Thanks for the recommendation!







Am 21.01.2013 20:28, schrieb Josue Barbosa dos Santos:

+1


On Mon, Jan 21, 2013 at 5:27 PM, Dave Rooney <daverooneyca@...> wrote:

**


+1

Dave...


On 13-01-21 2:20 PM, Colin Vipurs wrote:
I can heartily recommend reading "Growing Object Oriented Software:
Guided
by Tests". (

).
It walks you through the entire process, and unlike alot of literature
doesn't shy away from some of the more "hairy" problems. The entire book
is pretty much an answer to your question

On Mon, Jan 21, 2013 at 6:05 PM, Matteo Vaccari vaccari@...
wrote:
**


On Mon, Jan 21, 2013 at 6:47 PM, sh shvfn@...
wrote:

Dear Listables,

...
For example I expect to end up with
- an engine class,
- a scene or context
- a renderer,
- an event- or signal/slot-system,
- an entity/component system
- etc, etc.

When I now start to write my first tests, I guess I start with the
engine class.
... I would not start with that. I would more likely start with the
test
of a simple behaviour of the completed system. Then I'd build just as
little as possible to make the test pass.

Matteo
Re: [TDD] Does TDD ask me to 'forget' all I know about software design?

 

+1


On Mon, Jan 21, 2013 at 5:27 PM, Dave Rooney <daverooneyca@...> wrote:

**


+1

Dave...


On 13-01-21 2:20 PM, Colin Vipurs wrote:

I can heartily recommend reading "Growing Object Oriented Software:
Guided
by Tests". (

).
It walks you through the entire process, and unlike alot of literature
doesn't shy away from some of the more "hairy" problems. The entire book
is pretty much an answer to your question

On Mon, Jan 21, 2013 at 6:05 PM, Matteo Vaccari vaccari@...
wrote:
**


On Mon, Jan 21, 2013 at 6:47 PM, sh shvfn@...
wrote:

Dear Listables,

...
For example I expect to end up with
- an engine class,
- a scene or context
- a renderer,
- an event- or signal/slot-system,
- an entity/component system
- etc, etc.

When I now start to write my first tests, I guess I start with the
engine class.
... I would not start with that. I would more likely start with the
test
of a simple behaviour of the completed system. Then I'd build just as
little as possible to make the test pass.

Matteo





--
础产谤补鏾蝉,
闯辞蝉耻�



[Non-text portions of this message have been removed]
Re: [TDD] Does TDD ask me to 'forget' all I know about software design?

 

+1

Dave...

On 13-01-21 2:20 PM, Colin Vipurs wrote:

I can heartily recommend reading "Growing Object Oriented Software: Guided
by Tests". (
).
It walks you through the entire process, and unlike alot of literature
doesn't shy away from some of the more "hairy" problems. The entire book
is pretty much an answer to your question

On Mon, Jan 21, 2013 at 6:05 PM, Matteo Vaccari vaccari@...
<mailto:vaccari%40pobox.com>> wrote:

**


On Mon, Jan 21, 2013 at 6:47 PM, sh shvfn@...
<mailto:shvfn%40yahoo.de>> wrote:

Dear Listables,

...
For example I expect to end up with
- an engine class,
- a scene or context
- a renderer,
- an event- or signal/slot-system,
- an entity/component system
- etc, etc.

When I now start to write my first tests, I guess I start with the
engine class.
... I would not start with that. I would more likely start with the test
of a simple behaviour of the completed system. Then I'd build just as
little as possible to make the test pass.

Matteo
Re: [TDD] Does TDD ask me to 'forget' all I know about software design?

 

I can heartily recommend reading "Growing Object Oriented Software: Guided
by Tests". (
).
It walks you through the entire process, and unlike alot of literature
doesn't shy away from some of the more "hairy" problems. The entire book
is pretty much an answer to your question

On Mon, Jan 21, 2013 at 6:05 PM, Matteo Vaccari <vaccari@...> wrote:

**


On Mon, Jan 21, 2013 at 6:47 PM, sh shvfn@...> wrote:

Dear Listables,

...
For example I expect to end up with
- an engine class,
- a scene or context
- a renderer,
- an event- or signal/slot-system,
- an entity/component system
- etc, etc.

When I now start to write my first tests, I guess I start with the
engine class.
... I would not start with that. I would more likely start with the test
of a simple behaviour of the completed system. Then I'd build just as
little as possible to make the test pass.

Matteo

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




--
Maybe she awoke to see the roommate's boyfriend swinging from the
chandelier wearing a boar's head.

Something which you, I, and everyone else would call "Tuesday", of course.
Re: [TDD] Does TDD ask me to 'forget' all I know about software design?

Michael Hill
 

Stefan...

TL;DR: Don't sweat it either way, start with your pre-TDD notion, pass a
test, and refactor until you can't stand it anymore, and it will work out.

For me, starting with TDD-as-I-grasped-it-then, I simply did not worry
about evolution OR my preconceptions.

With evolution, I assumed that just meant that I'd make my app better as
time went by. Certainly I had had some experience with iterative
approaches, and iterations were a lot like what I understood as design
evolution.

As for preconceptions, I'd say I was blithely unaware that anything like my
preconceptions even existed, except as an abstraction. That is, I regarded
my mental stance about things like what method goes where and how classes
should interact as hard-earned geek skill, not even conceivably in
collision with strong design, rather mostly just making up my definition of
strong design!

As my TDD chops got better, the steps I took got smaller and smaller,
including the refactorings. By focusing so "micro" in my work, I began to
create classes I'd never really met before. It sounds trivial, but I never
created many "verb" classes before, like, say, a LineCleaner, or a
WebWrapper. In fact, I had some sense that classes whose names ended with
-er were "bad", altho they worked pretty well.

My preconceptions bothered me, so I began to push well-factored code into
the kinds of pre-TDD nouns (circled of course), that had been my wont
before TDD. And what I found was just unbelievable: the code got worse, not
better. Stuff I had labored painstakingly over, making my code tight,
clean, correct, and easy to grasp, became ugly and clearly wrong.

So i stopped worrying about it.

And though it sounds like I'm an aspiring mystic, I'd say my current
understanding is that I should make the code be the shape it wants to be
in.

For your case, then, my advice is this: don't even worry about those two
factors, the evolution and the preconception. Just refactor until you're
red in the face, every time. If, as I for one claim, the code will tell you
what it wants to be, over time you'll get an ear for that telling, and
you'll find yourself just getting stronger.

I routinely start code using my old ideas. For instance, some variation of
MVC in GUI apps. Then it's red-green-refactor-commit, and the real "right
code" emerges quicker than I ever imagined would happen.

Good luck with it!
Hill
Re: [TDD] Does TDD ask me to 'forget' all I know about software design?

 

On Mon, Jan 21, 2013 at 6:47 PM, sh <shvfn@...> wrote:

Dear Listables,

...
For example I expect to end up with
- an engine class,
- a scene or context
- a renderer,
- an event- or signal/slot-system,
- an entity/component system
- etc, etc.

When I now start to write my first tests, I guess I start with the
engine class.
... I would not start with that. I would more likely start with the test
of a simple behaviour of the completed system. Then I'd build just as
little as possible to make the test pass.

Matteo
Does TDD ask me to 'forget' all I know about software design?

sh
 

Dear Listables,

first post here. I hope, this hasn't been asked a thousand times... :)

TL,DR first:
What are your experiences regarding the evolutional aspect of TDD when it comes to systems?
And how do you handle your own preconceptions about software design?

Fulltext:
Since I have some time at hand I want to develop a small game-engine in Haxe as a hobby project.
I want to use a TDD approach, but I have some questions.

Since I already coded several small games/experiments I have certain ideas about how a game engine should be structured.
For example I expect to end up with
- an engine class,
- a scene or context
- a renderer,
- an event- or signal/slot-system,
- an entity/component system
- etc, etc.

When I now start to write my first tests, I guess I start with the engine class. At some point I will introduce vertices and a render()-method, because I want to draw meshes to the screen.

When it comes to that, how would you approach this task in a test driven way?

Do you say to yourself "Hey, it will end up like that anyway, I introduce a new class named Renderer and write the next tests for this class."?
Or do you take the next smallest step and add a method "renderVertices" to the engine class and refactor it out to a renderer, when the "rule" says so? (in this case separation of concerns?)

Same thing for events or messages: I expect I will need a dispatcher and an interface for objects to register themselves as listeners to certain events. Do you try to "forget" such expectations when using TDD?

When and how do you decide to introduce a new system?
Do you always do it because "the tests say so" or because you know you need it?
Does something like an eventSystem with listeners/dispatchers really "evolve" by just adding the right tests and refactoring?

So:
What are your experiences regarding the evolutional aspect of TDD? Should I just trust the method?
And how do you handle your own preconceptions about software design?

Best,
Stefan
Re: Arabic to Roman Numeral kata with commentary

Carlos Ble
 

Excellent screencast Corey! thanks for that :-)

My experience with this kind of complex-algorithms katas is that TDD is not
enough
to find the best solution. TDD helps when you already have the solution in
your head.
Then TDD and the TTP helps you write the minimun code to write the
algorithm you are thinking of.

Transforming "II" in "I" + convert(in_aragic -1) is an insightful idea, not
just emerging design.

So in these cases I try to do several spikes, use pencil and paper, think
hard, and then test drive
my solution towards the algorithm in my head. Because there is no obvious
triangulation.
This is the more effective way of solving the problem right for me.

Cheers ;-)


--
Carlos Ble
www.CarlosBle.com <> - @carlosble
Check out my book on TDD: www.dirigidoPorTests.com/el-libro
Try my latest app for team productivity: www.liveTeamApp.com
Need test doubles for python?: www.pyDoubles.org
(No subject)

 

(No subject)

 

Submission extension XP2013 Vienna: Call for Research and Experience Papers

 

Extended submission deadline: 25.1.2013

The 14th International Conference on Agile Software Development is a leading conference on agile methods in software and information systems development. XP2013 will be located in Vienna, Austria June 3-7. This conference brings together industrial practitioners and researchers in the fields of information systems and software development, and examines latest theory, practical applications, and implications of agile methods. For more information visit .

We allow submission as research papers as well as experience reports.

Research papers
===============
We are looking for original research, with implications for theory and practice. Motivation for research and discussion of the related work must be included, as well as a description of the research method applied. Full papers are limited to 15 pages and short papers to 8 pages.

Experience reports
==================
We are looking for experience reports sharing experiences about the business impact generated when introducing agile practices, and challenges to be overcome as well as horror stories on failures including lessons learned. Experience papers must be clearly marked as such so that they can be appropriately reviewed by the program committee. Concerning length and formatting, experience reports must follow the same rules and guidelines as research papers.

If you would like to receive help from an experienced agile researcher to shepherd you in developing a submission, please contact the PC chairs (research@...) by the time indicated in the important dates list.

Areas of interest
=================
We are inviting innovative and high quality research papers as well as experience reports related to agile software development. Topics of particular interest in the conference include, but are not restricted to, the following:

- Foundations and conceptual studies of and for agile methods
- Living examples of agility in all areas
- Current practices and future trends, agile evolution and revolution
- Empirical studies and experiences
- Experiments in software development and their relation to agile methods
- Implications for industrial practice
- Tools and techniques for agile development
- Social and human aspects including teams
- Forming agile organizations and its implications
- Management and governance aspects
- Measurement and metrics
- Global software development and offshoring
- Systems engineering and safety critical systems
- Software- and systems architecture
- Legacy systems
- Usability
- Using agile methods in education and research
- Teaching agile methods in particular in an university context

Presentation of accepted papers
===============================
Accepted papers will either be presented within the research track or as part of the main conference track-depending on whether the implications of the contribution are mainly related to theory and/or practice. Authors of papers that are selected for presentations in the main conference track will be assigned a mentor who will advise and assist in adapting the presentation to suit a mixed audience of practitioners and researchers.

Research Program Committee
==========================
Hubert Baumeister, Technical University of Denmark, Denmark (co-chair)
Barbara Weber, University of Innsbruck Austria (co-chair)

Muhammad Ali Babar, IT University of Copenhagen, Denmark
Robert Biddle, Carleton University, Canada
Luigi Buglione, Engineering.IT / ETS, Italy
Ivica Crnkovic, Mlardalen University, Sweden
Simon Cromarty, Red Gate Software, UK
Steven D. Fraser, Cisco Research, USA
Torgeir Dingsoyr, SINTEF ICT, Norway
Tore Dyb, SINTEF and Department of Informatic, University of Oslo, Norway Amr Elssamadisy, Gemba Systems, USA
Juan Garbajosa, Universidad Politecnica de Madrid / Technical University of Madrid, Spain
Alfredo Goldma, University of So Paulo, Brazil
Des Greer, Queens University Belfast, Ireland
Rashina Hoda, The University of Auckland, New Zealand
Kirsi Korhonen NSN, Finland
Pasi Kuvaja, University of Oulu, Finland
Stig Larsson, Effective Change AB, Sweden
Casper Lassenius, Aalto University, Finland
Lech Madeyski, Wroclaw University of Technology, Poland
Michele Marchesi, University of Cagliari, Italy
Grigori Melnik Microsoft, Canada
Alok Mishra, Atilim University, Turkey
Nils Brede Moe, SINTEF ICT, Norway
Ana Moreno, University Madrid, Spain
Oscar Nierstrasz, University of Bern, Switzerland
Maria Paasivaar, Helsinki University of Technology, Finland
Jennifer Perez, Technical University of Madrid, Spain
Kai Petersen, Blekinge Institute of Technology/Ericsson AB, Sweden
Adam Porter, University of Maryland, USA Outi Salo, Nokia, Finland
Helen Sharp, The Open University, UK
Alberto Sillitti, Free University of Bolzano, Italy
Darja Smite, Blekinge Institute of Technology, Sweden
Giancarlo Succi, Free University of Bolzano/Bozen, Italy
Marco Torchiano, Politecnico di Torino, Italy
Stefan Van Baelen, iMinds, Belgium
Xiaofeng Wang, Free University of Bozen-Bolzano, Italy
Hironori Washizaki, Waseda University, Japan
Werner Wild, EVOLUTION, Austria
Laurie Williams, North Carolina State University, USA
Agustin Yague, Universidad Politecnica de Madrid, Spain

Submission instructions
=======================
Papers should be submitted electronically as a self-contained PDF file using the EasyChair submission site: . Papers have to be written in English and formatted according to Springer's LNBIP format: . Papers not following the guidelines will be rejected.

Important Dates
===============
Deadline (extended): 25.1.2013
Feaddback to authors: 22.2.2013
Final version due: 8.3.2013
Conference: 3-7.6.2013

--
Hubert Baumeister
Associate Professor
Research program co-chair of XP2013 (research@...)
www.imm.dtu.dk/~hub
Re: [TDD] Sharable Examples of Good Testing

Mark Levison
 

The Apache Tika project turns out to be another good example of a Test
Driven Code base. I spent only an hour with it and already I have a fair
understanding. I will using as an example good code next week.

I gather (3rd hand) that its been worked on by about a dozen people since
it began.

Cheers
Mark


On Wed, Dec 19, 2012 at 5:51 AM, Esko Luontola <esko.luontola@...>wrote:

**


john_s_ryan wrote on 18.12.2012 16:56:

I'm looking for some examples of software programs that are good
examples of TDD in action. I want to be able to share them with anyone,
so they need to be publicly accessible.

Do you know of any open source projects that we can proudly hold up?
I'm publishing screencasts of implementing a couple of projects. There's
well over 100 hours of programming with 100% TDD:


Especially with the Jumi test runner project (), I'm
recording all implementation work since day one. (I didn't record
implementing my continuous delivery build pipeline, but I've written


about the end result.) Based on my own standards I'm very happy with
Jumi's quality. It's easier to avoid slipping to bad practices when you
know that someone is watching everything you do. ;-)

--
Esko Luontola
www.orfjackal.net




--
Cheers
Mark Levison
Agile Pain Relief Consulting <>
| Writing <>
Proud Sponsor of Agile Tour Gatineau Ottawa <> Nov
28, Toronto <>
26 and Montreal <> 24


[Non-text portions of this message have been removed]
Re: [TDD] Arabic to Roman Numeral kata with commentary

 

Hi Corey,



Thank you for sharing this. I played this kata months ago, but your kata is
quite inspiring to me and I see some improvements I can make. I can't wait
to replay it. J



Regarding the TTP part, I agree with you that the case "convert 5 to V" is a
simpler transformation than the case "convert 2 to II". But, if I first go
with the latter case, it won't impact the entire algorithm transformation.
In fact, I went with the case for convert 2 earlier than 5 (actually case
for 3 and 4 came after 2) and wasn't blocked by this. I haven't found a kata
like the word wrapper kata which will go into a trap if choosing a wrong
order according to TTP.



The most impressive part to me is your algorithm and how easy it is
implemented in Ruby. In my previous exercise, my algorithm is to convert for
each digit to roman number and combine them into one string. It's more
complex than yours. My feeling is that the algorithm itself is sometime more
related to your programming knowledge and skill but less related to whether
you implement it in TDD or not.



Anyway, I will play this kata again soon and try it with your algorithm. My
original kata is posted at
(in Java).



Merry Christmas and Happy new year,

Joseph



From: testdrivendevelopment@...
[mailto:testdrivendevelopment@...] On Behalf Of Corey Haines
Sent: Tuesday, December 18, 2012 9:21 PM
To: testdrivendevelopment
Subject: [TDD] Arabic to Roman Numeral kata with commentary





Hi, All,

I recently posted a katacast of the arabic to roman numeral conversion kata
with an audio commentary track over it. It is heavy TDD, plus uses bits of
the transformation priority premise.


ary.html

Would love to hear any feedback from the list.

Thanks!
-Corey Haines
Re: [TDD] Arabic to Roman Numeral kata with commentary

 

Thanks a lot, Alpar!


On Wed, Dec 19, 2012 at 3:06 AM, G醔os Alp醨 <jr_alpar@...> wrote:

**


Hi Corey,

Your katacast is fantastic, it shows the power of TDD(combined with TPP)
really well.

I'm really grateful for your contribution towards the IT craftsmanship!
Keep up the good work!

Br,
Alpar Gabos

________________________________
From: Corey Haines <coreyhaines@...>
To: testdrivendevelopment <testdrivendevelopment@...>
Sent: Tuesday, December 18, 2012 2:21 PM
Subject: [TDD] Arabic to Roman Numeral kata with commentary




Hi, All,

I recently posted a katacast of the arabic to roman numeral conversion kata
with an audio commentary track over it. It is heavy TDD, plus uses bits of
the transformation priority premise.




Would love to hear any feedback from the list.

Thanks!
-Corey Haines



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



[Non-text portions of this message have been removed]
Re: [TDD] Sharable Examples of Good Testing

 

john_s_ryan wrote on 18.12.2012 16:56:
I'm looking for some examples of software programs that are good
examples of TDD in action. I want to be able to share them with anyone,
so they need to be publicly accessible.

Do you know of any open source projects that we can proudly hold up?
I'm publishing screencasts of implementing a couple of projects. There's well over 100 hours of programming with 100% TDD:

Especially with the Jumi test runner project (), I'm recording all implementation work since day one. (I didn't record implementing my continuous delivery build pipeline, but I've written about the end result.) Based on my own standards I'm very happy with Jumi's quality. It's easier to avoid slipping to bad practices when you know that someone is watching everything you do. ;-)

--
Esko Luontola
www.orfjackal.net
1101 - 1120 of 36280