The grain and it's beach

A software unit is defined by the IEEE in 1008-1987 asⁱ:

“The smallest unit of a software program.”

Depending on the type of program being tested the software unit may represent a single function, sub-routine, or given algorithm. The languages may be functional, procedural, low level or object-oriented, however each language and program will have a defined function and desired operation.

Since all software applications are composed as the “sum of their parts” however simple or complex the program may be; each of the parts plays a role in the operations of said program. There are numerous philosophies around what makes a high quality reliable software; the Unix paradigm states that a program should be as small as possible and have only one functionⁱⁱ. This Bottom-Up approach has created Linux and the entire open-source movement. Top down approaches exist and most formal testing and development methods are top-down in nature, Agile and XP and SCRUM are examples of methodologies that are top-downⁱⁱⁱ. Each of these approaches has their respective merit; however we are simply mentioning them here to illustrate what a software unit may be defined as.

The importance of isolation of a given software unit for test is that this unit must be verified according to formal methods to ensure that for all desired operational states the unit functions as required, since malfunctions of the software unit will ultimately lead to errors, faults and failures.

Formal methods for software verification include; Black Box, White Box, Correctness and all other validation and verification methods as defined by Galin^iv.

An oft used metaphor is that of an internal combustion engine; it's purpose is to generate motive power from some combustible fuel, all engines have the same purpose and within modern engineering, one stated piece of common knowledge is that if a given engine has too many moving parts it will be less reliable than a similar one with fewer moving parts.^v Fewer parts means less to potentially go wrong.

Within a software application, the “moving parts” are composed of mathematical abstractions defined as software units. The verification of which requires that both the logic of the math behind the algorithms being tested be sound.

The methods to isolate the software unit as defined by Galin^vi include “Black-Box” and “White-Box” testing; where the only major difference between the two is access to the source code. If one has access to a programs source then each “Sub-routine” may be defined as a software unit for testing purposes. Without access to the source code, black box testing focuses on application functions versus stated business requirements.

Another method of testing quite frequently used to locate software defects is disassembly and reverse engineering; disassembly of obfuscated binaries allows anyone with physical access to computing resources to view and interpret a software programs intent and function.^vii All malware development is based on defects found utilizing static disassembly techniques. Though disassembly is not a formal method it does offer insight into the function of a given software program without access to the relevant source code.

The modes of testing may be automated; or standardized and manual. Each has their respective benefits, most automated tests using software will offer only as much insight as they are programmed to offer. Standardized manual tests for senarios that are seen as eccentric or unique will further increase time requirements but they will also increase the reliability of a given program or system.

The success or failure of a given software unit may be defined by the test data from the unit testing; this includes conformance to all formally stated requirements for function; conformance to all expected input via output and functional tests and general sanity regarding the function as defined mathematically.

Since software is the most complex machine ever developed by man, each unit equating to a given mechanical cog; should a single cog rotate ineffectively; or worse rotate backwards, then the machine will fail. Each grain of sand may not be visible on the beach; by removing the grain and inspecting it we can discern it's origin, composition and age. This is the goal of software unit testing; it's designed to ensure that the software preformes as it should by testing as many parts as is warranted by the project at hand.

iN.A. (IEEE, ANSI, 1987) 1008-1987 IEEE Standard for Software Unit Testing [Online] PDF Document, Available from: http://standards.ieee.org/findstds/standard/1008-1987.html (Accessed on March 1^st 2011)

iiMcIIlroy, M. D.; Pinson D.E.; Tague, B.A. (Bell Labratories, 1978) The Bell System Technical Journal, “Unix Time Sharing System forward” 1978, 57 (6 Part 2) P. 1992 [Online] World Wide Web, Available from: http://www.faqs.org/docs/artu/ch01s06.html (Accessed on March 1^st 2011)

iiiStallings, Brian (Agile Journal, March 2007) Agile Top-Down: Striking a Balance [Online] World Wide Web, Available from: http://www.agilejournal.com/articles/columns/column-articles/273-agile-top-down-striking-a-balance (Accessed on March 1^st 2011)

ivGalin, Daniel (Pearson Addison Welsly, 2008) Software Quality Assurance from theory to implementation P.187 ISBN:0-201-70945-7

vBrommley, Richard; Newton, David; O'Connor, Patrick T; ( John Wiley and Sons, 2002) Practical Reliability Engineering P. 215-221 ISBN: 0-470-84463-9

viGalin, Daniel (Pearson Addison Welsly, 2008) Software Quality Assurance from theory to implementation P.189-192 ISBN:0-201-70945-7

viiKrugel, Christopher; Robertson, William; Valeur, Fredrick; Vigna, Giovanni; (University of Santa Barbara California, 2004) Static Dissassembly of Obfuscated Binaries [Online] World Wide Web, Available from; https://www.usenix.org/events/sec04/tech/full_papers/kruegel/kruegel_html/disassemble.html (Accessed on March 1^st 2011)