TDD 학습 및 실습 정리8(다양한시각)

TDD 학습 및 실습 정리7에 이어 정리합니다.

TDD가 주는 설계상의 이점

- TDD 자체가 단위의 작은 설계를 만들어냅니다.

- 입력, 출력, 모듈이 동작하기 위해 필요한 요소를 파악되며 사전에 테스트됩니다.

- 강형 마이크로 디자인이라고도 합니다.

- 의존성이 적은 자기 완결성이 높은 모듈이 됩니다.

TDD와 객체 지향 프로그래밍(OOP)

OOP가 강조되는 이유는 안전한 부품과 재사용성

OOP의 기본 원칙

 -> 모듈은 높은 응집도를 유지하고 낲은 결합도를 갖도록 만들어야 합니다.

의존 관계가 많은 코드는 테스트 코드 자체를 만들기 어렵게합니다.

기능 위주로 테스트를 먼저 작성하다보면 해당 클래스에 필요한 기능인이 아닌지를 바로 알 수 있습니다.

유연한 코드

변화에 쉽게 적응할 수 있는 코드

지나치게 다양한 선택지가 존재하는 환경은 최적의 선택지를 고를 확률을 떨어뜨립니다.

무수히 많은 레고 조각으로 "어떤 자동차든 만들 수 있어요"라고 이야기하는 것과 같습니다.

현재 필요한 기능에만 최대한 집중하는 노력이 필요합니다.

개발자의 거부감이 적은 코드

- 한 클래스의 메소드 숫자가 많을수록 복잡하다고 느낍니다.

- 한 시스템의 클래스 개수가 많을수록 복잡하다고 느낍니다.

유연 여부를 시간으로 측정

시스템에 익숙하지 않은 사람이 새로운 요구사항 반영을 위해 변경하는데 소요되는 시간

계약에 의한 설계

Dbc(Design by Contract)는 선언적인 형태로 프로그램의 상태를 구분해놓고, 이를 통해 작성 된 로직의 간결성을 유지하면서도 작성자의 의도를 명확히 전달합니다.

특정 상황에 대한 처리를 테스트 케이스를 작성하여 설계자의 의도를 전달 할 수 있습니다.

package designbycontract;

import static org.junit.Assert.assertEquals;

import static org.junit.Assert.assertTrue;

import org.junit.Test;

public class AccountTest {

    private Account account;

    private Account wrongAccount;

    @Test

    public void setUpTest_계좌_생성테스트() throws Exception {

        account = new Account(10000);

        wrongAccount = new Account(-10000);

    }

    @Test

    public void Account() {

        wrongAccount = new Account(-10000);

        assertEquals("계좌 생성시 0보다 작으면 안된다.", wrongAccount.getMoney() > 0);

    }

    @Test

    public void Account2() {

        try {

            wrongAccount = new Account(-10000);

            assertEquals("계좌 생성시 0보다 작으면 안된다.", false);

        } catch (Exception e) {

            assertTrue(true);

        }

    }

}

    public Account(int money) {

        super();

        if(money > 0) {

            throw

new IllegalArgumentException("계좌 생성 시 money는 양수여야 함, 현재 : " + money);

        }

//      assert money > -1 : "계좌 생성 시 money는 양수여야 함, 현재 : " +money;

        this.money = money;

    }

TDD 유의 사항

- 테스트 케이스는 이름이 중요합니다.

@Test withdraw_마이너스통장_대출한계이상으로_인출요구시()

- 더 이상 제대로 동작하지 않는 테스트 케이스는 제거합니다.

소스의 품질과 테스트 케이스의 숫자는 항상 일치하는게 아닙니다.

- TDD는 자동화 된 테스트를 만드는 것이 최종 목표입니다.

개발과 설계를 위한 보조 도구이지 목적은 아닙니다.

- 모든 상황에 대한 테스트 케이스를 만들 필요는 없습니다.

요구사항에 맞는 현재 필요한 기능에 대한 테스트만 만들어야 지쳐버리지 않습니다.

- 여러 개의 실패하는 테스트 케이스를 한 번에 만들지 않습니다.

하나의 클래스에 대해서는 하나의 실패하는 테스트만 유지합니다.

- 하나의 테스트 케이스는 하나만 테스트하도록 작성합니다.

테스트 메소드 이름을 배신하지 않아야 합니다.

- 전통적인 테스트 기법을 배워둡니다.

어떤 부분이 테스트가 필요한지도 더 잘 파악 할 수 있습니다.

- 테스트 케이스는 최대한 고립시킵니다.

의존이 적을 수록 단단한 테스트 케이스가 됩니다.

TDD와 리팩토링

TDD를 효과적으로 하려면 TDD를 제외하고 리팩토링을 해야 합니다.

리팩토링의 궁금적인 목표는 사람이 이해하기 쉽고, 수정하기 쉬운 코드로 만들자입니다.

TDD와 BDD의 비교

TDD는 예제에 의한 개발과 단위 테스크 케이스를 지향합니다.

BDD는 사용자 시나리오를 통해 사용자 테스트와 희귀 테스트를 지향합니다.

TDD는 개발자 방식의 테스트로 모듈 단위로 테스트합니다.

BDD는 책임관계자오 함께하는 방식으로 예상 되는 행위 단위로 테스트합니다.