8장은 외부 패키지, 라이브러리, 오픈 소스등으로 사용되는 외부코드에 관한 글이다.
경계살피고 익히기
외부에서 온 코드를 다루는 방법은 어렵다. 사용할 때 라이브러리가 예상대로 동작하는지, 라이브러리코드의 문제인지 나의 코드 문제인지 파악하기가 힘들다.
그렇기때문에 외부 코드 작성전 학습테스트를 진행하는것이 좋다.
통제된 테스트 환경에서 외부 코드를 테스트해 API를 제대로 이해했는지를 확인하는 것.
학습테스트에는 비용이 없다. 투자 대비 얻는 성과가 더 큼.
아직 존재하지 않는 코드를 사용하기
협업 과정중 다른팀이 아직 우리가 필요한 API를 완성하지 못했을때의 이야기
구현을 미루고 인터페이스를 정의 -> 우리가 작성하려는 코드의 의도가 분명해진다.
인터페이스 정의 후 다른팀의 API가 완성되었을때 인터페이스를 구현해가며 우리가 생각했던 존재하지않던 코드와의 간격을 줄임.
9장 단위테스트
TDD 법칙 3가지
- 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지않는다.
- 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위테스트를 진행한다.
- 현재 실패하는 테스트를 통과할 정도로만 실제코드를 작성한다.
테스트 코드의 중요성
테스트는 유연성, 유지보수성, 재사용성을 제공한다.
테스트 케이스가 존재하면 변경이 두렵지않다.
테스트 케이스가 존재하지 않는다면 모든 변경이 잠정적인 버그가 된다.
이를 위해 깨끗한 테스트코드를 유지해야한다.
깨끗한 테스트 코드
가독성이 가장 중요하다. (테스트 코드는 문서화의 역할도 하기때문에...)
최소의 표현으로 많은것을 나타내야한다.
given, when, then을 사용하자.
Assert문은 메서드당 하나를 사용하는것이 좋다 ( 최대한 줄이는게 좋다고 함. )
-> 테스트당 한 개념만 테스트하자.
깨끗한 테스트는 F I R S T 라는 5가지 규칙을 따른다.
Fast: 테스트 수행은 빨라야한다. 테스트 수행이 늦어질 경우 자주 돌릴 엄두가 안나기때문, 테스트를 자주 돌려 초반에 문제를 찾아내야한다.
Independent: 각 테스트는 서로 의존하면 안된다. 한 테스트가 다음 테스트에 영향을 끼쳐서는 안됨.
서로를 의존하면 하나가 실패하면 잇달아 실패하므로 원인을 찾기 어려워진다.
Refeatalble: 테스트는 어떤 환경에서도 반복이 가능해야한다. (프로덕션 환경, QA 환경, 네트워크에 연결되지 않는 환경 등등... )
Self-Validating: 테스트는 Bool값으로 결과를 내야한다. -> 성공 or 실패
통과 여부를 알기위해 로그파일을 읽게 만들어서는 안된다.
Timely: 테스트느 적시에 작성해야한다.
테스트를 실제코드를 구현하기전에 작성하라는 이야기
실제 코드를 먼저 작성하면 테스트하기 불가능하도록 설계할 수 있기때문에...
책에서는 입이 아플정도로 테스트의 중요성을 강조한다. 한 챕터로 끝내기에 부족하다고함.
테스트 코드가 망가지면 -> 실제 코드도 망가진다.
항상 테스트 코드를 깨끗하게 유지해 유연하고 확장성있는 어플리케이션을 개발하자.