J. B. Rainsberger writes on test-driven development, software design, and consulting for programmers.
Commenters recommend his "Integrated Tests Are a Scam" as a counterpoint on testing, and recommend him as a consultant and change agent.
A graphic I found very enlightening in the past year is here: http://blog.thecodewhisperer.com/images/age_old_battle/virtuous_cycle.png
from this blog post: http://blog.thecodewhisperer.com/2013/12/07/putting-an-age-old-battle-to-rest/
There's a lot of other good stuff there too, when you start digging through the archives.
Generally, I find that I've got to build a prototype first, which is quick and dirty and ugly, but works. Then iterate as the structure emerges. Some things stay in flux, and it's okay to leave them messier, but eventually the code and functionality settles out and commonality arises. Quite often, I don't necessarily know what I'm doing going in; I've got a general goal, but until I experiment a bit, the best way to get there is unclear.
One of the joys and pitfalls of a multi-paradigm language like C# is that there are so many different ways to skin a cat. You can pick and choose procedural, object-oriented, functional, or some bastard mishmash of all of the above and more.
> How did you go around to finding him?
If you're going to shop around for a change agent, I recommend reading Jerry Weinberg's "Secrets of Consulting"; although this is targeted at consultants rather than their clients, it can provide useful insight into how to create an effective working partnership with one.
Technical know-how doesn't by itself qualify someone to help you implement changes towards becoming more effective. It can be detrimental, in fact.
But someone with a solid grasp of the fundamentals AND a productive attitude to coaching/mentoring/consulting can be a great asset. One I recommend wholeheartedly is JB: http://blog.thecodewhisperer.com/ (and if you can't get him, try to find someone like him).
I think the point is something like "don't unit test the system as a whole". Black box testing is great and most definitely should be used, but should be kept very high level and unit tests should be kept very small and granular.
The author has several other articles on the subject that I have not read yet, so I'm not sure if I've got a full understanding of his point yet: http://blog.thecodewhisperer.com/blog/categories/integrated-tests-are-a-scam
I believe Microsoft's Pex [1] is an attempt to generate all the unit tests automatically. You can't do that with integration tests, because their number grows exponentially with the number of paths in the code [2].
[1] https://www.microsoft.com/en-us/research/project/pex-and-moles-isolation-and-white-box-unit-testing-for-net/
[2] http://blog.thecodewhisperer.com/permalink/integrated-tests-are-a-scam
> Technical know-how doesn't by itself qualify someone to help you implement changes towards becoming more effective. It can be detrimental, in fact.
Yeah I'm well-aware of that.
> One I recommend wholeheartedly is JB: http://blog.thecodewhisperer.com/ (and if you can't get him, try to find someone like him).
Thanks for the suggestion.
> Tests should mostly be integration, not unit.
Other people disagree: <https://blog.thecodewhisperer.com/series#beware-the-integrated-tests-scam-was-integrated-tests-are-a-scam>
In short (IIUC), integration tests do not give you any feedback on when your design needs to change, while unit tests do.