SqueakByExample:7.5: Difference between revisions
Onionmixer (talk | contribs) mNo edit summary |
Onionmixer (talk | contribs) (번역수정) |
||
(3 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
==SUnit | ==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 | 메서드 7.7 오류 발생에 대한 테스트 | ||
<syntaxhighlight lang="smalltalk"> | <syntaxhighlight lang="smalltalk"> | ||
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 은 스몰토크의 모든 파생 언어들에서 사용될 수 있습니다. SUnit 의 개발자들은 SUnit 이 다른곳에서도 사용될 수 있도록 하기위해 여러가지-파생언어에 비의존적일 수 있는-각도에서 고려했습니다. '''TestResult class>>error''' 클래스 메서드는 구현언어-독립적인 방식을 위해 시스템의 오류 클래스를 해결책으로 사용합니다. 다음과같은 방법을 사용하면 좋습니다: 만약 테스트를 작성할때 어떤 스몰토크 방언에서도 메서드 7.8 처럼 작성한다면 말이죠. | |||
메서드 7.8: | 메서드 7.8: 간편하게 오류를 다룰 수 있는 방법 | ||
<syntaxhighlight lang="smalltalk"> | <syntaxhighlight lang="smalltalk"> | ||
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를 실행하는게 귀찮다면, Workspace 등에서 TestRunner 를 {{Template:HighlightGray|print it}} 하면 실행할 수 있습니다. | |||
다음과같이 단일테스트를 실행할 수도 있습니다. | |||
<syntaxhighlight lang="smalltalk"> | <syntaxhighlight lang="smalltalk"> | ||
Line 52: | Line 53: | ||
===테스트 클래스에서 모든 테스트들을 실행하기=== | |||
TestCase 의 모든 하위클래스들은 suite 라는 메시지에 응답하며, 이 응답은 문자열 "test" 로 시작하는 이름을 가진 클래스에 있는 모든 메서드들을 포함하는 테스트 suite 를 만들게 됩니다. 이렇게 만들어진 suite 의 테스트들을 실행하려면 실행을 원하는 suite 에 run 이라는 메세지를 발송합니다. 예를 들자면 아래와 같습니다: | |||
<syntaxhighlight lang="smalltalk"> | <syntaxhighlight lang="smalltalk"> | ||
ExampleSetTest | ExampleSetTest run: #testRemove ⇒ 1 run, 1 passed, 0 failed, 0 errors | ||
</syntaxhighlight> | </syntaxhighlight> | ||
===반드시 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 의 사용법을 확인할 수 있습니다.
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
단일 테스트 실행하기
일반적으로, 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