Test Doubles: Replacing real objects for testing

Rellyson Silva — Wed, 18 Aug 2021 17:24:30 +0000

What it is?

Test Doubles are objects that mimic real objects. This give us the possibility to simulate an external dependency to the SUT (System under Test) or any other real element under test. This approach is widely used in unit tests, focused in ensure the unit's assertiveness, ignoring anything outside this scope.

"Test Double is a generic term for any case where you replace a production object for testing purposes." ~Martin Flower.

Gerard Meszaros (creator of Test Doubles) divides this into five categories: Mocks, Stubs, Fakes, Spies e Dummies.

Dummy: is an object passed around but never actually used. Used to fill parameter lists.
Fake: is an object that have working implementations, but are not suitable for production.
Spies: are stubs that record some information based on how they were called. One example of this might be an email service that records how many messages it was sent.
Mocks: predefined implementations with expectations which form a specification of the calls they are expected to receive. They can throw an exception if they receive a call they don't expect and are checked during verification to ensure they got all the calls they were expecting.
Stubs: provide canned answers to calls made during the test, not responding at all to anything outside what's programmed in for the test.

Furthermore, these five categories can be reduced into just two groups: Mocks and Stubs.

Removed from Unit Testing Principles, Practices, and Patterns (Vladimir Khorikov).

Mocks and Stubs

Mocks

Mocks are generally used to simulate outbound interactions. They are used to control and inspect fake calls to a dependency. We can simulate and test if one or more methods were called/not called, the order in which these methods were called, whether those methods were called with the right arguments, and how many times they were called.

Usage

✅ You can use Mocks to:

Test if external dependency methods were called as expected.
Test how many times an external dependency method were called.
Test if an external dependency method was called with the correct arguments.

🚫 Do not use Mocks to:

To test function return values.
To test function behaviors.

Stubs

Stubs are generally used to simulate inbound interactions. Different from Mock, stubs are defined objects, ready to be used. They don't know how to answer how many times an external dependency method was called/not called and which parameters were used, they just return an object already defined. In other words, a stub is the final return of a method.

Usage

✅ You can use Stubs to:

Test the SUT behaviors when receiving different returns from an external dependency.

🚫 Do not use Stubs to:

Test if external dependency methods were called.
Test external dependency methods behaviors.

What about Fakes, Spies and Dummies?

They are complementary to the groups cited, helping the proper creation of Mocks and Stubs.

Fakes

Fakes (also known as Fakers) are real implementations of an external dependency, but are not suitable to production. They are generally used when we need a real functionality (or as close as possible to a real one). The most common example is to use an in-memory database to persist data. Fakers are useful in functional testing or integration testing, but are not recommended for unit testing where we can supply our needs with stubs.

Spies

Spies are objects that record their interactions to other objects (can be compared to a combination of Mock and Stub). They can be used to test both inbound and outbound interactions.

Dummies

Dummies are the simplest piece of an test, used to fill a method signature. Their only purpose is to fill a necessary space, having no effect in the test.

References

Mocks aren't Stubs
Unit Testing Principles, Practices, and Patterns

Abstract class vs interfaces. When to use them?

Rellyson Silva — Wed, 28 Jul 2021 18:56:51 +0000

Abstract class

"When we talk about abstract classes we are defining characteristics of an object type; specifying **what an object is." ~Jorge, 2017.

An abstract class is a "template" for classes, cannot be instantiated and should be extended by a class. It is used to define some common functionality across a set of related classes and allowing default method implementations.

Abstract classes are defined using the keyword abstract. It can have both abstract and regular methods and can only be accessed in classes that inherit it.

public abstract class Animal {
    public abstract void makeSound();
    public void sleep() {
        System.out.println("Zzz");
    }
}

public class Dog extends Animal {
    public void makeSound() {
        System.out.println("Uff uff!");
    }
}

public class Main {
    public static void main(String[] args) {
        Dog snoopy = new Dog();
        snoopy.makeSound();
        snoopy.sleep();
    }
}

When to use abstract classes?

When you need to implement code

Different from interfaces, abstract class can have method implementations. This helps having code re-usability and to ensure that a class contains its expected behaviors, by extending an existing method or implementing an abstract method already defined in the abstract class.

When you need encapsulation

Different from interfaces, abstract classes allow us to have encapsulated methods and attributes. It helps restricting direct access to the object's component and preventing unauthorized access to them.

Interface

"When we talk about an interface and define capabilities that we promise to provide, we are talking about establishing a contract about **what the object can do." ~Jorge, 2017.

An interface is a "contract" and should be implemented by a class*.* When a class implements **an interface, it must follow the behavior published by the interface. Interfaces generally defines properties and methods a class must have and unlike abstract class, **enable multiple inheritance.

Interfaces are defined using the keyword interface. In languages like C# and Java, there is a standard convention to prefix all interfaces with an I, so a file handler interface will be IFileHandler.

public interface IWallet {
    public void withdraw();
    public void deposit();
    double getBalance();
}

public class Wallet implements IWallet {
    public void withdraw(){
        //do something
    }

    public void deposit() {
        //do something
    }

    double getBalance(){
        //do something
    }

}

When to use interfaces?

When you need a class to have expected behaviors

It means that by implementing an interface, the class agrees to implement all of the functionality specified by the interface, ensuring that the expected behaviors are fulfilled.

When you need multiple inheritance

Different from abstract classes, interfaces enables multiple inheritance in classes. It allow us to write assertive interfaces for a specific need. For example, we have an interface for a specific class and it can be reused in another class that combines two or more interfaces to achieve it's behavior.

When you need to provide common functionality to unrelated classes

Interfaces allow us to ensure functionality to classes in different contexts but with similar behavior.

References

Abstract classes and interfaces - Developer Fields

Java OOP

DEV Community: Rellyson Silva

Test Doubles: Replacing real objects for testing

What it is?

Mocks and Stubs

Mocks

Usage

Stubs

Usage

What about Fakes, Spies and Dummies?

Fakes

Spies

Dummies

References

Abstract class vs interfaces. When to use them?

Abstract class

When to use abstract classes?

When you need to implement code

When you need encapsulation

Interface

When to use interfaces?

When you need a class to have expected behaviors

When you need multiple inheritance

When you need to provide common functionality to unrelated classes

References