테스트란 무엇인가?
테스트는 광범위한 용어이며, 결국에는 일반적으로 무언가가 의도한 대로 작동하는지 확인하는 것을 의미합니다.
그리고 소프트웨어를 작성하거나 웹사이트를 구축할 때, 결국에는 소프트웨어를 작성하는 것이므로 일반적으로 소프트웨어나 구축 중인 웹사이트가 예상대로 작동하는지 테스트하고 싶습니다. 물론 이를 검증할 수 있습니다.
수동 테스트를 통해 소프트웨어나 웹사이트를 테스트할 수 있지만 수동 테스트에는 몇 가지 단점이 있으므로 수동 테스트 외에도 자동 테스트를 수행할 수 있습니다. 수동 테스트는 예를 들어 데모 웹사이트를 구축하는 동안 시스템에서 로컬로 방문한다는 의미입니다. 따라서 개발 서버를 가동하고 작업하는 동안 웹사이트를 테스트하고 사이트에서 작업하는 동안 다양한 기능을 테스트할 수 있습니다.
이 작업은 매우 중요하고 반드시 해야 하는 작업이며 피해야 하는 작업은 아니지만 물론 지루하고 번거로운 작업이기도 합니다. 특히 현재 작업 중인 기능만 테스트하는 것이 아니라 작은 변경을 할 때마다 모든 기능과 웹사이트를 사용하는 다양한 방법을 항상 테스트해야 한다면 더욱 번거롭습니다. 물론 웹사이트의 한 부분을 변경했는데 그 변경으로 인해 다른 부분이 작동하지 않을 수도 있으므로 이러한 모든 가능한 시나리오를 테스트해야 할 수 있습니다.
모든 것을 테스트하지 않으면 작동이 중지된 부분을 놓치게 되고 이는 문제가 될 수 있습니다. 하지만 전체 사이트, 모든 기능 및 사이트와 관련된 모든 것을 테스트하기 시작하면 작은 변경을 할 때마다 해야 할 일이 많아집니다. 그래서 자동화된 테스트가 필요합니다. 자동화된 테스트를 사용하면 코드를 테스트하는 코드를 작성한다는 아이디어가 있습니다.
1. 수동 test
- 지루하고 번거로움
- 오류가 발생하기 쉬움
- 종종 불완전함 (모든 시나리오를 다루지 않음)
2. 자동화 test
- 초기에 노력이 필요하지만(테스트 작성), 그 이후에는 노력이 필요 없음
- 예측 가능하고 일관됨
- 높은/완전한 코드 및 시나리오 커버리지 달성 가능
개발 중 또는 새 기능을 추가할 때마다 실행되는 추가 코드를 작성하고, 이 코드는 사이트의 다양한 측면을 테스트하는 사전 정의된 테스트 목록을 항상 동일한 단계와 흐름에 따라 자동으로 실행합니다. 따라서 도구 상자에 자동화된 테스트를 추가하면 초기 설정 작업이 필요하고 처음에는 테스트 코드를 작성해야 하지만 그 이후에는 아무런 노력이 필요하지 않습니다. 수동 테스트의 경우 오류가 발생하기 쉽습니다.
웹사이트의 특정 부분을 테스트하는 것을 잊어버리기 쉽고, 항상 모든 것을 동일한 신뢰할 수 있는 방식으로 테스트한다는 보장이 없습니다. 특정 기능을 다른 시점에 다른 방식으로 테스트할 수도 있습니다. 자동화된 테스트를 사용하면 메인 코드를 테스트하는 코드를 작성하면 해당 코드가 항상 같은 방식으로 실행되고 항상 동일한 테스트를 수행하므로 예측 가능하고 일관성이 있습니다. 수동 테스트의 단점은 물론 특정 시나리오나 측면을 테스트하는 것을 잊을 수 있으므로 불완전한 경우가 많다는 단점도 있습니다.
자동화된 테스트를 사용하면 테스트를 정의하면 모든 테스트를 실행할 때 항상 해당 테스트가 실행되므로 높은 코드 커버리지를 달성하기가 훨씬 쉬우며 모든 종류의 다양한 시나리오를 테스트하기가 더 쉽습니다. 테스트하고 싶은 특정 시나리오나 사용자 행동이 있을 때마다 새 테스트를 작성하여 프로젝트에 추가하면 다음에 모든 테스트를 실행할 때 이 새 테스트도 포함될 수 있습니다.
따라서 자동화된 테스트는 프로젝트에 추가하는 것을 적극 고려해야 하며, 앞서 언급했듯이 수동 테스트를 대체하는 것은 아닙니다. 특히 현재 프로젝트를 진행 중이라면 수동 테스트도 중요하지만 수동 테스트만 해서는 안 됩니다. 대신 프로젝트에 자동화된 테스트를 추가해야 합니다.
1. 단위 테스트의 정의
- 애플리케이션의 가장 작은 빌딩 블록(주로 함수나 클래스)을 독립적으로 테스트하는 것입니다.
- 각 단위가 예상대로 작동하는지 확인합니다.
2. 단위 테스트의 목적
- 코드 변경 시 발생할 수 있는 문제를 빠르게 감지합니다.
- 수동 테스트의 필요성을 줄입니다.
- 전체 코드베이스를 효과적으로 커버할 수 있습니다.
3. 단위 테스트의 장점
- 코드 변경의 영향을 쉽게 확인할 수 있습니다.
- 자동화된 테스트로 시간을 절약합니다.
- 더 깨끗하고 좋은 코드 작성을 유도합니다.
4. 단위 테스트의 특징
- 개별 단위를 독립적으로 테스트합니다.
- 모든 단위가 제대로 작동하면 전체 앱도 작동해야 한다는 원칙에 기반합니다.
5. 주의사항
단위 테스트만으로는 충분하지 않을 수 있으며, 통합 테스트 등 다른 테스트 방법과 함께 사용해야 합니다.
1. 단위 테스트 외에도 통합 테스트와 엔드-투-엔드 (E2E) 테스트가 있습니다.
접근성 테스트 등 다른 종류의 테스트도 있지만, 이 세 가지가 가장 일반적이고 인기 있는 자동화 테스트 형태입니다.
2. 단위 테스트는 애플리케이션의 개별 구성 요소(함수, 클래스)를 독립적으로 테스트합니다.
3. 통합 테스트는 단위 테스트를 기반으로 하여 여러 구성 요소의 조합을 테스트합니다.
4. E2E 테스트는 특정 사용자 행동이나 API 인터페이스에 초점을 맞추어 전체 애플리케이션 기능을 테스트합니다.
5. 각 테스트 유형은 장단점이 있습니다
- 단위 테스트: 문제를 빠르게 찾을 수 있지만 실제 사용자 흐름을 무시합니다.
- 통합 테스트: 단위 조합을 테스트하지만 정확한 문제 위치를 찾기 어려울 수 있습니다.
- 엔드-투-엔드 테스트: 실제 사용자 행동을 테스트하지만 모든 가능한 행동을 커버하기 어렵고 문제 원인을 찾는 데 시간이 걸릴 수 있습니다.
6. 테스팅 피라미드 개념에 따르면 단위 테스트를 가장 많이, 그 다음 통합 테스트, 마지막으로 중요한 기능에 대한 엔드-투-엔드 테스트를 수행합니다. 하지만 이는 절대적인 규칙은 아닙니다.
단위 테스팅 (Unit Testing)
- 애플리케이션의 개별 빌딩 블록(함수, 클래스)을 테스트합니다.
- 각 빌딩 블록(단위)은 독립적으로 테스트됩니다.
- 모든 빌딩 블록이 작동하면 전체 앱이 작동한다고 가정합니다.
통합 테스팅 (Integration Testing)
- 빌딩 블록의 조합을 테스트합니다.
- 여러 단위가 함께 잘 작동하는지 확인합니다.
- 모든 단위가 독립적으로 작동하더라도 조합 시 문제가 발생할 수 있음을 인식합니다.
엔드-투-엔드 (E2E) 테스팅
- 전체 애플리케이션 흐름과 기능을 테스트합니다.
- 실제 사용자가 수행할 "실제" 작업을 테스트합니다.
- 사용자는 개별 단위가 아닌 앱과 그 기능을 사용한다는 점을 강조합니다.
테스트 주도 개발은 결국 테스트를 작성하기 위한 프레임워크 또는 철학이라고 할 수 있습니다.
테스트 중심 개발의 개념은 애플리케이션 코드를 먼저 작성한 다음 그 코드에 대한 테스트를 작성하는 것이 아니라 애플리케이션 코드를 작성하기 전에 첫 번째 테스트로 실패 테스트를 작성하는 것입니다. 결국 예상되는 동작을 정의한 다음 테스트해야 할 코드를 구현하고, 그 동작이 충족되어 테스트가 성공하도록 당연히 구현해야 합니다.
그런 다음 반복적으로 리팩터링하고 그 흐름을 반복해서 거치고, 새로운 동작을 추가하고 싶을 때마다 새 테스트를 작성하거나 새 단위 테스트를 먼저 작성한 다음 로직을 구현하고 그 후에 로직을 최적화하는 식으로 테스트를 작성할 수 있습니다.