SqueakByExample:7.4

SUnit 의 예

SUnit의 세부사항으로 들어가기 전에, 우리는 차례차례 예시를 보여드릴 것입니다. 우리는 클래스 세트(the class Set)를 테스트하는 예시를 사용할 것입니다. 우리가 하는 대로 코드 입력을 시도해 보십시오.

1 단계: 테스트 클래스(the test class)를 만듭니다.

먼저 여러분은 ExampleSetTest라 불리는 TestCase의 새로운 서브클래스(subclasss)를 만들어야만 합니다. 두 개의 인스턴스 변수를 추가하면 여러분의 새로운 클래스가 다음처럼 보이게 됩니다:

클래스 7.1: 견본 세트 테스트 클래스

TestCase subclass: #ExampleSetTest
  instanceVariableNames: 'full empty'
  classInstanceVariableNames: ''
  poolDictionaries: ''
  category: 'MyTest'

우리는 클래스 세트와 연관된 모든 테스트들을 범주화 하기 위해 클래스 ExampleSetTest를 사용할 것입니다. 이 클래스는 테스트들이 실행될 컨텍스트를 정의합니다. 여기의 컨텍스트(the context)는 우리가 완전히 가득찬 세트와(full set)와 빈 세트(empty set)를 나타내기 위해 사용할 인스턴스 변수 full과 empty에 의해 묘사될 것입니다.

클래스의 이름은 치명적으로 중요한 것은 아니지만, 관례에 의해, Test로 끝나야 합니다. 만약 여러분이 Pattern으로 지칭되는 클래스를 정의한다면 대응하는 테스트 클래스는 Pattern Test이며, 두 개의 클래스들은 브라우저에 함께 알파벳순으로 정리됩니다. (동일한 카테고리에 있다고 가정하면) 여러분의 클래스가 TestCase의 서브클래스가 되게 하는 것은 치명적으로 중요합니다.

2단계: 테스트 컨텍스트를(test context) 초기화 하기

메서드 setUp은 테스트가 실행될 컨텍스트(the context)를 정의하며, 초기화 메서드와(initialize method) 약간 비슷합니다. setUp은 테스트 클래스(the test class)에서 정의된 각 테스트 메서드(test method)의 실행 전에 불러집니다(invoked)

빈 세트(Empty set)를 참조할 empty 변수를 초기화 하고, 두 개의 구성요소를 포함하고 있는 세트를 참조할 full 변수를 초기화 하기 위해 다음과 같이 setup 메서드를 정의합니다.

메서드 7.2 고정물(fixture)셋업하기

ExampleSetTest»setUp
  empty := Set new.
  full := Set with: 5 with: 6

테스트 전문 용어로, 컨텍스트(the context)는 테스트를 위해 고정물(fixture)로 지칭됩니다.

3 단계: 몇 가지 테스트 메서드를 작성하기

클래스 ExampleSetTest에서 몇 가지 메서드를 정의하여 몇 개의 테스트를 만들어 봅시다. 각 메서드는 한 개의 테스트를 나타내며, 메서드의 이름은 반드시 문자열 ‘test’로 시작해야만 하며, 그 결과 SUnit이 테스트 스위트(test Suites) 속으로 그 이름들을 수집합니다. 테스트 메서드들은 어떤 인수들도 취하지 않습니다.

다음 테스트 메서드들을 정의합니다.

testIncludes라 작명된 첫 번째 테스트는 세트의 includes: 메서드를 테스트합니다. 테스트는 5를 포함하고 있는 세트에 :5를 포함한 메시지를 발송하라고 말합니다. 이 테스트는 setUp 메서드가 이미 실행 중 이라는 사실에 정확히 의존합니다.

메서드 7.3 set 멤버십(set membership) 테스트 하기

ExampleSetTest»testIncludes
  self assert: (full includes: 5).
  self assert: (full includes: 6)

testOccurrences라 지칭된 두 번째 테스트는, 우리가 다른 구성요소 5를 세트에 더했을 지라도, full 세트에서 5가 생겨난 횟수가 1과 동등한 것을 증명합니다.

메서드 7.4: 발생(occurrences) 테스트

ExampleSetTest»testOccurrences
self assert: (empty occurrencesOf: 0) = 0.
self assert: (full occurrencesOf: 5) = 1.
full add: 5.
self assert: (full occurrencesOf: 5) = 1

마침내, 우리가 그것을 제거한 이후, 구성요소 5를 더 이상 포함하지 않는 세트를 테스트하였습니다.

Method 7.5: Testing removal

ExampleSetTest»testRemove
  full remove: 5.
  self assert: (full includes: 6).
  self deny: (full includes: 5)

참(true)이 되어서는 안될 어떤 것을 assertion(주장)할 때, 메서드 deny:의 사용에 유의합시다. aTest deny:anExpression은 aTest assert:와 등가물이고 anExpression과는 등가물이 아니지만, 훨씬 더 판독이 쉽습니다.

4 단계: 테스트를 실행합니다

테스트들을 실행하는 가장 쉬운 방법은 SUnit Test Runner를 사용하는 것이며, 이것은 World ▷ open... 메뉴를 사용하거나 도구 플랩(the Tools flap)에서 TestRunner를 드레그하여 열수 있습니다. 그림 7.1에 보이는 TestRunner는 테스트들의 그룹들을 쉽게 실행할 수 있도록 디자인 되었습니다. 테스트 클래스들(예를 들어 TestCase의 서브클래스들)를 포함하고 있는 모든 시스템 카테고리들을 열거하며, 이 카테코리들 중 몇 개가 선택되면 그 카테고리들이 포함하고 있는 테스트 클래스들은 그 패널의 오른쪽 패널에 나타납니다. 추상 클래스들은 이텔릭체로 인쇄되어 있으며, 테스트 클래스 계층도(the test class hierarchy)는 들여쓰기되어 나타나므로, ClassTestCase의 서브클래스들은 TestCase의 서브클래스들보다 더 들여쓰기 되어 표시됩니다.

Test Runner를 열고, 카테고리 MyTest를 선택한 다음, 선택된 버튼 Run Selected를 클릭합니다.

여러분은 또한 다음 코드에서 print it을 실행하여 여러분의 테스트를 실행할 수 있습니다. (ExampleSetTest selector: #testRemove) run. 이 표현식은 더 짧은 ExampleSetTest run: #testRemove와 등가물입니다. 우리는 보통 메서드 7.6에서 보이는 것 처럼 브라우저에서 do it 으로 테스트 메서드들을 실행할 수 있도록 허용하는, 실행가능한 주석을 (executable comment) 우리 자신의 테스트 메서드들 속에 포함시킵니다.

그림 7.1: 스퀵 SUnit Test Runner

메서드 7.6: 테스트 메서드에서 실행가능한 주석(Executable comments)

ExampleSetTest»testOccurrences
  self assert: (empty occurrencesOf: 0) = 0.
  self assert: (full occurrencesOf: 5) = 1.
  full add: 5.
  self assert: (full occurrencesOf: 5) = 1

ExampleSetTest»testRemove에서 버그를 소개하고, 테스트를 다시 실행합니다. 예를 들면 5를 4로 변경합니다.

패스되지 않은 테스트는(만약 무엇이든 존재한다면), Test Runner의 오른쪽에 열거되며 만약 여러분이 왜 그 테스트가 실패했는지 보기 위해 디버그를 수행하시려면, 단지 테스트 이름을 클릭합니다. 다른 대안으로 다음 표현식을 실행하실 수 있습니다:

(ExampleSetTest selector: #testRemove) debug

또는

ExampleSetTest debug: #testRemove

5단계: 결과의 해석

클래스 TestCase에서 정의되는 메서드 assert:는 보통 테스트된 표현식의 값인 불리언 인수(Boolean argument) 값을 기대합니다. 인수가 참이면, 테스트는 통과되며 인수가 거짓이면 테스트는 실패합니다.

실제로 3 개의 가능한 테스트 결과가 있습니다. 우리가 희망하는 결과는 테스트의 모든 주장들이(assertions) 참이 되는 것이고, 그럴 경우, 테스트가 패스됩니다. Test Runner에서, 모든 테스트들이 패스될 때, 상단의 막대가 녹색으로 변합니다. 그럼에도 불구하고, 여러분이 테스트를 실행할 때, 잘못될 수 있는 두 가지 종류의 그 무엇이 있습니다. 가장 분명한 것은, 주장들(assertions)의 하나가 테스트를 실패로 이끌 수 있는 거짓(false)이 될 수 있다는 것입니다. 그럼에도 불구하고 message not understood 에러 또는 index out of bounds error와 같이 테스트가 실행되는 동안 발생되는 몇 가지 종류의 발생 가능한 에러가 있을 수 있습니다. 만약 에러가 발생하면 테스트 메서드(the test method)에 있는 주장(assertion)들은 다 실행되지 않을 수 있으므로, 우리는 그 테스트가 실패하였다고 말할 수 없지만 그럼에도 불구하고, 어떤 것이 분명히 잘못되었다고 말할 수 있습니다. Test Runner에서 실패한 테스트들은 상단의 막대를 노랑색으로 바꾸며, 오른쪽의 패널에 열거됩니다. 반면에 에러가 있는 테스트들은 막대를 빨강으로 바꾸며, 오른쪽 아래의 패널에 열거됩니다.

에러들과 실패들을 불러 일으키는 여러분의 테스트들을 수정합니다.