15_Legacy_code_with_Unit_Test.md

Lagacy code 에 Unit Test 적용하기

현재 주 업무로 다루고 있는 부분이 iOS Swift 이다 보니, iOS Swift 기준으로 생각해 본다.
(현 업무에서 적용해본 경험 위주로 기술한다.)

A. Legacy code 를 testable 한 코드로 변경하기

보통(경험상 거의 다..) Legacy code 는 테스트 코드가 없고, 코드로 테스트 하기가 매우 어려운 상태이다.
Unit Test 를 적용한다고 하는 것은 코드를 코드로 테스트 하겠다는 의미다.

코드를 왜 코드로 테스트 해야 할까?

프로그램의 크기가 작거나 초기라면, 손으로 프로그램의 로직을 쉽게 테스트할 수 있다.
하지만 프로그램의 크기가 커지고, 기능이 많고, 예외 상황이 많고, 복잡한 환경에서 프로그램이 동작한다고 한다면..
(아마도 대부분의 프로그램이 시간이 지남에 따라 필연적으로 이렇게 되는 것 같다.)

모든 케이스에 대해서 손으로 테스트하는 것은 불가능(?)해진다. 그냥 그때 그때 수정한 부분의 코드 정도만 손으로 테스트하고,
출시하게 될 것이다. (어떤 사이드 이펙트가 발생했는지 전혀 알지 못하고.. 릴리즈할 때마다 전전긍긍대고 기도를 하게 될지도 모른다.
아니면 배째라(?)라는 마인드가 되어 아무 걱정 없이(?) 출시하게 될지도 모른다.)

프로그램이 복잡해질 수록 모든 경우의 수에 대해서 손으로 테스트할 수 없으니,
코드/기능을 추가할 때마다 코드로 테스트를 작성해두면,
프로그램이 점점 복잡해져도 테스트하는데 들어가는 시간이 그렇게 많이 늘어나지 않는다.
그리고 몇번이고 반복해서 테스트가능하다.(손으로는 아마도 점점 한번 전체로 테스트하기도 불가능해질 것이다.. ㅡㅜ)

서론이 길었다.

그러면 코드를 테스트가능하게 만들기 위해서 가장 먼저 해야 하는 것은 무엇일까?

1.프로그램에서 로직과 그렇지 않은 부분으로 코드를 분리한다.

왜 로직과 그렇지 않은 부분으로 분리하는가?
프로그램을 코드로 테스트한다는 것은 무엇을 의미하는가?
코드로 무엇을 테스트해야 하는가?

프로그램에서 가장 중요한 부분은 로직이다. 어떤 조건일 때, 어떻게 분기되고, 어떤 함수가 동작해야 하고, 값이 어떻게 변하고 저장되어야 하는가가 가장 중요하다.
로직 중에서 어떤 부분을 테스트해야 하는가? 사실 100% 모든 코드를 테스트한다는 것은 불가능할지 모르겠다.
특히나 내가 작성하지 않은 부분에 대한 코드는 더욱 테스트하기 힘들 것이다.
하지만 내가 작성한 부분의 코드는 테스트하기 쉽다.

그래서 내가 작성하지 않은 부분의 코드에 대한 테스트는 최소한으로 작성하고,
내가 작성한 부분의 코드를 테스트하는데 집중한다.

iOS 에서는 일단 로직과 View를 분리한다. 이것을 위해서 MVP를 하든 MVVM, Store/Reactor 등을 작성한다. 하지만 일단 목적은 모두 같다. View(로직과 크게 상관없이 화면을 그리는 부분) 과 로직을 분리하는 것이다. 로직을 View 와 분리하여 Presenter든, ViewModel, Store, Reactor든 한쪽으로 분리해서 몰아 넣어야 합니다. (* View 에 로직을 하나도 남겨놓지 않는 것은 Unit Test Code Coverage 를 100% 하려는 것도 같다는 말도 있긴 합니다. 어디까지나 우리의 목적은 우리가 작성한 코드를 테스트하는 것인데, view 에서 (테스트가 필요 없을 정도로 자명하게) 간단히 작성할 수 있는 코드를 코드로 테스트 가능하게 하기 위해서 (많이) 복잡하게 만들어야 한다면 목적보다 수단에 너무 치중한 것이 될 수 있습니다. 하지만 테스트가 필요 없을 정도로 자명한 코드의 기준이 조금 애매하긴 합니다. ㅡㅜ)

...