เมื่อเขียนรายละเอียดสไตล์ BDD คุณควรใช้“ ควร” หรือไม่? [ปิด]


12

ฉันรู้ว่านี่เป็นอัตนัย แต่ฉันไม่สามารถหากรณีที่ดีสำหรับหนึ่งหรืออื่น ๆ :

มัน "ควรทำอะไร"
มัน "ทำอะไรบางอย่าง"

ผู้เสนอแบบควรพูดถึงว่ามันบังคับให้คุณถามจริง ๆ ว่าคุณกำลังพยายามทำอะไรให้สำเร็จในขณะที่ผู้ค้นหาพบว่ามันซ้ำซ้อน

มีฉันทามติเกี่ยวกับเรื่องนี้หรือว่าเป็นเรื่องของสไตล์อย่างหมดจดหรือไม่?

คำตอบ:


3

ยินดีต้อนรับสู่ Legal English

การใช้ "ควร" == "จะ" == ภาระผูกพันตามสัญญา มันเป็นกฎนิยม มันไม่ได้นำไปสู่ ​​"การตั้งคำถาม" มันทำเครื่องหมายประโยคเป็นภาระผูกพันตามสัญญาอย่างเป็นทางการ

ใช้ "จะ" == "จะ" == ความคิดที่ดี มันทำเครื่องหมายประโยคเป็นคุณสมบัติเสริม

การตั้งคำถามเป็นส่วนหนึ่งของการอำนวยความสะดวกการจัดองค์กรการช่วยเหลือการสร้างความไว้วางใจ ไม่ใช่การเลือกคำ

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

คำกริยาง่ายเช่น "เพื่อแจ้ง" หรือ "เพื่อสร้าง"

  • ระบบแจ้งเตือนผ่านทางอีเมล์ (คำกริยา "แจ้งเตือน" ผันคำว่า "แจ้ง" สำหรับ "ระบบ" - ไม่ว่าจะเป็นอะไรก็ตาม)

  • ระบบจะแจ้งให้ทราบทางอีเมล ("เพื่อแจ้ง" กลายเป็น "จะต้องแจ้ง" - ไม่มีการผันคำกริยาง่ายมาก)

คำกริยาวลีที่ยากเช่น "เพื่อเข้าสู่ระบบ" หรือวลีคำกริยาเฉพาะโดเมนเช่น "เพื่อแยกชำระล้างแปลงขจัดข้อมูลซ้ำซ้อนและโหลด" หรือคำนามเช่น "โอกาส" ซึ่งได้รับการ verbed วลีที่ยาวกว่าซึ่งมีกริยาฝังอยู่หลายตัวมันยากที่จะผัน: ผันแต่ละกริยาหรือไม่ หรือลองผันคำยาว ๆ ราวกับมันเป็นคำเดียว? เนื่องจากคำนามสามารถใช้เป็นคำกริยาในภาษาอังกฤษได้ยากที่จะรู้วิธีการผันคำกริยาที่สร้างขึ้นมา

  • ระบบแยก, ทำความสะอาด, แปลง, ขจัดข้อมูลซ้ำซ้อนและโหลดเมื่อผู้ใช้คลิกเข้าไป (คำกริยาภาษาอังกฤษเล็กน้อยคำนามใด ๆ .) หรือมันเป็นสารสกัด, ทำความสะอาด, แปลง, การขจัดความซ้ำซ้อนและโหลด?

  • ระบบควรแยก, ทำความสะอาด, แปลง, ขจัดข้อมูลซ้ำซ้อนและโหลดเมื่อผู้ใช้คลิกเข้าไป (วลีที่น่ากลัวถูกทิ้งไว้ไม่เป็นความลับเกี่ยวกับการผันคำกริยา)

["อะไร?" คุณพูดว่า "คำนามใด ๆ สามารถใช้เป็นภาษาอังกฤษได้" ใช่. คำนามใด ๆ ฉันจะสกัดกั้นสิ่งนั้น ฉันมักจะติดขัดในเรื่องนั้น แม้แต่สเปคก็ควรจะติดกับที่]


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

3
ฉันขอขอบคุณที่คุณมีภาษาที่แตกต่างกันออกไป BDD เริ่มต้นที่ลอนดอนแม้ว่า ... ด้วยคำว่า "ควร";) OP ถามว่ามีฉันทามติเกี่ยวกับเรื่องนี้หรือไม่และมีมาตั้งแต่ปี 2004 -> dannorth.net/introducing-bdd
Lunivore

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

1
หากคุณต้องแก้ไขคำตอบของคุณเพื่อให้มันมีบางอย่างเช่น "บางคนเช่น 'ควร' เพราะมันนำไปสู่การตั้งคำถาม" แทนที่จะเป็นสิ่งที่มันพูดในขณะนี้ซึ่งก็คือ "มันไม่ได้นำไปสู่การซักถาม" มีความสุข. คำถามที่ตั้งคำถามเกี่ยวกับ BDD เป็นหนึ่งในสิ่งที่สำคัญที่สุดสำหรับฉันและวิธีที่คุณใช้ในการพูดกำจัดสิ่งนี้ออกไปแทนที่จะให้บริบทเพิ่มเติม ขอบคุณสำหรับการสนทนานี้ไม่ว่าคุณจะแก้ไขคำตอบหรือไม่ก็ตาม ฉันซาบซึ้งในบทสนทนาที่ให้เกียรติ
Lunivore

11
IETF มาตรฐานสำหรับการเขียน RFCs เฉพาะกล่าวว่า 'ต้อง' และ 'จะ' เป็น 'จำเป็น', 'ควร' เป็น 'แนะนำ' และ 'อาจ' คือ 'ตัวเลือก'
oosterwal

4

เป็นเรื่องของการตั้งค่าโวหาร มันทำให้การถามคุณ / ลูกค้าของคุณชอบที่จะคิดถึงระบบในปัจจุบันหรืออนาคตไหม?

ผู้มีคุณสมบัติเช่น "ควร" หรือ "จะ" บอกถึงความตึงเครียดในอนาคต แต่สิ่งนี้นุ่มนวลและอ่านได้ดีเมื่อคิดในกาลปัจจุบัน การขาดผู้มีคุณสมบัติบ่งบอกถึงกาลเวลาปัจจุบัน (เช่นในขณะนี้)

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

ในกรณีใด ๆ ถ้าคุณตัดสินใจที่จะใช้รอบคัดเลือกผมขอแนะนำให้ใช้"ต้อง" แทน "ควร" "ควร" สามารถตีความได้ว่าเป็นทางเลือก (แม้จะมีการยืนยันของ S.Lott ในทางตรงกันข้าม) แต่ "ต้อง" ลบความคลุมเครือใด ๆ - ต้องหมายความว่า "ไม่จำเป็น" อย่างชัดเจน


และเนื่องจากฉันยังไม่สามารถแสดงความเห็น (ข้อ จำกัด ด้านกรรม) นี่คือการตอบสนองต่อ S.Lott เกี่ยวกับควร / จะเทียบกับ / จะ: มีความคลุมเครือมากมายเกี่ยวกับความประสงค์และความประสงค์แม้ในการเขียนสัญญาทางกฎหมาย ดูบทความนี้สำหรับคำอธิบาย


"การขาดตัวระบุอ่านค่อนข้างแปลกในระหว่างการพัฒนาเมื่อทุกอย่างเป็นอนาคต" - ดีถ้าคุณทำ TDD และเขียนการทดสอบ แต่ยังไม่ได้เขียนรหัสการทดสอบของคุณก็ล้มเหลวในขณะนี้ ในขณะที่ความหมายของ "มันควรจะผ่านในอนาคต" จะหมายความว่ามันอาจจะผ่านตอนนี้ ดังนั้นกาลปัจจุบันนำมาซึ่งความชัดเจนมากขึ้นอย่างน้อยในกรณี TDD: มันไม่ใช่สัญญาเกี่ยวกับอนาคตที่ล้มเหลว แต่เป็นพฤติกรรมที่คาดหวังในขณะนี้ซึ่งไม่ถือ
Mikhail Vasin

2

ฉันชอบที่จะใช้บุคคลที่สามนำเสนอกาลโดยไม่ต้องคัดเลือก

ข้อโต้แย้งหลักของฉันคือ: การทดสอบเป็นเรื่อง

เรื่องราวประกอบด้วยฉากต่างๆ แต่ละฉากอธิบาย:

  • เรื่อง
  • บริบท
  • หนังบู๊

ตัวอย่าง:

DESCRIBE : getReceiptฟังก์ชัน

CONTEXT : ใบเสร็จรับเงินมีอยู่

มัน : ส่งคืนใบเสร็จรับเงิน

เช่นเดียวกับเรื่องราวที่ดีการทดสอบที่ดีนั้นง่ายต่อการอ่าน

เรื่องราวบอกคุณว่าโปรแกรมทำอะไรเช่น

  • เริ่มทำธุรกรรม
  • ทำให้คำขอ
  • การตอบสนองปกติ
  • สิ้นสุดการทำธุรกรรม
  • ส่งคืนใบเสร็จรับเงิน

ในทางกลับกันการใช้งาน qualifier (ไม่สำคัญว่าจะเป็น "ควร" หรือ "ต้อง") เปลี่ยนการทดสอบเป็นรายการการยืนยันเช่น:

  • ควรเริ่มทำธุรกรรม
  • ควรทำการร้องขอ
  • ควรทำให้การตอบสนองเป็นปกติ
  • ควรยุติการทำธุรกรรม
  • ควรคืนใบเสร็จรับเงิน

ไม่มีเรื่องต่อเนื่อง: จิตใจของคุณกำลังประเมินรายการการยืนยัน

นี่เป็นเรื่องส่วนตัว แต่การอ่านภาษาธรรมชาติ (เรื่อง) นั้นง่ายกว่าการอ่านรายการคำยืนยัน


1

ในความคิดของฉันคุณควรใช้ 'ควร'

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


1
"ยังไม่มีตัวตน" ดูเหมือนจะมีเหตุผลมากกว่าที่จะใช้กาลปัจจุบันแทนที่จะเป็น "ควร" BDD สำหรับการทดสอบการยอมรับและหากระบบยังไม่ได้ทำอะไรมันก็ควรจะล้มเหลวทันที ดูเหมือนจะมีการแบ่งระหว่าง BDDers เท่าที่ใช้ "ควร" หรือไม่
Brenden

1

จากbehaviour-driven.orgชื่อ"GettingTheWordsRight" :

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

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

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

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.