TDD

소프트웨어 마에스트로 14기 팀 프로젝트에서 나는 백엔드 파트를 담당하여 Spring Boot를 통한 API 서버 개발을 하게 되었다. 이번 프로젝트에서 TDD를 도입하는 것을 고민하게 되면서, TDD에 대해 자세하게 알아보고자 하여 학습 차 게시글을 작성하게 되었다.


TDD

  Test-Driven Development의 약자로, 테스트 주도 개발이라는 의미이다. 새로운 기능을 개발하기 전에 그 기능을 검증할 수 있는 테스트를 먼저 작성하는 것을 중심으로 한다. 쉽게 설명하면 테스트를 먼저 설계 및 구축 후 테스트를 통과할 수 있는 코드를 짜는 것으로, 코드 작성 후 테스트를 진행하는 지금까지 사용된 일반적인 방식과는 다소 차이가 있다.   애자일 개발 방식중 하나로, 코드 설계 시 원하는 단계적 목표에 대해 설정하여 진행하고자 하는 것에 대한 결정 방향의 갭을 줄이고자 하며, 최초 목표에 맞춘 테스트를 구축하여 그에 맞게 코드를 설꼐하기 때문에 방향 일치로 인한 피드백과 진행 방향의 충돌을 방지하여 보다 적은 의견 충돌을 기대할 수 있다.

Test Code의 작성 목적

  • 코드의 안정성을 높일 수 있음
  • 기능을 추가하거나 변경하는 과정에서 발생할 수 있는 Side-Effect를 줄일 수 있음
  • 코드에 불필요한 내용이 들어가는 것을 비교적 줄일 수 있음 => 해당 코드가 작성된 목적을 명확하게 표현할 수 있음

TDD Cycle

image

  반복 테스트를 이용하여 테스트 케이스를 작성하고, 이를 통과하는 코드를 추가하는 단계를 반복하며 구현한다. 이러한 방식은 개발자가 새로운 기능을 안전하게 추가하고, 기존의 코드를 변경할 때 발생할 수 있는 문제를 최소화하는 데 도움이 된다.

  1. TEST FAILS(Red State): 새로운 기능에 대한 테스트를 작성, 이 테스트는 아직 해당 기능이 구현되지 않았기 때문에 실패하게 됨
  2. Test PASSES(Green State): 새로운 기능을 구현하여 테스트를 통과하게 함, 가능한 간단한 방식으로 기능을 구현
  3. REFACTOR(Blue State): 코드 리팩토링을 통해 코드의 품질을 향상시킴, 코드의 기능을 변경하지 않으면서 코드의 구조를 개선

JUnit

  Java 진영의 대표적인 Test Framework이다. 단위 테스트(Unit Test)를 위한 도구를 제공한다. 각 메소드나 클래스의 동작을 테스트할 수 있고, 이를 통해 코드 변경에 따른 부작용을 빠르게 발견하여 코드의 품질을 향상시킬 수 있다.

단위 테스트

  소프트웨어 개발에서 단위 테스트는 작은 코드 단위가 예상대로 작동하는지 확인하는 방법이다. 코드의 특정 모듈이 의도된 대로 동작하는지 테스트하는 절차를 의미하고, 모든 함수와 메소드에 대한 각각의 테스트 케이스(Test Case)를 작성하는 것을 의미한다.

JUnit 특징

  • 어노테이션(Annotation) 기반: 어노테이션을 사용하여 테스트 메소드를 정의하고, 테스트 사이클을 설정한다.
  • 단정문(Assert): 다양한 assertion 메소드를 통해 테스트의 결과를 검증한다.
  • 테스트 케이스의 실행 순서, 그룹화 필터링 등을 제어할 수 있음
  • 예외 처리 테스트를 지원한다.

JUnit 모듈

  • JUnit jupiter

    • TestEngine API 구현체로 JUnit 5를 구현하고 있음
    • 테스트의 실제 구현체는 별도 모듈 역할을 수행하는데, 그 모듈 중 하나가 Jupiter-Engine임
    • Jupiter-API를 사용하여 작성한 테스트 코드를 발견하고 실행하는 역할을 수행
    • 개발자가 테스트 코드를 작성할 때 사용됨
  • JUnit Platform

    • Test를 실행하기 위한 뼈대
    • Test를 발견하고 테스트 계획을 생성하는 TestEngine 인터페이스를 가지고 있음
    • TestEngineㅇ르 통해 Test를 발견하고, 수행 및 결과를 보고함
    • 각종 IDE 연동을 보조하는 역할 수행 (콘솔 출력 등)
    • Platform = TestEngine API + Console Launcher + JUnit 4 Based Runner 등)
  • JUnit Vintage

    • TestEngine API 구현체로 JUnit 3, 4를 구현하고 있음
    • 기존 JUnit 3, 4 버전으로 작성된 테스트 코드를 실행할 때 사용됨
    • Vintage-Engine 모듈을 포함하고 있음

JUnit LifeCycle Annotation

  • @Test: 테스트용 메소드를 표현하는 어노테이션
  • @BeforeEach: 각 테스트 메소드가 시작되기 전에 실행되어야 하는 메소드를 표현
  • @AfterEach: 각 테스트 메소드가 시작된 후 실행되어야 하는 메소드를 표현
  • @BeforeAll: 테스트 시작 전에 실행되어야 하는 메소드를 표현 (static 처리 필요)
  • @AfterAll: 테스트 종료 후에 실행되어야 하는 메소드를 표현 (static 처리 필요)

JUnit Main Annotation

  • @@SpringBootTest
    • 통합 테스트 용도로 사용
    • @SpringBootApplication을 찾아 하위의 모든 Bean을 스캔하여 로드함
    • 그 후 Test용 Application Context를 만들어 Bean을 추가하고, MockBean을 찾아 교체
  • @ExtendWith
    • JUnit4에서 @RunWith로 사용되던 어노테이션이 ExtendWith로 변경됨
    • @ExtendWith는 메인으로 실행될 Class를 지정할 수 있음
    • @SpringBootTest는 기본적으로 @ExtendWith가 추가되어 있음
  • WebMvcTest(Class명.class)
    • ()에 작성된 클래스만 실제로 로드하여 테스트를 진행
    • 매개변수를 지정해주지 않으면 @Controller, @RestController, @RestControllerAdvice 등 컨트롤러와 연관된 Bean이 모두 로드됨
    • 스프링의 모든 Bean을 로드하는 @SpringBootTest 대신 컨트롤러 관련 코드만 테스트할 경우 사용
  • @Autowired about Mockbean
    • Controller의 API를 테스트하는 용도인 MockMvc 객체를 주입 받음
    • perform() 메소드를 활용하여 컨트롤러의 동작을 확인할 수 있음
      • andExpect(), andDo(), andReturn() 등의 메소드를 같이 활용함
  • @MockBean
    • 테스트할 클래스에서 주입 받고 있는 객체에 대해 가짜 객체를 생성해주는 어노테이션
    • 해당 객체는 실제 행위를 하지 않음
    • given() 메소드를 활용하여 가짜 객체의 동작에 대해 정의하여 사용할 수 있음
  • @AutoConfigureMockMvc
    • spring.test.mockmvc의 설정을 로드하면서 MockMvc의 의존성을 자동으로 주입
    • MockMvc 클래스는 REST API 테스트를 할 수 있는 클래스
  • @Import
    • 필요한 Class들을 Configuration으로 만들어 사용할 수 있음
    • Configuration Component 클래스도 의존성 설정할 수 있음
    • Import된 클래스는 주입으로 사용 가능

단위 테스트

  위에서도 언급하였지만, 다시 설명하자면 단위 테스트는 프로젝트에 필요한 모든 기능에 대한 테스트를 각각 진행하는 것을 의미한다. 일반적으로 스프링 부트에서는 org.springframework.boot:spring-boot-starter-test 디펜던시만으로 의존성을 모두 가질 수 있다.

F.I.R.S.T 원칙

  • Fast: 테스트 코드의 실행은 빠르게 진행되어야 함
  • Independent: 독립적인 테스트가 가능해야 함
  • Repeatable: 테스트는 매번 같은 결과를 만들어야 함
  • Self-Validating: 테스트는 그 자체로 실행하여 결과를 확인할 수 있어야 함
  • Timely: 단위 테스트는 비즈니스 코드가 완성되기 전에 구성하고 테스트가 가능해야 함
    • 코드가 완성되기 전부터 테스트가 따라와야 한다는 TDD의 원칙을 담고 있음

Reference