하나의 실행 파일에서 모든 단위 테스트 또는 분할?


12

라이브러리와 같이 하나의 소프트웨어에 대한 테스트를 작성할 때 모든 단위 테스트를 하나로 컴파일하거나 여러 실행 파일로 분리 하시겠습니까?

내가 묻는 이유는 현재 CUnit 을 사용하여 작업중 인 라이브러리를 테스트 하기 때문 입니다. 테스트는 별도의 제품군으로 나뉘어 하나의 실행 파일로 컴파일되어 오류에 대한 인쇄 출력이 완성됩니다. 자, 라이브러리에 대한 빌드 시스템은 CMake 자체 테스트 프레임 워크와 함께 제공됩니다 (그 이름에도 불구하고, Cunit의과 거의있다,), CTest . CTest를 사용하면 테스트 역할을하는 실행 파일 목록을 등록 할 수 있습니다.

자동화 된 테스트 실행에 CTest를 사용할지 고민하고 있습니다. 그러나 지금까지 작성한 테스트를 별도의 컴파일 대상으로 분할해야합니다. 그렇지 않으면 선택적으로 테스트를 실행하는 것과 같은 일부 CTest 고급 기능을 실제로 사용할 수 없습니다.

나는 이것이 어떤 도구를 사용 해야하는지, 처리 및 규칙에 관한 질문이라는 것을 알고 있지만, 그 외에도 별도의 도구보다 단일 테스트 실행 파일을 선호하는 다른 이유가 있습니까? 혹은 그 반대로도?


클래스별로 별도의 실행 파일로 분리하십시오. 클래스를 테스트 할 수없고 다른 클래스에서 간접적으로 테스트해야하는 경우가 아니면 각 클래스는 자체 단위 테스트를 가져야합니다.
Brian

1
각각 단위 테스트가있는 수백 개의 클래스가있는 큰 라이브러리가있는 경우 하나 (또는 ​​몇 개의) 큰 이진에 비해 각각에 대해 완전한 이진을 만들면 빌드 시간이 훨씬 길어집니다. 또한 개별 링크 라인이있는 많은 관리 파일이 있습니다.
JBR 윌킨슨

그렇게 크지 않습니다. 20 개 미만의 모듈. 또한 동일한 플래그로 모두 컴파일 할 수 있으므로 CMake는 내 작업에 많은 노력을 기울이지 않고도 Makefile을 생성 할 수 있습니다.
Benjamin Kloster

답변:


5

개별 바이너리에서 자동화 된 테스트를 받거나 적어도 "함께"그룹별로 묶인 다음 간단한 셸 스크립트 (0이 아닌 종료 코드 신호 실패 및 stderr의 출력이 캡처 될 수 있음)에서 호출합니다. 설명을 기록하기 위해). 이런 식으로, 테스트에 대한 유연성을 유지합니다-커맨드 라인에서 직접 개별 테스트를 실행할 수 있고, 원하는 경우 모든 종류의 멋진 스크립트를 만들 수 있으며, 다시 컴파일하지 않고도 적합하다고 생각되는대로 다시 정렬 할 수 있습니다.

그러나 더 중요한 것은 다른 언어로 작성된 테스트를 포함하거나 동일한 실행에서 다른 툴 체인을 사용하는 테스트도 포함 할 수 있다는 것입니다. 예를 들어, 내가 작성한 단위 테스트는 프로젝트의 주요 언어로되어있을 가능성이 높으며 실행은 바이너리를 빌드하고 호출하는 문제입니다. 그러나 나는 또한 데이터베이스를 테스트하고 싶고 SQL 스크립트를 데이터베이스에 직접 공급하고 싶을 것이다. 내 코드에서 정적 코드 분석 도구를 실행하고 싶을 수도 있습니다 (어떤 종류의 린터 인 경우에도). 유효성 검사기를 통해 정적 HTML을 실행하고 싶을 수도 있습니다. grep의심스러운 구성, 코딩 스타일 위반 또는 "적색 플래그"키워드를 확인하기 위해 코드베이스에 명령을 실행할 수 있습니다 . 가능성은 무한합니다. 명령 행에서 실행할 수 있고 "제로 종료 상태는 정상임을 의미합니다"를 준수하면 사용할 수 있습니다.


라이브러리에 대한 파이썬 바인딩을 구현할 계획이기 때문에 언어에 무관심한 논쟁은 매우 좋은 지적입니다. 감사!
Benjamin Kloster

@ tdammers : 특정 테스트 프레임 워크?
JBRWilkinson

@JBRWilkinson : 30 줄짜리 쉘 스크립트. 내가 사용하는 대부분의 언어에는 함수 실행, 결과를 예상 값과 비교 및 ​​일치하지 않는 경우 던지기와 같은 일반적인 테스트 작업을위한 라이브러리가 거의 없습니다. 그러나 명령 행에서 실행 가능하고 종료 상태를 통해 성공 / 실패 신호를 보내는 한 모든 단위 테스트 프레임 워크를 이러한 "메타 시스템"에 쉽게 통합 할 수 있습니다.
tdammers

2

한 응용 프로그램의 단위 테스트 (또는 일반적으로 공유되는 라이브러리 패키지)를위한 라이브러리가 하나 있습니다. 해당 라이브러리 내에서 테스트 픽스처에 대해 테스트중인 객체의 네임 스페이스를 복제하거나 근사하려고합니다 (주로 NUnit을 사용합니다). 이는 .NET에서 각 바이너리를 빌드 할 때 발생하는 오버 헤드가있어 동일한 LOC를 사용하는 10 개 프로젝트 솔루션보다 20 개 프로젝트 솔루션의 빌드 시간을 늘리는 오버 헤드가 있으므로 컴파일을 단순화합니다. 테스트 바이너리는 어쨌든 배포되지 않으므로 테스트 바이너리를 바이너리로 구성하는 것은 사용자 편의를위한 것이며, 일반적으로 YAGNI는 여기 어디에서나 적용됩니다.

이제는 보통 tdammers가 고려해야 할 사항이 없습니다. 내 코드는 사실상 모두 한 언어로되어 있으며 SQL 문자열과 관련된 테스트는 단위 테스트가 아닙니다 (쿼리 생산자가 특정 기준에 따라 예상되는 SQL 문자열을 반환하는지 테스트하지 않는 한) 실제로는 실제 단위 테스트를 수행하지 않습니다 UI (많은 상황에서 단순히 불가능합니다). 또한 빌드 봇 및 IDE 플러그인과 같은 타사 도구에서 잘 받아 들여지는 단위 테스트 라이브러리를 사용하므로 개별 테스트, 부분 스위트 등을 실행하는 데 대한 우려가 최소화됩니다.


1
문화의 문제는 .NET 환경에서 아마도 당신과 같은 이유 일 것입니다.
tdammers
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.