List view
After we release 1.0.0, we need to think in which direction does pykiso will go. **What we learned up to 1.0.0:** * integration tests are rarely used mid project * simple configuration is important for users * modularity on the selection of the modules to build a test is important, even if it means that the tests are unstable first * sticking to Python helps. At first, we had decided to have an embedded flavour in pykiso because we were testing embedded systems. But because Python language became so big, many engineers now know how to code in python * managing the typings are important **How should pykiso 2.x.x evolve to:** A refocus to our initial goal: integration-tests As developer, we want to develop and test our software. This way, we tend to use one specific testing framework to do so. If you are a C developer, you may use unity, if you are a rust developer, you may use the native test framework for it. By experience, we know our auxiliary and connectors are really robust. We could extend them in two ways: * a simulation can be built on top of them (in a python file), a user can run their script which will call pykiso that will orchestrate the simulation * a REST API or grpc API of the auxiliaries can be exposed to trigger different actions on the auxiliaries * small rust lib can be created to communicate with pykiso and auxiliaries (TBD) * small c or c++, etc libs can be used to communicate with pykiso (TBD) * pykiso should expose a central API that allows the trigger of simulations * If test should be run as blackbox, pytest should be the used framework. Future: * potential use of GenAI to generate the simulation * potential use of GenAI to help configuring pykiso * validation-test-suite to validate new auxiliaries and connectors
No due date- No due date•2/9 issues closed
- No due date•2/3 issues closed
- No due date•1/8 issues closed
Configure test -> auto generate yaml Start/stop/select tests Graphical log display and choose logs to display Auto-detection of attached hardware (scroll menu) and possible yaml to execute generate log test result file Remote connection to a server that can execute the tests for you
No due date* Discuss how the repo structure should look like * CI/CD pipeline for it (linter, unittests, integration tests? SIL?) * C++ code structure & IP removal
No due date•0/2 issues closed- No due date
Integration of a Pigweed test auxiliary allowing users to trigger and control tests running on it Link: https://github.com/google/pigweed
No due dateIntegration of a zephyr test auxiliary allowing users to trigger and control tests running on the OS Link: https://www.zephyrproject.org/
No due date•1/2 issues closedA set of tutorials to enable future users to learn how to use pykiso. * prelude: catchy introduction with general overview * part 1: installation & overiew of the functionalities * part 2: test app example (code, flashing & test run) * part 3: communication test example (e.g.serial) * part 4: extending the ITF (plugins, external aux con loading)
No due date