Feeds

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

Word games

Intelligent flash storage arrays

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

Top 5 reasons to deploy VMware with Tegile

More from The Register

next story
Preview redux: Microsoft ships new Windows 10 build with 7,000 changes
Latest bleeding-edge bits borrow Action Center from Windows Phone
Google opens Inbox – email for people too thick to handle email
Print this article out and give it to someone tech-y if you get stuck
Microsoft promises Windows 10 will mean two-factor auth for all
Sneak peek at security features Redmond's baking into new OS
UNIX greybeards threaten Debian fork over systemd plan
'Veteran Unix Admins' fear desktop emphasis is betraying open source
Entity Framework goes 'code first' as Microsoft pulls visual design tool
Visual Studio database diagramming's out the window
Google+ goes TITSUP. But WHO knew? How long? Anyone ... Hello ...
Wobbly Gmail, Contacts, Calendar on the other hand ...
DEATH by PowerPoint: Microsoft warns of 0-day attack hidden in slides
Might put out patch in update, might chuck it out sooner
Redmond top man Satya Nadella: 'Microsoft LOVES Linux'
Open-source 'love' fairly runneth over at cloud event
prev story

Whitepapers

Choosing cloud Backup services
Demystify how you can address your data protection needs in your small- to medium-sized business and select the best online backup service to meet your needs.
Forging a new future with identity relationship management
Learn about ForgeRock's next generation IRM platform and how it is designed to empower CEOS's and enterprises to engage with consumers.
Security for virtualized datacentres
Legacy security solutions are inefficient due to the architectural differences between physical and virtual environments.
Reg Reader Research: SaaS based Email and Office Productivity Tools
Read this Reg reader report which provides advice and guidance for SMBs towards the use of SaaS based email and Office productivity tools.
Storage capacity and performance optimization at Mizuno USA
Mizuno USA turn to Tegile storage technology to solve both their SAN and backup issues.