나중에 귀농을 한다고 생각해보자. 나는 비닐하우스에서 어떠한 작물을 키우는데 이 작물은 귀해서 키우기 굉장히 까다로웠다. 나는 이런 까다로운 조건을 알기 귀찮아서 자동화 작업을 외주로 맡겼으며, 자세한 조건은 모르지만 작물을 키우기 위해선 아래와 같은 조건들을 지켜야 한다고 가정해보자.
1. 매일 작물이 말랐을 때마다 물을 줘야 한다. 이때 작물의 성장에 따라 말라가는 속도가 다르다.
2. 물을 줄 때 작물의 성장 정도에 따라 물의 양을 다르게 주어야만 한다.
3. 이 작물은 해가 가장 높게 떴을 때에 해당하는 시간 대에 햇살을 쐬게 해주어야 한다.
4. 이 작물은 병에 잘 걸린다. 잎사귀가 썩고 나서부터 1시간 뒤 내에 병에 맞는 약을 뿌려주어야 살 수 있다. 이 작물이 걸릴 수 있는 병의 가짓수는 5개이다.
자동화를 맡기고 난 후, 유지보수 비용이 너무 많이 발생하는 것 같아 자동화 기능을 내가 직접 관리하려고 코드를 인수받았다. 아쉽게도 코드는 유지 보수하기 어렵게 되어 있었으며 조건을 잘못 수정한다면 귀한 작물이 다 죽어버리는 굉장히 중요한 코드지만 테스트 코드가 짜여있지 않아 코드 수정 시 매번 전체적으로 잘 동작하는지 테스트를 직접 수행했어야 하는 구조였다. 또한, 클래스가 분리되어 있지 않고 하나의 클래스 내, 하나의 메소드에 각 조건들에 대한 코드가 존재하여 단위 테스트를 짜기 힘든 구조였다.
이제 나는 어떠한 방식으로 이 작물 대한 특징들을 파악할 것이며, 어떻게 해야 코드를 수정해도 작물에 이상이 없도록 수정이 가능한지 생각해봐야 한다.
이제 다시 개발 이야기로 돌아오도록 하겠다. 먼저, 추후에 리팩토링이나 조건이 변경되더라도 기존 동작과 동일한 결과를 얻는다는 것을 확인하기 위해 미리 단위 테스트에서 검증될 수 있도록 테스트를 작성하려고 한다. 그러기 위해선 하나의 클래스에 하나의 메소드에 구현된 조건들을 분리해야 한다고 생각했다. 왜냐하면 하나의 메소드에 여러가지 행위들이 존재한다면 단위 테스트를 짜기가 힘들어진다고 생각하는데 그 이유는 다음과 같다.
1. 단위 테스트에서 특정 기능의 행위, 상태를 검증할 때 검증해야 할 것들이 너무 많아진다.
2. 검증해야 할 것들이 많아지면서 단위 테스트가 비대해진다.
3. 단위 테스트가 비대해지면서 추후에 관리하기 어려워진다.
예를 들어 다음과 같은 기능에 대해 단위 테스트를 작성한다고 해보자.
그렇다면 해당 메소드에 대한 단위 테스트에는 총 5가지의 조건들을 체크해야 한다. 여기서 중간에 1개의 조건이라도 수정되면 모든 조건에 대해서 영향이 간다는 것이다. 또한, 각 조건들이 의도한 대로 동작하는지 체크를 하지 못하고 단순 메소드의 결과값으로만 판단해야 한다.
그래서 난 각 조건들을 분리해야 한다고 생각했다.
분리하려고 보니 조건문이 꽤 복잡한 상황이라고 생각해보자. 각 if, else 부분마다 여러 상태를 가지는 값들이 존재하고 여러 계산 로직들이 들어간다고 상상해보자. 이제 점점 더 머리가 복잡해지는 상황이다.
---
작성 중