I have build custom "test platforms" — dedicated Python programs that drive, observe, and verify concurrent/distributed systems while they're under load and stress. They augment unit/integration tests.
The core part of a test platform is called gDS (global Data Store), a Python data-handling pattern built on multiprocessing.Manager(), generated from a simple schema file (.dd) by a compiler (gDSCompile). You define and update your tables and references and the compiler generates the "helper" code for you. Together with the necessary application code, concurrency is managed much like it is in an operating system.
There are 4 case studies at this time in various states of operation (Linux/Python 3) and documentation (some are still being "painted" at this time):
Feedback is welcome, especially on the gDS pattern itself — I'm curious as to whether others have had issues managing concurrency and solved them differently (or similiary).
1 comment
[ 3.3 ms ] story [ 21.1 ms ] threadThe core part of a test platform is called gDS (global Data Store), a Python data-handling pattern built on multiprocessing.Manager(), generated from a simple schema file (.dd) by a compiler (gDSCompile). You define and update your tables and references and the compiler generates the "helper" code for you. Together with the necessary application code, concurrency is managed much like it is in an operating system.
There are 4 case studies at this time in various states of operation (Linux/Python 3) and documentation (some are still being "painted" at this time):
A site with a broad writeup: https://testingcomplexsystems.com A link to code documentation: https://talborough.github.io/tcsDocs/ And a repo: https://github.com/talborough/testingComplexSystems
Feedback is welcome, especially on the gDS pattern itself — I'm curious as to whether others have had issues managing concurrency and solved them differently (or similiary).