ceedling 0.28.2 → 0.28.3
Sign up to get free protection for your applications and to get access to all the features.
- checksums.yaml +4 -4
- data/assets/ceedling +3 -0
- data/assets/ceedling.cmd +1 -0
- data/assets/default_gitignore +5 -0
- data/assets/project_with_guts.yml +1 -0
- data/assets/project_with_guts_gcov.yml +3 -0
- data/assets/test_example_file_verbose.c +12 -0
- data/bin/ceedling +30 -6
- data/docs/CeedlingPacket.md +135 -23
- data/docs/CeedlingPacket.odt +0 -0
- data/examples/blinky/rakefile.rb +2 -1
- data/lib/ceedling/configurator.rb +7 -5
- data/lib/ceedling/configurator_builder.rb +10 -7
- data/lib/ceedling/configurator_plugins.rb +29 -24
- data/lib/ceedling/configurator_setup.rb +0 -1
- data/lib/ceedling/defaults.rb +7 -2
- data/lib/ceedling/dependinator.rb +10 -2
- data/lib/ceedling/file_finder.rb +57 -49
- data/lib/ceedling/file_path_utils.rb +12 -4
- data/lib/ceedling/file_wrapper.rb +4 -0
- data/lib/ceedling/generator.rb +4 -3
- data/lib/ceedling/generator_test_results.rb +15 -13
- data/lib/ceedling/plugin_manager.rb +18 -18
- data/lib/ceedling/plugin_reportinator.rb +3 -2
- data/lib/ceedling/plugin_reportinator_helper.rb +2 -3
- data/lib/ceedling/preprocessinator_extractor.rb +2 -2
- data/lib/ceedling/preprocessinator_includes_handler.rb +5 -0
- data/lib/ceedling/rakefile.rb +1 -0
- data/lib/ceedling/release_invoker_helper.rb +5 -2
- data/lib/ceedling/rules_release.rake +2 -1
- data/lib/ceedling/rules_tests.rake +18 -9
- data/lib/ceedling/rules_tests_deep_dependencies.rake +2 -2
- data/lib/ceedling/task_invoker.rb +15 -3
- data/lib/ceedling/tasks_vendor.rake +3 -3
- data/lib/ceedling/test_invoker.rb +39 -12
- data/lib/ceedling/test_invoker_helper.rb +5 -1
- data/lib/ceedling/tool_executor.rb +8 -4
- data/lib/ceedling/version.rb +1 -1
- data/out.fail +21 -0
- data/plugins/beep/README.md +22 -0
- data/plugins/beep/lib/beep.rb +40 -0
- data/plugins/bullseye/bullseye.rake +43 -36
- data/plugins/bullseye/config/defaults.yml +4 -0
- data/plugins/bullseye/lib/bullseye.rb +27 -5
- data/plugins/command_hooks/lib/command_hooks.rb +3 -0
- data/plugins/gcov/README.md +34 -1
- data/plugins/gcov/config/defaults.yml +3 -3
- data/plugins/gcov/gcov.rake +7 -5
- data/plugins/gcov/lib/gcov.rb +3 -1
- data/plugins/gcov/lib/gcov_constants.rb +2 -0
- data/plugins/junit_tests_report/lib/junit_tests_report.rb +12 -9
- data/plugins/module_generator/lib/module_generator.rb +14 -1
- data/plugins/module_generator/module_generator.rake +21 -4
- data/plugins/raw_output_report/lib/raw_output_report.rb +41 -0
- data/spec/gcov/gcov_deployment_spec.rb +1 -1
- data/spec/gcov/gcov_test_cases_spec.rb +2 -2
- data/spec/generator_test_results_spec.rb +5 -0
- data/spec/preprocessinator_includes_handler_spec.rb +1 -0
- data/spec/spec_system_helper.rb +178 -4
- data/spec/support/test_example.fail +1 -0
- data/spec/support/test_example.pass +1 -0
- data/spec/support/test_example_empty.pass +1 -0
- data/spec/support/test_example_ignore.pass +1 -0
- data/spec/support/test_example_mangled.pass +1 -0
- data/spec/support/test_example_with_time.pass +22 -0
- data/spec/system/deployment_spec.rb +33 -0
- data/vendor/cmock/README.md +4 -3
- data/vendor/cmock/docs/CMock_Summary.md +1 -1
- data/vendor/cmock/lib/cmock_config.rb +4 -0
- data/vendor/cmock/lib/cmock_generator.rb +5 -2
- data/vendor/cmock/lib/cmock_generator_plugin_array.rb +4 -4
- data/vendor/cmock/lib/cmock_generator_plugin_callback.rb +9 -11
- data/vendor/cmock/lib/cmock_generator_plugin_cexception.rb +0 -1
- data/vendor/cmock/lib/cmock_generator_plugin_ignore.rb +2 -3
- data/vendor/cmock/lib/cmock_generator_plugin_ignore_arg.rb +2 -4
- data/vendor/cmock/lib/cmock_generator_plugin_return_thru_ptr.rb +0 -2
- data/vendor/cmock/lib/cmock_generator_utils.rb +16 -3
- data/vendor/cmock/lib/cmock_header_parser.rb +59 -34
- data/vendor/cmock/release/build.info +1 -1
- data/vendor/cmock/release/version.info +1 -1
- data/vendor/cmock/scripts/create_makefile.rb +17 -2
- data/vendor/cmock/src/cmock.c +13 -7
- data/vendor/cmock/test/test_helper.rb +11 -10
- data/vendor/cmock/test/unit/cmock_config_test.rb +4 -2
- data/vendor/cmock/test/unit/cmock_generator_main_test.rb +10 -4
- data/vendor/cmock/test/unit/cmock_generator_plugin_array_test.rb +20 -12
- data/vendor/cmock/test/unit/cmock_generator_plugin_expect_a_test.rb +2 -2
- data/vendor/cmock/test/unit/cmock_generator_plugin_expect_b_test.rb +2 -2
- data/vendor/cmock/test/unit/cmock_generator_plugin_ignore_arg_test.rb +3 -3
- data/vendor/cmock/test/unit/cmock_generator_plugin_return_thru_ptr_test.rb +8 -6
- data/vendor/cmock/test/unit/cmock_generator_utils_test.rb +27 -10
- data/vendor/cmock/test/unit/cmock_header_parser_test.rb +108 -20
- data/vendor/cmock/vendor/c_exception/Gemfile +4 -0
- data/vendor/cmock/vendor/c_exception/Gemfile.lock +12 -0
- data/vendor/cmock/vendor/c_exception/LICENSE.txt +30 -0
- data/vendor/cmock/vendor/c_exception/README.md +162 -0
- data/vendor/cmock/vendor/c_exception/Rakefile +42 -0
- data/vendor/cmock/vendor/c_exception/docs/CException.md +292 -0
- data/vendor/cmock/vendor/c_exception/docs/ThrowTheSwitchCodingStandard.md +207 -0
- data/vendor/cmock/vendor/c_exception/lib/CException.c +46 -0
- data/vendor/cmock/vendor/c_exception/lib/CException.h +110 -0
- data/vendor/cmock/vendor/c_exception/makefile +24 -0
- data/vendor/cmock/vendor/c_exception/release/build.info +2 -0
- data/vendor/cmock/vendor/c_exception/release/version.info +2 -0
- data/vendor/cmock/vendor/c_exception/test/CExceptionConfig.h +46 -0
- data/vendor/cmock/vendor/c_exception/test/TestException.c +391 -0
- data/vendor/cmock/vendor/c_exception/test/TestException_Runner.c +67 -0
- data/vendor/cmock/vendor/unity/README.md +231 -0
- data/vendor/cmock/vendor/unity/auto/colour_prompt.rb +118 -0
- data/vendor/cmock/vendor/unity/auto/colour_reporter.rb +39 -0
- data/vendor/cmock/vendor/unity/auto/generate_config.yml +36 -0
- data/vendor/cmock/vendor/unity/auto/generate_module.rb +308 -0
- data/vendor/cmock/vendor/unity/auto/generate_test_runner.rb +457 -0
- data/vendor/cmock/vendor/unity/auto/parse_output.rb +323 -0
- data/vendor/cmock/vendor/unity/auto/stylize_as_junit.rb +252 -0
- data/vendor/cmock/vendor/unity/auto/test_file_filter.rb +25 -0
- data/vendor/cmock/vendor/unity/auto/type_sanitizer.rb +6 -0
- data/vendor/cmock/vendor/unity/auto/unity_test_summary.py +139 -0
- data/vendor/cmock/vendor/unity/auto/unity_test_summary.rb +136 -0
- data/vendor/cmock/vendor/unity/auto/unity_to_junit.py +146 -0
- data/vendor/cmock/vendor/unity/docs/ThrowTheSwitchCodingStandard.md +206 -0
- data/vendor/cmock/vendor/unity/docs/UnityAssertionsCheatSheetSuitableforPrintingandPossiblyFraming.pdf +0 -0
- data/vendor/cmock/vendor/unity/docs/UnityAssertionsReference.md +779 -0
- data/vendor/cmock/vendor/unity/docs/UnityConfigurationGuide.md +433 -0
- data/vendor/cmock/vendor/unity/docs/UnityGettingStartedGuide.md +192 -0
- data/vendor/cmock/vendor/unity/docs/UnityHelperScriptsGuide.md +260 -0
- data/vendor/cmock/vendor/unity/docs/license.txt +21 -0
- data/vendor/cmock/vendor/unity/examples/example_1/makefile +71 -0
- data/vendor/cmock/vendor/unity/examples/example_1/readme.txt +5 -0
- data/vendor/cmock/vendor/unity/examples/example_1/src/ProductionCode.c +24 -0
- data/vendor/cmock/vendor/unity/examples/example_1/src/ProductionCode.h +3 -0
- data/vendor/cmock/vendor/unity/examples/example_1/src/ProductionCode2.c +11 -0
- data/vendor/cmock/vendor/unity/examples/example_1/src/ProductionCode2.h +2 -0
- data/vendor/cmock/vendor/unity/examples/example_1/test/TestProductionCode.c +62 -0
- data/vendor/cmock/vendor/unity/examples/example_1/test/TestProductionCode2.c +31 -0
- data/vendor/cmock/vendor/unity/examples/example_1/test/test_runners/TestProductionCode2_Runner.c +53 -0
- data/vendor/cmock/vendor/unity/examples/example_1/test/test_runners/TestProductionCode_Runner.c +57 -0
- data/vendor/cmock/vendor/unity/examples/example_2/makefile +70 -0
- data/vendor/cmock/vendor/unity/examples/example_2/readme.txt +5 -0
- data/vendor/cmock/vendor/unity/examples/example_2/src/ProductionCode.c +24 -0
- data/vendor/cmock/vendor/unity/examples/example_2/src/ProductionCode.h +3 -0
- data/vendor/cmock/vendor/unity/examples/example_2/src/ProductionCode2.c +11 -0
- data/vendor/cmock/vendor/unity/examples/example_2/src/ProductionCode2.h +2 -0
- data/vendor/cmock/vendor/unity/examples/example_2/test/TestProductionCode.c +64 -0
- data/vendor/cmock/vendor/unity/examples/example_2/test/TestProductionCode2.c +33 -0
- data/vendor/cmock/vendor/unity/examples/example_2/test/test_runners/TestProductionCode2_Runner.c +9 -0
- data/vendor/cmock/vendor/unity/examples/example_2/test/test_runners/TestProductionCode_Runner.c +11 -0
- data/vendor/cmock/vendor/unity/examples/example_2/test/test_runners/all_tests.c +12 -0
- data/vendor/cmock/vendor/unity/examples/example_3/helper/UnityHelper.c +10 -0
- data/vendor/cmock/vendor/unity/examples/example_3/helper/UnityHelper.h +12 -0
- data/vendor/cmock/vendor/unity/examples/example_3/rakefile.rb +43 -0
- data/vendor/cmock/vendor/unity/examples/example_3/rakefile_helper.rb +249 -0
- data/vendor/cmock/vendor/unity/examples/example_3/readme.txt +13 -0
- data/vendor/cmock/vendor/unity/examples/example_3/src/ProductionCode.c +24 -0
- data/vendor/cmock/vendor/unity/examples/example_3/src/ProductionCode.h +3 -0
- data/vendor/cmock/vendor/unity/examples/example_3/src/ProductionCode2.c +11 -0
- data/vendor/cmock/vendor/unity/examples/example_3/src/ProductionCode2.h +2 -0
- data/vendor/cmock/vendor/unity/examples/example_3/target_gcc_32.yml +46 -0
- data/vendor/cmock/vendor/unity/examples/example_3/test/TestProductionCode.c +62 -0
- data/vendor/cmock/vendor/unity/examples/example_3/test/TestProductionCode2.c +31 -0
- data/vendor/cmock/vendor/unity/examples/unity_config.h +247 -0
- data/vendor/cmock/vendor/unity/extras/eclipse/error_parsers.txt +26 -0
- data/vendor/cmock/vendor/unity/extras/fixture/rakefile.rb +48 -0
- data/vendor/cmock/vendor/unity/extras/fixture/rakefile_helper.rb +178 -0
- data/vendor/cmock/vendor/unity/extras/fixture/readme.txt +9 -0
- data/vendor/cmock/vendor/unity/extras/fixture/src/unity_fixture.c +436 -0
- data/vendor/cmock/vendor/unity/extras/fixture/src/unity_fixture.h +83 -0
- data/vendor/cmock/vendor/unity/extras/fixture/src/unity_fixture_internals.h +51 -0
- data/vendor/cmock/vendor/unity/extras/fixture/src/unity_fixture_malloc_overrides.h +47 -0
- data/vendor/cmock/vendor/unity/extras/fixture/test/Makefile +75 -0
- data/vendor/cmock/vendor/unity/extras/fixture/test/main/AllTests.c +22 -0
- data/vendor/cmock/vendor/unity/extras/fixture/test/template_fixture_tests.c +39 -0
- data/vendor/cmock/vendor/unity/extras/fixture/test/unity_fixture_Test.c +543 -0
- data/vendor/cmock/vendor/unity/extras/fixture/test/unity_fixture_TestRunner.c +57 -0
- data/vendor/cmock/vendor/unity/extras/fixture/test/unity_output_Spy.c +57 -0
- data/vendor/cmock/vendor/unity/extras/fixture/test/unity_output_Spy.h +17 -0
- data/vendor/cmock/vendor/unity/release/build.info +2 -0
- data/vendor/cmock/vendor/unity/release/version.info +2 -0
- data/vendor/cmock/vendor/unity/src/unity.c +1572 -0
- data/vendor/cmock/vendor/unity/src/unity.h +503 -0
- data/vendor/cmock/vendor/unity/src/unity_internals.h +924 -0
- data/vendor/cmock/vendor/unity/test/Makefile +68 -0
- data/vendor/cmock/vendor/unity/test/expectdata/testsample_cmd.c +61 -0
- data/vendor/cmock/vendor/unity/test/expectdata/testsample_def.c +57 -0
- data/vendor/cmock/vendor/unity/test/expectdata/testsample_head1.c +55 -0
- data/vendor/cmock/vendor/unity/test/expectdata/testsample_head1.h +15 -0
- data/vendor/cmock/vendor/unity/test/expectdata/testsample_mock_cmd.c +80 -0
- data/vendor/cmock/vendor/unity/test/expectdata/testsample_mock_def.c +76 -0
- data/vendor/cmock/vendor/unity/test/expectdata/testsample_mock_head1.c +75 -0
- data/vendor/cmock/vendor/unity/test/expectdata/testsample_mock_head1.h +13 -0
- data/vendor/cmock/vendor/unity/test/expectdata/testsample_mock_new1.c +89 -0
- data/vendor/cmock/vendor/unity/test/expectdata/testsample_mock_new2.c +89 -0
- data/vendor/cmock/vendor/unity/test/expectdata/testsample_mock_param.c +77 -0
- data/vendor/cmock/vendor/unity/test/expectdata/testsample_mock_run1.c +89 -0
- data/vendor/cmock/vendor/unity/test/expectdata/testsample_mock_run2.c +89 -0
- data/vendor/cmock/vendor/unity/test/expectdata/testsample_mock_yaml.c +90 -0
- data/vendor/cmock/vendor/unity/test/expectdata/testsample_new1.c +67 -0
- data/vendor/cmock/vendor/unity/test/expectdata/testsample_new2.c +70 -0
- data/vendor/cmock/vendor/unity/test/expectdata/testsample_param.c +58 -0
- data/vendor/cmock/vendor/unity/test/expectdata/testsample_run1.c +67 -0
- data/vendor/cmock/vendor/unity/test/expectdata/testsample_run2.c +70 -0
- data/vendor/cmock/vendor/unity/test/expectdata/testsample_yaml.c +71 -0
- data/vendor/cmock/vendor/unity/test/rakefile +125 -0
- data/vendor/cmock/vendor/unity/test/rakefile_helper.rb +260 -0
- data/vendor/cmock/vendor/unity/test/spec/generate_module_existing_file_spec.rb +158 -0
- data/vendor/cmock/vendor/unity/test/targets/clang_file.yml +78 -0
- data/vendor/cmock/vendor/unity/test/targets/clang_strict.yml +78 -0
- data/vendor/cmock/vendor/unity/test/targets/gcc_32.yml +49 -0
- data/vendor/cmock/vendor/unity/test/targets/gcc_64.yml +50 -0
- data/vendor/cmock/vendor/unity/test/targets/gcc_auto_limits.yml +47 -0
- data/vendor/cmock/vendor/unity/test/targets/gcc_auto_stdint.yml +59 -0
- data/vendor/cmock/vendor/unity/test/targets/gcc_manual_math.yml +47 -0
- data/vendor/cmock/vendor/unity/test/targets/hitech_picc18.yml +101 -0
- data/vendor/cmock/vendor/unity/test/targets/iar_arm_v4.yml +90 -0
- data/vendor/cmock/vendor/unity/test/targets/iar_arm_v5.yml +80 -0
- data/vendor/cmock/vendor/unity/test/targets/iar_arm_v5_3.yml +80 -0
- data/vendor/cmock/vendor/unity/test/targets/iar_armcortex_LM3S9B92_v5_4.yml +94 -0
- data/vendor/cmock/vendor/unity/test/targets/iar_cortexm3_v5.yml +84 -0
- data/vendor/cmock/vendor/unity/test/targets/iar_msp430.yml +95 -0
- data/vendor/cmock/vendor/unity/test/targets/iar_sh2a_v6.yml +86 -0
- data/vendor/cmock/vendor/unity/test/testdata/CException.h +11 -0
- data/vendor/cmock/vendor/unity/test/testdata/Defs.h +8 -0
- data/vendor/cmock/vendor/unity/test/testdata/cmock.h +14 -0
- data/vendor/cmock/vendor/unity/test/testdata/mockMock.h +13 -0
- data/vendor/cmock/vendor/unity/test/testdata/testRunnerGenerator.c +186 -0
- data/vendor/cmock/vendor/unity/test/testdata/testRunnerGeneratorSmall.c +70 -0
- data/vendor/cmock/vendor/unity/test/testdata/testRunnerGeneratorWithMocks.c +195 -0
- data/vendor/cmock/vendor/unity/test/tests/test_generate_test_runner.rb +1252 -0
- data/vendor/cmock/vendor/unity/test/tests/testparameterized.c +113 -0
- data/vendor/cmock/vendor/unity/test/tests/testunity.c +5371 -0
- data/vendor/unity/auto/generate_test_runner.rb +30 -10
- data/vendor/unity/auto/parse_output.rb +212 -109
- data/vendor/unity/docs/ThrowTheSwitchCodingStandard.md +9 -10
- data/vendor/unity/docs/UnityAssertionsReference.md +11 -2
- data/vendor/unity/docs/UnityConfigurationGuide.md +90 -55
- data/vendor/unity/docs/UnityGettingStartedGuide.md +6 -5
- data/vendor/unity/docs/UnityHelperScriptsGuide.md +23 -5
- data/vendor/unity/examples/unity_config.h +8 -0
- data/vendor/unity/extras/fixture/src/unity_fixture.c +4 -0
- data/vendor/unity/extras/fixture/src/unity_fixture.h +1 -1
- data/vendor/unity/extras/fixture/src/unity_fixture_internals.h +2 -2
- data/vendor/unity/release/build.info +1 -1
- data/vendor/unity/release/version.info +1 -1
- data/vendor/unity/src/unity.c +64 -57
- data/vendor/unity/src/unity.h +111 -7
- data/vendor/unity/src/unity_internals.h +173 -73
- data/vendor/unity/test/Makefile +5 -1
- data/vendor/unity/test/testdata/testRunnerGenerator.c +4 -1
- data/vendor/unity/test/testdata/testRunnerGeneratorSmall.c +4 -1
- data/vendor/unity/test/testdata/testRunnerGeneratorWithMocks.c +4 -1
- data/vendor/unity/test/tests/testparameterized.c +5 -2
- data/vendor/unity/test/tests/testunity.c +34 -0
- metadata +150 -2
@@ -0,0 +1,206 @@
|
|
1
|
+
# ThrowTheSwitch.org Coding Standard
|
2
|
+
|
3
|
+
Hi. Welcome to the coding standard for ThrowTheSwitch.org. For the most part,
|
4
|
+
we try to follow these standards to unify our contributors' code into a cohesive
|
5
|
+
unit (puns intended). You might find places where these standards aren't
|
6
|
+
followed. We're not perfect. Please be polite where you notice these discrepancies
|
7
|
+
and we'll try to be polite when we notice yours.
|
8
|
+
|
9
|
+
;)
|
10
|
+
|
11
|
+
|
12
|
+
## Why Have A Coding Standard?
|
13
|
+
|
14
|
+
Being consistent makes code easier to understand. We've tried to keep
|
15
|
+
our standard simple because we also believe that we can only expect someone to
|
16
|
+
follow something that is understandable. Please do your best.
|
17
|
+
|
18
|
+
|
19
|
+
## Our Philosophy
|
20
|
+
|
21
|
+
Before we get into details on syntax, let's take a moment to talk about our
|
22
|
+
vision for these tools. We're C developers and embedded software developers.
|
23
|
+
These tools are great to test any C code, but catering to embedded software has
|
24
|
+
made us more tolerant of compiler quirks. There are a LOT of quirky compilers
|
25
|
+
out there. By quirky I mean "doesn't follow standards because they feel like
|
26
|
+
they have a license to do as they wish."
|
27
|
+
|
28
|
+
Our philosophy is "support every compiler we can". Most often, this means that
|
29
|
+
we aim for writing C code that is standards compliant (often C89... that seems
|
30
|
+
to be a sweet spot that is almost always compatible). But it also means these
|
31
|
+
tools are tolerant of things that aren't common. Some that aren't even
|
32
|
+
compliant. There are configuration options to override the size of standard
|
33
|
+
types. There are configuration options to force Unity to not use certain
|
34
|
+
standard library functions. A lot of Unity is configurable and we have worked
|
35
|
+
hard to make it not TOO ugly in the process.
|
36
|
+
|
37
|
+
Similarly, our tools that parse C do their best. They aren't full C parsers
|
38
|
+
(yet) and, even if they were, they would still have to accept non-standard
|
39
|
+
additions like gcc extensions or specifying `@0x1000` to force a variable to
|
40
|
+
compile to a particular location. It's just what we do, because we like
|
41
|
+
everything to Just Work™.
|
42
|
+
|
43
|
+
Speaking of having things Just Work™, that's our second philosophy. By that, we
|
44
|
+
mean that we do our best to have EVERY configuration option have a logical
|
45
|
+
default. We believe that if you're working with a simple compiler and target,
|
46
|
+
you shouldn't need to configure very much... we try to make the tools guess as
|
47
|
+
much as they can, but give the user the power to override it when it's wrong.
|
48
|
+
|
49
|
+
|
50
|
+
## Naming Things
|
51
|
+
|
52
|
+
Let's talk about naming things. Programming is all about naming things. We name
|
53
|
+
files, functions, variables, and so much more. While we're not always going to
|
54
|
+
find the best name for something, we actually put a bit of effort into
|
55
|
+
finding *What Something WANTS to be Called*™.
|
56
|
+
|
57
|
+
When naming things, we follow this hierarchy, the first being the
|
58
|
+
most important to us (but we do all four when possible):
|
59
|
+
1. Readable
|
60
|
+
2. Descriptive
|
61
|
+
3. Consistent
|
62
|
+
4. Memorable
|
63
|
+
|
64
|
+
|
65
|
+
#### Readable
|
66
|
+
|
67
|
+
We want to read our code. This means we like names and flow that are more
|
68
|
+
naturally read. We try to avoid double negatives. We try to avoid cryptic
|
69
|
+
abbreviations (sticking to ones we feel are common).
|
70
|
+
|
71
|
+
|
72
|
+
#### Descriptive
|
73
|
+
|
74
|
+
We like descriptive names for things, especially functions and variables.
|
75
|
+
Finding the right name for something is an important endeavor. You might notice
|
76
|
+
from poking around our code that this often results in names that are a little
|
77
|
+
longer than the average. Guilty. We're okay with a bit more typing if it
|
78
|
+
means our code is easier to understand.
|
79
|
+
|
80
|
+
There are two exceptions to this rule that we also stick to as religiously as
|
81
|
+
possible:
|
82
|
+
|
83
|
+
First, while we realize hungarian notation (and similar systems for encoding
|
84
|
+
type information into variable names) is providing a more descriptive name, we
|
85
|
+
feel that (for the average developer) it takes away from readability and is to be avoided.
|
86
|
+
|
87
|
+
Second, loop counters and other local throw-away variables often have a purpose
|
88
|
+
which is obvious. There's no need, therefore, to get carried away with complex
|
89
|
+
naming. We find i, j, and k are better loop counters than loopCounterVar or
|
90
|
+
whatnot. We only break this rule when we see that more description could improve
|
91
|
+
understanding of an algorithm.
|
92
|
+
|
93
|
+
|
94
|
+
#### Consistent
|
95
|
+
|
96
|
+
We like consistency, but we're not really obsessed with it. We try to name our
|
97
|
+
configuration macros in a consistent fashion... you'll notice a repeated use of
|
98
|
+
UNITY_EXCLUDE_BLAH or UNITY_USES_BLAH macros. This helps users avoid having to
|
99
|
+
remember each macro's details.
|
100
|
+
|
101
|
+
|
102
|
+
#### Memorable
|
103
|
+
|
104
|
+
Where ever it doesn't violate the above principles, we try to apply memorable
|
105
|
+
names. Sometimes this means using something that is simply descriptive, but
|
106
|
+
often we strive for descriptive AND unique... we like quirky names that stand
|
107
|
+
out in our memory and are easier to search for. Take a look through the file
|
108
|
+
names in Ceedling and you'll get a good idea of what we are talking about here.
|
109
|
+
Why use preprocess when you can use preprocessinator? Or what better describes a
|
110
|
+
module in charge of invoking tasks during releases than release_invoker? Don't
|
111
|
+
get carried away. The names are still descriptive and fulfill the above
|
112
|
+
requirements, but they don't feel stale.
|
113
|
+
|
114
|
+
|
115
|
+
## C and C++ Details
|
116
|
+
|
117
|
+
We don't really want to add to the style battles out there. Tabs or spaces?
|
118
|
+
How many spaces? Where do the braces go? These are age-old questions that will
|
119
|
+
never be answered... or at least not answered in a way that will make everyone
|
120
|
+
happy.
|
121
|
+
|
122
|
+
We've decided on our own style preferences. If you'd like to contribute to these
|
123
|
+
projects (and we hope that you do), then we ask if you do your best to follow
|
124
|
+
the same. It will only hurt a little. We promise.
|
125
|
+
|
126
|
+
|
127
|
+
#### Whitespace
|
128
|
+
|
129
|
+
Our C-style is to use spaces and to use 4 of them per indent level. It's a nice
|
130
|
+
power-of-2 number that looks decent on a wide-screen. We have no more reason
|
131
|
+
than that. We break that rule when we have lines that wrap (macros or function
|
132
|
+
arguments or whatnot). When that happens, we like to indent further to line
|
133
|
+
things up in nice tidy columns.
|
134
|
+
|
135
|
+
```C
|
136
|
+
if (stuff_happened)
|
137
|
+
{
|
138
|
+
do_something();
|
139
|
+
}
|
140
|
+
```
|
141
|
+
|
142
|
+
|
143
|
+
#### Case
|
144
|
+
|
145
|
+
- Files - all lower case with underscores.
|
146
|
+
- Variables - all lower case with underscores
|
147
|
+
- Macros - all caps with underscores.
|
148
|
+
- Typedefs - all caps with underscores. (also ends with _T).
|
149
|
+
- Functions - camel cased. Usually named ModuleName_FuncName
|
150
|
+
- Constants and Globals - camel cased.
|
151
|
+
|
152
|
+
|
153
|
+
#### Braces
|
154
|
+
|
155
|
+
The left brace is on the next line after the declaration. The right brace is
|
156
|
+
directly below that. Everything in between in indented one level. If you're
|
157
|
+
catching an error and you have a one-line, go ahead and to it on the same line.
|
158
|
+
|
159
|
+
```C
|
160
|
+
while (blah)
|
161
|
+
{
|
162
|
+
//Like so. Even if only one line, we use braces.
|
163
|
+
}
|
164
|
+
```
|
165
|
+
|
166
|
+
|
167
|
+
#### Comments
|
168
|
+
|
169
|
+
Do you know what we hate? Old-school C block comments. BUT, we're using them
|
170
|
+
anyway. As we mentioned, our goal is to support every compiler we can,
|
171
|
+
especially embedded compilers. There are STILL C compilers out there that only
|
172
|
+
support old-school block comments. So that is what we're using. We apologize. We
|
173
|
+
think they are ugly too.
|
174
|
+
|
175
|
+
|
176
|
+
## Ruby Details
|
177
|
+
|
178
|
+
Is there really such thing as a Ruby coding standard? Ruby is such a free form
|
179
|
+
language, it seems almost sacrilegious to suggest that people should comply to
|
180
|
+
one method! We'll keep it really brief!
|
181
|
+
|
182
|
+
|
183
|
+
#### Whitespace
|
184
|
+
|
185
|
+
Our Ruby style is to use spaces and to use 2 of them per indent level. It's a
|
186
|
+
nice power-of-2 number that really grooves with Ruby's compact style. We have no
|
187
|
+
more reason than that. We break that rule when we have lines that wrap. When
|
188
|
+
that happens, we like to indent further to line things up in nice tidy columns.
|
189
|
+
|
190
|
+
|
191
|
+
#### Case
|
192
|
+
|
193
|
+
- Files - all lower case with underscores.
|
194
|
+
- Variables - all lower case with underscores
|
195
|
+
- Classes, Modules, etc - Camel cased.
|
196
|
+
- Functions - all lower case with underscores
|
197
|
+
- Constants - all upper case with underscores
|
198
|
+
|
199
|
+
|
200
|
+
## Documentation
|
201
|
+
|
202
|
+
Egad. Really? We use mark down and we like pdf files because they can be made to
|
203
|
+
look nice while still being portable. Good enough?
|
204
|
+
|
205
|
+
|
206
|
+
*Find The Latest of This And More at [ThrowTheSwitch.org](https://throwtheswitch.org)*
|
Binary file
|
@@ -0,0 +1,779 @@
|
|
1
|
+
# Unity Assertions Reference
|
2
|
+
|
3
|
+
## Background and Overview
|
4
|
+
|
5
|
+
### Super Condensed Version
|
6
|
+
|
7
|
+
- An assertion establishes truth (i.e. boolean True) for a single condition.
|
8
|
+
Upon boolean False, an assertion stops execution and reports the failure.
|
9
|
+
- Unity is mainly a rich collection of assertions and the support to gather up
|
10
|
+
and easily execute those assertions.
|
11
|
+
- The structure of Unity allows you to easily separate test assertions from
|
12
|
+
source code in, well, test code.
|
13
|
+
- Unity's assertions:
|
14
|
+
- Come in many, many flavors to handle different C types and assertion cases.
|
15
|
+
- Use context to provide detailed and helpful failure messages.
|
16
|
+
- Document types, expected values, and basic behavior in your source code for
|
17
|
+
free.
|
18
|
+
|
19
|
+
|
20
|
+
### Unity Is Several Things But Mainly It's Assertions
|
21
|
+
|
22
|
+
One way to think of Unity is simply as a rich collection of assertions you can
|
23
|
+
use to establish whether your source code behaves the way you think it does.
|
24
|
+
Unity provides a framework to easily organize and execute those assertions in
|
25
|
+
test code separate from your source code.
|
26
|
+
|
27
|
+
|
28
|
+
### What's an Assertion?
|
29
|
+
|
30
|
+
At their core, assertions are an establishment of truth - boolean truth. Was this
|
31
|
+
thing equal to that thing? Does that code doohickey have such-and-such property
|
32
|
+
or not? You get the idea. Assertions are executable code (to appreciate the big
|
33
|
+
picture on this read up on the difference between
|
34
|
+
[link:Dynamic Verification and Static Analysis]). A failing assertion stops
|
35
|
+
execution and reports an error through some appropriate I/O channel (e.g.
|
36
|
+
stdout, GUI, file, blinky light).
|
37
|
+
|
38
|
+
Fundamentally, for dynamic verification all you need is a single assertion
|
39
|
+
mechanism. In fact, that's what the [assert() macro in C's standard library](http://en.wikipedia.org/en/wiki/Assert.h)
|
40
|
+
is for. So why not just use it? Well, we can do far better in the reporting
|
41
|
+
department. C's `assert()` is pretty dumb as-is and is particularly poor for
|
42
|
+
handling common data types like arrays, structs, etc. And, without some other
|
43
|
+
support, it's far too tempting to litter source code with C's `assert()`'s. It's
|
44
|
+
generally much cleaner, manageable, and more useful to separate test and source
|
45
|
+
code in the way Unity facilitates.
|
46
|
+
|
47
|
+
|
48
|
+
### Unity's Assertions: Helpful Messages _and_ Free Source Code Documentation
|
49
|
+
|
50
|
+
Asserting a simple truth condition is valuable, but using the context of the
|
51
|
+
assertion is even more valuable. For instance, if you know you're comparing bit
|
52
|
+
flags and not just integers, then why not use that context to give explicit,
|
53
|
+
readable, bit-level feedback when an assertion fails?
|
54
|
+
|
55
|
+
That's what Unity's collection of assertions do - capture context to give you
|
56
|
+
helpful, meaningful assertion failure messages. In fact, the assertions
|
57
|
+
themselves also serve as executable documentation about types and values in your
|
58
|
+
source code. So long as your tests remain current with your source and all those
|
59
|
+
tests pass, you have a detailed, up-to-date view of the intent and mechanisms in
|
60
|
+
your source code. And due to a wondrous mystery, well-tested code usually tends
|
61
|
+
to be well designed code.
|
62
|
+
|
63
|
+
|
64
|
+
## Assertion Conventions and Configurations
|
65
|
+
|
66
|
+
### Naming and Parameter Conventions
|
67
|
+
|
68
|
+
The convention of assertion parameters generally follows this order:
|
69
|
+
|
70
|
+
TEST_ASSERT_X( {modifiers}, {expected}, actual, {size/count} )
|
71
|
+
|
72
|
+
The very simplest assertion possible uses only a single "actual" parameter (e.g.
|
73
|
+
a simple null check).
|
74
|
+
|
75
|
+
"Actual" is the value being tested and unlike the other parameters in an
|
76
|
+
assertion construction is the only parameter present in all assertion variants.
|
77
|
+
"Modifiers" are masks, ranges, bit flag specifiers, floating point deltas.
|
78
|
+
"Expected" is your expected value (duh) to compare to an "actual" value; it's
|
79
|
+
marked as an optional parameter because some assertions only need a single
|
80
|
+
"actual" parameter (e.g. null check).
|
81
|
+
"Size/count" refers to string lengths, number of array elements, etc.
|
82
|
+
|
83
|
+
Many of Unity's assertions are clear duplications in that the same data type
|
84
|
+
is handled by several assertions. The differences among these are in how failure
|
85
|
+
messages are presented. For instance, a `_HEX` variant of an assertion prints
|
86
|
+
the expected and actual values of that assertion formatted as hexadecimal.
|
87
|
+
|
88
|
+
|
89
|
+
#### TEST_ASSERT_X_MESSAGE Variants
|
90
|
+
|
91
|
+
_All_ assertions are complemented with a variant that includes a simple string
|
92
|
+
message as a final parameter. The string you specify is appended to an assertion
|
93
|
+
failure message in Unity output.
|
94
|
+
|
95
|
+
For brevity, the assertion variants with a message parameter are not listed
|
96
|
+
below. Just tack on `_MESSAGE` as the final component to any assertion name in
|
97
|
+
the reference list below and add a string as the final parameter.
|
98
|
+
|
99
|
+
_Example:_
|
100
|
+
|
101
|
+
TEST_ASSERT_X( {modifiers}, {expected}, actual, {size/count} )
|
102
|
+
|
103
|
+
becomes messageified like thus...
|
104
|
+
|
105
|
+
TEST_ASSERT_X_MESSAGE( {modifiers}, {expected}, actual, {size/count}, message )
|
106
|
+
|
107
|
+
Notes:
|
108
|
+
- The `_MESSAGE` variants intentionally do not support `printf` style formatting
|
109
|
+
since many embedded projects don't support or avoid `printf` for various reasons.
|
110
|
+
It is possible to use `sprintf` before the assertion to assemble a complex fail
|
111
|
+
message, if necessary.
|
112
|
+
- If you want to output a counter value within an assertion fail message (e.g. from
|
113
|
+
a loop) , building up an array of results and then using one of the `_ARRAY`
|
114
|
+
assertions (see below) might be a handy alternative to `sprintf`.
|
115
|
+
|
116
|
+
|
117
|
+
#### TEST_ASSERT_X_ARRAY Variants
|
118
|
+
|
119
|
+
Unity provides a collection of assertions for arrays containing a variety of
|
120
|
+
types. These are documented in the Array section below. These are almost on par
|
121
|
+
with the `_MESSAGE`variants of Unity's Asserts in that for pretty much any Unity
|
122
|
+
type assertion you can tack on `_ARRAY` and run assertions on an entire block of
|
123
|
+
memory.
|
124
|
+
|
125
|
+
TEST_ASSERT_EQUAL_TYPEX_ARRAY( expected, actual, {size/count} )
|
126
|
+
|
127
|
+
"Expected" is an array itself.
|
128
|
+
"Size/count" is one or two parameters necessary to establish the number of array
|
129
|
+
elements and perhaps the length of elements within the array.
|
130
|
+
|
131
|
+
Notes:
|
132
|
+
- The `_MESSAGE` variant convention still applies here to array assertions. The
|
133
|
+
`_MESSAGE` variants of the `_ARRAY` assertions have names ending with
|
134
|
+
`_ARRAY_MESSAGE`.
|
135
|
+
- Assertions for handling arrays of floating point values are grouped with float
|
136
|
+
and double assertions (see immediately following section).
|
137
|
+
|
138
|
+
|
139
|
+
### TEST_ASSERT_EACH_EQUAL_X Variants
|
140
|
+
|
141
|
+
Unity provides a collection of assertions for arrays containing a variety of
|
142
|
+
types which can be compared to a single value as well. These are documented in
|
143
|
+
the Each Equal section below. these are almost on par with the `_MESSAGE`
|
144
|
+
variants of Unity's Asserts in that for pretty much any Unity type assertion you
|
145
|
+
can inject _EACH_EQUAL and run assertions on an entire block of memory.
|
146
|
+
|
147
|
+
TEST_ASSERT_EACH_EQUAL_TYPEX( expected, actual, {size/count} )
|
148
|
+
|
149
|
+
"Expected" is a single value to compare to.
|
150
|
+
"Actual" is an array where each element will be compared to the expected value.
|
151
|
+
"Size/count" is one of two parameters necessary to establish the number of array
|
152
|
+
elements and perhaps the length of elements within the array.
|
153
|
+
|
154
|
+
Notes:
|
155
|
+
- The `_MESSAGE` variant convention still applies here to Each Equal assertions.
|
156
|
+
- Assertions for handling Each Equal of floating point values are grouped with
|
157
|
+
float and double assertions (see immediately following section).
|
158
|
+
|
159
|
+
|
160
|
+
### Configuration
|
161
|
+
|
162
|
+
#### Floating Point Support Is Optional
|
163
|
+
|
164
|
+
Support for floating point types is configurable. That is, by defining the
|
165
|
+
appropriate preprocessor symbols, floats and doubles can be individually enabled
|
166
|
+
or disabled in Unity code. This is useful for embedded targets with no floating
|
167
|
+
point math support (i.e. Unity compiles free of errors for fixed point only
|
168
|
+
platforms). See Unity documentation for specifics.
|
169
|
+
|
170
|
+
|
171
|
+
#### Maximum Data Type Width Is Configurable
|
172
|
+
|
173
|
+
Not all targets support 64 bit wide types or even 32 bit wide types. Define the
|
174
|
+
appropriate preprocessor symbols and Unity will omit all operations from
|
175
|
+
compilation that exceed the maximum width of your target. See Unity
|
176
|
+
documentation for specifics.
|
177
|
+
|
178
|
+
|
179
|
+
## The Assertions in All Their Blessed Glory
|
180
|
+
|
181
|
+
### Basic Fail and Ignore
|
182
|
+
|
183
|
+
##### `TEST_FAIL()`
|
184
|
+
|
185
|
+
This fella is most often used in special conditions where your test code is
|
186
|
+
performing logic beyond a simple assertion. That is, in practice, `TEST_FAIL()`
|
187
|
+
will always be found inside a conditional code block.
|
188
|
+
|
189
|
+
_Examples:_
|
190
|
+
- Executing a state machine multiple times that increments a counter your test
|
191
|
+
code then verifies as a final step.
|
192
|
+
- Triggering an exception and verifying it (as in Try / Catch / Throw - see the
|
193
|
+
[CException](https://github.com/ThrowTheSwitch/CException) project).
|
194
|
+
|
195
|
+
##### `TEST_IGNORE()`
|
196
|
+
|
197
|
+
Marks a test case (i.e. function meant to contain test assertions) as ignored.
|
198
|
+
Usually this is employed as a breadcrumb to come back and implement a test case.
|
199
|
+
An ignored test case has effects if other assertions are in the enclosing test
|
200
|
+
case (see Unity documentation for more).
|
201
|
+
|
202
|
+
### Boolean
|
203
|
+
|
204
|
+
##### `TEST_ASSERT (condition)`
|
205
|
+
|
206
|
+
##### `TEST_ASSERT_TRUE (condition)`
|
207
|
+
|
208
|
+
##### `TEST_ASSERT_FALSE (condition)`
|
209
|
+
|
210
|
+
##### `TEST_ASSERT_UNLESS (condition)`
|
211
|
+
|
212
|
+
A simple wording variation on `TEST_ASSERT_FALSE`.The semantics of
|
213
|
+
`TEST_ASSERT_UNLESS` aid readability in certain test constructions or
|
214
|
+
conditional statements.
|
215
|
+
|
216
|
+
##### `TEST_ASSERT_NULL (pointer)`
|
217
|
+
|
218
|
+
##### `TEST_ASSERT_NOT_NULL (pointer)`
|
219
|
+
|
220
|
+
|
221
|
+
### Signed and Unsigned Integers (of all sizes)
|
222
|
+
|
223
|
+
Large integer sizes can be disabled for build targets that do not support them.
|
224
|
+
For example, if your target only supports up to 16 bit types, by defining the
|
225
|
+
appropriate symbols Unity can be configured to omit 32 and 64 bit operations
|
226
|
+
that would break compilation (see Unity documentation for more). Refer to
|
227
|
+
Advanced Asserting later in this document for advice on dealing with other word
|
228
|
+
sizes.
|
229
|
+
|
230
|
+
##### `TEST_ASSERT_EQUAL_INT (expected, actual)`
|
231
|
+
|
232
|
+
##### `TEST_ASSERT_EQUAL_INT8 (expected, actual)`
|
233
|
+
|
234
|
+
##### `TEST_ASSERT_EQUAL_INT16 (expected, actual)`
|
235
|
+
|
236
|
+
##### `TEST_ASSERT_EQUAL_INT32 (expected, actual)`
|
237
|
+
|
238
|
+
##### `TEST_ASSERT_EQUAL_INT64 (expected, actual)`
|
239
|
+
|
240
|
+
##### `TEST_ASSERT_EQUAL (expected, actual)`
|
241
|
+
|
242
|
+
##### `TEST_ASSERT_NOT_EQUAL (expected, actual)`
|
243
|
+
|
244
|
+
##### `TEST_ASSERT_EQUAL_UINT (expected, actual)`
|
245
|
+
|
246
|
+
##### `TEST_ASSERT_EQUAL_UINT8 (expected, actual)`
|
247
|
+
|
248
|
+
##### `TEST_ASSERT_EQUAL_UINT16 (expected, actual)`
|
249
|
+
|
250
|
+
##### `TEST_ASSERT_EQUAL_UINT32 (expected, actual)`
|
251
|
+
|
252
|
+
##### `TEST_ASSERT_EQUAL_UINT64 (expected, actual)`
|
253
|
+
|
254
|
+
|
255
|
+
### Unsigned Integers (of all sizes) in Hexadecimal
|
256
|
+
|
257
|
+
All `_HEX` assertions are identical in function to unsigned integer assertions
|
258
|
+
but produce failure messages with the `expected` and `actual` values formatted
|
259
|
+
in hexadecimal. Unity output is big endian.
|
260
|
+
|
261
|
+
##### `TEST_ASSERT_EQUAL_HEX (expected, actual)`
|
262
|
+
|
263
|
+
##### `TEST_ASSERT_EQUAL_HEX8 (expected, actual)`
|
264
|
+
|
265
|
+
##### `TEST_ASSERT_EQUAL_HEX16 (expected, actual)`
|
266
|
+
|
267
|
+
##### `TEST_ASSERT_EQUAL_HEX32 (expected, actual)`
|
268
|
+
|
269
|
+
##### `TEST_ASSERT_EQUAL_HEX64 (expected, actual)`
|
270
|
+
|
271
|
+
|
272
|
+
### Masked and Bit-level Assertions
|
273
|
+
|
274
|
+
Masked and bit-level assertions produce output formatted in hexadecimal. Unity
|
275
|
+
output is big endian.
|
276
|
+
|
277
|
+
|
278
|
+
##### `TEST_ASSERT_BITS (mask, expected, actual)`
|
279
|
+
|
280
|
+
Only compares the masked (i.e. high) bits of `expected` and `actual` parameters.
|
281
|
+
|
282
|
+
|
283
|
+
##### `TEST_ASSERT_BITS_HIGH (mask, actual)`
|
284
|
+
|
285
|
+
Asserts the masked bits of the `actual` parameter are high.
|
286
|
+
|
287
|
+
|
288
|
+
##### `TEST_ASSERT_BITS_LOW (mask, actual)`
|
289
|
+
|
290
|
+
Asserts the masked bits of the `actual` parameter are low.
|
291
|
+
|
292
|
+
|
293
|
+
##### `TEST_ASSERT_BIT_HIGH (bit, actual)`
|
294
|
+
|
295
|
+
Asserts the specified bit of the `actual` parameter is high.
|
296
|
+
|
297
|
+
|
298
|
+
##### `TEST_ASSERT_BIT_LOW (bit, actual)`
|
299
|
+
|
300
|
+
Asserts the specified bit of the `actual` parameter is low.
|
301
|
+
|
302
|
+
### Integer Less Than / Greater Than
|
303
|
+
|
304
|
+
These assertions verify that the `actual` parameter is less than or greater
|
305
|
+
than `threshold` (exclusive). For example, if the threshold value is 0 for the
|
306
|
+
greater than assertion will fail if it is 0 or less.
|
307
|
+
|
308
|
+
##### `TEST_ASSERT_GREATER_THAN (threshold, actual)`
|
309
|
+
|
310
|
+
##### `TEST_ASSERT_GREATER_THAN_INT (threshold, actual)`
|
311
|
+
|
312
|
+
##### `TEST_ASSERT_GREATER_THAN_INT8 (threshold, actual)`
|
313
|
+
|
314
|
+
##### `TEST_ASSERT_GREATER_THAN_INT16 (threshold, actual)`
|
315
|
+
|
316
|
+
##### `TEST_ASSERT_GREATER_THAN_INT32 (threshold, actual)`
|
317
|
+
|
318
|
+
##### `TEST_ASSERT_GREATER_THAN_UINT (threshold, actual)`
|
319
|
+
|
320
|
+
##### `TEST_ASSERT_GREATER_THAN_UINT8 (threshold, actual)`
|
321
|
+
|
322
|
+
##### `TEST_ASSERT_GREATER_THAN_UINT16 (threshold, actual)`
|
323
|
+
|
324
|
+
##### `TEST_ASSERT_GREATER_THAN_UINT32 (threshold, actual)`
|
325
|
+
|
326
|
+
##### `TEST_ASSERT_GREATER_THAN_HEX8 (threshold, actual)`
|
327
|
+
|
328
|
+
##### `TEST_ASSERT_GREATER_THAN_HEX16 (threshold, actual)`
|
329
|
+
|
330
|
+
##### `TEST_ASSERT_GREATER_THAN_HEX32 (threshold, actual)`
|
331
|
+
|
332
|
+
##### `TEST_ASSERT_LESS_THAN (threshold, actual)`
|
333
|
+
|
334
|
+
##### `TEST_ASSERT_LESS_THAN_INT (threshold, actual)`
|
335
|
+
|
336
|
+
##### `TEST_ASSERT_LESS_THAN_INT8 (threshold, actual)`
|
337
|
+
|
338
|
+
##### `TEST_ASSERT_LESS_THAN_INT16 (threshold, actual)`
|
339
|
+
|
340
|
+
##### `TEST_ASSERT_LESS_THAN_INT32 (threshold, actual)`
|
341
|
+
|
342
|
+
##### `TEST_ASSERT_LESS_THAN_UINT (threshold, actual)`
|
343
|
+
|
344
|
+
##### `TEST_ASSERT_LESS_THAN_UINT8 (threshold, actual)`
|
345
|
+
|
346
|
+
##### `TEST_ASSERT_LESS_THAN_UINT16 (threshold, actual)`
|
347
|
+
|
348
|
+
##### `TEST_ASSERT_LESS_THAN_UINT32 (threshold, actual)`
|
349
|
+
|
350
|
+
##### `TEST_ASSERT_LESS_THAN_HEX8 (threshold, actual)`
|
351
|
+
|
352
|
+
##### `TEST_ASSERT_LESS_THAN_HEX16 (threshold, actual)`
|
353
|
+
|
354
|
+
##### `TEST_ASSERT_LESS_THAN_HEX32 (threshold, actual)`
|
355
|
+
|
356
|
+
|
357
|
+
### Integer Ranges (of all sizes)
|
358
|
+
|
359
|
+
These assertions verify that the `expected` parameter is within +/- `delta`
|
360
|
+
(inclusive) of the `actual` parameter. For example, if the expected value is 10
|
361
|
+
and the delta is 3 then the assertion will fail for any value outside the range
|
362
|
+
of 7 - 13.
|
363
|
+
|
364
|
+
##### `TEST_ASSERT_INT_WITHIN (delta, expected, actual)`
|
365
|
+
|
366
|
+
##### `TEST_ASSERT_INT8_WITHIN (delta, expected, actual)`
|
367
|
+
|
368
|
+
##### `TEST_ASSERT_INT16_WITHIN (delta, expected, actual)`
|
369
|
+
|
370
|
+
##### `TEST_ASSERT_INT32_WITHIN (delta, expected, actual)`
|
371
|
+
|
372
|
+
##### `TEST_ASSERT_INT64_WITHIN (delta, expected, actual)`
|
373
|
+
|
374
|
+
##### `TEST_ASSERT_UINT_WITHIN (delta, expected, actual)`
|
375
|
+
|
376
|
+
##### `TEST_ASSERT_UINT8_WITHIN (delta, expected, actual)`
|
377
|
+
|
378
|
+
##### `TEST_ASSERT_UINT16_WITHIN (delta, expected, actual)`
|
379
|
+
|
380
|
+
##### `TEST_ASSERT_UINT32_WITHIN (delta, expected, actual)`
|
381
|
+
|
382
|
+
##### `TEST_ASSERT_UINT64_WITHIN (delta, expected, actual)`
|
383
|
+
|
384
|
+
##### `TEST_ASSERT_HEX_WITHIN (delta, expected, actual)`
|
385
|
+
|
386
|
+
##### `TEST_ASSERT_HEX8_WITHIN (delta, expected, actual)`
|
387
|
+
|
388
|
+
##### `TEST_ASSERT_HEX16_WITHIN (delta, expected, actual)`
|
389
|
+
|
390
|
+
##### `TEST_ASSERT_HEX32_WITHIN (delta, expected, actual)`
|
391
|
+
|
392
|
+
##### `TEST_ASSERT_HEX64_WITHIN (delta, expected, actual)`
|
393
|
+
|
394
|
+
|
395
|
+
### Structs and Strings
|
396
|
+
|
397
|
+
##### `TEST_ASSERT_EQUAL_PTR (expected, actual)`
|
398
|
+
|
399
|
+
Asserts that the pointers point to the same memory location.
|
400
|
+
|
401
|
+
|
402
|
+
##### `TEST_ASSERT_EQUAL_STRING (expected, actual)`
|
403
|
+
|
404
|
+
Asserts that the null terminated (`'\0'`)strings are identical. If strings are
|
405
|
+
of different lengths or any portion of the strings before their terminators
|
406
|
+
differ, the assertion fails. Two NULL strings (i.e. zero length) are considered
|
407
|
+
equivalent.
|
408
|
+
|
409
|
+
|
410
|
+
##### `TEST_ASSERT_EQUAL_MEMORY (expected, actual, len)`
|
411
|
+
|
412
|
+
Asserts that the contents of the memory specified by the `expected` and `actual`
|
413
|
+
pointers is identical. The size of the memory blocks in bytes is specified by
|
414
|
+
the `len` parameter.
|
415
|
+
|
416
|
+
|
417
|
+
### Arrays
|
418
|
+
|
419
|
+
`expected` and `actual` parameters are both arrays. `num_elements` specifies the
|
420
|
+
number of elements in the arrays to compare.
|
421
|
+
|
422
|
+
`_HEX` assertions produce failure messages with expected and actual array
|
423
|
+
contents formatted in hexadecimal.
|
424
|
+
|
425
|
+
For array of strings comparison behavior, see comments for
|
426
|
+
`TEST_ASSERT_EQUAL_STRING` in the preceding section.
|
427
|
+
|
428
|
+
Assertions fail upon the first element in the compared arrays found not to
|
429
|
+
match. Failure messages specify the array index of the failed comparison.
|
430
|
+
|
431
|
+
##### `TEST_ASSERT_EQUAL_INT_ARRAY (expected, actual, num_elements)`
|
432
|
+
|
433
|
+
##### `TEST_ASSERT_EQUAL_INT8_ARRAY (expected, actual, num_elements)`
|
434
|
+
|
435
|
+
##### `TEST_ASSERT_EQUAL_INT16_ARRAY (expected, actual, num_elements)`
|
436
|
+
|
437
|
+
##### `TEST_ASSERT_EQUAL_INT32_ARRAY (expected, actual, num_elements)`
|
438
|
+
|
439
|
+
##### `TEST_ASSERT_EQUAL_INT64_ARRAY (expected, actual, num_elements)`
|
440
|
+
|
441
|
+
##### `TEST_ASSERT_EQUAL_UINT_ARRAY (expected, actual, num_elements)`
|
442
|
+
|
443
|
+
##### `TEST_ASSERT_EQUAL_UINT8_ARRAY (expected, actual, num_elements)`
|
444
|
+
|
445
|
+
##### `TEST_ASSERT_EQUAL_UINT16_ARRAY (expected, actual, num_elements)`
|
446
|
+
|
447
|
+
##### `TEST_ASSERT_EQUAL_UINT32_ARRAY (expected, actual, num_elements)`
|
448
|
+
|
449
|
+
##### `TEST_ASSERT_EQUAL_UINT64_ARRAY (expected, actual, num_elements)`
|
450
|
+
|
451
|
+
##### `TEST_ASSERT_EQUAL_HEX_ARRAY (expected, actual, num_elements)`
|
452
|
+
|
453
|
+
##### `TEST_ASSERT_EQUAL_HEX8_ARRAY (expected, actual, num_elements)`
|
454
|
+
|
455
|
+
##### `TEST_ASSERT_EQUAL_HEX16_ARRAY (expected, actual, num_elements)`
|
456
|
+
|
457
|
+
##### `TEST_ASSERT_EQUAL_HEX32_ARRAY (expected, actual, num_elements)`
|
458
|
+
|
459
|
+
##### `TEST_ASSERT_EQUAL_HEX64_ARRAY (expected, actual, num_elements)`
|
460
|
+
|
461
|
+
##### `TEST_ASSERT_EQUAL_PTR_ARRAY (expected, actual, num_elements)`
|
462
|
+
|
463
|
+
##### `TEST_ASSERT_EQUAL_STRING_ARRAY (expected, actual, num_elements)`
|
464
|
+
|
465
|
+
##### `TEST_ASSERT_EQUAL_MEMORY_ARRAY (expected, actual, len, num_elements)`
|
466
|
+
|
467
|
+
`len` is the memory in bytes to be compared at each array element.
|
468
|
+
|
469
|
+
|
470
|
+
### Each Equal (Arrays to Single Value)
|
471
|
+
|
472
|
+
`expected` are single values and `actual` are arrays. `num_elements` specifies
|
473
|
+
the number of elements in the arrays to compare.
|
474
|
+
|
475
|
+
`_HEX` assertions produce failure messages with expected and actual array
|
476
|
+
contents formatted in hexadecimal.
|
477
|
+
|
478
|
+
Assertions fail upon the first element in the compared arrays found not to
|
479
|
+
match. Failure messages specify the array index of the failed comparison.
|
480
|
+
|
481
|
+
#### `TEST_ASSERT_EACH_EQUAL_INT (expected, actual, num_elements)`
|
482
|
+
|
483
|
+
#### `TEST_ASSERT_EACH_EQUAL_INT8 (expected, actual, num_elements)`
|
484
|
+
|
485
|
+
#### `TEST_ASSERT_EACH_EQUAL_INT16 (expected, actual, num_elements)`
|
486
|
+
|
487
|
+
#### `TEST_ASSERT_EACH_EQUAL_INT32 (expected, actual, num_elements)`
|
488
|
+
|
489
|
+
#### `TEST_ASSERT_EACH_EQUAL_INT64 (expected, actual, num_elements)`
|
490
|
+
|
491
|
+
#### `TEST_ASSERT_EACH_EQUAL_UINT (expected, actual, num_elements)`
|
492
|
+
|
493
|
+
#### `TEST_ASSERT_EACH_EQUAL_UINT8 (expected, actual, num_elements)`
|
494
|
+
|
495
|
+
#### `TEST_ASSERT_EACH_EQUAL_UINT16 (expected, actual, num_elements)`
|
496
|
+
|
497
|
+
#### `TEST_ASSERT_EACH_EQUAL_UINT32 (expected, actual, num_elements)`
|
498
|
+
|
499
|
+
#### `TEST_ASSERT_EACH_EQUAL_UINT64 (expected, actual, num_elements)`
|
500
|
+
|
501
|
+
#### `TEST_ASSERT_EACH_EQUAL_HEX (expected, actual, num_elements)`
|
502
|
+
|
503
|
+
#### `TEST_ASSERT_EACH_EQUAL_HEX8 (expected, actual, num_elements)`
|
504
|
+
|
505
|
+
#### `TEST_ASSERT_EACH_EQUAL_HEX16 (expected, actual, num_elements)`
|
506
|
+
|
507
|
+
#### `TEST_ASSERT_EACH_EQUAL_HEX32 (expected, actual, num_elements)`
|
508
|
+
|
509
|
+
#### `TEST_ASSERT_EACH_EQUAL_HEX64 (expected, actual, num_elements)`
|
510
|
+
|
511
|
+
#### `TEST_ASSERT_EACH_EQUAL_PTR (expected, actual, num_elements)`
|
512
|
+
|
513
|
+
#### `TEST_ASSERT_EACH_EQUAL_STRING (expected, actual, num_elements)`
|
514
|
+
|
515
|
+
#### `TEST_ASSERT_EACH_EQUAL_MEMORY (expected, actual, len, num_elements)`
|
516
|
+
|
517
|
+
`len` is the memory in bytes to be compared at each array element.
|
518
|
+
|
519
|
+
|
520
|
+
### Floating Point (If enabled)
|
521
|
+
|
522
|
+
##### `TEST_ASSERT_FLOAT_WITHIN (delta, expected, actual)`
|
523
|
+
|
524
|
+
Asserts that the `actual` value is within +/- `delta` of the `expected` value.
|
525
|
+
The nature of floating point representation is such that exact evaluations of
|
526
|
+
equality are not guaranteed.
|
527
|
+
|
528
|
+
|
529
|
+
##### `TEST_ASSERT_EQUAL_FLOAT (expected, actual)`
|
530
|
+
|
531
|
+
Asserts that the ?actual?value is "close enough to be considered equal" to the
|
532
|
+
`expected` value. If you are curious about the details, refer to the Advanced
|
533
|
+
Asserting section for more details on this. Omitting a user-specified delta in a
|
534
|
+
floating point assertion is both a shorthand convenience and a requirement of
|
535
|
+
code generation conventions for CMock.
|
536
|
+
|
537
|
+
|
538
|
+
##### `TEST_ASSERT_EQUAL_FLOAT_ARRAY (expected, actual, num_elements)`
|
539
|
+
|
540
|
+
See Array assertion section for details. Note that individual array element
|
541
|
+
float comparisons are executed using T?EST_ASSERT_EQUAL_FLOAT?.That is, user
|
542
|
+
specified delta comparison values requires a custom-implemented floating point
|
543
|
+
array assertion.
|
544
|
+
|
545
|
+
|
546
|
+
##### `TEST_ASSERT_FLOAT_IS_INF (actual)`
|
547
|
+
|
548
|
+
Asserts that `actual` parameter is equivalent to positive infinity floating
|
549
|
+
point representation.
|
550
|
+
|
551
|
+
|
552
|
+
##### `TEST_ASSERT_FLOAT_IS_NEG_INF (actual)`
|
553
|
+
|
554
|
+
Asserts that `actual` parameter is equivalent to negative infinity floating
|
555
|
+
point representation.
|
556
|
+
|
557
|
+
|
558
|
+
##### `TEST_ASSERT_FLOAT_IS_NAN (actual)`
|
559
|
+
|
560
|
+
Asserts that `actual` parameter is a Not A Number floating point representation.
|
561
|
+
|
562
|
+
|
563
|
+
##### `TEST_ASSERT_FLOAT_IS_DETERMINATE (actual)`
|
564
|
+
|
565
|
+
Asserts that ?actual?parameter is a floating point representation usable for
|
566
|
+
mathematical operations. That is, the `actual` parameter is neither positive
|
567
|
+
infinity nor negative infinity nor Not A Number floating point representations.
|
568
|
+
|
569
|
+
|
570
|
+
##### `TEST_ASSERT_FLOAT_IS_NOT_INF (actual)`
|
571
|
+
|
572
|
+
Asserts that `actual` parameter is a value other than positive infinity floating
|
573
|
+
point representation.
|
574
|
+
|
575
|
+
|
576
|
+
##### `TEST_ASSERT_FLOAT_IS_NOT_NEG_INF (actual)`
|
577
|
+
|
578
|
+
Asserts that `actual` parameter is a value other than negative infinity floating
|
579
|
+
point representation.
|
580
|
+
|
581
|
+
|
582
|
+
##### `TEST_ASSERT_FLOAT_IS_NOT_NAN (actual)`
|
583
|
+
|
584
|
+
Asserts that `actual` parameter is a value other than Not A Number floating
|
585
|
+
point representation.
|
586
|
+
|
587
|
+
|
588
|
+
##### `TEST_ASSERT_FLOAT_IS_NOT_DETERMINATE (actual)`
|
589
|
+
|
590
|
+
Asserts that `actual` parameter is not usable for mathematical operations. That
|
591
|
+
is, the `actual` parameter is either positive infinity or negative infinity or
|
592
|
+
Not A Number floating point representations.
|
593
|
+
|
594
|
+
|
595
|
+
### Double (If enabled)
|
596
|
+
|
597
|
+
##### `TEST_ASSERT_DOUBLE_WITHIN (delta, expected, actual)`
|
598
|
+
|
599
|
+
Asserts that the `actual` value is within +/- `delta` of the `expected` value.
|
600
|
+
The nature of floating point representation is such that exact evaluations of
|
601
|
+
equality are not guaranteed.
|
602
|
+
|
603
|
+
|
604
|
+
##### `TEST_ASSERT_EQUAL_DOUBLE (expected, actual)`
|
605
|
+
|
606
|
+
Asserts that the `actual` value is "close enough to be considered equal" to the
|
607
|
+
`expected` value. If you are curious about the details, refer to the Advanced
|
608
|
+
Asserting section for more details. Omitting a user-specified delta in a
|
609
|
+
floating point assertion is both a shorthand convenience and a requirement of
|
610
|
+
code generation conventions for CMock.
|
611
|
+
|
612
|
+
|
613
|
+
##### `TEST_ASSERT_EQUAL_DOUBLE_ARRAY (expected, actual, num_elements)`
|
614
|
+
|
615
|
+
See Array assertion section for details. Note that individual array element
|
616
|
+
double comparisons are executed using `TEST_ASSERT_EQUAL_DOUBLE`.That is, user
|
617
|
+
specified delta comparison values requires a custom implemented double array
|
618
|
+
assertion.
|
619
|
+
|
620
|
+
|
621
|
+
##### `TEST_ASSERT_DOUBLE_IS_INF (actual)`
|
622
|
+
|
623
|
+
Asserts that `actual` parameter is equivalent to positive infinity floating
|
624
|
+
point representation.
|
625
|
+
|
626
|
+
|
627
|
+
##### `TEST_ASSERT_DOUBLE_IS_NEG_INF (actual)`
|
628
|
+
|
629
|
+
Asserts that `actual` parameter is equivalent to negative infinity floating point
|
630
|
+
representation.
|
631
|
+
|
632
|
+
|
633
|
+
##### `TEST_ASSERT_DOUBLE_IS_NAN (actual)`
|
634
|
+
|
635
|
+
Asserts that `actual` parameter is a Not A Number floating point representation.
|
636
|
+
|
637
|
+
|
638
|
+
##### `TEST_ASSERT_DOUBLE_IS_DETERMINATE (actual)`
|
639
|
+
|
640
|
+
Asserts that `actual` parameter is a floating point representation usable for
|
641
|
+
mathematical operations. That is, the ?actual?parameter is neither positive
|
642
|
+
infinity nor negative infinity nor Not A Number floating point representations.
|
643
|
+
|
644
|
+
|
645
|
+
##### `TEST_ASSERT_DOUBLE_IS_NOT_INF (actual)`
|
646
|
+
|
647
|
+
Asserts that `actual` parameter is a value other than positive infinity floating
|
648
|
+
point representation.
|
649
|
+
|
650
|
+
|
651
|
+
##### `TEST_ASSERT_DOUBLE_IS_NOT_NEG_INF (actual)`
|
652
|
+
|
653
|
+
Asserts that `actual` parameter is a value other than negative infinity floating
|
654
|
+
point representation.
|
655
|
+
|
656
|
+
|
657
|
+
##### `TEST_ASSERT_DOUBLE_IS_NOT_NAN (actual)`
|
658
|
+
|
659
|
+
Asserts that `actual` parameter is a value other than Not A Number floating
|
660
|
+
point representation.
|
661
|
+
|
662
|
+
|
663
|
+
##### `TEST_ASSERT_DOUBLE_IS_NOT_DETERMINATE (actual)`
|
664
|
+
|
665
|
+
Asserts that `actual` parameter is not usable for mathematical operations. That
|
666
|
+
is, the `actual` parameter is either positive infinity or negative infinity or
|
667
|
+
Not A Number floating point representations.
|
668
|
+
|
669
|
+
|
670
|
+
## Advanced Asserting: Details On Tricky Assertions
|
671
|
+
|
672
|
+
This section helps you understand how to deal with some of the trickier
|
673
|
+
assertion situations you may run into. It will give you a glimpse into some of
|
674
|
+
the under-the-hood details of Unity's assertion mechanisms. If you're one of
|
675
|
+
those people who likes to know what is going on in the background, read on. If
|
676
|
+
not, feel free to ignore the rest of this document until you need it.
|
677
|
+
|
678
|
+
|
679
|
+
### How do the EQUAL assertions work for FLOAT and DOUBLE?
|
680
|
+
|
681
|
+
As you may know, directly checking for equality between a pair of floats or a
|
682
|
+
pair of doubles is sloppy at best and an outright no-no at worst. Floating point
|
683
|
+
values can often be represented in multiple ways, particularly after a series of
|
684
|
+
operations on a value. Initializing a variable to the value of 2.0 is likely to
|
685
|
+
result in a floating point representation of 2 x 20,but a series of
|
686
|
+
mathematical operations might result in a representation of 8 x 2-2
|
687
|
+
that also evaluates to a value of 2. At some point repeated operations cause
|
688
|
+
equality checks to fail.
|
689
|
+
|
690
|
+
So Unity doesn't do direct floating point comparisons for equality. Instead, it
|
691
|
+
checks if two floating point values are "really close." If you leave Unity
|
692
|
+
running with defaults, "really close" means "within a significant bit or two."
|
693
|
+
Under the hood, `TEST_ASSERT_EQUAL_FLOAT` is really `TEST_ASSERT_FLOAT_WITHIN`
|
694
|
+
with the `delta` parameter calculated on the fly. For single precision, delta is
|
695
|
+
the expected value multiplied by 0.00001, producing a very small proportional
|
696
|
+
range around the expected value.
|
697
|
+
|
698
|
+
If you are expecting a value of 20,000.0 the delta is calculated to be 0.2. So
|
699
|
+
any value between 19,999.8 and 20,000.2 will satisfy the equality check. This
|
700
|
+
works out to be roughly a single bit of range for a single-precision number, and
|
701
|
+
that's just about as tight a tolerance as you can reasonably get from a floating
|
702
|
+
point value.
|
703
|
+
|
704
|
+
So what happens when it's zero? Zero - even more than other floating point
|
705
|
+
values - can be represented many different ways. It doesn't matter if you have
|
706
|
+
0 x 20 or 0 x 263.It's still zero, right? Luckily, if you
|
707
|
+
subtract these values from each other, they will always produce a difference of
|
708
|
+
zero, which will still fall between 0 plus or minus a delta of 0. So it still
|
709
|
+
works!
|
710
|
+
|
711
|
+
Double precision floating point numbers use a much smaller multiplier, again
|
712
|
+
approximating a single bit of error.
|
713
|
+
|
714
|
+
If you don't like these ranges and you want to make your floating point equality
|
715
|
+
assertions less strict, you can change these multipliers to whatever you like by
|
716
|
+
defining UNITY_FLOAT_PRECISION and UNITY_DOUBLE_PRECISION. See Unity
|
717
|
+
documentation for more.
|
718
|
+
|
719
|
+
|
720
|
+
### How do we deal with targets with non-standard int sizes?
|
721
|
+
|
722
|
+
It's "fun" that C is a standard where something as fundamental as an integer
|
723
|
+
varies by target. According to the C standard, an `int` is to be the target's
|
724
|
+
natural register size, and it should be at least 16-bits and a multiple of a
|
725
|
+
byte. It also guarantees an order of sizes:
|
726
|
+
|
727
|
+
```C
|
728
|
+
char <= short <= int <= long <= long long
|
729
|
+
```
|
730
|
+
|
731
|
+
Most often, `int` is 32-bits. In many cases in the embedded world, `int` is
|
732
|
+
16-bits. There are rare microcontrollers out there that have 24-bit integers,
|
733
|
+
and this remains perfectly standard C.
|
734
|
+
|
735
|
+
To make things even more interesting, there are compilers and targets out there
|
736
|
+
that have a hard choice to make. What if their natural register size is 10-bits
|
737
|
+
or 12-bits? Clearly they can't fulfill _both_ the requirement to be at least
|
738
|
+
16-bits AND the requirement to match the natural register size. In these
|
739
|
+
situations, they often choose the natural register size, leaving us with
|
740
|
+
something like this:
|
741
|
+
|
742
|
+
```C
|
743
|
+
char (8 bit) <= short (12 bit) <= int (12 bit) <= long (16 bit)
|
744
|
+
```
|
745
|
+
|
746
|
+
Um... yikes. It's obviously breaking a rule or two... but they had to break SOME
|
747
|
+
rules, so they made a choice.
|
748
|
+
|
749
|
+
When the C99 standard rolled around, it introduced alternate standard-size types.
|
750
|
+
It also introduced macros for pulling in MIN/MAX values for your integer types.
|
751
|
+
It's glorious! Unfortunately, many embedded compilers can't be relied upon to
|
752
|
+
use the C99 types (Sometimes because they have weird register sizes as described
|
753
|
+
above. Sometimes because they don't feel like it?).
|
754
|
+
|
755
|
+
A goal of Unity from the beginning was to support every combination of
|
756
|
+
microcontroller or microprocessor and C compiler. Over time, we've gotten really
|
757
|
+
close to this. There are a few tricks that you should be aware of, though, if
|
758
|
+
you're going to do this effectively on some of these more idiosyncratic targets.
|
759
|
+
|
760
|
+
First, when setting up Unity for a new target, you're going to want to pay
|
761
|
+
special attention to the macros for automatically detecting types
|
762
|
+
(where available) or manually configuring them yourself. You can get information
|
763
|
+
on both of these in Unity's documentation.
|
764
|
+
|
765
|
+
What about the times where you suddenly need to deal with something odd, like a
|
766
|
+
24-bit `int`? The simplest solution is to use the next size up. If you have a
|
767
|
+
24-bit `int`, configure Unity to use 32-bit integers. If you have a 12-bit
|
768
|
+
`int`, configure Unity to use 16 bits. There are two ways this is going to
|
769
|
+
affect you:
|
770
|
+
|
771
|
+
1. When Unity displays errors for you, it's going to pad the upper unused bits
|
772
|
+
with zeros.
|
773
|
+
2. You're going to have to be careful of assertions that perform signed
|
774
|
+
operations, particularly `TEST_ASSERT_INT_WITHIN`.Such assertions might wrap
|
775
|
+
your `int` in the wrong place, and you could experience false failures. You can
|
776
|
+
always back down to a simple `TEST_ASSERT` and do the operations yourself.
|
777
|
+
|
778
|
+
|
779
|
+
*Find The Latest of This And More at [ThrowTheSwitch.org](https://throwtheswitch.org)*
|