“등장인물은 작가의 지능을 넘지 못한다.”
이 문장을 처음 들었을 때, 나는 테스트 코드가 떠오른다.
테스트 코드라는 건 결국, 내가 만든 로직을 내가 만든 기준으로 검증하는 일이다. 그래서 종종 이런 생각이 들기도 한다.
“아니, 그래서 테스트코드는 결국 본인이 만들어낸 쉐도우복싱이 아닌가?”
현실 속 테스트 코드의 풍경
대부분의 개발자들은 테스트 코드의 중요성을 알고 있다.
TDD라는 개념도 알고, 단위 테스트를 작성해 본 적도 있다.
Junit, Mockito 같은 도구도 익숙하다. 하지만? ㅋㅋ
"딸깍"
System.out.println(obj.toString());- 로그 찍고
- 흐름 추적하고
- 직접 눈으로 확인하고
- 수정하고 끝
특히 실무에선 이런 방식이 훨씬 빠르게 느껴진다.
테스트 코드는 작성도 귀찮고, 깨지면 고쳐야 하고, 런타임도 느리다.
게다가 기능이 바뀌면 테스트 코드도 함께 바꿔야 하니
결국 손이 더 간다고 느껴질 때도 많다.
테스트는 정말 비효율적일까?
맞다. 테스트는 늘 효율적이지 않다.
실무에서는 잦은 요구사항 변경으로 테스트가 자주 깨질 수 있고, 구조가 불안정할 땐 테스트를 짜는 게 오히려 발목을 잡기도 한다.
작은 기능엔 오히려 로그나 직접 확인이 더 빠르다.
게다가 앞서 말한 것처럼, 테스트는
"내가 만든 시스템을 내가 만든 상상력으로 검증하는 것"일 뿐이다.
완전히 새로운 사고를 할 수 있는 것도 아니고,
예상치 못한 시나리오는 대부분 테스트 밖에 있다.
그럼에도 테스트 코드를 쓰는 이유
그런데도 나는 테스트 코드를 완전히 포기하진 않는다. (일단 노력은 해봄.. 마감기한이 다가오지 않는다면 😅)
왜냐하면 테스트 코드는 정답을 보장하는 수단은 아니지만,
위험을 줄여주는 안전망이기 때문이다.
내가 이해한 테스트 코드의 진짜 역할
단순히 "테스트 코드로 버그를 잡는다"가 아니라, "테스트 코드로 코드에 대한 신뢰를 하나 더 쌓는다"는 쪽에 가깝다.
- 혼자서 작업할 땐 로그로 빠르게 확인하면 된다.
- 하지만 여러 명이 함께 일할 땐, 코드에 대한 신뢰 근거가 필요하다.
- 테스트는 그걸 만들어주는 명문화된 계약이다.
그래서 나는 이렇게 합의하게 됐다
- 모든 걸 테스트하진 않는다.
- 하지만 핵심 로직은 테스트로 방어선을 그어둔다.
- 테스트는 개발 속도를 늦추는 게 아니라,
미래에 발생할 리스크를 줄이는 보험이라고 생각한다.
결론
테스트와 TDD는 절대적인 방패는 아니다. 하지만 협업과 유지보수에서 필요한 안전망이다.
결국 중요한 건 '모든 걸 테스트할 수 없다'는 걸 인정하면서도,
그 한계 안에서 어떻게 테스트를 의미 있게 활용할지를 고민하는 자세라고 생각한다.
또 이렇게 써두고 비즈니스 로직부터 짜는 바로 너.. 이번엔 반드시 꼬옥 TDD해보도록
