특히 많은 사용자들을 위한 경우, API 설계는 어렵습니다. 만약 여러분이 수 백에서 수 천의 사용자들이 사용할  API 를 설계한다면, 미래에 이것이 얼마나 바뀔 것인지, 그리고 변경 사항이 클라이언트 코드를 손상시킬 수 있는지 여부를 고려해야 합니다. 그 이상으로, 여러분은 API 사용자가 여러분에게 어떻게 영향을 미칠지 생각해야 합니다.

만약에 여러분의 API 클래스 중 하나가 내부적으로 자신의 함수들 중에 하나를 사용한다면, 사용자가 여러분의 클래스의 서브클래스를 만들고 오버라이드override 할 수 있으며, 그리고 그것은 재앙이 될 수 있다는 것을 꼭 명심해야 합니다. 몇몇 사용자들이 그 메소드를 서로 다른 의미로 받아들였기 때문에 여러분은 그것을 바꿀 수 없을지도 모릅니다. 메소드 내부 구현에 대한 여러분의 향후 선택은 사용자들이 이를 얼마나 받아들여 줄 수 있느냐에 달려 있습니다.

API 개발자들은 다양한 방법으로 이러한 문제들을 해결하지만, 가장 쉬운 방법은 API 를 봉쇄하는 것입니다. 만약 여러분이 자바 환경에서 작업한다면, 대부분의 클래스와 메소드를 final 로 선언하는 유혹에 빠질 수도 있습니다. C# 환경에서는, 여러분의 클래스와 메소드들을 sealed 로 선언해 버릴 수도 있습니다. 여러분이 어떤 개발 언어를 사용하든 간에, 행위를 오버라이드하거나 이후에 여러분의 선택을 제약하도록 코딩하는 것을 막기 위해 싱글턴 패턴이나 정적 팩토리 메소드를 이용해 API를 제공하고자 할 것입니다. 이 모든 것들이 합리적으로 보입니다만, 진짜로 그렇습니까?

지난 십년 동안, 우리는 점차 단위 테스트가 실전에 매우 중요한 부분이라는 사실을 깨달았지만, 이런 교훈이 업계에 완벽하게 확산되지는 못했습니다. 그 증거는 우리 주위에 널려 있습니다. 타사의 API 를 사용하는 임의의 테스트 안된 클래스에 대한 단위 테스트를 하려고 하면, 여러분은 곤경에 빠질 것입니다. 여러분은 그 코드가 마치 접착체로 붙인 듯이 API 를 사용하고 있다는 것을 알게 될 것입니다. 그것이 API 클래스이고 그래서 여러분의 다른 코드와 API 가 상호작용 한다는 것을 알아챌 수 있도록 하는 방법도 없고, 그래서 테스트를 위한 반환값을 제공할 수 있는 방법도 없습니다.

우리가 API 설계를 할 때 테스트를 실제 유스케이스처럼 생각해야만 점차 나아질 것입니다. 불행히도, 그것은  자신의 코드를 테스트하는 것보다 더 복잡합니다. 바로 거기가 API 디자인의황 금률 이 적합한 곳 입니다 .  여러분이 개발하는 API 를 위한 테스트를 작성하는 것 만으로는 충분하지 않습니다.  여러분은 API를 사용하는 코드들을 위한 단위 테스트를 작성해야 합니다. 여러분이 그렇게 할때, 사용자들이 코드를 독립적으로 테스트하는데 있어서 이겨내야 할 어려움을 직접적으로 배우게 됩니다.

개발자들이 쉽게 여러분의 API를 사용하여 코드 테스트를 만드는 유일한 길은 없습니다. static, final, 그리고 sealed 키워드는 본질적으로 나쁜 구조가 아닙니다. 그들은 때때로 유용할 수 있습니다. 그러나 테스트 이슈에 대해 알고 있는 것이 중요합니다. 그렇게 하기 위해서 여러분 스스로가 경험해야 합니다. 한 번 그렇게하면, 여러분은 어떤 다른 디자인의 도전에도 접근할 수 있을 것 입니다.

Written By Michael Feathers   , 약력

Translated by 임병수  / Reviewed by 김수현, 최현미 / Final Reviewed by 손영수