Feeds

Driven to test-action

A practical view of unit testing

Business security measures using SSL

Comment Test-Driven Development (TDD) has increased in popularity both as a practice and as a term. Although there is a strong association with Extreme Programming, more generally there is a certain set of practices that can be honed in on and applied across various development models.

headshot_Kevlin_Henney (large teaser)

Decoupling TDD from XP, which specifically focuses on the terms 'programmer tests' and 'test-first programming', and understanding it as a set of microprocess practices in its own right, makes it a more general and useful tool for programmers, regardless of the development macroprocess they are in.

Unit testing and more

The term TDD is often mistakenly used as a synonym for "unit testing". The relationship between the two is that unit testing forms part of TDD, but there is more to TDD than just unit testing. Both critics and advocates often miss that metonymic distinction.

Unit testing is a general notion that can be employed and practised in many ways, whether up-front documentation of test plans associated with up-front documentation of detailed designs in the classic waterfall approach (think Niagara Falls and people in barrels), or more informally by individual programmers seeking confidence in their own work and applying the simple tool of an assertion in a test case that exercises some code they have written.

TDD places unit testing in the context of agile development by motivating it in a different way from traditional testing approaches, which typically borrow from the classic V model of testing - a smokily mirrored view of the waterfall development lifecycle that emphasises testing but divorces it from other activities making up the main flow of development [1].

Effective unit testing can be seen to rest on the foundation of programmer testing responsibility, automated tests and example-based tests. TDD drives that through the design-focused activities of active test writing, sufficient design and refactoring.

Programmer testing responsibility

Unit tests are sometimes called programmer tests to differentiate them from system-level tests carried out in a separate testing role or department. It is important to remember that testing a unit is not the same as testing a system. Testing a system involves the software combination of the many code units, whatever their granularity, and the elements of the system external to the code, e.g. target software environment, configuration and broad usage. Units test as a whole, rather than as integrated parts, and are isolated from the external environment.

Of course, there is a natural tension in any development process between the responsibilities each role can include and the control it can exercise. A development role needs to be broad enough to connect to the range of activities involved in software development, but cohesive enough and appropriately sized that responsibilities are not overwhelming. For the role of developer, the organisational pattern Developer Controls Process defines such a focus, and includes the following brief [2]:

"Responsibilities of developers include understanding requirements, reviewing the solution structure algorithm with peers, building the implementation, and performing unit testing."

However, this does not limit or define the whole range of testing activities. The system-level perspective is explicitly covered in patterns such as Engage Quality Assurance and Application Design Is Bounded by Test Design. The inclusion of a code-testing responsibility in the programmer's canon also receives strong support from more orthodox testing perspectives [3]:

"I find the projects I work on usually go more smoothly when programmers do some unit and component testing of their own code. Through the ascendance of approaches like Extreme Programming, such a position is becoming less controversial. [...] So, a good practice is to adopt a development process that provides for unit testing, where programmers find bugs in their own software, and for component testing, where programmers test each other's software (this is sometimes called 'code swapping'). Variations on this approach use concepts like pair programming and peer reviews of automated component test stubs or harnesses."

However, sometimes responsibility can also translate to burden. Just stating that unit testing is a programmer's responsibility does not offer guidance as to how the responsibility can be met in practical terms, which is where the other practices listed earlier fit in.

New hybrid storage solutions

Next page: Automated tests

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
New 'Cosmos' browser surfs the net by TXT alone
No data plan? No WiFi? No worries ... except sluggish download speed
iOS 8 release: WebGL now runs everywhere. Hurrah for 3D graphics!
HTML 5's pretty neat ... when your browser supports it
Mathematica hits the Web
Wolfram embraces the cloud, promies private cloud cut of its number-cruncher
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
SUSE Linux owner Attachmate gobbled by Micro Focus for $2.3bn
Merger will lead to mainframe and COBOL powerhouse
iOS 8 Healthkit gets a bug SO Apple KILLS it. That's real healthcare!
Not fit for purpose on day of launch, says Cupertino
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.