开云体育

Note that the context here is not greenfield TDD but bringing existing code that starts entirely without tests into testing and refactoring along the way initially via characterization tests etc. The

Wow, that’s depressing. For me, this is a major portion of the disconnect: I had to read that multiple times and read on to make sure that he was actually saying what it sounded as though he was

I think this difficulty is more or less the driving motivation behind Justin Searls' London-style approach to TDD. Here's a choice quote:

I can see how those paragraphs can be ambiguous. I didn't originally read them the way you are reading them now. As for the tests dictating the design. I think this is where most people get stuck.

Quite possibly. I'd trace this back to the article, with a couple of paragraphs quoted by way of example:

Note that if you're using automated refactoring tools, they will refactor the test code and the application code at the same time. It's a big win to think of editing in terms of concepts instead of

I think there is a distinction between testing behavior vs testing implementation and testing the end user experience / acceptance tests that is getting muddled here.

Sure, it wasn't my intention to claim either that the tradeoffs are entirely due to mocks, or that mocks aren't a good way of isolating a test subject from its dependencies. Sorry if I was unclear.

I very much agree about the tradeoffs. I disagree about attributing all the tradeoffs to mocks. Sometimes mocks are the most expedient way to purely unit test an object in isolation from the objects

So the biggest difference between the two schools of TDD I mentioned is in their use of mock objects, but there's broad agreement that mocks act as an impediment to some refactorings. People who use

Some quotes from Kent Beck. I call them "unit-tests," but they don't match the accepted definition of unit test very well. -- Kent Beck, Test Driven Development by Example (2003) Structure-invariant

I think my response would be somewhat similar to that of the comments. (FYI, to make the comments visible click the link that says "25 responses" below the article.) For starters, it's worthwhile

Huh, I'm curious why others can't see the comments. I don't have a Medium account as well. I wonder if it's because I got the link through AMP. brought to you by the letters A, V, and I and the number

Weak - yes. Didn't see comments either, but this line made me wonder about the author grasp of the big picture: "By the third round, we developers simply throw our hands up towards testing our code

Reposting the main comment which got the most likes. "You’re arguing against what would classically be described as unit tests (without ever actually using that term) while arguing in favor of

Comments not visible to me. I do not subscribe to Medium (and do not plan to). Maybe that's why the comments didn't show up. Good general advice: never read your reviews, never read the comments.

I just came across this blog post. The title is click bait. Overall I think the blog post is good and accurate. However, the comments scare me. What are your

Having developed a couple of CQRS event sourced systems, I found TDD to be a perfect companion. The Given ( events[] ) When( command() ) Then ( resultingEvents[] / resultingState ) pattern lends

Thanks for the correction, and sorry for not crediting Kent Beck. I like the point Jeff made, by refactoring your code you can also try different solutions "to find the one that seems most

A few months ago, I used TDD to learn some Kotlin basics. While I could make Green code, I needed help with the Refactor step. It came in two forms: ? The IDE itself offered suggestions. ?