1. 17장 프로젝트 냄새

2. 1. 테스트를 작성하지 않는 개발자 2. 버그 투성이 테스트 3. 높은 테스트 유지 비용 4. 제품 버그

3. 테스트를 작성하지 않는 개발자 증상 : 개발자가 테스트를 작성하지 않는다. 버그가 왜 이렇게 많죠?거긴 테스트를 안만들었는데요…

4. 테스트를 작성하지 않는 개발자 미치는 영향 : 자동 테스트를 작성하지 않는 것은 팀의 미래를 저당 잡히는 짓! 테스트 빚(test debt)을 지게 되므로길게 봤을때 개발 속도저하를 가져오고리팩토링도 점점 더 어려워지고결국 지옥문으로 되돌아가는 길이 될 것.

5. 테스트를 작성하지 않는 개발자 원인 : 부족한 시간 테스트하기 힘든 코드 잘못된 자동화 전략

7. 개발자가 테스트 작성법을 몰라.

8. 개발자에게 필요한 건? 테스트 개발을 학습할 시간과 그에 따른 일정조정

10. 깨지기 쉬운 테스트테스트 실행에 영향이 안가게SUT를 변경하지만아.. 테스트가 컴파일이 안돼… 실행이 안돼…

12. 개발자에게 적절한 권한과 시간을.

14. 버그 투성이 테스트 완전자동테스트를 도입했지만 어딘가 문제 있음을 알려주는 프로젝트 단위의 신호 코드는 정상인데 테스트가 실패(거짓양성 – 양치기 소년, 신뢰 상실) 실제 버그가 발생하는데 테스트는 성공(거짓음성 – 테스트가 바보)

15. 버그 투성이 테스트 원인 : 깨지기 쉬운 테스트 애매한 테스트 테스트 하기 힘든 코드

17. 동작에 민감함?

18. 데이터에 민감함?

24. 높은 테스트 유지 비용 어플 개발도 힘든데 테스트까지 유지 보수 해야 하다니… 너무 힘들어요. 기능 추가할 때 마다 테스트도 많이 고쳐야 해요. 새로운 기능 개발에 드는 기간이 점점 늘어나요. 테스트 유지 보수 때문에 팀의 생산력이 떨어져요. 그 동안의 노력이 물거품이 되는 한이 있더라도 테스트를 없애버리고 싶어요!

26. 너무 많은 테스트가 같은 픽스처 설계에 의존하는깨지기 쉬운 테스트

32. 무엇이 문제인지를 잘 파악하고

33. 좋은 방법을 찾도록 개발자들을 독려하고 지원해 주어야.

34. 추가 기능 조절, 개발속도 조절, 테스트 리팩토링 스토리 기간을 만들어 시간을 벌어주어야.

36. 제품 버그 그렇게 노력했건만,공식테스팅이나 제품에 버그가 너무 많아. 개발시 버그 제거 시간 보다 공식 테스트 기간일 때 더 오래 걸리고,제품에서 발견될 때는 더더더 오래 걸린다. 미뤄지는 출시일, 개발비용의 상승, 회사의 신뢰도 추락 등

37. 제품 버그 원인 : 드문 테스트 실행 놓친 테스트 빠진 단위 테스트 테스트 안 된 코드 테스트 안 된 요구 사항 절대 실패하지 않는 테스트

39. 테스트 실행이 너무 오래 걸려서.

40. 상관없는 실패가 너무 많아.

41. 테스트를 할 때마다 직접 조정 해줘야 해서.(수동 조정 Manual Intervention)

43. 예전에는 테스트가 걸러주던 버그인데 재발…찾아보니 해당 테스트가 비활성화 되어.

45. 테스트 메소드를 테스트 스위트 객체에 추가하는걸 까먹은건 아닌지.

46. 스위트들의스위트에 테스트 스위트를 추가하는 걸 까먹은건 아닌지.

47. 테스트케이스 클래스에 [TestFicture]속성을 추가하는 걸 까먹은건 아닌지.

48. 이름규약에 맞지 않는 메소드 이름을 사용했는지.

49. 테스트 메소드에[Ignore]속성을 추가한건 아닌지.

51. 테스트 스위트에서 특정 테스트만 실행하도록 하거나,

52. 테스트 무시 기능 지원과 동시에 실행되지 않는 테스트 개수를 항상 체크하는 기능을 지원하거나,

60. 하지만 작성한 테스트는 모두 통과한다.

61. 어떠한 요구 사항을 처리 하기 위한 코드를 추가해야 할 때

65. 그 기능에 대한 테스트는 통과한다.

68. 대강 만든 실행기(Humble Executable)를 지원할 수 있게 리팩토링 하기.