- 1002/Journal
기존의 AcceptanceTest 들이 작동을 못한다. (Python 에서 정규표현식 이용. 데이터 파싱 & 추출. Prometheus UI 가 바뀌면 다시 바뀜) 전에 구경한 것처럼 XPath 를 이용하는 방법을 궁리해보거나, Prometheus 쪽에서 XML + XSLT 를 이용하는 방법을 궁리했다. 하지만, 그러기엔 현재 Prometheus 의 JSP 부분을 전부 바꾸는데 부담이 크리라 판단, Servlet Controller 중 Service 클래스 부분에 대해 테스트 코드를 붙이는 방법을 생각해 냈다. 하지만, 막상 작성해보고 나니 그 또한 테스트 코드의 크기가 크긴 하다.
Service 와 Controller 가 거의 Composition 이고, 그로 인해 Controller 는 Mapper, Recommender 들이 줄줄히 의존성을 가졌다. 각각의 Mapper, Recommender 들이 DB 를 쓰므로 이를 Mock Object 를 쓸까 하다가, 어차피 현재 작성하는 부분이 AcceptanceTest 의 일부이므로 실제 객체를 그냥 이용해도 좋겠다고 판단, 그대로 이용하고 작성.
Refactoring 을 하기전 Todo 리스트를 정리하는데만 1시간정도를 쓰고 실제 작업을 들어가지 못했다. 왜 오래걸렸을까 생각해보면 Refactoring 을 하기에 충분히 Coverage Test 코드가 없다 라는 점이다. 현재의 UnitTest 85개들은 제대로 돌아가지만, AcceptanceTest 의 경우 함부로 돌릴 수가 없다. 왜냐하면 현재 Release 되어있는 이전 버전에 영향을 끼치기 때문이다. 이 부분을 보면서 왜 JuNe 이 DB 에 대해 세 부분으로 관리가 필요하다고 이야기했는지 깨닫게 되었다. 즉, DB 와 관련하여 개인 UnitTest 를 위한 개발자 컴퓨터 내 로컬 DB, 그리고 Integration Test 를 위한 DB, 그리고 릴리즈 된 제품을 위한 DB 가 필요하다. ("버전업을 위해 기존에 작성한 데이터들을 날립니다" 라고 서비스 업체가 이야기 한다면 얼마나 황당한가.; 버전 패치를 위한, 통합 테스트를 위한 DB 는 따로 필요하다.)
- AcceptanceTest
AcceptanceTest는 UserStory들에 의해서 만들어진다. Iteration 동안 IterationPlanning 회의때 선택되어진 UserStory들은 AcceptanceTest들로 전환되어진다. Customer는 해당 UserStory가 정확히 구현되었을때에 대한 시나리오를 구체화시킨다. 하나의 시나리오는 하나나 그 이상의 AcceptanceTest들을 가진다. 이 AcceptanceTest들은 해당 기능이 제대로 작동함을 보장한다.
AcceptanceTest는 blackbox system test 이다. 각각의 AcceptanceTest는 해당 시스템으로부터 기대되는 결과물에 대해 표현한다. Customer는 AcceptanceTest들에 대한 정확성을 검증과, 실패된 테스트들에 대한 우선순위에 대한 test score를 검토할 책임이 있다. AcceptanceTest들은 또한 production release를 위한 우선순위의 전환시에도 이용된다.
UserStory는 해당 UserStory의 AcceptanceTest를 Pass 하기 전까지는 수행되었다고 생각할 수 없다. 이는 새로운 AcceptanceTest들은 각 Iteration 때 만들어져야 함을 뜻한다.
AcceptanceTest는 자동으로 수행되어져야 하며, 또한 그렇기 때문에 자주 실행될 수 있다. AcceptanceTest score는 개발팀에 의해 점수가 매겨진다. 매 Iteration에 대해 실패한 AcceptanceTest를 수정하기 위한 시간분배 스케줄에 대해서 또한 개발팀의 책임이다.
'AcceptanceTest'란 이름은 본래 'FunctionalTest' 로부터 온 것이다. 이는 ''Customer의 요구사항에 대해 system이 'acceptable' 함을 보증한다''라는 본래의 의도를 더 충실히 반영해준다.
["ProjectPrometheus"] 진행중에 ["1002"] 와 ["상민"]은 AcceptanceTest 를 작성하며 진행하였다. 주로 Python 을 이용하여 간단한 web bot 를 작성, 시스템이 잘 작동하는지에 대해 자동테스트를 구현했다.
(["ProjectPrometheus/AcceptanceTest"], 소스는 ZeroPageServer 의 CVS 프로젝트들중 AcceptanceTestServer 참조)
- Ant/JUnitAndFtp
만일 XP Process 를 따른다면, 전체 CustomerTest(AcceptanceTest) 갯수 / 통과하는 Test 갯수 등이 나오므로, 매번 작업의 진척도를 파악하기 쉽다.
- ExtremeProgramming
초기 Customer 요구분석시에는 UserStory를 작성한다. UserStory는 추후 Test Scenario를 생각하여 AcceptanceTest 부분을 작성하는데 이용한다. UserStory는 개발자들에 의해서 해당 기간 (Story-Point)을 예측(estimate) 하게 되는데, estimate가 명확하지 않을 경우에는 명확하지 않은 부분에 대해서 SpikeSolution 을 해본뒤 estimate을 하게 된다. UserStory는 다시 Wiki:EngineeringTask 로 나누어지고, Wiki:EngineeringTask 부분에 대한 estimate를 거친뒤 Task-Point를 할당한다. 해당 Point 의 기준은 deadline 의 기준이 아닌, programminer's ideal day (즉, 아무런 방해를 받지 않는 상태에서 프로그래머가 최적의 효율을 진행한다고 했을 경우의 기준) 으로 계산한다.
개발시에는 PairProgramming 을 한다. 프로그래밍은 TestFirstProgramming(TestDrivenDevelopment) 으로서, UnitTest Code를 먼저 작성한 뒤 메인 코드를 작성하는 방식을 취한다. UnitTest Code -> Coding -> ["Refactoring"] 을 반복적으로 한다. 이때 Customer 는 스스로 또는 개발자와 같이 AcceptanceTest 를 작성한다. UnitTest 와 AcceptanceTest 로서 해당 모듈의 테스트를 하며, 해당 Task를 완료되고, UnitTest들을 모두 통과하면 Integration (ContinuousIntegration) 을, AcceptanceTest 를 통과하면 Release를 하게 된다. ["Refactoring"] 과 UnitTest, CodingStandard 는 CollectiveOwnership 을 가능하게 한다.
* AcceptanceTest: 사용자 관점에서 해당 작업산출물이 제대로 돌아가는지 확인할 수 있는 테스트.
- Java
||["HttpUnit"] || 웹 AcceptanceTest 를 위한 Framework ||
||["JwebUnit"] || 웹 AcceptanceTest 를 위한 Framework ||
- NSISIde
* AcceptanceTest 를 중간에 짤 시간을 할당하지 못했다. (솔직히 GUI 부분이 들어가는 부분에 대해 감이 오질 않았다. 전에 Web Programming 때에는 직접 HTTP Protocol을 이용, 웹서버로부터 받아온 HTML 문서를 Parsing 한 뒤 그 결과에 대해 Test Code를 작성하는 식이였는데.. (그래도 Manual Test 목록이라도 작성해 두었어야 했는데 이건 계획단계의 실수라 생각)
- ProjectPrometheus/AcceptanceTest
AcceptanceTest Server - http://zeropage.org/~reset/cgi-bin/AcceptanceTestServer/testserver.cgi
- ProjectPrometheus/AcceptanceTestServer
Acceptance Test 환경 만들기 - Python 으로 작성. 165.194.17.55 에서 AcceptanceTest 웹서버 돌리기.
AcceptanceTest / Search Test One , Two 등 테스트 리스트가 나오고, 실행을 할 수 있다.
해당 AcceptanceTest 의 Run 를 클릭하면, WEB 에서 해당 AcceptanceTest (UnitTest 작성 코드) 를 실행하고, 그 결과를 그대로 화면에 출력한다. 그러면 해당 테스트에 대한 결과를 확인할 수 있다.
Python CGI 로 작성된 Acceptance Test 용 서버 -> Acceptance Test 에 대해서 출력 양식. AcceptanceTest 스펙을 구체적으로 명시해둘것.
- ProjectPrometheus/EngineeringTask
|| Iteration 2 AcceptanceTest 작성 || ○ ||
- ProjectPrometheus/Iteration2
|| 7/18 || 1차 Iteration 에 대한 AcceptanceTest. 2차 Iteration 계획. ||
- ProjectPrometheus/Iteration3
|| Iteration 2 AcceptanceTest 작성 || 1 || ○ ||
- ProjectPrometheus/Iteration4
|| ["ProjectPrometheus/AcceptanceTestServer"] 작성 || 2 || ○ ||
|| Iteration 1, 2 AcceptanceTest WEB 에서 테스트 가능하도록 연결 || 1 || ○ ||
- ProjectPrometheus/Iteration9
* AcceptanceTest 에 대해서는 변함 없음.
-> AcceptanceTest Update
- ProjectPrometheus/Journey
* Test 마저 고치는 중, 내가 당연하다고 생각되었던 Test 가 깨진 문제 분석이 실제로 틀렸음을 알게 되었다. 상민이 덕택에 의외로 30분 내로 간단히 해결되었다. 오랜만에 AcceptanceTest 포함 80여개 테스트가 녹색불을 켜게 되었다.
* 대안을 생각중인데, 일종의 Facade 를 만들고, Controller 의 각 service 들은 Facade 만 이용하는 식으로 작성하면 어떨까. 그렇게 한다면 Facade 에 대해서 Test Code 를 작성할 수 있으리라 생각. 또는, Servlet 부분에 대해서는 AcceptanceTest 의 관점으로 접근하는 것을 생각. 또는, cactus 에 대해서 알아봐야 하려나.. --["1002"]
* AcceptanceTest login , view page 테스트 추가
어차피 AcceptanceTest 관련 코드의 경우 Server 프로그램과 독립적으로 돌아가기에 그리 걱정하지 않아도 상관없을듯. 소스는 CVS에 올려놓고 있으니 시간있을때 확인하셔도 좋을듯. --["1002"]
* Python 의 ClientCookie 모듈의 편리함에 즐거워하며. Redirect, cookie 지원. 이건 web browser AcceptanceTest를 위한 모듈이란 생각이 팍팍! --["1002"]
* AcceptanceTest 가 작성되고 나면서부터는 매일 AcceptanceTest 를 돌려서 연기가 나는지(?) 확인해본다. (M$에서의 테스팅처럼..) 매일 AcceptanceTest 를 돌려봄으로서 앞전의 작업에 대해서 그 결과에 대한 보장을 해둔다.
* AcceptanceTest 에 대해서는 Customer 가 이해할 수 있도록 코드를 작성한다. 가급적이면 High-Level 로. 간단한 스크립트언어를 작성하는것도 방법이 되겠다.
* Iteration 1 에서 못한 일들 마저 함. AcceptanceTest 작성.
["Jython"] 의 편리함을 깨닫았다. Java 의 클래스들에 대해서 바로 Import 하여서 쓸 수 있다. 그리고 ["Python"] 에 있는 라이브러리들을 거의 그대로 이용할 수 있다. 단, 한글 문제로 걸림. AcceptanceTest 의 경우 ["Python"] 으로 작성함.
* AcceptanceTest 방법에 대한 논의 부족 - 수요일 이전까지 궁리 예정; 흐..흐;
- TddWithWebPresentation
하지만, 이건 리팩토링 단계에서의 이야기고, 만일 새 코드를 작성하는 중의 UI 부분 presenter 를 TDD로 구현한다면 어떻게 될까? 아마 저 MockViewPresenter 부분이 먼저 구현되고, 이 인터페이스를 근거로 ViewPresenter 를 만든 뒤 HTML 코드 부분을 작성하면 될 것 같다. 실제 UI 에 어떠어떠한 것이 표현되느냐는 AcceptanceTest 단에 맡기면 되리라.
- TestFirstProgramming
이 경우에도 ["MockObjects"] 를 이용할 수 있다. 기본적으로 XP에서의 테스트는 자동화된 테스트, 즉 테스트가 코드화 된 것이다. 처음 바로 접근이 힘들다면 Mock Server / Mock Client 를 만들어서 테스트 할 수 있겠다. 즉, 해당 상황에 대해 이미 내장되어 있는 값을 리턴해주는 서버나 클라이언트를 만드는 것이다. (이는 TestFirstProgramming 에서보단 ["AcceptanceTest"] 에 넣는게 더 맞을 듯 하긴 하다. XP 에서는 UnitTest 와 AcceptanceTest 둘 다 이용한다.)
- XpQuestion
개인적으로, TestDrivenDevelopment 는 연습해보면 배울 게 많다고 생각한다. Test 를 작성하는데에서 배웠던 일들이 많기에. (Test 를 작성하기 위해 큰 모듈덩어리에서 일어나는 중간단계에 대해 더 깊게 생각하고 작은단위로 쪼갠다던지, AcceptanceTest 를 작성하기 위해 전체 시스템 돌아가는 과정을 안다던지 등등)
- Story Card 는 Kent Beck 이 사용자와 더 빠른 피드백을 위해 생각한 덜 형식적인 방법이다. 어차피 Story Card 는 전부 AcceptanceTest 로 작성할 것이기에, 테스트가 작성되고 나면 AcceptanceTest 가 도큐먼트 역할을 할 것이다. Index Card 도구 자체가 보관용이 아니다. 보관이 필요하다면 위키를 쓰거나 디지털카메라 & 스캐너 등등 '보관용 도구', 'Repository' 를 이용하라.
- XpWeek/ToDo
고객 - AcceptanceTest 작성
==== 고객 - AcceptanceTest 작성 ====
모든 AcceptanceTest 통과
Found 18 matching pages out of 7540 total pages
You can also click here to search title.
