TDD에 대해 알아본다.

TDD describe context it

• 테스트를 할 때 사용자 행동을 묘사한다고 생각하면 된다.

Describe - 묘사

Context - 맥락

it - 맥락의 결과? output?

예시 )
Describe “ATTACK”
Context “without a weapon”
It should do 1 point of damage
Context “with a sword”
It should do 10 point of damage

Q1. 자식 컴포너트에서 테스트 한 부분을 부모 컴포넌트에서 테스트 해야할까?

A. 해야한다.

왜? - 자식 컴포넌트에서 테스트했지만 조합된 부모 컴포넌트에서 테스트 했을 때 올바르게 동작하는지도 테스트 해야하기 때문이다.

Q2. 테스트 작성은 자식 컴포넌트에서 부모 컴포넌트로 아래에서 위로 해야할지 아니면 위에서 아래로 진행해야할지 궁금하다.

A. 둘다 할 줄 알아야한다. ( 상황에 맞게? )

왜 ? - 자식부터 작성하면 더 간단한 것부터 시작하기 때문에 테스트를 작성하기 쉽다는 장점이 있는데, 막상 테스트 코드를 작성하고 코드를 작성 완료 했을때 실제 사용하는 부모에서는 사용하기 불편하거나 잘못 설계했을 수도 있다. 그럴 경우 다시 부모에서 자식으로 테스트 코드를 작성하는 경우가 더 좋다.

중복이 발생할 수 있다. 일단 극단적으로 작성해보자!

안전한 테스트를 만든다 생각하고 극단적으로 작성하고 테스트 코드를 만들자 커버리지 100% 달성이 목표이다.

해봐야 할 점 !

RED - GREEN - REFACTOR 과정대로 RED 로 시나리오를 쭉 작성해보고,

GREEN 으로 만들고 REFACTOR를 해보는 과정으로 진행하는게 좋을 것 같다.

App.jsx 경우 E2E 테스트와 비슷하게 시나리오를 작성해보자?

테스트 작성시 Given When Then 에 맞춰서 코드를 작성해보자.

GIVEN WHEN THEN

render는 tasks 가 없을 때 빈페이지를 출력한다.

Given 주어진 조건 ? When ~ 할 때 Then ~를 출력한다.

context 안에는 with, without, when 만 사용하도록 권장된다.

Use - case 시스템 동작을 사용자 입장에서?

it 첫번째 인수로, 특정 유즈 케이스 에 대한 설명이 들어간다.

이 설명은 누구나 읽을 수 있고 이해 할 수 있는 자연어로 적어준다.

두번째 인수에는 유즈 케이스 테스트 함수가 들어간다.

개발 순서

명세서 초안을 작성한다. 기본적인 테스트도 들어간다.

초안을 보고 코드를 작성한다.

코드가 동작하는지 확인하기 위해 Mocha프레임워크를 사용하여 명세서를 실행한다. 이때 코드가 잘못 작성되어 있다면, 에러가 출력된다.

테스트가 모두 통과해 에러가 더이 출력되지 않도록 코드를 수정한다.

모든 테스트를 통과하는 코드 초안이 완성된다.

명세서에 고려되지않았던 유즈 케이스를 몇가지 추가한다.

다시 테스트에 통과되도록 코드를 수정한다.

기능이 완성될때까지 3~6단계를 반복한다.

테스트 하나에선 한 가지만 확인하기

RED - GREEN - REFACTOR 는 테스트 주도 개발의 단계이다.

테스트 코드 작성시 우리가 아직은 코드를 직접 만든게 아니기 때문에

테스트 코드를 짜두면 RED, 직접 코드를 테스트 일단 통과하도록 짜는게 GREEN ,
반복을 줄이고 더 범용성을 가지도록 짜주는게 REFACTOR 이다.
즉, 개발 순서에 대한 얘기다.