테스트가 어려운 이유 그럼에도 작성해야 하는 이유

TDD를 논하기 전에 테스트가 가능한 구조로 변경 되어야 한다.

 

개발자라면 테스트 작성을 잘 해야한다라는 인식이 있습니다.

테스트를 잘 작성하면 뭔가 멋있어 보이고 특히 TDD를 한다는 사람들을 보면

마치 다른 세계의 개발자인것 마냥 신기하고 부러웠습니다.

 

하지만 같은 개발자로서 마냥 부러워하기만 하면 안된다는 생각에

이제부터라도 테스트, TDD를 공부하려고 합니다.

 

지금 회사는 테스트 코드를 작성하지 않아 개인적으로 공부해야하지만

또 그런맛이 있다고 생각합니다.

 

아직 반년차 신입 개발자이지만  테스트 코드를 작성하지 않았던 이유와

작성해야 하는 이유를 소개해 드리겠습니다.

 

단점

난이도

테스트 코드는 어렵습니다.

따로 공부해야할 라이브러리가 많고

어디서부터 어디까지 그리고 어떻게 테스트를 해야할지 잘 모르기 때문입니다.

 

특히 테스트를 작성하고 나서도 이게 정말 완벽하게 테스트가 된건가?

라는 생각이 많이 들곤 하였습니다.

(공부 해야함)

개발 비용, 회귀 버그 (Regression)

테스트를 작성하면 그만큼 시간이 오래걸리고

테스트를 위한 테스트를 하게 되는 상황이 생기게 됩니다.

 

만약 다른 로직이 작동하지 않는다면, 실제 코드와 테스트 코드까지 바꿔야 하는

회귀버그를 만나게 됩니다.

 

이런 상황을 피하기 위해 테스트 코드를 작성하지 않습니다.

(테스트 자동화 해야함)

 

꼭 필요한가?

테스트 코드를 작성하지 않아도 문제없이 빌드 배포가 됩니다.

그렇기에 굳이? 라는생각이 들면서 위에 언급한 난이도, 비용 문제때문에

테스트 작성을 피하게 됩니다.

(테스트 하면 더 좋음)

 

 

테스트를 작성해야 하는 이유

테스트의 목적

테스트는 난이도가 높습니다.

하지만 테스트 코드를 잘 작성할 수록

코드는 유연해지고 회귀버그를 방지할 수 있습니다.

유연한 설계는 테스트를 쉽게 그리고 결정적이게 만들어 줍니다.

 

즉, 힘들지만 테스트를 공부해서 테스트 자체를 쉽고 결정적이게 만든다면

앞서 말씀드린 단점을 모두 커버하는 장점이 되는것입니다.

 

유연한 코드

유연한 코드는 테스트를 쉽고 결정적이게 만든다고 했습니다.

유연한 코드란 외부 시스템에 의존 적이지 않은 코드입니다.

 

즉, 설계를 잘 해야합니다.

테스트와 설계는 긴밀한 상호관계를 갖고 있다는 것을 알게 됩니다.

 

개발자는 설계와 테스트를 동시에 고민해야

좋은 코드를 작성할 수 있습니다.

 

커버리지에 집착하지 않는 테스트

테스트를 추가했을 때 얻을 수 있는 효용성을 생각해야지

커버리지 자체에 집착하면 올바른 테스트를 할 수 없습니다.

방향

테스트를 하지 않았던 이유와

테스트를 작성해야 하는 이유를 정리하니

앞으로 어떻게 테스트를 공부해야할지 조금은 정리된거 같습니다.

 

왜 테스트를 해야하고, 어떻게 테스트를 해야하는지 고민해야하고

테스트와 확장성을 동시에 지닌 방법을 생각하고

외부 시스템의 의존을 줄여야 하며

커버리지에 대한 집착을 버리면서

테스트 공부를 해보겠습니다!