Contents
테스트 코드 작성 순서
   Sep 13, 2022     3 min read

테스트 코드 작성 순서

  • 테스트 작성 순서
  • 작성 순서 예제
  • 테스트 목록

그 전 Chapter에서 암호 측정 기능 테스트 코드 작성순서

  1. 모든 규칙을 충족하는 암호 강도는 ‘강함’
  2. 길이만 8글자 미만이고 나머지 규칙은 충족하는 암호의 강도는 ‘보통’
  3. 숫자를 포함하지 않고 나머지 규칙은 충족하는 암호의 강도는 ‘보통’
  4. 값이 없는 암호의 강도는 ‘유효하지 않음’
  5. 대문자를 포함하지 않고 나머지 규칙은 충족하는 경우
  6. 길이가 8글자 이상인 규칙만 충족하는 경우
  7. 숫자 포함 규칙만 충족하는 경우
  8. 대문자 포함 규칙만 충족하는 경우
  9. 아무 규칙도 충족하지 않는 경우

이 순서는 이 규칙에서 나왔다.

  • 쉬운 경우에서 어려운 경우로 진행
  • 예외적인 경우에서 정상인 경우로 진행

초반에 복잡한 테스트부터 시작하면 안되는 이유

만약 초반부터 다양한 조합을 검사하는 복잡한 상황을 테스트로 추가하면 해당 테스트를 통과 시키기 위해 한 번에 구현해야 할 코드가 많아진다.

예를들면

  • 대문자 포함 규칙만 충족하는 경우
  • 모든 규칙을 충족하는 경우
  • 숫자를 포함하지 않고 나머지 규칙은 충족하는 경우

순서대로 TDD를 진행 → 우선 대문자 포함 규칙만 충족하는 경우를 테스틑하기 위한 코드를 작성

@Test
void meetsOnlyUpperCreteria_Then_Weak(){
	PasswordStrengthMeter meter = new PasswordStrengthMeter();
	PasswordStrength result = meter.meter("abcDef");
	assertEquals(PasswordStrength.WEAK, result);
}

이 테스트를 통과시킬 만큼 구현하는 것은 간단하다. 단순히 WEAK를 리턴하면 된다.

public class PasswordStrengthMeter{
	public PasswordStrength meter(String s) {
		return PasswordStrength.WEAK;
	}
}

모든 규칙을 충족하는 경우를 테스트하기 위한 코드를 추가

@Test
void meetsAllCreteria_Then_Weak(){
	PasswordStrengthMeter meter = new PasswordStrengthMeter();
}

구현하기 쉬운 테스트부터 시작하기

가장 구현하기 쉬운 경우부터 시작하면 빠르게 테스트를 통과시킬 수 있다.

  • 모든 조건을 충족하는 경우
  • 모든 조건을 충족하지 않는 경우

첫 번째로 모든 조건을 충족하는 경우를 테스트하면 단순히 STRONG을 리턴한다.

두 번째는 비슷한 모든 조건을 충족하지 않는 경우를 첫 번째로 테스트하면 단순히 WEAK를 리턴하면 된다.

  • 다음 추가 테스트 구현은 쉬운 것이 선택 기준
    • 모든 규칙을 충족하지 않는 경우
    • 한 규칙만 충족하는 경우
      • 한 규칙을 충족하는지 검사 → WEAK 리턴
    • 두 규칙을 충족하는 경우
      • 두 규칙을 충족한다는 것은 충족하지 않는 규칙이 하나 존재한다는 것이므로 한 규칙을 충족하는지 검사해서 충족하지 않으면 NORMAL을 리턴한다.

모든 규칙을 충족하지 않는 경우보다 한 규칙만 충족하거나 두 규칙을 충족하는 경우를 테스트하는 게 더 쉽게 구현할 수 있다.

그렇다면 여러 규칙 중에서 어떤 규칙을 검사하는 것이 가장 쉬울까?

  • 대문자 포함 여부를 검사하거나 숫자 포함 여부를 검사하는 것보다는 8글자 이상인지 검사하는 것이 쉽다.

따라서 다음 테스트는 아래와 같다.

  • 길이만 8글자 미만이고 나머지 규칙은 충족하는 암호의 강도는 ‘보통’

그리고 다음 테스트

  • 길이가 8글자 이상이고 나머지 규칙은 충족하지 않은 암호의 강도는 ‘약함’

둘다 길이가 8글자 이상인지 여부를 판단하는 로직만 구현하면 테스트를 통과시킬 수 있다.

Tip. 한 번에 구현하는 시간이 짧아지면 디버깅할 때에 유리하다.

  • 작성한 코드가 많지 않고 작성 시간도 짧으면 머릿속에 코드에 대한 내용이 생생하게 남아 있기 때문에 디버깅할 때 문제 원인을 빠르게 찾을 수 있다.

예외 상황을 먼저 테스트해야 하는 이유

다양한 예외 상황은 복잡한 if-else 블록을 동반할 때가 많다. 예외 상황을 전혀 고려하지 않은 코드에 예외 상황을 반영하려면 코드의 구조를 뒤집거나 코드 중간에 예외 상황을 처리하기 위해 조건문을 중복해서 추가하는 일이 벌어진다. 이는 코드를 복잡하게 만들어 버그 발생 가능성을 높인다.

초반에 예외 상황을 테스트하면 이런 가능성이 줄어든다. 예외 상황에 따른 if-else 구조가 미리 만들어지기 때문에 많은 코드를 완성한 뒤에 예외 상황을 반영할 때보다 코드 구조가 덜 바뀐다.

※주의※

TDD를 하는 동안 예외 상항을 찾고 테스트에 반영하면 예외 상황을 처리하지 않아 발생하는 버그도 줄여준다.

암호 등급 측정 예의 경우 암호 값이 없는 상황에 대한 테스트를 추가했다. 이 테스트를 추가하지 않으면 시스템 운영 중에 NPE가 발생할 수 있다.

완급 조절

TDD를 처음 접할 때 다음 단계에 따라 TDD를 익혀보자.

  • 정해진 값을 리턴
  • 값 비교를 이용해서 정해진 값을 리턴
  • 다양한 테스트를 추가하면서 구현을 일반화