TDD 정리

TDD란?(Test Driven Development)

TFD(Test First Development) + 리팩토링

-> 테스트 코드를 먼저 작성하고 프로덕션 코드를 작성하여 

     테스트 코드를 통과시킨 다음! 리팩토링을 하면 TDD이다.

 

TDD 사이클

1. 실패하는 테스트코드를 먼저 작성한다.

2. 테스트 코드가 성공하도록 프로덕션 코드를 구현한다.

3. 프로덕션 코드와 테스트 코드를 리팩토링 한다.

 

TDD의 장점

1. 변화에 대해 두렵지 않다. (중요)

-> 요구 사항이 변경 되었을 때, 그에 대한 테스트 코드를 먼저 추가하고

      테스트 코드를 만족하는 프로덕션 코드를 만들어 가는 것!

      리팩토링을 할 때도 테스트 코드는 이미 있기 때문에 심적으로 안정된 상태에서

      여러 방법으로 리팩토링을 시도해볼 수 있다.

      리팩토링은 가장 큰 재미이기 때문에 중요한 장점이다.

 

2. 한 번에 한가지 일에 집중할 수 있다.

-> Test Fails면 Test를 Pass시키는 것에 집중하고

    리팩토링할 차례면 리팩토링에만 집중할 수 있다.

 

3. 점진적으로 설계를 개선해 나갈 수 있다.

-> 처음부터 완벽한 설계를 한다면 과도한 설계에 따른 추가비용이 발생 될 것이다.

     TDD를 통해 점진적으로 설계를 개선한다면 추가비용을 해소할 수 있다!

 

4. 빠른 피드백을 통한 개발 효율 증대

-> 수동테스트를 하는 것보다 훨씬 버그를 찾는 시점이 빨라지고

    그로인해 일정한 리듬으로 일함으로써 프로그래밍에 재미를 느낄 수 있다!

 

5. 서비스 안전성이 높아진다.

-> 버그 발생 가능성이 줄어들고 코드 품질이 높아져 변화에 좀 더 빠르게 대응할 수 있다.

-> 수동 테스트, 배포에 대한 부담을 줄이면서 핵심 비즈니스 로직 구현에 집중할 수 있다.

 

6. 자연스럽게 객체지향적인 코드가 된다.

-> 테스트를 하기 좋은 코드를 짜기 위해서 void를 지양, 클래스 분리, 메소드를 분리 등등의 

    노력을 하다보면 자연스럽게 객체지향적인 코드가 된다!

 

 

TDD 단점

1. 변경이나 요구사항 추가 시 유지보수 해야 할 코드가 두배로 늘어난다.

   -> 요구사항이 변했는데, 테스트 코드에 변경해야할 게 많다면 중복되는 테스트가 많다는 것.

   -> 테스트 코드도 끊임없이 리팩토링으로 중복을 제거해주고 관리해줘야 한다.

 

2. 효과가 나타날 때까지 시간이 많이 필요하다.

  -> 6개월 ~~ 1년 ~~ 낭비라고 생각하지 마라. 빠르게 만드는 건 누구나 할 수 있다.

        어떻게 하면 유지보수를 잘하느냐가 더 중요한 시대.

 

 

TDD관련 팁

1. 테스트하기 어렵다면 설계가 잘못된 것이다.

  설계를 바꾸면 자연스럽게 테스트하기 좋은 코드가 된다,

 

2. 모든 코드를 테스트하지 않아도 되지만, 테스트 가능한 코드는 모두 테스트하자.

   최대한 테스트할 수 있도록 코드를 만들어라.

 

3. 테스트를 위해 privite을 바꿔야 할까?

   -> 설계가 잘못되었을 가능성, private를 다른 클래스로 이동해야 하는 건 아닌지 고민해봐라.

   -> 그 private을 사용하는 public을 통해 테스트를 하는 것도 고려해봐야 한다.

   -> 테스트를 하기 위해서 private를 때고 default 메소드로 만드는 것도 좋은 방법이다.

 

4.  TDD에 대한 자신만의 소신과 철학을 만들어라

 

5. 테스트 케이스를 만들 때 어떤 케이스가 다른 케이스를 커버하면 다 만들 필요 없다.

   경계값 테스트를 하고, 버그가 발생할 것 같은 부분을 테스트해라.

 

6. 모든 테스트에서 중복적으로 사용하는 것만 Fixture에 위치하는 것이 맞다.

   나머지는 각 TestCase에서 로컬 변수로 구현해라.

   하지만 반드시 모든 테스트에서 사용되야만 하는 것은 아니다. 효율성을 비교하여 유동적으로 위치시키자.

 

7. 단위테스트는 도메인에서 집중해야 한다.

    도메인에서 getter는 무조건 없앨 수 없다. 하지만 setter는 무조건 없앨 수 있다.

    DTO에서는 setter와 getter를 허용한다.

 

8. TDD를 한다고 설계를 안하는 것이 아니다. 

   리팩토링의 목적은 설계를 자주 하자는 것이다.

   할 수 있는데까지는 MVC패턴 기반으로 설계를 하자.

   도메인 설계가 가장 중요하다!

   초반에 완벽한 설계를 하겠단 생각을 버리고

   TDD를 하면서 점진적으로 완벽한 설계를 한다고 생각해라.

 

9. 테스트를 할 수 있는 부분만 분리해라.

    분리하는 것이 초보에게는 어렵다. 할 수 있는데까지 해보고 안되면

    리팩토링 시 설계를 개선하면 된다.

    ex) RandomNo클래스를 분리

 

10. getter보다 객체에게 메세지를 보내면 테스트하기 쉬워진다.

 

 

11. 인터페이스를 기반으로하면 더 유연한 설계가 가능하다.

     하지만 확장 가능 여부를 모르는 상태에서 인터페이스로 설계를 하는 것은

     오버 엔지니어링이다. 요구 사항이 계속 바뀌는 상태라면 

     인터페이스를 사용하면 빠르게 수정 및 반영이 가능하다.

     현재 요구사항에 맞는 최소한의 설계를 해라.

 

12. 인스턴스 만드는 과정이 복잡하면 팩토리라는 클래스를 통해서 만들 수 있다.

     팩토리 패턴에대해 공부하자.

 

13. 테스트는 랜덤으로 실행되기 때문에

     테스트간에 의존성이 있으면 안된다.

 

14. given, when, then은 처음에는 의미가 있다.

    나중에는 좋지 않은 습관이 될 수 있다.

     익숙해지면 제거해도 된다.

     when과 then이 하나로 갈 수도 있고

     빈 공백 라인으로 구분할 수도 있고 

     본인이 직접 결정하는 것이다.

 

15. Test들이 독립적으로 실행되기 위해

     BeforeEach로 각각 실행 시키는 것.