한 4년쯤 전에 정리를 시작했던 주제로, 지인 몇 명과 논문으로 써볼까 기고를 할까 고민하다 제 때 빛을 보지 못했다. 실례를 찾아 보강하는 것이 가장 큰 숙제였는데, 불행히도 그 후 테스트 관련 업무를 접할 기회가 없었어서 기고까지는 하지 못했다.

Testable Design Fundamentals

In other to make software testable, designer should follow some rules. If you are interested in software design, some of them must be familiar to you. That’s because they are rules for improving software ‘design‘ in testability perspective. Lets look into the rules one by one.

1. Clear Specification: Specification should cover all possible situations even for illegal conditions. Moreover, it must be clearly defined without any ambiguous sentences.
2. Controlability: Target should provide mechanisms to read/write the conditions or to run the operations which are required to verify its functionality. It should be easy enough to implement.
3. Modularity: Adequate modularization is one of the fundamental requirements not only for design, implementation, and reuse, but also for test. For an example, a module which has many relationships with other modules is hard to test independently. It should use stub/mock object of wait until the dependant modules are implemented.
4. Readability: Easy and intuitive naming reduces human errors and decreases design/implementation time. It makes overall testing time shorter.
5. Consistency: All of the above rules should be reflected consistently so that the software can be look like designed and implemented by one person.

Software which satisfies these rules can be called testable. However, it is very hard to measure quantitatively how well the rules are reflected. I’ll remain this issue for other dedicated articles.

(in Korean)

테스트 가능한 소프트웨어를 만들기 위해서는, 설계자는 몇 가지 규칙을 따라야 한다. 소프트웨어 설계에 관심있는 사람이라면, 친숙한 이름의 규칙들을 찾을 수 있을 것이다. 이유인 즉, 이 규칙들은 테스트의 관점에서 소프트웨어의 ‘설계‘를 향상시키기 위한 지침이기 때문이다. 그럼 그 규칙들을 하나씩 살펴보도록 하자.

1. 명확한 기능 명세: 소프트웨어 명세서는 잘못된 상황까지 포함한 모든 가능한 상황을 기술해야 한다. 이 때, 의미가 분명한 문장만을 사용해야 한다.
2. 조작성: 테스트 대상은 그 기능 동작 여부를 판단할 수 있는 정보를 읽고/쓰거나 기능을 동작시킬 수 있는 메커니즘을 제공해야 한다. 또한 소프트웨어 적으로 쉽게 구현할 수 있어야 한다.
3. 모듈화: 적절한 모듈화는 소프트웨어 설계, 구현, 재활용 뿐 아니라 테스트를 위해서도 꼭 필요하다. 예를 들어, 다수의 다른 모듈과 종속성이 있는 모듈은 독립적으로 테스트하기 어렵다. Stub/Mock Object를 사용하거나, 타 모듈들이 구현되기까지 기다려야 한다.
4. 가독성: 쉽고 직관적인 이름(모듈, 함수 등 모든 경우에 해당됨)은 휴먼 에러(human error)를 줄여주고, 설계와 구현 시간을 단축시킨다. 결과적으로 테스트에 소요되는 전체 시간을 단축시키는 효과가 있다.
5. 일관성: 이상의 모든 규칙들은 마치 한 사람의 설계하고 구현한 것처럼 일관성 있게 적용되어야 한다. 각각의 모듈마다 그 정도가 다르다면 휴먼 에러(human error)를 증가시킬 것이다.

이상의 규칙들이 충족된 소프트웨어라면 ‘테스트할 수 있다’고 얘기할 수 있을 것이다. 단, 이런 규칙들이 얼마나 잘 반영되었는지를 정량적으로 측정하는데는 분명한 한계가 있다. 측정 이슈는 주제의 범위를 벗어나므로 본 글에서는 더 자세히 다루지 않을 것이다.

(Read the full article)

Spring Framework 관련 한글책[1]을 보다가 Dependency Injection(DI)의 번역에 대한 역자주에서 생각해볼 만한 것이 있어 보충 설명 겸, 잠시 끄적여본다. DI의 개념이 아직 모호한 사람이라면 이 글을 먼저 읽어본 후 참조한 wikipedia[2]의 글을 보면 전체적인 윤곽을 잡는데 도움이 될 것이다.

역자주: 종속객체 주입, 즉 DI(dependency injection)는 스프링에서 가장 기본이 되면서도 매우 중요한 의미를 갖는다. 기존에 가장 많이 쓰이던 번역은 ‘의존성 주입’이었다. 그러나 역자가 보기에 이 번역은 ‘없는 의존성을 만들어 주입한다’는 오해를 일으키고, 이 때문에 DI의 이해가 어려웠다고 생각한다. DI는 없는 의존성을 주입하는 것이 아니라 의존성은 이미 존재하되, 실제 객체가 필요로 하는 종속객체를 주입하는 것을 의미한다. 따라서 ‘의존성 주입’보다 뜻이 명확하도록 ‘종속객체 주입’이라고 번역했다. .. (후략)

일단.. 이 역자가 잘 봤다고 말하고 싶다. DI에서 dependency를 의존성으로 번역한 것은 확실히 잘못된 것이다. UML, OOAD 등 지금까지 IT 기술 관련 대부분의 상황에서는 모듈 간 관계를 명시하기 위해 dependency라는 용어를 사용해왔기 때문에 여기서도 습관적으로 의존성이라는 단어를 선택했으리라 생각한다. 하지만 단어는 문맥에 따라 여러 가지 의미를 가지고 있음을 잊어서는 안 된다.

DI를 직역하더라도 의존성 주입은 아니다. 오히려 위 역자가 사용한 종속객체 주입이 더욱 적절하다. 약간 아쉬운 게 있다면 DI는 object 세상에 국한되지 않기 때문에 ‘객체’라는 말은 여전히 논란의 소지가 있다는 점 정도. 범위를 제한하지 않으려면 module 정도의 추상적인 용어를 사용할 수 있겠지만, object라는 용어도 꼭 OOP에서 말하는 object로 제한되는 것은 아니니 상관없을 듯하다.

그럼 다시.. 왜 직역을 했는데도 의존성은 틀린 것일까? 이는 DI 패턴의 구조[2]를 살펴보면 쉽게 이해가 된다. DI 패턴은 세 개의 요소로 구성된다. 적절한 한글 대용어를 찾기 어려워 대강 번역해보면 이렇다.

이 패턴은 최소 3개의 구성 요소로 이루어진다: dependent와 그의 dependencies, 그리고 injector (혹은 provider, container). Dependent 는 컴퓨터 프로그램에서 작업(task)을 수행해야 할 소비자(consumer)다. 작업 완료를 위해선 특정 부작업들(sub-tasks)을 수행하는 다양한 서비스(dependencies)들을 활용해야 한다. 마지막으로 Injector는 dependent와 그에 필요한 dependency들을 조합해서 작업을 수행할 준비를 갖추는 컴포넌트로써, 이 객체들의 전반적인 라이프 사이클을 관리하기도 한다.

위 설명에서와 같이 DI의 dependency는 객체 간의 관계 속성을 의미하는 것이 아니라 서비스를 제공해주는 ‘실체’를 가리킨다. 그 실체를 (의미 그대로) dependent에서 주입시켜주는 것이다. 위 역자의 용어에 맞추어보면 대략 이렇게 되지 않을까 싶다.

• Dependent: 의존객체
• Dependency: 종속객체
• Injector: 주입자
• Dependency Injection: 종속객체 주입

이 용어들을 적용해 다시 번역해보면 아래처럼 되겠다. 깔끔하려나.. ^^

이 패턴은 최소 3개의 구성 요소로 이루어진다: 의존 객체(dependent)와 그의 종속 객체들(dependencies), 그리고 주입자(injector, provider, or container). 의존 객체는 컴퓨터 프로그램에서 작업을 수행해야 할 소비자다. 작업 완료를 위해선 특정 부작업들을 수행하는 다양한 서비스(종속객체)들을 활용해야 한다. 마지막으로 주입자는 의존객체와 그에 필요한 종속객체들을 조합해서 작업을 수행할 준비를 갖추는 컴포넌트로써, 이 객체들의 전반적인 라이프 사이클을 관리하기도 한다.

---

References

1. Spring in Action SE (Craig Walls / 장시형, 전지훈 / Manning)
2. Dependency injection (wikipedia)