테스트 주도 개발 실천

테스트 주도 개발 실천

테스트 주도 개발(test-driven development)은 점진적으로 검증하며 코드를 작성하는 소프트웨어 개발 방법이다. 자신이 작성한 코드의 동작을 직접 확인하는 것은 어쩌면 프로그래머의 기본 미덕이고 테스트 주도 개발은 이 미덕의 실천을 프로그래밍 과정 속에 자연스레 녹여낸다. 또한 테스트 주도 개발은 좋은 설계의 강력한 지원자다. 테스트 주도 개발 자체가 좋은 설계를 유도하는 것은 아니지만 프로그래머가 좋은 설계를 위해 노력할 수 있도록 든든히 뒷받침한다.

하지만 테스트 주도 개발은 어렵다. 전통적인 프로그래밍 절차와 상이할 뿐 아니라 긴 시간동안 몸에 밴 나쁜 버릇들이 억제되며 답답함이 느껴지기도 한다. 개념을 이해했다 하더라도 현장에서 실천하는 데에는 많은 장벽들이 있다. 이 글은 가상의 예제가 아니라 간단하지만 실제 서비스 개발에 사용된 사례를 통해 현장에서 테스트 주도 개발이 어떻게 적용되는지 보여준다.

계속 읽기

Advertisements

비공개 메서드를 테스트 해야 하는가?

TDD(Test-Driven Development, 테스트 주도 개발)에 익숙하지 않은, 개체지향 프로그래밍 언어를 사용하는, 프로그래머들은 간혹 이런 질문을 한다.

비공개(private) 메서드도 테스트 해야 하는가?

이 질문의 대답은 ‘그렇다’ 또는 ‘아니다’보다 좀 더 길다. 비공개 메서드의 인터페이스는 테스트 하지 않지만 비공개 메서드의 구현은 테스트 대상이다. 혼란스러울 수 있다. 어쩌라는 말인가?

계속 읽기

적은 코드가 항상 더 좋지는 않다

예상했던 일이지만 소셜 미디어에서 정적 기록자(static logger) 변수를 그만 사용하자는 의견에 반발이 거세다. 모든 의견에 하나하나 대응해 줄 여유가 없음이 안타깝다. 그 중 다음 한가지 의견에 대해 답해 본다.

"우리 응용프로그램은 수백 개의 클래스로 구성된다. 정적 기록자를 사용하지 않기 위해 모든 클래스에 DI(dependency injection) 설정을 하는 것은 비현실적이다."

계속 읽기

정적 기록자는 이제 그만

수십년간 적응력있는 소프트웨어를 만들기 위한 노력이 지속되고 있다. 우리는 많은 원칙들과 패턴들을 도출했고 또 일부는 퇴출시켰다. 도메인은 가장 높은 적응력을 가져야 하는 소프트웨어 구성요소로 거론되고 있다. 간혹 도메인을 호스팅하는 웹 응용프로그램 코드가 도메인 코드보다 물리적으로 더 큰 비중을 차지하더라도 도메인의 중요성은 여전히 가장, 그리고 월등히, 높다.

아키텍처는 점점 다양해지고 그 수명은 점점 짧아진다. 변화하는 비즈니스 상황에 따라 동일한 도메인 논리는 다양한 호스팅 환경으로 확산되어 구동된다. 서비스 초기에는 단순한 웹 응용프로그램 호스트면 충분하다. 그러다 아마 곧 반응성에 대한 사용자들의 불만이 생겨날 것이고, 도메인 구성요소의 일부를 작업자 프로세스로 이동시켜 비동기적으로 실행해 반응성을 높여야 한다. 서비스가 성장하면 이제 도메인은 외부 서비스들과 교류하게 되고 개방형 API와 웹 훅을 통해 도메인 논리가 트리거된다. 아, 그렇지! 지금은 클라우드 시대다. FaaS(Function as a Service)를 빠뜨릴 수 없다. 다시 한 번 언급하면 도메인 논리는 동일하다. 외부 변화에 따라 다른 아키텍처로 이동되거나 확산될 뿐이다.

물론 상당수의 서비스는 성장하지 못하고 생을 다한다. 하지만 성장의 기회가 왔을 때 정적 기록자(static logger) 변수 따위가 도메인의 발목을 잡는다면 모습이 우스을 것이다. 그것도 화려하고 무거운 무언가를 도입하는 것이 아니라 고작 담백한 한 두 줄 코드 추가가 부담되어 그랬다면 말이다.

계속 읽기

싱글턴은 정적이지 않다

얼마전 페이스북에서 많은 프로그래머들이 당연시하게 기록자(logger)를 정적(static)으로 사용하는 것을 비판했는데, 비슷한 주장을 하는 다른 분의 글에서 기록자는 인스턴스 범위(scope)에 있지 않고 클래스 범위에 있다는 반론을 발견했다. 나는 반론 제기자에게 그것은 논점을 벗어나니 의존성 역전 원칙(dependency inversion principle)를 공부하라고 조언했다. 아쉽지만 반응에 의하면 아마 내 조언은 무시된 것 같았다.

계속 읽기

MVVM 응용프로그램을 위한 프로젝트 구조화

MVVM 아키텍처 패턴을 사용할 때 코드의 의존관계를 엄격하게 제한함으로써 구성요소의 잘못된 설계 위험을 줄일 수 있다.

structuring-projects-for-mvvm-application

계속 읽기

MVVM 아키텍처 패턴

MVVM(Model/View/ViewModel) 패턴은 UI를 가지는 응용프로그램을 위한 아키텍처 패턴(architectural pattern)이다. MVVM 패턴은 MVC(Model/View/Controller) 패턴의 변형으로 뷰의 추상화를 만드는 것이 핵심이다. 뷰의 추상화는 재사용할 수 있고(reusable) 테스트하기 쉽다(testable). 뷰의 추상화를 통해 응용프로그램 구조는 단순해지고, 이상적으로, 시각 디자인과 표현 논리를 독립적으로 구현할 수 있다.

모델(Model)과 뷰(View)는 MVC 패턴의 그것들과 동일하다. 모델은 데이터, 비즈니스 논리, 서비스 클라이언트 등으로 구성된다. 뷰는 선언적으로 구성된 UI 요소들을 의미한다. MVVM 패턴을 학습하며 가장 집중해야할 부분은 뷰모델(ViewModel)이다. 아직까지 .NET 언어들과 XAML(eXtensible Application Markup Language, /zæməl/), Blend[1]를 제외하고 MVVM 패턴에 대해 얘기하는 것은 쉽지 않은 일이다. 하지만 나는 이 글에서 특정 플랫폼 언급을 가능하면 자제하고 뷰모델을 중심으로 MVVM 패턴의, 구현이 아니라, 개념적 특징들과 가치를 설명하려 한다.

계속 읽기