Eternity's Chit-Chat Eternity's Chit-Chat

단위 테스트 딜레마XP를 위시로 한 애자일 진영이 소프트웨어 커뮤니티에 미친 가장 큰 영향은 소프트웨어의 품질을 좌우하는 핵심적인 설계 기법으로서 단위 테스트(Unit Test)의 지위가 격상되었다는 점이다. 단위 테스트는 개발자 관점에서 코드의 안전성과 정확성을 보장할 수 있는 최고의 실행지침이다. 실패하는 단위 테스트 없이 코드를 작성하지 말라는 테스트 주도 개발(Test-Driven Development)의 기본 원칙은 리팩토링(Refactoring), 지속적인 통합(Continuous Integration)과 같은 피드백 기반의 실행지침과 결합됨으로써 안정적이고 신뢰도 높은 소프트웨어 개발을 가능하게 한다.단위 테스트(Unit Test)란 무엇인가소프트웨어 개발 커뮤니티에서 사용되는 대부분의 용어..

소프트웨어 설계 시에 고려해야 할 기본 원리 중 가장 중요한 원리가 무엇이냐고 물어본다면 주저 없이 ‘정보 은닉(Information Hiding)’이라고 대답할 것이다. 정보 은닉(또는 정보 은폐라고도 한다)은 1972년 Davis Parnas가 발표한 “On the Criteria To Be Used in Decomposing Systems Into Modules”에 소개된 이후로 오랜 세월 동안 소프트웨어 개발 분야에 지대한 영향을 끼친 원리이다. 그러나 이런 중요성에도 불구하고 정보 은닉의 개념을 정확하게 이해하고 있는 사람은 많지 않다. 소프트웨어 개발 분야에서 가장 큰 영향력을 지닌 동시에 가장 큰 오해를 받고 있는 두 가지 원리가 있다면 바로 정보 은닉과 캡슐화(Encapsulation)일 ..

얼마 전에 열렸던 회사 컨퍼런스에서 테스트 커버리지를 주제로 한 발표가 있었다. 발표 내용을 간략하게 요약하면 어떤 서비스에 단위 테스트를 작성하도록 정책적인 장치를 마련한 결과 70%의 테스트 커버리지를 얻게 되었다는 것이다. 코드에 실행 가능한 단위 테스트가 존재하고 팀이 지속적으로 70%의 테스트 커버리지를 유지할 수 있다는 것은 팀과 코드의 상태 모두 양호하고 프로젝트의 가시성이 확보되었다는 것을 나타내주는 긍정적인 척도다. 그러나 문제는 발표에서 언급하고 있는 테스트 커버리지의 종류가 라인 커버리지(Line Coverage)라는데 있다. 그리고 더 큰 문제는 대부분의 사람들이 라인 커버리지라는 용어는 무시한 채 70%라는 수치 자체를 중요시 한다는데 있다. 결론부터 말하자면 테스트 커버리지에 대..

이전 글 : 프레임워크 - 1부제어 역전(Inversion of Control)과 프레임워크의존성 역전은 의존성의 방향뿐만 아니라 제어 흐름의 주체 역시 역전 시킨다. 앞서 설명한 것처럼 상위 정책이 구체적인 세부사항에 의존하는 전통적인 구조에서는 상위 정책의 코드가 하부의 구체적인 코드를 호출한다. 즉, 애플리케이션의 코드가 재사용 가능한 라이브러리나 툴킷의 코드를 호출한다. 그러나 의존성을 역전 시킨 객체 지향 구조에서는 반대로 프레임워크가 애플리케이션에 속하는 서브 클래스의 메소드를 호출한다. 따라서 프레임워크를 사용할 경우 개별 애플리케이션에서 프레임워크로 제어 흐름의 주체가 이동된다. 즉, 의존성을 역전시키면 제어 흐름의 주체 역시 역전된다. 이를 제어 역전(Inversion of Control..

재사용과 프레임워크가장 이상적인 재사용 방법은 추가적인 프로그래밍 작업 없이 이미 존재하는 컴포넌트(component)를 조립하여 시스템을 구축하는 것이다. 그러나 이와 같은 컴포넌트 기반의 레고 블록(LEGO block, 또는 집적 회로 IC) 접근 방법에는 분명한 한계가 있다. 다양한 컨텍스트 내에서 컴포넌트를 재사용하기 위해서는 조립 시 다양한 매개변수와 옵션을 설정할 수 있어야 한다. 설정 가능한 파라미터와 옵션의 종류가 적을수록 컴포넌트를 재사용할 수 있는 콘텍스트의 범위가 줄어든다. 반대로 설정 가능한 파라미터와 옵션의 종류가 많을수록 재사용을 위해 기억해야 하는 정보의 양이 늘어나기 때문에 프레임워크를 사용하기가 복잡해진다. 컴포넌트와 관련된 역설은 컴포넌트를 재사용 가능하게 만들려고 하는 ..

이전 글 : 의존성 끊기와 단위 테스트 - 1부의존성 끊기와 설계의존성 끊기 게임의 효과는 단위 테스트만으로 국한되지 않는다. 일반적으로 클래스 간의 의존성을 제어하여 테스트 용이성을 향상시킬 경우 결과적으로 시스템의 설계를 개선시킬 수 있는 가능성이 높아 진다.앞에서 예로 든 통계 서비스의 경우 일간 통계뿐만 아니라, 주간, 월간 단위의 통계 데이터 역시 사용자에게 제공하고 있다. 의존성을 끊기 전에는 에서 볼 수 있는 것처럼 일간, 주간, 월간 작업을 실행하는 클래스 모두가 JobConf와 JobClient에 의존하고 있었으며 입력 경로나 출력 경로 값 이외에 에서 보인 대부분의 코드가 중복되어 있었다. 따라서 일간, 주간, 월간 통계를 테스트하기 어려웠을 뿐만 아니라 절차적인 방식의 설계와 코드 중..

단위 테스트 표류기최근 몇 년 동안 소프트웨어 개발 방식은 혁신적인 전환점을 맞이하게 되었다. 과거의 무겁고 형식적인 프로세스 중심의 개발 방식을 벗어나, 점차 소프트웨어와 사람에 초점을 맞추는 기민하고 적응적인 개발 방식을 채택하는 조직이 늘어나고 있다. 이와 함께 소프트웨어를 개발하는 방식 역시 커다란 변화를 맞이하게 되었는데 그 중 가장 주목할만한 점은 단위 테스트(Unit Test)가 소프트웨어 개발 프로세스의 핵심 요소로 자리를 잡았다는 점이다. 단위 테스트의 핵심 아이디어는 소프트웨어를 구성하는 개별적인 클래스를 고립시킨 상태에서 테스트하는 것이다. 문제는 테스트를 수행하기 위해 클래스를 고립시킨다는 것이 말처럼 간단하지 않다는 점이다. 객체-지향 시스템 안에서 숨쉬고 있는 객체들은 다른 객체..

컴퓨터 프로그래밍이라는 것을 처음 배우기 시작하던 시절에 x = x + 1이라는 문장을 보고 의아하게 생각했던 기억이 있다. 어떻게 x에 1을 더한 값이 x와 같을 수 있지? 더 당황스러웠던 것은 프로그램 내의 함수 f에 대해 f(x) = y이고 f(x) = z일 경우 y와 z가 다른 값일 수 있다는 사실이었다. 별다른 배경지식이 없었던 당시에는 그저 프로그래밍과 수학에서 말하는 함수가 이름은 같지만 정의에 있어서는 미묘한 차이가 있는 것이라고 막연하게 추측했던 것 같다. 그리고 몇 년 후 x = x + 1이라는 문장이 에러라고 생떼를 쓰는 프로그래밍 언어를 보고 다시한 번 당혹감에 빠져 들었다. 왜 x에 1을 더한 값을 x에 대입하는데 에러가 나는거지? 더 짜증이 났던 것은 f(x) = y이고 f(x)..