Contents |
This page is intended to ease the transition between 0.1 and 0.8 for Developers.
The majority of the OTS wiki is written for the 0.8 branch and this is the best place to start. This page is not intended as a replacement for the rest of the Wiki, nor for looking at the code and epydocs!
The brief for 0.8 was to keep the architecture as close to 0.1 as possible. There are some changes worth noting.
A general principle that should be followed is that OTS should be attractive to as wider audience as possible. From a development culture that means making changes in ways that provide more benefits than hindrances.
Proprietary needs and architectures are met, but in a way that allows other configurations as far as is possible.
The extensions to OTS are no longer in-house additions. There might or might not be a reporting tool present and if there is the exact nature of it is unknown.
To meet this requirement there has been formalisation of the Plugins of which the Publisher is the principle beneficiary at present. So Email and Reporting tools are both variants of Publishers.
These are not the same as *Plugins* in CITA. The equivalent in OTS is described later
OTS is trending towards a Component Architecture. These components have distinct responsibilities. As well as the obvious first-hand benefits it provides benefits from an Open Sourced perspective
e.g. Test distribution is now a generic task distribution system (to see the open source benefits think Django: have you seen any code related to news sites?) OTS can provide code which is potentially usable by a far wider audience and will benefit if it is.
Interfaces are where most of the changes have occurred. Checking for validity, previously scattered around the code, has been moved closer to the interface into, what are effectively, Adaptation Layers.
The legacy XMLRPC interface is supported
The XMLRPC interface is fairly ragged and not that Pythonic. A couple of adaptation layers are waded through (combining with config parameters etc) to arrive at options.
Note: We stopped short of formalising this Adaptation for example with ZCA. Though this approach might be worth considering in the future.
The Plugins might have additional parameters that are needed from the external interface over and above those required by the core OTS system. Any additional parameters recieved at the interface are delegated into the Publisher Plugins.
A good example of this is in the demo PublisherPlugin. The Parent for the Widget is needed but Parent is not an OTS parameter. Thus OTS provides the interfaces to accommodate PublisherPlugins with diverse and previously unconsidered features.
Another key change is aiming towards naming consistency of the parameters and to work towards clearly defined names. These are defined in the Glossary.
Passing of data loosely by strings then validating them has been largely removed. Datatypes that are recognised system wide are now defined as Data Transport Objects.
The walking of the datastructure arising from the results XML and and the calling of abstracted interfaces at the nodes was previously termed Plugins. This was essentially the Visitor Pattern and the code has been reworked slightly to fit the pattern. The visitors only feed the Go / No Go assesment at this stage.
The interface into the Publishers is now the XML file itself. Whether the Visitor Pattern will remain in 0.9 will probably depend on the needs of 6 Pack.
The Architecture of OTS is such that concurrency on a Testrun level is handled in processes. There is no persistence layer as part of the core. Even if the persistence layer existed the bootstrapping CITA has shown that bootstrapping and accessing Testrun Id to be messy.
Hence 0.8 uses a uuid for Testrun Id.
Currently a WIP
A WIP. Likely to be deprecated
We are working towards all network communication going through AMQP
Working towards each module having a unittest module associated with it. This differs from the Django approach but more in-line with the rest of the Python world.
The Components have tests associated with them in the `tests/component` sub-directory. Significant effort has been made to make OTS 0.8 less dependent on manual system testing.