Good Practices
Provtest is a testing tool. It can can save much time on projects and support if some good practices are followed.
-
Use only one test file for one "component" (a specific module for instance, or package, or functionality) : it serves no one to have 30 provtest files to test an object interface
-
Provtest files must be independent
-
Limit the dependency between unit test at maximum : it is in general a bad idea to create an object in one test and to use it in another test, though it is sometimes unevitable
-
Do not use the "system" action intensively as the easiest way to do complex things in complex scripts : this action should only call system commands (ls, cat etc) not users scripts
-
Do not use the "sleep" action intensively as sleeping 10 seconds on a 8 CPUS 2Gz is not the same, from a testing point of vue, as sleeping 10 seconds on a 1 CPU 450Mhz
-
Give short names to objects : objects referenced are automatically scoped with the test name exactly to allow this.
-
Do not write too complex unit tests : a unit test must exactly target the criteria you want to validate (an operation behaviour for instance)
-
Do not assign a flow to a unit test when it does not need it
-
Write a comprehensive description for each unit test
-
Group action sub-elements when possible
-
Correctly indent provtest files
-
Use infsup substitution instead of legacy < and > if the data you manipulate contains lots of '<' and '>'
-
Do not declare one flow per test : mutualize them, just like you would do with a XMI legacy Fulfillment Provisioning flow
-
Even if some custom code is needed in order to test a specific component, this code should not contain any data relative to test, but only an interface allowing to test what you want from the outside. The injected data should only appear in the provtest file. This will allow people who read the provtest file to know exactly what the test does, which data is injected etc.