SweatLife 처럼 UnitTestLife 를 즐겨보자구

UnitTest?

코드를 짜면서 함수가 잘 실행 되는지 확인하기위해 주로 print문을 찍어보았다. 그래서 그 함수가 의도한 대로 잘 작동하는지 확인을 하였다.
이 과정은 정말 단순하지만, 매번 빌드를 하고 직접 시뮬레이터에서 기능들을 터치해나가며 확인해야하기때문에 사실상 번거롭고 빠른 리팩토링이 힘들다.

따라서 이제, 이렇게 잘 작동하는지 검증하기 위해 테스트 코드를 짜보려고 한다.

FIRST 원칙

UnitTest 를 하면서 지켜야 하는 원칙으로 FIRST가 많이 알려져 있다.
FIRST 원칙은 Bob Martin 이라는 "클린 코드" 책의 저자분이 제시한 규칙이다.

F : Fast

- 테스트는 빠르게 동작해야한다.
사실 빌드속도보다 테스트가 느리다면, 큰 의미가 없을거 같다고 생각한다. 왜냐하면 테스트 코드를 작성할 시간에 빠르게 빌드를 확인하는게 효율적이라고 생각하는 사람도 있을 수 있기 때문이다.
테스트 코드를 빠르게 동작할 수 있게끔 하여, 결과를 빠르게 확인하고 오류 발생시, 수정을 하는 방식으로 진행할 수 있어야한다고 생각한다.

I : Independent/Isolated

- 각각의 테스트는 서로 독립적이어야한다
UnitTest, 말그대로 단위테스트 이다. 단어에서 오는 느낌 처럼 최소한의 기능을 하는 단위를 테스트하는 것에 포커스를 맞춰야한다고 생각한다.
만약, 테스트들끼리 서로 의존성이 높다면 다른 테스트 결과에 영향을 끼칠 수 있고 실패 사유가 불분명해질수 있다.

R : Repeatable

- 테스트는 언제 어디서나 같은 결과가 반복되어야한다
당연한 이야기 같지만, 테스트를 어떻게 몇번을 하든 같은 결과가 나와야한다.

S : Self-Validating

- 테스트는 Bool을 이용해 성공/실패에 대해 스스로 검증이 가능해야한다

T : Timely

- 이상적인 테스트는 실제코드를 구현하기 직전에 구현해야한다

결론

테스트 코드를 염두하고 코드를 작성한다면, 프로젝트의 코드들의 유지보수성이 강화될 수 있다고 느껴졌다.
왜냐하면 FIRST 원칙을 지키려 하다보면, 기능별로 독립적인 함수가 구현이 될거 같기 때문이다.
당분간 테스트 코드에 대해 공부하면서, 과연 코드가 얼마나 깔끔해지고 유지보수성이 좋아지는지 지켜봐야겠다. 그리고 더 클린해진 내 코드를 볼 생각에 기대가 된다.