From f2e84a898e9bee506cdcc033bb114465af74f49c Mon Sep 17 00:00:00 2001 From: Hyuk Myeong Date: Tue, 10 Sep 2019 10:52:30 +0900 Subject: [PATCH] Update cook_book.md --- googlemock/docs/kr/cook_book.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/googlemock/docs/kr/cook_book.md b/googlemock/docs/kr/cook_book.md index f18ecece..d9aab8be 100644 --- a/googlemock/docs/kr/cook_book.md +++ b/googlemock/docs/kr/cook_book.md @@ -1138,7 +1138,7 @@ gMock의 `ON_CALL`은 아마도 자주 사용되는 기능은 아닐 것입니 약간 직관에 반하는 이야기이기도 합니다. 왜 더 많이 검증하는 것이 더 적게 검증하는 것보다 나쁜 걸까요? -정답은 테스트가 *무엇을* 검증해야 하는가에 있습니다. **좋은 테스트는 코드의 상호작용을 검증해야 합니다.** 테스트가 너무 과도한 제약사항을 가지게 되면 구현을 자유롭게 할 수 없게 됩니다. 그러한 제약사항으로 인해 인터페이스(모듈간의 interaction)를 망가트리지 않음에도 불구하고 refactoring이나 optimization을 자유롭게 할 수 없다면 큰 문제가 되는 것입니다. 심지어는 어떤 수정사항이 테스트에서 실패하는 것을 제외하고는 아무런 문제가 없는 경우도 발생하게 됩니다. 그로 인해 테스트에 실패한 이유를 디버깅하고 해결하기 위해 의미없는 시간을 허비하게 될 것입니다. +정답은 테스트가 *무엇을* 검증해야 하는가에 있습니다. **좋은 테스트는 코드의 상호작용을 검증해야 합니다.** 테스트가 너무 과도한 제약사항을 가지게 되면 구현을 자유롭게 할 수 없게 됩니다. 간단히 말해서 과도한 테스트로 인해서 인터페이스(모듈간의 상호작용)를 망가트리지 않음에도 불구하고 refactoring이나 optimization을 자유롭게 할 수 없다면 이게 더 큰 문제가 되는 것입니다. 극단적인 경우에는 어떤 수정사항이 테스트에서 실패하는 것을 제외하고는 아무런 문제가 없는 경우도 발생할 수 있을 것입니다. 게다가 테스트에 실패한 이유를 디버깅하고 해결하기 위해서 의미없는 시간을 허비하게 될 것입니다. 1개의 테스트로 많은 것을 검증하려고 하면 안됩니다. **1개 테스트로는 1개만 검증하는 것이 좋은 습관입니다.** 그렇게 해야만 bug가 발생해도 1~2개의 테스트에서만 문제가 될 것입니다. 그렇지 않고 여러개의 테스트가 한 번에 잘못되면 디버깅하기가 훨씬 어려워집니다. 또한, 테스트의 이름을 통해서 무엇을 검증하려 하는지 자세히 표현하는 것도 좋은 습관입니다. 그렇게 해야 log만 보고도 어떤 문제인지 예측할 수 있습니다.