SqueakByExample:1.10: Difference between revisions

From 흡혈양파의 번역工房
Jump to navigation Jump to search
(SBE 새로운메소드정의하기 페이지 추가)
 
(번역 수정)
 
(19 intermediate revisions by the same user not shown)
Line 1: Line 1:
==새로운 메소드 정의하기==
==새로운 메서드 정의하기==


[[image:MethodFinder-example1.png|none|467px|thumb|그림 1.19: 예(例)로 메소드 찾기]]
테스트 주도 개발(Test Driven Development)<ref name="주석1-4">Kent Beck, Test Driven Development:By Example. Addison-Wesley, 2003, ISBN 0–321–14653–0.</ref>의 출현은 코드를 작성하는 방식을 바꾸었습니다. TDD 또는 행동 주도 개발(Behavior Driven Development)이라고 하는 테스트 주도 개발(Test Driven Development)의 배경 개념은, 코드 자체를 ''작성하기 전에'', 원하는 코드 동작을 정의하는 테스트를 작성하는 것에 있습니다. 그 다음, 테스트를 만족하는 코드를 작성하는거죠.


테스트 주도 개발(Test Driven Development)의 출현은 우리가 코드를 쓰는 방식을 바꾸었습니다. TTD로 불리는 테스트주도개발(Test Driven Development) 또는 행동주도개발(Behavior Driven Development) 뒤의 아이디어는, 우리가 코드 자체를 기록하기 전에, 우리의 코드의 원했던 코드의 동작을 정의하는 테스트를 기록한다는 것입니다. 오직, 그 작업 이후에, 우리는 테스트를 만족시키는 코드를 기록합니다.
이제부터 해야할일이 "say something loudly and with emphasis"<ref name="역자주1">의역하자면 '''크게 힘주어 말하기''' 정도의 문장이 됩니다.</ref> 를 수행할 메서드를 만드는것이라고 가정해봅시다. 이건 정확하게 어떤 의미가 될까요? 메서드에 붙일 좋은 이름은 무엇일까요? 이 메서드를 관리할 프로그레머가, 이 메서드가 무엇을 해야 하는지 명확하게 알게 하려면 어떻게 해야 하는가? 이런 질문들에 대한 답은 아래와 같습니다.


우리가 해야 할 과제가 “say something loudly and with emphasis”(무엇인가를 강조하여 크게 말하기)라는 메소드를 기록하는 것이라고 가정해 봅시다. 이 말이 정확하게 무엇을 의미할까요? 이 메소드에 좋은 이름은 무엇일까요? 모호한 동작 설명을 갖고 있는 이 메소드를 미래에도 유지해야만 하는 프로그래머들에게 우리는 어떻게 명료화를 시킬 수 있을까요? 우리는 예를 제공하여 이러한 질문들에 답할 수 있습니다.


<center> 메시지를 문자열 "Don't panic" 으로 보내면, 그 결과는 "DON'T PANIC"이 되어야 합니다.</center>


'''우리가 메시지 shout을 문자열 “Don’t panic”에 보낼 때, 그 결과는 반드시 “DON’T PANIC”이 되어야 합니다..'''


이 예시를 시스템에서 사용할 수 있도록 하기위해, 테스트 메서드로 변환해 보겠습니다:


시스템이 사용가능 한 어떤 대상 내부에, 이 예(例)를 만들려면, 우리는 그 예를 테스트 메소드로(a test method) 변환해야 합니다:


 
메서드 1.1: "shout" 메서드를 위한 테스트
 
메소드 1.1: “shout” 메소드를 위한 테스트
<syntaxhighlight lang="smalltalk">
<syntaxhighlight lang="smalltalk">
testShout
self assert: ('Don''t panic' shout = 'DON''T PANIC!')
self assert: ('Don''t panic' shout = 'DON''T PANIC!')
</syntaxhighlight>
</syntaxhighlight>




스퀵에서는 어떻게 해야 이 새로운 메서드를 만들 수 있을까요? 먼저 어떤 클래스에 새로 만들 메서드를 넣을 것인지 결정해야 합니다. 지금은, String 클래스에 테스트할 "shout" 메서드를 넣고, 관례적으로 이 클래스에 대한 관련 테스트를 실행할 클래스를 StringTest 라고 하겠습니다.


스퀵으로 어떻게 이 새로운 메소드를 만들 수 있을까요? 먼저 우리는 어떤 클래스에 메소드가 소속될 것인지를 결정해야만 합니다.
이번 경우, 우리가 테스트할 “shout” 메소드는 클래스 문자열 (class String)속으로 들어가게 될 것이며, 그러므로 이에 대응하는 테스트는 관례적으로, StringTest(문자열 테스트)라고 명칭을 부여하겠습니다.


[[image:StringTest-newMethodTemplate.png|none|527px|thumb|그림 1.20: StringTest 클래스에 있는 새로운 메서드 템플릿]]


{{CommentSqueak|클래스 문자열 테스트(StringTest)에서 브라우저를 열고, 우리의 메소드에 적합한 프로토콜을 선택합니다, 이번 경우 그림 1.20에서 볼 수 있듯이 {{HighlightGray|tests-converting}}이 적합한 프로토콜입니다.}}


{{CommentSqueak|StringTest 클래스에서 브라우저를 열고, 메서드에 적합한 프로토콜을 선택하십시오. 이 같은 경우에는 그림 1.20에서 보시는 바와 같이 {{HighlightGray|tests - converting}} 이 적당한 프로토콜입니다. 하단 패인의 강조된 텍스트는 스몰토크 메서드가 어떻게 생겼는지 알려주는 기본 템플릿입니다. 이 부분을 지우고 메서드 1.1 의 코드를 입력하십시오.}}


[[image:StringTest-newMethodTemplate.png|none|527px|thumb|그림 1.20: 클래스 문자열 테스트(class StringTest)속에 있는 새로운 메소드 탬플릿(method template)]]
브라우저에 텍스트를 입력하고 나면, 하단 패인이 빨간 테두리로 둘러 쌓여진 것을 보십시오. 이는 저장되지 않은 내용이 패인에 있음을 알려주는 알리미입니다. 따라서, 여러분이 작성하던 메서드를 컴파일하고 저장하려면 하단 패인의 노랑 버튼 메뉴에서 {{HighlightGray|accept(s)}}를 선택하거나, CMD-s를 입력하십시오.


아직 "shout" 라고 하는 메서드가 없기 때문에, 브라우저에서 이 이름을 정말 사용할 것인지 물어보고 여러분이 원할만한 다른 이름들을 제안할 것입니다(그림 1.21). 이러한 동작은 입력을 실수했을 때 약간 쓸모있을 수도 있지만, 이번과 같은 경우에는 정말로 만들고자 하는 ''shout'' 메서드를 ''실행'' 하려는 의미이므로, 그림 1.21에서 보시는 바와 같이 메뉴 선택으로부터 첫번째 옵션을 선택하여 shout 를 선택해야 합니다.


아래의 패널에 있는 음영으로 강조된 텍스트는 스몰토크 메소드가 어떤 모습을 갖고 있는 지를 여러분에게 상기 시켜 줍니다. 이 부분을 지우고, 메소드 1.1에서 가져온 코드를 입력합니다. 일단 여러분이 브라우저에 텍스트를 타이핑 하면, 아래의 패널이 빨강색으로 강조됩니다. 이것은 이 창이 저장되지 않은 변경사항들을 포함하고 있음을 상기시켜 줍니다.
[[image:testShoutConfirm.png|none|601px|thumb|그림 1.21: StringTest 클래스의 testShout 메서드 수락]]
그러므로, 아래의 패널 속에서, 노랑색 버튼 메뉴를 불러 {{HighlightGray|accept(s)}}를 선택하거나, 여러분의 메소드를 컴파일하고 저장하기 위해 CMD-s를 타이핑합니다.


그 이유는, 아직 어떤 메소드도 “Shout”로 명칭을 부여 받지 않았기 때문에, 브라우저는 그 Shout라는 이름이 여러분이 정말로 원하는 이름인지를 확인할 것이고, 여러분이 의도했을 수 있는 몇 가지 다른 이름들(그림 1.21)을 제안해 드릴 것입니다. 이 작업은 만약 타이핑 실수를 하였을 경우에 꽤 유용할 수 있지만, 이번 경우, 우리가 지금 만들려고 하는 메소드가 "shout’이고, 우리가 정말로 의도한 타이핑과 일치하기 때문에, 그림 1.21에 보이는 것처럼 메뉴 선택 첫 번째 옵션을 선택하여 확인을 해야만 합니다.


{{CommentSqueak|새로 만든 테스트를 실행하십시오. Tools flap에서 끌어 옮기거나 {{HighlightGray|World▷open…▷Test Runner}}를 선택해서 {{HighlightBold|SUnit TestRunner}} 를 여십시오.}}


{{CommentSqueak|새롭게 만든 여러분의 테스트를 실행합니다. 도구 플랩(Tool flap)에서 드레그를 하거나 {{HighlightGray|World▷open…▷Test Runner}}를 선택하여 “SUnit TestRunner”를 엽니다.}}


가장 왼쪽에 있는 두 개의 패인은 시스템 브라우저의 상단 패인과 약간 비슷합니다. 왼쪽 패인에는 시스템 카테고리의 목록이 들어있지만, 이 패인은 테스트 클래스를 포함하는 카테코리에 한정되어 있습니다.


가장 왼쪽의 두 개의 패널은 시스템 브라우저의 맨 위의 패널들과 약간 유사합니다. 왼쪽의 패널은 시스템 카테고리의 목록을 포함하지만, 그 패널은 테스트 클래스를 포함하는 카테코리에 한정되어 있습니다.


{{CommentSqueak|{{HighlightBold|CollectionsTests-Text}}를 선택하면 오른쪽에 있는 패널은 클래스 {{HighlightBold|StringTest}}를 포함한 카테고리의 모든 테스트 클래스를 보여줄 것입니다. 클래스 이름을 이미 선택했다면, 이들 테스트를 실행하기 위해 {{HighlightGray|Run selected}}를 클릭하십시오.}}


{{CommentSqueak|"Collections Tests-Text”를 실행하면 오른쪽에 있는 패널은 클래스 “StringTest”를 포함하는 카테고리의 위치에 모든 테스트 결과를 보여드릴 것입니다.}}


[[image:testRunnerOnStringTest.png|none|705px|thumb|그림 1.22 String 테스트 실행]]




[[image:testShoutConfirm.png|none|601px|thumb|그림 1.21: “testShout 메소드 클래스(method class) StringTest(문자열테스트)” 수락]]
그림 1.22에 보이는 것처럼 테스트 실행 도중 오류가 있었음을 알리는 메시지를 보게 됩니다. 오류를 일으키는 테스트의 목록은 하단 오른쪽 패인에 보여집니다. 보시다시피 StringTest>>#testShout가 범인입니다. (참고로 StringTest>>#testShout는 StringTest 클래스의 "testShout" 메서드를 식별하기 위한 스몰토크 방식입니다.) 텍스트 줄을 클릭하면 오류가 생긴 테스트를 다시 실행할 것이며, 이 때 여러분은 "MessageNotUnderstood:ByteString>>shout"와 같은 식으로 발생한 오류를 보게 됩니다.


오류 메시지가 떠 있는 패인이 바로 스몰토크 디버거 입니다(그림 1.23 참조). 6장에서 디버거를 어떻게 사용하는지 보겠습니다.


[[image:Predebugger.png|none|451px|thumb|그림 1.23: (pre-)디버거]]


{{CommentSqueak|클래스의 이름들이 이미 선택되었으므로, 이 모든 테스트를 실행하기 위해 {{HighlightGray|Run selected}}를 클릭합니다.}}
 


[[image:testRunnerOnStringTest.png|none|705px|thumb|그림 1.22 문자열 테스트 (String Test) 실행]]
물론 이 오류는 확실히 기대하던 대로 입니다. 테스트를 실행하면 오류가 발생하는데. 어떻게 "shout" 해야 할 지에 대한 내용을 아직 작성하지 않았기 때문입니다. 그럼에도 불구하고, 테스트가 실패했음을 분명히 해두는 것은 바람직한 습관인데, 테스트 장치를 정확하게 설정 했으며 새 테스트가 실제로 실행중임을 확인시켜주기 때문입니다. 오류를 보고 나면, 디버거 창을 닫아서 실행 중인 테스트를 {{HighlightBox|Abandon}} 할 수 있습니다. 참고로 스몰토크에서는 {{HighlightBox|CreateNote}} 버튼을 사용하여 빠진 메서드를 정의하고, 새로 만든 메서드를 디버거에서 편집하며, 테스트를  {{HighlightBox|Proceed}} 할 수 있습니다.




여러분은 그림 1.22에 보이는 것처럼, 테스트 실행시 에러가 있었음을 가리키는 메시지를 반드시 볼 수 있어야만 합니다.
이제 테스트를 성공으로 만들어줄 메서드를 정의해보도록 하겠습니다!


여러분이 보시는 바와 같이, 우측 아래쪽 창에서 보이는 에러를 일으킨 테스트의 목록은, StringTest>>#testShout가 주범입니다.
(StringTest>>#testShout는 문자열테스트 클래스(the StringTest Class)의 “testShout” 메소드를 감지하기 위한 스몰토크 방식임을 주목해 주십시오)
만약 여러분이 텍스트의 라인을 클릭하면, 에러가 생긴 테스트는 다시 실행될 것이며, 이번 경우에 여러분은 그와 같은 방식으로, 발생한 에러 “MessageNotUnderstood:ByteString>>shout"를 보게 됩니다


{{CommentSqueak|시스템 브라우저에서 {{HighlightBold|String}} 클래스를 선택하고, {{HighlightGray|Converting(변환)}} 프로토콜을 선택한 후, 메서드 생성 템플릿에, 메서드 1.2를 입력하시고 {{HighlightGray|accept}}를 실행하십시오(참고: ↑를 입력하려면, ^를 입력하십시오).}}


[[image:Predebugger.png|none|451px|thumb|그림 1.23: (~이전) 디버거 [(pre-)debugger]]]




물론 정확히 우리가 기대했었던 에러가 생겼습니다. 테스트를 실행하면 에러가 발생합니다. 그 이유는 우리가 어떻게 “shout”를 할지에 대해 문자열에게 말해주는 메소드를 아직 만들지 않았기 때문입니다. 그럼에도 불구하고, 그 테스트가 실패를 하였다는 것을 분명히 해두는 것이 좋습니다. 그 이유는 그 작업이 우리가 테스트 기구(the testing machinery)를 정확히 설정하였고, 새로운 테스트가 실제 실행 중이라는 사실을 확인해 주기 때문입니다. 일단 에러가 발생하면 여러분은 실행중인 테스트를 {{HighlightBox|Abandon(포기)}}할 수 있으며 그 포기 작업은 디버그 창(the debugger window)을 닫을 것입니다. 여러분은 종종 스몰토크에서 {{HighlightBox|Create}} button(버튼생성)을 사용하여 누락된 메소드를 정의하고, 디버그를 하여 새롭게 만들어진 메소드를 편집하고 그 테스트를 {{HighlightBox|Proceed(진행)}}할 수 있는 사실에 주목해 주십시오.
메서드 1.2: "shout" 메서드
이제. 성공한 테스트를 만들 메소드를 정의하겠습니다.
 
 
{{CommentSqueak|시스템 브라우저에서 클래스 String(문자열)을 선택하고 {{HighlightGray|Converting(변환)}} 프로토콜을 선택한 후 메소드 생성 탬플릿(the method creation template)위의, 메소드 1.2에서 “the text”를 타이핑한 후 {{HighlightGray|accept}}합니다. (주의 ↑를 얻기 위해, ^를 타이핑합니다.)}}
 
 
 
메소드 1.2: “shout” 메소드
<syntaxhighlight lang="smalltalk">
<syntaxhighlight lang="smalltalk">
shout                                                                 
shout                                                                 
↑self asUppercase, '!'                                                   
    ↑self asUppercase, '!'                                                   
</syntaxhighlight>
</syntaxhighlight>


Smalltalk 에서 쉼표는 문자열 결합 연산자입니다. 따라서 이 메서드 내용에서는 "String" 객체와 "Shout" 메시지의 대문자 버전 문자열에 느낌표를 붙입니다. ↑는 뒤에 이어진 표현식이 메서드에서 반환하는 답이라는 것을 스퀵에 알려주며, 이 경우, 새롭게 연속된 문자열이 됩니다. 이 메서드가 동작할까요? 테스트를 실행하고 살펴보겠습니다.




콤마는 문자열 결합 연산이며(string concatenation operation, 그러므로 이 메소드의 바디는 “String”(문자열) 오브젝트와 “Shout” 메시지가 보내어진 모든 대문자 버전에 느낌표를 첨가합니다.↑는 뒤에 이어진 표현식이, 메소드에서 리턴된 답변이 되도록 하며, 이번 경우에는, 새롭게 연속된 문자열이 됩니다.. 이 메소드가 동작합니까? 테스트를 실행하고 살펴보겠습니다.
{{CommentSqueak|test runner 에서 {{HighlightGray|Run Selected}}를 다시 클릭하면, 이번에는 모든 테스트가 실패와 오류없이 실행되었음을 알려주는 녹색 표시줄을 볼 수 있을 것입니다.}}
 
 
{{CommentSqueak|“test runner(테스트 실행자)”에서 {{HighlightGray|Run Selected}}를 다시 클릭하면, 이번에 여러분은 모든 테스트가 실패와 에러 없이 실행되었음을 가리키는 녹색 바를 볼 수 있어야 합니다.}}




만약 여러분이 녹색 바 를 보시게 되면,<ref name="주석1장5">실제로, 여러분은 몇몇 이미지가 버그 테스트를 포함하고 있고, 여전히 수정된 필요가 있기 때문에 녹색 바를 볼 수 없을 수도 있습니다. 이 현상에 대해 걱정하지 마십시오. 스퀵은 계속해서 진화되고 있습니다.</ref> 하시던 작업을 저장하고 잠시 쉴 좋은 시간입니다. 그러면 지금 당장 휴식을 취해봅시다!
녹색 표시줄을 보셨다면,<ref name="주석1-5">실제로, 몇가지 이미지는 버그 테스트를 포함하고 있고 여전히 수정될 필요가 있기 때문에 녹색 표시줄을 볼 수 없을 수도 있습니다. 이 문제에 대해서는 걱정하지 마십시오. 스퀵은 계속해서 진화하고 있습니다.</ref> 하던 일을 저장하고 잠시 쉴 좋은 때입니다. 그러면 이제 좀 쉬도록 하겠습니다.


[[image:String-Shout.png|none|602px|thumb|그림 1.24: 클래스 "string"에 정의된 "Shout" 메서드]]


[[image:String-Shout.png|none|602px|thumb|그림 1.24: 클래스 "string”에 정의된 “Shout” 메소드]]




Latest revision as of 14:59, 12 August 2017

새로운 메서드 정의하기

테스트 주도 개발(Test Driven Development)[1]의 출현은 코드를 작성하는 방식을 바꾸었습니다. TDD 또는 행동 주도 개발(Behavior Driven Development)이라고 하는 테스트 주도 개발(Test Driven Development)의 배경 개념은, 코드 자체를 작성하기 전에, 원하는 코드 동작을 정의하는 테스트를 작성하는 것에 있습니다. 그 다음, 테스트를 만족하는 코드를 작성하는거죠.

이제부터 해야할일이 "say something loudly and with emphasis"[2] 를 수행할 메서드를 만드는것이라고 가정해봅시다. 이건 정확하게 어떤 의미가 될까요? 메서드에 붙일 좋은 이름은 무엇일까요? 이 메서드를 관리할 프로그레머가, 이 메서드가 무엇을 해야 하는지 명확하게 알게 하려면 어떻게 해야 하는가? 이런 질문들에 대한 답은 아래와 같습니다.


메시지를 문자열 "Don't panic" 으로 보내면, 그 결과는 "DON'T PANIC"이 되어야 합니다.


이 예시를 시스템에서 사용할 수 있도록 하기위해, 테스트 메서드로 변환해 보겠습니다:


메서드 1.1: "shout" 메서드를 위한 테스트 

self assert: ('Don''t panic' shout = 'DON''T PANIC!')


스퀵에서는 어떻게 해야 이 새로운 메서드를 만들 수 있을까요? 먼저 어떤 클래스에 새로 만들 메서드를 넣을 것인지 결정해야 합니다. 지금은, String 클래스에 테스트할 "shout" 메서드를 넣고, 관례적으로 이 클래스에 대한 관련 테스트를 실행할 클래스를 StringTest 라고 하겠습니다.


그림 1.20: StringTest 클래스에 있는 새로운 메서드 템플릿


Squeak comment.pngStringTest 클래스에서 브라우저를 열고, 메서드에 적합한 프로토콜을 선택하십시오. 이 같은 경우에는 그림 1.20에서 보시는 바와 같이 tests - converting 이 적당한 프로토콜입니다. 하단 패인의 강조된 텍스트는 스몰토크 메서드가 어떻게 생겼는지 알려주는 기본 템플릿입니다. 이 부분을 지우고 메서드 1.1 의 코드를 입력하십시오.

브라우저에 텍스트를 입력하고 나면, 하단 패인이 빨간 테두리로 둘러 쌓여진 것을 보십시오. 이는 저장되지 않은 내용이 패인에 있음을 알려주는 알리미입니다. 따라서, 여러분이 작성하던 메서드를 컴파일하고 저장하려면 하단 패인의 노랑 버튼 메뉴에서 accept(s)를 선택하거나, CMD-s를 입력하십시오.

아직 "shout" 라고 하는 메서드가 없기 때문에, 브라우저에서 이 이름을 정말 사용할 것인지 물어보고 여러분이 원할만한 다른 이름들을 제안할 것입니다(그림 1.21). 이러한 동작은 입력을 실수했을 때 약간 쓸모있을 수도 있지만, 이번과 같은 경우에는 정말로 만들고자 하는 shout 메서드를 실행 하려는 의미이므로, 그림 1.21에서 보시는 바와 같이 메뉴 선택으로부터 첫번째 옵션을 선택하여 shout 를 선택해야 합니다.

그림 1.21: StringTest 클래스의 testShout 메서드 수락


Squeak comment.png새로 만든 테스트를 실행하십시오. Tools flap에서 끌어 옮기거나 World▷open…▷Test Runner를 선택해서 SUnit TestRunner 를 여십시오.


가장 왼쪽에 있는 두 개의 패인은 시스템 브라우저의 상단 패인과 약간 비슷합니다. 왼쪽 패인에는 시스템 카테고리의 목록이 들어있지만, 이 패인은 테스트 클래스를 포함하는 카테코리에 한정되어 있습니다.


Squeak comment.pngCollectionsTests-Text를 선택하면 오른쪽에 있는 패널은 클래스 StringTest를 포함한 카테고리의 모든 테스트 클래스를 보여줄 것입니다. 클래스 이름을 이미 선택했다면, 이들 테스트를 실행하기 위해 Run selected를 클릭하십시오.


그림 1.22 String 테스트 실행


그림 1.22에 보이는 것처럼 테스트 실행 도중 오류가 있었음을 알리는 메시지를 보게 됩니다. 오류를 일으키는 테스트의 목록은 하단 오른쪽 패인에 보여집니다. 보시다시피 StringTest>>#testShout가 범인입니다. (참고로 StringTest>>#testShout는 StringTest 클래스의 "testShout" 메서드를 식별하기 위한 스몰토크 방식입니다.) 텍스트 줄을 클릭하면 오류가 생긴 테스트를 다시 실행할 것이며, 이 때 여러분은 "MessageNotUnderstood:ByteString>>shout"와 같은 식으로 발생한 오류를 보게 됩니다.

오류 메시지가 떠 있는 패인이 바로 스몰토크 디버거 입니다(그림 1.23 참조). 6장에서 디버거를 어떻게 사용하는지 보겠습니다.

그림 1.23: (pre-)디버거


물론 이 오류는 확실히 기대하던 대로 입니다. 테스트를 실행하면 오류가 발생하는데. 어떻게 "shout" 해야 할 지에 대한 내용을 아직 작성하지 않았기 때문입니다. 그럼에도 불구하고, 테스트가 실패했음을 분명히 해두는 것은 바람직한 습관인데, 테스트 장치를 정확하게 설정 했으며 새 테스트가 실제로 실행중임을 확인시켜주기 때문입니다. 오류를 보고 나면, 디버거 창을 닫아서 실행 중인 테스트를 Abandon 할 수 있습니다. 참고로 스몰토크에서는 CreateNote 버튼을 사용하여 빠진 메서드를 정의하고, 새로 만든 메서드를 디버거에서 편집하며, 테스트를 Proceed 할 수 있습니다.


이제 테스트를 성공으로 만들어줄 메서드를 정의해보도록 하겠습니다!


Squeak comment.png시스템 브라우저에서 String 클래스를 선택하고, Converting(변환) 프로토콜을 선택한 후, 메서드 생성 템플릿에, 메서드 1.2를 입력하시고 accept를 실행하십시오(참고: ↑를 입력하려면, ^를 입력하십시오).


메서드 1.2: "shout" 메서드 

shout                                                                
    ↑self asUppercase, '!'

Smalltalk 에서 쉼표는 문자열 결합 연산자입니다. 따라서 이 메서드 내용에서는 "String" 객체와 "Shout" 메시지의 대문자 버전 문자열에 느낌표를 붙입니다. ↑는 뒤에 이어진 표현식이 메서드에서 반환하는 답이라는 것을 스퀵에 알려주며, 이 경우, 새롭게 연속된 문자열이 됩니다. 이 메서드가 동작할까요? 테스트를 실행하고 살펴보겠습니다.


Squeak comment.pngtest runner 에서 Run Selected를 다시 클릭하면, 이번에는 모든 테스트가 실패와 오류없이 실행되었음을 알려주는 녹색 표시줄을 볼 수 있을 것입니다.


녹색 표시줄을 보셨다면,[3] 하던 일을 저장하고 잠시 쉴 좋은 때입니다. 그러면 이제 좀 쉬도록 하겠습니다.

그림 1.24: 클래스 "string"에 정의된 "Shout" 메서드


Notes

  1. ↑ Kent Beck, Test Driven Development:By Example. Addison-Wesley, 2003, ISBN 0–321–14653–0.
  2. ↑ 의역하자면 크게 힘주어 말하기 정도의 문장이 됩니다.
  3. ↑ 실제로, 몇가지 이미지는 버그 테스트를 포함하고 있고 여전히 수정될 필요가 있기 때문에 녹색 표시줄을 볼 수 없을 수도 있습니다. 이 문제에 대해서는 걱정하지 마십시오. 스퀵은 계속해서 진화하고 있습니다.
Retrieved from "https://trans.onionmixer.net/mediawiki/index.php?title=SqueakByExample:1.10&oldid=1132"