Title: P2: Object-Oriented Design and Mocking TDD nil

you design objects like big isolated containers, this slow down
refactoring which require 1) to split code actively to more specific
parts 2) collect them again in better ones.

Tests as additional dependency, coupled with code.

Conclusion: balance, balance, balance.

Links:
- Test-Driven Development paper "Mock Roles, Not Objects" by Steve Freeman, Nat Pryce, Tim Mackinnon, Joe Walnes. #dailyreport #progrmming #OOP #TTD #mockobject

Title: P1: Object-Oriented Design and Mocking TDD nil

5) Be explicit about things that should not happen. Not only that save() happened BUT also that delete() did not.
6) Percentage of coverage should be balanced
Pros of tests:

Writing tests provides a framework to think about functionality, not state.

Amplifies problems such as tight coupling. It is motivator for improving the design

Cons of test: #dailyreport #progrmming #OOP #TTD #mockobject

Title: P0: Object-Oriented Design and Mocking TDD nil

1) Dont use getters or "Tell, Don't Ask."
- Instead of if (account.getBalance() > 100), you write account.debitIfAffordable(100).
2) dont do mock.getA().getB().doSomething()
3) You should almost always mock an Interface, not a concrete Class
4) You shouldn't mock third-party libraries #dailyreport #progrmming #OOP #TTD #mockobject

What's a good name for a #testdouble that collects the data written to it and then allows that data to be queried?

It doesn't feel like a #mockobject, because I'm not tracking interactions per se. And it's not really a shunt. And it does more than a fake or stub might do.

Does this pattern have a "standard" name?