일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |
- front-end
- Color
- 다이나믹 프로그래밍
- java
- SQL
- 구현
- Kotlin
- CleanCode
- 해슁
- 클린코드
- 알고리즘
- 검색트리
- javascript
- html
- DP
- android
- BFS
- 순환
- inflearn
- SWEA
- DFS
- 코딩테스트
- codecademy
- Spring
- CSS
- 프로그래머스
- 자바
- Web
- algorithm
- 정렬
- Today
- Total
깡뇽
[Clean Code] 클린 코드 - 9장 단위 테스트 본문
TDD, 애자일과 같은 프로세스들과 함께 이 분야의 많은 발전이 이루어졌는데 그만큼 제대로 된 테스트 케이스 작성에도 신경을 써야 한다.
* TDD(Test Driven Development) 테스트 주도 개발 : 매우 짧은 개발 사이클을 반복하는 소프트웨어 개발 프로세스 중 하나이다. 개발자는 먼저 요구사항을 검증하는 자동화된 테스트 케이스를 작성한다. 그런 후에, 그 테스트 케이스를 통과하기 위한 최소한의 코드를 생성한다. 마지막으로 작성한 코드를 표준에 맞도록 리팩토링한다. - 위키백과
TDD 법칙 세 가지
1. 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다.
2. 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다.
3. 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다.
깨끗한 테스트 코드 유지하기
대충 작성한 테스트 코드는 실제 코드 작성보다 더 많은 시간이 걸리게 되거나 새 버전 출시마다 유지 및 보수 비용을 크게 만들어 버리는 등 악순환을 만든다. 그러므로 테스트 코드는 실제 코드만큼이나 중요하고, 깨끗하게 짜기 위해 노력해야 한다.
- 테스트는 유연성, 유지보수성, 재사용성을 제공한다
테스트 케이스가 없다면 모든 변경 사항들은 미래에 어떠한 버그를 일으킬지 모르지만, 테스트 케이스가 있다면 걱정을 할 필요가 없으며 유연성, 유지보수성, 재사용성을 제공하기 때문에 실제 코드도 더 잘 보존할 수 있다.
깨끗한 테스트 코드
실제 코드에서처럼 테스트 코드에서의 가독성이 중요하다. 테스트 코드는 너무 구체적이기 보다는 진짜 필요한 자료 유형과 함수만을 사용해 작성해야 헷갈리지 않게 코드의 기능을 빨리 이해할 수 있게 해 준다.
- 도메인에 특화된 테스트 언어
* DSL(Domain Specific Language) 도메인 특화 언어 : 특정한 도메인을 적용하는데 특화된 컴퓨터 언어이다. 이는 어느 도메인에서나 적용 가능한 범용 언어와는 반대되는 개념이다.
시스템 조작을 위해 API를 사용하는 대신에 API 위에 함수와 유틸리티를 구현하여 사용하면 테스트 코드 작성 및 읽기가 쉬워진다. 이러한 특수 API는 리팩터링을 통해 개선되므로 지속적인 코드 리팩터링이 진행되어야 한다.
- 이중 표준
테스트 코드는 실제 코드와의 요구사항이 다르므로 실제 코드만큼 효율적인 필요는 없다.
테스트 환경은 대게 자원(메모리 or CPU 효율 관련)이 제한적이지 않으므로 실제 환경에서는 절대 안 되지만 테스트 환경에서는 문제없는 방식이 있기도 하므로 주의해야 한다.
테스트 당 assert 하나
함수마다 assert 문을 되도록 적게 사용하는 것이 좋다. 하나만 사용해야 한다고 말하기도 하지만 그렇게 되면 테스트를 분리해야 하고 중복되는 코드도 많아지게 되는 단점이 존재하기 때문이다.
- 테스트 당 개념 하나
여러 개념을 연속을 테스트하는 긴 함수보다는 테스트 함수마다 한 개념만을 테스트 하는 것이 좋다.
F.I.R.S.T
테스트는 "Fast 빠르게, Independent 독립적으로, Repeatable 반복 가능하게, Self-Validating 자가 검증하는, Timely 적시에"의 규칙을 따라야 한다. 즉, 테스트는 빠른 속도로 작동되어야 하고, 각 테스트는 순서 및 실패에 상관없도록 서로 의존해서는 안 된다. 또한, 어떠한 환경에서도 테스트가 수행 가능해야 하고, 테스트 결과는 성공 또는 실패로 나누어 얻어서 수작업으로 비교하지 않도록 한다. 마지막으로 단위 테스트는 테스트하려고 하는 실제 코드를 구현하기 직전에 구현하여 실제 코드 작성이 테스트 코드 작성에 영향을 미치는 일이 없도록 한다.
결론
실제 코드의 유연성, 유지보수성, 재사용성을 보존 및 강화해주는 테스트 코드는 실제 코드만큼 중요하기 때문에 지속적으로 깨끗하게 관리하려고 노력해야 한다.
실질적으로 테스트 코드를 작성해 본 경험이 아직 없다. 그저 디버깅을 위한 코드만 작성해 봤을 뿐 앞으로 내가 테스트 코드를 작성하며 코딩하는 날이 빨리 왔으면 좋겠다...! 오늘 읽은 9장을 통해서 테스트 코드의 중요성을 머릿속에 깊게 새길 수 있었다. 깃허브에서 다운로드한 코드들을 볼 때에도 실제 코드와 함께 테스트 코드들도 보면서 눈에 익히는 것도 좋을 것 같다는 생각이 들었다.
'Book > Clean Code' 카테고리의 다른 글
[Clean Code] 클린 코드 - 10장 클래스 (2) | 2022.03.09 |
---|---|
[Clean Code] 클린 코드 - 7장 오류 처리 (0) | 2022.03.03 |
[Clean Code] 클린 코드 - 6장 객체와 자료구조 (0) | 2022.03.01 |
[Clean Code] 클린 코드 - 5장 형식 맞추기 (0) | 2022.02.28 |
[Clean Code] 클린 코드 - 4장 주석 (0) | 2022.02.24 |