Community

개발자 99% 커뮤니티에서 수다 떨어요!

← Go back
TIL 9장.단위 테스트
#clean_code
2년 전
590
1

오늘 TIL 3줄 요약

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

  • 테스트 코드는 표현력을 높이고 간결하게 정리하자

  • 테스트 API를 구현해 도메인 특화 언어(Domain Specific Language, DSL)를 만들자

TIL (Today I Learned) 날짜

2022.03.05 ~ 2022.03.06

오늘 읽은 범위

9장. 단위 테스트
먼저 읽은 후

8장. 경계

내용 정리는 9장의 내용

책에서 기억하고 싶은 내용을 써보세요.

TDD 법칙 세 가지

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

  • 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다.

  • 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다.

=> 위 세가지 규칙을 따르면 개발과 테스트가 대략 30초 추기로 묶인다.
테스트코드와 실제 코드가 함께 나올뿐더러 테스트 코드가 실제 코드보다 불과 몇 초 전에 나온다.

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

테스트 슈트가 없으면?

  • 개발자는 자신이 수정한 코드가 제대로 도는지 확인할 방법이 없다.

  • 시스템 이쪽을 수정해도 저쪽이 안전하다는 사실을 검증하지 못한다.

  • 결함률이 높아지기 시작한다.

  • 의도하지 않은 결함 수가 많아지면 개발자는 변경을 주저한다.

  • 변경하면 득보다 해가크다 생각해 더 이상 코드를 정리하지 않는다.

  • 코드가 망가지기 시작한다

테스트 케이스가 있으면?

  • 코드에 유연성, 유지보수성, 재사용성을 제공하는 버팀목이 바로 단위 테스트다.

  • 코드의 변경이 두렵지 않다 -> 코드의 변경이 쉬워진다

깨끗한 테스트 코드

깨끗한 테스트 코드를 만드려면 필요한 것 -> 가독성!!! 가장 중요

가독성은 실제 코드보다 테스트 코드에 더더욱 중요하다.

테스트 코드는 최소의 표현으로 많은 것을 나타내야 한다.

테스트 코드는 본론에 돌입해 진짜 필요한 자료 유형과 함수만 사용한다.

도메인에 특화된 테스트 언어

  • 시스템 조작 API를 사용하는 대신 API 위에다 함수와 유틸리티를 구현한 후 그 함수와 유틸리티를 사용하므로 테스트 코드를 짜기도 읽기도 쉬워진다.

  • 이렇게 구현한 함수와 유틸리티는 테스트 코드에서 사용하는 특수 API가 된다.

  • 테스트를 구현하는 당사자와 나중에 테스트를 읽어볼 독자를 도와주는 테스트 언어다.

이중 표준

  • 실제 환경에서는 절대로 안 되지만 테스트 환경에서는 전혀 문제없는 방식이 있다.

  • 대개 메모리나 CPU 효율과 관련 있는 경우다. 코드의 깨끗함과는 철저히 무관하다.

테스트 당 assert 하나 -> 테스트 당 개념 하나!

  • "개념당 assert 문 수를 최소로 줄여라"

  • "테스트 함수마다 한 개념만 테스트하라"

  • 이것저것 잡다가 개념을 연속으로 테스트하는 긴 함수는 피한다.

F.I.R.S.T

  • Fast(빠르게) : 테스트는 빨라야 한다. 테스트는 빨리 돌아야 한다는 말

  • Independent(독립적으로) : 각 테스트는 서로 의존하면 안 된다. 한 테스트가 다음 테스트가 실행될 환겨을 준비해서는 안 된다.

  • Repeatable(반복적으로) : 테스트는 어떤 환경에서도 반복 가능해야 한다.

  • Self-Validating(자가검증하는) : 테스트는 bool값으로 결과를 내야 한다.

  • Timely(적시에) : 테스트는 적시에 작성해야 한다. 단위 테스트는 테스트하려는 실제 코드를 구현하기 직전에 구현한다.

오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요

테스트 주도 개발을 해보려고 했다가 테스트 환경 구성부터 막혀서 결국엔 꼭 테스트 자동화 환경을 구축해서 개발을 해야해? 빨리 잘 돌아가게만 만들어도 되잖아? 테스트 자동화 환경 구축하고 하느라 개발할 시간 다 잡아먹겠다! 라는 생각에 시도만 찔끔 하다가 나 혼자만의 테스트 방식, 사실상 테스트라고 말하기도 민망한 수준의 테스트를 돌리고 잘 되네! 하고 만족했던 적이 생각나는 장이다.

일정이 촉박하니까, 일단 잘 동작하니까 라는 생각으로 테스트를 외면하면 결국 그 부메랑은 레거시 코드가 되어 나에게 돌아왔던 것 까지도.

궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.

  • BUILD-OPERATE-CHECK 패턴

  • given-when-then 관례

오늘 읽은 다른사람의 TIL

1 comment