.._Development: For_Development =============== Background Reading ------------------ The *syqada* executable is constructed by bin/package from bin/syqada-template, which wraps bin/syqada.py. bin/syqada.py is a dispatcher that runs one of Automator.py, Tool.py, BatchRunner.py, or batch_tool.py depending on its first argument. You'll want to read :ref:`Architecture` and :ref:`System_Internals` to get some clue to the mysteries of SyQADA's organic development and consequently sometimes twisted structure. Thereafter, the test suite might be a useful guide. The test suite is pretty comprehensive, although some of the behaviors that only affect reporting were mostly tested at the command line. if you grep around the test suite for the key concepts you're interested in, you will probably find a test that shows you how it is put together and invoked. Testing ------- The test suite is governed by test/unit_test.py, and can be run by invoking that file. However, my standard approach is instead to invoke:: bin/package which runs the test suite, and if the whole suite succeeds, builds docs, builds and brands a distribution package, and then runs a couple of final integration tests on the package itself before zipping it all up. >>> bin/package docs will skip the tests and just build the docs. >>> bin/package skip-tests will skip the tests and build docs and package. >>> bin/package help will list individual unit test files and list for each one all the ways it can be invoked. For example, the Tool test suite can be invoked in several ways, including >>> bin/package Tool or >>> bin/package tools or >>> bin/package tailend There are three global tags:: basic runs the infrastructure tests middle runs the JobGeneration, JobBatch, and BatchRunner tests tailend runs the Automator, Replication, and integration tests >>> bin/package only testname ... will run only the testname test suite(s). >>> bin/package ignore testname ... will skip the testname test suite(s) and run everything else.