[Spring] TestCode, TDD, JUnit, assertJ

Test Code

제품 또는 서비스의 품질을 확인하고 소프트웨어의 버그를 찾습니다.  
즉, 함수, 특정한 기능, UI, 성능, API스펙이 예상대로 동작하는지 확인하는 것입니다.

 

테스트 코드의 종류

 

 

• 테스트 피라미드는 대상 범위나 성격에 따라 Unit test(단위 테스트), Integration test(통합 테스트), UI 테스트(E2E 테스트) 3가지의 테스트로 나누어집니다.
• 개발자분들이 프로젝트를 진행할 때 공통적으로 작성해야 하는 테스트들을 모아놓은 것이 테스트 피라미드입니다.

 

1. Unit Test

• 단위 테스트
• 함수나 모듈 클래스와 같은 단위의 기능에 대한 유효성을 검증하는 테스트입니다.
• 예를 들어 자동차의 타이어를 하나 테스트하는 것을 단위 테스트라 합니다.
• 단위 테스트는 매우 간단하고 명확하며 빠르게 실행된다는 특징이 있습니다.
• 또한, 작게 쪼개진 단위 테스트는 해당 로직이 어떤 역할을 하는지 쉽게 파악할 수 있다.
• 단위 테스트를 사용하면 System.out으로 하는 번거로운 디버깅이 필요 없습니다.

 

2.  Integration test

• 통합 테스트
• 하나의 단위가 아니라 여러 가지의 서로 다른 모듈 혹은 클래스 간 상호작용의 유효성을 검사하는 테스트이다.
• 이러한 통합 테스트가 필요한 이유는 각각 단위 테스트가 검증되었다 하더라도, 모듈 간 인터페이스 및 데이터 흐름이 의도한 대로 작동하지 않는 경우도 있기 때문이다.
• 예를 들어, 타이어와 엔진 등 부품들이 서로 상호작용을 하면서 시동이 걸리는지를 확인하는 통합 테스트입니다. 

 

3. User interface Test(E2E Test)

• End-to-End의 줄임말로 끝과 끝의 테스트
• 실제 사용자들이 사용하는 화면에 대한 테스트를 하여 서비스의 기능이 정상적으로 작동하는지 검증하는 테스트입니다.
• 예를 들어, 타이어나 엔진 등 부분적인 상호작용이 아니라 엑셀과 브레이크, 엔진 등 차가 나아가는지 전체적으로 테스트하는 것을 의미합니다.
• UI 테스트는 실제 앱을 사용하는 사용자의 흐름에 대해 테스트 함으로써 UI 변경 사항으로 발생할 수 있는 문제를 사전에 차단함으로써 신뢰성을 높입니다. 
• 하지만 화면과 직접적으로 연관되어있는 테스트이다보닌 실행 시간도 오래 걸리고 디자인이 변경될 때마다 테스트 코드의 수정이 필요합니다.
• 그래서 유지보수 비용도 큽니다.

 

테스트 코드 작성의 장점

• 개발 과정 중 예상치 못한 문제를 미리 발견할 수 있다. (에러를 클라이언트보다 빨리 발견할 수 있다.)
• 작성한 코드가 의도한 대로 작동하는지 검증할 수 있다.
• 코드 리펙토링을 유연하고 안정적인 대응을 할 수 있게 해 준다.
• 코드의 모듈화를 한 번 더 고민하게 해 준다.
• 코드 변경 시, 변경 부분으로 인한 영향도를 쉽게 파악할 수 있다.
• 테스트 코드를 통해 동작하는 방식 및 결과 확인이 가능하다.

---

TDD (Test Driven Development)

• 테스트 주도 개발
• 테스트를 먼저 짜고 테스트를 통과할 만큼의 코드를 추가하는 단계를 반복하여 구현한다.
• 실패하는 테스트를 먼저 작성하고 그에 해당하는 기능을 만들어나가는 방식이다.
• 이후엔 리팩터링으로 효율성 향상한다.

 

TDD 개발 프로세스

 

• { Red } 단계에서는 실패하는 테스트 코드를 먼저 작성합니다.
• { Green } 단계에서는 테스트 코드를 성공시키기 위한 실제 코드를 작성합니다.
• { Yellow } 단계에서는 중복 코드 제거, 일반화 등의 리팩터링을 수행합니다.

 

이렇게 실패하는 테스트 코드를 먼저 작성하고 그에 해당하는 기능을 구현하는 방식이 TDD이다. 중요한 것은 실패하는 테스트 코드를 작성할 때까지 실제 코드를 작성하지 않는 것과, 실패하는 테스트를 통과할 정도의 최소 실제 코드를 작성해야 하는 것입니다. 

 

 

TDD의 장점

• 모든 요구사항, 목표에 대해서 점검할 수 있고, 사용자 입장에서 코드를 작성할 수 있다.
  (시스템 전반적인 설계 향상)
• 구현보다는 인터페이스에 집중해서 코드를 구현함으로써 코드의 퀄리티는 향상되고 시스템 전반적인 설계를 향상한다. 
• 자연스럽게 테스트 통과율이 높아진다.
• 오버 엔지니어링 방지
• 설계에 대한 피드백에 빠르다.

 

일반 개발 방식과 TDD 개발 방식의 차이점

 

일반 개발 방식

보통 개발 방식은 ‘요구사항 분석 → 설계 → 개발 → 테스트 → 배포’의 형태의 개발 주기를 갖습니다.

 

 

일반 개발 방식의 문제점

1. 소프트웨어 개발을 느리게 하는 잠재적 위험이 존재한다.
2. 소비자의 요구사항이 처음부터 명확하지 않을 수 있다.
3. 따라서 처음부터 완벽한 설계는 어렵다.
4. 자체 버그 검출 능력 저하 또는 소스코드의 품질이 저하될 수 있다.
5. 자체 테스트 비용이 증가할 수 있다.

 

이러한 문제점이 발생되는 이유는 어느 프로젝트든 초기 설계가 완벽하지 않아 재설계로 인해 개발자는 코드를 삽입, 수정, 삭제하는 과정에서 불필요한 코드가 남거나 중복될 가능성이 큽니다.

그래서 일반 개발 방식은 고객의 요구사항 또는 디자인의 오류 등 많은 외부 또는 내부 조건에 의해 재설계하여 점진적으로 완벽한 설계로 나아가는데, 결론적으로 이러한 코드들은 재사용이 어렵고 관리가 어려워서 유지보수를 어렵게 만듭니다.

작은 부분의 기능 수정에도 모든 부분을 테스트해야 하므로 전체적인 버그를 검출하기 어려워져 자체 버그 검출 능력이 저하됩니다. 따라서 작은 수정에도 모든 기능을 다시 테스트해야 하는 문제가 발생하여 자체 테스트 비용이 증가됩니다.

 

 

TDD 개발 방식

 

TDD와 일반적인 개발 방식의 가장 큰 차이점은 테스트 코드를 작성한 뒤에 실제 코드를 작성한다는 것입니다.

디자인(설계) 단계에서 프로그래밍 목적을 반드시 미리 정의해야만 하고 또 무엇을 테스트해야 할지 미리 정의(테스트 케이스 작성) 해야 합니다. 테스트 코드를 작성하는 도중 발생하는 예외 사항(버그 및 수정사항)은 테스트 케이스에 추가하고 설계를 개선합니다. 이후 테스트가 통과된 코드만을 코드 개발 단계에서 실제 코드로 작성합니다.

 

이러한 반복적인 단계가 진행되면서 자연스럽게 코드의 버그가 줄어들고 소스코드는 간결해집니다. 또한 테스트 케이스 작성으로 인해 자연스럽게 설계가 개선됨으로 재설계 시간이 절감됩니다.

 

 

TDD 개발 방식의 문제점

 

1. 생산성 저하

처음부터 2개의 코드를 짜야하고 중간중간 테스트를 하면서 고쳐나가야 하기 때문에 개발 속도가 느려진다고 생각하는 사람이 많습니다. TDD 방식의 개발 시간은 일반적인 개발 방식에 비해 대략 10~30% 정도로 늘어납니다. 

따라서 SI 프로젝트에서는 소프트웨어의 품질보다는 납기일 준수가 훨씬 중요하기 때문에 TDD 방식을 잘 사용하지 않습니다.

 

---

테스트 도구 (JUnit & assertJ)

 

JUnit

•  자바용 단위테스트(Unit Test) 도구 

 

 JUnit 특징

• @Test 메서드가 호출할 때 마다 새로운 인스턴스를 생성하여 독립적인 테스트가 이루어지게 합니다.
• 단정(assert) 메서드로 테스트 케이스의 수행 결과를 판별할 수 있습다. (단정메소드는 아래에 정리)
• jUnit4부터는 어노테이션으로 간결하게 테스트를 지원합니다.(@Test @Before @After)
• 결과는 성공(녹색), 실패(붉은색) 중 하나로 표시됩니다.
• 테스트 결과를 확인하는 것 이외 최적화된 코드를 유추해내는 기능도 제공합니다.

 

assert메서드 정리

• assertArrayEquals(a, b) :  배열 A와 B가 일치함을 확인한다.
• assertEquals(a, b) : 객체 A와 B가 같은 값을 가지는지 확인한다.
• assertEquals(a, b, c) :  객체 A와 B가 값이 일치함을 확인한다.( a: 예상값, b:결과값, c: 오차범위)
• assertSame(a, b) : 객체 A와 B가 같은 객체임을 확인한다.
• assertTrue(a): 조건 A가 참인지 확인한다.
• assertNotNull(a) : 객채 A가 null이 아님을 확인한다.

 

org.junit.Assert.assertThat

공식 문서

org.junit.Assert.assertThat의 기본 형태는 아래와 같습니다.

public static <T> void assertThat(T actual, Matcher<? super T> matcher)

actual 인자에 검증대상(실행 단계의 결과)을 넣고, 이와 비교하는 로직(matcher)을 주입받아 검증 단계를 수행합니다.

개발자가 matcher를 직접 구현하는 것은 비효율적이고, 구현한 matcher에서 오류가 발생할 수도 있습니다.
matcher에서 오류가 발생하면 테스트가 실패하는데, 외부 요인에 영향을 받는 것은 좋은 테스트라고 할 수 없습니다.
그런 이유 때문인지, JUnit의 assertThat은 hamcrest에 구현된 matcher를 사용하도록 강제하고 있습니다.

 

AssertJ

• Java 테스트에서 유창하고 풍부한 assertions를 작성하는 데 사용되는 오픈 소스 커뮤니티 기반 라이브러리
• 테스트 코드 작성 시 가독성이 뛰어나고 상세한 에러 메시지를 제공해주는 라이브러리

 

org.assertj.core.api.Assertions.assertThat

공식 문서

public static AbstractAssert<SELF, T> assertThat(T actual)

assertj의 assertThat은 인자로 actual(검증대상)만 받습니다.

그리고 actual의 타입에 따라 AbstractAssert라는 추상 클래스를 상속한 Assert 클래스를 반환합니다.

 

 

결론

AssertJ와 Junit Assertions 중 어떤 걸 써야 하나

Assertions는 Junit이 구현한 클래스도 있고, AssertJ의 Assertions가 있습니다. 주로 AssertJ를 사용합니다. 그 이유는 JUnit5.Assertions는 IDE가 자동 완성도 지원하지 않으며 메서드를 외워야 한다는 단점이 있습니다.

반면 assertJ는 junit이 제공하는 assert 보다 사용하기 편한 문법을 제공하며, 함수명이 직관적이어서 가독성도 좋습니다.

AssertJ공식문서를 보면 바꾸는 방법이 나온 예시에서 AssertJ가 더 명확합니다.

 

// Junit 
assertEquals(expected, actual);
// to : AssertJ
assertThat(actual).isEqualTo(expected);

 

 

 

 

[참조]

1. https://hanamon.kr/tdd%EB%9E%80-%ED%85%8C%EC%8A%A4%ED%8A%B8-%EC%A3%BC%EB%8F%84-%EA%B0%9C%EB%B0%9C/

2. https://wooaoe.tistory.com/33

3. https://hanamon.kr/%ED%85%8C%EC%8A%A4%ED%8A%B8-%EC%BD%94%EB%93%9C-%EC%9E%91%EC%84%B1%EC%9D%98-%EC%A4%91%EC%9A%94%EC%84%B1/

4. https://jwkim96.tistory.com/168