[23.10.16] 테스트코드와 tdd에 대한 느낌

글의 목적

• 테스트에 대한 공부를 막 시작하는 시기에 내가 생각하는 테스트코드의 작성이유와 tdd에 대한 생각들이 나중에 어떻게 바뀌었을지 궁금해서 현재의 생각을 정리해두려는 목적.

본론

TDD

• TDD란 Test Driven Development의 약자로 '테스트 주도 개발'이라고 한다.
• 반복 테스트를 이용한 소프트웨어 방법론으로, 작은 단위의 테스트 케이스를 작성하고 이를 통과하는 코드를 추가하는 단계를 반복하여 구현한다.
  1. 실패하는 테스트 코드를 먼저 작성한다. (TDD)
  2. 테스트를 성공시키는 비즈니스 로직을 작성한다.

TDD에 대한 나의 생각

• 솔직히 말해서 아직은 완벽하게 이해하기 어렵다. 테스트코드를 먼저 작성하고 통과하는 코드를 비즈니스로직에 추가하는 방식이라는건데, 현재 내가 생각하는 테스트와는 조금 거리감이 느껴지는 방식이라고 생각이 든다.
• 그래서 장점들만 한번 추려보려고 한다.
  1. 미리 예외처리에 대한 부분을 명확하게 할 수 있을 것 같다.
  2. 기획을 구현하고 설계하는 부분에 대한 팀단위에 단단함이 생길것 같다.
  3. 장기적으로 보면 생산성이 올라가나...? 아직 경험해보지 못했지만 30:70으로 올라갈 것 같다. 그 이유는 문제의 원인을 test코드에서 바로 파악할 수 있기 때문에 30:70이라고 생각한다.
  4. 추가적인 문서화에 시간과 노력이 줄어들것 같다.
• 단점들이 계속 생각나기 때문에 적어보려고 한다.
  1. 어쩔수 없는 초기 생산성 저하.
  2. 모든 test로직이 정말 비즈니스로직을 test할까? mocking으로 후두려 패면 그게 test인가? 비즈니스로직을 복붙해와서 test하는게 test인가?

const sum = (a, b) => {
  return a + b;
};
const sumMock = jest.fn((a, b) => a + b);
// 1번
it("sum / a와 b를 인자로 넣으면 두 인자의 합이 리턴됨.", () => {
  const a = 2;
  const b = 3;
  const result = sum(a, b);
  expect(result).toBe(a + b);
});
// 2번
it("sum / a와 b를 인자로 넣으면 두 인자의 합이 리턴됨.", () => {
  expect(sumMock(2, 3)).toBe(5);
});
// 3번
it("sum / a와 b를 인자로 넣으면 두 인자의 합이 리턴됨.", () => {
  expect(sum(2, 3)).toBe(5);
});

• 위에 코드를 보면 3가지 모두 sum을 테스트하는 방법은 맞다.
• 그리고 3가지 모두 테스트도 통과한다.
• 하지만 내가 생각하는 테스트는 3번이 그나마 맞다.
  1번은 정말 무의미하다. sum을 테스트하는데 sum을 사용하다니 그냥 비즈니스로직 복붙이다.
  2번은 괜찮다. 그렇지만 앞으로도 모든 테스트를 mocking하지 않을까? 이게 TDD랑 맞을까?
  3번은 test가 성공적으로 되었다.
• 그럼 이제 3번의 방식이 좋은 테스트라는 건데 이미 비즈니스로직을 완성했는데 이게 TDD가 맞을까? 라는 생각이 든다. 아! TDD는 동료 개발자에 대한 Docs를 제공하면서 하는 개발인건가!?? 선 docs를 제작하고 docs에 맞게 개발한다인건가 test를 레퍼런스로 로직을 완성하는것인가

test

• 현재 내가 작성하고 있는 test는 jest를 이용한 test이다.
• 따라서 test의 정의는 설명과 기대하는것, 기대하는값이 jest를 통과하는것 이라고 정의하겠다.

test에 대한 나의 생각

• 테스트는 독립적이어야 한다. 테스트를 수정했는데 다른 테스트의 영향을 준다면 테스트수정하다가 야근할 것 같다.
• test는 비즈니스 로직으로 test하는게 아니다. 이 테스트는 그 누구에게도 도움이 되지 않을것 같다.
• test는 많이할수록 좋다. 로직이 단단해지는것 뿐만 아니라 테스트를 공유하는 팀 전체가 단단해질것 같다.
• 나중에는 방대한 양의 테스트를 효율적으로 컴파일해주는 도구도 나오지 않을까? 이미 있나?
• 테스트 도구를 공부하는 것과 테스트 자체를 이해해야하는 러닝커브가 조금 있다.....고 생각한다.

결론

• test코드 만큼은 정말 test를 잘하는 리더가 통일시켜줬으면 좋겠다.
• 현재 나의 생각이 리팩터링2판을 읽고 어떻게 달라질지 기대가 된다.
• 현재 객체와 class에 대해서 공부를 해보려고 하는데 객체지향에서의 복잡한 테스트는 어떻게 다뤄야할지에 대한 부분도 나의 생각을 정리해보고 싶다.
• 테스트는 독립적이어야 한다는 생각은 결국 모든 레이어층의 비즈니스로직을 유닛테스트로 테스팅할 수 있다는 의미이고 이 생각이 맞는 생각일지 궁금하다. 통합테스트는 유닛테스트와는 또 다르다고 생각하는 현재이다.
• jest의 mock 기능은 정말 놀라운데 mock으로 테스트하면 당연히 내가 이렇게 mocking했으니까 통과하겠지라는 생각이 든다. 이게 진짜 test인가?!???
• 일단 절대적으로 Repository의 메서드를 테스트할때 저 멀리 router부터 실행 안시켜도 되니까 너무 좋다.