'분류 전체보기'에 해당되는 글 87건
- 2009.07.31 GTD 따라잡기 #5 - 단계 2 : 처리 (Process)
- 2009.07.31 GTD 따라잡기 #4 - 단계 1 : 수집 (Collect)
- 2009.07.31 GTD 따라잡기 #2 - GTD 준비하기 1
- 2009.07.31 GTD 따라잡기 #1 - 원리 그리고 프로세스
- 2009.07.29 Guidelines for Better Unit Tests
- 2009.07.29 Roo Demo
- 2009.07.28 휴가 첫째날 !!
- 2009.07.26 Things, GTD tool
- 2009.07.24 AspectJ ITD를 이용한 ActiveRecord 구현
- 2009.07.21 Eclipse 3.5 Hidden Treasures
GTD 따라잡기 #4 - 단계 1 : 수집 (Collect) 관리2009. 7. 31. 22:19
GTD 따라잡기 #2 - GTD 준비하기 관리2009. 7. 31. 18:14
GTD 따라잡기 #1 - 원리 그리고 프로세스 관리2009. 7. 31. 15:10
Guidelines for Better Unit Tests TDD2009. 7. 29. 15:04
http://www.infoq.com/news/2009/07/Better-Unit-Tests
Jimmy Bogard는 “Getting value out of your unit tests” 라는 아티클에서 다음과 같은 3가지 규칙을 명시했다.
1. 테스트 이름은 사용자 입장에서 무엇/왜를 기술해야 한다. - 개발자가 테스트의 이름을 보면 의도된 행위가 무엇인지 이해할 수 있어야 한다.
2. 테스트도 코드이다. 테스트에도 사랑을 나눠주라. - 운영코드만 리팩토링해야 하는것이 아니다. 읽기 좋은 테스트는 유지보수하기 쉽고, 다른 사람이 이해하기 쉽다. 길고, 복잡한 테스트를 좋아하는 사람은 없다. 테스트에 30 라인이 넘는 셋업 코드가 있다면 해당 코드를 생성 메소드로 분리하라. 긴 테스트 코드는 개발자를 당혹스럽게 한다. 운영코드에 긴 메소드가 있으면 리팩토링하면서 왜 긴 테스트는 코드는 내버려두는가 ?
3. “Don’t settle on one fixture pattern/organizational style” – Sometimes the standard pattern of one class, one test fixture doesn’t work.
Lior Friedman는 테스트의 첫번째 원칙은 내부 구조가 아니라 외부적인 행위를 테스트하는 것이라고 한다. 달리 표현한다면 해당 클래스에 대한 현재 구조가 아니라 기대치를 테스트하라는 것이다.
Ravichandran Jv는 아래와 같은 자신의 규칙을 언급했다.
1. 가능한 하나의 테스트에 하나의 Assert
2. test 메소드 내에 if/else가 존재한다면 분기문을 다른 개별 테스트 메소드로 분리하라.
3. 테스트 대상 메소드에 if/else가 존재한다면, 이 메소드도 리팩토링 대상이다.
4. 메소드의 이름은 어떤 테스트인지를 나타내야 한다. ex. TestMakeReservation와 TestMakeNoReservation는 다르다.
NUnit의 저자인 Charlie Poole도 하나의 테스트방 하나의 Assert를 언급했다.
Bryan Cook은 아래와 같은 고려할 만한 테스트 관련 목록을 만들었다:
DO: Name Fixtures consistently
DO: Mimic namespaces of Target Code
DO: Name Setup/TearDown methods consistently
CONSIDER: Separating your Tests from your Production Code
DO: Name Tests after Functionality
CONSIDER: Use "Cannot" Prefix for Expected Exceptions
그리고 이상과 같은 모든 이슈들은 Gerard Meszaros의 “xUnit Test Patterns: Refactoring Test Code”이라는 책에 집대성된다.
사는 곳이 제주이다 보니, 휴가 기간이라도 그리 갈곳이 만만치 않다. 또 학원 라이프로 바쁜 아이들 때문에라도 그러기 쉽지 않다.
이번주로 금연을 시작한지 꼭 2달이 된다. 그 동안 체중은 한 1kg 정도 증가한 듯 하다. 금연보다 체중 유지가 더 힘든 것 같다.
오늘 아침 운동 후 76.6이였는데... 2주 동안 잦은 운동으로 체중을 최대한 내려 보도록 해야 겠다.
참 아이폰은 언제 나오나 ? 지겹다. 블랙베리로 확 갈까보다...
Things, GTD tool 관리2009. 7. 26. 21:59
김지현님의 Things에 대한 설명 요약.
Inbox: 해야 할 모든 일들을 기록.
Today: TO DO를 기록해 넣을 때에 당장 해야 할 일
Next: 최대한 빠른 시간 내에 처리해야 할 일
Someday: 마감이 정해지지 않은 시일 내에 해야 할 일
Scheduled: 일정이 정해진 일
ORGANIZE
Projects: 프로젝트 리스트를 정리
Projects를 만든 이후에 그 프로젝트에 하위의 TO DO List를 추가해 넣을 수 있다.
Areas: 특정한 장소(영역)으로 TO DO를 구분할 때 사용(예. 종료)
AspectJ ITD를 이용한 ActiveRecord 구현 Java2009. 7. 24. 16:06
public class ArticleTest {
@Test
public void find() {
Article key = new Article();
Article a = (Article) new Article().find(key);
assertThat(a, is(key));
ArticleContent key2 = new ArticleContent();
ArticleContent a2 = (ArticleContent) new ArticleContent().find(key2);
assertThat(a2, is(key2));
}
}
위 테스트는 find 메소드를 호출하여 그 값이 key와 동일한지 비교하는 테스트이다.
Article, ArticleContent 클래스에는 find 메소드가 존재하지 않는다.
2. Aspect
privileged aspect ActiveRecordITD {
public interface ActiveRecord {};
declare parents : Article implements ActiveRecord;
declare parents : ArticleContent implements ActiveRecord;
@SuppressWarnings("unused")
private void ActiveRecord.log(String methodName) {
System.out.println(this.getClass().getSimpleName()+"#" + methodName +" called !!!");
}
public <T> T ActiveRecord.find(T key) {
log("find");
return key;
}
}
위 aspect에서 특이한 부분을 살펴보도록 하자.
privileged: weaving할 클래스의 private까지도 access 가능하도록 한다.
declare parents: 해당 클래스가 특정 인터페이스를 구현하도록 한다.
public <T> T ActiveRecord.find(T key): ActiveRecord를 구현하는 클래스들에 해당 메소드를 제공한다.
지금까지 간략하게 generic 메소드를 제공하는 ITD를 구현하는 방법을 간략하게 알아보았다. 실제의 경우라면 find 메소드가 보다 복잡해야겠지만서도...