1 - 테스트란 무엇이며 왜 테스트를 수행해야 합니까?

1장 테스트란 무엇이며 왜 테스트를 수행해야 합니까?

Written by Alex Jover Morales

소프트웨어 엔지니어링에서 테스트는 응용 프로그램의 모든 부분이 예상대로 작동하는지 평가하는 프로세스입니다.

테스트는 다른 입력이 주어졌을 때 수신된 출력이 사양과 일치하는지 확인하여 소프트웨어에 대한 검증을 수행합니다. 이러한 각 검증을 테스트 케이스 라고 합니다. 애자일 워크플로에서 각 사용자 스토리에는 일련의 테스트 사례가 있어야 합니다.

간단한 예:

US-01: 통화 입력 구성 요소 만들기

테스트 사례:

• TC-01: 숫자 만 허용해야 합니다.
  1. 숫자 “2”를 입력합니다. 예상됨: 괜찮을 것입니다.
  2. 문자 “a”를 입력합니다. 예상됨: “숫자만 허용됨” 메시지가 표시되어야 합니다.
• TC-02: 비워둘 수 없습니다
  …

테스트 케이스는 특정 기능의 요구 사항과 사양을 확인합니다. 그들은 그것을 재현하기 위한 몇 가지 세부 사항이나 단계를 제공할 수도 있습니다.

이 기사를 읽고 있다면 테스팅과 TDD가 이미 무엇인지 알고 있고 테스트가 처음이라면 우리 모두가 가지고 있던 질문이 있을 수 있습니다.

테스트에 시간이 너무 많이 걸리지 않습니까? 모든 것을 테스트해야 하나요?

이 기사에서는 테스트의 장단점에 대해 이야기하고 Jest를 사용하여 JavaScript에서 첫 번째 단위 테스트를 수행하는 방법도 알려줍니다.

왜 테스트를 작성합니까?

테스트에 대한 이유에 대해 이야기하면 실제로 다음과 같은 몇 가지 이점이 있습니다.

• 비용 절감 : 적절한 테스트 없이 제품을 장기적으로 유지 관리하는 데 필요한 시간과 리소스는 테스트에 투자한 것보다 훨씬 더 많습니다.
• 코드 안전성 제공 : 소프트웨어는 종종 팀에서 빌드합니다. 다른 사람들은 시간이 지남에 따라 동일한 코드를 수정합니다. 테스트를 하면 아무도 모르는 상태에서 무언가를 깨뜨릴 수 없기 때문에 프로세스가 더 안전해집니다. 이것은 미래의 자신에게도 해당되며, 1~2년 후에 변경 사항을 적용하기 위해 돌아올 때 코드 안전성을 제공합니다.
• 더 나은 아키텍처 : 소프트웨어의 일부를 테스트하기 어려울 때 일반적으로 다른 부분과 밀접하게 연결되어 있거나 기능이 너무 복잡하기 때문입니다. 그것들을 테스트하면 소프트웨어를 가능한 한 간단하고 테스트 가능하게 유지하기 위해 디커플링, 위임 및 디자인 패턴을 적용하는 것이 좋습니다.
• 코드 품질 향상 : 귀하의 제품으로 인해 테스트가 더 나은 아키텍처를 구축 할 수 있도록한다는 사실에 파손 가능성이 줄어 듭니다.
• 보다 쉽고 안전한 리팩토링 : 소프트웨어 구축은 반복적인 프로세스입니다. 요구 사항은 시간이 지남에 따라 변경되므로 기능이 변경됩니다. 테스트 커버리지가 좋으면 테스트가 여전히 통과하는지 확인하면서 일부 코드를 수정할 수 있습니다. 그렇지 않은 경우 테스트에서 정의한 설정된 출력 계약을 적용하도록 코드를 수정합니다.

테스트가 귀하, 귀하의 응용 프로그램 및 귀하의 회사에 좋은 이유에 대해 확신을 가지기를 바랍니다.

테스트 유형

테스트는 다양한 유형으로 나뉩니다. 각 테스트 유형에는 고유한 목적과 범위가 있으며 이를 알고 있어야 합니다. 모든 개발자는 언젠가는 하지 말아야 할 것을 테스트하는 테스트를 작성합니다.

세 가지 주요 유형의 테스트가 있습니다.

• End to End(E2E) : 실제 사용자 환경을 에뮬레이트하여 시스템 전체를 테스트합니다. 웹에서는 마우스 클릭과 키 입력을 에뮬레이트하는 브라우저에서 실행되는 테스트입니다. 일반적으로 테스트 스위트에는 유지 관리 비용이 많이 들고 시스템 전체를 테스트하기 때문에 쉽게 쓸모 없게 될 수 있으므로 이러한 항목이 너무 많아서는 안 됩니다.
• Integration : 그 목적은 여러 종속 단위가 함께 작동하고 상호 작용이 예상대로 작동하는지 확인하는 것입니다.
• Unit tests : 특정 기능을 개별적으로 테스트합니다. 생성 및 유지 관리가 가장 쉽기 때문에 대부분의 테스트 모음이 단위 테스트입니다.

피라미드는 다양한 테스트 유형의 균형을 설명합니다. 아래쪽 부분은 가장 빠르고 쉽고 가장 격리된 테스트인 반면 위쪽 부분은 더 비싸고 느리며 앱 전체에 적용됩니다.

통합 계층은 더 많은 계층으로 분리될 수 있습니다.

테스트 유형과 이름에 대해 약간의 불일치가 있지만 가장 일반적인 것은 구성 요소 및 API 테스트입니다. 이는 특정 유형의 통합 테스트일 뿐입니다. 특히 컴포넌트 테스트는 Vue.js에서 테스트할 때 프런트 엔드 측에서 수행하는 테스트입니다.

정적 분석

테스트는 코드 품질을 제공하는 유일한 도구가 아닙니다. JavaScript의 현대에는 정적 타이핑과 린터도 있습니다. 둘 다 코드의 정적 분석을 수행하여 불일치, 잘못된 언어 사용, 잘못된 관행, 데이터 계약 등을 찾습니다.

정적 타이핑 은 계약별로 코드를 더 안전하게 만듭니다. TypeScript 또는 Flow와 같은 도구를 사용하면 변수, 매개변수 및 반환된 값 유형을 정의할 수 있습니다. 클래스, 함수 및 메서드에 특정 구조가 있고 나머지 코드에서 이를 어설션하고 있음을 확인합니다. 정적 타이핑을 채택한 많은 회사들이 무료로 몇 가지 오류를 즉시 포착하기 시작했습니다.

sum함수 의 유형이 지정된 버전과 유형이 지정되지 않은 버전을 비교해 보겠습니다.

// Non-typed
function sum(a, b) {
    return a + b;
}

// Typed
function sum(a: number, b: number) : number {
    return a + b;
}

형식이 지정되지 않은 버전은 문자열 연결을 반환하는 문자열로 호출하는 것을 방지하지 않습니다. 예를 들어, sum('1', '2')를 호출하면 12가 리턴됩니다. 그러나 정적 입력을 사용하는 경우 Argument of type '"1"' is not assignable to parameter of type 'number' 오류가 발생하여 컴파일 시 실수를 방지합니다.

Linters는 컴파일 시간에 코드의 다양한 측면을 분석하고 검토하는 소프트웨어입니다. 컴파일러의 이점이 없는 JavaScript는 다른 언어에 비해 오류가 발생하기 쉽습니다. ESLint는 JavaScript에서 사실상의 린터인 반면 TypeScript 커뮤니티에서는 TSLint입니다.

린터는 구문 오류, 코드 스타일 및 문제가 있는 패턴을 확인하는 규칙을 제공하여 격차를 메우려고 합니다. 결과적으로 버그를 줄이고 코드의 품질과 일관성을 높입니다.

예를 들어 ESLint 에서 no-var 규칙을 사용 하고 다음 코드를 작성하는 경우:

var greet = 'Hallow, Kitty';

Unexpected var, use let or const instead (no-var) 오류가 발생 합니다.

피라미드에서 정적 분석은 단위 테스트보다 훨씬 더 구체적이고 빠르게(거의 실시간으로) 확인하므로 피라미드의 기본이 됩니다.