자동화된 테스트를 수학 공식으로 나타내면 다음과 같을 것입니다.
자동화된 테스트의 핵심은 다음과 같습니다.
- 테스트 하려는 코드를 가져옵니다.
- 올바른 상태로 만들기 위한 작업을 수행합니다.
- 상태(또는 값)가 예상과 일치하는지 확인합니다.
위의 공식을 테스트 방정식이라고 해 보겠습니다. 이 방정식은 실제 테스트에서 다음과 같이 표현됩니다.
import { fetchUser } from './fetch-user.js';
test('fetches the user by id', async () => {
await expect(fetchUser('abc-123')).resolves.toEqual({ firstName: 'John' });
// fetchUser() 함수 + "abc-123"와 함께 호출 = 이 사용자 객체
});"이 세 가지 구성 요소는 모든 테스트를 구성하는 세 단계이기도 합니다."
실제로 테스트하는 코드는 더 큰 시스템의 일부로 존재하는 경우가 많습니다. 이러한 코드는 다른 코드에 의존하거나 테스트하려는 의도와 관련이 있기도 하고 없기도 한 사이드 이펙트를 유발할 수 있습니다.
예시로 fetchUser() 함수가 어떻게 구현됐는지 살펴보겠습니다.
import { toCamelCase } from './to-cammel-case.js'
export function fetchUser(id: string): Promise<User> {
const response = await fetch(`/user/${id}`)
const user = await response.json()
const normalizedUser = toCamelCase(user)
return normalizedUser
}이 함수에서는 몇 가지 일이 일어나고 있습니다.
- 먼저
/user/:id엔드포인트를 HTTP로 호출하여 사용자를 가져옵니다. - 그런 다음 응답의 본문을 JSON으로 읽어
user객체에 담습니다. - 마지막으로
user객체의 모든 키를 카멜 케이스로 정규화합니다.
이 모든 단계가 합쳐져 fetchUser() 함수가 됩니다. 방정식을 치환해보면 fetchUser() 함수를 각 부분의 합으로 대체할 수 있습니다.
이를 통해 이 테스트에 관련된 모든 부분을 완벽하게 파악할 수 있습니다. 각 부분은 고유한 로직을 제공하지만, 이를 올바른 순서로 조합하는 것은 fetchUser() 함수입니다.
이것이 왜 유용할까요? 왜냐하면...
"테스트 방정식의 모든 요소는 테스트 결과에 영향을 미칩니다."
테스트를 통해 얻을 수 있는 가장 큰 가치는 언제 테스트가 실패해야 하는지 아는 것입니다. fetchUser() 함수의 경우 다음과 같은 경우 테스트가 실패합니다.
- 네트워크 에러가 발생할 때 실패합니다. 어떤 이유로든
/user/:id에 대한 요청이 실패하면 종속 코드 중 어느 것도 올바르게 실행되지 않습니다. - 서버 응답. 서버가 JSON이 아닌 응답을 하거나, 예상한 객체가 아닌 응답(예: 에러)을 반환하면, 테스트에서 반환된 사용자는 예상한 사용자와 일치하지 않습니다.
toCammelCase()의 버그. 유틸리티 함수가user객체 키를 정규화하지 못하면 실제 사용자 객체가 여전히 예상한 객체와 일치하지 않습니다.
이 사실을 알기 때문에 테스트 실패 시점을 결정하는 것은 여러분께 달려있습니다. 이 결정은 테스트의 신뢰성과 테스트 중인 동작에 모두 영향을 미칩니다.
이 경우 가장 먼저 해야 할 일은 네트워크가 테스트 결과에 영향을 미치지 않도록 하는 것입니다. 서버의 작동 가능성 및 정확성은 테스트된 함수의 관심사가 아닙니다. 함수는 서버에 영향을 미치지 않으며 그 동작을 보장할 수 없습니다. 따라서 테스트 코드의 관심 밖에 있는 사항으로 인해 테스트가 실패해서는 안 됩니다.
이를 달성하는 일반적인 방법은 API 모킹을 사용하는 것입니다. 응답을 모킹함으로써 테스트 방정식에서 네트워크를 제거하고, 주어진 변수로 변환합니다. 이제 테스트에 실제로 영향을 미치는 유일한 요소는 fetchUser()의 로직과 toCammelCase()에 대한 종속성뿐입니다.
테스트 방정식에서 무언가를 제거할 때마다 테스트 경계를 설정합니다.
테스트 경계
"테스트 경계는 테스트에서 실행되는 테스트 시스템의 범위입니다."
테스트 경계는 코드에 가상의 선을 그어 그 선을 넘는 부분은 테스트에 중요하지 않다는 것을 알리는 역할을 합니다.
테스트 경계를 설정하는 시기와 방법을 아는 것은 모든 테스트의 핵심입니다.
잘못 설정하면 쉽게 깨지고 불안정한 테스트가 되며, 차라리 삭제하는 것이 나을 수도 있습니다. 반면, 올바르게 설정하면 테스트 대상과 테스트 실패가 가져오는 가치를 완벽하게 제어할 수 있습니다.
테스트 경계는 모킹과 필연적으로 연결됩니다. 사실 모킹의 핵심은 테스트에서 그 경계를 설정하기 위해 고안된 도구입니다.
"테스트한 코드에 대한 모킹은 대리석 블록에 끌을 대어 다듬는 것과 같습니다."
fetchUser() 테스트에서 네트워크를 제거하면 해당 테스트는 함수의 동작과 테스트 방정식의 나머지 멤버인 toCamelCase()에 대한 종속성에 초점을 맞출 수 있습니다. 또한 toCamelCase() 함수를 모킹하기로 결정한 경우 테스트의 렌즈를 더욱 좁혀서 이제 fetchUser()에서 올바른 단계와 그 순서만 확인합니다.
그리고 여기에 숨겨진 점이 있습니다.
"대리석을 너무 많이 깎아내면 아무것도 남지 않습니다."
테스트 경계는 테스트에서 중요하지 않은 것을 결정하는 데 도움이 되므로, 테스트 경계를 과도하게 설정하면 실제로는 아무것도 테스트하지 않아 아무것도 중요하지 않은 테스트가 됩니다. 이를 종종 오버모킹이라고 하는데, 이는 절대 도달하고 싶지 않은 상태입니다.
그렇다면 의문이 생깁니다. 어디에 선을 그어야 할까요?
테스트 경계를 어디에 설정할까요?
테스트하려는 코드와 테스트하고자 하는 내용에 따라 "제거할" 항목이 크게 달라집니다. 하지만 저는 "상황에 따라 다르다"는 대답을 싫어하기 때문에 어떤 상황에도 적용할 수 있는 몇 가지 적용 가능한 팁을 제공하려고 합니다.
실패 하지 않는 방법은 단언(Assertion)의 황금률을 따르는 것입니다.
"테스트는 시스템의 의도가 충족되지 않는 경우에만 실패해야 합니다."
코드의 의도와 관련이 없는 테스트 방정식의 멤버를 제거합니다. 함수가 ID로 사용자를 가져와야 하는 경우, 그 의도는 다음과 같습니다.
- 올바른 페이로드를 사용하여 올바른 엔드포인트에 요청합니다.
- 사용자 응답을 읽고 정규화하여 반환합니다.
당연히 경계를 그리는 부분은 요청과 그에 대한 응답입니다.
HTTP 요청, 사이드 이펙트(파일 시스템에 쓰기 또는 DOM과의 상호작용 등), 비결정적 값(날짜 또는 RNG 등)은 항상 모킹을 원하는 일반적인 것들 중 일부입니다.
이러한 문제를 해결하면 테스트 경계가 돋보기처럼 작동하게 되며, 테스트 경계를 설정하는 방식에 따라 어떤 종류의 테스트을 볼 수 있는지가 결정됩니다. 무슨 말인지 설명해드리겠습니다.
컴포넌트 B에 종속된 컴포넌트 A를 테스트하는 경우 선택의 여지가 있습니다. 해당 종속성을 그대로 두거나 모의 테스트를 할 수 있습니다. 어느 쪽이든 잘못된 선택은 아닙니다. 결과적으로 다른 테스트가 나올 뿐입니다. 종속성을 모킹한 단위 테스트에서 컴포넌트 A에 집중 하거나, 종속성은 그대로 두고 A와 B가 통신하는 방식이 중요하고 테스트 결과에 영향을 미치는 통합 테스트를 만들 수 있습니다.
결론
테스트를 할 때 테스트 경계가 주는 힘을 깨닫고 사랑하게 되기를 바랍니다. 원치 않는 코드를 제거하면서 중요한 동작이나 통합에 집중할 수 있도록 도와줍니다.
저는 다음 워크숍에서 자바스크립트의 현존하는 모킹 기법에 대해 자세히 알아볼 모킹 기법에 대한 워크숍을 준비 중입니다! 그때까지 경계, 모의 테스트, 테스트 전반에 관한 다양한 소식을 계속 전해드리겠습니다.
좋은 테스트 작성하시길, 안녕히 계세요! 👋
🚀 한국어로 된 프런트엔드 아티클을 빠르게 받아보고 싶다면 Korean FE Article(https://kofearticle.substack.com/)을 구독해주세요!
