การทดสอบของคุณสื่อสารกันหรือไม่?

กุญแจสำคัญในการก้าวไปอย่างรวดเร็วคือความมั่นใจในการเปลี่ยนแปลง

ความมั่นใจในการเปลี่ยนแปลงขึ้นอยู่กับความครอบคลุมของการทดสอบ

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

อย่างไรก็ตาม การเริ่มต้น ยังไม่เพียงพอ

เกิดอะไรขึ้นกับการเริ่มต้นใช้งานตัวอย่างข้อมูล

ตัวอย่างส่วนใหญ่ที่มีจุดมุ่งหมายเพื่อเริ่มต้นอย่างรวดเร็ว นี่เป็นเรื่องจริงสำหรับ "stackoverflow", "codewhisperer", "copilot", "Bard" และ "ChatGPT" แม้แต่บทช่วยสอนของกรอบการทดสอบก็มีความผิดร่วมกัน

ทำไม

1. พวกเขามุ่งเป้าไปที่ผู้อ่านที่มีส่วนร่วมต่ำที่สุด ด้วยเหตุนี้พวกเขาจึงข้ามรายละเอียดทางวิชาชีพไป
2. พวกเขาเลื่อนส่วนที่สูงชันของช่วงการเรียนรู้ออกไป คุณจะได้พบมันหลังจากที่คุณติดกรอบการทำงานแล้วเท่านั้น
3. มีความคิดเห็นที่ขัดแย้งกันเกี่ยวกับแนวทางปฏิบัติและรูปแบบที่ดีที่สุด ดังนั้นบทช่วยสอนจะพยายามไม่แสดงความคิดเห็นหรือนำเสนอความคิดเห็นตามความเป็นจริง
   หลีกเลี่ยงการสนทนาและความคิดที่ควรสร้างแรงบันดาลใจทั้งสองวิธี
4. การปรับปรุงหลายอย่างขึ้นอยู่กับความสามารถ วัฒนธรรม และกรณีที่เป็นรูปธรรมของทีม

โดยทั่วไปแล้วผลลัพธ์จะได้ผล แต่จะเป็นเกรดนักเรียนที่ดีที่สุด

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

ความจริงที่หายไป

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

ความจริงที่เราพลาดคือ:

Codebase ถูกสร้างขึ้นเพียงครั้งเดียวแต่ได้รับการทดสอบอย่างต่อเนื่องตลอดชีวิต

ที.ที.อาร์. - ถึงเวลาฟื้นตัว

Codebase มีแนวโน้มที่จะเติบโต และ Tests ก็ต้องล้มเหลวอย่างแน่นอน
แต่ต้องใช้เวลานานเท่าใดจึงจะฟื้นตัวจากการทดสอบที่ล้มเหลว?

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

• โค้ดทดสอบ ป้องกันข้อมูลจำเพาะที่ถูกต้องซึ่งต้องยึดถือหรือไม่
  — หรือ —
• ข้อมูลจำเพาะใหม่ทำให้รุ่นเก่าล้าสมัยหรือไม่

ยิ่งคุณต้องการถอดรหัสน้อยลง TTR ของคุณก็จะยิ่งดีขึ้นเท่านั้น มีความเป็นจริงที่ดีกว่านี้อีก:

จะเกิดอะไรขึ้นหากการทดสอบสามารถสื่อสารได้อย่างแม่นยำถึงข้อกำหนดที่พวกเขาปกป้อง?

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

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

คุณสามารถข้ามส่วนที่น่าหงุดหงิดที่สุดของการฟื้นฟูไปได้...

กุญแจวัฒนธรรม

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

ซึ่งหมายความว่าพวกเราหลายคนจำเป็นต้องประดิษฐ์วงล้อแบบเดียวกันซ้ำแล้วซ้ำอีก และการที่เราลงท้ายด้วยผลลัพธ์ที่คล้ายกันก็หมายความว่ามันเป็นคำตอบที่ถูกต้อง

วัฒนธรรมที่ดีหล่อเลี้ยงการปรับปรุงอย่างต่อเนื่อง

การปฏิบัติต่อการทดสอบที่ล้มเหลวเหมือนการหยุดทำงานเป็นองค์ประกอบทางวัฒนธรรมอีกประการหนึ่ง
การเพิ่มประสิทธิภาพ TTR เป็นองค์ประกอบทางวัฒนธรรม

แต่จะไปถึงที่นั่นได้อย่างไร?

ปัจจัยนำ

มีอะไรเหมือนกันระหว่างการแจ้งเตือนการหยุดให้บริการและการแจ้งเตือนเกี่ยวกับบิลด์ที่ล้มเหลว

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

แน่นอนว่าไม่ใช่เปลวไฟที่มีขนาดเท่ากัน แต่โดยพื้นฐานแล้ว — ความรู้สึกเสียเปล่าและการสื่อสารที่ผิดพลาดแบบเดียวกัน

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

และบทเรียนก็คือ

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

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

เรามาเริ่มจากกรณีที่เลวร้ายที่สุด และปรับปรุงทีละขั้นตอนเล็กๆ น้อยๆ

ระดับ (-5) — การเริ่มต้นที่ไร้เดียงสา

น่าเสียดายที่ในฐานะที่ปรึกษา ฉันยังคงได้เห็นห้องทดสอบด้วยจิตวิญญาณเช่นนี้:

const myModule = ... //require or import the System-Under-Test

it("should work", async () => {
  await setup...;
  await step1(...);
  expect(…)... .
  await step2(...);
  expect(…)... .
  await step3(...);
  expect(…)... .

  // and a load more of those in the same function
});

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

ไปยังรูปแบบที่ได้รับการปรับปรุงล่าสุดของโพสต์นี้ — ข้าม "ที่นี่"

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

และยังมีอีกหลายทีมที่ไม่ต้องการให้โค้ดทดสอบของตนมีมากกว่านี้

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

เกิดอะไรขึ้นกับระดับ (-5)?

หลายสิ่งหลายอย่าง.

1. เป็นการแสดงความเคารพต่อคำสั่ง BDD ที่ว่า “ปฏิบัติตามถ้อยคำภาษาอังกฤษของ API“ แต่ทำในลักษณะที่ไม่ได้ให้ข้อมูลใดๆ เกี่ยวกับกรณีทดสอบหรือสถานการณ์จำลอง
2. เมื่อขั้นตอนใดล้มเหลว สถานการณ์ทั้งหมดจะพังและขั้นตอนต่อไปนี้จะไม่สามารถทำงานได้
   (ℹ️) บางครั้งฉันเห็น try-catch พยายามล้างข้อมูล มันไม่ได้ดีไปกว่านี้มากนัก เพราะคุณยังต้องประกันตัวหรือสร้างข้อผิดพลาดที่การทดสอบควรจะสร้างขึ้นใหม่ สิ่งนี้ทำให้คุณทำงานให้กับผู้ทดสอบแทนที่จะให้มันทำงานแทนคุณ
3. เมื่อสถานการณ์ล้มเหลว สิ่งบ่งชี้ทั้งหมดที่คุณได้รับคือข้อผิดพลาด เมื่อข้อผิดพลาดเกิดขึ้น — มักจะเป็นความลับและทั่วไป และไม่ได้ให้ข้อมูลที่เป็นประโยชน์มากนัก
4. เมื่อไม่กี่ขั้นตอนในสถานการณ์อาจทำให้เกิดข้อผิดพลาดที่คล้ายกัน ก็ทำให้เกิดความสับสน ทำให้ยากต่อการสังเกตจุดล้มเหลว
   (ℹ️) บางครั้งฉันเห็น consul.log การโทรที่พยายามช่วยระบุจุดในขั้นตอนการทดสอบ แต่นั่นเป็นอีกครั้งที่ได้ผลสำหรับนักวิ่งทดสอบและไลบรารีการยืนยันแทนที่จะปล่อยให้มันทำงานให้คุณ
5. เมื่อมีความล้มเหลว คุณไม่รู้ว่าผู้กระทำผิดอยู่ที่ไหน ปัญหาอยู่ในรหัสทดสอบหรือไม่? เช่น. การทดสอบล้มเหลวในการจัดเตรียม โต้ตอบ หรือทำความสะอาดหลังจาก S.U.T (System-Under-Test)?
   หรือเป็นเพราะ S.U.T ล้มเหลว เช่น การเปลี่ยนแปลงในรหัสการผลิตที่เสียหาย?
   (ℹ️) บางครั้งฉันเห็นความคิดเห็นของ //arrange หรือ //setup และ //cleanup หรือ //teardown แต่สิ่งเหล่านี้เป็นความคิดเห็นที่มองเห็นได้ในโค้ดทดสอบ โดยที่เป้าหมายคือกำจัดเราจากการอ่านโค้ดทดสอบ

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

การจัดการกับ “(ℹ️) บางครั้ง” ทั้งหมดที่กล่าวถึงข้างต้นอาจทำให้คุณเลื่อนระดับ (-5) ขึ้นไปอีกระดับได้ (-2) และยังทิ้งเธอไว้ข้างหลังแสนไกล

โครงสร้างเช่นนั้นไม่ล้มเหลวในการสัมภาษณ์งานที่ดี

ระดับ 0 — การใช้หัวเรื่อง

ระดับต่อไปที่ฉันได้เห็นคือจิตวิญญาณต่อไปนี้

describe('my-module', () => {
  // async api_one(...) 
  it('should do this when called with ...', async () => { ...
  it('should do that when called after ...', async () => { ...
  it('should throw that error when ...', async () => { ...

  // async api_two(...)
  it('should do this when called with ...', async () => { ...
  it('should do that when called after ...', async () => { ...
  it('should throw that error when ...', async () => { ...

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

ที่นี่เราอยู่ในสถานะที่ดีกว่าตัวอย่างก่อนหน้านี้มาก:

• ก็มีการจัด
• มีความคิดที่ชัดเจนเกี่ยวกับเมทริกซ์เคส
• นี่เป็นพื้นฐานสำหรับการแยกการทดสอบ - ความล้มเหลวในการทดสอบครั้งหนึ่งจะไม่ขัดขวางกรณีอื่นๆ ที่จะดำเนินต่อไป
• เมื่อการทดสอบใด ๆ ล้มเหลว คำอธิบายภาษาอังกฤษจะมาพร้อมกับผลลัพธ์การทดสอบพร้อมกับข้อผิดพลาดในการปฏิเสธ

มีอะไรผิดปกติอีก?

อันดับแรก— เริ่มจากเล็กๆ ลำดับของข้อความกลับกัน

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

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

ที่สอง— เมื่อการทดสอบล้มเหลว คุณยังคง ต้องอ่านโค้ดทดสอบ

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

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

ที่สาม — ส่วนต่างๆ จะถูกแบ่งตามความคิดเห็น ซึ่งนักข่าวข้อมูลจำเพาะไม่สามารถเข้าถึงได้

โปรแกรมรายงานคือส่วนที่ผู้ทดสอบใช้เพื่อส่งผลลัพธ์ไปยังผลลัพธ์การทดสอบ นักข่าวส่วนใหญ่ปล่อยบทสรุปความล้มเหลวออกมาในท้ายที่สุด

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

ความคิดเห็นไม่สามารถเข้าถึงได้สำหรับผู้รายงานการทดสอบ – ส่งคุณกลับไปอ่านโค้ดทดสอบ

ด้วยระเบียบวินัยบางประการ รายงานนี้สามารถทำหน้าที่เป็นข้อกำหนดของซอฟต์แวร์ได้ เช่น. — เอกสารที่สามารถอ่านได้ซึ่งมาจากโค้ดทดสอบของคุณ

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

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

(ℹ️) โปรดทราบว่าคุณไม่จำเป็นต้องเขียนการทดสอบก่อนหรือทำงานร่วมกับ TDD/BDD เพื่อใช้นักข่าวข้อมูลจำเพาะ เรียกใช้โปรแกรมรายงานข้อมูลจำเพาะทุกครั้งที่คุณต้องการดูว่าแผนผังทดสอบของคุณบอกเล่าเรื่องราวอะไร :)

สุดท้าย— มีบางสิ่งที่คุณสามารถขอให้ผู้ทดสอบทำเพื่อคุณได้:

1. ดำเนินการตั้งค่าและล้างข้อมูลให้กับคุณ
2. ตรวจสอบให้แน่ใจว่าหากการทดสอบล้มเหลว การล้างข้อมูลจะยังคงเกิดขึ้น
3. ไม่ผ่านการทดสอบที่มีการตั้งค่าหรือการล้างข้อมูลล้มเหลว
4. แจ้งข้อผิดพลาดหากการทดสอบล้มเหลวในการตั้งค่าหรือระหว่างการทดสอบ

การแก้ไขปัญหาทั้ง 4 ข้อนี้จะทำให้คุณไปถึงระดับ (4)

ระดับ (4) — มืออาชีพขั้นพื้นฐาน

describe('my-module', () => {
  context('when used in cased A…', () => {
    before(async () => { ... //case setup
    it('should fulfil requirement 1…', () => { ...
    it('should fulfil requirement 2…', () => { ...
    ...
    after(async () => { ...  //cleanup
  })
  context('when used in case B…', () => {
    before(async () => { ... //case setup
    it('should fulfil requirement 1…', () => { ...
    it('should fulfil requirement 2…', () => { ...
    ...
    after(async () => { ... //cleanup

Mocha BDD แนะนำ api context สำหรับการอธิบายบริบทของเคส อันที่จริง มันเป็นนามแฝงสำหรับ describe Jest รองรับเพียง describe และให้คุณซ้อนมันได้เหมือนมอคค่า ดังนั้นการใช้ describe จะทำให้ทุกอย่างเหมือนกันระหว่างทั้งสอง

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

สรุป

จนถึงตอนนี้เราทำอะไรสำเร็จไปแล้วบ้าง?

1. ผู้ทดสอบทำให้แน่ใจว่ารหัสการตั้งค่าและการรื้อถอนจะทำงานแม้ว่าสถานการณ์จะล้มเหลวก็ตาม ไม่ต้องลองจับ ไม่มี console.log ผู้ทดสอบจะบอกคุณเกี่ยวกับความล้มเหลวแต่ละครั้งอย่างชัดเจนว่าตัวจัดการล้มเหลวประการใด มันจะสังเกตว่าเป็นตะขอสำหรับการตั้งค่า/การรื้อถอนหรือการทดสอบเอง
2. บริบทและกรณีจะถูกสื่อสารด้วยชื่อเรื่องที่จะถูกพิมพ์สำหรับการทดสอบที่ล้มเหลวแต่ละครั้ง
3. แต่ละบริบทคือการปิดตัวเองด้วยตัวแปรของตัวเอง คุณสามารถใช้มันเพื่อเก็บสถานะที่เกี่ยวข้องกับกรณีทดสอบได้

(ℹ️) มอคค่าให้คุณคงสถานะบน this คุณจะต้องเขียนตัวจัดการทั้งหมดของคุณเป็นฟังก์ชันแบบเก่าแทนที่จะเป็นฟังก์ชันลูกศร
โดยส่วนตัวแล้ว ฉันเกลียดการใช้ this ใน JavaScript และชอบที่จะคงสถานะของฉันไว้ที่สมาชิกของการปิด แต่คุณทำ...

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

แล้วไงต่อไป?

มีอีกหลายระดับให้ทำคะแนน
ตัวอย่างเช่น:

1. คุณสามารถเยาะเย้ยกับสายลับและต้นขั้วได้
   (ℹ️) แต่ระวัง "อย่าหลงทางในขอบเขตของหน่วย" และพลาดการทดสอบว่าระบบทำงานได้โดยรวม
2. คุณสามารถใช้โรงงานกรณีทดสอบได้ สิ่งนี้ช่วยให้คุณแสดงการทดสอบของคุณโดยมุ่งเน้นไปที่ปัจจัยนำเข้า ผลลัพธ์ และความคาดหวังเพียงอย่างเดียว ดีกว่าการคัดลอกและวางโครงสร้างทั้งหมดแล้วแฮ็กเข้าไปข้างใน
3. คุณสามารถจัดระเบียบข้อมูลการติดตั้ง อำนวยความสะดวกในการตั้งค่าและการล้างข้อมูล และจัดระเบียบเป็นโมดูลเพื่อให้คุณสามารถนำเข้าการตั้งค่า/การแยกส่วน และนำเข้าข้อมูลที่แทรกเข้าไปได้ สิ่งนี้ช่วยให้คุณใช้และยืนยันกับเอนทิตีเชิงตรรกะแทนค่าที่ฮาร์ดโค้ดในการทดสอบของคุณ
4. คุณสามารถ จัดทำรายงานความครอบคลุม และผสานรวมการตรวจจับกลิ่นรหัสได้ จากนั้นคุณสามารถใช้วงล้อเลื่อนของแท่งคุณภาพได้

ตอนนี้ถึงตาคุณที่จะสอนฉันแล้ว:
- LMK: ฉันควรพูดถึงเรื่องไหนก่อน
- ตบมือให้ฉันดูระหว่าง 1 ถึง 50 คุณชอบงานนี้อย่างไร
💙 ฉันขอขอบคุณการมีส่วนร่วมและเวลาของคุณ 💙

ขอขอบคุณเป็นพิเศษกับ Yonatan Kra คนดีๆ ที่ฉันเคยร่วมงานด้วยในอดีต "วิดีโอของเขา" ทำให้ฉันกลับไปนั่งเขียนทั้งหมดนี้ในที่สุด