Feeds

One programmer's unit test is another's integration test

Word games

Boost IT visibility and business value

Of course, in the middle of all these word games, there is an obvious and pragmatic question waiting to be answered: so long as we're testing, does it even matter what we call our tests or what kinds of tests they are? Inasmuch as the test is more important than the unit, it doesn't matter. On the other hand, if we care about communication and the broader implications of our testing styles, it does matter. Without a consistent vocabulary, it's easy to talk at cross purposes: one programmer's unit test could be another's integration test. The meaning of the terms has implications not only for testing but, more importantly, implications for design. A different definition can suggest and encourage a different style of design.

In other words, what we mean by unit test can have architectural implications. If we are looking for loosely-coupled code, a definition of test granularity should ideally help us to achieve this goal.

Here is a simple definition that I have used for a couple of years that seems to offer a simple litmus test for whether or not something is a unit test, and which has some other useful consequences to boot: A unit test is a test of behaviour (normally functional) whose success or failure is wholly determined by the correctness of the test and the correctness of the unit under test.

Consequently, the unit under test has no external dependencies across boundaries of trust or control, which could introduce other sources of failure. Such external dependencies include networks, databases, files, registries, clocks and user interfaces. In other words, the unit in question can be isolated at a level below the whole system and its interactions with the environment. By implication, an integration test is one that does not fully satisfy this definition, where reasons for failure could be environmental, but it is below the level of the whole system.

This brief definition is also largely compatible with the definition offered by Michael Feathers. The architectural implications for both views are pretty much the same: the more loosely-coupled the code of a system is, the more of it can be described and checked in terms of unit tests. An architect cannot reasonably support the claim that a system is loosely-coupled when it is not unit testable.

Many of the "unit tests" being written in projects today are not unit tests by the definitions we've homed in on, but they probably should be. The tests are consequently harder to write and slower to run – they touch the file system, network, etc.

In other words, unit testability offers feedback on the quality of coupling in a system. However, being able to write unit tests against such code does not come for free, because the design needs to be changed.

Techniques such as interface extraction and dependency inversion [pdf download] have an important role to play.

It is not that the coupling in such systems is necessarily messy – for example, filled with dependency cycles between packages – it is that even in a conventionally layered system there's more transitive coupling across layers than is strictly necessary.

Although the code in one class may depend only on the public interface of another class, the code base itself depends on the other class's private section and those dependencies in turn until the dependency horizon is reached. Introduce a pure interface at the right point and the chain of dependencies is broken. This reduction in coupling simplifies many things. For testing it becomes possible to mock or stub, as appropriate, the dependencies that cross boundaries of trust and control without undue effort. ®

Build a business case: developing custom apps

More from The Register

next story
KDE releases ice-cream coloured Plasma 5 just in time for summer
Melty but refreshing - popular rival to Mint's Cinnamon's still a work in progress
Leaked Windows Phone 8.1 Update specs tease details of Nokia's next mobes
New screen sizes, dual SIMs, voice over LTE, and more
Mozilla keeps its Beard, hopes anti-gay marriage troubles are now over
Plenty on new CEO's todo list – starting with Firefox's slipping grasp
Apple: We'll unleash OS X Yosemite beta on the MASSES on 24 July
Starting today, regular fanbois will be guinea pigs, it tells Reg
Another day, another Firefox: Version 31 is upon us ALREADY
Web devs, Mozilla really wants you to like this one
Secure microkernel that uses maths to be 'bug free' goes open source
Hacker-repelling, drone-protecting code will soon be yours to tweak as you see fit
Cloudy CoreOS Linux distro declares itself production-ready
Lightweight, container-happy Linux gets first Stable release
prev story

Whitepapers

Implementing global e-invoicing with guaranteed legal certainty
Explaining the role local tax compliance plays in successful supply chain management and e-business and how leading global brands are addressing this.
Boost IT visibility and business value
How building a great service catalog relieves pressure points and demonstrates the value of IT service management.
Why and how to choose the right cloud vendor
The benefits of cloud-based storage in your processes. Eliminate onsite, disk-based backup and archiving in favor of cloud-based data protection.
The Essential Guide to IT Transformation
ServiceNow discusses three IT transformations that can help CIO's automate IT services to transform IT and the enterprise.
Maximize storage efficiency across the enterprise
The HP StoreOnce backup solution offers highly flexible, centrally managed, and highly efficient data protection for any enterprise.