คุณสามารถ TDD สำหรับข้อบกพร่องที่สามารถทดสอบได้หลังจากที่ได้รับการแก้ไขแล้วเท่านั้น?

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

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

ในฟังก์ชั่นง่าย ๆ เช่นlet sum = (a, b) => a - bคุณสามารถเขียนการทดสอบว่าทำไมsum(1, 2)ไม่เท่ากัน3ก่อนที่จะเขียนโค้ดใด ๆ

ในกรณีที่ฉันอธิบายฉันไม่สามารถทดสอบได้เพราะฉันไม่ทราบว่าการตรวจสอบคืออะไร (ฉันไม่รู้ว่าการยืนยันควรเป็นอย่างไร)

วิธีแก้ไขปัญหาที่อธิบายคือ:

let dataTransfer = e.dataTransfer
let canvas = document.createElement('canvas');
canvas.style.opacity = '0';
canvas.style.position = 'absolute';
canvas.style.top = '-1000px';
dataTransfer.effectAllowed = 'none';

document.body.appendChild(canvas);
dataTransfer.setDragImage(canvas, 0, 0);

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

สิ่งที่จะเป็นวิธีการ TDD กับปัญหานี้? การเขียนการทดสอบก่อนรหัสบังคับหรือไม่ก็ได้?

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

• วิธีการทดสอบพฤติกรรมบางอย่างของส่วนต่อประสานผู้ใช้แบบกราฟิกโดยอัตโนมัติ

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

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

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

สิ่งที่จะเป็นวิธีการ TDD กับปัญหานี้? การเขียนการทดสอบก่อนรหัสบังคับหรือไม่ก็ได้?

วิธีหนึ่งคือการใช้อนาล็อกของการแก้ปัญหาการขัดขวาง

James Shoreอธิบายด้วยวิธีนี้

เราทำการทดลองขนาดเล็กและแยกเมื่อเราต้องการข้อมูลเพิ่มเติม

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

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

ม้าสำหรับหลักสูตร

แก้ไข:

คุณจะทำการทดสอบโดยอัตโนมัติได้อย่างไรหากดวงตาของมนุษย์มองเห็นข้อบกพร่อง

ฉันต้องการแนะนำการสะกดที่แตกต่างกันเล็กน้อย: "คุณจะทดสอบอัตโนมัติได้อย่างไรถ้าการทดสอบอัตโนมัติไม่คุ้มค่า"

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

มีสองวิธีในการสร้างการออกแบบซอฟต์แวร์: วิธีหนึ่งคือทำให้ง่ายจนไม่มีข้อบกพร่อง - CAR Hoare

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

สำหรับการทดสอบการรวมรหัสของเรากับรหัสของบุคคลที่สามที่แท้จริงเราต้องอาศัยเทคนิคอื่น ๆ (การตรวจสอบด้วยภาพการสนับสนุนทางเทคนิคการมองในแง่ดี .... )

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

การทดสอบรอบ UI / GUI สามารถทำได้ค่อนข้างดีกว่าในแง่ของการทดสอบการยอมรับ (การทดสอบกึ่งกลางของฟีเจอร์ / ธุรกิจ)

สำหรับเว็บฉันคิดว่าเฟรมเวิร์กเช่น selenium webdriver มีศักยภาพที่จะเข้าใกล้การทดสอบที่ถูกต้อง แต่ค่าใช้จ่ายในการเริ่มต้นอาจสูงกว่านี้เล็กน้อยและเป็นการเปลี่ยนแปลงในการไหลของ TDD ที่เกี่ยวข้องกับการทดสอบหน่วย .

ส่วนที่จะช่วยในสถานการณ์ของคุณโดยเฉพาะคือสิ่งที่เรียกว่ารูปแบบวัตถุหน้า ( https://www.guru99.com/page-object-model-pom-page-factory-in-selenium-ultimate-guide.html ) สิ่งนี้ประสบความสำเร็จในการแม็พ GUI ของรันไทม์อย่างชัดเจนกับโค้ดบางส่วนโดยการตั้งชื่อเมธอด / เหตุการณ์ / สมาชิกคลาส

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

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

ภาพผีมีลักษณะอย่างไร หากคุณสร้าง ummy จำลองที่มีสีเดียวที่รู้จักซึ่งคุณใส่องค์ประกอบที่ลากได้ จะมีสีที่เฉพาะเจาะจงอยู่หรือไม่ถ้ามีภาพผี

จากนั้นการทดสอบสามารถทดสอบสีของภาพผีได้

การทดสอบดังกล่าวจะมีความทนทานและเหมาะสม