SqueakByExample:7.5 - Revision history

Onionmixer: 번역수정

2013-03-21T15:07:08Z

번역수정

← Older revision		Revision as of 15:07, 21 March 2013
Line 64:		Line 64:


	===반드시 TestCase 의 하위클래스가 되어야 하나요?===		===반드시 TestCase 클래스의 하위클래스가 되어야 하나요?===

	JUnit 에서는, test* 메서드들을 포함하고 있는 임의의 클래스로부터, TestSuite를 구축해 낼 수 있습니다. 스몰토크에서도, 이런식의 동일한 작업을 할 수는 있습니다만, 직접 suite 를 만들어야만 하며, 이렇게 만들어진 클래스는 assert: 와 같은 모든 필수적인 TestCase 메서드들을 실행하게 될 것입니다. 이런작업은 그리 권장하고 싶지 않네요. 현재 존재하는 프레임웍을 사용하는것이 더 좋은 방법입니다.(아래에는 직접 suite를 만든경우 테스트를 진행하는 방법에 대한 예입니다)		JUnit 에서는, test* 메서드들을 포함하고 있는 임의의 클래스로부터, TestSuite를 구축해 낼 수 있습니다. 스몰토크에서도, 이런식의 동일한 작업을 할 수는 있습니다만, 직접 suite 를 만들어야만 하며, 이렇게 만들어진 클래스는 assert: 와 같은 모든 필수적인 TestCase 메서드들을 실행하게 될 것입니다. 이런작업은 그리 권장하고 싶지 않네요. 현재 존재하는 프레임웍을 사용하는것이 더 좋은 방법입니다.(아래에는 직접 suite를 만든경우 테스트를 진행하는 방법에 대한 예입니다)

Onionmixer: 번역수정

2013-03-21T14:44:51Z

번역수정

New page

==SUnit 활용하기==

이 섹션에서는 Sunit을 사용하는 방법에 대한 좀 더 세부적인 사항들을 다루게 됩니다. 만약 당신이 JUnit<ref name="주석7-1">http://junit.org</ref>과 같은 다른 테스트 프레임워크를 사용해 본적이 있다면, 이후의 내용중 많은 부분이 익숙하실텐데, 왜냐하면 이 모든 프레임 워크들은 SUnit를 기반으로 시작되었기 때문이죠. 일반적으로 테스트들을 실행하기 위해서 SUnit 의 GUI 를 사용합니다만, GUI 를 쓰고싶지 않을때도 있습니다.

===Other assertions===

테스트를 만즐때에는 assert: 와 deny: 뿐만아니라, assertions 을 만들기 위해 사용될 수 있는 여러개의 다른 메서드들도 있습니다.

첫번째로 살펴볼 메서드는 assert:description: 과 deny:description: 으로서 실패의 원인을 알기 힘든경우, 메서드의 두번째 인수로 테스트가 실패한 이유를 알려주는 string 을 지정합니다. 뒤에 살펴볼 섹션 7.7 에 이 메서드에 대한 설명이 있습니다.

그 다음으로는, SUnit 에서 제공되는 테스트진행시 적합한 예외가 발생하는지를 테스트하는 메서드인 should:raise:와 shouldnt:raise: 가 있습니다. 예를 들어 self should: aBlock raise:anException 를 실행했을 경우, aBlock 의 실행중에 예외 anException가 발생하면 테스트는 성공입니다. 메서드 7.7 에서 should:raise 의 사용법을 확인할 수 있습니다.

{{CommentSqueak|이 테스트를 실행해보세요}}

should: 와 shouldnt: 의 첫 번째 인수는 처리할 표현식을 포함하고 있는 블록이 되어야 하는것에 주의합니다.

메서드 7.7 오류 발생에 대한 테스트
<syntaxhighlight lang="smalltalk">
ExampleSetTest>>testIllegal
self should: [empty at: 5] raise: Error.
self should: [empty at: 5 put: #zork] raise: Error
</syntaxhighlight>

SUnit 은 다른곳에서도 사용이 가능합니다: SUnit 은 스몰토크의 모든 파생 언어들에서 사용될 수 있습니다. SUnit 의 개발자들은 SUnit 이 다른곳에서도 사용될 수 있도록 하기위해 여러가지-파생언어에 비의존적일 수 있는-각도에서 고려했습니다. '''TestResult class>>error''' 클래스 메서드는 구현언어-독립적인 방식을 위해 시스템의 오류 클래스를 해결책으로 사용합니다. 다음과같은 방법을 사용하면 좋습니다: 만약 테스트를 작성할때 어떤 스몰토크 방언에서도 메서드 7.8 처럼 작성한다면 말이죠.

메서드 7.8: 간편하게 오류를 다룰 수 있는 방법
<syntaxhighlight lang="smalltalk">
ExampleSetTest>>testIllegal
self should: [empty at: 5] raise: TestResult error.
self should: [empty at: 5 put: #zork] raise: TestResult error
</syntaxhighlight>

{{CommentSqueak|위의 테스트 작성방법을 시도해보시기 바랍니다.}}

===단일 테스트 실행하기===

일반적으로, Test Runner 를 해서 작성한 테스트들을 실행할 것입니다. 만약 {{Template:HighlightGray|open...}} 메뉴 또는 도구 플랩에서 Test Runner를 실행하는게 귀찮다면, Workspace 등에서 TestRunner 를 {{Template:HighlightGray|print it}} 하면 실행할 수 있습니다.

다음과같이 단일테스트를 실행할 수도 있습니다.

<syntaxhighlight lang="smalltalk">
ExampleSetTest run: #testRemove ⇒ 1 run, 1 passed, 0 failed, 0 errors
</syntaxhighlight>

===테스트 클래스에서 모든 테스트들을 실행하기===

TestCase 의 모든 하위클래스들은 suite 라는 메시지에 응답하며, 이 응답은 문자열 "test" 로 시작하는 이름을 가진 클래스에 있는 모든 메서드들을 포함하는 테스트 suite 를 만들게 됩니다. 이렇게 만들어진 suite 의 테스트들을 실행하려면 실행을 원하는 suite 에 run 이라는 메세지를 발송합니다. 예를 들자면 아래와 같습니다:

<syntaxhighlight lang="smalltalk">
ExampleSetTest run: #testRemove ⇒ 1 run, 1 passed, 0 failed, 0 errors
</syntaxhighlight>

===반드시 TestCase 의 하위클래스가 되어야 하나요?===

JUnit 에서는, test* 메서드들을 포함하고 있는 임의의 클래스로부터, TestSuite를 구축해 낼 수 있습니다. 스몰토크에서도, 이런식의 동일한 작업을 할 수는 있습니다만, 직접 suite 를 만들어야만 하며, 이렇게 만들어진 클래스는 assert: 와 같은 모든 필수적인 TestCase 메서드들을 실행하게 될 것입니다. 이런작업은 그리 권장하고 싶지 않네요. 현재 존재하는 프레임웍을 사용하는것이 더 좋은 방법입니다.(아래에는 직접 suite를 만든경우 테스트를 진행하는 방법에 대한 예입니다)

<syntaxhighlight lang="smalltalk">
ExampleSetTest suite run ⇒ 5 run, 5 passed, 0 failed, 0 errors
</syntaxhighlight>

==Notes==
<references />

[[Category:SqueakByExample]]

Onionmixer at 05:17, 30 August 2012

2012-08-30T05:17:28Z

← Older revision		Revision as of 05:17, 30 August 2012
Line 54:		Line 54:
	===테스트 클래스(a test class)에서 모든 테스트들을 실행하기===		===테스트 클래스(a test class)에서 모든 테스트들을 실행하기===

	TestCase의 모든 서브클래스들은 메시지 ~~스위트~~(the message suite)에 응답할 것이며, 이 응답은 문자열 "test"로 시작하는 이름을 가진 클래스에 있는 모든 메서드들을 포함하는 테스트 ~~스위트~~(a test suite)를 구축할 것입니다. 그 ~~스위트에서~~ 테스트들을 실행하려면 그 ~~스위트에~~ 메시지 run을 발송합니다. 예를 들면:		TestCase의 모든 서브클래스들은 메시지 슈트(the message suite)에 응답할 것이며, 이 응답은 문자열 "test"로 시작하는 이름을 가진 클래스에 있는 모든 메서드들을 포함하는 테스트 슈트(a test suite)를 구축할 것입니다. 그 슈트에서 테스트들을 실행하려면 그 슈트에 메시지 run을 발송합니다. 예를 들면:

	<syntaxhighlight lang="smalltalk">		<syntaxhighlight lang="smalltalk">
Line 63:		Line 63:
	===TestCase를 하위분류(subclass)해야만 하나요?===		===TestCase를 하위분류(subclass)해야만 하나요?===

	JUnit에서, 여러분은 test* 메서드들을 포함하고 있는 임의의 클래스로부터, TestSuite를 구축할 수 있습니다. 스몰토크에서, 동일한 작업을 하실 수 있지만, 손수 직접 ~~스위트~~(suite)를 만들어야만 하며, 여러분의 클래스는 assert:와 같은 모든 필수적인 TestCase 메서드들을 실행하게 될 것입니다. 우리는 여러분에게 이 작업을 시도하지 않으실 것을 권장합니다. 존재하는 프레임 워크를 사용하십시오.		JUnit에서, 여러분은 test* 메서드들을 포함하고 있는 임의의 클래스로부터, TestSuite를 구축할 수 있습니다. 스몰토크에서, 동일한 작업을 하실 수 있지만, 손수 직접 슈트(suite)를 만들어야만 하며, 여러분의 클래스는 assert:와 같은 모든 필수적인 TestCase 메서드들을 실행하게 될 것입니다. 우리는 여러분에게 이 작업을 시도하지 않으실 것을 권장합니다. 존재하는 프레임 워크를 사용하십시오.

	<syntaxhighlight lang="smalltalk">		<syntaxhighlight lang="smalltalk">

Onionmixer at 05:12, 30 August 2012

2012-08-30T05:12:45Z

← Older revision		Revision as of 05:12, 30 August 2012
Line 6:		Line 6:
	===다른 주장들(Other assertions)===		===다른 주장들(Other assertions)===

	assert:와 deny: 뿐만아니라, 주장들(assertions)을 만들기 위해 사용될 수 있는 여러개의 다른 ~~메소드들이~~ 있습니다.		assert:와 deny: 뿐만아니라, 주장들(assertions)을 만들기 위해 사용될 수 있는 여러개의 다른 메서드들이 있습니다.

	제일 먼저, assert:description:과 deny:description:은 테스트 자체로 분명하지 않을 경우, 실패의 이유를 기술하기 위해 사용될 수 있는 메시지 문자열인 두 번째 인수를 취합니다. 이 ~~메소드들은~~ 섹션 7.7에 설명되어 있습니다.		제일 먼저, assert:description:과 deny:description:은 테스트 자체로 분명하지 않을 경우, 실패의 이유를 기술하기 위해 사용될 수 있는 메시지 문자열인 두 번째 인수를 취합니다. 이 메서드들은 섹션 7.7에 설명되어 있습니다.

	그 다음, SUnit은 예외 전달(exception propagation)을 테스트 하기 위해 두 개의 추가 ~~메소드인~~ should:raise:와 shouldnt:raise:를 제공합니다. 예를 들면, 여러분은 aBlock을 실행하는 동안 제기된 특별한 예외인 테스트에 (self should: aBlock raise: anException)을 사용할 것입니다. ~~메소드~~ 7.7은 should:raise의 사용을 묘사하였습니다.		그 다음, SUnit은 예외 전달(exception propagation)을 테스트 하기 위해 두 개의 추가 메서드인 should:raise:와 shouldnt:raise:를 제공합니다. 예를 들면, 여러분은 aBlock을 실행하는 동안 제기된 특별한 예외인 테스트에 (self should: aBlock raise: anException)을 사용할 것입니다. 메서드 7.7은 should:raise의 사용을 묘사하였습니다.


Line 16:		Line 16:


	Should:의 첫 번째 인수와 shoudnt: ~~메소드는~~ 평가될 표현식을 포함하고 있는 블록임인 것에 주의합니다.		Should:의 첫 번째 인수와 shoudnt: 메서드는 평가될 표현식을 포함하고 있는 블록임인 것에 주의합니다.


	~~메소드~~ 7.7 발생하는 에러 테스트		메서드 7.7 발생하는 에러 테스트
	<syntaxhighlight lang="smalltalk">		<syntaxhighlight lang="smalltalk">
	ExampleSetTest»testIllegal		ExampleSetTest»testIllegal
Line 27:		Line 27:


	SUnit은 이동 가능합니다: Sunit은 스몰토크의 모든 파생 언어들로(dialect) 사용될 수 있습니다. Sunit을 이동할 수 있게 만들기 위해, 그 개발자들은 파생언어-의존 측면들(the dialect-dependent aspects)을 추출하였습니다. 클래스 ~~메소드~~ TestResult class»error는 언어-독립 방식으로 (dialect-independent fashion) 시스템의 에러 클래스(error class)를 답변으로 내놓습니다. 여러분이 작성할 ~~메소드~~ 7.7 대신에, 모든 스몰토크 파생 언어에서 작동할 테스트들을 작성하기 원하신다면, 이 SUnit을 활용하십시오.		SUnit은 이동 가능합니다: Sunit은 스몰토크의 모든 파생 언어들로(dialect) 사용될 수 있습니다. Sunit을 이동할 수 있게 만들기 위해, 그 개발자들은 파생언어-의존 측면들(the dialect-dependent aspects)을 추출하였습니다. 클래스 메서드 TestResult class»error는 언어-독립 방식으로 (dialect-independent fashion) 시스템의 에러 클래스(error class)를 답변으로 내놓습니다. 여러분이 작성할 메서드 7.7 대신에, 모든 스몰토크 파생 언어에서 작동할 테스트들을 작성하기 원하신다면, 이 SUnit을 활용하십시오.


	~~메소드~~ 7.8: 이동 가능한 에러 취급 (Portable error handling)		메서드 7.8: 이동 가능한 에러 취급 (Portable error handling)
	<syntaxhighlight lang="smalltalk">		<syntaxhighlight lang="smalltalk">
	ExampleSetTest»testIllegal		ExampleSetTest»testIllegal
Line 54:		Line 54:
	===테스트 클래스(a test class)에서 모든 테스트들을 실행하기===		===테스트 클래스(a test class)에서 모든 테스트들을 실행하기===

	TestCase의 모든 서브클래스들은 메시지 스위트(the message suite)에 응답할 것이며, 이 응답은 문자열 ~~“test”로~~ 시작하는 이름을 가진 클래스에 있는 모든 ~~메소드들을~~ 포함하는 테스트 스위트(a test suite)를 구축할 것입니다. 그 스위트에서 테스트들을 실행하려면 그 스위트에 메시지 run을 발송합니다. 예를 들면:		TestCase의 모든 서브클래스들은 메시지 스위트(the message suite)에 응답할 것이며, 이 응답은 문자열 "test"로 시작하는 이름을 가진 클래스에 있는 모든 메서드들을 포함하는 테스트 스위트(a test suite)를 구축할 것입니다. 그 스위트에서 테스트들을 실행하려면 그 스위트에 메시지 run을 발송합니다. 예를 들면:

	<syntaxhighlight lang="smalltalk">		<syntaxhighlight lang="smalltalk">
Line 63:		Line 63:
	===TestCase를 하위분류(subclass)해야만 하나요?===		===TestCase를 하위분류(subclass)해야만 하나요?===

	JUnit에서, 여러분은 test* ~~메소드들을~~ 포함하고 있는 임의의 클래스로부터, TestSuite를 구축할 수 있습니다. 스몰토크에서, 동일한 작업을 하실 수 있지만, 손수 직접 스위트(suite)를 만들어야만 하며, 여러분의 클래스는 assert:와 같은 모든 필수적인 TestCase ~~메소드들을~~ 실행하게 될 것입니다. 우리는 여러분에게 이 작업을 시도하지 않으실 것을 권장합니다. 존재하는 프레임 워크를 사용하십시오.		JUnit에서, 여러분은 test* 메서드들을 포함하고 있는 임의의 클래스로부터, TestSuite를 구축할 수 있습니다. 스몰토크에서, 동일한 작업을 하실 수 있지만, 손수 직접 스위트(suite)를 만들어야만 하며, 여러분의 클래스는 assert:와 같은 모든 필수적인 TestCase 메서드들을 실행하게 될 것입니다. 우리는 여러분에게 이 작업을 시도하지 않으실 것을 권장합니다. 존재하는 프레임 워크를 사용하십시오.

	<syntaxhighlight lang="smalltalk">		<syntaxhighlight lang="smalltalk">

Onionmixer: SBE SUnitCookBook 페이지 추가

2012-08-16T08:49:27Z

SBE SUnitCookBook 페이지 추가

New page

==SUnit cook book==

이 섹션은 여러분에게 Sunit을 사용하는 방법에 대한 좀 더 세부적인 사항들을 부여할 것입니다. 만약 여러분이 JUnit<ref name="주석7-1">http://junit.org</ref>과 같은 다른 테스트 프레임워크를 사용해 보셨다면, 이 내용 중 많은 부분이 친숙하실 것이며, 그 이유는 이 모든 프레임 워크들이 그 근간을(root) SUnit에 두고 있기 때문입니다. 보통 여러분은 테스트들을 실행하기 위해 SUnit의 GUI를 사용할 것이지만, 여러분이 GUI를 사용하기를 원치 않을 상황들이 존재합니다.

===다른 주장들(Other assertions)===

assert:와 deny: 뿐만아니라, 주장들(assertions)을 만들기 위해 사용될 수 있는 여러개의 다른 메소드들이 있습니다.

제일 먼저, assert:description:과 deny:description:은 테스트 자체로 분명하지 않을 경우, 실패의 이유를 기술하기 위해 사용될 수 있는 메시지 문자열인 두 번째 인수를 취합니다. 이 메소드들은 섹션 7.7에 설명되어 있습니다.

그 다음, SUnit은 예외 전달(exception propagation)을 테스트 하기 위해 두 개의 추가 메소드인 should:raise:와 shouldnt:raise:를 제공합니다. 예를 들면, 여러분은 aBlock을 실행하는 동안 제기된 특별한 예외인 테스트에 (self should: aBlock raise: anException)을 사용할 것입니다. 메소드 7.7은 should:raise의 사용을 묘사하였습니다.

{{CommentSqueak|이 테스트 실행을 시도하십시오.}}

Should:의 첫 번째 인수와 shoudnt: 메소드는 평가될 표현식을 포함하고 있는 블록임인 것에 주의합니다.

메소드 7.7 발생하는 에러 테스트
<syntaxhighlight lang="smalltalk">
ExampleSetTest»testIllegal
self should: [empty at: 5] raise: Error.
self should: [empty at: 5 put: #zork] raise: Error
</syntaxhighlight>

SUnit은 이동 가능합니다: Sunit은 스몰토크의 모든 파생 언어들로(dialect) 사용될 수 있습니다. Sunit을 이동할 수 있게 만들기 위해, 그 개발자들은 파생언어-의존 측면들(the dialect-dependent aspects)을 추출하였습니다. 클래스 메소드 TestResult class»error는 언어-독립 방식으로 (dialect-independent fashion) 시스템의 에러 클래스(error class)를 답변으로 내놓습니다. 여러분이 작성할 메소드 7.7 대신에, 모든 스몰토크 파생 언어에서 작동할 테스트들을 작성하기 원하신다면, 이 SUnit을 활용하십시오.

메소드 7.8: 이동 가능한 에러 취급 (Portable error handling)
<syntaxhighlight lang="smalltalk">
ExampleSetTest»testIllegal
self should: [empty at: 5] raise: TestResult error.
self should: [empty at: 5 put: #zork] raise: TestResult error
</syntaxhighlight>

{{CommentSqueak|이것을 시도해 보십시오.}}

===단일 테스트 실행하기===

보통 여러분은, Test Runner를 사용하여 여러분의 테스트들을 실행할 것입니다. 만약 여러분이 {{Template:HighlightGray|open...}} 메뉴 도는 도구 플랩에서 Test Runner를 실행하기를 원치 않으시면, {{Template:HighlightGray|print it}} 으로 TestRunner를 실행할 수 있습니다.

여러분은 다음과 같이 단일 테스트를 실행할 수 있습니다.

<syntaxhighlight lang="smalltalk">
ExampleSetTest run: #testRemove ⇒ 1 run, 1 passed, 0 failed, 0 errors
</syntaxhighlight>

===테스트 클래스(a test class)에서 모든 테스트들을 실행하기===

TestCase의 모든 서브클래스들은 메시지 스위트(the message suite)에 응답할 것이며, 이 응답은 문자열 “test”로 시작하는 이름을 가진 클래스에 있는 모든 메소드들을 포함하는 테스트 스위트(a test suite)를 구축할 것입니다. 그 스위트에서 테스트들을 실행하려면 그 스위트에 메시지 run을 발송합니다. 예를 들면:

<syntaxhighlight lang="smalltalk">
ExampleSetTest suite run ⇒ 5 run, 5 passed, 0 failed, 0 errors
</syntaxhighlight>

===TestCase를 하위분류(subclass)해야만 하나요?===

JUnit에서, 여러분은 test* 메소드들을 포함하고 있는 임의의 클래스로부터, TestSuite를 구축할 수 있습니다. 스몰토크에서, 동일한 작업을 하실 수 있지만, 손수 직접 스위트(suite)를 만들어야만 하며, 여러분의 클래스는 assert:와 같은 모든 필수적인 TestCase 메소드들을 실행하게 될 것입니다. 우리는 여러분에게 이 작업을 시도하지 않으실 것을 권장합니다. 존재하는 프레임 워크를 사용하십시오.

<syntaxhighlight lang="smalltalk">
ExampleSetTest suite run ⇒ 5 run, 5 passed, 0 failed, 0 errors
</syntaxhighlight>

==Notes==
<references />

[[Category:SqueakByExample]]