Unit testing is often talked about in software development, and is a term that I’ve been familiar with during my whole time writing programs. Like most software development terminology, however, it’s very ill-defined, and I see confusion can often occur when people think that it’s more tightly defined than it actually is.
소프트웨어 개발에서 단위 테스트는 자주 회자되고, 내가 프로그램을 작성해 오면서 언제나 친근하게 느껴온 용어이기도 하다. 그러나 대부분의 소프트웨어 용어처럼 단위 테스트는 잘못 정의되어 있으며, 사람들이 단위 테스트를 실제보다 더 엄격하게 정의되어 있다고 생각할 때 혼란이 발생할 수 있다.
Although I’d done plenty of unit testing before, my definitive exposure was when I started working with Kent Beck and used the Xunit family of unit testing tools. (Indeed I sometimes think a good term for this style of testing might be “xunit testing.”) Unit testing also became a signature activity of ExtremeProgramming (XP), and led quickly to TestDrivenDevelopment.
나는 전부터 많은 단위 테스트를 해봤지만, 내가 Kent Beck과 Xunit 그룹의 단위 테스트 도구를 사용하면서 일을 시작했을 때가 단위 테스트를 접한 결정적 계기가 되었다. (그래서 나는 “xunit testing”이 이런 테스팅 스타일 위한 좋은 용어라고 생각했다.) 또한 단위 테스팅은 익스트림 프로그래밍 (XP)의 대표적인 활동이고, 테스트 주도 개발로 로 빠르게 이어졌다.
There were definitional concerns about XP’s use of unit testing right from the early days. I have a distinct memory of a discussion on a usenet discussion group where us XPers were berated by a testing expert for misusing the term “unit test.” We asked him for his definition and he replied with something like “in the morning of my training course I cover 24 different definitions of unit test.”
최근에 XP의 단위 테스팅 사용에 관련된 고민들이 있었다. 나는 usenet 토론 그룹에서 XPer들이 “unit test”라는 단어를 잘못 사용하는 테스트 전문가에게 배신 당했던 기억이 있다. 우리는 그가 생각하는 정의를 물어봤고, 그는 “아침 트레이닝 코스에서 단위 테스트에 대한 24개의 다른 정의를 다뤘다” 같은 대답을 했다.
Despite the variations, there are some common elements. Firstly there is a notion that unit tests are low-level, focusing on a small part of the software system. Secondly unit tests are usually written these days by the programmers themselves using their regular tools — the only difference being the use of some sort of unit testing framework [1]. Thirdly unit tests are expected to be significantly faster than other kinds of tests.
다양한 해석에도 불구하고 몇 가지 공통된 요소가 있다. 첫 번 째로 단위 테스트는 낮은 수준이고, 시스템의 작은 부분에만 집중한다. 두 번 째로 요즘은 개발자 스스로가 편한 도구를 사용해서 스스로 단위 테스트를 작성한다 — 차이는 그저 몇 가지 단위 테스팅 프레임워크를 사용하는 것이다. 세 번 째는 단위 테스트는 다른 종류의 테스트들에 비해서 상당히 빠르다.
So there’s some common elements, but there are also differences. One difference is what people consider to be a unit. Object-oriented design tends to treat a class as the unit, procedural or functional approaches might consider a single function as a unit. But really it’s a situational thing — the team decides what makes sense to be a unit for the purposes of their understanding of the system and its testing. Although I start with the notion of the unit being a class, I often take a bunch of closely related classes and treat them as a single unit. Rarely I might take a subset of methods in a class as a unit. However you define it doesn’t really matter.
몇 가지 공통 요소들이 있지만 차이점도 있다. 첫 번 째는 무엇이 단위가 되어야 하냐는 것이다. 객체지향 디자인은 클래스를 단위로 취급하는 경향이 있고, 절차적 또는 함수형 접근은 하나의 함수를 단위로 생각할 수도 있다. 그러나 단위는 상황적인 것이다 — 시스템과 테스팅을 이해하기 위해 무엇이 단위가 되는 것이 합리적인지는 팀이 (그때그때)정하는 것이다. 비록 내가 클래스를 단위로 취급하는 개념으로 시작했다고는 하지만, 종종 관련된 여러 클래스들을 하나의 단위로 취급하기도 하고, 드물게는 클래스 메소드들의 부분 집합을 하나의 단위로 삼을 수도 있다. 이런 것을 정의하는 것은 전혀 중요하지 않다.
A more important distinction is whether the unit you’re testing should be sociable or solitary [2]. Imagine you’re testing an order class’s price method. The price method needs to invoke some functions on the product and customer classes. If you like your unit tests to be solitary, you don’t want to use the real product or customer classes here, because a fault in the customer class would cause the order class’s tests to fail. Instead you use TestDoubles for the collaborators.
더 중요한 차이는 당신이 테스트하는 단위가 통합되어야 하는지 고립되어야 하는지다. 당신이 주문 클래스의 가격 메소드를 테스트 중이라고 상상해보라. 가격 메소드는 상품과 고객 클래스들의 어떤 함수를 실행시켜야 한다. 만약 당신이 단위 테스트가 고립 되기를 바란다면, 당신은 이 테스트에서 실제 상품, 고객 클래스를 쓰고 싶지는 않을 것이다. 왜냐하면 고객 클래스에서의 실패가 주문 클래스 테스트에서의 실패로 이어질 것이기 때문이다. 대신 연관된 작업을 위한 테스트 대역을 사용한다.
But not all unit testers use solitary unit tests. Indeed when xunit testing began in the 90’s we made no attempt to go solitary unless communicating with the collaborators was awkward (such as a remote credit card verification system). We didn’t find it difficult to track down the actual fault, even if it caused neighboring tests to fail. So we felt allowing our tests to be sociable didn’t lead to problems in practice.