inspired by material published by Tomasz Kaczanowski, Steven Sanderson and other fine sources.

• high internal quality
• not necessarily end-to-end (external quality)

• a test is a specification of behavior
• a test is a valuable asset and as such should be treated as first class citizen of our code
• writing a test is not a one-time activity, therefore concentrate on the important tests – what do you really need to test (see test method names)

START_TEST(UA_DateTime_calcSize_NullArgumentShouldReturnStorageSize) 
{
// **given** data and/or context
 UA_DateTime arg = UA_NULL;
// **when** contract is fullfilled correctly by function
 UA_Int32 storageSize = UA_DateTime_calcSize(&arg);
// **then** this behaviour should be observed
 ck_assert_int_eq(storageSize, 8);
}
END_TEST

• split valid / invalid
• split happy-path / error-path

• Use speaking defines instead of simple values (do not teach the API)
• Test shall tell the whole story

• Use describing names! A good name tells which part of the system fails if the test fails.
• UA_DateTime_test tells nothing, use something like UA_DateTime_calcSize_NullArgumentShouldReturnStorageSize

A test case is the smallest unit of testing. It checks for a specific response to a particular set of inputs (https://docs.python.org/2/library/unittest.html#unittest.TestCase), see section concentrate.

A test suite is a collection of test cases, test suites, or both. It is used to aggregate tests that should be executed together (https://docs.python.org/2/library/unittest.html#unittest.TestCase)

For instance testing the relevant aspects of all the basic data types that can be encoded in an IEC 62541 structure (i.e. UA_Variant) makes up a perfect suite which still has a manageable volume.

A test package is a build target for an executable in the tests-directory.

If you want to introduce a new abstract data type such as a list or a namespace you might want to start with specifying the normative behavior in a corresponding test package (Test Driven Development).