test double

Test double is a term coined by xUnit author Gerard Meszaros.

스턴트 더블(스턴트 대역 배우를 지칭하는 용어)

It is said that the idea was taken from . This is a Test object used when access to the actual DOC is difficult and unusable. Using test doubles, you can isolate the code under test and improve testing speed. And it can simulate special situations.

Dummy

This refers to an object that is not actually used but is used to fill the parameter list. The object is only passed as a derived object of the base class or interface, excluding its implementation, and is not used. Looking at the code below,

DummyObject

Although there is nothing

@Test

You can see that it is an object that exists to fill parameters and has only a name.

public class DummyObject {}
public class DummyObjectTest {
@Test
public void testDummyObject() {
DummyObject dummy = new DummyObject();
// 테스트할 로직 작성
}
}

Stub

Dummy refers to an object that is made to look like it actually operates. It is used to isolate the caller from the actual implementation. Provides canned results for requests invoked in tests.

public interface DatabaseService {
String getData();
}
public class DatabaseServiceStub implements DatabaseService {
@Override
public String getData() {
return "Stubbed data";
}
}
public class MyClassTest {
@Test
public void testMethodWithStub() {
DatabaseService databaseStub = new DatabaseServiceStub();
MyClass myClass = new MyClass(databaseStub);
// Call the method that uses the stubbed database service
String result = myClass.processData();
// Assert the result
assertEquals("Stubbed data", result);
}
}

###Fake

in-memory test database

A representative example is an object that does not actually operate but is hard-coded to return a specified result value. Therefore, although it has an implementation, it only looks like an object that is actually used, and the behavior of the actual object is different.

public interface EmailService {
void sendEmail(String to, String message);
}
public class FakeEmailService implements EmailService {
private List<String> sentEmails = new ArrayList<>();
@Override
public void sendEmail(String to, String message) {
// 이메일을 실제로 보내지 않고, 리스트에 추가한다.
sentEmails.add(to + ": " + message);
}
public List<String> getSentEmails() {
return sentEmails;
}
}
public class FakeEmailServiceTest {
@Test
public void testFakeEmailService() {
FakeEmailService fakeEmailService = new FakeEmailService();
// 테스트할 로직 작성
}
}

Spy

It is used when a situation arises in a test where it is necessary to check whether a specific object was used and whether the expected method of that object was called properly.

public class SpyList extends ArrayList<String> {
private boolean addMethodCalled = false;
@Override
public boolean add(String element) {
addMethodCalled = true;
return super.add(element);
}
public boolean isAddMethodCalled() {
return addMethodCalled;
}
}
public class SpyListTest {
@Test
public void testSpyList() {
SpyList spyList = new SpyList();
// 테스트할 로직 작성
}
}

Mock

It refers to an object that is programmed to give a certain result when a certain action is performed.

MockPaymentGateway

is an object used in an actual program, and because the object is imported and tested, you can check whether the actual process has been implemented and operates well.

public interface PaymentGateway {
boolean processPayment(double amount);
}
public class MockPaymentGateway implements PaymentGateway {
private boolean processPaymentCalled = false;
@Override
public boolean processPayment(double amount) {
processPaymentCalled = true;
// 실제 결제 프로세스를 모킹하여 테스트에 사용한다.
return true;
}
public boolean isProcessPaymentCalled() {
return processPaymentCalled;
}
}
public class MockPaymentGatewayTest {
@Test
public void testMockPaymentGateway() {
MockPaymentGateway mockPaymentGateway = new MockPaymentGateway();
// 테스트할 로직 작성
}
}

So when should you use which test double? The test double that should be used is different depending on the usage. In the case of Mockist TDD, it is appropriate to use only Mock, and in the case of Classicist TDD, it is appropriate to use Fake, Stub, and Spy, and in some cases, Mock can also be used. Please refer to the article written below for Mockist and Classicist.

TestDouble - Martin Flower Learn about Test Double TDD: Test Doubles in Unit Testing. Should we use Fakes? Stubs? Mocks?