[번역] TDD에 대한 큰 오해

원문 : https://linkedrecords.com/the-big-tdd-misunderstanding-8e22c2f1fc21

💡 “단위 테스트”의 “단위”라는 용어는 원래 테스트 대상 시스템의 단위가 아니라 테스트 자체를 의미한다는 일부 루머가 있습니다. 이 아이디어는 테스트가 하나의 단위로 실행될 수 있고 다른 테스트를 사전에 실행하는데 의존하지 않는다는 의미였습니다(이 글과 이 영상 살펴보세요).

그러나 사람들이 "단위"를 시스템의 클래스/메서드로 간주할 때 일반적으로 두 가지 일이 발생합니다. 먼저 개발자가 모든 클래스나 메서드에 대해 하나의 "단위 테스트"를 독단적으로 작성한다는 것입니다. 두 번째로 테스트 더블(모의 객체)을 사용하여 이러한 "단위"를 다른 "단위"와 분리하는 것입니다.

코드 베이스에서 아주 작은 부분을 수정했는데, 테스트 스위트에서 알려주는 유일한 것은 대상 코드가 정상적인데도 불구하고 테스트가 실패하는 경우를 하루 종일 다시 작성하느라 바쁠 것이라는 것뿐입니다.

단위를 서로 분리하면 잠재적인 버그를 더 쉽게 발견할 수 있다는 주장이 있습니다. 즉, 테스트 스위트는 어떤 클래스/메서드/함수에서 문제가 있는지 정확히 알려준다는 것입니다. 제 생각에는 거짓 양성 테스트 케이스가 엄청나게 많이 발생하고 이를 수정하는 데 시간이 많이 걸리기 때문에 이 방법은 효과가 없는 것 같습니다. 또한 코드 베이스를 조금이라도 알고 있다면 문제가 어디에 있는지 알 수 있을 것입니다. 그렇지 않다면 이번이 코드 베이스를 좀 더 자세히 알 수 있는 기회입니다.

안타깝게도 현재 단위 테스트에 대한 인식은 매우 경직되어 있으며, 다르게 생각하는 것은 금기시되는 주제입니다. 하지만 테스트에 관해서는 mockist와 classicist라는 두 가지 학파가 있다는 사실을 알면 사고방식을 조금 느슨하게 하는 데 도움이 될 수 있습니다. 다음은 주로 classicist 스타일에서 영감을 받아 "좋은" 테스트를 작성하는 방법에 대한 제 팁입니다. 그러나 소프트웨어 엔지니어링에는 좋은 테스트와 나쁜 테스트가 없으며, 오직 요구 사항을 충족하는지 여부만이 존재한다는 점을 명심하세요.

팁 #1. 외부에서 내부로 테스트를 작성하세요. 즉, 현실적인 사용자 관점에서 테스트를 작성해야 한다는 뜻입니다. 최상의 품질 보증과 리팩터링 저항성을 가지려면 e2e 또는 통합 테스트를 작성해야 합니다. 이로 인해 테스트를 실행하는 데 시간이 오래 걸리고 피드백 루프가 늘어날 수 있습니다. 테스트를 서로 독립적으로 만들어 병렬로 실행할 수 있도록 함으로써 이 문제를 해결할 수 있습니다. 원래 테스트 피라미드에서는 많은 e2e 및 통합 테스트가 금지되었습니다. 대신 피라미드에서는 단위 테스트를 많이 작성해야 한다고 말하며, 대부분의 사람들에게 단위는 클래스입니다. 이는 종종 시스템 동작보다는 시스템 구조를 테스트하는 내부 접근 방식으로 이어지는 경우가 많습니다. 기존의 테스트 피라미드에 도전하고 e2e 통합 및 단위 테스트가 여러분의 상황에 얼마나 적합한지 생각해 보세요. 또한 테스트 피라미드에 대한 보다 최근의 대안인 "Honeycomb" 및 "The Testing Trophy"를 고려해보세요.

팁 #2. 테스트할 때 코드를 분리하지 마세요. 그렇게 하면 테스트가 취약해지며 소프트웨어를 리팩토링할 때 도움이 되지 않습니다. 실제 외부 서비스에서만 코드를 격리하세요. 인프라 코드에서 "메인 코드"를 분리하는 데 좋은 출발점이 되는 포트 및 어댑터 패턴(일명 육각형 아키텍처)을 살펴보세요. 스텁을 사용할 때는 인프라 구현을 스텁화하세요. 또한 인프라를 스텁화하지 않고 실제 데이터베이스를 사용하는 것도 고려해 보세요. 도커와 같은 도구를 사용하면 더 이상 그렇게 어렵거나 느리지 않습니다. 또한 테스트 중인 "단위"를 더 많이 분리할수록 테스트 커버리지 보고서의 의미가 떨어집니다. 각 줄을 테스트하더라도 시스템이 전체적으로 작동하는지 알 수 없습니다. 동적으로 타입이 지정되는 언어의 경우 특히 그렇습니다.

팁 #3. 적절한 TDD를 수행하려면 테스트 실패 없이 코드를 변경해서는 안 됩니다. 여기에는 두 가지 이점이 있습니다. 1) 테스트 자체의 테스트입니다. 빨간색이면 테스트 자체가 올바르게 작동한다는 것을 알 수 있습니다. 2) 모든 시나리오를 테스트할 수 있습니다. 물론 코드를 리팩터링할 때는 적용되지 않습니다. 물론 코드를 리팩터링할 때는 적용되지 않습니다. 가끔은 머릿속이 복잡해서 코드를 먼저 작성하고 테스트를 나중에 하기도 하고, 일부러 버그를 도입하여 테스트 스위트가 빨간색으로 바뀌는지 확인하기도 합니다. 두 번째 요점과 관련하여 테스트 커버리지 보고서를 사용하여 테스트되지 않은 코드를 도입했는지 확인할 수 있습니다. 소프트웨어의 공용 인터페이스로 테스트되지 않은 줄에 도달 할 수없는 경우 해당 줄을 삭제하면 됩니다. 100% 테스트 커버리지를 달성하기 위해 스텁/모의 테스트에 의존하지 말고, 현실적인 관점에서 API를 사용하여 이러한 브랜치를 실행하는 방법에 대한 시나리오를 찾아보세요. 이제 커버리지 보고서가 다시 유용해지고 높은 커버리지를 갖는다는 것은 실제로 의미있게 됩니다.

팁 #4. TDD는 테스트를 먼저 작성하는 프로세스가 소프트웨어 설계를 주도할 것이며, 주도해야 한다고 말합니다. 어쩌면 다른 사람에게는 통할지 모르지만 저는 이것을 이해하지 못했습니다. 소프트웨어 아키텍처 101 - 비기능적 요구 사항(NFR)은 아키텍처를 정의합니다(이 주제에 대한 좋은 추천 도서는 실제로 제가 가장 좋아하는 책인 Bass, Clements, Kazman의 "Software Architecture in Practice"입니다). 단위 테스트를 작성할 때는 일반적으로 NFR이 역할을 하지 않습니다.

요약하자면, 제 생각에 자동화 테스트를 작성할 때 가장 중요한 결정은 어떤 트레이드 오프를 택할지 결정하는 것입니다. 높은 수준의 품질 보증, 리팩터링 저항 또는 빠른 피드백 루프를 원하시나요? 오늘날에는 e2e 테스트 또는 통합 테스트를 충분히 빠르게 실행할 수 있는 경우가 많습니다.