실제로 테스트 첫 번째 방식으로 BDD / TDD를 수행해야합니까?

11

TDD 또는 BDD 프로젝트에 참여하지 않았거나 TDD를 수행하고 있다고 말하는 사람들이 있지만 그와는 거리가 멀지 만 생각할 수 있고 가능한 한 많이 읽으려고합니다. 약.

질문으로 돌아 가기 BDD를 할 때는 먼저 "테스트"를 작성하여 실패해야합니까? 그런 다음 해당 기능 또는 호출 한 기능을 구현하십시오. 그러나 이것을 극단적으로 가져 가면 일종의 하향식 개발이 될 수 없습니까? UI를보고 "이 기능 / 여기를 여기에 갖고 싶습니다"라고 말합니다. 그런 다음 UI를 수정하여 해당 기능과 UI를 지원하는 코드를 구현하십시오. 이 시점에서 비즈니스 로직 또는 데이터 액세스 로직을 구현하지 않았으며 방금 동작을 구현했습니다. 먼저 테스트를 작성하는 대신 내가 목표로하는 것은 UI 코드를 먼저 작성하는 것입니다. UI 코드를 사용하여 비즈니스에서 지원해야하는 것을 정의하므로 데이터 액세스 및 비즈니스 계층에 동일한 코드가 생성되는 경우도 있습니다.

물론 기능이 기능에서 제대로 작동하는지 확인하는 데 사용되는 테스트로이를 보완해야합니다.

이견있는 사람?

unit-testing tdd

— 토마스 얀손
소스

TDD 테스트는 별도의 테스트를 수행하는 것처럼 모듈을 직접 구동하는 유닛 테스트 main입니다. 하향식 주석에서 기능 테스트에 대해 이야기하고 있습니다. 기능 테스트는 단일 프로그램을 통해 전체 프로그램을 실행합니다 main.

— Macneil

@ Macneil : 전체 프로그램을 테스트하는 기능 테스트에 대해서는 이야기하지 않으며 프로그램을 구현 / 디자인한다고 생각하더라도 모든 공개 코드에 대해 단위 테스트를 구현해야합니다. 위에서 아래로 수행한다고해서 다른 레이어를 추상적으로 만들 수 없으므로 모든 레이어를 자체적으로 분리 할 수 없습니다.

— Tomas Jansson

1

@Macneil : 이것은 일반적인 오해입니다. TDD 테스트는 단위 테스트가 아닙니다 . TDD 는 스케일이 설정되지 않은 기능을 테스트 합니다 .

— Steven A. Lowe

2

그러나 정해진 규모가 있습니다. 테스트는 TDD에서 빠르게 실행되어야합니다. TDD의 범위를 벗어나는 테스트도 수행해야합니다. 전반적으로 TDD는 테스트 계획이 아닌 개발 계획입니다.

— Macneil

@Macneil : "빠른"은 상대적인 용어입니다. 마지막 프로젝트의 테스트 스위트는 약 30 분 안에 실행됩니다. 8 시간 의 수동 테스트를 대체합니다 . 그것은 "빨리"충분하다!

— Steven A. Lowe

8

UI 테스트의 높은 수준의 관점에서 BDD에 대해 이야기하고 있습니다. 자바 스크립트 / 서버 사이드 코드에서 테스트하는 것보다이 레벨에서 테스트가 약간 더 모호합니다.

TDD에서 읽은 몇 권의 책은 기본 시스템이 존재하는 것처럼 코드를 작성하고 테스트에 통과 할 수있을 정도로 작성해야한다고 말합니다. UI 행동 테스트를 통과하기 위해 서버에 스텁을 작성할 수 있습니다. 그런 다음이 스텁 솔기에서 시작하여 서버 측 코드에 대한 몇 가지 단위 테스트를 작성하고 완전한 구현으로 진행하십시오.

나는 기본 레이어가 존재하는 것처럼 종종 높은 수준의 테스트를 통과하도록 코딩하고, 토끼 구멍을 내려 가고 높은 수준의 테스트를 만족시키기 위해 다른 많은 클래스를 추출하여 낮은 수준의 테스트를 작성하는 것처럼 느낍니다. 이미 인식 했으므로 더 높은 수준의 테스트를 시작하는 데 집중할 수 있습니다.

노련한 프로그래머가 알고 있듯이 소프트웨어 개발에는 많은 계층이 있습니다. 나는 UI보다 작업이 적고 서버에서 UI가 필요로하는 데이터 또는 동작에 대해 생각하고 시작합니다 (요즘 UI 작업이 많지 않기 때문에).

정말 정직하다면 기본 레이어에서 클래스를 추출한다는 것은 먼저 테스트를 수행하지 않지만 몇 분 또는 몇 시간 내에 해당 코드에 대한 테스트를 수행한다는 의미입니다. 클래스에 대한 종속성을 제공하고 단일 책임 원칙을 준수해야 할 위치를 확인하는 데 도움이되므로 여전히 도움이됩니다. 테스트하기 어려운 경우 한곳에서 너무 많은 일을하고 있습니다.

— 그렉 케이
소스

그 쪽이 맞는 거 같아요. 이번 여름에 루비 온 레일을 시험해 보았을 때 UI를 구동하는 bdd 테스트가있어 나중에 기본 클래스의 구현을 유도합니다.

— Tomas Jansson

17

예! 그렇지 않으면, 당신이 얻는 것은 개발 주도 테스트 입니다.

그러나 실제로는 "순수한"TDD를 사용하여 접근하기 어려운 문제가 있습니다. 발견되지 않은 프로덕션 코드를 미리 작성하고 나중에 테스트로 덮음으로써 (그리고 나중에 TDD와 유사한 문제에 접근하는 방법을 배우면) 생산성을 높일 수 있습니다. 저자 가 더 나은 용어를 원하기 위해 헹굼 및 반복 TDD 라고하는 이 기술을 살펴보십시오 .

— 아 zhe 글 로프
소스

3

첫 번째 줄은 굉장합니다.

— EpsilonVector

TDD와 비교할 때 사실이지만 하향식을 수행하는 것은 BDD와 잘 맞아야합니다. GUI를보고 원하는 동작을 지정합니다. "동작 테스트"를 바로 작성하지는 않지만 UI를 구현하기 전에 UI를 통해 동작을 지정했습니다.

— Tomas Jansson

15

테스트를 먼저 작성하지 않으면 테스트를 통해 개발을 추진하지 않습니다. Ergo, 당신은 테스트 중심 개발을하고 있지 않습니다!

— 프랭크 시어
소스

TDD가 아닌 BDD를 수행 할 때 테스트를 먼저 작성해야하는지에 대한 질문은 공정하지 않습니까?

— bytedev

"테스트"를 "행동"으로 자유롭게 대체하십시오. TDD와 BDD 사이에는 큰 차이가 있다는 사실을 설득 할만한 것을 보지 못했습니다. 집중 해 그러나 핵심 아이디어? 별로.

— Frank Shearar

테스트 주도 개발을하고 있지 않다는 사실에 동의하지 마십시오. 핵심 용어의 정의에 따라하지는 않지만 코드 테스트를 개발하는 한 코드 작성 시점에 관계없이 테스트에 의해 코드가 구동됩니다.

— 대안

TDD는 특히 코드 전에 테스트를 작성하는 것을 의미합니다. 마음에 들지 않으면 용어를 발명 한 Kent Beck에게 맡기십시오. 코드를 작성한 후 테스트를 작성 하면 코드가 어느 정도 구동 될 수 있지만 그렇지 않은 경우 테스트를 통해 코드 디자인을 추진하고 있다고 자신을 속일 수 있습니다. 테스트 되지 않은 코드 를 자주 변경해야하기 때문에 이러한 테스트를 작성하기가 더 어렵습니다 . 너무 자주 언급했습니다.

— Frank Shearar

@ FrankShearar 나는 Kent Beck의 말에 따르면 TDD가 아니라는 것을 인정했지만 솔직히 나는 임의의 사람이 말한 것에 신경 쓰지 않습니다. 테스트를 먼저 작성하지 않고도 테스트를 통해 코드 디자인을 구동 할 수 있습니다.

— 대안

4

이런 식으로 일하고 싶다면 가십시오. 그러나 테스트 중심 개발은 아닙니다.

— 돈 로비
소스

3

설명하는 내용은 Front-Ahead Design 방식 과 매우 비슷합니다 . 불행히도 Front-Ahead Design은 민첩한 방법으로 Alex Papadimoulis의 풍자적 찌르기입니다.

— 사용자 281377
소스

풍자적 찌르기를 해제하면서 FAD에서 싸우는 기사를 알고 있는지 궁금합니다.

— CL22

3

개인적으로 저는 디자인 단계에서의 테스트에 대해 생각하는 것이 중요하다고 생각합니다. 실제로 구현하는 것은 훌륭하지만 작동하는 제품을 가지고 있는지 확인할 수있는 유일한 방법은 조각으로 테스트 한 것입니다. 이를 다루는 방법은 단위 테스트와 숙련 된 QA 팀이 협력하여 협력하는 것입니다.

이제이 분야를 팀에 설치하는 방법은 전적으로 귀하에게 달려 있습니다. TDD는 그러한 전략 중 하나이며 다른 전략도 있습니다. 그러나 TDD는 UI 레이아웃 개발에 특히 적합하지 않습니다.

— 마이클 쇼
소스