มีกรอบการทดสอบหน่วยผู้ไม่เชื่อเรื่องพระเจ้าหรือไม่? [ปิด]

11

ปิด. คำถามนี้เป็นคำถามปิดหัวข้อ ไม่ยอมรับคำตอบในขณะนี้

ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้เป็นหัวข้อสำหรับ Software Engineering Stack Exchange

ปิดให้บริการใน5 ปีที่ผ่านมา

ฉันสงสัยในการเขียนรหัสการทำงานใหม่อยู่เสมอ - การย้ายรหัสจะไม่มีข้อยกเว้น อย่างไรก็ตามด้วยการถือกำเนิดของ TDD และการทดสอบอัตโนมัติมันมีความเหมาะสมมากกว่าในการเขียนและสร้างรหัสใหม่

ไม่มีใครรู้ว่ามีเครื่องมือ TDD ที่สามารถใช้ในการย้ายรหัสเก่าได้หรือไม่? เป็นการดีที่คุณสามารถทำต่อไปนี้:

เขียนการทดสอบหน่วยผู้ไม่เชื่อเรื่องภาษาสำหรับรหัสเก่าที่ผ่าน (หรือล้มเหลวหากคุณพบข้อบกพร่อง!)
เรียกใช้การทดสอบหน่วยในฐานรหัสอื่น ๆ ของคุณที่ล้มเหลว
เขียนรหัสในภาษาใหม่ของคุณที่ผ่านการทดสอบโดยไม่ต้องดูรหัสเก่า

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

แก้ไข: มันคุ้มที่จะสังเกตคำถามนี้ใน StackOverflow

unit-testing language-agnostic porting

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

จัดเตรียมโปรโตคอลคำสั่งข้อความล้วนจากนั้นใช้expectเพื่อดำเนินการทดสอบของคุณ

— SK-logic

@ expectSK-ตรรกะผมไม่เคยได้ยินของ หากคุณมีระบบดั้งเดิมของ Unix ที่สื่อสารกับไพพ์โดยใช้ stdin และ stdout เครื่องมือนั้นสามารถใช้งานได้อย่างแน่นอน ความจริงแล้วมันค่อนข้างง่ายที่จะทดสอบด้วยภาษาสคริปต์ใด ๆ

— Bringer128

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

— SK-logic

@ SK-logic ขออภัยที่ไม่ชัดเจน ผมบอกว่า "ดั้งเดิม" เพราะการย้ายจะกระทำโดยทั่วไปจากการlegacy language x fancy new language yฉันไม่ได้พยายามจะบอกอะไรเกี่ยวกับยูนิกซ์!

— Bringer128

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

— SK-logic

6

ฉันไม่คิดว่าเป็นไปได้ที่จะเขียนการทดสอบหน่วยในภาษาอื่น

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

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

แน่นอนว่าคุณจะไม่ได้รับความครอบคลุมเช่นเดียวกับการทดสอบระดับหน่วย (ยกเว้นการใช้เวลามาก) แต่อย่างน้อยคุณจะต้องใช้ชุดทดสอบ

— เดวิด
แหล่งที่มา

+1 สำหรับการทดสอบระดับสูงอัตโนมัติ สิ่งเหล่านี้จะคุ้มค่ากับความพยายามในการผลิต

— Bringer128

1

"ฉันไม่คิดว่าเป็นไปได้ที่จะเขียนการทดสอบหน่วยในภาษาอื่น" : ตัวนับตัวอย่าง: ใน. NET คุณสามารถเขียนการทดสอบหน่วยของ C # ใน Visual Basic (หรือภาษาที่เปิดใช้งาน. NET อื่น ๆ ) ไม่กี่ปีที่ผ่านมาสิ่งนี้ได้รับการสนับสนุนโดย Microsoft ในฐานะที่เป็นแนวปฏิบัติที่ดีเนื่องจากลดความเสี่ยงในการทำทั้งรหัสและการทดสอบข้อผิดพลาดเดียวกันที่เกี่ยวข้องกับภาษา ตกลงหนึ่งจะไม่เขียนการทดสอบหน่วยใน Fortran เพื่อทดสอบรหัส PHP

— Arseni Mourzenko

2

ฉันคิดว่าสิ่งที่ใกล้เคียงที่สุดกับความคิดของคุณคือกรอบการทดสอบหน่วยบนระบบนิเวศที่ใช้เครื่องเสมือนเช่น Java VM อย่างน้อย Scala (และฉันเชื่อว่า Groovy เหมือนกัน - ฉันไม่แน่ใจเกี่ยวกับ Clojure) เกือบจะทำงานร่วมกันได้อย่างสมบูรณ์กับ Java นั่นคือโค้ด Scala สามารถทดสอบได้ด้วย JUnit และโค้ด Java สามารถทดสอบกับ ScalaTest ได้ วิธีนี้คุณสามารถ (ค่อย ๆ หรือพร้อมกัน) เขียนโค้ด Java ใน Scala และใช้การทดสอบหน่วย Java แบบเดิมต่อไปเพื่อตรวจสอบความถูกต้อง (หรือวิธีอื่น ๆ - แม้ว่าฉันไม่สามารถจินตนาการถึงเหตุผลที่ถูกต้องในการโยกย้ายจาก Scala กลับไปที่ Java)

อาจเหมือนกันกับภาษาใน. NET CLI เช่น C #, F #, ASP.NET และอื่น ๆ

อย่างไรก็ตามนอก VM / CLR มันยากกว่า ในทางทฤษฎีเราสามารถรวบรวมการทดสอบหน่วยและ / หรือรหัสภายใต้การทดสอบเป็นภาษาอื่นเช่น C (เช่นเดิมและเป็นเรื่องปกติกับภาษาใหม่เช่นต้น C ++ เป็นต้น) แต่ฉันไม่เคยได้ยินใครที่ทดลองใช้สิ่งนี้โดยเฉพาะ การทดสอบหน่วย

— PéterTörök
แหล่งที่มา

1

ฉันเดาว่าสิ่งนี้จะแสดงปัญหากับคำถามของฉัน หากพวกเขาสามารถทำงานร่วมกันได้อย่างง่ายดายทำไมพอร์ต? และหากไม่สามารถทำได้สิ่งกีดขวางทางภาษาจะทำให้ไม่สามารถทำการทดสอบข้ามภาษาได้

— Bringer128

@ Bringer128 ผู้เสนอสายพันธุ์ใหม่ของภาษา JVM อ้างว่าปัญหาเฉพาะสามารถแก้ไขได้เร็วขึ้นโดยมีรหัสน้อยลงและสะอาดกว่า Java มาก ประสบการณ์ที่ จำกัด ของฉันกับ Scala เป็นการยืนยันในตอนนี้

— PéterTörök

Groovy ทำงานร่วมกับ Java ได้เช่นกัน

— 281377

1

กรอบงานดังกล่าวไม่มีอยู่เนื่องจากจะต้องมีการเขียนในภาษาของรหัสที่ใช้

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

— BЈовић
แหล่งที่มา

1

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

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

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

— ฮาเวียร์
แหล่งที่มา

0

กรอบการทดสอบผู้ไม่เชื่อเรื่องภาษาเป็นกรอบการทดสอบทั่วไปที่เหมาะสำหรับการทดสอบการยอมรับ (มุมมอง) และการทดสอบในกรอบการทำงานนั้นได้รับการจัดการโดย QA เช่น Robotframework

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

2

สิ่งนี้ดูเหมือนจะไม่นำเสนออะไรมากมายเกินกว่าที่ทำคะแนนและอธิบายไว้ในคำตอบ 4 ข้อก่อนหน้านี้

— ริ้น