The Story So Far:
Software Engineers are not really fond of test tools. They use them, if the project management requires so, but usually they don’t love them. Why is this so?
Software development projects are often subdivided in phases Specification, Design, Implementation, Testing, Documentation, and Maintenance. Most software engineers consider the first three phases creative and interesting, while the last three are more or less boring. Good tools are made for a specific purpose. Test tools are made for testing. Testing is boring. So while test tools can help (for example, by reducing the time needed to run the tests), they are not associated with the sexy parts of the development process. Test tools are primarily made for managers, so managers love them, developers don’t.
In reality, there is often not such a hard cut between implementation and testing – even a compiler run is some kind of test (for syntax errors, for example). But test tools don’t help here, as they are made for testing, not for the implementation phase. Well, most of them. Except tbot. tbot was written by developers, for developers. It’s main purpose is not to generate test charts for the management (it does that, too, of course), but to automate boring parts of the developer’s work. So tbot is focussed on the tasks that developers have to perform routinely, to eliminate necessary, but non-creative parts of the daily work. While most other test tools add to the work a developer has to perform, tbot actually reduces the amount of work.
In the end, the developer has more time to focus on the creative, mentally challenging, sexy parts of his job, and the manager can access a lot of statistical data about performed tests. And they all lived happily ever after…
A nice fairy tale? No! Try it out yourself:
- Tests are performed on real hardware.
- Even complex scenarios are fully supported (for example power cycling, tests for boot loaders (e.g. U-Boot), operating systems (e.g. Linux) and device drivers, applications, communication with other systems etc.
- tbot is implemented in Python. Extensions and test cases are also written in Python and thus very easy.
- tbot is modular and easy to configure. It can be flexibly adapted to different lab equipment (for example computerized power switching, plugging and removing of SDCards or USB sticks, etc.)
- Test cases can run other test cases, so that it is very easy to construct test groups and hierarchies, or to re-use existing test cases for other projects.
- An event-driven postprocessing allows to generate for example statistical data or graphic representations of the test results. Another interesting use case is the automated generation of documentation.
- tbot can easily be integrated into other CI and Test Systems like Buildbot or Jenkins.
- tbot is completely Open Source (GPLv2).
tbot is a testing/automation tool that is focused on usage in embedded development. At its core tbot just provides utilities for interaction with remote hosts/targets and an extensive library of routines that are common in embedded development/testing.
tbot aims to be a support for the developer while working on a project and without much modification also allow running tests in an automated setting (CI).