SqueakByExample:1.10: Difference between revisions
Onionmixer (talk | contribs) (번역수정) |
Onionmixer (talk | contribs) (번역 수정) |
||
| (5 intermediate revisions by the same user not shown) | |||
| Line 3: | Line 3: | ||
테스트 주도 개발(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)<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)의 배경 개념은, 코드 자체를 ''작성하기 전에'', 원하는 코드 동작을 정의하는 테스트를 작성하는 것에 있습니다. 그 다음, 테스트를 만족하는 코드를 작성하는거죠. | ||
이제부터 해야할일이 " | 이제부터 해야할일이 "say something loudly and with emphasis"<ref name="역자주1">의역하자면 '''크게 힘주어 말하기''' 정도의 문장이 됩니다.</ref> 를 수행할 메서드를 만드는것이라고 가정해봅시다. 이건 정확하게 어떤 의미가 될까요? 메서드에 붙일 좋은 이름은 무엇일까요? 이 메서드를 관리할 프로그레머가, 이 메서드가 무엇을 해야 하는지 명확하게 알게 하려면 어떻게 해야 하는가? 이런 질문들에 대한 답은 아래와 같습니다. | ||
<center> | <center> 메시지를 문자열 "Don't panic" 으로 보내면, 그 결과는 "DON'T PANIC"이 되어야 합니다.</center> | ||
이 예시를 시스템에서 사용할 수 있도록 하기위해, 테스트 메서드로 변환해 보겠습니다: | |||
메서드 1.1: | 메서드 1.1: "shout" 메서드를 위한 테스트 | ||
<syntaxhighlight lang="smalltalk"> | <syntaxhighlight lang="smalltalk"> | ||
self assert: ('Don''t panic' shout = 'DON''T PANIC!') | self assert: ('Don''t panic' shout = 'DON''T PANIC!') | ||
</syntaxhighlight> | </syntaxhighlight> | ||
스퀵에서는 어떻게 이 새로운 메서드를 만들 수 있을까요? 먼저 어떤 클래스에 메서드를 넣을 것인지 결정해야 합니다. | 스퀵에서는 어떻게 해야 이 새로운 메서드를 만들 수 있을까요? 먼저 어떤 클래스에 새로 만들 메서드를 넣을 것인지 결정해야 합니다. 지금은, String 클래스에 테스트할 "shout" 메서드를 넣고, 관례적으로 이 클래스에 대한 관련 테스트를 실행할 클래스를 StringTest 라고 하겠습니다. | ||
[[image:StringTest-newMethodTemplate.png|none|527px|thumb|그림 1.20: StringTest 클래스에 있는 새로운 메서드 | [[image:StringTest-newMethodTemplate.png|none|527px|thumb|그림 1.20: StringTest 클래스에 있는 새로운 메서드 템플릿]] | ||
{{CommentSqueak|StringTest 클래스에서 브라우저를 열고, 메서드에 적합한 프로토콜을 선택하십시오. 이 같은 | {{CommentSqueak|StringTest 클래스에서 브라우저를 열고, 메서드에 적합한 프로토콜을 선택하십시오. 이 같은 경우에는 그림 1.20에서 보시는 바와 같이 {{HighlightGray|tests - converting}} 이 적당한 프로토콜입니다. 하단 패인의 강조된 텍스트는 스몰토크 메서드가 어떻게 생겼는지 알려주는 기본 템플릿입니다. 이 부분을 지우고 메서드 1.1 의 코드를 입력하십시오.}} | ||
브라우저에 텍스트를 입력하고 나면, 하단 | 브라우저에 텍스트를 입력하고 나면, 하단 패인이 빨간 테두리로 둘러 쌓여진 것을 보십시오. 이는 저장되지 않은 내용이 패인에 있음을 알려주는 알리미입니다. 따라서, 여러분이 작성하던 메서드를 컴파일하고 저장하려면 하단 패인의 노랑 버튼 메뉴에서 {{HighlightGray|accept(s)}}를 선택하거나, CMD-s를 입력하십시오. | ||
따라서, 여러분이 작성하던 메서드를 컴파일하고 저장하려면 하단 | |||
아직 | 아직 "shout" 라고 하는 메서드가 없기 때문에, 브라우저에서 이 이름을 정말 사용할 것인지 물어보고 여러분이 원할만한 다른 이름들을 제안할 것입니다(그림 1.21). 이러한 동작은 입력을 실수했을 때 약간 쓸모있을 수도 있지만, 이번과 같은 경우에는 정말로 만들고자 하는 ''shout'' 메서드를 ''실행'' 하려는 의미이므로, 그림 1.21에서 보시는 바와 같이 메뉴 선택으로부터 첫번째 옵션을 선택하여 shout 를 선택해야 합니다. | ||
[[image:testShoutConfirm.png|none|601px|thumb|그림 1.21: StringTest 클래스의 testShout 메서드 수락]] | [[image:testShoutConfirm.png|none|601px|thumb|그림 1.21: StringTest 클래스의 testShout 메서드 수락]] | ||
{{CommentSqueak|새로 만든 테스트를 실행하십시오. Tools flap에서 끌어 옮기거나 {{HighlightGray|World▷open…▷Test Runner}}를 선택해서 {{HighlightBold|SUnit TestRunner}} 를 여십시오.}} | |||
가장 왼쪽에 있는 두 개의 패인은 시스템 브라우저의 상단 패인과 약간 비슷합니다. 왼쪽 패인에는 시스템 카테고리의 목록이 들어있지만, 이 패인은 테스트 클래스를 포함하는 카테코리에 한정되어 있습니다. | |||
{{CommentSqueak|{{HighlightBold| | |||
{{CommentSqueak|{{HighlightBold|CollectionsTests-Text}}를 선택하면 오른쪽에 있는 패널은 클래스 {{HighlightBold|StringTest}}를 포함한 카테고리의 모든 테스트 클래스를 보여줄 것입니다. 클래스 이름을 이미 선택했다면, 이들 테스트를 실행하기 위해 {{HighlightGray|Run selected}}를 클릭하십시오.}} | |||
| Line 47: | Line 45: | ||
그림 1.22에 보이는 것처럼 테스트 실행 도중 오류가 있었음을 알리는 메시지를 보게 됩니다. 오류를 일으키는 테스트의 목록은 하단 오른쪽 | 그림 1.22에 보이는 것처럼 테스트 실행 도중 오류가 있었음을 알리는 메시지를 보게 됩니다. 오류를 일으키는 테스트의 목록은 하단 오른쪽 패인에 보여집니다. 보시다시피 StringTest>>#testShout가 범인입니다. (참고로 StringTest>>#testShout는 StringTest 클래스의 "testShout" 메서드를 식별하기 위한 스몰토크 방식입니다.) 텍스트 줄을 클릭하면 오류가 생긴 테스트를 다시 실행할 것이며, 이 때 여러분은 "MessageNotUnderstood:ByteString>>shout"와 같은 식으로 발생한 오류를 보게 됩니다. | ||
(참고로 StringTest>>#testShout는 StringTest 클래스의 "testShout" 메서드를 식별하기 위한 스몰토크 방식입니다.) 텍스트 줄을 클릭하면 오류가 생긴 테스트를 다시 실행할 것이며, 이 때 여러분은 "MessageNotUnderstood:ByteString>>shout"와 같은 식으로 발생한 오류를 보게 됩니다. | |||
오류 메시지가 떠 있는 | 오류 메시지가 떠 있는 패인이 바로 스몰토크 디버거 입니다(그림 1.23 참조). 6장에서 디버거를 어떻게 사용하는지 보겠습니다. | ||
[[image:Predebugger.png|none|451px|thumb|그림 1.23: ( | [[image:Predebugger.png|none|451px|thumb|그림 1.23: (pre-)디버거]] | ||
물론 이 | 물론 이 오류는 확실히 기대하던 대로 입니다. 테스트를 실행하면 오류가 발생하는데. 어떻게 "shout" 해야 할 지에 대한 내용을 아직 작성하지 않았기 때문입니다. 그럼에도 불구하고, 테스트가 실패했음을 분명히 해두는 것은 바람직한 습관인데, 테스트 장치를 정확하게 설정 했으며 새 테스트가 실제로 실행중임을 확인시켜주기 때문입니다. 오류를 보고 나면, 디버거 창을 닫아서 실행 중인 테스트를 {{HighlightBox|Abandon}} 할 수 있습니다. 참고로 스몰토크에서는 {{HighlightBox|CreateNote}} 버튼을 사용하여 빠진 메서드를 정의하고, 새로 만든 메서드를 디버거에서 편집하며, 테스트를 {{HighlightBox|Proceed}} 할 수 있습니다. | ||
이제 테스트를 성공으로 | 이제 테스트를 성공으로 만들어줄 메서드를 정의해보도록 하겠습니다! | ||
{{CommentSqueak|시스템 브라우저에서 {{HighlightBold|String}} 클래스를 선택하고, {{HighlightGray|Converting(변환)}} 프로토콜을 선택한 후, 메서드 생성 | {{CommentSqueak|시스템 브라우저에서 {{HighlightBold|String}} 클래스를 선택하고, {{HighlightGray|Converting(변환)}} 프로토콜을 선택한 후, 메서드 생성 템플릿에, 메서드 1.2를 입력하시고 {{HighlightGray|accept}}를 실행하십시오(참고: ↑를 입력하려면, ^를 입력하십시오).}} | ||
| Line 68: | Line 65: | ||
<syntaxhighlight lang="smalltalk"> | <syntaxhighlight lang="smalltalk"> | ||
shout | shout | ||
↑self asUppercase, '!' | ↑self asUppercase, '!' | ||
</syntaxhighlight> | </syntaxhighlight> | ||
쉼표는 문자열 결합 연산자입니다. 따라서 이 메서드 내용에서는 "String" | Smalltalk 에서 쉼표는 문자열 결합 연산자입니다. 따라서 이 메서드 내용에서는 "String" 객체와 "Shout" 메시지의 대문자 버전 문자열에 느낌표를 붙입니다. ↑는 뒤에 이어진 표현식이 메서드에서 반환하는 답이라는 것을 스퀵에 알려주며, 이 경우, 새롭게 연속된 문자열이 됩니다. 이 메서드가 동작할까요? 테스트를 실행하고 살펴보겠습니다. | ||
{{CommentSqueak| | {{CommentSqueak|test runner 에서 {{HighlightGray|Run Selected}}를 다시 클릭하면, 이번에는 모든 테스트가 실패와 오류없이 실행되었음을 알려주는 녹색 표시줄을 볼 수 있을 것입니다.}} | ||
녹색 표시줄을 보셨다면,<ref name="주석1-5">실제로, | 녹색 표시줄을 보셨다면,<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" 메서드]] | ||
==Notes== | ==Notes== | ||
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] 를 수행할 메서드를 만드는것이라고 가정해봅시다. 이건 정확하게 어떤 의미가 될까요? 메서드에 붙일 좋은 이름은 무엇일까요? 이 메서드를 관리할 프로그레머가, 이 메서드가 무엇을 해야 하는지 명확하게 알게 하려면 어떻게 해야 하는가? 이런 질문들에 대한 답은 아래와 같습니다.
이 예시를 시스템에서 사용할 수 있도록 하기위해, 테스트 메서드로 변환해 보겠습니다:
메서드 1.1: "shout" 메서드를 위한 테스트
self assert: ('Don''t panic' shout = 'DON''T PANIC!')
스퀵에서는 어떻게 해야 이 새로운 메서드를 만들 수 있을까요? 먼저 어떤 클래스에 새로 만들 메서드를 넣을 것인지 결정해야 합니다. 지금은, String 클래스에 테스트할 "shout" 메서드를 넣고, 관례적으로 이 클래스에 대한 관련 테스트를 실행할 클래스를 StringTest 라고 하겠습니다.
StringTest 클래스에서 브라우저를 열고, 메서드에 적합한 프로토콜을 선택하십시오. 이 같은 경우에는 그림 1.20에서 보시는 바와 같이 tests - converting 이 적당한 프로토콜입니다. 하단 패인의 강조된 텍스트는 스몰토크 메서드가 어떻게 생겼는지 알려주는 기본 템플릿입니다. 이 부분을 지우고 메서드 1.1 의 코드를 입력하십시오.
브라우저에 텍스트를 입력하고 나면, 하단 패인이 빨간 테두리로 둘러 쌓여진 것을 보십시오. 이는 저장되지 않은 내용이 패인에 있음을 알려주는 알리미입니다. 따라서, 여러분이 작성하던 메서드를 컴파일하고 저장하려면 하단 패인의 노랑 버튼 메뉴에서 accept(s)를 선택하거나, CMD-s를 입력하십시오.
아직 "shout" 라고 하는 메서드가 없기 때문에, 브라우저에서 이 이름을 정말 사용할 것인지 물어보고 여러분이 원할만한 다른 이름들을 제안할 것입니다(그림 1.21). 이러한 동작은 입력을 실수했을 때 약간 쓸모있을 수도 있지만, 이번과 같은 경우에는 정말로 만들고자 하는 shout 메서드를 실행 하려는 의미이므로, 그림 1.21에서 보시는 바와 같이 메뉴 선택으로부터 첫번째 옵션을 선택하여 shout 를 선택해야 합니다.
새로 만든 테스트를 실행하십시오. Tools flap에서 끌어 옮기거나 World▷open…▷Test Runner를 선택해서 SUnit TestRunner 를 여십시오.
가장 왼쪽에 있는 두 개의 패인은 시스템 브라우저의 상단 패인과 약간 비슷합니다. 왼쪽 패인에는 시스템 카테고리의 목록이 들어있지만, 이 패인은 테스트 클래스를 포함하는 카테코리에 한정되어 있습니다.
CollectionsTests-Text를 선택하면 오른쪽에 있는 패널은 클래스 StringTest를 포함한 카테고리의 모든 테스트 클래스를 보여줄 것입니다. 클래스 이름을 이미 선택했다면, 이들 테스트를 실행하기 위해 Run selected를 클릭하십시오.
그림 1.22에 보이는 것처럼 테스트 실행 도중 오류가 있었음을 알리는 메시지를 보게 됩니다. 오류를 일으키는 테스트의 목록은 하단 오른쪽 패인에 보여집니다. 보시다시피 StringTest>>#testShout가 범인입니다. (참고로 StringTest>>#testShout는 StringTest 클래스의 "testShout" 메서드를 식별하기 위한 스몰토크 방식입니다.) 텍스트 줄을 클릭하면 오류가 생긴 테스트를 다시 실행할 것이며, 이 때 여러분은 "MessageNotUnderstood:ByteString>>shout"와 같은 식으로 발생한 오류를 보게 됩니다.
오류 메시지가 떠 있는 패인이 바로 스몰토크 디버거 입니다(그림 1.23 참조). 6장에서 디버거를 어떻게 사용하는지 보겠습니다.
물론 이 오류는 확실히 기대하던 대로 입니다. 테스트를 실행하면 오류가 발생하는데. 어떻게 "shout" 해야 할 지에 대한 내용을 아직 작성하지 않았기 때문입니다. 그럼에도 불구하고, 테스트가 실패했음을 분명히 해두는 것은 바람직한 습관인데, 테스트 장치를 정확하게 설정 했으며 새 테스트가 실제로 실행중임을 확인시켜주기 때문입니다. 오류를 보고 나면, 디버거 창을 닫아서 실행 중인 테스트를 Abandon 할 수 있습니다. 참고로 스몰토크에서는 CreateNote 버튼을 사용하여 빠진 메서드를 정의하고, 새로 만든 메서드를 디버거에서 편집하며, 테스트를 Proceed 할 수 있습니다.
이제 테스트를 성공으로 만들어줄 메서드를 정의해보도록 하겠습니다!
시스템 브라우저에서 String 클래스를 선택하고, Converting(변환) 프로토콜을 선택한 후, 메서드 생성 템플릿에, 메서드 1.2를 입력하시고 accept를 실행하십시오(참고: ↑를 입력하려면, ^를 입력하십시오).
메서드 1.2: "shout" 메서드
shout
↑self asUppercase, '!'
Smalltalk 에서 쉼표는 문자열 결합 연산자입니다. 따라서 이 메서드 내용에서는 "String" 객체와 "Shout" 메시지의 대문자 버전 문자열에 느낌표를 붙입니다. ↑는 뒤에 이어진 표현식이 메서드에서 반환하는 답이라는 것을 스퀵에 알려주며, 이 경우, 새롭게 연속된 문자열이 됩니다. 이 메서드가 동작할까요? 테스트를 실행하고 살펴보겠습니다.
test runner 에서 Run Selected를 다시 클릭하면, 이번에는 모든 테스트가 실패와 오류없이 실행되었음을 알려주는 녹색 표시줄을 볼 수 있을 것입니다.
녹색 표시줄을 보셨다면,[3] 하던 일을 저장하고 잠시 쉴 좋은 때입니다. 그러면 이제 좀 쉬도록 하겠습니다.
