테스트 코드란
작성한 코드에 문제가 없는지 테스트하기 위해 작성하는 코드
테스트 단위가 좀 더 쪼개질수록 어느 부분에서 에러가 발행했는지 좀 더 찾기가 쉬워진다.
테스트 코드의 종류
- 단위 테스트(유닛 테스트)
가장 작은 규모의 기능을 테스트
- 통합 테스트
여러 가지 기능을 합쳤을 때 생시는 문제를 방지하기 위한 테스트
- E2E 테스트(end-to-end 테스트)
백앤드부터 시작해서 최종적으로 웹페이지가 원하는 대로 동작하며 원하는 데이터를 잘 보여주는지 확인
TDD
Test Driven Development의 약자로 테스트 주도 개발이라고 한다.
작은 단위의 테스트 코드를 작성하고, 이를 통과하면, 코드를 추가하는 단계를 반복하여 구현
즉, 바로 코드를 작성하는 것이 아닌, 테스트 코드를 먼저 만들어 오류를 검증하고, 통과하면 코드를 작성하는 것
테스트 피라미드
아래부터 Unit Test(단위 테스트), Integration Test(통합 테스트), UI Test(E2E 테스트)가 위치한다.
아래에 위치할수록 적용이 쉽고 비용이 적고, 위로 올라갈수록 적용이 어렵고 비용이 많이 든다.
아래에 위치할수록 많은 테스트 코드를 작성하고, 위로 올라갈수록 실제로 돌아가는, 유저가 사용하는 영역이며, 실행 시간이 오래 걸리고, 유지보수, 디버깅 하기 더 어렵다.
유닛 테스트(단위 테스트)
가장 쉽고 코드가 짧고, 간단하며, 빠르게 적용이 가능한 테스트
함수에 인풋을 넣고, 기대했던 아웃풋이 나오는지 확인하는 식의 방법
각 컴포넌트 및 기능 단위의 동작을 검증
주로 애플리케이션의 로직들을 최대한 테스트하는 것이 중요하다.
통합 테스트
코드가 시스템과 어떻게 상호작용하는지 확인한다.
큰 코드 조각을 테스트하기 전에 개별 기능이 올바르게 작동하는지 확인하고자 사용한다.
유닛 테스트에서 검사한 기능들이 서로 간의 상호 연결이 되었을 때도 이상 없이 작동하는지 확인하는 사용 한다.
E2E 테스트
실제 유저가 보는 화면을 기준으로 하는 테스트
UI 또는 사용자 인터페이스 테스트는 앱의 사용자 단계 동작을 관찰한다.
테스트 코드의 이점
- 안정적인 코드
많은 테스트 코드를 거친 코드는 오류를 발견하고, 수정 및 보완을 했기 때문에 더욱 안정적인 코드가 된다.
- 디버깅 시간 단축
잘못된 데이터가 나온다면, UI 문제인지 DB의 문제인지 일일이 확인해야 하지만, 테스트 환경이 구축되어있다면, 자동화된 유닛 테스트로 특정 버그를 쉽게 찾아낼 수 있다.
- 전통적, 추상적 코드와 결별
테스트 코드를 사용하지 않는다면 직접 손으로 일일이 코드를 수정하고 확인하면서 번거로운 작업을 해야 하지만,
테스트 코드를 통해 전보다 논리적, 체계적, 경제적으로 오류를 바로잡고, 만들 수 있다.
- 테스트 커버리지, 통과율은 품질의 정량화의 척도
테스트를 통해 경과물의 안정성, 검증된 코드임을 증명할 수 있다.
테스트 커버리지를 통해 코드가 얼마만큼 테스트되었는지에 대한 내용 증명이 되기 때문에 코드의 품질과 개인의 전문성에 대해 증명할 수 있는 좋은 수단이 된다.
무엇이 좋은 테스트 방법인가?
이 것은 온전히 필자의 개인 생각이다.
좋은 테스트라는 것은 없다. 테스트 코드를 공부하고, 직접 코드를 만들어보면서 느낀 것은 상황에 맞게 사용하는 것 좋은 방법이라고 생각한다.
단위 테스트를 통해 오류를 검사할 수 있지만, 콘솔 로그를 통해 내가 짠 코드에 이상이 없는지 확인할 수도 있고,
테스트 코드를 작성하여 오류를 검사할 수도 있다. 그때의 상황에 맞는 방법으로 코드의 품질을 높이면 될 것 같다.
테스트를 한다고 가정하면, 단위 테스트부터 시작해서 통합 테스트, E2E 테스트로 가는 것이 좋을 것 같다.
사용자가 직접 사용하는 E2E 테스트가 좋은 것은 누구나 알지만, 그것을 구현하고 만드는 데엔 많은 시간과 노력이 필요하고, 변동성도 높기 때문에 정말 중요한 비즈니스 로직이라면 E2E 테스트까지 작성하는 것이 좋을 것 같다.
그 외의 작은 기능들은 단위 테스트를 진행하여 잘 동작하는지 확인하고
기능들이 모여서 상호작용을 알아야 한다면 통합 테스트를 사용해서 코드를 만드는 것이 좋다고 생각한다.
'coding > IT, CS' 카테고리의 다른 글
http https (0) | 2022.08.19 |
---|---|
Side effect, Decoupling, 디자인 패턴 (0) | 2022.08.10 |
마이크로 서비스 아키텍처 도메인 (0) | 2022.08.07 |
Restful API (0) | 2022.07.31 |
SQL과 NOSQL의 차이 (0) | 2022.07.25 |