태그 보관물: testing

테스트 주도 개발 실천

테스트 주도 개발 실천

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

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

계속 읽기

Advertisements

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

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

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

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

계속 읽기

싱글턴은 정적이지 않다

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

계속 읽기

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 패턴의, 구현이 아니라, 개념적 특징들과 가치를 설명하려 한다.

계속 읽기

두렵다면 테스트를 작성하라

얼마전 페이스북에서 다음과 같은 코드에 null 여부 검사가 필요한지 의견을 묻는 글을 발견했다.

public void MyCode(string param)
{
    if (param != null && TheirCode(param))
        DoSomething();
}

계속 읽기

좋은 디자인과 테스트하기 쉬운 디자인

TDD와 관련된 오해 중 가장 심각한 것은 단위 테스팅과 TDD를 구별하지 못하는 것입니다. 그리고 또 다른 오해가 ‘좋은 디자인’과 ‘테스트하기 쉬운 디자인’의 관계에서도 발견됩니다. ‘좋은 디자인은 테스트하기 쉽다’는 명제에 대한 반론은 찾아보기 어렵습니다. 저도 반례를 경험한 일이 없습니다. 따라서 TDD 과정에서 어떤 코드를 테스트하기 어렵다면 디자인 문제를 의심해 볼 수 있고 이것은 TDD가 주는 나쁜 디자인에 대한 피드백으로 볼 수 있습니다. 게다가 이 피드백은 세부 구현 전에 제공되기 때문에 더 유익합니다. 하지만 안타깝게도 그 역인 ‘테스트하기 쉬운 디자인은 좋다’는 명제는 성립하지 않습니다. ‘좋은 디자인’과 ‘테스트하기 쉬운 디자인’은 동치가 아닙니다. 단순한 사례는 아주 쉽게 만들 수 있습니다.

계속 읽기

Microsoft.Owin.Testing 패키지를 이용한 인메모리 통합 테스트

단위 테스트 만큼이나 통합 테스트는 필요하며 통합 테스트에 있어서도 자동화는 중요합니다. 단위 테스트를 통과한 모듈도 서로 조합되면 운영 환경에서 오류를 발생시킬 가능성이 존재하며 다양한 이유로 인해 단위 테스트가 어려운 코드도 있죠. GUI를 가진 응용프로그램을 인력 자원을 동원해 하나하나 통합 테스트하거나 그것조차 제대로 하지 않는 것이 국내 사정이지만 CUIT(Code UI Tests)나 Jasmine 등의 E2E(End-to-End) 도구를 사용해 통합 테스트를 자동화하면 테스트 비용과 테스트 오류 가능성을 낮출 수 있습니다.

API 역시 통합 테스트 대상입니다. API는 GUI 기반 응용프로그램과 비교할 때 통합 테스트를 수동으로 진행하기에 귀찮고 어려운 반면 자동화하기는 더 쉽습니다. Jasmine을 이용한 API 통합 테스트 자동화를 고려해 볼 수도 있지만 Visual Studio에 의해 관리되고 있는 기존의 테스트가 있다면 동일한 테스트 도구를 통해 관리하는 것이 훨씬 좋겠죠.

Microsoft.Owin.Testing 패키지를 사용하면 OWIN(Open Web Interface for .NET) 기반 ASP.NET Web API에 대한 통합 테스트를 쉽게 작성할 수 있습니다. 테스트는 메모리를 통해 이루어지기 때문에 네트워크 트래픽이 발생하지 않아 매우 효율적이면서도 ASP.NET Web API의 전체 파이프라인을 관통합니다. 뿐만 아니라 IoC 컨테이너를 조작하면 컨트롤러 이후의 과정을 모의화하는 것도 가능합니다.

계속 읽기