mirror of
https://github.com/ThrowTheSwitch/Unity.git
synced 2025-10-19 02:33:00 +08:00
Catch up documentation to match these changes.
This commit is contained in:
@@ -119,10 +119,10 @@ 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
|
default, if not autodetected, is 32-bits. If you're getting ugly compiler
|
||||||
warnings about casting from pointers, this is the one to look at.
|
warnings about casting from pointers, this is the one to look at.
|
||||||
|
|
||||||
_Hint:_ In order to support exotic processors (for example TI C55x with a pointer
|
_Hint:_ In order to support exotic processors (for example TI C55x with a pointer
|
||||||
width of 23-bit), choose the next power of two (in this case 32-bit).
|
width of 23-bit), choose the next power of two (in this case 32-bit).
|
||||||
|
|
||||||
_Supported values:_ 16, 32 and 64
|
_Supported values:_ 16, 32 and 64
|
||||||
|
|
||||||
_Example:_
|
_Example:_
|
||||||
```C
|
```C
|
||||||
@@ -343,36 +343,6 @@ _Note:_
|
|||||||
specifying `UNITY_USE_FLUSH_STDOUT`. No other defines are required.
|
specifying `UNITY_USE_FLUSH_STDOUT`. No other defines are required.
|
||||||
|
|
||||||
|
|
||||||
##### `UNITY_WEAK_ATTRIBUTE`
|
|
||||||
|
|
||||||
##### `UNITY_WEAK_PRAGMA`
|
|
||||||
|
|
||||||
##### `UNITY_NO_WEAK`
|
|
||||||
|
|
||||||
For some targets, Unity can make the otherwise required setUp() and tearDown()
|
|
||||||
functions optional. This is a nice convenience for test writers since setUp and
|
|
||||||
tearDown don’t often actually do anything. If you’re using gcc or clang, this
|
|
||||||
option is automatically defined for you. Other compilers can also support this
|
|
||||||
behavior, if they support a C feature called weak functions. A weak function is
|
|
||||||
a function that is compiled into your executable unless a non-weak version of
|
|
||||||
the same function is defined elsewhere. If a non-weak version is found, the weak
|
|
||||||
version is ignored as if it never existed. If your compiler supports this feature,
|
|
||||||
you can let Unity know by defining UNITY_WEAK_ATTRIBUTE or UNITY_WEAK_PRAGMA as
|
|
||||||
the function attributes that would need to be applied to identify a function as
|
|
||||||
weak. If your compiler lacks support for weak functions, you will always need to
|
|
||||||
define setUp and tearDown functions (though they can be and often will be just
|
|
||||||
empty). You can also force Unity to NOT use weak functions by defining
|
|
||||||
UNITY_NO_WEAK. The most common options for this feature are:
|
|
||||||
|
|
||||||
_Example:_
|
|
||||||
```C
|
|
||||||
#define UNITY_WEAK_ATTRIBUTE weak
|
|
||||||
#define UNITY_WEAK_ATTRIBUTE __attribute__((weak))
|
|
||||||
#define UNITY_WEAK_PRAGMA
|
|
||||||
#define UNITY_NO_WEAK
|
|
||||||
```
|
|
||||||
|
|
||||||
|
|
||||||
##### `UNITY_PTR_ATTRIBUTE`
|
##### `UNITY_PTR_ATTRIBUTE`
|
||||||
|
|
||||||
Some compilers require a custom attribute to be assigned to pointers, like
|
Some compilers require a custom attribute to be assigned to pointers, like
|
||||||
|
@@ -93,8 +93,9 @@ Next, a test file will include a `setUp()` and `tearDown()` function. The setUp
|
|||||||
function can contain anything you would like to run before each test. The
|
function can contain anything you would like to run before each test. The
|
||||||
tearDown function can contain anything you would like to run after each test.
|
tearDown function can contain anything you would like to run after each test.
|
||||||
Both functions accept no arguments and return nothing. You may leave either or
|
Both functions accept no arguments and return nothing. You may leave either or
|
||||||
both of these blank if you have no need for them. If you're using a compiler
|
both of these blank if you have no need for them.
|
||||||
that is configured to make these functions optional, you may leave them off
|
|
||||||
|
If you're using Ceedling or the test runner generator script, you may leave these off
|
||||||
completely. Not sure? Give it a try. If you compiler complains that it can't
|
completely. Not sure? Give it a try. If you compiler complains that it can't
|
||||||
find setUp or tearDown when it links, you'll know you need to at least include
|
find setUp or tearDown when it links, you'll know you need to at least include
|
||||||
an empty function for these.
|
an empty function for these.
|
||||||
@@ -103,7 +104,7 @@ The majority of the file will be a series of test functions. Test functions
|
|||||||
follow the convention of starting with the word "test_" or "spec_". You don't HAVE
|
follow the convention of starting with the word "test_" or "spec_". You don't HAVE
|
||||||
to name them this way, but it makes it clear what functions are tests for other
|
to name them this way, but it makes it clear what functions are tests for other
|
||||||
developers. Also, the automated scripts that come with Unity or Ceedling will default
|
developers. Also, the automated scripts that come with Unity or Ceedling will default
|
||||||
to looking for test functions to be prefixed this way. Test functions take no arguments
|
to looking for test functions to be prefixed this way. Test functions take no arguments
|
||||||
and return nothing. All test accounting is handled internally in Unity.
|
and return nothing. All test accounting is handled internally in Unity.
|
||||||
|
|
||||||
Finally, at the bottom of your test file, you will write a `main()` function.
|
Finally, at the bottom of your test file, you will write a `main()` function.
|
||||||
@@ -156,7 +157,7 @@ This should be enough to get you going, though.
|
|||||||
|
|
||||||
### Running Test Functions
|
### Running Test Functions
|
||||||
When writing your own `main()` functions, for a test-runner. There are two ways
|
When writing your own `main()` functions, for a test-runner. There are two ways
|
||||||
to execute the test.
|
to execute the test.
|
||||||
|
|
||||||
The classic variant
|
The classic variant
|
||||||
``` c
|
``` c
|
||||||
@@ -170,8 +171,8 @@ These macros perform the necessary setup before the test is called and
|
|||||||
handles cleanup and result tabulation afterwards.
|
handles cleanup and result tabulation afterwards.
|
||||||
|
|
||||||
### Ignoring Test Functions
|
### Ignoring Test Functions
|
||||||
There are times when a test is incomplete or not valid for some reason.
|
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
|
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.
|
returned to the caller of the test, and no failures will be returned.
|
||||||
This is useful when your test runners are automatically generated.
|
This is useful when your test runners are automatically generated.
|
||||||
|
|
||||||
|
Reference in New Issue
Block a user