Refactoring - Building Test

Martin Fowler - Refactoring을 읽고 정리한 글입니다.(90~96p)

요약

• 테스트가 완벽할 필요는 없다. 자주 실행하는 것이 더 중요하다.
• 테스트코드에서 중복 제거에 열 낼 필요 없다. standard하게 만드는건 괜찮지만.

 

A Firts Test

코드 테스트를 위해서는, 테스팅 프레임워크의 정렬이 필요하다. Mocha를 사용할 것이다. 보편적이고 잘 만들어졌음. 프레임워크 어떻게 쓰는지는 다 설명하지 않고 예시만 좀 보여줄것임.

 

모카는 테스트를 블록으로 나누고, 테스트 수트를 그룹핑한다. 각 테스트는 it 블록으로 나타난다.

describe 안의 description strings를 테스트가 뭘 테스트하는지, 비워두기, 그냥 원래 있던거 복사하기도 하지만, 저자는 테스트가 실패했을 때 어디서 실패했는지 충분히 알 수 있을정도로 작성함. (당연한거 아닌가..?)

테스트가 실패하면 반드시 확인해라.

테스트가 다 통과하면 좋긴 하겠지만 저자는 회의적이다. 테스트가 코드를 다 테스트하는지 걱정된다. 그래서 테스트를 작성했는데 페일나면 좋아한다.

테스트를 자주 실행해라. 적어도 몇 분마다 당신이 연습하고 있는 코드를 실행해라. 전체 테스트는 적어도 매일 실행해라.

저자는 테스트 1000개정도 갖고있음. 프레임워크가 좋아야 자주 실행하고 실패했을때 쉽게 확인한다. 실행도 자주한다. 새 코드나 리팩토링할때 체크하는 용도로 자주 씀.

모카는 다른 라이브러리도 사용할 수 있는데 Chai라는걸 쓰면 assert/expect style을 쓸수있음.

 

테스트코드 통과 못했을땐 리팩토링 하지말고, 통과한 상태로 되돌려라. version control 쓰든지 해서.

 

Add Another Test

실행하지 않는 완전한 테스트보다, 실행하는 불완전한 테스트가 낫다.

보통 중복 코드를 제거하려고 하기 때문에, 테스트 코드에서도 팩토리를 없애려고 할 것이다. 하지만 그러지 말고, beforeEach써라. 실행될때마다 asia에 할당된 값을 지우고 재할당해준다.

매번 새 fixture를 만들면 느려지지 않을까 고민하는 사람도 있을텐데 대부분 별 영향 없다. 문제가 되면 재사용 하겠지만, 그러면 굉장히 조심해서 테스트를 수정해야 할 것이다.

그럼 그냥 it 블록마다 각각 셋팅하는 코드 넣어도 되지 않느냐 할건데, 저자는 fixture를 standard하게 만드는걸 좋아함. 그러면 읽는 사람이 beforeEach블록으로 standard한 데이터를 쓰고있다는걸 알 수 있음. 그럼 describe 블록 단위로 시작점에서 바로 이 테스트가 어떤 데이터 쓰는지 알수있음.

 

Modifying the Fixture

setup-exercise-verify : descripbe block에서 초기 셋팅된 standard fixture를 가지고, 테스트를 위해 fixture를 exercise(실행?작동?)하고, 생각한대로 완료됐는지 검증함.

암묵적이지만 네번째 단계가 있는데 Teardown임. 테스트끼리는 상호작용하지 않게 함. 저자는 beforeEach 셋팅 다하고나면, 테스트들 간에 fixture를 분리해서 teardown단계를 거침. 하지만 대부분 teardown안함. 하지만 무조건 필요할 때도 있다. 특히 테스트들 간에 공유해야 하는 fixture가 있는 경우 생성할때 느리므로.

⇒ 이거 뭔말인지 도대체 모르겠음..

보면 it안에 두 characteristic을 가지고 있음. 보통 하나만 검증하는게 좋지만 두가지는 연관성이 깊다고 생각해서 이렇게 함. 나중에 분리하고싶으면 그때 해도됨.

exercise가 자주 나오는데 어떤 의미로 쓰이는건지 감이 잘 안옴..