상사는 TDD를 인정하지 않을 것입니다: 이 행동 중심 개발 사례를 시도해 보십시오.

테스트. 종종 마지막 순간까지 남겨진 다음 시간이 부족하거나 예산 초과 등으로 인해 중단됩니다.

경영진은 왜 개발자가 "처음부터 제대로 만들 수" 없는지 의아해하며, 다른 이해 관계자가 시스템의 다른 부분을 설명할 때 개발자(특히 대규모 시스템의 경우)는 방심할 수 있습니다. 코끼리.

그러나 모든 프로젝트의 첫 번째 단계는 구축할 소프트웨어 또는 기능의 동작에 대한 토론인 것은 불가피합니다. 클라이언트 또는 비즈니스 담당자가 개발 팀의 누군가에게 다가가 원하는 것을 설명합니다.

때때로 이러한 상호 작용은 Agile 사용자 스토리의 형태로 제공됩니다. 작년 Chris Fox의 블로그 항목에서와 같이 때때로 디자인 문서의 형태로 제공됩니다. 또한 Keynote의 순서도나 모형, 또는 급한 전화 통화로 제공될 수도 있습니다.

이러한 커뮤니케이션만으로도 개발자는 "정상 작동하는" 시스템을 구축할 책임이 있습니다. 이는 대규모 시스템 외부에서 일하는 프리랜서에게 특히 어렵습니다.

테스트가 중단되는 이유는 무엇입니까?

여기에는 분명한 차이가 있습니다. 비즈니스 소유자가 처음에 시스템의 동작을 구상했다면 이러한 동작이 실제로 작동 하는지 테스트하는 것이 왜 종종 중단되는 단계입니까?

대답은 무지하게 간단할 수 있습니다. 테스트는 종종 공유 자본 으로 간주되지 않습니다. 그들은 프로젝트에 가치가 있는 것으로 생각되지 않습니다. "그들은 엔지니어를 위한 것"이거나 유사하게 단일 부서나 사람들 그룹에 가치를 제공하기 때문입니다.

이 공유 자본, 이 시스템 동작 목록을 테스트하려면 어떻게 해야 합니까? 테스트 주도 개발(TDD)뿐만 아니라 행동 주도 개발(BDD)을 수용합니다.

BDD 란 무엇입니까?

행동 중심 개발은 코드가 구현하는 비즈니스 행동, 즉 코드 이면의 "이유" 에 초점을 맞춰야 합니다. 팀 중심(특히 교차 기능) 워크플로를 지원합니다.

개발자와 Agile 제품 소유자 또는 비즈니스 분석가가 함께 앉아서 일반 텍스트 편집기에서 보류 중인 사양(개발자가 나중에 채울 예정)을 작성할 때 Agile BDD가 정말 잘 작동하는 것을 보았습니다.

1. 비즈니스 담당자 는 시스템에서 보고 싶은 행동을 지정합니다.
2. 개발자 는 시스템에 대한 이해를 바탕으로 질문을 하고 개발 관점에서 필요한 추가 동작을 기록합니다.

이상적으로는 양 당사자가 현재 시스템 동작 목록을 참조하여 이 새로운 기능이 기존 기능을 중단하는지 확인할 수 있습니다.

이 간단한 행동이 개발자처럼 생각할 수 있는 충분한 제약을 제공한다는 것을 알았습니다. "이러한 테스트를 구현해야 하는 경우 저/모든 사람이 코드로 구현할 수 있는 사양으로 어떻게 제한됩니까?" 사양이 보류 중이므로 공동 작업이 많은 경우 빠르고 쉽게 작성할 수 있습니다.

이 협업 접근 방식을 통해 최종 사용자에게 기능이 제공하는 것에 집중할 수 있으며 비즈니스 담당자가 바로 거기에 있으면 구현이 아니라 행동에 대해 이야기할 수 있습니다. 이것은 BDD와 TDD의 차이점을 강조합니다.

행동 주도 개발의 예를 살펴보겠습니다.

시나리오: 귀하는 Rails로 구현된 회사 회계 시스템을 담당하는 팀의 개발자입니다. 어느 날 한 비즈니스 담당자가 고객에게 보류 중인 송장을 상기시키는 알림 시스템을 구현해 달라고 요청합니다. 이 튜토리얼에 따라 BDD를 연습하고 있기 때문입니다. (TDD 대), 그 비즈니스 사람과 함께 앉아서 행동을 정의하기 시작합니다.

텍스트 편집기를 열고 비즈니스 사용자가 원하는 동작에 대해 보류 중인 사양을 만들기 시작합니다.

 it "adds a reminder date when an invoice is created" it "sends an email to the invoice's account's primary contact after the reminder date has passed" it "marks that the user has read the email in the invoice"

개발 중 동작에 초점을 맞추면 코드가 올바른지 뿐만 아니라 올바른 기능을 빌드하고 있는지 확인하는 데 테스트가 유용합니다. 문구는 시스템의 내부 구현 언어가 아니라 비즈니스 언어로 되어 있습니다. 인보이스가 계정에 belongs_to 있다는 것을 보거나 신경 쓰지 않습니다. 개발 팀 외부의 누구도 그것에 대해 신경 쓰지 않기 때문입니다.

일부 개발자는 다음과 같이 시스템에서 메서드를 호출하고 기대치를 설정하여 그 자리에서 테스트 케이스를 작성하는 것을 선호합니다.

 it "adds a reminder date when an invoice is created" do current_invoice = create :invoice current_invoice.reminder_date.should == 20.days.from_now end

아직 reminder_date 을 설정하는 코드를 작성하지 않았기 때문에 테스트 스위트는 실패할 것입니다.

실패한 사양 비교

나는 실패한 사양을 작성하는 개발자를 이해하지만 내 옆에 비즈니스 사람과 함께 이것은 나를 위해 일한 적이 없습니다. 잘못된 비즈니스 담당자는 세부 사항에 주의가 산만해지거나 이 새로운 지식을 가지고 개발자가 더 많이 알고 있는 사항(적절한 데이터베이스 디자인, 코드 재사용)을 세세하게 관리하려고 할 것입니다.

내 경험에 따르면 특정 행동에 대한 한 줄 이상의 개요를 작성하는 것은 비즈니스 사람을 지루하게 할 것입니다. 그들은 그것을 시간을 잘 사용하지 않는 것으로 간주하거나 마음속에 있는 동안 다음 행동을 설명하는 데 불안해할 것입니다.

BDD는 TDD와 어떻게 다릅니까?

테스트 주도 개발 접근 방식을 사용하여 이를 다른 방식으로 살펴보고 보류 중인 테스트를 작성해 보겠습니다.

 it "after_create an Invoice sets a reminder date to be creation + 20 business days" it "Account#primary_payment_contact returns the current payment contact or the client project manager" it "InvoiceChecker#mailer finds invoices that are overdue and sends the email"

이 테스트는 도움이 되지만 엔지니어라는 한 그룹의 사람들에게만 도움이 됩니다. BDD는 다기능 제품 팀의 모든 구성원과 의사 소통하는 데 유용합니다.

보류 중인 동작을 사용하여 BDD 사고 방식에서 테스트 우선 개발을 확실히 수행할 수 있습니다. 먼저 테스트를 작성하십시오. 그런 다음 실행하십시오(빨간색). 그런 다음 작동시키십시오(녹색). 그런 다음 올바르게 만드십시오(리팩터링).

BDD 커뮤니티의 많은 작업은 테스트 내부의 주장 검사를 영어처럼 읽도록 만들기 위해 진행되었습니다. 다음은 전형적인 RSpec 테스트입니다.

 a = 42 a.should == 42

이 형식을 사용하면 나중에 더 쉽게 읽을 수 있습니다. 그러나 이것은 우리가 여기서 하는 일이 아님을 기억하십시오. 요점은 가능한 한 빨리 동작을 낮추고 '사양당 하나의 테스트된 동작' 원칙 을 시행하는 것입니다. 이상적으로는 보류 중인 사양 제목이 테스트 중인 내용을 알려야 합니다.

BDD는 결과를 검증하는 멋진 방법에 관한 것이 아닙니다. 팀의 모든 구성원이 예상되는 행동을 공유하는 것입니다.

행동 중심 개발은 협업 및 커뮤니케이션에 관한 것입니다.

회사 회계 시스템 작업이라는 시나리오로 돌아가 보겠습니다.

비즈니스 담당자와 함께 항목의 기능을 살펴보고 내부를 통해 시스템을 분석하고(객체가 내부적으로 어떻게 결합되는지) 외부에서 시스템을 분석합니다.

몇 가지 조건을 생각하고 비즈니스 분석가에게 다음 시나리오에서 어떤 일이 발생하는지 물어보십시오.

 * What's the default reminder date going to be? How many days before the invoice due date? * Are those business days or just calendar days? * What happens if there's not a primary contact associated with the account?

그리고 답 을 얻습니다. 비즈니스 사람은 당신이 그들의 애완동물 아이디어에 구멍을 뚫으려 하거나 지나치게 현학적인 것이 아니라는 점을 이해하는 것이 중요합니다.

이러한 방식으로 행동 주도 개발은 협업을 지원하고 두 부서 간의 대화를 시작하는 도구입니다. 또한 원하는 기능의 범위를 명확히 하고 개발 팀에서 더 나은 평가를 받는 방법이기도 합니다. 특정 시점에서 영업일 기준 10일을 계산할 수 있는 방법이 없다는 것을 알고 계실 것입니다. 이는 구현해야 하는 별도의 추가 기능입니다.

개발자는 개발자 고려 사항("당신이 말하는 '날'이 정확히 무엇을 의미합니까?")이 있는 반면 비즈니스 사람들은 나름대로 고려 사항이 있습니다("여기서 기한이 지난 용어를 사용하지 마십시오. 다른 의미입니다."). 한 그룹 또는 다른 그룹이 나가서 이러한 비즈니스 논리 동작 테스트를 자체적으로 작성하려고 하면(Cucumber의 약속) 양쪽의 귀중한 입력이 차단됩니다.

또한 Agile Client가 더 이상 물리적으로 방에 있지 않을 때 좋은 대안이 됩니다. 즉, 구축 중인 항목에 대한 개발자 분석(및 번역)과 함께 그들의 욕구를 종이에 기록하는 것입니다.

디자인 문서

이전 Toptal 블로그 게시물 Chris Fox는 특히 프로젝트 초기에 디자인 문서에 대해 이야기했습니다. 비즈니스 행동을 이해하고 추출하는 것은 시스템을 어느 정도 알 수 있는 프로젝트에서 수십 년의 프로그래머가 필요하고 수백 또는 수천 개의 행동 사양을 갖는 프로젝트로 축소됩니다.

Chris의 기사는 또한 요소의 화면상의 동작에 대해 언급하며, 이것은 디자이너와 끊임없이 의견이 엇갈리는 영역입니다. 이 페이지는 분명히 24인치 화면용으로 설계되었나요?" 비즈니스 담당자와 이 대화를 통해 프로젝트의 그래픽 자산이나 페이지 레이아웃에서 공백을 찾을 수 있습니다.

매우 큰 규모의 교차 기능 팀에는 디자이너, 개발자, 잠재적으로 운영 담당자, 데이터베이스 관리자, 아마도 QA 담당자(예, TDD 및 BDD에 모두를 위한 자리가 있습니다!) 자신의 관심사와 질문으로. BDD는 테스트 주도 개발보다 이러한 협업을 더 많이 추진할 수 있습니다. "데이터가 이 테이블에 비해 너무 크면 어떻게 됩니까?"에서 "음, 비용이 많이 드는 쿼리가 될 것입니다. 어떻게든 캐시하고 싶습니다.", "잠깐만, 사용자가 해당 기밀 정보를 모두 볼 수 있어야 하나요?", 개발자 및 이 새로운 기능에 대한 질문이 있는 비즈니스 분석가

행동 중심 개발은 공유 아티팩트에 관한 것입니다.

공유 아티팩트란 무엇입니까?

저는 소프트웨어 엔지니어링의 "아티팩트"를 프로젝트 또는 프로젝트 팀을 설명하고 6개월 후에 찾을 수 있는 잠재적으로 물리적인 것으로 생각하는 것을 좋아합니다. 좋은 유물은 사물이 있는 그대로의 이유를 설명합니다.

복도 대화는 인공물이 아닙니다. 화이트보드 그림도 아닙니다. 크고 긴 수업 문서 또는 설계 문서로 바뀌는 화이트보드 도면은 아티팩트입니다. 회의록도 인공물입니다.

아티팩트는 저장소나 공유 공간에 저장된 일부 소스 코드, 티켓 시스템의 티켓, 내부 Wiki의 메모 또는 영구적인 채팅 로그입니다.

내 생각에 공유 인공물은 최고의 인공물 입니다. 그것들은 어떤 것이 있는 그대로의 이유 뿐만 아니라 그것이 앱 에 존재하는 이유를 보여줍니다.

BDD에서 어떻게 사용합니까?

동작은 공유된 팀 결과물이어야 합니다. 테스트는 프로그래머에게만 바쁜 작업이 되어서는 안 됩니다! 전체 팀이 현재 사양을 쉽게 볼 수 있는 시스템을 갖는 것이 가장 좋지만(아마도 배포 시스템은 동작 목록을 추출하여 사이트나 위키의 비공개 영역에 저장함), 매 시간마다 수동으로 수행할 수도 있습니다. 스프린트.

게임의 이름은 "개발자가 비즈니스 가치를 더 빠르게 제공하고, 부서 간 협업을 수행하고, 더 나은 견적을 내리는 데 필요한 사양을 만들 수 있도록 지원"입니다.

시스템 이 하는 일에 대한 이러한 전사적 이해도 일종의 자본입니다. 코드의 "방법"에 대한 "왜"입니다.

결론

버그가 있는 소프트웨어가 고객에게 전달되는 문제를 어떻게 해결합니까? 테스트가 "개발자만 관심 있는" 것으로 간주되지 않도록 합니다.

시스템의 요구 사항을 설명하고 이해하는 것은 코드 정확성을 넘어 많은 이점이 있습니다. 부서 간 대화를 설정하고 모든 이해 관계자의 관심사가 충족되었는지 확인합니다(큰 호칭을 가진 이해 관계자뿐만 아니라). 행동 중심 개발을 사용하여 시작부터 이러한 요구 사항을 이해하고 전체 팀이 관심을 갖는 외부 비즈니스 행동을 테스트 하는 것은 양질의 프로젝트를 보장하는 좋은 방법입니다.