In order to help ensure data related bugs are found and fixed prior to releasing updates we have added a new system with the ability to run sanity checks on datatables.
In Editor
The easiest way to run the tool is by going into the editor, and running it from the toolbar there (Edit > Exiles Tools > Commandlets > Check DataTables).
This will freeze the editor for a short time, then the results will be visible in the output log. You can filter by CheckDataTables to get the relevant lines.
You can enter the names of the tests you want to run as a comma separated list in the
Arguments
field to avoid running the whole test suite
Commandlet
The tool can also be run by launching a commandlet (CheckDataTables) this can be done by starting the editor with the commandline argument :
-run=CheckDataTables <potential commandline arguments>
This will run the commandlet which will run the tests and print out any errors it finds. The result will be saved into ConanSandbox.log.
Similar to data table checks, we can run checks on any blueprint as explained here: Public Blutilities w Example
The tests are defined entirely in blueprints, and can be created in 3 steps.
Create a blueprint class with base class “DataTableTest“
Override GetRowStructure on the blueprint, returning the name of the structure of the DataTable we want to create a test for
Create a function with an input of the type defined in GetRowStructure, and add the logic for the test
When creating the test functions there are a few key points to be aware of :
The system will only find it if the inputs to the function are exactly the structure we want to test and then an FName, and the function doesn’t have any outputs. (If you have a function with other inputs/outputs it will not be treated as a test. This can be useful for making common functions to use between the tests)
In order to return an error you must set the “Error Message“ variable to a value, this is what will be output to the log, so try to be clear about what the error is
If you set the “Error Message“ variable to any value this is treated as an error, so don’t set it if the test passes
You can create as many test function as you want in the same blueprint, this helps to keep the tests seperated and well defined
Now I will show the creation of some basic ItemTableTests. First we create the blueprint:
Now we need to define the row structure that we want our test to operate on, we do this by overriding the function “Get Row Structure“:
In this case we want to test the ItemTable, which has the structure type “ItemTableRow“, so our GetRowStructure function should look like this:
Now we create our new function, TestAttachReach, and make sure it has two input pins of the right types, and NO outputs:
-
Item Table Row
(or whichever row you defined in GetRowStructure)
- FName (Should contain the row name corresponding to the struct)
Now in our function we can define our test, and set an error message if the test fails:
Some test classes might require to cache some data to make running tests more efficient. For instance, the test “TestXXRecipe” that makes sure that no visible recipe has the prefix “XX_” needs to go through the whole FeatTable to see if a feat is providing that recipe as a reward.
Instead of going through the whole table for every recipe row to test, we can use a pre-compute step where all the visible recipes will be cached in a set. It can be done by overriding PreTestActions in the event graph:
This function will be called before any test is run, but after the ModControllers have merged the DLC tables into their respective base tables.
In case we need to even more control over the data table tests we have 2 more events, one triggering after the tests ( Post Test Action ) and one triggering for each datatable ( Per Asset Action )
In case we want to exclude some of the tests from the global run, we can toggle the IsExcludedFromRegularTest variable in the test blueprint
In that case the only way to run the test from this file is via argument
All current tests can be found under /Content/Dev/DataTableTests: