(지속적인 통합) Chapter 6. 지속적인 테스트

by

지속적인 통합 연구의 메인 페이지

색인

    *참고: 이것은 기억해야 할 사항과 책(Paul M. Duvall – 지속적인 통합)에 대한 내 생각의 목록입니다. 책이 나온지 오래되서 설명에 있는 기술 스택들이 현재 많이 사용되지 않아서 기술 스택보다는 책에서 나온 이론이나 조언 위주로 글을 쓸 것 같습니다. 내가 아는 한 수정하고 수정했습니다. 그래서 책이 말하고자 하는 것과 다를 수 있다.

    * 별도의 언급이 없는 한 이미지는 지속적인 통합(Paul M Duvall 작성) 책에서 가져온 것입니다.

    '추천 관련글,

    6장. 지속적인 테스트

    • 선형 시스템의 신뢰도는 각 시스템 구성요소의 신뢰도의 곱입니다.
      • 각각 99%의 신뢰도를 갖는 100개의 구성요소로 구성된 프로그램은 37%의 신뢰도를 가집니다.


    • 신뢰할 수 있는 소프트웨어를 만들려면 적어도 개체 수준에서 신뢰성을 보장해야 합니다.
      • 이는 단위 테스트를 통해서만 달성할 수 있습니다.
      • 또한 변경 사항이 있을 때 테스트를 실행해야 합니다.

    테스트 자동화

    • 지속적인 통합 시스템이 모든 서면 테스트를 매번 실행하면 빌드 시간이 점점 더 길어집니다.
      • 개발자 테스트를 범주(단위 테스트, 구성 요소 테스트, 시스템 테스트 및 기능 테스트)로 나누면 빠른 테스트를 먼저 실행하고 나중에 느린 테스트를 실행하기가 더 쉬워집니다.

    • 장치 테스트
      • 소프트웨어 시스템 내에서 작은 요소(일반적으로 클래스)의 동작을 확인합니다.
      • 종속 개체가 파일 시스템이나 데이터베이스와 같은 외부 엔터티에 종속되고 더미 클래스를 사용하지 않는 경우 테스트는 단위 테스트가 됩니다.
      • 그러나 단위 테스트의 중요한 측면은 DB와 같은 외부 종속성에 전혀 의존하지 않는다는 것입니다.

    • 구성요소 테스트(서브시스템 테스트)
      • 구성 요소가 상호 작용하여 예상되는 전체 동작을 생성하는지 확인(시스템 부분의 유효성 검사)
      • DB, 파일 시스템, 네트워크 끝점 등과 같은 외부 종속성이 필요할 수 있습니다.

    • 시스템 테스트
      • 웹 페이지, 웹 서비스 끝점 및 GUI가 처음부터 끝까지 의도한 대로 작동하는지 확인
      • 전체 소프트웨어 시스템 실행 및 실행. 즉, 완전히 설치된 시스템이 있어야 합니다. B. 서블릿 컨테이너 또는 관련 DB.
      • 합격시험 대비 보다 체계적인 측면(성능, 신뢰성, 보안)

    • 기능 테스트(인수 테스트)
      • 고객의 관점에서 애플리케이션의 기능을 테스트합니다.
      • 즉, 테스트 자체가 클라이언트를 모방하는 테스트입니다.
      • 시스템 테스트에 비해 더 많은 사용자 측(요구 사항)

    테스트를 먼저 실행하여 시간이 덜 걸립니다.

    • 단위 테스트는 가장 자주 실행되며 단위 테스트, 시스템 테스트 및 기능 테스트는 두 번째 빌드 중에 또는 정기적으로 실행할 수 있습니다.

    • 장치 테스트
      • 진정한 단위 테스트는 실행에서 완료까지 순식간에 진행되어야 합니다.
      • 누군가 코드를 체크인(빌드 커밋)할 때마다 단위 테스트를 실행해야 합니다.

    • 단위 테스트
      • 단위 테스트에 비해 실행 시간이 약간 더 깁니다.
      • 보조 빌드의 일부로 또는 주기적으로 실행해야 합니다.
      • 물론 단위 테스트가 간단한 프로젝트라면 각 커밋 빌드에서 테스트를 실행할 수 있습니다.

    • 시스템 테스트, 기능 테스트(인수 테스트)
      • 시스템 테스트 또는 기능 테스트에는 완전히 설치된 시스템이 필요하며 가장 많은 시간이 소요됩니다.
      • 밤에 일하지 않을 때 시스템 테스트를 실행하는 것이 좋습니다.

    오류 검사를 위한 테스트 작성

    • 테스트 및 지속적인 통합은 오류 빈도를 줄일 수 있지만 여전히 발생할 수 있습니다. 결과를 만들어 상을 받을 수 있습니다. 그러나 같은 실수는 한 번만 해야 합니다.
    • 오류가 발생하면 먼저 오류를 표시하는 테스트 사례를 만듭니다. (동일한 오류를 재현하고 성공한 테스트 케이스)
    • 그리고 버그를 수정하면 이제 버그를 재현하는 테스트가 실패합니다. 그리고 테스트 사례를 업데이트하여 디버깅된 코드를 확인합니다.
    • 위의 방법을 사용하면 변경한 코드가 올바르게 작동하는지 확인하고 동일한 문제가 다시 발생하지 않도록 방지하는 회귀 테스트를 수행할 수 있습니다.

    어설션을 테스트 케이스로 제한

    • 책에 여러 주장이 있고 첫 번째 주장이 실패하면 실패 지점에서 전체 테스트 사례가 폐기되어 하나로 제한되는 것처럼 보입니다.
    • junit5를 기반으로 assertAll 또는 assertSoftly를 사용하면 그 안에 포함된 모든 assert가 중단 없이 실행되고 결과가 보고됩니다.
    assertSoftly(
        () -> assertNotNull(studyBasic),
        () -> assertEquals(StudyBasicStatus.ENDED, studyBasic.getStatus(), () -> "Study 생성시 초기값은 " + StudyBasicStatus.ENDED + " 이여야 함."),
        () -> assertTrue(studyBasic.getLimit() > 5, () -> "스터디 참가 인원은 5 이상이어야 함.")
);

    묻다

    • 자동화된 테스트를 단위 테스트, 단위 테스트, 시스템 테스트 및 기능 테스트와 같은 다양한 범주로 나누었습니까?
    • 서로 다른 빌드에서 각 테스트 범주를 실행하도록 지속적 통합 시스템을 조정하고 있습니까?
    • 테스트를 자동화할 수 있습니까? 자동화된 개발자 테스트를 버전 관리 저장소에 커밋했습니까?