이 방법이 TDD가 맞나요?

친절한 답변 감사합니다!

그런데 TDD와 테스트 코드 작성 그 자체는 엄연히 다르다고 알고 있습니다.

테스트 주도 개발(Test-driven development TDD)은 매우 짧은 개발 사이클을 반복하는 소프트웨어 개발 프로세스 중 하나이다. 개발자는 먼저 요구사항을 검증하는 자동화된 테스트 케이스를 작성한다. 그런 후에, 그 테스트 케이스를 통과하기 위한 최소한의 코드를 생성한다. 마지막으로 작성한 코드를 표준에 맞도록 리팩토링한다. (위키피디아)

그런데 답글의 내용 중

실용적 TDD는 테스트 코드를 먼저 작성하던, 비즈니스 코드를 먼저 작성하던 결국에는 테스트 코드가 함께 해야한다는 것

이 부분을 보면 말씀하신 실용적 TDD는 테스트를 먼저 작성해야하는 TDD가 아니라, 그냥 테스트 코드 작성과 테스트 커버리지의 중요성에 대한 내용으로 생각됩니다. TDD가 아닌데 왜 실용적 "TDD"가 될까요?

혹시 원칙적 TDD와 실용적 TDD에 대한 내용을 어디서 볼 수 있을까요? 구글에 검색해도 뭐가 안 나오네용..

실용적 TDD에 대한 내용을 어디서 볼 수 있나요?

실무에서는 생산성이 중요하죠. 그에 맞춰 변화한 것이 실용적 TDD 또는 실용주의 TDD 입니다.

현업에서 발생하는 이슈기 때문에 구글링해도 안나오는게 맞습니다. 딱히 논란거리도, 재밌는 토론거리도 안되기 때문이죠.

https://youtu.be/eRxc4PD6RN0

실용적 TDD는 테스트를 먼저 작성해야하는 TDD가 아니라, 그냥 테스트 코드 작성과 테스트 커버리지의 중요성에 대한 내용으로 생각됩니다.

아니요! 테스트 코드를 먼저 작성해도 됩니다 🙂

그리고 테스트 커버리지는 중요하지 않습니다. 커버리지가 중요하다고 생각해 불필요한 테스트 코드까지 찍어내는 일은 절대로 절대로 있어선 안됩니다.

중요한 것은 테스트 코드를 잘게 잘게 쪼개어 내어도, 그 코드를 통해 정확히 기능의 동작을 확인할 수 있는가입니다. 즉, 유의미한 테스트 코드만 작성해라! 가 중요 포인트겠네요.

TDD가 아닌데 왜 실용적 "TDD"가 되나요?

우선 'TDD를 어떻게 하는가?' 라는 것은 중요하지 않다고 생각합니다. 테스트에 관심 있는 개발자들은 'TDD를 하는 목적이 무엇인가?'란 질문에 본인만의 답을 찾아야 한다고 생각해요.

제 답은 테스트 코드를 작성하는 목적 자체가 TDD를 하는 목적과 같다입니다. (하지만 TDD라고 하는 단어 자체는 중요하지 않습니다. )

우선 테스트 코드를 제대로 작성하지 않으면 어떻게 될까요?

단순히 "기능이 돌아가기만 하면 됐지!", "커버리지 높게 쳐주면 되는거 아니야?", "요구사항 만족했잖아?" 라는 마인드로 비즈니스 코드와 테스트 코드를 작성하면 그 서비스는 빠른 시일 내에 장애가 터질거고, 장애를 찾기 위해 버그 잡느라 시간을 많이 소비해서 고객 이탈이 발생할 겁니다.

또한 요구사항이 변경해 코드도 변경해야 하는 상황이 왔을 때라면, 위 3가지 마인드로 작성한 코드는 그냥 새로 개발하는게 더 빠를지도 모릅니다. 왜냐면 분명히 구조적으로 결함이 있을 수 밖에 없을 거거든요. (물론 새로 개발하는 것도 구조가 받쳐줘야 가능한 상황이 분명 있습니다.)

그럼 테스트 코드를 잘 작성하면 어떻게 될까요?

코드 구조가 테스트 가능성을 갖게 됩니다. 이 말은 프레임워크나 인프라 같은 예측 불가능한 요소들을 예측 가능하게 바꿔서 개발자가 원하는 결과를 쉽게 만든다는 것입니다. 그렇게 하면 테스트 코드가 실패한 다고 해서 불안해지지 않죠. 내가 만든 코드에서 버그를 찾으면 그만이거든요. 디버깅 자체가 쉬워집니다.

또한 제가 위에서 테스트 코드를 잘게 쪼개어 내어도, 기능이 정확히 동작함을 확인할 수 있어야 한다고 했습니다? A라는 기능을 A, B, C, E라는 기능으로 나눈 다음에 합쳐서 A라는 기능이 완성되도록 리팩토링 한 다음에 A 기능 전체를 테스트 하던, A, B, C, E 기능을 나누어 테스트 하던 결과가 동일해야 한다는 겁니다. 코드는 응집도를 높이고 결합도를 낮추게 되는거죠.

이 외에도 여러 장점들을 갖게 되죠. 여러 설계 방식을 지원하기 좋은 구조를 갖는다 던가, 테스트 코드 자체가 문서가 된다던가, 테스트 코드를 통해 빠른 피드백을 받게 된다던가, 유지보수성이 좋아진다던가 등등..

그런데 TDD를 공부하다 보면 이런 장점들이 제가 말한 테스트 코드를 작성해서 얻는 이점과 동일 하다는 게 보이지 않나요? ㅎㅎ. 결국에 테스트 코드를 작성하는 목적이 TDD의 목적과 일치해지면 결국 남는건 테스트 코드뿐이라는 겁니다.

아무튼 결론은 TDD <-- 단어와 행위 자체보단 목적에 무게중심을 두고 공부하자! 입니다.

아래 키워드를 몇 가지 드릴테니 공부해 보시고 본인만의 답을 찾을 수 있으면 좋겠습니다.

[클린 아키텍처, DDD, 객체지향 사실과 오해, 테스트 피라미드, Ci/CD]