요즘 업무에서 농산물의 생육단계를 계산하는 코드를 작성하고 있다.
기후환경/작물 기반의 생육단계 모형이 존재하고,
그날그날의 날씨와 작물의 특성에 따라 그날그날의 해당 작물의 생육단계(발아기 인지, 개화기 인지 등)를 계산한다.
이 작업을 하면서,
내가 생육단계를 잘 계산하고 있는 걸까?라는 걱정이 들었고
테스트 코드 작성을 처음 도입하게 되었는데,
아래와 같은 좋은 점들을 느끼게 되어 정리해본다.
1. 내가 의도한 것과 실제 결과를 비교할 수 있다.
- 내가 a라는 동작을 할 것이라고 기대하며 코드를 짠다.
- 내가 짠 코드가 a 동작을 하는지 비교하는 테스트 코드를 짠다.
- 결과는... fail!
위의 일련의 과정을 통해 내가 의도한 것과 실제 결과가 다름을 알 수 있다.
코드를 작성하다보면, 생각보다 내가 의도한 것과 실제 결과가 다른 경우가 종종 있다.
테스트 코드 작성을 이를 빨리 발견할 수 있도록 도와준다.
2. 테스트 케이스 구상을 통해 "정상 동작"의 정의가 명확해 진다.
a조건일 때 b로 동작해야할까? c로 동작해야할까?
코드를 작성할 때는 인지하지 못했던, 모호한? 조건들이 생길 수 있다.
이때의 동작은 어떻게 해야할까?
테스트 코드는 쉽게 생각하면,
input이 있고 input에 대한 코드의 실행 결과를 명시하는 것이다.
다양한 input에서의 코드 동작을 명시?하게 되는데.
다양한 input을 고민하게 되면서, 코드 작성 때 인지못했던 다양한 조건의 경우의 수를 발견하게 된다.
예:
어떤 식물의 생육단계는 아래와 같다고 가정하자.
발아기 -> 개화기 -> 만개기 -> 낙화기 -> 과실비대기 -> 수확기 -> 양분축적기
개화기와 만개기를 판단하는 기준으로 아래와 같다고 가정하자.
생육계절 온도가 10 이상이면 개화기이다.
생육계절 온도가 15 이상이면 만개기이다.발아기에 있던 식물이 오늘의 생육계절 온도가 15가 되었다.
생육계절 온도 15는 개화기/만개기 조건을 모두 만족한다.
발아기 다음은 개화기이다.
오늘 식물의 생육단계는 개화기여야할까? 만개기여야 할까?
생물계절별로 만족해야하는 조건이 있고 이를 만족하면 해당 계절이 되도록 코드를 작성하였는데,
여러 계절의 조건을 동시에 만족하는 경우에 대해서는 생각하지 못했다.
그래서, 이런 경우에는 어떻게 하는 것이 정상동작인지 팀원분과 논의해서 "정상 농작"을 추가 정의할 수 있었다.
3. 안심하고 리팩토링할 수 있다. (변수명 또는 dictionary key의 리네이밍)
변수명 리네이밍은 파이참에서 잘 해준다.
그런데 dictionary key는 좀 어렵다.
텍스트 찾아바꾸기를 통해 바꿀 수 있긴 하지만, 정말 변경해야하는 곳만 변경되었는지 별도의 확인이 필요하다.
plum_pheonology_data = {
'bloom_date': date(2020, 5, 1),
'average_temperature': 15,
}
get_growth_stage(a_plum_pehonology_data, crop_variety):
bloom_date = a_plum_phenology_data.get('bloom_date')
...식물의 생육단계를 계산하는 데, 개화일이 필요해서 위와 같이 작성하였는데,
개화일이 아니라 만개일이 요구조건임을 알게되어 수정한다고 하자.
get_growth_stage 함수의 bloom_date는 그냥 ide에서 제공하는 refactor 기능을 사용하면 간단하게 변경할 수 있으며, 따로 검증이 필요없을 만큼 알아서 잘 바꿔준다.
그런데, plum_phenology_data의 key인 'bloom_date'를 'full_bloom_date'로 변경하려면,
"텍스트 찾기"를 해가면서 일일이 찾아서 수정해줘야한다.
수동을 하는 것이기에 중간에 빼먹은 일이 있었는데,
테스트 코드에서 fail이 난 덕에 쉽게 빼먹은 곳을 찾을 수 있었다.
