[ Clean Code ] 클린코드 - 단위테스트(Unit Test)

TDD( Test Driven Development)

과거 인식

클래스, 메서드를 공들여 구현하고는 → 엉망진창 테스트 코드로 돌아가기만 하면 아무 코드나 급조해서 붙여 넣음. → 일회성코드에 불과

TDD 법칙 세가지

첫째, 실패하는 단위테스트 작성할 때까지 실제 코드를 작성하지 않는다.

둘째, 컴파일은 실패하지 않으면서, 실행이 실패하는 정도로만 단위테스트 작성

셋째, 현재 실패하는 테스트 통과할 정도로만 실제 코드 작성

⛔️ 그러나, 방대한 테스트 코드는 심각한 관리 문제를 유발하기도 함.

깨끗한 코드 유지하기

밥 아저씨 사례

그냥 테스트만 구현하고 돌아가면 지저분한 코드여도 상관 없다!

⛔️ 막 쓰는 테스트 코드에 대한 위험성

• 코드가 지저분해질수록 변경도 어렵다!
• 테스트 코드 복잡할수록 실제 코드 짜는 시간보다, 테스트케이스 추가하는 시간 오래걸림
• 새 버전 출시할 때마다 TC 유지보수 비용도 올라감⇒ 그 버팀목이 바로 단위테스트(Unit Test)⇒ 아키텍쳐 부실한 코드여도 우려 없이 변경가능테스트슈트: 테스트 케이스를 실행환경에 따라 구분해 놓은 테스트케이스의 집합
• 🔑 실제 코드를 점검하는 자동화된 테스트슈트는 설계와 아키텍쳐를 최대한 깨끗하게 보존하는 열쇠
• 테스트케이스가 없다면 모든 변경이 잠정적인 버그다. 테스트 커버리지가 높을수록 안정적
• 테스트는 유연성, 유지보수성, 재사용성 제공

깨끗한 테스트 코드

도메인에 특화된 언어(Domain Specific Language)

특정한 도메인을 적용하는데 특화된 컴퓨터 언어. 이는 어느 도메인에서나 적용가능한 범용언어와는 반대되는 개념이다. 도메인 특화 언어에는 매우 넓은 다양성이 존재

HTML 과 같이 웹페이지 분야에서 널리 쓰이는 언어가 있는가 하면, GNU Emacs 와 XEmacs 를 위한 Emacs Lisp 와 같이 한정된 분야에서 사용되는 언어도 있다.

장점과 단점

장점

• 도메인 특화 언어는 도메인 수준에서 검증, 확인이 가능하다. 언어의 구조가 안정적이라면, 그 언어에서 쓰여진 문장은 그 분야의 사람들이 이해하는데 불편함이 없다.
• 도메인 특화 언어는 비즈니스 정보 체계의 개발을 전통적인 소프트웨어 개발자들에게서 도메인에 깊은 지식을 가지고 있는 더 큰 도메인 전문가 그룹으로 옮기는데 도움을 준다.

단점

• 새로운 언어를 배워야 한다는 초기 비용과 매우 좁은 적용분야.
• 도메인 특화 언어를 설계, 구현, 유지 하는데 드는 비용. 또한 그것으로 개발하기 위한 툴 개발 비용.
• 예제를 찾아보기 힘듦.

https://ko.wikipedia.org/wiki/도메인_특화_언어

이중표준

테스트 당 assert 하나

F.I.R.S.T - 깨끗한 코드

FIRST 라는 약어 → 효과적 단위테스트를 위한 간결한 기준 세트를 설명함

• Fast : 테스트는 빠르게 실행 되어야함.
• Independent / Isolated(독립/격리): 서로 상태를 공유하지 않아야 함.
• Repeatable(반복 가능): 테스트를 실행할 때마다 동일한 결과를 얻어야 함. 외부 데이터 공급자 또는 동시성 문제로 인해 간헐적인 실패가 발생할 수 있음.
• Self-validating(자체 검증): 테스트는 완전 자동화되어야 함. 로그 파일에 대한 프로그래머의 해석에 의존하지 않고 ‘합격’ 또는 ‘불합격’ 중 하나를 출력해야 함.
• Timely(시기 적절성): 테스트를 테스트하는 프로덕션 코드를 작성하기 전 테스트를 작성하는 것이 이상적. ⇒ 이를 테스트 중심 개발이라고 함(Test-driven development)

 

결론

실제 코드의 유연성, 유지보수성, 재사용성    → 보존, 강화

 

테스트 코드 지속적으로 깨끗하게 관리

테스트 API 구현해 도메인 특화언어(DSL) 만들면 테스트 쉬워짐

 

---

그렇다면 Swift 에선 어떻게 Unit Test 를 어떻게 생각해야할까? 

https://playground-coding.tistory.com/96