TDD 테스트 주도 개발

2021.01.21 - [실전/Spring Boot & JPA] - 구현 (1) - 엔티티's

구현 (1) - 엔티티's

지난번에 추첨하기를 만들면서 TDD로 하다가 이도저도 아니게 되어버렸다. 원인이 무엇일까?

TDD에 대한 오해가 있었던 것 같아서 내 생각을 정리해 보려고 한다.

 

가. TDD

 a. 무엇인가?

  -  테스트 주도 개발은 테스트를 통한 비즈니스 로직을 구현하는 방법론이다.

 

 b. 간단하네? 

  -  개발할때 보통 로직을 구현하고 테스트 코드를 작성하는데 이거를 반대로 하면 되는게 아닐까?

      =>  반은 맞고 반은 틀리다. 단순히 테스트 코드를 미리 만드는게 TDD는 아니다.

 

 c. 정확히 뭔데?

  -  테스트 코드를 먼저 작성하는 것은 맞지만 어떻게 작성하는지가 중요하다.

  -  실패하는 최소한의 단위테스트로 작성을 해야한다.! 

  -  TDD의 단계

      1. 실패하는 테스트를 만든다.

      2. 당연히 실패한다.

      3. 성공하도록 로직을 만든다.

      4. 테스트를 실행해본다.

      5. 해당 테스트가 실패하거나 실패된 테스트들이 있으면 로직을 수정한다.

      6. 테스트가 성공하면 1번으로 돌아가자!

 

나. TDD가 잘 안됐던 이유

 a. 충분하지 못한 설계 

  -  이게 가장 큰 이유라고 생각하는데 TDD는 기존 사고 방식을 바꿔야 한다.

  -  보통 개발자들은 로직을 만들면서 설계해나가는 경우가 많다. 나는 특히 더 그런것 같다

  -  그러면 어떻게 미리 생각할 수 있느냐?  라는 의문이 들 수도 있다.

      => 전반적인 로직이 아닌 실패하는 최소한의 단위 테스트라는 것을 기억하자

  -  설계 및 테스트 시나리오를 구체적으로 만들자

      => 입력에 따라 과일이름을 리턴한다가 아닌 숫자 1이 들어오면 사과를 리턴한다처럼 구체적으로 만들기  

 

 b. 완벽한 테스트

  -  테스트는 무엇인가 테스트는 실패를 미리 찾아서 수정하는 것이지 성공만을 위한게 아니다.

  -  1~20개의 테스트를 순서대로 만든다고 한다면 순서상 이전의 테스트가 실패한다고 해서 잘못만든게 아니다.

  -  테스트를 완변하게 만들려고 하지말자! 테스트의 크기가 커지게 되면서 TDD의 의미를 잃게 된다. 

  

 

이렇게 정리해봤는데 내가 생각하기에 방법론은 큰 틀만 있을 뿐 누가 맞고 틀리다의 정답은 없는 것 같다.

이 방법론이 무엇때문에 나온 것인가를 깊이 생각해보면 옳바른 방향으로 개발할 수 있을 것 같다.

내가 생각하기에 TDD의 핵심은 모든 로직에 테스트가 있다는 것이 아닐까라는 생각이 든다.

로직을 만든 이후에 테스트 하려고하면 어디서부터 어디까지 테스트코드를 만들어야하는지 난감할때가 있고

의존성도 커져서 쉽게 테스트 하기가 어렵고 솔직히 만들지 않을때도 있다. 물론 테스트코드를 통해서

모든 운영상의 오류는 잡기 어렵다. 하지만 테스트를 만들지 않아 미리 예측할 수 있었던 오류가 발생하는 것은

오히려 더 큰 비용으로 돌아오니 열심히 테스트 코드를 작성 해야겠다.