mirror of
https://github.com/ThrowTheSwitch/Unity.git
synced 2026-01-23 00:15:58 +01:00
markdown conformance
This commit is contained in:
wolf99
47
README.md
47
README.md
@@ -1,5 +1,5 @@
|
||||
Unity Test 
|
||||
==========
|
||||
# Unity Test 
|
||||
|
||||
__Copyright (c) 2007 - 2021 Unity Project by Mike Karlesky, Mark VanderVoord, and Greg Williams__
|
||||
|
||||
Welcome to the Unity Test Project, one of the main projects of ThrowTheSwitch.org. Unity Test is a
|
||||
@@ -8,22 +8,21 @@ unit testing framework built for C, with a focus on working with embedded toolch
|
||||
This project is made to test code targetting microcontrollers big and small. The core project is a
|
||||
single C file and a pair of headers, allowing it to the added to your existing build setup without
|
||||
too much headache. You may use any compiler you wish, and may use most existing build systems
|
||||
including make, cmake, etc. If you'd like to leave the hard work to us, you might be interested
|
||||
including Make, CMake, etc. If you'd like to leave the hard work to us, you might be interested
|
||||
in Ceedling, a build tool also by ThrowTheSwitch.org.
|
||||
|
||||
If you're new to Unity, we encourage you to tour the [getting started guide](docs/UnityGettingStartedGuide.md)
|
||||
|
||||
Getting Started
|
||||
===============
|
||||
## Getting Started
|
||||
|
||||
The [docs](docs/) folder contains a [getting started guide](docs/UnityGettingStartedGuide.md)
|
||||
and much more tips about using Unity.
|
||||
|
||||
Unity Assertion Summary
|
||||
=======================
|
||||
## Unity Assertion Summary
|
||||
|
||||
For the full list, see [UnityAssertionsReference.md](docs/UnityAssertionsReference.md).
|
||||
|
||||
Basic Validity Tests
|
||||
--------------------
|
||||
### Basic Validity Tests
|
||||
|
||||
TEST_ASSERT_TRUE(condition)
|
||||
|
||||
@@ -46,8 +45,7 @@ Another way of calling `TEST_ASSERT_FALSE`
|
||||
|
||||
This test is automatically marked as a failure. The message is output stating why.
|
||||
|
||||
Numerical Assertions: Integers
|
||||
------------------------------
|
||||
### Numerical Assertions: Integers
|
||||
|
||||
TEST_ASSERT_EQUAL_INT(expected, actual)
|
||||
TEST_ASSERT_EQUAL_INT8(expected, actual)
|
||||
@@ -87,19 +85,15 @@ Another way of calling TEST_ASSERT_EQUAL_INT
|
||||
Asserts that the actual value is within plus or minus delta of the expected value. This also comes in
|
||||
size specific variants.
|
||||
|
||||
|
||||
TEST_ASSERT_GREATER_THAN(threshold, actual)
|
||||
|
||||
Asserts that the actual value is greater than the threshold. This also comes in size specific variants.
|
||||
|
||||
|
||||
TEST_ASSERT_LESS_THAN(threshold, actual)
|
||||
|
||||
Asserts that the actual value is less than the threshold. This also comes in size specific variants.
|
||||
|
||||
|
||||
Arrays
|
||||
------
|
||||
### Arrays
|
||||
|
||||
_ARRAY
|
||||
|
||||
@@ -116,8 +110,7 @@ value. You do this by specifying the EACH_EQUAL macro. For example:
|
||||
|
||||
TEST_ASSERT_EACH_EQUAL_INT32(expected, actual, elements)
|
||||
|
||||
Numerical Assertions: Bitwise
|
||||
-----------------------------
|
||||
### Numerical Assertions: Bitwise
|
||||
|
||||
TEST_ASSERT_BITS(mask, expected, actual)
|
||||
|
||||
@@ -139,8 +132,7 @@ Test a single bit and verify that it is high. The bit is specified 0-31 for a 3
|
||||
|
||||
Test a single bit and verify that it is low. The bit is specified 0-31 for a 32-bit integer.
|
||||
|
||||
Numerical Assertions: Floats
|
||||
----------------------------
|
||||
### Numerical Assertions: Floats
|
||||
|
||||
TEST_ASSERT_FLOAT_WITHIN(delta, expected, actual)
|
||||
|
||||
@@ -151,8 +143,7 @@ Asserts that the actual value is within plus or minus delta of the expected valu
|
||||
|
||||
Asserts that two floating point values are "equal" within a small % delta of the expected value.
|
||||
|
||||
String Assertions
|
||||
-----------------
|
||||
### String Assertions
|
||||
|
||||
TEST_ASSERT_EQUAL_STRING(expected, actual)
|
||||
|
||||
@@ -170,8 +161,7 @@ Compare two null-terminate strings. Fail if any character is different or if th
|
||||
|
||||
Compare two strings. Fail if any character is different, stop comparing after len characters. Output a custom message on failure.
|
||||
|
||||
Pointer Assertions
|
||||
------------------
|
||||
### Pointer Assertions
|
||||
|
||||
Most pointer operations can be performed by simply using the integer comparisons above. However, a couple of special cases are added for clarity.
|
||||
|
||||
@@ -183,18 +173,15 @@ Fails if the pointer is not equal to NULL
|
||||
|
||||
Fails if the pointer is equal to NULL
|
||||
|
||||
Memory Assertions
|
||||
-----------------
|
||||
### Memory Assertions
|
||||
|
||||
TEST_ASSERT_EQUAL_MEMORY(expected, actual, len)
|
||||
|
||||
Compare two blocks of memory. This is a good generic assertion for types that can't be coerced into acting like
|
||||
standard types... but since it's a memory compare, you have to be careful that your data types are packed.
|
||||
|
||||
\_MESSAGE
|
||||
---------
|
||||
### \_MESSAGE
|
||||
|
||||
you can append \_MESSAGE to any of the macros to make them take an additional argument. This argument
|
||||
you can append `\_MESSAGE` to any of the macros to make them take an additional argument. This argument
|
||||
is a string that will be printed at the end of the failure strings. This is useful for specifying more
|
||||
information about the problem.
|
||||
|
||||
|
||||
@@ -8,14 +8,12 @@ and we'll try to be polite when we notice yours.
|
||||
|
||||
;)
|
||||
|
||||
|
||||
## Why Have A Coding Standard?
|
||||
|
||||
Being consistent makes code easier to understand. We've tried to keep
|
||||
our standard simple because we also believe that we can only expect someone to
|
||||
follow something that is understandable. Please do your best.
|
||||
|
||||
|
||||
## Our Philosophy
|
||||
|
||||
Before we get into details on syntax, let's take a moment to talk about our
|
||||
@@ -46,7 +44,6 @@ default. We believe that if you're working with a simple compiler and target,
|
||||
you shouldn't need to configure very much... we try to make the tools guess as
|
||||
much as they can, but give the user the power to override it when it's wrong.
|
||||
|
||||
|
||||
## Naming Things
|
||||
|
||||
Let's talk about naming things. Programming is all about naming things. We name
|
||||
@@ -56,20 +53,19 @@ finding *What Something WANTS to be Called*™.
|
||||
|
||||
When naming things, we follow this hierarchy, the first being the
|
||||
most important to us (but we do all four when possible):
|
||||
|
||||
1. Readable
|
||||
2. Descriptive
|
||||
3. Consistent
|
||||
4. Memorable
|
||||
|
||||
|
||||
#### Readable
|
||||
### Readable
|
||||
|
||||
We want to read our code. This means we like names and flow that are more
|
||||
naturally read. We try to avoid double negatives. We try to avoid cryptic
|
||||
abbreviations (sticking to ones we feel are common).
|
||||
|
||||
|
||||
#### Descriptive
|
||||
### Descriptive
|
||||
|
||||
We like descriptive names for things, especially functions and variables.
|
||||
Finding the right name for something is an important endeavor. You might notice
|
||||
@@ -90,16 +86,14 @@ naming. We find i, j, and k are better loop counters than loopCounterVar or
|
||||
whatnot. We only break this rule when we see that more description could improve
|
||||
understanding of an algorithm.
|
||||
|
||||
|
||||
#### Consistent
|
||||
### Consistent
|
||||
|
||||
We like consistency, but we're not really obsessed with it. We try to name our
|
||||
configuration macros in a consistent fashion... you'll notice a repeated use of
|
||||
UNITY_EXCLUDE_BLAH or UNITY_USES_BLAH macros. This helps users avoid having to
|
||||
remember each macro's details.
|
||||
|
||||
|
||||
#### Memorable
|
||||
### Memorable
|
||||
|
||||
Where ever it doesn't violate the above principles, we try to apply memorable
|
||||
names. Sometimes this means using something that is simply descriptive, but
|
||||
@@ -108,10 +102,9 @@ out in our memory and are easier to search for. Take a look through the file
|
||||
names in Ceedling and you'll get a good idea of what we are talking about here.
|
||||
Why use preprocess when you can use preprocessinator? Or what better describes a
|
||||
module in charge of invoking tasks during releases than release_invoker? Don't
|
||||
get carried away. The names are still descriptive and fulfill the above
|
||||
get carried away. The names are still descriptive and fulfil the above
|
||||
requirements, but they don't feel stale.
|
||||
|
||||
|
||||
## C and C++ Details
|
||||
|
||||
We don't really want to add to the style battles out there. Tabs or spaces?
|
||||
@@ -123,8 +116,7 @@ We've decided on our own style preferences. If you'd like to contribute to these
|
||||
projects (and we hope that you do), then we ask if you do your best to follow
|
||||
the same. It will only hurt a little. We promise.
|
||||
|
||||
|
||||
#### Whitespace
|
||||
### Whitespace in C/C++
|
||||
|
||||
Our C-style is to use spaces and to use 4 of them per indent level. It's a nice
|
||||
power-of-2 number that looks decent on a wide-screen. We have no more reason
|
||||
@@ -139,8 +131,7 @@ things up in nice tidy columns.
|
||||
}
|
||||
```
|
||||
|
||||
|
||||
#### Case
|
||||
### Case in C/C++
|
||||
|
||||
- Files - all lower case with underscores.
|
||||
- Variables - all lower case with underscores
|
||||
@@ -149,8 +140,7 @@ things up in nice tidy columns.
|
||||
- Functions - camel cased. Usually named ModuleName_FuncName
|
||||
- Constants and Globals - camel cased.
|
||||
|
||||
|
||||
#### Braces
|
||||
### Braces in C/C++
|
||||
|
||||
The left brace is on the next line after the declaration. The right brace is
|
||||
directly below that. Everything in between in indented one level. If you're
|
||||
@@ -163,8 +153,7 @@ catching an error and you have a one-line, go ahead and to it on the same line.
|
||||
}
|
||||
```
|
||||
|
||||
|
||||
#### Comments
|
||||
### Comments in C/C++
|
||||
|
||||
Do you know what we hate? Old-school C block comments. BUT, we're using them
|
||||
anyway. As we mentioned, our goal is to support every compiler we can,
|
||||
@@ -172,23 +161,20 @@ especially embedded compilers. There are STILL C compilers out there that only
|
||||
support old-school block comments. So that is what we're using. We apologize. We
|
||||
think they are ugly too.
|
||||
|
||||
|
||||
## Ruby Details
|
||||
|
||||
Is there really such thing as a Ruby coding standard? Ruby is such a free form
|
||||
language, it seems almost sacrilegious to suggest that people should comply to
|
||||
one method! We'll keep it really brief!
|
||||
|
||||
|
||||
#### Whitespace
|
||||
### Whitespace in Ruby
|
||||
|
||||
Our Ruby style is to use spaces and to use 2 of them per indent level. It's a
|
||||
nice power-of-2 number that really grooves with Ruby's compact style. We have no
|
||||
more reason than that. We break that rule when we have lines that wrap. When
|
||||
that happens, we like to indent further to line things up in nice tidy columns.
|
||||
|
||||
|
||||
#### Case
|
||||
### Case in Ruby
|
||||
|
||||
- Files - all lower case with underscores.
|
||||
- Variables - all lower case with underscores
|
||||
@@ -196,11 +182,9 @@ that happens, we like to indent further to line things up in nice tidy columns.
|
||||
- Functions - all lower case with underscores
|
||||
- Constants - all upper case with underscores
|
||||
|
||||
|
||||
## Documentation
|
||||
|
||||
Egad. Really? We use mark down and we like pdf files because they can be made to
|
||||
look nice while still being portable. Good enough?
|
||||
|
||||
|
||||
*Find The Latest of This And More at [ThrowTheSwitch.org](https://throwtheswitch.org)*
|
||||
|
||||
@@ -16,7 +16,6 @@ source code in, well, test code.
|
||||
- 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
|
||||
@@ -24,7 +23,6 @@ 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
|
||||
@@ -44,7 +42,6 @@ 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
|
||||
@@ -60,14 +57,13 @@ 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:
|
||||
|
||||
```
|
||||
```c
|
||||
TEST_ASSERT_X( {modifiers}, {expected}, actual, {size/count} )
|
||||
```
|
||||
|
||||
@@ -87,7 +83,6 @@ 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
|
||||
@@ -100,17 +95,18 @@ the reference list below and add a string as the final parameter.
|
||||
|
||||
_Example:_
|
||||
|
||||
```
|
||||
```c
|
||||
TEST_ASSERT_X( {modifiers}, {expected}, actual, {size/count} )
|
||||
```
|
||||
|
||||
becomes messageified like thus...
|
||||
|
||||
```
|
||||
```c
|
||||
TEST_ASSERT_X_MESSAGE( {modifiers}, {expected}, actual, {size/count}, message )
|
||||
```
|
||||
|
||||
Notes:
|
||||
|
||||
- The `_MESSAGE` variants intentionally do not support `printf` style formatting
|
||||
since many embedded projects don't support or avoid `printf` for various reasons.
|
||||
It is possible to use `sprintf` before the assertion to assemble a complex fail
|
||||
@@ -119,7 +115,6 @@ Notes:
|
||||
a loop) , building up an array of results and then using one of the `_ARRAY`
|
||||
assertions (see below) might be a handy alternative to `sprintf`.
|
||||
|
||||
|
||||
#### TEST_ASSERT_X_ARRAY Variants
|
||||
|
||||
Unity provides a collection of assertions for arrays containing a variety of
|
||||
@@ -128,7 +123,7 @@ with the `_MESSAGE`variants 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.
|
||||
|
||||
```
|
||||
```c
|
||||
TEST_ASSERT_EQUAL_TYPEX_ARRAY( expected, actual, {size/count} )
|
||||
```
|
||||
|
||||
@@ -144,7 +139,6 @@ Notes:
|
||||
- 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
|
||||
@@ -153,7 +147,7 @@ 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.
|
||||
|
||||
```
|
||||
```c
|
||||
TEST_ASSERT_EACH_EQUAL_TYPEX( expected, actual, {size/count} )
|
||||
```
|
||||
|
||||
@@ -168,7 +162,6 @@ Notes:
|
||||
- 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
|
||||
@@ -179,7 +172,6 @@ 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
|
||||
@@ -187,14 +179,13 @@ 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, Pass and Ignore
|
||||
|
||||
##### `TEST_FAIL()`
|
||||
#### `TEST_FAIL()`
|
||||
|
||||
##### `TEST_FAIL_MESSAGE("message")`
|
||||
#### `TEST_FAIL_MESSAGE("message")`
|
||||
|
||||
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()`
|
||||
@@ -207,25 +198,25 @@ code then verifies as a final step.
|
||||
- Triggering an exception and verifying it (as in Try / Catch / Throw - see the
|
||||
[CException](https://github.com/ThrowTheSwitch/CException) project).
|
||||
|
||||
##### `TEST_PASS()`
|
||||
#### `TEST_PASS()`
|
||||
|
||||
##### `TEST_PASS_MESSAGE("message")`
|
||||
#### `TEST_PASS_MESSAGE("message")`
|
||||
|
||||
This will abort the remainder of the test, but count the test as a pass. Under
|
||||
normal circumstances, it is not necessary to include this macro in your tests...
|
||||
a lack of failure will automatically be counted as a `PASS`. It is occasionally
|
||||
useful for tests with `#ifdef`s and such.
|
||||
|
||||
##### `TEST_IGNORE()`
|
||||
#### `TEST_IGNORE()`
|
||||
|
||||
##### `TEST_IGNORE_MESSAGE("message")`
|
||||
#### `TEST_IGNORE_MESSAGE("message")`
|
||||
|
||||
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).
|
||||
|
||||
##### `TEST_MESSAGE(message)`
|
||||
#### `TEST_MESSAGE(message)`
|
||||
|
||||
This can be useful for outputting `INFO` messages into the Unity output stream
|
||||
without actually ending the test. Like pass and fail messages, it will be output
|
||||
@@ -233,27 +224,27 @@ with the filename and line number.
|
||||
|
||||
### Boolean
|
||||
|
||||
##### `TEST_ASSERT (condition)`
|
||||
#### `TEST_ASSERT (condition)`
|
||||
|
||||
##### `TEST_ASSERT_TRUE (condition)`
|
||||
#### `TEST_ASSERT_TRUE (condition)`
|
||||
|
||||
##### `TEST_ASSERT_FALSE (condition)`
|
||||
#### `TEST_ASSERT_FALSE (condition)`
|
||||
|
||||
##### `TEST_ASSERT_UNLESS (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_NULL (pointer)`
|
||||
|
||||
##### `TEST_ASSERT_NOT_NULL (pointer)`
|
||||
#### `TEST_ASSERT_NOT_NULL (pointer)`
|
||||
|
||||
Verify if a pointer is or is not NULL.
|
||||
|
||||
##### `TEST_ASSERT_EMPTY (pointer)`
|
||||
#### `TEST_ASSERT_EMPTY (pointer)`
|
||||
|
||||
##### `TEST_ASSERT_NOT_EMPTY (pointer)`
|
||||
#### `TEST_ASSERT_NOT_EMPTY (pointer)`
|
||||
|
||||
Verify if the first element dereferenced from a pointer is or is not zero. This
|
||||
is particularly useful for checking for empty (or non-empty) null-terminated
|
||||
@@ -268,26 +259,25 @@ 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_INT (expected, actual)`
|
||||
|
||||
##### `TEST_ASSERT_EQUAL_INT8 (expected, actual)`
|
||||
#### `TEST_ASSERT_EQUAL_INT8 (expected, actual)`
|
||||
|
||||
##### `TEST_ASSERT_EQUAL_INT16 (expected, actual)`
|
||||
#### `TEST_ASSERT_EQUAL_INT16 (expected, actual)`
|
||||
|
||||
##### `TEST_ASSERT_EQUAL_INT32 (expected, actual)`
|
||||
#### `TEST_ASSERT_EQUAL_INT32 (expected, actual)`
|
||||
|
||||
##### `TEST_ASSERT_EQUAL_INT64 (expected, actual)`
|
||||
#### `TEST_ASSERT_EQUAL_INT64 (expected, actual)`
|
||||
|
||||
##### `TEST_ASSERT_EQUAL_UINT (expected, actual)`
|
||||
#### `TEST_ASSERT_EQUAL_UINT (expected, actual)`
|
||||
|
||||
##### `TEST_ASSERT_EQUAL_UINT8 (expected, actual)`
|
||||
#### `TEST_ASSERT_EQUAL_UINT8 (expected, actual)`
|
||||
|
||||
##### `TEST_ASSERT_EQUAL_UINT16 (expected, actual)`
|
||||
#### `TEST_ASSERT_EQUAL_UINT16 (expected, actual)`
|
||||
|
||||
##### `TEST_ASSERT_EQUAL_UINT32 (expected, actual)`
|
||||
|
||||
##### `TEST_ASSERT_EQUAL_UINT64 (expected, actual)`
|
||||
#### `TEST_ASSERT_EQUAL_UINT32 (expected, actual)`
|
||||
|
||||
#### `TEST_ASSERT_EQUAL_UINT64 (expected, actual)`
|
||||
|
||||
### Unsigned Integers (of all sizes) in Hexadecimal
|
||||
|
||||
@@ -295,16 +285,15 @@ 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_HEX (expected, actual)`
|
||||
|
||||
##### `TEST_ASSERT_EQUAL_HEX8 (expected, actual)`
|
||||
#### `TEST_ASSERT_EQUAL_HEX8 (expected, actual)`
|
||||
|
||||
##### `TEST_ASSERT_EQUAL_HEX16 (expected, actual)`
|
||||
#### `TEST_ASSERT_EQUAL_HEX16 (expected, actual)`
|
||||
|
||||
##### `TEST_ASSERT_EQUAL_HEX32 (expected, actual)`
|
||||
|
||||
##### `TEST_ASSERT_EQUAL_HEX64 (expected, actual)`
|
||||
#### `TEST_ASSERT_EQUAL_HEX32 (expected, actual)`
|
||||
|
||||
#### `TEST_ASSERT_EQUAL_HEX64 (expected, actual)`
|
||||
|
||||
### Characters
|
||||
|
||||
@@ -312,36 +301,30 @@ While you can use the 8-bit integer assertions to compare `char`, another option
|
||||
to use this specialized assertion which will show printable characters as printables,
|
||||
otherwise showing the HEX escape code for the characters.
|
||||
|
||||
##### `TEST_ASSERT_EQUAL_CHAR (expected, actual)`
|
||||
|
||||
#### `TEST_ASSERT_EQUAL_CHAR (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)`
|
||||
#### `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)`
|
||||
#### `TEST_ASSERT_BITS_HIGH (mask, actual)`
|
||||
|
||||
Asserts the masked bits of the `actual` parameter are high.
|
||||
|
||||
|
||||
##### `TEST_ASSERT_BITS_LOW (mask, actual)`
|
||||
#### `TEST_ASSERT_BITS_LOW (mask, actual)`
|
||||
|
||||
Asserts the masked bits of the `actual` parameter are low.
|
||||
|
||||
|
||||
##### `TEST_ASSERT_BIT_HIGH (bit, actual)`
|
||||
#### `TEST_ASSERT_BIT_HIGH (bit, actual)`
|
||||
|
||||
Asserts the specified bit of the `actual` parameter is high.
|
||||
|
||||
|
||||
##### `TEST_ASSERT_BIT_LOW (bit, actual)`
|
||||
#### `TEST_ASSERT_BIT_LOW (bit, actual)`
|
||||
|
||||
Asserts the specified bit of the `actual` parameter is low.
|
||||
|
||||
@@ -352,16 +335,15 @@ than `threshold` (exclusive). For example, if the threshold value is 0 for the
|
||||
greater than assertion will fail if it is 0 or less. There are assertions for
|
||||
all the various sizes of ints, as for the equality assertions. Some examples:
|
||||
|
||||
##### `TEST_ASSERT_GREATER_THAN_INT8 (threshold, actual)`
|
||||
#### `TEST_ASSERT_GREATER_THAN_INT8 (threshold, actual)`
|
||||
|
||||
##### `TEST_ASSERT_GREATER_OR_EQUAL_INT16 (threshold, actual)`
|
||||
#### `TEST_ASSERT_GREATER_OR_EQUAL_INT16 (threshold, actual)`
|
||||
|
||||
##### `TEST_ASSERT_LESS_THAN_INT32 (threshold, actual)`
|
||||
#### `TEST_ASSERT_LESS_THAN_INT32 (threshold, actual)`
|
||||
|
||||
##### `TEST_ASSERT_LESS_OR_EQUAL_UINT (threshold, actual)`
|
||||
|
||||
##### `TEST_ASSERT_NOT_EQUAL_UINT8 (threshold, actual)`
|
||||
#### `TEST_ASSERT_LESS_OR_EQUAL_UINT (threshold, actual)`
|
||||
|
||||
#### `TEST_ASSERT_NOT_EQUAL_UINT8 (threshold, actual)`
|
||||
|
||||
### Integer Ranges (of all sizes)
|
||||
|
||||
@@ -370,60 +352,57 @@ These assertions verify that the `expected` parameter is within +/- `delta`
|
||||
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_INT_WITHIN (delta, expected, actual)`
|
||||
|
||||
##### `TEST_ASSERT_INT8_WITHIN (delta, expected, actual)`
|
||||
#### `TEST_ASSERT_INT8_WITHIN (delta, expected, actual)`
|
||||
|
||||
##### `TEST_ASSERT_INT16_WITHIN (delta, expected, actual)`
|
||||
#### `TEST_ASSERT_INT16_WITHIN (delta, expected, actual)`
|
||||
|
||||
##### `TEST_ASSERT_INT32_WITHIN (delta, expected, actual)`
|
||||
#### `TEST_ASSERT_INT32_WITHIN (delta, expected, actual)`
|
||||
|
||||
##### `TEST_ASSERT_INT64_WITHIN (delta, expected, actual)`
|
||||
#### `TEST_ASSERT_INT64_WITHIN (delta, expected, actual)`
|
||||
|
||||
##### `TEST_ASSERT_UINT_WITHIN (delta, expected, actual)`
|
||||
#### `TEST_ASSERT_UINT_WITHIN (delta, expected, actual)`
|
||||
|
||||
##### `TEST_ASSERT_UINT8_WITHIN (delta, expected, actual)`
|
||||
#### `TEST_ASSERT_UINT8_WITHIN (delta, expected, actual)`
|
||||
|
||||
##### `TEST_ASSERT_UINT16_WITHIN (delta, expected, actual)`
|
||||
#### `TEST_ASSERT_UINT16_WITHIN (delta, expected, actual)`
|
||||
|
||||
##### `TEST_ASSERT_UINT32_WITHIN (delta, expected, actual)`
|
||||
#### `TEST_ASSERT_UINT32_WITHIN (delta, expected, actual)`
|
||||
|
||||
##### `TEST_ASSERT_UINT64_WITHIN (delta, expected, actual)`
|
||||
#### `TEST_ASSERT_UINT64_WITHIN (delta, expected, actual)`
|
||||
|
||||
##### `TEST_ASSERT_HEX_WITHIN (delta, expected, actual)`
|
||||
#### `TEST_ASSERT_HEX_WITHIN (delta, expected, actual)`
|
||||
|
||||
##### `TEST_ASSERT_HEX8_WITHIN (delta, expected, actual)`
|
||||
#### `TEST_ASSERT_HEX8_WITHIN (delta, expected, actual)`
|
||||
|
||||
##### `TEST_ASSERT_HEX16_WITHIN (delta, expected, actual)`
|
||||
#### `TEST_ASSERT_HEX16_WITHIN (delta, expected, actual)`
|
||||
|
||||
##### `TEST_ASSERT_HEX32_WITHIN (delta, expected, actual)`
|
||||
#### `TEST_ASSERT_HEX32_WITHIN (delta, expected, actual)`
|
||||
|
||||
##### `TEST_ASSERT_HEX64_WITHIN (delta, expected, actual)`
|
||||
#### `TEST_ASSERT_HEX64_WITHIN (delta, expected, actual)`
|
||||
|
||||
##### `TEST_ASSERT_CHAR_WITHIN (delta, expected, actual)`
|
||||
#### `TEST_ASSERT_CHAR_WITHIN (delta, expected, actual)`
|
||||
|
||||
### Structs and Strings
|
||||
|
||||
##### `TEST_ASSERT_EQUAL_PTR (expected, actual)`
|
||||
#### `TEST_ASSERT_EQUAL_PTR (expected, actual)`
|
||||
|
||||
Asserts that the pointers point to the same memory location.
|
||||
|
||||
|
||||
##### `TEST_ASSERT_EQUAL_STRING (expected, actual)`
|
||||
#### `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)`
|
||||
#### `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
|
||||
@@ -438,43 +417,43 @@ For array of strings comparison behavior, see comments for
|
||||
Assertions fail upon the first element in the compared arrays found not to
|
||||
match. Failure messages specify the array index of the failed comparison.
|
||||
|
||||
##### `TEST_ASSERT_EQUAL_INT_ARRAY (expected, actual, num_elements)`
|
||||
#### `TEST_ASSERT_EQUAL_INT_ARRAY (expected, actual, num_elements)`
|
||||
|
||||
##### `TEST_ASSERT_EQUAL_INT8_ARRAY (expected, actual, num_elements)`
|
||||
#### `TEST_ASSERT_EQUAL_INT8_ARRAY (expected, actual, num_elements)`
|
||||
|
||||
##### `TEST_ASSERT_EQUAL_INT16_ARRAY (expected, actual, num_elements)`
|
||||
#### `TEST_ASSERT_EQUAL_INT16_ARRAY (expected, actual, num_elements)`
|
||||
|
||||
##### `TEST_ASSERT_EQUAL_INT32_ARRAY (expected, actual, num_elements)`
|
||||
#### `TEST_ASSERT_EQUAL_INT32_ARRAY (expected, actual, num_elements)`
|
||||
|
||||
##### `TEST_ASSERT_EQUAL_INT64_ARRAY (expected, actual, num_elements)`
|
||||
#### `TEST_ASSERT_EQUAL_INT64_ARRAY (expected, actual, num_elements)`
|
||||
|
||||
##### `TEST_ASSERT_EQUAL_UINT_ARRAY (expected, actual, num_elements)`
|
||||
#### `TEST_ASSERT_EQUAL_UINT_ARRAY (expected, actual, num_elements)`
|
||||
|
||||
##### `TEST_ASSERT_EQUAL_UINT8_ARRAY (expected, actual, num_elements)`
|
||||
#### `TEST_ASSERT_EQUAL_UINT8_ARRAY (expected, actual, num_elements)`
|
||||
|
||||
##### `TEST_ASSERT_EQUAL_UINT16_ARRAY (expected, actual, num_elements)`
|
||||
#### `TEST_ASSERT_EQUAL_UINT16_ARRAY (expected, actual, num_elements)`
|
||||
|
||||
##### `TEST_ASSERT_EQUAL_UINT32_ARRAY (expected, actual, num_elements)`
|
||||
#### `TEST_ASSERT_EQUAL_UINT32_ARRAY (expected, actual, num_elements)`
|
||||
|
||||
##### `TEST_ASSERT_EQUAL_UINT64_ARRAY (expected, actual, num_elements)`
|
||||
#### `TEST_ASSERT_EQUAL_UINT64_ARRAY (expected, actual, num_elements)`
|
||||
|
||||
##### `TEST_ASSERT_EQUAL_HEX_ARRAY (expected, actual, num_elements)`
|
||||
#### `TEST_ASSERT_EQUAL_HEX_ARRAY (expected, actual, num_elements)`
|
||||
|
||||
##### `TEST_ASSERT_EQUAL_HEX8_ARRAY (expected, actual, num_elements)`
|
||||
#### `TEST_ASSERT_EQUAL_HEX8_ARRAY (expected, actual, num_elements)`
|
||||
|
||||
##### `TEST_ASSERT_EQUAL_HEX16_ARRAY (expected, actual, num_elements)`
|
||||
#### `TEST_ASSERT_EQUAL_HEX16_ARRAY (expected, actual, num_elements)`
|
||||
|
||||
##### `TEST_ASSERT_EQUAL_HEX32_ARRAY (expected, actual, num_elements)`
|
||||
#### `TEST_ASSERT_EQUAL_HEX32_ARRAY (expected, actual, num_elements)`
|
||||
|
||||
##### `TEST_ASSERT_EQUAL_HEX64_ARRAY (expected, actual, num_elements)`
|
||||
#### `TEST_ASSERT_EQUAL_HEX64_ARRAY (expected, actual, num_elements)`
|
||||
|
||||
##### `TEST_ASSERT_EQUAL_CHAR_ARRAY (expected, actual, num_elements)`
|
||||
#### `TEST_ASSERT_EQUAL_CHAR_ARRAY (expected, actual, num_elements)`
|
||||
|
||||
##### `TEST_ASSERT_EQUAL_PTR_ARRAY (expected, actual, num_elements)`
|
||||
#### `TEST_ASSERT_EQUAL_PTR_ARRAY (expected, actual, num_elements)`
|
||||
|
||||
##### `TEST_ASSERT_EQUAL_STRING_ARRAY (expected, actual, num_elements)`
|
||||
#### `TEST_ASSERT_EQUAL_STRING_ARRAY (expected, actual, num_elements)`
|
||||
|
||||
##### `TEST_ASSERT_EQUAL_MEMORY_ARRAY (expected, actual, len, num_elements)`
|
||||
#### `TEST_ASSERT_EQUAL_MEMORY_ARRAY (expected, actual, len, num_elements)`
|
||||
|
||||
`len` is the memory in bytes to be compared at each array element.
|
||||
|
||||
@@ -485,37 +464,37 @@ These assertions verify that the `expected` array parameter is within +/- `delta
|
||||
\[10, 12\] and the delta is 3 then the assertion will fail for any value
|
||||
outside the range of \[7 - 13, 9 - 15\].
|
||||
|
||||
##### `TEST_ASSERT_INT_ARRAY_WITHIN (delta, expected, actual, num_elements)`
|
||||
#### `TEST_ASSERT_INT_ARRAY_WITHIN (delta, expected, actual, num_elements)`
|
||||
|
||||
##### `TEST_ASSERT_INT8_ARRAY_WITHIN (delta, expected, actual, num_elements)`
|
||||
#### `TEST_ASSERT_INT8_ARRAY_WITHIN (delta, expected, actual, num_elements)`
|
||||
|
||||
##### `TEST_ASSERT_INT16_ARRAY_WITHIN (delta, expected, actual, num_elements)`
|
||||
#### `TEST_ASSERT_INT16_ARRAY_WITHIN (delta, expected, actual, num_elements)`
|
||||
|
||||
##### `TEST_ASSERT_INT32_ARRAY_WITHIN (delta, expected, actual, num_elements)`
|
||||
#### `TEST_ASSERT_INT32_ARRAY_WITHIN (delta, expected, actual, num_elements)`
|
||||
|
||||
##### `TEST_ASSERT_INT64_ARRAY_WITHIN (delta, expected, actual, num_elements)`
|
||||
#### `TEST_ASSERT_INT64_ARRAY_WITHIN (delta, expected, actual, num_elements)`
|
||||
|
||||
##### `TEST_ASSERT_UINT_ARRAY_WITHIN (delta, expected, actual, num_elements)`
|
||||
#### `TEST_ASSERT_UINT_ARRAY_WITHIN (delta, expected, actual, num_elements)`
|
||||
|
||||
##### `TEST_ASSERT_UINT8_ARRAY_WITHIN (delta, expected, actual, num_elements)`
|
||||
#### `TEST_ASSERT_UINT8_ARRAY_WITHIN (delta, expected, actual, num_elements)`
|
||||
|
||||
##### `TEST_ASSERT_UINT16_ARRAY_WITHIN (delta, expected, actual, num_elements)`
|
||||
#### `TEST_ASSERT_UINT16_ARRAY_WITHIN (delta, expected, actual, num_elements)`
|
||||
|
||||
##### `TEST_ASSERT_UINT32_ARRAY_WITHIN (delta, expected, actual, num_elements)`
|
||||
#### `TEST_ASSERT_UINT32_ARRAY_WITHIN (delta, expected, actual, num_elements)`
|
||||
|
||||
##### `TEST_ASSERT_UINT64_ARRAY_WITHIN (delta, expected, actual, num_elements)`
|
||||
#### `TEST_ASSERT_UINT64_ARRAY_WITHIN (delta, expected, actual, num_elements)`
|
||||
|
||||
##### `TEST_ASSERT_HEX_ARRAY_WITHIN (delta, expected, actual, num_elements)`
|
||||
#### `TEST_ASSERT_HEX_ARRAY_WITHIN (delta, expected, actual, num_elements)`
|
||||
|
||||
##### `TEST_ASSERT_HEX8_ARRAY_WITHIN (delta, expected, actual, num_elements)`
|
||||
#### `TEST_ASSERT_HEX8_ARRAY_WITHIN (delta, expected, actual, num_elements)`
|
||||
|
||||
##### `TEST_ASSERT_HEX16_ARRAY_WITHIN (delta, expected, actual, num_elements)`
|
||||
#### `TEST_ASSERT_HEX16_ARRAY_WITHIN (delta, expected, actual, num_elements)`
|
||||
|
||||
##### `TEST_ASSERT_HEX32_ARRAY_WITHIN (delta, expected, actual, num_elements)`
|
||||
#### `TEST_ASSERT_HEX32_ARRAY_WITHIN (delta, expected, actual, num_elements)`
|
||||
|
||||
##### `TEST_ASSERT_HEX64_ARRAY_WITHIN (delta, expected, actual, num_elements)`
|
||||
#### `TEST_ASSERT_HEX64_ARRAY_WITHIN (delta, expected, actual, num_elements)`
|
||||
|
||||
##### `TEST_ASSERT_CHAR_ARRAY_WITHIN (delta, expected, actual, num_elements)`
|
||||
#### `TEST_ASSERT_CHAR_ARRAY_WITHIN (delta, expected, actual, num_elements)`
|
||||
|
||||
### Each Equal (Arrays to Single Value)
|
||||
|
||||
@@ -568,17 +547,15 @@ match. Failure messages specify the array index of the failed comparison.
|
||||
|
||||
`len` is the memory in bytes to be compared at each array element.
|
||||
|
||||
|
||||
### Floating Point (If enabled)
|
||||
|
||||
##### `TEST_ASSERT_FLOAT_WITHIN (delta, expected, actual)`
|
||||
#### `TEST_ASSERT_FLOAT_WITHIN (delta, expected, actual)`
|
||||
|
||||
Asserts that the `actual` value is within +/- `delta` of the `expected` value.
|
||||
The nature of floating point representation is such that exact evaluations of
|
||||
equality are not guaranteed.
|
||||
|
||||
|
||||
##### `TEST_ASSERT_EQUAL_FLOAT (expected, actual)`
|
||||
#### `TEST_ASSERT_EQUAL_FLOAT (expected, actual)`
|
||||
|
||||
Asserts that the ?actual?value is "close enough to be considered equal" to the
|
||||
`expected` value. If you are curious about the details, refer to the Advanced
|
||||
@@ -586,74 +563,63 @@ Asserting section for more details on this. Omitting a user-specified delta in a
|
||||
floating point assertion is both a shorthand convenience and a requirement of
|
||||
code generation conventions for CMock.
|
||||
|
||||
|
||||
##### `TEST_ASSERT_EQUAL_FLOAT_ARRAY (expected, actual, num_elements)`
|
||||
#### `TEST_ASSERT_EQUAL_FLOAT_ARRAY (expected, actual, num_elements)`
|
||||
|
||||
See Array assertion section for details. Note that individual array element
|
||||
float comparisons are executed using T?EST_ASSERT_EQUAL_FLOAT?.That is, user
|
||||
specified delta comparison values requires a custom-implemented floating point
|
||||
array assertion.
|
||||
|
||||
|
||||
##### `TEST_ASSERT_FLOAT_IS_INF (actual)`
|
||||
#### `TEST_ASSERT_FLOAT_IS_INF (actual)`
|
||||
|
||||
Asserts that `actual` parameter is equivalent to positive infinity floating
|
||||
point representation.
|
||||
|
||||
|
||||
##### `TEST_ASSERT_FLOAT_IS_NEG_INF (actual)`
|
||||
#### `TEST_ASSERT_FLOAT_IS_NEG_INF (actual)`
|
||||
|
||||
Asserts that `actual` parameter is equivalent to negative infinity floating
|
||||
point representation.
|
||||
|
||||
|
||||
##### `TEST_ASSERT_FLOAT_IS_NAN (actual)`
|
||||
#### `TEST_ASSERT_FLOAT_IS_NAN (actual)`
|
||||
|
||||
Asserts that `actual` parameter is a Not A Number floating point representation.
|
||||
|
||||
|
||||
##### `TEST_ASSERT_FLOAT_IS_DETERMINATE (actual)`
|
||||
#### `TEST_ASSERT_FLOAT_IS_DETERMINATE (actual)`
|
||||
|
||||
Asserts that ?actual?parameter is a floating point representation usable for
|
||||
mathematical operations. That is, the `actual` parameter is neither positive
|
||||
infinity nor negative infinity nor Not A Number floating point representations.
|
||||
|
||||
|
||||
##### `TEST_ASSERT_FLOAT_IS_NOT_INF (actual)`
|
||||
#### `TEST_ASSERT_FLOAT_IS_NOT_INF (actual)`
|
||||
|
||||
Asserts that `actual` parameter is a value other than positive infinity floating
|
||||
point representation.
|
||||
|
||||
|
||||
##### `TEST_ASSERT_FLOAT_IS_NOT_NEG_INF (actual)`
|
||||
#### `TEST_ASSERT_FLOAT_IS_NOT_NEG_INF (actual)`
|
||||
|
||||
Asserts that `actual` parameter is a value other than negative infinity floating
|
||||
point representation.
|
||||
|
||||
|
||||
##### `TEST_ASSERT_FLOAT_IS_NOT_NAN (actual)`
|
||||
#### `TEST_ASSERT_FLOAT_IS_NOT_NAN (actual)`
|
||||
|
||||
Asserts that `actual` parameter is a value other than Not A Number floating
|
||||
point representation.
|
||||
|
||||
|
||||
##### `TEST_ASSERT_FLOAT_IS_NOT_DETERMINATE (actual)`
|
||||
#### `TEST_ASSERT_FLOAT_IS_NOT_DETERMINATE (actual)`
|
||||
|
||||
Asserts that `actual` parameter is not usable for mathematical operations. That
|
||||
is, the `actual` parameter is either positive infinity or negative infinity or
|
||||
Not A Number floating point representations.
|
||||
|
||||
|
||||
### Double (If enabled)
|
||||
|
||||
##### `TEST_ASSERT_DOUBLE_WITHIN (delta, expected, actual)`
|
||||
#### `TEST_ASSERT_DOUBLE_WITHIN (delta, expected, actual)`
|
||||
|
||||
Asserts that the `actual` value is within +/- `delta` of the `expected` value.
|
||||
The nature of floating point representation is such that exact evaluations of
|
||||
equality are not guaranteed.
|
||||
|
||||
|
||||
##### `TEST_ASSERT_EQUAL_DOUBLE (expected, actual)`
|
||||
#### `TEST_ASSERT_EQUAL_DOUBLE (expected, actual)`
|
||||
|
||||
Asserts that the `actual` value is "close enough to be considered equal" to the
|
||||
`expected` value. If you are curious about the details, refer to the Advanced
|
||||
@@ -661,64 +627,54 @@ Asserting section for more details. Omitting a user-specified delta in a
|
||||
floating point assertion is both a shorthand convenience and a requirement of
|
||||
code generation conventions for CMock.
|
||||
|
||||
|
||||
##### `TEST_ASSERT_EQUAL_DOUBLE_ARRAY (expected, actual, num_elements)`
|
||||
#### `TEST_ASSERT_EQUAL_DOUBLE_ARRAY (expected, actual, num_elements)`
|
||||
|
||||
See Array assertion section for details. Note that individual array element
|
||||
double comparisons are executed using `TEST_ASSERT_EQUAL_DOUBLE`.That is, user
|
||||
specified delta comparison values requires a custom implemented double array
|
||||
assertion.
|
||||
|
||||
|
||||
##### `TEST_ASSERT_DOUBLE_IS_INF (actual)`
|
||||
#### `TEST_ASSERT_DOUBLE_IS_INF (actual)`
|
||||
|
||||
Asserts that `actual` parameter is equivalent to positive infinity floating
|
||||
point representation.
|
||||
|
||||
|
||||
##### `TEST_ASSERT_DOUBLE_IS_NEG_INF (actual)`
|
||||
#### `TEST_ASSERT_DOUBLE_IS_NEG_INF (actual)`
|
||||
|
||||
Asserts that `actual` parameter is equivalent to negative infinity floating point
|
||||
representation.
|
||||
|
||||
|
||||
##### `TEST_ASSERT_DOUBLE_IS_NAN (actual)`
|
||||
#### `TEST_ASSERT_DOUBLE_IS_NAN (actual)`
|
||||
|
||||
Asserts that `actual` parameter is a Not A Number floating point representation.
|
||||
|
||||
|
||||
##### `TEST_ASSERT_DOUBLE_IS_DETERMINATE (actual)`
|
||||
#### `TEST_ASSERT_DOUBLE_IS_DETERMINATE (actual)`
|
||||
|
||||
Asserts that `actual` parameter is a floating point representation usable for
|
||||
mathematical operations. That is, the ?actual?parameter is neither positive
|
||||
infinity nor negative infinity nor Not A Number floating point representations.
|
||||
|
||||
|
||||
##### `TEST_ASSERT_DOUBLE_IS_NOT_INF (actual)`
|
||||
#### `TEST_ASSERT_DOUBLE_IS_NOT_INF (actual)`
|
||||
|
||||
Asserts that `actual` parameter is a value other than positive infinity floating
|
||||
point representation.
|
||||
|
||||
|
||||
##### `TEST_ASSERT_DOUBLE_IS_NOT_NEG_INF (actual)`
|
||||
#### `TEST_ASSERT_DOUBLE_IS_NOT_NEG_INF (actual)`
|
||||
|
||||
Asserts that `actual` parameter is a value other than negative infinity floating
|
||||
point representation.
|
||||
|
||||
|
||||
##### `TEST_ASSERT_DOUBLE_IS_NOT_NAN (actual)`
|
||||
#### `TEST_ASSERT_DOUBLE_IS_NOT_NAN (actual)`
|
||||
|
||||
Asserts that `actual` parameter is a value other than Not A Number floating
|
||||
point representation.
|
||||
|
||||
|
||||
##### `TEST_ASSERT_DOUBLE_IS_NOT_DETERMINATE (actual)`
|
||||
#### `TEST_ASSERT_DOUBLE_IS_NOT_DETERMINATE (actual)`
|
||||
|
||||
Asserts that `actual` parameter is not usable for mathematical operations. That
|
||||
is, the `actual` parameter is either positive infinity or negative infinity or
|
||||
Not A Number floating point representations.
|
||||
|
||||
|
||||
## Advanced Asserting: Details On Tricky Assertions
|
||||
|
||||
This section helps you understand how to deal with some of the trickier
|
||||
@@ -727,7 +683,6 @@ the under-the-hood details of Unity's assertion mechanisms. If you're one of
|
||||
those people who likes to know what is going on in the background, read on. If
|
||||
not, feel free to ignore the rest of this document until you need it.
|
||||
|
||||
|
||||
### How do the EQUAL assertions work for FLOAT and DOUBLE?
|
||||
|
||||
As you may know, directly checking for equality between a pair of floats or a
|
||||
@@ -768,7 +723,6 @@ assertions less strict, you can change these multipliers to whatever you like by
|
||||
defining UNITY_FLOAT_PRECISION and UNITY_DOUBLE_PRECISION. See Unity
|
||||
documentation for more.
|
||||
|
||||
|
||||
### How do we deal with targets with non-standard int sizes?
|
||||
|
||||
It's "fun" that C is a standard where something as fundamental as an integer
|
||||
@@ -827,5 +781,4 @@ operations, particularly `TEST_ASSERT_INT_WITHIN`.Such assertions might wrap
|
||||
your `int` in the wrong place, and you could experience false failures. You can
|
||||
always back down to a simple `TEST_ASSERT` and do the operations yourself.
|
||||
|
||||
|
||||
*Find The Latest of This And More at [ThrowTheSwitch.org](https://throwtheswitch.org)*
|
||||
|
||||
@@ -22,7 +22,6 @@ challenging to build. From a more positive perspective, it is also proof that a
|
||||
great deal of complexity can be centralized primarily to one place to
|
||||
provide a more consistent and simple experience elsewhere.
|
||||
|
||||
|
||||
### Using These Options
|
||||
|
||||
It doesn't matter if you're using a target-specific compiler and a simulator or
|
||||
@@ -58,8 +57,7 @@ certainly not every compiler you are likely to encounter. Therefore, Unity has a
|
||||
number of features for helping to adjust itself to match your required integer
|
||||
sizes. It starts off by trying to do it automatically.
|
||||
|
||||
|
||||
##### `UNITY_EXCLUDE_STDINT_H`
|
||||
#### `UNITY_EXCLUDE_STDINT_H`
|
||||
|
||||
The first thing that Unity does to guess your types is check `stdint.h`.
|
||||
This file includes defines like `UINT_MAX` that Unity can use to
|
||||
@@ -70,18 +68,19 @@ That way, Unity will know to skip the inclusion of this file and you won't
|
||||
be left with a compiler error.
|
||||
|
||||
_Example:_
|
||||
|
||||
```C
|
||||
#define UNITY_EXCLUDE_STDINT_H
|
||||
```
|
||||
|
||||
|
||||
##### `UNITY_EXCLUDE_LIMITS_H`
|
||||
#### `UNITY_EXCLUDE_LIMITS_H`
|
||||
|
||||
The second attempt to guess your types is to check `limits.h`. Some compilers
|
||||
that don't support `stdint.h` could include `limits.h` instead. If you don't
|
||||
want Unity to check this file either, define this to make it skip the inclusion.
|
||||
|
||||
_Example:_
|
||||
|
||||
```C
|
||||
#define UNITY_EXCLUDE_LIMITS_H
|
||||
```
|
||||
@@ -91,19 +90,18 @@ do the configuration yourself. Don't worry. Even this isn't too bad... there are
|
||||
just a handful of defines that you are going to specify if you don't like the
|
||||
defaults.
|
||||
|
||||
|
||||
##### `UNITY_INT_WIDTH`
|
||||
#### `UNITY_INT_WIDTH`
|
||||
|
||||
Define this to be the number of bits an `int` takes up on your system. The
|
||||
default, if not autodetected, is 32 bits.
|
||||
|
||||
_Example:_
|
||||
|
||||
```C
|
||||
#define UNITY_INT_WIDTH 16
|
||||
```
|
||||
|
||||
|
||||
##### `UNITY_LONG_WIDTH`
|
||||
#### `UNITY_LONG_WIDTH`
|
||||
|
||||
Define this to be the number of bits a `long` takes up on your system. The
|
||||
default, if not autodetected, is 32 bits. This is used to figure out what kind
|
||||
@@ -112,12 +110,12 @@ of 64-bit support your system can handle. Does it need to specify a `long` or a
|
||||
ignored.
|
||||
|
||||
_Example:_
|
||||
|
||||
```C
|
||||
#define UNITY_LONG_WIDTH 16
|
||||
```
|
||||
|
||||
|
||||
##### `UNITY_POINTER_WIDTH`
|
||||
#### `UNITY_POINTER_WIDTH`
|
||||
|
||||
Define this to be the number of bits a pointer takes up on your system. The
|
||||
default, if not autodetected, is 32-bits. If you're getting ugly compiler
|
||||
@@ -129,6 +127,7 @@ width of 23-bit), choose the next power of two (in this case 32-bit).
|
||||
_Supported values:_ 16, 32 and 64
|
||||
|
||||
_Example:_
|
||||
|
||||
```C
|
||||
// Choose on of these #defines to set your pointer width (if not autodetected)
|
||||
//#define UNITY_POINTER_WIDTH 16
|
||||
@@ -136,8 +135,7 @@ _Example:_
|
||||
#define UNITY_POINTER_WIDTH 64 // Set UNITY_POINTER_WIDTH to 64-bit
|
||||
```
|
||||
|
||||
|
||||
##### `UNITY_SUPPORT_64`
|
||||
#### `UNITY_SUPPORT_64`
|
||||
|
||||
Unity will automatically include 64-bit support if it auto-detects it, or if
|
||||
your `int`, `long`, or pointer widths are greater than 32-bits. Define this to
|
||||
@@ -146,11 +144,11 @@ can be a significant size and speed impact to enabling 64-bit support on small
|
||||
targets, so don't define it if you don't need it.
|
||||
|
||||
_Example:_
|
||||
|
||||
```C
|
||||
#define UNITY_SUPPORT_64
|
||||
```
|
||||
|
||||
|
||||
### Floating Point Types
|
||||
|
||||
In the embedded world, it's not uncommon for targets to have no support for
|
||||
@@ -160,14 +158,13 @@ are always available in at least one size. Floating point, on the other hand, is
|
||||
sometimes not available at all. Trying to include `float.h` on these platforms
|
||||
would result in an error. This leaves manual configuration as the only option.
|
||||
|
||||
#### `UNITY_INCLUDE_FLOAT`
|
||||
|
||||
##### `UNITY_INCLUDE_FLOAT`
|
||||
#### `UNITY_EXCLUDE_FLOAT`
|
||||
|
||||
##### `UNITY_EXCLUDE_FLOAT`
|
||||
#### `UNITY_INCLUDE_DOUBLE`
|
||||
|
||||
##### `UNITY_INCLUDE_DOUBLE`
|
||||
|
||||
##### `UNITY_EXCLUDE_DOUBLE`
|
||||
#### `UNITY_EXCLUDE_DOUBLE`
|
||||
|
||||
By default, Unity guesses that you will want single precision floating point
|
||||
support, but not double precision. It's easy to change either of these using the
|
||||
@@ -176,14 +173,14 @@ suits your needs. For features that are enabled, the following floating point
|
||||
options also become available.
|
||||
|
||||
_Example:_
|
||||
|
||||
```C
|
||||
//what manner of strange processor is this?
|
||||
#define UNITY_EXCLUDE_FLOAT
|
||||
#define UNITY_INCLUDE_DOUBLE
|
||||
```
|
||||
|
||||
|
||||
##### `UNITY_EXCLUDE_FLOAT_PRINT`
|
||||
#### `UNITY_EXCLUDE_FLOAT_PRINT`
|
||||
|
||||
Unity aims for as small of a footprint as possible and avoids most standard
|
||||
library calls (some embedded platforms don’t have a standard library!). Because
|
||||
@@ -196,24 +193,24 @@ can use this define to instead respond to a failed assertion with a message like
|
||||
point assertions, use these options to give more explicit failure messages.
|
||||
|
||||
_Example:_
|
||||
|
||||
```C
|
||||
#define UNITY_EXCLUDE_FLOAT_PRINT
|
||||
```
|
||||
|
||||
|
||||
##### `UNITY_FLOAT_TYPE`
|
||||
#### `UNITY_FLOAT_TYPE`
|
||||
|
||||
If enabled, Unity assumes you want your `FLOAT` asserts to compare standard C
|
||||
floats. If your compiler supports a specialty floating point type, you can
|
||||
always override this behavior by using this definition.
|
||||
|
||||
_Example:_
|
||||
|
||||
```C
|
||||
#define UNITY_FLOAT_TYPE float16_t
|
||||
```
|
||||
|
||||
|
||||
##### `UNITY_DOUBLE_TYPE`
|
||||
#### `UNITY_DOUBLE_TYPE`
|
||||
|
||||
If enabled, Unity assumes you want your `DOUBLE` asserts to compare standard C
|
||||
doubles. If you would like to change this, you can specify something else by
|
||||
@@ -222,14 +219,14 @@ could enable gargantuan floating point types on your 64-bit processor instead of
|
||||
the standard `double`.
|
||||
|
||||
_Example:_
|
||||
|
||||
```C
|
||||
#define UNITY_DOUBLE_TYPE long double
|
||||
```
|
||||
|
||||
#### `UNITY_FLOAT_PRECISION`
|
||||
|
||||
##### `UNITY_FLOAT_PRECISION`
|
||||
|
||||
##### `UNITY_DOUBLE_PRECISION`
|
||||
#### `UNITY_DOUBLE_PRECISION`
|
||||
|
||||
If you look up `UNITY_ASSERT_EQUAL_FLOAT` and `UNITY_ASSERT_EQUAL_DOUBLE` as
|
||||
documented in the big daddy Unity Assertion Guide, you will learn that they are
|
||||
@@ -243,14 +240,14 @@ For further details on how this works, see the appendix of the Unity Assertion
|
||||
Guide.
|
||||
|
||||
_Example:_
|
||||
|
||||
```C
|
||||
#define UNITY_FLOAT_PRECISION 0.001f
|
||||
```
|
||||
|
||||
|
||||
### Miscellaneous
|
||||
|
||||
##### `UNITY_EXCLUDE_STDDEF_H`
|
||||
#### `UNITY_EXCLUDE_STDDEF_H`
|
||||
|
||||
Unity uses the `NULL` macro, which defines the value of a null pointer constant,
|
||||
defined in `stddef.h` by default. If you want to provide
|
||||
@@ -258,11 +255,11 @@ your own macro for this, you should exclude the `stddef.h` header file by adding
|
||||
define to your configuration.
|
||||
|
||||
_Example:_
|
||||
|
||||
```C
|
||||
#define UNITY_EXCLUDE_STDDEF_H
|
||||
```
|
||||
|
||||
|
||||
#### `UNITY_INCLUDE_PRINT_FORMATTED`
|
||||
|
||||
Unity provides a simple (and very basic) printf-like string output implementation,
|
||||
@@ -282,6 +279,7 @@ which is able to print a string modified by the following format string modifier
|
||||
- __%%__ - The "%" symbol (escaped)
|
||||
|
||||
_Example:_
|
||||
|
||||
```C
|
||||
#define UNITY_INCLUDE_PRINT_FORMATTED
|
||||
|
||||
@@ -300,7 +298,6 @@ TEST_PRINTF("\n");
|
||||
TEST_PRINTF("Multiple (%d) (%i) (%u) (%x)\n", -100, 0, 200, 0x12345);
|
||||
```
|
||||
|
||||
|
||||
### Toolset Customization
|
||||
|
||||
In addition to the options listed above, there are a number of other options
|
||||
@@ -310,14 +307,13 @@ certain platforms, particularly those running in simulators, may need to jump
|
||||
through extra hoops to run properly. These macros will help in those
|
||||
situations.
|
||||
|
||||
#### `UNITY_OUTPUT_CHAR(a)`
|
||||
|
||||
##### `UNITY_OUTPUT_CHAR(a)`
|
||||
#### `UNITY_OUTPUT_FLUSH()`
|
||||
|
||||
##### `UNITY_OUTPUT_FLUSH()`
|
||||
#### `UNITY_OUTPUT_START()`
|
||||
|
||||
##### `UNITY_OUTPUT_START()`
|
||||
|
||||
##### `UNITY_OUTPUT_COMPLETE()`
|
||||
#### `UNITY_OUTPUT_COMPLETE()`
|
||||
|
||||
By default, Unity prints its results to `stdout` as it runs. This works
|
||||
perfectly fine in most situations where you are using a native compiler for
|
||||
@@ -333,6 +329,7 @@ _Example:_
|
||||
Say you are forced to run your test suite on an embedded processor with no
|
||||
`stdout` option. You decide to route your test result output to a custom serial
|
||||
`RS232_putc()` function you wrote like thus:
|
||||
|
||||
```C
|
||||
#include "RS232_header.h"
|
||||
...
|
||||
@@ -346,44 +343,43 @@ _Note:_
|
||||
`UNITY_OUTPUT_FLUSH()` can be set to the standard out flush function simply by
|
||||
specifying `UNITY_USE_FLUSH_STDOUT`. No other defines are required.
|
||||
|
||||
#### `UNITY_OUTPUT_FOR_ECLIPSE`
|
||||
|
||||
##### `UNITY_OUTPUT_FOR_ECLIPSE`
|
||||
#### `UNITY_OUTPUT_FOR_IAR_WORKBENCH`
|
||||
|
||||
##### `UNITY_OUTPUT_FOR_IAR_WORKBENCH`
|
||||
|
||||
##### `UNITY_OUTPUT_FOR_QT_CREATOR`
|
||||
#### `UNITY_OUTPUT_FOR_QT_CREATOR`
|
||||
|
||||
When managing your own builds, it is often handy to have messages output in a format which is
|
||||
recognized by your IDE. These are some standard formats which can be supported. If you're using
|
||||
Ceedling to manage your builds, it is better to stick with the standard format (leaving these
|
||||
all undefined) and allow Ceedling to use its own decorators.
|
||||
|
||||
|
||||
##### `UNITY_PTR_ATTRIBUTE`
|
||||
#### `UNITY_PTR_ATTRIBUTE`
|
||||
|
||||
Some compilers require a custom attribute to be assigned to pointers, like
|
||||
`near` or `far`. In these cases, you can give Unity a safe default for these by
|
||||
defining this option with the attribute you would like.
|
||||
|
||||
_Example:_
|
||||
|
||||
```C
|
||||
#define UNITY_PTR_ATTRIBUTE __attribute__((far))
|
||||
#define UNITY_PTR_ATTRIBUTE near
|
||||
```
|
||||
|
||||
##### `UNITY_PRINT_EOL`
|
||||
#### `UNITY_PRINT_EOL`
|
||||
|
||||
By default, Unity outputs \n at the end of each line of output. This is easy
|
||||
to parse by the scripts, by Ceedling, etc, but it might not be ideal for YOUR
|
||||
system. Feel free to override this and to make it whatever you wish.
|
||||
|
||||
_Example:_
|
||||
|
||||
```C
|
||||
#define UNITY_PRINT_EOL { UNITY_OUTPUT_CHAR('\r'); UNITY_OUTPUT_CHAR('\n'); }
|
||||
```
|
||||
|
||||
|
||||
##### `UNITY_EXCLUDE_DETAILS`
|
||||
#### `UNITY_EXCLUDE_DETAILS`
|
||||
|
||||
This is an option for if you absolutely must squeeze every byte of memory out of
|
||||
your system. Unity stores a set of internal scratchpads which are used to pass
|
||||
@@ -392,11 +388,12 @@ report which function or argument flagged an error. If you're not using CMock an
|
||||
you're not using these details for other things, then you can exclude them.
|
||||
|
||||
_Example:_
|
||||
|
||||
```C
|
||||
#define UNITY_EXCLUDE_DETAILS
|
||||
```
|
||||
|
||||
##### `UNITY_PRINT_TEST_CONTEXT`
|
||||
#### `UNITY_PRINT_TEST_CONTEXT`
|
||||
|
||||
This option allows you to specify your own function to print additional context
|
||||
as part of the error message when a test has failed. It can be useful if you
|
||||
@@ -404,6 +401,7 @@ want to output some specific information about the state of the test at the poin
|
||||
of failure, and `UNITY_SET_DETAILS` isn't flexible enough for your needs.
|
||||
|
||||
_Example:_
|
||||
|
||||
```C
|
||||
#define UNITY_PRINT_TEST_CONTEXT PrintIterationCount
|
||||
|
||||
@@ -415,7 +413,7 @@ void PrintIterationCount(void)
|
||||
}
|
||||
```
|
||||
|
||||
##### `UNITY_EXCLUDE_SETJMP`
|
||||
#### `UNITY_EXCLUDE_SETJMP`
|
||||
|
||||
If your embedded system doesn't support the standard library setjmp, you can
|
||||
exclude Unity's reliance on this by using this define. This dropped dependence
|
||||
@@ -425,23 +423,28 @@ compiler doesn't support setjmp, you wouldn't have had the memory space for thos
|
||||
things anyway, though... so this option exists for those situations.
|
||||
|
||||
_Example:_
|
||||
|
||||
```C
|
||||
#define UNITY_EXCLUDE_SETJMP
|
||||
```
|
||||
|
||||
##### `UNITY_OUTPUT_COLOR`
|
||||
#### `UNITY_OUTPUT_COLOR`
|
||||
|
||||
If you want to add color using ANSI escape codes you can use this define.
|
||||
|
||||
_Example:_
|
||||
|
||||
```C
|
||||
#define UNITY_OUTPUT_COLOR
|
||||
```
|
||||
|
||||
##### `UNITY_SHORTHAND_AS_INT`
|
||||
##### `UNITY_SHORTHAND_AS_MEM`
|
||||
##### `UNITY_SHORTHAND_AS_RAW`
|
||||
##### `UNITY_SHORTHAND_AS_NONE`
|
||||
#### `UNITY_SHORTHAND_AS_INT`
|
||||
|
||||
#### `UNITY_SHORTHAND_AS_MEM`
|
||||
|
||||
#### `UNITY_SHORTHAND_AS_RAW`
|
||||
|
||||
#### `UNITY_SHORTHAND_AS_NONE`
|
||||
|
||||
These options give you control of the `TEST_ASSERT_EQUAL` and the
|
||||
`TEST_ASSERT_NOT_EQUAL` shorthand assertions. Historically, Unity treated the
|
||||
@@ -482,8 +485,7 @@ require special help. This special help will usually reside in one of two
|
||||
places: the `main()` function or the `RUN_TEST` macro. Let's look at how these
|
||||
work.
|
||||
|
||||
|
||||
##### `main()`
|
||||
### `main()`
|
||||
|
||||
Each test module is compiled and run on its own, separate from the other test
|
||||
files in your project. Each test file, therefore, has a `main` function. This
|
||||
@@ -515,8 +517,7 @@ after all the test cases have completed. This allows you to do any needed
|
||||
system-wide setup or teardown that might be required for your special
|
||||
circumstances.
|
||||
|
||||
|
||||
##### `RUN_TEST`
|
||||
#### `RUN_TEST`
|
||||
|
||||
The `RUN_TEST` macro is called with each test case function. Its job is to
|
||||
perform whatever setup and teardown is necessary for executing a single test
|
||||
@@ -552,12 +553,10 @@ each result set. Again, you could do this by adding lines to this macro. Updates
|
||||
to this macro are for the occasions when you need an action before or after
|
||||
every single test case throughout your entire suite of tests.
|
||||
|
||||
|
||||
## Happy Porting
|
||||
|
||||
The defines and macros in this guide should help you port Unity to just about
|
||||
any C target we can imagine. If you run into a snag or two, don't be afraid of
|
||||
asking for help on the forums. We love a good challenge!
|
||||
|
||||
|
||||
*Find The Latest of This And More at [ThrowTheSwitch.org](https://throwtheswitch.org)*
|
||||
|
||||
@@ -17,7 +17,6 @@ rules. Unity has been used with many compilers, including GCC, IAR, Clang,
|
||||
Green Hills, Microchip, and MS Visual Studio. It's not much work to get it to
|
||||
work with a new target.
|
||||
|
||||
|
||||
### Overview of the Documents
|
||||
|
||||
#### Unity Assertions reference
|
||||
@@ -26,21 +25,18 @@ This document will guide you through all the assertion options provided by
|
||||
Unity. This is going to be your unit testing bread and butter. You'll spend more
|
||||
time with assertions than any other part of Unity.
|
||||
|
||||
|
||||
#### Unity Assertions Cheat Sheet
|
||||
|
||||
This document contains an abridged summary of the assertions described in the
|
||||
previous document. It's perfect for printing and referencing while you
|
||||
familiarize yourself with Unity's options.
|
||||
|
||||
|
||||
#### Unity Configuration Guide
|
||||
|
||||
This document is the one to reference when you are going to use Unity with a new
|
||||
target or compiler. It'll guide you through the configuration options and will
|
||||
help you customize your testing experience to meet your needs.
|
||||
|
||||
|
||||
#### Unity Helper Scripts
|
||||
|
||||
This document describes the helper scripts that are available for simplifying
|
||||
@@ -49,7 +45,6 @@ included in the auto directory of your Unity installation. Neither Ruby nor
|
||||
these scripts are necessary for using Unity. They are provided as a convenience
|
||||
for those who wish to use them.
|
||||
|
||||
|
||||
#### Unity License
|
||||
|
||||
What's an open source project without a license file? This brief document
|
||||
@@ -57,7 +52,6 @@ describes the terms you're agreeing to when you use this software. Basically, we
|
||||
want it to be useful to you in whatever context you want to use it, but please
|
||||
don't blame us if you run into problems.
|
||||
|
||||
|
||||
### Overview of the Folders
|
||||
|
||||
If you have obtained Unity through Github or something similar, you might be
|
||||
@@ -82,7 +76,6 @@ everything is configured properly.
|
||||
- `auto` - Here you will find helpful Ruby scripts for simplifying your test
|
||||
workflow. They are purely optional and are not required to make use of Unity.
|
||||
|
||||
|
||||
## How to Create A Test File
|
||||
|
||||
Test files are C files. Most often you will create a single test file for each C
|
||||
@@ -156,21 +149,27 @@ For that sort of thing, you're going to want to look at the configuration guide.
|
||||
This should be enough to get you going, though.
|
||||
|
||||
### Running Test Functions
|
||||
|
||||
When writing your own `main()` functions, for a test-runner. There are two ways
|
||||
to execute the test.
|
||||
|
||||
The classic variant
|
||||
|
||||
``` c
|
||||
RUN_TEST(func, linenum)
|
||||
```
|
||||
|
||||
or its simpler replacement that starts at the beginning of the function.
|
||||
|
||||
``` c
|
||||
RUN_TEST(func)
|
||||
```
|
||||
|
||||
These macros perform the necessary setup before the test is called and
|
||||
handles cleanup and result tabulation afterwards.
|
||||
handles clean-up and result tabulation afterwards.
|
||||
|
||||
### Ignoring Test Functions
|
||||
|
||||
There are times when a test is incomplete or not valid for some reason.
|
||||
At these times, TEST_IGNORE can be called. Control will immediately be
|
||||
returned to the caller of the test, and no failures will be returned.
|
||||
@@ -189,18 +188,24 @@ TEST_IGNORE_MESSAGE (message)
|
||||
Ignore this test and return immediately. Output a message stating why the test was ignored.
|
||||
|
||||
### Aborting Tests
|
||||
|
||||
There are times when a test will contain an infinite loop on error conditions, or there may be reason to escape from the test early without executing the rest of the test. A pair of macros support this functionality in Unity. The first `TEST_PROTECT` sets up the feature, and handles emergency abort cases. `TEST_ABORT` can then be used at any time within the tests to return to the last `TEST_PROTECT` call.
|
||||
|
||||
```c
|
||||
TEST_PROTECT()
|
||||
```
|
||||
|
||||
Setup and Catch macro
|
||||
|
||||
```c
|
||||
TEST_ABORT()
|
||||
```
|
||||
|
||||
Abort Test macro
|
||||
|
||||
Example:
|
||||
|
||||
```c
|
||||
main()
|
||||
{
|
||||
if (TEST_PROTECT())
|
||||
@@ -208,11 +213,10 @@ Example:
|
||||
MyTest();
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
If MyTest calls `TEST_ABORT`, program control will immediately return to `TEST_PROTECT` with a return value of zero.
|
||||
|
||||
|
||||
|
||||
## How to Build and Run A Test File
|
||||
|
||||
This is the single biggest challenge to picking up a new unit testing framework,
|
||||
@@ -225,6 +229,7 @@ You have two really good options for toolchains. Depending on where you're
|
||||
coming from, it might surprise you that neither of these options is running the
|
||||
unit tests on your hardware.
|
||||
There are many reasons for this, but here's a short version:
|
||||
|
||||
- On hardware, you have too many constraints (processing power, memory, etc),
|
||||
- On hardware, you don't have complete control over all registers,
|
||||
- On hardware, unit testing is more challenging,
|
||||
@@ -247,5 +252,4 @@ This flexibility of separating tests into individual executables allows us to
|
||||
much more thoroughly unit test our system and it keeps all the test code out of
|
||||
our final release!
|
||||
|
||||
|
||||
*Find The Latest of This And More at [ThrowTheSwitch.org](https://throwtheswitch.org)*
|
||||
|
||||
@@ -8,7 +8,6 @@ easier. They are completely optional. If you choose to use them, you'll need a
|
||||
copy of Ruby, of course. Just install whatever the latest version is, and it is
|
||||
likely to work. You can find Ruby at [ruby-lang.org](https://ruby-labg.org/).
|
||||
|
||||
|
||||
### `generate_test_runner.rb`
|
||||
|
||||
Are you tired of creating your own `main` function in your test file? Do you
|
||||
@@ -114,21 +113,19 @@ test_files.each do |f|
|
||||
end
|
||||
```
|
||||
|
||||
#### Options accepted by generate_test_runner.rb:
|
||||
#### Options accepted by generate_test_runner.rb
|
||||
|
||||
The following options are available when executing `generate_test_runner`. You
|
||||
may pass these as a Ruby hash directly or specify them in a YAML file, both of
|
||||
which are described above. In the `examples` directory, Example 3's Rakefile
|
||||
demonstrates using a Ruby hash.
|
||||
|
||||
|
||||
##### `:includes`
|
||||
|
||||
This option specifies an array of file names to be `#include`'d at the top of
|
||||
your runner C file. You might use it to reference custom types or anything else
|
||||
universally needed in your generated runners.
|
||||
|
||||
|
||||
##### `:suite_setup`
|
||||
|
||||
Define this option with C code to be executed _before any_ test cases are run.
|
||||
@@ -138,7 +135,6 @@ option unset and instead provide a `void suiteSetUp(void)` function in your test
|
||||
suite. The linker will look for this symbol and fall back to a Unity-provided
|
||||
stub if it is not found.
|
||||
|
||||
|
||||
##### `:suite_teardown`
|
||||
|
||||
Define this option with C code to be executed _after all_ test cases have
|
||||
@@ -151,7 +147,6 @@ option unset and instead provide a `int suiteTearDown(int num_failures)`
|
||||
function in your test suite. The linker will look for this symbol and fall
|
||||
back to a Unity-provided stub if it is not found.
|
||||
|
||||
|
||||
##### `:enforce_strict_ordering`
|
||||
|
||||
This option should be defined if you have the strict order feature enabled in
|
||||
@@ -159,7 +154,6 @@ CMock (see CMock documentation). This generates extra variables required for
|
||||
everything to run smoothly. If you provide the same YAML to the generator as
|
||||
used in CMock's configuration, you've already configured the generator properly.
|
||||
|
||||
|
||||
##### `:externc`
|
||||
|
||||
This option should be defined if you are mixing C and CPP and want your test
|
||||
@@ -206,7 +200,6 @@ This option specifies the pattern for matching acceptable source file extensions
|
||||
By default it will accept cpp, cc, C, c, and ino files. If you need a different combination
|
||||
of files to search, update this from the default `'(?:cpp|cc|ino|C|c)'`.
|
||||
|
||||
|
||||
### `unity_test_summary.rb`
|
||||
|
||||
A Unity test file contains one or more test case functions. Each test case can
|
||||
@@ -274,5 +267,4 @@ OVERALL UNITY TEST SUMMARY
|
||||
|
||||
How convenient is that?
|
||||
|
||||
|
||||
*Find The Latest of This And More at [ThrowTheSwitch.org](https://throwtheswitch.org)*
|
||||
|
||||
@@ -9,14 +9,14 @@ Test Driven Development, or those coming to Unity from CppUTest. We should note
|
||||
framework glosses over some of the features of Unity, and makes it more difficult
|
||||
to integrate with other testing tools like Ceedling and CMock.
|
||||
|
||||
# Dependency Notification
|
||||
## Dependency Notification
|
||||
|
||||
Fixtures, by default, uses the Memory addon as well. This is to make it simple for those trying to
|
||||
follow along with James' book. Using them together is completely optional. You may choose to use
|
||||
Fixtures without Memory handling by defining `UNITY_FIXTURE_NO_EXTRAS`. It will then stop automatically
|
||||
pulling in extras and leave you to do it as desired.
|
||||
|
||||
# Usage information
|
||||
## Usage information
|
||||
|
||||
By default the test executables produced by Unity Fixtures run all tests once, but the behavior can
|
||||
be configured with command-line flags. Run the test executable with the `--help` flag for more
|
||||
|
||||
@@ -11,16 +11,16 @@ the allocation and deallocation of memory. When it is not symmetric, unit testin
|
||||
can report a number of false failures. A more advanced runtime tool is required to
|
||||
track complete system memory handling.
|
||||
|
||||
# Module API
|
||||
## Module API
|
||||
|
||||
## `UnityMalloc_StartTest` and `UnityMalloc_EndTest`
|
||||
### `UnityMalloc_StartTest` and `UnityMalloc_EndTest`
|
||||
|
||||
These must be called at the beginning and end of each test. For simplicity, they can
|
||||
be added to `setUp` and `tearDown` in order to do their job. When using the test
|
||||
runner generator scripts, these will be automatically added to the runner whenever
|
||||
unity_memory.h is included.
|
||||
|
||||
## `UnityMalloc_MakeMallocFailAfterCount`
|
||||
### `UnityMalloc_MakeMallocFailAfterCount`
|
||||
|
||||
This can be called from the tests themselves. Passing this function a number will
|
||||
force the reference counter to start keeping track of malloc calls. During that test,
|
||||
@@ -28,22 +28,22 @@ if the number of malloc calls exceeds the number given, malloc will immediately
|
||||
start returning `NULL`. This allows you to test error conditions. Think of it as a
|
||||
simplified mock.
|
||||
|
||||
# Configuration
|
||||
## Configuration
|
||||
|
||||
## `UNITY_MALLOC` and `UNITY_FREE`
|
||||
### `UNITY_MALLOC` and `UNITY_FREE`
|
||||
|
||||
By default, this module tries to use the real stdlib `malloc` and `free` internally.
|
||||
If you would prefer it to use something else, like FreeRTOS's `pvPortMalloc` and
|
||||
`pvPortFree`, then you can use these defines to make it so.
|
||||
|
||||
## `UNITY_EXCLUDE_STDLIB_MALLOC`
|
||||
### `UNITY_EXCLUDE_STDLIB_MALLOC`
|
||||
|
||||
If you would like this library to ignore stdlib or other heap engines completely, and
|
||||
manage the memory on its own, then define this. All memory will be handled internally
|
||||
(and at likely lower overhead). Note that this is not a very featureful memory manager,
|
||||
but is sufficient for most testing purposes.
|
||||
|
||||
## `UNITY_INTERNAL_HEAP_SIZE_BYTES`
|
||||
### `UNITY_INTERNAL_HEAP_SIZE_BYTES`
|
||||
|
||||
When using the built-in memory manager (see `UNITY_EXCLUDE_STDLIB_MALLOC`) this define
|
||||
allows you to set the heap size this library will use to manage the memory.
|
||||
|
||||
Reference in New Issue
Block a user