3.2 Spring Test

1) Test 개요

1. 테스팅이란 무엇인가?

요구하는 수준을 만족하는지 확인하기 위해 결함을 발견하는 과정이라고 말할 수 있습니다.

 

전통적인 테스팅 개념은 응용 프로그램 또는 시스템이 잘 작동하는지 확인하는 것입니다.

현재의 테스팅 개념은 사용자의 기대 수준과 요구 사항에 맞게 구현되고 동작하는지를 확인하고 이를 통해 결함을 발견하고,

최종적으로 결함 데이터를 근간으로 개발 프로젝트의 리스크(Risk)에 대한 수치적인 판단 근거를

의사 결정권자(프로젝트 관리자 등)에게 전달하는 것을 말합니다.

 

개발 프로젝트 초기에 개발 중간 산출물(Work products)을 테스팅 관점에서 리뷰(Review)하고,

테스트 케이스를 미리 만드는 과정에서 결함을 발견하는 작업(결함 예방 활동)도 테스팅 활동의

중요한 부분이라고 말할 수 있습니다.

 

생각해 보세요. 사용자에게 전혀 필요없는 부분을 개발하고 개발한 부분을 테스트한다면 무의미 하지 않을까요?

'요구사항이 잘못된것 아닐까?'와 같은 리뷰가 중요할까요? 개발이 중요한 것일까요?

이 2가지 물음 중에서 현재의 테스팅은 전자가 더 중요하다고 생각합니다.

 

프로그램을 개발하기 전에 요구사항 등을 리뷰하는 것을 정적 테스트라고 하고,

프로그램 개발 이후에 실제 실행하면서 테스트하는 것을 동적 테스트라고 합니다.

 

본 수업에서는 정적 테스트보다 동적 테스트를 하는 방법에 좀 더 초점이 맞춰져 있습니다.

2. 소프트웨어에서 테스트가 필요한 이유

소프트웨어가 올바르게 동작하지 않는 경우, 다음과 같은 문제가 발생할 수 있습니다.

 

1) 금전적인 손실

2) 시간 낭비

3) 비즈니스의 이미지 손상

4) 부상이나 사망

 

소프트웨어가 올바르게 동작하지 않는다고 해서 부상이나 사망을 할 수 있다는 문제에 대해 의아해 할 수 있습니다.

하지만 오늘날에는 우주선, 비행기, 선박, 자동차 등 다양한 곳에서 소프트웨어가 사용되기 때문에 오동작을 일으킬 경우 실제로 부상이나 사망까지도 일어나게 할 수 있습니다.

따라서, 테스팅은 이러한 소프트웨어 시스템의 문제를 최소화기 위해 필요합니다.

3. 소프트웨어 결함의 원인

소프트웨어가 결함이 발생하는 이유는 무엇일까요?

개발자가 잘못 작성한 오류로 인하여 결함(Defects 또는 Bug)이 발생합니다.

결함이 있는 소프트웨어를 실행하게 되면 장애(Failure)가 발생하여 의도한대로 소프트웨어가 동작하지 않거나

또는 소프트웨어가 동작하지 않아야 하는 상황에서 동작하는 문제가 발생할 수 있습니다.

단, 모든 결함의 원인이 인간이 범하는 오류 때문만은 아닙니다.

 

인간이 오류를 범하기 쉽기 때문에 발생하는 결함도 있지만 시간적인 압박, 복잡한 코드, 기반환경의 복잡성,

기술이나 시스템의 변경, 그리고 수많은 시스템 상호간의 연동 등의 이유로 발생할 수도 있습니다.

4. 소프트웨어 개발, 유지보수, 운영 시 테스팅의 역할

소프트웨어는 개발이 완료되고 실제 환경에 배포를 해야 운영됩니다.

운영되는 도중에도 해당 소프트웨어를 더 이상 사용하지 않을 때까지 계속해서 유지보수를 하게 됩니다.

테스팅은 개발 시에만 필요한 것이 아니라 개발, 유지보수, 운영 시에 모두 필요합니다.

 

그렇다면 테스트가 언제 필요한지 알아볼까요?

1) 테스팅을 통해 릴리즈 전에 발견되지 않은 결함들이 수정된다면, 운영 환경 내에서 발생하는 리스크(risk)를 줄이는데 기여할 수 있으며 소프트웨어 품질에 도움을 줍니다.

2) 테스팅은 개발 초기의 요구사항 분석 단계부터 리뷰 및 인스펙션을 통해 정적으로 이뤄질 수 있으며 각각의 개발 단계에 대응하는 테스트 레벨(test level)에 따른 테스팅이 이뤄집니다.

3) 기존에 운영되는 소프트웨어 시스템이 유지 보수 활동으로 변경 및 단종되거나 환경이 변하는 경우, 변경된 소프트웨어에 대한 테스팅과 변경된 환경에서의 운영 테스팅이 요구됩니다.

4) 소프트웨어 테스팅은 계약상(법적) 요구조건들, 또는 산업에 특화된 표준들을 만족시키기 위해서 필요합니다.

5. 테스팅과 품질

테스팅으로 발견된 결함이 소수이거나 없을 경우에 소프트웨어의 품질에 대한 확신(Confidence)를 가지게 됩니다.

잘 설계된 테스트는 시스템의 전반적인 리스크를 감소시키고 결함을 발견합니다.

발견된 결함이 수정될 때 소프트웨어 시스템의 품질 증가됩니다.

 

품질을 높이기 위해서는 이전 프로젝트를 통해 많은 테스팅 경험과 정보를 확보할 필요성이 있습니다.

다른 프로젝트에서 발견된 결함의 근본적인 원인에 대한 이해함으로써 프로세스를 개선할 수 있으며,

그러한 결함의 재발을 방지함으로써, 결과적으로, 차후 시스템의 품질을 개선할 수 있게 됩니다.

 

개발 표준이나 교육 훈련 그리고 결함 분석 등과 함께 테스팅은 품질 보증 활동의 하나로

테스팅을 통해 소프트웨어 시스템의 품질을 확보할 수 있습니다.

6. 테스팅은 얼마나 해야 충분한가?

그렇다면 테스팅은 얼마나 해야 충분하다고 말할 수 있을까요?

어느 정도 테스팅 하는 것이 적절한지를 파악하기 위해서는 다음과 같은 리스크(Risk) 수준과

프로젝트 제약사항을 고려해야합니다.

 

1) 기술적인 내용

2) 비즈니스 제품

3) 프로젝트 리스크

4) 시간과 비용

 

테스트는 개발 프로젝트 관련자들이 테스트된 소프트웨어나 시스템의 다음 개발 단계로의 릴리즈(Release)에 대한 결정 또는 고객에게 이양(Handover)하는 릴리즈에 대한 결정을 내릴 수 있도록 충분한 정보를 제공해야 합니다.

7. 테스팅의 일반적인 원리

다수의 테스팅의 원리가 40여년간 제안되어 왔으며 테스팅의 원리는 테스팅 전반에 대한

일반적인 가이드 라인 역할을 해오고 있습니다.

 

원리 1 – 테스팅은 결함이 존재함을 밝히는 활동이다.

테스팅은 결함이 존재함을 드러내지만, 결함이 없다는 것을 증명할 수 없습니다.

즉, 프로그램이 완벽하다고 증명할 수 없습니다.

이는 테스트 한 부분까지만 잘 동작한다고 말할 수 있고 테스트를 하지 않은 부분은

결함 있는지 또는 없는지에 대해서 예측할 수 없다는 의미입니다.

 

원리 2 – 완벽한 테스팅(Exhaustive testing)은 불가능하다.

모든 가능성(입력과 사전 조건의 모든 조합)을 테스팅하는 것은 지극히 간단한 소프트웨어를 제외하고 가능하지 않습니다.

보통 다음과 같은 이유 때문입니다.

-  한 프로그램 내의 내부 조건이 무수히 많음. (무한 경로)

-  입력이 가질 수 있는 모든 값의 조건이 무수히 많음 (무한 입력 값)

-  GUI 이벤트 발생 순서에 대한 조합도 무수히 많음 (무한 타이밍)

완벽한 테스팅 대신, 리스크 분석과 결정된 우선순위에 따라 테스팅 활동 노력을 집중시켜야 합니다. (Risk-based testing)

완벽한 테스팅은 우주항공, 의료 등 안전이 최우선(Safety critical)인 소프트웨어를 개발할 때 고려할 수 있으나

실제로 완벽한 것은 아니고 강력한 테스팅으로 볼 수 있습니다.

 

원리 3 – 테스팅을 개발 초기에 시작한다.

테스팅 활동은 소프트웨어나 시스템 개발 수명주기에서 가능한 초기에 시작되어야 하며,

설정한 테스팅 목표에 집중해야 합니다.

개발 초기에 테스팅을 시작한다는 것의 의미는 개발의 시작과 동시에 테스트를 계획하고

전략적으로 접근하는 것을 고려하는 것은 물론, 요구사항 분석서와 설계서 등의 개발 중간 산출물을 분석하여

테스트하는 것을 의미합니다.

 

+테스팅이 중요하다보니 TDD같은 방법론도 존재합니다. TDD가 무엇인지 알아보세요. ㅡ> spring-boot 강의에 이어서 배우고 있음.

---

2) JUnit

1. JUnit이란?

프로그래밍 언어마다 테스트를 위한 프레임워크가 존재합니다.

이러한 도구들을 보통 xUnit이라고 말합니다. 자바언어의 경우는 JUnit이라고 말합니다.

각 언어마다 사용되는 xUnit은 다음과 같습니다.

 

2. JUnit 사용하기

JUnit을 사용하려면 JUnit 라이브러리가 클래스패스(CLASSPATH)에 존재해야 합니다.

직접 다운로드를 받는 것은 번거롭기 때문에 보통 빌드 도구인 Maven이나 Gradle을 이용해 다운로드 받아 사용합니다.

Maven을 사용할 경우 pom.xml에 다음을 추가합니다.

<dependency>
    <groupId>junit</groupId>
    <artifactId>junit</artifactId>
    <version>4.12</version>
    <scope>test</scope>
</dependency>

---

3) 스프링 테스트 어노테이션 사용하기

프로젝트명: calculatorcli02

 

이전 시간에 학습했던 사칙연산을 계산하는 CalculatorService클래스를 스프링 프레임워크에서 빈(Bean)으로 관리되도록 수정해보겠습니다.

그리고 나서 기존 테스트 클래스도 수정하여 빈(Bean)을 테스트 하겠습니다.

 

1. 스프링 프레임워크를 사용하도록 기존 코드 변경하기

스프링 프레임워크를 사용하려면 관련 라이브러리들이 프로젝트에 추가 되야 합니다.

pom.xml 파일을 수정합니다.

수정을 하고 나서 Maven update를 수행합니다.

스프링 프레임워크를 사용하려면 설정 파일을 작성해야 합니다. 스프링 설정 파일은 xml파일이나 Java Config로 작성할 수 있다고 하였습니다. Java Config파일로 다음과 같이 작성해 보도록 하겠습니다.

 

ApplicationConfig.java

package org.edwith.webbe.calculatorcli;

import org.springframework.context.annotation.ComponentScan;
import org.springframework.context.annotation.Configuration;

@Configuration // 나 스프링 설정 파일이야. 스프링 설정파일은 스프링 빈 컨테이너인 ApplicationContext에서 읽어들인다
@ComponentScan(basePackages = {"org.edwith.webbe.calculatorcli"}) //특정 패키지 이하에서 @Component, @Repository, @Service, @Controller, @RestController 등의 어노테이션이 붙은 클래스를 찾아 빈으로 등록합니다.
public class ApplicationConfig {
}

 

CalculatorService.java

package org.edwith.webbe.calculatorcli;

import org.springframework.stereotype.Component;

//스프링 빈 컨테이너에서 관리한다는 것은 개발자가 직접 인스턴스를 생성하지 않는다는 것을 의미합니다.
//스프링 빈 컨테이너가 인스턴스를 생성해 관리한다는 것을 뜻합니다.
@Component // 스프링 빈 컨테이너가 CalculatorService클래스를 찾아 빈으로 등록할 수 있도록 어노테이션.
public class CalculatorService {
    public int plus(int value1, int value2) {
        return value1 + value2;
    }

    public int minus(int value1, int value2) {
        return value1 - value2;
    }

    public int multiple(int value1, int value2) {
        return value1 * value2;
    }

    public int divide(int value1, int value2) throws ArithmeticException {
        return value1 / value2;
    }
}

스프링 빈 컨테이너에서 관리한다는 것은 개발자가 직접 인스턴스를 생성하지 않는다는 것을 의미합니다.

스프링 빈 컨테이너가 인스턴스를 생성해 관리한다는 것을 뜻합니다.

스프링 빈 컨테이너가 CalculatorService클래스를 찾아 빈으로 등록할 수 있도록 클래스 위에 @Component를 붙입니다.

 

위와 같이 작성했다면, 기존 클래스를 스프링 프레임워크에서 사용될 준비가 끝난 것입니다.

CalculatorService 클래스를 이용하려면 다음과 같은 클래스를 작성해야 합니다.

 

Main.java

package org.edwith.webbe.calculatorcli;

import org.springframework.context.ApplicationContext;
import org.springframework.context.annotation.AnnotationConfigApplicationContext;

public class Main {
  public static void main(String[] args){
   ApplicationContext applicationContext = new AnnotationConfigApplicationContext(ApplicationConfig.class);

   CalculatorService calculatorService = applicationContext.getBean(CalculatorService.class);
   System.out.println(calculatorService.plus(10, 50)); // result: 60
  }
}

2. 테스트 클래스를 스프링 빈 컨테이너를 사용하도록 수정하기

기존 테스트 클래스는 테스트할 객체를 @Before가 붙은 메소드에서 초기화 하였습니다.

 

스프링 빈 컨테이너를 사용할 때는 개발자가 직접 인스턴스를 생성하면 안됩니다.

스프링 빈 컨테이너가 빈을 생성하고 관리하도록 하고, 그 빈을 테스트 해야합니다.

이를 위해서 스프링 프레임워크는 몇가지 특별한 기능을 제공합니다. 소스 코드를 아래와 같이 수정하도록 합니다.

 

기존 테스트 클래스 위에 @RunWith(SpringJUnit4ClassRunner.class)를 붙입니다.

@RunWith 어노테이션은 JUnit이 제공하는 어노테이션입니다.

JUnit은 확장기능을 가지는데, 스프링에서는 JUnit을 확장하도록 SpringJUnit4ClassRunner.class를 제공합니다.

해당 코드는 JUnit이 테스트 코드를 실행할 때 스프링 빈 컨테이너가 내부적으로 생성되도록 합니다.

 

@ContextConfiguration(classes = {ApplicationConfig.class})은 내부적으로 생성된 스프링 빈 컨테이너가 사용할 설정파일을 지정할 때 사용합니다.

 

위에서 설명한 2줄이 테스트 클래스 위에 있으면, 테스트 클래스 자체가 빈(Bean)객체가 되어 스프링에서 관리되게 됩니다.

 

@Autowired

CalculatorService calculatorService;

CalcultorServiceTest 클래스가 빈으로 관리되면서, 스프링 빈 컨테이너는 CalculatorService를

주입(Inject)할 수 있게 됩니다. 이렇게 주입된 클래스를 테스트하면 됩니다.

 

테스트 결과는 기존의 클래스와 같은 것을 확인할 수 있습니다.

---

4) 로직 단위테스트 구현하기

빈들 간에는 다양한 관계를 맺고 있는 경우가 많습니다.

하나의 빈을 사용한다는 것은 관계된 빈들도 함께 동작한다는 것을 의미합니다.

 

통합 테스트(integration test): 하나의 빈을 테스트할 때 관련된 빈들이 모두 잘 동작하는지 테스트하는 것

단위 테스트(unit test): 관계된 다른 클래스와는 상관 없이 특정 빈이 가지고 있는 기능만 잘 동작하는지 확인하는 것

 

MyService.java

package org.edwith.webbe.calculatorcli;
import org.springframework.stereotype.Service;

@Service
public class MyService {
     private final CalculatorService calculatorService;
     public MyService(CalculatorService calculatorService) {
          this.calculatorService = calculatorService;
     }
     public int execute(int value1, int value2) {
    //  return 0;
          return calculatorService.plus(value1, value2) * 2;
    }
}

MyService클래스는 아래의 클래스 다이어그램처럼 CalculatorService를 필드로 가지고 있습니다.

해당 필드는 생성자를 통해 초기화를 합니다.

MyService가 가지고 있는 execute메소드는 calculatorService.plus()메소드를 사용합니다.

2개의 값을 받아 plus()메소드를 이용해 더한 후 2를 더한 값을 반환합니다.

 

이렇게 작성한 MyService객체는 다음과 같은 방법으로 테스트를 할 수 있습니다.

 

MyServiceTest.java

package org.edwith.webbe.calculatorcli;

import org.junit.Assert;
import org.junit.Test;
import org.junit.runner.RunWith;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.test.context.ContextConfiguration;
import org.springframework.test.context.junit4.SpringJUnit4ClassRunner; 

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(classes = {ApplicationConfig.class})
public class MyServiceTest {
    @Autowired
    MyService myService;

    @Test
    public void execute() throws Exception{
        // given
        int value1 = 5;
        int value2 = 10;

        // when
        int result = myService.execute(value1, value2);

        // then
        Assert.assertEquals(30, result);
    }
}

@RunWith(SpringJUnit4ClassRunner.class) 는 내부적으로 스프링 빈 컨테이너를 생성한다고 하였습니다.

스프링 빈 컨테이너는 빈들을 찾아 메모리에 올리게 됩니다. 그리고 나서 myService필드에 객체를 주입하게 됩니다.

 

테스트 메소드는 myService.execute()를 실행합니다. 5와 10을 더한 값에 2를 곱한 결과를 exeucte()메소드는 반환합니다.

 

assertEquals()메소드로 비교한 결과, 결과는 맞게 나올 거라고 예상할 수 있습니다.

그런데, CalculatorService의 plus()메소드에 버그가 있다면 어떻게 될까요?

plus()메소드가 더하는 것이 아니라 곱한 결과를 반환한다면 어떻게 될까요?

아마 내가 생각한 값이 나오지 않을 것입니다.

 

MyService를 테스트하려고 하였지만 CalculatorService의 버그로 인해 에러가 날 수도 있는 것입니다. 이런 문제를 해결하려면 어떻게 해야할까요? 이런 문제를 해결하는 방법 중 하나는 목(Mock)객체를 이용하는 방법이 있습니다.

MyService가 사용하던 CalculatorService를 사용하는 대신, 가짜 객체를 하나 생성하도록 하는 것입니다. 내가 원하는 동작을 하는 Mock객체로 CalculatorService를 사용함으로써 MyService의 내용만 테스트를 수행할 수 있습니다.

 

이를 위해 pom.xml파일에 다음을 추가합니다.

<!-- test mock을 위한 라이브러리를 추가합니다. -->
<dependency>
    <groupId>org.mockito</groupId>
    <artifactId>mockito-core</artifactId>
    <version>1.9.5</version>
    <scope>test</scope>
</dependency>

mockito는 모기의 영어단어를 줄인 말이 아니고 유명한 영화 대사인 “모히또 한 잔하러 가자”의 모히토에서 이름을 따왔다고 합니다.

mockito는 오픈소스 목 프레임워크입니다.

테스트를 위해 가짜 객체를 쉽게 만들어 줄 수 있는 프레임워크라고 생각하면 편합니다.

Mockito 프레임워크 자체만 하더라도 다뤄야 할 양이 많아서 Mockito에 대해 모두 다루기는 어렵습니다.

이번 시간은 Mockito를 이용해 목 객체를 사용하는 것이 이런 것이구나라고 느끼게 만드는 것이 목적입니다.

 

MyServiceTest2.java

package org.edwith.webbe.calculatorcli;

import org.junit.Assert;
import org.junit.Test;
import org.junit.runner.RunWith;
import org.mockito.InjectMocks;
import org.mockito.Mock;
import org.mockito.runners.MockitoJUnitRunner;

import static org.mockito.BDDMockito.given;
import static org.mockito.Matchers.anyInt;
import static org.mockito.Mockito.verify;

// mockito가 제공하는 Junit 확장 클래스 MockitoJunitRunner를 이용해 테스트 클래스를 실행하도록 합니다.
@RunWith(MockitoJUnitRunner.class)
public class MyServiceTest2 {

//    @InjectMocks 어노테이션이 붙은 필드는 목 객체를 사용하는 MyService 객체를 생성하여 초기화하라는 의미를 가집니다. 
//    myService 역시 여러분들이 초기화하지 않아도 자동으로 MyService 객체가 생성되어 초기화 됩니다.
    @InjectMocks
    MyService myService;

//    @Mock 어노테이션은 calculatorService가 목 객체를 참조하도록 합니다.
//    즉, 여러분이 객체를 생성하지 않아도 자동으로 객체가 생성되고 해당 필드가 초기화 된다는 것을 의미합니다.
    @Mock
    CalculatorService calculatorService;

    @Test
    public void execute() throws Exception {
        // given
        int value1 = 5;
        int value2 = 10;
        given(calculatorService.plus(5, 10)).willReturn(15);
//        given()은 static메소드입니다.
//        import문을 보면 org.mockito.BDDMockito 클래스의 static 메소드인것을 알 수 있습니다. 
//        calculatorService는 가짜 객체입니다. 이 가짜 객체가 동작하는 방법을 규정할 수 있는 것이 given()메소드입니다.
//        calculatorService.plus(5,10)을 호출하면 plus메소드가 15를 반환하도록 하라는 의미를 가집니다. 


        // when
        int result = myService.execute(value1, value2);
//        execute()메소드는 내부적으로 calculatorService의 plus메소드를 호출합니다. 
//        해당 메소드는 위에서 설정한대로만 동작합니다. 
//        value1과 value2가 무슨 값이든지 간에 result는 30을 반환할 것입니다.

        // then
        verify(calculatorService).plus(anyInt(), anyInt());
//        verify()메소드는 org.mockito.Mockito의 static한 메소드입니다. 
//        anyInt()메소드는 org.mockito.Matchers의 static한 메소드입니다. 
//        verify메소드는 파라미터로 들어온 객체의 plus메소드가 호출된 적이 있는지 검증합니다.
//        좀 더 자세히 살펴보자면 plus(anyInt(), anyInt())는 어떤 정수든지 2개를 파라미터로 넣어서
//        plus()메소드를 호출했는지를 검증합니다. 
//        myService.execute()메소드 내부적으로 plus 메소드를 호출했다면 해당 메소드는 검증을 성공한 것입니다.
//        만약, execute()메소드에서 plus(anyInt(), anyInt())를 호출하지 않았다면 오류가 발생하게 됩니다.
        Assert.assertEquals(30, result);
    }
}

execute() 메소드를 위와 같이(plus메소드가 호출되지 않도록 주석문 처리하였다.) 수정한 후 테스트를 실행해보겠습니다.

해당 메소드가 호출한 적 없다는 Exception이 발생하면 테스트는 실패한 것입니다.