Kevlin Henney, Curbralan, UKKevlin Henney is an independent consultant and trainer based in Bristol, UK. He has variously developed and delivered training courses, consultancy and software across a number of domains ever since getting involved in professional software development in the late 1980s. His work focuses on software architecture and patterns, programming languages and techniques, and development process and practices.
Kevlin is and has been a columnist for various magazines and online publications, including Better Software, SearchSoftwareQuality.com, The Register, Java Report and C++ Report. He is coauthor of A Pattern Language for Distributed Computing and On Patterns and Pattern Languages, two volumes in the Pattern-Oriented Software Architecture Series.
Know Your UnitsThese days testing is considered sexy for programmers. Who'd have thought it? But there is a lot more to effective programmer testing than the fashionable adoption of a unit-testing framework: effective unit testing involves (a lot) more than knowledge of assertion syntax.
Testing represents a form of communication and, as such, it offers multiple levels and forms of feedback, not just basic defect detection. Effective unit testing requires an understanding of what forms of feedback and communication are offered by tests, and what styles encourage or discourage such qualities. Unit testing can highlight coupling problems, functional defects, problematic programming practices, awkward programmatic interfaces, overly procedural objects, overly object-like procedures, unclear requirements, poor integration culture, development process problems and so on. However, not everyone appreciates that problems with unit testing tend to be a consequence of these deeper problems, and so they aim to fix or criticise symptoms rather than root causes, thereby missing a valuable opportunity for improvement and learning.
While there is certainly more to testing than unit testing, and more to a well-rounded approach to development than just testing, a failure to appreciate the role and practice of unit testing can lead to disappointment or a skewed notion of testing as a programmer's responsibility. This session aims to look at some issues, examples and counterexamples that help to highlight some of the problems and offer some solutions.
