개발 방법론

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

정의

• 해석 그대로 테스트행위가 주도하여 개발되는 행위 입니다.
  어떤 요구사항에 대해서 또는 필요한 기능에 있어서 먼저 기능을 개발을 하는 것이 아니라 기능개발에 대한 테스트코드를 먼저 작성하고, 테스트가 성공하면 작성된 테스트크 케이스 기반으로 기능을 개발합니다. 그래서 테스트 주도 개발, TDD라고 불립니다.

• 테스트 주도 개발을 하기 위해서는 테스트-코드-리팩토링 과정이라는 3단계를 걸치게 됩니다. 필요한 기능개발에 대해서 3단계의 사이클로 반복하며 개선합니다.
  

Write a failing Test

• 필요한 기능 개발에 필요한 테스트 코드를 작성합니다.
• 테스트 코드는 실패하는 테스트 코드이여만 합니다. 실패한 테스트 코드는 기능이 아직 완성되지 않았음을 의미 합니다.

Make test pass

• 필요한 기능 개발 테스트 케이스에 대해서 통과하도록 개발합니다.

Refactoring

• 통과한 테스트 코드에 대해서 개선할 여지가 보인다면 개선합니다.

장점

1. 휴먼에러
사람이라는 존재는 완벽한 존재가 아니기 때문에 항상 꼭 나도 모르게 실수를 하게 됩니다. 실수를 방지하기 위해 테스트 케이스를 잘 작성해 놓는 다면 실수를 방지 할 것 입니다. 또한 기존 코드의 변화가 있을때 마다 일일이 기능을 눌러서 검증하기 보다는 자동화된 테스트 코드로 검증한다면 쉽게 오류를 찾거나 검증 할 수 있습니다.

2. 유연한 기능추가
기능을 추가할때 마다 다른코드에 영향을 끼치는지 파악을 해야합니다. 만약에 자동화된 테스트가 없다면 수동으로 일일이 눌러서 오류를 찾아야 합니다. 하지만 자동화된 테스트가 구축되어 있다면 쉽게 오류를 찾거나 검증 할 수 있습니다.

3. 개발자용 문서화
지속적으로 빠르게 변하는 요구사항에 대해서 문서를 따로 작성하면 좋치만 관리하기도 힘들고 따로 시간을 들여야 하지만 비지니스 요구사항을 테스트 케이스로 작성한다면 새로참여하는 개발자가 와서도 빠르게 업무를 이해하는데 도움이 됩니다.

4. CI/CD를 통한 프로세서 자동화
Jenkins를 통하여 거의 모든 프로세스가 자동화로 움직입니다. 이런 환경에서 개발자가 테스트 케이스를 작성하지 않고 배포가 된다면 휴먼에러가 언제 어떻게 터질지 모르는 폭탄을 배포하는 것과 같습니다.

단점

1. 기능개발에 대한 시간
TDD룰 기반으로 기능 개발을 하면 테스트 케이스를 먼저 작성하고 통과 시키고 리팩토링까지 끝난 후에 기능개발이 시작됩니다.
테스트 케이스를 작성하는 부분에 있어서 많은 시간과 노력이 필요합니다.
2. 고민
TDD를 수행하다보면 자연스럽게 리팩토링을 하게 되고 객체지향적인 코드가 탄생이 됩니다. 하지만 TDD를 수행하다보면 테스트케이스 작성과 구조적인 설계에 대해서 수많은 고민과 노력이 필요할 것입니다.

3. 러닝커브
TDD를 평소에 수행하지 않은 사람이 TDD를 수행하기 위해서는 많은 지식과 방법을 익혀야 합니다.

DDD(Domain Driven Desion) - 도메인 주도개발

• 도메인 주도 개발은 MAS와 함께 설명되어야 하는 개념으로 신규 시리즈로 더 자세희 설명하겠습니다.

정의

• 비지니스 Domain별로 나누어 설계하는 개발 방법론이다.

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

정의

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

기본 패턴

• Feature: 테스트에 대상의 기능/책임을 명시한다.
• Scenario: 테스트 목적에 대한 상황을 설명한다.
• Given: 시나리오 진행에 필요한 값을 설정한다.
• When: 시나리오를 진행하는데 필요한 조건을 명시한다.
• Then: 시나리오를 완료했을 때 보장해야 하는 결과를 명시 한다.