เจ้านายของคุณจะไม่ชื่นชม TDD: ลองตัวอย่างการพัฒนาที่ขับเคลื่อนด้วยพฤติกรรมนี้

การทดสอบ มักจะถูกทิ้งไว้จนนาทีสุดท้าย แล้วตัดทิ้งเพราะคุณไม่มีเวลา ใช้งบประมาณเกิน หรืออะไรก็ตาม

ผู้บริหารสงสัยว่าทำไมนักพัฒนาไม่สามารถ "ทำให้ถูกต้องในครั้งแรก" ได้ และนักพัฒนา (โดยเฉพาะในระบบขนาดใหญ่) อาจถูกมองข้ามเมื่อผู้มีส่วนได้ส่วนเสียต่างๆ อธิบายส่วนต่างๆ ของระบบ เช่น เรื่องราวของชายตาบอดที่บรรยายถึง ช้าง.

อย่างไรก็ตาม หลีกเลี่ยงไม่ได้ที่ขั้นตอนแรกในทุกโครงการคือการอภิปรายเกี่ยวกับพฤติกรรมของซอฟต์แวร์หรือคุณลักษณะที่จะสร้างขึ้น ลูกค้าหรือนักธุรกิจเข้ามาหาใครบางคนในทีมพัฒนาและอธิบายสิ่งที่พวกเขาต้องการ

บางครั้งการโต้ตอบเหล่านี้มาในรูปแบบของเรื่องราวของผู้ใช้ Agile บางครั้งมาในรูปแบบของเอกสารการออกแบบ เช่นเดียวกับบล็อกของ Chris Fox เมื่อปีที่แล้ว พวกเขายังอาจมาเป็นแผนผังลำดับงานหรือแบบจำลองใน Keynote หรือแม้แต่การโทรแบบด่วนก็ได้

จากการสื่อสารเหล่านี้เพียงอย่างเดียว นักพัฒนาต้องรับผิดชอบในการสร้างระบบที่ “ใช้งานได้” นี่เป็นเรื่องยากโดยเฉพาะอย่างยิ่งสำหรับ freelancer ที่ทำงานนอกระบบที่ใหญ่กว่า

ทำไมการทดสอบถึงถูกตัดออก?

มีช่องว่างที่ชัดเจน: หากเจ้าของธุรกิจมองเห็นพฤติกรรมของระบบตั้งแต่เริ่มต้น เหตุใดการทดสอบว่าพฤติกรรมเหล่านี้มักได้ ผล จริงจึงเป็นขั้นตอนที่ถูกตัดออก

คำตอบอาจดูธรรมดามาก: การทดสอบมักไม่ถูกมองว่าเป็น ทุนที่ใช้ร่วมกัน พวกเขาไม่ได้ถูกมองว่ามีคุณค่าต่อโครงการ เพราะ "พวกเขามีไว้สำหรับวิศวกรเท่านั้น" หรือในทำนองเดียวกัน ให้คุณค่าแก่แผนกหรือกลุ่มคนเพียงกลุ่มเดียว

เราจะทำการทดสอบทุนที่ใช้ร่วมกันนี้ รายการพฤติกรรมของระบบนี้ได้อย่างไร โดยไม่เพียงแต่รองรับการพัฒนาที่ขับเคลื่อนด้วยการทดสอบ (TDD) แต่ยังรวมถึงการพัฒนาที่ขับเคลื่อนด้วยพฤติกรรม (BDD)

BDD คืออะไร?

การพัฒนาที่ขับเคลื่อนด้วยพฤติกรรมควรเน้นที่พฤติกรรมทางธุรกิจที่โค้ดของคุณกำลังนำไปใช้: "สาเหตุ" ที่อยู่เบื้องหลังโค้ด สนับสนุนเวิร์กโฟลว์ที่เน้นทีม (โดยเฉพาะข้ามสายงาน)

ฉันเคยเห็น BDD ที่คล่องแคล่วทำงานได้ดีมากเมื่อนักพัฒนาและทั้งเจ้าของผลิตภัณฑ์ Agile หรือนักวิเคราะห์ธุรกิจนั่งลงด้วยกันและเขียนข้อกำหนดที่รอดำเนินการ (นักพัฒนาจะกรอกในภายหลัง) ในโปรแกรมแก้ไขข้อความธรรมดา:

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

ข้อกำหนดที่ล้มเหลวของ Vis-a-vis

ฉันเข้าใจนักพัฒนาที่เขียนข้อกำหนดที่ล้มเหลว แต่ด้วยนักธุรกิจที่อยู่เคียงข้างฉัน สิ่งนี้ไม่เคยได้ผลสำหรับฉัน นักธุรกิจที่ไม่ถูกต้องอาจถูกรบกวนจากรายละเอียดหรือนำความรู้ใหม่นี้ไปใช้และพยายามจัดการสิ่งต่าง ๆ ที่นักพัฒนาซอฟต์แวร์รู้มากขึ้น (การออกแบบฐานข้อมูลที่เหมาะสม การใช้รหัสซ้ำ)

จากประสบการณ์ของผม การเขียนภาพรวมมากกว่าหนึ่งบรรทัดของพฤติกรรมเฉพาะจะทำให้นักธุรกิจเบื่อ พวกเขาจะมองว่าเป็นการใช้เวลาที่ไม่ดีหรือรู้สึกกระวนกระวายที่จะอธิบายพฤติกรรมต่อไปในขณะที่ยังนึกถึงอยู่

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 ผ่านการใช้พฤติกรรมที่รอดำเนินการ ขั้นแรก เขียนแบบทดสอบ จากนั้นเรียกใช้ (สีแดง); แล้วทำให้มันทำงาน (สีเขียว); แล้วทำให้ถูกต้อง (refactor)

งานมากมายในชุมชน 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 วันทำการจากจุดที่กำหนดในเวลา ซึ่งเป็นคุณลักษณะเพิ่มเติมที่แยกต่างหากซึ่งคุณจะต้องนำไปใช้

นักพัฒนาจะต้องคำนึงถึงข้อพิจารณาของนักพัฒนา (“คุณหมายถึงอะไรเมื่อคุณพูดว่า 'วัน'?”) ในขณะที่นักธุรกิจจะมีข้อพิจารณาของตนเอง (“โปรดอย่าใช้คำว่าค้างชำระที่นี่ นั่นหมายถึงสิ่งที่แตกต่างไปจากนี้”) การมีกลุ่มใดกลุ่มหนึ่งออกไปและพยายามเขียนการทดสอบพฤติกรรมเชิงตรรกะทางธุรกิจเหล่านี้ด้วยตนเอง (คำสัญญาของแตงกวา) จะตัดข้อมูลที่มีค่าของแต่ละฝ่ายออกไป

นอกจากนี้ยังเป็นการยืนหยัดที่ดีเมื่อ Agile Client ไม่อยู่ในห้องอีกต่อไป: มีความปรารถนาบนกระดาษ ผสมผสานกับการวิเคราะห์ของนักพัฒนา (และการแปล) ของสิ่งที่คุณกำลังสร้าง

ออกแบบเอกสาร

โพสต์บนบล็อกของ Toptal ก่อนหน้านี้ Chris Fox พูดถึงเอกสารการออกแบบ โดยเฉพาะอย่างยิ่งในช่วงเริ่มต้นของโครงการ การทำความเข้าใจและการแยกพฤติกรรมทางธุรกิจจะลดขนาดลงจากโครงการที่ระบบค่อนข้างจะรู้จัก ไปจนถึงโครงการที่ต้องใช้เวลาหลายสิบปีของโปรแกรมเมอร์ในการบรรลุผลและมีข้อกำหนดด้านพฤติกรรมนับร้อยหรือหลายพัน

บทความของ Chris ยังกล่าวถึงพฤติกรรมบนหน้าจอขององค์ประกอบต่างๆ และนี่คือพื้นที่ที่ฉันมักจะขัดแย้งกับนักออกแบบอยู่เสมอ: “ปุ่มนี้มีลักษณะอย่างไรเมื่อมันมืด” หรือ “สิ่งนี้ดูเป็นอย่างไรในหน้าจอ 11” เพราะ หน้านี้ออกแบบมาสำหรับหน้าจอ 24” อย่างชัดเจน?” การกลับไปกลับมานี้กับนักธุรกิจสามารถค้นหาช่องว่างในเนื้อหากราฟิกของโครงการหรือเลย์เอาต์ของเพจได้

ในทีมข้ามสายงานที่มีขนาดใหญ่มาก มีสมาชิกในทีมจำนวนมากที่มีข้อกังวลของตนเอง: นักออกแบบ นักพัฒนา ผู้ที่มีแนวโน้มว่าจะมาจากฝ่ายปฏิบัติการ ผู้ดูแลระบบฐานข้อมูล บางทีอาจเป็นคน QA (ใช่ มีที่สำหรับทุกคนใน TDD และ BDD!) แต่ละคน ด้วยความกังวลและคำถามของตนเอง BDD สามารถขับเคลื่อนการทำงานร่วมกันนี้ได้มากกว่าการพัฒนาที่ขับเคลื่อนด้วยการทดสอบ จาก “จะเกิดอะไรขึ้นเมื่อข้อมูลมีขนาดใหญ่เกินไปสำหรับตารางนี้” กับ "อืม นั่นเป็นคำถามราคาแพง เราจะต้องแคชข้อมูลนั้น" กับ "เดี๋ยวนะ ผู้ใช้ควรเห็น ข้อมูล ที่เป็นความลับทั้งหมดนั้นไหม" อาจมีความเสี่ยงมากกว่าแค่นักพัฒนาซอฟต์แวร์และ นักวิเคราะห์ธุรกิจที่มีคำถามเกี่ยวกับคุณสมบัติใหม่นี้

การพัฒนาที่ขับเคลื่อนด้วยพฤติกรรมเป็นเรื่องเกี่ยวกับสิ่งประดิษฐ์ที่ใช้ร่วมกัน

สิ่งประดิษฐ์ที่ใช้ร่วมกันคืออะไร?

ฉันชอบคิดว่า "สิ่งประดิษฐ์" ในงานวิศวกรรมซอฟต์แวร์เป็นสิ่งที่มีอยู่จริงที่อธิบายโครงการหรือทีมงานโครงการ และสิ่งที่สามารถค้นหาได้ในอีกหกเดือนข้างหน้า สิ่งประดิษฐ์ที่ดีจะอธิบายว่าทำไมสิ่งต่าง ๆ จึงเป็นเช่นนั้น

บทสนทนาในห้องโถงไม่ใช่สิ่งประดิษฐ์ ไม่ใช่ภาพวาดไวท์บอร์ด ภาพวาดบนกระดานไวท์บอร์ดที่เปลี่ยนเป็นเอกสารประกอบการเรียนขนาดใหญ่หรือเอกสารการออกแบบ สิ่งเหล่านี้ คือสิ่งประดิษฐ์ รายงานการประชุมถือเป็นสิ่งประดิษฐ์เช่นกัน

สิ่งประดิษฐ์คือซอร์สโค้ดบางส่วนที่บันทึกไว้ในที่เก็บหรือพื้นที่ที่ใช้ร่วมกัน และตั๋วในระบบตั๋ว หรือบันทึกใน Wiki ภายใน หรือแม้แต่บันทึกการแชทแบบถาวร

สิ่งประดิษฐ์ที่ใช้ร่วมกันเป็นสิ่งประดิษฐ์ที่ดีที่สุด ในใจของฉัน พวกเขาแสดงไม่เพียงแค่ ว่าทำไม บางสิ่งถึงเป็นอย่างที่เป็น แต่ทำไมมันถึงมีอยู่ในแอพ เลย

คุณใช้พวกเขาใน BDD อย่างไร?

พฤติกรรมควรเป็นสิ่งประดิษฐ์ของทีมที่ใช้ร่วมกัน การทดสอบไม่ควรจะเป็นงานยุ่งสำหรับโปรแกรมเมอร์เท่านั้น! แม้ว่าจะดีที่สุดที่จะมีระบบที่ทั้งทีมสามารถดูข้อกำหนดปัจจุบันได้อย่างง่ายดาย (บางทีระบบการปรับใช้อาจแยกและบันทึกรายการพฤติกรรมไปยังพื้นที่ส่วนตัวของไซต์หรือวิกิ) คุณยังสามารถทำด้วยตนเองทุกๆ วิ่ง.

ชื่อของเกมคือ “ช่วยนักพัฒนาสร้างข้อกำหนดที่เราจำเป็นต้องใช้เพื่อส่งมอบมูลค่าทางธุรกิจได้เร็วขึ้น ทำงานร่วมกันระหว่างแผนก และประเมินผลได้ดีขึ้น”

ความเข้าใจทั่วทั้งบริษัทเกี่ยวกับสิ่งที่ระบบ ทำ อยู่นี้ก็คือรูปแบบของทุนเช่นกัน มันคือ "ทำไม" ถึง "อย่างไร" ของรหัส

บทสรุป

เราจะแก้ปัญหาซอฟต์แวร์ buggy ที่ส่งถึงมือลูกค้าอย่างไร? โดยทำให้แน่ใจว่าการทดสอบจะไม่ถูกมองว่าเป็น “เฉพาะนักพัฒนาเท่านั้นที่ใส่ใจ”

การอธิบายและทำความเข้าใจความต้องการของระบบมีประโยชน์มากมายนอกเหนือจากความถูกต้องของโค้ด: การสร้างบทสนทนาระหว่างแผนกและดูแลให้แน่ใจว่าข้อกังวลของผู้มีส่วนได้ส่วนเสียทั้งหมดได้รับการปฏิบัติตาม (และไม่ใช่แค่ผู้มีส่วนได้ส่วนเสียที่มีตำแหน่งใหญ่โต) การใช้การพัฒนาที่ขับเคลื่อนโดยพฤติกรรมเพื่อทำความเข้าใจความต้องการเหล่านี้ตั้งแต่เริ่มต้น และทดสอบพฤติกรรมทางธุรกิจภายนอกที่ทั้งทีมใส่ใจ นั่น คือวิธีที่ยอดเยี่ยมในการทำให้โครงการมีคุณภาพ