Testing subroutines in Rust, Common Lisp, JavaScript, and other programming languages, using either automatic or manual methods

Compile-time type checking is a great way to catch errors early, but it is not a guarantee of correctness. Even simple subroutines can be incorrect. For example, is_old_enough is a subroutine for checking whether a person is at least 21 years old.

fn is_old_enough(a_person: &Person) -> bool {
    a_person.age > 20
}

Here is an example of how the is_old_enough subroutine could be incorrectly implemented:

fn is_old_enough(a_person: &Person) -> bool {
    a_person.age >= 20
}

Adding an equals sign (=) to the code changes the behavior of the subroutine, even though the code is still type-safe. The similar bug is found in Servo, but the type was integer.

Testing the entire program manually or programmatically is essential, but it can be difficult to catch all errors, especially those hidden in the details. Testing subroutines is important because it allows testers to focus on small, well-defined units of code. This makes it easier to identify and fix errors. Here are three prerequisites for testing subroutines:

1. Defining subroutines
2. An input environment for testing
3. Result validation

Defining subroutines

Some programming languages encourage programmers to define subroutines more than others. This is because some languages have features that make it easier and more natural to define and use subroutines.

Defining subroutines in BASIC programming language

In the 1970s, to define a subroutine in BASIC, you would assign it a line number and use the RETURN statement.

1000 PRINT "SUBROUTINE"
1100 RETURN 

We can call a subroutine in a program using the GOSUB command, followed by the line number of the subroutine.

GOSUB 1000 

Defining a subroutine in BASIC is as simple as using the GOTO statement, but with the added convenience of being able to return to the calling code.

Defining subroutines in Common Lisp

In Common Lisp, a function is a subroutine that always returns a value when it is called with a specific set of inputs. This Common Lisp code processes a-person, which is a member of the list people one-by-one using the DOLIST command. If a-person is at least 21 years old, the program will print it out.

(dolist (a-person people)
   (when (> (person-age a-person) 20) 
        (print a-person)))

We can create a new function from the part (> (person-age a-person) 20) by using the DEFUN command, with a function name - old-enough?, and an input variable, which is a-person.

(defun old-enough? (a-person) 
    (> (person-age a-person) 20))

Then, in the main program, we substitute the code part (> (person-age a-person) 20) with a function call (old-enough? a-person).

(dolist (a-person people)
   (when (old-enough? a-person)
        (print a-person)))

Common Lisp encourages programmers to create subroutines by making it easy to copy and paste parts of code, which are also known as expressions, or forms.

Defining subroutines in Java

Here is a Java version of a print-a-person-if-at-least-21 program. Java uses the for loop instead of the Common Lisp DOLIST command.

for (var a_person: people) {
   if (a_person.age > 20) {
      System.out.println(a_person);
   }
}

We can create a function from the expression (a_person.age > 20) using this syntax.

private static boolean isOldEnough(Person a_person) {
    return a_person.age > 20;
}

In addition to Common Lisp, Java requires type annotations for functions. The function is_old_enough was annotated as a function that takes a Person as input and returns a boolean. Moreover, In Java, programmers must decide whether a function belongs to a class or an object by using the static keyword. In Java, programmers also use the private and public keywords to control access to functions. Java functions always require a return statement, similar to BASIC subroutines, except for functions that do not return any value.

Java encourages programmers to create subroutines, but with more annotations, it is not as encouraging as Common Lisp.

Defining subroutines in Crystal: Static typing doesn't mean more annotations.

My explanation of Java, a statically typed programming language, may have led to the misconception that statically typed languages require more annotations. Crystal - another statically typed programming language is the counter example. Here is a Crystal version of a print-a-person-if-at-least-21 program. Instead of the DOLIST command, Crystal uses the EACH command.

people.each {|a_person| puts person if a_person.age > 20}

To create a function, we can copy the expression a_person.age > 20, and paste it into DEF ... END block, without any type annotations or any RETURN statement.

def old_enough?(a_person)
  a_person.age > 20
end

We can substitute the expression a_person.age > 20 with a function call old_enough?(a_person).

people.each {|a_person| puts a_person if old_enough?(a_person)}

So, the ease of defining a function in Crystal is on par with Common Lisp.

Defining subroutines in Rust

Here is a Rust version of a print-a-person-if-at-least-21 program, which look almost identical to Java version.

for a_person in people {
  if a_person.age > 20 {
     println!("{:?}", a_person)
  }
}

Surprisingly, the Rust version of is_old_enough looks similar to the Crystal version, but with type annotations. Type annotation in Rust is more complicated than in Java because Rust has references and programmers need to think about the lifetime of variables. Type annotations and lifetimes could make it more difficult for programmers to write subroutines in Rust.

fn is_old_enough(a_person: &Person) -> bool {
    a_person.age > 20
}

Type annotations make definitions precise and easier to read, but they require more work, can be distracting, and do not help encouraging a programming to create a subroutine.

Preparing an environment for calling a subroutine

Some programming language features and software design can make preparing the environment for calling a subroutine difficult. Moreover, maintaining the code used for preparing the environment could require unnecessary work if the code is too coupled with data structures, which are usually changed.

Preparing an environment in Common Lisp and JavaScript

The variable a-person is an environment for calling the function old-enough?. We create a data structure from a struct in Common Lisp by calling a function make-*. In this example, we call a function make-person.

(make-person :name "A" :age 30)

Moreover, we can make a data structure from a struct using #S syntax, which is in the same form as it is printed.

#S(PERSON :NAME "A" :AGE 30)

This #S syntax is very useful when we have existing data structures, because it allows us to use printed data structures to prepare the environment later. This is especially helpful when we want to build long or complex data structures, such as a list of 1,000 people.

In JavaScript, we can prepare data structures in a similar way to Common Lisp, but without specifying the types of the data.

{"name": "A", "age": 30}

Like Common Lisp, JavaScript can dump data structures to JSON format using the JSON.stringify() command.

It is easy to prepare a data structure as an environment for calling Common Lisp and JavaScript functions, especially because we can reuse the format that a data structure was dumped from memory.

Preparing an environment in Java and Rust

In Java, we create a data structure by instantiating a class using the new keyword. The arguments, which are the input values for creating an object, are sent in a strict order without any keywords, such as :name and :age seen in the Common Lisp example. This style should be fine when the number of arguments does not exceed three.

var a_person = new Person("A", 30);

We can call the function is_old_enough, which in Java is a class method.

is_old_enough(a_person)

Alternatively, we can define the function is_old_enough as an object method, and then call it with this syntax.

a.is_old_enough()

Still, the method for preparing the person data structure remains the same. So class methods are not necessarily easier to test than object methods.

In Rust, we create a data structure with the similar syntax to Rust. However, Rust has a more step, which is converting &str to String using the function to_string.

Person {name: "A".to_string(), age: 30}

Although both Java and Rust cannot use printed format for creating data structure directly. We can use JSON library to dump and load
data.

So, preparing an environment in Java and Rust is not as convenient as Common Lisp or JavaScript, since we cannot copy printed data structure, and directly use it in the program without a help of an additional library.

The difficulty in preparing the environment is caused by the software design.

Sometimes preparing the environment is difficult because of the software design. To create a Person object in this example, we must pass in the person's name and a service that can return their age.

Person(String name, Service service) {
    this.name = name;
    age = service.getAge(name) ;
}

// ...

var a_person = new Person("A", service);

So, we cannot prepare a person data structure with a specific age without creating a service, which is remotely related to test the function is_old_enough.

Using basic data structure

Instead of defining a class or a struct, we can use a list for representing personal data.

'(:name "A" :age 30)

Using a list removes unnecessary restrictions on creating a person, even though our design is primarily to get a person from a service. Here is an example of calling a function to obtain a person data structure from a service.

(get-person "A" service) 

In JavaScript, we can create an object, which is idiomatic for JavaScript, instead of a list.

{"name": "A", "age": 30}

In Java, we use HashMap although creating HashMap in Java does not look as concise as list in Common Lisp.

However, using a list or other basic data structure also has a downside, which will be explained later.

Modifying the data structure affects the code for preparing an environment.

Given, we added reward to the struct person.

struct Person {
  name: String,
  age: u32,
  reward: u32,
}

This code for creating a Person data structure would be broken.

Person {name: "A".to_string(), age: 10}

We have to create a data structure by passing a reward value.

Person {name: "A".to_string(), age: 10, reward: 800} 

It may seem trivial, but I've never enjoyed fixing repetitive code in tests.

Use default values for values we don't care about.

In Rust, we can create a data structure with default values, and then we assigned only a value that we care.

let mut a_person = Person::default(); 
a_person.age = 30 

Before we use the function default, we put #[derive(Default)] before the struct definition.

#[derive(Default)]
struct Person {
    name: String,
    age: u32,
}

In Common Lisp, we can put default values in the struct definition. Then we can call a function make-person by passing a value that we care about.

(defstruct person 
  (name "") 
  (age 0))

(make-person :age 30)

Using basic data structure

We can use a list instead of a specific struct, and in a list, we can put only :age with other values. Still, we can run the test.

(setq a-person '(:age 30)) 
(old-enough? a-person) 

Using basic data structures has some downsides. Lists and hash tables do not perform as well as structs, because accessing struct member is very fast. The position of each struct member in memory is calculated arithmetically. Moreover, when everything is a list, a compiler cannot help checking types since their types are the same. A programmer may have no idea how the data structure looks like by looking a function definition. Still, we alleviate solve these problems by using a runtime schema such as JSON Schema.

Preparing an environment for async function and database connection is not convenient

Some subroutines need a database connection to establish. Some subroutines need an async event loop to run before testing, for example, async functions in Rust. Preparing a fake database and connecting the everything before testing is inconvenient, especially for testing a function like is_old_enough?, which can be fixed by improving the software design. Testing async functions become easier by using a tool, such as Tokio::test.

Testing a subroutine in the production environment

Testing in the production environment is not preferable, but sometimes it is necessary, especially when we cannot reproduce the problem somewhere else.
Common Lisp can run Read-Eval-Print Loop (REPL) along with the production, so we can always test subroutines. Many languages come with an REPL, but we have to make sure that libraries and frameworks play well the REPL. In Common Lisp community, libraries and frameworks are usually REPL-friendly.

Result validation

After running a subroutine, we usually want to validate the result either manually or programatically.

Programatical validation

Most data comparison functions check if the data is the same object in memory, which is not what we want in this case. The code below does not return true even if the content of the data structures is the same because the EQ function does not compare the content.

(eq 
    (get-eldest_person people) 
    (make-person :name "C" :age 120))

When testing, we usually want to compare data structures for content equality. In Common Lisp, we can use the EQUALP function to do this, instead of the EQ function.

(equalp 
    (get-eldest_person people) 
    (make-person :name "C" :age 120))

In Rust, we solve this issue by insert #[derive(PartialEq)] before the struct definition.

#[derive(PartialEq)]
struct Person {
    pub name: String,
    pub age: u32,
}

Manual validation

Manually validating a complex data structure can be difficult, so there are many tools that can display data in a structured view. In Common Lisp, we can use Emacs inspectors like slime-inspect and sly-inspect, or we can use Clouseau, which is part of McCLIM. For other programming languages, I typically convert data structures to JSON and view them in Firefox.