“Unit Testing - 블라디미르 코리코프 지음” 책을 학습하여 일부 내용을 요약하였습니다.

단위 테스트의 목표

  • 테스트로 대부분의 회귀에 대한 보험을 제공하는 도구라 할 수 있다.
  • 새로운 요구 사항에 더 잘 맞게 리팩터링한 후에도 기존 기능이 잘 작동하는지 확인하는데 도움이 된다.
  • 테스트 초반에 (상당한)노력이 필요하다.
    • 그러나 프로젝트 후반에도 잘 성장할 수 있도록 하므로 장기적으로 보면 그 비용을 메울 수 있다.
  • 지속성과 확장성이 핵심이며, 이를 통해 장기적으로 개발 속도를 유지 할 수 있다.

잘못 된 테스트

  • 잘못된 테스트는 초반에 코드가 나빠지는것을 늦출 수는 있다.
    테스트가 없는 상황에 비해 개발 속도가 덜 느려진다.
    그러나, 잘못 된 테스트로 진행한다면 시간이 지남에 따라 프로젝트 침체단계를 필할 수는 없다.

제품 코드 대 테스트 코드

  • 제품코드와 테스트 코드는 다르다고 생각하지만 다르지 않다. 테스트 코드가 많을수록 좋다고 생각하지만, 그렇지 않다. 코드는 자산이 아니라 책임이다. 코드가 많아 질수록 잠재적인 버그가 많아 지고 유지비가 증가된다. 테스트 코드 역시 코드다. 특정 문제를 해결하는것. 다른 코드와 마찬가지로 단위 테스트도 버그에 취약하고 유지보수가 필요하다

외부 라이브러리의 코드 경로를 고려할 수 없음

public static int Parse(string input) 
{
    return int.parse(input);
}

public void test() 
{
    int result = Parse("5");
    Assert.Equal(5, result);
}

테스트는 모든 구성 요소를 검증한다. 단지 값을 반환하는 한 줄이라 하더라도 단일한 구성 요소이기는 하다. 하지만, 테스트는 완벽하지 않다. 프레임워크의 int.parse 메서드가 수행하는 코드 경로는 고려하지 않았다.
null,"",5,정수가 아님,너무 긴 문자열 숨겨진 분기가 많다.
수 많은 예외상황을 모두 테스트로 다루는지 확인 할 수 없다. 이는 커버리지 지표가 외부 라이브러리의 코드 경로를 고려야해야 한다는것은 아니다.(고려하면 안된다.) 커버리지 지표로 테스트가 철저한지 또는 테스트가 충분하지 알 수 없다.
[테스트 커버리지 참고 링크]

요약

코드는 점점 나빠지는 경향이 있다. 코드가 변경 될때마다 코드의 무질서도(엔트로피)는 증가된다. 이러한 상황에서 지속적인 정리와 리팩토링이 없으면 시스템은 점점 복잡해지고 흐트러진다. 테스트로 이러한 부분을 뒤집을 수 있다. 테스트는 안전망 역할을 하며 대부분의 회귀에 대한 보험을 제공하는 도구라 할 수 있다.

“Unit Testing - 블라디미르 코리코프 지음” 책을 학습하여 일부 내용을 요약하였습니다.