Viewpoint News, November 2008

Test Driven Development in LabVIEW: Part 1 - Motivations

by Benjamin Hysell - bhysell@viewpointusa.com

Description of Test Driven Development (TDD)

From Wikipedia, the free encyclopedia:

Test-Driven Development (TDD) is a software development technique consisting of short iterations where new test cases covering the desired improvement or new functionality are written first, then the production code necessary to pass the tests is implemented, and finally the software is refactored to accommodate changes. The availability of tests before actual development ensures rapid feedback after any change. Practitioners emphasize that test-driven development is a method of designing software, not merely a method of testing.

Motivations

If it's worth building, it's worth testing. If it's not worth testing, why are you wasting your time working on it?
~www.agiledata.org

What if there was a method to capture all of the ad-hoc testing one performs on their VIs during the normal development cycle?

What if one could pull down the latest VIs from source control and be assured one has a working copy by successfully testing the VIs before making changes?

What if one could prove to management the changes made to the application didn’t break existing functionality?

TDD aims to make development life easier and more productive by providing these benefits to developers and management. Using TDD developers do not have to fear modifying or adding new functionality to VIs as they are always one button click away from running a full regression test on the entire application. The short iteration cycles between adding a test, adding the VI, testing, and refactoring the VI ensures developers do not ‘over develop’ an application and only add enough functionality to their VIs to get the job done.

Managing a TDD project is easier than managing a traditional project, now that management can utilize a suite of test VIs used to validate the application. Developers as well as managers can perform a full regression test on the latest VIs at a touch of a button.

By examining the tests produced by developers, management is able to spot potential problems with implementation through the lack of testing or improperly testing of VIs. This provides the manager an opportunity to mentor the developer and pass on learned knowledge about a system to the developer through writing new tests that break the developers’ VIs. This shared experience can be very valuable in educating new developers in the architecture of a project.

Methodology

TDD can be broken down into six steps. Each step has a very short iteration cycle from start to finish forcing developers to add new functionality one feature at a time in very small chunks. Taken from Wikipedia:

• Add a test
• Run all tests and see the new test fails
• Create/Modify VIs
• Run the automated tests and see them succeed
• Refactor VIs
• Repeat

Add a Test

Before a developer modifies a VI they write the test that will test the new feature to be added to the system.

Run All Tests and See the New Test Fails

This phase ensures that all other tests in the system currently pass. A developer can be sure they have a working copy of the application and any modifications they make that break old tests can be attributed to the new modifications being added right now.

Create/Modify VIs

The goal is to create/modify a VI just enough to ensure the test pass. This is not the time to look for an optimal solution or to ‘gold plate’ the VI.

Run the Automated Tests and See Them Succeed

Run the test on the newly created VIs to see if it passes or fails. Modify the new VI until it succeeds. Once the VI passes run all automated tests to ensure old tests still run successfully.

Refactor Code

Now that a developer has a VI that passes its tests and doesn’t break any other application functionality the code needs to be cleaned up and optimized. Since the developer has tests for the new VIs that meet the specification, they can change and improve the VIs, run the tests, and be assured the VI cleanup didn’t change core functionality of the application.

Repeat

Repeat the process to add further functionality to the application.

Caveats

Poorly written tests will result in poorly written VIs

Tests that fail to exercise all execution paths in the VIs result in untested VIs. Untested VIs are more difficult to maintain and change later on in the lifecycle of an application. So care and thought is required to assure good coverage of VI functionality and associated checks against requirements.

Tests Require Maintenance

A living test suite will now accompany all developed code and will need to be kept up to date to be useful during the next round of changes to the source code. The motivation for this seemingly double effort is that development is assisted by developing better code from the start and being able to catch bugs faster at the end. Thus, the total development time is usually only slightly more than without TDD and the output is more robust due to the thorough testing.

Summary

Test Driven Development provides a software development framework adding long term value to all development projects. The ability to run regression tests on all developed VIs at a touch of a button to prove applications are correct saves countless hours of development time. The short iteration cycles used in TDD provide instant feedback to the developer while they are adding new features to an established codebase, and ensures all those features that are added do not break prior functionality.