테스트란, 우리가 작성한 코드가 잘 작동한다는 것을 검증하는 작업을 의미합니다. 우리가 화면에서 클릭해보고, 키보드로 입력해보면서 확인하는 것 또한 테스트입니다.
이렇게 수동으로 직접 해보는 것은 정말 번거로운 일입니다. 그래서 테스트 자동화라는 작업을 합니다. 사람이 직접 확인을 하는 것이 아니라 테스트를 하는 코드를 작성해서, 테스트 시스템이 자동으로 확인을 해줄 수 있게 하는 것이죠. 이를 테스트 자동화
라고 합니다.
테스트 코드를 작성했다고 프로젝트에서 버그가 발생하지 않는 것은 절대 아니다. 하지만, 버그가 발생하면 그 버그에 대해서 테스트 코드를 작성하게 되면 똑같은 실수를 하는 것을 방지할 수 있습니다.
유닛 테스트는 하나에 초점을 둔다면, 통합 테스트는 이름이 그러하듯 여러 요소들을 고려하여 작성합니다.
프로젝트의 기능을 잘게잘게 쪼개서 테스트를 하는 것이다.
기능들이 전체적으로 잘 작동하는지 확인하기 위해서 사용하는 것이다.
그냥 Test First. TFD(Test First Development).
테스트 케이스
를 먼저 작성하고 이후 그 테스트 케이스를 통과하는 구현체에 내용을 작성
한다, 즉 테스트가 개발을 주도한다.
일반적인 개발의 흐름을 보자면 우리는 구현체를 구현한 이후 선택적으로 테스트 코드를 작성한다. 쉽게 순서를 바꾸면 된다.
TDD 를 함으로써 구현체에 내용을 담기전 인터페이스, 즉 설계 관점
에서 여러 상황들을 열어두고 보게 되는데 이러한 열린 설계 방식이 안정성 높고 좀 더 확장성 높은 프로그램을 만드는데 도움을 준다. 실제 코드에 대한 명확한 처리를 설계함으로써 실제 구현체에서의 과도한 설계를 피할 수 있고, 간결한 인터페이스를 정의할 수 있다.
현재 나는 테스트를 작성해본 적도 드물다. 개발 흐름이 바뀌어 테스트 케이스를 먼저 작성한다고 하는데, 테스트 케이스를 작성하면 오히려 시간적인 비용이 더 소모된다고 느낄 수도 있을 것 같다. 하지만 프로젝트를 어느 정도 해보니까 백로그 작성, 기능 잘개 쪼개기 등 시간적인 비용이 더 소모된다고 느끼는 과정이 생산성을 향상 시켜주는 것을 경험했다. 이와 마찬가지로 TDD를 제대로 적용하면 협업, 리팩토링, 효율성과 같은 장점들이 많이 보인다. TDD를 적용할 때 나도 모르게 테스트 케이스보다 구현체로 넘어가 있을 것 같은데 테스트 케이스를 먼저 작성하는 것을 절대 놓치지 않아야 할 것이다.
https://velog.io/@hax0r/%EB%8B%A4-%ED%95%A8%EA%BB%98-TDD-u5v3zo6e
https://velog.io/@velopert/TDD%EC%9D%98-%EC%86%8C%EA%B0%9C