Notes from Jan 09, 2014 LIDNUG TDD, Where Did It All Go Wrong

Originally posted on: GWB in February 2014.

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).

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

fluent, with overrides Summary at 1:26

test the port (BAL?) not the adapter (DAL)