开云体育

Stefan, I would /not/ write production code (particularly alternate flows like this) for testability. I /would/ modify the structure of the code for tes

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

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

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

Hi Tim, Am 23.01.2013 16:07, schrieb Tim Ottinger: 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

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

Stefan, 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

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

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

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

>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?

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

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

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:

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

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

For Tetris I've done this: https://github.com/orfjackal/tdd-tetris-tutorial I first focused on getting 1x1 blocks falling, then moved to rotating multi-block shapes, and merged those together to get

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

Hi � 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

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