저는 대기업에서 일하고 있으며 수천 개의 junit 테스트로 대규모 Java 응용 프로그램을 담당하고 있습니다. 이 직책으로 이사 한 이후 200-300 건의 테스트가 중단되었습니다 (수년 동안 중단 된 것 같습니다). 테스트는 오래되고 깨지기 쉬우 며 일반적으로 라이브 샌드 박스 데이터로 끝나는 스파게티 종속성의 혼란입니다.
내 목표는 100 % 테스트 통과이므로 단위 테스트 실패에 대한 빌드를 중단 할 수는 있지만 깨진 테스트를 처리 할 때까지는 할 수 없습니다. 유지 관리 예산이 주로 지원을위한 예산으로 인해 예산이 매우 적지 만 팀에서 낮은 결실 테스트 (주로 구성 / 로컬 리소스 문제)를 식별하고 수정했으며 실제로 30 ~ 40 개 정도의 추악한 테스트를 거쳤습니다.
모범 사례에 대한 의견은 무엇입니까? 나는 테스트가 가치가 있다고 생각하지 않지만 테스트하고있는 것이 무엇인지, 파지 않고 작동하지 않는 이유를 알지 못합니다. 아마도 시간과 돈이 없을 것입니다.
깨진 테스트의 상태를 우리가 아는 것으로 문서화 한 다음 깨진 테스트를 완전히 삭제하거나 무시하고 우선 순위가 낮은 버그 / 작업 항목을 입력하여 조사하고 수정해야한다고 생각합니다. 그런 다음 100 %에 도달하고 다른 테스트에서 실질적인 가치를 얻습니다. 유지 보수 / 리팩토링이 발생하는 경우 다시 선택할 수 있습니다.
가장 좋은 방법은 무엇입니까?
편집 : 나는 우리가 앞으로 작성해야 할 테스트에 대한 명확한 지시가 있기 때문에 이것이이 질문 과 다른 질문이라고 생각 하지만, 큰 현재 테스트 세트가 의미를 갖기 전에 해결해야 할 레거시 실패 테스트를 상속했습니다.