UNITTEST
2022-09-22
스프링을 사용한 프로젝트에서 종종 보이는 어노테이션에 사용한 의존성 주입의 남용과 오랜 세월의 흐름으로 의도치 않게 서비스 간의 의존성 그래프가 복잡하게 강결합으로 묶이면서 코드를 읽기도 어렵고 단위 테스트를 구성하기도 어려운 상황이 생긴다. 아래는 어떤 백엔드 서비스의 의존성 그래프다. 순환 종속성이 포함된 복잡한 왼쪽의 의존성 그래프를 오른쪽의 단순한 의존성 그래프로 리팩터링하여 라이브 서비스에 반영하였다. 이번 글은 오랜 세월의 흐름으로 서비스 의존성 그래프가 복잡해진 라이브 서비스를 리팩터링한 내용을 일반화하여 작은 예제로 만들어서 정리한다....
2021-07-29
테스트 자동화 Test automation 의 일환으로 필자는 Golang으로 테스트 코드를 작성할 때 먼저 통합 테스트 Integration Test [1] 를 작성한다. 통합 테스트 코드를 작성하다 보면 주요 테스트 시나리오 외의 케이스를 촘촘하게 테스트 하기 어려운데 그 이유는 테스트 실행 비용(예. 웹 서버, 데이터베이스 등등)이 비싸고 비슷한 케이스를 작성하다 보면 코드 중복이 많이 발생하여 유지 보수가 어렵기 때문이다. 통합 테스트를 보완해 주는 것은 단위 테스트 Unit Test...
2019-06-16
해당 코드는 Github 에 공개되어 있습니다. 실무에서 Lombok 사용법 에서 기본적인 Lombk 사용법과 Builder 사용법을 간단하게 정리 한 내용을 먼저 참고하면 좋습니다. JPA를 이용하면 엔티티 객체들을 Builder 기반으로 생성하는 것이 흔한 패턴입니다. 이러한 경우 Builder의 문제점들과 이것을 더욱 안전하게 사용하는 방법에 대해서 이야기해보겠습니다. Builder로 안전하게 생성하자 JPA 엔티티 객체들에 Builder 어노테이션을 이용해서 엔티티 객체를 Builder를 이용하는 것이 흔한 패턴입니다. 이 패턴의 장단점을 알아보고 더욱 안전하게 객체를 생성하는 방법을 소개하겠습니다. Builder 패턴을 사용하면 다음과 같은 장점이 있습니다....
2018-04-02
이전 포스팅 BDD(Behaviour-Driven Development)에 대한 간략한 정리에서 같이 다루려고 했던 내용이다. 하나의 클래스를 테스트하기 위해서는 그 클래스가 사용하는 다른 클래스의 실제 구현이 필요하거나 테스트 대상 클래스가 사용하는 데이터베이스 등에 대한 외부 환경이 구성되어 있어야 하는 경우가 있다. 하지만 테스트 환경에서 이를 모두 구성하는 것은 현실적으로 쉽지 않고, 테스트 실패에 대한 원인이 해당 클래스만의 문제인지, 아니면 관련된 다른 클래스의 문제인지를 찾기가 무척 어렵다. 즉, 테스트 대상 클래스의 기능만 한정 지어 테스트를 수행하기 어려운 경우가 많다. 테스트 용이성이란 말 그대로 테스트 대상을 얼마나 테스트하기 쉬운가에 대한 척도이다. 테스트 대상이 얼마나 복잡한가? 얼마나 결합도가 높은가? 등 몇 가지 내용이 있지만, 이번 글에서는 테스트 용이성에서 결합도와 Mocking 에 대한 내용만을 간단히, 이를 개선하기 위해 Dependency Injection 이 어떻게 사용되는지에 대해 설명한다. 이 글에서 Mocking 은 Mocking 객체를 의미하며 이를 간단히 말하면 실제 객체를 흉내내는 가짜 객체를 하나 만드는...
더보기