มีเหตุผลที่การทดสอบไม่ได้ถูกเขียนขึ้นโดยสอดคล้องกับรหัสที่พวกเขาทำการทดสอบหรือไม่?

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

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

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

อย่างไรก็ตามมีข้อเสียมากมายที่เห็นได้ชัดสำหรับการทดสอบแบบอินไลน์:

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

ฉันคิดได้บ้าง:

• การอ่าน การใส่รหัสและการทดสอบที่กระจาย "จริง" จะทำให้การอ่านรหัสจริงยากขึ้น

• รหัสขยาย การผสมโค้ด "ของจริง" และรหัสทดสอบลงในไฟล์ / คลาส / สิ่งเดียวกันที่มีแนวโน้มว่าจะส่งผลให้ไฟล์ที่รวบรวมมีขนาดใหญ่ขึ้น ฯลฯ ซึ่งเป็นสิ่งสำคัญอย่างยิ่งสำหรับภาษาที่มีความผูกพันในช่วงท้าย

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

ขณะนี้มีวิธีแก้ไขปัญหาที่เป็นไปได้สำหรับแต่ละปัญหาเหล่านี้ แต่ IMO มันง่ายกว่าที่จะไม่ไปที่นั่นตั้งแต่แรก

เป็นที่น่าสังเกตว่าในช่วงแรกโปรแกรมเมอร์ Java เคยทำสิ่งนี้ เช่นรวมถึงmain(...)วิธีการในชั้นเรียนเพื่ออำนวยความสะดวกในการทดสอบ แนวคิดนี้หายไปเกือบหมดแล้ว มันเป็นแนวปฏิบัติอุตสาหกรรมที่จะใช้การทดสอบแยกต่างหากโดยใช้กรอบการทดสอบบางชนิด

นอกจากนี้ยังเป็นสิ่งที่ควรค่าแก่การสังเกตว่าการเขียนโปรแกรมวรรณกรรม (ตามที่ Knuth คิดไว้) ไม่เคยถูกจับในอุตสาหกรรมวิศวกรรมซอฟต์แวร์

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

Michael Feathers มีการนำเสนอเกี่ยวกับสิ่งนี้และนี่เป็นหนึ่งในหลาย ๆ วิธีที่เขากล่าวถึงคุณสามารถปรับปรุงคุณภาพรหัส

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

การสร้าง:การทดสอบและรหัสอาจถูกเขียนในเวลาต่างกันโดยผู้คนต่างกัน

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

ความสามารถนำมาใช้ซ้ำได้:หากคุณใส่การทดสอบแบบอินไลน์คุณจะไม่สามารถใช้การทดสอบเหล่านั้นกับโค้ดส่วนอื่นได้

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

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

ตัวอย่างเช่นคุณอาจมีชุดการทดสอบขนาดเล็กที่เกี่ยวข้องกับรหัสที่คุณกำลังทำงานอยู่ในขณะนี้และชุดที่ใหญ่กว่าที่ทดสอบทั้งโครงการ

นี่คือเหตุผลเพิ่มเติมบางอย่างที่ฉันนึกได้:

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

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

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

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

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

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

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

สิ่งนี้เป็นการตอบสนองต่อความคิดเห็นจำนวนมากที่ชี้ให้เห็นว่าการทดสอบแบบอินไลน์ไม่ได้ทำเพราะเป็นการยากที่จะลบรหัสทดสอบออกจาก build build นี่เป็นเรื่องจริง คอมไพเลอร์และแอสเซมเบลอร์เกือบทั้งหมดสนับสนุนสิ่งนี้อยู่แล้วด้วยภาษาที่คอมไพล์เช่น C, C ++, C # สิ่งนี้ทำกับสิ่งที่เรียกว่าคำสั่งคอมไพเลอร์

ในกรณีของ c # (ฉันเชื่อว่า c ++ เช่นกันไวยากรณ์อาจแตกต่างกันเล็กน้อยขึ้นอยู่กับคอมไพเลอร์ที่คุณใช้) นี่เป็นวิธีที่คุณทำได้

#define DEBUG //  = true if c++ code
#define TEST /* can also be defined in the make file for c++ or project file for c# and applies to all associated .cs/.cpp files */

//somewhere in your code
#if DEBUG
// debug only code
#elif TEST
// test only code
#endif

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

เราใช้การทดสอบแบบอินไลน์กับโค้ด Perl ของเรา มีโมดูลTest :: Inlineที่สร้างไฟล์ทดสอบจากโค้ดอินไลน์

ฉันไม่เก่งในการจัดการทดสอบและพบว่าง่ายขึ้นและมีแนวโน้มที่จะได้รับการดูแลเมื่อมีการขีดเส้นใต้

การตอบสนองต่อข้อกังวลสองข้อที่เกิดขึ้น:

• การทดสอบแบบอินไลน์เขียนไว้ในส่วน POD ดังนั้นจึงไม่ได้เป็นส่วนหนึ่งของรหัสจริง ล่ามจะถูกละเว้นดังนั้นจึงไม่มีการขยายโค้ด
• เราใช้Vim foldingเพื่อซ่อนส่วนการทดสอบ +-- 33 lines: #test----สิ่งเดียวที่คุณเห็นคือบรรทัดเดียวข้างต้นแต่ละวิธีการทดสอบเช่น เมื่อคุณต้องการทำงานกับการทดสอบคุณเพียงแค่ขยายมัน
• โมดูล Test :: Inline "รวบรวม" การทดสอบไฟล์ที่เข้ากันได้กับ TAP แบบปกติดังนั้นพวกเขาจึงสามารถอยู่ร่วมกับการทดสอบแบบดั้งเดิมได้

สำหรับการอ้างอิง:

• POD
• TAP

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

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

นอกจากนี้การทดสอบมีแนวโน้มที่จะมีบรรทัดโค้ดมากกว่าส่วนการใช้งานที่พวกเขาทดสอบดังนั้นคุณจะมีปัญหาในการค้นหาการใช้งานระหว่างการทดสอบทั้งหมด :-)

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

หากคุณกำลังพัฒนาภายใต้. NET คุณสามารถใส่รหัสทดสอบของคุณลงในชุดการผลิตแล้วใช้Scalpelเพื่อลบออกก่อนที่จะส่ง