p.135 테스트를 작성하기 가장 좋은 시점은 프로그래미을 시작하기 전이다. 테스트를 작성하다보면 원하는 기능을 추가하기 위해 무엇이 필요한지 고민하게 된다. 구현보다 인터페이스에 집중하게 된다는 장점도 있다. 간혹 테스트가 갖춰지지않은 코드를 리팩터링할 때도 있다. 그럴 때는 곧바로 리팩터링하지 않고 먼저 자가테스트 코드부터 작성한다.
p.141 실패해야할 상황에는 반드시 실패하게 만들자 코드에 오류를 주입한다. 자바스크립트 테스트 프레임워크 모카 프레임워크를 사용하는 경우 assert, expect문을 사용해서 코드를 검증할 수 있다. 실패한 테스트가 하나라도 있으면 리팩터링하면 안된다.
p.143 완벽하게 만드느라 테스트를 수행하지 못하느니, 불완전한 테스트라도 작성해 실행하는게 낫다.
p.144 테스트 코드에서도 중복은 조심해야하지만 테스트끼리 상호작용하게하는 공유픽스처를 생성하는 원인이 된다. 나중에 다른 테스트에서 이 공유 객체의 값을 수정하면 이 픽스처를 사용하는 또다른 테스트가 실패 할 수 있다. 이렇게되면 테스트 결과가 제멋대로된다.
1
2
3
4
5
6
describe('province',function(){
let asia = new Province(sampleProvinceData();
//이렇게 하면 안된다.
...
})
1
2
3
4
5
6
7
describe('province',function(){
let asia;
beforeEach(function(){
asia = new Province(sampleProvinceData())
...
});
})
이렇게 작성하면 개별 테스트를 실행할 때마다 픽스처를 새로 만들면 모든 테스트를 독립적으로 구성할 수 있다.
p.146 beforeEach 블록에서 설정한 표준 픽스처를 취해서, 테스트를 수행하고, 이 픽스처가 일을 기대한 대로 처리했는지를 검증한다. 이 패턴을 설정-실행-검증, 조건-발생-결과, 준비-수행-단언 등으로 부른다.
p.148 경계를 확인하는 테스트를 작성해보면 프로그램에서 이런 특이 상황을 어떻게 처리하는게 좋을지 생각해 볼 수 있다. 문제가 생길 가능성이 있는 경계 조건을 생각해보고 그 부분을 집중적으로 테스트하자. 이러한 오류로 인해 프로그램 내부에 잘못된 데이터가 흘러서 디버깅하기 어려운 문제가 발생한다면 어서션 추가하기를 적용해 오류가 최대한 빨리 드러나게하다. 어서션도 일종의 테스트로 볼 수 있으니 테스트 코드를 따로 작성할 필요는 없다.
p.151 기능을 새로 추가할 때마다 테스트도 추가하는 것은 물론, 기존 테스트도 다시 살펴본다. 기존 테스트가 명확한지, 테스트과정을 더 이해하기 쉽게 리팩터링할 수는 없는지, 제대로 검사하는지 등을 확인한다. 버그를 발견하는 즉시 발견한 버그를 명확히 잡아내는 테스트를 작성하는 습관을 들이자.
Comments powered by Disqus.