- 1002/Journal
이걸 상속받아서 getLibrary를 override하고 MockObject로 연결해라.
- MockObjects
실제의 객체역할을 흉내내는 일을 하는 객체이다. 보통 MockObject라는 클래스를 상속받아서 (구현은 각 언어별로 '알아서'이다. ^^; 처음 Mock 의 개념이 나온 컬럼은 Java 소스였다.) 만들어준다. 테스트를 위해서는 처음에 해당 객체에 초기설정을 해 둔다. 그리고 Test를 돌리게 된다.
사용 예1) 여러 사람이 프로그래밍 할때, 독립된 프로그램이 아닌 모듈별로 프로그램을 만들고 있는 경우. 이럴때 해당 모듈을 작성하고 테스트 코드를 만들려고 해도, 다른 모듈의 의존성 때문에 진행이 어렵게 된다. 아직 완성되지 않은 의존성을 가진 모듈을 MockObject로 만듬으로서 해당 모듈을 만드는 동안의 의존성문제를 해결할 수 있다.
-> MockObjects 자체가 인터페이스정의를 위한 도구로 이용할 수 있다. (TestFirstProgramming 에서는 Test Code가 일종의 인터페이스를 정의하기 위한 방법으로 이용된다.)
사용 예2) Datatbase 와 관련된 프로그래밍에 대해서 UnitTest를 할때, DB Connection 에 대한 MockObject를 만들어서 DB Connection을 이용하는 객체에 DB Connection 객체 대신 넣어줌으로서 해당 작업을 하게끔 할 수 있다. 그리고 해당 함수 부분이 제대로 호출되고 있는지를 알기 위해 MockObject안에 Test 코드를 넣어 줄 수도 있다.
MockObject 는 어디까지나 가짜객체이다. 실제 테스트를 할때에는 MockObject를 이용한 경우와 실제의 객체를 이용했을때의 경우 둘 다 고려해야 한다.
본래 MockObjects 관련 글은 Java 소스이지만 각 언어에 따라 나름대로 구현할 방법이 있겠다.
* [http://no-smok.net/seminar/moin.cgi/mockobect_2epy mockobject.py] - Python MockObjects framework
|| MockObject || Mock Object들의 상위클래스. Mock Object들은 MockObject 들을 상속받아서 구현한다. ||
|| Expectation || 소위 말하는 '기대값' 을 위해 미리 Mock Object에 예정된 값들을 채워넣기 위한 클래스들. MockObject는 자신의 구현을 위한 자료구조체로서 Expectation 클래스들을 이용할 수 있다. ||
* 이용방법 - [http://xper.org/wiki/seminar/MockObjects MockObjects] 를 참조.
* http://www.mockobjects.com/endotesting.html.
* http://www.mockobjects.com/papers/jdbc_testfirst.html - MockObjects를 이용한 JDBC 어플리케이션 TestFirstProgramming
* [http://www.pragmaticprogrammer.com/starter_kit/ut/mockobjects.pdf Using Mock Objects] (extracted from pragmatic unit testing)
- TestFirstProgramming
후자의 경우는 해당 코드의 구조를 테스트해나가는 방법으로, 해당 코드의 진행이 의도한 상황에 맞게 진행되어가는지를 체크해나가는 방법이다. 이는 MockObjects 를 이용하여 접근할 수 있다. 즉, 해당 테스트하려는 모듈을 MockObject로 구현하고, 호출되기 원하는 함수들이 제대로 호출되었는지를 (MockObjects 의 mockobject.py 에 있는 ExpectationCounter 등의 이용) 확인하거나 해당 데이터의 추가 & 삭제관련 함수들이 제대로 호출되었는지를 확인하는 방법 (ExpectationList, Set, Map 등의 이용) 등으로서 접근해 나갈 수 있다.
Random 은 우리가 예측할 수 없는 값이다. 이를 처음부터 테스트를 하려고 하는 것은 좋은 접근이 되지 못한다. 이 경우에는 Random Generator 를 ["MockObjects"] 로 구현하여 예측 가능한 Random 값이 나오도록 한 뒤, 테스트를 할 수 있겠다.
이 경우에도 ["MockObjects"] 를 이용할 수 있다. 기본적으로 XP에서의 테스트는 자동화된 테스트, 즉 테스트가 코드화 된 것이다. 처음 바로 접근이 힘들다면 Mock Server / Mock Client 를 만들어서 테스트 할 수 있겠다. 즉, 해당 상황에 대해 이미 내장되어 있는 값을 리턴해주는 서버나 클라이언트를 만드는 것이다. (이는 TestFirstProgramming 에서보단 ["AcceptanceTest"] 에 넣는게 더 맞을 듯 하긴 하다. XP 에서는 UnitTest 와 AcceptanceTest 둘 다 이용한다.)
- StaticInitializer
문제는 StaticInitializer 부분에 대해서 상속 클래스에서 치환을 시킬 수 없다는 점이다. 이는 꽤 심각한 문제를 발생하는데, 특히 Test 를 작성하는중 MockObject 등의 방법을 사용할 때 StaticInitializer 로 된 코드를 치환시킬 수 없기 때문이다. 저 안에 의존성을 가지는 다른 객체를 생성한다고 한다면 그 객체를 Mock 으로 치환하는 등의 일을 하곤 하는데 StaticInitialzer 는 아에 해당 클래스가 인스턴스화 될때 바로 실행이 되어버리기 때문에 치환할 수 없다.
- CxxTest
단점이 있다면 테스트 상속이 안된다는 점이다. 개인적으로 MockObject 만들어 인터페이스 테스트 만든뒤 RealObject 를 만들어 테스트하는 경우가 많은 만큼 귀찮다. (테스트의 중복으로 이어지므로) 어흑.
- TestDrivenDevelopmentBetweenTeams
일단 각 팀들끼리 TDD 를 하면서 팀들간의 대화를 통해서 일종의 공통 interface 를 빼낼 수 있다. 일단은 일종의 MockObject 로 가짜값을 채워서 테스트를 통과시킨뒤, 실제 Object 가 구현되면, 천천히 하나씩 실제 Object 의 interface 를 끼워가면서 테스트를 통과하는지를 확인한다. 그리고 최종적으로 실제 Object 로 MockObject 를 대체시킨다.
- XpWeek/20041224
알바하느라 소홀히 한점이 아쉽다. 또한 MockObjects에 대한 이해가 부족하여 TDD로 진행하지 못한 점이 아쉽다. 5일간 쉼없이 달려왔는데 아직 미흡한 점이 많다. 혼자 리펙토링을 해보았지만 별로 재미 없었다. 구피에서 돌릴 수 있도록 간단한 리펙토링하고 GUI 기능을 추가하고 싶다. 다음주중 하루 잡아서 하는게 어때?? 그리고 나의 최종 목표는 테스트코드를 추가하는 것이다. TDD는 아니지만 네트워크에 대한 MockObjects를 구현해보고 싶다. -- 재선
사실 네트워크에 대한 MockObjects는 어렵지 않았던 것 같아. JUnit에서 제공하는 MockObject클래스를 소켓에 써먹는 방법에 집착한 나머지 포기하지 않았을까? 단순히 서버와 클라이언트 흉내만 내면 될텐데...
- TestDrivenDatabaseDevelopment
[1002]의 경우 TDD 로 DB 부분을 만들때 어떻게 진행될까 궁리하던중 두가지를 실험해보았다. 보통은 TDD로 DB 부분을 만들때 DB Repository 부분에 대해서 MockObject 를 만들지만, 다음은 Mock 을 안만들고 작성해봤다. 어떤 일이 일어날까를 생각하며.
Found 8 matching pages out of 7540 total pages
You can also click here to search title.
