[ATDD] 2. ATDD + TDD

목차

1. 단위 테스트

2. 협력 객체

3. 통합과 고립(Sociable and Solitary)

4. Test Double

5. Classist TDD vs Mockist TDD

6. ATDD + TDD Cycle

 

 

TDD, ATDD 란?

ATDD(Acceptance Test Driven Development) 참고

 

전체 코드 확인

 

1. 단위 테스트

단위 테스트란?

단위는 클래스, 메소드 등 정의하기 나름이지만 단위 테스트의 목적은

작은 코드 조각에 대한 검증에 있다.

따라서 단위 테스트는 다른 종류의 테스트 보다 수행 속도가 빠르다.

 

2. 협력 객체

@Service
@Transactional
public class LineService {
    private final LineRepository lineRepository;

    public LineService(LineRepository lineRepository) {
        this.lineRepository = lineRepository;
    }
    
    public LineResponse saveLine(LineRequest request) {
        Line line = lineRepository.save(new Line(request.getName(), request.getColor()));
        return LineResponse.of(line);
    }
}

Service 계층의 메소드에 대한 단위 테스트를 작성할 때 Repository 객체에 의존하고 있으면

Repository 객체가 단위 테스트의 협력 객체가 된다.

 

협력 객체가 있는 경우

협력 객체가 없는 경우는 비교적 테스트가 쉽지만,

반대의 경우 협력객체의 상태와 의존성을 고려해야 하기 때문에 복잡도가 높아진다.

 

3. 통합과 고립(Sociable and Solitary)

협력 객체의 사용 방식에 따라 다음 두 가지 단위 테스트로 나눌 수 있다.

 

1) 통합 : 협력 객체를 실제 객체를 사용해 단위 테스트를 작성

   - 장점 : 협력 객체의 상세 구현을 알 필요가 없다.

   - 단점 : 협력 객체의 동작에 영향을 받는다.

 

2) 고립 : 협력 객체를 Mock(가짜)로 사용해 단위 테스트를 작성

   - 장점 : 외부 요인(협력 객체)로 부터 격리되어 테스트 대상의 검증에 집중할 수 있다.

   - 단점 : 테스트가 협력 객체의 상세 구현을 알아야 함.

             협력 객체의 로직이 변경되면 단위 테스트는 성공하지만 실제 시스템은 다르게 동작하게 된다.

 

4. Test Double

실제 객체 대신 사용되는 모든 종류의 객체에 대한 일반 용어

Stub

협력 객체의 호출에 대한 응답을 설정해 놓고 테스트 대상의 상태 검증에 사용한다.

Fake

실제 구현체를 만들어 특정 데이터에 다른 응답을 하도록 설정할 때 사용한다.

 

Mock 

테스트 대상의 행위에 대한 검증에 사용한다.

Mock 객체가 만들어 지면 특정 메소드가 몇 번 호출 되었는지를 카운트해 검증 하는데 사용한다.

 

Stubbing : Stub 객체를 정의하는 행위

1) Mockito 활용

2) MockitoExtension 활용

3) Spring을 활용한 Stubbing

Spring 컨테이너를 띄우고 실제 객체를 Mock Bean으로 변경해 주입한다.

 

5. Classist TDD vs Mockist TDD

단위 테스트를 바라보는 두 관점 Classist와 Mockist.

 

1) Classist TDD

테스트와 테스트 간의 격리

테스트 간의 의존성이 아니라면 실제 객체를 사용한다.

• 도메인 설계가 충분히 이루어진 다음 진행 가능
• TDD 사이클을 이어나가기가 상대적으로 어려움
• 프로덕션 코드에 덜 의존적인 테스트가 작성됨

 

TDD 진행 방식 : Inside-Out

의존성이 작은 레벨인 도메인 모델부터 시작

의존하는 협력 객체가 실제 존재해야 테스트를 작성할 수 있음

 

2) Mockist TDD

테스트 대상과 협력 객체의 격리

• 도메인에 대한 이해도가 높지 않은 상태에서 진행이 가능
• 상대적으로 프로덕션 코드에 의존적인 테스트가 작성됨 (깨지기 쉬운 테스트)

 

TDD 진행 방식 : Outside-In

(1) 의존성이 큰 상위 레벨(Controller)부터 시작

(2) 테스트 더블을 활용하여 테스트 대상이 의존하는 협력 객체(Service)의 예상 결과를 정의

(3) 다음 사이클로 테스트 더블로 미리 정의한 협력 객체를 테스트 대상으로 함

 

6. ATDD + TDD Cycle

 

1) 인수 테스트 작성을 통해 요구사항과 기능 전반에 대한 이해를 선행

2) 내부 구현에 대한 설계 흐름을 구상

3) 도메인에 대한 이해가 생길 때 까지 Outside-In TDD 를 진행한다.

4) 도메인에 대한 이해가 생기면 도메인부터 차근차근 Inside-Out TDD로 기능 구현 

 

 

 

 

 

 

 

출처

nextstep - ATDD와 함께 클린 API로 가는 길