테스트의 종류
단위 테스트는 응용 프로그램에서 테스트 가능한 가장 작은 소프트웨어를 실행하여 예상대로 동작하는지 확인 하는 테스트
단위테스트에서 테스트 대상 단위의 크기는 엄격하게 정해져 있지 않습니다. 하지만 일반적으로 클래스 또는 메소드 수준으로 정하여 테스트합니다. 단위의 크기가 작을 수록 복잡성이 낮아집니다. 따라서 단위 테스트를 활용하여 동작을 표현하기 더 쉬워집니다. 즉, 테스트 대상 단위의 크기를 작게 설정해서 단위 테스트를 최대한 간단하고 디버깅하기 쉽게 작성해야 합니다.
소프트웨어를 개발할 때, 소프트웨어 내부 구조나 구현 방법을 고려하여 개발자 관점에서 테스트합니다. 그러므로 단위 테스트는 소프트웨어 내부 코드에 관련한 지식을 반드시 알고 있어야 하는 화이트박스 테스트입니다.
통합테스트는 단위 테스트보다 더 큰 동작을 달성하기 위해 여러 모듈들을 모아 이들이 의도대로 협력하는지 확인하는 테스트
통합테스트는 단위테스트와 달리 개발자가 변경할 수 없는 부분(ex. 외부 라이브러리)까지 묶어서 검증할 때 사용합니다. 이는 DB에 접근하거나 전체 코드와 다양한 환경이 제대로 동작하는지 확인하는데 필요한 모든 작업을 수행 할 수 있습니다. 그러나 통합테스트가 응용 프로그램이 완전하게 동작하는지를 무조건 증명하지는 않습니다.
통합테스트의 장점은 단위테스트에서 발견하기 어려운 버그를 찾을 수 있다는 점입니다. 한편 통합테스트의 단점은 단위 테스트보다 더 많은 코드를 테스트하기 때문에 신뢰성이 떨어질 수 있다는 점. 또한 어디에서 에러가 발생했는지 확인하기 쉽지 않아 유지보수가 힘들다는 점이 있습니다.
인수테스트는 사용자 스토리(시나리오)에 맞춰 수행하는 테스트
비즈니스쪽에 초점을 둔 테스트입니다. 프로젝트에 참여하는 사람들(ex. 기획자, 클라이언트 대표, 개발자 등)이 토의해서 시나리오를 만들고, 개발자는 이에 의거하여 코드를 작성합니다. 개발자가 직접 시나리오를 제작할 수도 있지만 다른 의사소통집단으로부터 시나리오를 받아(인수) 개발한다는 의미를 가지고 있습니다.
인수테스트는 애자일 개발 방법론에서 파생했습니다. 특히 익스트림 프로그래밍에서 사용하는 용어입니다. 이는 시나리오가 정상적으로 동작하는지를 테스트 하기 때문에 통합테스트와는 분류가 다릅니다. 시나리오에서 요구하는 것은 누가, 어떤 목적으로, 무엇을 하는가 입니다. 개발을 하다보면 이런 기능은 API를 통해 드러나는데 그렇기에 인수테스트는 주로 이 API를 확인하는 방식으로 이뤄집니다.
결국, 인수테스트는 소프트웨어 인수를 목적으로 하는 테스트입니다. 소프트웨어를 인수하기 전에 명세한 요구 사항(인수조건)대로 잘 작동하는지 검증을 합니다. 소프트웨어를 인수할 때, 소프트웨어 내부 구조나 구현 방법을 고려하기보다는 실제 사용자 관점에서 테스트하는 경우가 많다. 따라서. 인수테스트는 소프트웨어 내부 코드에 관심을 가지지 않는 블랙박스 테스트 입니다. 실제 사용자 관점에서 테스트 할 때 주로 E2E 형식을 이용해서 확인을 합니다.
테스트코드란?
소프트웨어의 제품 또는 서비스의 품질을 확인하거나 소프트웨어의 버그를 찾을 때 작성하는 코드를 말합니다.
테스트코드를 작성하는 이유
1.코드가 정상적으로 동작하는지 확인할 수 있다
코드를 작성하고 일일이 실행해보면 기능을 확인 하는 번거로움을 줄일 수 있습니다. 처음 코드를 작성하고 직접확인 하는 일은 크게 어렵지 않지만 코드의 수정사항이 발생하여 다시 테스트를 해야하는 일이 생기거나 코드를 작성후에 일정기간의 시간이 흐르고 나면 코드에 대한 기억이 사라지고 없기 때문에 테스트를 하는데 어려움을 겪습니다.
기능에 대한 명세를 작성하고 문서를 계속해서 최신화 한다면 비교적 간단히 테스트를 할 수 도 있지만 이것마저 쉬운일은 아닙니다. 테스트 코드는 기능코드의 가장 가까운 곳에서 가장 비슷한 언어로 쓰인 코드의 명세입니다. 테스트코드를 잘 작성하였다면 함수, 클래스, 인터페이스 등의 코드가 어떤 역할과 기능을 하는지 파악하는것이 아주 쉽습니다.
2. 코드의 결함을 사전에 발견할 수 있다.
여러가지 기능에 대한 테스트코드를 작성해 놓았다면 기존 코드를 잘못 작성 했을 때 오류가 발생하므로 결함을 사전에 발견할 수 있습니다.
3. 코드에 대한 의존성을 분리할 수 있다.
테스트 코드를 작성하면 기능 코드의 의존성을 쉽게 파악하고 분리할 수 있습니다. 테스트 케이스 환경에서는 같은 입력에 대해서는 같은 결과가 나와야 의미 있는 테스트입니다. 그렇게 하려면 기능 코드의 의존성을 제거하고 외부에서 주입하는 형태로 코드를 작성할 수 밖에 없습니다. 테스트 케이스 환경에서 그러한 의존성을 주입하여서 기능 코드의 의존성을 제어하는 것입니다.
신뢰할만한 테스트 코드를 작성하려면 기능 코드의 의존성을 파악하고, 테스트 환경에서 의존성을 주입하거나 적어도 제어 할 수 있는 방식으로 기능 코드를 작성하게 될 것입니다.
4. Refactoring을 부담없이 할 수 있다.
기존 코드를 다른 코드로 리팩토링 할 때 기존의 소스와 동일한 동작을 하는지에 대한 걱정을 줄일수 있습니다. 코드를 수정하고 테스트 코드를 실행했을 때 오류가 나지 않는다면 코드의 안정성을 확보 할수 있습니다.
5. 문서로 작용 할 수 있다.
테스트코드를 잘 작성해 놓으면 코드 작성자의 의도, 사용법, 주의사항 등이 드러나게 되어 별도의 문서가 없어도 문서화의 효과도 누릴수 있습니다.
Jest?
Jest는 페이스북에서 만들어진 ALL-IN-ONE 테스팅 라이브러리 입니다.
Jest 이전에 자바스크립트 코드를 테스트 하려면 여러가지 테스팅 라이브러리가 필요했었습니다. 예를들어 Mocha나 Jasmin을 Test runner로 사용하고 Chai 나 Expect와 같은 Test Mathcher를 사용하였고, Sinon과 Testdouble 같은 Test Mock 라이브러리도 필요하였습니다. 이러한 라이브러리들은 유사하지만 살짝씩 다른부분들이 있어서 개발자들에게 혼란을 야기하였습니다. 하지만 Jest는 Jest하나의 설치로 이러한 역할들을 모두 할수 있는 ALL-in-one 테스팅 라이브러리 입니다.
Jest 라이브러리 설치
npm 또는 yarn을 사용하여 Jest를 설치 합니다.
// npm
npm i -D jest
// yarn
yarn add --dev jest
script 추가
다음 내용을 package.json 에 추가하세요
// package.json
"scripts": {
"test": "jest"
}
해당 내용을 script에 추가하면 npm jest 혹은 yarn jest 를 터미널에 입력 함으로 jest 커멘드를 실행할 수 있습니다.
테스트 코드 작성
test("테스트 설명", () => {
expect("검증 대상").toXxx("기대 결과")
})
위와 같은 형식으로 테스트 코드를 작성할 수 있습니다. 간단한 테스트 코드를 작성해 보겠습니다.
test("1 is 1", () => {
expect(1).toBe(1)
})
위와 같이 작성하고 터미널에 npm jest 혹은 yarn jest 라고 입력하면 초록색 글씨로 테스트가 통과 했다는 메시지를 볼 수 있습니다.
> jest
PASS ./test.js
✓ 1 is 1 (1 ms)
Test Suites: 1 passed, 1 total
Tests: 1 passed, 1 total
Snapshots: 0 total
Time: 0.158 s, estimated 1 s
toBe 부분은 Test Matcher 라고 부르는데 여러가지 방법들이 있습니다. toBe 함수의 경우에는 숫자나 문자와 같은 객체가 아닌 기본형 값을 비교 할때 사용하는 Matcher입니다.
기본적으로 jest를 실행하면 프로젝트 내에 모든 테스트 파일을 찾아서 테스트를 실행해줍니다. test.js로 끝나거나 __test__ 디텍터리 안에 있는 파일들은 모두 테스트 파일로 인식합니다. 만약 특정 테스트 파일만 실행하고 싶을 경우에는 npm test <파일명 이나 경로> 를 입력하면 됩니다.
Reference
https://tecoble.techcourse.co.kr/post/2021-05-25-unit-test-vs-integration-test-vs-acceptance-test/https://jestjs.io/docs/getting-started
https://www.daleseo.com/jest-basic/
https://inpa.tistory.com/entry/JEST-%F0%9F%93%9A-jest-%EB%AC%B8%EB%B2%95-%EC%A0%95%EB%A6%AC
