Jenkins 파이프라인에서의 인수 테스트/TDD

인수테스트

• 프로덕션 환경과 동일한 바이너리 (빌드의 결과)를 이용하여 스테이징
• 스테이징된 소프트웨어 (컨테이너화되어 있음)를 대상으로 사용자 요구사항을 만족하는지 테스트

Jenkins 를 이용한 인수 테스트 자동화

• Dockerfile을 포함하여 빌드와 관련한 모든 파일을 깃허브 소스 레포지토리에 등록
• 자동화 테스트가 가능한 방법을 구현하고 이를 실행하는 파이프라인 스테이지를 정의

그러나, 이 테스트가 인수 테스트로서 적당하게 이용될 수 있는 것인가?

• NO

BDD(Behavior-Driven-Development)

• 사용자(또는 프로덕트 오너)가 인수 기준을 제시
• 위 인수 기준으로부터 개발자는 픽스처(fixture) 또는 스텝 정의 (step definitions)라고 부르는 사용자 친화적인 DSL(domain-specific language)와 프로그래밍 언어를 통합해서 테스트를 작성

Cucumber를 이용한 인수 테스트 생성

• 인수 기준 생성
  - 특정 파일에 비즈니스 사양을 명세
  
• 스텝 정의 작성
  - 기능 사양을 실행할 수 있는 java 바인딩을 생성
  
• 자동 인수 테스트 실행
  - gradle 설정에 라이브러리 의존성 명세 추가
  • gradle 태스크와 junit 테스트 러너를 추가
• 여기에서는 cucumber를 이용한 테스트가 아니라 인수 테스트 자동화에 관심과 중점

TDD (TEST-DRIVEN DEVELOPMENT)

• (중요) 인수 테스트는 기술보다 사람이 중심
  - 지속적 인도 프로세스의 다른 단계들도 마찬가지
  
• 소프트웨어 개발 수명 주기 중 어느 시점에 테스트를 작성해야할까?
  - 코딩 전? 코딩 후?
  • TDD는 특히 인수 테스트에 적합하다.
• 인수 기준 사양을 먼저 작성
  - 인수 테스트 통과를 기능 구현 완료로 간주
  • 이슈 추적 도구의 요청 티켓에 기능 사양을 첨부하는 방법도