[25장] 테스트 주도 개발 패턴
-테스트한다는 것은 무엇을 뜻하는가?
-테스트를 언제 해야 하는가?
-테스트할 로직을 어떻게 고를 것인가?
-테스트할 데이터를 어떻게 고를 것인가?
<테스트(명사)>
소프트웨어를 어떻게 테스트할 것인가? 자동화된 테스트를 만들어라.
아주 확신에 찬 사람과 정말 얼렁뚱땅 넘어가는 사람을 제외한다면, 아무리 작은 변화라도 테스트하지 않고 릴리즈하지는 않는다.
실제로 변화를 테스트하는 것은 ‘테스트를 갖고 있다’는 것과 똑같지 않다.
양성 피드백 고리(positive feedback loop). 스트레스를 많이 받으면 테스트를 점점 더 뜸하게 한다. 테스트를 뜸하게 하면 당신이 만드는 에러는 점점 많아질 것이다. 에러가 많아지면 더 많은 스트레스를 받게 된다. 어떻게 하면 이 고리에서 빠져나올 수 있을까? ‘자동화된 테스트’
테스트는 프로그래머를 위한 묘석인데, 두려움을 지루함으로 바꿔주는 효험이 있다.
“테스트할 시간이 어딨어. 그냥 릴리즈해!” 이 장면에 대해서는 결과를 보장할 수 없다. 스트레스를 점점 많이 받으면 결국 실패하게 된다. 그러나 자동화된 테스트가 있다면 두려운 정도를 선택할 수 있다. 실패할 게 뻔하더라도 테스트를 작성한 후에는 반드시 실행해봐야 할까?
<격리된 테스트>
테스트를 실행하는 것이 서로 어떤 식으로 영향을 미쳐야 좋은가? 아무 영향이 없어야 한다.
테스트가 충분히 빨라서 내가 직접,자주 실행할 수 있게끔 만들어야 한다. 그리고 앞부분에서 실행된 테스트가 실패한 후 그 영향으로 다음 테스트부터는 시스템이 예측 불가능한 상태에 놓이는 경우가 허다하다.
테스트는 전체 애플리케이션을 대상으로 하는 것보다 좀더 작은 스케일로 하는 게 좋다는 것이다. 각각의 테스트는 다른 테스트와 완전히 독립적이어야 한다는 것이다. 즉 문제가 하나면 테스트도 하나만 실패해야 하고, 문제가 둘이면 테스트도 두 개만 실패해야 한다. 격리된 테스트가 암묵적으로 내포하는 특징 중 하나는 테스트가 실행 순서에 독립적이게 된다는 점이다. 테스트를 격리하기 위한 작업은 결과적으로 시스템이 응집도는 높고 결합도는 낮은 객체의 모음으로 굿어되도록 한다.
<테스트 목록>
뭘 테스트해야 하나? 시작하기 전에 작성해야 할 테스트 목록을 모두 적어 둘 것.
할일 목록이 많아질수록 내가 하던 일에 대한 집중력이 떨어지고 성취도는 낮아진다. 성취도가 낮아지면 할일 목록은 더 많아진다.
구현해야 할 것들에 대한 테스트를 목록에 적게 된다. 우선 구현할 필요가 있는 모든 오퍼레이션의 사용 예들을 적는다. 그 다음, 이미 존재하지 않는 오퍼레이션에 대해서는 해당 오퍼레이션의 널 버전(아무 일도 하지 않는 버전)을 리스트에 적는다. 마지막으로 깔끔한 코드를 얻기 위해 이번 작업을 끝내기 전에 반드시 해야 할 리팩토링 목록을 적는다.
만들어진 모든 테스트는 리팩토링에 대해 약간의 관성을 갖는다. 열개의 테스트를 만든 후에 매개 변수의 순서를 반대로 하는 게 좋을 거라는 사실을 발견하더라도 여러분은 아마 이 순서를 바꾸지 않으려 할 것이다.
양 팔, 양 다리 중 둘 이상을 동시에 움직이는 역동적인 움직임은 위험하다. 초록 막대 상태에서 한 번에 한 개만 수정하는 순수한 형태의 TDD는 이 규칙(사중삼 법칙)과 비슷하다.
테스트를 통과하게 만드는 과정에서 여러분이 작성한 코드들은 새로운 테스트가 필요함을 암시적으로 알려줄 것이다. 이 새 테스트를 리팩토링과 마찬가지로 할일 목록에 적어 놓아라.
<테스트 우선>
테스트를 언제 작성하는 것이 좋을까? 테스트 대상이 되는 코드를 작성하기 직전에 작성하는 것이 좋다. 코드를 작성한 후에는 테스트를 만들지 않을 것이다. 프로그래머로서 여러분의 목표는 기능이 실행되도록 만드는는 것이다.
<단언 우선>
테스트를 작성할 때 단언(assert)은 언제쯤 쓸까? 단언을 제일 먼저 쓰고 시작하라.
-완료된 시스템이 어떨 거라고 알려주는 이야기(유저 스토리)부터 작성한다.
-기능이 완료되면 통과할 수 있는 테스트부터 작성한다.
-완료될 때 통과해야 할 단언부터 작성한다.
⇒ 제임스 뉴커크
<테스트 데이터>
테스트를 읽을 때 쉽고 따라가기 좋을 만한 데이터를 사용하라. 데이터 간에 차이가 있다면 그 속에 어떤 의미가 있어야 한다. 1과 2사이에 어떠한 개념적 차이점도 없다면 1을 사용하라.
만약 시스템이 여러 입력을 다루어야 한다면 테스트 역시 여러 입력을 반영해야 한다.
테스트 데이터에 대한 대안은 실제 세상에서 얻어진 실제 데이터를 사용 하는 것이다.
<명백한 데이터>
테스트 자체에 예상되는 값과 실제 값을 포함하고 이 둘 사이의 관계를 드러내기 위해 노력하라. 테스트를 작성할 때는 컴퓨터뿐 아니라 후에 코드를 읽을 다른 사람들도 생각해야 한다.
명백한 데이터가 주는 또 다른 이점은 프로그래밍이 더 쉬워진다는 것이다. 단언 부분에 일단 수식을 써놓으면 다음으로 무엇을 해야 할지 쉽게 알게 된다.
댓글