소프트웨어 장인 정신 이야기 (2)

2024.05.07 - [source-code/software] - 소프트웨어 장인 정신 이야기 (1)

3장. 고급 테스트 주도 개발

단계마다 테스트는 더욱더 제한적이고 구체적으로 바뀌는 반면, 제품 코드는 점점 더 일반화된다. 이 과정은 제품 코드가 너무 일반적이어서 실패하는 테스트를 더 이상 생각해 낼 수 없을 때까지 계속된다. 그러면 문제가 모두 풀린 것이다.

 

복잡한 문제일 수록, 단순한 공리(실패하는 테스트 코드)에서 출발해야 한다.

한 번에 한 단계씩, 제품 코드를 구현하고, 리팩터링 하고, 다음 테스트 케이스를 작성해야 한다.

 

하지만... 모든 경우에 이러한 주기를 적용하는 게 어렵지 않을까?

가장 대표적인 예시가 → 요구사항이 너무 복잡해서, 한 번에 모든 구현을 작성하지 않으면 테스트 케이스가 통과하지 않는 경우!

 

실제로도 이런 순간을 많이 겪었고,

길어진 제품 코드에 맞는 테스트를 추가하며... '테스트를 위한 테스트를 하는 것 아닌가?' 하는 회의감을 겪은 적도 있다.

 

테스트 주도 개발 초보는 이따금 곤경에 빠지곤 한다. 완벽하게 좋은 테스트를 썼는데, 이 테스트를 통과하려면 알고리즘 전체를 한 번에 다 구현할 수밖에 없는 경우가 있다. 나는 이런 경우를 '막다른 길'이라고 부른다.
막다른 길의 해법은 마지막으로 추가한 테스트를 지우고, 통과시킬 만한 더 단순한 테스트를 찾는 것이다.

 

C.마틴은 귀신 같이 막다른 길 문제를 언급하며

이를 해결하기 위해 테스트 주도 개발에 새로운 규칙, 즉 통과시킬 만한 더 단순한 테스트를 찾아라 란 지침을 추가한다.

 

(...)
여러분이 쓰는 모든 테스트는 시스템의 동작을 기술하는 유한 상태 기계의 상태 이행이다.

 

유한 상태 기계의 상태 변경 세 요소는 

GWT(given-when-then)나 3A(arrange-act-assert)와 동일한 의미를 가진다.

그리고 모든 프로그램은 유한 상태 기계라 볼 수 있다.

→ 따라서... 우리가 작성하는 모든 테스트 묶음은, 필요한 요구 사항(프로그램의 상태 이행)의 묶음 그 자체라 할 수 있겠다! 와!

 

'테스트 대역'이라니, 참 좋은 이름이다. (...) 테스트 대역은 테스트가 실행될 때 다른 객체를 대신한다.

데트스트 대역들은 일종의 타입 계층 구조를 형성한다. 더미가 가장 간단하다. 스텁은 더미이기도 하고, 스파이는 스텁이기도 하며, 모의 객체는 스파이이기도 하다. 가짜는 혼자 떨어져 있다.

모든 테스트 대역이 사용하는 메커니즘은 단순한 다형성이다. (...)