Pathways glossary

ATS

ATSes

Automatic Test Script

Automated Test Script

An ATS is a scripted test to ‘prove’ (or disprove) a part of the developed PUT works correctly. As such it delivers only one bit of information: verified of fail. This implies it does verify (check) the results of test.

An ATS typically consists of a number of steps, like starting a session, doing several operations, and verifying the results. Each step, not only the verification once, have to be successful to get an ‘OK’.

ATSfile

ATStest

As a single ATSfile can contain several ATStests and both are typically called ATS, the suffixes file and test are sometime used distinguish them.

TsTbrick

brick

A (test) brick is the basic, reusable, unit to build (all) ATSes. A brick offers a conceptual, human oriented set of commands to the ATS; so the upper-interface of the brick is independend of the technology of the PUT.

Typically, the brick’s implementation should also not depend on (PUT-implementation & -interfacing) technology depending; it makes the brick better reusable.
There are some brick-like unit for that; see: cobblestone, gate

gate

During the executing an ATS all kind of commands and results are passed to and from the PUT, by an interface called the gate. The implementation of a gate is typically specific to the technology of that that PUT. At the same time, the role of the gate is to hide that technology. Such that cobblestones are less depending on that specific PUT and bricks not at all.

interface

Deprecated since version pre-alfa: Old name for gate; do not use anymore

cobblestone

A rough kind of brick, for special cases. By example to extend a pathways.puts.put

A real brick has a functional interface; with cobblestone a second, lower-level way to interact with the PUT possible. Which isn’t used in most tests, but can be convenient in exceptional cases. It better to have a test, that scripted with to many details, then having no option to automate it.

This is best explained with a simple web-calculator. A (human) user can control it by clicking buttons, reading or entering some text, etc. With a cobblestone that level of control is available for a script. Although, a good test isn’t build out of this kind of commands. They use more functional commands, like: ‘add two numbers’; a typical brick-command.

With a cobblestone those smaller steps, like clicking, entering test and reading values are possible. Just for in case they are needed to test the exception.

Secondly, cobblestones are often used to script real bricks. By example the ‘add two numbers’ bricks-command can be implemented by entering a some strings, clicking a few buttons, and reading the result.

PUT

Product Under Test

Depending on the context, the term put can refer to the actual product that is tested, or to the proxy-object that represents it.

The proxy-object is typically a subclass of pathways.puts.put, or one of it subclasses in pathways.puts, which can be extended with cobblestones

feed

The feed part of a test-vector are used as input for the PUT.

expected

expected results

The expected results (or shortly: expected) part of a test-vector specify the values that the PUT should return. They are (smartly) compared with the actual results.

actuals

actual results

This are the values the PUT outputs and are compared to the expected results to verify correctness.

Note that the compare has to be smart; not all parts of the output are relevant. By example an (generated) XML-file typically contains a datestamp; which will vary each run. So that part is typically filtered out

conditions

New in version Future: Currently no support is available for conditions. Only feed and expected can be used now.

Some tests may need more complex validations then comparing the expected results with the actual results after giving the PUT an input feed. By example, real-time demands may specify a maximum delay. This kind of conditions can be given in the condition part of a test-vector.

TstVector

Todo

TstVector

fixture

fixtures

Todo

fixture