-
Notifications
You must be signed in to change notification settings - Fork 565
Writing Tests
Uncrustify has two major classes of tests, in addition to a handful of ad-hoc tests. The major test types are "front-end" and "formatting" tests. This guide is concerned with the latter.
A "formatting" test is the most important test for uncrustify. These tests help to verify that uncrustify's main function — formatting source code — is working as expected.
There are several suites of formatting tests; one per language supported by uncrustify. Each suite describes a set of tests for that language, where each test has a number, configuration file, and input source file.
When it comes time to test a new feature or a fixed bug, there is a choice between reusing an existing test or writing a new one. New functionality should usually mean new tests. When fixing bugs, however, if there is an existing test (or tests) very similar to the new functionality, it may make sense to enhance one or more existing tests to also cover new or altered functionality.
When adding tests for new features,
prefer to add individual tests for each feature,
rather than testing multiple features at once.
(In many cases, "feature" will be synonymous with "option".)
For IARF options, prefer to test both remove and force,
with an input file designed so that each will cause a change in output.
When adding tests for bugs, prefer to reuse an existing configuration file if possible.
Each language suite has an assigned range of test numbers that is documented at the start of the file. When creating new tests, any unused test number may be used. However, it is preferred to keep similar tests grouped together, if possible.
(Also, this should go without saying, but, keep tests in order. The lists of tests in each suite should always remain sorted by the test number; otherwise it can be nearly impossible to find available numbers.)
Try to name tests after what is being tested.
For example, an input file named lambdas.cpp
might contain many variations of C++11 lambdas,
and can be used to test an array of options related to the formatting thereof.
Configuration files to be as minimal as possible;
ideally, containing only one line.
Single line configuration files in particular
should be named after their contents.
For example, sp_foo-r.cfg would contain sp_foo = remove.
Input files designed to test a specific option
may also be named after that option, e.g. sp_foo.cpp.
Tests that do not test a specific feature,
and are not conducive to a short, meaningful name,
may be named after reported issues.
In this case, both the input and configuration
will frequently be named like bug_1234.cfg, bug_1234.cpp.