TDD, 이름하여 Test-Driven-Development
TDD란?
말 그대로 테스트 주도 개발 방식을 말한다.
- 개발자는 자동화된 테스트 케이스를 작성한다
- 테스트 케이스를 통과하기 위한 코드를 작성한다
- 마지막으로 작성 코드를 리팩토링한다
테스트는 크게 3가지로 나뉘는데,
unit test > intergration test > E2E test 가 그것.
사실 코드를 작성한 후에 테스트를 하는 것은 매우 중요하고 당연한 말이다. 이전에 얼핏 개발자 친구에게 들은 얘기로는, 테스트만 따로 하는 role도 있을 정도.
위키백과를 찾아보니 TDD를 제안한 Kent Beck은 훌륭한 TDD가 단순 설계를 장려하고 자신감을 준다고 했는데, 이것도 당연한 말인 듯.
이미지 출처: https://martinfowler.com/bliki/TestPyramid.html
1
가장 저렴하면서 효과적인, Unit test
개발자가 코드를 작성하고 스크립트에서 바로 실행할 수 있는 Test.
때문에 저렴하고 빠른 방법이다.
최소한의 코드를 작성해 테스트 케이스를 만들고 통과 여부를 확인한다.
regression test(과거에 테스트되었던 unit test를 반복 사용하는 것)를 가능하게해 유지/보수에도 활용도가 높다.
2
Integration test
작성된 클래스와 시스템의 결합을 테스트하는 것
현재와 같이 postman/httipie를 사용해서 테스트 돌리는 것을 말한다.
때문에 메소드 별로 통신했을 때, jsonresponse가 의도한 대로 잘 돌아오는지에 초점이 맞춰져 있다.
3
E2E test
End to End, 즉 front-end와 back-end 레벨에서 test하는 것.
만약 특정 카테고리 별 제품 list를 GET으로 조회하는 것이라면,
정보가 잘 response되고 브라우저 상에 잘 구현되는지까지 확인한다.
그래서 UI test라고도 부른다.
Then, what is BDD?
Behavior-Driven-Development의 약자로, 개발자-비개발자의 협업과 논의를 통해 기능을 완성해나가는 방식
- TDD에서 파생되었으며, ATDD(Acceptance-Test-Driven-Development)를 합친 개념
- ATDD는 기획 단계서부터 유관부서 관계자들이 모여 공통의 이해를 모색하는 것 (같은 얘기를 저마다 다르게 이해할 risk가 있기 때문에)
그래서 사실 위 2개 방법과 비교했을 때,
TDD는 클래스 단위(가장 작은 단위)의 테스트를 우선으로 깔고 가는 것이고 그러다보니 개발이 빠르고 효율적이다.
하지만 오히려 TDD를 사용했을 때 전체 생산성이 저하된다.
결국 테스트 코드와 main 코드 2개를 작성해야 하고,
계속 듀얼로 돌리면서 기능을 완성해야 하기 때문이다.
단위 별로 매번 저렇게 하다보면 deadline 맞추기가 아무래도 어려울 것이다.
또한 테스트 케이스가 모든 케이스를 cover한다고 장담할 수 없다.
게다가 TDD 또한 결국 비용이 드는 작업이라 모든 기업에서 적용할 수 없는 현실적인 문제 존재.
그럼에도 불구하고,
TDD 방법을 통해 독립적인 모듈을 작성하고 디버그가 어디서 일어나는지 쉽게 찾을 수 있다. 필요에 따라 특정 모듈을 제거해도 전체 소프트웨어에 미치는 영향이 최소화된다. (좀 더 객체지향적인 모듈이 만들어지므로)
유지/보수/확장에 유리하고, 테스트 코드 자체가 테스트 관련 문서를 대체할 수 있어 장점이 많은 개발 방법론이라고 할 수 있다.
참고 자료
http://clipsoft.co.kr/wp/blog/tddtest-driven-development-%EB%B0%A9%EB%B2%95%EB%A1%A0/
https://martinfowler.com/bliki/TestPyramid.html
https://architecture101.blog/2014/04/25/tdd-isnot-always-true/
