# Pattern-Based Test Suite Reduction Method for Smart Contracts
## 6 Discussion and Limitations  
The test set reduction method proposed in the article ensures obtaining the minimum number of test cases verifying the operation of the smart contract. In other words, we obtain the optimal solution without the need to apply optimization algorithms. Optimization techniques may be time-consuming and yield sub-optimal results. The testing method is based on knowledge of the structure of the smart contract and, in particular, the mechanism for processing logical conditions imposed on the possibility of executing a transaction. Therefore, the use of design patterns in the construction of a smart contract has a positive impact on its implementation and results in measurable savings at the testing level. The reduction in the number of test cases already goes into the thousands starting from ten verification rules in a smart contract. The conducted tests showed that the execution times of the test suite for a smart contract are below 0.01 [ms]. Two factors influence the results obtained. Firstly, a smart contract design pattern ensures the linear complexity of verification rule processing. The second is the proposed \(k+1\) testing method enabling the construction of the minimal test suite. Moreover, not only test suite execution time benefits  
Figure 10: Percentage reduction in the number of test transactions for \(T_{k}^{set}\). Figure 9: Test suite execution time for \(T_{k}^{suite}\in\langle 2;9\rangle\). from the fact of lowered number of test cases. A low and manageable number of test cases affirmatively affects the preparation time of test cases. Preparing a huge number of test cases is prone to errors and maintenance would be even more challenging. The JUnit package is often used to test software at the unit testing level. However, the ability to employ this tool was limited due to the level of timing accuracy. JUnit assures 1 [ms] accuracy of measurement of the execution time of a single test. Such a level of accuracy for the tests performed in this research was not sufficient. The Java test classes _TestManager_ and _TestRunner_ constructed in this work allow acquiring the smart contract evaluation time with an accuracy of 1 [ns]. Moreover, JUnit requires defining separate methods to construct tests, and each may need a separate transaction object. It may lead to a growth in the number of testing methods and the number of transaction objects. As a result, the effort to maintain the test suite also rises. Test transaction objects are independent of each other and cannot be reused. Due to that fact, the redundancy of transaction objects increases as the test suite enlarges. In the event of a change in the functionality of the smart contract, the effort to update the test suite is significant. Unlike this standard package, the classes designed for smart contract testing exploit two dynamic elements. The first is the verification rule list in the smart contract. This dynamic structure determines the composition and order of the rules in the evaluation expression. Verification rules are stored using the _Predicate\(<>\)_ type. The adopted data structure design eliminates the need to create classes for verification rules. These rules are created dynamically. It also ensures deferred execution of verification rules using lambda expressions. The second is the list of unique transaction objects reused among all test suites in the smart contract testing. The method is dedicated to a specific design pattern. On the one hand, this is its advantage, but at the same time, it also has limitations. The method in its specific form cannot be directly applied to a wide group of smart contracts without knowing the mechanism of their construction so it is not suitable for black-box testing. However, the use of the method leads to significant savings in the number of test cases and the number of test data. This results in short execution times of test suites for the smart contract. That feature is of utmost importance for regression testing and is applied especially in continuous software delivery.