14장. 프로젝트에서 테스트. 빠른 도입 단위테스트와 같은 실천법을 배우는 것은 끊임없는 경계를 요구한다. 팀원들과의 마찰이 생길 수도 있는데 아마 팀원은 조심스럽지 않게 테스트 코드보다 훨씬 빨리 코드를 만드는 것에 집중할 것이다. 처음부터 품질을 통제하면서 개발하길 주장하면 코드가 엉망이 되는 것을 최소한으로 줄일 수 있다. 이러한 단위 테스트가 팀 문화의 습관적인 일부가 될 수 있을지 토론해보는 것도 좋다. 팀과 같은 편 되기 아래 두 질문에 대한 대답을 생각하면서 단위 테스트 표준을 만들자. 개발자들은 어떤 것이 모든 사람의 시간을 많이 낭비하게 만든다고 느끼는지? 모두가 빠르게 동의할 수 있는 표준은 무엇인가? 초창기에 표준화해야 하는 목록은 아래와 같다. 코드를 체크인하기 전에 어떤 테스트를 ..

13장. 까다로운 테스트. 어떤 코드는 테스트하기 까다로운 코드들이 존재한다. 특히 스레드와 영속성에 연관된 코드를 테스트하는 것이 까다롭다. 이 장에서는 스레드와 영속성을 테스트하는접근 방법 두 가지 주제에 기반을 두어 어떻게 하는지 살펴본다. 멀티스레드 코드 테스트 기대한 대로 동작하는 코드를 작성하는 것은 어렵기에 단위 테스트를 작성하는 것이다. 동작하는 동시성 코드를 작성하는 것은 훨씬 더 어렵다. 동시성 처리가 필요한 애플리케이션 코드를 테스트하는 것은 기술적으로 단위테스트의 영역이 아닌 통합 테스트로 분류하는 것이 낫다. 스레드를 사용하느 코드에 대하 테스트는 느린 경향이 있다. 동시성 문제가 없다는 것을 보장하면서 실행 시간의 범위를 확장해야 하기 때문이다. 스레드에 관한 결함은 오랫동안 잠..

12장. 테스트 주도 개발. 작성하려는 코드가 있다면 항상 먼저 어떻게 그 코드를 테스트할지 고민해야 한다. 코드를 작성한 후에 어떻게 테스트할지 고민하기보다 작성할 코드를 묘사하는 테스트를 설계해야 한다. TDD에서 단위 테스트를 시스템의 모양을 잡고 통제하는 도구로 활용해야 한다. 단위 테스트는 소프트웨어를 어떻게 만들어야 할지에 관한 잘 훈련된 사이클의 핵심적인 부분이다. 따라서 TDD를 채택하면 소프트웨어 설계는 달라지고 아마도 더 좋아질 것이다. TDD의 주된 이익 단위 테스트를 사휘에 작성하여 얻을 수 있는 가장 명확한 이익은 코드가 예상한 대로 동작한다는 자신감인데 TDD에서도 동일하다. 또한 TDD를 잘 따른다면 구현하는 실질적인 모든 사례에 대해 단위 테스트를 작성하게 된다. 이런 단위 ..

11장. 테스트 리팩토링. 테스트 코드는 상당한 투자를 의미한다. 테스트는 결함을 최소화하고 리팩토링으로 프로덕션 시스템을 깔끔하게 유지시켜 주지만, 이것은 지속적인 비용을 의미하기도 한다. 이 장에서는 비용 증가로 이어지는 테스트 문제들을 해결할 것이다. 프로덕션 시스템을 리팩토링 하는 것처럼 테스트를 리팩토링하고 이해도를 최대화하며 유지 보수 비용을 최소화할 것이다. 불필요한 테스트 코드 테스트 코드가 예외를 기대하지 않는다면 단지 예외가 날아가게 두면 된다. 예외가 발생한 테스트는 오류로 표시되고 출력 창에 스택 트레이스가 보인다. 명시적인 try/catch 블록은 부가 가치가 업다. try/catch 블록을 제거하고 메서드의 원형을 IOException을 던지도록 변경하자. 추상화 누락 추상화로 ..

10장. 목 객체 사용. 이 장에서는 목 객체를 도입하여 고통을 주는 협력자에 대한 의존성을 끊는 방법과 항상 존재하는 장애물을 넘을 수 있게 도와주는 도구 활용법에 대해 알아본다. 목(mock)과 함께 단위테스트의 터널 끝에서 한 줄기의 빛을 볼 수 있을 것이라고 한다. 주소를 입력하는 대신 사용자는 지도에서 Profile 주소를 나타내는 지점을 선택할 수 있다. 애플리케이션은 선택된 지점은 위도와 경도 좌표를 AddressRetriever 클래스의 retrieve() 메서드로 넘긴다. 이 메서드는 좌표를 기반으로 생성된 Address 객체를 반환해야 한다. import java.io.*; import org.json.simple.*; import org.json.simple.parser.*; impo..

9장. 더 큰 설계 문제. 단위 테스트를 작성하는 것은 진공 속에서 벌어지는 일이 아니다. 설계라고 부르는 좀 더 크고 지속적으로 이동하는 퍼즐의 일부와 같다. 시스템 설계는 테스트를 작성하는 능력에 영향을 미치고 그 역 관계도 성립힌다. 이 장에서는 SRP원칙에 초점을 맞추어 더 작은 클래스들을 만들어 유연성과 테스트 용이성을 높이는 방법에 대해 알아본다. SRP-단일 책임 원칙. 클래스는 변경할 때 한 가지 이유만 있어야 한다는 원칙이다. 어떤 클래스에 대해서 단일 책임을 강조하면 변경으로 인한 리스크는 줄어든다. 클래스에 더 많은 책임이 존재할수록 클래스에 있는 코드를 변경할 때 기존의 다른 동작들을 깨기 쉽다. Profile 클래스는 책임 두 개를 정의한다. 1) 프로파일에 관한 정보 추적하기. ..

8장. 깔끔한 코드로 리팩토링하기. 낮은 중복성과 높은 명확성이라는 두 가지 목표를 합리적인 비용과 놀라운 투자 수익률로 달성할 수 있다. 단위 테스트를 만들면 이러한 목표에 도달할 수 있다. 이 장에서는 이런 목표를 마음에 두고 코드를 리팩토링 하는 방법에 대해 알아보도록 한다. 리팩토링 코드를 이리저리 옮겨서 시스템이 정상 동작함을 보장하는 것. 마음대로 코드를 바꾸는 것은 위험하다. 이런저런 방식으로 바꾸었을 때 적절한 보호 장치가 있는지 확인할 필요가 있는데 이것이 바로 테스트이다. 리팩토링의 가장 중요한 것은 이름짓기. 대상은 클래스, 메서드, 모든 종류의 변수들이다. 명확성은 코드 의도를 선언하는 것이고 좋은 이름은 코드 의도를 전달하는 가장 좋은 수단이다. 누군가가 메서드나 클래스명만 봐도 ..

7장. 경계 조건: CORRECT 기억법 1. Conformance(준수) - 값이 기대한 양식을 준수하고 있는가? 2. Ordering(순서) - 값의 집합이 적절하게 정렬되거나 정렬되지 않았나? 3. Range(범위) - 이성적인 최솟값과 최대값 안에 있는가? 4. Reference(참조) - 코드 자체에서 통제할 수 없는 어떤 외부 참조를 포함 하고 있는가? 5. Existence(존재) - 값이 존재하는가? null이 아니거나 0이 아니거나 등등등,,,, 6. Cardinality(기수) - 정확히 충분한 값들이 있는가? 7. Time(절대적 혹은 상대적 시간) - 모든 것이 순서대로 일어나는가? 정확한 시간에,,

6장. Right-BICEP: 무엇을 테스트할 것인가? 1. Right: 결과가 올바른가? 테스트 코드는 무엇보다도 먼저 기대한 결과를 산출하는지 검증할 수 있어야 한다. @Test public void answersArithmeticMeanOfTwoNumbers() { ScoreCollection collection = new ScoreCollection(); collection.add(() -> 5); collection.add(() -> 7); int actualResult = collection.arithmeticMean(); assertThat(actualResult, equalTo(6)); } ScoreCollection에 더 많은 숫자나 큰 수를 넣어서 테스트를 강화할 수도 있지만 이런 테스..