더욱 간단한 테스트 피라미드: 테스트를 최대한 활용하기

InfoQ 홈페이지 기사 더욱 간단한 테스트 피라미드: 테스트를 최대한 활용하기

이 항목은 일본어로 표시됩니다.

2023년 4월 10일 10분 분량의 읽기

~에 의해

타이슨 글래들리

검토자

매트 캠벨

개발자는 자동화된 테스트(단위, 통합, 수용, 구성 요소, 서비스, 종단 간, UI, 데이터베이스, 시스템, 기능 또는 API)를 설명하기 위해 다양한 레이블을 사용합니다. 이러한 각 레이블은 테스트 범위, 테스트에서 수행하는 작업 유형, 테스트 대상 또는 대상의 협력자를 설명하는 등 서로 다른 의미론적 의미를 갖습니다. 우리는 일반적으로 이러한 각 레이블이 의미하는 바에 동의하지 않으며 해당 정의에 대한 논의는 무의미한 경향이 있습니다.

어떤 레이블을 사용할지, 어떻게 정의할지 논쟁하기보다는 두 가지 형용사 중 하나를 사용하여 각 테스트에 레이블을 지정하는 것이 더 도움이 된다는 것을 알았습니다: 느림 또는 빠름. 이러한 레이블은 개발자가 비생산적인 주장 없이 테스트를 객관적으로 분류할 수 있도록 하는 동시에 테스트 모음의 구성을 결정할 때에도 유용할 수 있습니다.

Java를 원하는 방식으로 코딩, 배포 및 확장하세요. Microsoft Azure는 Java 앱, 앱 서버 또는 프레임워크에서 작업하는지 여부에 관계없이 다양한 선택을 통해 워크로드를 지원합니다. 더 알아보기.

테스트 라벨의 선택은 테스트 스위트 구성에 중요한 영향을 미칩니다. 개발자는 이를 사용하여 특정 동작에 대한 테스트를 언제 작성해야 하는지, 어떤 테스트 유형을 작성해야 하는지 파악하고 테스트 도구 모음의 균형을 전체적으로 평가합니다. 이것이 잘못되면 정확한 적용 범위를 제공하지 않거나 허용할 수 없는 비용으로 적용 범위를 제공하는 테스트 모음이 생성됩니다.

특정 프로덕션 코드에 대한 테스트는 언제 작성해야 합니까? 나처럼 익스트림 프로그래밍(XP)이나 테스트 주도 개발(TDD)을 연습하는 개발자들은 이 질문에 "항상"이라고 대답하는 경우가 많습니다. 그러나 모든 코드가 자동으로 테스트되는 것은 아닙니다. 제안된 각 테스트에 대해 먼저 테스트 작성 비용과 이점을 비교해 보세요.

나는 테스트 작성을 옹호하는 것이 아닙니다. 실제로 대부분의 테스트에서 이는 간단한 확인이며 대답은 '예'입니다. 그러나 이 검사는 특히 테스트 실행 속도가 느리거나, 작성 속도가 느리거나, 유지 관리가 어려운 경우에 유용합니다. 이러한 경우에는 스스로에게 몇 가지 질문을 해보세요.

설계 결정 때문에 테스트 비용이 많이 드나요? 테스트를 더 잘 수용할 수 있도록 코드를 리팩토링할 수 있습니까? 테스트는 프로덕션 코드의 첫 번째 소비자입니다. 코드를 테스트하기 쉽게 만들면 사용하기가 더 쉬워지고 코드베이스의 품질이 향상되는 경우가 많습니다.

테스트 접근 방식 때문에 테스트 비용이 많이 드나요? 다른 테스트 접근 방식을 사용하면 이 테스트를 더 쉽게 작성할 수 있습니까? 공동 작업자 대신 가짜 또는 모의와 같은 테스트 더블을 사용하는 것을 고려해보세요. 테스트에 복잡한 설정이 필요한 경우 이를 테스트 간에 재사용할 수 있는 테스트 시나리오로 추출하세요.

테스트 더블을 과도하게 사용하지 않도록 주의하세요. 실제 공동 작업자만큼 신뢰도를 제공하지 않기 때문입니다. 때때로 이러한 신뢰도 하락은 설정 용이성, 테스트 기간 단축 또는 신뢰성 증가의 가치가 있습니다. 그러나 테스트 더블에 너무 많이 의존하면 테스트가 구현과 결합되어 신뢰도가 낮아지고 리팩토링을 방해하는 테스트 모음이 생성될 수 있습니다.

동작이 본질적으로 테스트하기 어렵기 때문에 테스트 비용이 많이 드는가? 그렇다면 테스트 중인 기능의 중요성을 고려하세요. 결제 처리와 관련된 중요한 기능인 경우 테스트는 비용의 가치가 있을 수 있습니다. 디스플레이 로직의 기발한 경우인 경우 테스트 작성 여부를 다시 고려해야 합니다.

테스트가 예측할 수 없게 실패하기 때문에 비용이 많이 드나요? 그렇다면 제거해야 하며, 더 안정적으로 다시 작성하거나 나머지 테스트 모음과 분리하세요. 테스트 스위트가 유용한 피드백을 제공하려면 테스트 실패가 바람직하지 않은 동작을 나타낸다는 것을 확신해야 합니다. 테스트가 필요하고 예측할 수 없다고 판단되면 자주 실행되지 않는 다른 테스트 모음으로 이동하세요.