> Be written in a way that prevents the reader from doing mental computation to verify the test’s correctness.
The validity of the above statement hinges on the definition of "mental computation".
> Include elements like loops, concatenations, or complex calculations that could obscure the intended result.
Complex inputs/preconditions and/or complex outputs/post-conditions are often part of the requirements. How do you avoid complex calculations when such states/data structures have to be created for verification?
For example, when the producer of the inputs and/or the consumer of the outputs are machines, the raw data may not be trivial to either assemble for the test's (human) author or to parse by the test's (human) reader. Programmatically assembling input and/or output data may be less error prone in such cases than literally including the test-data.
State-related test-complexity can be often observed (and seems to be inevitable) with white-box testing time-sensitive functionality. Concurrency testing (e.g. mocking known potentially problematic states involving concurrent functions) is one large obvious sub-category here.
The underlying principle is double checking. If you get to the same answer through two methods, you’re much more confident.
> Be written in a way that prevents the reader from doing mental computation to verify the test’s correctness.
The validity of the above statement hinges on the definition of "mental computation".
> Include elements like loops, concatenations, or complex calculations that could obscure the intended result.
Complex inputs/preconditions and/or complex outputs/post-conditions are often part of the requirements. How do you avoid complex calculations when such states/data structures have to be created for verification?
For example, when the producer of the inputs and/or the consumer of the outputs are machines, the raw data may not be trivial to either assemble for the test's (human) author or to parse by the test's (human) reader. Programmatically assembling input and/or output data may be less error prone in such cases than literally including the test-data.
State-related test-complexity can be often observed (and seems to be inevitable) with white-box testing time-sensitive functionality. Concurrency testing (e.g. mocking known potentially problematic states involving concurrent functions) is one large obvious sub-category here.