테스트를 증거로 사용하세요

요구사항에서 시작하세요

테스트는 특정 주장의 증거입니다. 테스트 실행이 성공해도 소프트웨어의 모든 속성이 입증되지는 않습니다. 테스트를 요청하기 전에 중요한 동작과 각 검사가 탐지할 결함을 정하세요.

가상의 조직 데이터 내보내기에서는 데이터 격리가 주요 요구사항입니다. A 조직의 사용자가 B 조직의 레코드를 받아서는 안 됩니다. 다운로드 성공만 확인하는 테스트는 이 요구사항을 입증하지 않습니다.

에이전트에게 요구사항과 검증문의 관계를 설명하도록 하세요. 테스트 모음이 커지기 전에 빠진 사례를 찾기 쉬워집니다.

단위 테스트는 작은 변환을 빠르게 확인할 수 있습니다. 통합 테스트는 구성요소가 함께 작동하는 방식을 확인합니다. 종단 간 테스트는 배포된 애플리케이션이나 대표 환경에서 중요한 사용자 절차를 확인할 수 있습니다.

필요한 증거를 제공하는 가장 좁은 범위를 사용하세요. 포맷터의 모든 입력에 전체 브라우저 테스트가 필요하지는 않습니다. 인가 경계에는 실제 라우트와 데이터 접근 경로가 필요할 수 있습니다. 중요한 브라우저 상호작용에는 렌더링된 인터페이스의 증거가 필요합니다.

모든 시스템에 맞는 테스트 유형의 고정 비율은 없습니다. 탐지해야 할 실패와 검사 유지 비용에 따라 선택하세요.

에이전트는 같은 오해를 바탕으로 구현과 테스트를 작성할 수 있습니다. 둘이 일치해도 요구사항은 충족되지 않을 수 있습니다.

구현이 요청에서 받은 조직 ID로 레코드를 필터링한다고 가정해 보세요. 테스트는 로그인한 사용자와 요청에 같은 ID를 씁니다. 테스트는 통과합니다. 빠진 사례는 다른 조직의 ID를 요청하는 사용자입니다.

실제로 신뢰하는 ID와 인가 경로로 그 사례를 추가하세요. 항상 “허용”을 반환하는 모의 함수는 테넌트 격리를 입증할 수 없습니다. 인가가 성공한 이후의 동작만 보여 줍니다.

알려진 결함은 격리된 브랜치에서 결함이 있는 버전에 새 회귀 테스트를 실행하세요. 의도한 이유로 실패하는지 확인하세요. 그다음 수정을 적용하고 다시 실행하세요.

테스트 데이터를 불러오지 못해 실패한 테스트는 아직 업무 동작의 증거가 아닙니다. 종료 코드만 보지 말고 실패 내용을 살펴보세요.

범위가 넓은 변경에서는 변이 테스트로 선택한 코드 변경이 테스트 실패를 유발하는지 평가할 수 있습니다. 비용이 들며 요구사항 검토를 대신하지는 않습니다. 추가 증거가 중요한 결정을 돕는 곳에 사용하세요.

최종 리비전에서 관련 검사를 실행하세요. 건너뛴 검사와 이유를 기록하세요. 검토 수정 후에는 이전 커밋의 결과가 더 이상 적용되지 않을 수 있습니다.

테스트를 이해하기 쉽게 유지하세요. 중요한 조건을 숨기는 큰 도우미보다 명시적인 설정과 검증문을 쓰세요. 다른 실패를 탐지하지 않으면서 유지 비용만 더하는 중복 검사는 제거하세요.

검토자는 테스트가 무엇을 입증하고 무엇이 불확실한지 설명할 수 있어야 합니다. 이 설명이 많은 테스트 수보다 유용합니다.