Full-Abstraction for Must Testing Preorders

Abstract

The client ${\mathsf {must}}$ preorder relates tests (clients) instead of processes (servers). The existing characterisation of this preorder is unsatisfactory for it relies on the notion of usable clients which, in turn, are defined using an existential quantification over the servers that ensure client satisfaction. In this paper we characterise the set of usable clients for finite-branching LTSs, and give a sound and complete decision procedure for it. We also provide a novel coinductive characterisation of the client preorder, which we use to argue that the preorder is decidable, thus positively answering the question opened in [3, 6].

1 Introduction

The standard testing theory of De Nicola–Hennessy [12, 15] has recently been employed to provide theoretical foundations for web-services [9, 25] (where processes denote servers). To better fit that setting, in [6] this theory has been enriched with preorders for clients (tests) and peers (where both interacting parties mutually satisfy one another). Client preorders also tie testing theory with session type theory, as is outlined in [2]: they are instrumental in defining semantic models of the Gay & Hole subtyping [14] for first-order session types [3, Theorem 6.3.4] and [5, Theorem 5.2].

The testing preorders for clients and peers are contextual preorders, defined by comparing the capacity of either being satisfied by servers or the capacity of peers to mutually satisfy one another. This paper focuses on the client preorder due to the ${\mathsf {must}}$ testing relation [12, 15]: a client $r_2$ is better than a client $r_1$, denoted , whenever every server p that ${\mathsf {must}}$ pass $r_1$ also ${\mathsf {must}}$ pass $r_2$. Although this definition is easy to understand, it suffers from the endemic universal quantification over contexts (servers) and, by itself, does not give any effective proof method to determine pairs in the preorder. To solve this problem, contextual preorders usually come equipped with behavioural characterisations that avoid universal context quantification thereby facilitating reasoning. In [6] the authors develop such characterisations for the client and the peer ${\mathsf {must}}$ preorders; these preorders are however not fully-abstract, for they are defined modulo usable clients, i.e., clients that are satisfied by some server.

Fig. 1.

LTS depictions of the behaviours described in Eq. (1)

Usability is a pivotal notion that appears frequently in the literature of process calculi and web-service foundations, cf. viability in [18, 26] and controllability in [8, 24], and has already been studied, albeit for restricted or different settings, in [6, 7, 18, 25, 26]. In general though, the characterisation of usability is problematic, for solving it requires finding the conditions under which one can either (a) construct a server p that satisfies a given client, or (b) show that every p does not satisfy a given client. Whereas proving (b) is complicated by the universal quantification over all servers, the proof of (a) is complicated by the non-deterministic behaviour of clients. In particular, the approach in (a) is complicated because client usability is not compositional. For instance consider the following clients, whose behaviours are depicted in Fig. 1:

$$\begin{aligned} r_1 = c.(a.\mathop {\textsf {1}}\mathrel {+}b.\mathop {\textsf {0}}) \qquad \text { and }\qquad r_2 = c.(a.\mathop {\textsf {0}}\mathrel {+}b.\mathop {\textsf {1}}) \end{aligned}$$

(1)

where $\mathop {\textsf {1}}$ denotes satisfaction (success). Both clients are usable, since $r_1$ is satisfied by the server , and $r_2$ is satisfied by server . However, their composition $r_1 \mathrel {+}r_2$ is not a usable client, i.e., for every p; intuitively, this is because $r_1$ and $r_2$ impose opposite constraints on the processes that pass one or the other (e.g., does not satisfy $r_1 \mathrel {+}r_2$). A compositional analysis is even more unwieldy for recursive tests. For instance, the client is not usable because of the non-determinism analogous to $r_1 \mathrel {+}r_2$, and the unsuccessful computations along the infinite trace of interactions $(c.b)^*$; this argument works because infinite unsuccessful computations are catastrophic wrt. ${\mathsf {must}}$ testing.

This paper presents a sound and complete characterisation for usable clients with finite-branching LTSs. Through the results of [6] — in particular, the equivalence of usability for clients and peers stated on [6, p. 11] — our characterisation directly yields a fully-abstract characterisation for the ${\mathsf {must}}$ preorder for clients and peers. We go a step further and use this characterisation to develop a novel coinductive and fully-abstract characterisation of , which we find easier to use than the one of [6] when proving inequalities involving recursive clients. This coinductive characterisation turns out to be informed by our study on usability, and differs from related coinductive characterisations for the server preorder [18, 25] in a number of respects. Finally, our inductive definition for usable clients also provides deeper insights into the original client preorder of [6]: we show that limiting contexts to servers offering only finite interactions preserves the discriminating power of the original preorder. Our contributions are:

• a fully-abstract characterisation of usable clients, Theorem 2;

• a coinductive, fully-abstract characterisation of the client preorder , Theorem 5;

• a contextual preorder that is equivalent to but relies only on non-recursive contexts Theorem 6;

• decidability results for usable clients and the client preorder, Theorem 7.

The solutions devised here addressing client usability are directly relevant to controllability issues in service-oriented architectures [21, 30]. Our techniques may also be extended beyond this remit. The ever growing sizes of test suites, together with the ubiquitous reliance on testing for the increasing quality-assurance requirements in software systems, has directed the attention to non-deterministic (or flaky) tests. Such tests arise frequently in practice and their impact on software development has been the subject of various studies [19, 20, 22]. By some measures, ${\approx }4.56\%$ of test failures of the TAP (Test Anything Protocol) system at Google are caused by flaky tests [19]. We believe that our concepts, models and procedures can be extended to such testing methodologies to analyse detrimental non-deterministic behaviour arising in test suites, thereby reducing the gap between empirical practices and theory.

Structure of the paper: Sect. 2 outlines the preliminaries for client must testing. Section 3 tackles client usability and gives a fully-abstract definition for it. Section 4 uses this result to give a coinductive characterisation for client preorders. In Sect. 5 we present expressiveness results for servers with finite interactions together with decidability results for client usability and the client testing preorder. Section 6 concludes.

2 Preliminaries

Let $a, b, c, \ldots \in \mathsf {Act}$ be a set of actions, and let $\tau ,{\, \checkmark }$ be two distinct actions not in $\mathsf {Act}$; the first denotes internal unobservable activity whereas the second is used to report success of an experiment. To emphasise their distinctness, we use $\alpha \in \mathsf {Act}_{\tau }$ to denote $\mathsf {Act} \cup \{{\tau }\}$, and similarly for $\lambda \in \mathsf {Act}_{\tau {\, \checkmark }}$. We assume $\mathsf {Act}$ has an involution function, with $\overline{a}$ being the complement to a.

A labelled transition system, LTS, consists of a triple , where is a set of processes and is a transition relation between processes decorated with labels drawn from the set $\mathsf {Act}_{\tau {\, \checkmark }}$; we write in lieu of . An LTS is finite-branching if for all $p \in \mathsf {Proc}$ and for all $\lambda \in \mathsf {Act}_{\tau {\, \checkmark }}$, the set is finite. For $s \in (\mathsf {Act}_{{\, \checkmark }})^\star$ we also have the standard weak transitions, , defined by ignoring the occurrences of $\tau$s.

Fig. 2.

Syntax and Semantics of recursive $\mathsf {CCS} ^{\mu }$ with $\mathop {\textsf {1}}$.

We limit ourselves to finite-branching LTSs. Whenever sufficient, we describe such LTSs using a version of $\mathsf {CCS}$ with recursion [23] and augmented with a success operator, denoted as $\mathop {\textsf {1}}$. The syntax of this language is depicted in Fig. 2 and assumes a denumerable set of variables $x,y,z\ldots \in \mathsf {Var}$. For finite I, we use the notation $\sum _{i \in I} p_i$ to denote the resp. sequence of summations $p_1 \mathrel {+}\ldots \mathrel {+}p_{n}$ where $I=1..n$. Similarly, when I is a non-empty set, we define $\bigoplus _{i \in I} p_i = \sum _{i \in I} \tau .p_i$ to represent process internal choice. The transition relation between terms of the language is the least one determined by the (standard) rules in Fig. 2. As usual, binds x in p and we identify terms up to alpha conversion of bound variables. The operation denotes the unfolding of the recursive process , by substituting the term for the free occurrences of the variable x in p.

To model the interactions taking place between the server and the client contracts, we use the standard binary composition of contracts, $p \mathrel {||}r$, whose operational semantics is given in Fig. 2. A computation consists of sequence of $\tau$ actions of the form

(2)

It is maximal if it is infinite, or whenever $p_n\,{\mathrel {||}}\,r_n$ is the last state then . We say (2) is client-successful if there exists some $k \ge 0$ such that .

p.g.

Definition 1

(Client Testing preorder [6]). We write $p~{\mathsf {must}}~r$ if every maximal computation from $p \mathrel {||}r$ is client-successful, and write if, for every p, $p~{\mathsf {must}}~r_1$ implies $p~{\mathsf {must}}~r_2$.    $\blacksquare$

Although intuitive, the universal quantification on servers in Definition 1 complicates reasoning about . One way of surmounting this is by defining alternative characterisations for of Definition 1, that come equipped with practical proof methods.

2.1 Characterising the Client Preorder

In [6, Definition 3.10, p. 9], an alternative characterisation for the preorder is given and proven to be sound and complete. We recall this characterisation, restating the resp. notation. The alternative characterisation relies on unsuccessful traces: means that r may weakly perform the trace of external actions s reaching state $r'$ without passing through any successful state; in particular neither r nor $r'$ are successful. Formally, is the least relation satisfying (a) implies , and (b) if and then (i) implies , and (ii) implies . The unsuccessful acceptance set of r after s, are defined as

(3)

where denotes the strong actions of r. Intuitively, for the client r, the set records all the actions that lead r out of potentially deadlocked (i.e. stable) states that it reaches performing unsuccessfully the trace s. It turns out that these abstractions are fundamental to characterise must-testing preorders and also compliance preorders [3, 6, 25]. In the sequel, we shall also use whenever , and hold.

Example 1

For client we have , but for we have . We also have for .   $\blacksquare$

Note that, whenever , then any sequence of moves with trace s from r to a stable reduct $r'$ must pass through a successful state, for otherwise we would have for some $r'$.

Definition 2

(Usable Clients). .    $\blacksquare$

Example 2

Recall clients $r_1$ and $r_2$ from (1) in Sect. 1. We show that despite being individually usable, the sum of these clients is not: for every p. Fix a process p. If p does not offer an interaction on , then, plainly, . Suppose that ; to prove , it suffices to show that there exists a client r reached by $r_1 \mathrel {+}r_2$ by performing action c (i.e., $r \in \{ \, a.\mathop {\textsf {1}}\mathrel {+}b.\mathop {\textsf {0}}, a.\mathop {\textsf {0}}\mathrel {+}b.\mathop {\textsf {1}} \, \}$) such that . Indeed, for $r = a.\mathop {\textsf {1}}\mathrel {+}b.\mathop {\textsf {0}}$, if $p'~{\mathsf {must}}~r$ implies $p'$ has to interact on a and not on b, but then such a $p'$ does not satisfy the derivative $r= a.\mathop {\textsf {0}}\mathrel {+}b.\mathop {\textsf {1}}$, i.e., (because the composition $p' \mathrel {||}r$ is stable but not client-successful). Using a symmetric argument we deduce that if $p'~{\mathsf {must}}~ a.\mathop {\textsf {0}}\mathrel {+}b.\mathop {\textsf {1}}$ then , and thus no process p exists that satisfies $r_1 + r_2$; note that the argument above crucially exploits the external non-determinism of . The client from Sect. 1 is unusable for similar reasons, the analysis being more involved due to infinite computations.    $\blacksquare$

We let , and call the set the residuals of r after the unsuccessful trace s. We extend the notion of usability and say that r is usable along an unsuccessful trace s whenever , which is the least predicate satisfying the conditions (a) whenever , and (b) whenever (i) and (ii) if then . If , any state reachable from r by performing any unsuccessful subsequence of s is usable [6]. Finally, let denote all the usable actions for a client r after the unsuccessful trace s.

Definition 3

(Semantic client-preorder). Let if, for every such that , we have (i) , (ii) for every there exists a such that , (iii) implies .    $\blacksquare$

Theorem 1

In any finite branching LTS, if and only .

Proof

Follows from [6, Theorem 3.13] and König’s Infinity Lemma.

Definition 3 enjoys a few pleasing properties and, through Theorem 1, sheds light on behavioural properties of clients related by . Concretely, it shares a similar structure to well-studied characterisations of the (standard) must-testing preorder of [12, 15], where process convergence is replaced by client usability, and traces and acceptance sets are replaced by their unsuccessful counterparts (modulo usable actions). Unfortunately, Definition 3 has a major drawback: it is parametric wrt. the set of usable clients  (Definition 2), which relies on an existential quantifications over servers. As a result, the definition is not fully-abstract, and this makes it hard to use as proof technique and to ground decision procedures for  on it.

3 Characterising Usability

We use the behavioural predicates of Sect. 2.1, together with the new predicate in Definition 4, to formulate the characterising properties of the set of usable clients (Proposition 1). We use these predicates to construct a set that coincides with (Theorem 2); this gives us an inductive proof method for determining usability.

Definition 4

We write $r \Downarrow _{{\, \checkmark }}$ whenever for every infinite sequence of internal moves , there exists a state $r_i$ such that .    $\blacksquare$

Recalling Eq. (3), let . Proposition 1 crystallises the characteristic properties of usable clients, providing a blue print for our alternative definition Definition 5. Instead of giving a direct proof of this proposition, we obtain it indirectly as consequence of our other results.

Proposition 1

For every , if and only if

• 1. , and

• 2. if , then there exists implies .    $\square$

The proposition above states that a client r is usable if and only if, for every potentially deadlocked state $r'$ reached via silent moves by r, there exists an action a that leads $r'$ out of the potential deadlock, i.e., into another state $r''$ where $r''$ is certainly usable.

Example 3

We use Proposition 1 to discuss the (non) usability of clients from previous example. Recall $r_3 = \tau .(\mathop {\textsf {1}}\mathrel {+}\tau .\mathop {\textsf {0}})$, $r'_3 = r_3 + \tau .\mathop {\textsf {0}}$ and from Example 1. Since we have $r_3 \Downarrow _{{\, \checkmark }}$ and , $r_3$ satisfies both condition of Proposition 1, with the second one being trivially true. As a consequence $r_3$ is usable, and indeed . On the contrary, we have , thus $r'_3$ violates Proposition 1(2) and thus $r'_3$ is unusable. Client $r''_3$ is unusable as well, but violates Proposition 1(1) instead. Conversely, client satisfies both conditions of Proposition 1, and it is usable. For instance, $\mathop {\textsf {0}}~{\mathsf {must}}~r'''_3$.

A more involved client is $r_1 \mathrel {+}r_2$ from Example 2. There we proved that , and indeed $r_1 \mathrel {+}r_2$ does not satisfy Proposition 1(2). This is true because and , where

In turn, the reason why $r'$ is not usable is that , and Proposition 1(2) requires us to consider every set in $\{ \, \{ \, a,b \, \} \, \}$ — we have only $\{ \, a,b \, \}$ to consider — and show that for some action , . It turns out that neither action in satisfies this condition. For instance, in the case of action b, we have and , so violates Proposition 1(2) and as a result . The reasoning why action a is not a good candidate either is identical.   $\blacksquare$

Definition 5

Let be defined by letting whenever

• 1. $r \Downarrow _{{\, \checkmark }}$, and

• 2. if , then there exists an .

We let , the least fix-point of .    $\blacksquare$

The function is continuous over the CPO , thus Kleene fixed point theorem [31, Theorem 5.11] ensures that (the least fix-point of ) exists and is equal to where and .

The bulk of the soundness result follows as a corollary from the next lemma, which also lays bare the role of non-recursive servers in proving usability of clients.

Lemma 1

For every $n \in \mathbb {N}$ and $r \in \mathsf {Proc}$, implies that there exists a non-recursive server p such that $p~{\mathsf {must}}~r$.    $\square$

An inductive argument is used to prove that is complete wrt. , where we define the following measure over which to perform induction. We let denote the set of maximal computations of a composition $r \mathrel {||}p$ and, for every computation $c \in MC (r,p)$, we associate the number $\mathsf{\#itr}( c )$ denoting the number of interactions that take place between the initial state of c, and the first successful state of the computation c ( whenever c is unsuccessful). Let . For instance, if , we have , but .

Lemma 2

Let T be a tree with root v. If T is finite branching and it has a finite number of nodes, then the number of paths $v \longrightarrow \ldots$ is finite.    $\square$

Lemma 3

In a finite branching LTS, $p~{\mathsf {must}}~r$ implies the number is finite.

Proof

If $p~{\mathsf {must}}~r$, every reaches a successful state after a finite number of reductions. Since the number of interactions is not more than the number of reductions:

(4)

A set of successful computations from $r \mathrel {||}p$, e.g., $MC (r,p)$, may also be seen as a computation tree, where common prefixes reach the same node in the tree. In general, such a tree may have infinite depth. Consider the computation tree T obtained by truncating all the maximal computations of $r \mathrel {||}p$ at their first successful state, and let $TMC (r,p)$ be the set of all the computations obtained this way. It follows that

(5)

From , (4) and (5) we know that that is finite if the set is finite. This will follow from Lemma 2 if we prove that the tree T has a finite number of nodes. By the contrapositive of König’s Lemma [16, 17], since every node in the tree T above is finitely branching, and there are no infinite paths, then T necessarily contains a finite number of nodes. By Lemma 2, must also be finite, and hence we can put a (finite) natural number as an upper bound on the number of interactions required to reach success.    $\square$

Fig. 3.

Servers and clients to discuss the hypothesis in Lemma 3

If the LTS is not image-finite then Lemma 3 is false. To see why, consider the infinite branching client r and the server p depicted in Fig. 3. Since r engages in finite sequences of a actions which are unbounded in size, and the p offers any number of interactions on action , we have that $p~{\mathsf {must}}~r$, but the set MC(r, p) contains an infinite amount of computations, and the number is not finite. Dually, even if the LTS of a composition is finite branching and finite state, it is necessary that $p~{\mathsf {must}}~r$ for to be finite. Lemma 3 lets us associate a rank to every usable client r, defined as . The well-ordering of $\mathbb {N}$ ensures that $rank ( r )$ is defined for every usable r. When defined, the rank of a client r gives us information about its usability,¹ where we can stratify as follows:

(6)

Lemma 4

For every $i \in \mathbb {N}$, implies for some $j \le i$.    $\square$

We are now ready to prove the main result of this section.

Theorem 2

(Full-abstraction usability). The sets $\mathcal {U}$ and $\mathcal {U}_{\mathsf{bhv}}$ coincide.

Proof

To show , pick an . By (6), for some $i \!\in \! \mathbb {N}$, and by Lemma 4 we obtain for some $j\!\in \mathbb {N}^+$. To show , pick an . Definition 5 ensures that , thus for some $n \in \mathbb {N}$. Lemma 1 implies that . The reasoning applies to any , thus .    $\square$

4 The Client Preorder Revisited

By combining the definition of with of Definition 5, Theorem 2 yields a fully-abstract characterisation of the client preorder . In general, however, this characterisation still requires us to consider an infinite number of (unsuccessful) traces to establish client inequality. In this section, we put forth a novel coinductive definition for the client preorder and exploit the finite-branching property of the LTS to show that this definition characterises the contextual preorder , Theorem 5. We also argue that this new characterisation is easier to use in practice than Definition 3, a claim that is substantiated by showing how this coinductive preorder can be used to prove the second result in this section, namely that servers offering a finite amount of interactions are sufficient and necessary to distinguish clients, Theorem 6. Subsequently, in Theorem 7, we also show that the coinductive preorder is decidable for our client language.

Example 4

The use of is hindered, in practice, by the universal quantification over traces in its definition. Consider, for instance, clients $r_4$ and $r_5$,

where from Example 1. One way to prove amounts in showing that , even though this task is far from obvious. Concretely, the definition of requires us to show that for every trace $s \in \mathsf {Act} ^\star$ where holds, clauses (i), (ii) and (iii) of Definition 3 also hold. In this case, there are an infinite number of such unsuccessful traces s to consider and, a priori, there is no clear way how to do this in finite time. Specifically, there are (unsuccessful) traces that $r_4$ can perform while remaining usable at every step, such as $s=b^n$, but also (unsuccessful) traces that $r_4$ cannot perform (which trivially imply according to the definition in Sect. 2.1), such as $s=d(b^n)$, $s=(db)^n$ or $s=(ac)^n$.

The definition of does however rule out a number of traces to consider, and Definition 5 helps us with this analysis. For instance, for $s=a$, we have because and, by using similar reasoning to that in Example 3 for $r''_3$, we know that which implies and, by Theorem 2, we have .    $\square$

To overcome the problems outlined in Example 4, we identify three properties of the preorder , stated in Lemma 5, which partly motivate the conditions defining the transfer function in Definition 6. Conditions (ii) and (iii) are explained in greater detail as discussions to points (2) and (3c) of Definition 6 below.

Lemma 5

implies (i) if then ; (ii) if then (iii) if then and .

   $\square$

Definition 6

Let be the function such that whenever all the following conditions hold:

• 1. if then

• 2. if then

• 3. if then

  • (a)

  • (b) if then there exists an such that

  • (c) if then and

where . Let where denotes the greatest fixpoint of . The function is monotone over the complete lattice and thus exists.

   $\square$

The definition of follows a similar structure to that of the resp. definitions that coinductively characterise the must preorder for servers [18, 25]. Definition 6, however, uses predicates for clients, i.e., unsuccessful traces and usability, in place of the predicates for servers, i.e., traces and convergence. Note, in particular, that we use the fully-abstract version of usability, , from Definition 5 and adapt the definition of usable actions accordingly, . Another subtle but crucial difference in Definition 6 is condition (2). The next example elucidates why such a condition is necessary for to be sound.

Counterexample 3

Let be defined as in Definition 6, but without part (2). In this case, we prove that the pair of clients is contained in the greatest fixed point of , and then proceed to show that this pair is not contained in . Let . It follows that if all the conditions for are satisfied: condition (1) in is trivially true, condition (3a) is true because and , condition (3b) holds trivially because , whereas condition (3c) is satisfied because $\tau .\mathop {\textsf {1}}$ does not perform any strong actions. It therefore follows that . Contrarily, because the divergent server $\tau ^{\infty }$ distinguishes between the two clients: whereas $\tau ^{\infty }~{\mathsf {must}}~\mathop {\textsf {1}}$ since the client succeeds immediately, we have because the composition has an infinite unsuccessful computation due to the divergence of $\tau ^{\infty }$.    $\blacksquare$

A more fundamental difference between Definition 6 and the coinductive server preorders in [18, 25] is that, in Definition 6(3c), the relation $\mathrel {R}$ has to relate internal sums of derivative clients on both sides. Although non-standard, this condition is sufficient to compensate for the lack of compositionality of usable clients (see clients $r_1$ and $r_2$ (1) from Sect. 1). Using the standard weaker condition makes the preorder unsound wrt. , as we proceed to show in the next example.

Counterexample 4

Let be defined as in Definition 6, but replacing the condition (3c) with the relaxed condition in (3bad) below, which requires each derivative $r'_2$ to be analysed in isolation. We show that the greatest fixpoint of , , contains client pairs that are not in .

Consider the clients $r_6 = c.r'_6$ and $r_7 = (r_1 \mathrel {+}r_2) \mathrel {+}\tau .\mathop {\textsf {1}}$ where

and $r_1$ and $r_2$ are the clients defined in (1) above. On the one hand, we have that , because whereas . On the other hand, we now show that . Focusing on condition Definition 6(3), we start by deducing that (either directly using Definition 5 or indirectly through , recalling Theorem 2). Now, Definition 6(3a) is true because $\mathop {\textsf {0}}~{\mathsf {must}}~r_7$, thus $r_7$ is usable, and thanks to Theorem 2 we have . Also point (3b) is satisfied, because .² To prove that the (relaxed) condition (3bad) holds, we have to show that

(3bad)

Let . We only show the proof for the inequality , since the proof for the other inequality is analogous. We focus again on conditions (3a), (3b), and (3bad). Condition (3a) is true because , and thus , and because as well (e.g., ). Condition (3b) holds because . Finally for (3bad) we only have to check the case for , which requires us to show that ; this latter check is routine. As a result, we have . Since we can also show that holds, we obtain (7), and consequently .    $\blacksquare$

After our digression on Definition 6, we outline why  coincides with . A detailed proof can be found in the full version of this paper [4].

Lemma 6

Whenever , for every $s \in \mathsf {Act} ^\star$, implies and also that for every , there exists an set such that and that if then .   $\square$

Theorem 5

In any finite branching LTS if and only if .

Proof

We have to show the set inclusions, and . Lemma 5 and Theorem 1 imply that , and thus, by the Knaster-Tarski theorem, we obtain the first inclusion. The second set inclusion follows from Theorem 1 and Lemma 6.    $\square$

Example 5

Recall clients and from Example 4, used to argue that the alternative relation is still a burdensome method for reasoning on . By contrast, We now contend that it is simpler to show by proving , thanks to Theorem 5 and the Knaster-Tarski theorem. By Definition 6, it suffices to provide a witness relation $\mathrel {R}$ such that and . Let where from Example 1, , and . Checking that $\mathrel {R}$ satisfies the conditions in Definition 6 is routine work. To prove condition (3b), though, note that and that . However and thus the required set inclusion holds.   $\blacksquare$

The coinductive preorder of may also be used to prove that two clients are not in the contextual preorder : by iteratively following the conditions of Definition 6 one can determine whether a relation including the pair of clients exists. This approach is useful when guessing a discriminating server is not straightforward; in failing to define a such relation $\mathrel {R}$ one obtains information on how to construct the discriminating server.

Example 6

Recall the clients $r_6$ and $r_7$ considered in Counterexample 4. By virtue of the full-abstraction result, we can show directly that by following the requirements of Definition 6 and arguing that no relation exists that contains the pair $(r_6,r_7)$ while satisfying the conditions of the coinductive preorder. Without loss of generality, pick a relation $\mathrel {R}$ such that $r_6 \mathrel {R}r_7$:we have to show that . Since , and , Definition 6(3c) requires that we show that

(7)

and $r^c_6$, $r'_7$ and $r''_7$ are the clients defined earlier in Counterexample 4. Since we want to show that , the condition Definition 6(3a) requires that, if , then . However, even though , we have , violating Definition 6(3a) and thus showing that no such $\mathrel {R}$ satisfying both $(r_6,r_7)\in {\mathrel {R}}$ and can exist. We highlight the fact that whereas (7) of Counterexample 4 resulted in , (8) is instrumental to conclude that . Note also that the path along c leading to a violation of the requirements of Definition 6 is related to the discriminating server used in Counterexample 4 to justify .    $\blacksquare$

5 Expressiveness and Decidability

We show that servers with finite interactions suffice to preserve the discriminating power of the contextual preorder in Definition 1, which has ramifications on standard verification techniques for the preorder, such as counter-example generation [11]. We also show that, for finite-state LTSs, the set of usable clients is decidable. Using standard techniques [27] we then argue that, in such cases, there exists a procedure to decide whether two finite-state clients are related by .

5.1 On the Power of Finite Interactions

We employ the coinductive characterisation of the client preorder, Theorem 5, to prove an important property of the client preorder of Definition 1, namely that servers that only offer a finite amount of interactions to clients are necessary and sufficient to distinguish all the clients according to our touchstone preorder of Definition 1. Let $\mathsf {CCS}^{ f }::= \mathop {\textsf {0}}\;\;|\;\;\mathop {\textsf {1}}\;\;|\;\;\alpha .p \;\;|\;\;p \mathrel {+}q \;\;|\;\;\tau ^{\infty }$, and

In what follows, we find it convenient to use the definitions above: $\mathsf {CCS}^{ f }$ excludes recursively-defined processes, but explicitly adds the divergent process $\tau ^{\infty }$ because of its discriminating powers (see Counterexample 3). Accordingly, and restrict the resp. sets to the syntactic class $\mathsf {CCS}^{ f }$.

Corollary 1

The sets and coincide.

Proof

The inclusion is immediate. Suppose that . By Theorem 2 we have . By Lemma 1, there exists a non-recursive $p\in \mathsf {CCS}^{ f }$ such that $p~{\mathsf {must}}~r$, thus follows.    $\square$

Theorem 6

In any finite-branching LTS if and only if .

Proof

The inclusion follows immediately from the resp. definitions. On the other hand, Theorem 5 provides us with a proof technique for showing the inclusion : if we show that then . In view of the Knaster-Tarski theorem it suffices to show that . In turn, this requires us to prove the three conditions stated in Definition 6. The argument for the first two conditions is virtually the same to that of Lemma 5. Similarly, the arguments for the third condition follow closely those used in Theorem 1 (albeit in a simpler setting of unsuccessful traces of length 1). The only new reasoning required is that servers that exists because of also belong to $\mathsf {CCS}^{ f }$, which we know from Corollary 1.    $\square$

An analogous result should also hold for the server-preorder, for the proofs of completeness in [6, Theorem 3.1] rely on clients that can be written in the language $\mathsf {CCS}^{ f }$.

5.2 Deciding the Client Preorder

Figure 4 describes the pseudo-code for the eponymous function , which is meant to determine whether a client r is usable. It adheres closely to the conditions of Definition 5 for , using acm as an accumulator to keep track of all the terms that have already been explored. Thus, if an r is revisited, the algorithm rejects it on the basis that a loop of unsuccessful interactions (leading to an infinite sequence of unsuccessful interactions that makes the client unusable) is detected (lines 2–3). If not, the algorithm checks for the conditions in Definition 5 (lines 4–9). In particular, line 4 checks that infinite sequences of internal moves are always successful (using function convtick defined on lines 11–17) and that partially deadlocked clients reached through a finite number of unsuccessful internal moves, , contain at least one action that unblocks them to some other usable client (lines 7–8). This latter check employs the function existsUnblockAction (defined on lines 19–26) which recursively calls isUsable to determine whether the client reached after an action is indeed usable. of Fig. 4 relies on the LTS of r being finite-state in order to guarantee termination via the state accumulation held in acm. This is indeed the case for our expository language $\mathsf {CCS} ^{\mu }$ of Fig. 2. Concretely, we define the set of internal-sums for the derivatives that a client r reaches via all the finite traces $\in \mathsf {Act} ^\star$, and show that this set is finite. Let

Lemma 7

For every $r \in \mathsf {CCS} ^\mu$, the set $\textsf {sumsRdx}( r )$ is finite.    $\square$

Proof

Let denote the set of reachable terms from client r, and denote the elements of the powerset of $\textit{Reach}_r$, expressed as internal summations of the elements of . By definition, we have that . Hence, it suffices to prove that $\textit{Reach}_r$ is finite to show that $\textit{PwrR}_r$ is finite, from which the finiteness of $\textsf {sumsRdx}( r )$ follows. The proof of the finiteness of $\textit{Reach}_r$ is the same as that of Lemma 4.2.11 of [29] for the language serial-CCS, which is homologous to $\mathsf {CCS} ^{\mu }$ of Fig. 2 modulo the satisfaction construct $\mathop {\textsf {1}}$.    $\square$

Fig. 4.

An algorithm for deciding inclusion in the set

Theorem 7

For every $r \in \mathsf {Proc}$ we have that

• (i) iff ,

• (ii) iff .

Proof

For the only-if case of clause (i), we use Theorem 2 and show instead that implies ; we do so by numerical induction on $n\in \mathbb {N}^+$ where . For the if case, we dually show that implies , by numerical induction on the least number $n\in \mathbb {N}^+$ of (recursive) calls to isUsable that yield the outcome $\mathsf{true}$. We note that in either direction of clause (i), there is a direct correspondence between the respective inductive indices (e.g., for the base case $n=1$, implies that $r \Downarrow _{{\, \checkmark }}$ and that ).

For the second clause (ii), the statements implies and implies contradict the first clause (i) which we just proved. The required result thus holds if we ensure that is defined for any $r \in \mathsf {Proc}$. This follows from Lemma 7.    $\square$

From Theorems 5, 7 and Lemma 7, we conclude that Definition 6 can be used to decide for languages such as $\mathsf {CCS} ^{\mu }$ of Fig. 2. We can do this by adapting the algorithm of [27, Chapter 21.5], and proving that in our setting [27, Theorems 21.5.9 and 21.5.12] are true. In particular, using the terminology of [27] we have that is finite, essentially because the resp. LTS is finite-state, and thus the decidability of follows from Theorem 21.5.12.

6 Conclusion

We present a study that revolves around the notion of usability and preorders for clients (tests). Preorders for clients first appeared for compliance testing [2], and were subsequently investigated in [3, 6] for must testing [12] and extended to include peers. The characterisations given in [6] relied fundamentally on the set of usable terms which made them not fully-abstract and hard to automate. This provided the main impetus for our study. In general, recursion poses obstacles when characterising usable terms, but the very nature of ${\mathsf {must}}$ testing — which regards infinite unsuccessful computations as catastrophic — let us treat recursive terms in a finite manner (see Definition 5).

We focus on the client preorder, even though [6] presents preorders for both client and peers; note however that [6, Theorem 3.20] and Theorem 2 imply full-abstraction for the peer preorder as well. Our investigations and the resp. proofs for Theorem 2, Theorems 5 and 6 are conducted in terms of finitely-branching LTSs, which cover the semantics used by numerous other work describing client and server contracts [6, 8, 9, 18] — we only rely on an internal choice construct to economise on our presentation, but this can be replaced by tweaking the resp. definitions so as to work on sets of processes instead. As a consequence, the results obtained should also extend to arbitrary languages enjoying the finite-branching property. Theorem 7 relies on a stronger property, namely that the language is finite-state. In [29], it is shown that this property is also enjoyed by larger $\mathsf {CCS}$ fragments, and we therefore expect our results to extend to these fragments as well.

6.1 Related Work

Client usability depends both on language expressiveness and on the notion of testing employed. Our comparison with the related work is organised accordingly.

Session types [14] do not contain unsuccessful termination, $\mathop {\textsf {0}}$, restrict internal (resp. external) choices to contain only pair-wise distinct outputs (resp. inputs) and are, by definition, strongly convergent [25] (i.e., no infinite sequences of $\tau$- transitions). E.g., $\tau .!a.\mathop {\textsf {1}}\mathrel {+}\tau .!b.?c.\mathop {\textsf {1}}$ corresponds to a session type in our language (modulo syntactic transformations such as those for internal choices), whereas $\tau .!a.\mathop {\textsf {0}}\mathrel {+}\tau .!b.?c.\mathop {\textsf {1}}$, $\tau .!a.\mathop {\textsf {1}}~\mathrel {+}~\tau .!a.?b.\mathop {\textsf {1}}$ and $?a.\mathop {\textsf {1}}~\mathrel {+}~?a.!b.\mathop {\textsf {1}}$ do not. Since they are mostly deterministic — only internal choices on outputs are permitted — usability is relatively easy to characterise. In fact [7, Section 5] shows that every session type is usable wrt. compliance testing (even in the presence of higher-order communication) whereas, in [26, Theorem 4.3], non-usable session types are characterised wrt. fair testing. First-order session types are a subset of our language, and hence, Theorem 2 is enough to (positively) characterise usable session types wrt. ${\mathsf {must}}$ testing; we leave the axiomatisation of in this setting as future work.

Contracts [25] are usually formalised as (mild variants of) our language $\mathsf {CCS} ^{\mu }$. In the case of ${\mathsf {must}}$ testing, the authors in [6, Theorem 6.9, Lemma 7.8(2)] characterise non-usable clients (and peers) for the sublanguage $\mathsf {CCS}^{ f }$ as the terms that can be re-written into $\mathop {\textsf {0}}$ via equational reasoning. Full-abstraction for usable clients wrt. compliance testing has been solved for strongly convergent terms in [25, Proposition 4.3] by giving a coinductive characterisation for viable (i.e., usable wrt. compliance) contracts. If we restrict our language to strongly convergent terms, that characterisation is neither sound nor complete wrt. ${\mathsf {must}}$ testing. It is unsound because clients such as are viable but not usable. It is incomplete because of clients such as $r =\mathop {\textsf {1}}\mathrel {+}\tau .\mathop {\textsf {0}}$; this client is usable wrt. ${\mathsf {must}}$ because, for arbitrary p, any computation of $p \mathrel {||}r$ is successful (since we have immediately). On the other hand, r is not viable wrt. compliance testing of [25] (where every server is strongly convergent), because for any server p we observe the computation starting with the reduction , and once p stabilises to some $p'$, the final state $p' \mathrel {||}\mathop {\textsf {0}}$ contains an unsuccessful client. This argument relies on subtle discrepancies in the definitions of the testing relations: in ${\mathsf {must}}$ testing it suffices for maximal computations to pass through a successful state, whereas in compliance testing the final state of the computation (if any) is required to be successful. This aspect impinges on the technical development: although our Definition 5(2) resembles [25, Definition 4.2], the two definitions have strikingly different meanings: we are forced to reason wrt. unsuccessful actions and unsuccessful acceptance sets whereas [25, Definition 4.2] is defined in terms of (standard) weak actions and acceptance sets (note that Definition 5(1) holds trivially in the strongly convergent setting of [25]). We note also that our Definition 5 is inductive whereas [25, Definition 4.2] is coinductive. More importantly, our work lays bare the non-compositionality of usable terms and how it affects other notions that depend on it, such as Definition 6 (and consequently Theorem 5). We are unaware of any full-abstraction results for contract usability in the case of should-testing [8, 24, 28].

Future work: In the line of [10], we plan to show a logical characterisation of the client and peer preorder. We also intend to investigate coinductive characterisations for the peer preorder of [6] and subsequently implement decision procedures for the server, client, and peer preorders in Caal [1]. Usability is not limited to tests. We expect it to extend naturally to runtime monitoring [13], where it can be used as a means of lowering runtime overhead by not instrumenting unusable monitors.