사용자 삽입 이미지

아주 올드한 디버깅 자바부터 제가 갖고 있는 책은 7권 정도 됩니다.
디버깅 자바: 버그 잡는 방법에 대한 일반론부터 정책들까지 다뤄집니다. (2000년 번역)

실용주의 프로그래머를 위한 단위 테스트 with JUnit : 가장 얇습니다만 굉장히 실용적입니다. (2004년 번역)

이클립스 기반 프로젝트 필수 유틸리티 : 국내 최초의 협업을 주제로 한 책입니다. JUnit과 Ant의 랑데뷰가 그려집니다.(2004년)

테스트 주도 개발 : 이게 다 이 책 때문입니다. (2005년 번역)

지름길로 빠르게 배울 수 있는 자바 프로그래밍 : 미스테리한 책입니다. 일단 출판사가 교학사, 뚜시쿵!!! 원제는 Agile Java : Crafting Code With Test-Driven Development. 아하! 그럴만 하겠죠. 자바 기초 서적인데 Hello World 나오기 전에 JUnit부터 나옵니다. 말 다했죠. (2005년 번역)
Unit Testing In Java : 2004년에 사서 아직도 다 못 봤습니다. UI, 웹, 동시성 등 다양한 영역에서 테스트 방식을 알려줍니다.

Working Effectively With Legacy Code : 작년 11월에 사서 아직도 2/3밖에 못 읽었습니다. 혹자의 서평이 이 책은 TDD의 실무 적용판이다라고 적절하게 하신 듯 합니다.

이 외에도 더 있습니다. 기억이 나거나 습득하게 되는 대로 계속 포스팅하고 싶습니다. ^^
급한 IBM의 협찬으로 볼펜과 샤방한 developerWorks 스티커를 가지고 갔습니다.
한 시간은 JUnit에 대한 이론, 다른 한 시간은 JUnit의 실제 사용, 그리고 세 번 째 시간은 TPTP의 프로파일링에 대한 가벼운 리뷰 정도가 되었습니다.

관련 자료는 http://okjsp.tistory.com/tag/test 에서 확인할 수 있습니다.

강의를 준비하면서 가장 인상 깊었던 것은 상용 JProfiler 못지 않게 좋아진 TPTP였습니다.

좀 더 많이 연구를 해서 공유를 해야할 것 같네요.

참가하신 분들 긴 시간 동안 잘 들어주셔서 고맙습니다.
그리고 IBM dW 고맙습니다. ^^

지난 글에서도 언급했지만 JUnit은 소프트웨어 업계의 잘 나가는 두 분이 만들었다고 했습니다. Kent Beck, 그리고 Erich Gamma 이 두 분이죠. 한 분은 TDD, Agile, XP로 다른 한 분은 디자인 패턴, 이클립스로 잘 살고 계시죠.

Registered : 2000-11-24 16:05 
뜬금 없는 이 날짜는 sourceforge.net에 JUnit프로젝트가 등록된 날입니다.
http://sourceforge.net/projects/junit/
링크된 페이지 우측 하단에서 확인할 수 있습니다.

8년 전 내가 만든 소프트웨어가 아직도 발전되고 쓰이고 있다면 기분이 어떨까요. 제 생각으로는 비슷한 것 중에 ANT가 있다고 생각됩니다.

JUnit 4.4가 현재 버전입니다. 3.8.x 까지의 컨벤션들이 Javadoc스타일의 Annotation 때문에 모두 바뀌었습니다.

  1. TestCase를 상속받지 않아도 되고요.
  2. 메소드명이 test로 시작하지 않아도 됩니다.

그 외에도 많은 특징들이 있지만 일단 샘플 하나를 소개하고 마칠까 합니다.

package test;

import org.junit.Test;

import junit.framework.Assert;

public class UnitTest {
 @Test
 public void 더하기() {
  Assert.assertEquals(2, add(1,1));
 }

 private Object add(int i, int j) {
  return i + j;
 }
}

http://www.eclipse.org/articles/Article-TPTP-Profiling-Tool/tptpProfilingArticle.html
문서에 있는 내용은 TPTP 초보자 가이드입니다. 프로파일링을 할 수 있도록 도와주는 것이죠. Test and Performance Tools Platform 이라는 말에서 알 수 있듯이 테스트와 성능진단을 위한 툴들의 플랫폼입니다. 기능이 무진장 많아서 어떻게 시작해야될지 막막한 느낌이 들기는 합니다.

설치를 간편히 하시려면 기존의 이클립스는 놔두시고, all-in-one버전을 받으시길 권장합니다.
ㅠㅠ; 맥용은 all-in-one버전이 없습니다. ^^;
http://www.eclipse.org/tptp/home/downloads/
사용자 삽입 이미지

문서에 있는 샘플을 실행해서 나온 리포트입니다.
사용자 삽입 이미지

몇 번 호출이 되었는지 CPU는 얼마나 사용되었는지, 호출 시간은 어떻게 되고 누적시간은 어떤지 보여줍니다.

공부할 게 또 생겼습니다. 그려~

related:
http://www.eclipse.org/tptp/home/documents/tutorials/profileOnServer/TPTP-WTP.html
테스트만큼 번잡스러운 것이 없습니다. 모두가 동의하는 것은 테스트를 많이 할 수록 버그는 많이 발견된다는 것인데, 문제는 테스트하기가 귀찮다는 것이죠.
6월 14일 발표하는 자료에서 이런 고민에 대한 저의 생각을 풀어볼 생각입니다.
사용자 삽입 이미지


첨부파일은 freemind(http://freemind.sourceforge.net) 마인드 맵 원본입니다.
invalid-file

몇 년 전 okjsp를 통해서 jprofiler를 소개했었습니다.
http://www.google.co.kr/search?q=jprofiler+site%3Aokjsp.pe.kr

맥용으로도 지원이 되는군요. 벌써 버전이 5입니다. 처음 본 때가 3.x 였는데요. ^^;
사용자 삽입 이미지

프로파일링을 간단히 얘기하자면 메모리와 CPU의 활동 내역을 기록하고 보여주는 행위입니다. 객체와 인스턴스의 생성갯수과 소멸 등을 기록합니다. 모든 것을 기록하기 때문에 실행 성능에는 막대한 영향을 줍니다. 쌓이는 로그의 양도 그렇구요.

10일짜리 라이센스를 계속 연장할 수 있습니다. 회사에서 쓴다면 구입하기에 부담되는 가격은 아니니까 툴에 익숙해지시면 구입도 추천합니다.

사용자 삽입 이미지

open session 에서 데모를 돌리시면 물고기 사냥 게임이 나옵니다.
사용자 삽입 이미지

물론 자바로 만들어진 것이구요. 이것을 시작점으로 여러가지 정보를 얻으시면 좋을 듯 합니다.
사용자 삽입 이미지

related: http://ej-technologies.com/
6월 14일 발표할 내용의 일부입니다.
JUnit에 관한 책들은 많이 있습니다.

사용자 삽입 이미지

invalid-file

Working Effectively with Legacy Code 책의 p.147에 있는 내용입니다.
메소드 또는 함수는 두 가지 타입의 역할을 하게 됩니다. 동작의 명령(Command)이 첫번째이고 결과값이 필요한 질의(Query)가 다른 역할입니다.

메소드는 이 두 가지 타입의 역할이 구분되어 있어야 되고, 메소드 내에서 두 가지가 혼용이 된다면 그 메소드의 재활용은 예상치 못한 결과를 초래하게 됩니다.

특히나 메소드 간에 통용되는 필드변수의 값에 변동이 다른 메소드에 영향을 주게 된다면 그 메소드의 독립성은 저하되는 것이고, 이에 따라 코드의 재활용과 테스트 가능성도 낮아지게 됩니다.

내용이 많이 어렵습니다만, 부작용(Side Effect) 없는 코드를 만들기 위해서 중요한 기준 원칙이라 생각합니다.

좋은 예가 생각나면 공유하도록 하겠습니다.
Working Effectively With Legacy Code 책을 다시 보기 시작했습니다.
이제 1/3 정도 읽었는데, 아주 벅찬 책입니다.

124페이지를 보면 다음과 같은 표현이 있습니다.

If we want to avoid talking to the database, we can subclass PermitRepository like this:
public class TestingPermitRepository extends PermitRepository {
...

심각하게 고민해봐야겠습니다.
자바를 좀 한다고 하는 사람들은 TDD를 들어봤을 것입니다. Test Driven Development, 즉 테스트로 주도하는 개발 방법입니다. 2003년인가 http://xper.org 에서 김창준님이 주최하는 XP 그 세번째 이야기 라고 기억되는 연극형 세미나에서 감명을 받은 이후로 계속해서 시도하고 있는 개발방법입니다. 6년째이지만 아직 잘 못하는 방법이기도 합니다.

방법이 기괴한데 먼저 테스트 코드를 짭니다. 테스트의 대상이 되는 코드를 짜기 전에 말이죠. 그래서 이런 형태가 됩니다.
assertEquals( 2, add(1, 1) );


1과 1을 인수로 하는 add() 메소드의 결과는 2와 같아야 된다는 뜻인데, 아직 add() 메소드가 만들어지지 않았지만 이렇게 먼저 선언, 또는 정의합니다. add() 메소드의 결과 동작을 먼저 만드는 것이죠. 에러 납니다. 컴파일도 안됩니다. 아직 없으니까요.

그 다음 동작은 add() 라는 메소드를 만드는 것입니다. 그럼 저 테스트 코드로 add() 메소드의 결과를 확인해 볼 수 있겠죠. 이렇게 개발을 하니 모든 메소드는 자동으로 실행할 수 있는 테스트 코드들을 갖고 있게 됩니다. 이게 모이게 되면 전체 애플리케이션을 테스트할 수 있는 집합체가 구성되는 것이죠.

그런데 이런 방식에는 테스트라는 단어의 레거시가 너무 강했습니다. 일반적인 상식에서는 테스트라 함은 후에 위치한다는 것이 자연스럽기 때문입니다.

사용자 삽입 이미지

그래서 나온 것이 Behavior Driven Development(행위 주도 개발 BDD) 입니다. 자바에서는 JBehave 라는 xUnit과 비슷한 개념으로 나온 것이 있습니다. 이에 관한 developerWorks의 기사를 추천합니다. 사실 저도 Kenny군에게서 일,이 년 전부터 계속 듣기는 했는데, 솔직히 말장난한다는 느낌이 들어서 안 했거든요.

TDD를 하지 않는 이유 중 가장 흔한 것이 "테스팅할 시간이 없어요"와 "테스트하기에 너무 복잡하고 힘든 코드"라는 것이다. 테스트 우선 프로그래밍의 또 다른 장애물은 테스트 우선이라는 개념 그 자체다. 우리 대부분은 테스팅을 감촉적(tactile) 행위, 추상적이기보다는 구체적인 행위로 본다. 우리는 경험적으로 존재하지 않는 어떤 것을 테스트하는 것이 가능하지 않다고 생각한다. 이 개념적인 프레임이 머릿속에 이미 자리잡은 일부 개발자들에게는 '테스트 우선(testing first)'이라는 아이디어가 바보 같은 일로 여겨진다.

그러나 테스트를 작성하고 어떻게 테스트할 것인가 하는 관점이 아닌, 행위(behavior)에 대해 생각해 본다면 어떨까? 여기서 말하는 행위란 애플리케이션이 어떻게 동작'해야' 하는가, 즉 본질적으로 그것의 명세를 말하는 것이다.


국내에도 IDD라 하여 Intention Driven Development를 얘기합니다만 가장 빨리 만들어 내는 방법이라 하여 얘기한다면 BDD와 다르다고 할 수 밖에 없을 듯 합니다. TDD나 BDD의 장점은 Test Harness를 마련해서 기능 추가나 변경에 따른 영향도 감지가 부수적으로 오게 되는 것인데, 그것을 얘기하지 않는다면 유지보수하는 사람들의 고통이 필요하기 때문이죠.

+ Recent posts

티스토리툴바