SqueakByExample:7.5: Difference between revisions

From 흡혈양파의 번역工房
Jump to navigation Jump to search
(SBE SUnitCookBook 페이지 추가)
 
(번역수정)
 
(4 intermediate revisions by the same user not shown)
Line 1: Line 1:
==SUnit cook book==
==SUnit 활용하기==


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




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


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


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


그 다음, SUnit은 예외 전달(exception propagation)을 테스트 하기 위해 두 개의 추가 메소드인 should:raise:와 shouldnt:raise:를 제공합니다. 예를 들면, 여러분은 aBlock을 실행하는 동안 제기된 특별한 예외인 테스트에 (self should: aBlock raise: anException)사용할 것입니다. 메소드 7.7은 should:raise의 사용을 묘사하였습니다.
첫번째로 살펴볼 메서드는 assert:description: 과 deny:description: 으로서 실패의 원인을 알기 힘든경우, 메서드의 두번째 인수로 테스트가 실패한 이유를 알려주는 string 지정합니다. 뒤에 살펴볼 섹션 7.7 에 이 메서드에 대한 설명이 있습니다.


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


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


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


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


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


메소드 7.7 발생하는 에러 테스트
메서드 7.7 오류 발생에 대한 테스트
<syntaxhighlight lang="smalltalk">
<syntaxhighlight lang="smalltalk">
ExampleSetTest»testIllegal
ExampleSetTest>>testIllegal
   self should: [empty at: 5] raise: Error.
   self should: [empty at: 5] raise: Error.
   self should: [empty at: 5 put: #zork] raise: Error
   self should: [empty at: 5 put: #zork] raise: Error
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 은 스몰토크의 모든 파생 언어들에서 사용될 수 있습니다. SUnit 의 개발자들은 SUnit 이 다른곳에서도 사용될 있도록 하기위해 여러가지-파생언어에 비의존적일 수 있는-각도에서 고려했습니다. '''TestResult class>>error''' 클래스 메서드는 구현언어-독립적인 방식을 위해 시스템의 오류 클래스를 해결책으로 사용합니다. 다음과같은 방법을 사용하면 좋습니다: 만약 테스트를 작성할때 어떤 스몰토크 방언에서도 메서드 7.8 처럼 작성한다면 말이죠.




메소드 7.8: 이동 가능한 에러 취급 (Portable error handling)
메서드 7.8: 간편하게 오류를 다룰 수 있는 방법
<syntaxhighlight lang="smalltalk">
<syntaxhighlight lang="smalltalk">
ExampleSetTest»testIllegal
ExampleSetTest>>testIllegal
   self should: [empty at: 5] raise: TestResult error.
   self should: [empty at: 5] raise: TestResult error.
   self should: [empty at: 5 put: #zork] raise: TestResult error
   self should: [empty at: 5 put: #zork] raise: TestResult error
Line 38: Line 38:




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




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


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


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


<syntaxhighlight lang="smalltalk">
<syntaxhighlight lang="smalltalk">
Line 52: Line 53:




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


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


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




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


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


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


==Notes==
==Notes==

Latest revision as of 15:07, 21 March 2013

SUnit 활용하기

이 섹션에서는 Sunit을 사용하는 방법에 대한 좀 더 세부적인 사항들을 다루게 됩니다. 만약 당신이 JUnit[1]과 같은 다른 테스트 프레임워크를 사용해 본적이 있다면, 이후의 내용중 많은 부분이 익숙하실텐데, 왜냐하면 이 모든 프레임 워크들은 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 의 사용법을 확인할 수 있습니다.


Squeak comment.png이 테스트를 실행해보세요


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

메서드 7.7 오류 발생에 대한 테스트

ExampleSetTest>>testIllegal
  self should: [empty at: 5] raise: Error.
  self should: [empty at: 5 put: #zork] raise: Error


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


메서드 7.8: 간편하게 오류를 다룰 수 있는 방법

ExampleSetTest>>testIllegal
  self should: [empty at: 5] raise: TestResult error.
  self should: [empty at: 5 put: #zork] raise: TestResult error


Squeak comment.png위의 테스트 작성방법을 시도해보시기 바랍니다.


단일 테스트 실행하기

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

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

ExampleSetTest run: #testRemove  1 run, 1 passed, 0 failed, 0 errors


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

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

ExampleSetTest run: #testRemove    1 run, 1 passed, 0 failed, 0 errors


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

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

ExampleSetTest suite run   5 run, 5 passed, 0 failed, 0 errors


Notes