Java Springboot Test Unit Code London VS Chicago 테스트 코드 방법론

항상 똑같은 일상에서 문득 테스트단위 테스트 코드를 만드는데 ..

코드를 잘만들고 있는건가? 라는 생각으로 정리 하다보니 아래 좋은 테스트코드관련된 내용이 있어서 공유드립니다.
chatGPT 고마워여 영어 번역은 역시!!!
키워드를 주신 겸손하게 익은 벼 님께도 감사드립니다.

 

원본 내용 번역본

참조링크 : https://devlead.io/DevTips/LondonVsChicago
게시일: 2019년 10월 17일
저자: Doug Klugh

통합이며, 선택이 아니다

이제 여러분은 Test-Driven Development의 기본을 마스터했습니다. TDD의 두 주요 학파를 고려해보십시오.
런던 학파는 외부에서 내부로, 행동 기반의 접근법을 취하며, Command-Query Separation을 촉진하고 테스트 더블에 크게 의존합니다

— 그 결과로 약간 불안정한 테스트가 생길 수 있습니다.

시카고 학파는 내부에서 외부로, 상태 기반의 접근법을 사용하며, 디자인 패턴에 더 큰 강조를 둡니다
— 비록 YAGNI (You Aren't Gonna Need It; 필요하지 않을 것이다)의 위험이 있습니다.

하지만 중요한 것은 하나를 다른 하나보다 선호하는 것이 아닙니다.

중요한 것은 여러분의 품질 모델을 이해하고 그 품질을 최적화하는 것입니다.
런던과 시카고는 각각 장점과 단점을 가지고 있습니다. TDD에 대한 최선의 접근법은 이 두 학파를 통합하여 채택하는 것입니다.

여기서 "Command-Query Separation"은 명령과 쿼리를 분리하는 원칙을 의미하며,
"YAGNI (You Aren't Gonna Need It)"는 초기에 필요하지 않은 기능은 구현하지 않아야 한다는 원칙을 나타냅니다.

 

행동 기반 : BDD

런던 학파는 애플리케이션의 외부(일반적으로 API나 컨트롤러에서 시작)부터 시작하여 도메인 모델을 포함하여 하위 계층까지,
그리고 지속성 계층까지 내부로 작업하는 방식으로 TDD에 대한 형식적이고 행동 기반의 접근법을 제공합니다.

런던학파  장점

행동 중심

이 접근법은 시스템의 진입점에서 시작하여 하위 계층까지 작업하면서 사용자가 애플리케이션을 어떻게 탐색할 것인지를 명확히 합니다.
분명히 이것은 깊게 파고들면서 테스트 더블을 많이 사용하게 될 것입니다.
이는 코드 기반을 작게 유지하며 죽은 코드를 작성하지 않게 도와주지만, 리팩토링을 더 어렵게 만드는 불안정한 테스트를 생성하는 경향이 있습니다

— 지속적인 리팩토링을 꺼리게 합니다.

명령 - 쿼리 분리

행동에 중점을 둠으로써 순수 함수를 촉진하여 부작용을 관리하는 데 도움이 됩니다
— 함수형 프로그래밍으로의 게이트웨이를 제공합니다.

런던학파 의 단점

약한 테스트
행동을 테스트 주도적으로 구현하는 것은 코드 기반을 작게 유지하며 죽은 코드를 작성하지 않게 도와주지만, 쉽게 깨지는 테스트를 생성하는 경향이 있습니다.

리팩토링 어려움

프로덕션 코드와 밀접하게 연결된 테스트를 갖는 것은 지속적인 리팩토링을 매우 어렵고 시간 소모적으로 만듭니다. 이는 top-down TDD의 가장 큰 단점 중 하나입니다 — 대부분의 코드 변경 시 깨진 테스트를 다루는 문제입니다. 여기서 "명령-쿼리 분리"는 명령과 쿼리를 분리하는 원칙을 의미합니다.

테스트 기반 : TDD

시카고 학파 (또는 디트로이트 학파)는 애플리케이션의 내부 (일반적으로 도메인 모델에서 시작)에서
시작하여 API로 향하는 방식으로 TDD에 대한 비공식적이고 탐색적이며 상태 기반의 접근법을 제공합니다.

시카고 학파의 장점

강력한 안전망
아키텍처의 하위 계층에서 시작하므로 지속적으로 이전 테스트를 기반으로 구축합니다.
이로 인해 구현과 분리된 테스트가 생성되는 경향이 있습니다

— 기존의 테스트를 깨트리지 않고 구현을 대담하게 리팩토링 할 수 있게 합니다.
이는 차례로 지속적인 리팩토링을 위한 강력한 안전망을 제공하는 고도로 중복된 회귀 테스트 스위트를 제공합니다.

높은 응집도

매우 구체적인 테스트에서 더 일반화된 테스트로 점진적으로 작성함에 따라 결과적으로 생성되는 프로덕션 코드는 매우 응집력이 있습니다.
테스트가 더 일반화됨에 따라 프로덕션 코드는 더 구체적이게 됩니다. 이는 높은 응집도를 촉진합니다. 높은 응집도가 있으면 느슨한 결합이 따라옵니다. 이는 유지보수성, 테스트 가능성, 확장성 등 높은 코드 품질을 촉진합니다.

테스트 더블 최소화

내부에서 밖으로 구축하면서 이전에 작성된 테스트 위에 구축되기 때문에 테스트 더블이 훨씬 적게 필요합니다.
대부분의 경우, 이전 (하위) 테스트의 결과로 그것들을 구축하기 때문에 종속성을 스텁(stub) 또는 모의(mock)로 만드는 필요성이 거의 없습니다. 이는 더 신뢰할 수 있고, 덜 취약한 테스트 스위트를 개발하는 데 도움이 됩니다.

시카고 학파의 단점

YAGNI (You Aren't Gonna Need It; 당신은 그것이 필요하지 않을 것입니다)
내부에서 구축하는 것은 종종 과도한 엔지니어링을 촉진합니다 — 결국 필요하지 않은 코드를 작성하는 것입니다.
여기서 "응집도"는 연관된 기능들이 한 곳에 모여 있는 정도를 나타내며, "YAGNI"는 초기에 필요하지 않은 기능은 구현하지 않아야 한다는 원칙을 나타냅니다.

시키고 학파

시카고 학파 TDD (Chicago School TDD)는 '클래식 TDD' 또는 '안쪽에서 바깥쪽으로' (Inside-Out)의 접근 방식을 의미합니다.
이 접근 방식은 작은 구성 요소부터 시작하여 외부로 확장해 나가면서 개발하는 방법입니다. 이 방식은 먼저 도메인 로직을 중심으로 하여 핵심 비즈니스 로직부터 구현해 나가는 방법입니다. 시카고 스타일의 TDD를 진행할 때는 다음과 같은 접근 방식을 따릅니다: 실패하는 테스트 작성: 가장 먼저 실패하는 테스트를 작성합니다.  이 때, 구현해야 할 기능의 핵심 비즈니스 로직에 대한 테스트를 작성합니다.

테스트 통과: 테스트를 통과하기 위한 최소한의 코드를 작성합니다.
리팩터링: 코드를 개선하여 깔끔하게 만듭니다.

 

시카고 학파 방법을 기반으로 하는 테스트 코드 만들기

Java와 Spring Boot에서 시카고 스타일 TDD를 적용하면서 테스트에서 assert부터 작성하는 방법을 소개하겠습니다:

시카고 피자나 먹을줄알았지 이런방법이 있을줄이야 으흐

1.테스트 시작: 해당 기능에 대한 테스트 클래스와 메서드를 생성하지 않고 시작합니다.

import static org.junit.jupiter.api.Assertions.assertEquals;

public class ProductServiceTest {
}

assert 작성: 아직 테스트 메서드나  테스트하려는 메서드가 없습니다. 그럼에도 불구하고 assert부터 작성합니다.

import static org.junit.jupiter.api.Assertions.assertEquals;

public class ProductServiceTest {

    @Test
    public void shouldReturnProductWhenSaved() {
        assertEquals(1, productService.save(new Product("Sample Product")).getId());
    }
}

테스트를 지원하는 코드 작성: 지금은 productService나 Product가 정의되어 있지 않기 때문에 컴파일 오류가 발생합니다. 이를 해결하기 위해 필요한 클래스나 메서드를 작성합니다.

@Service
public class ProductService {

    @Autowired
    private ProductRepository productRepository;

    public Product save(Product product) {
        return productRepository.save(product);
    }
}

 

최근 개발자 면접 이직을 위한 프로이직러의 노하우 가이드 작성하였습니다.
항상 감사합니다.
By 프로이직러 앵과장

프로이직러 앵과장님의 소개 - 인프런 | 온라인 강의 플랫폼

 

#London VS Chicago 테스트코드 방법론