Mock Object를 이용한 테스트 (행위기반의 테스트 케이스)

Mock Object는 어떤 한 부분을 대신하는 가짜 객체이다. 대부분 모듈이 가진 의존성에 의해 Mock Object를 사용하는 주요 원인이며, 아래와 같은 경우에 사용하게 된다.

1. 특정 환경을 구축하는데 많은 시간이 소요되는 경우 (메일 서버 연동을 위하여 DB 및 모듈 설치 등의 많은 작업이 소요 되는 경우)
2. 특정 모듈을 사용하기 위한 여건이 부족한 경우 (미구현된 모듈 및 버그 모듈등)
3. 타 시스템과의 연계되는 모듈 (타 시스템의 요청 결과에 따라 움직이는 모듈의 경우)
4. 특정 상황을 만족해야만 사용 가능한 모듈 (인쇄 실패시 처리 모듈등)
5. 테스트 시간 단축을 위하여 사용 (네트워크 간 연동 모듈 테스트시 접속하는데 시간이 많이 소요 되는 경우)

1. Dummy Object : 인스턴스화 될 수 있을 정도로만 구현한 객체 (기능 사용X) , 메소드를 사용하지 않는 객체
2. Test Stub :  Dummy Object각 실제로 동작하는 것처럼 보이게 만든 객체로, 메소드를 호출하면 동작을 하긴 하나 반환은 기본값을 반환하게끔 구성, 인스턴스화 + 상태를 표현하는 경우에 해당됨, 객체의 특정 상태를 가정해서 만들어 놓은 단순 구현체, 하드 코딩되어 있기 때문에 로직이 들어가는 부분은 테스트 할 수 없다.
3. Fake Object : 여러개의 인스턴스를 대표하는 경우 혹은 구현이 들어가는 경우 (DB 조회 결과를 반환하는 Fake Object는 실제 DB를 조회 하지 않으나 가상의 테이터를 생성하여 반환하도록 구성)
4. Test Spy : 테스트에 사용되는 객체에 대해서 호출여부를 감시하거나 정보를 주기 위한 목적의 객체

참고 URL:

http://egloos.zum.com/kingori/v/4169398

참고 : https://surpreem.com/%EC%9E%85%EB%AC%B8-%EA%B5%AC%EA%B8%80-c-%ED%85%8C%EC%8A%A4%ED%8A%B8-%ED%94%84%EB%A0%88%EC%9E%84%EC%9B%8C%ED%81%AC-%EC%8B%9C%EC%9E%91%ED%95%98%EA%B8%B0/

"소프트웨어 개발 생명주기를 검토한 후, 공학 설계의 기준을 실제로 만족시킬 유일한 소프트웨어 문서는 소스 코드 목록뿐임을 알 수 있었다" - 잭 리브스 (Jack Reeves)

일련의 UML 다이어그램이 설계의 일부를 나타낼 수는 있지만 설계 자체는 아니다. 소프트웨어 프로젝트의 설계는 추상적인 개념으로, 구체적인 각 모듈, 클래스, 메소드의 형태와 구조뿐만 아니라 프로그램의 전체 형태와 구조와도 관련되어 있다. 이것은 다양한 매체로 표현될 수 있지만, 최종적인 구현은 소스 코드가 되고 이것이 결국 바로 설계다

대부분의 소프트웨어 프로젝트에서 가장 변덕스러운 요소는 바로 요구사항이다. 요구사항은 끊임없이 변화한다. 우리는 변하는 요구사항의 세계에 살고 있고, 우리가 만든 소프트웨어가 이런 변화 속에서 살아남을 수 있게 만드는 것이 바로 우리가 해야 하는 일이다.

애자일 팀은 개방 폐쇄 원칙(OCP : Open-Closed Principle)을 따른다. 이 원칙은 프로그래머가 모듈을 수정하지 않고도 설계를 확장하도록 이끈다.

애자일 개발자는 설계는 가능한 한 적절하고 명료한 상태로 유지하기 위해 애쓴다. 몇 주마다 한 번씩 설계를 Clean up 하지 않는다. 매일, 매시간, 심지어 분마다 소프트웨어를 가능한 명료하고, 간단하고, 표현적인 상태로 유지한다. 절대 부패가 시작되도록 놔두지 않는다.

▒ 애자일 설계의 패턴 (SOLID)

1) 단일 책임의 원칙 (SRP : Single-Responsibility Principle)

한 클래스는 단 한 가지의 변경 이유만을 가져야 한다.

한 클래스가 하나 이상의 책임을 맡는다면, 그 클래스를 변경할 하나 이상의 이유가 있을 것이다. 만약 한 클래스가 하나 이상의 책임을 맡는다면, 그 책임들은 경합이 되고, 한 책임에 대한 변경은 다른 책임을 충족시키는 클래스의 능력을 떨어뜨리거나 저하시킬 수도 있다. 이런 종류의 결합은 변경을 했을 대 예상치 못한 방식으로 잘못 동작하는 취약한 설계를 유발한다.

<SRP 위반>

위 그림에서 Rectangle Class는 직사각형 모양의 수학적 모델 제공과 그래픽 사용자 인터페이스에 직사각형을 그리는 2가지의 책임을 맡고 있음으로 SRP를 위반한다.

그러면 '책임' 이란 무엇인가?

책임을 '변경을 위한 이유'로 정의한다. 만약 한 클래스를 변경하기 위한 한 가지 이상의 이유를 생각할 수 있다면, 그 클래스는 한가지 이상의 책임을 맡고 있는 것이다.

2) 개방 폐쇄 원칙 (OCP : Open-Closed Principle)

소프트웨어 개체 (클래스, 모듈, 함수등)는 확장에 열려 있어야 하고, 수정에 대해서는 닫혀 있어야 한다.

프로그램 한 군데를 변경한 것이 의존적인 모듈에서 단계적인 변경을 불러일으킬 때, 이 설계는 경직성의 악취를 풍긴다. OCP에서는 시스템을 리팩토링하여 나중에 일어날 그와 같은 종류의 변경이 더 이상 수정을 유발하지 않도록 하라고 충고한다. OCP가 잘 적용된다면, 이미 제대로 동작하고 있던 원래 코드를 변경하는 것이 아니라 새로운 코드를 덧붙임으로써 나중에 그런 변경을 할 수 있게 된다.

OCP 원칙의 해결책은 추상화다.

그렇다고 애플리케이션의 모든 부분에 마구 추상화를 적용하는 것도 좋은 생각이 아니다. 프로그램에서 자주 변경되는 부분에만 추상화를 적용하기 위한 개발자의 헌신이 필요하다. 어설픈 추상화를 피하는 일은 추상화 자체만큼이나 중요하다.

3) 리스코프 치환 원칙 (LSP : Liskov Substitution Principle)

서브타입(subtype)은 그것의 기반 타입(base type)으로 치환 가능해야 한다.

OCP는 OOD를 위해 논의된 수많은 의견 중에서도 핵심이다. 이 원칙이 효력을 가질 때, 애플리케이션은 좀 더 유지보수 가능하고, 재사용 가능하고, 견고해진다. LSP는 OCP를 가능하게 하는 주요 요인 중 하나다. 이것은 기반 타입으로 표현된 모듈을 수정 없이도 확장 가능하게 만드는, 서브 타입의 치환 가능성을 말한다.

4) 단일 책임의 원칙 (SRP : Single-Responsibility Principle)

한 클래

5) 단일 책임의 원칙 (SRP : Single-Responsibility Principle)

한 클래