[TOC]

• Acceptance: Does the whole system work?
  • same as: “functional tests,” “customer tests,” “system tests.”, "UI tests"
  • 진척도 측정
• Integration: Does our code work against code we can't change?
  • spring configuration works ?
• Unit: Do our objects do the right thing, are they convenient to work with?
  • iterative discovery of interfaces, design with working code(refactoring)

https://gaboesquivel.com/blog/2014/differences-between-tdd-atdd-and-bdd/

• 구현 전에 사용자, 테스터 및 개발자가 인수 조건(Acceptance Criteria)을 정의하는 협업 실천법
• 모든 프로젝트 구성원이 수행해야 할 작업과 요구 사항을 정확히 이해할 수 있도록 도와줌
• 요구 사항이 만족되지 않으면 테스트가 실패하여 빠른 피드백 제공
• 테스트는 비즈니스 도메인 용어로 기술됨.
• 각 기능은 반드시 실질적이고 측정 가능한 비즈니스 가치를 제공해야합니다.
• 인수 테스트(Acceptance Test)에 요구사항을 명시하는데 촛점. 인수 테스트로 개발을 주도(drive)

https://reqtest.com/testing-blog/tdd-and-atdd-an-overview-of-the-two-popular-methods-2/

• 구현 전에 관련된 모든 사람들(테스터, 개발자 및 사용자)이 한 팀으로써 개발 초기 단계에 시스템이 충족해야하는 인수 조건을 정의하도록하는 공동 작업 방식

https://www.agilealliance.org/glossary/atdd/

• ATDD는 해당 기능을 구현하기 전에 서로 다른 시각을 가진 구성원들(고객, 개발, 테스트)이 인수 테스트를 작성하는 작업 방식

• 고품질의 SW를 작성하는 가장 빠른 방법
  • Kent Beck. punch card / print out.
• 작고, 빠른 피드백
• 첫번째 고객. 메뉴얼.

1. Write NO production code except to pass a failing test.
2. Write only ENOUGH of a test to demonstrate a failure
3. Write only ENOUGH production code to pass the test

refactoring: mandatory not optional

• 시간이 없다 ? 별도의 일정 ?
• 화장실 다녀오면서 손 씻을 시간을 별로도 잡나 ???

• Test After도 나쁘지 않지만 그건 TDD(Design)이 아니라 Coverage가 일부 확보된 것

Growing Object-Oriented Software, Guided by Tests

• 특정 클래스에 대한 단위 테스트를 작성함으로써 TDD를 시작하고 싶은 욕구 발생
  • 테스트를 전혀 작성하지 않는 것보다는 좋겠지만 단위 테스트만 있는 프로젝트는 TDD 프로세스의 아주 중요한 혜택을 놓치게 됨
  • 단위 테스트가 잘 작성된 고품질의 코드들이
    • 어디서도 호출되지 않거나
    • 시스템의 다른 부분과 통합할 수 없거나
    • 재작성해야만 하는
  • 경우가 존재한다(bottom-up의 폐해).
• 어디서 코딩을 시작하고, 언제 코딩을 종료할지를 어떻게 알 수 있을까 ?(top-down)
• 특정 기능(Feature)를 구현할 때 우리가 구현하려는 기능을 보여주는 Acceptance Test를 작성함으로써 시작
  • 이 테스트가 실패하는 동안은 시스템이 이 기능을 아직 구현하지 못했다는 것을 보여준다. 그리고 테스트가 성공하면 우린 완료한 것이다.

가장 간단한 성공 케이스로 테스트를 시작

• degenerate or failure case로 시작하는 것은 쉽다
• Degenerate cases는 시스템의 가치에 많은 것을 추가하지 않고, 또한 우리의 생각이 유효한지에 대해 충분한 피드백틀 주지 않는다.
• 당신이 읽고 싶은 테스트를 작성하라(Unit vs. Acceptance Test)

사용자(Employee)는 lastName을 인자로 인사말(greeting)을 요구한다. 시스템은 lastName으로 DB에서 Employee를 찾고

• 존재하는 경우 "Hello firstName lastName !"을
• 존재하지 않는 경우 "Who is this lastName you're talking about?"을

반환한다.

<dependency>
    <groupId>io.rest-assured</groupId>
    <artifactId>rest-assured</artifactId>
    <version>3.0.7</version>
    <scope>test</scope>
</dependency>

추가

package com.example.employee;

import io.restassured.specification.RequestSpecification;
import org.junit.Before;
import org.junit.Test;
import org.junit.runner.RunWith;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.http.HttpStatus;
import org.springframework.test.context.TestPropertySource;
import org.springframework.test.context.junit4.SpringRunner;

import static io.restassured.RestAssured.given;
import static org.hamcrest.core.Is.is;

@RunWith(SpringRunner.class)
@SpringBootTest(
        webEnvironment = SpringBootTest.WebEnvironment.DEFINED_PORT,
        classes = EmployeeApplication.class
)
@TestPropertySource(
        locations = "classpath:application-integration.properties"
)
public class EmployeeControllerRestAssuredIntegrationTest {
    @Autowired
    private EmployeeRepository repository;

    private RequestSpecification basicRequest;

    @Before
    public void setUp() {
        basicRequest = given()
                .baseUri("http://localhost")
                .port(8080)
        ;

        repository.deleteAll();
        repository.save(new Employee("Baek", "Myeongseok"));
    }

    @Test
    public void shouldReturnDefaultMessageWhenLastNameNotFound() {
        String nonExistingLastName = "nonExistingLastName";
        String expectedMessage = "Who is this " + nonExistingLastName + " you're talking about?";

        given().spec(basicRequest).basePath("/api/hello/" + nonExistingLastName)
                .when().get()
                .then().log().body()
                .statusCode(HttpStatus.OK.value())
                .body(is(expectedMessage));
    }

    @Test
    public void shouldReturnGreetingMessageWhenLastNameFound() {
        String existingLastName = "Baek";
        String expectedMessage = "Hello Myeongseok Baek!";

        given().spec(basicRequest).basePath("/api/hello/" + existingLastName)
                .when().get()
                .then().log().body()
                .statusCode(HttpStatus.OK.value())
                .body(is(expectedMessage));
    }
}

• add src/test/resources/application-integration.properties

spring.datasource.url = jdbc:h2:mem:test
spring.jpa.properties.hibernate.dialect = org.hibernate.dialect.H2Dialect

• add jpa annotation to Employee, EmployeeRepository
• add EmployeeController

@RestController
@RequestMapping("/api")
public class EmployeeController {
    @GetMapping("/hello/{lastName}")
    public String greeting(@PathVariable String lastName) {
        return "Who is this " + lastName + " you're talking about?";
    }
}

controller에서 하드 코딩된 결과를 반환하도록 하여 하나의 테스트는 성공시켰지만 2가지 경우를 성공시키진 못했다. 제대로 하려면 로직이 필요하다.

controller는

• 사용자의 요청 해석(spring-mvc의 경우는 annotation으로 가능)
• controller 수준의 validation
• service로 위임
• 다음 페이지를 결정하고 service에서 반환받은 값을 전달하여 view를 출력

하는 책임을 갖는다(POJOs in Action).

따라서 우리는 service 객체가 필요하다.

@Service
public class GreetingService {
    public String greet(String lastName) {
        return null;
    }
}

로직을 구현할 서비스 객체와 메소드를 발견했으므로 이제부터 TDD로 하나의 메소드를 완성한다.

public class GreetingServiceTest {
    private GreetingService greetService;

    @Before
    public void setUp() throws Exception {
        greetService = new GreetingService();
    }

    @Test
    public void greet_with_nonExisting_last_name_should_return_default_message() {
        String nonExistingLastName = "nonExistingLastName";
        String msg = greetService.greet(nonExistingLastName);
        assertThat(msg, is("Who is this " + nonExistingLastName + " you're talking about?"));
    }
}

이게 맞으나 이렇게 하면 작은 단위로 빠르게 확인하며 구현하기 어렵다. 왜냐하면 이 테스트를 성공시키기 위해서 service 메소드를 구현해야 하는데 빠르게 한 줄 단위로 실행시키고 확인해 보면서 구현하기 어렵다.

테스트에 직접 서비스 메소드를 구현한다.

이때 실패하는지도 인자를 바꿔서 확인해서 우리의 테스트가 성공하는 경우와 실패하는 경우 모두를 검증하는지 확인

• extract fields
• move up given code to setUp
• declare variables(lastName, employee1, msg1)

• extract method to move

@Service
public class GreetingService {
    EmployeeRepository repository;

    public String greet(String lastName) {
        Optional<Employee> employee = repository.findByLastName(lastName);
        return employee
                .map(e -> String.format("Hello %s %s!", e.getFirstName(), e.getLastName()))
                .orElse("Who is this " + lastName + " you're talking about?");
    }
}

move후에 change signature로 test에 대한 의존성 제거

이제 우리의 테스트 코드는 comment out한 초기 의도를 나타낸 테스트 코드와 같아졌다. comment를 삭제하고 , 테스트 명에 맞게 메소드를 분리한다.

controller integration test가 real object로 동작하도록 수정

controller integration test가 제대로된 E2E 테스트(Acceptance)가 되었고, 우리의 작업은 완료되었다.

바로 테스트 코드에서 한줄 단위로 작성/실행/확인하는데...

spring mock mvc도 훌륭. 원격의 CI서버에서 원격의 검증 서버에 대해서 Integration Test를 해야 하는 필요로 rest-assured 선택

@SpringBootTest

• 통합 테스트, 전체 Bean 로딩됨

@WebMvcTest

• WebApplicationContext이 Bean 들이 로딩됨

@DataJpaTest

• Repository 레스트를 위한 JPA 관련 Bean들이 로딩됨
• persistence layer 테스트를 위한 표준 설정 제공
  • H2 인메모리 DB, Hiberante, Spring Data, Datasource 등을 설정
  • @EntityScan 실행
  • SQL 로깅 설정

@ExtendWith(SpringExtension.class)

• spring boot test의 기능과 junit의 연결의 제공
• junit 테스트에서 spring boot test 기능이 필요할 때 이 어노테이션을 사용

@AutoConfigureMockMvc

• MockMvc Autowire 제공

@TestPropertySource

• 테스트에서 사용할 properties 파일의 위치를 설정
• application.properties에 정의된 설정을 오버라이드

TestEntityManager

• TestEntityManager provided by Spring Boot is an alternative to the standard JPA EntityManager that provides methods commonly used when writing tests

@Autowired
private TestEntityManager entityManager;