코드는 실행돼야 비로소 온전히 알 수 있습니다. 실행되기 전에는 의도대로 작동할지 확신할 수 없습니다.
지금은 문제가 없을 수 있습니다. 그러나 미래의 환경 변화에도 괜찮을지는 알 수 없습니다.
해답은 선험적으로 얻을 수 없습니다. 실제로 해 봐야만 알 수 있는 것들이 있습니다.
요컨대, 테스트 없이 소프트웨어의 동작에 대해 확신을 가져선 안 됩니다.
아무리 간단한 코드라도 테스트해야 한다
아무리 간단한 코드라도 테스트하지 않고서 기대대로 작동할 것이라고 확신해선 안 됩니다.
아래 코드를 한 번 봅시다.
<div hidden data-is-logged-in="{{ Auth::user() ? 1 : 0 }}"></div>치이 코드는 사용자의 로그인 여부를 알려 주는 매우 단순한 코드입니다. 에러 유발 확률도 거의 없습니다. div 요소에는 hidden 속성이 설정돼 있어서 실수가 있어도 일단은 사용자에게 보이지 않습니다. 그래서 이 코드는 테스트 없이 실서버에 적용됐습니다.
그런데 생각지도 못한 일이 벌어졌습니다. 리눅스 한글 입력기의 버그 때문에 개발자 모르게 div 옆에 “치“라는 글자가 들어가 버린 것입니다.
테스트 없이 코드에 확신을 가진 채 서버에 적용했기 때문에 갑자기 사이트의 모든 곳에 “치”라는 글자가 등장하게 됐습니다. 페이지를 한 번만 로드해 봤다면(즉, 테스트해 봤다면) 발견할 수 있었을 문제였는데 말입니다.
많이 사용(테스트)할수록 많이 알게 된다
우리가 테스트를 많이 할수록 소프트웨어의 동작에 대해 더 많이 확신할 수 있습니다.
그래서 개발자 세계에는 개밥 먹기(DogFooding)라는 문화가 있습니다. 자신이 만든 소프트웨어를 자신이 평소에 직접 사용하는 문화를 말합니다. 반복해서 여러 경로로 테스트를 하는 셈이죠.
자동으로 테스트하면 더 많이 테스트할 수 있다
많이 테스트할수록 소프트웨어의 동작에 대해 더 많이 알게 된다면, 테스트를 자동화한다면 어떨까요. 그렇다면 더 많이 테스트할 수 있을 테고, 소프트웨어의 동작에 대해 더 많이 알고 확신할 수 있게 될 겁니다.
단지 테스트 횟수가 많아지므로 테스트 자동화가 좋다고 하는 것이 아닙니다.
- 통시적 효과: 테스트 자동화는 환경이 변하거나, 소프트웨어 코드의 다른 부분이 변화했을 때도 이 동작이 의도대로 작동한다는 것을 확인시켜 줍니다.
- 공시적 효과: 테스트 자동화는 수동 테스트에 비해 시간이 훨씬 덜 들어갑니다. 따라서 개발자는 상대적으로 더 여유롭게 되고, 그렇다면 여러가지 종류의 테스트를 할 가능성이 늘어납니다.
여기에서 테스트 주도 개발의 원리도 도출할 수 있습니다. “더 많이 테스트할수록 좋다면 테스트부터 작성하는 것이 어떨까? 그렇다면 가장 많이, 빠짐없이 테스트하게 될 텐데.”
결론
우리가 소프트웨어의 작동에 대해 확신을 가질 수 있는 것은 딱 테스트한 만큼입니다. 그 이상 확신을 가져서는 안 됩니다.
따라서 테스트는 많이 할수록 좋습니다. 테스트 자동화는 테스트를 많이 할 수 있도록 돕기 때문에 좋습니다.
부록: 개인의 경험은 유한하므로 사용자에게 배워야 한다
여러 종류의 테스트를 작성한다 해도 문제는 남습니다. 한 사람의 경험에는 한계가 있다는 것입니다. 아무리 개밥을 먹어도 자신이 만든 소프트웨어인 만큼 자신의 의도대로만 사용할 확률도 높습니다.
따라서 우리는 사용자에게 배워야 합니다. 사용자들은 개발자들이 예상치 못한 방법으로 소프트웨어를 사용합니다. 다시 말해 예외를 발생시킵니다. 예외를 처리하는 것은 개발자들의 중요한 임무입니다.
예외를 예상하지 못해 1시간 동안 쓴 댓글이 날아간 적이 있습니다.
제가 관리한 사이트에는 댓글란이 있었습니다. 그리고 CSRF(Cross Site Request Forgery, 사이트 간 요청 위조) 공격 방지용 토큰이 있었죠. 이 토큰은 사용자의 페이지 접속과 함께 발행되고, 한 번 발행되면 30분 간 유효했습니다. 유효한 토큰과 함께 댓글을 작성해야만 댓글이 정상 등록됐습니다.
문제는 댓글란에서 30분 넘게 글을 작성한 사용자가 등장한 것이었습니다. 공들여 작성한 댓글은 CSRF 공격으로 간주돼 인터넷 회선 속으로 사라지고 말았습니다.
제품은 의도대로 동작했습니다. 문제는 의도가 예외적 현실을 반영하지 못했던 것이죠. 그래서 우리는 사용자에게도 배워야 합니다.
《코드 심플리시티》 8장 “테스트”를 참고했습니다.
댓글 남기기