단위 테스트를 빠르게 수행하려면 어떻게해야합니까?

우리는 프로젝트에서 거의 천 번의 테스트를 받았으며 사람들은 체크인하는 데 시간이 오래 걸리기 때문에 테스트를 중단하는 것을 중단했습니다. 기껏해야 변경 한 코드와 관련된 테스트를 실행하고 최악의 경우 테스트하지 않고 간단히 체크인합니다.

이 문제는 솔루션이 120 개의 프로젝트로 증가했기 때문에 (우리는 일반적으로 훨씬 더 작은 프로젝트를 수행하며 TDD를 올바르게 수행하는 것은 두 번째 일뿐입니다) 빌드 + 테스트 시간은 약 2-3 분으로 증가했기 때문입니다 더 작은 기계에.

테스트 실행 시간을 어떻게 줄이나요? 기술이 있습니까? 더 가짜? 덜 가짜? 모든 테스트를 실행할 때 더 큰 통합 테스트가 자동으로 실행되지 않아야할까요?

편집 : 여러 답변에 대한 응답으로 이미 CI와 빌드 서버를 사용하고 있습니다. 이것이 테스트 실패를 아는 방법입니다. 문제 (실제로 증상)는 실패한 빌드에 대한 메시지가 계속 표시된다는 것입니다. 부분 테스트를 실행하는 것은 대부분의 사람들이하는 것이지만 전부는 아닙니다. 그리고 테스트에 관해서는, 그들은 실제로 꽤 잘 만들어졌으며, 모든 것에 가짜를 사용하고 IO는 전혀 없습니다.

가능한 해결책은 테스트 시스템을 개발 머신에서 git , svn 등 의 버전 제어 소프트웨어를 사용하여 지속적인 통합 설정 ( 예 : Jenkins ) 으로 옮기는 것 입니다.

새 코드를 작성해야하는 경우 지정된 개발자는 저장소에서 수행하는 모든 작업에 대한 분기를 작성합니다. 모든 작업은이 브랜치에서 수행되며 메인 코드를 손상시키지 않고 언제든지 브랜치에 대한 변경 사항을 커밋 할 수 있습니다.

지정된 기능, 버그 수정 또는 기타 작업이 완료되면 모든 단위 테스트가 실행되는 분기를 트렁크로 다시 병합 할 수 있습니다 (또는 원하는 경우). 테스트가 실패하면 병합이 거부되고 개발자에게 통지되어 오류를 해결할 수 있습니다.

커밋이 수행 될 때 CI 서버가 각 기능 분기에서 단위 테스트를 실행하도록 할 수도 있습니다. 이런 식으로 개발자는 일부 변경을 수행하고 코드를 커밋하며 서버가 추가 변경 또는 다른 프로젝트를 계속 진행하면서 백그라운드에서 테스트를 실행할 수 있습니다.

이러한 설정을 수행하는 한 가지 방법에 대한 훌륭한 안내서는 여기에서 찾을 수 있습니다 (git 특정이지만 다른 버전 제어 시스템에서는 작동해야 함). http://nvie.com/posts/a-successful-git-branching-model/

단위 테스트의 대부분은 각각 10 밀리 초 미만이어야합니다. '거의 수천 번의 테스트'를하는 것은 아무것도 아니며 실행하는 데 몇 초가 걸릴 수 있습니다.

그렇지 않은 경우 , 코드에 필요한 경우가 아니라면, 고도로 결합 된 통합 테스트 작성을 중단 하고 올바른 분리 테스트 및 가짜 / 모의 / 스텁 등의 적절한 사용으로 시작하는 좋은 단위 테스트 작성을 시작해야합니다. 이 커플 링은 테스트 품질과 테스트 시간에도 영향을 미치므로 테스트 실행 시간을 줄이는 것만이 아닙니다.

비슷한 문제를 해결하기 위해 사용한 몇 가지 방법이 있습니다.

1. 실행 시간을 확인하고 가장 느린 테스트를 모두 찾은 다음 실행하는 데 시간이 많이 걸리는 이유 를 분석하십시오 .
2. 100 개의 프로젝트가 있으며 매번 빌드하고 테스트 할 필요가 없습니까? 야간 빌드에서만 모든 단위 테스트를 실행할 수 있습니까? 매일 사용하기 위해 여러 개의 '빠른'빌드 구성을 작성하십시오 . CI 서버는 현재 개발 프로세스의 '핫'부분과 관련된 제한된 단위 테스트 프로젝트 만 수행합니다 .
3. 가능한 모든 것을 모의하고 격리하고 가능할 때마다 디스크 / 네트워크 I / O를 피하십시오
4. 이러한 작업을 분리 할 수없는 경우 통합 테스트가있을 수 있습니까? 야간 빌드에만 통합 테스트를 예약 할 수 있습니까?
5. 인스턴스 / 자원에 대한 참조를 유지하고 메모리를 소비하는 모든 단일 싱글 톤을 확인하면 모든 테스트를 실행하는 동안 성능이 저하 될 수 있습니다.

또한 다음 도구를 사용하여 생활을 쉽게하고 테스트를 더 빠르게 실행할 수 있습니다.

1. 게이트 된 커밋 일부 CI 서버는 소스 리포지토리에 코드를 커밋하기 전에 빌드 및 테스트를 수행하도록 구성 할 수 있습니다. 누군가가 모든 테스트를 미리 실행하지 않고 코드를 커밋하면 실패한 테스트도 포함되며 거부되어 다시 작성자에게 반환됩니다.
2. 여러 시스템 또는 프로세스를 사용하여 병렬로 테스트를 실행하도록 CI 서버 를 구성하십시오 . 예는 pnunit여러 노드가있는 CI 구성입니다.
3. 개발자 를 위한 지속적인 테스트 플러그인 . 코드 작성 중에 모든 테스트를 자동으로 실행합니다.

0. 프로그래머의 말을 듣습니다.

테스트를 실행하지 않는 경우 비용 (테스트 실행 대기, 잘못된 실패 처리)이 값 (버그를 바로 잡기)보다 크다는 것을 의미합니다. 비용을 줄이고 가치를 높이면 사람들은 항상 테스트를 실시합니다.

1. 테스트를 100 % 신뢰할 수있게하십시오.

위음성 검사에 실패한 테스트가있는 경우 즉시 처리하십시오. 100 % 신뢰성을 보장하는 데 필요한 모든 것을 수정하고 변경하고 제거하십시오. (신뢰할 수는 있지만 여전히 유용한 테스트를 별도로 수행 할 수는 있지만 테스트의 주요 내용은 신뢰할 수 있어야합니다.)

2. 모든 테스트가 항상 통과하도록 시스템을 변경하십시오.

지속적인 통합 시스템을 사용하여 전달 커밋 만 주 / 공식 / 릴리스 / 무엇이든 브랜치에 병합되도록합니다.

3. 문화를 100 % 합격 시험 가치로 변경하십시오.

100 %의 테스트가 통과 될 때까지 작업이 "완료"되지 않고 주 / 공식 / 릴리스 / 어떤 지점으로 병합되었는지에 대한 교훈을 가르치십시오.

4. 테스트를 빠르게하십시오.

테스트가 1 초 걸리는 프로젝트와 하루 종일 걸리는 프로젝트에서 일했습니다. 테스트 실행 시간과 생산성 간에는 강한 상관 관계가 있습니다.

테스트 실행 시간이 길수록 실행할 빈도가 줄어 듭니다. 즉, 변경 사항에 대한 피드백을받지 않고도 더 오래 갈 수 있습니다. 또한 커밋 사이에 더 오래 갈 것임을 의미합니다. 더 자주 커밋하는 것은 병합하기 쉬운 작은 단계를 의미합니다. 커밋 히스토리를 따르는 것이 더 쉽다; 역사에서 버그를 찾는 것이 더 쉽다; 롤백도 쉽습니다.

컴파일 할 때마다 자동으로 실행되는 것을 신경 쓰지 않을 정도로 빠르게 실행되는 테스트를 상상해보십시오.

테스트를 빠르게하는 것은 어려울 수 있습니다 (OP가 요구 한 것입니다). 디커플링 이 핵심입니다. 목신 / 가짜는 괜찮지 만 리팩토링을 통해 모의 / 가짜를 불필요하게 만들면 더 잘 할 수 있다고 생각합니다. http://arlobelshee.com/post/the-no-mocks-book으로 시작하는 Arlo Belshee의 블로그를 참조하십시오 .

5. 테스트를 유용하게 만듭니다.

나사를 조일 때 테스트가 실패하지 않으면 요점이 무엇입니까? 자신이 만들 가능성이 높은 버그를 잡아낼 테스트를 작성하도록 가르친다. 이것은 그 자체의 기술이며 많은 관심을 기울일 것입니다.

단위 테스트에는 몇 분이면됩니다. 그러나 3 가지 주요 테스트 유형이 있습니다.

1. 단위 테스트-프로젝트의 나머지 부분과 독립적으로 각 "단위"(클래스 또는 방법)를 테스트합니다.
2. 통합 테스트-일반적으로 프로그램을 호출하여 프로젝트 전체를 테스트합니다. 내가 본 일부 프로젝트는 이것을 회귀 테스트와 결합합니다. 단위 테스트보다 조롱이 훨씬 적습니다.
3. 회귀 테스트-테스트 스위트는 최종 사용자이므로 완료된 프로젝트를 전체적으로 테스트합니다. 콘솔 응용 프로그램이있는 경우 콘솔을 사용하여 프로그램을 실행하고 테스트합니다. 내부적으로 이러한 테스트에 노출시키지 않으며 프로그램의 모든 최종 사용자는 이론적으로는 회귀 테스트 스위트를 실행할 수 있어야합니다.

속도 순서대로 나열됩니다. 단위 테스트는 빠릅니다. 그들은 모든 버그를 잡을 수는 없지만 프로그램이 제정신임을 확인합니다. 단위 테스트는 3 분 이내에 또는 적절한 하드웨어에서 실행해야합니다. 1000 단위 테스트 만하고 2-3 분이 걸린다고 말합니까? 아마 괜찮을 것입니다.

확인 사항 :

• 단위 테스트와 통합 테스트가 분리되어 있는지 확인하십시오. 통합 테스트는 항상 느려집니다.

• 단위 테스트가 병렬로 실행되고 있는지 확인하십시오. 그들이 진정한 단위 테스트인지 아닌지에 대한 이유는 없습니다

• 단위 테스트가 "종속성이없는"지 확인하십시오. 데이터베이스 나 파일 시스템에 액세스해서는 안됩니다

그 외에는 지금 테스트가 너무 나쁘지 않습니다. 그러나 참고로 Microsoft 팀의 친구 중 한 명이 적절한 하드웨어에서 2 분 이내에 실행되는 4,000 단위 테스트를했습니다 (복잡한 프로젝트입니다). 빠른 단위 테스트가 가능합니다. 의존성을 제거하고 (필요한만큼만 조롱하는) 속도를 얻는 것이 가장 중요합니다.

PSP (Personal Software Process) 에 대해 개발자를 교육하여 더 많은 훈련을 통해 성능을 이해하고 개선하도록 도와줍니다. 코드 작성은 키보드에서 손가락을 두드리는 것과 관련이 없으며 나중에 컴파일 및 체크인 버튼을 누릅니다.

PSP는 코드를 컴파일하는 데 많은 시간이 걸리는 프로세스 (메인 프레임에서 몇 시간 / 일이되어 모든 사람이 컴파일러를 공유해야 함)였던 과거에 매우 인기가있었습니다. 그러나 개인용 워크 스테이션이 더욱 강력 해지면 우리 모두 프로세스를 수용하게되었습니다.

1. 생각없이 코드를 입력하십시오
2. 빌드 / 컴파일 히트
3. 구문을 수정하여 컴파일하십시오.
4. 실제로 작성한 내용이 맞는지 테스트를 실행하십시오.

입력하기 전에 생각한 다음 입력 한 후에 작성한 내용을 검토하면 빌드 및 테스트 스위트를 실행하기 전에 오류 수를 줄일 수 있습니다. 빌드를 하루에 50 번 누르지 말고 한두 번 정도 누르는 법을 배우면 빌드 및 테스트 시간이 몇 분 더 걸리는 것이 더 중요합니다.

한 가지 가능한 방법 : 솔루션을 분할하십시오. 솔루션에 100 개의 프로젝트가있는 경우 관리하기가 어렵습니다. 두 프로젝트 (A와 B)가 다른 프로젝트 (Lib와 같은)의 공통 코드를 사용한다고해서 동일한 솔루션에 있어야한다는 의미는 아닙니다.

대신 프로젝트 A 및 Lib을 사용하여 솔루션 A를 작성하고 프로젝트 B 및 Lib을 사용하여 솔루션 B를 작성할 수도 있습니다.

나는 비슷한 상황에 처해있다. 서버와의 통신을 테스트하는 단위 테스트가 있습니다. 시간 초과, 연결 취소 등으로 동작을 테스트하고 있습니다. 전체 테스트 세트는 7 분 동안 실행됩니다.

7 분은 비교적 짧은 시간이지만 매번 커밋하기 전에해야 할 일은 아닙니다.

또한 자동화 된 UI 테스트 세트가 있으며 실행 시간은 2 시간입니다. 컴퓨터에서 매일 실행하고 싶은 것이 아닙니다.

그래서 뭐 할까?

1. 테스트 변경은 일반적으로 효과적이지 않습니다.
2. 커밋하기 전에 관련 테스트 만 실행하십시오.
3. 빌드 서버에서 매일 (또는 하루에 여러 번) 모든 테스트를 실행하십시오. 또한 멋진 코드 적용 범위 및 코드 분석 보고서를 생성 할 수 있습니다.

중요한 것은 버그를 찾는 것이 중요하기 때문에 모든 테스트를 자주 실행해야한다는 것입니다. 그러나 커밋 전에 찾을 필요는 없습니다.

문제에 대한 설명이 코드베이스에 대한 철저한 통찰력을 제공하지는 않지만 문제가 두 가지라고 안전하게 말할 수 있다고 생각합니다.

올바른 테스트 작성법을 배우십시오.

거의 천 번의 테스트가 있고 120 개의 프로젝트가 있다고 말합니다. 해당 프로젝트의 최대 절반이 테스트 프로젝트라고 가정하면 1000 개의 테스트에서 60 개의 프로덕션 코드 프로젝트가 있습니다. 그것은 당신에게 약 16-17 테스트 홍보를 제공합니다. 계획!!!

그것은 아마도 프로덕션 시스템에서 약 1-2 클래스를 다루어야 할 테스트의 양일 것입니다. 따라서 각 프로젝트에 1-2 개의 클래스 만있는 경우 (이 경우 프로젝트 구조가 너무 세분화 됨) 테스트가 너무 크면 너무 많은 근거를 포함합니다. 이것이 TDD를 올바르게 수행하는 첫 번째 프로젝트라고 말합니다. 예를 들어, 제시 한 숫자는 이것이 사실이 아님을 나타내며 TDD 속성을 수행하지 않습니다.

올바른 테스트 작성법을 배워야합니다. 이는 아마도 코드를 처음에 테스트 할 수있게하는 방법을 배워야한다는 것을 의미합니다. 팀 내에서 그렇게 할 수있는 경험을 찾을 수 없다면, 외부에서 도움을받는 것이 좋습니다. 예를 들어 2-3 개월 동안 팀에서 테스트 가능한 코드 작성을 배우는 데 도움이되는 한두 명의 컨설턴트의 형태입니다. 최소 단위 테스트.

이에 비해 현재 작업중인 .NET 프로젝트에서 10 초 이내에 약 500 개의 단위 테스트를 실행할 수 있습니다 (고사양 시스템에서는 측정되지 않음). 이것이 당신의 인물이라면, 당신은 이것을 자주 로컬로 실행하는 것을 두려워하지 않을 것입니다.

프로젝트 구조를 관리하는 방법을 배웁니다.

솔루션을 120 개의 프로젝트로 나누었습니다. 그것은 내 표준에 의해 엄청난 양의 프로젝트입니다.

따라서 실제로 그러한 양의 프로젝트를 보유하는 것이 합리적이라면 (그렇지 않은 느낌이 들지만 귀하의 질문에이를 판단하기에 충분한 정보를 제공하지 못하는 경우) 프로젝트를 작은 구성 요소로 나눌 필요가 있습니다. 별도로 빌드, 버전 관리 및 배포 할 수 있습니다. 따라서 개발자는 테스트 스위트 단위를 실행할 때 현재 작업중인 구성 요소와 관련된 테스트 만 실행하면됩니다. 빌드 서버는 모든 것이 올바르게 통합되었는지 확인해야합니다.

그러나 여러 구성 요소로 프로젝트를 분할하고 개별적으로 빌드하고 버전을 지정하면 배포 할 때 경험이 매우 성숙한 개발 팀이 필요합니다.

그러나 어쨌든 프로젝트 구조에 대해 무언가를해야합니다. 프로젝트를 별도의 구성 요소로 분할하거나 프로젝트 병합을 시작하십시오.

정말로 120 개의 프로젝트가 필요한지 자문 해보십시오.

ps NCrunch를 확인하고 싶을 수도 있습니다. 백그라운드에서 테스트를 자동으로 실행하는 Visual Studio 플러그인입니다.

JUnit 테스트는 일반적으로 빠르지 만 일부는 단순히 흥분하는 데 시간이 걸립니다.

예를 들어, 데이터베이스 테스트는 일반적으로 초기화 및 완료에 몇 시간이 걸립니다.

수백 개의 테스트가있는 경우 테스트 속도가 빠르더라도 숫자 때문에 실행하는 데 많은 시간이 필요합니다.

수행 할 수있는 작업은 다음과 같습니다.

1) 중요한 테스트를 식별하십시오. 라이브러리의 가장 중요한 부분과 변경 후 실패 할 가능성이 가장 큰 부분. 컴파일 할 때는 항상 해당 테스트 만 실행해야합니다. 일부 코드가 자주 손상되는 경우, 실행하는 데 시간이 오래 걸리더라도 테스트가 필수적이어야하지만, 소프트웨어의 일부에서 문제가 발생하지 않은 경우 각 빌드에서 테스트를 건너 뛸 수 있습니다.

2) 백그라운드에서 모든 테스트를 실행할 연속 통합 서버를 준비하십시오. 매 시간마다 빌드하거나 모든 커밋 후에 빌드하기로 결정하는 것은 당신에게 달려 있습니다 (두 번째는 커밋이 문제를 일으킨 커밋을 자동으로 감지하려는 경우에만 의미가 있습니다).

내가 본 문제 :

a) 테스트 요소를 구축하기 위해 IOC 사용. 컨테이너를 제거하여 70 초-> 7 초

b) 모든 수업을 조롱하지는 않습니다. 단위 테스트를 단일 요소로 유지하십시오. 몇 가지 수업을 통해 테스트가 진행되는 것을 보았습니다. 이것들은 단위 테스트가 아니며 훨씬 더 깨질 수 있습니다.

c) 무슨 일이 있었는지 알아보기 위해 프로필을 작성하십시오. 생성자가 내가 필요로하지 않는 물건을 만들고 있다는 것을 알았으므로 현지화하고 런타임을 줄였습니다.

d) 프로필. 아마도 코드가 그렇게 좋지 않고 검토를 통해 효율성을 얻을 수 있습니다.

e) 종속성을 제거하십시오. 실행 파일을 작게 유지하면로드 시간이 줄어 듭니다. 인터페이스 라이브러리 및 IOC 컨테이너를 사용하여 최종 솔루션을 실행하지만 기본 테스트 프로젝트에는 인터페이스 라이브러리 만 정의해야합니다. 이렇게하면 분리가 보장되고 테스트가 더 쉬워지며 테스트 풋 프린트가 더 작아집니다.

나는 당신의 고통을 느낍니다. 그리고 빌드 속도를 많이 향상시킬 수있는 여러 곳에 왔습니다. 그러나 내가 추천하는 것은 빌드가 가장 오래 걸리는 위치를 파악하기 위해 세부적 으로 측정 하는 것입니다. 예를 들어, 약 30 분 정도의 프로젝트로 빌드하는 데 1 분 이상이 걸립니다. 그러나 그것은 그림의 일부일뿐입니다. 또한 어떤 프로젝트를 구축하는 데 가장 오랜 시간이 걸리는지 알고있어 내 노력에 집중할 수 있습니다.

빌드 타임을 먹는 것들 :

• 패키지 다운로드 (C # 용 덩어리, Java 용 Maven, Ruby 용 Gem 등)
• 파일 시스템에서 대량의 파일 복사 (예 : GDAL 지원 파일)
• 데이터베이스에 대한 연결 열기 (일부 연결 당 1 초 이상이 소요됨)
• 리플렉션 기반 코드
• 자동 생성 코드
• 예외를 사용하여 프로그램 흐름 제어

모의 라이브러리는 리플렉션을 사용하거나 바이트 코드 라이브러리를 사용하여 코드를 삽입하여 모의 객체를 생성합니다. 매우 편리하지만 테스트 시간이 많이 걸립니다. 테스트에서 루프 내부에 모의 객체를 생성하는 경우 단위 테스트에 상당한 시간이 추가 될 수 있습니다.

문제를 해결하는 방법이 있습니다.

• 데이터베이스와 관련된 테스트를 통합으로 이동 (즉, CI 빌드 서버에서만)
• 테스트에서 루프에서 모의 ​​객체를 만들지 마십시오. 실제로 테스트에서 루프를 피하십시오. 이 경우 매개 변수화 된 테스트를 사용하여 동일한 결과를 얻을 수 있습니다.
• 대규모 솔루션을 별도의 솔루션으로 분할 고려

솔루션에 100 개가 넘는 프로젝트가 포함 된 경우 라이브러리 코드, 테스트 및 응용 프로그램 코드의 조합이 있습니다. 각 라이브러리는 관련 테스트가있는 자체 솔루션 일 수 있습니다. Jet Brains Team City 는 Nuget 서버의 두 배인 CI 빌드 서버이며 이것이 유일한 서버는 아니라고 확신합니다. 따라서 자주 변경되지 않는 라이브러리를 자체 솔루션 / 프로젝트로 이동하고 Nuget을 사용하여 응용 프로그램 코드의 종속성을 해결할 수있는 유연성을 제공합니다. 솔루션이 작을수록 라이브러리를 신속하고 신속하게 변경하고 기본 솔루션의 이점을 누릴 수 있습니다.

테스트 환경을 어디에서나 실행할 수 있습니까? 가능하다면 클라우드 컴퓨팅을 사용하여 테스트를 실행하십시오. N 개의 가상 머신간에 테스트를 분할하십시오. 단일 시스템에서 테스트를 실행하는 시간이 T1 초인 경우이를 분할하는 시간 T2는 T2 = T1 / N에 근접 할 수 있습니다. (각 테스트 사례가 동일한 시간이 걸린다고 가정합니다.) 또한 VM을 사용할 때만 비용을 지불하면됩니다. 따라서 24/7 어딘가에 실험실에 앉아있는 테스트 머신이 없습니다. (내가 일하는 곳 에서이 작업을 수행하고 싶지만 특정 하드웨어에 묶여 있습니다. VM은 없습니다.)