TDD, Unit Test

Think about Keywords

목록 보기

15/37

다시 한번 상기하자. TDD는 실패하는 테스트 작성(Red) - 테스트를 통과할 수 있는 (최소한의) 코드 작성(Green) - 리팩토링의 과정을 거친다.
뭘 할지 적어 놓고, 그것에 부합하(지만 실패하)는 테스트 코드부터 먼저 짜고, 그것을 해결하기 위한 코드를 작성하는 것.
TDD를 좋아하는 회사가 그렇게 많지 않다는 것이, TDD 방법론을 실습해보면서 이해가 되었다. 테스트 케이스를 억지로 짜내는 느낌도 있다.
생각보다도 꽤나 많은 코드를 짜야 하기 때문에, 초기 개발 단계에서는 개발 시간이 늘어지는 것이 꽤나 자명했다.
결국 시간을 비용이라고 생각했을 때, 초기에 들어가는 비용과 미래에 유지보수를 위한 비용을 저울질할 수 있다고 생각했다.
좋은 테스트 코드의 작성을 위한 FIRST 원칙도 기억하자. Fast, Independent, Repeatable, Self-validating, Timely.
FIRST 원칙에서 전반적으로 느껴졌던 것은, 테스트 코드를 마치 하나의 모듈처럼 생각하고 다루면 대부분 만족시킬 수 있는 원칙이라는 것이었다.
개발을 함에 있어서 여러모로 모듈화가 중요한 것 같다.. 고 생각했다.

XCTest 프레임워크에서 사용할 수 있는 Assertion의 종류가 상당히 많았다. 어제 실습해본 것은 XCTAssertEqual, XCTAssertTrue, XCTAssertFalse.
공식 문서에서 보니 true냐 false냐, nil이냐 아니냐, 값이 같냐 다르냐뿐만 아니라 값 간의 대소 비교, 에러가 나오는지 여부 등이 있었다.
또한, 일부러 실패를 일으킬 수도 있고, 특정 상황에서는 테스트를 스킵할 수도 있다. 사용하기에 따라 다재다능한 도구가 될 수 있겠다고 생각했다.
다만 기억할 것은, 기술의 사용법이 중요한 게 아니라 어떻게 사용하느냐가 중요한 것이라는 것.
XCTest 프레임워크 또한 테스트를 위한 도구라는 것이다. 이 테스트를 어떻게 활용할 것인지 잘 생각해봐야 할 것이다.
여느 코드가 그렇듯 테스트 코드, 심지어 테스트를 사용하는 것에 있어서도 정답은 없지 않을지.