테스트 더블과 모의 객체 (with mockito 예제)

이펙티브 소프트웨어 테스팅 – 마우리시오 아니시 6장 테스트 더블과 모의 객체 참고 작성 글 테스트 대역 (목 과 스텁) 이펙티브 소프트웨어 테스팅은 처음 펼쳐봤는데 단위테스트(블라디미르 코리코프) 책에서 단위테스트를 고전파와 런던파로 나눠서 설명했던 것이 떠올랐다. 설명을 가져와 보면 다음과 같다. 단위 테스트의 고전파와 런던파 고전적 접근법은 ‘디트로이트(Detroit)’라고도 하며, 때로는 단위 테스트에 대한 고전주의적(classicist)접근법이라고도 한다. 아마도 고전파의 …

테스트 더블과 모의 객체 (with mockito 예제) 더 보기 »

테스트 코드 개선하기 – 테스트 리팩토링 하기 (+ 예제)

테스트 코드 개선하기 – 테스트 리팩토링 하기 (+ 예제) xUnit 테스트 패턴 – 제라드 메스자로스 – 0장 테스트는 애자일 개발 프로세스에서 금방 병목이 될 수 있다. 간단하고 알기쉬운 테스트와 복잡하고 무디며 유지 보수하기 어려운 테스트는 생산성에서 엄청난 차이가 있다. 예시를 통해 실제적으로 어떻게 테스트 코드를 개선할지에 대한 예시를 같이 알아보자. 복잡한 테스트 최초 코드는 다음과 …

테스트 코드 개선하기 – 테스트 리팩토링 하기 (+ 예제) 더 보기 »

테스트는 왜 해야하고 어떻게 해야할까

테스트를 왜 해야하고 어떻게 해야할까? xUnit 테스트 패턴 – 제라드 메스자로스 – 0장 리팩토링 4장에서 마틴 파울러는 다음과 같이 이야기 했다. 프로그래머가 업무 시간을 어떻게 보내는지를 살펴보면 사실 코드를 짜는 시간은 얼마 되지 않는다는 사실을 알게 될 것이다. 뭐가 어덯게 돌아가야 하는지를 찾아보거나 설계를 하기도 하지만 업무 시간의 대부분은 디버깅으로 보낸다. 프로그래머라면 누구나 몇 시간, …

테스트는 왜 해야하고 어떻게 해야할까 더 보기 »

xUnit 테스트 패턴 – 소개

xUnit 테스트 패턴 – 제라드 메스자로스 단위 테스트 책을 다 읽었다. 그리고 다음 읽을 책을 이 책으로 정했다. 이 책은 한국어 번역본은 있긴 했는데 절판된 상태라 구하기 어려웠다. 그냥 원문을 구매할까 고민을 많이 하다가 그래도 번역본이 읽는 속도가 빠를것 같아 번역본을 구매하는 방향으로 결정했다. 어렵게 구한만큼 열심히 읽어야겠다 마음먹었다. 기존에 읽던 단위 테스트 책은 C# …

xUnit 테스트 패턴 – 소개 더 보기 »

단위 테스트 안티 패턴 – 11장

1 비공개 메서드 단위 테스트 비공개 메서드는 어떻게 해야할까? 결론 부터 이야기 하면 ‘전혀 하지 말아야 한다’. 1.1 비공개 메서드와 테스트 취약성 단위 테스트를 하려고 비공개 메서드를 노출하는 것은 "식별할 수 있는 동작만 테스트 하라" 라는 기본 원칙을 위반한다. 비공개 메서드를 노출하면 테스트가 구현 세부 사항과 결합되고 결과적으로 리팩터링 내성이 덜어진다. 비공개 메서드를 직접 테스트하는 …

단위 테스트 안티 패턴 – 11장 더 보기 »

데이터베이스 테스트 – 10장

10장에서 다루는 내용 데이터베이스 테스트를 위한 전제 조건 데이터베이스 테스트 모범 사례 테스트 데이터 생명 주기 테스트 내 데이터베이스 트랜잭션 관리 통합 테스트 라는 퍼즐의 마지막 조각은 프로세스 외부 관리 의존성이다. 가장 일반적인 예시는 애플리케이션 데이터베이스다. 애플리케이션 데이터베이스는 다른 애플리케이션이 접근할 수 없는 데이터베이스다. 실제 데이터베이스를 테스트하면 회귀 방지가 아주 뛰어나지만 설정하기가 쉽지 않다. 이 …

데이터베이스 테스트 – 10장 더 보기 »

목 처리에 대한 모범 사례 – 9장

9장에서 다루는 내용 목의 가치를 극대화하기 목을 스파이로 교체하기 목 처리에 대한 모범 사례 목은 테스트 대상 시스템과 의존성 간의 상호 작용을 모방하고 검사 하는 데 도움이 되는 테스트 대역이다. 목은 비관리 의존성(외부 애플리케이션에서 식별할 수 있음)에만 적용해야 한다. 다른 것에 목을 사용하면 깨지기 쉬운 테스트(리팩터링 내성이 없는 테스트)가 된다. 이번 장에서는 목에 대해 리팩터링 …

목 처리에 대한 모범 사례 – 9장 더 보기 »

로깅도 테스트 해야할까 – 8장 통합 테스트를 하는 이유 (4)

로그도 테스트 해야할까? 로깅(logging)은 회색 지대로, 테스트에 관해서는 어떻게 해야 할지 분명하지 않다. 로깅과 관련해서는 다음과 같은 질문으로 나눌 수 있다. 로깅을 조금이라도 테스트해야 하는가? 만약 그렇다면 어떻게 테스트해야 하는가? 로깅이 얼마나 많으면 충분한가? 로거(logger) 인스턴스를 어떻게 전달할까? 8.6.1 로깅을 테스트해야 하는가? 로깅은 횡단 기능(cross-cutting functionality)으로, 코드베이스 어느 부분에서나 필요로 할 수 있다. 다음은 User …

로깅도 테스트 해야할까 – 8장 통합 테스트를 하는 이유 (4) 더 보기 »

8장 통합 테스트를 하는 이유 (3) : 언제 인터페이스를 써야할까? + 통합 테스트 작성 팁

8장 통합 테스트를 하는 이유 (3) 단위테스트 (블라디미르 코리코프) 8.4 의존성 추상화를 위한 인터페이스 사용 8.4.1 인터페이스와 느슨한 결합 많은 개발자가 데이터베이스나 메시지 버스와 같은 프로세스 외부 의존성을 위해 인터페이스를 도입한다. 심지어 인터페이스에 구현이 하나만 있는 경우에도 그렇다. 이 관습은 널리 퍼져 있어서 아무도 의문을 제기하지 않는다. 예시는 다음과 같다. public interface ImessageBus public class …

8장 통합 테스트를 하는 이유 (3) : 언제 인터페이스를 써야할까? + 통합 테스트 작성 팁 더 보기 »

8장 통합 테스트를 하는 이유 (2) : 언제 목을 써야할까? + 예시

8장 통합 테스트를 하는 이유 (2) 단위테스트 (블라디미르 코리코프) Freepik image by upklyak 8.2 어떤 프로세스 외부 의존성을 직접 테스트해야 하는가? 통합 테스트는 시스템이 프로세스 외부 의존성과 어떻게 통합하는지를 검증한다. 검증을 구현하는 방식은 두 가지가 있다. 실제 프로세스 외부 의존성을 사용 해당 의존성을 목으로 대체 두 가지 방식을 언제 적용해야 하는지에 대해 알아보자. 8.2.1 프로세스 …

8장 통합 테스트를 하는 이유 (2) : 언제 목을 써야할까? + 예시 더 보기 »

Scroll to Top