간단한 회고38일간(1/31 ~ 3/9)의 Good Code Bad Code 독서가 끝났다. 해당 책을 고른 이유는 클린코드 강의해 주신 코치님이 해당 책을 추천해주시기도 했고, 코드를 짜거나 리뷰할 때 뭔가 확실한 기준점이 있으면 좋겠다는 생각으로 읽었다. 책을 읽으면서 당연한 내용도 있었고, 미처 알지 못한 부분도 있었고, 모호했던 것들이 확실해진 부분도 있었다. 다 이해하고 적용할 수 있으면 좋겠지만 아직까지 100프로 숙지가 된 상태는 아니다. 아마 나중에 프로젝트에서 직접 적용해 보면서 몸에 배이도록 해야 할 거 같다.  매일 책을 읽으면서 할 게 많아 숙제처럼 읽은 날도 있었고 어떤 날은 내용이 흥미로워서 계속 읽힌 날도 있었다. 때때로 이렇게 억지로 보는게 의미가 있나 싶은 날도 있었지만, ..

해당 포스팅은 톰 롱의 Good Code, Bad Code (P.380~389)를 읽고 정리한 글입니다. 적절한 어서션 확인자를 사용하라어서션 확인자 (assertion matcher)는 보통 테스트 통과 여부를 최종적으로 결정하기 위한 테스트 케이스 내의 코드이다. 테스트 케이스가 실패하면 어서션 확인자는 실패 이유를 설명하는 메세지를 생성한다. 좋은 단위 테스트는 잘 설명된 실패를 해야 한다. 따라서 가장 적절한 어서션 확인자를 선택하는 것이 중요하다. 부적합한 확인자는 테스트 실패를 잘 설명하지 못할 수 있다. @Test void inappropriateAssertionMatcher() { List names = List.of("Alice", "Bob", "Charlie");..

해당 포스팅은 톰 롱의 Good Code, Bad Code (P.367~380)를 읽고 정리한 글입니다. 공유 설정을 적절하게 사용하라테스트 프레임워크에서 테스트 케이스 간에 설정을 쉽게 공유할 수 있는 기능을 제공한다. 이를 활용하면 코드 반복이나 비용이 많이 들어가는 설정의 반복적인 수행을 피하는데 유용하다. 일반적으로 다음과 같이 4가지  시점에서 공유 설정과 해체 코드를 실행하도록 설정한다.공유 설정BeforeAllBeforeEache공유 해체AfterAllAfterEach두 가지 중요한 방식으로 서로 다른 테스트 케이스 간에 공유할 수 있다. BeforeAll을 통해 상태를 공유할 수 있고 BeforeEach을 통해 설정 공유를 할 수 있다. 상태 공유는 문제가 될 수 있다.서로 다른 테스트 케..

해당 포스팅은 톰 롱의 Good Code, Bad Code (P.361~367)를 읽고 정리한 글입니다. 한 번에 하나의 동작만 테스트하라주어진 코드에 테스트해야 하는 동작은 여러 가지가 있다. 각각의 동작을 테스트하려면 약간 다른 시나리오를 설정해야 하므로, 별도의 테스트 케이스로 테스트하는 것이 가장 자연스럽다. 여러 동작을 한꺼번에 테스트하면 테스트가 제대로 안 될 수 있다.하나의 테스트 코드에 여러 동작을 한 번에 테스트하게 되면 테스트 케이스가 정확히 무엇을 하고 있는지 이해하기 어렵다. 테스트 코드의 함수 명이 내용이 무엇인지 구체적으로 보여주지 않으며, 테스트 케이스 코드도 너무 길이 파악하기 상당히 어렵다. 이는 좋은 단위 테스트의 주요 특징인 이해하기 쉬운 테스트 코드와 잘 설명된 실패를..

해당 포스팅은 톰 롱의 Good Code, Bad Code (P.353~361)를 읽고 정리한 글입니다. 테스트만을 위해 퍼블릭으로 만들지 말라프라이빗 함수 중 일부를 테스트 코드에서도 접근할 수 있도록 만들어 직접 테스트하고자 할 수 있다. 하지만 이렇게 된다면 두 가지 문제점이 발생할 수 있는데 첫 번째로 구현 세부 사항과 밀접하게 연관된 테스트가 될 수 있고 실제적으로 테스트해야 하는 코드의 동작을 테스트하지 않을 수 있다. 프라이빗 함수를 테스트하는 것은 바람직하지 않을 때가 많다.class MortgageAssessor{ // public API MortgageDecision assess(Customer customer){ if(!isEligibleForMortgage..

해당 포스팅은 톰 롱의 Good Code, Bad Code (P.347~353)를 읽고 정리한 글입니다. 기능뿐만 아니라 동작을 시험하라테스트 대상 코드가 수행하는 작업이 여러 가지가 있으며 이 각각의 작업에 대해 테스트 케이스를 따로 작성해야 한다.  함수당 하나의 테스트 케이스만 있으면 적절하지 않을 때가 있다.테스트를 작성하는 개발자가 기능 테스트에만 집중하면, 각 상황에서 올바르게 동작하는지 충분히 확인하지 못할 수 있다. 해결책 : 각 동작을 테스트하는 데 집중하라함수와 동작 사이에 일대일로 연결이 안 되는 경우가 많다. 코드에 대한 신뢰도를 높이기 위해 여러 가지 값과 경계 조건을 테스트하는 것도 타당하므로 여러 케이스가 포함되어야 한다. 모든 동작이 테스트되었는지 거듭 확인하라코드가 제대로 ..

해당 포스팅은 톰 롱의 Good Code, Bad Code (P.325~339)를 읽고 정리한 글입니다. 단위 테스트는 코드의 특정 단위를 비교적 격리된 방식으로 검증하는 것을 목표로 하지만, 실제 코드는 다양한 의존성을 갖는다. 따라서 모든 동작을 완벽하게 테스트하려면 적절한 입력을 설정하고 부수 효과를 검증해야 한다. 이때, 의존성을 실제로 사용하는 대신 테스트 더블을 활용하는 것이 효과적이다. 테스트 더블을 사용하는 이유테스트 단순화의존성 설정에는 많은 노력이 필요할 수 있으며, 하위 의존성에서 원하는 부수 효과가 발생했는지 검증해야 할 수도 있다. 이 과정에서 테스트 코드에 설정 코드가 쌓이고, 구현 세부 사항과 밀접하게 결합될 위험이 있다. 하지만 테스트 더블을 사용하게 되면 실제 의존성을 설정..

해당 포스팅은 톰 롱의 Good Code, Bad Code (P.318~325)를 읽고 정리한 글입니다. 이해 가능한 테스트 코드한 코드에 대해 세 가지 동작이 테스트된다고 가정했을 때, 하나만 의도적으로 변경할 경우 해당 동작에 대한 테스트 케이스만 변경하고 다른 두 가지 동작에 대한 테스트 케이스는 변경하지 않고 그대로 두는 것이 이상적이다.  자신이 변경한 사항이 원하는 동작에만 영향을 미친다는 확신을 가지려면 테스트의 어느 부분에 영향을 미치고 있는지, 테스트 코드에 대한 수정이 필요한지 여부를 알 수 있어야 한다. 이를 위해서 서로 다른 테스트 케이스가 무엇을 테스트하는지 그리고 어떻게 테스트하는지 이해하고 있어야 한다. 또한 일부 개발자들은 테스트를 코드에 대한 사용 설명서로 사용하기 때문에 ..