เพื่อทดสอบระบบ A, แยกผลข้างเคียง

การออกผลข้างเคียงเป็นหนึ่งในวิธีที่ดีที่สุดในการสร้างรหัสที่ทดสอบได้

รูปภาพการแข่งขันชกมวยระหว่างนักสู้ชายสองคน ใบหน้าของพวกเขาอยู่นอกกรอบ นักสู้ทางด้านซ้ายได้ส่งฮุกซ้ายไปทางนักสู้ทางด้านขวา นักมวยที่อยู่ทางขวาสวมกางเกงขาสั้นสีแดงที่มีสัญลักษณ์ขนาดเล็กของสหภาพโซเวียต

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

อย่างไรก็ตามมันก็เป็นกลิ่น

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

นี่คือเหตุผล

สมมติว่ามีเซิร์ฟเวอร์ที่ส่งคืนรายการโพสต์และฟังก์ชั่นที่ใช้การตอบสนองจากเซิร์ฟเวอร์นั้นเพื่อสร้างรายการชื่อเรื่อง การทดสอบฟังก์ชั่นใช้ Nock เพื่อทำให้การตอบสนองจากเซิร์ฟเวอร์สมบูรณ์:

ไดอะแกรมที่แสดงบล็อกทางด้านซ้ายพร้อมคำบรรยาย

รหัสมีความครอบคลุมที่ดี อย่างไรก็ตามมีปัญหาบางอย่างกับมัน

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

เช่นเดียวกับหากคุณทำการเปลี่ยนแปลง URL ส่วนหัวหรือพารามิเตอร์ที่ Nock กำลังขัด คุณต้องเปลี่ยนการทดสอบแม้ว่าพฤติกรรมของระบบจะยังคงเหมือนเดิม:

ฟังก์ชั่น "สร้างรายการโพสต์" คือ System Under Test (SUT) ข้อมูลจากการโทร HTTP คือแหล่งข้อมูล

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

ไดอะแกรมที่แสดงบล็อกทางด้านซ้ายพร้อมคำบรรยาย“ รายการชื่อเรื่อง” ลูกศรหนึ่งชี้ไปที่บล็อกที่มีคำอธิบายภาพ“ แหล่งข้อมูลในหน่วยความจำ” ลูกศรชี้ไปที่บล็อกที่มีคำบรรยายภาพ“ HTTP Server Data” ที่มา.”

สำหรับสภาพแวดล้อมการทดสอบคุณสามารถฉีด“ แหล่งข้อมูลในหน่วยความจำ” สำหรับการผลิตคุณสามารถใช้“ แหล่งข้อมูลเซิร์ฟเวอร์ HTTP”

“ อินเทอร์เฟซทั่วไป” ใน JSFiddle ก่อนหน้านี้เป็นวิธี“ ค้นหาชื่อโพสต์” ไม่ว่าคุณจะสร้างอินเทอร์เฟซอย่างไรคุณสามารถควบคุมผู้โทรทั้งหมดได้ ดังนั้นการเปลี่ยนแปลงจึงตรงไปตรงมา Martin Fowler เรียกว่า "ส่วนต่อประสานที่ไม่ได้เผยแพร่"

ในทางกลับกันถ้าเซิร์ฟเวอร์ผิดสัญญาของส่วนต่อประสานที่เผยแพร่ของพวกเขากล่าวว่าการเปลี่ยนแปลงคุณสมบัติของคลาสจาก post-title เป็น article-title คุณจะต้องเปลี่ยนการใช้งานแหล่งข้อมูล คุณไม่จำเป็นต้องทำการเปลี่ยนแปลงทุกที่

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

ด้วยการออกแบบใหม่คุณได้แยกแหล่งข้อมูลออกจากระบบภายใต้การทดสอบ ดังนั้นคุณสามารถลบ Nock ได้

การออกแบบใหม่ยังช่วยลดงานที่จำเป็นในการเพิ่มกฎใหม่ลงในระบบโดยไม่ต้องคัดลอก / วาง:

ถึงกระนั้น "แหล่งข้อมูลเซิร์ฟเวอร์ HTTP" ยังมีตรรกะที่ยังไม่ผ่านการทดสอบภายในฟังก์ชันส่วนตัว

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

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

คุณผลักผลข้างเคียงออกจากตรรกะอย่างสมบูรณ์ ในกรณีนี้ฟังก์ชั่น "ขอจริง" คือผลข้างเคียง ตอนนี้คุณสามารถใช้ Nock เพื่อปกปิดสิ่งนั้นได้

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

Nock มีประโยชน์ในการ stub การเชื่อมต่อในเลเยอร์ HTTP และเพื่อให้การตอบสนองคงที่ อย่างไรก็ตามใช้มันเท่าที่จำเป็น สำหรับการทดสอบทุกครั้งที่คุณเริ่มต้นคุณจะเพิ่มการมีเพศสัมพันธ์ที่สำคัญและค่าใช้จ่ายในการเปลี่ยนแปลง

หากไม่ได้ใช้เท่าที่จำเป็น Nock สามารถสร้าง Nock Hell ได้

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

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

แยกผลข้างเคียงและ จำกัด การใช้เครื่องมือเช่น Nock ตามขอบเขตของแอปพลิเคชัน

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

เข้าร่วมการต่อสู้ผลักผลข้างเคียงจากนั้น…ใส่เข้าไป

ขอบคุณที่อ่าน. หากคุณมีข้อเสนอแนะโปรดติดต่อฉันทาง Twitter, Facebook หรือ Github

ขอบคุณ Eduardo Slompo และ Guilherme J. Tramontina สำหรับคำติชมที่ลึกซึ้งของพวกเขาต่อโพสต์นี้