마틴 파울러의 UnitTest 이해하기 - 번역본

원본 사이트 - martinfowler.com/bliki/UnitTest.html

bliki: UnitTest

 

단위 테스트는 소프트웨어 개발에서 자주 언급되며 프로그램을 작성하는 동안 제가 익숙한 용어입니다. 그러나 대부분의 소프트웨어 개발 용어와 마찬가지로 매우 잘못 정의되어 있으며 사람들이 실제보다 더 엄격하게 정의되었다고 생각할 때 종종 혼동이 발생할 수 있습니다.

전에는 많은 단위 테스트를 해봤지만 Kent Beck과 함께 작업을 시작하고 Xunit 단위 테스트 도구 제품군을 사용했을 때 결정적인 노출이있었습니다 . (사실 나는 때때로 이 테스트 스타일의 좋은 용어가 "xunit 테스트"라고 생각한다.) 단위 테스트는 또한 ExtremeProgramming (XP) 의 시그니처 활동이되었고 빠르게 TestDrivenDevelopment로 이어졌습니다.

초기부터 XP의 단위 테스트 사용에 대한 정의적인 우려가있었습니다. 나는 유즈넷 토론 그룹에서 우리 XPers가 "단위 테스트"라는 용어를 오용 한 것에 대해 테스트 전문가로부터 비난을 받았던 토론에 대한 뚜렷한 기억을 가지고 있습니다. 우리는 그에게 그의 정의를 물었고 그는 "교육 과정의 첫날 아침에 단위 테스트에 대한 24 가지 다른 정의를 다룹니다."와 같이 대답했습니다.

변형에도 불구하고 몇 가지 공통 요소가 있습니다. 
첫째, 단위 테스트가 소프트웨어 시스템의 작은 부분에 초점을 맞춘 저수준이라는 개념이 있습니다. 둘째로, 단위 테스트는 일반적으로 프로그래머가 일반 도구를 사용하여 작성합니다. 유일한 차이점은 일종의 단위 테스트 프레임 워크를 사용하는 것입니다 [1] . 셋째, 단위 테스트는 다른 종류의 테스트보다 훨씬 빠를 것으로 예상됩니다.

따라서 몇 가지 공통 요소가 있지만 차이점도 있습니다. 한 가지 차이점은 사람들이 하나의 단위로 간주하는 것 입니다. 객체 지향 디자인은 클래스를 하나의 단위로 취급하는 경향이 있으며, 절차적 또는 기능적 접근 방식은 단일 기능을 하나의 단위로 간주 할 수 있습니다. 그러나 실제로는 상황에 따른 것입니다. 팀은 시스템 및 테스트에 대한 이해를 위해 단위가되는 것이 합당한 것을 결정합니다. 나는 유닛이 클래스라는 개념으로 시작하지만 종종 밀접하게 관련된 클래스를 여러 개 가져 와서 하나의 유닛으로 취급합니다. 드물게 클래스에서 메서드의 하위 집합을 단위로 취할 수 있습니다. 그러나 당신이 그것을 정의하는 것은 실제로 중요하지 않습니다.

Solitary or Sociable? - 독방인가 사교인가?

더 중요한 차이점은 테스트하는 단위가 사교적이어야하는지 아니면 혼자 야하는지 여부입니다 [2] . 주문 클래스의 가격 방법을 테스트한다고 상상해보십시오. 가격 메소드는 제품 및 고객 클래스에 대한 일부 기능을 호출해야합니다. 단위 테스트가 단독으로 이루어지기를 원한다면 고객 클래스의 결함으로 인해 주문 클래스의 테스트가 실패 할 수 있으므로 여기서 실제 제품 또는 고객 클래스를 사용하고 싶지 않습니다. 대신 공동 작업자 를 위해 TestDoubles 를 사용 합니다.

그러나 모든 단위 테스터가 단독 단위 테스트를 사용하는 것은 아닙니다. 실제로 90 년대에 xunit 테스트가 시작되었을 때 우리는 협력자들과의 의사 소통이 어색하지 않는 한 (원격 신용 카드 확인 시스템과 같은) 혼자 가려고 시도하지 않았습니다. 인접한 테스트가 실패하더라도 실제 결함을 추적하는 것이 어렵지 않았습니다. 그래서 우리는 테스트를 사교적으로 허용하는 것이 실제로 문제를 일으키지 않는다고 느꼈습니다.

실제로 사교적인 단위 테스트를 사용하는 것이 우리가 "단위 테스트"라는 용어를 사용하는 것에 대해 비판을받은 이유 중 하나였습니다. 이러한 테스트는 단일 유닛의 동작 테스트이기 때문에 "단위 테스트"라는 용어가 적절하다고 생각합니다. 우리는 해당 유닛 이외의 모든 것이 올바르게 작동한다고 가정하여 테스트를 작성합니다.

2000 년대에 xunit 테스트가 더 대중화됨에 따라 적어도 일부 사람들에게는 단독 테스트라는 개념이 다시 나타났습니다. 모킹을 지원하는 모의 객체와 프레임 워크가 등장했습니다. 두 개의 xunit 테스트 학교가 개발되었으며,이를 클래식 스타일과 모의 스타일이라고 부릅니다 . 두 스타일의 차이점 중 하나는 모의 전문가가 단독 단위 테스트를 고집하는 반면 고전주의자는 사교적 인 테스트를 선호한다는 것입니다. 오늘 저는 두 스타일의 xunit 테스터를 알고 존경합니다 (개인적으로 저는 클래식 스타일을 유지했습니다).

저와 같은 고전적인 테스터조차도 어색한 협업이있을 때 테스트 복식을 사용합니다. 원격 서비스와 통신 할 때 비결 정성을 제거하는 데 매우 중요 합니다 . 실제로 일부 고전주의 xunit 테스터는 데이터베이스 또는 파일 시스템과 같은 외부 리소스와의 모든 협력은 double을 사용해야한다고 주장합니다. 부분적으로 이것은 비결 정성 위험, 부분적으로는 속도 때문입니다. 이것이 유용한 지침이라고 생각하지만 외부 리소스에 double을 사용하는 것을 절대적인 규칙으로 취급하지는 않습니다. 리소스와의 대화가 안정적이고 빠르다면 단위 테스트에서 수행하지 않을 이유가 없습니다.

속도

단위 테스트의 일반적인 속성은 프로그래머가 직접 수행하는 작은 범위, 빠른 속도로 프로그래밍 할 때 매우 자주 실행할 수 있음을 의미합니다. 실제로 이것은 SelfTestingCode 의 주요 특성 중 하나입니다 . 이 상황에서 프로그래머는 코드를 변경 한 후 단위 테스트를 실행합니다. 컴파일 할 가치가있는 코드가있을 때마다 1 분에 여러 번 단위 테스트를 실행할 수 있습니다. 실수로 무언가를 부 수면 즉시 알고 싶기 때문에 이렇게합니다. 마지막 변경 사항으로 결함을 도입했다면 멀리 볼 필요가 없기 때문에 버그를 발견하기가 훨씬 쉽습니다.

단위 테스트를 너무 자주 실행하면 모든 단위 테스트를 실행하지 못할 수 있습니다. 일반적으로 현재 작업중인 코드 부분에 대해 작동하는 테스트 만 실행하면됩니다. 평소와 같이 테스트 스위트를 실행하는 데 걸리는 시간과 테스트의 깊이를 상쇄합니다. 이 스위트를 컴파일 스위트 라고 부를 것입니다. 컴파일을 생각할 때마다 실행되는 것이기 때문입니다. Ruby와 같은 해석 언어에서도 실행됩니다.

지속적 통합을 사용하는 경우 테스트 스위트를 일부로 실행해야합니다. 커밋 스위트 라고 부르는이 스위트 는 모든 단위 테스트를 포함 하는 것이 일반적입니다 . 또한 몇 개의 BroadStackTest가 포함될 수 있습니다 . 프로그래머는이 커밋 모음을 하루에 여러 번 실행해야합니다. 확실히 버전 제어에 대한 공유 커밋 전에는 물론 다른 시간에 휴식을 취하거나 회의에 가야 할 때도 마찬가지입니다. 커밋 스위트가 빠를수록 더 자주 실행할 수 있습니다. [3]

사람들마다 단위 테스트와 테스트 스위트의 속도에 대한 표준이 다릅니다. David Heinemeier Hansson 은 몇 초가 걸리는 컴파일 스위트와 몇 분이 걸리는 커밋 스위트에 만족합니다. Gary Bernhardt 는 그것이 견딜 수 없을 정도로 느리다는 것을 발견하고 약 300ms의 컴파일 스위트를 주장하며 Dan Bodart 는 그의 커밋 스위트가 10 초 이상이되는 것을 원하지 않습니다.

여기에는 절대적인 답이 없다고 생각합니다. 개인적으로 나는 1 초 이하의 컴파일 스위트와 몇 초의 차이를 느끼지 못합니다. 커밋 스위트가 10 분 이내에 실행되어야한다는 Kent Beck의 경험 법칙이 마음에 듭니다. 그러나 진짜 요점은 테스트 스위트가 충분히 자주 실행되는 것을 낙담하지 않도록 충분히 빠르게 실행되어야한다는 것입니다. 그리고 버그를 발견했을 때 신속하게 찾을 수있을만큼 충분히 적은 양의 작업이 필요합니다.

메모

1: 나는 이것이 확실히 XP로 인해 변경된 것이기 때문에 "오늘"이라고 말한다. 세기가 바뀌는 논쟁에서 XPers는 프로그래머가 자신의 코드를 절대 테스트해서는 안된다는 공통된 견해를 갖고 있기 때문에 이에 대해 강하게 비판을 받았습니다. 일부 상점에는 개발자가 이전에 작성한 코드에 대한 단위 테스트를 작성하는 것이 전체 작업 인 특수 단위 테스터가있었습니다. 그 이유는 다음과 같습니다. 자신의 코드를 테스트하는 데 개념적인 맹목이있는 사람들, 프로그래머가 좋은 테스터가 아니며 개발자와 테스터 사이에 적대적인 관계를 갖는 것이 좋았습니다. XPer의 견해는 프로그래머가 최소한 단위 수준에서 효과적인 테스터가되는 법을 배울 수 있다는 것이 었습니다. 그리고 만약 당신이 별도의 그룹을 포함한다면 테스트가 제공 한 피드백 루프는 절망적으로 느려질 것입니다. Xunit은 여기서 중요한 역할을했으며, 테스트를 작성하는 프로그래머의 마찰을 최소화하도록 특별히 설계되었습니다.

2 : Jay Fields 는 "단독"과 "사교 가능" 이라는 용어를 생각해 냈습니다.

3 : 유용한 테스트가 있지만 커밋 스위트를 실행하는 데 더 오래 걸리는 경우 DeploymentPipeline을 빌드 하고 파이프 라인의 나중 단계에 더 느린 테스트를 배치 해야합니다 .