단위 테스트 경쟁

고용주는 월 단위 테스트 날 경쟁을합니다. 하루 종일 단위 테스트를 작성하는 데 전념합니다. 분명히 한 달 내내 더 많은 테스트를 수행하지만 이것은 하루 종일입니다. 경쟁의 "우승자"에게는 상이 수여됩니다. 그러나 우리는 승자가 누구인지 판단하기가 어렵다는 것을 알게되었습니다.

각 테스트 사례에 대해 포인트를 할당했습니다. 따라서 이와 같은 단위 테스트를 작성하면 ...

for (int i = 0; i < 100; i++) {
  assertTrue(i*i, square(i));
}

당신은 100 점을 받게 될 것입니다. 분명히 이것은 간단한 예이지만 각 테스트 사례에 "포인트"를 할당 할 때 발생하는 문제를 보여줍니다.

우리는 주로 Java & Javascript 상점입니다. 그래서 메트릭으로 테스트 된 코드 분기 수를 계산하는 것이 좋습니다. 코드 커버리지 도구 (예 : EclEmma)를 통해 테스트 된 브랜치를 쉽게 계산할 수 있습니다. 그러나 Selenium 테스트를 통해이 작업을 수행하고 Javascript 소스 (아이디어)에 대한 코드 적용 범위를 얻는 방법을 확실하지 않습니다.

이 경쟁의 승자를 더 잘 결정할 수있는 방법에 대한 제안이 있습니까?

편집하다

나는 단위 테스트를 작성하는 방법을 알고, 효과적인 단위 테스트를 작성하는 방법을 알고, 무엇을 테스트할지 결정하는 데 도움이 필요하지 않습니다. 나는이 경쟁을 통제 할 수 없다. 경쟁은 계속 될 것이다. 그래서 나는 더 나은 결과를 내기 위해 약간의 입력을 추가하거나 테스트 게임을 계속합니다 (예, 게임합니다. 물론 게임합니다. 당첨 될 상이 있습니다)

편집하다

여기서 좋은 질문 을 찾는 방법에 대한 유용한 정보가 포함되어 있지만 경쟁을 평가하는 데 유용한 지표는 제공하지 않지만 이 질문 은 분명히 중복되지 않습니다.

이 경쟁의 승자를 더 잘 결정할 수있는 방법에 대한 제안이 있습니까?

나에게 의미있는 유일한 것은 투표하는 것입니다-모든 개발자는 다른 모든 개발자의 테스트에 자신의 것을 제외하고 몇 가지 포인트를 할당 할 수 있습니다. 어쩌면 테스트에서 3 점은 "가장 효과적인"1 점, 2 점은 1 점, 3 점은 1 점이라고 생각합니다. 가장 많은 점수를 얻은 테스트가 이깁니다. 누가 특정 테스트를했는지 미리 몰라도 포인트 할당이 완료되면 더 나은 결과를 얻을 수 있습니다.

보너스로 모든 테스트 피어를 검토하게됩니다.

따라서 이와 같은 단위 테스트를 작성하면 ...

for (int i = 0; i < 100; i++) {
 assertTrue(i*i, square(i));
}

당신은 100 점을 받게 될 것입니다.

루프 내 어설 션은 거의 의미가 없으며 여러 어설 션 (특히 루프 또는 맵 형태)으로 테스트하기가 어렵 기 때문에이 사람에게 0 점을 줄 것입니다 (테스트가 실제로 관련있는 것을 테스트하는 경우에도).

문제는 본질적으로 [쉬운] 속일 수없는 메트릭을 갖는 것입니다. 어설 션 수를 기반으로하는 메트릭은 작성된 LOC 당 개발자에게 지불하는 것과 정확히 동일합니다. LOC (Pay-by-LOC)와 마찬가지로 코드를 유지 관리하는 것이 거대하고 불가능하기 때문에 실제 회사 정책은 쓸모없고 잘못 작성된 테스트로 이어집니다.

어설 션 수와 관련이없는 경우 테스트 수도 관련이 없습니다. 이러한 상황에 대해 상상할 수있는 많은 메트릭 (결합 된 메트릭 포함)의 경우도 마찬가지입니다.

이상적으로는 체계적인 접근 방식을 적용하는 것입니다. 실제로 이것은 대부분의 소프트웨어 개발 회사에서 거의 작동하지 않습니다. 그래서 나는 몇 가지 다른 것을 제안 할 수 있습니다 :

1. 테스트를 위해 쌍 검토 를 사용 하고 분당 WTF 수 와 비슷한 것을 갖습니다 .

2. 이러한 테스트가 시간이 지남에 따라 버그 수에 미치는 영향을 측정 하십시오 . 여기에는 몇 가지 이점이 있습니다.

   • 공정 해 보인다
   • 버그 보고서와 그 운명에 대한 충분한 데이터를 수집하면 실제로 측정 할 수 있습니다.
   • 실제로 가치가 있습니다!

3. 분기 적용 범위를 사용 하되 다른 측정 항목 및 검토와 결합하십시오. 지점 적용 범위에는 이점이 있지만 더 나은 성적을 얻기 위해 CRUD 코드를 테스트하는 것이 개발자의 시간을 보내는 가장 좋은 방법은 아닙니다.

4. 현재 시행하고자하는 지표가 무엇인지 함께 결정하십시오 (이러한 결정은 환영받지 못하거나 일부 회사 및 팀에서는 불가능할 수도 있습니다). 측정 항목을 자주 검토하고 변경하여 관련성이 높은 측정 항목을 선택하고 모든 사람이 측정 대상과 방법을 명확하게 이해하도록합니다.

직원들이 버그를 찾고 더 큰 코드 범위를 달성하고 더 많은 테스트를 받도록 인센티브를 제공하기 위해이 단위 테스트 날을 조직한다고 가정합니다.

따라서 우승자는 가장 많은 버그를 발견 한 개발자이거나 테스트에서 코드 범위가 가장 많이 증가한 개발자 여야한다는 것이 합리적이라고 생각합니다.

문제 / 버그 / 결함 추적 시스템에서 새 항목이 열리면 테스트를 통해 점수를 얻습니다. 해당 이슈에 대해 이미 열려있는 항목은 포함되지 않습니다. 또한 주석에서 제안한대로 사용자 코드의 버그는 포함되지 않습니다. 다른 사람의 코드에있는 버그만 계산해야합니다. 불행히도,이 방법은 모든 실패한 테스트가 탐지되고 해당 문제가 열릴 때까지 며칠이 걸릴 수 있기 때문에 즉각적인 만족감을 제공하지 않습니다. 또한 항상 작동하지 않을 수도 있습니다. 시스템이 성숙함에 따라 테스트를 추가하여 버그를 발견하는 것은 매우 드물게 시작될 수 있습니다.

코드 범위의 증가는 새로운 테스트로 표현 된 개선의 객관적인 측정을 제공 할 수 있습니다. 먼저, 총 코드 적용 범위는 대회 전날 기록되어야합니다. 그런 다음 각 개발자는 다른 개발자가 작성한 테스트로 인한 코드 범위의 증가를 고려하지 않고 테스트만으로 발생하는 코드 범위의 증가를 어떻게 든 표시해야합니다. 즉, 누군가의 테스트가 확정되기 전에 각 개발자의 컴퓨터로 가서 새로운 코드 적용 범위를 기록 할 심판이 필요할 것입니다.

또한 코드 적용 범위를 고려하면 문제에서 제공 한 예제와 같은 바보 같은 일을하는 대신 실제 테스트를 작성하는 사람들에게 공정한 보상이 제공됩니다.