staon / otest2 Goto Github PK

Allow repeated run of a suite or test case.

Proposal:
If a fixture variable derives from a special interface, the framework will repeat the test object until the fixture says stop. The fixture object will survive resurrection of the test object, hence it will able to keep the status of repeating.

Currently the API for assertion functions allows just to add generic text messages. Design and implement a new API which allows more rich manipulations with the output. E.g. coloring of the output useful for assertions printing differences between texts.

A set of assertions checking state of STL containers

An assertion function comparing floating points values with specified precission.

A description how a container test mark is printed.

Remove constraints in the data model:

• a testcase may be standalone with no wrapping in a suite
• suites may be nested

The parser, generator and reporters must be fixed.

A possibility to define user tags of test suites and cases. And a possibility to run tests with selected tags.

Proposal:

• an annotation allowing tagging of a test object
• a command line option

As the boost test or catch2 frameworks do, implement an assertion function which parses the relation expression and allows to print left and right operand separately.

Because the OTest2 uses the libclang library the functionality may be implemented in much more clear way than prepending of the ->* operator and stealing the left operand.

If the state function is declared with user data parameters it cannot be used by the switching function - the function pointer doesn't match the parameter type.

A tool for management of the test mark storage:

• deletion of a mark,
• comparing of current and stored mark,
• storing of current marks.

Sections inside test cases which causes repeated invocation of the case. Hence, the same initialization code may be shared by several runs.

A set of assertion functions checking content of text files.

Custom objects with special initialization/destruction during the start-up/tear-down phases of their parent test object.

Implement a feature which allows to create a custom class which allows usage of assertion and control functions inside its methods.

A possibility to pass custom data from the main function to test cases and the start-up/tear-down functions.

Proposal:
The DSL will allow to add parameters to the functions (test states and the start-up/tear-down functions). The otest2 pre-processor will generate a code which grabs the user data from an object placed in the otest2 context and passes them correctly typed into the function.