일단 프로그래머 대부분이 생각 -> 프로그래밍 -> 테스트 하는 싸이클은 기본적으로 따라가거든. 테스트 자체가 자동화되고 (가능하면 표준화된) 결과를 보고받는 방식이어야 TDD 가 아닐까 함.

근데 뭐 네 말대로 테스트(?)먼저 해보는 방식은 약간 TDD스럽긴 하네. 사실 *nix의 많은 툴들이 일명 dry-run (전과정을 실제 사이드이펙트 없이 순서대로 밟아만 보는 것) 기능을 제공하지…

어제 convmv를 해보고 발견한건데,
실제 mv를 수행하기 전에 이름 문자열만 먼저 바꿔보고 실패하는 것들을 쭉 뽑아내 주더라구요. 왠지 TDD를 보는 느낌(…) 알아서 해결할 방법을 제공해 주지 않는건 좀 불만이었지만요.(escaping이라거나..)

한발자국 나아간 것인 것 같긴하지만, 그걸로 채워지지 않는 부분이 너무 많다고 생각해. 타입 추론이 의미론적인 빌딩블럭인지는 조금 의문. 함수형 언어에서는 각종 reduction을 수행하기 위해서 어쩔 수 없이 그런 검사가 필요한 것일 뿐이지 않나하는 생각이 좀 드는데;

타입이 맞는 프로그램이 제대로 동작하는 프로그램이다! 라는 것 자체가 우리의 기준에 맞지 않는건 맞지만, 한 발자국 나간 느낌이라고 생각해요. 프로그램의 의미 구조를 formal하게 정의할 수 있게 된다면 그걸 기반으로 의미 구조가 성립하는지를 확인하는 녀석을 만들 수 있을지도 모르죠. nML수업을 듣고 생각한건 타입 추론은 큰 목적을 위해 쌓아가는 중- 정도의 의미라고 생각해요.

물론 DbC가 사용되면 개별 계약(?)단위마다 테스트를 지정하면 되긴하죠. 그렇지만 이 글과 아주 직접적인 연관은 없는듯 합니다.
이글에서 쓰고 싶었던 것은 “정적분석보다 실제 테스트를 믿고 써줘”라는 거라서(…)

(3/15에 추가)
+ 만들어놓은 테스트는 그 자체가 “contract의 일부”를 표현하기도 할 것이고,
+ 이후의 변경이 contract를 깼는지 여부를 확인하는 도구가 될 수도 있겠군요