Feeds

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

Word games

Business security measures using SSL

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. ®

New hybrid storage solutions

More from The Register

next story
'Windows 9' LEAK: Microsoft's playing catchup with Linux
Multiple desktops and live tiles in restored Start button star in new vids
Not appy with your Chromebook? Well now it can run Android apps
Google offers beta of tricky OS-inside-OS tech
New 'Cosmos' browser surfs the net by TXT alone
No data plan? No WiFi? No worries ... except sluggish download speed
SUSE Linux owner Attachmate gobbled by Micro Focus for $2.3bn
Merger will lead to mainframe and COBOL powerhouse
iOS 8 release: WebGL now runs everywhere. Hurrah for 3D graphics!
HTML 5's pretty neat ... when your browser supports it
Greater dev access to iOS 8 will put us AT RISK from HACKERS
Knocking holes in Apple's walled garden could backfire, says securo-chap
NHS grows a NoSQL backbone and rips out its Oracle Spine
Open source? In the government? Ha ha! What, wait ...?
Google extends app refund window to two hours
You now have 120 minutes to finish that game instead of 15
Intel: Hey, enterprises, drop everything and DO HADOOP
Big Data analytics projected to run on more servers than any other app
prev story

Whitepapers

Providing a secure and efficient Helpdesk
A single remote control platform for user support is be key to providing an efficient helpdesk. Retain full control over the way in which screen and keystroke data is transmitted.
WIN a very cool portable ZX Spectrum
Win a one-off portable Spectrum built by legendary hardware hacker Ben Heck
Storage capacity and performance optimization at Mizuno USA
Mizuno USA turn to Tegile storage technology to solve both their SAN and backup issues.
High Performance for All
While HPC is not new, it has traditionally been seen as a specialist area – is it now geared up to meet more mainstream requirements?
Security and trust: The backbone of doing business over the internet
Explores the current state of website security and the contributions Symantec is making to help organizations protect critical data and build trust with customers.