킹의 개발일지

Test SpringBoot MVC Web Apps - Database Integration Testing #시나리오 주어진 시나리오로, 새로 일하게된 직장에서 이전 직원이 데이터 베이스 작업을 하던도중 일을 그만두는 바람에 내가 작업해야 한다는것이다. 해야할 작업 H2 인메모리 DB에 데이터를 저장하는 기능을 완성해야한다. 종속은 미리 pom.xml에 추가해두었다. 그에 대한 단위 테스트와 통합 테스트를 추가해야한다. 일반적으로 DB를 연결해서 테스트를 진행하면 그것을 통합테스트라고 한다. 네번 째 포스팅에서 봤던 작업은 Mocking을 이용해서 서비스 레이어에서 메서드를 특정 메서드를 호출하면 Dao 객체가 특정한 값을 반환하도록 했었다. 이제는 실제 DB에 값을 읽고 쓰는 테스트를 작성해야한다. T..

Mocking with Mockito 서비스 레이어는 주로 관련된 DAO 클래스를 주입받아 사용하는 경우가 많다. 때문에 테스트를 하려면 서비스 레이어가 의존하는 DAO 객체, DB 등 테스트하고자 하는 대상 이외의 것들도 함께 고민해야 할것이다. 원하는 대상만 고립시켜 최소한의 의존으로 테스트 하는 방법은 없을까. 이때 리허설에서 최소한의 장비만으로 시범 무대를 가지는것처럼 서비스 레이어가 의존하는 실제 DAO를 사용하지 말고 "이러한 요청이 있으면 이런 값을 반환하세요~ " 라고 미리 말해둔 대역을 쓰면 된다. 이를 Mocking이라고한다. Mocking을 하면 다음과 같은 장점이 있다. 테스트 하고자하는 클래스를 격리시켜 해당 클래스만 테스트 할 수 있다. 특정 메서드가 호출되면 DAO가 특정값을 ..

Springboot unit testing support 스프링 부트가 제공하는 테스트 지원 특징 스프링부트가 제공하는 테스트 지원을 받으려면 먼저 스프링 부트 프로젝트에 spring-boot-starter-test 종속성을 추가해주어야한다. 해당 종속성은 JUnit 5에 대한 transtive 종속성을 포함하고 있기 때문에 여타 필요한 종속을 명시적으로 나열할 필요 없어진다. 테스트시에만 사용할 것이기 때문에 scope를 테스트로 해준다. org.springframework.boot spring-boot-starter-test test 다음으로 특징으로, 스프링부트가 제공하는 @SpringBootTest 어노테이션은 한 줄로 많은 기능을 사용할 수 있게 해준다. Application context를 로..

TDD (Test Driven Development) 전통적인 개발 방법으로 첫째로 앱을 디자인하고 그것에 대한 코드를 작성하고 마지막으로 앱을 테스트한다. 테스트 주도 개발은 이러한 전통적인 개발 방법을 뒤집는 방식으로 시작한다. 테스트 주도개발은 실패하는 테스트를 먼저 시작한다. 아무것도 없는 상태에서 테스트를 하면 당연히 실패할것이다. 이에 우리는 이 실패한 테스트를 통과하도록 코드를 작성한다. 그러나 작성한 코드는 테스트를 성공시키고자 만든 급조한 코드이기에 리팩토링해야한다. 두번째 단계에서 작성한 코드는 테스트를 단순히 통과하고자 만든 코드이기에 소위 냄새나는 코드일지도 모른다. 때문에 우리는 리팩토링 단계를 통해 코드를 향상시켜야한다. 테스트 주도 개발을 진행할 때 위 단계를 끊임없이 순환한다..

테스트 케이스를 작성할 때 반복되는 초기화 작업이 있을 때 가 종종있다. 예를들면 아래 예시를 보면 DemoUtils demoUtils = new DemoUtils(); 이 부분에서 DemoUtils 객체를 테스트 케이스마다 반복적으로 선언해주고 있다. 만약 테스트 케이스가 수만개가 된다면 해당 클래스에 변경이 일어났을 때 해야할 고생은 이만저만이 아닐 것이다. 개방-폐쇄 원칙은 이와 같은 유형의 변경이 더 이상의 수정을 유발하지 않도록 하는데, 이에 맞게 바꿔줄 필요가 있다. @Test @DisplayName("Null And NotNull") void testNullAndNotNull() { DemoUtils demoUtils = new DemoUtils(); // 반복이 있는 부분 String st..

단위테스트 스프링 프레임워크 공부한걸 바탕으로 이것저것 만들어보는데, 테스트에는 큰 관심을 두지 않았다. 그러다보니 생산성이 많이 떨어지는것을 체감했다. 항상 애플리케이션을 실행해서 출력된 로그로 확인하다보니, 코드수가 늘어나니까 기다리는게 한세월이었다. 토비의 스프링에서 테스트 관련 이야기를 할 때, 개발자들이 무의식적으로 실패하는 테스트는 피하는 경향이 있다는것이다. '당연히 이런짓은 안하겠지?' 라는 생각으로 해당 부분의 테스트는 건너띄고 나중에 앱이 터지고나서야 부랴부랴 수습한다는 것이다. 나도 테스트 코드를 짜다보니 그런 부분을 빼먹는 경우가 많았다. 실제론 테스트 코드를 만들기 귀찮음도 있었다. JUnit을 다루는 솜씨도 떨어지다보니, 테스트에 무관심해졌다. 여하튼 토비의 스프링을 읽으면서 테..