티스토리 뷰
목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
- hooks
- C/C++
- MSVC 2017 RC
- gram
- coroutine
- MSVC2013
- Authentication
- getch()
- intellisense
- Deemo
- React
- Code Snippet
- JWT
- software compraison
- Windows Defender
- Qt5
- Kotlin
- game design
- C++11
- WSL
- novel review
- V3 Lite
- Notion
- SHAREX
- Rust
- IntelliJ
- Haskell
- error highlighting
- MSVC
- CLion
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |