

Professionalism and TDD (Reprise) - ColinWright
http://blog.8thlight.com/uncle-bob/2014/05/02/ProfessionalismAndTDD.html

======
dozzie
TDD and tests in general seem today to be something to do _instead_ of good
architecture and code structure. Extensive tests are only good when the code
is complex and difficult. There may be some cases when this is how things must
be, but typically it means the code should be rewritten, not tests must be
added.

~~~
axanoeychron
A bad architecture and bad code structure can be achieved without TDD. I don't
think well thought out design precludes unit testing.

I don't think producing bad architecture/bad code structure is goal of TDD and
I suspect it's something to be thinking about regardless of whether you use
TDD. If you're having to contort your code or change it just to make a test
pass, that's probably a smell.

It just so happens that the SOLID principles (distinct from TDD) are
beneficial for TDD and you would probably consider those to create a 'good
architecture' and 'code structure'.

[http://en.wikipedia.org/wiki/SOLID_%28object-
oriented_design...](http://en.wikipedia.org/wiki/SOLID_%28object-
oriented_design%29)

~~~
dozzie
> A bad architecture and bad code structure can be achieved without TDD.

Of course. But TDD seems to be applied _instead_ of good architecture. The
latter is way, way more important than some tests.

> I don't think well thought out design precludes unit testing.

It doesn't, but the latter is often applied without the former, resulting in
claims "it has many tests, so it must be good code".

~~~
axanoeychron
In that example I agree with you.

I've seen my fair share of bad design with good test coverage. Then I have
also seen my fair share of good architectures with no test coverage.

When I see a good architecture with effective testing - that's just
awesomeness. I think this is something to endeavour for. I'm not sure how you
solve the problem of developers creating bad architectures with heavy test
coverage but I don't think pure abandonment of TDD is necessarily the answer
(for the alternative which is bad code with no coverage). I do not subscribe
to the reasoning that Tests immediately cause a bad design - they definitely
influence it but they are not the primary cause.

~~~
dozzie
> I do not subscribe to the reasoning that Tests immediately cause a bad
> design

Me neither. But tests are given much, much more attention than they are worth.
Tests mainly make up for lack of clean structure and good tooling for static
analysis. Strong static typing is worth attention. Static analysers and code
proof assistants are worth attention. Simple design that make whole class of
errors _impossible_ is worth it. Tests are not worth that much in this
neighbourhood.

Having plenty of tests is OK when the code base is fragile _and_ it's not
clear how to make it robust. Tests are a tool of last resort, if all thinking
fails to produce something bug-resistant.

