by Kevlin Henney

www.artima.com/weblogs/viewpost.jsp?thread=340839

(my emphasis)

Summary
What can you learn from testing? When you look beyond the red and the green, the fail and the pass, you can learn a lot more about the nature of the code and the nature of the problem domain. And there is a lot to learn — software development is called knowledge work for a reason.

….
deeper truth becomes visible: knowledge work is about knowledge. It’s about knowing stuff and, most often, also about how you deal with stuff you don’t know.

….
curiosity is key to how we address a lack of knowledge. Questions are the agents of curiosity. Even without answers, questions can help us to increase and refine our knowledge, to learn.

….
Software testing is a form of learning. …. A test allows us to move from belief to knowledge

….
the first part of any feedback-based process is generating the feedback; what you do with it becomes the next challenge

….
learning opportunities are available from … the formulation [of testing] rather than the execution of tests.

….
The reality is that some things just are harder to code and test no matter how you write the code or the tests. When complexity was being handed out, not all applications and domains of interest were created equal.

on accidental complexity:

in principle, avoidable. This is the realm of technical debt, baroque frameworks and rococo architectures. It’s where speculative generality has come home to roost, copy-and-paste code has blossomed and coupling has weighed anchor. This is where the observation “if your code is difficult to test, it means your code is messy” may often apply.