TDD vs Defensive Programming -

uncle bob says:

"defensive programming, in non-public apis, smell, , symptom, of teams don't tdd."

i wondering how tdd can avoid (internal) function used in unintended way? think tdd can´t avoid it. merely shows function used correctly because calling function covered it´s passing unit tests.

when developing new feature using (undefensive) function feature developed tdd. unintended use of function fail new features tests.

so using tdd drive new features force correcty use (internal) functions.

do think meant uncle bob´s tweet?

so using tdd drive new features force correctly use (internal) functions.

exactly. keep in mind subtle "gap" here: should use tdd write (unit) tests test contract of public methods. not care implementation of these methods - internal implementation detail.

therefore: if "new" code uses existing method in unintended way "told" because exception thrown or receive unexpected result.

that mean "gap": see, above describes black box testing approach. have public method x, , verify public contract. compare white box testing write tests cover paths taken within x. when doing that, notice: "ok test 1 condition in internal method, have drive special data".

but said - think should go black box testing - white box tests might break when refactoring internal methods.

and there additional dimension here: keep in mind ideally change code in order implement new features. means adding new features takes place writing new classes , methods. means new code has no chance using private internal methods. because within new class. in other words: when regularly happen run situations internal methods used in many different ways - doing wrong.

the ideal path is: implement new requirement creating set of new classes. later on, have add other requirements - writing more classes.

in ideal path - there no need defensive programming within internal methods. because understand each use case such internal methods!

thus, conclusion is: avoid defensive programming in internal methods. make sure public apis check pre-conditions, fail (as fast possible) if there problem. try avoid these internal consistency checks - tend bloat code - , rest assured: in 5 weeks or 5 months not remember if needed check, or if "defensive".

wiki