도전 TDD! - 테스트 주도 개발의 패턴(2)
테스트 주도 개발 패턴 27장~29장
6/13/2024, 11:17:00 PM
27장. 테스팅 패턴
자식 테스트
- 지나치게 큰 테스트 케이스는 깨지는 부분에 해당하는 작은 테스트 케이스를 작성하고 그 작은 테스트 케이스가 실행되도록 하라.
- 빨강/초록/리팩토링 리듬을 유지하는건 중요함. 테스트가 너무 크면 방해됨.
모의 객체
- 비용이 많이 들거나 복잡한 리소스에 의존하는 테스트라면, 모의 객체를 써라.
- 데이터베이스를 통한 테스트 같은 것
- 가독성이 좋아진다는 점도 있음
- 모의 객체를 적극적으로 사용하려면, 객체의 가시성이 좋아야한다. 그로인해 모의 객체를 도입하다보면 설계에서 커플링이 감소하도록 유도된다.
- 모의 객체가 진짜 객체와 동일하게 동작하지 않는다면..? 실제로 발생하는 문제이기도 하고, 모의 객체에 대한 비판점이기도 함.
셀프 션트(self shunt)
- 한 객체가 다른 객체와 올바르게 대화하는지 테스트하려면, 대화 상대 자체를 테스트 케이스로 만들어버려라.
- 이를 위해서 인터페이스 추출이 필요하다. 인터페이스 추출은 여러 곳에서 쓰이는 경우가 많기는 하지만 복잡하기 때문에, 그냥 원래 클래스를 블랙박스로 테스트 할건지 판단해야 한다.
로그 문자열
- 호출 순서가 올바른지 검사하려면, 로그 문자열을 가지고 있다가 호출 될때마다 문자열에 추가하고 검사하라.
크래시 테스트 더미
- 발생하기 힘든 에러 상황을 테스트하려면, 그냥 예외를 발생시키기만 하는 특수 객체를 만들어서 호출해라.
- 모의 객체와 유사.
깨진 테스트
- 혼자 프로그래밍 할때는, 마지막 테스트가 깨진 상태로 끝마치는 것이 좋다.
- 다음번에 다시 시작할때, 어느 작업부터 시작할 것인지 명백히 할 수 있다.(작업 책갈피)
28장. 초록 막대 패턴
깨진 테스트를 빠르게 고치는 방법. 초록 막대로 빠르게 만드는건 중요하다!
가짜로 구현하기(진짜로 만들기 전까지만)
- 실패하는 테스트를 만든 후 첫 번째 구현은 그냥 상수를 반환하게 해라
- 이렇게까지 해서 일단 돌아가도록 만드는게 그렇게 중요한가?
- 초록 막대 상태는 자신이 어디에 있는지 아는 상태이다. 확신을 가지고 거기서부터 리팩토링 할 수 있다
- 고민의 범위를 조절할 수 있다.
삼각측량
- 최대한 보수적으로 추상화하려면, 오로지 예가 두 개 이상일 때에만 추상화를 하라.
- 어떻게 해야 올바르게 추상화할 것인지 정말 감잡기 어려울 때만 사용하는 편.
명백한 구현
- 단순한 연산들은 그냥 구현해버려라. 정말 확신이 들때는 그렇게 해라.
- 그러나.. 당신은 정말 완벽한가? 정말 그게 가장 단순한 변경인가? 명백한 구현은 계단을 두걸음씩 올라가는 것과 같다. 손가락이 머리를 따라오지 못하면 바로 한걸음씩으로 바꿔라.
하나에서 여럿으로
- 객체 컬렉션을 다루는 연산은 어떻게 구현할까? 일단 컬렉션 없이 구현하고 그 다음에 컬렉션을 사용하라.
29장. xUnit 패턴
단언(assertion)
- 단언은 구체적이어야 한다.
- 객체를 블랙박스처럼 취급하고 단언을 평가해야 한다. public 메서드만 사용해서 테스트하는게 좋다. 화이트박스 테스트를 바라는 것은 테스팅 문제가 아니라 설계 문제다. 클래스 내부의 변수 등을 대상으로 평가하지 말라는 뜻.
픽스처
- 여러 테스트에서 공통으로 사용하는 객체들은 setUp 에서 초기화하라
- 단점은 픽스처를 쓰면, 테스트 코드를 읽는 방향이 뒤죽박죽이 될 수 있다는 점.
- 약간 다른 픽스처가 필요하면 아예 새로운 TestCase 하위 클래스를 만들어버리는 편. 모델 클래스(제품 코드) 와 테스트 클래스 사이에 단순한 관계가 존재하는건 아니다. 모델클래스 하나당 테스트 클래스가 꼭 하나일 필요는 없다.
테스트 메서드
- 테스트 메서드 이름은 나중에 아무것도 모르는 사람이 이 코드를 읽더라도 왜 이 테스트가 작성되었는지 알 수 있어야 한다.
- 테스트 메서드는 읽기 쉬워야 한다. 목표에 다가가는 가장 짧은 코드로 간단하게 작성하라. 쪼개라.
예외 테스트
- 예외가 발생하는 것이 정상인 경우를 테스트하려면, 예외는 잡아서 무시하고, 예외가 발생하지 않는 경우에 테스트가 실패하게 하라.
- assertThrow 같은 단언도 있으므로 꼭 이래야 하진 않을듯..
소감
이 3개의 장에서는 테스트를 효과적으로 짜고 빠르게 통과시킬 수 있는 방법에 대해 설명하고 있다. 나는 보통 JUnit + AssertJ + Mockito 으로 테스트 코드를 작성하는데 이 조합으로 이미 효과적으로 테스트를 작성할 수 있었다.
댓글
* 작성 이후에 수정/삭제 할 수 없어요!
아직 작성된 댓글이 없습니다.