开云体育

ctrl + shift + ? for shortcuts
© 2025 Groups.io
  1. Testdrivendevelopment
  2. Messages
Expanded Topics Messages Polls
Date
Re: [TDD] Howto mock a final object that doesn't offer an interface?

 

Stefan,

On 1/23/13 10:43 AM, sh wrote:
Hi Tim,

Am 23.01.2013 16:07, schrieb Tim Ottinger:
TDD is constantly about modifying the code to fit the tests, since

the test comes first and the code is written to satisfy it. I don't
understand the objection here.
that maybe a misunderstanding because of my english.
The objection I wanted to express is: I don't want to introduce
(production-)code that only exists to be able to test something. As an
ugly example:

// bad:
class Renderer {
public function render( graphics : Graphics, ?testGraphics :
MockGraphics = null ) {
if ( testGraphics != null ) {
graphics = testGraphics;
}
graphics.drawSomething();
}
}

That is what I meant by "code that fits the test".
I would /not/ write production code (particularly alternate flows like this) for testability.

I /would/ modify the structure of the code for testability. This includes introducing an interface.


One could argue that an adapter like a GraphicsView is a more elegant,
but similar artificial construct, that is only introduced to be able to
test the real object. Since I just started, I wanted to know, how this
is handled by experienced TDD-practitioners.

But I followed your suggestions, wrote a thin Adapter/Wrapper and that
works very nice for now!
Glad it's working.

- George

--
----------------------------------------------------------------------
* George Dinwiddie *
Software Development
Consultant and Coach
----------------------------------------------------------------------
Re: [TDD] Howto mock a final object that doesn't offer an interface?

 

It's the tests that have "driven" you to introduce the indirection, so your
argument may be that you've introduced it "just for the test", but what
you've actually done is decoupled the main body of your code from the
specific implementation (something adobe in this case?). I would say this
is nearly always a good thing irrespective of the tests getting you there
or not.

This is one of the things that got me test infected many years ago - I
found the code I ended up producing was so much more flexible and less tied
to infrastructure than it would've been previously.

One could argue that an adapter like a GraphicsView is a more elegant,
but similar artificial construct, that is only introduced to be able to
test the real object. Since I just started, I wanted to know, how this
is handled by experienced TDD-practitioners.
Re: [TDD] Howto mock a final object that doesn't offer an interface?

 

Ah. I get it.

The way most of us handle it is to not worry about it too much.

James Grenning talks about all the electronics in your car that are only
there to allow diagnostics. He suggests it is no less a proper car for
having them in there, and in fact it improves the car-owner's experience
even though most car owners never use the diagnostic capabilities directly.

I think that's fair enough.

On Wed, Jan 23, 2013 at 9:43 AM, sh <shvfn@...> wrote:

Hi Tim,

Am 23.01.2013 16:07, schrieb Tim Ottinger:
TDD is constantly about modifying the code to fit the tests, since

the test comes first and the code is written to satisfy it. I don't
understand the objection here.
that maybe a misunderstanding because of my english.
The objection I wanted to express is: I don't want to introduce
(production-)code that only exists to be able to test something. As an
ugly example:

// bad:
class Renderer {
public function render( graphics : Graphics, ?testGraphics :
MockGraphics = null ) {
if ( testGraphics != null ) {
graphics = testGraphics;
}
graphics.drawSomething();
}
}

That is what I meant by "code that fits the test".

One could argue that an adapter like a GraphicsView is a more elegant,
but similar artificial construct, that is only introduced to be able to
test the real object. Since I just started, I wanted to know, how this
is handled by experienced TDD-practitioners.

But I followed your suggestions, wrote a thin Adapter/Wrapper and that
works very nice for now!

Thanks!






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

Yahoo! Groups Links



--
Tim Ottinger, Sr. Consultant, Industrial Logic
-------------------------------------
Re: [TDD] Howto mock a final object that doesn't offer an interface?

 

On Wed, Jan 23, 2013 at 8:43 AM, sh <shvfn@...> wrote:

**


One could argue that an adapter like a GraphicsView is a more elegant,
but similar artificial construct, that is only introduced to be able to
test the real object.
You are *not* testing the rendering object (real or adapted). You are
TDDing *your* code that calls that object.

If an adapter facilitates TDDing your own code, then what is the downside?

What is the upside of making that adaptor more "elegant"?
Re: [TDD] Howto mock a final object that doesn't offer an interface?

sh
 

Hi Tim,

Am 23.01.2013 16:07, schrieb Tim Ottinger:
TDD is constantly about modifying the code to fit the tests, since

the test comes first and the code is written to satisfy it. I don't
understand the objection here.
that maybe a misunderstanding because of my english.
The objection I wanted to express is: I don't want to introduce
(production-)code that only exists to be able to test something. As an
ugly example:

// bad:
class Renderer {
public function render( graphics : Graphics, ?testGraphics :
MockGraphics = null ) {
if ( testGraphics != null ) {
graphics = testGraphics;
}
graphics.drawSomething();
}
}

That is what I meant by "code that fits the test".

One could argue that an adapter like a GraphicsView is a more elegant,
but similar artificial construct, that is only introduced to be able to
test the real object. Since I just started, I wanted to know, how this
is handled by experienced TDD-practitioners.

But I followed your suggestions, wrote a thin Adapter/Wrapper and that
works very nice for now!

Thanks!
Re: [TDD] Howto mock a final object that doesn't offer an interface?

 

On Wed, Jan 23, 2013 at 7:47 AM, sh <shvfn@...> wrote:

but I don't see a way to do this now
without modifying the code to fit the tests
TDD is constantly about modifying the code to fit the tests, since
the test comes first and the code is written to satisfy it. I don't
understand the objection here.

But +1 on everyone else's suggestion that you build an adapter
for 3rd party stuff. I keep seeing posts and tweets about people who
waited too long to do so, and others about people who have them
pay off faster than they expected.

It's a harder call with locally-produced components.

Best of luck.

--
Tim Ottinger, Sr. Consultant, Industrial Logic
-------------------------------------
Re: [TDD] Howto mock a final object that doesn't offer an interface?

 

Stefan,

On 1/23/13 8:47 AM, sh wrote:
Hello everybody,

I need a little help again. The question is: How do you test 3rd party
objects, that are declared final and do not implement any interface to
work on?
I generally use the adapter pattern to isolate my code from such a dependency. On my side of the adapter, I express the API in terms that are most convenient for my code, and do translation in the adapter. For TDD, I use a fake adapter. I also write integration tests for the real adapter talking to the real dependency. These I run much less frequently.

- George


Background: Yesterday I started the testdriven approach for a small
game. I have to get used to this process, it's a little bumpy and slow,
but I really appreciate the green bar after refactoring something. Very
enjoyable. :)

Now I want to render a very simple shape to the screen. By "rendering" I
mean - for now - drawing 2D-vertices with an AS3 Graphics object:


I need to call some draw-methods on this object (moveTo( x, y ),
drawLine( x, y ), etc.).

This Graphics-thing is declared final, so I can't overwrite its' methods
with a mockObject and it offers no interface that I could implement for
a mockObject.
If I could use a mock, I could check which calls were made and which
arguments (vertices) were given, but I don't see a way to do this now
without modifying the code to fit the tests.

How would you approach this? Is there an approach to this? Or should
this not be tested?

Best,
Stefan
--
----------------------------------------------------------------------
* George Dinwiddie *
Software Development
Consultant and Coach
----------------------------------------------------------------------
Re: [TDD] Howto mock a final object that doesn't offer an interface?

sh
 

Hi Colin,

ok, so I should use a view-class as a wrapper for the Graphics object
and then mock the view?
I thought of this as making the code fit the test, but it's probably the
easiest way.
I'll try this.

Thank you!



Am 23.01.2013 14:53, schrieb Colin Vipurs:


My advice on this is always "don't do it". My second piece would be
"don't do it (unless you absolutely have to and have no other
choice)".

If you *can* use a the real object, use the real object. If you
can't, put an abstraction layer around the thing you think you want to
mock and make that layer as thin as possible and test it in another
way. In your situation I would probably be abstracting this class
behind a "view" kind-of object that *you* own. Test and mock against
that, and make it a simple delegate to the real version. You're going
to get the added benefit that changing your rendering technology
becomes a simple case of swapping out the view implementation.

On Wed, Jan 23, 2013 at 1:47 PM, sh shvfn@...
<mailto:shvfn%40yahoo.de>> wrote:
Hello everybody,

I need a little help again. The question is: How do you test 3rd party
objects, that are declared final and do not implement any interface to
work on?

Background: Yesterday I started the testdriven approach for a small
game. I have to get used to this process, it's a little bumpy and slow,
but I really appreciate the green bar after refactoring something. Very
enjoyable. :)

Now I want to render a very simple shape to the screen. By "rendering" I
mean - for now - drawing 2D-vertices with an AS3 Graphics object:


I need to call some draw-methods on this object (moveTo( x, y ),
drawLine( x, y ), etc.).

This Graphics-thing is declared final, so I can't overwrite its' methods
with a mockObject and it offers no interface that I could implement for
a mockObject.
If I could use a mock, I could check which calls were made and which
arguments (vertices) were given, but I don't see a way to do this now
without modifying the code to fit the tests.

How would you approach this? Is there an approach to this? Or should
this not be tested?

Best,
Stefan



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

Yahoo! Groups Links


--
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] Howto mock a final object that doesn't offer an interface?

 

My advice on this is always "don't do it". My second piece would be
"don't do it (unless you absolutely have to and have no other
choice)".

If you *can* use a the real object, use the real object. If you
can't, put an abstraction layer around the thing you think you want to
mock and make that layer as thin as possible and test it in another
way. In your situation I would probably be abstracting this class
behind a "view" kind-of object that *you* own. Test and mock against
that, and make it a simple delegate to the real version. You're going
to get the added benefit that changing your rendering technology
becomes a simple case of swapping out the view implementation.

On Wed, Jan 23, 2013 at 1:47 PM, sh <shvfn@...> wrote:
Hello everybody,

I need a little help again. The question is: How do you test 3rd party
objects, that are declared final and do not implement any interface to
work on?

Background: Yesterday I started the testdriven approach for a small
game. I have to get used to this process, it's a little bumpy and slow,
but I really appreciate the green bar after refactoring something. Very
enjoyable. :)

Now I want to render a very simple shape to the screen. By "rendering" I
mean - for now - drawing 2D-vertices with an AS3 Graphics object:


I need to call some draw-methods on this object (moveTo( x, y ),
drawLine( x, y ), etc.).

This Graphics-thing is declared final, so I can't overwrite its' methods
with a mockObject and it offers no interface that I could implement for
a mockObject.
If I could use a mock, I could check which calls were made and which
arguments (vertices) were given, but I don't see a way to do this now
without modifying the code to fit the tests.

How would you approach this? Is there an approach to this? Or should
this not be tested?

Best,
Stefan



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

Yahoo! Groups Links


--
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.
Howto mock a final object that doesn't offer an interface?

sh
 

Hello everybody,

I need a little help again. The question is: How do you test 3rd party objects, that are declared final and do not implement any interface to work on?

Background: Yesterday I started the testdriven approach for a small game. I have to get used to this process, it's a little bumpy and slow, but I really appreciate the green bar after refactoring something. Very enjoyable. :)

Now I want to render a very simple shape to the screen. By "rendering" I mean - for now - drawing 2D-vertices with an AS3 Graphics object:


I need to call some draw-methods on this object (moveTo( x, y ), drawLine( x, y ), etc.).

This Graphics-thing is declared final, so I can't overwrite its' methods with a mockObject and it offers no interface that I could implement for a mockObject.
If I could use a mock, I could check which calls were made and which arguments (vertices) were given, but I don't see a way to do this now without modifying the code to fit the tests.

How would you approach this? Is there an approach to this? Or should this not be tested?

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

 

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

For me, the most amazing points of TDD are:

1. the code can run at any time;

2. after the code running, the correction of the code is known automatically;

3. every time the code is modified, I can know if the modification OK immediately.

About these points, I think the first one is the most amazing one.

TDD without preconceptions is something like nature selection. TDD with preconceptions is something like artificial selection. Both can reach the target.

-------------------------------------------------------------------------------------------------------------------------------------
链偖浠跺强鍏堕檮浠跺惈链夋涩宸炲崕涓夐赌氢俊鎶赌链湁闄愬叕鍙哥殑淇濆瘑淇℃伅锛屼粎闄愪簬鍙戦赌佺粰涓婇溃鍦板潃涓垪鍑�
鐨勪釜浜烘垨缇ょ粍銆傜姝换浣曞叾浠栦汉浠ヤ换浣曞舰寮忎娇鐢纸鍖呮嫭浣嗕笉闄愪簬鍏ㄩ儴鎴栭儴鍒嗗湴娉勯湶銆佸鍒躲赌�
鎴栨暎鍙戯级链偖浠朵腑鐨勪俊鎭赌傚鏋沧偍閿欐敹浜嗘湰閭欢锛岃镇ㄧ珛鍗崇数璇濇垨閭欢閫氱煡鍙戜欢浜哄苟鍒犻櫎链�
閭欢锛�
This e-mail and its attachments contain confidential information from H3C, which is
intended only for the person or entity whose address is listed above. Any use of the
information contained herein in any way (including, but not limited to, total or partial
disclosure, reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender
by phone or email immediately and delete it!
Re: [TDD] Does TDD ask me to 'forget' all I know about software design?

sh
 

Esko,
that looks like a great tutorial to get going. I also read your
article about "three styles of naming tests". Very good read. I
realized, that I am used to implementation-style naming and -thinking
and I guess, that is also the reason, why I had such a hard time finding
the initial behaviours for my game-project. Instead of thinking about
something like "player ship should accelerate when the 'forward-key' is
pressed" I started with "Engine should initialize Renderer on startup".
That's quite a different 'story'. :)
Somehow I automatically think about several different classes/systems,
when I think about coding "move a tetris-block". I start to understand
now, that I have to forget this to get going.


Matteo,
thanks for explaining your approach! That's really helpful.



Ron, Bill and Avi,
thank you for the links and articles! I'm slowly digesting the different
inputs and views you all offered to me and that is definitely helping to
get a better understanding.
It seems, it's not a bad idea to start TDD with a game. Now I need to
practice! :)


Best,
Stefan






Am 21.01.2013 23:51, schrieb Esko Luontola:


For Tetris I've done this:


I first focused on getting 1x1 blocks falling, then moved to rotating
multi-block shapes, and merged those together to get falling multi-block
shapes. And it's in a tutorial form, so that others can follow the same
steps to learn TDD.

Angel Java Lopez wrote on 21.1.2013 23:40:
Ummm.. for Tetris, I could write tests (one by one) to:

- Give me an empty "board"
- Put a Piece X at position x,y, get its position
- Put a Piece X at position x,y, run a cycle, get its new position
- Put a Piece Y at position x1,y1, Put Piece X at positions ... all
invalids because they are on Y
- Put a Piece Y at position x1,y1, touching floor, put Piece X
above, next
cycle, Y and X are in the same position
- etc...
--
Esko Luontola
www.orfjackal.net
Re: [TDD] Does TDD ask me to 'forget' all I know about software design?

 

I just saw this blog entry today, and I think it might help you understand
and answer your questions. It might also help you get past your mental
block (which I believe we all have had at one point or another)



brought to you by the letters A, V, and I
and the number 47


On Tue, Jan 22, 2013 at 3:18 PM, Bill Wake <william.wake@...> wrote:

**


On Mon, Jan 21, 2013 at 3:06 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?

I'm not Matteo, but you usually have a number of choices. Joseph Leddy,
Kent Beck, & I wrote this article, "Slicing Functionality: Alternate Paths"
to talk about exploring some of them:


Different approaches can lead you toward different solutions to the same
overall problem.

--Bill


--
Bill Wake
Industrial Logic, Inc. @IndustrialLogic
Coaching | Training | Assessment | eLearning





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

Bill Wake
 

On Mon, Jan 21, 2013 at 3:06 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?

I'm not Matteo, but you usually have a number of choices. Joseph Leddy,
Kent Beck, & I wrote this article, "Slicing Functionality: Alternate Paths"
to talk about exploring some of them:


Different approaches can lead you toward different solutions to the same
overall problem.

--Bill

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

 

On Tue, Jan 22, 2013 at 1:39 PM, Matteo Vaccari <vaccari@...> wrote:



On Mon, Jan 21, 2013 at 9:06 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?
Well, for instance in Tetris you could list a few simple behaviours:

- a block falls
- a block stops when it hits the bottom
- a block stops when it hits another block
- the player can rotate the block
- the player can slide the block left or right
- ...

Then you choose one and write a test for it.
Sometimes the test you choose turns out to be too difficult... in the sense
that it takes more than a few minutes to make it pass. This is where the
fun begins :) you can comment the current test and try to write a smaller
test that you hope will make it easier to pass the original one. You can
try to see the behaviour as a composition of simpler behaviours. You can
try to simplify the problem by making it more general.

There is a great example in the TDD book by Kent Beck. He says (quoting
from memory) "when I have to implement a TCP server, I start by writing a
test for a server that echoes whatever you send to it [and this is the
simplification part]. Then I extract the part that reads a string and
returns the same string in an object. Now the TCP server uses that object
to decide what to answer." So now he can continue to TDD the logic of the
server in a plain object that does not know about sockets. The problem has
been generalized *and* made simpler at the same time :-)

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

 

On Mon, Jan 21, 2013 at 9:06 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?
Well, for instance in Tetris you could list a few simple behaviours:

- a block falls
- a block stops when it hits the bottom
- a block stops when it hits another block
- the player can rotate the block
- the player can slide the block left or right
- ...

Then you choose one and write a test for it.

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

 

For Tetris I've done this:

I first focused on getting 1x1 blocks falling, then moved to rotating multi-block shapes, and merged those together to get falling multi-block shapes. And it's in a tutorial form, so that others can follow the same steps to learn TDD.


Angel Java Lopez wrote on 21.1.2013 23:40:

Ummm.. for Tetris, I could write tests (one by one) to:

- Give me an empty "board"
- Put a Piece X at position x,y, get its position
- Put a Piece X at position x,y, run a cycle, get its new position
- Put a Piece Y at position x1,y1, Put Piece X at positions ... all
invalids because they are on Y
- Put a Piece Y at position x1,y1, touching floor, put Piece X above, next
cycle, Y and X are in the same position
- etc...
--
Esko Luontola
www.orfjackal.net
Re: [TDD] Does TDD ask me to 'forget' all I know about software design?

sh
 

Avi,
ok, I see. So you would start with something more "practical" than the
concept of class Engine?
This is something I noticed when I read about behaviour driven
development, that I had problems to define a "behaviour" of my game. I
could have immediately started coding the usual bunch of classes, but to
sit in front of an empty file and think about a "behaviour" to start
with... wasn't exactly easy. :)
I guess that's part of my learning curve.
Thank you!



Angel & Ron,
thanks for the examples! That's a good reference for me (see above :) ).


Corey,
the book is on my list now! Thanks!



Bill,
I like you're idea of testing the "stress point".
I guess, I simply have to "do TDD", gain more experience and be open to
what the tests tell me...



Charlie,
the "programming propeller" is a nice image... :)
And "tension" describes my initial feeling towards TDD quite good. On
the one hand I'm fascinated by the idea of an "emerging design" that is
always secured by tests; on the other hand my brain is simply not
convinced, that this will work out. I am really surprised, how hard it
is for me to let these thoughts rest aside.
Thank you for describing your mindset, very helpful.



Thank you all for the nice welcome!
:)






Am 21.01.2013 21:50, schrieb Avi Kessner:


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@...
<mailto:shvfn%40yahoo.de>> 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@... <mailto:daverooneyca%40gmail.com>>
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@... <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




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

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

 

Hi �

On Jan 21, 2013, at 3:06 PM, sh <shvfn@...> wrote:

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

For a look at one what man is trying see the Codea articles on my web site. I'm not very far along yet, but they'll show you the way I'm thinking at the beginning. Questions welcome, they'll help me figure out what to do and say next.

Ron Jeffries
www.XProgramming.com
It's true hard work never killed anybody, but I figure, why take the chance?
-- Ronald Reagan





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

 

Ummm.. for Tetris, I could write tests (one by one) to:

- Give me an empty "board"
- Put a Piece X at position x,y, get its position
- Put a Piece X at position x,y, run a cycle, get its new position
- Put a Piece Y at position x1,y1, Put Piece X at positions ... all
invalids because they are on Y
- Put a Piece Y at position x1,y1, touching floor, put Piece X above, next
cycle, Y and X are in the same position
- etc...

It's not full TDD, but many test on a simple isometric engine JavaScript

(I skipped the test at browser side, I should learn how to do them, maybe
using QUnit or Jazmine?)
See the commits, I usually commit test (one by one))

A full TDD sample, chess, see the commit


Angel "Java" Lopez
@ajlopez
github:ajlopez

On Mon, Jan 21, 2013 at 5:06 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
1081 - 1100 of 36280