test building blocks

Each test structure is simple: Peers send messages. Other peers are expected to receive messages. Messages are supposed to be transmitted when they are sent before or during an encounter. Encounter can be stopped and re-established. Basis of an encounter is either a direct connection between two peer or a hub mediated connection.

Messages can be short, longer or even huge - we have to define what that really means in terms of number of bytes.

We need to test if any reasonable variant of connecting, sending, disconnnecting works.

We can even name it like this: CSD or more specific Cab;Sa:1;Dab;Eb:1 which is to be read as: a connects to b, a sends message 1, a disconnects from B, we expect B to receive message 1.

Or even more complex: Cab;Sa:1;Dab;Sa2;Eb:1,!2 Same scenario but a sends another message 2 that is not expected to be received by b. That scenario language is used as input for our test generator but also as shorthand for insiders.

We need building blocks to test

• Connection establishment (direct, hub mediated)
• Checking for the expected result

We need a well defined set of test sequences. That test set defines what to expect from a certain version of our software.

Test language

• C(onnect)ab .. two mandatory parameters labeling two peers. Peer A connects to peer B. Peer B made itself available by e.g. opening a port
• S(end)a[:message] .. mandatory parameter labels a peer; optional parameter describes a single message (default: 1_1)
• message->id_len .. id labels the message (default 1), second - message len (default 1).
• D(isconnect)ab .. two mandatory parameters labeling two peers. Peer A disconnects from B.
• E(xpected)a:messageDescriptionList .. a labels one peer
• messageDescriptionList -> messageDescription[,] * .. comma separated message list
• messageDescription -> [!]message .. message is meant to received without leading '!'. It must not be received otherwise.

A test script generator must be aware of synchronisation issues, e.g. tests on received message must wait until the actual message was sent and had enough time to reach receiver. Rule of thumb: Every connect is lead and trailed by a wait. Every send leads to an additional wait on receiver side.

context

That language helps to describe scenarios. A test word has the tendency to become unreadable when they get longer. We will label certain scenarios with shorter names.

We will introduce a basic scenarios: CS (connect & send) that stands for Cab;Sa:1_1;Eb:1_1.

We can explicitly label the scenario name context to avoid ambiguities, like Basic:CS.