테스트 코드가 왜 필요한지, 어떤 문제를 해결해준다고 생각하시나요?

[softmoca]

테스트를 하기 위해서는 고려해야 할 사항들이 아주 많습니다.

여러분은 테스트가 왜 중요하며 무엇을 위해 해야한다고 생각하시나요 ?

[sangjun121]

처음 테스트를 학습했을 때는, 기능을 검증하는 좋은 습관정도로만 이해했었는데, 지금은 변경을 가능하게 만드는 안전장치 로서 더 중요하고 필요하다고 체감하고 있습니다.

기존 기능의 변경 시 보안 장치

실제로 프로젝트를 진행하다보면 함께 협업하는 개발자들 사이의 커뮤니케이션 비용도 무시할 수 없다고 생각합니다. 특히 6개월 이전에 퇴사한 A개발자가 구현한 기능 위에 개발자B가 요구사항을 변경해야한다면 어떻게 해야할까요? 이때, 테스트 코드는 코드의 온보딩 문서로서의 역할을 할 수 있습니다.

주의할 점

테스트의 장점만 생각한다면, 작성하지 않을 이유가 없는데요, 너무 과한 테스트는 오히려 유지보수 비용이 올라간다고 생각합니다. 테스트 또한 코드이기 때문에 유지보수의 관리 포인트가 증가하게 된다는 단점이 있습니다.

결론적으로 나중에 코드를 수정할 수 있기 위해 테스트를 쓴다라는 이유가 가장 테스트의 실용적인 장점이라고 생각합니다.

[koreaioi]

전 두려움을 보호하기 위해 테스트코드를 작성합니다.

도메인이 지켜야할 규칙, 서비스 흐름, 사용자 시나리오가 깨지고, 그로 인한 피해에 대한 두려움이 존재합니다. 그 두려움이 현실이 되지 않기를 막기위해 테스트 코드를 작성합니다.
그래서 이렇게 동작해야 해. 라는 생각으로 테스트 코드를 작성하며, 테스트 코드가 모두 성공할 때는, 두려움이 아닌 안도감이 듭니다 ㅎㅎ

이렇게 동작해야 해로 작성된 테스트 코드는 다른 사람이 봤을 때, 이렇게 동작 하는 군으로 해석되어, 명세의 역할을 할 수 있습니다.

이렇게 동작해야 해로 작성된 테스트 코드가 깨졌을 때는, 이 규칙은 이렇게 동작해야 하는데?를 통해 잘못된 지점을 파악해주는 도구가 됩니다.

이런 장점을 본인뿐만 아니라, 동료 개발자들에게도 느끼게 해주기 때문에, 협력관점에서도 테스트 코드를 작성해야한다고 생각합니다.

[Uechann]

제가 생각 했던 테스트 코드들에 대해 생각했던 내용을 생각해보고 Kent Beck이 생각하는 테스트 코드에 대해서 찾아보고 정리 해보았습니다. 제가 지금까지 개발을 하면서 겪었던 경험을 토대로 한 저의 테스트 코드 필요성 Kent Beck이 생각하는 테스트 코드의 필요성을 접목하고 다음과 같이 정리해 보았습니다.

Kent Beck이 생각하는 테스트 코드

Kent Beck은 테스트 코드를 검증 도구보다는 두려움을 관리하는 도구라고 말합니다.

Kent Beck이 『Test-Driven Development: By Example』 도서에서 이러한 내용들이 언급되었습니다.

TDD는 애플리케이션 개발에서 두려움을 제거하기 위한 것이고,
테스트가 푸는 문제는 기계의 문제가 아니라, 사람의 두려움 문제라고 말하였습니다.

테스트 코드의 필요성 정리

1. 두려움은 개발자를 망가뜨린다.

두려움은 코드가 아니라 개발자의 행동을 먼저 망친다고 생각합니다.

두려움의 부산물들로 개발자가, 소심해지고, 신경질적이고, 소통을 안하고, 비판을 받아들이지 않고,
즉 여러가지 수반되는 문제점들이 발생합니다.

그래서 Beck이 한 말 중에서 많이 와닫는 점은 두려움이 지루함으로 바뀔 때까지 테스트를 작성하라는 말입니다.

테스트는 막연한 불안을 구체적이고 다룰 수 있는 작업으로 바꿈으로써,
까다롭고 모호한 요구사항 앞에서 테스트를 작성하는 행위가
명확하고, 강제적이고, 구체적인 과제로 전환되는 거라고 생각합니다.

즉, 첫번째 이유는 겁먹지 않고 일하기 위해서라고 생각합니다.

2. 구현에 대한 빠른 피드백 제공

내가 결정하고 설계한 내용을 코드로 옮겼다면 테스트 코드는 그 기능 구현한 것에 대한 피드백을 제공해준다고 생각합니다.
불확실한 사실들과 결과를 테스트 코드로써 증명해주고
즉각적이고 객관적인 근거로 대체된다고 생각합니다.

머리로 생각하고 수동으로 검증하는 시간을 줄여서 빠른 피드백을 통해 구현 검증 받을 수도 있다고 생각합니다.

3. 코드에 대한 변경 보호

내가 이 기능 구현에 대한 테스트 코드를 작성을 했다면 내가 보호해야 할 기능들에 대해 테스트가 보호하고 있기 때문에
리팩터링이나 변경이 이루어 지더라도, 두렵지 않고 확인있게 진행할 수 있게 해준다고 생각합니다.

4. 문서로써 명세화의 효과

코딩 개발은 혼자 진행하는 것이 아니라고 생각합니다.

다른 사람들이 같이 개발을 하면서 내가 구현한 기능에 대한 테스트 코드를 통해 나의 구현 의도와 명세들을 명확히 표현할 수 있게 해준다고 생각합니다.

즉, 같이 일하는 사람들에게 내가 구현한 기능들에 대한 명세의 효과가 있다고 생각합니다.

[haeyoon1]

저는 테스트의 가장 중요한 목적은 변경에 대한 안전장치를 만드는 것이라고 생각합니다.

코드는 한 번 작성하고 끝나는 것이 아니라 계속 변경됩니다.
이때 테스트가 없다면 내가 수정한 코드가 기존 기능을 깨뜨렸는지 바로 알기 어렵습니다. 반면 테스트가 잘 작성되어 있다면, 누군가 작성해둔 코드에 제가 변경 사항을 만들었을 때 그 변경으로 인해 테스트가 깨지는 순간 “내 변경이 기존에 지켜져야 할 동작을 위반했을 수 있구나”를 빠르게 인지 후 수정할 수 있습니다.

따라서 테스트는 단순히 버그를 찾기 위한 도구라기보다, 코드가 변해도 반드시 유지되어야 하는 규칙과 기대 동작을 검증하는 장치라고 생각합니다.

예를 들어 비즈니스 로직 중에는 시간이 지나도 바뀌면 안 되는 조건들이 있습니다. 특정 상태에서는 주문이 취소되면 안 된다거나, 재고가 부족하면 결제가 진행되면 안 된다거나, 권한이 없는 사용자는 특정 기능을 실행할 수 없어야 하는 것들 등이 있습니다. 테스트는 이런 중요한 약속을 코드로 남기는 안전장치의 역할을 하는 것 같습니다!