คำถามติดแท็ก bdd

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

91 testing  unit-testing  bdd  literate-programming 

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

62 testing  unit-testing  tdd  bdd  integration-tests 

ความสัมพันธ์ของ BDD และ TDD คืออะไร? จากสิ่งที่ฉันเข้าใจ BDD เพิ่มสองสิ่งสำคัญเหนือ TDD: การทดสอบการตั้งชื่อ (มั่นใจ / ควร) และการทดสอบการยอมรับ ฉันควรติดตาม TDD ในระหว่างการพัฒนาโดย BDD หรือไม่ ถ้าใช่จะทำการตั้งชื่อการทดสอบหน่วย TDD ของฉันในแบบเดียวกันให้แน่ใจว่า / ควรมีสไตล์?

30 tdd  bdd 

มันเป็นไปได้ที่จะคาดหวังความคุ้มครองรหัส 100% ในการใช้งานเว็บ jquery / backbonejs หนัก? มันสมเหตุสมผลที่จะล้มเหลวในการวิ่งเนื่องจากความครอบคลุม 100% ไม่พบเมื่อครอบคลุมรหัสจริงวนเวียนอยู่รอบ ๆ 92% -95% ใน javascript / jquery?

28 code-quality  tdd  bdd 

คำถามนี้ถูกโยกย้ายจาก Stack Overflow เพราะสามารถตอบได้ใน Software Engineering Stack Exchange อพยพ 8 ปีที่แล้ว ในการเริ่มต้นผมไม่คิดว่านี่เป็นซ้ำของคำถามอื่น ๆในการทดสอบหน่วย สิ่งที่ฉันต้องการความช่วยเหลือคือการสื่อสารถึงคุณค่าของมันกับทีมโปรแกรมเมอร์นักวิเคราะห์ผู้จัดการและผู้ทดสอบ โดยการทดสอบอัตโนมัติฉันไม่คิดว่าฉันต้องแยกความแตกต่างระหว่างการทดสอบหน่วย (เช่น JUnit), BDD (เช่น JBehave, ฟิตเนส) และ UI (Selenium, Watir) เพราะฉันคิดว่าพวกเขาให้คุณค่าที่คล้ายคลึงกัน (แต่รู้สึกอิสระที่จะ เขียนคำตอบที่ไม่เห็นด้วย :)) ต่อไปนี้เป็นรายการที่ฉันระบุฉันกำลังมองหาคำตอบที่ช่วยขยายหรือปรับแต่ง: ประหยัดเวลา / ค่าใช้จ่าย : การเขียนแบบทดสอบอัตโนมัติอาจใช้เวลามากกว่ากรณีทดสอบแบบเป็นลายลักษณ์อักษร อย่างไรก็ตามการพิจารณาการทดสอบนั้นดำเนินการหลายครั้งงานส่วนเพิ่ม (เช่นราคา / เวลา) ในการดำเนินการทดสอบอัตโนมัตินั้นมีคำสั่งไม่มากนัก การทดสอบอัตโนมัตินั้นมีราคาถูกในการใช้งานช่วยให้การเปลี่ยนระบบเป็นไปอย่างสะดวก เอกสาร : ไม่มีวิธีที่แท้จริงที่จะรู้ว่าระบบทำงานอย่างไรกว่าการทดสอบ เอกสารอื่น ๆ มักจะล้าสมัยทันทีที่มีการเขียน แต่การทดสอบ (อย่างน้อยผู้ที่ผ่าน) เปิดเผยว่าสิ่งที่ใช้งานได้จริง …

25 unit-testing  selenium  tdd  bdd 

การพัฒนาพฤติกรรมที่ขับเคลื่อนด้วยสัญลักษณ์ของสถานการณ์“ ที่ได้รับเมื่อนั้น” ได้รับการเน้นย้ำอย่างมากสำหรับการใช้ที่เป็นไปได้ในฐานะวัตถุขอบเขตสำหรับการประเมินการทำงานของซอฟต์แวร์ ฉันยอมรับอย่างแน่นอนว่าGherkinหรือสคริปต์การกำหนดคุณสมบัติที่คุณต้องการเป็นDSL ที่สามารถอ่านได้ทางธุรกิจและมอบคุณค่าเช่นนี้แล้ว อย่างไรก็ตามฉันไม่เห็นด้วยที่จะไม่สามารถเขียนโปรแกรมได้ (เช่นMartin Fowler ) ใครบ้างมีบัญชีของสถานการณ์ที่เขียนโดยไม่ใช่โปรแกรมเมอร์แล้ว instrumented โดยนักพัฒนา หากมีความเห็นพ้องต้องกันเกี่ยวกับการขาดความสามารถในการเขียนคุณจะเห็นปัญหากับเครื่องมือที่แทนที่จะเริ่มต้นด้วยสถานการณ์และการใช้เครื่องมือพวกเขาจะสร้างสถานการณ์ที่สามารถอ่านได้ทางธุรกิจจากการทดสอบจริงหรือไม่ อัปเดต:เกี่ยวกับเครื่องมือ“ ตัวสร้างสถานการณ์จำลอง” แน่นอนว่ามันจะไม่เดาภาษาธุรกิจอย่างน่าอัศจรรย์;) แต่เหมือนกับที่เราใช้ regexp matchers ในการสร้างแบบทดสอบจากบนลงล่าง (ในมิติที่เป็นนามธรรม) เราสามารถใช้ ผู้สร้างสตริงเพื่อสร้างสถานการณ์ในแนวทางจากล่างขึ้นบน ตัวอย่าง“ เพื่อให้ความคิดเท่านั้น”: Given I am on page ${test.currentPage.name} And I click on element ${test.currentAction.element} …

24 documentation  bdd  documentation-generation  business-rules 

คุณเคยได้ยินหลายครั้งจากผู้ที่ไม่เข้าใจคุณค่าของการทดสอบอย่างแท้จริง เพียงเพื่อเริ่มต้นสิ่งต่าง ๆ ฉันเป็นผู้ติดตาม Agile และการทดสอบ ... ฉันเพิ่งมีการอภิปรายเกี่ยวกับการดำเนินการ TDD บนผลิตภัณฑ์เขียนใหม่ที่ทีมปัจจุบันไม่ฝึกการทดสอบหน่วยในระดับใดและอาจไม่เคยได้ยินเกี่ยวกับเทคนิคการฉีดพึ่งพาหรือรูปแบบการทดสอบ / การออกแบบ ฯลฯ (เราจะไม่ได้รับ เพื่อทำความสะอาดรหัส) ตอนนี้ฉันมีความรับผิดชอบอย่างเต็มที่สำหรับการเขียนซ้ำของผลิตภัณฑ์นี้และฉันบอกว่าการพยายามใช้มันในรูปแบบของ TDD จะทำให้มันเป็นฝันร้ายในการบำรุงรักษาและเป็นไปไม่ได้สำหรับทีมที่ดูแลรักษา นอกจากนี้เนื่องจากเป็นแอปพลิเคชันส่วนหน้า (ไม่ใช่บนเว็บ) การเพิ่มการทดสอบจึงไม่มีจุดหมายเนื่องจากการเปลี่ยนแปลงของไดรฟ์ทางธุรกิจ (โดยการเปลี่ยนแปลงหมายถึงการปรับปรุงแน่นอน) การทดสอบจะล้าสมัยนักพัฒนาอื่น ๆ ที่เข้ามา โครงการในอนาคตจะไม่รักษาและกลายเป็นภาระสำหรับพวกเขาในการแก้ไข ฯลฯ ฉันสามารถเข้าใจได้ว่า TDD ในทีมที่ไม่มีประสบการณ์การทดสอบใด ๆ ในขณะนี้ไม่ดี แต่ข้อโต้แย้งของฉันในกรณีนี้คือฉันสามารถสอนการฝึกฝนของฉันกับคนรอบตัวฉัน แต่ยิ่งกว่านั้นฉันรู้ว่า TDD ทำให้ดีขึ้น ซอฟต์แวร์. แม้ว่าฉันจะผลิตซอฟต์แวร์โดยใช้ TDD และส่งการทดสอบทั้งหมดไปมอบให้กับทีมซ่อมบำรุงมันจะเป็นวิธีที่ดีกว่าการไม่ใช้ TDD เลยตั้งแต่แรก? ฉันถูกยิงเพราะพูดถึงการทำ TDD ในโครงการส่วนใหญ่สำหรับทีมที่ไม่เคยได้ยินมาก่อน แนวคิดของ "ส่วนต่อประสาน" และตัวสร้าง DI ที่ดูแปลก …

24 testing  agile  tdd  bdd 

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

22 development-process  scalability  bdd  integration-tests 

สมมติว่าเรามีแอปพลิเคชันระดับองค์กรขนาดใหญ่โดยไม่มีการทดสอบหน่วย / การทำงานใด ๆ ไม่มีกระบวนการพัฒนาที่ขับเคลื่อนด้วยการทดสอบในระหว่างการพัฒนาอันเนื่องมาจากกำหนดเวลาที่เข้มงวดมาก (ฉันรู้ว่าเราไม่ควรสัญญาวันครบกำหนดที่แน่นเมื่อเราไม่แน่ใจ แต่สิ่งที่ทำเสร็จแล้ว!) ตอนนี้ทุกอย่างผ่านไปและทุกอย่างสงบลงทุกคนตกลงที่จะเปลี่ยนเราให้เป็นทีมงานที่มีประสิทธิผลของ TDD / BDD ... ตอนนี้คำถามเกี่ยวกับรหัสที่เรามีอยู่แล้ว: (1) มันยังไม่เป็นไรหรือเป็นความคิดที่ดีที่จะหยุดการพัฒนาส่วนใหญ่และเริ่มเขียนกรณีทดสอบที่เป็นไปได้ทั้งหมดตั้งแต่เริ่มต้นถึงแม้ว่าทุกอย่างจะทำงานได้อย่างสมบูรณ์ ? หรือ (2) เป็นการดีกว่าที่จะรอสิ่งที่ไม่ดีเกิดขึ้นจากนั้นในระหว่างการแก้ไขการทดสอบหน่วยการทดสอบใหม่หรือ (3) แม้กระทั่งลืมรหัสก่อนหน้าและเพียงแค่เขียนการทดสอบหน่วยสำหรับรหัสใหม่เท่านั้นและเลื่อนทุกอย่าง มีไม่กี่ที่ดีและบทความที่เกี่ยวข้องเช่นนี้ ฉันยังไม่แน่ใจว่ามันคุ้มค่าหรือไม่ที่จะพิจารณาเรื่องนี้เพราะเรามีเวลา จำกัด และโครงการ / งานอื่น ๆ อีกมากมายกำลังรอเราอยู่ หมายเหตุ : คำถามนี้อธิบาย / จินตนาการถึงสถานการณ์ที่น่าอึดอัดใจในทีมพัฒนา นี่ไม่เกี่ยวกับฉันหรือเพื่อนร่วมงานของฉัน มันเป็นเพียงสถานการณ์ในจินตนาการ คุณอาจคิดว่าสิ่งนี้ไม่ควรเกิดขึ้นหรือผู้จัดการฝ่ายพัฒนารับผิดชอบต่อความยุ่งเหยิง! แต่อย่างไรก็ตามสิ่งที่ทำเสร็จแล้ว หากเป็นไปได้โปรดอย่าโหวตเพราะคุณคิดว่าสิ่งนี้จะไม่เกิดขึ้น

17 unit-testing  testing  tdd  bdd  acceptance-testing 

ฉันพยายามที่จะเข้าใจ BDD ฉันอ่านบทความแล้วและฉันเข้าใจว่า BDD คือ "ขั้นตอนต่อไป" จาก TDD ฉันบอกว่าเพราะฉันพบว่าทั้งคู่มีความคล้ายคลึงกันมากและอย่างที่ฉันสามารถอ่านได้ในบทความนี้ BDD เกิดมาเพื่อปรับปรุงจาก TDD เยี่ยมมากฉันชอบความคิดจริงๆ มีจุดหนึ่งที่ใช้งานได้จริงที่ฉันไม่ได้รับคิดว่า: มีไฟล์. Feature ซึ่ง BA จะเขียนพฤติกรรมที่คาดหวังไว้ทั้งหมดซึ่งระบบจะมี ในฐานะที่เป็นปริญญาตรีเขาไม่มีความคิดว่าระบบจะสร้างอย่างไรดังนั้นเราจะเขียนดังนี้: + สถานการณ์ที่ 1: บัญชีอยู่ในเครดิต + รับบัญชีเป็นเครดิต และบัตรถูกต้อง และตัวจ่ายประกอบด้วยเงินสด เมื่อลูกค้าขอเงินสด จากนั้นตรวจสอบให้แน่ใจว่าบัญชีเดบิตและตรวจสอบให้แน่ใจว่าจ่ายเงินสดแล้ว และให้แน่ใจว่าบัตรจะถูกส่งกลับ ตกลงนี่เป็นสิ่งที่ดี แต่มีหลายส่วนของระบบที่จะทำงานร่วมกันเพื่อให้สามารถเกิดขึ้นได้ (คิดว่าบัญชี obj, เครื่องจ่าย obj, ลูกค้า obj และอื่น ๆ ) สำหรับฉันนี่ดูเหมือนการทดสอบการรวมเข้าด้วยกัน ฉันต้องการทดสอบยูนิต ฉันจะทดสอบรหัสที่ตรวจสอบว่าเครื่องจ่ายมีเงินได้อย่างไร หรือว่าเงินสดจ่าย? หรือว่าบัญชีถูกหักบัญชีเมื่อจำเป็น? ฉันจะผสมการทดสอบหน่วยกับการทดสอบ "สร้างโดย BA" …

17 unit-testing  bdd 

ใน TDD มีไวยากรณ์จัดเรียง Assert (AAA): [Test] public void Test_ReturnItemForRefund_ReturnsStockOfBlackSweatersAsTwo_WhenOneInStockAndOneIsReturned() { //Arrange ShopStock shopStock = new ShopStock(); Item blackSweater = new Item("ID: 25"); shopStock.AddStock(blackSweater); int expectedResult = 2; Item blackSweaterToReturn = new Item("ID: 25"); //Act shopStock.ReturnItemForRefund(blackSweaterToReturn); int actualResult = shopStock.GetStock("ID: 25"); //Assert Assert.AreEqual(expectedResult, actualResult); } ในการทดสอบการเขียน BDD ใช้โครงสร้างที่คล้ายกัน แต่มีไวยากรณ์เมื่อเมื่อ (GWT): [Given(@"a …

13 c#  unit-testing  tdd  bdd 

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

13 testing  team  qa  bdd  acceptance-testing 

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

12 testing  bdd 

ถาม: วิธีใดที่ดีที่สุดในการย้าย บริษัท ขนาดใหญ่ไปยัง Cucumber ด้วยความต้องการซอฟต์แวร์รุ่นเก่าอย่างน้อย 15 ปีในฐานข้อมูลความต้องการ กำลังพิจารณา: 1) โยกย้ายทุกอย่าง ข้อเสีย: เราไม่มีเวลา / งบประมาณไม่ จำกัด เราต้องเดินหน้าต่อไปเพื่อความอยู่รอดเราไม่สามารถหยุดทุกสิ่งได้และ GC 100% ของข้อกำหนดดั้งเดิมและชุดทดสอบแบบดั้งเดิม 2) กฎลูกเสือ ปล่อยให้ทุกสิ่งทุกอย่างดีกว่าที่คุณพบ หากคุณสัมผัสข้อกำหนดหรือเปลี่ยนแปลงเขียน / อัปเดตคุณสมบัติแตงกวา ข้อเสีย: เราจะมีระบบการบันทึกสองระบบ (แตงกวามรดกความต้องการฐานข้อมูล) ซึ่งอาจเป็นไปได้ว่าสมมติว่ามีมุมของแอปพลิเคชันที่ให้มาซึ่งไม่ได้สัมผัสเป็นเวลานาน 3) กฎลูกเสือพลัส เหมือนกับ # 2 แต่วางข้อกำหนดซึ่งเราไม่ได้ย้ายไปที่แตงกวาในคุณลักษณะด้วยสถานการณ์ที่รอดำเนินการเดียวและคัดลอก / วางข้อกำหนดดั้งเดิมลงในส่วนคำอธิบาย วิธีนี้เราจะได้รับตัวชี้วัด (ผ่านสถานการณ์ที่รอดำเนินการ) ว่า "ครอบคลุม" เราเป็นอย่างไรโดย Cucumber และทำให้เรามีความต้องการที่จะรักษาระบบข้อกำหนดเก่า ฉันไม่สามารถหาข้อเสียอื่น ๆ นอกเหนือจากนี้อาจเป็นเรื่องใหญ่ใน Cucumber 4) …

11 bdd  cucumber 

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

11 productivity  agile  unit-testing  bdd