좋은 테스트의 특징(A TRIP) - YooYoungmo/AEP GitHub Wiki

실용주의 프로그래머를 위한 단위 테스트 with JUnit 중 'Chapter 7 좋은 테스트의 특징'을 발췌하여 요약

A-TRIP

Automatic(자동적)

단위 테스트는 자동적으로 실행되어야 한다. '자동적으로'라는 말은 최소 두 가지 경우, 테스트를 실행하는 경우와 결과를 확인하는 경우를 모두 의미하는 것이다. 여러분 혼자만 테스트하는 것은 아니다. 어딘가에서 어떤 컴퓨터가 전체 체크인된 코드에 대해 모든 단위 테스트를 연속으로 실행해 보고 있을 것이다. 자동적이고, 사람이 개입하지 않은 이 확인 작업은 '후방 방어벽' 노릇을 한다. 이것은 체크인된 모든 코드가 어디에서든지 어떤 테스트도 어기지 않는다는 것을 확실히 보장하는 안전 메커니즘이다. '자동적'이라는 말에는 테스트가 자신이 통과 하는지, 그렇지 못한지 결정할 수 있어야 한다는 의미가 포함되어 있다. 한 사람(여러분이나 그외의 불쌍한 희생자) 어느 한 사람을 정해 두고 테스트의 출력을 읽어 그 코드가 제대로 동작하는지 아닌지를 확인하게 한다는 것은 프로젝트 실패의 첩경이다. 테스트가 자신을 검증할 수 있게 만드는 것이 일관성 있는 회귀 테스트의 중요한 기능이다. 테스트가 혼자 실행되고 자신을 검증할 수 있게 만든다는 이 개념은 아주 중요하다. 여러분이 이것에 대해 생각할 필요가 없다는 것을 의미하기 때문이다. 테스트는 프로젝트의 일부로서 알아서 동작한다. 그러면 테스트는 프로젝트 안전망의 중요한 구성 요소로서 제구실을 다 할 수 있게 된다. 오늘날 고공 줄타기처럼 위험하고 민감한 프로그래밍을 할 때는 온 신경을 거기에만 집중해야 할 것이다.

Thorough(철저함)

좋은 단위 테스트는 철저하다. 문제가 될 수 있는 모든 것을 테스트 한다. 그런데 얼마나 철저하게 해야 할까? 극단적인 경우에는 코드의 모든 줄 하나하나, 코드가 취할 수 있는 모든 가능한 분기, 코드가 일으키는 모든 예외 등을 테스트 대상으로 삼을 수 있다. 정반대로 극단적인 경우에는 경계 조건들, 빠뜨렸거나 형식이 잘못된 데이터 등 가장 그럴 듯한 후보들만 테스트한다. 이것은 프로젝트에서 어떤 요구가 생기느냐에 기반을 두고 판단할 문제다. 버그들은 소스 코드 전체에 균일하게 분포되어 있지 않다는 사실을 인식하는 것이 중요하다. 오히려, 버그들은 문제가 되는 영역에 몰리는 경향이 있다.

Repeatable(반복 가능)

모든 테스트는 다른 테스트들로부터 독립적이어야 하는 것과 마찬가지로, 환경으로부터도 독립적이어야 한다. 모든 테스트가 어떤 순서로든 여러 번 반복 실행될 수 있어야 하고, 그때마다 '늘 같은 결과를 내야 한다'는 목표도 변함 없다. 이것은 테스트가 프로그래머의 직접 제어 아래 있지 않은 외부 환경에 의존해서는 안된다는 것을 의미 한다. 반복 가능성을 갖추지 않는다면, 최악의 순간에 뜻밖의 일을 당하는 상황을 면할 수 없을지도 모른다. 더 나쁜 것은, 이 뜻밖의 일이란 것이 보통 가짜(bogus)라는 것이다. 이것을 진짜 버그가 아니라, 테스트와 관련된 문제일 뿐이다. 이 유령 같은 문제들을 찾아내기 위해 시간 낭비를 할 만한 여유는 없다. 각 테스트는 늘 같은 결과를 내야만 한다. 만약 그렇지 않다면, 코드에 '진짜' 버그가 있다고 알려 주는 신호임에 틀림없다.

Independent(독립적)

테스트는 깔끔함가 단정함을 유지해야 한다. 즉, 확실히 한 대강에 집중한 상태여야 하며, 환경과 다른 개발자들(명심하라. 다른 개발자들이 동시에 같은 테스트를 실행해 볼 수도 있다)에게서 독립적인 상태를 유지해야 한다. 또하 독립적이라는 것은 어떤 테스트도 다른 테스트에 의존하지 않는다는 것을 의미한다. 어느 순서로든, 어떤 개별 테스트라도 실행해 볼 수 있어야 한다. 처음 것을 실행할 때 그 밖의 다른 테스트에 의존해야 하는 상황을 원하지는 않을 것이다. 모든 테스트는 섬이어야 한다.

Professional(전문적)

단위 테스트를 위해 작성하는 코드는 진짜다. 몇몇은 고객에게 인도하는 코드보다도 더 진짜배기라고 주장할지도 모르겠다. 이것은 단위 테스트 코드가 제품 코드와 마찬가지로 전문적 표준을 유지하면서 작성되어야 한다는 것을 의마 한다. 좋은 설계를 위한 모든 일반적인 규칙, 캡슐화 유지, DRY 원칙 지키기, 결합도 낮추기 등은 제품 코에서 그랬듯이 테스트 코드에서도 반드시 지켜져야 한다. 테스트 코드가 적어도 제품 코드만큼 있을 거라고 생각하라. 제품 코드에 20,000줄이 있다면, 그것을 실험해 보기 위한 단위 테스트 코드에도 20,000줄이나 그 이상이 있다고 생각하는 게 합리적일 것이다. 이것은 아주 많은 양이고, 이는 테스트 코드가 깔끔함과 단정함을 유지해야 하고, 잘 성계되고 잘 분리되어야 하고, 제품 코드와 마찬가지로 전문적이어야 하는 부분적 이유가 된다.

더 알아보기