BDD: เริ่มต้น

9

ฉันเริ่มต้นด้วย BDD และนี่คือเรื่องราวของฉัน:

Feature: Months and days to days
    In order to see months and days as days
    As a date conversion fan
    I need a webpage where users can enter
    days and months and convert them to days.

ฉันมีข้อสงสัยบางอย่าง ...

ฉันควรเขียนสถานการณ์ของฉันก่อนที่จะเขียนโค้ดอะไรหรือฉันควรเขียนสถานการณ์ก่อนแล้วจึงเขียนรหัสเขียนสถานการณ์อีกครั้งแล้วเขียนรหัสและอื่น ๆ ... ?

ถ้าฉันควรเขียนสถานการณ์ของฉันก่อนหน้านี้ขั้นตอนของฉันจะได้รับการอนุมัติและรหัสการผลิตยังไม่เสร็จ

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

— Thom
แหล่งที่มา

"ขั้นตอนของฉันสามารถได้รับการอนุมัติและรหัสการผลิตยังไม่สามารถทำได้" สิ่งนี้หมายความว่า? กรุณาอธิบาย.

— S.Lott

12

จากเรื่องนี้ฉันอนุมานว่าคุณกำลังเขียนโค้ดด้วยตัวเอง

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

หากคุณทำสิ่งนี้ด้วยตัวเองคว้าเป็ดยางพาราและอธิบายพฤติกรรมของใบสมัครของคุณกับเป็ด ยกตัวอย่างบางส่วนของวิธีการทำงาน นั่นจะเป็นสถานการณ์ของคุณ

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

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

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

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

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

In order to attract people to my website
As @thom
I want users to easily convert months and days to days.

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

— Lunivore
แหล่งที่มา

1

ส่วน 'เป็ดยาง' ดีมาก ฉันคิดว่าฉันเป็นคนเดียวที่จะคิดอย่างนั้น!

— NoChance

3

ฉันควรเขียนสถานการณ์ของฉันก่อนที่จะเขียนโค้ดอะไรหรือฉันควรเขียนสถานการณ์ก่อนแล้วจึงเขียนรหัสเขียนสถานการณ์อีกครั้งแล้วเขียนรหัสและอื่น ๆ ... ?

ทั้งสองจะทำงาน เลือกหนึ่ง.

มันไม่สำคัญอะไรมาก

ยิ่งคุณมีสถานการณ์มากเท่าไหร่คุณก็ยิ่งสามารถออกแบบได้มากขึ้นเท่านั้น

ยิ่งคุณมีสถานการณ์มากเท่าไหร่การทำบางสิ่งให้สำเร็จก็จะนานขึ้น

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

ไม่ได้คุณสร้างใหม่เมื่อมันยากที่จะออกแบบฉากต่อไป

— S.Lott
แหล่งที่มา

ฉันได้ตั้งคำถามใหม่ ... "ถ้าฉันควรเขียนสถานการณ์ของฉันก่อน ... " ขอดูหน่อยได้ไหม? ขอบคุณมาก.

— ธ.ค.

1

@ S.Lott คำตอบที่ดี แต่หนึ่งคำพูดเล่นลิ้น: ตามประโยชน์ของวงจรสีแดง - เขียว - refactor ฉันจะแนะนำ refactoring อย่างต่อเนื่องในระหว่างกระบวนการ BDD ทันทีหลังจากการทดสอบสีเขียวแต่ละครั้ง

— Rein Henrichs

@Rein Henrichs: ทางเลือกอื่นคือให้สังเกตว่าการปรับโครงสร้างใหม่เพื่อให้การทดสอบทั้งหมดสำหรับเรื่องหนึ่งเกิดขึ้นซึ่งเป็นส่วนที่หลีกเลี่ยงไม่ได้และไม่สามารถหลีกเลี่ยงได้ของการเข้ารหัส แม้แต่การออกแบบที่ยอดเยี่ยมก็ไม่สามารถครอบคลุมฐานทั้งหมดได้ การเปลี่ยนโครงสร้างนั้นไม่ได้คุ้มค่าที่จะกล่าวถึง อย่างไรก็ตามคุณได้ชี้ให้เห็นอย่างชัดเจน อย่างไรก็ตามการปรับโครงสร้างใหม่ระหว่างเรื่องต่าง ๆ นั้นเป็นการดำเนินการที่จริงจังและใช้เวลามากขึ้นเนื่องจากชุดคุณลักษณะนี้พัฒนาขึ้นตามการเพิ่มขึ้นของเรื่องราว

— S.Lott

3

ใช้คำกริยาที่สื่อความหมาย

Feature: CONVERT Months and days to days

อย่าตัดสินใจออกแบบเรื่อง ["ฉันต้องการเว็บเพจ" เป็นการตัดสินใจออกแบบ]

As a date conversion fan
I want to convert days and months into days

ใช้เป้าหมายมูลค่าทางธุรกิจในเรื่องราว

So that [some business reason]

เขียนคุณสมบัติและเรื่องราวให้มากที่สุดเท่าที่จะทำได้ก่อนที่จะเริ่มเขียนโค้ด เรื่องแจ้งซึ่งกันและกันมีอิทธิพลต่อคุณสมบัติและแจ้งการออกแบบ

Refactor หลังจากแต่ละเรื่อง สีแดงสีเขียว-Refactor

— สตีเว่นเอ. โลว์
แหล่งที่มา

+1, คำตอบที่ดี แต่ไม่ใช่ "BDD way" ในการ refactor ซึ่งเป็นส่วนหนึ่งของวงจรการทดสอบหน่วยภายในแทนที่จะเป็นรอบนอกการทดสอบการยอมรับ?

— pdr

@pdr: นั่นคือสิ่งที่ฉันหมายถึง refactor หลังจากแต่ละเรื่อง ระดับการทดสอบ BDD / TDD จากหน่วยหนึ่งไปสู่การยอมรับมีเพียงหนึ่งรอบเท่านั้น (ในใจของฉัน) ;-)

— Steven A. Lowe

ทำไม "ฉันต้องการเว็บเพจ" คือการตัดสินใจออกแบบ? ขอบคุณ!

— ธ.ค.

@thom: เรื่องราวของผู้ใช้ควรแสดงสิ่งที่ผู้ใช้ต้องการที่จะสามารถทำได้ไม่ใช่วิธีการนำไปใช้ กล่าวอีกนัยหนึ่งคือคุณสมบัติเรื่องราวและสถานการณ์ต่าง ๆ คือข้อกำหนดและข้อกำหนดการใช้งาน อย่าตัดสินใจออกแบบจนกว่าคุณจะได้ภาพเต็ม ในตัวอย่างนี้ (อาจสันนิษฐานได้) ความต้องการทางธุรกิจของผู้ใช้โดยรวมอาจระบุว่าหน้าเว็บอาจไม่ใช่วิธีที่สะดวกที่สุด - วิดเจ็ตเดสก์ท็อปหรือแอพมือถืออาจดีกว่าขึ้นอยู่กับวิธี / เมื่อพวกเขาต้องการใช้งาน รายละเอียดการใช้งานมีความยุ่งเหยิงเรื่องราวและอาจล็อคคุณในการออกแบบที่เฉพาะเจาะจงเร็วเกินไป

— Steven A. Lowe