테스트주도개발 09

테스트 주도개발 9장

9.1 저희는 이미 충분히 많은 기능 테스트를 하고 있습니다. 그런데도 따로 단위 테스트 케이스를 만들 필요가 있을까요?

• 있다.

9.2 개발 시에 결과값을 미리 예상할 수 없는 경우에는 그럼 어떻게 TDD를 진행하나요?

• 결과 값을 모르고 개발하는 경우는 드물다. 실제 개발 업무가 아닌 경우가 높다.

9.3 저희는 특정 객체 생성 시 사용되는 값이 랜덤 값입니다. 이런 랜덤 값에 대한 테스트는 어 떻게 만드나요?

• 그럴경우 assetEquals보다 assertTrue를 이용해라.
• 분포가 중요한 경우 오차값을 포함한 통계를 측정해서 판단해라.

Dice dice = new Dice(); // 주사위 객체를 생성한다.
int [] distribution = new int[7]; // 분포를 저장할 수 있게 배열을 잡는다.

for(int i = 0; i < 60000; i++){ // 충분히 많은 숫자에 대해 동작시킨다.
	distribution[dice.roll()]++; // 주사위 숫자에 해당하는 배열의 숫자가 증가한다.
} 
assertEquals(10000, distribution[1], 100); // 특정 값의 분포가 오차 내에 있는지 확인한다

9.4 만일 팀 내에 TDD를 통한 단위 테스트 케이스를 작성하지 않고도 이미 높은 수준의 코드를 작성하고 있다면 어떻게 해야 할까요?

• 미래를 봐라. 해야하는게 맞다.
• 내 생각 : 근데 이건 판단이 ㅋㅋㅋ 누가함? 그게 객관적임?

9.5 단위 테스트 케이스 코드를 작성하기가 여전히 어렵습니다. 옆 동료를 보니까, 전 잘 이해 할 수 없는 코드를 이용해 어떻게든 테스트 코드를 만들면서 진행하고 있던데, 저는 어떻게 해 야 할까요?

• TDD의 목표가 테스트 작성이 아닌 더 나은 설계를 만드는 것에 있다는 사실을 잊지 말자.
• 억지로 테스트를 작성하는 것은 잘못된 접근이다. 테스트를 작성하기 쉽게 코드를 작성하는 것이 맞다.
• 테스트를 만들기 어렵다는 것은 기본 코드 설계가 잘못 되었다는 것이다. 의존성이 높다는 뜻.
• Mock을 최대한 사용하지 않는 것이 좋다. 의존성이 높다는 뜻이기 때문이다.
• 즉, 테스트 케이스가 작성하기 어렵다는 말이 테스트 작성하는 자체인지 아님 작성하기 어렵게 프로그램이 설계되어 있는지 봐야 한다.

9.6 왜 이클립스의 각종 기능과 단축키 등을 사용해야, 혹은 배워야 하나요? 전 울트라 에디터 (UltraEditor)나 심지어 때로는 메모장(notepad)으로도 충분히 잘할 수 있다구요! (게다가 TDD 랑 무슨 상관?)

• 효율적으로 시간을 관리 할 수 있다.
• 생각할 시간을 높여준다.

9.7 테스트 케이스를 작성할 때 사용하게 되는 외부 모듈이 익숙지 않을 때는 어떻게 해야 하 나요?

• 라이브러리 학습을 위한 테스트 케이스
• 업무 코드 작성을 위한 테스트 케이스 : 일단은 배제하고 업무 시나리오에 맞게 테스트 케이스 작성

9.8 private 메소드도 테스트 케이스를 만들어야 하나요?

• 굳이 할 필요는 없다.
• private 특성상 해당 클래스에서만 작동하므로 public을 테스트한다는 것은 private도 자동적으로 테스트가 된다는 뜻으로 간주.
• 굳이 한다면 리플렉션으로 가능하다 추후 쓸모가 없어짐.

9.9 사용자가 직접 수행하는 수동 테스트와 자동화된 테스트, 굳이 TDD에 한정하지 않고 봤을 때, 어느 것이 더 중요한가요?

• 둘 다 중요하나 굳이 선택하자면 자동화.

9.10 TDD를 적용하기 대표적인 이유는 무엇입니까?

• 해야할 기능이나 기능 리스트가 명확하지 않으면 테스트 코드를 작성하기 매우 어려워진다는 점
• 예제 코드 수준이 현업의 업무 상황이나 레벨과 차이가 많이 남
• 개발자들의 연습이 안되어 있음
• 체계적인 가이드가 없음.

9.11 테스트 케이스를 최대한 정교하게 작성하려고 노력하고 있습니다. 그런데, 그러다 보니 테 스트 대상 객체나 코드가 조금만 변경이 일어나도 테스트가 와장창 깨져서 유지보수하는 데 비 용이 많이 듭니다. 이젠 솔직히 TDD에 대한 회의가 들 정도에요. 뭐가 잘못된 걸까요?

• 민감한 센서일수록 오탐률이 높은게 사실. 답은 없다.
• 그렇지만 포기하지말고 필요한만큼만 테스트한다는 원칙을 세워보자

9.12 면접시 TDD에 대해서

• TDD의 장점과 단점을 아는 것이 중요.

• TDD에 단점을 말하는 것이 더 TDD에 잘 안다는 것.

9.13 void 메소드 테스트에 대해서

• 이런 메소드는 Mock을 기반한 행위 기반 테스트를 해야 함.
• 상태를 확인 가능한 다른 메소드로 테스트 하는 것
• 위의 경우가 안되면 리플렉션. 그러나 비추천

9.14 TDD와 단위 테스트는 같은 건가?

• TDD는 개발 방식을 의미. 단위 테스트는 자동화된 테스트 케이스를 의미
• 단위 테스트는 TDD로 개발한 부산물. 즉, 하위 개념.

9.15 커버리지 100%의 의미

• 커버리지가 낮으면 케이스가 부족하다는 의미. 추가할 필요가 있다.
• 100%가 되었다는 것은 한번은 해당 로직의 흐름에 맞추어 테스트 케이스가 진행 했다는 것. 그 이상의 의미는 아님.
• 누누히 얘기해지만 이것을 순수 목적으로 삼으면 TDD 영역이 아님.
• 최종 목표는 개발하는 프로그램의 효율적관리와 더 나은 설계를 하기 위한 것이다.
• 커버리지가 높다고 해서 잘 되고 있다고 판단하기 어려움
• 테스트 케이스는 불안함이 사라지기 전까지 하면 되는 것.