CHAPTER 4: 기능 명세·설계

기능 명세: 입력과 결과

입력을 보통 메서드의 파라미터로 전달한다.

결과는 여러 형식으로 정의할 수 있다. (예) 리턴 값, 익센셥

기능 실행 결과에는 변경도 포함한다. (예) 회원 가입 기능은 DB에 회원 정보를 추가한다.

설계 과정을 지원하는 TDD

TDD는 테스트를 만드는 것부터 시작한다.

• 테스트할 기능을 실행
• 실행 결과를 검증

타입의 이름을 정의하고, 타입이 제공할 기능을 결정하는 것은 기본적인 설계 행위이다.

TDD 자체는가 설계는 아니지만, TDD를 하다 보면 테스트 코드를 작성하는 과정에서 일부 설계가 진해앟게 된다.

필요한 만큼 설계하기

• 필요할 것으로 예측해서 미리 코드를 만들지 않는다.
  실제 테스트 사례를 추가하고 통과시키는 과정에서 필요한 만큼 설계를 변경한다.
  - 사전 설계 활동을 생략하는 것은 아니다.
• TDD로 개발하는 코드 비율이 높아질수록 지금 시점에서 필요한 설계만 코드에 반영할 가능성이 커진다. 유연한 설계는 필요한 시점에 추가한다.

기능 명세 구체화

테스트 코드를 작성하기 위해 개발자는 기능 명세를 정리해야 한다.

요구사항 명세서로는 생략된 내용이 많은데 테스트 코드를 작성하려면 입력과 결과가 명확해야 하므로 애매한 점을 발견하면 기획자나 실무 담당자와 얘기해서 상황에 따라 기능이 어떻게 동작해야 하는지 구체적으로 정리할 수 있다.

모호한 상황을 만나면 이를 구체적인 예로 바꾸어 테스트 코드에 반영한다.

특정 상황에서 코드가 어떻게 동작하는지 이해하고 싶다면 해당 상황을 검증하는 테스트를 실행하고 이해가 필요한 코드를 추적하면 된다. 이는 유지보수에 큰 도움이 된다.

CHAPTER 5: JUnit 5 기초

JUnit 5 모듈 구성

• JUnit 플랫폼
• JUnit 주피터
• JUnit 빈티지

@Test 애노테이션과 테스트 메서드

JUnit 코드의 기본 구조는 @Test 애노테이션을 메서드에 붙이는 것이다.

• @Test 애노테이션을 붙인 메서드는 private이면 안 된다.

JUnit Assertions 클래스는 assertEquals() 메서드와 같이 값을 검증하기 위한 다양한 정적 메서드를 제공한다.

주요 단언 메서드

• assertEquals(expected, actual)
• assertNotEquals(unexpected, actual)
• assertSame(Object expected, actual) : 두 객체가 동일한 객체인지 검사한다.
• assertNotEquals(Object unexpected, actual)
• assertTrue(boolean condition)
• assertFalse(boolean condition)
• assertNull(Object actual)
• assertNotNull(Object actual)
• fail() : 테스트 실패 처리

Assertions가 제공하는 익셉션 발생 유무 검사 메서드

• assertThrows(Class<T> expectedType, Executable executable)
• seertDoesNotThrow( Executable executable)

테스트 라이프 사이클

• @BeforeEach
• @AfterEach
• @BeforeAll
• @AfterAll

public class LifecycleTest {
	public LifecycleTest() {
		System.out.,println("new LifecycleTest");
	}

	@BeforeEach
	void setUp() {
		System.out.,println("setUp");
	}

	@Test
	void a() {
		System.out.,println("A");
	}
	@Test
	void b() {
		System.out.,println("B");
	}
	@BeforeEach
	void tearDown() {
		System.out.,println("tearDown");
	}
}

실행 결과

new LifecycleTest
setUp
A
tearDown
new LifecycleTest
setUp
B
tearDown

• @Test 메서드를 실행할 때마다 객체를 새로 생성하는 점을 주의하자

테스트 메서드 간 실행 순서 의존과 필드 공유하지 않기

각 테스트 메서드는 서로 독립적으로 동작해야한다.

서로 필드를 공유한다거나 실행 순서를 가정하고 테스트 작성하지 말아야한다.

JUnit은 테스트 메서드의 실행 순서를 지정하는 방법을 제공하고 있다, 하지만 각 테스트는 독립적으로 동작해야 한다. 테스트 메서드 간에 의존이 생기면 유지보수를 어렵게 만든다.

추가 애노테이션

• @DisplayName
• @Disabled

CHAPTER 6: 테스트 코드의 구성

상황

노련한 개발자는 어떤 상황이 실행 결과에 영향을 줄 수 있는지 찾기 위해 노력한다.

기능에서의 상황

주어진 상황에 따라 기능 실행 결과는 달라진다. 이는 테스트 코드 구조에도 영향을 준다.

테스트 코드의 구성 요소: 상황, 실행, 결과 확인

given, when, then

어떤 상황이 주어지고, 그 상황에서 기능을 실행하고, 실행한 결과를 확인하는 세 가지가 테스트 코드의 기본 골격이다.

JUnit

JUnit에서 상황을 설정하는 방법은 테스트할 대상에 따라 달라진다.

• 객체를 생성할 때 정답 숫자를 지정하는 경우

  @Test
  void exactMatch() {
  	// 정답이 456인 상황
  	BaseballGame game = new BaseballGame("456");
  	// 실행
  	Score score = game.guess("456)
  	// 결과 확인
  	assertEquals(3, score.strikes());
  	assertEquals(0, score.balls());
  }
  
  @Test
  void noMatch() {
  	// 정답이 123인 상황
  	BaseballGame game = new BaseballGame("123");
  	// 실행
  	Score score = game.guess("456)
  	// 결과 확인
  	assertEquals(0, score.strikes());
  	assertEquals(0, score.balls());
  }

• @BeforeEach를 적용한 메서드에서 상황을 설정할 경우

  @BeforeEach
  void givenGame() {
  	BaseballGame game = new BaseballGame("456");
  }
  
  @Test
  void exactMatch() {	// 실행
  	Score score = game.guess("456)
  	// 결과 확인
  	assertEquals(3, score.strikes());
  	assertEquals(0, score.balls());
  }
  
  @Test
  void noMatch() {
  	// 실행
  	Score score = game.guess("456)
  	// 결과 확인
  	assertEquals(0, score.strikes());
  	assertEquals(0, score.balls());
  }

• 상황이 없는 경우
  2장에서 사용한 암호 강도 측정의 경우 결과에 영향을 주는 상황이 존재하지 않으므로 기능을 실행하고 결과를 확인하는 코드만 포함할 수 있다.
  

    @Test
    void meetsAllCriteria_Then_Strong() {	
    	// 실행
    	PasswordStrengthMeter meter = new PasswordStrengthMeter();
    	PasswordStrength result = meter.meter("ab12!@AB");
    	
    	// 결과 확인
    	assertEquals(PasswordStrength.STRONG, result);
    }

• 실행 결과를 확인하는 방법으로 리턴 값을 사용하는 경우나 익셉션을 발생하는 방법이 있다.

  @Test
  void genGame_With_DupBumber_Then_Fail() {	
  	assertThrows(IllegalArgumentException.calss,
  		() -> new BaseballGame("110")
  	);
  }

외부 상황과 외부 결과

상황 설정은 테스트 대상뿐만 아니라 외부 요인도 있다.

File dataFile = new File("file.txt");
long sum = MathUtils.sum(dataFile);

파일이 존재하지 않는 상황을 생각해보자.

• 존재하지 않는 파일을 경로로 사용할 경우

@Test
void noDataFile_Then_Exception() {
	File dataFile = new File("badpath.txt");
	assertThrows(TllegalArgumentException.class,
	() -> MathUtils.sum(dataFile));
}

• 명시적으로 파일이 없는 상황

@Test
void noDataFile_Then_Exception() {
	givenNoFile("badpath.txt");
	File dataFile = new File("badpath.txt");
	assertThrows(TllegalArgumentException.class,
	() -> MathUtils.sum(dataFile));
}

private void givenNoFile(String path) {
	File file = new File(path);
	if (file.exists()) {
		boolean delete = file.delete();
		// 해당 경로에 파일이 존재하는지 검사해서 존재할 경우 해당 파일을 삭제한다.
		if (!deleted)
			throw new RuntimeException("faile givenNoFile:" + path);
	}
}

• 상황에 알맞는 파일을 미리 만들어 둔다.
  다른 개발자도 테스트를 실행할 수 있어야 하므로 테스트에 맞게 준비한 파일은 버전 관리 대상에 추가한다.

@Test
void dataFileSumTest() {
 File dataFile = new File("src/test/resources/datafile.txt");
 long sum = MathUtils.sum(dataFile);
 asserEquals(101, sum);
}

• 파일을 미리 만들지 않고 테스트 코드에서 상황에 맞는 파일을 생성하는 방법

@Test
void dataFileSumTest2() {
	givenDataFile("target/datafile.txt", "1", "2", "3", "4");
 File dataFile = new File("target/datafile.txt");
 long sum = MathUtils.sum(dataFile);
 asserEquals(101, sum);
}

private void givenDataFile(String path, String... lines) {
	try {
		Path dataPath = Paths.get(path);
		if(Files.exists(dataPath)) {
			Files.delete(dataPath);
		}
		Files.write(dataPath, Arrays.asList(lines));
	} catch(IOException e) {
		throw new RuntimeException(e);
	}
}

외부 상태가 테스트 결과에 영향을 주지 않게 하기

테스트 코드는 한 번만 실행하고 끝나지 않는다.

간헐적으로 실패하거나 성공하면 테스트 신뢰도가 떨어진다.

• 예): DB 데이터 상태에 따라 테스트가 성공하기도 하고 실패하는 경우

해결방법은 테스트 실행 전에 외부를 원하는 상태로 만들거나 테스트 실행 후에 외부 상태를 원래대로 되돌려 놓아야 한다.

외부 상태와 테스트 어려움

상황과 결과에 영향을 주는 외부 요인은 파일, DBMS, 외부 서버 REST API 등 다양하다.

외부 상황은 테스트 코드에서 마음대로 제어할 수 없는 경우도 있다.

테스트 대상의 상황과 결과에 외부 요인이 관여할 경우 대역을 사용하면 테스트 작성이 쉬워진다.

대역은 테스트 대상이 의존하는 대상의 실제 구현을 대신하는 구현인데 이 대역을 통해서 외부 상황이나 결과를 대체할 수 있다.

느낀 점

1. 기능 명세와 설계의 중요성: 테스트를 작성하기 전에 기능 명세를 명확히 하고, 설계를 최소한으로 유지하며 필요한 시점에만 설계를 발전시키는 접근이 필요합니다. 이는 유연하고 확장 가능한 코드를 작성이 가능하고 유지보수에 좋습니다.
2. TDD와 설계의 관계: TDD는 설계를 직접적으로 수행하는 것은 아니지만, 테스트 작성 과정에서 자연스럽게 설계가 이루어질 수 있습니다.
3. 테스트 코드의 구조: 테스트 코드는 주어진 상황(given), 그 상황에서의 실행(when), 그리고 그 결과를 확인하는(then) 세 가지로 구성됩니다. 이 구조는 테스트 코드의 가독성을 높이고, 논리적인 흐름을 명확히 하는 데 유용합니다.
4. 외부 요인의 관리: 테스트 결과에 영향을 줄 수 있는 외부 요인(예: 파일, 데이터베이스, 외부 API)들을 관리하는 것이 중요합니다. 해결방법은 테스트 실행 전에 외부를 원하는 상태로 만들거나 테스트 실행 후에 외부 상태를 원래대로 되돌려 놓아야 합니다.
5. 대역의 사용: 외부 의존성을 테스트에서 제어하기 어려울 때, 대역(Stub, Mock 등)을 사용하여 테스트를 단순화하고, 신뢰성을 높일 수 있습니다.