티스토리 뷰

원문, 번역문

목mock이 안 좋다는 인식은 알고 있었어도 그게 단순히 목 라이브러리를 쓰지 말라는 이야기는 아닐 거란 생각에 제대로 알아보는 차원에서 검색해보았다. 그리고 나도 테스트를 제대로 활용하고 있는지 의구심도 들었기에.

TDD로 더 나은 디자인을 이끌어내야 한다

  • DI는 목을 가져온다. 하지만 DI 없이도 분리된 코드를 짤 수 있다.
  • 코드 커버리지를 무작정 늘리는 것은 프로그램 코드를 복잡하게 만들어 더 많은 버그를 도사리게 한다.

이 소제목 이전의 내용이 목이 필요하다는 건 추상화 표면, 즉 코드를 사용하기 위해 알아야하는 지식이 너무 많은 걸 의미해서 좋은 설계가 아닐 수 있다는 듯. 때문에 독립적인 유닛 테스트에 목킹이 필요하다는 건 사실 그 유닛이 독립적이지 않다는 걸 의미할 수 있다고.

코드 스멜이란?

코드 스멜은 복잡한 문제의 가능성을 드러내는 증상입니다 - 마틴 파울러

  • 목이 나쁘다는 게 아니라 목이 필요없는 상황이 있다는 것이다. 가령 IO 테스트는 목이 빠지면 커버리지가 0이 될 것이다.
  • 로직이 없는 함수 조립만 있는 코드는 커버리지가 0이어도 괜찮다. 하지만 로직이 있다면 유닛 테스트가 필요하고 코드의 단순화와 목을 줄일 수 있는 기회가 있을 것이다.

여기서 함수 조립은 로직이 아니라는 점에서 의문이 들었다. 조립해야 할 함수를 빼먹은 건 테스트 대상이 아닌 건가?

목이란?

  • 목은 유닛 테스트에서 실제 코드대신 들어가 어설션을 하는 테스트 더블(=대역)
  • 모든 테스트 더블은 결합을 의미하고 단순화의 여지가 있다.

두 코드를 같이 쓸 수 밖에 없다는 점에서 결합이라고 볼 수 있을 것이다. 보통 부수 효과 코드 직전까지만을 테스트해서 목을 없앨 수도 있지만, 반대로 생각하면 고차 함수의 경우는 이런 단순화의 대상일까? 어설션이 필요 없기 때문에 목이라고 안 보는 걸지도 ㅎ.

유닛 테스트란?

  • 유닛 테스트란 코드 일부분(=유닛)을 프로그램의 나머지에서 고립시켜서 테스트 하는 것
  • 통합 테스트는 2개 이상의 유닛을 테스트하는 것
  • 블랙 박스 테스트는 공개 API만 테스트하는 것. 반대로 화이트 박스 테스트는 구현에 따라 깨지기에 낭비다.

화이트 박스의 경계가 되는 불변식은 다르게 보자면 요구 사항이다. 이 요구 사항을 정확하게 파악하지 못해 나오는 문제가 더 까다롭다.
이건 어쩔 수 없다 쳐도 아래에 나올 간단한 것들은 숙지해야겠다.

테스트 커버리지란?

  • 코드 커버리지와 케이스 커버리지로 나뉜다
  • 코드 커버리지: 테스트가 얼마나 많은 코드를 실행했는지
  • 케이스 커버리지: 테스트가 얼마나 많은 유즈 케이스를 다루는지

케이스 커버리지가 더 중요하지만 수치화되지 않으므로 수치화되는 코드 커버리지에 목매지 말자

강한 결합이란?

위키에 나온 내용이 아닐까 싶지만 요약 차원에서.

강한 결합의 원인

  • 변이 vs 불변성
  • 섞인 부수효과 vs 격리된 부수효과
  • 책임 과부하 vs 하나만 하기
  • 절차를 기술 vs 구조를 기술
  • 명령형 구성 vs 선언적인 구성

그리고 순수 함수 예찬에 들어간다. 그 아래로는 왠지 요약 의욕이 떨어진다. 좀 많이 스킵하겠다.

하스켈의 IO 모나드 경험 때문에 알고는 있었는데 그동안 실천은 잘 못한 느낌이다.

pipe같은 걸 쓰라고 하는 건 의문을 제기하고 싶다. 리스프를 써보진 않았지만 그 괄호 단위의 평가같이 디버깅이 편리하면 모를까 보통의 C 패밀리 언어에선 그런 조립은 오히려 중간 값 확인과 조립한 함수 분해를 방해하지 않을까 생각한다.

그리고 위에서 언급했던 함수 조립은 왜 테스트의 대상이 아닌 건지 좀 많이 궁금하다. 나름 근거가 있을 거라 생각하는데.

로깅 인터페이스도 목킹 대상이 될 텐데 어쩌면 generator가 이런 부분을 해소할 수도 있지 않을까 싶었다. 실제론 더 복잡한 게 필요하지만.

코드 스멜은 경고지 법칙이 아니다. 목은 나쁘지 않다.

목이 필요한 예시로 express 코드를 들고 있다. 그리고 목이 필요하다는 게 integration point라는 걸 의미한다고 한다.

목은 통합 테스트에서 좋다

부수 효과 부분을 목으로 대체하는 건 매우 상식적이라고 함.

'지식저장소 > 개발' 카테고리의 다른 글

git 다중 계정 사용  (1) 2021.06.05
'React Hook의 어두운면'을 읽고  (0) 2020.11.06
로딩 스피너 컴포넌트 고찰  (0) 2019.06.30
React Hooks를 사용할 이유  (6) 2019.06.19
깃 3-way merge IntelliJ 설정  (0) 2019.03.19
댓글
공지사항
최근에 올라온 글
최근에 달린 댓글
Total
Today
Yesterday
링크
«   2024/04   »
1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30
글 보관함