테스트와 가독성
4부에 들어섰다. 성능, 좋은 설계, 가독성이 어떻게 상호작용하는지 살펴볼 예정이다.
읽거나 유지보수하기 쉽게 테스트를 만들어라
테스트 코드가 읽기 쉬워야 한다는 점은 테스트와 상관없는 실제 코드와 마찬가지로 중요하다.
→ 그래서 나는 @DisplayName을 많이쓴다.
어떤 개발자는 종종 테스트 코드를 실제 코드가 어떻게 동작하며 어떻게 사용되어야 하는지에 관한 비공식적 문서라고 생각한다. 그래서 테스트 코드가 읽기 쉬우면 사용자는 실제 코드가 어떻게 동작하는지 파악하기가 더 쉽다.
다른 프로그래머가 수정하거나 새로운 테스트를 더하는 걸 쉽게 느낄 수 있게 테스트 코드는 쉬워야 한다.
만약 테스트가 크고 두렵게 느껴진다면?
- 코드를 수정하는 일이 두려워진다.
- 새로운 코드를 작성하면 그에 따르는 새로운 테스트를 작성하지 않을 것이다.
코드로 사용자는 새로운 코드가 왜 현재 테스트에서 실패하는지 쉽게 진단이 가능하여야 한다.
또, 새로운 테스트도 쉽게 테스트하며 덧붙일 수 있어야 한다.
테스트를 더 읽기 쉽게
일반적인 설계원리를 따르면 덜 중요한 세부 사항은 사용자가 볼 필요 없게 숨겨서 더 중요한 내용이 눈에 잘 띄게 하여야 한다.
좋은 테스트 입력값의 선택
- 테스트에 알맞은 입력값 선택
좋은 입력값을 선택하는 방법은?🤔
좋은 입력값은 코드를 구석구석 철저하게 테스트하며 간단하고 읽기도 쉬워야 한다.
다양한 기능의 테스트
코드를 구석구석 철저하게 수행하려고 하나의 테스트를 완벽한 입력을 사용하여 만들기 보다는
작은 테스트를 여러개 사용하는 방식이 더 쉽고 효과적이다.
구분된 테스트를 사용한다면 나중에 다른 사람이 이 코드로 쉽게 이해할 수 있다.
버그가 발생한다면, 그 버그가 발생한 테스트 케이스를 구체적으로 확인이 가능하다.
테스트에 친숙한 개발
테스트 하기 좋은 코드는 잘 정의된 인터페이스를 가지고 지나치게 많은 상태나 설정을 요구하지 않으며, 감추어진 데이터를 포함하지 않는다.
테스트 코드를 작성하면 잘 조직된 코드를 자연스럽게 짜게되고 그렇게 되면 더 나은 전체 로직을 구성할 수 있게 될 것이다.
테스트 주도 개발(Test-Driven Development)
테스트 주도 개발은 실제 코드를 작성하기 전에 우선 테스트 코드부터 작성하는 프로그래밍 스타일이다.
테스트하기 어려운 코드의 특징과 설계와 관련된 문제에 미치는 영향
| 특징 | 테스트 문제 | 설계 문제 |
|---|---|---|
| 전역변수 사용 | 테스트 할 때 마다 모든 전역 변수를 초기화 해야한다. 그렇지 않으면 테스트가 서로의 결과에 영향을 준다. | 어느 함수가 어떤 부수적인 효과를 가지는지 판별이 어려움. 모든게 제대로 작동하는지 알기 위해선 전체 테스트를 생각해야 한다. |
| 외부 컴포넌트 사용 | 처음에 설정할 일이 많아 테스트를 작성하기 힘들다. | 외부 시스템중 어느 하나가 제대로 작동하지 않으면 프로그램이 실패, 프로그램에 가한 수정이 어떤 효과를 낳을지 알기가 어렵다. |
| 코드가 비결정적 행동을 가짐 | 가끔 실패하는 테스트가 그냥 무시됨 | 프로그램의 논리를 따라가기 어려움. 현장에서 발생한 버그를 추적하여 수정하기가 힘들다. |
설계가 가지는 좋은 특징
| 특징 | 테스트 장점 | 설계 장점 |
|---|---|---|
| 클래스들이 내부 상태를 가지고 있지 않음 | 테스트 하기전에 설정할 일이 없고 감춰져 있는 상태가 없어 테스트 작성이 수월 | 소수의 내부 상태를 가진 클래스는 이해하기 더 간단하고 쉬움 |
| 클래스/함수가 한번에 하나의 일만 수행 | 더 적은 테스트 요구 | 더 작고 간단한 컴포넌트는 잘 모듈화되어있고, 시스템이 서로 더 멀리 떨어져있다. |
| 클래스가 의존하지 않음 | 각 클래스가 독립적으로 테스트 | 시스템 병렬적으로 개발 가능. 쉽게 수정되고 다른 시스템에 영향을 주지 않는다. |
| 함수가 간단하고 잘 정의된 인터페이스를 가짐 | 테스트 대상이 잘 정의됨. 테스트를 위해 더 적은일을 요구 | 개발자가 인터페이스를 쉽게 배울 수 있음. 재사용될 가능성👍 |
지나친 테스트는 금물
- 테스트를 가능하게 하려고 실제 코드의 가독성을 희생
- 100% 코드 테스트에 집착
- 버그가 야기하는 비용이 어느정도 인지
- 프로젝트의 일부분인 테스트가 프로젝트 전체를 지배하는 경우
요즘 내 미니 프로젝트에 이러한 테스트 코드 작성하는 것을 도입했는데 개발의 생산성이 뭔가 향상되는 느낌이고, 조기에 오류같은것을 많이 잡아낼 수 있어서 좋은것 같다. 실행자체도 tomcat을 실행해서 아예 웹서버를 구동하여 무겁게 도메인에서 테스트를 하는것보다 가볍고 실행이 빨라서 좋은것 같다.
앞으로 Mock과 Junit4, Junit5 지금 쓰고는 있지만 더 심도있게 공부할 필요성이 느껴진다.
이런식으로 클린코드를 지향하며 테스트를 생활화하는 개발자가 되어야겠다‼️
이제 마지막 단 15장만 남겨두고 있는데 교양도서로 읽은 이책이 내 코드를 작성하는데에 많은 도움을 준것 같아 보람차다.
다음 책은 지금 진행중인 스프링부트와 aws로 혼자 구현하는 웹서비스를 읽고 클라우드 시스템에 대해서도 깊게 공부할 예정이다.
이상으로 포스팅을 마치도록 하겠다.
