Previously each test was bounded to a set of connections. Now the tests are generic, and theoretically you can execute any test with any connection. If the connection is not compatible the test can raise an exception or better validate that the library raises an exception.
With this new system the setups are defined in python files, they are instances of the dataclasses previously introduced.
The default file and setup that is executed is tests_setup.TESTS_SETUP. This is a file that is gitignored, so every developer can define there the setup that they have on their desk without commiting changes. The user could also change the setup indicating it by argument (--setup)
Commited to the repository there's the virtual drive setup, and a rack_setup.
The setups now also have a flag indicating if they have a connection to rack service, If so the firmware will be uploaded through that. If not, for now the FW version will be ignored (we could work on that)
There's also a specific EthercatMultiSlaveSetup for multidrive fixtures, that now will be run as an independent step on the pipeline, instead of each slave stage.
Now that the setups have a name the stages of the pipeline are much more explicit (Everest Ethercat) instead of indicating slave number
[Test]
Run on jenkins
Run some a virtual drive test, a soem test and the test_start_pdos multislave test
[Doc] Refactored setup systems
Previously each test was bounded to a set of connections. Now the tests are generic, and theoretically you can execute any test with any connection. If the connection is not compatible the test can raise an exception or better validate that the library raises an exception.
With this new system the setups are defined in python files, they are instances of the dataclasses previously introduced.
The default file and setup that is executed is tests_setup.TESTS_SETUP. This is a file that is gitignored, so every developer can define there the setup that they have on their desk without commiting changes. The user could also change the setup indicating it by argument (--setup)
Commited to the repository there's the virtual drive setup, and a rack_setup.
The setups now also have a flag indicating if they have a connection to rack service, If so the firmware will be uploaded through that. If not, for now the FW version will be ignored (we could work on that)
There's also a specific EthercatMultiSlaveSetup for multidrive fixtures, that now will be run as an independent step on the pipeline, instead of each slave stage. Now that the setups have a name the stages of the pipeline are much more explicit (Everest Ethercat) instead of indicating slave number
[Test] Run on jenkins Run some a virtual drive test, a soem test and the test_start_pdos multislave test