두렵다면 테스트를 작성하라
얼마전 페이스북에서 다음과 같은 코드에서 null
여부 검사가 필요한지 의견을 묻는 글을 발견했다.
public void MyCode(string param) { if (param != null && TheirCode(param)) DoSomething(); }
나는 원칙적인 의견을 제시했다.
MyCode()
메서드에서param
매개변수의 멤버를 호출하지 않으며TheirCode()
메서드에 전달하기만 하기 때문에null
여부 검사는 할 필요가 없다.null
참조 오류 방어에 대한 책임은TheirCode()
메서드에 있다.
하지만 현실에서 원칙을 벗어나는 경우는 허다하다. 때문에 내 의견 뒤로 TheirCode()
를 신뢰할 수 없으니 안전하게 null
여부 검사를 하는 것이 좋겠다는 의견도 다수 있었고 이를 지원하는 기법들도 소개되었다. 이런 의견들을 지켜보며 공통점을 두가지 발견했는데 하나는 운영환경에서 TheirCode()
가 null
참조 오류를 발생시킬지 두려워한다는 것과 그러면서도 아무도 배포 전에 직접 확인하려 하지는 않는다는 것이었다.
당시에 조금 바쁜 상황이라 의견을 추가하지 못했는데 이제 그 두려움을 털어낼 방법을 알려주겠다. 테스트를 작성하라.
public void MyCode_does_not_throw_NullReferenceException_when_param_is_null() { string param = null; Action act = () => sut.MyCode(param); act.ShouldNotThrow<NullReferenceException>(); }
이 테스트 케이스는 MyCode()
가 param
매개변수에 대해 null
여부 검사를 해야하는지 명확히 판단해 줄 뿐 아니라 소프트웨어 회귀를 검출하기 때문에 앞으로의 코드 변경에 대해서도 자신감을 줄 것이다. 지불해야 할 댓가는 약간의 지루함 뿐이다. 이제 겁먹지 말고 리팩터하라.