SqueakByExample:7.4: Difference between revisions

From 흡혈양파의 번역工房
Jump to navigation Jump to search
(SBE SUNIT의예제 페이지 추가)
 
(용어수정)
 
(11 intermediate revisions by the same user not shown)
Line 1: Line 1:
==SUnit 의 예==
==예제로 보는 SUnit==


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


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




{{CommentSqueak|먼저 여러분은 {{Template:HighlightBold|ExampleSetTest}}라 불리는 {{Template:HighlightBold|TestCase}}의 새로운 서브클래스(subclasss)를 만들어야만 합니다. 두 개의 인스턴스 변수를 추가하면 여러분의 새로운 클래스가 다음처럼 보이게 됩니다:}}
===1 단계: 테스트 클래스를 만듭니다.===
 
 
{{CommentSqueak|먼저 여러분은 {{Template:HighlightBold|ExampleSetTest}}라 불리는 {{Template:HighlightBold|TestCase}}의 새로운 하위 클래스를 만들어야 합니다. 두 개의 인스턴스 변수를 추가하면 여러분의 새로운 클래스가 다음처럼 보이게 됩니다:}}




Line 20: Line 21:




우리는 클래스 세트와 연관된 모든 테스트들을 범주화 하기 위해 클래스 '''ExampleSetTest'''를 사용할 것입니다. 이 클래스는 테스트들이 실행될 컨텍스트를 정의합니다. 여기의 컨텍스트(the context)는 우리가 완전히 가득찬 세트와(full set)와 빈 세트(empty set)를 나타내기 위해 사용할 인스턴스 변수 full과 empty에 의해 묘사될 것입니다.
'''ExampleSetTest''' 클래스에 Set 클래스의 테스트를 정의합니다. 이 클래스에는 테스트를 진행할 컨텍스트를 정의합니다. 여기서 컨텍스트는 full set empty set 에 해당되는 full 과 empty 라는 두개의 인스턴스 변수로 이루어집니다
 
클래스의 이름이 절대적으로 중요한것은 아닙니다만, 관례를 따라, Test로 끝내는것을 권장합니다. 만약 '''Pattern'''으로 지칭되는 클래스를 정의하는 경우 대응되는 테스트 클래스는 '''PatternTest''' 라는 이름이 되며, 두 개의 클래스들은 브라우저에 함께 알파벳순으로 정리됩니다. (동일한 카테고리에 있다고 가정한다면) 만들어진 테스트 클래스가 '''TestCase'''의 하위클래스가 되는것은 대단히 중요한 부분입니다.


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




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




{{CommentSqueak|빈 세트(Empty set)를 참조할 {{Template:HighlightBold|empty}} 변수를 초기화 하고, 두 개의 구성요소를 포함하고 있는 세트를 참조할 full 변수를 초기화 하기 위해 다음과 같이 setup 메소드를 정의합니다.}}
{{CommentSqueak|다음과 같이 {{Template:HighlightBold|empty}} 메소드를 정의하고, 인스턴스 변수인 {{Template:HighlightBold|empty}} 에 빈상태의 Set 를 대입한후 full 에 두 개의 요소를 가지는 Set 를 대입합니다.}}




메소드 7.2 고정물(fixture)셋업하기
메서드 7.2 fixture 셋업하기
<syntaxhighlight lang="smalltalk">
<syntaxhighlight lang="smalltalk">
ExampleSetTest»setUp
ExampleSetTest>>setUp
   empty := Set new.
   empty := Set new.
   full := Set with: 5 with: 6
   full := Set with: 5 with: 6
Line 41: Line 43:




테스트 전문 용어로, 컨텍스트(the context)는 테스트를 위해 고정물(fixture)로 지칭됩니다.
테스팅에 대한 전문용어로 컨텍스트는 '''fixture for the test'''<ref name="역자주1">텍스트를 고정한다. 또는 고정부..정도 되겠습니다만.. 알맞는 표현이 없어서 원문을 그대로 썼습니다</ref> 라고 부릅니다.
 




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


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




{{CommentSqueak|다음 테스트 메소드들을 정의합니다.}}
{{CommentSqueak|다음의 테스트 메서드를 정의하십시오.}}




testIncludes라 작명된 첫 번째 테스트는 세트의 includes: 메소드를 테스트합니다. 테스트는 5를 포함하고 있는 세트에 :5를 포함한 메시지를 발송하라고 말합니다. 이 테스트는 setUp 메소드가 이미 실행 중 이라는 사실에 정확히 의존합니다.
testIncludes 라는 이름을 가진 첫 번째 테스트는 Set 의 includes: 메서드를 테스트합니다. 테스트는 5를 인자로 하는 include: 5 라는 메세지를 보내면 true 가 반환되는것으로 처리하고 있습니다. 이 테스트는 setUp 메서드가 이미 실행(instance의 생성)되었다라는것을 분명한 전제로 하고 있습니다.




메소드 7.3 set 멤버십(set membership) 테스트 하기
메서드 7.3 set 멤버십 테스트
<syntaxhighlight lang="smalltalk">
<syntaxhighlight lang="smalltalk">
ExampleSetTest»testIncludes
ExampleSetTest>>testIncludes
   self assert: (full includes: 5).
   self assert: (full includes: 5).
   self assert: (full includes: 6)
   self assert: (full includes: 6)
Line 63: Line 66:




testOccurrences라 지칭된 두 번째 테스트는, 우리가 다른 구성요소 5를 세트에 더했을 지라도, full 세트에서 5가 생겨난 횟수가 1과 동등한 것을 증명합니다.
두번째 테스트인 testOccurrences 에서는, 이미 5가 포함되어있는 Set(full) 에 5 를 더한다고 해도 결과가 그대로 1 인것을 검증합니다.




메소드 7.4: 발생(occurrences) 테스트
메서드 7.4: 상황발생 테스트
<syntaxhighlight lang="smalltalk">
<syntaxhighlight lang="smalltalk">
ExampleSetTest»testOccurrences
ExampleSetTest>>testOccurrences
self assert: (empty occurrencesOf: 0) = 0.
self assert: (empty occurrencesOf: 0) = 0.
self assert: (full occurrencesOf: 5) = 1.
self assert: (full occurrencesOf: 5) = 1.
Line 76: Line 79:




마침내, 우리가 그것을 제거한 이후, 구성요소 5를 더 이상 포함하지 않는 세트를 테스트하였습니다.
마지막으로 Set(full)에서 5를 제거한다음 5가 더이상 포함되지 않는 Set를 테스트하게됩니다.


Method 7.5: Testing removal
Method 7.5: Testing removal
<syntaxhighlight lang="smalltalk">
<syntaxhighlight lang="smalltalk">
ExampleSetTest»testRemove
ExampleSetTest>>testRemove
   full remove: 5.
   full remove: 5.
   self assert: (full includes: 6).
   self assert: (full includes: 6).
Line 86: Line 89:
</syntaxhighlight>
</syntaxhighlight>


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


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


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




{{CommentSqueak|Test Runner를 열고, 카테고리 {{Template:HighlightGray|MyTest}}를 선택한 다음, 선택된 버튼 {{Template:HighlightBox|Run Selected}}를 클릭합니다.}}
{{CommentSqueak|Test Runner를 열고, 카테고리 {{Template:HighlightGray|MyTest}}를 선택한 다음, 선택된 버튼 {{Template:HighlightBox|Run Selected}}를 클릭하십시오.}}




여러분은 또한 다음 코드에서 {{Template:HighlightGray|print it}}을 실행하여 여러분의 테스트를 실행할 수 있습니다. '''(ExampleSetTest selector: #testRemove) run.''' 이 표현식은 더 짧은 ExampleSetTest run: #testRemove와 등가물입니다. 우리는 보통 메소드 7.6에서 보이는 것 처럼 브라우저에서 {{Template:HighlightGray|do it}} 으로 테스트 메소드들을 실행할 있도록 허용하는, 실행가능한 주석을 (executable comment) 우리 자신의 테스트 메소드들 속에 포함시킵니다.
그리고 다음의 코드를 대상으로 {{Template:HighlightGray|print it}} 을 실행해서 만들어진 테스트를 실행할 수 있습니다: '''(ExampleSetTest selector: #testRemove) run'''. 이 표현식은 더 짧은 ExampleSetTest run: #testRemove 와 같은 의미입니다. 그리고 일반적으로 메서드 7.6 처럼 브라우저에서 {{Template:HighlightGray|do it}} 으로 테스트 메서드들을 실행해볼 있는, 실행가능한 주석을 테스트 메서드들 속에 포함시키죠.




Line 103: Line 107:




메소드 7.6: 테스트 메소드에서 실행가능한 주석(Executable comments)
메서드 7.6: 테스트 메서드에서 실행가능한 주석  
<syntaxhighlight lang="smalltalk">
<syntaxhighlight lang="smalltalk">
ExampleSetTest»testOccurrences
ExampleSetTest>>testOccurrences
   self assert: (empty occurrencesOf: 0) = 0.
   self assert: (empty occurrencesOf: 0) = 0.
   self assert: (full occurrencesOf: 5) = 1.
   self assert: (full occurrencesOf: 5) = 1.
Line 113: Line 117:




{{CommentSqueak|{{Template:HighlightBold|ExampleSetTest»testRemove}}에서 버그를 소개하고, 테스트를 다시 실행합니다. 예를 들면 5를 4로 변경합니다.}}
{{CommentSqueak|{{Template:HighlightBold|ExampleSetTest>>testRemove}}에서 버그를 새로 만들고, 테스트를 다시 실행해보세요 예를 들어 5를 4로 변경해 보시기 바랍니다.}}




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


<syntaxhighlight lang="smalltalk">
<syntaxhighlight lang="smalltalk">
Line 124: Line 126:
</syntaxhighlight>
</syntaxhighlight>


 
또다른 방법으로는 아래와 같은 방식도 가능합니다.
또는


<syntaxhighlight lang="smalltalk">
<syntaxhighlight lang="smalltalk">
ExampleSetTest debug: #testRemove
ExampleSetTest debug: #testRemove
</syntaxhighlight>
</syntaxhighlight>




===5단계: 결과의 해석===
===5단계: 결과의 해석===


클래스 TestCase에서 정의되는 메소드 assert:는 보통 테스트된 표현식의 값인 불리언 인수(Boolean argument) 값을 기대합니다. 인수가 참이면, 테스트는 통과되며 인수가 거짓이면 테스트는 실패합니다.
TestCase 클래스에서 정의된 assert: 메서드는 일반적으로 표현식이 테스트된후 반환값으로 Boolean 인자 값을 처리합니다. 반환값이 True 면, 테스트는 통과처리되며 인자가 False 라면 테스트는 실패로 처리됩니다.
 
하지만 사실 테스트의 결과는 3가지로 나뉠 수 있습니다. 프로그래머가 희망하는 결과는 테스트의 모든 assertions 들이 True 가 되는 것이고, 그럴 경우, 테스트들은 통과됩니다. Test Runner 에서, 모든 테스트들이 통과될 때, 상단의 막대는 녹색으로 변합니다. 하지만, 테스트를 실행할 때, 좋지않은 결과가 나올 수 있는 경우는 2가지가 있습니다. 가장 확실한 경우는, assertions 중 하나가 테스트를 실패로 만들게되는 False 가 될 수 있다는거죠. 다른 경우로는 message not understood 오류 또는 index out of bounds error 처럼, 테스트가 실행되는 동안 일어날 수 있는 몇가지 종류의 오류가 있습니다. 만약 오류가 발생되는 시점에서 테스트 메서드에 있는 assertion 들이 다 실행되지 않는 경우도 있기때문에, 모든 테스트가 실패되었다고 할 수는 없습니다만, 그렇다 하더라도 어떤 테스트에서 문제가 일어났는지는 분명히 확인할 수 있습니다. Test Runner 에서 실패한 테스트가 있는경우 상단의 막대는 노랑색으로 바뀌며, 오른쪽의 패널에 나열됩니다. 반면에 테스트 자체에 오류가 있는 테스트들은 막대를 빨강으로 바꾸며, 오른쪽 아래의 패널에 나열됩니다.
 


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


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


==Notes==
==Notes==

Latest revision as of 19:18, 16 September 2013

예제로 보는 SUnit

SUnit 의 세부사항을 살펴보기 전에, 차례차례 예제를 살펴 보도록 하겠습니다. 여기서는 클래스 세트를 테스트하는 예제를 사용하게 될것입니다. 아래의 내용대로 코드 입력을 시도해 보십시오.


1 단계: 테스트 클래스를 만듭니다.

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


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

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


ExampleSetTest 클래스에 Set 클래스의 테스트를 정의합니다. 이 클래스에는 테스트를 진행할 컨텍스트를 정의합니다. 여기서 컨텍스트는 full set 과 empty set 에 해당되는 full 과 empty 라는 두개의 인스턴스 변수로 이루어집니다

클래스의 이름이 절대적으로 중요한것은 아닙니다만, 관례를 따라, Test로 끝내는것을 권장합니다. 만약 Pattern으로 지칭되는 클래스를 정의하는 경우 대응되는 테스트 클래스는 PatternTest 라는 이름이 되며, 두 개의 클래스들은 브라우저에 함께 알파벳순으로 정리됩니다. (동일한 카테고리에 있다고 가정한다면) 만들어진 테스트 클래스가 TestCase의 하위클래스가 되는것은 대단히 중요한 부분입니다.


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

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


Squeak comment.png다음과 같이 empty 메소드를 정의하고, 인스턴스 변수인 empty 에 빈상태의 Set 를 대입한후 full 에 두 개의 요소를 가지는 Set 를 대입합니다.


메서드 7.2 fixture 셋업하기

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


테스팅에 대한 전문용어로 컨텍스트는 fixture for the test[1] 라고 부릅니다.


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

클래스 ExampleSetTest에서 몇 가지 메서드를 정의해서 몇 개의 테스트를 만들어 보겠습니다. 각 메서드는 한 개의 테스트를 나타내며, 메서드의 이름은 반드시 문자열 'test'로 시작해야하고, 그렇게 이름을 만들게되면 SUnit이 테스트 suite 로 해당되는 이름들을 수집합니다. 테스트 메서드들은 어떤 인자들도 필요로하지 않습니다.


Squeak comment.png다음의 테스트 메서드를 정의하십시오.


testIncludes 라는 이름을 가진 첫 번째 테스트는 Set 의 includes: 메서드를 테스트합니다. 테스트는 5를 인자로 하는 include: 5 라는 메세지를 보내면 true 가 반환되는것으로 처리하고 있습니다. 이 테스트는 setUp 메서드가 이미 실행(instance의 생성)되었다라는것을 분명한 전제로 하고 있습니다.


메서드 7.3 set 멤버십 테스트

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


두번째 테스트인 testOccurrences 에서는, 이미 5가 포함되어있는 Set(full) 에 5 를 더한다고 해도 결과가 그대로 1 인것을 검증합니다.


메서드 7.4: 상황발생 테스트

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


마지막으로 Set(full)에서 5를 제거한다음 5가 더이상 포함되지 않는 Set를 테스트하게됩니다.

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 not 과 같은 의미지만, 훨씬 더 알아보기 쉽습니다.


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

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


Squeak comment.pngTest Runner를 열고, 카테고리 MyTest를 선택한 다음, 선택된 버튼 Run Selected를 클릭하십시오.


그리고 다음의 코드를 대상으로 print it 을 실행해서 만들어진 테스트를 실행할 수 있습니다: (ExampleSetTest selector: #testRemove) run. 이 표현식은 더 짧은 ExampleSetTest run: #testRemove 와 같은 의미입니다. 그리고 일반적으로 메서드 7.6 처럼 브라우저에서 do it 으로 테스트 메서드들을 실행해볼 수 있는, 실행가능한 주석을 테스트 메서드들 속에 포함시키죠.


그림 7.1: 스퀵 SUnit Test Runner


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

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


Squeak comment.pngExampleSetTest>>testRemove에서 버그를 새로 만들고, 테스트를 다시 실행해보세요 예를 들어 5를 4로 변경해 보시기 바랍니다.


검사과정에서 실패된 테스트는(실패한 테스트가 존재한다면) Test Runner 의 오른쪽에 표시되며, 만약 그 테스트가 실패했는지 이유를 보기 위해 디버그를 수행하시려면, 단지 테스트 이름을 클릭하기만 하면 됩니다. 다른 방법으로 다음의 표현식중 하나를 실행해도 됩니다:

(ExampleSetTest selector: #testRemove) debug

또다른 방법으로는 아래와 같은 방식도 가능합니다.

ExampleSetTest debug: #testRemove


5단계: 결과의 해석

TestCase 클래스에서 정의된 assert: 메서드는 일반적으로 표현식이 테스트된후 반환값으로 Boolean 인자 값을 처리합니다. 반환값이 True 면, 테스트는 통과처리되며 인자가 False 라면 테스트는 실패로 처리됩니다.

하지만 사실 테스트의 결과는 3가지로 나뉠 수 있습니다. 프로그래머가 희망하는 결과는 테스트의 모든 assertions 들이 True 가 되는 것이고, 그럴 경우, 테스트들은 통과됩니다. Test Runner 에서, 모든 테스트들이 통과될 때, 상단의 막대는 녹색으로 변합니다. 하지만, 테스트를 실행할 때, 좋지않은 결과가 나올 수 있는 경우는 2가지가 있습니다. 가장 확실한 경우는, assertions 중 하나가 테스트를 실패로 만들게되는 False 가 될 수 있다는거죠. 다른 경우로는 message not understood 오류 또는 index out of bounds error 처럼, 테스트가 실행되는 동안 일어날 수 있는 몇가지 종류의 오류가 있습니다. 만약 오류가 발생되는 시점에서 테스트 메서드에 있는 assertion 들이 다 실행되지 않는 경우도 있기때문에, 모든 테스트가 실패되었다고 할 수는 없습니다만, 그렇다 하더라도 어떤 테스트에서 문제가 일어났는지는 분명히 확인할 수 있습니다. Test Runner 에서 실패한 테스트가 있는경우 상단의 막대는 노랑색으로 바뀌며, 오른쪽의 패널에 나열됩니다. 반면에 테스트 자체에 오류가 있는 테스트들은 막대를 빨강으로 바꾸며, 오른쪽 아래의 패널에 나열됩니다.


Squeak comment.png오류와 실패가 일어난 테스트들을 수정하십시오.


Notes

  1. 텍스트를 고정한다. 또는 고정부..정도 되겠습니다만.. 알맞는 표현이 없어서 원문을 그대로 썼습니다