테스트 수정이 우선적으로 고려되는 환경을 만들려면 어떻게해야합니까?

저는 중소 기업의 소프트웨어 엔지니어입니다. 우리는 TeamCity에서 상당히 강력한 테스트 플랫폼을 운영하고 있습니다. 체크인 할 때마다 단위 테스트를 수행하고 매일 단위 테스트 / BVT를 실행합니다.

문제는-우리는 많은 부서진 단위 테스트를 가지고 있습니다.

단위 테스트가 지속적으로 중단되고 유지되지 않는 경우 종종 무의미 함을 드러냅니다. 변경으로 인해 회귀가 발생했는지 확인할 수 없으면 단위 테스트 플랫폼의 가치가 대부분 제거됩니다.

나는 좋은 습관의 문화를 만들어 낼 씨앗을 심고 싶습니다-그들이 깨졌을 때 테스트를 고치고 가치있는 것으로보고 다른 작업과 함께 테스트의 고정을 우선시합니다.

나는 뇌물 수수 (구운 제품!)를 시험해 보았습니다. 모두들 그것이 좋은 생각이라고 말하지만, 나는 그것에 대해 아무것도하지 않는 유일한 사람입니다.

다른 사람이 테스트를 수정하도록 권장하고 스프린트 내에서 테스트 수정의 우선 순위를 정하는 가장 좋은 방법은 무엇입니까?

이것에 대해 덜 주관적인 방법이 있다면, 나는 어떤 팁이라도 기꺼이 받아 들일 것이다.

테스트를 수정하지 않고 실제로 아무것도 해제 할 수 없도록하십시오.

1. 테스트가 실패하면 빌드가 실패합니다.
2. 테스트가 무시되면 빌드가 실패합니다.
3. 테스트 범위가 특정 수준 아래로 떨어지면 빌드가 실패합니다. 따라서 테스트를 삭제하여 해결할 수는 없습니다.
4. CI 서버를 사용하여 릴리스 빌드를 수행 하고 서버 빌드 드롭에서 빌드 만 UAT / 스테이징 / 생산 / 무엇으로 승격되도록 허용합니다.

문제는 빌드가 한 번에 약 15 분 이상 중단되고 테스트에 실패 하는 경우 지속적인 통합을 수행하지 않는 것 입니다.

"핵 옵션"은 소스 제어 서버가 빌드를 중단 한 사용자 이외의 사용자의 커밋 / 체크인을 거부하도록하는 것입니다. 당연히 휴일에 갈 경우 관리자는이를 일시적으로 무시할 수 있어야합니다. 그러나 모든 사람이 테스트를 고칠 때까지 팀 전체 가 망가 졌다는 것을 알고 있다면 신속하게 해결할 수 있습니다.

좋은 정책 (자동화 할 때 더 나은)은 15 분의 빌드 실패 후 소스를 마지막으로 알려진 안정적인 커밋으로 되 돌리는 것입니다. 다시 말해, 고칠 수 없거나 빌드 또는 테스트가 중단 된 원인을 모르는 경우 되돌릴 수 있고 해결 될 때까지 로컬에서 작업하십시오. 다른 개발자가 엄지 손가락 을 돌리지 않도록 절대로 그들이 걱정하지 않는 문제.

PS 이미 실패한 테스트가 많으면 CI에서 "트레일 링 임계 값"을 사용할 수 있습니다. 지난 번보다 많은 테스트 실패 가있는 경우에만 빌드가 실패하도록 설정하십시오 . 이는 적용 규칙과 함께 개발자가 계속 작업하기를 원할 경우 테스트 상황을 개선하도록합니다.

PPS 나는 이것이 일부 사람들에게는 극적으로 보일지 모른다는 것을 알고 있지만, 그것은 당신의 문화에 달려 있습니다. 당신은 사람들이 단지 지점에 도착하면 하지 않는 실패 깨진 빌드 또는 테스트를 떠나 (I 가끔 그들을 생각 나게 할 필요가 있지만 우리 팀은 거의 결코 않음), 당신은 규칙의 엄격한 세트를 계속 필요 없어. IMO이지만 깨진 단위 테스트에서는 항상 빌드에 실패해야합니다. 때때로 통합 / 브라우저 테스트가 실패 할 수 있습니다.

실패한 단위 테스트는 문제가 아닙니다. 그것들은 증상 입니다.

실제 문제는 문화에 있습니다. 부드럽게 밟아야합니다 : 여기 용이 있습니다. 당신은 스스로 문화를 바꿀 수 없으며, 삐걱 거리는 바퀴가되면 결국 버림 받게됩니다. 말 그대로.

당신이 원인을 옹호하고 길을 이끌 노인을 찾으려고 제안합니다. 실패하면 손가락을 가리 키거나 이름을 부르지 않고 일반 개발자 회의에서 올리십시오. 또 다른 대안은 적절한 업무를 수행하는 데 책임을지는 것입니다. 체크인 할 때마다 몇 가지 테스트 만 수정하면됩니다. 시간이 지남에 따라 실패한 테스트 수를 보여주는 차트를 벽에 유지하십시오. 다른 사람들은 그것을 보게 될 것입니다.

쉬운 대답이 없습니다.