Up until now the knowledge repository contained the collector commands (the .ind scripts) in a fairly simple directory structure:
All the commands are placed in different folders / packages under the parsers directory of the project. Alongside the commands there were also the .input and .output files, which were used to either test the commands or to get an idea of what should the input and output look like - the .input describes the device’s response to the command’s remote operation, while the .output describes the parsed result.
We now have changed this structure in order to make it possible to create more tests per command and in order to make it more compatible with developers’ conventions.
The new structure
The first change is the separation of the actual commands -- the .ind files -- from the test files; the commands are now located under parsers/src, while the test files are located under parsers/test.
Each command has a test directory containing all of its test files. The directory is located in the same path and file-name of the command itself; for instance, if a command is located in parsers/src/path/to/command.ind, then its tests will be located in parsers/test/path/to/command/.
The test file
Inside the test directory there is the main test file, named test.json, which describes the structure of tests, which is basically a combination of separate test-cases. The file looks as follows:
It is a map from the name of the test-case to all the properties needed in order to run it. As you can see, each test-case has its own input and output files, where an input file might actually bundle a few inputs together (more on that later). The paths are relative to the test directory, and can be written in either unix format (single slash /) or windows format (double backslash \\).
There are additional properties associated with each test-case, such as the time-zone in which the test-case has been created (which may affect the output of certain commands that rely on the time-zone in order to parse timestamps).
Notice that the files of each test-case are located in a folder with the name of the test-case:
The input file
The input file, named input.json, has a structure that supports multiple input files; but why would we need multiple input files in a test-case? Doesn’t a device respond with a single output for a remote operation?
While this is true, some commands have multiple-steps; meaning, more than one remote-operation will be sent to the device during a single execution of the command.
Here is an example for an input.json of a command with one step only:
The JSON contains the steps value which is an array where each item describes the device’s responses for each step (the steps are ordered in the same order as in the command). Each item of this array is in fact its own array, since there may be multiple inputs for a step - one for each unique combination of dynamic variables.
Note that the inputs in the main input file are merely paths to the files containing the actual inputs (the paths are relative to the main file).
Here is an example of an input file describing the device’s response for a command with multiple steps (and multiple remote-operations):
The first step will always have but a single input and it’s never executed with any dynamic variables, while the next steps will always have one or more inputs, each associated with some dynamic variables.
The output file
The output file, named output.json, describes the final output of the command, after all the parsing is done:
The output of monitoring commands will contain metrics (either time-series / double or snapshot / complex), while the output of interrogation commands will contain the device tags.