Whiteship's Note


상태 기반 테스트란?

모하니?/Coding : 2008.07.08 20:16


참조 : http://blog.jayfields.com/2008/02/state-based-testing.html

번역 및 요약 및 편역

테스트 대상이 되는 객체에 있는 여러 메소드들을 호출 한 뒤에 객체의 상태를 확인해보는 테스트 기법이다. 테스트 코드가 테스트 대상의 세부 구현 내역에 대해 보더 덜 상세하게 알아도 된다. 따라서, 테스트 대상이 되는 코드의 구현 내용이 바뀐다 하더라도 결과 상태만 같으면 해당 테스트 코드는 깨지지 않고 유지 된다.

사족

흠.. 확실히 EasyMock을 사용할 때는 테스트 대상이 참조하는 객체를 Mock으로 만들고 그 Mock이 어떻게 행동할지를 일일히 세부적으로 순서까지 맞춰가면서 결과값까지 예측, 혹은 녹화를 해줬어야 테스트가 동작을 했습니다. 그래서 테스트 대상이 되는 메소드가 혹시 해당 객체에서 다른 메소드를 호출하거나 호출 순서를 약간 조정하면 해당 테스트를 깨지는 사태가 종종 발생했습니다. 불편했죠. 테스트 만들기도 빡쌨고, 이런식의 코드로 어떻게 (순수) TDD를 하나 싶었습니다. '차라리 이럴바엔 바로 구현을 하지... 테스트 코드를 왜 만들어...' 라는 생각이 절로 나는거죠.

그런데 위의 얘기 처럼 상태 기반으로 테스트를 쉽게 작성할 수만 있다면, Mockito가 그런식 으로 테스트를 작성하기 쉽게 해준다면, 좀 더 시간을 들여서 익혀볼 만 한 것 같습니다. 흠.. 상태 기반 테스트라~ 어떻게 작성해야 하나.. Mockito로 작성된 테스트 코드를 보고 싶네요.
top

Write a comment.


expect -> run -> verify 스타일(ex. Easymock) 바이바이

모하니?/Coding : 2008.07.08 19:50


참조 : http://monkeyisland.pl/2008/02/01/deathwish/

이지목 스타일은 녹화 -> 플레이 -> 확인(expect -> run -> verify) 순으로 mocking 또는 stubbing 하는 거였습니다. 그러나 이 스타일은 다음과 같은 단점들이 있습니다.

1. 테스트 메소드가 지져분해짐.
- 이것 저것 예측/녹화를 해줘야 하는데 그게 테스트를 위해서가 아니라 Mock을 위해서 해줘야 한다는게 좀..

2. 자연스러운 테스트 스타일로 느껴지지 않는다.
- 예측을 한 담에 실행하는게 아니라, 실행 한 다음에 예측되는 Mock의 행위를 나열해 주는게 더 자연스럽다.

3. 테스트가 깨지기 쉽다.
- 새로운 기능을 추가하면, Mock을 사용한 테스트가 왕창 깨지는 경우가 발생한다.

4. 보다 자세한 실패 메시지를 보여줄 수 있었을 텐데...

5. 보다 가독성 좋게 만들 수 있었을 텐데...

그래서 상태 기반 테스트를 제공하는 Mockito를 강추 한다는거...

Mockito 홈에서 다음을 인용합니다.

No expect-run-verify also means that Mockito mocks are often ready without expensive setup upfront. They aim to be transparent and let the developer to focus on testing selected behavior rather than absorb attention.

Mockito has very slim API, almost no time is needed to start mocking. There is only one kind of mock, there is only one way of creating mocks. Just remember that stubbing goes before execution, verifications of interactions go afterwards. You'll soon notice how natural is that kind of mocking when test-driving java code.

즉 stubbing -> execution -> verification 라고 할 수 있겠네요. 훔.. 그래도 왠지 expect -> run -> verify 형태와 비슷해 보이네요.

사용법은 여기에 잘 나와있습니다.
top

Write a comment.


JUnit 4.4에 추가된 Assumetion

모하니?/Coding : 2008.07.08 16:32


테스트 코드를 실행하는 환경이 달라짐에 따라서 테스트가 동작하지 않는 경우가 있는데, 그럴 때는 그런 환경 값들을 테스트를 돌리기 전에 설정해주면 테스트가 다시 잘 돌아갑니다. 예를 들어, 위도우에서는 폴더 구분할 때 \를 쓰지만 리눅스에서는 / 를 쓰고, 라인브레이크나 뭐 기타 표시들이 다를 수 있죠. 그런 경우 파일을 읽어오는 테스트가 있다면 운이 안 좋을 땐 테스트가 실패할 수도 있습니다.

그래서 그러한 "가정"을 실제로 코드로 미리 해두면, 그 테스트가 여러 환경에서 테스트를 하더라도 실패하는 일이 발생하진 않겠죠.

import static org.junit.Assume.*

@Test public void filenameIncludesUsername() {
   assumeThat(File.separatorChar, is('/'));
   assertThat(new User("optimus").configFileName(), is("configfiles/optimus.cfg"));
}

@Test public void correctBehaviorWhenFilenameIsNull() {
   assumeTrue(bugFixed("13356"));  // bugFixed is not included in JUnit
   assertThat(parse(null), is(new NullDocument()));
}

이런 식으로 사용할 수 있군요. 흠.. Stub을 만들고 그걸 Injection 해주는 걸까요.

참조 : http://junit.sourceforge.net/doc/ReleaseNotes4.4.html

ps : assumetion을 @Theory와 @Datapoint라는 것도 있는데 이건 좀 복잡해 보이네요. 패스~!
top

Write a comment.


JUnit 4.4에 추가된 assertThat()

모하니?/Coding : 2008.07.08 15:44


참조
http://junit.sourceforge.net/doc/ReleaseNotes4.4.html

흠.. 맨날 쓰는 메소드만 쓰다보니까, 새로운 기능들을 전혀 몰랐네요;
assertThat() 처럼 멋진 메소드를 이제야 알게 됐습니다.

보통 값을 비교할 때 assertEquals()를 사용해서

assertEquals(new Integer(2), game.getLeastTryCount());

이런식으로 값을 비교합니다. 메소드에 넘겨주는 첫 번째 인자가 기대값이고 뒤에 오는 인자가 실제 값인데, 사실  인자들의 순서가 바껴도 테스트 목적에는 별 다른 지장을 주지 않습니다. 위에서 테스트한 것과 동일한 내용을 assertThat()을 사용하여 다음과 같이 작성할 수 있습니다.

assertThat(game.getLeastTryCount(), is(2));

코드를 한 번 읽어보시죠. 훨씬 좋치 않나요? 위에서 사용한 is() 라는 메소드는 JUnit이 처음로 의존성을 가지고 사용하는 제 3자의 클래스들 입니다. Hamcrest라는 프로젝트 인데, Matcher를 확장한 다양한 메소드들을 제공해주고 있습니다. 그 중 하나가 is() 입니다. 따라서 import 문이 필요한데, 위에서 is만 사용한거 보니까 static import 겠거니.. 하고 짐작을 하셨겠죠?

import static org.hamcrest.CoreMatchers.*;

이렇게 추가해주시면 됩니다.

문장이 읽기 좋다는 장점 외에도 다음과 같은 장점들이 있습니다.
- 콤비네이션 가능. is(not(3)) 이나 eather(2).or(3) 같은 조합을 이뤄서 사용할 수 있음.
- assertEquals() 보다 더 가독성 높은 에러 메시지.
- 커스텀 매처 사용하능.

JUnit 4.4 가 제공하는 매처들
- org.hamcrest.CoreMatchers
- org.junit.matchers.JUnitMatchers.


top

Write a comment.


Eclipse에서 bnd 사용해서 번들 만들기



top

Write a comment.


20080708 GMP

모하니?/GMPing : 2008.07.08 09:12


News

fruit ㅍ룻.
more and more 모렌모어
each year 이치이어
crops 크뢉: 농작물(돈을 벌게 해주는 식물, plants는 그냥 자라는 식물)
pollination: 수분

Many fruits, nuts and berry crops depend on honey bees for pollination, but more and more bee colonies are diying each year.

Screen English

She just needs some space.
That's not what she needs.
Yes she does. From the sound of things you all do. Why don't you go get the papers.
Oh.. mom..
Ye. Go on. It would do you good. Get lost.

Pop's English

But some how I can't believe that anything should happen.
I know where I belong and nothings gonna happen.
She is so high~

Talk Play Learn

너 ~~하지 않니?(이미 알면서 물어보기)
Aren't you ~

Aren't you full?
Aren't you sorry?
Aren't you dizzy?
Aren't you happy?
Aren't you sleepy?
Aren't you health?
Aren't you hungry?

Sound Sound Play

자음이 겹치면 자음을 한 번만 발음한다.
running 러닝
Emma 에마
Madonna 마다나
Sommer 써머ㄹ
Manner 매너

Bit around the bush. = 핵심을 찌르지 못하고 변죽을 울리다.
ex) Please don't bit around the bush. Tell me the truth.
be wasted = 술에 꼴아 박은
She is totally wasted.


'모하니? > GMPing' 카테고리의 다른 글

20080718 GMP  (0) 2008.07.18
20080717 GMP  (0) 2008.07.17
20080716 GMP  (0) 2008.07.16
20080715 GMP  (0) 2008.07.15
20080710 GMP  (0) 2008.07.10
20080708 GMP  (0) 2008.07.08
20080707 GMP  (0) 2008.07.07
20080705 GMP  (0) 2008.07.05
20080704 GMP  (0) 2008.07.04
20080703 GMP  (0) 2008.07.03
20080702 GMP  (0) 2008.07.02
top

TAG GMP

Write a comment.