开云体育

JB, I'm quite surprised by your second claim, that "One can learn design skill by practising TDD". Can you support that? K

I am surprised to encounter so many people who claim something like this: "You must understand how to design before you can practise TDD well." I say the following in response: - Practising TDD

test/behaviour test doesn't work, but I'm not sure what's the "sensible" way to separate them yet like fast/slow/io/non-io? business/technical?structure vs behaviour? I'm curious about this, because

I'd like to build on this in addition to echoing it. Everyone, feel invited to join in. I'm asking everyone and not only George. Which freedoms? Why do you care? What do those freedoms give you? I

Hi there ? A recent article I found quite interesting is the one by Roberto Ostinelli: he made a very insightful experiment using AI as a pair programming companion:

Hi Tony, I'm 100% with you on the things you like. When I don't do TDD (see below) I get very very uncomfortable WRT my code. This comment made me think... test/behaviour test doesn't work, That's

All XP practices need to exit from the comfort zone, they need courage and, If you are brave enough, the reward is high. I started practicing TDD in 2004 – 2005. Back then, there was the false idea

TDD is the only process I know that helps me, personally, deal with otherwise crushing perfectionism and anxiety. The fact that Red->Green means I can do whatever I want, ugly or not, messy or not,

Tony raises some interesting points. It does seem to me that people have different ideas about these issues. My own preference is a simple division: “pure” unit tests that only simulate I/O and

I'm posting this for the benefit of those who follow the group via the online groups.io interface rather than as a mailing list as some of us do.... or is it just me? :-) Groups.io makes it look like

Things I don't like about TDD: - I think the test name separation by unit test/integration test/micro test/behaviour test doesn't work, but I'm not sure what's the "sensible" way to separate them

Like others: it removes the fear, helps me think about design, and makes change easier (more like: a little less hard). I also enjoy that code under test is code that has been used in two slightly

I'll second what George said. I also find it very gratifying--joyful even--to be able to whittle code into something elegant yet direct. Regarding teaching it, it's extremely rewarding seeing people

Once upon a time, I cared about TDD. In fact, I moved from being a frontend game developer towards more server side and business applications, in part so that I could take advantage of TDD. I tried

I care about it because: It helps me work in small steps, and small steps help me go faster. It gives me confidence in my code, so I am less tense and enjoy the work more. I feel sure that I make

"That's what TDD is, you know. It's not just test cases and assertions and a suite and a test runner. That's what TDD needs. But what TDD is... is freedom." --

Because it is refactoring-as-design. I can refactor immediately instead of waiting until the whole feature works, then adding enough tests that I can afford to do some refactoring late in the process,

I still care - for others. It seems to work well. Why not for myself? 95% chance I'll be retired within 3 months. -- 73 de KG2V Charles Gallo http://www.kg2v.com

Joe, There are a lot of aspects I could mention, but it basically comes down to the fact that TDD made my software development joyful. The worrisome aspects were out of my head and into test code.

I have a few small applications published in Apple’s AppStore for iOS that are written entirely in Swift, and I used TDD from the very beginning to develop those applications. I tried to get my code