mirror of
https://github.com/catchorg/Catch2.git
synced 2024-11-26 07:16:10 +01:00
Docs: TABs to Spaces
Replace TABs with four (4) spaces in code docs.
This commit is contained in:
parent
9773d89ab4
commit
7667a7d89c
@ -19,8 +19,8 @@ Nonetheless there are still some occasions where finer control is needed. For th
|
||||
|
||||
## main()/ implementation
|
||||
|
||||
CATCH_CONFIG_MAIN // Designates this as implementation file and defines main()
|
||||
CATCH_CONFIG_RUNNER // Designates this as implementation file
|
||||
CATCH_CONFIG_MAIN // Designates this as implementation file and defines main()
|
||||
CATCH_CONFIG_RUNNER // Designates this as implementation file
|
||||
|
||||
Although Catch is header only it still, internally, maintains a distinction between interface headers and headers that contain implementation. Only one source file in your test project should compile the implementation headers and this is controlled through the use of one of these macros - one of these identifiers should be defined before including Catch in *exactly one implementation file in your project*.
|
||||
|
||||
@ -34,16 +34,16 @@ Implied by both `CATCH_CONFIG_MAIN` and `CATCH_CONFIG_RUNNER`.
|
||||
|
||||
## Prefixing Catch macros
|
||||
|
||||
CATCH_CONFIG_PREFIX_ALL
|
||||
CATCH_CONFIG_PREFIX_ALL
|
||||
|
||||
To keep test code clean and uncluttered Catch uses short macro names (e.g. ```TEST_CASE``` and ```REQUIRE```). Occasionally these may conflict with identifiers from platform headers or the system under test. In this case the above identifier can be defined. This will cause all the Catch user macros to be prefixed with ```CATCH_``` (e.g. ```CATCH_TEST_CASE``` and ```CATCH_REQUIRE```).
|
||||
|
||||
|
||||
## Terminal colour
|
||||
|
||||
CATCH_CONFIG_COLOUR_NONE // completely disables all text colouring
|
||||
CATCH_CONFIG_COLOUR_WINDOWS // forces the Win32 console API to be used
|
||||
CATCH_CONFIG_COLOUR_ANSI // forces ANSI colour codes to be used
|
||||
CATCH_CONFIG_COLOUR_NONE // completely disables all text colouring
|
||||
CATCH_CONFIG_COLOUR_WINDOWS // forces the Win32 console API to be used
|
||||
CATCH_CONFIG_COLOUR_ANSI // forces ANSI colour codes to be used
|
||||
|
||||
Yes, I am English, so I will continue to spell "colour" with a 'u'.
|
||||
|
||||
@ -57,14 +57,14 @@ Typically you should place the ```#define``` before #including "catch.hpp" in yo
|
||||
|
||||
## Console width
|
||||
|
||||
CATCH_CONFIG_CONSOLE_WIDTH = x // where x is a number
|
||||
CATCH_CONFIG_CONSOLE_WIDTH = x // where x is a number
|
||||
|
||||
Catch formats output intended for the console to fit within a fixed number of characters. This is especially important as indentation is used extensively and uncontrolled line wraps break this.
|
||||
By default a console width of 80 is assumed but this can be controlled by defining the above identifier to be a different value.
|
||||
|
||||
## stdout
|
||||
|
||||
CATCH_CONFIG_NOSTDOUT
|
||||
CATCH_CONFIG_NOSTDOUT
|
||||
|
||||
To support platforms that do not provide `std::cout`, `std::cerr` and
|
||||
`std::clog`, Catch does not usem the directly, but rather calls
|
||||
|
@ -45,7 +45,7 @@ int main( int argc, char* argv[] )
|
||||
|
||||
int returnCode = session.applyCommandLine( argc, argv );
|
||||
if( returnCode != 0 ) // Indicates a command line error
|
||||
return returnCode;
|
||||
return returnCode;
|
||||
|
||||
// writing to session.configData() or session.Config() here
|
||||
// overrides command line args
|
||||
@ -94,7 +94,7 @@ int main( int argc, char* argv[] )
|
||||
// Let Catch (using Clara) parse the command line
|
||||
int returnCode = session.applyCommandLine( argc, argv );
|
||||
if( returnCode != 0 ) // Indicates a command line error
|
||||
return returnCode;
|
||||
return returnCode;
|
||||
|
||||
// if set on the command line then 'height' is now set at this point
|
||||
if( height > 0 )
|
||||
|
@ -20,10 +20,10 @@ Tags allow an arbitrary number of additional strings to be associated with a tes
|
||||
|
||||
As an example - given the following test cases:
|
||||
|
||||
TEST_CASE( "A", "[widget]" ) { /* ... */ }
|
||||
TEST_CASE( "B", "[widget]" ) { /* ... */ }
|
||||
TEST_CASE( "C", "[gadget]" ) { /* ... */ }
|
||||
TEST_CASE( "D", "[widget][gadget]" ) { /* ... */ }
|
||||
TEST_CASE( "A", "[widget]" ) { /* ... */ }
|
||||
TEST_CASE( "B", "[widget]" ) { /* ... */ }
|
||||
TEST_CASE( "C", "[gadget]" ) { /* ... */ }
|
||||
TEST_CASE( "D", "[widget][gadget]" ) { /* ... */ }
|
||||
|
||||
The tag expression, ```"[widget]"``` selects A, B & D. ```"[gadget]"``` selects C & D. ```"[widget][gadget]"``` selects just D and ```"[widget],[gadget]"``` selects all four test cases.
|
||||
|
||||
@ -37,7 +37,7 @@ All tag names beginning with non-alphanumeric characters are reserved by Catch.
|
||||
|
||||
* `[!hide]` or `[.]` - causes test cases to be skipped from the default list (i.e. when no test cases have been explicitly selected through tag expressions or name wildcards). The hide tag is often combined with another, user, tag (for example `[.][integration]` - so all integration tests are excluded from the default run but can be run by passing `[integration]` on the command line). As a short-cut you can combine these by simply prefixing your user tag with a `.` - e.g. `[.integration]`. Because the hide tag has evolved to have several forms, all forms are added as tags if you use one of them.
|
||||
|
||||
* `[!throws]` - lets Catch know that this test is likely to throw an exception even if successful. This causes the test to be excluded when running with `-e` or `--nothrow`.
|
||||
* `[!throws]` - lets Catch know that this test is likely to throw an exception even if successful. This causes the test to be excluded when running with `-e` or `--nothrow`.
|
||||
|
||||
* `[!mayfail]` - doesn't fail the test if any given assertion fails (but still reports it). This can be useful to flag a work-in-progress, or a known issue that you don't want to immediately fix but still want to track in your tests.
|
||||
|
||||
@ -55,11 +55,11 @@ All tag names beginning with non-alphanumeric characters are reserved by Catch.
|
||||
|
||||
Between tag expressions and wildcarded test names (as well as combinations of the two) quite complex patterns can be constructed to direct which test cases are run. If a complex pattern is used often it is convenient to be able to create an alias for the expression. This can be done, in code, using the following form:
|
||||
|
||||
CATCH_REGISTER_TAG_ALIAS( <alias string>, <tag expression> )
|
||||
CATCH_REGISTER_TAG_ALIAS( <alias string>, <tag expression> )
|
||||
|
||||
Aliases must begin with the `@` character. An example of a tag alias is:
|
||||
|
||||
CATCH_REGISTER_TAG_ALIAS( "[@nhf]", "[failing]~[.]" )
|
||||
CATCH_REGISTER_TAG_ALIAS( "[@nhf]", "[failing]~[.]" )
|
||||
|
||||
Now when `[@nhf]` is used on the command line this matches all tests that are tagged `[failing]`, but which are not also hidden.
|
||||
|
||||
|
@ -10,8 +10,8 @@ This is the standard way of providing string conversions in C++ - and the chance
|
||||
|
||||
```
|
||||
std::ostream& operator << ( std::ostream& os, T const& value ) {
|
||||
os << convertMyTypeToString( value );
|
||||
return os;
|
||||
os << convertMyTypeToString( value );
|
||||
return os;
|
||||
}
|
||||
```
|
||||
|
||||
@ -24,10 +24,10 @@ If you don't want to provide an ```operator <<``` overload, or you want to conve
|
||||
|
||||
```
|
||||
namespace Catch {
|
||||
template<>
|
||||
template<>
|
||||
struct StringMaker<T> {
|
||||
static std::string convert( T const& value ) {
|
||||
return convertMyTypeToString( value );
|
||||
static std::string convert( T const& value ) {
|
||||
return convertMyTypeToString( value );
|
||||
}
|
||||
};
|
||||
}
|
||||
@ -56,7 +56,7 @@ By default all exceptions deriving from `std::exception` will be translated to s
|
||||
|
||||
```
|
||||
CATCH_TRANSLATE_EXCEPTION( MyType& ex ) {
|
||||
return ex.message();
|
||||
return ex.message();
|
||||
}
|
||||
```
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user