최근에 커널 프로그래밍에 조금씩 TDD를 적용하고 있습니다. 커널에서도 주로 네트웍 관련 코드를 많이 작성하게 되는데 TDD를 적용하기가 굉장히 어렵다고 생각했습니다. 네트웍 프로그래밍의 경우 패킷을 직접 송수신해보지 않고는 테스트하기가 어려운 경우가 많기 때문입니다.

패킷을 물리적으로 송수신하지 않고 패킷을 처리하는 코드의 테스트를 작성하기 위해서는 테스트 안에서 소켓버퍼를 할당하는 방법으로 패킷을 하나하나 만들어 준 다음 각각의 경우에 대해서 테스트를 하는 방법이 있습니다. 커널 프로그래밍에 처음 TDD를 사용하려 했을 때는 테스트가 없는 코드를 유지보수하는 일이 시급했기 때문에 실제로 그러한 방식으로 테스트를 작성했습니다. 하지만 테스트를 위해서 매번 소켓버퍼를 할당하여 패킷을 만드는 것은 테스트를 작성하는 것 자체가 굉장히 부담스럽게 느껴졌습니다.

최근의 경험에 비추어보면 대부분의 테스트를 그런 방식으로 작성하려 했던 것이 좀 무식한 방법이지 않았나 생각합니다. TDD에 아주 조금 익숙해진 지금에서야 느끼는 것은 가능한 다른 기능과는 독립적으로 테스트를 작성하는 것이 중요하다는 것입니다. 예를 들어 소켓버퍼를 사용하는 함수를 찬찬히 살펴보면 소켓버퍼 자체보다 소켓버퍼의 특정 필드(예를 들어 IP)가 필요한 경우가 많습니다. 이러한 함수의 경우 인자로 소켓버퍼를 직접 넘기는 것이 아니라 필요한 필드만 넘기도록 작성한다면 테스트를 작성하기가 훨씬 용이하고 커널의 동작에 독립적인 코드가 될 것입니다.

아마도 네트웍 프로그래밍 뿐만 아니라 TDD를 사용하는 어떠한 코드라도 가장 기본이 되는 것은 다른 모듈이나 다른 기능과는 독립적으로 동작시킬 수 있도록 테스트를 작성하는 것이 아닐까 합니다. 이렇게 쉽게 테스트할 수 있는 테스트 코드를 먼저 작성함으로써 코드가 자연스럽게 다른 기능이나 모듈에 독립적이 되는 것이 TDD의 큰 강점인 것 같습니다.
이전 1 ... 20 21 22 23 24 25 26 27 28 ... 42 다음