테스트 주도 개발(TDD)이란 무엇입니까? 예

테스트 주도 개발(TDD)이란 무엇입니까?

테스트 주도 개발(TDD) 코드가 수행할 작업을 지정하고 검증하기 위해 테스트 케이스를 개발하는 소프트웨어 개발 접근 방식입니다. 간단히 말해서 각 기능에 대한 테스트 케이스를 먼저 만들고 테스트한 다음 테스트가 실패하면 테스트를 통과하고 코드를 단순하고 버그 없는 코드로 만들기 위해 새 코드를 작성합니다.

테스트 주도 개발은 애플리케이션의 모든 작은 기능에 대한 테스트를 설계하고 개발하는 것부터 시작됩니다. TDD 프레임워크는 자동화된 테스트가 실패한 경우에만 개발자에게 새 코드를 작성하도록 지시합니다. 이렇게 하면 코드 중복이 방지됩니다. TDD 전체 형식은 테스트 중심 개발입니다.

TDD의 간단한 개념은 새로운 코드를 작성하기 전(개발 전)에 실패한 테스트를 작성하고 수정하는 것입니다. 이는 테스트를 통과하기 위해 한 번에 소량의 코드를 작성하므로 코드 중복을 피하는 데 도움이 됩니다. (테스트는 테스트를 수행하기 위해 테스트해야 하는 요구 사항 조건일 뿐입니다.)

테스트 주도 개발(Test-Driven Development)은 실제 애플리케이션 개발에 앞서 자동화된 테스트를 개발하고 실행하는 프로세스입니다. 따라서 TDD는 때때로 TDD라고도 불립니다. 테스트 우선 개발.

TDD 테스트 수행 방법

다음 단계는 TDD 테스트를 수행하는 방법을 정의합니다.

테스트를 추가합니다.
모든 테스트를 실행하고 새로운 테스트가 실패하는지 확인합니다.
코드를 작성하십시오.
테스트 및 리팩터링 코드를 실행합니다.
반복.

TDD 주기는 다음과 같이 정의합니다.

테스트 작성
실행해 보세요.
코드를 올바르게 변경하십시오(예: 리팩터링).
과정을 반복합니다.

TDD에 대한 몇 가지 설명:

TDD 접근 방식은 "테스트"나 "디자인"에 관한 것이 아닙니다.
TDD는 "일부 테스트를 작성한 다음 테스트를 통과하는 시스템을 구축하는 것"을 의미하지 않습니다.
TDD는 "많은 테스트를 수행하라"는 뜻이 아닙니다.

TDD 대. 전통적인 테스트

다음은 테스트 중심 개발과 기존 테스트의 주요 차이점입니다.

TDD 접근법은 기본적으로 사양 기술입니다. 소스 코드가 확인 수준에서 철저히 테스트되도록 보장합니다.

기존 테스트를 사용하면 성공적인 테스트를 통해 하나 이상의 결함이 발견됩니다. TDD와 동일합니다. 테스트가 실패하면 문제를 해결해야 한다는 것을 알기 때문에 진전을 이룬 것입니다.
TDD는 시스템이 정의된 요구 사항을 실제로 충족하는지 확인합니다. 이는 시스템에 대한 자신감을 키우는 데 도움이 됩니다.
TDD에서는 테스트가 제대로 작동하는지 확인하는 프로덕션 코드에 더 중점을 둡니다. 기존 테스트에서는 테스트 케이스 디자인에 더 중점을 둡니다. 테스트에서 요구 사항을 충족하기 위해 애플리케이션의 적절한/부적절한 실행을 보여줄지 여부.
TDD에서는 100% 커버리지 테스트를 달성합니다. 기존 테스트와 달리 모든 코드 줄이 테스트됩니다.
전통적인 테스트와 TDD의 결합은 시스템의 완벽함보다는 시스템 테스트의 중요성으로 이어집니다.
In 민첩한 모델링(AM), "목적을 가지고 테스트"해야 합니다. 무언가를 테스트하는 이유와 테스트해야 할 수준이 무엇인지 알아야 합니다.

수용 TDD와 개발자 TDD란 무엇입니까?

TDD에는 두 가지 수준이 있습니다.

TDD(ATDD) 승인: ATDD를 사용하면 단일 승인 테스트를 작성합니다. 이 테스트는 사양 요구 사항을 충족하거나 시스템 동작을 만족합니다. 그런 다음 해당 승인 테스트를 수행하기에 충분한 생산/기능 코드를 작성하십시오. 승인 테스트는 시스템의 전반적인 동작에 중점을 둡니다. ATDD는 다음과 같이 알려져 있습니다. 행동 주도 개발(BDD).
개발자 TDD: 개발자 TDD를 사용하면 단일 개발자 테스트, 즉 단위 테스트를 작성한 다음 해당 테스트를 수행하기에 충분한 프로덕션 코드를 작성합니다. 단위 테스트는 시스템의 모든 작은 기능에 중점을 둡니다. 개발자 TDD는 간단히 다음과 같이 호출됩니다. TDD.ATDD 및 TDD의 주요 목표는 JIT(Just In Time) 기반으로 솔루션에 대한 상세하고 실행 가능한 요구 사항을 지정하는 것입니다. JIT는 시스템에 필요한 요구 사항만 고려하는 것을 의미합니다. 따라서 효율성을 높이십시오.

AMDD(Agile Model Driven Development)를 통한 TDD 확장

TDD는 상세한 사양과 검증에 매우 능숙합니다. 전반적인 디자인, 시스템 사용 또는 UI와 같은 더 큰 문제를 생각하는 데 실패합니다. AMDD는 TDD가 해결하지 못하는 Agile 확장 문제를 해결합니다.

따라서 AMDD는 더 큰 문제에 사용되었습니다.

AMDD의 수명주기

MDD(모델 중심 개발)에서는 소스 코드가 작성되기 전에 광범위한 모델이 생성됩니다. 민첩한 접근 방식은 어느 것입니까?

위 그림에서 각 상자는 개발 활동을 나타냅니다.

구상은 프로젝트 첫 주에 수행될 테스트를 예측/상상하는 TDD 프로세스 중 하나입니다. 구상의 주요 목표는 시스템의 범위와 시스템 아키텍처를 식별하는 것입니다. 성공적인 구상을 위해 상위 수준 요구 사항과 아키텍처 모델링이 수행됩니다.

소프트웨어/시스템의 세부 스펙을 작성하는 것이 아니라, 소프트웨어/시스템의 요구사항을 탐색하여 프로젝트의 전반적인 전략을 정의하는 프로세스입니다.

반복 0: 구상

두 가지 주요 하위 활성화가 있습니다.

초기 요구사항 구상.시스템의 높은 수준의 요구 사항과 범위를 식별하는 데 며칠이 걸릴 수 있습니다. 주요 초점은 사용 모델, 초기 도메인 모델 및 사용자 인터페이스 모델(UI)을 탐색하는 것입니다.
처음의 Archi구조적 구상. 또한 시스템 아키텍처를 식별하는 데 며칠이 걸립니다. 이를 통해 프로젝트에 대한 기술적 방향을 설정할 수 있습니다. 주요 초점은 기술 다이어그램, 사용자 인터페이스(UI) 흐름, 도메인 모델 및 변경 사례를 탐색하는 것입니다.

반복 모델링

여기서 팀은 각 반복에 대해 수행할 작업을 계획해야 합니다.

각 반복마다 Agile 프로세스가 사용됩니다. 즉, 각 반복 중에 새 작업 항목이 우선적으로 추가됩니다.
우선 순위가 높은 작업이 먼저 고려됩니다. 추가된 작업 항목은 언제든지 항목 스택에서 우선순위를 다시 지정하거나 제거할 수 있습니다.
팀에서는 각 요구 사항을 어떻게 구현할 것인지 논의합니다. 모델링은 이러한 목적으로 사용됩니다.
해당 반복을 위해 구현할 각 요구 사항에 대해 모델링 분석 및 설계가 수행됩니다.

모델폭풍

이는 적시 모델링(Just in time Modeling)이라고도 합니다.

여기서 모델링 세션에는 종이나 화이트보드에서 문제를 논의하는 2/3의 구성원으로 구성된 팀이 포함됩니다.
한 팀원은 다른 팀원에게 함께 모델을 만들어 달라고 요청할 것입니다. 이 모델링 세션은 약 5~10분 정도 소요됩니다. 팀원들이 함께 모여 화이트보드/종이를 공유하는 곳입니다.
그들은 문제의 주요 원인을 찾지 못할 때까지 문제를 탐구합니다. 적시에 한 팀원이 해결하고 싶은 문제를 식별하면 다른 팀원의 빠른 도움을 받을 것입니다.
그런 다음 다른 그룹 구성원이 문제를 탐색하고 모두가 이전과 같이 계속합니다. 스탠드업 모델링 또는 고객 QA 세션이라고도 합니다.

테스트 주도 개발(TDD)

이는 애플리케이션 코드와 자세한 사양에 대한 확인 테스트를 촉진합니다.
승인 테스트(세부 요구사항)와 개발자 테스트(단위 테스트)는 모두 TDD의 입력입니다.
TDD는 코드를 더 간단하고 명확하게 만듭니다. 이를 통해 개발자는 더 적은 수의 문서를 유지 관리할 수 있습니다.

후기

이는 선택 사항입니다. 여기에는 코드 검사와 모델 검토가 포함됩니다.
이는 각 반복 또는 전체 프로젝트에 대해 수행할 수 있습니다.
이는 프로젝트에 대한 피드백을 제공하는 좋은 옵션입니다.

테스트 주도 개발(TDD)과 민첩한 모델 중심 개발(AMDD)

TDD	AMDD
TDD는 프로그래밍 피드백 루프를 단축합니다.	AMDD는 모델링 피드백 루프를 단축합니다.
TDD는 세부 사양입니다.	AMDD는 더 큰 문제를 해결합니다.
TDD는 고품질 코드 개발을 촉진합니다	AMDD는 이해관계자 및 개발자와의 고품질 커뮤니케이션을 장려합니다.
TDD는 프로그래머에게 말합니다.	AMDD와 대화 비즈니스 분석가, 이해 관계자 및 데이터 전문가.
TDD 비시각 지향적	AMDD 시각적 지향
TDD는 소프트웨어 작업으로 범위가 제한되어 있습니다.	AMDD는 이해관계자를 포함하여 광범위한 범위를 가지고 있습니다. 이는 공통된 이해를 향해 노력하는 것을 포함합니다.
둘 다 진화적 발전을 지원합니다	---------------

TDD 프레임워크

최고의 테스트 중심 개발(TDD) 프레임워크 목록은 다음과 같습니다.

주닛
TestNG
csUnit 및 NUnit
알스펙

이제 예제를 통해 테스트 주도 개발(Test Driven Development)을 배워보겠습니다.

TDD의 예

여기 이 테스트 주도 개발 예제에서, 우리는 클래스 비밀번호를 정의할 것입니다. 이 클래스에 대해, 우리는 다음 조건을 만족시키려고 노력할 것입니다.

비밀번호 수락 조건:

비밀번호는 5~10자 사이여야 합니다.

먼저 이 TDD 예제에서는 위의 모든 요구 사항을 충족하는 코드를 작성합니다.

시나리오 1: 테스트를 실행하기 위해 PasswordValidator() 클래스를 생성합니다.

TestPassword() 클래스 위에서 실행하겠습니다.

출력은 아래와 같이 PASSED입니다.

산출:

시나리오 2: 여기에서 TestPasswordLength() 메소드에서 PasswordValidator 클래스의 인스턴스를 생성할 필요가 없다는 것을 알 수 있습니다. 인스턴스는 생성을 의미합니다. 대상 해당 클래스의 멤버(변수/메서드)를 참조하는 클래스입니다.

코드에서 PasswordValidator pv = new PasswordValidator() 클래스를 제거하겠습니다. 우리는 isValid () 직접 방법 비밀번호 유효성 검사기. IsValid("Abc123"). (아래 이미지 참조)

그래서 우리는 아래와 같이 리팩터링(코드 변경)합니다:

시나리오 3: 리팩토링 후 출력이 실패 상태를 표시합니다(아래 이미지 참조). 이는 인스턴스를 제거했기 때문입니다. 따라서 비정적 메서드에 대한 참조가 없습니다. isValid()입니다.

따라서 Boolean 앞에 public static boolean isValid(문자열 비밀번호)로 "정적" 단어를 추가하여 이 방법을 변경해야 합니다. 테스트를 통과하려면 위의 오류를 제거하기 위해 클래스 PasswordValidator()를 리팩터링합니다.

출력:

PassValidator() 클래스를 변경한 후 테스트를 실행하면 출력은 아래와 같이 PASSED가 됩니다.

TDD의 장점

소프트웨어 엔지니어링에서 테스트 주도 개발의 주요 장점은 다음과 같습니다.

조기 버그 알림.

개발자는 코드를 테스트하지만 데이터베이스 세계에서는 수동 테스트나 일회성 스크립트로 구성되는 경우가 많습니다. TDD를 사용하면 시간이 지남에 따라 귀하와 다른 개발자가 마음대로 다시 실행할 수 있는 자동화된 테스트 모음을 구축할 수 있습니다.

더 나은 디자인, 더 깨끗하고 확장 가능한 코드.

코드가 어떻게 사용되는지, 다른 모듈과 어떻게 상호 작용하는지 이해하는 데 도움이 됩니다.
그 결과 더 나은 디자인 결정이 가능하고 코드 유지 관리가 더 쉬워졌습니다.
TDD를 사용하면 여러 책임이 있는 모놀리식 프로시저 대신 단일 책임을 갖는 더 작은 코드를 작성할 수 있습니다. 이렇게 하면 코드를 더 쉽게 이해할 수 있습니다.
또한 TDD는 사용자 요구 사항에 따라 테스트를 통과하기 위해 프로덕션 코드만 작성하도록 강제합니다.

리팩토링에 대한 자신감

코드를 리팩터링하는 경우 코드가 중단될 가능성이 있습니다. 따라서 일련의 자동화된 테스트를 사용하면 출시 전에 이러한 중단 사항을 수정할 수 있습니다. 자동화된 테스트를 사용할 때 중단이 발견되면 적절한 경고가 제공됩니다.
TDD를 사용하면 최소한의 위험으로 업데이트할 수 있는 버그가 적고 더 빠르고 확장 가능한 코드가 생성됩니다.

팀워크에 좋다

팀원이 없으면 다른 팀원이 쉽게 코드를 가져와서 작업할 수 있습니다. 또한 지식 공유에 도움이 되어 팀 전체의 효율성이 향상됩니다.

개발자에게 좋음

개발자는 TDD 테스트 사례를 작성하는 데 더 많은 시간을 투자해야 하지만, 새로운 기능을 디버깅하고 개발하는 데는 훨씬 적은 시간이 걸립니다. 더 깔끔하고 덜 복잡한 코드를 작성하게 됩니다.

제품 개요

TDD는 테스트 중심 개발을 의미합니다.
TDD 의미: 이전에 설계된 테스트를 통과하기 위해 코드를 수정하는 프로세스입니다.
테스트 케이스 디자인보다는 프로덕션 코드에 더 중점을 둡니다.
테스트 주도 개발은 이전에 설계된 테스트를 통과하기 위해 코드를 수정하는 프로세스입니다.
In 소프트웨어 공학, 때로는 다음과 같이 알려져 있습니다. “테스트 우선 개발.”
TDD 테스트에는 코드 리팩토링, 즉 코드 동작에 영향을 주지 않고 기존 코드에 일정량의 코드를 변경/추가하는 작업이 포함됩니다.
TDD 프로그래밍을 사용하면 코드가 더 명확해지고 이해하기 쉬워집니다.

테스트 주도 개발(TDD)이란 무엇입니까? 예

테스트 주도 개발(TDD)이란 무엇입니까?