서버사이드의 웹 서버 뒤에서 동작하는 어플리케이션을 유닛테스팅하기 위해서는 번거롭고 거추장스러운 추가작업이 필요하다. 게다가 EJB 처럼 꽉짜인 묵직한 프래임웍상에서 동작하는 경우라면 더 그렇다.

최근 하는 일중 하나는 웹서비스 API를 만든는 일인데, 이 경우 클라이언트 사이드에서 서버로 HTTP 요청을 보내고 응답을 원하는 응답과 비교하는 테스트를 통해 클라이언트사이드에서 간단히 유닛테스팅을 해 낼 수 있다.

복잡한 HTML 스트림을 응답하는 일반적인 웹 어플리케이션에서는 원하는 HTML을 만드는 일과 실제 응답된 HTML이 동일한지 판별하는 일은 쉬운일이 아니다. (어디 찾아보면 두 HTML이 동일한 지 판별하는 코드가 있겠지만…) 하지만 응답이 정형화된 웹서비스의 경우는 어렵지 않게 동일성 여부를 판단할 수 있다.

이 방법의 단점은 웹 어플리케이션을 구성하는 개개의 클래스를 개별적으로 테스팅하기는 어렵다는 것이다. 하지만 테스팅을 위해 복잡한 구성을 하지않고도 간단히 유닛테스트하여 수정에 대한 최소한의 확신을 가져갈 수 있다.

한가지 즐거움이라면 서버 어플리케이션은 EJB, 클라언트 테스트는 C# + NUnit 식으로 할 수 있다는 점이다. 개인적으로 NUnit을 선호하기 때문에…

총 1760명이 참여했다는 지디넷 코리아 설문조사에 다음과 같은 두가지 질문이 있다.

• “앞으로 5년 후를 주도할 소프트웨어 아키텍처 플랫폼은? “. 1위는 윈도우/닷넷 41.9%.
• “앞으로 5년 후를 주도할 프로그래밍 언어는?”. 1위는 자바 43.4%

그럼… 닷넷 + 자바 = J# 이란 말인가? ㅡ,.ㅡ;

Fedora Core 5에 Mono가 탑재될 것이라고 한다.

나이스~!

오늘은 정말 버전 컨트롤 시스템의 날이다.

요구사항을 적용하기 위해 2~3일간 기존 소스를 수정했왔다.
변경된 내용을 오늘까지 적용하기 위해 야근을 하고 있었다.
오늘 오후 10시가 넘어서 요구사항이 변경되었다.

“A 모드인 경우 새로 작성된 로직을 적용하고 B 모드인 경우 이전 로직을 그대로 적용하는 것이 좋겠다.”

2~3일간 변경된 소스 이제와 어떻게 기존 로직으로 되돌릴 것인가!
순간 당황했다.

Subversion에서 이전 소스를 찾아낸 후 30분정도의 merge 작업으로 간단히 요구사항은 반영됬다.
버전 컨트롤의 도움이 없었다면 하루는 꼬박 작업해야 했을 일이다.

또 하나, 디자이너가 버전 컨트롤 시스템에 자신의 작업을 커밋하는 것을 목격했다.
커밋과 업데이트가 귀찮아 버전 컨트롤 시스템을 거부하는 개발자가 있다는 것을 생각해 보면 신선한 충격이다.

ImplicitInterfaceImplementation (martinFowler.com)

전에도 어디선가 한번은 본 듯하다.
하지만 mock object 만들때 답답한 상황을 접한 후 보니 확~ 와닿는다.