Working Effectively with Unit Tests

Working Effectively with Unit Tests #1

https://leanpub.com/wewut 를 읽고 정리한 내용 첫번째 단락

Unit Testing, a First Example

* Replace Loop with individual Test

- https://github.com/bistros/wewut-code#replace-loop-with-individual-tests

- 읽기 쉬운 테스트를 위한 첫 번째 단계는 반복 테스트를 각각의 테스트로 변경하는 것이다.

ex) for-each를 돌면서 여러값을 테스트 하는 것을 제거한다

* Expect Literals

- https://github.com/bistros/wewut-code#expect-literals

그 다음 가독성을 높이는 단계로는 literal 값을 예상하는 것이다. 여전히 테스트는 실패 하겠지만, value를 직접적으로 확인 할 수 있게 된다.

* Inline Setup

- https://github.com/bistros/wewut-code#inline-setup

- 실패한 테스트의 원인을 쉽게 찾을 수 있어야한다. Template Method Pattern을 이용하면, 중복을 약간 줄일 수있는 있지만 다른 장점은 없다. 그리고 오버헤드가 증가할 수도 있다. 이러한 @Before setup에서 일어나는 이러한 부분을 없앤다면, 실패 했을 경우 setup을 안봐도 된다. 즉 code search가 거의 필요없게 되는 것이다. 

코드 중복에 대해서는 밑의 Final Thoughts on our Tests 에서 책 이외의 내용을 좀 더 추가하였다.

* Replace ObjectMother with DataBuilder

- https://github.com/bistros/wewut-code#replace-objectmother-with-databuilder

- 테스트를 위해 mock instance를 만드는 ObjectMother가 제한적일때는 유리하지만, 다른 시나리오(케이스)가 필요할때는 난감하다. 이 시점에서는 ObjectMother style 보다는 new Domain Model Instance 스타일로 변경되는 것이 실용적일 것이다. 대신에 Builder 가 변경이 필요하다면, 사용되는 모든 곳의 코드를 업데이트 쳐야하는 문제가 있는데 그건 다른 방법으로 해결 할 수 있다 (주: 챕터6 TestDataBuilder를 참고하면 된다) 물론 기존의 ObjectMother 보다는 코딩해야 할 내용이 많다. 하지만 좀 더 일반적이고 독립적으로 객체를 만들어 낼 수 있다. 

* Comparing the Results

- https://github.com/bistros/wewut-code#comparing-the-results

- 쉽게 assertion 하게 하라 (좋은 테스트는 나뿐 아니라 미래의 팀원들을 위해서이기도 하다)

* Final Thoughts on our Tests

- https://github.com/bistros/wewut-code#final-thoughts-on-our-tests

- 참고1) DAMP  https://stackoverflow.com/questions/6453235/what-does-damp-not-dry-mean-when-talking-about-unit-tests

프로덕션 레벨과는 달리 유닛 테스트에서는 파일/단일 테스트 내에서만 코드가 적용된다. 이 때문에 중복 코드에 대한 minimal and obvious 다.  또한 이러한 중복을 제거해 버린다면 테스트의 가독성이 떨어진다. 그래서 DRY를 프로덕션에서 선호하고 테스트에는 DAMP를 우선하여 균형을 이뤄야 한다

참고2) http://blog.jayfields.com/2006/05/dry-code-damp-dsls.html

DRY를 DAMP로 바꾸더라도 크게 라인수가 늘어나지는 않음을 보여줬고, 대신 가독성 측면 등에서 가치를 높일 수 있었다.