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

이전 글 :도메인 특화 언어와 단위 테스트 - 7부테스트 케이스 리팩토링TEST DATA BUILDER를 구현했으므로 이제 이전에 작성한 테스트 케이스를 리팩토링하자. 먼저 대륙의 수가 정확한 지를 검증하는 ContinentSpecification의 테스트 케이스부터 살펴 보자. ContinentSpecification은 Continent가 명세를 만족하는 지만 검증하므로 ContinentSpecification테스트를 위해서는 Continent픽스처를 제외한 다른 정보들은 불필요하다. Atmosphere나 Ocean은 Planet을 생성하기 위해 요구되는 정보일 뿐 현재의 테스트 결과와는 직접적인 관계가 없다. 따라서 에 나열된 현재의 테스트 케이스는 핵심적인 정보가 불필요한 정보의 홍수 속에 묻혀 있..

이전 글 : 도메인 특화 언어와 단위 테스트 - 6부테스트 도메인에 특화된 언어지금까지 살펴 본 것처럼 픽스처로 사용할 객체의 구조가 복잡하고 그로 인해 테스트의 결과를 예측하기 어려울 경우 테스트 케이스를 작성하려는 개발자의 의지는 좌절된다. 테스트를 생성하기 위해 미로처럼 복잡한 픽스처의 내부 구조를 이해해야 할 경우 테스트 케이스의 작성을 미루는 경향이 있다. 실패한 테스트 케이스를 열어 보았을 때 픽스처 설정 부분이 길고 복잡해서 실패의 원인을 파악하기 어려운 경우 테스트 실행 목록에서 해당 테스트 케이스를 제외하거나 테스트가 실패하지 않도록 코드의 구조를 왜곡시킨다. 결국 테스트는 상환하지 못 할 기술 부채(technical debt)를 누적시키는 원흉으로 전락하고 만다. 픽스처로 사용할 객체의..

이전  글 : 도메인 특화 언어와 단위 테스트 - 5부내부 DSL(Internal DSL)내부 DSL은 호스트 언어가 가진 제약 내에서 DSL을 구축한다. 호스트 언어에 대한 의존성은 양날의 검과 같다. 별도의 파서나 도구를 개발하지 않고도 호스트 언어가 제공하는 컴파일러만 있으면 쉽게 DSL을 구축할 수 있다. 그러나 DSL의 표현력이 호스트 언어의 표현력에 의해 제약을 받기 때문에 외부 DSL에 비해 언어의 유창함과 간결함이 상대적으로 떨어지는 경향이 있다. 또한 호스트 언어에서 사용 가능한 어떤 표현이라도 DSL 내에서 적법한 표현이기 때문에 범용 언어의 자유로움 속에서 DSL의 단순함을 잃어버릴 여지가 있다. 또한 언어에 대한 설계와 언어를 사용하는 사고 방식이 호스트 언어의 틀 안에 구속될 수 ..

이전 글 : 도메인 특화 언어와 단위 테스트 - 4부소프트웨어의 본질적인 복잡성프레더릭 브룩스는 그의 기념비적인 논문 “은총알은 없다(No Silver Bullet)”에서 소프트웨어 개발과 관련된 작업을 본질적인 작업(essential task)과 부차적인 작업(accidental task)으로 구분하고 있다. 브룩스에 따르면 본질적인 작업이란 도메인 내의 추상적인 개념들을 명세하고 설계하고 구현 가능한 상태로 정교하게 다듬는 정신적인 작업을 의미한다. 이에 반해 부차적인 작업이란 고안된 추상화를 공간과 시간 제약 속에서 프로그래밍 언어로 변환하는 작업을 말한다.프레더릭 브룩스는 불행히도 소프트웨어 개발과 관련된 전체 작업 가운데 부차적인 작업이 차지하는 비율이 90%를 넘지 않는 한 부차적인 작업에 쏟..

이전 글 : 도메인 특화 언어와 단위 테스트 - 3부FACTORY를 이용한 생성 메서드(CREATION METHOD) 중복 제거픽스처 생성과 관련해서 테스트 케이스 간의 중복을 제거하는 또 다른 방법은 테스트 케이스의 슈퍼 클래스가 아닌 별도의 독립 클래스로 생성 메서드(CREATION METHOD)를 옮기는 것이다. 독립 클래스는 테스트에 필요한 픽스처를 생성하기 위한 오퍼레이션을 제공하는 일종의 FACTORY다. 이처럼 테스트 케이스 클래스 간의 중복 코드를 제거하기 위해 재사용 가능한 테스트 유틸리티 메서드(TEST UTILITY METHOD)를 제공하는 독립적인 클래스를 테스트 도우미(TEST HELPER)라고 한다.테스트 케이스 슈퍼클래스(TESTCASE SUPERCLASS)의 경우 테스트 케이..

이전 글 : 도메인 특화 언어와 단위 테스트 - 2부테스트 코드 리팩토링테스트와 관련 없는 정보(IRRELEVANT INFORMATION)를 너무 상세하게 노출시켜 애매한 테스트(OBSCURE TEST)가 되어버리는 문제를 해결할 수 있는 한 가지 방법은 안정적인 인터페이스를 이용해 픽스처를 생성하는 코드를 캡슐화시키는 것이다. 가장 간단한 방법은 픽스처 생성 코드를 메서드로 추출(EXTRACT METHOD 리팩토링)해서 별도의 테스트 유틸리티 메서드(TEST UTILITY METHOD)로 분리하는 것이다. 이처럼 픽스처를 생성하기 위한 목적을 가진 독립적인 테스트 유틸리티 메서드(TEST UTILITY METHOD)를 생성 메서드(CREATION METHOD)라고 한다. 다음은 픽스처를 생성하기 위해 ..

이전 글 : 도메인 특화 언어와 단위 테스트 - 1부검증을 위한 SPECIFICATION 패턴 적용객체지향 프로그래밍의 기본 원칙은 데이터와 데이터를 이용하는 행위를 함께 두는 것이다. 그러나 때로는 데이터와 행위를 뭉쳐 놓는 것이 최선의 선택이 아닐 수도 있다. 예를 들어 대부분의 개발자들은 도메인 개념을 표현하는 엔티티 내에 데이터베이스 저장과 같은 영속성 로직을 위치시키는 ACTIVE RECORD 패턴보다는 별도의 독립적인 클래스로 영속성 로직을 분리하는 DATA MAPPER 패턴을 선호한다. 기준은 응집도와 결합도다. 영속성 로직과 도메인 로직을 엔티티에 함께 섞는 것은 전체적으로 객체들의 응집도를 낮추고 결합도를 높이는 부정적인 결과를 낳는다. 따라서 영속성 로직이 엔티티의 데이터를 사용하더라도..

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