티스토리 뷰

반응형

마틴 파울러 - 리팩터링 (2판)  의  4장 내용 중 기억하고 싶은 것 기록 ✏️✏️

 

 

[1] 테스트 코드의 가치

 

프로그래머들은 대부분의 시간을 디버깅에 쓴다. (실제 코드를 작성하는 시간의 비중은 그리 크지 않다)

 

컴파일할 때마다 테스트를 돌렸더니 생산성이 급상승했다. 디버깅 시간이 크게 줄어든 것이다. 

직전까지 테스트가 성공했다면 마지막 테스트 이후에 작성한 코드에서 버그가 발생했음을 알 수 있다. 

 

테스트를 자주 돌려봤기 때문에 버그가 발생한 지점은 조금 전에 작성한 코드에 있다는 것을 알 수 있고 

그로인해 디버깅 시간이 크게 줄어든다. 

 

 

[2] 마틴파울러에게 배우는 좋은 테스트 습관 

 

1. 자주 테스트하기 

 

자주 테스트하라. 작성 중인 코드는 최소한 몇 분 간격으로 테스트하고, 적어도 하루에 한 번은 전체 테스트를 돌려보자

 

 

⭐️ 2.  테스트가 실패하는 모습을 직접 확인하기 

 

각각의 테스트가 실패하는 모습을 최소한 한 번씩은 직접 확인해본다. 

일부러 주입한 이 오류를 테스트가 걸러내는 게 확인되면, 만족해하며 원래 코드로 되돌린다. 

 

 

3. 위험영역을 집중적으로 테스트하기 

 

테스트는 위험요인을 중심으로 작성해야한다. 테스트의 목적은 향후 발생할 버그를 찾는 데 있다.

따라서 단순히 필드를 읽고 쓰기만 하는 접근자는 테스트할 필요가 없다. 

 

테스트를 너무 많이 만들다보면 오히려 필요한 테스트를 놓치기 쉽니다.

나는 적은 수의 테스트만으로 큰 효과를 얻고 있다. 잘못될까봐 가장 걱정되는 영억을 집중적으로 테스트하는데, 

이렇게 해서 테스트에 쏟는 노력의 효과를 극대화하는 것이다. 

 

또 테스트를 너무 많이 작성하다 보면 오히려 의욕이 떨어져 나중에는 하나도 작성하지 않게 될 위험도 있다.

따라서 위험한 부분에 집중하는 게 좋다.

코드에서 처리과정이 복잡한 부분, 함수에서 오류가 생길만한 부분을 찾아보자 

 

 

4. 경계 조건 검사하기 

 

경계를 확인하는 테스트를 작성해보면 프로그램에서 이런 특이 상황을 어떻게 처리하는 게 좋을 지 생각해볼 수 있다.

 

 

⭐️ 5. 버그 리포트를 받으면 가장 먼저 그 버그를 드러내는 단위 테스트부터 작성하기 

 

버그를 발견하는 즉시 발견한 버그를 명확히 잡아내는 테스트부터 작성하는 습관을 들이자.

나는 버그를 고치기 전에 항상 이런 테스트부터 만든다.

또한 그 버그와 테스트를 계기로 테스트 스위트에 또 다른 구멍은 없는 지 살펴본다. 

 

 

 

5. 리팩토링 전, 리팩토링 하는 동안 테스트 추가하기 

 

나는 항상 테스트 스위트부터 갖춘 뒤에 리팩터링하지만, 리팩터링하는 동안에도 계속해서 테스트를 추가한다. 

 

 

6. 기존 테스트 관리

 

새로운 기능을 추가할 때, 새로운 테스트도 추가하지만 기존 테스트도 다시 살펴본다.

테스트 과정을 더 이해하기 쉽게 리팩터링 할 수 는 없는지, 제대로 검사하는 지 등을 확인한다. 

 

 

[3] 그 외 

 

이 장에서 자바스크립트 테스트 프레임웤인 mocha (mochajs.org) 를 써서 테스트 하는 방법을 보여주신다. 

여기도 iOS의 Quick (github.com/Quick/Quick) 처럼 describe, context, it ... 구문을 쓴다. 

그 동안 안드랑 파이썬 쪽은 보통 테스트 프레임웤이 given, when, then 구문을 제공하는데  iOS만 왜 다르지..? 했는데 

친구(?)를 만났다. 

 

 

 

 

 

 

반응형
댓글