[ATDD] 3주차 강의

인수 테스트 통합 시 장점

• 테스트 비용 절감
• 인수 테스트 스텝의 중복을 효과적으로 제거할 수 있음
• 흐름을 검증하면서 자연스럽게 사용자 스토리에 대한 검증이 가능
• 사이드 케이스는 단위 테스트에서 수행하게 유도

레거시 리팩터링

레거시 리팩터링 시

인수 테스트 있음 vs 인수 테스트 없음

 

레거시 리팩터링 with 인수 테스트

기능 변경 혹은 리팩터링을 하더라도 마음껏 할 수 있음

작업하다가 막히거나 꼬이(?)더라도 인수 테스트가 성공하는 시점으로 돌아갈 수 있음

 

레거시 리팩터링 without 인수 테스트

인수 테스트를 먼저 만들고 시작

세부 구현에 의존하지 않는 블랙 박스 테스트이기 때문에 구현이 변경되더라도 검증 가능

 

인수 테스트 다음 스텝

1. 인수 테스트를 성공 시키기 위한 단위 테스트 작성

2. 단위 테스트를 성공 시키기 위한 기능 구현 (or 리팩터링)

3. 단위 테스트 성공 후 리팩터링

4. 그리고 반복

 

기존 코드를 바로 수정하면?

변경한 부분을 의존하는 부분에서 빨간불

기존 테스트 코드 모두 실패

코드를 바로 수정하는 것 보다는 나음

하지만 테스트가 검증하고 있던 프로덕션 코드를 검증할 수 없게됨

 

테스트, TDD는 비효율적인가?

TDD나 테스트 작성을 껴려하는 사람들의 가장 큰 이유

관리할 코드가 두배가 되어 번거롭다고 느낌

> 준비 없이 바로 프로덕션 코드나 테스트 코드를 변경하기 때문

 

레거시 리팩터링 단계

예시) 인증 방법 추가하기

기존에 세션 기반 인증에서 토큰 기반 인증 방법 추가

 

새로운 테스트 만들기

반드시 기존 테스트와 프로덕션 코드는 그대로 두기

 

기능 구현하기

• 기존 코드와 중복이 발생 할 수 있음
• 기존 코드와 신규 코드가 함꼐 존재함
• 작업 중 다른 작업을 하더라도 문제가 없음
  기존 코드가 유지되어 기능에 이슈는 없고,
  신규 작업한 코드도 그대로 남아있음
• 단, 기존 코드와 신규 코드가 혼재되는 기간을 짧게 가져가도록 해야함

 

위 과정을 반복하여 기존 코드를 대체할 수 있을때 대체한다.

그리고 기존 프로덕션 코드와 테스트 코드를 제거한다.

 

인수 테스트와 인증

인수 테스트에서 갑자기 인증?

• 인수 테스트는 시나리오 기반 요구사항을 검증하는 테스트
• 앞선 단계에서는 고려하지 않았지만 시나리오에는 "누가" 라는 정보가 포함되어 있는 경우가 많음
• 행위자가 누구인지에 따라 시나리오 흐름과 결과가 달라짐

인수 테스트에서 인증을 고려할 때 고민해야 할 점

• 어떤 인증을 사용할 것 인가?

인증과 인증 도구

RequestSpecification.auth()

form("email,password")

basic("email,password")

bearer("email,password")

oauth2("email,password")