เหตุใดการทดสอบขับเคลื่อนการพัฒนา (TDD) จึงเป็นวิธีที่ดีที่สุดสำหรับการเข้ารหัสที่แข็งแกร่ง

ก่อนอื่นให้เขียนการทดสอบหน่วยจากนั้นเขียนรหัส

เครดิตรูปภาพ: Pexels.com

หลายปีที่ผ่านมาเมื่อฉันได้ยิน "การพัฒนาขับเคลื่อนการทดสอบครั้งแรก" ฉันไม่แน่ใจ

แนวคิดของ“ การทดสอบหน่วยการเขียนครั้งแรกจากนั้นเขียนรหัส” นั้นพูดพล่อยๆกับฉัน

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

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

ดังนั้นฉันจึงปรึกษาเพื่อนของฉันที่แสดงให้ฉันเห็นตัวอย่างพื้นฐาน

ตัวอย่างพื้นฐานนี้มีคลาส LCL_SUM พร้อมเมธอด SUM ความรับผิดชอบของวิธีนี้คือการเพิ่มตัวเลข มันต้องใช้ตัวเลขเป็นพารามิเตอร์ในการนำเข้าแล้วเพิ่มเข้าไปเพื่อรับผลลัพธ์ ให้เราเรียกวิธีนี้เป็นวิธีการผลิต

รหัสสำหรับชั้นเรียนเป็นดังนี้:

คลาส lcl_sum คำจำกัดความ
ส่วนสาธารณะ
วิธีการ: การนำเข้าผลรวม iv_1 ประเภท
ค่าตอบแทน (rv_sum) TYPE i
ENDCLASS “ นิยาม lcl_sum
* * * *
การเริ่มต้นของการเลือก
* ยังไม่มีอะไรที่นี่
* * * *
* * * *
CLASS lcl_sum การดำเนินการ
ผลรวม
rv_sum = iv_1 * iv_1 “ ความผิดพลาดโดยเจตนา (ฉันคูณแทนที่จะเพิ่ม)
ENDMETHOD “ผลรวม
ENDCLASS “ การดำเนินการ lcl_sum

ทดสอบการตั้งค่าคลาส

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

คลาส lcl_test คำจำกัดความสำหรับการทดสอบ
ส่วนสาธารณะ
วิธีการ: m_sum สำหรับการทดสอบ
ENDCLASS “ lcl_test DEFINITION
* * * *
CLASS lcl_test การดำเนินการ
วิธี m_sum
ENDMETHOD “m_sum
ENDCLASS “ lcl_test การดำเนินการ

การใช้วิธีทดสอบ

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

ขึ้นอยู่กับค่าดัมมี่วิธีการจะส่งผลให้คุณ - ผลลัพธ์ที่เกิดขึ้นจริงจากวิธีการ ขึ้นอยู่กับค่าดัมมี่คุณรู้ว่าสิ่งที่จะเป็นค่าที่คาดหวัง เช่น. ถ้าคุณส่งเมธอดหมายเลข 3 ไปยัง SUM มันจะให้ผลลัพธ์เป็น 6 เมื่อเพิ่มเป็น 3

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

CLASS lcl_test IMPLEMENTATION
วิธี m_sum
ข้อมูล: o_cut ประเภท REF TO lcl_sum
DATA: lv_result TYPE i
* * * *
สร้าง OBJECT o_cut
lv_result = o_cut-> ผลรวม (3)
* * * *
cl_aunit_assert => ASSERT_EQUALS (
EXP = 6
act = lv_result
msg = 'สิ่งผิดปกติในเอาต์พุต'
)
ENDMETHOD “m_sum
ENDCLASS “ lcl_test การดำเนินการ

ผลการทดสอบหน่วย

สิ่งนี้บอกฉันว่ามีบางอย่างผิดปกติในการใช้งานวิธีการผลิต

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

ฉันถูกตะขอของ TDD Flabbergasted จะเป็นคำที่ถูกต้อง

สิ่งที่น่าทึ่งคือรอบเวลาการพัฒนาและทดสอบลดลงอย่างมาก

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

ดังนั้นในช่วงสั้น ๆ TDD จะรับรู้ผ่านวงจรการพัฒนาสั้น ๆ ที่เป็นไปตามกฎ“ การทดสอบหน่วยการเขียนครั้งแรกจากนั้นเขียนรหัสจากนั้นทำการ refactor และจากนั้นทำซ้ำ” การทดสอบหน่วยเป็นการทดสอบอัตโนมัติที่ตรวจสอบว่า การทดสอบหน่วยแรกของคุณควรล้มเหลวเนื่องจากถูกเขียนขึ้นก่อนที่คุณจะมี codebase ใด ๆ

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

มาตรการนี้ป้องกันไม่ให้นักพัฒนาเขียนโค้ดที่ไม่จำเป็นซึ่งไม่เป็นไปตามการทดสอบที่กำหนด

และวิธีการแบบบูรณาการทั้งหมดนี้นำเสนอบทเพลงของผลประโยชน์ให้กับนักพัฒนา

คุณแก้ไขรหัสไม่ถูกต้องโดยไม่ทำลายอะไรเลย

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

·“ นี่เป็นระเบียบ ฉันคิดว่าฉันต้องแก้ไขมันอย่างใด "

·“ ฉันไม่ได้แตะต้องเลย”

ทั้งสองกรณีมีองค์ประกอบของความกลัวที่เกี่ยวข้อง ในความเป็นจริงความไม่แน่นอน

จะเกิดอะไรขึ้นถ้ารหัสของฉันใช้งานไม่ได้?

TDD ช่วยให้คุณเอาชนะความไม่แน่นอนนั้นได้อย่างแม่นยำ

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

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

TDD บังคับใช้เอกสารประกอบ

ดิ๊กแบรนดอนกระแทกกับเล็บเมื่อเขาสังเกตเห็น

“ เอกสารเป็นเรื่องเพศ เมื่อมันดีมันดีมากดีมากและเมื่อมันแย่มันก็ดีกว่าไม่มีอะไรเลย”

เอกสารเป็นน้ำมันละหุ่งของการเขียนโปรแกรม ผู้จัดการคิดว่ามันดีสำหรับโปรแกรมเมอร์และโปรแกรมเมอร์เกลียดมัน!

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

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

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

TDD ช่วยในการออกแบบที่ดีขึ้น

ข้อกำหนดเบื้องต้นพื้นฐานใน TDD คือคุณต้องเขียนกรณีทดสอบหน่วยของคุณก่อนที่จะเขียนรหัส

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

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

ในขณะที่การเขียนกรณีทดสอบล่วงหน้าอาจใช้เวลานาน แต่สิ่งนี้ให้ประโยชน์มากมาย นักพัฒนายอมรับว่าก่อนหน้านี้พวกเขาเคยเขียนบรรทัดของรหัสตระหนักดีว่าโซลูชันของพวกเขาไม่เกี่ยวข้องแล้วเริ่มเข้ารหัสอีกครั้งตั้งแต่เริ่มต้น

ซึ่งแตกต่างจากวิธีการเข้ารหัสที่ล้าสมัย TDD ช่วยให้นักพัฒนาสามารถกลับไปที่กระดานวาดภาพและมีสมาธิในการออกแบบสถาปัตยกรรมที่มีน้ำหนักเบาและยืดหยุ่นได้ล่วงหน้า

และความเป็นจริงของการเขียนกรณีทดสอบล่วงหน้าป้องกันข้อผิดพลาดใด ๆ ที่อาจปรากฏขึ้นในภายหลังจึงประหยัดเวลาความพยายามและอิจฉาริษยา

และสุดท้ายคือ TDD ปฏิบัติตามวิธีการเข้ารหัสที่ดีที่สุด

TDD ส่งเสริมหลักการเข้ารหัสที่ดีรวมถึง DRY, KISS, YAGNI และ SOLID

หลักการ DRY (อย่าทำซ้ำตัวเอง) บอกให้นักพัฒนาหลีกเลี่ยงการทำซ้ำรหัสเดียวกันในส่วนต่าง ๆ ของระบบเดียวกันซึ่งเป็นสาเหตุที่บางครั้งเรียกว่าหลักการ DIE (ซ้ำซ้อนคือความชั่วร้าย) แห้งแนะนำให้นักพัฒนาใช้คลาสและฟังก์ชั่นเพื่อห่อหุ้มการทำงานของระบบและรักษา codebase ที่สอดคล้องกัน

หลักการของ KISS (Keep it Simple, Stupid!) ให้คำแนะนำแก่นักพัฒนาที่จะไม่พลิกโฉมวงล้อ แต่เพื่อสร้างสถาปัตยกรรมที่เรียบง่ายและชัดเจน สาระสำคัญของ KISS คือการหลีกเลี่ยงการแก้ปัญหาที่มีการออกแบบเกิน

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

SOLID ประกอบด้วยห้าหลักการในหนึ่งเดียวความรับผิดชอบเดี่ยวทดแทนแบบเปิดปิด Liskov การแยกส่วนต่อประสานและการผกผันของการพึ่งพา โดยย่อ SOLID ระบุว่าการปฏิบัติตามหลักการเหล่านี้ทำให้แอพพลิเคชั่นบำรุงรักษาและทดสอบง่ายขึ้น

สรุป TDD ช่วยในการสร้างรหัสที่ง่ายและสง่างามซึ่งง่ายต่อการบำรุงรักษา

อย่างที่โรเบิร์ตมาร์ตินได้กล่าวอย่างเหมาะสม

“ โค้ดที่ดูสะอาดตามักจะเขียนโดยคนที่ใส่ใจ”

อ้างอิง

โปรแกรมสุดขีด: Kent Beck

การพัฒนาซอฟต์แวร์แบบว่องไว: Robert Martin

Refactoring: Martin Fowler

เกี่ยวกับผู้แต่ง:

Ravi Rajan เป็นผู้จัดการโปรแกรมด้านไอทีระดับโลกซึ่งตั้งอยู่ที่เมืองมุมไบประเทศอินเดีย เขายังเป็นบล็อกเกอร์ตัวยงนักเขียนบทกวีไฮกุผู้ที่ชื่นชอบโบราณคดีและนักคลั่งไคล้ประวัติศาสตร์ เชื่อมต่อกับ Ravi บน LinkedIn, Medium และ Twitter

เรื่องนี้ได้รับการเผยแพร่ใน The Startup ซึ่งเป็นสิ่งพิมพ์ผู้ประกอบการที่ใหญ่ที่สุดของ Medium ตามด้วยผู้คน +438,678 คน

สมัครสมาชิกเพื่อรับเรื่องเด่นของเราที่นี่