단위 테스트 지침

Question

단위 테스트 지침 및 권장 사항을 어디서 찾을 수 있는지 아는 사람이 있습니까?나는 다음과 같은 유형의 주제를 다루는 것을 갖고 싶습니다(예를 들어):

• 테스트는 애플리케이션 로직과 동일한 프로젝트에 있어야 합니까?
• 내 논리 클래스를 반영하는 테스트 클래스가 있어야 합니까, 아니면 필요하다고 생각되는 만큼만 테스트 클래스가 있어야 합니까?
• 테스트 클래스, 메서드 및 프로젝트의 이름을 어떻게 지정해야 합니까(다른 프로젝트에 속하는 경우)
• 비공개, 보호 및 내부 메서드를 테스트해야 합니까, 아니면 공개적으로 액세스할 수 있는 메서드만 테스트해야 합니까?
• 단위 테스트와 통합 테스트를 분리해야 합니까?
• 거기에 좋은 100% 테스트 커버리지가 없는 이유는 무엇입니까?

내가 되어야 할 것에 대해 내가 묻고 있지 않은 것은 무엇입니까?

온라인 리소스가 가장 좋습니다.

Answer 1

나는 추천하고 싶다 켄트 벡의 TDD에 대해 예약하세요.

또한, 당신은에 가야합니다 마틴 파울러의 대지.그는 테스트에 관한 좋은 정보도 많이 가지고 있습니다.

우리는 TDD에 대해 꽤 큰 관심을 갖고 있으므로 그런 관점에서 질문에 대답하겠습니다.

테스트는 애플리케이션 로직과 동일한 프로젝트에 있어야 합니까?

일반적으로 테스트를 동일한 솔루션에 유지하지만 테스트 중인 DLL/프로젝트를 미러링하는 별도의 DLL/프로젝트로 테스트를 나누지만 테스트가 하위 네임스페이스에 있는 네임스페이스를 유지합니다.예:공통/공통.테스트

내 논리 클래스를 반영하는 테스트 클래스가 있어야 합니까, 아니면 필요하다고 생각되는 만큼만 테스트 클래스가 있어야 합니까?

예, 클래스가 생성되기 전에 테스트를 생성해야 하며, 정의에 따라 단일 단위만 격리하여 테스트해야 합니다.따라서 솔루션의 각 클래스에 대한 테스트 클래스가 있어야 합니다.

테스트 클래스, 메서드 및 프로젝트의 이름을 어떻게 지정해야 합니까(다른 프로젝트에 속하는 경우)

나는 동작이 테스트 대상이라는 점을 강조하고 싶기 때문에 일반적으로 SUT 다음에 테스트 클래스 이름을 지정합니다.예를 들어 User 클래스가 있는 경우 테스트 클래스 이름을 다음과 같이 지정합니다.

public class UserBehavior

예상되는 동작을 설명하기 위해 메서드 이름을 지정해야 합니다.

public void ShouldBeAbleToSetUserFirstName()

프로젝트 이름은 원하는 대로 지정할 수 있지만 일반적으로 테스트 중인 프로젝트가 무엇인지 확실히 알 수 있기를 원합니다.프로젝트 조직에 대한 이전 답변을 참조하세요.

비공개, 보호 및 내부 메서드를 테스트해야 합니까, 아니면 공개적으로 액세스할 수 있는 메서드만 테스트해야 합니까?

마찬가지로 테스트 대상 개체의 제3자 소비자인 것처럼 예상되는 동작을 확인하는 테스트가 필요합니다.내부 구현 세부 사항을 테스트하면 테스트가 불안정해질 것입니다.기존 기능을 손상시킬 염려 없이 자유롭게 리팩터링할 수 있는 테스트를 원합니다.테스트가 구현 세부 사항을 알고 있는 경우 해당 세부 사항이 변경되면 테스트를 변경해야 합니다.

단위 테스트와 통합 테스트를 분리해야 합니까?

예, 단위 테스트는 승인 및 통합 테스트와 격리되어야 합니다.우려사항의 분리는 테스트에도 적용됩니다.

100% 테스트 커버리지를 갖지 못하는 타당한 이유가 있나요?

나는 100% 코드 적용 범위에 매달리지 않을 것입니다.100% 코드 적용 범위는 테스트의 어느 정도 품질을 암시하는 경향이 있지만 이는 신화입니다.끔찍한 테스트를 거쳐도 100% 보장을 받을 수 있습니다.대신 나는 좋은 테스트 우선 사고 방식에 의존할 것입니다.코드 줄을 작성하기 전에 항상 테스트를 작성한다면 100% 적용 범위를 보장하므로 논쟁의 여지가 있습니다.

일반적으로 클래스의 전체 동작 범위를 설명하는 데 초점을 맞추면 걱정할 것이 없습니다.코드 적용 범위를 측정 기준으로 삼으면 게으른 프로그래머는 해당 표시를 충족할 만큼만 작업을 수행할 것이며 여전히 형편없는 테스트를 받게 될 것입니다.대신 테스트도 검토하는 동료 리뷰에 크게 의존하십시오.

Answer 2

좋은 질문입니다.우리는 유기적으로 성장했으며 가장 좋은 방법은 바로 그것이라고 생각합니다."상황에 따라..."라는 부분이 조금 있습니다.

동일한 프로젝트의 "UnitTes"라는 하위 네임스페이스에 테스트를 실행했습니다.

우리의 테스트 클래스는 테스트 대상과 관련하여 테스트 위치를 쉽게 추적할 수 있도록 논리 클래스를 반영합니다.

클래스는 테스트 중인 논리 클래스와 같이 이름이 지정되고, 메서드는 테스트 중인 시나리오에 따라 이름이 지정됩니다.

우리는 공개 및 내부 메서드에 대한 테스트만 작성하며(테스트는 동일한 프로젝트에 있음) 클래스의 95% 적용 범위를 목표로 합니다.

나는 "단위"와 "중간"을 구별하지 않는 것을 선호합니다.어느 것이 어느 것인지 알아내려고 노력하는 데 너무 많은 시간이 소요될 것입니다...저것을 가방에 넣으세요!테스트는 테스트다.

100%는 항상 달성하기가 너무 어렵습니다.우리는 95%를 목표로 하고 있습니다.또한 최종 5%를 얻는 데 걸리는 시간과 실제로 무엇을 얻을지에 대한 수익도 감소합니다.

그것이 우리이고 환경과 속도에 적합한 것입니다.마일리지가 다를 수 있습니다.당신의 환경과 관련된 성격에 대해 생각해보십시오.

나는 이것에 대해 다른 사람들이 어떻게 말할지 기대하고 있습니다!

Answer 3

Josh의 대답은 옳습니다. 단 한 가지 설명이 필요합니다.

단위 테스트를 통합 및 승인 테스트와 분리하는 이유는 속도 때문입니다.나는 TDD를 사용한다.방금 생성/수정한 코드 줄에 대한 즉각적인 피드백이 필요합니다.전체 통합 및/또는 승인 테스트(실제 디스크, 실제 네트워크, 매우 느리고 예측할 수 없는 외부 시스템에 대한 테스트)를 실행하는 경우에는 이를 얻을 수 없습니다.

광선을 건너지 마십시오.그렇게 하면 나쁜 일이 일어날 것입니다.

Answer 4

꼭 읽어보시길 권합니다 테스트 주도 개발:예를 들어 그리고 테스트 주도 개발:실용적인 가이드 단일 주제에 대한 질문이 너무 많습니다.

Answer 5

마지막 질문과 관련하여 내 경험상 100% 테스트 적용 범위를 주장하지 않는 "타당한" 이유는 특히 대규모 코드 기반에서 마지막 몇 퍼센트 포인트를 얻으려면 불균형한 노력이 필요하기 때문입니다.따라서 수익이 감소하는 지점에 도달하면 시간을 투자할 가치가 있는지 여부를 결정하는 문제입니다.

Answer 6

순서대로:

• 아니요, 일반적으로 별도의 프로젝트에 포함시키는 것이 가장 좋습니다.런타임에 진단을 실행할 수 있기를 원하지 않는 한.
• 이상적인 것은 100% 코드 적용 범위입니다. 즉, 모든 클래스의 모든 루틴에 있는 모든 코드 줄을 의미합니다.
• 나는 ClassnameTest, ClassnameTest.MethodNameTestnumber를 사용합니다.
• 모든 것.
• 단위 테스트가 실패하면 통합 테스트를 실행할 필요가 없으므로 그렇다고 말하고 싶습니다.
• 필드를 설정하고 가져오는 간단한 속성은 테스트할 필요가 없습니다.

Answer 7

테스트는 애플리케이션 로직과 동일한 프로젝트에 있어야 합니까?

때에 따라 다르지.어느 쪽이든 장단점이 있습니다.

이를 하나의 프로젝트에 유지하려면 프로젝트를 배포하기 위한 추가 대역폭, 추가 빌드 시간 및 설치 공간이 필요하며 테스트 코드에 의존하는 프로덕션 로직을 갖는 실수를 저지르기가 더 쉽습니다.

반면에 별도의 프로젝트를 유지하면 개인 메서드/클래스(프로그래밍 언어에 따라 다름)가 포함된 테스트를 작성하기가 더 어려워지고 새로운 개발 환경(예:새로운 개발자가 프로젝트에 참여하면) 더 어려워집니다.

이러한 다양한 비용이 얼마나 중요한지는 프로젝트마다 다르므로 보편적인 대답은 없습니다.

내 논리 클래스를 반영하는 테스트 클래스가 있어야 합니까, 아니면 필요하다고 생각되는 만큼만 테스트 클래스가 있어야 합니까?

아니요.

잘 구성된 테스트 코드를 허용하는 테스트 클래스가 있어야 합니다(예:최소한의 중복, 명확한 의도 등).

테스트 클래스의 논리 클래스를 직접 미러링하는 것의 확실한 이점은 특정 코드 부분에 해당하는 테스트를 쉽게 찾을 수 있다는 것입니다.테스트 코드의 유연성을 제한하지 않고 이 문제를 해결하는 다른 방법이 있습니다.일반적으로 테스트 모듈과 클래스에 대한 간단한 명명 규칙이면 충분합니다.

테스트 클래스, 메서드 및 프로젝트의 이름을 어떻게 지정해야 합니까(다른 프로젝트에 속하는 경우)

다음과 같이 이름을 지정해야 합니다.

• 각 테스트 클래스와 테스트 방법에는 명확한 목적이 있습니다.
• 특정 테스트(또는 특정 단위에 대한 테스트)를 찾는 사람이 쉽게 찾을 수 있도록 합니다.

비공개, 보호 및 내부 메서드를 테스트해야 합니까, 아니면 공개적으로 액세스할 수 있는 메서드만 테스트해야 합니까?

비공개 메서드를 테스트해야 하는 경우가 많습니다.공개 인터페이스를 테스트하는 것만으로도 충분한 자신감을 얻을 수 있는지, 아니면 실제로 테스트하려는 장치가 공개적으로 액세스할 수 없는지에 따라 달라집니다.

단위 테스트와 통합 테스트를 분리해야 합니까?

이는 선택한 테스트 프레임워크에 따라 다릅니다.테스트 프레임워크에 가장 적합한 방법을 선택하고 다음을 수행하세요.

• 코드 조각과 관련된 단위 테스트와 통합 테스트를 모두 쉽게 찾을 수 있습니다.
• 단위 테스트만 실행하는 것은 쉽습니다.
• 통합 테스트만 실행하는 것은 쉽습니다.
• 모든 테스트를 실행하는 것은 쉽습니다.

100% 테스트 커버리지를 갖지 못하는 타당한 이유가 있나요?

그렇습니다. 그럴 만한 이유가 있습니다.엄밀히 말하면 "100% 테스트 적용 범위"는 코드에서 가능한 모든 상황을 실행하고 테스트한다는 의미입니다.이는 거의 모든 프로젝트에서 달성하기가 비실용적입니다.

단순히 "100% 테스트 적용 범위"를 소스 코드의 모든 라인이 어느 시점에서 테스트 스위트에 의해 실행된다는 것을 의미한다면 이는 좋은 목표이지만 때로는 어려운 위치에 몇 라인만 있는 경우도 있습니다. 자동화된 테스트를 통해 도달할 수 있습니다.해당 기능을 주기적으로 수동으로 확인하는 비용이 마지막 5개 회선에 도달하기 위해 왜곡을 겪는 비용보다 적다면 이는 100% 회선 적용 범위를 갖지 않는 좋은 이유입니다.

100% 라인 커버리지를 가져야 한다는 단순한 규칙 대신 개발자가 다음을 발견하도록 권장하십시오. 어느 테스트의 공백을 확인하고 "포함된" 줄 수가 개선되는지 여부에 관계없이 이러한 공백을 수정하는 방법을 찾으세요.즉, 커버된 라인을 측정하면 라인 커버리지가 향상되지만 실제로 원하는 것은 품질 향상입니다.따라서 라인 커버리지는 품질에 대한 매우 조악한 근사치라는 점을 잊지 마십시오.