Lately, software testing has been on my mind. I’ve been trying to dial in the sweet spot where automated testing is directly profitable by decreasing net development time, and indirectly profitable by increasing the intangible perception of quality.
Here’s the problem: unit testing can seem tedious. Prohibitively expensive. Tough to justify. Even intimidating! As a result, applications and application components can easily get starved of any form of automated testing.
A colleague let me in on a secret that helps break down these misconceptions. It’s simple, and maybe even obvious, but it’s still a secret worth sharing: a unit is as big as you want it to be. It’s just that once the unit gets big enough, we call it something else: a functional test, or an integration test. This type of testing can be a great strategy if you’re looking to minimize time writing tests yet ensure many high-level functional units are working as expected.
Here’s an example of how I recently used JKI’s VI Tester to develop an integration test for a LabVIEW application I was working on, and turned some low-value “throw-away” code into a permanent, reusable part of my application’s build process.
I received a new requirement that would require significant modification to a stable application. In this project, a .NET FileSystemWatcher monitors a directory where a third-party app creates test result files. This new requirement involved monitoring for an additional file extension, which meant I could no longer rely on the simple filter built-in to the FileSystemWatcher. While working on this modification, two things became evident: I was going to need to write some helper code in order to develop the feature, and I would need a test plan that involved more than just kicking the tires after building.
I started to write some throw-away code to enable development of a regular expression to replace the simple built-in filter. During this process, it hit me: toss this code into a VI Tester Test Case, and the helper code would effectively become my test plan. By making this code part of a Test Case and running those tests automatically at build time, the code became a valuable, functional part of my QA process! (By the way, the winning regex turned out to be “^[^\~].*\.(xls|xlsm)$“)
This VI is the Test Case that is run by VI Tester. It ensures that the application is able to properly monitor the test file directory and filter the filenames of interest.
By using two application functions (File System Watcher and File Call Back) as part of the Test Harness, I ensure functionality of the entire application component.
Functional tests like these help quell misconceptions about writing software tests. Testing does not have to be boring – feel free to whip out some application design patterns to create integration tests! Further, testing does not have to be tedious. Consider functional testing of high-level processes if the application does not warrant unit testing each low-level function.
Download a packaged version of this example below and poke around. There are a few more goodies in there, such as the source of the FileSystemWatcher setup, and a design pattern I dub “The Flaky Delegate” where a .NET callback brokers messages back as LabVIEW User Events.
Download the example as a VI Package. (108 KB, requires the free VI Package Manager Community Edition or higher)
Learn more about VI Tester, JKI’s free unit testing framework for LabVIEW.
A view of VI Tester and the project structure of VIs under test.
