This commit change the regex to accept more spaces inside the brackets
of the TEST_RANGE().
I use clang-format through vscode "editor.formatOnSave": true feature and it produce
padding spaces inside the array brackets by default.
```c
int a[] = [1, 2];
```
is changed into
```c
int a[] = [ 1, 2 ];
```
Also, every time I save a file containing a TEST_RANGE() with ctrl + s,
it breaks it.
TEST_RANGE([start, stop, step]) generates following runs of the test
function: test(start), test(start + step), ..., test(start + n * step),
where start + n * step <= stop. The step must be positive.
If the test function takes several arguments, the following syntax must be used:
TEST_RANGE([arg1_start, arg1_stop, arg1_step], ..., [argN_start, argN_stop, argN_step])
This addresses issues #53 and #144.
Reported-by: Alex Rodriguez <alejmrm@gmail.com>
Reported-by: Hiroaki Yamazoe <PastelParasol@gmail.com>
By passing --omit_begin_end=1 to generate_test_runner.rb, the script
will now omit calls to UnityBegin and UnityEnd when running tests in a
suite.
This allows multiple suites to be executed in a row, and then have an overall
summary of the tests which were executed across all suites.
Converting RUN_TEST() from a macro to a function significantly reduces the size
of the compiled binary. On amd64, the largest test runner in the test suite
(testsample_DefaultsThroughCommandLine_runner.o) was reduced from 3.4 kB to 2.4
kB (stripped).
- Running time macros have been made more portable, previously it was not
possible to override all macros
- Running time macros will be executed by default test runner, and auto test
runners
- Adds a default execution time implementation for unix. (Previous default
implementation only worked on Windows)
- For embedded platforms there is a simple method of getting a default
implementation by defining a single macro UNITY_CLOCK_MS()
- Removed need for UNITY_EXEC_TIME_RESET. This was not being used for the default
implementations, if anything ever did need reset-like functionality it could
simply be wrapped up with the start or stop macros for that platform
MinGW supports a limited form of weak symbols, with the restriction
that weak/default implementations need to be defined in the same
translation unit they are called from. Strong/overriding symbols
may of course be specified in a different translation unit.
This is simpler and more flexible than embedding C code in the Ruby options
(:suite_setup and :suite_teardown). However, support for :suite_setup and
:suite_teardown is kept for backwards compatibility.
Several configurations are possible:
1. :suite_setup and :suite_teardown options provided and used.
2. :suite_setup and :suite_teardown options not provided (nil):
2a. Weak symbols not supported; suiteSetUp() and suiteTearDown() are not called.
It would be simpler to make user-provided functions mandatory in this case,
but it could break some pre-existing test suites.
2b. Weak symbols are supported and the stub implementations of suiteSetUp() and
suiteTearDown() are called if there are no user-provided functions.
2c. Weak symbols are supported but overridden by user-provided suiteSetUp() and
suiteTearDown() functions.
