끄적끄적 개발

지난 글에서는 Mockito로 mock 객체를 만들고 JUnit과 함께 간단한 테스트를 작성하는 방법과 여러 Mockito 어노테이션에 대해 알아보았다. 이번 글에서는 Mockito를 사용하여 Spring Boot에서 Service 계층을 어떻게 테스트하면 좋을지 여러 테스트 케이스들을 살펴볼 것이다. Mockito에 대한 기본 개념이 궁금하신 분들은 이전 글을 먼저 참고하시길. 스프링 부트에서는 Mockito, JUnit 라이브러리가 자동으로 포함되기 때문에 별도의 설정없이도 테스트 코드를 작성할 수 있다. 그럼 테스트를 작성하기 위해 간단하면서도 의미있는 어플리케이션을 먼저 개발해보자. 이 어플리케이션은 Member, Team 엔티티로만 구성되며, 각 Member는 하나의 Team에 소속된다. (즉 ..

클래스 간 의존관계가 없는 자바 어플리케이션에서는 JUnit만으로도 테스트가 가능하다. 그러나 스프링의 핵심 개념인 DI(Dependency Injection), 즉 의존관계 주입으로 인해 각 클래스 간 의존관계가 생겨 테스트가 힘들어지게 된다. 대표적인 예를 들어보자. 스프링으로 웹 개발을 할 때 일반적으로 Controller - Service - Repository 계층을 구성하며 Controller는 Service를, 다시 Service는 Repository를 의존하게 된다. 이때 Service 계층을 테스트하려고 테스트 코드를 작성하고 실행 버튼을 눌렀더니 테스트에 실패했다. 비즈니스 로직은 아무리 봐도 잘못된 것이 없는데... 아뿔싸 Service가 의존하고 있던 Repository 계층에 잘못..

대부분의 테스트는 특정 메소드에 특정 인자를 전달하였을 때 기대한 값이 맞는지 확인하는 방식으로 이루어진다. 이때 전달하는 인자로 일반적인 값뿐만 아니라 edge case 혹은 corner case 등까지 포함해야 제대로 된 테스트라 할 수 있다. 아래와 같이 A 클래스에서 인자로 전달된 값을 바로 반환하는 메소드를 테스트한다고 가정해보자. 메소드가 제대로 동작하는지 확인하기 위해서는 하나의 값 뿐만 아니라 다양한 케이스에 해당하는 값들을 인자로 넘겨 테스트를 수행해야 한다. 그런데 아래와 같이 get 테스트 대상 메소드에 전달하는 인자 별로 테스트 메소드를 분리하게 되면, 중복 코드가 많아지고 테스트 클래스의 크기도 커져 무엇을 테스트 하고 있는지 한눈에 알아보기 어려워진다. 따라서 JUnit에서는 테..

지난 글에서는 JUnit이 제공하는 Assertions에 대해 알아보았다. 이번에 알아볼 AssertJ의 Assertions는 JUnit의 Assertions 보다 더 유연하고 가독성 있는 테스트 코드를 작성할 수 있게 해주며, 특히 자바 8의 함수형 프로그래밍의 특징들을 잘 활용할 수 있게 해준다. 그럼 이 AssertJ가 뭔지 간단히 살펴보고 AssetJ의 Assertions 메소드들을 자주 사용하는 것들 위주로 정리해보자. JUnit 자바 기반 테스트 자동화 프레임워크 AssertJ 자바 기반 테스트에서 Assertions를 작성하기 위한 오픈소스 라이브러리 즉 JUnit에 비해 AssertJ가 Assertion에 더 특화되어 있다고 보면 된다. 자바에서 AssertJ를 사용하기 위해서는 build..