Speed Up the Conception of Logical Systems with Test-Driven Development

Abstract

In this paper, I stress the utility of employing test-driven development (TDD) for conceiving logical systems. TDD, originally invented in the context of Extreme Programming, is a methodology widely used by software engineers to conceive and develop programs. Its main principle is to design the tests of the expected properties of the system before the development phase. I argue that this methodology is especially convenient in conceiving applied logics. Indeed, this technique is efficient with most decidable logics having a software implementation. Having a clear list of the desired inferences right from the beginning makes it possible to refine the properties of the system step by step until its completion. I distinguish and detail seven advantages of the usage of TDD for the conception of a logical theory. Most importantly, this methodology increases the predictability of the inferential power of the theory. A second important benefit is that the time required for the conception of the logic goes down dramatically. This methodology will change both ideas and practices. Logic is no longer considered to be a formal science, but rather to be an empirical one. Research in the field is geared toward specific and concrete goals. Programs are considered tools used to verify the conformity of formal theories. To sum up, I defend the view that, in some situations, this way of designing a formal system brings significant benefits, and that the construction of new logics can be conducted similarly to the development of open source software.

Appendices

Appendix 1

In this appendix, I present the beginning of the source code of a typical class of test employed during my research. It is based on the Junit library, a framework specialized for testing purpose in a Java environment. I first detail the most important sections before grouping the different elements together. These explanations assume a basic understanding of object-oriented programming techniques.

Let us first look at the declaration of the class. Its name (“SufficientConnectionTransitiveTest”) is chosen to indicate its function. The first chunk of the identifier (“SufficientConnection”) details the type of hypothetical sentence that will be tested. The second part (“Transitive”) specifies that the context is constant, allowing the validity of transitive inferences. Finally, the last segment (“Test”) describes the general purpose of the class. The most important point is that the class must extend the basic class TestCase to benefit from the capabilities of the Junit framework. Indeed, TestCase allows running multiple tests.

public class SufficientConnectionTransitiveTest extends TestCase {

The next part of the code concerns the declaration of the main attribute of the class. Its name is validator, with a lower-case first letter. Its class is Validator (“V” capital letter), a class designed in my software to test the validity of inferences. Finally, the object is created with the constructor Validator(boolean) preceded by the reserved word new. When the boolean is true, we have a constant context (validation of the transitivity) and when the boolean is false, we obtain a changing context (invalidation of the transitivity).

private Validator validator = new Validator(true);

The third interesting part of the code is the way we test a particular inference. To do it, we pass the string representing the reasoning to test to the method validateDeduction of the validator. The result is obtained via the call to the method isResult. Hence, validator.validateDeduction(“$(p \rightarrow q) \wedge p \vdash q$”)).isResult() returns true if the modus ponens is valid, false otherwise. Finally, this call is used as the second argument of the method assertEquals from Junit. Its first argument is the expected result, before the test is passed. Hence, the method assertEquals signals an error if the two booleans are divergent: we obtained a result different from the initial prediction.

assertEquals(true, validator.validateDeduction (“$(p \rightarrow q) \wedge p \vdash q$”)).isResult());

Finally, below are the different elements put together. “...” indicates a missing part of the code, not sufficiently interesting to be reproduced here. Comments are the text between “/**” and “*/” or lines beginning with “//”. Notice that the three first tests are embedded in a method called here “testClassics”. ...

public class SufficientConnectionTransitiveTest extends TestCase {

    /** Object which tests the validity of the inference. */

    private Validator validator = new Validator(true);

/** Test of classical inferences in conditional logic.*/

public void testClassics() throws Exception {

     // Modus Ponens

     assertEquals(true, (validator.

            validateDeduction(“$(p \rightarrow q) \wedge p \vdash q$”)).isResult());

      // Modus Tollens

     assertEquals(true, (validator.

           validateDeduction(“$(p \rightarrow q) \wedge \lnot q \vdash \lnot p$”)).isResult());

      // Affirming the Consequent

     assertEquals(false, (validator.

           validateDeduction(“$(p \rightarrow q) \wedge q \vdash p$”)).isResult());

...

The number of inferences tested can be easily increased, by adding them to the existing method or by grouping them under a different function.

Appendix 2

To execute the test campaign, I use the build manager Maven. The command mvn test launches it by telling to run all the tests defined in the project. Notice that further instructions can be given to Maven, such as to compile the code before the testing. This is useful for instance after a change of the implementation of one connective. Below is the beginning and the end of the outputs produced with this command. As several inferences are grouped in each test, behind the 170 tests are computed around 1,200 inferences.

We see that four tests fall into error. The intermediate console output (not shown here) displays the name of the failed methods with the line where the problems occur. It allows finding quickly the inferences whose results differ from the initial predictions.