# Triangulation (TDD)

> 테스트 주도 개발에서 빠르게 녹색 막대를 보기 위해 쓸 수 있는 세 가지 전략 중 하나. 리팩토링을 어떻게 하면 좋을지 명확히 떠오르지 않을 때, 실패하는 새로운 테스트를 추가하여 여러 테스트를 통과시키는 일반해를 유도해내는 방식.

[테스트 주도 개발](https://wiki.g15e.com/pages/Test-driven%20development.txt)에서 빠르게 <녹색 막대>를 보기 위해 쓸 수 있는 세 가지 전략 중 하나. 리팩토링을 어떻게 하면 좋을지 명확히 떠오르지 않을 때, 실패하는 새로운 테스트를 추가하여 여러 테스트를 통과시키는 일반해를 유도해내는 방식.

## 설명

> By analogy, when we triangulate, we only generalize code when we have two examples or more. We briefly ignore the duplication between test and model code. When the second example demands a more general solution, then and only then do we generalize. …
>
> Triangulation feels funny to me. I use it only when I am completely unsure of how to [refactor](https://wiki.g15e.com/pages/Refactoring.txt). … However, when the design thoughts just aren’t coming, Triangulation provides a chance to think about the problem from a slightly different direction. What axes of variability are you trying to support in your design? Make some of them vary, and the answer may become clearer.
>
> --Chapter 3, [Test-driven development: by example](https://wiki.g15e.com/pages/Test-driven%20development%20-%20By%20example.txt)

## 다른 전략들

- [Fake it](https://wiki.g15e.com/pages/Fake%20it%20(TDD.txt)): 일단 상수를 반환하게 만들고, 점진적으로 실제 코드로 바꿔가기
- [Obvious implementation](https://wiki.g15e.com/pages/Obvious%20implementation%20(TDD.txt)): 명백한 구현이 바로 떠오르면 그냥 적기