SqueakByExample:7.4 - Revision history

Onionmixer: 용어수정

2013-09-16T19:18:44Z

용어수정

← Older revision		Revision as of 19:18, 16 September 2013
Line 49:		Line 49:
	===3 단계: 몇 가지 테스트 메서드를 작성하기===		===3 단계: 몇 가지 테스트 메서드를 작성하기===

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


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

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

Onionmixer: 번역수정

2013-03-21T12:52:26Z

번역수정

← Older revision		Revision as of 12:52, 21 March 2013
Line 1:		Line 1:
	==예제로 보는 SUnit==		==예제로 보는 SUnit==

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


Line 8:		Line 8:


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


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

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

Onionmixer: 번역수정

2013-03-21T12:51:22Z

번역수정

Show changes

Onionmixer: 용어수정

2013-02-22T02:06:55Z

용어수정

New page

==SUnit 예제==

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

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

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

클래스 7.1: 견본 세트 테스트 클래스
<syntaxhighlight lang="smalltalk">
TestCase subclass: #ExampleSetTest
instanceVariableNames: 'full empty'
classInstanceVariableNames: ''
poolDictionaries: ''
category: 'MyTest'
</syntaxhighlight>

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

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

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

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

{{CommentSqueak|빈 세트(Empty set)를 참조할 {{Template:HighlightBold|empty}} 변수를 초기화 하고, 두 개의 구성요소를 포함하고 있는 세트를 참조할 full 변수를 초기화 하기 위해 다음과 같이 setup 메서드를 정의하십시오.}}

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

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

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

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

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

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

메서드 7.3 set 멤버십 테스트
<syntaxhighlight lang="smalltalk">
ExampleSetTest»testIncludes
self assert: (full includes: 5).
self assert: (full includes: 6)
</syntaxhighlight>

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

메서드 7.4: 발생 여부 테스트
<syntaxhighlight lang="smalltalk">
ExampleSetTest»testOccurrences
self assert: (empty occurrencesOf: 0) = 0.
self assert: (full occurrencesOf: 5) = 1.
full add: 5.
self assert: (full occurrencesOf: 5) = 1
</syntaxhighlight>

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

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

참(true)이 되어서는 안될 어떤 것을 assertion(주장)할 때, 메서드 deny:의 사용에 유의하십시오. aTest deny:anExpression은 aTest assert:와 동일한 존재이고 anExpression과는 동일한 존재가 아니지만, 훨씬 더 알아보기 쉽습니다.

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

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

{{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}} 으로 테스트 메서드들을 실행할 수 있도록 허용하는, 실행가능한 주석을 테스트 메서드들 속에 포함시킵니다.

[[image:test-runner.png|none|698px|thumb|그림 7.1: 스퀵 SUnit Test Runner]]

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

{{CommentSqueak|{{Template:HighlightBold|ExampleSetTest»testRemove}}에서 버그를 소개하고, 테스트를 다시 실행하십시오. 예를 들어 5를 4로 변경해보십시오.}}

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

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

또는

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

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

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

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

{{CommentSqueak|오류와 실패를 불러 일으키는 여러분의 테스트들을 수정하십시오.}}

==Notes==
<references />

[[Category:SqueakByExample]]

Onionmixer at 05:17, 30 August 2012

2012-08-30T05:17:41Z

← Older revision		Revision as of 05:17, 30 August 2012
Line 46:		Line 46:
	===3 단계: 몇 가지 테스트 메서드를 작성하기===		===3 단계: 몇 가지 테스트 메서드를 작성하기===

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

Onionmixer at 04:46, 30 August 2012

2012-08-30T04:46:14Z

← Older revision		Revision as of 04:46, 30 August 2012
Line 27:		Line 27:
	===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)의 실행 전에 불러집니다(invoked)


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


	~~메소드~~ 7.2 고정물(fixture)셋업하기		메서드 7.2 고정물(fixture)셋업하기
	<syntaxhighlight lang="smalltalk">		<syntaxhighlight lang="smalltalk">
	ExampleSetTest»setUp		ExampleSetTest»setUp
Line 44:		Line 44:


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

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


	{{CommentSqueak\|다음 테스트 ~~메소드들을~~ 정의합니다.}}		{{CommentSqueak\|다음 테스트 메서드들을 정의합니다.}}


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


	~~메소드~~ 7.3 set 멤버십(set membership) 테스트 하기		메서드 7.3 set 멤버십(set membership) 테스트 하기
	<syntaxhighlight lang="smalltalk">		<syntaxhighlight lang="smalltalk">
	ExampleSetTest»testIncludes		ExampleSetTest»testIncludes
Line 66:		Line 66:


	~~메소드~~ 7.4: 발생(occurrences) 테스트		메서드 7.4: 발생(occurrences) 테스트
	<syntaxhighlight lang="smalltalk">		<syntaxhighlight lang="smalltalk">
	ExampleSetTest»testOccurrences		ExampleSetTest»testOccurrences
Line 86:		Line 86:
	</syntaxhighlight>		</syntaxhighlight>

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

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


	여러분은 또한 다음 코드에서 {{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}} 으로 테스트 메서드들을 실행할 수 있도록 허용하는, 실행가능한 주석을 (executable comment) 우리 자신의 테스트 메서드들 속에 포함시킵니다.


Line 103:		Line 103:


	~~메소드~~ 7.6: 테스트 ~~메소드에서~~ 실행가능한 주석(Executable comments)		메서드 7.6: 테스트 메서드에서 실행가능한 주석(Executable comments)
	<syntaxhighlight lang="smalltalk">		<syntaxhighlight lang="smalltalk">
	ExampleSetTest»testOccurrences		ExampleSetTest»testOccurrences
Line 134:		Line 134:
	===5단계: 결과의 해석===		===5단계: 결과의 해석===

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

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

Onionmixer at 08:34, 16 August 2012

2012-08-16T08:34:47Z

← Older revision		Revision as of 08:34, 16 August 2012
Line 137:		Line 137:

	실제로 3 개의 가능한 테스트 결과가 있습니다. 우리가 희망하는 결과는 테스트의 모든 주장들이(assertions) 참이 되는 것이고, 그럴 경우, 테스트가 패스됩니다. Test Runner에서, 모든 테스트들이 패스될 때, 상단의 막대가 녹색으로 변합니다. 그럼에도 불구하고, 여러분이 테스트를 실행할 때, 잘못될 수 있는 두 가지 종류의 그 무엇이 있습니다. 가장 분명한 것은, 주장들(assertions)의 하나가 테스트를 실패로 이끌 수 있는 거짓(false)이 될 수 있다는 것입니다. 그럼에도 불구하고 message not understood 에러 또는 index out of bounds error와 같이 테스트가 실행되는 동안 발생되는 몇 가지 종류의 발생 가능한 에러가 있을 수 있습니다. 만약 에러가 발생하면 테스트 메소드(the test method)에 있는 주장(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\|에러들과 실패들을 불러 일으키는 여러분의 테스트들을 수정합니다.}}

Onionmixer: SBE SUNIT의예제 페이지 추가

2012-08-16T08:34:27Z

SBE SUNIT의예제 페이지 추가

New page

==SUnit 의 예==

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

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

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

클래스 7.1: 견본 세트 테스트 클래스
<syntaxhighlight lang="smalltalk">
TestCase subclass: #ExampleSetTest
instanceVariableNames: 'full empty'
classInstanceVariableNames: ''
poolDictionaries: ''
category: 'MyTest'
</syntaxhighlight>

우리는 클래스 세트와 연관된 모든 테스트들을 범주화 하기 위해 클래스 '''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)

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

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

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

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

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

{{CommentSqueak|다음 테스트 메소드들을 정의합니다.}}

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

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

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

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

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

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

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

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

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

{{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) 우리 자신의 테스트 메소드들 속에 포함시킵니다.

[[image:test-runner.png|none|698px|thumb|그림 7.1: 스퀵 SUnit Test Runner]]

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

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

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

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

또는

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

===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에서 실패한 테스트들은 상단의 막대를 노랑색으로 바꾸며, 오른쪽의 패널에 열거됩니다. 반면에 에러가 있는 테스트들은 막대를 빨강으로 바꾸며, 오른쪽 아래의 패널에 열거됩니다.

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

==Notes==
<references />

[[Category:SqueakByExample]]