TDD - 켄트백 (2) 전략 &팁

InSeok·2023년 2월 8일
0

TDD

목록 보기
2/4

setup()

  • 일단 하드코딩을 한 다음에 상수를 변수로 대체하여 일반성을 이끌어 내는 방식으로 기능 구현
  • 여러 테스트에서 같은 객체를 사용한다면, 객체 하나만 생성해서 모든 테스트가 이 객체를 쓰게 할 수 있다.
  • 그러나, 테스트들이 객체를 공유하는 상태에서 하나의 테스트가 공유객체의 상태를 변경한다면 다음 테스트의 결과에 영향을 미칠 가능성이 있다.
    • ex) 테스트가 실행되는 순서에따라 결과가 달라지는 경우
  • 각 테스트 케이스마다 새로운 인스턴스를 SetUp 함으로써 두개이상의 테스트가 커플링될 가능성을 없앨 수 있다.
  • 가끔 setUP()에서 외부자원을 할당하는 경우가 있는데, 테스트를 계속 독립적으로 유지하려면 외부자원을 할당한다음 테스트들은 작업을 마치기전에 tearDown()같은 메서드에서 자원을 다시 반환해야한다.
  • setUp은 테스트 메서드가 실행되기전에 호출되어야 하고, tearDown은 테스트 메서드가 실행된 후에 호출되어야 하는데, 로그를 통해 메서드 호출 순서를 파악할 수 있다.

테스트를 확실히 돌아가게 만드는 세가지 접근법

- 가짜로 구현하기
- 명백하게 구현하기
- 삼각측량법

테스트 3A패턴

  1. 준비(arrange) - 객체를 생성한다.
  2. 행동(act) - 어떤 자극을 준다.
  3. 확인(assert) - 결과를 검사한다.
  • 테스트 전략
    • 테스트를 언제 해야하는가?
    • 테스트할 로직을 어떻게 고를 것인가?
    • 테스트할 데이터를 어떻게 고를 것인가?

테스트

  • 자동화된 테스트를 만들자.
  • 아무리 작은 변화라도 테스트를 하고 릴리즈하자.

격리된 테스트

  • 각각의 테스트는 다른 테스트와 완전히 독립적이어야 한다.
  • 테스트가 빨라서 내가 직접 자주 실행할 수 있게끔 만들자
  • 주어진 문제를 작은 단위로 분리하기 위해 노력해서 각 테스트를 실행하기 위한 환경을 쉽고 빠르게 세팅할 수 있게 해야 한다.
  • 테스트를 격리하기 위한 작업은 결과적으로 시스템이 응집도는 높고 결합도는 낮은 객체의 모음으로 구성되도록 한다.

테스트 목록

  • 시작하기전에 작성해야 할 테스트 목록을 모두 적어두자

    • 날짜 + 내용 + 작성자 이름 형식으로 Todo로 등록

    출처: https://cheese10yun.github.io/intellij-todo/

    Todo 전체 검색

  • Todo List 작성 추천

    1. 구현해야 할 것들에 대한 테스트 목록을 적는다.
    2. 구현할 필요가 있는 모든 오퍼레이션의 사용 예들을 적는다.
    3. 이미 존재하지 않는 오퍼레이션에 대해서는 해당 오퍼레이션의 널 버전을 리스트에 적는다.
    4. 마지막으로, 깔끔한 코드를 얻기 위해 이번 작업을 끝내기 전에 반드시 해야할 리팩토링 목록을 적는다.
  • 초록 막대상태에서 한번에 한개 만 수정하자. 몇단계 뛰어넘어서 한번에 큰 테스트를 하지말고

  • 제대로 작동하지 않는 테스트를 하나라도 생각할 수 있다면, 그걸 제대로 되게 하는것이 코드를 릴리즈하는 것보다 더 중요하다.

TDD 팁

  • 가짜구현을 한 뒤에 단계적으로 상수를 변수로 바꾸어 실제 구현으로 만들자.
  • 테스트가 실패했을때 좀 더 작은 스케일로 또 다른 테스트를 만들어서 실패한 테스트가 성공하게 만드는 것을 보조할 수 있다.
  • 작은 스케일의 테스트에서 보았던 메커니즘을 이용하여 큰 스케일의 테스트를 빠르게 통과시킬 수 있다.
  • 큰 설계아이디어를 다루다가 곤경에 빠질경우, 더 작은 작업을 수행하자.
  • 어떻게 설계해야할지 명백하지 않으면 가짜 구현을 하고 리팩토링을 하는식으로 접근하자
  • 가지고 있는 객체가 우리가 원하는 방식으로 동작하지 않을 경우에 그 객체와 외부 프로토콜이 같으면서 내부 구현은 다른 새로운 객체를 만들 수 있다.
  • 핵심이 되는 객체가 다른 부분에 대해서 될 수있는한 모르게 하면, 핵심객체가 가능한 오랫동안 유연해질 수 있다.
  • 클래스를 명시적으로 검사하는 코드가 있을때에는 다형성을 사용하여 제거할 수 있다.
  • 모든 중복이 제거되기 전까지는 테스트를 통과한 것으로 치지 않는다.
  • 필요할 거라고 생각한 인자를 빠르게 추가하자
  • 코드와 테스트 사이에 있는 데이터 중복을 끄집어내자.
  • 좁은 범위의 한정적인 테스트를 빠르게 작성한 후에 일반화함으로써 처음 코드 수정이 다음으로 계속해서 퍼져나갈 수 있게된다. 가지 → 뿌리
  • TDD에서 다루는 테스트는 성능테스트, 스트레스 테스트, 사용성 테스트와는 다르다.
  • 설계를 주도하기 위한 방법으로 테스트코드와 실제코드사이의 중복을 제거하기
  • 테스트 사이의 간격을 조절하기
profile
백엔드 개발자

0개의 댓글