Monday, July 20, 2015

Kinds of tests

These are my thoughts on software testing terminology. Some of these tests have definitions that float, and I want to get down my definitions, so that I can refer to them and refer people to them if there's any uncertainty about what I mean.
Integration test
A test of the boundary between components. An integration test in project A for components B confirms that the interface A expects of B matches up with the interface that B provides. Such tests make sense whenever component B is not available to A's developer at the time that she writes A.
Unit test
A test of the primary functionality of a component and of the edge cases and error modes of the component. The component for which a unit test is written should not have untested sub-parts -- in other words, the unit test assumes that below the level of abstraction at which the test is performed, all components perform perfectly. It may be necessary to make "perfect" sub-parts (e.g., "mock" objects) to effectively test at the desired level of abstraction.
Acceptance test
A test of a component against customer requirements. These are tests which must be passed for acceptance of the component by the customer.
Formal test
A test of the mathematical abstraction of the software component against known failure modes which can be formally proven to occur, not occur, or possibly occur under a class of inputs.


Sunday, July 19, 2015

Human communication protocols. You can't tell what type PDU you deal with sans reading a variable number of headers, the offsets for each header encoded, in prose, by a randomly selected preceding header. Then, when you finally get to the damn payload, too often there's virtually no content. Absurd.