ต้องการเขียนการทดสอบที่สามารถบำรุงรักษาได้ในโค้ดของคุณหรือไม่? ใช้การทดสอบที่เปิดเผย

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

วิธีหนึ่งที่ฉันค้นพบในการเขียนการทดสอบความยืดหยุ่นคือการมุ่งเน้นไปที่การประกาศการตั้งค่าข้อมูล

มีประโยชน์หลายประการสำหรับโค้ดการตั้งค่าที่ประกาศ รวมถึงการลดความซ้ำซ้อนของโค้ด

อย่างไรก็ตาม สำหรับฉัน การปรับปรุงที่ใหญ่ที่สุดคือการทำให้การตั้งค่า (และการทดสอบ) อ่านง่ายขึ้น บำรุงรักษาง่ายขึ้น และเขียนง่ายขึ้น

การตั้งค่าการประกาศคืออะไร?

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

เพื่อช่วยชี้แจง ขั้นแรกเรามาดูตัวอย่างที่ ไม่ ประกาศ

ลองนึกภาพการทดสอบที่เราจำเป็นต้อง “เพาะ” ข้อมูลโดเมนพื้นฐานลงในฐานข้อมูล

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

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

แล้วเราจะเปลี่ยนโค้ดนี้ให้เป็น Declarative ได้อย่างไร? เราแยก อย่างไร จาก อะไร โดยการสร้างฟังก์ชันตัวช่วยใหม่

ฟังก์ชั่นนี้จะยอมรับวัตถุที่ อธิบายข้อมูลที่ต้องการ

ฟังก์ชัน setupPost ยังคงมีโค้ดเดียวกัน (หรือคล้ายกัน) เหมือนกับตัวอย่างแรกได้ แต่ตอนนี้รายละเอียดถูกซ่อนจากการทดสอบแล้ว

โปรดสังเกตว่าเวอร์ชันนี้ยังคงมีข้อมูลเดียวกันกับตัวอย่างขั้นตอนแรก แต่จัดเป็นออบเจ็กต์อธิบายเดียว ใช้เวลาสักครู่เพื่อเปรียบเทียบทั้งสองตัวอย่างและชื่นชมความแตกต่าง — มันเป็นเรื่องละเอียดอ่อน!

สิ่งนี้อาจช่วยให้โค้ด "แห้ง" ได้ แต่ฉันคิดว่ามีประโยชน์ที่สำคัญมากกว่าซึ่งไม่ชัดเจนตั้งแต่แรกเห็น

อ่านง่ายขึ้น

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

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

เปรียบเทียบกับเวอร์ชันขั้นตอนที่เราต้องอ่านแต่ละบรรทัดและตัดสินใจว่าเกี่ยวข้องกันอย่างไร

ง่ายต่อการบำรุงรักษา

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

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

เรียบเรียงได้ง่ายขึ้น

ประโยชน์ที่ซ่อนอยู่อีกประการหนึ่งคือคำอธิบายโพสต์ของเราเขียนได้ง่ายมากเนื่องจากเป็นเพียงข้อมูล

ตัวอย่างเช่น หากเราต้องการรวมโพสต์ไว้ในฟังก์ชันการตั้งค่าที่ใหญ่ขึ้น ตอนนี้ก็จะชัดเจนมากขึ้น นี่คือตัวอย่างการฝังโพสต์ ภายใน ฟังก์ชัน setupUser

ฟังก์ชัน setupUser นี้สามารถสร้างข้อมูล ได้มากกว่า มากกว่าฟังก์ชัน setupPost เอกพจน์ของเรา แต่เราได้นำไปใช้งานจำนวนมากแล้ว!

นั่นเป็นเพราะว่าเราสามารถนำฟังก์ชัน setupPost กลับมาใช้ใหม่ได้ มันจัดการรูปร่างที่แน่นอนนั้นแล้ว ดังนั้นมันควรจะง่ายเหมือน posts.map(setupPost); เพื่อสร้างอาร์เรย์ของโพสต์ทั้งหมด!

ส่วนที่ดีที่สุดคือคุณสามารถเขียนข้อมูลนี้ต่อไปได้ รูปร่าง user ใหม่ของเราสามารถใช้ได้เดี่ยวๆ แต่ยังรวมไว้ในรูปร่างอื่นๆ ได้ เช่น องค์กร เป็นต้น

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

ลองดูสิ!

ฉันคิดว่าแนวปฏิบัตินี้เป็นสิ่งที่พวกเราหลายคนทำในโค้ด "ปกติ" แต่มักจะหายไปจากการทดสอบแบบสุ่ม

ครั้งถัดไปที่คุณต้องบูทข้อมูลบางอย่าง อาจเป็นฐานข้อมูล ผู้จัดการของรัฐ แบ็กเอนด์จำลอง ฯลฯ ให้ลองมุ่งเน้นไปที่ฟังก์ชันการประกาศ

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