단위 테스트를 구성하는 가장 좋은 방법은 무엇입니까

우리는 수년에 걸쳐 주요 프로그램에 대해 상당한 수의 단위 테스트를 구축했습니다. 수천 문제는 테스트가 너무 많기 때문에 어떤 테스트를했는지 명확하게 알 수 없다는 것입니다. 테스트에서 약한 부분 (또는 중복 된 부분)을 모르기 때문에 문제가됩니다.

우리의 응용 프로그램은보고 엔진입니다. 따라서 구문 분석을 테스트하는 데 사용되는 템플릿 (모든 테이블 속성을 읽습니까)을 병합하고 데이터를 병합하고 (병합에 올바른 테이블 속성을 유지 한 경우) 최종 페이지의 서식을 지정합니다 (테이블이 페이지에 올바르게 배치됨) ) 및 / 또는 출력 형식 (생성 된 DOCX 파일 임)입니다.

우리가 테스트해야 할 것을 추가하십시오. 표 셀 주위를 채 웁니다 (보고서 디자인에는 Word, Excel 및 PowerPoint를 사용합니다). 셀 내 테이블, 세로 병합 된 셀, 가로로 병합 된 셀, 세로 및 가로로 병합 된 셀, 내부 테이블에 세로 및 가로로 병합 된 셀이있는 테이블이 포함 된 페이지 나누기에서 패딩을 테스트해야합니다. 한 페이지에서 나옵니다.

그 시험은 어떤 범주에 들어가나요? 표 패딩, 페이지 나누기, 중첩 셀, 세로 병합 된 셀, 가로 병합 된 셀 또는 다른 것?

그리고 우리는 어떻게 이러한 범주를 문서화하고, 단위 테스트 등을 명명합니까?

업데이트 : 많은 사람들이 우리가 전체 범위를 가지고 있는지 확인하기 위해 범위 도구를 사용하도록 제안했습니다. 불행히도 버그는 특정 조합으로 인한 경향이 있기 때문에 우리의 경우에는 제한적으로 사용되므로 모든 테스트가 완료되었지만 해당 조합은 아닙니다.

예를 들어, 어제 고객은 템플릿에서 forEach 루프의 끝에서 Word 책갈피를 시작하고 (Word 문서) 다음 forEach 루프의 시작에서 종료했습니다. 이것은 모두 단위 테스트가있는 코드를 사용했지만 북마크를 확장하는 템플릿의 조합이 25 번 시작되고 10 번 끝났다고 생각하지 않았습니다 (두 forEach 루프는 다른 행 수를 가짐).

일반적으로 단위 테스트를 위해 소스 트리를 미러링하는 경향이 있습니다. 따라서 src / lib / fubar가 있으면 fubar에 대한 단위 테스트를 포함하는 test / lib / fubar가 있습니다.

그러나 당신이 묘사하고있는 것은 더 많은 기능 테스트입니다. 이 경우 가능한 모든 조건을 열거 한 다차원 테이블이 있습니다. 그런 다음 테스트가없는 테스트는 의미가 없거나 새로운 테스트가 필요합니다. 물론 테스트 스위트 세트에 넣을 수 있습니다.

가장 일반적인 구조는 src및 test디렉토리 미러 인 것 같습니다 .

src/module/class
test/module/class_test

그러나 내가 본 더 나은 대안 구조가 있습니다.

src/module/class
src/module/class_test

단위 테스트는 테스트하는 클래스를 반영하는 경향이 있으므로 동일한 디렉토리에 배치하면 파일에 훨씬 쉽게 액세스 할 수 있으므로 나란히 작업 할 수 있습니다.

.NET에서는 테스트 프로젝트의 소스 코드에 대한 네임 스페이스 구조를 "Tests.Unit"또는 "Tests.Integration"마스터 네임 스페이스 아래에 미러링하거나 최소한 근사화하는 경향이 있습니다. 모든 단위 테스트는 하나의 프로젝트에서 진행되며 소스 코드의 기본 구조는 프로젝트 내의 폴더로 복제됩니다. 통합 테스트에서도 동일합니다. 따라서 프로젝트에 대한 간단한 솔루션은 다음과 같습니다.

Solution
   MyProduct.Project1 (Project)
      Folder1 (Folder)
         ClassAA (Class def)
         ...
      Folder2
         ClassAB
         ...
      ClassAC
      ...
   MyProduct.Project2
      Folder1
         ClassBA
         ...
      ClassBB
      ...
   ...
   MyProduct.Tests.Unit
      Project1
         Folder1
            ClassAATests
            ClassAATests2 (possibly a different fixture setup)
         Folder2
            ClassABTests
         ClassACTests
      Project2
         Folder1
            ClassBATests
         ClassBBTests
      ...
   MyProduct.Tests.Integration
      Project1 (a folder named similarly to the project)
         Folder1 (replicate the folders/namespaces for that project beneath)
            ClassAATests
         Folder2
            ClassABTests
         ClassACTests
      Project2
         Folder1
            ClassBATests
         ClassBBTests

단위 테스트 프레임 워크로 코딩 된 AAT 또는 AEET의 경우 약간 변경됩니다. 일반적으로 이러한 테스트는 일련의 단계를 반영하여 새로운 사용 사례 또는 사례의 기능을 테스트합니다. 나는 보통 이러한 테스트를 MyProduct.Tests.Acceptance프로젝트에서 각 스토리에 대한 테스트와 함께 개발중인 스토리가 속한 마일스톤 또는 "에픽"스토리로 그룹화하여 구성합니다. 그러나 이는 실제로 통합 통합 테스트 일 뿐이므로 스토리 지향 방식이 아닌보다 객체 지향적 인 방식으로 테스트를 구성하려는 경우 MyProduct.Tests.Acceptance프로젝트 도 필요하지 않습니다 . MyProduct.Tests.Integration테스트중인 최상위 레벨 객체의 범위 에서 em을 던지십시오 .

단위 테스트가 하나의 범주에만있을 이유는 없습니다. 모든 주요 단위 테스트 툴킷 은 특정 범주에 대한 테스트를 번들로 묶는 테스트 스위트 작성을 지원합니다 . 특정 코드 영역이 변경되면 개발자는 먼저 해당 제품군을 실행해야하며 종종 깨진 부분을 확인해야합니다. 테스트가 패딩 및 나누기 및 중첩 과 관련 이있는 경우 반드시 세 가지 스위트 모두에 배치하십시오.

즉, 즉 그들이 작고 충분히 빨리 그들을 실행 가능하다고해야한다, 단위 테스트의 요점은 그들에게 모든 시간을 실행하는 것입니다 말했다 모든 코드를 커밋을 befor. 즉, 테스트가 어떤 범주인지는 중요하지 않으므로 어쨌든 커밋하기 전에 실행해야합니다. 스위트는 어떤 이유로 든 빨리 테스트를 작성할 수없는 경우 사용하는 목발입니다.

적용 범위에 대해서는 테스트를 실행하여 실제로 실행 된 라인의 비율을 알려주는 매우 유용한 적용 범위 도구가 있습니다. 이것은 여전히 ​​어떤 종류의 테스트가 누락되었는지에 대한 명백한 포인터입니다.

명명에 관해서 는 단위 테스트 의 이름 에 노력을 기울이는 데 특별한 가치가 없습니다 . 당신의 시험에서 듣고 싶은 것은 "5235 of 5235 시험 통과"입니다. 테스트가 실패하면 읽는 것이 이름이 아니라 성공 기준을 구현 하는 메시지 와 같은 메시지assert() 입니다. 메시지는 테스트 본문을 읽지 않고 무엇이 잘못되었는지에 대한 정보를 충분히 제공 할 수 있어야합니다. 그 이름은 그것에 비해 중요하지 않습니다.

테스트에 약한 지 여부를 알 수있는 한 가지 방법은 추적 성입니다. 일반적으로 테스트의 경우 적용 범위의 형태를 취합니다.

테스트에서 다루지 않은 코드를 볼 수 있도록 테스트에서 코드의 어떤 부분이 실행되는지 측정하는 것이 목적입니다. "코드의 일부"를 정의하는 것은 사용자 (및 적용 범위 도구)의 책임입니다. 최소한 지점 적용 범위입니다.