테스트 시작하기 #2
인터페이스 확장 시 테스트 코드의 변경
* 이 글은 Swift 5를 기준으로 작성했다.
* 글의 목적: "클라이언트 개발자의 TDD" 매거진은 그동안 테스트를 위해 학습을 했던 것을 공유하고자 한다.
지난 글('테스트 시작하기') 에 이어
로거의 다음 요구사항에 대한 테스트를 작성해보자.
" 로그 레벨, 종류 ( network , 일반 등), 검색 키워드에 따라 필터링되도록 한다. "
로그 종류는 아직 정하지 않았으니까, 레벨과 검색 키워드로 필터링되는 기능에 대해서 테스트를 작성하자.
TDD: Red ( 테스트 코드를 먼저 작성하자 )
준비 과정으로 log를 다섯 개 넣어줬다.
테스트할 인터페이스는 로그 레벨로 필터링하는 함수로 만들까 한다.
( 느낌상 나중에 확장이 필요할 것 같지만 )
결과로는 필터링된 verbose 레벨 1개가 결과값으로 전달되길 기대값으로 뒀다.
TDD: Green ( 테스트가 통과하는 최소한의 코드를 작성해보자.)
테스트가 통과되는 최소한의 구현을 했다.
실제 구현을 해보자.
TDD: Refactor ( 테스트 성공을 유지한 채 구현부를 작성하자 )
실제 구현부를 작성했다.
Parameterized Tests
로그 레벨을 하나만 테스트하니까 불안하다. 5개 레벨 모두 필터링이 잘 되는지 검증을 할 수 있으면 좋겠다.
filtered 함수에 5개의 레벨을 넣고 값을 비교해 보면 될 것 같다.
Act & Assert 코드 3줄을 복붙 해서 5번 반복해도 되겠지만 parameterized tests 가 있으면 테스트 코드를 읽기 편할 것 같다.
XCTest에서는 지원하지 않기 때문에 내부 함수를 하나 만들자.
로그 레벨 모두를 테스트했다.
인터페이스 확장
실제 사용하는 쪽을 고민해보니 하나의 레벨을 필터링하는 것도 필요하겠지만 한 개 이상의 레벨을 필터링하는 것이 필요할 것 같다.
요구사항이 확장되었으나 기존의 테스트는 그대로 두고 새롭게 테스트를 하나 더 만들자
TDD: Red ( 테스트 코드를 먼저 작성하자 )
구현된 코드를 확장할 것이라 최소한의 코드 작성의 테스트 통과는 스킵하고 바로 구현하자.
TDD: Green ( 테스트가 통과하도록 코드 변경 )
인자값으로 배열을 받도록 했으니 기존의 테스트 코드도 변경이 필요하다.
테스트 입력과 결과를 좀 더 추가해도 좋겠지만, 코드를 검증하는 데에는 이 정도 수준이어도 충분하다고 생각된다.
* 나중에 테스트 작성 밸런스에 대한 이야기를 따로 글로 작성하려고 한다.
이전 글에서 첫 번째 작성한 dataSources로 필터링된 결과도 같이 확인하고 싶다는 생각이 들지만, 실제 사용 시 어떤 것이 더 유리할지 아직 판단이 들지 않기 때문에 최소한의 구현만하고 다음 단계로 넘어가자.
검색이 가능하도록 구현해보자
요구사항 중 로그 종류는 나중에 구현토록 하고 나머지 기능인 검색 기능을 만들어보자.
TDD: Red ( 테스트 코드를 먼저 작성하자 )
이번에도 parameterized test를 작성했다.
검색어를 넣으면 해당 문자열이 있는 로그를 보여주는 걸 기대한다.
TDD: Green
엄격하게는 최소한의 구현만으로 Green을 만들어야 하지만 기존의 로그 레벨 필터링 구현과 별반 다를 게 없다고 판단되어 바로 구현을 하기로 했다.
search 함수를 구현해서 green으로 만들었다.
대, 소문자 여부에 상관없이 검색이 되게 하고 싶다는 생각이 든다. parameterized test를 하나 추가해본다.
TDD: Red
TDD: Green
원하는 요구사항의 구현을 마쳤다.
기존의 테스트 코드는 변경하지 않고 추가 기능에 대한 테스트를 추가하고 구현도 추가 확장 구현했다.
목표로 했던 요구사항은 만족했고, 테스트 코드 작성은 여기까지다.
인터페이스를 확장할 때 테스트는 어떤 때 변경이 필요하고, 어떤 때 변경이 필요 없는지 간단하게 살펴볼 수 있었다.
우리가 작성하는 코드는 '요구사항 변경, 구현괸 코드의 버그 수정' 등으로 지속적으로 변경이 발생한다. 이런 이유들로 변경이 발생하면 이에 관련한 테스트 코드도 때때로 변경이 필요하다.
테스트 코드 또한 구현 코드와 함께 같이 유지보수되어야 하는 코드라는 것을 이야기하고 싶었다.
나의 경우 처음에는 구현 코드를 작성하고 테스트 코드를 작성하는 것만으로도 벅찼던 기억이 있다.
구현 코드와 테스트 코드를 계속 같이 손봐야 될 때 그 이유가 요구사항 변경이 아닌 버그의 발견 같은 경우 '왜 처음부터 이렇게 테스트 코드를 작성하지 못했지? 왜 이런 버그를 난 예상하지 못하고 코드를 작성했지? ' 라며 스스로를 질책하기도 했다.
하지만 어느 순간 테스트가 하나의 짐이 아닌 아군이 한 명 생겼다고 느끼게 된 시점이 왔고, 그때부터는 테스트는 나에게 많은 도움을 줬던 것 같다.
이 글은 처음 테스트를 시작하는 사람들이 좀 더 부담 없이 테스트를 이해하고 실천해 볼 수 있었으면 하는 마음에서 시작했고, 앞으로의 글들을 통해 나보다 좀 더 빠르게 테스트를 아군으로 만들 수 있도록 도움을 주고 싶다. :D
마침.
오늘 코드는 이 commit 에서 확인 할 수 있다.
