“릴리스 초기 릴리스 자주”환경에서 단위 테스트와 관련이있는 것은 무엇입니까?

지난 1 년 동안 팀을 출시 초기 릴리스의 개발 모드 (AKA : Agile이 아닌 Rapid Application Development)로 이끌었습니다. 빌드를 닫는 방법에 대한 자세한 내용은 다음 답변을 참조하십시오. RAD 환경에서 릴리스 품질을 향상시키는 간단한 방법

우리가 RAD를 채택했을 때, 사람들은 상당히 독립적이었고 그들은 단위 테스트를 먼저하고있었습니다. 통합 테스트는 프로세스 후반에 훨씬 많이 발생했습니다. 많은 공식적인 시행 없이는 자연스러운 과정이었습니다. 이제 상황이 상당히 다릅니다.

1. 전체 플랫폼은 핫스팟없이 클라이언트 측에서 작동하는 기존 빌드 / 릴리스와 잘 통합되어 있습니다.

2. 새로운 기능 요구 사항이 계속 나타나고 갈수록 점진적으로 요구합니다.

3. 독립적 인 개발 그룹이 프로세스를 올바르게 따르고 있지만 복잡하고 명백하지 않은 상황으로 인해 주요 장애가 발생했기 때문에 시스템의 전반적인 역학이 매우 중요합니다.

4. 시스템의 많은 부분에는 새로운 알고리즘과 연구 입력이 포함되어 있으므로 잘 정의 된 소프트웨어의 기능 테스트와 같은 문제 (및 테스트 메커니즘)가 항상 정확하게 예측되는 것은 아닙니다.

최근에는 프로세스 개선이 필요한지 확인하기 위해 전반적인 전반적인 그림을 얻으려고했습니다. 팀과 함께 앉았을 때 많은 사람들이 "우리는 더 이상 단위 테스트를하지 않습니다!" 다른 사람들은 우리가 지금부터 시작해서는 안된다고 생각했지만 그것이 효과적이지 않을 것입니다.

단위 테스트는 비교적 성숙한 시스템에서 유용합니까? 최소한 장치의 성숙도에 따라 테스트 범위를 측정해야합니까? 단위 테스트로 개발 속도가 느려 집니까? 다른 방법으로 단위 테스트를 평가해야합니까?

릴리스 초기 릴리스 환경에서 성숙한 플랫폼에 대한 테스트의 모범 사례는 무엇입니까?

단위 테스트는 우선 버그를 찾기위한 것이 아니라 시스템의 다음 릴리스가 이전 릴리스만큼 안정적임을 확인하기위한 것입니다. 릴리스주기가 짧을수록이 테스트를 수동으로 수행하는 대신 자동으로 실행할 수있는 것이 중요합니다.

물론, 독립 부품이있는 시스템이 있고 시스템의 작은 부분에서만 두 릴리스 사이에서 작업하는 경우 시스템의 다른 부분에 대한 일부 단위 테스트를 생략 할 수 있습니다. 그러나 작업중인 부품에 대한 단위 테스트를 반드시 사용하고 확장해야합니다.

또 다른 것은 시스템이 커지면 추가 통합 테스트가 점점 더 필요하다는 것입니다. 그러나 이것이 더 적은 단위 테스트가 필요하다는 의미는 아닙니다.

당신의 진짜 질문은 아마도 다른 질문 일 것입니다. 시스템이 점점 커지면서 단위 테스트를 작성하기가 더 어려워 졌습니까? "단위"테스트는 실제로 단위 테스트입니까, 아니면 더 이상 개별적으로 테스트하지 않습니까? 시간이지나면서 안정화 된 시스템의 하위 레벨에 의존하기 때문일 수 있습니다.

개발자가 기존 라이브러리와 코드를 직접 참조하여 재사용하는 경향이 있기 때문에 이런 일이 발생합니다. 단위 테스트 작성은 더 복잡한 환경과 더 많은 테스트 데이터를 제공해야하기 때문에 종종 단위 테스트 작성이 어려워지는 효과가 있습니다. 이것이 문제라면, 의존성 주입 과 인터페이스 분리 원리 의 핵심 개념에 대해 배워야합니다 . 이는 코드를보다 단위 테스트 가능하게 만드는 데 도움이 될 수 있습니다.

테스트 중심 개발을 검토해야합니다. 여기서 테스트는 먼저 설계 되고 새 코드가 작성 될 때 어떻게 작동하는지 설명해야합니다. 그런 다음 테스트를 통과시킵니다.

내 경험상 이것은 특히 라이브러리에 대해 코드를 더 얇고 더 잘 생각하는 경향이 있으며 사양의 실행 가능한 부분입니다 (항상 올바른 문서임을 의미합니다).

즉, 기존 테스트는 코드가 여전히 예상대로 작동 하는지 확인하는 데 사용됩니다 . 코드가 손상되어 업그레이드 할 때 타사 코드가 여전히 예상대로 작동하는지 확인할 수 있습니다.

에 의해 제안 문서 브라운 과 Thorbjørn Ravn 안데르센 하는 출시 초기에 종종 해제 환경이 혜택을 누릴 수 있습니다 더 좋은 단위 테스트와에서 테스트 주도 개발 긴 릴리즈주기 하나보다.

적절한 통합 통합 시스템이 있고 기능을 잘 나타내는 테스트가있는 경우 언제든지 작동하고있는 기능 (기능 테스트가 통과되었으므로)과 아직 구현되지 않은 사항 (예 : 해당 기능에 대한 테스트가 없기 때문입니다).