TDD 장단점 - Bob martin 과 Jim Coplien 토론을 보고

TDD 장단점 - Bob martin 과 Jim Coplien 토론을 보고

https://www.youtube.com/watch?v=eRxc4PD6RN0

일단 Bob은 TDD 신봉 Jim은 정반대

• TDD 3가지 법칙
  • 실패하는 단위 테스트 작성 전까지는 한 줄의 상용 코드를 작성할 수 없다.
  • 실패하기에 충분한 양의 단위 테스트만 작성해야 한다. (컴파일이 안되는것도 실패에 해당)
  • 현댖 실패하는 테스트 코드들을 성공시킬 만큼만 상용 코드를 작성해야 한다.
    • 즉 지금 실패하는 코드에 해당하는것 이상의 코드는 작성할 수 없다는 것

위의 내용은 30초단위로 실패코드-상용코드를 한꺼번에 작성한다는것을 의미한다.

• TDD의 2가지 문제(Jim이 경험한)
  • 아키텍처나 프레임워크 없이 TDD를 사용한다.
    • kent(아마 켄트백?) 이 얘기한 내용중 TDD를 사용해 아키텍처를 이끌어야 한다는것.
      • 이거는 즉 하향식 아키텍처를 초래한다. 현재는 주체가 객체이고 절차를 테스트하는데 여기서 전체를 이용해 아키텍쳐를 구성한다면? 길을 잃고 리팩터링이 힘들다는것.(왜냐면 주체가 객체인데 다른 곳에서 아키텍쳐를 만드는거니까)
  • GUI를 망가뜨린다.
    • 절차적 아키텍처가 자바 클래스 래퍼 안에 들어가면서 구조를 도메인 지식이나 사용자 개념 모델에 따라 이끌어 갈 수 없다.

위의 3가지 법칙은 매우 좋은데, 이런 문제가 없다면 괜찮을 것이라고 생각한다.
-> 결국 여기서 얘기는 테스트를 하면서 구조를 만들어가는게 아키텍처를 구성하기 힘들다는것이 주제인것같음.

• Bob의 반박
  • 애자일 커뮤니티에 따르면 아키텍처를 할 필요가 없다(?)
    • 단지 더 많은 테스트와 스토리를 만들면 알아서 조립될 것이다.
      • 이거는 말도안된다고 한다(나도 그래)
  • 아키텍처가 한번에 만들어지지는 않는다.
    • 좋은 기술을 통해 여러번에 걸처 아키텍처를 만드는 것이다.
      • 그래서 다양한 실험을 하고나서 두세번의 반복이 지나면 좋은 아키텍처가 될 것이다.
        • 그게 실행되는 코드에 의해(+ 테스트)

그리고

• 여기서 Jim 반박 -> 도메인 지식 없이 고객과의 상호작용만으로 하려하면 잘못된 방향으로 갈 수 있다.
  • 예를들어 은행같은 경우 보이는게 다가 아니고 뒤에 복잡한 상호작용이 있는데 그거를 애자일하게 갈수 있느냐? 도메인 지식을 활용해서 미리 어떻게 할지 생각해둔다면 더 잘 접근할 수 있을 것이다.

그 다음에는 미리 구조를 잡아두는게 맞는지에 대한 얘기

• Bob : 나는 테스트를 하면서 만들어가고 미리 만드는건 하지 않겠다. 테스트하면서 자연스럽게 생길것
• Jimmy : 근데 우리는 명확하게 무엇을 만들지를 알고있으면 그걸 만들면 될것이다.

그다음은 프로페셔널에 대한 정의인데

• Bob : 프로페셔널하지 않은 개발자 -> 아무 테스트 코드 없이 그냥 배포하는사람 -> 그걸 방지하려면? TDD실천하기
• Jimmy : 전혀 동의하지 않고 더 중요한것은 계약에 의한 설계라는 생각이다. -> 사전,사후,불변 조건을 설정하는것. 이게 TDD의 장점을 다 가지고 있다는 생각이다. 그리고 계약은 인자의 전체 범위를 다루기 때문에 더 넓은 범위를 커버할 수 있다. 근데 테스트는 무작위로 흩뿌려서 하는거임. -> 근데 TDD는 그냥 유닛테스트 단위로 하기 때문에 API를 클래스 수준에서 비즈니스 중요성까지 추적하기가 매우 힘들다.

뭔가 얘기하다가 끊긴거 같은데

혼자 생각

나름대로 겪었던거랑 생각을 정리해 보면

• TDD의 장점
  • 적어도 내가 생각한 문제상황에 대해서는 막아줄 수 있다는 것.
    • 작은 단위로 테스트가 있고 그게 문제상황에 대한 것들이 많아서 코드가 많아질 때에 혹시 잘못된 동작을 하는걸 막을 수 있다는 장점이 있어보인다.
  • 클래스에 관련 로직을 넣을 수 있다(근데 장점인지 단점인지는 잘 모르겠음...)
• TDD의 단점(다른거랑 같이 언급하면)
  • 전체 로직에 대한 테스트를 하기가 쉽지않음(하나씩 조합하는거기는 한데 큰 단위는?)
  • 쓸데없는 코드가 늘어날 수 있다.
  • 뭔가 아키텍쳐 짤때 골때리는 경우가 많이 있긴했다.

개인적으로 TDD는 개발의 하방을 올리는 장점이 있고 뭔가 큰그림을 보기 어렵다는 느낌이 든다.
근데 좀 많이 공부하고 해봐야할것같다.
처음부터 TDD랑 OOP를 도입한 개발을 한다면 장점이 될 것 같고, 그거에 대한 도메인적 지식을 누군가 나중에 들어와서 파악하기는 좀 힘들것같은 느낌적인 느낌