อะไรคือความแตกต่างระหว่าง BDD frameworks สำหรับ Java? [ปิด]

อะไรคือข้อดีข้อเสียของแต่ละเฟรมเวิร์กBehavior Driven Development (BDD) สำหรับ Java

ฉันพบบางส่วนที่นี่เช่น

มันสมเหตุสมผลหรือไม่ที่จะใช้เฟรมเวิร์ก BDD หากฉันใช้ไลบรารีจำลอง (เช่นMockito ) อยู่แล้ว

ฉันเพิ่งเสร็จสิ้นการเปรียบเทียบ BDD framework สามตัวสำหรับ Java เห็นได้ชัดว่าการค้นพบของฉันมีวันที่ใช้งานค่อนข้างสั้น

Concordion

• มีความยืดหยุ่นมาก
• เอาท์พุทรายงานสวยมาก
• กรอบปลั๊กอินที่ดี
• เอกสารไม่ดี ฉันต้องอ่านแหล่งที่มาเพื่อหาข้อมูล (โชคดีที่คุณภาพดีมาก)
• การแข่งขันดูเหมือนจะจบลงอย่างแน่นหนาควบคู่ไปกับ html

EasyB

• เส้นโค้งการเรียนรู้ที่ตื้นมาก (แม้แต่สำหรับนักพัฒนาที่ไม่ใช่ Groovy)
• การรวม DBUnit ที่ทรงพลังอย่างยิ่ง
• เห็นได้ชัดว่าไม่มีการรองรับพารามิเตอร์ (นำไปสู่เรื่องราวที่คลุมเครือมากหรือการทำซ้ำระหว่างข้อความและรหัส (แก้ไข: มีอยู่จริง แต่เอกสารประกอบถูกซ่อนไว้เป็นอย่างดี)
• เรื่องราวและรหัสเชื่อมโยงกันอย่างแน่นหนา (ไฟล์เดียวกัน)
• เอาต์พุตรายงานพื้นฐานมาก
• ไม่สามารถรับปลั๊กอิน IntelliJ ในการทำงาน
• ชุมชนที่ไม่ได้ใช้งาน (ปลั๊กอิน Maven ดูเหมือนจะใช้งานไม่ได้เป็นเวลาสามเดือน - มีตัวอย่างโค้ดไม่มากนัก)

JBehave

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

ฉันไม่มีโอกาสได้ลอง Cuke4Duke ของ JDave อย่างที่ฉันชอบ แต่อาจจะผลักดันให้ JBehave ในเวลานี้

"ข้อดีข้อเสีย" อาจแตกต่างกันไปสำหรับแต่ละคน ฉันมักจะดูที่

• กิจกรรมการพัฒนาเช่นมีแนวโน้มจะออกใหม่หรือเป็นรุ่นล่าสุดที่มีอายุ 2 ปี
• วุฒิภาวะเช่นมีมานานแค่ไหนมีแบบฝึกหัดและอาจมีหนังสือด้วย (ฉันไม่ได้อ่านหนังสือเหล่านี้มันเป็นเพียงสัญญาณของการยอมรับ)
• การสนับสนุนเครื่องมือเช่นมีปลั๊กอิน Eclipse, Ant support ฯลฯ
• ขนาดของการอ้างอิงฉันไม่ชอบกรอบที่มาพร้อมกับทุกอย่างของตัวเอง เช่นฉันต้องการเลือกกรอบการล้อเลียนของฉันเอง
• ประเภทของใบอนุญาตนี่เป็นสิ่งสำคัญสำหรับฉันเนื่องจากเงื่อนไขทางกฎหมายใน บริษัท ที่ฉันทำงาน
• ความเข้ากันได้กับเครื่องมือที่เกี่ยวข้องเช่นใช้ภาษา Gherkin หรือไม่

และจากกรอบบางอย่างฉันได้ดู

• สัญชาตญาณ ไม่ดี : กิจกรรมล่าสุดเมื่อเดือนมีนาคม 2010ดี : ใบอนุญาต ASF
• JDave bad : มาพร้อมกับ matchers และ mocks, good : กิจกรรมล่าสุด ม.ค. 2011, ใบอนุญาต ASF
• easyb bad : กิจกรรมล่าสุด ต.ค. 2010ไม่แน่ใจ : ใช้ Groovy นี่อาจจะใช้ได้ แต่จะเป็นปัญหาสำหรับการนำไปใช้ในกรณีของฉัน
• beanpec ไม่ดี : มีเพียงเวอร์ชันเดียวในปี 2550 เท่านั้นที่ตายไปแล้ว
• bdoc ไม่ดี : กิจกรรมล่าสุดเมื่อเดือนมกราคม 2010ไม่แน่ใจ : ดูเหมือนว่าจะไปอีกทางหนึ่งโดยสร้างรายงานจากโค้ด
• สป็อค ไม่ดี : อาจจะรุนแรงไปหน่อยนี่เป็นกรอบการทดสอบที่สมบูรณ์ไม่ใช่เฉพาะ BDD เท่านั้นที่ดี : ใช้งานได้ดีเยี่ยมมาก
• jbehave "แม่" ของ BDD ทั้งหมดใน Javaไม่ดี : มีประสิทธิภาพมาก = ซับซ้อนสิทธิ์การใช้งานที่เข้ากันไม่ได้ (สำหรับฉัน) มาพร้อมกับไลบรารีทดสอบเกือบทุกตัวและอื่น ๆ อีกมากมายดี : ใช้ RSpec และเข้ากันได้ปลั๊กอิน eclipse การรวม maven ชุมชนที่กระตือรือร้นมาก
• ginkgo4jซึ่งเป็นเฟรมเวิร์ก BDD สำหรับ Java ซึ่งใช้ RSpec ของ Ruby แต่ใช้ Java lambda (แทนคำอธิบายประกอบ) เพื่อให้คุณสร้างการทดสอบที่มีบริบทสูงและอ่านได้ง่าย ง่าย ทรงพลังมาก. ใบอนุญาตโอเพนซอร์ส Apache 2

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

BDD framework ที่ดีที่สุดที่จะใช้กับ Java คืออะไร? ทำไม? แต่ละกรอบมีข้อดีข้อเสียอย่างไร

นี่คือลิงค์ที่น่าสนใจเกี่ยวกับConcordion vs. Cucumber และ Java based Acceptance Testing

ฉันเจอสองสามตัวที่นี่ แต่ไม่แน่ใจว่าจะเลือกอันไหนดี

จริงๆดูที่กล่าวไว้ข้างต้น

มันสมเหตุสมผลหรือไม่ที่จะใช้เฟรมเวิร์ก BDD หากฉันใช้ไลบรารีจำลอง (เช่น Mockito) อยู่แล้ว

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

เดิมทีฉันทำ BDD ด้วย jUnit ธรรมดา แต่เมื่อเร็ว ๆ นี้ฉันได้ดูJDaveเพราะมันเกือบ 1: 1 สำหรับสิ่งที่ฉันทำกับ jUnit นอกจากนี้ยังทำงานบน jUnit ดังนั้นจึงทำงานบน Eclipse อยู่แล้วและยังง่ายต่อการกำหนดค่าให้ทำงานกับระบบการรวมต่อเนื่องเช่น Hudson ไม่สามารถเปรียบเทียบกับคนอื่น ๆ ได้เลย แต่ประสบการณ์ของฉันกับ JDave นั้นดีมาก

โอ้และไม่เคยเป็นความคิดที่โง่เลยที่จะใช้ล้อเลียน! พวกเขาไม่ได้เชื่อมโยงกับ TDD / BDD โดยเฉพาะจุดประสงค์คือเพื่อลดภาระในการทดสอบโดยทั่วไป

ว้าวเห็นประเด็นร้อนคำตอบดีๆเยอะมาก ...

นอกจากนี้ฉันเพิ่งค้นพบ BDD และพบว่าแนวคิดนี้น่าสนใจ เฮ้มันบังคับให้เขียนทั้งการทดสอบ ... และข้อกำหนด! น่าแปลกใจที่อาจดูเหมือนว่าโครงการหลังอาจหายไปในบางโครงการ ... หรือขาดความแม่นยำที่ BDD บังคับให้แนะนำ

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

เนื่องจาก BDD ต้องอาศัยความสามารถในการอ่านโค้ดทดสอบเป็นอย่างมากฉันจึงคิดว่าเกณฑ์ที่ดีในการเลือกคือการดูทัวร์ / บทช่วยสอนฉบับย่อและดูว่าอันไหนเหมาะกับสไตล์ของคุณมากขึ้น เกณฑ์อื่น ๆ อาจเป็นเครื่องมือที่ใช้ประโยชน์จากเฟรมเวิร์กที่คุณคุ้นเคย (การทดสอบหน่วยการเยาะเย้ย) การใช้งานกับ IDE และอื่น ๆ

ฉันลองใช้Cucumber-JVM (ก่อนหน้านี้พัฒนาเป็น Cuke4Duke) ใช้ Gherkin DSL สำหรับข้อกำหนดจัดเก็บเป็นข้อความธรรมดา

สามารถรันเป็นการทดสอบ JUnit ดังนั้นปัญหาเดียวในการเริ่มต้นใช้งานคือทำให้นักธุรกิจหรือผู้จัดการผลิตภัณฑ์อ่าน / เขียนคุณสมบัติใน Sources

ผล

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

มีปัญหาบางอย่างเช่นกัน เราได้เปลี่ยนไปใช้ Java 6 บางครั้งขั้นตอนสถานการณ์บางอย่างจะถูกละเว้นระหว่างการดำเนินการ อาจทำให้เกิดปัญหามากมายในการหาจุดบกพร่อง

ทีมของฉันใช้ JBehave อย่างประสบความสำเร็จ - เราย้ายไปใช้งานหลังจากใช้ EasyB และพบว่าไฟล์สถานการณ์ข้อความธรรมดาจัดการได้ง่ายขึ้น