-
Peter Thedens authoredPeter Thedens authored
Unity Assertions Reference
Background and Overview
Super Condensed Version
- An assertion establishes truth (i.e. boolean True) for a single condition. Upon boolean False, an assertion stops execution and reports the failure.
- Unity is mainly a rich collection of assertions and the support to gather up and easily execute those assertions.
- The structure of Unity allows you to easily separate test assertions from source code in, well, test code.
- Unity's assertions:
- Come in many, many flavors to handle different C types and assertion cases.
- Use context to provide detailed and helpful failure messages.
- Document types, expected values, and basic behavior in your source code for free.
Unity Is Several Things But Mainly It's Assertions
One way to think of Unity is simply as a rich collection of assertions you can use to establish whether your source code behaves the way you think it does. Unity provides a framework to easily organize and execute those assertions in test code separate from your source code.
What's an Assertion?
At their core, assertions are an establishment of truth - boolean truth. Was this thing equal to that thing? Does that code doohickey have such-and-such property or not? You get the idea. Assertions are executable code (to appreciate the big picture on this read up on the difference between [link:Dynamic Verification and Static Analysis]). A failing assertion stops execution and reports an error through some appropriate I/O channel (e.g. stdout, GUI, file, blinky light).
Fundamentally, for dynamic verification all you need is a single assertion
mechanism. In fact, that's what the assert() macro in C's standard library
is for. So why not just use it? Well, we can do far better in the reporting
department. C's assert() is pretty dumb as-is and is particularly poor for
handling common data types like arrays, structs, etc. And, without some other
support, it's far too tempting to litter source code with C's assert()'s. It's
generally much cleaner, manageable, and more useful to separate test and source
code in the way Unity facilitates.
Unity's Assertions: Helpful Messages and Free Source Code Documentation
Asserting a simple truth condition is valuable, but using the context of the assertion is even more valuable. For instance, if you know you're comparing bit flags and not just integers, then why not use that context to give explicit, readable, bit-level feedback when an assertion fails?
That's what Unity's collection of assertions do - capture context to give you helpful, meaningful assertion failure messages. In fact, the assertions themselves also serve as executable documentation about types and values in your source code. So long as your tests remain current with your source and all those tests pass, you have a detailed, up-to-date view of the intent and mechanisms in your source code. And due to a wondrous mystery, well-tested code usually tends to be well designed code.
Assertion Conventions and Configurations
Naming and Parameter Conventions
The convention of assertion parameters generally follows this order:
TEST_ASSERT_X( {modifiers}, {expected}, actual, {size/count} )The very simplest assertion possible uses only a single "actual" parameter (e.g. a simple null check).
"Actual" is the value being tested and unlike the other parameters in an assertion construction is the only parameter present in all assertion variants. "Modifiers" are masks, ranges, bit flag specifiers, floating point deltas. "Expected" is your expected value (duh) to compare to an "actual" value; it's marked as an optional parameter because some assertions only need a single "actual" parameter (e.g. null check). "Size/count" refers to string lengths, number of array elements, etc.
Many of Unity's assertions are apparent duplications in that the same data type
is handled by several assertions. The differences among these are in how failure
messages are presented. For instance, a _HEX variant of an assertion prints
the expected and actual values of that assertion formatted as hexadecimal.
TEST_ASSERT_X_MESSAGE Variants
All assertions are complemented with a variant that includes a simple string message as a final parameter. The string you specify is appended to an assertion failure message in Unity output.
For brevity, the assertion variants with a message parameter are not listed
below. Just tack on _MESSAGE as the final component to any assertion name in
the reference list below and add a string as the final parameter.
Example:
TEST_ASSERT_X( {modifiers}, {expected}, actual, {size/count} )becomes messageified like thus...
TEST_ASSERT_X_MESSAGE( {modifiers}, {expected}, actual, {size/count}, message )TEST_ASSERT_X_ARRAY Variants
Unity provides a collection of assertions for arrays containing a variety of
types. These are documented in the Array section below. These are almost on par
with the _MESSAGEvariants of Unity's Asserts in that for pretty much any Unity
type assertion you can tack on _ARRAY and run assertions on an entire block of
memory.
TEST_ASSERT_EQUAL_TYPEX_ARRAY( expected, actual, {size/count} )"Expected" is an array itself. "Size/count" is one or two parameters necessary to establish the number of array elements and perhaps the length of elements within the array.
Notes:
- The
_MESSAGEvariant convention still applies here to array assertions. The_MESSAGEvariants of the_ARRAYassertions have names ending with_ARRAY_MESSAGE. - Assertions for handling arrays of floating point values are grouped with float and double assertions (see immediately following section).
TEST_ASSERT_EACH_EQUAL_X Variants
Unity provides a collection of assertions for arrays containing a variety of
types which can be compared to a single value as well. These are documented in
the Each Equal section below. these are almost on par with the _MESSAGE
variants of Unity's Asserts in that for pretty much any Unity type assertion you
can inject _EACH_EQUAL and run assertions on an entire block of memory.
TEST_ASSERT_EACH_EQUAL_TYPEX( expected, actual, {size/count} )"Expected" is a single value to compare to. "Actual" is an array where each element will be compared to the expected value. "Size/count" is one of two parameters necessary to establish the number of array elements and perhaps the length of elements within the array.
Notes:
- The
_MESSAGEvariant convention still applies here to Each Equal assertions. - Assertions for handling Each Equal of floating point values are grouped with float and double assertions (see immediately following section).
Configuration
Floating Point Support Is Optional
Support for floating point types is configurable. That is, by defining the appropriate preprocessor symbols, floats and doubles can be individually enabled or disabled in Unity code. This is useful for embedded targets with no floating point math support (i.e. Unity compiles free of errors for fixed point only platforms). See Unity documentation for specifics.
Maximum Data Type Width Is Configurable
Not all targets support 64 bit wide types or even 32 bit wide types. Define the appropriate preprocessor symbols and Unity will omit all operations from compilation that exceed the maximum width of your target. See Unity documentation for specifics.
The Assertions in All Their Blessed Glory
Basic Fail and Ignore
TEST_FAIL()
This fella is most often used in special conditions where your test code is
performing logic beyond a simple assertion. That is, in practice, TEST_FAIL()
will always be found inside a conditional code block.
Examples:
- Executing a state machine multiple times that increments a counter your test code then verifies as a final step.
- Triggering an exception and verifying it (as in Try / Catch / Throw - see the CException project).
TEST_IGNORE()
Marks a test case (i.e. function meant to contain test assertions) as ignored. Usually this is employed as a breadcrumb to come back and implement a test case. An ignored test case has effects if other assertions are in the enclosing test case (see Unity documentation for more).
Boolean
TEST_ASSERT (condition)
TEST_ASSERT_TRUE (condition)
TEST_ASSERT_FALSE (condition)
TEST_ASSERT_UNLESS (condition)
A simple wording variation on TEST_ASSERT_FALSE.The semantics of
TEST_ASSERT_UNLESS aid readability in certain test constructions or
conditional statements.
TEST_ASSERT_NULL (pointer)
TEST_ASSERT_NOT_NULL (pointer)
Signed and Unsigned Integers (of all sizes)
Large integer sizes can be disabled for build targets that do not support them. For example, if your target only supports up to 16 bit types, by defining the appropriate symbols Unity can be configured to omit 32 and 64 bit operations that would break compilation (see Unity documentation for more). Refer to Advanced Asserting later in this document for advice on dealing with other word sizes.
TEST_ASSERT_EQUAL_INT (expected, actual)
TEST_ASSERT_EQUAL_INT8 (expected, actual)
TEST_ASSERT_EQUAL_INT16 (expected, actual)
TEST_ASSERT_EQUAL_INT32 (expected, actual)
TEST_ASSERT_EQUAL_INT64 (expected, actual)
TEST_ASSERT_EQUAL (expected, actual)
TEST_ASSERT_NOT_EQUAL (expected, actual)
TEST_ASSERT_EQUAL_UINT (expected, actual)
TEST_ASSERT_EQUAL_UINT8 (expected, actual)
TEST_ASSERT_EQUAL_UINT16 (expected, actual)
TEST_ASSERT_EQUAL_UINT32 (expected, actual)
TEST_ASSERT_EQUAL_UINT64 (expected, actual)
Unsigned Integers (of all sizes) in Hexadecimal
All _HEX assertions are identical in function to unsigned integer assertions
but produce failure messages with the expected and actual values formatted
in hexadecimal. Unity output is big endian.
TEST_ASSERT_EQUAL_HEX (expected, actual)
TEST_ASSERT_EQUAL_HEX8 (expected, actual)
TEST_ASSERT_EQUAL_HEX16 (expected, actual)
TEST_ASSERT_EQUAL_HEX32 (expected, actual)
TEST_ASSERT_EQUAL_HEX64 (expected, actual)
Masked and Bit-level Assertions
Masked and bit-level assertions produce output formatted in hexadecimal. Unity output is big endian.
TEST_ASSERT_BITS (mask, expected, actual)
Only compares the masked (i.e. high) bits of expected and actual parameters.
TEST_ASSERT_BITS_HIGH (mask, actual)
Asserts the masked bits of the actual parameter are high.
TEST_ASSERT_BITS_LOW (mask, actual)
Asserts the masked bits of the actual parameter are low.
TEST_ASSERT_BIT_HIGH (bit, actual)
Asserts the specified bit of the actual parameter is high.
TEST_ASSERT_BIT_LOW (bit, actual)
Asserts the specified bit of the actual parameter is low.
Integer Less Than / Greater Than
These assertions verify that the actual parameter is less than or greater
than threshold (exclusive). For example, if the threshold value is 0 for the
greater than assertion will fail if it is 0 or less.
TEST_ASSERT_GREATER_THAN (threshold, actual)
TEST_ASSERT_GREATER_THAN_INT (threshold, actual)
TEST_ASSERT_GREATER_THAN_INT8 (threshold, actual)
TEST_ASSERT_GREATER_THAN_INT16 (threshold, actual)
TEST_ASSERT_GREATER_THAN_INT32 (threshold, actual)
TEST_ASSERT_GREATER_THAN_UINT (threshold, actual)
TEST_ASSERT_GREATER_THAN_UINT8 (threshold, actual)
TEST_ASSERT_GREATER_THAN_UINT16 (threshold, actual)
TEST_ASSERT_GREATER_THAN_UINT32 (threshold, actual)
TEST_ASSERT_GREATER_THAN_HEX8 (threshold, actual)
TEST_ASSERT_GREATER_THAN_HEX16 (threshold, actual)
TEST_ASSERT_GREATER_THAN_HEX32 (threshold, actual)
TEST_ASSERT_LESS_THAN (threshold, actual)
TEST_ASSERT_LESS_THAN_INT (threshold, actual)
TEST_ASSERT_LESS_THAN_INT8 (threshold, actual)
TEST_ASSERT_LESS_THAN_INT16 (threshold, actual)
TEST_ASSERT_LESS_THAN_INT32 (threshold, actual)
TEST_ASSERT_LESS_THAN_UINT (threshold, actual)
TEST_ASSERT_LESS_THAN_UINT8 (threshold, actual)
TEST_ASSERT_LESS_THAN_UINT16 (threshold, actual)
TEST_ASSERT_LESS_THAN_UINT32 (threshold, actual)
TEST_ASSERT_LESS_THAN_HEX8 (threshold, actual)
TEST_ASSERT_LESS_THAN_HEX16 (threshold, actual)
TEST_ASSERT_LESS_THAN_HEX32 (threshold, actual)
Integer Ranges (of all sizes)
These assertions verify that the expected parameter is within +/- delta
(inclusive) of the actual parameter. For example, if the expected value is 10
and the delta is 3 then the assertion will fail for any value outside the range
of 7 - 13.
TEST_ASSERT_INT_WITHIN (delta, expected, actual)
TEST_ASSERT_INT8_WITHIN (delta, expected, actual)
TEST_ASSERT_INT16_WITHIN (delta, expected, actual)
TEST_ASSERT_INT32_WITHIN (delta, expected, actual)
TEST_ASSERT_INT64_WITHIN (delta, expected, actual)
TEST_ASSERT_UINT_WITHIN (delta, expected, actual)
TEST_ASSERT_UINT8_WITHIN (delta, expected, actual)
TEST_ASSERT_UINT16_WITHIN (delta, expected, actual)
TEST_ASSERT_UINT32_WITHIN (delta, expected, actual)
TEST_ASSERT_UINT64_WITHIN (delta, expected, actual)
TEST_ASSERT_HEX_WITHIN (delta, expected, actual)
TEST_ASSERT_HEX8_WITHIN (delta, expected, actual)
TEST_ASSERT_HEX16_WITHIN (delta, expected, actual)
TEST_ASSERT_HEX32_WITHIN (delta, expected, actual)
TEST_ASSERT_HEX64_WITHIN (delta, expected, actual)
Structs and Strings
TEST_ASSERT_EQUAL_PTR (expected, actual)
Asserts that the pointers point to the same memory location.
TEST_ASSERT_EQUAL_STRING (expected, actual)
Asserts that the null terminated ('\0')strings are identical. If strings are
of different lengths or any portion of the strings before their terminators
differ, the assertion fails. Two NULL strings (i.e. zero length) are considered
equivalent.
TEST_ASSERT_EQUAL_MEMORY (expected, actual, len)
Asserts that the contents of the memory specified by the expected and actual
pointers is identical. The size of the memory blocks in bytes is specified by
the len parameter.
Arrays
expected and actual parameters are both arrays. num_elements specifies the
number of elements in the arrays to compare.
_HEX assertions produce failure messages with expected and actual array
contents formatted in hexadecimal.
For array of strings comparison behavior, see comments for
TEST_ASSERT_EQUAL_STRING in the preceding section.
Assertions fail upon the first element in the compared arrays found not to match. Failure messages specify the array index of the failed comparison.