Workspace 6.21.5
|
This class is designed to simplify the use of loading workspace test files for use as test cases. More...
#include <Workspace/testworkspaceassertionfile.h>
Inherits QObject.
Classes | |
struct | TestCase |
Public Types | |
using | TestCases = std::list< TestCase > |
Public Member Functions | |
TestWorkspaceAssertionFile (const QStringList requiredPlugins, const TestCases tests) | |
Sets the data for this test case. | |
Static Public Member Functions | |
static QString | prependTestPath (const QString &file) |
Adds the test directory to the supplied filename. | |
This class is designed to be used as a base class when implementing tests which just require loading a test workspace file (loading and asserting successful execution of the workspace is enough to run the test). For example when then workspace contains assertion operations which perform the actual checks. By specifying the parameters of the test (workspace files to load / plugins) when initalising the base class from the constructor it is possible to control the operation of the test case. You can then further extend the tests by adding further tests cases using the QT slots feature for the additional test cases. For an example of how this operates in practice see the implementation of test_disabledconnection.cpp.
At the moment the implementation of this class is only useful for "static" workspace tests where the workspace is loaded and run without changes, however it is imagined and desirable that in future this functionality be extended to cater for also suppling workspace input and output values and then also checking these which would cater for a wider range of test cases. This extension is tracked in the issue: WORKSPACE-7535
|
inline |
requiredPlugins | The necessary plugins that need to be loaded for running the tests. |
tests | A list of pairs containing the indiviual test names (in first) and the workspace file to load (in second). |
Only the specified plugins are loaded.
|
inlinestatic |
file | The filename to apply the directory to. |
This implementation is somewhat fragile in that it internally relies on a macro which changes based on the test build location, so this relies on the function being inlined and the value being stamped in correctly by the compiler in each of the inlined instances. This means this implementation is somewhat fragile and could stop working at any time because the compiler chooses to ignore the inline directive. For now this implementation works so it is fine, however we may have to refactor this in the future if we find it becomes unstable.