Test Code 2부

 

 

과거 Test Code 관련해서 정리한 글이 있었다.

왜 Test Code가 필요하고, 어떻게 작성해야하며, 전반적인 내용을 가볍게 다뤘었다. 오늘은 테스트 코드 관련해서 조금 더 깊은 내용을 작성해보고자 한다.

 

과거 정리한 글 

• 2022.12.27 - [독후감/자바 웹프로그래밍 Next Step] - Chapter 2 테스트와 리팩토링
• 2022.12.28 - [TIL(Today I Learned)] - Day.39 테스트 그리고 refactoring

일단 항상 코드를 작성하다보면 테스트코드를 짜야지 하지만, 이렇게 짜는 것이 맞나? 라는 물음을 스스로 해보았을 것이다. 나 역시 이번 프로젝트를 하면서 거의 테스트 코드를 작성하지 않았다.

나름대로의 이류를 들어보자면 다음과 같다.

1. 테스트 코드를 작성할 기능이 아니라고 생각했다. ( 무분별한 테스트 코드를 짜는 것이 맞나? )
2. 뭔가 여유가 부족했다. ( 테스트코드를 짜면서 검증하는 것보다 그냥 런 시켜놓고 postman을 이용한 방식이 더 편리 )

사실 핑계에 가깝다 이 점들은....

 

일단 백엔드 개발자라고 하면 Test Code가 무조건 중요하다는 것을 알고 있다. 이 점을 잊으면 안된다.

 

그러나 많은 개발자들 및 취준생들이 나처럼 작성을 미루거나, 관리를 소홀이 하는 case 들이 많다고 한다. 

항상 고민의 중심에는 무엇을 테스트 해야할 지 모르겠다가 중심이였다.

 

대표적으로 이 Test code는 3가지 Lv이 있다.

 

1. Level 1 -  Unit Test
   1. 이는 단위 테스트라고도 불리는데, 각 단위별로 테스트를 수행한다
   2. 그래서 테스트의 수행 속도가 빠르고 작성 및 관리 비용이 낮다 ( 한 단위씩 테스트 하니까? )
   3. 내가 만든 기능이 정상적으로 동작하는지 test를 통해 즉각적인 피드백이 가능하다 
2. Level 2 - Service Test ( Integration Test)
   1. 통합 테스트라고도 불리며, UI를 제외한 애플리케이션의 외부 구성요소들과의 상호작용을 테스트 한다.
   2. UI test와 비슷하게 종단 간 테스트를 진행하지만, UI 테스트를 다루는 복잡성을 피할 수 있다
   3. 보통 UI를 호출하는 Endpoint api를 통해 테스트 한다.
3. Level 3 - UI Test ( End to End Test)
   1. 사용자 기반의 테스트이다.
   2. 그래서 속도가 느리다.
   3. 자동화된 테스트를 위한 테스트 작성 비용이 높다
   4. 테스트가 깨지기 쉽다.

 

테스트를 진행하면 명확한 테스트의 의도가 중요하다. 

그럼 무엇을 테스트 해야하나?

 

바로 Aplication Design(명세)를 테스트 해야합니다. ( 이건 또 무슨 말이냐? )

---

일반적으로 우리가 구현하는 대부분의 애플리케이션은 많은 객체들이 상호 협력해서 작업을 처리하는데, 이 객체 간 협력에 필요한 것은  "어떻게"가 아닌 "무엇(명세)" 이며 우리는 "인터페이스"라 부릅니다.

( 사실 아래참고하는 레퍼런스의 블로그 내용을 잘 이해하지 못했습니다. - 카카오 부분 )

---

일단 test case에 대해서는, 구현된 명세를 기반으로 경우의 수를 정의해서 테스트 코드를 구현해주면 됩니다. 

 

테스트하기 쉬운 코드는 다음과 같습니다.

• 결정적 코드 (Deterministic code) = 같은 입력에 항상 같은 결과를 반환
• 외부 상태를 변경하지 않은 코드 (No side effects) = 부수 효과가 없는 코드는 테스트 하기 쉽다. 

테스트하기 어려운 코드는 다음과 같습니다.

• 비 결정적 코드 (Non - deterministic code) = 결정적 코드와 반대로 실행 시점마다 결과가 달라짐
• 외부 상태를 변경하는 코드

테스트 코드를 작성하려면 주의해야할 사항들 

1. 테스트 코드를 작성하면 두 가지 이상을 한번에 검증하려 하면 안된다.
   1. 이유는 검증 내용이 두 가지 이상이면 결과를 확인할 때, 집중도가 떨어지기 때문이다. 
2. 변수나 필드를 사용해서 기댓값 표현하지 않기.
3. 정확하게 일치하는 값으로 모의 객체 설정하지 않기 .
4. 과도하게 구현 검증하지 않기 .
5. 셋업을 이용해 중복된 상황을 설정하지 않기.

 

내 생각

해당 레퍼런스들을 참고하고 이해하려고 했지만 완전히 내 지식으로는 만들지 못했다. 아직 이해되지 않는 부분들이 많아서 향후 물어볼 기회가 생기면 부족한 부분들을 채워넣어야 겠다고 생각한다. 

 

 

참고 레퍼런스

• https://kakaoentertainment-tech.tistory.com/78

Test Code Why? What? How?

• https://blogshine.tistory.com/186

[TDD] 테스트 코드 작성 팁 (1/2)

• https://toss.tech/article/how-to-manage-test-dependency-in-gradle

테스트 의존성 관리로 높은 품질의 테스트 코드 유지하기

• https://nesoy.github.io/articles/2018-02/CleanCode-UnitTest

Clean Code - 단위테스트(Unit Test)