이 테스트에 관련된 내용을 몇 가지 정리해보자.
• container는 ‘테스트 대상’으로 beforeEach에서 생성된다. 테스트마다 인스턴스를 갓 구워내면 다른 테스트의 결과를 어지럽히지 않아도 된다.
• 중첩된 describes와 it 함수가 인자로 받은 문자열을 죽 이어서 읽어보면 “DiContainer register (name,dependencies,func)는 인자가 하나라도 누락되었거나 타입이 잘못되면 예외를 던진다.”5는 문장이 된다.
• TDD 순수주의자는 badArgs 원소마다 테스트를 따로 만들라고 하겠지만, 실제로 그렇게까지 개발자에게 부담을 주면 필요한 조건을 모두 테스트하기도 전에 질려버릴지도 모른다. 기대식 한 개와 서술문 한 개로 모든 테스트를 묶어 작성해도 무방하다.
TIP
기대식에 사용한 apply 함수가 아직 낯선 독자도 있을 것이다. apply는 해당 함수(register)를, 주어진 ‘this’(container) 콘텍스트(context)로, 콤마로 나뉜 일반 함수 호출과 달리 배열 타입의 인자(args)를 넘겨 호출하는 함수다. call 함수는 뒷부분 ‘사례 연구: Aop.js 모듈 개발’ 절을 참고하자.
테스트를 실행하면 실패한다(그림 2-4).
►그림 2-4
5 역주 BDD 창시자가 원래 가장 강조했던 사상이지만, 반드시 이런 식으로 연결할 때 완벽한 문장이 되어야 하는 건 아닙니다. 영어는 in, with 같은 전치사가 발달되어 있고, describe(“In 어디”) ~ it(“무엇을 이렇게 작동해야 한다”) 구조가 손쉬운 편이지만, 한국어는 조사 단위로 끊기가 오히려 부자연스러울 수 있습니다. 따라서 describe 함수에 개발 업무별 대, 소분류 또는 계층적인 화면/테스트 ID로 표시하는 것이 더 식별하기 좋은 경우도 있습니다(예: describe(“1. 대분류명”) ~ describe(“1.1. 소분류”) ~ describe(“1.1.1. 화면명”) ~ it(“~한 데이터가 표시되어야 한다”)).