[CleanCode]단위 테스트

들어가기 전에

 클린코드 저자의 말에 따르면 1997년만 해도 TDDTest Driven Development 개념을 아무도 몰랐다고 한다.

당시만 해도 단위 테스트란 프로그램이 '돌아간다'는 사실을 증명하는 일회성 코드에 불과했다.

 또한 아직도 클린코드 라는 개념은 현재 떠오르는 개념이며, 실제 업무에서는 상사의 지시대로 개발을 진행하는 것이 바람직하다.

---

깨끗한 테스트 코드

 

실제 코드가 변하면 테스트 코드도 변해야 한다.
→ 테스트 코드가 지저분할수록 테스트코드를 수정하는데 더 많은 시간이 걸리고 실패로 뜰 확률이 높아진다.

 

테스트 코드는 실제 코드 못지 않게 중요하다.

---

테스트는 유연성, 유지보수성, 재사용성을 제공한다.

 코드가 변경된 상황에서 우리는 클릭 한번으로 변경된 코드가 성공이라는 것을 알아야 한다.

이것을 제공하는 것이 바로 단위 테스트이다.

 우리는 테스트 케이스가 있으면 변경이 두렵지 않게 된다.

실제 코드를 점검하는 자동화된 단위 테스트 슈트는 설계와 아키텍쳐를 깨끗하게 보존하는 열쇠다.

---

이중 표준

• 테스트 API 코드에 적용하는 표준은 실제 코드에 적용하는 표준과 다른다.
• 간결하고, 표현력이 풍부해야 하지만, 실제 코드만큼 효율적일 필요는 없다.

---

테스트 당 assert 하나

• assert 문이 하나면 결론도 하나이기에 코드를 이해하기 빠르고 쉽다.
• 하지만 필요시 assert문을 더 추가해도 상관없다.
• 되도록 최대한 줄여야 좋다는 것이다.

---

F.I.R.S.T

• Fast
  : 테스트는 빨리 돌아야 한다. 느리면 테스트를 자주할 엄두를 못 낸다.
• Independent
  : 각 테스트는 서로 의존하면 안된다. 하나가 실패하면 나머지도 실패하므로.
• Repeatable
  : 어떤 환경에서도 반복 가능해야 한다.
  실제 환경, QA환경, 네트워크가 안되는 환경에서도.
• Self-Validating
  : 테스트 결과는 True/False. 성공 아님 실패하는 boolean 값이여야 한다.
  결과를 확인하려고 파일 두개를 수작업으로 비교하게 만들어서도 안된다.
• Timely
  : 단위 테스트는 테스트하려는 실제 코드를 구현하기 직전에 구현한다.
  코드를 만들고 테스트 코드를 만들면 실제 코드가 테스트하기 어렵다는 사실을 발견하거나, 테스트가 불가능하게 코드를 설계할 수 도 있다.

---

결론
 테스트 API를 구현해 도메인 특화 언어DSL을 만들자.

2024.10.03 - [📑 개발 사전/📖 용어] - [IT용어]DSL:Domain Specific Language

그러면 그만큼 테스트 코드를 짜기가 쉬워진다.