InfoGrab DocsInfoGrab Docs

테스트 레벨

요약

이 다이어그램은 우리가 사용하는 각 테스트 유형의 상대적 우선순위를 보여줍니다. 안정성과 속도를 갖춘 테스트 커버리지를 달성하기 위해, 테스트 배분을 안내하는 테스트 피라미드를 사용합니다. 대부분의 테스트는 단위 레벨에서 이루어져야 하며, 레벨이 올라갈수록 테스트 수가 줄어들어야 합니다.

이 다이어그램은 우리가 사용하는 각 테스트 유형의 상대적 우선순위를 보여줍니다. e2e는 end-to-end를 의미합니다.

안정성과 속도를 갖춘 테스트 커버리지를 달성하기 위해, 테스트 배분을 안내하는 테스트 피라미드를 사용합니다.

대부분의 테스트는 단위 레벨에서 이루어져야 하며, 레벨이 올라갈수록 테스트 수가 줄어들어야 합니다. 최상단의 엔드투엔드 테스트는 실행 및 유지 비용이 가장 많이 듭니다. 따라서 전체 테스트에서 가장 작은 비율을 차지해야 합니다.

2025-02-03 기준, 레벨별 예상 테스트 분포는 다음과 같습니다:

테스트 레벨 Community Edition Enterprise Edition Community + Enterprise Edition
시스템 레벨 블랙박스 테스트 (엔드투엔드 또는 QA 테스트) 401 (0.14%) 303 (0.10%) 704 (0.24%)
시스템 레벨 화이트박스 테스트 (시스템 또는 기능 테스트) 8,362 (2.90%) 4,082 (1.41%) 12,444 (4.31%)
통합 테스트 39,716 (13.76%) 17,411 (6.03%) 57,127 (19.79%)
단위 테스트 139,504 (48.32%) 78,955 (27.35%) 218,459 (75.66%)

단위 테스트#

공식 정의: https://en.wikipedia.org/wiki/Unit_testing

이 유형의 테스트는 코드의 단일 단위(메서드)가 예상대로 동작하는지(입력이 주어졌을 때 예측 가능한 출력이 나오는지) 검증합니다. 이 테스트는 가능한 한 격리되어야 합니다. 예를 들어, 데이터베이스를 사용하지 않는 모델 메서드는 DB 레코드가 필요하지 않아야 합니다. 데이터베이스 레코드가 필요하지 않은 클래스는 가능한 한 스텁/더블을 사용해야 합니다.

코드 경로 테스트 경로 테스트 엔진 참고
app/assets/javascripts/ spec/frontend/ Jest 프론트엔드 테스트 가이드 섹션에서 자세히 설명합니다.
app/finders/ spec/finders/ RSpec
app/graphql/ spec/graphql/ RSpec
app/helpers/ spec/helpers/ RSpec
app/models/ spec/models/ RSpec
app/policies/ spec/policies/ RSpec
app/presenters/ spec/presenters/ RSpec
app/serializers/ spec/serializers/ RSpec
app/services/ spec/services/ RSpec
app/uploaders/ spec/uploaders/ RSpec
app/validators/ spec/validators/ RSpec
app/views/ spec/views/ RSpec
app/workers/ spec/workers/ RSpec
bin/ spec/bin/ RSpec
config/ spec/config/ RSpec
config/initializers/ spec/initializers/ RSpec
config/routes.rb, config/routes/ spec/routing/ RSpec
config/puma.example.development.rb spec/rack_servers/ RSpec
db/ spec/db/ RSpec
db/{post_,}migrate/ spec/migrations/ RSpec Rails 마이그레이션 테스트 가이드에서 자세히 설명합니다.
Gemfile spec/dependencies/, spec/sidekiq/ RSpec
lib/ spec/lib/ RSpec
lib/tasks/ spec/tasks/ RSpec
rubocop/ spec/rubocop/ RSpec
spec/support/ spec/support_specs/ RSpec

프론트엔드 단위 테스트#

단위 테스트는 가장 낮은 추상화 레벨에 있으며, 일반적으로 사용자가 직접 인지하기 어려운 기능을 테스트합니다.

%%{init: { "fontFamily": "GitLab Sans" }}%% graph RL accTitle: Frontend unit tests accDescr: Diagram showing how frontend unit tests work and test functionality

plain[Plain JavaScript];
Vue[Vue Components];
feature-flags[Feature flags];
license-checks[License Checks];

plain---Vuex;
plain---GraphQL;
Vue---plain;
Vue---Vuex;
Vue---GraphQL;
browser---plain;
browser---Vue;
plain---backend;
Vuex---backend;
GraphQL---backend;
Vue---backend;
backend---database;
backend---feature-flags;
backend---license-checks;

class plain tested;
class Vuex tested;

classDef node stroke-width:2px
classDef label stroke-width:0;
classDef tested stroke-width:2px,stroke-dasharray: 5, 5;

subgraph " "
tested;
mocked;
class tested tested;
end

단위 테스트를 언제 사용하나#

  • 내보낸(exported) 함수 및 클래스: 내보내진 항목은 여러 곳에서 다양한 방식으로 재사용될 수 있습니다. 공개 인터페이스의 예상 동작을 테스트로 문서화해야 합니다.

  • Vuex actions: 모든 Vuex action은 트리거되는 컴포넌트와 무관하게 일관된 방식으로 동작해야 합니다.

  • Vuex mutations: 복잡한 Vuex mutation의 경우, 문제 해결을 단순화하기 위해 Vuex 스토어의 다른 부분과 테스트를 분리해야 합니다.

단위 테스트를 언제 사용하지 않나#

  • 내보내지 않은(non-exported) 함수 또는 클래스: 모듈에서 내보내지 않은 항목은 비공개 또는 구현 세부 사항으로 간주될 수 있으며, 테스트할 필요가 없습니다.

  • 상수(Constants): 상수의 값을 테스트하는 것은 해당 값을 복사하는 것을 의미하며, 값이 올바른지에 대한 추가적인 신뢰 없이 불필요한 작업만 늘립니다.

  • Vue 컴포넌트: 계산된 속성, 메서드, 라이프사이클 훅은 컴포넌트의 구현 세부 사항으로 간주될 수 있으며, 컴포넌트 테스트에 의해 암묵적으로 커버되므로 별도로 테스트할 필요가 없습니다. 자세한 내용은 공식 Vue 가이드라인을 참고하세요.

단위 테스트에서 무엇을 목(mock)으로 처리하나#

  • 테스트 대상 클래스의 상태: 클래스의 메서드를 사용하는 대신 테스트 대상 클래스의 상태를 직접 수정하면 테스트 설정에서 부작용을 방지할 수 있습니다.

  • 기타 내보낸 클래스: 테스트 시나리오가 기하급수적으로 증가하는 것을 방지하기 위해 각 클래스는 격리된 상태에서 테스트되어야 합니다.

  • 매개변수로 전달되는 단일 DOM 요소: 전체 페이지가 아닌 단일 DOM 요소에 대해서만 동작하는 테스트의 경우, 전체 HTML 픽스처를 로드하는 것보다 해당 요소를 직접 생성하는 것이 비용이 적게 듭니다.

  • 모든 서버 요청: 프론트엔드 단위 테스트 실행 시 백엔드에 도달하지 못할 수 있으므로 모든 외부 요청을 목으로 처리해야 합니다.

  • 비동기 백그라운드 작업: 백그라운드 작업은 중지하거나 대기할 수 없으므로, 이후 테스트에서도 계속 실행되어 부작용을 일으킵니다.

단위 테스트에서 무엇을 목으로 처리하지 않나#

  • 내보내지 않은 함수 또는 클래스: 내보내지 않은 모든 항목은 모듈에 비공개인 것으로 간주될 수 있으며, 내보낸 클래스와 함수를 통해 암묵적으로 테스트됩니다.

  • 테스트 대상 클래스의 메서드: 테스트 대상 클래스의 메서드를 목으로 처리하면 실제 메서드가 아닌 목이 테스트됩니다.

  • 유틸리티 함수(순수 함수 또는 매개변수만 수정하는 함수): 함수에 상태가 없어 부작용이 없다면, 테스트에서 목으로 처리하지 않아도 안전합니다.

  • 전체 HTML 페이지: 단위 테스트에서 전체 페이지의 HTML을 로드하는 것은 테스트 속도를 저하시키므로 피해야 합니다.

프론트엔드 컴포넌트 테스트#

컴포넌트 테스트는 사용자 입력, 다른 컴포넌트에서 발생한 이벤트, 또는 애플리케이션 상태와 같은 외부 신호에 따라 사용자가 인지할 수 있는 단일 컴포넌트의 상태를 다룹니다.

%%{init: { "fontFamily": "GitLab Sans" }}%% graph RL accTitle: Frontend component tests accDescr: Diagram showing how component tests work

plain[Plain JavaScript];
Vue[Vue Components];
feature-flags[Feature flags];
license-checks[License Checks];

plain---Vuex;
plain---GraphQL;
Vue---plain;
Vue---Vuex;
Vue---GraphQL;
browser---plain;
browser---Vue;
plain---backend;
Vuex---backend;
GraphQL---backend;
Vue---backend;
backend---database;
backend---feature-flags;
backend---license-checks;

class Vue tested;

classDef node stroke-width:2px
classDef label stroke-width:0;
classDef tested stroke-width:2px,stroke-dasharray: 5, 5;

subgraph " "
tested;
mocked;
class tested tested;
end

컴포넌트 테스트를 언제 사용하나#

  • Vue 컴포넌트

컴포넌트 테스트를 언제 사용하지 않나#

  • Vue 애플리케이션: Vue 애플리케이션은 많은 컴포넌트를 포함할 수 있습니다. 컴포넌트 레벨에서 테스트하는 것은 너무 많은 노력이 필요합니다. 따라서 프론트엔드 통합 레벨에서 테스트합니다.

  • HAML 템플릿: HAML 템플릿은 마크업만 포함하며 프론트엔드 로직이 없습니다. 따라서 완전한 컴포넌트가 아닙니다.

컴포넌트 테스트에서 무엇을 목으로 처리하나#

  • 부작용(Side effects): 외부 상태를 변경할 수 있는 모든 것(예: 네트워크 요청)은 목으로 처리해야 합니다.

  • 자식 컴포넌트: 각 컴포넌트는 개별적으로 테스트되므로 자식 컴포넌트는 목으로 처리합니다. shallowMount()도 참고하세요.

컴포넌트 테스트에서 무엇을 목으로 처리하지 않나#

  • 테스트 대상 컴포넌트의 메서드 또는 계산된 속성: 테스트 대상 컴포넌트의 일부를 목으로 처리하면 실제 컴포넌트가 아닌 목이 테스트됩니다.

  • Vuex: 취약하고 거짓 양성인 테스트를 방지하기 위해 Vuex를 목으로 처리하지 않습니다. mutation을 사용하여 Vuex를 올바른 상태로 설정하세요. Vuex action이 아닌 부작용을 목으로 처리하세요.

통합 테스트#

공식 정의: https://en.wikipedia.org/wiki/Integration_testing

이 유형의 테스트는 실제 앱 환경(예: 브라우저)의 오버헤드 없이 애플리케이션의 개별 부분이 잘 함께 작동하는지 검증합니다. 이 테스트는 요청/응답 레벨(상태 코드, 헤더, 본문)에서 검증해야 합니다. 권한, 리다이렉션, API 엔드포인트, 렌더링되는 뷰 등을 테스트하는 데 유용합니다.

코드 경로 테스트 경로 테스트 엔진 참고
app/controllers/ spec/requests/, spec/controllers RSpec 레거시 컨트롤러 스펙보다 요청 스펙이 선호됩니다. API 엔드포인트에는 요청 스펙이 권장됩니다.
app/mailers/ spec/mailers/ RSpec
lib/api/ spec/requests/api/ RSpec
app/assets/javascripts/ spec/frontend/ Jest 아래에서 자세히 설명합니다.

프론트엔드 통합 테스트#

통합 테스트는 단일 페이지의 모든 컴포넌트 간 상호작용을 다룹니다. 추상화 레벨은 사용자가 UI와 상호작용하는 방식과 유사합니다.

MSW jest 통합 테스트와 사용 방법에 대한 자세한 내용은 MSW 통합 테스트 페이지를 참고하세요.

%%{init: { "fontFamily": "GitLab Sans" }}%% graph RL accTitle: Frontend integration tests accDescr: Diagram showing how integration tests work

plain[Plain JavaScript];
Vue[Vue Components];
feature-flags[Feature flags];
license-checks[License Checks];

plain---Vuex;
plain---GraphQL;
Vue---plain;
Vue---Vuex;
Vue---GraphQL;
browser---plain;
browser---Vue;
plain---backend;
Vuex---backend;
GraphQL---backend;
Vue---backend;
backend---database;
backend---feature-flags;
backend---license-checks;

class plain tested;
class Vue tested;
class Vuex tested;
class GraphQL tested;
class browser tested;
linkStyle 0,1,2,3,4,5,6 stroke-width:2px,stroke-dasharray: 5, 5;

classDef node stroke-width:2px
classDef label stroke-width:0;
classDef tested stroke-width:2px,stroke-dasharray: 5, 5;

subgraph " "
tested;
mocked;
class tested tested;
end

통합 테스트를 언제 사용하나#

  • 페이지 번들(app/assets/javascripts/pages/의 index.js 파일): 페이지 번들을 테스트하면 해당 프론트엔드 컴포넌트가 잘 통합되는지 확인할 수 있습니다.

  • 페이지 번들 외부의 Vue 애플리케이션: Vue 애플리케이션을 전체로 테스트하면 해당 프론트엔드 컴포넌트가 잘 통합되는지 확인할 수 있습니다.

통합 테스트에서 무엇을 목으로 처리하나#

  • HAML 뷰(대신 픽스처 사용): HAML 뷰를 렌더링하려면 실행 중인 데이터베이스를 포함한 Rails 환경이 필요하며, 프론트엔드 테스트에서는 이에 의존할 수 없습니다.

  • 모든 서버 요청: 단위 및 컴포넌트 테스트와 마찬가지로, 컴포넌트 테스트 실행 시 백엔드에 도달하지 못할 수 있으므로 모든 외부 요청을 목으로 처리해야 합니다.

  • 페이지에서 인지할 수 없는 비동기 백그라운드 작업: 페이지에 영향을 미치는 백그라운드 작업은 이 레벨에서 테스트해야 합니다. 그 외 모든 백그라운드 작업은 중지하거나 대기할 수 없으므로 이후 테스트에서도 계속 실행되어 부작용을 일으킵니다.

통합 테스트에서 무엇을 목으로 처리하지 않나#

  • DOM: 실제 DOM에서 테스트하면 컴포넌트가 의도된 환경에서 작동하는지 확인할 수 있습니다. DOM 테스트의 일부는 크로스 브라우저 테스트에 위임됩니다.

  • 컴포넌트의 속성 또는 상태: 이 레벨에서 모든 테스트는 사용자가 수행할 수 있는 작업만 수행할 수 있습니다. 예를 들어, 컴포넌트의 상태를 변경하려면 클릭 이벤트를 발생시킵니다.

  • Vuex 스토어: 페이지의 프론트엔드 코드를 전체로 테스트할 때 Vue 컴포넌트와 Vuex 스토어 간의 상호작용도 함께 커버됩니다.

컨트롤러 테스트에 대하여#

GitLab은 컨트롤러 스펙에서 요청 스펙으로 전환 중입니다.

이상적으로 컨트롤러는 가벼워야 합니다. 그러나 그렇지 않은 경우, 컨트롤러 테스트 대신 JavaScript 없이 시스템 또는 기능 테스트를 작성하는 것이 허용됩니다. 비대한 컨트롤러를 테스트하면 보통 다음과 같은 많은 스터빙이 필요합니다:

controller.instance_variable_set(:@user, user)

그리고 Rails 5에서 더 이상 사용되지 않는(deprecated) 메서드를 사용합니다.

시스템 레벨 화이트박스 테스트 (이전의 시스템/기능 테스트)#

공식 정의:

이 유형의 테스트는 GitLab Rails 애플리케이션(예: gitlab-foss/gitlab)이 브라우저 관점에서 예상대로 작동하는지 검증합니다.

참고 사항:

  • 애플리케이션 내부에 대한 지식이 여전히 필요합니다.

  • 테스트에 필요한 데이터는 일반적으로 RSpec 팩토리를 사용하여 직접 생성합니다.

  • 기대값은 종종 데이터베이스 또는 객체 상태에 대해 설정됩니다.

이 테스트는 다음의 경우에만 사용해야 합니다:

  • 테스트하려는 기능/컴포넌트가 작은 경우

  • 객체/데이터베이스의 내부 상태를 테스트해야 하는 경우

  • 더 낮은 레벨에서 테스트할 수 없는 경우

예를 들어, 특정 페이지의 브레드크럼을 테스트하려면 시스템 테스트를 작성하는 것이 적합합니다. 이는 단위 또는 컨트롤러 레벨에서 테스트할 수 없는 작은 컴포넌트이기 때문입니다.

정상 경로(happy path)만 테스트하되, 더 나은 테스트로 낮은 레벨에서 발견할 수 없었던 회귀(regression)에 대한 테스트 케이스를 반드시 추가하세요(예를 들어, 회귀가 발견된 경우 가능한 가장 낮은 레벨에서 회귀 테스트를 추가해야 합니다).

테스트 경로 테스트 엔진 참고
spec/features/ Capybara + RSpec 테스트에 :js 메타데이터가 있으면 브라우저 드라이버는 Selenium이고, 그렇지 않으면 RackTest를 사용합니다.

프론트엔드 기능 테스트#

프론트엔드 통합 테스트와 달리, 기능 테스트는 픽스처를 사용하는 대신 실제 백엔드에 요청을 보냅니다. 이는 데이터베이스 쿼리가 실행됨을 의미하며, 이 카테고리를 훨씬 더 느리게 만듭니다.

참고:

%%{init: { "fontFamily": "GitLab Sans" }}%% graph RL accTitle: Frontend feature tests accDescr: Diagram showing how feature tests work

plain[Plain JavaScript];
Vue[Vue Components];
feature-flags[Feature flags];
license-checks[License Checks];

plain---Vuex;
plain---GraphQL;
Vue---plain;
Vue---Vuex;
Vue---GraphQL;
browser---plain;
browser---Vue;
plain---backend;
Vuex---backend;
GraphQL---backend;
Vue---backend;
backend---database;
backend---feature-flags;
backend---license-checks;

class backend tested;
class plain tested;
class Vue tested;
class Vuex tested;
class GraphQL tested;
class browser tested;
linkStyle 0,1,2,3,4,5,6,7,8,9,10 stroke-width:2px,stroke-dasharray: 5, 5;

classDef node stroke-width:2px
classDef label stroke-width:0;
classDef tested stroke-width:2px,stroke-dasharray: 5, 5;

subgraph " "
tested;
mocked;
class tested tested;
end

기능 테스트를 언제 사용하나#

  • 백엔드가 필요하며 픽스처를 사용하여 테스트할 수 없는 사용 사례.

  • 페이지 번들의 일부가 아니지만 전역적으로 정의된 동작.

관련 참고 사항#

전체 환경이 로드되도록 테스트에 :js 플래그를 추가합니다:

scenario 'successfully', :js do
  sign_in(create(:admin))
end

각 테스트의 단계는 다음과 같이 (capybara 메서드)를 사용하여 작성됩니다:

find('.form-control').native.send_keys(:enter)

expect(page).to have_selector('.card')

시스템 테스트를 작성하지 않는 경우 고려#

낮은 레벨 컴포넌트가 잘 작동한다는 확신이 있다면(충분한 단위 및 통합 테스트가 있다면), 시스템 테스트 레벨에서 철저한 테스트를 중복으로 작성할 필요가 없습니다.

테스트를 추가하는 것은 매우 쉽지만, 테스트를 제거하거나 개선하는 것은 훨씬 더 어렵습니다. 따라서 너무 많은 (느리고 중복된) 테스트를 도입하지 않도록 주의해야 합니다.

이러한 모범 사례를 따라야 하는 이유는 다음과 같습니다:

  • 시스템 테스트는 헤드리스 브라우저에서 전체 애플리케이션 스택을 시작하기 때문에 실행 속도가 느리며, JS 드라이버를 통합할 때는 더욱 느려집니다.

  • 시스템 테스트가 JavaScript 드라이버로 실행되면, 테스트는 애플리케이션과 다른 스레드에서 실행됩니다. 이는 데이터베이스 연결을 공유하지 않으며, 실행 중인 애플리케이션이 데이터를 볼 수 있도록(그 반대도 마찬가지) 테스트가 트랜잭션을 커밋해야 함을 의미합니다. 이 경우 트랜잭션을 롤백하는 대신(다른 테스트 유형에서 사용하는 더 빠른 전략) 각 스펙 이후 데이터베이스를 잘라내야(truncate) 합니다. 이는 트랜잭션보다 느리기 때문에 필요한 경우에만 잘라내기를 사용해야 합니다.

시스템 레벨 블랙박스 테스트 (엔드투엔드 테스트)#

공식 정의:

GitLab은 GitLab Shell, GitLab Workhorse, Gitaly, GitLab Pages, GitLab Runner, GitLab Rails 등 여러 구성 요소로 구성됩니다. 이 모든 구성 요소는 Omnibus GitLab에 의해 구성 및 패키징됩니다.

QA 프레임워크와 인스턴스 레벨 시나리오는 코드베이스(특히 뷰)와 항상 동기화되도록 GitLab Rails의 일부입니다.

참고 사항:

  • 애플리케이션 내부에 대한 지식이 필요하지 않습니다.

  • 테스트에 필요한 데이터는 GUI 또는 API를 통해서만 생성할 수 있습니다.

  • 기대값은 브라우저 페이지와 API 응답에 대해서만 설정할 수 있습니다.

모든 새 기능에는 테스트 계획이 포함되어야 합니다.

테스트 경로 테스트 엔진 참고
qa/qa/specs/features/ Capybara + RSpec + 커스텀 QA 프레임워크 테스트는 해당 제품 카테고리 아래에 배치해야 합니다.

자세한 내용은 엔드투엔드 테스트를 참고하세요.

qa/spec에는 QA 프레임워크 자체의 단위 테스트가 포함되어 있으며, 애플리케이션의 단위 테스트나 엔드투엔드 테스트와 혼동하지 않도록 주의하세요.

스모크 테스트#

스모크 테스트는 언제든지(특히 사전 배포 마이그레이션 후) 실행될 수 있는 빠른 테스트입니다.

이 테스트는 UI를 대상으로 실행되며 기본 기능이 작동하는지 확인합니다.

자세한 내용은 스모크 테스트를 참고하세요.

GitLab QA 오케스트레이터#

GitLab QA 오케스트레이터는 GitLab Rails의 특정 버전에 대한 Docker 이미지를 빌드하고 이를 대상으로 엔드투엔드 테스트(Capybara 사용)를 실행하여 이 모든 구성 요소가 잘 통합되는지 테스트할 수 있는 도구입니다.

자세한 내용은 GitLab QA 오케스트레이터 README를 참고하세요.

EE 전용 테스트#

EE 전용 테스트는 동일한 구성을 따르지만 ee/spec 폴더 아래에 있습니다.

올바른 레벨에서 테스트하는 방법#

삶의 많은 것들과 마찬가지로, 각 테스트 레벨에서 무엇을 테스트할지 결정하는 것은 트레이드오프입니다:

  • 단위 테스트는 보통 비용이 저렴하며, 집의 기초처럼 생각해야 합니다: 코드가 올바르게 동작한다는 확신을 얻기 위해 필요합니다. 그러나 통합/시스템 테스트 없이 단위 테스트만 실행하면 큰 그림을 놓칠 수 있습니다!

  • 통합 테스트는 비용이 조금 더 들지만 남용하지 마세요. 많은 내부를 스터빙하는 통합 테스트보다 시스템 테스트가 종종 더 낫습니다.

  • 시스템 테스트는 (단위 테스트에 비해) 비용이 많이 들며, JavaScript 드라이버가 필요한 경우 더욱 그렇습니다. 속도 섹션의 가이드라인을 반드시 따르세요.

또 다른 관점은 "테스트 비용"에 대해 생각하는 것으로, 이 글에서 잘 설명하고 있으며, 기본 아이디어는 테스트 비용에 다음이 포함된다는 것입니다:

  • 테스트를 작성하는 데 걸리는 시간

  • 스위트가 실행될 때마다 테스트를 실행하는 데 걸리는 시간

  • 테스트를 이해하는 데 걸리는 시간

  • 테스트가 실패하고 기반 코드는 정상일 때 테스트를 수정하는 데 걸리는 시간

  • 경우에 따라, 코드를 테스트 가능하게 만들기 위해 코드를 변경하는 데 걸리는 시간.

프론트엔드 관련 테스트#

테스트하려는 동작이 전체 애플리케이션을 실행하는 데 들이는 시간의 가치가 없는 경우가 있습니다. 예를 들어, 스타일링, 애니메이션, 엣지 케이스, 또는 백엔드가 관여하지 않는 소규모 작업을 테스트하는 경우, 프론트엔드 통합 테스트를 사용하여 통합 테스트를 작성해야 합니다.

테스트 문서로 돌아가기

테스트 레벨

GitLab v19.1
원문 보기
요약

이 다이어그램은 우리가 사용하는 각 테스트 유형의 상대적 우선순위를 보여줍니다. 안정성과 속도를 갖춘 테스트 커버리지를 달성하기 위해, 테스트 배분을 안내하는 테스트 피라미드를 사용합니다. 대부분의 테스트는 단위 레벨에서 이루어져야 하며, 레벨이 올라갈수록 테스트 수가 줄어들어야 합니다.

이 다이어그램은 우리가 사용하는 각 테스트 유형의 상대적 우선순위를 보여줍니다. e2e는 end-to-end를 의미합니다.

안정성과 속도를 갖춘 테스트 커버리지를 달성하기 위해, 테스트 배분을 안내하는 테스트 피라미드를 사용합니다.

대부분의 테스트는 단위 레벨에서 이루어져야 하며, 레벨이 올라갈수록 테스트 수가 줄어들어야 합니다. 최상단의 엔드투엔드 테스트는 실행 및 유지 비용이 가장 많이 듭니다. 따라서 전체 테스트에서 가장 작은 비율을 차지해야 합니다.

2025-02-03 기준, 레벨별 예상 테스트 분포는 다음과 같습니다:

테스트 레벨 Community Edition Enterprise Edition Community + Enterprise Edition
시스템 레벨 블랙박스 테스트 (엔드투엔드 또는 QA 테스트) 401 (0.14%) 303 (0.10%) 704 (0.24%)
시스템 레벨 화이트박스 테스트 (시스템 또는 기능 테스트) 8,362 (2.90%) 4,082 (1.41%) 12,444 (4.31%)
통합 테스트 39,716 (13.76%) 17,411 (6.03%) 57,127 (19.79%)
단위 테스트 139,504 (48.32%) 78,955 (27.35%) 218,459 (75.66%)

단위 테스트#

공식 정의: https://en.wikipedia.org/wiki/Unit_testing

이 유형의 테스트는 코드의 단일 단위(메서드)가 예상대로 동작하는지(입력이 주어졌을 때 예측 가능한 출력이 나오는지) 검증합니다. 이 테스트는 가능한 한 격리되어야 합니다. 예를 들어, 데이터베이스를 사용하지 않는 모델 메서드는 DB 레코드가 필요하지 않아야 합니다. 데이터베이스 레코드가 필요하지 않은 클래스는 가능한 한 스텁/더블을 사용해야 합니다.

코드 경로 테스트 경로 테스트 엔진 참고
app/assets/javascripts/ spec/frontend/ Jest 프론트엔드 테스트 가이드 섹션에서 자세히 설명합니다.
app/finders/ spec/finders/ RSpec
app/graphql/ spec/graphql/ RSpec
app/helpers/ spec/helpers/ RSpec
app/models/ spec/models/ RSpec
app/policies/ spec/policies/ RSpec
app/presenters/ spec/presenters/ RSpec
app/serializers/ spec/serializers/ RSpec
app/services/ spec/services/ RSpec
app/uploaders/ spec/uploaders/ RSpec
app/validators/ spec/validators/ RSpec
app/views/ spec/views/ RSpec
app/workers/ spec/workers/ RSpec
bin/ spec/bin/ RSpec
config/ spec/config/ RSpec
config/initializers/ spec/initializers/ RSpec
config/routes.rb, config/routes/ spec/routing/ RSpec
config/puma.example.development.rb spec/rack_servers/ RSpec
db/ spec/db/ RSpec
db/{post_,}migrate/ spec/migrations/ RSpec Rails 마이그레이션 테스트 가이드에서 자세히 설명합니다.
Gemfile spec/dependencies/, spec/sidekiq/ RSpec
lib/ spec/lib/ RSpec
lib/tasks/ spec/tasks/ RSpec
rubocop/ spec/rubocop/ RSpec
spec/support/ spec/support_specs/ RSpec

프론트엔드 단위 테스트#

단위 테스트는 가장 낮은 추상화 레벨에 있으며, 일반적으로 사용자가 직접 인지하기 어려운 기능을 테스트합니다.

%%{init: { "fontFamily": "GitLab Sans" }}%% graph RL accTitle: Frontend unit tests accDescr: Diagram showing how frontend unit tests work and test functionality

plain[Plain JavaScript];
Vue[Vue Components];
feature-flags[Feature flags];
license-checks[License Checks];

plain---Vuex;
plain---GraphQL;
Vue---plain;
Vue---Vuex;
Vue---GraphQL;
browser---plain;
browser---Vue;
plain---backend;
Vuex---backend;
GraphQL---backend;
Vue---backend;
backend---database;
backend---feature-flags;
backend---license-checks;

class plain tested;
class Vuex tested;

classDef node stroke-width:2px
classDef label stroke-width:0;
classDef tested stroke-width:2px,stroke-dasharray: 5, 5;

subgraph " "
tested;
mocked;
class tested tested;
end

단위 테스트를 언제 사용하나#

  • 내보낸(exported) 함수 및 클래스: 내보내진 항목은 여러 곳에서 다양한 방식으로 재사용될 수 있습니다. 공개 인터페이스의 예상 동작을 테스트로 문서화해야 합니다.

  • Vuex actions: 모든 Vuex action은 트리거되는 컴포넌트와 무관하게 일관된 방식으로 동작해야 합니다.

  • Vuex mutations: 복잡한 Vuex mutation의 경우, 문제 해결을 단순화하기 위해 Vuex 스토어의 다른 부분과 테스트를 분리해야 합니다.

단위 테스트를 언제 사용하지 않나#

  • 내보내지 않은(non-exported) 함수 또는 클래스: 모듈에서 내보내지 않은 항목은 비공개 또는 구현 세부 사항으로 간주될 수 있으며, 테스트할 필요가 없습니다.

  • 상수(Constants): 상수의 값을 테스트하는 것은 해당 값을 복사하는 것을 의미하며, 값이 올바른지에 대한 추가적인 신뢰 없이 불필요한 작업만 늘립니다.

  • Vue 컴포넌트: 계산된 속성, 메서드, 라이프사이클 훅은 컴포넌트의 구현 세부 사항으로 간주될 수 있으며, 컴포넌트 테스트에 의해 암묵적으로 커버되므로 별도로 테스트할 필요가 없습니다. 자세한 내용은 공식 Vue 가이드라인을 참고하세요.

단위 테스트에서 무엇을 목(mock)으로 처리하나#

  • 테스트 대상 클래스의 상태: 클래스의 메서드를 사용하는 대신 테스트 대상 클래스의 상태를 직접 수정하면 테스트 설정에서 부작용을 방지할 수 있습니다.

  • 기타 내보낸 클래스: 테스트 시나리오가 기하급수적으로 증가하는 것을 방지하기 위해 각 클래스는 격리된 상태에서 테스트되어야 합니다.

  • 매개변수로 전달되는 단일 DOM 요소: 전체 페이지가 아닌 단일 DOM 요소에 대해서만 동작하는 테스트의 경우, 전체 HTML 픽스처를 로드하는 것보다 해당 요소를 직접 생성하는 것이 비용이 적게 듭니다.

  • 모든 서버 요청: 프론트엔드 단위 테스트 실행 시 백엔드에 도달하지 못할 수 있으므로 모든 외부 요청을 목으로 처리해야 합니다.

  • 비동기 백그라운드 작업: 백그라운드 작업은 중지하거나 대기할 수 없으므로, 이후 테스트에서도 계속 실행되어 부작용을 일으킵니다.

단위 테스트에서 무엇을 목으로 처리하지 않나#

  • 내보내지 않은 함수 또는 클래스: 내보내지 않은 모든 항목은 모듈에 비공개인 것으로 간주될 수 있으며, 내보낸 클래스와 함수를 통해 암묵적으로 테스트됩니다.

  • 테스트 대상 클래스의 메서드: 테스트 대상 클래스의 메서드를 목으로 처리하면 실제 메서드가 아닌 목이 테스트됩니다.

  • 유틸리티 함수(순수 함수 또는 매개변수만 수정하는 함수): 함수에 상태가 없어 부작용이 없다면, 테스트에서 목으로 처리하지 않아도 안전합니다.

  • 전체 HTML 페이지: 단위 테스트에서 전체 페이지의 HTML을 로드하는 것은 테스트 속도를 저하시키므로 피해야 합니다.

프론트엔드 컴포넌트 테스트#

컴포넌트 테스트는 사용자 입력, 다른 컴포넌트에서 발생한 이벤트, 또는 애플리케이션 상태와 같은 외부 신호에 따라 사용자가 인지할 수 있는 단일 컴포넌트의 상태를 다룹니다.

%%{init: { "fontFamily": "GitLab Sans" }}%% graph RL accTitle: Frontend component tests accDescr: Diagram showing how component tests work

plain[Plain JavaScript];
Vue[Vue Components];
feature-flags[Feature flags];
license-checks[License Checks];

plain---Vuex;
plain---GraphQL;
Vue---plain;
Vue---Vuex;
Vue---GraphQL;
browser---plain;
browser---Vue;
plain---backend;
Vuex---backend;
GraphQL---backend;
Vue---backend;
backend---database;
backend---feature-flags;
backend---license-checks;

class Vue tested;

classDef node stroke-width:2px
classDef label stroke-width:0;
classDef tested stroke-width:2px,stroke-dasharray: 5, 5;

subgraph " "
tested;
mocked;
class tested tested;
end

컴포넌트 테스트를 언제 사용하나#

  • Vue 컴포넌트

컴포넌트 테스트를 언제 사용하지 않나#

  • Vue 애플리케이션: Vue 애플리케이션은 많은 컴포넌트를 포함할 수 있습니다. 컴포넌트 레벨에서 테스트하는 것은 너무 많은 노력이 필요합니다. 따라서 프론트엔드 통합 레벨에서 테스트합니다.

  • HAML 템플릿: HAML 템플릿은 마크업만 포함하며 프론트엔드 로직이 없습니다. 따라서 완전한 컴포넌트가 아닙니다.

컴포넌트 테스트에서 무엇을 목으로 처리하나#

  • 부작용(Side effects): 외부 상태를 변경할 수 있는 모든 것(예: 네트워크 요청)은 목으로 처리해야 합니다.

  • 자식 컴포넌트: 각 컴포넌트는 개별적으로 테스트되므로 자식 컴포넌트는 목으로 처리합니다. shallowMount()도 참고하세요.

컴포넌트 테스트에서 무엇을 목으로 처리하지 않나#

  • 테스트 대상 컴포넌트의 메서드 또는 계산된 속성: 테스트 대상 컴포넌트의 일부를 목으로 처리하면 실제 컴포넌트가 아닌 목이 테스트됩니다.

  • Vuex: 취약하고 거짓 양성인 테스트를 방지하기 위해 Vuex를 목으로 처리하지 않습니다. mutation을 사용하여 Vuex를 올바른 상태로 설정하세요. Vuex action이 아닌 부작용을 목으로 처리하세요.

통합 테스트#

공식 정의: https://en.wikipedia.org/wiki/Integration_testing

이 유형의 테스트는 실제 앱 환경(예: 브라우저)의 오버헤드 없이 애플리케이션의 개별 부분이 잘 함께 작동하는지 검증합니다. 이 테스트는 요청/응답 레벨(상태 코드, 헤더, 본문)에서 검증해야 합니다. 권한, 리다이렉션, API 엔드포인트, 렌더링되는 뷰 등을 테스트하는 데 유용합니다.

코드 경로 테스트 경로 테스트 엔진 참고
app/controllers/ spec/requests/, spec/controllers RSpec 레거시 컨트롤러 스펙보다 요청 스펙이 선호됩니다. API 엔드포인트에는 요청 스펙이 권장됩니다.
app/mailers/ spec/mailers/ RSpec
lib/api/ spec/requests/api/ RSpec
app/assets/javascripts/ spec/frontend/ Jest 아래에서 자세히 설명합니다.

프론트엔드 통합 테스트#

통합 테스트는 단일 페이지의 모든 컴포넌트 간 상호작용을 다룹니다. 추상화 레벨은 사용자가 UI와 상호작용하는 방식과 유사합니다.

MSW jest 통합 테스트와 사용 방법에 대한 자세한 내용은 MSW 통합 테스트 페이지를 참고하세요.

%%{init: { "fontFamily": "GitLab Sans" }}%% graph RL accTitle: Frontend integration tests accDescr: Diagram showing how integration tests work

plain[Plain JavaScript];
Vue[Vue Components];
feature-flags[Feature flags];
license-checks[License Checks];

plain---Vuex;
plain---GraphQL;
Vue---plain;
Vue---Vuex;
Vue---GraphQL;
browser---plain;
browser---Vue;
plain---backend;
Vuex---backend;
GraphQL---backend;
Vue---backend;
backend---database;
backend---feature-flags;
backend---license-checks;

class plain tested;
class Vue tested;
class Vuex tested;
class GraphQL tested;
class browser tested;
linkStyle 0,1,2,3,4,5,6 stroke-width:2px,stroke-dasharray: 5, 5;

classDef node stroke-width:2px
classDef label stroke-width:0;
classDef tested stroke-width:2px,stroke-dasharray: 5, 5;

subgraph " "
tested;
mocked;
class tested tested;
end

통합 테스트를 언제 사용하나#

  • 페이지 번들(app/assets/javascripts/pages/의 index.js 파일): 페이지 번들을 테스트하면 해당 프론트엔드 컴포넌트가 잘 통합되는지 확인할 수 있습니다.

  • 페이지 번들 외부의 Vue 애플리케이션: Vue 애플리케이션을 전체로 테스트하면 해당 프론트엔드 컴포넌트가 잘 통합되는지 확인할 수 있습니다.

통합 테스트에서 무엇을 목으로 처리하나#

  • HAML 뷰(대신 픽스처 사용): HAML 뷰를 렌더링하려면 실행 중인 데이터베이스를 포함한 Rails 환경이 필요하며, 프론트엔드 테스트에서는 이에 의존할 수 없습니다.

  • 모든 서버 요청: 단위 및 컴포넌트 테스트와 마찬가지로, 컴포넌트 테스트 실행 시 백엔드에 도달하지 못할 수 있으므로 모든 외부 요청을 목으로 처리해야 합니다.

  • 페이지에서 인지할 수 없는 비동기 백그라운드 작업: 페이지에 영향을 미치는 백그라운드 작업은 이 레벨에서 테스트해야 합니다. 그 외 모든 백그라운드 작업은 중지하거나 대기할 수 없으므로 이후 테스트에서도 계속 실행되어 부작용을 일으킵니다.

통합 테스트에서 무엇을 목으로 처리하지 않나#

  • DOM: 실제 DOM에서 테스트하면 컴포넌트가 의도된 환경에서 작동하는지 확인할 수 있습니다. DOM 테스트의 일부는 크로스 브라우저 테스트에 위임됩니다.

  • 컴포넌트의 속성 또는 상태: 이 레벨에서 모든 테스트는 사용자가 수행할 수 있는 작업만 수행할 수 있습니다. 예를 들어, 컴포넌트의 상태를 변경하려면 클릭 이벤트를 발생시킵니다.

  • Vuex 스토어: 페이지의 프론트엔드 코드를 전체로 테스트할 때 Vue 컴포넌트와 Vuex 스토어 간의 상호작용도 함께 커버됩니다.

컨트롤러 테스트에 대하여#

GitLab은 컨트롤러 스펙에서 요청 스펙으로 전환 중입니다.

이상적으로 컨트롤러는 가벼워야 합니다. 그러나 그렇지 않은 경우, 컨트롤러 테스트 대신 JavaScript 없이 시스템 또는 기능 테스트를 작성하는 것이 허용됩니다. 비대한 컨트롤러를 테스트하면 보통 다음과 같은 많은 스터빙이 필요합니다:

controller.instance_variable_set(:@user, user)

그리고 Rails 5에서 더 이상 사용되지 않는(deprecated) 메서드를 사용합니다.

시스템 레벨 화이트박스 테스트 (이전의 시스템/기능 테스트)#

공식 정의:

이 유형의 테스트는 GitLab Rails 애플리케이션(예: gitlab-foss/gitlab)이 브라우저 관점에서 예상대로 작동하는지 검증합니다.

참고 사항:

  • 애플리케이션 내부에 대한 지식이 여전히 필요합니다.

  • 테스트에 필요한 데이터는 일반적으로 RSpec 팩토리를 사용하여 직접 생성합니다.

  • 기대값은 종종 데이터베이스 또는 객체 상태에 대해 설정됩니다.

이 테스트는 다음의 경우에만 사용해야 합니다:

  • 테스트하려는 기능/컴포넌트가 작은 경우

  • 객체/데이터베이스의 내부 상태를 테스트해야 하는 경우

  • 더 낮은 레벨에서 테스트할 수 없는 경우

예를 들어, 특정 페이지의 브레드크럼을 테스트하려면 시스템 테스트를 작성하는 것이 적합합니다. 이는 단위 또는 컨트롤러 레벨에서 테스트할 수 없는 작은 컴포넌트이기 때문입니다.

정상 경로(happy path)만 테스트하되, 더 나은 테스트로 낮은 레벨에서 발견할 수 없었던 회귀(regression)에 대한 테스트 케이스를 반드시 추가하세요(예를 들어, 회귀가 발견된 경우 가능한 가장 낮은 레벨에서 회귀 테스트를 추가해야 합니다).

테스트 경로 테스트 엔진 참고
spec/features/ Capybara + RSpec 테스트에 :js 메타데이터가 있으면 브라우저 드라이버는 Selenium이고, 그렇지 않으면 RackTest를 사용합니다.

프론트엔드 기능 테스트#

프론트엔드 통합 테스트와 달리, 기능 테스트는 픽스처를 사용하는 대신 실제 백엔드에 요청을 보냅니다. 이는 데이터베이스 쿼리가 실행됨을 의미하며, 이 카테고리를 훨씬 더 느리게 만듭니다.

참고:

%%{init: { "fontFamily": "GitLab Sans" }}%% graph RL accTitle: Frontend feature tests accDescr: Diagram showing how feature tests work

plain[Plain JavaScript];
Vue[Vue Components];
feature-flags[Feature flags];
license-checks[License Checks];

plain---Vuex;
plain---GraphQL;
Vue---plain;
Vue---Vuex;
Vue---GraphQL;
browser---plain;
browser---Vue;
plain---backend;
Vuex---backend;
GraphQL---backend;
Vue---backend;
backend---database;
backend---feature-flags;
backend---license-checks;

class backend tested;
class plain tested;
class Vue tested;
class Vuex tested;
class GraphQL tested;
class browser tested;
linkStyle 0,1,2,3,4,5,6,7,8,9,10 stroke-width:2px,stroke-dasharray: 5, 5;

classDef node stroke-width:2px
classDef label stroke-width:0;
classDef tested stroke-width:2px,stroke-dasharray: 5, 5;

subgraph " "
tested;
mocked;
class tested tested;
end

기능 테스트를 언제 사용하나#

  • 백엔드가 필요하며 픽스처를 사용하여 테스트할 수 없는 사용 사례.

  • 페이지 번들의 일부가 아니지만 전역적으로 정의된 동작.

관련 참고 사항#

전체 환경이 로드되도록 테스트에 :js 플래그를 추가합니다:

scenario 'successfully', :js do
  sign_in(create(:admin))
end

각 테스트의 단계는 다음과 같이 (capybara 메서드)를 사용하여 작성됩니다:

find('.form-control').native.send_keys(:enter)

expect(page).to have_selector('.card')

시스템 테스트를 작성하지 않는 경우 고려#

낮은 레벨 컴포넌트가 잘 작동한다는 확신이 있다면(충분한 단위 및 통합 테스트가 있다면), 시스템 테스트 레벨에서 철저한 테스트를 중복으로 작성할 필요가 없습니다.

테스트를 추가하는 것은 매우 쉽지만, 테스트를 제거하거나 개선하는 것은 훨씬 더 어렵습니다. 따라서 너무 많은 (느리고 중복된) 테스트를 도입하지 않도록 주의해야 합니다.

이러한 모범 사례를 따라야 하는 이유는 다음과 같습니다:

  • 시스템 테스트는 헤드리스 브라우저에서 전체 애플리케이션 스택을 시작하기 때문에 실행 속도가 느리며, JS 드라이버를 통합할 때는 더욱 느려집니다.

  • 시스템 테스트가 JavaScript 드라이버로 실행되면, 테스트는 애플리케이션과 다른 스레드에서 실행됩니다. 이는 데이터베이스 연결을 공유하지 않으며, 실행 중인 애플리케이션이 데이터를 볼 수 있도록(그 반대도 마찬가지) 테스트가 트랜잭션을 커밋해야 함을 의미합니다. 이 경우 트랜잭션을 롤백하는 대신(다른 테스트 유형에서 사용하는 더 빠른 전략) 각 스펙 이후 데이터베이스를 잘라내야(truncate) 합니다. 이는 트랜잭션보다 느리기 때문에 필요한 경우에만 잘라내기를 사용해야 합니다.

시스템 레벨 블랙박스 테스트 (엔드투엔드 테스트)#

공식 정의:

GitLab은 GitLab Shell, GitLab Workhorse, Gitaly, GitLab Pages, GitLab Runner, GitLab Rails 등 여러 구성 요소로 구성됩니다. 이 모든 구성 요소는 Omnibus GitLab에 의해 구성 및 패키징됩니다.

QA 프레임워크와 인스턴스 레벨 시나리오는 코드베이스(특히 뷰)와 항상 동기화되도록 GitLab Rails의 일부입니다.

참고 사항:

  • 애플리케이션 내부에 대한 지식이 필요하지 않습니다.

  • 테스트에 필요한 데이터는 GUI 또는 API를 통해서만 생성할 수 있습니다.

  • 기대값은 브라우저 페이지와 API 응답에 대해서만 설정할 수 있습니다.

모든 새 기능에는 테스트 계획이 포함되어야 합니다.

테스트 경로 테스트 엔진 참고
qa/qa/specs/features/ Capybara + RSpec + 커스텀 QA 프레임워크 테스트는 해당 제품 카테고리 아래에 배치해야 합니다.

자세한 내용은 엔드투엔드 테스트를 참고하세요.

qa/spec에는 QA 프레임워크 자체의 단위 테스트가 포함되어 있으며, 애플리케이션의 단위 테스트나 엔드투엔드 테스트와 혼동하지 않도록 주의하세요.

스모크 테스트#

스모크 테스트는 언제든지(특히 사전 배포 마이그레이션 후) 실행될 수 있는 빠른 테스트입니다.

이 테스트는 UI를 대상으로 실행되며 기본 기능이 작동하는지 확인합니다.

자세한 내용은 스모크 테스트를 참고하세요.

GitLab QA 오케스트레이터#

GitLab QA 오케스트레이터는 GitLab Rails의 특정 버전에 대한 Docker 이미지를 빌드하고 이를 대상으로 엔드투엔드 테스트(Capybara 사용)를 실행하여 이 모든 구성 요소가 잘 통합되는지 테스트할 수 있는 도구입니다.

자세한 내용은 GitLab QA 오케스트레이터 README를 참고하세요.

EE 전용 테스트#

EE 전용 테스트는 동일한 구성을 따르지만 ee/spec 폴더 아래에 있습니다.

올바른 레벨에서 테스트하는 방법#

삶의 많은 것들과 마찬가지로, 각 테스트 레벨에서 무엇을 테스트할지 결정하는 것은 트레이드오프입니다:

  • 단위 테스트는 보통 비용이 저렴하며, 집의 기초처럼 생각해야 합니다: 코드가 올바르게 동작한다는 확신을 얻기 위해 필요합니다. 그러나 통합/시스템 테스트 없이 단위 테스트만 실행하면 큰 그림을 놓칠 수 있습니다!

  • 통합 테스트는 비용이 조금 더 들지만 남용하지 마세요. 많은 내부를 스터빙하는 통합 테스트보다 시스템 테스트가 종종 더 낫습니다.

  • 시스템 테스트는 (단위 테스트에 비해) 비용이 많이 들며, JavaScript 드라이버가 필요한 경우 더욱 그렇습니다. 속도 섹션의 가이드라인을 반드시 따르세요.

또 다른 관점은 "테스트 비용"에 대해 생각하는 것으로, 이 글에서 잘 설명하고 있으며, 기본 아이디어는 테스트 비용에 다음이 포함된다는 것입니다:

  • 테스트를 작성하는 데 걸리는 시간

  • 스위트가 실행될 때마다 테스트를 실행하는 데 걸리는 시간

  • 테스트를 이해하는 데 걸리는 시간

  • 테스트가 실패하고 기반 코드는 정상일 때 테스트를 수정하는 데 걸리는 시간

  • 경우에 따라, 코드를 테스트 가능하게 만들기 위해 코드를 변경하는 데 걸리는 시간.

프론트엔드 관련 테스트#

테스트하려는 동작이 전체 애플리케이션을 실행하는 데 들이는 시간의 가치가 없는 경우가 있습니다. 예를 들어, 스타일링, 애니메이션, 엣지 케이스, 또는 백엔드가 관여하지 않는 소규모 작업을 테스트하는 경우, 프론트엔드 통합 테스트를 사용하여 통합 테스트를 작성해야 합니다.

테스트 문서로 돌아가기