The idea is that as part of writing the ticket, you write the tests that you'll use to determine its completion. Since this is "writing tests first", is that a form of TDD? (View Highlight)
My response to the question above is that tests written before the code as part of the ticket are acceptance tests. These are different from TDD, which produces unit tests. (View Highlight)
This is an indication that the tests are testing internal implementation details, not behavior. That means they have violated the cardinal rule I mentioned above. (View Highlight)
It can be useful to temporarily add some tests that delve into internals until you get things worked out, but then remove them. (View Highlight)
"What behavior will we need to produce the revised report? Put another way, what set of tests, when passed, will demonstrate the presence of code we are confident will compute the report correctly?" (View Highlight)
"When we write a test, we imagine the perfect interface for our operation. We are telling ourselves a story about how the operation will look from the outside. Our story won't always come true, but it's better to start from the best-possible application program interface (API) and work backward than to make things complicated, ugly, and "realistic" from the get-go." (View Highlight)
If the interface for a method is at all unclear, you write a test before you write the method. (View Highlight)
"The customers write tests story-by-story." These are the acceptance tests. The customers rely on testers to automate the acceptance tests. (View Highlight)
"The question they need to ask themselves is, "What would have to be checked before I would be confident that this story was done?" Each scenario they come up with turns into a test, in this case a functional test." (View Highlight)
"The developers integrate those tests into the continuous build. Those tests become the Definition of Done for the stories in the iteration. A story is not specified until its acceptance test is written (Martin means the story has not reached the fully-specified state until the test is written). A story is not complete until its acceptance test passes." (View Highlight)
Do not write any production code until you have first written a test that fails due to the lack of that code. (View Highlight)
Do not write more of a test than is sufficient to fail - and failing to compile counts as a failure. (View Highlight)
Do not write more production code than is sufficient to pass the currently failing test. (View Highlight)
"The idea here is that writing code that works and writing code that is clean are two separate dimensions of programming. Attempting to control both dimensions at the same time is difficult at best, so we separate the two dimensions into two different activities." (View Highlight)
In section 1.3, "Physics of TDD," he says that the typical Debug Later Programming (DLP) style results in lots of waste, due to the late feedback. (View Highlight)
