테스트코드는 매우 많아질수 있다. 그러나 이를 적극적으로 관리하지 않으면 빠르게 부패하는 경향이 있다. 품질이 좋은 테스트코드를 작성하기 위한 노력을 기울이고 유지보수 하기 쉽게 만들어야한다. 테스트 유지보수성을 위한 원칙 1) 테스트는 빨라야 한다. 어떤 테스트가 느리다면, 다음사항을 고려해보자 => 모의객체나 스텁을 이용해 느린 구성요소를 대체한다. => 제품코드를 재설계해서 느린코드를 빠른코드와 분리하여 테스트할 수 있도록 한다. => 느린 테스트를 자주 실행하지 않는 다른 테스트 스위트로 옮긴다. SQL테스트와 같은경우 느린테스트보다 훨씬 느리지만, 뾰족한 방법이 별로 없다. 이런경우 빠른테스트와 느린테스트를 분리해서 따로 실행하면 좋다. 2) 테스트는 응집력있고 독립적이며 격리되어야한다. 테스트..

여기서 말하는 대규모의 테스트는 통합테스트와 시스템 테스트를 의미한다. 언제 대규모 테스트를 사용해야 할까? 1) 개별 클래스의 테스트는 수행했지만, 전체 동작이 여러클래스로 구동될때 어떤일이 일어나는지 확인하고 싶은경우 2) 테스트하려는 클래스가 거대한 플러그앤플레이 아키텍처의 구성요소일때 => 객체지향 설계의 장점으로 복잡성은 캡슐화 하고 추상화 되어있기 때문에 우리는 중요한것만 구현하면 된다. SQL 쿼리에서 테스트해야 하는것은 무엇일까? 1. SQL 조건문을 위한 MC/DC 적용하기 => join, where, having 조건에 대해 MC/DC 조건을 적용해볼수 있다. 2. null 처리를 위한 MC/DC 적용하기 => 데이터베이스는 3가지 값(ture,false,null)으로 된 로직을 적용해..

항상 TDD를 해야하는가? 당연하게도 '항상' '무조건' 같은 키워드는 NG워드이고, 그렇지 않다. 개발할 기능에 대해 내가 얼마나 알아야 할지에 따라 다르다. 저자가 선호하는 TDD를 사용하는 시점은 1. 설계, 아키텍처, 요구사항에 대한 구현방법이 명확하지 않아서 천천히 여러가지 가능성을 시험할 필요가 있을때. 2. 복잡한 문제나 그 문제에 관한 전문성이 부족할때 반대로 개발과정에서 배울만한것이 없고, 이미 문제와 그 해결책을 잘 알고있으면 바로 코딩한다. TDD는 대부분의 애플리케이션과 도메인에서 동작한다. 최근의 논문에서의 주장은 TDD의 이점은 테스트우선에 대한 역학 때문이 아니라 TDD의 프로세스를 따르면 집중력과 흐름을 개선하고 세분화되고 안정된 단계를 가지게 하기 때문이라는 주장이있다. 테..

이번 챕터는 TDD에 대해 알아보는 챕터이다. 저자는 처음에 간단한 프로그램을 테스트를 먼저 짜면서 구현하는 방식을 예제를 통해 소개한다. 이 과정을 통해 보여지는 반복 개발 프로세스를 요약하면 다음과 같은데 1. 구현하고 하는 기능조각에 대한 단위테스트를 작성한다. 테스트는 실패한다. 2. 기능을 구현한다. 테스트는 통과한다. 3. 제품코드와 테스트코드를 리팩터링한다. 이런 TDD프로세스를 빨강-초록 리팩터 주기라고도 한다. 이 방법의 이점은 다음과 같다 1. 요구사항을 먼저 살펴본다 => 특정문제에 대한 코드를 작성하고, 불필요한 코드를 작성하지 않도록 해준다. 2. 제품코드 작성속도를 완전히 제어한다. => 문제가 한번에 파악되지 않아도, 작은 부분으로 나누어서 간단한 부분에 대한 테스트를 먼저 작..

의존성 전달 방법의 트레이드오프 비교 1) 클래스 생성자 를 통한 의존성 주입 - 스텁을 만들기 쉽다. 주입받는 클래스의 의존성은 복잡해지지만, 이를 소비하는 테스트가 단순해진다. - 전체 클래스, 테스트의 복잡도를 약간 증가시키지만, 클라이언트 클래스를 단순하게 만들어준다. 2) 메서드 매개변수의 전달을 통한 의존성 주입 - 구현과 테스트 측면에서 가장 간단한 해결책, 하지만 모든곳에서 인수가 제공되어야한다는 단점이 있다. - 클래스와 테스트를 단순하게 만들지만 클라이언트의 복잡도를 약간 증가 시킨다. 저자가 추천하는 방식은 클래스를 호출한쪽의 작업을 단순하게 하는 방향을 택한다. (클래스 생성사를 통한 주입) 개발도중 테스트를 작성하는것의 이점 테스트에 관심을 두면, 테스트하려는 코드의 설계에 대한 ..

어떤 시스템은 테스트 하기 너무 힘들다! 테스트 가능성에 대한 설계 원칙에 대해 다루어 보자. 테스트가능성을 고려해야 할때는 언제일까? 답은 '항상' 고려 해야한다. 스파게티 코드를 작성하는일은 상호 협력적이고 응집력이 있고 테스트하기 쉬운 코드를 작성하는것보다 훨씬 쉽다. 테스트하기 쉽고 좋은코드는 비용은 많이들지만 품질을 보장하기 위한 유일한 방법이다. 1. 도메인코드에서 인프라 코드를 분리하기 간단하게, 도메인 코드에 데이터 베이스를 다루는 코드가 섞이면 어떻게 될까? 기본적으로 해당 클래스는 책임이 더 커질것이고 이는 버그가 발생할 가능성이 증가한다는뜻이다. 덜 응집된 클래스는 코드량이 많다. 인프라요소 외에도 사용자 인터페이스역시 마찬가지다, 비지니스 로직과 섞일때 이는 대부분 테스트 가능성을 ..