서론

본 포스팅은 아래의 인강을 듣고, 추가 공부가 필요한 내용들을 포함하여 정리한 포스팅입니다.

통합 테스트 (Integration Test)

여러 모듈이 협력하는 기능을 통합적으로 검증하는 테스트로, 단위 테스트가 끝난 모듈을 통합하는 과정에서 발생하는 오류를 찾기 위한 테스트이다. 단위 테스트만으로는 기능 전체의 신뢰성을 보장할 수 없을 뿐더러, 한 Product 위에 여러 모듈이 있고, 해당 모듈들이 유기적으로 관계를 맺고 있기 때문에, 모듈들을 결합한 형태로 테스트를 수행 해봐야 한다. 그렇기에 주로 확인하는 것은 모듈 간의 상호작용이다. 모듈 사이의 인터페이스 오류는 없는지, 모듈이 올바르게 연계되어 동작하고 있는지를 체크한다.

단위 테스트와 달리 개발자가 변경할 수 없는 부분(외부 라이브러리 등)까지 묶어 검증할 때에도 사용한다.

스프링부트에서는 클래스 상단에 @SpringBootTest를 붙여 수행할 수 있다.

@SpringBootTest
class ApplicationTests {
    @Test
    void contextLoads() {
    }
}

접근 방식

하향식 (Top-Down)

• 가장 상위의 모듈부터 통합하며 테스트를 순차적으로 진행한다.
• 테스트 제어 흐름은 UI에서 시작해 DB로 끝나는 Top-Down의 이동
• 하향식 테스트를 위헤 테스트 스텁(Stub)으로 I/F 테스트 진행한다.
• 구현이 비교적 간단하고, 애플리케이션의 다른 부분에 대한 종속성이 낮다.
• 단순하고 점진적인 특성으로 인해 인터페이스 오류를 빠르게 식별할 수 있다.
• 웹 애플리케이션과, 여러 계층의 소프트웨어 아키텍처 모두에 사용 가능하다.

상향식 (Bottom-Up)

• 최하위 모듈부터 시작하여, 위쪽으로 작업하며 테스트하고 통합하는 방식이다.
• 상향식 테스트를 위해 테스트 드라이버(Driver)로 I/F 테스트 진행
• 기성 구성 요소를 기존 제품과 통합하려 할 때 일반적으로 사용된다.
• 성공률이 높고, 비교적 빠른 통합 테스트 형태이다.
• 하위 모듈을 먼저 테스트하기 때문에, 기본적인 모델이 원활하게 함께 실행되는지 확인할 수 있다.
• 마지막 테스트 드라이버가 설치될 때까지 시스템 수준 기능을 관찰하는 것이 불가능하다.

샌드위치

• 하향식과 상향식 테스트의 접근 방식을 결합한 방식이다.
• 상단, 하단, 중간 계층의 세 가지 계층으로 분리된다.
• 중간 계층에서 모듈 테스트를 시작하고, 위 아래로 진행하여 최상위 및 최하위 모듈에 우선 순위가 지정되도록 한다.
• 스텁과 드라이버 모두를 사용하여 모든 수준에서 모듈을 테스트한다.
• 테스트 시간이 길다.
• 여러 하위 프로젝트로 분리될 수 있는 대규모 프로젝트, 큰 소프트웨어 모듈을 테스트할 때 사용한다.

빅뱅 (BigBang)

• 모듈을 각각 따로 구현하고, 전체 시스템을 한번에 테스트한다.
• 테스트를 위한 드라이버와 스텁 없이, 실제 모듈들로 실행한다.
• 테스트 수행 기간이 짧다.
• 결함의 격리가 어렵다.

참조

https://www.geeksforgeeks.org/sandwich-testing-software-testing/

https://needjarvis.tistory.com/443

https://corgibytes.com/blog/2016/03/28/pyramid-of-tests/

관련 포스팅

테스트 코드를 작성하는 이유 - TestCode (1)

단위 테스트 - TestCode (2)

JUnit 5를 사용한 Java 단위 테스트 - TestCode (3)

TDD - TestCode (4)

BDD - TestCode(5)

서론

본 포스팅은 아래의 인강을 듣고, 추가 공부가 필요한 내용들을 포함하여 정리한 포스팅입니다.

BDD (Behavior Driven Development - 행위 주도 개발)

BDD는 TDD에서 파생된 개발 방법으로, TDD에서 한발 더 나아가 테스트 케이스 자체가 요구사양이 되도록 개발하는 방법이다. 함수 단위 테스트를 권장하지 않으며, 시나리오에 기반한 테스트케이스 자체에 집중하여 테스트한다. 개발자가 아닌 사람이 봐도 이해할 수 있을 정도의 레벨을 권장한다.

하나의 시나리오에는, Given When, Then 구조를 가지는 것을 기본 패턴으로 권장한다.

(Given - 데이터를 입력한 뒤, When - 실행을 하면, Then - 어떠한 결과가 나와야 한다 라는 것이다.)

해당 패턴에 대해서는 아래 포스팅을 참조하자.

https://mag1c.tistory.com/402

관련 포스팅

테스트 코드를 작성하는 이유 - TestCode (1)

단위 테스트 - TestCode (2)

JUnit 5를 사용한 Java 단위 테스트 - TestCode (3)

TDD - TestCode (4)

BDD - TestCode(5)

서론

본 포스팅은 아래의 인강을 듣고, 추가 공부가 필요한 내용들을 포함하여 정리한 포스팅입니다.

TDD(Test Driven Development - 테스트 주도 개발)

테스트 코드를 먼저 작성하여, 테스트가 구현 과정을 주도하도록 하는 방법론이다.
짧은 개발 주기의 반복에 의존하는 개발 프로세스이며, 애자일 방법론 중 하나인 XP(eXtream Programming)의 Test-First 개념에 기반을 둔 단순한 설계를 중요시한다.

XP(eXtream Programming)

미래에 대한 예측을 최대한 하지 않고 지속적으로 프로토타입을 완성하는 애자일 기방법론 중 하나로 추가 요구사항이 생기더라도 실시간으로 반영할 수 있다.

기존 방식과 비교

일반 개발 방식

일반 개발 방식은, 위의 과정을 거쳐 배포를 하게 되는데, 이러한 방식은 아래의 문제점들을 가지고 있다.

• 소비자의 요구사항이 처음부터 명확하지 않을 수 있기 때문에 처음부터 완벽한 설계가 불가능하다.
• 자체 버그 검출 능력 저하 또는 소스 코드의 품질이 저하될 수 있다.
• 테스트 비용이 증가할 수 있다.

위의 문제점들은 소프트웨어 개발의 속도를 느리게 만든다.
 
어느 프로젝트든 초기 설계가 완벽할 수는 없다. 고객의 요구사항 또는 디자인의 오류 등 많은 외부 또는 내부 조건에 의해 재설계되어 점진적으로 완벽한 설계로 나아가는데, 재설계로 인해 개발자는 코드를 삽입, 수정, 삭제하는 과정에서 불필요한 코드가 남거나 중복되는 코드를 생성할 가능성이 크다. 이러한 코드들은 재사용이 어렵고 관리가 어렵기 때문에 유지보수를 어렵게 만든다.
 
또한 작은 수정에도 모든 기능을 다시 테스트해야하는 문제가 발생하여 자체 테스트비용이 증가하게 된다.
 
 

TDD 개발 방식

 
위에서 언급한 것 처럼, TDD는 테스트 코드를 작성한 뒤 실제 코드를 작성한다. 설계 단계에서 프로그래밍 목적을 반드시 미리 정의해야만 하고, 테스트 케이스를 작성해야만 한다.
 
테스트 코드를 작성하는 도중 발생하는 예외 사항은 테스트 케이스에 추가하고 설계를 개선한다. 이후 테스트가 통과된 코드만을 코드 개발 단계에서 실제 코드로 작성한다.
 
이러한 반복적인 단계를 통해 자연스럽게 코드의 버그가 줄어들고 소스코드는 간결해진다. 또한 테스트 케이스 작성으로 인해 자연스럽게 설계가 개선됨으로써 재설계 시간이 줄어든다.
 
 

TDD 개발 사이클(주기)

• Red -실패하는 테스트 코드를 먼저 작성한다.
• Green - 테스트 코드를 성공시키기 위한 실제 코드를 작성한다.
• Blue - 중복 코드 제거, 일반화 등의 리팩토링을 수행한다.

예시

아래 예시는, TDD의 개발 사이클을 활용한 예시이다.
1. 테스트 할 코드를 먼저 작성한다.

@Test
void totalPrice(){
    Calculator calculator = new Calculator();
    Pizza pizza = new Pizza();
    Chicken chicken = new Chicken();

    calculator.add(pizza);
    calculator.add(chicken);

    int totalPrice = calculator.calculateTotalPrice();

    assertThat(totalPrice).isEqualTo(25000);
}

 
2. 구현부에서 기능 코드를 구현한다.

public int calculateTotalPrice() {
    int totalPrice = 0;
    for(Product p : products) {
    	totalPrice += p.getPrice();
    }
    return totalPrice;
}

 
3. 테스트가 성공했다면, 리팩토링을 시도한다.

public int calculateTotalPrice() {
    return beverages.stream()
                .mapToInt(Beverage::getPrice)
                .sum();
}

참조

https://younitystudy.tistory.com/58
https://hanamon.kr/tdd%EB%9E%80-%ED%85%8C%EC%8A%A4%ED%8A%B8-%EC%A3%BC%EB%8F%84-%EA%B0%9C%EB%B0%9C/

관련 포스팅

테스트 코드를 작성하는 이유 - TestCode (1)
단위 테스트 - TestCode (2)
JUnit 5를 사용한 Java 단위 테스트 - TestCode (3)
 

서론

본 포스팅은 아래의 인강을 듣고, 추가 공부가 필요한 내용들을 포함하여 정리한 포스팅입니다.

JUnit

JUnit에서 제공하는 assertEquals()와 같은 메서드는 AssertJ가 제공하는 메서드에 비해 가독성이 떨어지기 때문에, Java 애플리케이션에서 단위 테스트를 위해 JUnit5와 AssertJ를 조합하여 많이 사용한다.

• JUnit5 : 자바 단위 테스트를 돕기 위한 테스팅 프레임워크
• AssertJ : 테스트 코드 작성을 돕는 다양한 API를 지원하는 라이브러리로, 메서드 체이닝 지원

 
아래는 JUnit과 AssertJ의 공식 문서

작성 예시

아래의 Food 인터페이스를 상속받는 Pizza클래스를 만들었다.

public class Pizza implements Food{
    @Override
    public String getName() {
        return "피자";
    }

    @Override
    public int getPrice() {
        return 10000;
    }
}

class PizzaTest {

    @Test
    void getName(){
        final Pizza pizza = new Pizza();        
        assertThat(pizza.getName()).isEqualTo("피자");
    }

    @Test
    void getAge(){
        final Pizza pizza = new Pizza();        
        assertThat(pizza.getAge()).isEqualTo(10000);
    }

}

 
테스트에 성공 했다면 아래처럼 파란 체크표시가 나타난다.

Given / When / Then 패턴

단위 테스트는 given-when-then 패턴으로 작성한다. 1개의 단위 테스트를 3가지 단계로 나누어 처리하는 패턴이다.

• given(준비) : 데이터를 입력한 뒤
• when(실행) : 실행을 하면
• then(검증) : 어떠한 결과가 나와야 한다.

위의 패턴을 바탕으로 다시 위의 테스트 코드를 수정해보자.

class PizzaTest {

    @Test
    void getName(){
    	// given
        final Pizza pizza = new Pizza();
        final String chkName = "피자"
        
        // when
        final String realName = pizza.getName();
        
        // then
        assertThat(pizza.getName()).isEqualTo(realName);
        
    }

    @Test
    void getPrice(){
    	// given
        final Pizza pizza = new Pizza();
        final int chkPrice = 10000
        
        // when
        final int realPrice = pizza.getPrice();
        
        // then
        assertThat(pizza.getPrice()).isEqualTo(realPrice);
    }

}

테스트 케이스 세분화

요구사항이 실제 구현할 때의 요구사항과 정확히 일치하는지, 암묵적이거나 드러나지 않은 요구사항들이 있는지 항상 고민해야 한다. 위의 코드를 예시로 Food를 주문할 때를 생각해 보자.

• 해피 케이스 : 요구사항대로 피자를 2개 선택
• 예외 케이스 : 만약 피자를 0개, 혹은 -1개 입력했다면?

상식적으로 음식점에서, 음식을 0개나 -1개 주문하는 상황은 말이 안된다. 당연한 상식이기에 요구사항에 드러나지 않은 상황이라고 할 수 있다. 이런 상황들을 모두 고려한 테스트를 위해서 경계값 테스트가 중요하다. 여기서 경계값이란 범위, 구간, 날짜 등을 말한다.

테스트하기 어려운 영역

• 변수를 선언할 때마다 다른 값에 의존하는 코드(input) - now(), random(), 전역변수/함수, 사용자 입력 등
• 테스트 영역 외부에 영향을 주는 코드(output) - 표준 출력, 메세지 발송, 데이터베이스에 기록 등

참조

항상 너무 좋은 글을 써주시는 망나니 개발자님 (given - when - then 패턴)

관련 포스팅

테스트 코드를 작성하는 이유 - TestCode (1)
단위 테스트 - TestCode (2)

서론

본 포스팅은 아래의 인강을 듣고, 추가 공부가 필요한 내용들을 포함하여 정리한  포스팅입니다.

단위 테스트(Unit test)

단위 테스트(Unit test - 위키백과)

컴퓨터 프로그래밍에서 소스 코드의 특정 모듈이 의도된 대로 정확히 작동하는지 검증하는 절차다. 즉, 모든 함수와 메소드에 대한 테스트 케이스(Test case)를 작성하는 절차를 말한다. 이를 통해서 언제라도 코드 변경으로 인해 문제가 발생할 경우, 단시간 내에 이를 파악하고 바로 잡을 수 있도록 해준다. 이상적으로, 각 테스트 케이스는 서로 분리되어야 한다. 이를 위해 가짜 객체(Mock object)를 생성하는 것도 좋은 방법이다. 유닛 테스트는 (일반적인 테스트와 달리) 개발자(developer) 뿐만 아니라 보다 더 심도있는 테스트를 위해 테스터(tester)에 의해 수행되기도 한다.

단위 테스트(Unit Test)는 하나의 모듈을 기준으로 독립적으로 진행되는 가장 작은 단위의 테스트를 말하며, 여기서의 모듈은 App에서 작동하는 하나의 기능( ≒ Class) 또는 메서드라 말할 수 있는 작은 코드 단위이다.
 
 

단위 테스트의 이유

아래의 이유들 때문에 단위 테스트를 실무에서 선호하며, 테스트 코드를 수시로 빠르게 돌리면서 문제를 파악할 수 있다.
TDD(Test Driven Development - 테스트 주도 개발) 또한 단위 테스트를 의미한다.

• 하나의 기능, 또는 메서드 부분만 독립적으로 테스트할 수 있어, 문제의 빠른 파악이 가능하다.
• 테스트를 진행하는 데 있어 시간과 비용을 절감할 수 있다.
• 리팩토링 시 안정성을 확보할 수 있다.
• 코드에 대한 문서가 될 수 있다.

단위 테스트의 규칙(First)

• Fast : 테스트는 빠르게 동작하여 자주 돌릴 수 있어야 한다.
• Independent : 각각의 테스트는 독립적이며 서로 의존해서는 안된다.
• Repeatable : 어느 환경에서도 반복이 가능해야 한다.
• Self-Validationg : 테스트는 성공 또는 실패로 bool 값으로 자체적으로 검증되어야 한다.
• Timely : 테스트는 테스트하려는 실제 코드를 구현하기 직전에 구현해야 한다.

 
또한 테스트를 작성 시에는 아래 사항들을 준수하는 것이 좋다.

실제 코드가 변경되면 테스트 코드 역시 변경이 필요할 수 있기 때문에 테스트 코드를 가독성 있게 작성해야 한다.
1개의 테스트 함수에 대해 assert를 최소화해야 한다.
1개의 테스트 함수는 1가지 개념만 테스트해야 한다.

Stub

일반적으로, App의 1개의 기능을 처리하기 위해서는, 다른 객체들과 메세지를 주고 받아야 한다. 하지만 단위 테스트는 해당 모듈에 대한 독립적인 테스트를 진행해야 한다. 그렇기 때문에 가짜 객체(Mock Object)를 주입하여 return값을 지정해주어야 하는데, 이를 stub라고 한다.

참조

관련 포스팅

단위 테스트 - TestCode (2)

서론

개발자로서, 꼭 테스트에 대한 공부를 수행하여 단위테스트 부터 시작하여 점진적으로 테스트하는 습관을 반드시 가져야겠다고 생각을 하고 있었고, 마침 즐겨 보는 유튜브에서 강의를 추천받아 수강하고, 해당 내용들을 정리하고, 사용해보며 테스트코드를 잘 작성하는 개발자로 성장해나가기 위해 인강을 정리하는 포스팅이다
 
개발바닥 유튜브를 시청하고 있다가, 꼭 학습해보고자 하는 테스트 관련 강의를 오픈한다고 하셔서 수강하기로 마음먹었다.
 

테스트코드의 사용

직접 테스트

Production Code를 개발한 개발자, 혹은 어떤 테스터가 직접 테스트를 수행한다고 가정해보자.
 
1. 만든 기능을 어떤 테스터(사람)이 직접 테스트를 한다. 기능이 1개일 때는 무리없이 수행할 수 있다.

 
 
2. 기존 기능 코드와 전혀 상관 없는 다른 코드가 App에 추가되었다. 또 다른 누군가가 테스트를 수행한다.

 
 
3. 또 새로운 기능이 추가되었다. 이번에는, 1번에서 만들었던 기존 코드와 겹치는 모듈을 사용한다고 가정해보자.
1번 기능에 겹쳐있는 기능이 새로 개발됐기 때문에, 신규로 추가한 3번 기능도 테스트 해야하지만, 1번 기능을 다시 테스트하여 1번 기능이 정상수행 되는지 또 테스트를 수행해야 한다.

 
 
코드들은 점점 확장되어 나갈 것이다. Product의 Production Code들이 Product가 개발됨에 따라 무수히 많은 코드들이 생성될 것이다.

직접 테스트의 한계

그렇다면, 확장되는 코드들에 대응해 테스트 인력을 어떻게 추가할 것인가?
그 전에, 근본적으로 사람은 실수를 할 수 있는 가능성을 지니고 있다. 테스터의 실수로 테스트가 통과되었다고 가정해보면, 해당 Product의 치명적인 결함이 될 수도 있다.
 

사람이 테스트를 했을 때의 문제점

1. 소프트웨어가 커지는 속도를 사람이 따라잡을 수 없게 된다.
2. 기능이 겹치면서 기존 테스트를 진행했던 내용들을 또 테스트를 해야한다.
3. 피드백이 늦어진다. (테스트 요청에 대한 응답을 직접 보내주어야 한다.)
4. 테스터의 경험과 감에 의존할 확률이 높아진다.

이런 문제점들은 소프트웨어의 신뢰도를 낮추게 된다.

 
그렇기 때문에 위의 문제점들을 보완할 수 있는 테스트코드의 작성이 필요하다.

빠른 피드백을 통한 오류 수정, 기계가 검증할 수 있도록 자동화하여 테스트 진행
→ 소프트웨어의 신뢰성, 안정성 향상

테스트 코드를 사용하지 않는다면

우선 새로운 기능이 추가되거나, 변경될 때 마다 발생할 수 있는 모든 상황을 고려해야 한다.
또한 개발자 A가 했던 생각을, B, C, D등 모든 팀원들이 같은 고민을 해야한다. 이는 업무의 효율성을 낮춘다.
또한 근본적으로 소프트웨어의 안정성을 보장할 수 없을 것이다.
 
 
 

잘못된 테스트 코드의 문제점

잘못된 검증이 이루어질 가능성이 생기며 이는 기능 코드의 안전성을 제공하기 힘들어지는 치명적인 문제가 발생한다. 또한 테스트 코드를 통해 업무 효율성을 향상시키려고 했지만 테스트 코드 자체가 유지보수하기 어려운 새로운 숙제가 된다.
 
 
 

올바른 테스트 코드의 장점

그렇다면 올바른 테스트 코드를 작성했을 때의 장점은 무엇이 있을까?
 
첫번째 장점으로, 자동화된 테스트로 직접 테스트보다, 빠른 시간안에 버그를 발견하고, 비용을 크게 절약할 수 있다. 또한 빠른 시간안에 버그를 발견하고, 픽스할 수 있기 때문에 제품의 빠른 변화를 지원한다.
 
또한 해당 기능을 만들며 했던 고민들을 녹여내어 작성한 테스트 코드를 다른 팀원들이 같이 공유할 수 있다. 이는 타 팀원들이 테스트 코드를 통해, 어떤 테스트들이 필요하며, 어떤 케이스들이 있는지 직접 고민하지 않아도 빠르게 파악할 수 있으다. 이는 업무 효율이 상승한다.
 
가까이 보면 느리지만, 멀리 보면 가장 빠르고 좋은 길이다. 테스트 코드를 작성하는 것은 귀찮고, 기능 구현과 테스트 코드 두 가지를 짜야하기 때문에, 업무 수행 속도가 느리게 보일 수 있다. 하지만 기능 코드가 쌓여가고, 테스트 코드가 쌓여가다보면 해당 프로젝트 내의 업무 효율성이 올라갈 수 밖에 없다.

관련 포스팅