효과적인 단위 테스트(Unit Testing)

장동혁 / 효과적인 단위 테스트 (Backend)

단위 테스트의 정의

1. 마틴 파울러
1. 작은 부분들에 집중한다.
2. 테스트 툴을 사용해서 프로그래머들이 직접 작성한다.
3. 다른 테스트 방식에 비해 확실히 빨라야한다.

2. 블라디미르 코리코프
1. 작은 코드 조각을 검증
2. 격리된 방식으로 처리하는 자동화된 테스트
3. 빠르게 수행되어야 한다.

1. Sociable Tests (고전파)
1. 예전부터 테스트 하던 방식을 고수하자.

// ServiceTest
UserService userService = new UserService(); // 실제로 생성
TokenService tokenService = new UserService(); // 실제로 생성

login(loginId, password)

2. 단위의 크기: 기능 단위 (1개 이상의 클래스, 의존관계가 있는 클래스들도 모두 생성)
3. Mock(대역) 사용 범위: 외부 시스템에 대한 의존성이 있을 때
4. 리팩토링 내성: 높다

login(loginId, password)

=> LoginDto(loginId, password)
   login(LoginDto loginDto)

// PASS

2. Solitary Tests (런던파)
1. 2010년쯤 런던에서 목킹하는 기술이 생겼고 목킹 툴을 적극적으로 활용하자고 함

// ServiceTest
UserService userService = Mock()
TokenService tokenService = Mock()

// Stubing 하여 목 객체 생성하여 테스팅
login(loginId, password)

2. 코드 단위 (1개의 클래스, 의존관계가 있는 클래스들은 Mock 객체로 생성)
3. Mock(대역) 사용 범위: 대부분의 의존성
4. 리팩토링 내성: 낮다

login(loginId, password)

=> LoginDto(loginId, password)
   login(LoginDto loginDto)

// FAIL

좋은 단위 테스트의 4대 요소

1. 버그 방지
• 불필요한 테스트 코드의 작성들

2. 리팩토링 내성
• 거짓 양성 최소화
• 거짓 양성은 테스트기의 품질 하락이 심함. 테스트기의 신뢰도를 떨어트림
• 물론 거짓 음성도 최소화해야함
• 거짓 양성: 실패하는 케이스가 왔는데, 정상으로 알려줌
• 거짓 음성: 정상적인 케이스가 왔는데, 오류라고 알려줌
• 테스터기는 테스터기 다워야 한다
• 문제가 있을 땐 문제를 알려주고, 문제가 없을 땐 문제가 없다고 알려주는 것

3. 빠른 피드백
• 빠를수록 비용이 경제적이기 때문에 중요함

4. 유지보수성

Good Practice VS Bad Practice

1. AAA(Arrange-Act-Assert), given-when-then
1. 유지보수성 향상
1. 코드가 직관적임

def "login test"() {
	given: // given
		def logginId = "GDG Songdo"
    def password = "gdgsongdo123"
  when: // when
		def token = sut.login(loginId, password)
		def logout = sut.logout(token)
  then: // then
	  token == "test token"
}

2. 하나의 테스트 메소드에는 하나만 검증한다.
1. 버그 방지, 빠른 피드백 향상

def "login test"() {
	given:
		def logginId = "GDG Songdo"
    def password = "gdgsongdo123"
  when:
		def token = sut.login(loginId, password)
		def logout = sut.logout(token)
  then:
	  token == "test token"
		logout == true // 격리되지 않은 테스트 코드. 비추천
}

3. 테스트 상호 의존성을 피해라
1. 버그 방지, 빠른 피드백 향상

private static int TEST_VARIABLE = 111;

def "login test"() {
  TEST_VARIABLE = 111;
	given:
		def logginId = "GDG Songdo" (mId)
    def password = "gdgsongdo123"
  when:
		def token = sut.login(loginId, password)
		def logout = sut.logout(token)
  then:
	  token == "test token"
}

def "logout test"() {
  TEST_VARIABLE = 222; // 비추천
	given:
		def logginId = "GDG Songdo"
    def password = "gdgsongdo123"
  when:
		def token = sut.login(loginId, password)
		def logout = sut.logout(token)
  then:
	  token == "test token"
}

4. 테스트 코드는 테스트 하려는 기능의 사용 설명서여야 한다.

5. 테스트 코드는 제품 코드 작성 라이프 사이클에 포함된다.
1. 망각 곡선
1. 사람은 20분이지나면 42%를 까먹는다.

Q&A

• 테스트 커버리지에 대해
• 없는 것 보다는 있는 게 좋다.
• 다만 과할 필요는 없다.
• 만약 의미있는 테스트 코드를 다 작성했는데도 70%밖에 되지않는다면 커버리지를 높이기 위해 불필요한 테스트 코드를 생성시킬 수 있다. 50% 정도만 되어도 충분할 것 같다.

• 고전파를 지향한다고 하셨는데 의존성 주입에 대해
• 메인 기능 위주로 작성하되, 서브 기능 같은 경우는 목킹을 해서 작성하기도 함

• 코드가 변경이 되면 테스트가 반드시 깨져야 한다 는 생각이 있는 팀이라면
• 팀이 공감할 수 있게 스터디를 한다거나 공유 세션이 필요함. 함께 호흡하는 것이므로 팀과 함께 맞춰가는 게 더 중요함

참고링크

Unit Tests, UI Tests, Integration Tests & End-To-End Tests

Software testing and their differences

https://lawrey.medium.com/unit-tests-ui-tests-integration-tests-end-to-end-tests-c0d98e0218a6

bliki: UnitTest

Unit Tests are focused on small parts of a code-base, defined in regular programming tools, and fast. There is disagreement on whether units should be solitary or sociable.

https://martinfowler.com/bliki/UnitTest.html

Comment