테스트의 내용과는 달리 무엇을 테스트할지는 모든 팀에서 중요한 질문입니다. 테스트는 최종적인 수단이며, 코드베이스의 여러 부분을 테스트할 우선순위를 정하는 방법을 선택하는 것은 어려울 수 있습니다.
우선순위를 지정하는 가장 좋은 방법은 코드베이스와 팀의 목표를 기반으로 하는 것입니다. 하지만 코드 적용 범위가 많은 소규모 테스트 (예: 단위 테스트와 같이 테스트 피라미드 하단)를 많이 작성하는 데는 시간과 대역폭이 거의 들지 않지만 프로젝트의 전반적인 위험이 반드시 줄어드는 것은 아닙니다.
애플리케이션, 웹사이트 또는 라이브러리의 주요 사용 사례를 고려하여 먼저 테스트할 항목을 선택할 수 있습니다. 예를 들어 사용자 환경을 뒷받침하는 핵심 구성요소인 사이트의 중요한 부분에 관한 구성요소 테스트를 작성할 수 있습니다. 예를 들어 사용자가 시계열 데이터를 업로드하고 관리할 수 있는 사이트의 개발자는 사용자가 이러한 작업을 수행할 수 있는 다양한 방법을 상상하고 테스트해야 합니다.
우선순위를 지정하는 또 다른 접근 방식은 가장 많은 정보를 얻는 것입니다. 코드베이스에 '위험'하거나, 레거시이거나, 잘못 작성된 부하 보유 부분이 있어 팀원 모두가 작업을 좋아하지 않는 경우, 추가로 무시하거나 리팩터링하기 전에 이를 중심으로 테스트를 빌드하여 동작을 더 일관되게 만드는 것이 유용할 수 있습니다. 이미 비난을 받았지만 여전히 데이터 센터가 있는 건물을 위한 발판이라고 생각하면 됩니다.
차원
테스트 피라미드 또는 다른 테스트 형태의 개념을 도입했지만 이러한 테스트는 한 가지 차원의 테스트만 제시하는 경향이 있습니다. 즉, 작은 범위의 간단한 단위 테스트에서 복잡한 광범위한 테스트로 이어지는 라인, 즉 단위 테스트와 통합 테스트, 엔드 투 엔드 테스트 비교를 나타냅니다.
하지만 가능한 테스트 유형의 긴 목록은 복잡성 수준을 나타내는 것이 아니라 테스트 목표 또는 기법을 나타냅니다. 예를 들어 스모크 테스트는 그 자체로 단위 테스트, 엔드 투 엔드 테스트, 기타 테스트일 수 있는 다른 테스트 카테고리이지만 테스터에게 테스트 중인 프로젝트가 유효한 상태임을 전반적으로 확신할 수 있도록 하기 위한 것입니다. 시각적 테스트는 작은 구성요소나 사이트 전체에 적용할 수도 있습니다.
코드베이스에는 고유한 요구사항이 있습니다. 예를 들어 코드베이스에서는 단일 기능에 맞춰 조율하여 제대로 작동하는지 확인하기 위해 다양한 유형의 테스트를 작성하는 것이 훨씬 더 중요할 수 있습니다. 테스트가 필요한 새로운 기능은 단일 구성요소, 기능 또는 접근 방식인 경우가 드물며, 프로젝트에 미치는 영향은 다양한 규모로 광범위하게 분산될 수 있습니다.
테스트 우선순위는 비즈니스 요구사항에 따라 달라질 수도 있습니다. 고도로 기술된 시스템에서는 고유한 알고리즘이 올바르게 실행되는지 확인하기 위해 복잡한 단위 테스트가 필요할 수 있는 반면, 고도의 대화형 도구는 복잡한 터치 입력이 올바른 응답을 유도하는지 확인하기 위해 시각적 테스트 또는 엔드 투 엔드 테스트에 집중할 가능성이 높습니다.
테스트에 대한 접근 방식
규모에 상관없이 코드베이스의 사용 사례를 테스트하는 데 집중해 보세요. 사용자가 프로젝트의 일부를 사용하는 방법을 상상해 보세요. 이는 단일 구성요소, 하위 수준 함수 또는 높은 수준의 엔드 투 엔드 사용 사례를 나타낼 수 있습니다. (테스트가 테스트 중 코드와 원활하게 상호작용할 수 없는 경우, 모든 규모에서 추상화의 결함을 발견할 수도 있습니다.)
각 테스트 사례에는 목표가 명확하게 정의되어 있어야 합니다. 대규모 '포괄적' 테스트는 비 테스트 코드에서처럼 다루기 어려울 수 있습니다.
테스트 기반 개발 지원
테스트 기반 개발(TDD)은 테스트(확장 또는 유형과 직각을 이루는) 테스트의 고유한 접근 방식으로, 적어도 처음에는 실패할 것으로 예상되는 테스트를 작성하는 것이 포함됩니다. 이는 수동 테스트와 자동 테스트 모두에 적용할 수 있습니다. 즉, 달성하려는 목표를 설명하고, 현재 솔루션 또는 코드에서 누락된 부분을 파악하고, 실패한 테스트를 솔루션을 위한 가이드로 사용합니다.
물론 가상의 애플리케이션이나 구성요소를 빌드하기 전에 가능한 모든 시나리오를 테스트하는 것은 유용하지 않습니다. TDD가 그 자리를 차지하며 코드베이스가 복잡해지면 유용할 수 있습니다
TDD는 버그를 수정할 때도 좋은 방법입니다. 버그의 재현 사례를 코드화할 수 있다면 처음에는 실패하게 되는 자동 테스트에 넣을 수 있습니다. 버그를 수정하면 테스트가 통과되어 수동 확인 없이 수정이 완료되었는지 확인할 수 있습니다.
불투명 vs. 투명 상자
이는 시스템의 모든 부분을 테스트하는 방식을 말합니다. 불투명하면 예를 들어 클래스의 내부 인터페이스를 검사하는 대신 클래스의 공개 인터페이스를 사용할 때 내부를 볼 수 없습니다.
특별한 이유가 없다면 불투명한 상자 테스트로 시작하는 것이 좋습니다. 그러면 구성요소 사용 방식에 따라 테스트를 설계하고 내부 기능 작동 방식에 방해되지 않습니다. 코드 경로의 '공개' 인터페이스만 사용하는 경우 (반드시 사용자에게 공개될 필요는 없지만 코드의 다른 부분에 공개될 수 있음) 테스트에서 변경사항을 감지할 수 있다는 점을 알고 해당 코드를 자유롭게 리팩터링하고 개선할 수 있습니다.
'빈 상자' 코드를 더 불투명하게 변환하는 한 가지 방법은 상태를 다른 시스템과 긴밀하게 결합하는 대신 코드 종속 항목의 추상화나 상태 관찰 콜백과 같은 구성 가능한 요소를 도입하는 것입니다. 이렇게 하면 코드가 더 분리되고 '테스트' 버전을 제공할 수 있습니다. 또는 코드가 다른 시스템과 상호작용하는 위치를 모의 처리할 수 있습니다.