SqueakByExample:1.10

새로운 메소드 정의하기

그림 1.19: 예(例)로 메소드 찾기

테스트 주도 개발(Test Driven Development)의 출현은 우리가 코드를 쓰는 방식을 바꾸었습니다. TTD로 불리는 테스트주도개발(Test Driven Development) 또는 행동주도개발(Behavior Driven Development) 뒤의 아이디어는, 우리가 코드 자체를 기록하기 전에, 우리의 코드의 원했던 코드의 동작을 정의하는 테스트를 기록한다는 것입니다. 오직, 그 작업 이후에, 우리는 테스트를 만족시키는 코드를 기록합니다.

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

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

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

메소드 1.1: “shout” 메소드를 위한 테스트

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

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

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

그림 1.20: 클래스 문자열 테스트(class StringTest)속에 있는 새로운 메소드 탬플릿(method template)

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

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

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

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

Collections Tests-Text를 실행하면 오른쪽에 있는 패널은 클래스 StringTest를 포함하는 카테고리의 위치에 모든 테스트 결과를 보여드릴 것입니다. 클래스의 이름들이 이미 선택되었으므로, 이 모든 테스트를 실행하기 위해 Run selected를 클릭합니다.

그림 1.21: “testShout 메소드 클래스(method class) StringTest(문자열테스트)” 수락

그림 1.22 문자열 테스트 (String Test) 실행

여러분은 그림 1.22에 보이는 것처럼, 테스트 실행시 에러가 있었음을 가리키는 메시지를 반드시 볼 수 있어야만 합니다.

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

그림 1.23: (~이전) 디버거 [(pre-)debugger]

물론 정확히 우리가 기대했었던 에러가 생겼습니다. 테스트를 실행하면 에러가 발생합니다. 그 이유는 우리가 어떻게 “shout”를 할지에 대해 문자열에게 말해주는 메소드를 아직 만들지 않았기 때문입니다. 그럼에도 불구하고, 그 테스트가 실패를 하였다는 것을 분명히 해두는 것이 좋습니다. 그 이유는 그 작업이 우리가 테스트 기구(the testing machinery)를 정확히 설정하였고, 새로운 테스트가 실제 실행 중이라는 사실을 확인해 주기 때문입니다. 일단 에러가 발생하면 여러분은 실행중인 테스트를 Abandon(포기)할 수 있으며 그 포기 작업은 디버그 창(the debugger window)을 닫을 것입니다. 여러분은 종종 스몰토크에서 Create button(버튼생성)을 사용하여 누락된 메소드를 정의하고, 디버그를 하여 새롭게 만들어진 메소드를 편집하고 그 테스트를 Proceed(진행)할 수 있는 사실에 주목해 주십시오. 이제. 성공한 테스트를 만들 메소드를 정의하겠습니다.

시스템 브라우저에서 클래스 String을 선택하고 Converting(변환) 프로토콜을 선택한 후 메소드 생성 탬플릿(the method creation template)위의, 메소드 1.2에서 “the text”를 타이핑한 후 accept합니다. (주의 ↑를 얻기 위해, ^를 타이핑합니다.)

메소드 1.2: “shout” 메소드

shout                                                                
↑self asUppercase, '!'

콤마는 문자열 결합 연산이며(string concatenation operation, 그러므로 이 메소드의 바디는 “String”(문자열) 오브젝트와 “Shout” 메시지가 보내어진 모든 대문자 버전에 느낌표를 첨가합니다.↑는 뒤에 이어진 표현식이, 메소드에서 리턴된 답변이 되도록 하며, 이번 경우에는, 새롭게 연속된 문자열이 됩니다.. 이 메소드가 동작합니까? 테스트를 실행하고 살펴보겠습니다.

test runner에서 Run Selected를 다시 클릭하면, 이번에 여러분은 모든 테스트가 실패와 에러 없이 실행되었음을 가리키는 녹색 바를 볼 수 있어야 합니다.

만약 여러분이 녹색 바 를 보시게 되면, 하시던 작업을 저장하고 잠시 쉴 좋은 시간입니다. 그러면 지금 당장 휴식을 취해봅시다!

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