2007/08/05 23:54 Developer
"The Way of Testivus" - Testing and Beautiful Code
결국, 테스트하기가 쉬운 코드가 아름다운 것이다.
나는 가끔 테스트를 편하게 하기 위해서 디자인 개선을 하기도 한다. 보통 아래 2가지의 경우는 상황에 따라서 선택을 한다. 상속과 위임을 통한 testability를 높이는 일이다. 경험상 위임을 잘 활용하는 것이 테스트하기가 더 쉬웠다. 일련의 로직들이 인터페이스 계약을 통해서 mock을 활용해서 dependency injection이 편했기 때문이다.
상속
비즈니스 로직을 처리하는 템플릿 클래스가 존재하는 경우는 템플릿 추상클래스만 테스트가 끝나면, 그것을 상속 받는 클래스는 거의 테스트가 필요가 없다. 대부분의 로직이나 알고리즘은 부모에서 처리가 되고, 하위에 클래스에 있는 일부 메소드들이 콜백형태로 불리어지기 때문이다.
위임
상속을 받아서 확장하는 디자인인데, 사실 상속받는 내용이 그다지 궁금하지는 않을 때가 있다. 이때는 상속으로 받아서 테스트의 dependency를 어렵게 하는 것보다는 위임을 통해서 좀더 관심의 영역을 좁게 만들 수가 있다. 지금 확장이 필요한 것만 테스트가 가능해지는 것이다.
"The Way of Testivus" - Testing and Beautiful Code
http://beautifulcode.oreillynet.com/2007/08/the_way_of_testivus_testing_an_1.php
Think of code and test as one
나는 가끔 테스트를 편하게 하기 위해서 디자인 개선을 하기도 한다. 보통 아래 2가지의 경우는 상황에 따라서 선택을 한다. 상속과 위임을 통한 testability를 높이는 일이다. 경험상 위임을 잘 활용하는 것이 테스트하기가 더 쉬웠다. 일련의 로직들이 인터페이스 계약을 통해서 mock을 활용해서 dependency injection이 편했기 때문이다.
상속
비즈니스 로직을 처리하는 템플릿 클래스가 존재하는 경우는 템플릿 추상클래스만 테스트가 끝나면, 그것을 상속 받는 클래스는 거의 테스트가 필요가 없다. 대부분의 로직이나 알고리즘은 부모에서 처리가 되고, 하위에 클래스에 있는 일부 메소드들이 콜백형태로 불리어지기 때문이다.
위임
상속을 받아서 확장하는 디자인인데, 사실 상속받는 내용이 그다지 궁금하지는 않을 때가 있다. 이때는 상속으로 받아서 테스트의 dependency를 어렵게 하는 것보다는 위임을 통해서 좀더 관심의 영역을 좁게 만들 수가 있다. 지금 확장이 필요한 것만 테스트가 가능해지는 것이다.
"The Way of Testivus" - Testing and Beautiful Code
http://beautifulcode.oreillynet.com/2007/08/the_way_of_testivus_testing_an_1.php
Think of code and test as one
When writing the code, think of the test.
When writing the test, think of the code.
When you think of code and test as one,
testing is easy and code is beautiful.
