유형 또는 테스트 : 왜 둘 다 안됩니까?

지금은 타이핑 된 JavaScript의 가치에 대한 논쟁이 있습니다. "더 많은 테스트를 작성하십시오!" 일부 반대자들은 소리 쳤다. "단위 테스트를 유형으로 교체하십시오!" 다른 사람들은 소리 쳤다. 둘 다 어떤면에서는 옳고 다른 방법으로는 옳습니다. 트위터의 공간은 미묘함을 반영하기에 충분하지 않습니다. 그러나이 기사에서는 두 사람이 어떻게 그리고 어떻게 공존 해야하는지에 대한 합리적인 주장을 자세히 설명 할 수 있습니다.

정확성 : 우리가 정말로 원하는 것

결과부터 시작하는 것이 가장 좋습니다. 우리 가이 모든 메타 엔지니어링에서 우리가 정말로 원하는 것은 정확성 입니다. 나는 엄격한 이론적 컴퓨터 과학 정의를 언급하는 것이 아니라 프로그램 행동과 그 규범에 대한보다 일반적인 준수입니다. 프로그램의 작동 방식에 대한 아이디어가 있으며 프로그래밍 프로세스는 비트와 바이트를 구성 하여이 아이디어를 현실로 만듭니다. 우리는 항상 우리가 원하는 것을 정확히 알지 못하고 변경할 때 프로그램이 깨지지 않도록하기를 원하기 때문에 기존 원본 코드 위에 유형과 테스트를 작성하여 처음부터 작동하도록합니다.

따라서 정확성이 우리가 원하는 것이며 유형과 테스트가이를 달성하는 자동화 된 방법 일 뿐이라면, 유형과 테스트가 우리가 정확성을 달성하는 데 도움이되는 방법을 보여주기 위해 직관적 인 모델을 갖는 것이 좋습니다.

프로그램 정확성의 시각화 모델

우리가 프로그램이 거대한 회색 영역으로 수행 할 수있는 모든 운영의 전체 무한 튜링에 완료 가능한 가능한 공간을 상상한다면, 우리가 프로그램을 수행하기를 원하는 것은 우리의 사양이 가능한 공간의 매우 작은 하위 집합입니다 ( 아래 그림의 녹색 마름모꼴, 크기가 과장되어 무언가를 표시합니다).

프로그래밍에서 우리의 임무는 프로그램을 가능한 한 사양에 맞게 조정하는 것입니다 (물론 우리는 불완전하고, 인적 오류, 새로운 특징 또는 지정되지 않은 행동으로 인해 우리의 사양이 끊임없이 변화하고 있음을 알고 있습니다.

여기서 논의의 목적을 위해 절차 행동의 경계에는 계획된 오류 및 계획되지 않은 오류도 모두 포함됩니다 . "정확성"의 우리의 의미에는 계획된 오류가 포함되지만 계획되지 않은 오류는 포함되지 않습니다.

테스트 및 정확성

우리는 우리의 프로그램이 우리의 기대를 충족 시키는지 확인하기 위해 테스트를 작성하지만 테스트 할 내용에 대한 많은 옵션이 있습니다.

이상적인 테스트는 그림의 주황색 점입니다. 프로그램이 사양과 겹치는지 정확하게 테스트합니다. 이 시각화에서 우리는 실제로 테스트 유형을 구별하지 않지만 단위 테스트를 매우 작은 포인트로 생각할 수 있으며 통합/엔드 투 엔드 테스트가 큰 요점입니다. 어느 쪽이든, 그들은 프로그램의 모든 경로를 완전히 설명 할 수 없기 때문에 포인트입니다. (실제로 100% 코드 범위를 가질 수 있지만 조합 폭발이 있기 때문에 모든 경로를 테스트 할 수는 없습니다 !)

그림의 파란 점은 나쁜 테스트입니다. 물론, 우리의 프로그램이 작동하는지 테스트하지만 실제로는 기본 사양 (하루가 끝나면 프로그램에서 얻고 싶은 것)에 고정하지는 않습니다. 이 테스트는 프로그램을 수정하여 사양과 더 밀접하게 조정하여 잘못된 긍정적 인 것을 제공 할 때 끊어집니다.

자주색 점은 프로그램이 작동한다고 생각하는 방법을 테스트하고 프로그램이 현재 작동하지 않는 영역을 결정하기 때문에 귀중한 테스트입니다. 자주색 테스트로 선도하고 그에 따라 프로그램 구현을 수정하는 것은 테스트 중심 개발 이라고도합니다.

그림의 빨간색 테스트는 드문 테스트입니다. "행복한 길"(계획의 잘못된 상태 포함)을 테스트하는 일반 (주황색) 테스트는 아니지만 " 불행한 경로"를 기대하고 검증하는 테스트에 실패했습니다. 이 테스트가 "실패 해야하는 위치"를 "통과"하는 경우, 무언가 잘못되었다는 것은 큰 조기 경고 신호이지만 기본적으로 Spec Green Area 외부에 존재하는 큰 불행한 경로를 다루기에 충분한 테스트를 작성하는 것은 불가능합니다. 작동하지 않아야 할 것들을 테스트하는 것이 가치가 있다는 것을 찾는 것은 드 rare니다. 그래서 그들은 그렇게하지 않습니다. 그러나 상황이 잘못되면 여전히 유용한 조기 경고 신호가 될 수 있습니다.

유형 및 정확성

테스트가 프로그램이 작업을 수행 할 수있는 확률 공간의 단일 지점 인 경우, 유형은 전체 부분을 총 확률 공간에서 나누는 범주를 나타냅니다. 우리는 그것들을 사각형으로 시각화 할 수 있습니다.

유형 시스템 자체가 유형을 사용하여 프로그램 동작을 완전히 설명 할 수 없기 때문에 프로그램을 나타내는 다이아몬드를 비교하기 위해 사각형을 선택합니다. (간단한 예를 들어, 항상 양수 정수가되어야하는 ID는 숫자 유형이지만 숫자 유형은 분수와 음수도 허용합니다. 숫자 유형을 매우 간단한 숫자 유형을 특정 범위로 제한하는 것은 불가능합니다).

유형은 코드를 작성할 때 프로그램을 실행할 수있는 위치에 대한 제약으로 작용합니다. 프로그램이 프로그램 유형의 지정된 경계를 초과하기 시작하면 유형 체커 (예 : TypeScript 또는 Flow)는 단순히 프로그램을 컴파일하는 것을 거부합니다. JavaScript와 같은 역동적 인 언어에서는 실수로 당신이 만들고자하는 충돌 프로그램을 쉽게 만들 수 있기 때문에 이것은 좋습니다. 가장 쉬운 값은 자동 널 값 점검입니다. FOO가 Bar라는 메소드가 없으면 foo.bar ()를 호출하면 잘 알려지지 않은 정의가 함수 런타임 예외가 아닙니다. FOO가 완전히 입력 된 경우 작성 당시 유형 검사기에 의해이 문제를 포착 할 수 있으며 문제가있는 코드 라인 (및 AutoComplete의 수반되는 이점)을 지적 할 수 있습니다. 이것은 테스트가 단순히 할 수없는 것입니다.

우리는 마치 우리의 사양에 맞는 사각형만큼 작게 쓰려고하는 것처럼 프로그램에 대한 엄격한 유형을 작성하고 싶을 수도 있습니다. 그러나 유형 시스템을 활용하려면 완전히 새로운 구문 및 연산자 학습뿐만 아니라 JavaScript의 전체 동적 범위를 시뮬레이션하는 데 필요한 일반 유형 논리의 구문을 학습하는 것이 포함되기 때문에 학습 곡선이 있습니다. 매뉴얼과 치트 시트는 학습 곡선을 낮추는 데 도움이되며 여기에는 더 많은 투자가 필요합니다.

다행히도이 채택/학습 곡선은 우리를 막을 필요가 없습니다. 유형 검사는 유량의 선택적 프로세스이며 구성 가능한 TypeScript (해당 코드 라인을 선택적으로 무시할 수있는 기능)이므로 유형 안전 범위 내에서 선택할 수 있습니다. 우리는 이것을 모델링 할 수도 있습니다.

위의 이미지의 큰 빨간색 사각형과 같은 큰 사각형은 코드베이스의 유형 시스템을 매우 느슨하게 채택 함을 나타냅니다. 예를 들어 암시 적이 허용하고 전적으로 유형 추론에 의존하여 최악의 코딩에서 프로그램을 제한합니다.

중간 크기의 녹색 사각형 (중간 크기의 녹색 사각형)은 더 충실한 타입을 나타낼 수 있지만 코드 기반 전체에 명시 적 인스턴스 및 수동 유형 어설 션을 사용하는 것과 같은 많은 취약점이 있습니다. 그럼에도 불구하고, 이러한 경량 타이핑 작업이 수행 되더라도 사양에 맞지 않는 효과적인 프로그램의 가능한 표면적은 크게 줄어 듭니다.

자주색 사각형과 같은 최대 엄격함은 상황이 너무 빡빡해서 때로는 프로그램의 부적절한 부분을 발견합니다 (일반적으로 프로그램 동작에서 계획되지 않은 오류). 이와 같은 기존 프로그램에서 오류를 찾는 것은 일반적인 JavaScript 코드 기반을 변환하는 팀에서 매우 일반적인 경우입니다. 그러나 유형 체커에서 최대 유형 안전을 얻으려면 각 변수 및 기능에 대한 가능한 유형 공간을 정제하고 좁히도록 설계된 일반 유형 및 특수 연산자를 활용해야 할 수 있습니다.

우리는 유형을 작성하기 전에 프로그램을 작성할 필요가 없습니다. 결국, 우리는 유형이 사양을 면밀히 시뮬레이션하기를 원하므로 실제로 유형을 먼저 작성한 다음 나중에 구현을 채울 수 있습니다. 이론적으로 이것은 유형 중심 개발 일 것입니다. 실제로 유형이 실제 프로그램 코드와 침투하고 얽히기 때문에 실제로는 실제로 이런 식으로 발전하는 사람은 거의 없습니다.

그것들을 합치십시오

우리가 궁극적으로 구축하고자하는 것은 프로그램의 정확성을 보장하기 위해 유형과 테스트가 서로를 보완하는 방법을 보여주는 직관적 인 시각화입니다.

우리의 테스트는 우리의 프로그램이 선택된 임계 경로에서 예상대로 구체적으로 수행된다고 주장합니다 (위에서 언급했듯이 다른 테스트 변형이 있지만 대부분의 테스트는 그렇게합니다). 우리가 개발 한 시각적 언어에서, 그들은 프로그램의 짙은 녹색 마름모를 표준의 밝은 녹색 마름모로 "고정"합니다. 프로그램의 모든 움직임은 이러한 테스트를 파괴하여 경고하게됩니다. 대단해! 테스트는 또한 가장 맞춤화 된 사용 사례에 대한 유연성과 구성 성이 무제한입니다.

우리의 유형은 우리의 프로그램이 우리가 그리는 경계를 넘어 가능한 실패 모드를 가능한 한 가능한 한 밀접하게 둘러싸기를 희망함으로써 우리의 프로그램이 우리의 통제를 중단하지 않을 것이라고 주장합니다. 우리의 시각적 언어에서, 그들은 표준에서 벗어날 수있는 가능한 프로그램의 표류를 "포함"합니다 (우리는 항상 결함이 있기 때문에 우리가하는 모든 실수는 프로그램에 추가 실패를 추가합니다). 유형은 또한 무뚝뚝하지만 강력한 (유형의 추론 및 편집기 도구로 인해) 강력한 커뮤니티의 혜택을받을 필요가없는 강력한 커뮤니티의 혜택을받을 필요가 있습니다.

요컨대 :

• 테스트는 행복한 경로가 작동하는지 확인하는 것이 가장 좋습니다.
• 유형은 기존에서 불행한 경로를 방지하는 데 가장 좋습니다.

최상의 결과를 위해 강점에 따라 함께 사용하십시오!

유형과 테스트가 어떻게 교차하는지에 대해 자세히 알고 싶다면 Gary Bernhardt의 경계에 대한 훌륭한 연설과 Kent C. Dodds의 테스트 트로피는이 게시물에 대한 나의 생각에 큰 영향을 미쳤습니다.

위 내용은 유형 또는 테스트 : 왜 둘 다 안됩니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!