# Pattern-Based Test Suite Reduction Method for Smart Contracts
## 3 Test Suite Reduction Method  
The method is adapted to a specific design of a smart contract. The main function of a smart contract is to check whether a set of conditions are met to enable the implementation of an operation/transaction. Even if the individual rules are very complex, all of them that have been imposed on the smart contract must be met for the operation/transaction to be performed. Therefore, the logical product of conditions is a natural form of a mechanism verifying the possibility of executing a smart contract. This mechanism was used to construct the smart contract design pattern. The current version of the pattern, covering lambda expressions from functional programming, was published in [8]. The source code of the pattern was published as an original software publication [45]. The testing method assumes the construction of a smart contract according to the design pattern to reduce the test suite. The test suite reduction method uses certain definitions from smart contract design. A verification rule means a single logical condition checked by a smart contract. Furthermore, an evaluation expression denotes a logical statement encompassing verification rules with logical operators. An evaluation expression returns a logical value. The value of the evaluation expression for a smart contract \(v^{sc}\) is expressed as the logical product of the logical values of all verification rules in that smart contract. The value of \(v^{sc}\) can be calculated by the following Equation (1):  
\[v^{sc}=\prod_{i=1}^{k}v_{i} \tag{1}\]  
where \(k\) is the number of verification rules, and \(v_{i}\) is the result of evaluating the \(i\)-th verification rule. A smart contract is verified positively only if all the verification rules included in that contract return the boolean TRUE value. So, only one test case returns the TRUE logical value from smart contract evaluation. A single verification rule can cause the evaluation expression to return a FALSE boolean value. In order to check the single rule, all other verification rules should return a TRUE boolean value. Having that in mind, we can state that the number of test cases required to test the operation of the smart contract is greater by one than the number of verification rules. In the proposed method (PM), the number of test cases \(T^{PM}\) can be calculated by the Formula (2). \[T^{PM}=k+1 \tag{2}\]  
It is important to emphasize that only a few test cases are required to test a smart contract. For full coverage (FC), the number of test cases \(T^{FC}\) can be calculated using variations with repetitions by the following Formula (3). \[T^{FC}=\bar{V}_{n}^{k}=n^{k} \tag{3}\]  
where \(n\) is the number of elements in the set N = \(\{0,1\}\). Figure 1 presents the comparison of the number of test cases for the \(k+1\) pattern with the number for full coverage. A logarithmic scale was used to visualize the difference in the number of required test cases. The method described by Formula (2) will be presented on the example of a smart contract with eight verification rules (Table 1). In the table, integer value 0 means boolean  
Figure 1: Dependence of the number of test cases on the number of verification rules in a smart contract. FALSE, and 1 stands for boolean TRUE. A bold single value of 0 indicates a rule in the test case that causes the transaction to validate negatively (FALSE). The set of all bold values 1 in the test case positively verifies the transaction (TRUE). This applies to both Tables 1 and 2. Let us look at the example of an evaluation expression with eight verification rules. Then, we have the following variable values: \(n=2\) and \(k=8\). As a result, the number of test cases is \(T^{FC}=2^{8}=256\). Table 2 comprises test cases for a smart contract with eight verification rules (\(k=8\)) for full coverage.