✨ 테스트 범위와 종류

테스트 범위

• 단위 테스트
• 통합 테스트
• 기능 테스트

기능 테스트와 E2E 테스트

• 기능 테스트는 사용자 입장에서 시스템이 제공하는 기능이 올바르게 동작하는지 확인합니다.
• 기능 테스트는 E2E(End-to-End) 테스트로 볼 수 있습니다.
• 주로 QA 조직에서 기능 테스트를 수행합니다.

통합 테스트

• 시스템의 각 구성 요소가 올바르게 연동되었는지 확인합니다.
• 소프트웨어 코드를 직접 테스트합니다.
• 예를 들어, 스프링 프레임워크, JPA, MariaDB를 이용하여 회원 가입 관련 서비스 클래스, DAO 인터페이스, SQL 쿼리를 구현한 경우, 이들을 통합한 회원 가입 서비스 클래스에 대한 테스트가 통합 테스트의 예가 될 수 있습니다.

단위 테스트

• 개별 코드나 컴포넌트가 기대한 대로 동작하는지 확인합니다.
• 주로 한 클래스나 한 메서드와 같은 작은 범위를 테스트합니다.

테스트 범위 간의 차이

• 통합 테스트를 실행하려면 DB나 캐시 서버와 같은 연동 대상을 구성해야 합니다.
• 기능 테스트를 실행하려면 웹 서버를 구동하거나 모바일 앱을 설치해야 합니다.
• 통합 테스트는 DB 연동, 소켓 통신, 스프링 컨테이너 초기화 등으로 인해 테스트 실행 속도가 느려질 수 있습니다.
• 통합 테스트나 기능 테스트는 외부 상황에 의해 준비나 테스트가 어려울 수 있습니다.
  통합 테스트는 많은 준비가 필요하지만, 필수적입니다. 단위 테스트를 아무리 많이 작성해도 각 구성 요소가 올바르게 연동되는지는 반드시 확인해야 합니다.

테스트 범위에 따른 테스트 코드 개수와 시간

테스트를 자동화할수록 고품질 소프트웨어를 더 빠르게 출시할 수 있습니다.
테스트 속도는 통합 테스트보다 단위 테스트가 빠르므로, 가능한 한 단위 테스트로 다양한 상황을 다루고, 통합 테스트나 기능 테스트는 주요 상황에 초점을 맞추는 것이 좋습니다.

외부 연동이 필요한 테스트

WireMock

• 서버 API를 스텁으로 대체할 수 있습니다.
• JSON/XML 응답, HTTPS 지원, 단독 실행 등 다양한 기능을 제공합니다.

코드 복사
public class CardNumberValidatorTest {

    private WireMockServer wireMockServer;

    @BeforeEach
    void setUp() {
        wireMockServer = new WireMockServer(options().port(8089));
        wireMockServer.start();
    }

    @AfterEach
    void tearDown() {
        wireMockServer.stop();
    }

    @Test
    void valid() {
        wireMockServer.stubFor(post(urlEqualTo("/card"))
                .withRequestBody(equalTo("1234567890"))
                .willReturn(aResponse()
                        .withHeader("Content-Type", "text/plain")
                        .withBody("ok"))
        );

        CardNumberValidator validator =
                new CardNumberValidator("http://localhost:8089");
        CardValidity validity = validator.validate("1234567890");
        assertEquals(CardValidity.VALID, validity);
    }

    @Test
    void timeout() {
        wireMockServer.stubFor(post(urlEqualTo("/card"))
                .willReturn(aResponse()
                        .withFixedDelay(5000))
        );

        CardNumberValidator validator =
                new CardNumberValidator("http://localhost:8089");
        CardValidity validity = validator.validate("1234567890");
        assertEquals(CardValidity.TIMEOUT, validity);
    }
}

스프링 부트의 내장 서버를 이용한 API 기능 테스트

• 스프링 부트를 사용하면 내장 톰캣을 이용해 API에 대한 테스트를 JUnit 코드로 작성할 수 있습니다.

코드 복사
@SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT)
public class UserApiE2ETest {
    @Autowired
    private TestRestTemplate restTemplate;

    @Test
    void weakPwResponse() {
        String reqBody = "{\"id\": \"id\", \"pw\": \"123\", \"email\": \"a@a.com\" }";
        RequestEntity<String> request =
                RequestEntity.post(URI.create("/users"))
                        .contentType(MediaType.APPLICATION_JSON_UTF8)
                        .body(reqBody);

        ResponseEntity<String> response = restTemplate.exchange(
                request,
                String.class);

        assertEquals(HttpStatus.BAD_REQUEST, response.getStatusCode());
        assertTrue(response.getBody().contains("WeakPasswordException"));
    }
}

`

✨ 테스트 코드와 유지보수

테스트 주도 개발을 통해 작성된 테스트 코드는 CI/CD 파이프라인에서 자동화 테스트로 사용됩니다. 이를 통해 배포 전에 버그를 발견하고 방지하여 소프트웨어 품질이 저하되는 것을 막을 수 있습니다. 그러나 테스트 코드도 제품 코드와 마찬가지로 지속적인 유지보수가 필요합니다. 테스트 코드를 방치하면 여러 문제가 발생할 수 있습니다.

테스트 코드 방치의 문제점

회귀 테스트의 신뢰도 저하

코드를 변경할 때 기존 기능이 올바르게 동작하는지 확인하는 회귀 테스트를 자동화합니다. 하지만 깨진 테스트를 방치하면 회귀 테스트의 검증 범위가 줄어들어 새로운 변경 사항이 기존 기능에 미치는 영향을 정확히 파악하기 어려워집니다.

테스트 통과를 위한 불필요한 노력 증가

깨진 테스트가 많아지면, 이러한 테스트를 통과시키기 위해 많은 노력이 필요해집니다. 이는 TDD의 본래 목적에서 벗어날 수 있습니다.

이러한 악순환을 방지하려면 테스트 코드의 유지보수성이 높아야 합니다.

깨진 유리창 이론

"깨진 유리창 이론"은 사소한 무질서를 방치하면 더 큰 문제로 이어질 가능성이 높아진다는 이론입니다. 이는 테스트 코드에도 적용됩니다. 테스트 코드를 방치하기 시작하면 실패하는 테스트가 점점 많아져, 결국에는 테스트를 유지보수할 수 없을 정도로 악화될 수 있습니다.

테스트 코드의 유지보수를 위한 방법

변수나 필드를 사용해 기댓값을 표현하지 않기

@Test
void dateFormat() {
	LocalDate date = LocalDate.of(1945,8,15);
	String dataStr = formatDate(date);
	assertEquals(date.getYear()+"년 "+
			date.getMonthValue()+"월 "+
			date.getDayOfMonth()+"일 ", dateStr);
}

테스트 코드에서 객체를 생성할 때 사용한 값을 확인하기 위해 필드나 변수를 참조하지 않도록 해야 합니다.

@Test
void dateFormat() {
	LocalDate date = LocalDate.of(1945,8,15);
	String dataStr = formatDate(date);
	assertEquals("1945년 8월 15일", dateStr);
}

이렇게 하면 테스트 코드가 더 명확해지고 유지보수하기 쉬워집니다.

private List<Integer> answers = Arrays.asList(1,2,3,4);
private Long respondentId = 100L;

@DisplayName("답변에 성공하면 결과 저장함")
@Test
public void saveAnswerSuccessfully() {
	// 답변할 설문이 존재
	Survey survey = SurveyFactory.createApprovedSurvey(1);
	surveyRepository.save(survey);

	// 설문 답변
	SurveyAnswerRequest surveyAnswer = SurveyAnswerRequest.builder()
		.surveyId(survey.getId())
		.respondentId(respondentId)
		.answers(answers)
		.build();

	svc.answerSurvey(surveyAnswer);

	// 저장 결과 확인
	SurveyAnswer savedAnswer =
		memoryRepository.findBySurveyAndRespondent(
			survey.getId(), respondentId);
	assertAll(
		()->assertEquals(respondentId, savedAnswer.getRespondentId()),
		()->assertEquals(answer.size(), savedAnswer.getAnswers().size()),
		()->assertEquals(answer.get(0), savedAnswer.getAnswers().get(0)),
		()->assertEquals(answer.get(1), savedAnswer.getAnswers().get(1)),
		()->assertEquals(answer.get(2), savedAnswer.getAnswers().get(2)),
		()->assertEquals(answer.get(3), savedAnswer.getAnswers().get(3))
		);
}

단언과 객체 생성에 필드와 변수를 사용할경우, 필드의 값을 검증하는 과정에서 실패하면 해당 필드를 확인해야 한다.
또는 테스트 코드를 처음 보는 사람은 변수와 필드를 오가며 테스트 코드를 이해해야 한다.

@DisplayName("답변에 성공하면 결과 저장함")
@Test
public void saveAnswerSuccessfully() {
	// 답변할 설문이 존재
	Survey survey = SurveyFactory.createApprovedSurvey(1);
	surveyRepository.save(survey);

	// 설문 답변
	SurveyAnswerRequest surveyAnswer = SurveyAnswerRequest.builder()
		.surveyId(1L)
		.respondentId(100L)
		.answers(Arrays.asList(1,2,3,4))
		.build();

	svc.answerSurvey(surveyAnswer);

	// 저장 결과 확인
	SurveyAnswer savedAnswer =
		memoryRepository.findBySurveyAndRespondent(
			survey.getId(), respondentId);
	assertAll(
		()->assertEquals(100L, savedAnswer.getRespondentId()),
		()->assertEquals(4, savedAnswer.getAnswers().size()),
		()->assertEquals(1, savedAnswer.getAnswers().get(0)),
		()->assertEquals(2, savedAnswer.getAnswers().get(1)),
		()->assertEquals(3, savedAnswer.getAnswers().get(2)),
		()->assertEquals(4, savedAnswer.getAnswers().get(3))
		);
}

객체 생성과 단언에서 변수 대신 값을 사용하면 코드 가독성이 좋아져서 테스트 코드를 쉽게 파악할 수 있다.

한 테스트에서 두 가지 이상의 사항을 검증하지 않기

@DisplayName("같은 ID가 없으면 가입에 성공하고 메일을 전송함")
@Test
void registerAndSendEmail() {
	userRegister.register("id", "pw", "email");
	
	// 검증1 : 회원 데이터가 올바르게 저장되었는지 검증
	User savedUser = userRepository.findById("id");
	assertEquals("id", savedUser.getId());
	assertEquals("email", savedUser.getEmail());

	// 검증2 : 이메일 발송을 요청했는지 검증
	ArgumentCaptor<String> captor = ArgumentCaptor.forClass(String.class);
	BDDMockito.then(mockEmailNotifier)
		.should().sendRegisterEmail(captor.capture());

	String realEmail = captor.getValue();
	assertEquals("email@email.com", realEmail);
}

한 테스트 메서드에서 서로 다른 내용을 검증하는 것은 지양해야 합니다. 예를 들어, 회원 데이터 저장 여부와 이메일 발송 요청 여부를 동시에 검증하는 대신, 각각의 내용을 별도의 테스트로 분리해 집중도를 높여야 합니다.

@DisplayName("같은 ID가 없으면 가입 성공함")
@Test
void noDupId_RegisterSuccess() {
	userRegister.register("id", "pw", "email");
	
	User savedUser = fakeRepository.findById("id");
	assertEquals("id", savedUser.getId());
	assertEquals("email", savedUser.getEmail());
}

@DisplayName("가입하면 메일을 전송함")
@Test
void whenRegisterThenSendMail() {
	userRegister.register("id", "pw", "email@email.com");

	ArgumentCaptor<String> captor = ArgumentCaptor.forClass(String.class);
	then(mockEmailNotifier).should().sendRegisterEmail(captor.capture());

	String realEmail = captor.getValue();
	assertEquals("email@email.com", realEmail);
}

정확하게 일치하는 값으로 모의 객체 설정하지 않기

@DisplayName("약한 암호면 가입 실패")
@Test
void weakPassword() {
	BDDMockito.given(mockPasswordChecker.checkPasswordWeak("pw"))
		.willReturn(true);

	assertThrows(WeakPasswordException.class, ()->{
		userRegister.register("id", "pw", "email");
	});
}

정확히 일치하는 상황을 정의한 모의(Mock) 객체는 작은 변화에도 테스트가 실패할 수 있습니다.
약한 암호 테스트는 UserRegister 가 원하는 대로 동작하는 지 확인하기 위한 코드입니다.
이럴 경우 임의의 값에 일치하도록 모의 객체를 설정하는 것이 좋습니다. 예를 들어, Mockito.anyString()을 사용해 임의의 문자열과 일치하도록 설정합니다.

@DisplayName("약한 암호면 가입 실패")
@Test
void weakPassword() {
	BDDMockito.given(mockPasswordChecker.checkPasswordWeak(Mockito.anyString()))
		.willReturn(true);

	assertThrows(WeakPasswordException.class, ()->{
		userRegister.register("id", "pw", "email");
	});
}

모의 객체를 호출했는지 여부를 확인하는 경우도 동일합니다.

@DisplayName("회원 가입시 암호 검사 수행됨")
@Test
void checkPassword() {
	userRegister.register("id", "pw", "email");

	BDDMockito.then(mockPasswordChecker)
		.should()
		.checkPasswordWeak("pw");
}

과도하게 내부 구현을 검증하지 않기

@DisplayName("회원 가입시 암호 검사 수행됨")
@Test
void checkPassword() {
	userRegister.register("id", "pw", "email");
	
	// PasswordChecker#checkPasswordWeak() 메서드 호출 여부 검사
	BDDMockito.then(mockPasswordChecker)
		.should()
		.checkPasswordWeak(Mockito.anyString());

	// UserRepository#findById() 메서드를 호출하지 않는 것을 검사
	BDDMockito.then(mockRepository)
		.should(Mockito.never())
		.findById(Mockito.anyString());
}

내부 구현을 검증하는 것은 좋은 방법이 아닙니다. 내부 구현은 언제든지 바뀔 수 있으므로, 실행 결과를 검증하는 데 집중해야 합니다.

예제 코드의 경우 register() 메서드가 PasswordChecker#checkPasswordWeak() 메서드를 호출하는지 검증하는 것보다 약한 암호일 때 register의 결과가 올바른지 검증해야합니다.

이미 존재하는 코드에 단위 테스트를 추가하면 어쩔 수 없이 내부 구현을 검증해야 할 때도 있습니다. 예를 들어 레거시 코드에 changeEmail() 메서드는 이메일을 변경하는 기능을 구현하고 있습니다.

public void changeEmail(String id, String email) {
	int cnt = userDao.countById(id);
	if(cnt == 0) {
		throw new NoUserException();
	}
	userDao.updateEmail(id, email);
}

레거시 코드에서 DAO는 다양한 update, select 등의 메서드를 정의하고 있는 경우가 많습니다.
따라서 메모리를 이용한 가짜 구현으로 대체하기가 쉽지 않습니다. 이런 경우 모의 객체를 많이 활용합니다.

@Test
void changeEmailSuccessfully() {
	given(mockDao.countById(Mockito.anyString())).willReturn();

	emailService.changeEmail("id", "new@somehost.com");

	then(mockDao).should()
		.updateEmail(Mockito.anyString(), Mockito.matches("new@somehost.com");
}

이 코드는 이메일을 수정했는지 확인하기 위해 updateEmail() 메서드 호출 여부를 확인합니다.

기능이 정상적으로 동작하는지 확인할 수단이 구현 검증밖에 없다면 모의 객체를 사용해서 테스트 코드를 작성해야 하지만 일단 테스트 코드를 작성한 뒤에는 점진적으로 코드를 리팩토링해서 구현이 아닌 결과를 검증할 수 있도록 시도해야 합니다.

셋업을 이용해 중복된 상황을 설정하지 않기

@BeforeEach
void setUp() {
	changeService = new ChangeUserService(memoryRepository);
	memoryRepository.save(
		new User("id", "name", "pw", new Address("서울", "북부")
	);
}

@Test
void noUser() {
	assertThrows(
		UserNotFoundException.class,
		()-> changeService.ChangeAddress("id2", new Address("서울", "남부"))
	);
}

@Test
void changeAddress() {
	changeService.changeAddress("id", new Address("서울", "남부"));

	User user = memoryRepository.findById("id");
	assertEquals("서울", user.getAddress().getCity());
}

@Test
void changePw() {
	changeService.changePw("id", "pw", "newpw");

	User user = memoryRepository.findById("id");
	assertTrue(user.matchPassword("newpw"));
}

@Test
void pwNotMatch() {
	assertThrows(
		IdPwNotMatchException.class,
		()->changeService.changePw("id", "pw2", "newpw")
	);
}

중복된 코드를 제거하기 위해 @BeforeEach 같은 메서드를 이용할 수 있지만, 이는 테스트를 깨지기 쉬운 구조로 만들 수 있습니다. 테스트 메서드는 독립적인 프로그램으로서, 상황 구성 코드가 메서드 내에 있어야 자체적으로 충분히 설명될 수 있습니다.

@BeforeEach
void setUp() {
	changeService = new ChangeUserService(memoryRepository);
	memoryRepository.save(
		new User("id", "name", "pw2", new Address("서울", "북부")
	);
}

통합 테스트에서 데이터 공유 주의하기

@SpringBootTest
@Sql("classpath:init-data.sql")
public class UserRegisterIntTestUsingSql {
	@Autowired
	private UserRegister register;
	@Autowired
	private JdbcTemplate jdbcTemplate;

	@Test
	void 동일ID가_이미_존재하면_익셉션() {
		// 실행 결과 확인
		assertThrows(DupIdException.class,
			()->register.register("cbk", "strongpw", "email@email.com")
		);
	}

	@Test
	void 존재하지_않으면_저장함() {
		// 실행
		register.register("cbk2", "strongpw", "email@email.com");
		// ...
	}
}

셋업을 이용한 상황 설정과 비슷한 것으로 통합 테스트의 DB 데이터 초기화가 있습니다.
DB 연동을 포함한 통합 테스트를 실행하려면 DB 데이터를 알맞게 구성해야 합니다.
스프링 프레임워크에서는 @Sql 애노테이션을 사용하여 테스트를 실행하기 전 특정 쿼리를 실행할 수 있습니다.

@Sql 애노테이션으로 지정한 sql 파일은 다음과 같이 테스트에 필요한 데이터를 초기화합니다.

truncate table user;
insert into user values ('cbk', 'pw', 'cbk@cbk.com');
insert into user values ('tddhit', 'pw1', 'tddhit@ilovetdd.com')

이 쿼리는 여러 테스트가 동일한 데이터를 사용할 수 있게 만들어주어서 통합 테스트 메서드는 데이터 초기화를 위한 코드를 작성하지 않아도 됩니다. 이 방식은 편리하지만 셋업 메서드와 마찬가지로 쿼리 파일을 조금만 변경해도 테스트가 깨질 수 있고 결국 유지보수를 어렵게 만듭니다.

통합 테스트 코드를 만들 때는 다음 두 가지로 초기화 데이터를 나눠서 생각해야 합니다.

• 모든 테스트가 같은 값을 사용하는 데이터 : 예) 코드값 데이터
• 테스트 메서드에서만 필요한 데이터 : 예) 중복 ID 검사를 위한 회원 데이터

코드값 데이터는 거의 바뀌지 않기 때문에 모든 테스트가 동일한 코드값 데이터를 사용해도 문제가 없습니다.

반면에 특정 테스트 메서드에만 의미 있는 데이터는 모든 테스트가 공유할 필요가 없습니다.
이런 데이터는 특정 테스트에서만 생성해서 테스트 코드가 완전히 하나가 되도록 해야 합니다.

@Test
void dupId() {
	// 상황
	jdbcTemplate.update(
		"insert into user values(?,?,?) "+
		"on duplicate key update password = ?, email = ?",
		"cbk", "pw", "cbk@cbk.com", "pw", "cbk@cbk.com");

	// 실행 결과 확인
	assertThrows(DupIdException.class,
		()->register.register("cbk", "strongpw", "email@email.com")
	);
}

통합 테스트에서 초기화 데이터를 나눌 때, 모든 테스트가 같은 값을 사용하는 데이터와 테스트 메서드에서만 필요한 데이터를 구분해야 합니다.

통합 테스트의 상황 설정을 위한 보조 클래스 사용

통합 테스트에서 데이터 공유 주의하기 처럼 중복 ID를 가진 회원이 존재하는 상황을 만들기 위해 필요한 회원 데이터를 생성했습니다. 비슷하게 이메일 수정 기능을 테스트할 때에도 유사한 쿼리르 실행해야 합니다. 각 테스트 메서드에서 상황을 직접 구성함으로써 테스트 메서드를 분석하기는 좋지만 반대로 상황을 만들기 위한 코드가 여러 테스트 코드에 중복됩니다.
테이블 이름이나 칼럼 이름이 바뀌면 여러 테스트 메서드를 수정해야 하므로 유지보수에 좋지 않습니다.

테스트 메서드에서 직접 상황을 구성하면서 코드 중복을 없애는 방법이 있는데, 상황 설정을 위한 보조 클래스를 사용하는 것입니다.

public class UserGivenHelper {
	private JdbcTemplate jdbcTemplate;

	public UserGivenHelper(JdbcTemplate jdbcTemplate) {
		this.jdbcTemplate = jdbcTemplate;
	}

	public void givenUser(String id, String pw, String email) {
		jdbcTemplate.update(
			"insert into user values (?,?,?) "+
			"on duplicate key update password = ?, email = ?",
			id, pw, email, pw, email);
	}
}

상황을 구성하기 위한 보조 클래스를 사용하게되면 아래와 같습니다.

Autowired JdbcTemplate jdbcTemplate;
private UserGivenHelper given;

@BeforeEach
void setUp() {
	given = new UserGivenHelper(jdbcTemplate);
}

@Test
void dupId() {
	given.givenUser("cbk", "pw", "cbk@cbk.com");

	// 실행 결과 확인
	assertThrows(DupIdException.class,
		()->register.register("cbk", "strongpw", "email@email.com")
	);
}

통합 테스트에서 동일한 상황 설정이나 검증을 반복할 때는 보조 클래스를 사용하여 유지보수를 용이하게 할 수 있습니다. 이를 통해 중복된 코드를 줄이고 테스트 코드의 가독성과 유지보수성을 높일 수 있습니다.

실행 환경이 다르다고 실패하지 않기

같은 테스트 메서드가 실행 환경에 따라 성공하거나 실패하면 안 됩니다.
로컬 개발환경, 빌드 서버, 맥 OS 등 여러 환경에서 동일하게 동작해야 합니다.
실행 환경에 따라 문제가 되는 예로 파일 경로가 있습니다.

public class BulkLoaderTest {
	private String bulkFilePath = "d:\\mywork\\temp\\bulk.txt";

	@Test
	void load() {
		BulkLoader loader = new BulkLoader();
		loader.load(bulkFilePath);
		// ...
	}
}

이럴 경우 상대 경로를 사용해야 합니다.

public class BulkLoaderTest {
	private String bulkFilePath = "src/test/resources/bulk.txt";

	@Test
	void load() {
		BulkLoader loader = new BulkLoader();
		loader.load(bulkFilePath);
		// ...
	}
}

테스트 코드에서 파일을 생성하는 경우에도 특정 OS나 개발 환경에따라 올바르게 동작하도록 주의해야 합니다.

public class ExporterTest {
	@Test
	void export() {
		String folder = System.getProperty("java.io.tempdir");
		Exporter exporter = new Exporter(folder);
		exporter.export("file.txt");

		Path path = Paths.get(folder, "file.txt");
		assertTrue(Files.exists(path));
	}
}

이 코드는 실행 환경에 알맞은 임시 폴더 경로를 구해서 동작합니다.

간혹 특정 OS 환경에서만 실행해야 하는 테스트도 있습니다.
JUnit 5가 제공하는 @EnabledOnOs, @DisabledOnOs 를 이용하면 됩니다.

실행 시점에 따라 실패하지 않기

회원의 만료 여부를 확인하는 테스트경우 코드 작성 시점에는 사용할 수 있지만 이후 시간이 지나면서 실패하는 테스트가 됩니다.

public class Member {
	private LocalDateTime expiryDate;

	public boolean isExpired() {
		return expiryDate.isBefore(LocalDateTime.now());
	}
}

@Test
void notExpired() {
	// 테스트 코드 작성 시점 2019.1.1
	LocalDateTime expiry = LocalDateTime.of(2019,12,31,0,0,0);
	Member m = Member.builder().expiryDate(expiry).build();
	assertFalse(m.isExpired());
}

이럴 경우 테스트 코드에서 명시적으로 시간을 제어할 방법을 선택하는 것이 좋습니다.

public class Member {
	private LocalDateTime expiryDate;

	public boolean passedExpiryDate(LocalDateTime time) {
		return expiryDate.isBefore(time);
	}
}

@Test
void notExpired() {
	LocalDateTime expiry = LocalDateTime.of(2019,12,31,0,0,0);
	Member m = Member.builder().expiryDate(expiry).build();
	assertFalse(m.passedExpiryDate(LocalDateTime.of(2019,12,30,0,0,0));
}

다른 방법으로는 별도의 시간 클래스를 작성하는 것입니다.

public class BizClock {
	private static BizClock DEFAULT = new BizClock();
	private static BizClock instance = DEFAULT;

	public static void reset() {
		instance = DEFAULT;
	}

	public static LocalDateTime now() {
		return instance.timeNow();
	}

	protected void setInstance(BizClock bizClock) {
		BizClock.instance = bizClock;
	}
	
	public LocalDateTime timeNow() {
		return LocalDateTime.now();
	}
}

public class Member {
	private LocalDateTime expiryDate;

	public boolean isExpired() {
		return expiryDate.isBefore(BizClock.now());
	}

BizClock 클래스의 setInstance() 메서드를 사용하면 instance 정적 필드를 교체할 수 있으므로 클래스를 상속받은 하위 클래스를 이용하면 BizClock.now()에서 현재 시간을 구할 수 있습니다.

class TestBizClock extends BizClock {
	private LocalDateTime now;

	public TestBizClock() {
		setInstance(this);
	}

	public void setNow(LocalDateTime now) {
		this.now = now;
	}
	
	@Override
	public LocalDateTime timeNow() {
		return now != null ? now : super.now();
	}
}

public class MemberTest {
	TestBizClock testClock = new TestBizClock();

	@AfterEach
	void resetClock() {
		BizClock.reset();
	}

	@Test
	void notExpired() {
		testClock.setNow(LocalDateTime.of(2019,1,1,13,0,0));
		LocalDateTime expiry = LocalDateTime.of(2019,12,31,0,0,0);
		Member m = Member.builder().expiryDate(expiry).build();
		assertFalse(m.isExpired());
	}

랜덤하게 실패하지 않기

필요하지 않은 값을 설정하지 않기

단위 테스트를 위한 객체 생성 보조 클래스 사용

조건부로 검증하지 않기

통합 테스트에서 불필요한 연동 범위 확대하지 않기

더 이상 쓸모없는 테스트 코드는 제거하기

테스트 코드는 단순한 검증 도구가 아니라, 소프트웨어의 품질을 유지하고 개선하는 중요한 자산입니다. 따라서 테스트 코드의 유지보수성을 높이는 것은 필수적이며, 이를 위해 위에서 언급한 방법들을 실천하는 것이 좋습니다.