Originally posted on: http://geekswithblogs.net/Aligned/archive/2014/02/10/notes-from-jan-09-2014-lidnug-tdd-where-did-it.aspx
I recently was asked by a co-worker to watch Ian Cooper talk about TDD to give my take on Mr. Cooper’s presentation on TDD. Here’s what I sent back and decided to share it with all of you as well.
He's got a lot of experience and laid out things are often stated as things against TDD. He even mentions SpecFlow and problems he had with that. This turns out to validate some of my ideas on BDD. Interesting talk about refactoring too (write code quick, then refactor and write clean code).
I'd suggest that people watch this. It expands on what I've been presenting (at work). I learned a lot from it.
TDD book by Kent Beck.
The Zen of TDD (minutes 16 and on):
- Avoid testing implementation details (methods and classes), test behaviors
- trigger is implementing a requirement (to test)
- Test outside in, not necessarily UI, but API, use cases, scenarios
- Don't test things that are only internal
Sounds a lot like BDD. Dan North is mentioned, he wrote the first article about BDD.
MSpec, Specflow
What is a unit test? minute 23
- 'runs in isolation'
- fast
- could be multiple classes to test the behavior
The simplest thing:
Get it to pass as quickly as you can. Only write the code you need to get the test to pass
Design doesn't matter right away, then refactor (I wonder about that...)
Refactoring is when we produce clean code (min 34)
- apply patterns
- remove duplication
- sanitize code smells
- no new tests here
Fowler refactoring book, not breaking tests or implementation
- 4 new classes, none have new tests at this point
Can't do refactoring when testing implementation details (so then, my tests I've written that ShouldHaveBeenCalled might not always be the way to test... Jason was saying this yesterday)
Integration tests needed because we've lost confidence in our tests? (min 40)
"Dependency is the key problem in software development at all scales" Kent Beck
Eliminate dependency between tests and code:
- tests should depend on contracts or
public interfaces - don't bake implementation into tests!
- test behaviors, not implementations
min 47
Design Patterns of TDD from Kent Beck
Ice Cream cone anti-pattern
Testing Pyramid
- rely on unit tests, not manual test cases, unit tests should be the bulk
- manual test what the unit tests can't cover
- have to trust tests
min 54 domain model diagram, walk through with use cases
- "adapter layer"
- test where the public behavior is exposed
I skipped some here..
Acceptance TDD (1:08)
- benefit/value from discipline of generating the acceptance criteria
- then have those tests in the unit tests
- tests should be comprehensible... someone could look at it and make sense of it
Conversations that it prompts are important (I agree, it's helped here at Daktronics).
Mocks (1:12)
- Tell, don't ask
- Remove hard to test dependencies
- Your repository, things you own
- Don't mock every dependency in a constructor
- No IoC inside the domain model...???
"Object Mother" (1:23) - coded mock object, becomes bloated
Test Builder pattern
Summary at 1:26
test the port (BAL?) not the adapter (DAL)
CodeProject 
