ทำไมไม่เขียนการทดสอบทั้งหมดพร้อมกันเมื่อทำ TDD

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

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

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

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

การใช้งานในอนาคตใด ๆ (ซึ่งการทดสอบครั้งต่อไปที่คุณเขียน) จะมาจากการออกแบบที่เรียบง่ายเริ่มต้นแทนที่จะใช้วิธีแก้ปัญหาการออกแบบที่ไม่ดีกับกรณีที่ซับซ้อนมากขึ้น

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

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

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

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

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

ฉันทำแบบทดสอบทั้งหมดที่ฉันสามารถคิดได้ล่วงหน้าในขณะที่ "ระดมสมอง" แต่ฉันเขียนการทดสอบแต่ละครั้งเป็นความคิดเห็นเดียวที่อธิบายการทดสอบ

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

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

ตอนนี้ถ้าคุณใช้ระบบอย่างโฟลว์สเปคเมื่อการทดสอบถูกเขียนเป็น“ ภาษาอังกฤษ” คุณอาจต้องการให้ลูกค้าเห็นด้วยกับชุดของการทดสอบในขณะที่คุณมีเวลามากกว่าที่จะสร้างการทดสอบเพียงครั้งเดียว

แนวคิดเบื้องหลัง TDD คือการทำซ้ำอย่างรวดเร็ว

หากคุณมีการทดสอบจำนวนมากที่ต้องเขียนก่อนที่คุณจะต้องเขียนรหัสของคุณมันยากที่จะกำหนดรหัสซ้ำอีกครั้ง

หากไม่มีการปรับเปลี่ยนรหัสอย่างง่ายคุณจะสูญเสียสิทธิประโยชน์มากมายของ TDD

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

หากคุณต้องการข้อมูลจำนวนมากคุณมีตัวเลือกมากมาย:

• กระดานไวท์บอร์ด
• เรื่องราวของผู้ใช้
• ความคิดเห็น
• ปากกาและกระดาษดี ol

ขอให้สังเกตว่าไม่มีที่ไหนในรายการนี้คือคอมไพเลอร์ :-)

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

คิดว่าการทดสอบแต่ละบทที่คุณเขียนเป็นทฤษฎีในสมุดบันทึกทางวิทยาศาสตร์ เมื่อคุณเติมโน้ตบุ๊กคุณจะพิสูจน์ทฤษฎีของคุณและสร้างใหม่ บางครั้งการพิสูจน์ทฤษฎีใหม่หักล้างทฤษฎีก่อนหน้าดังนั้นคุณต้องแก้ไข เป็นการง่ายกว่าที่จะพิสูจน์ทฤษฎีเดียวในแต่ละครั้งแทนที่จะพยายามพิสูจน์ว่าครั้งละ 20 ทฤษฎี

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

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

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

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

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

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

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

ฉันได้ทำงานในโครงการที่นักพัฒนาที่เขียนการทดสอบ (ล้มเหลว) นั้นแตกต่างจากนักพัฒนาที่ใช้รหัสที่จำเป็นเพื่อให้ผ่านและฉันพบว่ามันมีประสิทธิภาพจริงๆ

ในกรณีนั้นเฉพาะการทดสอบที่เกี่ยวข้องกับการวนซ้ำปัจจุบันถูกเขียนเพียงครั้งเดียว ดังนั้นสิ่งที่คุณแนะนำจะเป็นไปได้อย่างสมบูรณ์ในสถานการณ์ประเภทนั้น

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

วัฏจักร Red-Green-Refactor เป็นรายการตรวจสอบที่มีไว้สำหรับนักพัฒนาใหม่สำหรับ TDD ฉันว่ามันเป็นความคิดที่ดีที่จะทำตามรายการตรวจสอบนี้จนกว่าคุณจะรู้ว่าจะต้องติดตามเมื่อใดและเมื่อใดที่คุณสามารถทำลายมันได้ (นั่นคือจนกว่าจะรู้ว่าไม่ต้องถามคำถามนี้ใน stackoverflow :)

หลังจากทำ TDD มาเกือบทศวรรษแล้วฉันสามารถบอกคุณได้ว่าฉันไม่ค่อยมีใครเขียนการทดสอบที่ล้มเหลวหลายครั้งก่อนที่ฉันจะเขียนรหัสการผลิต

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

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

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

แต่นี้เป็นสิ่งที่คุณไม่ผสมขึ้นกับการทดสอบหน่วยของคุณซึ่งเป็นมากใกล้ nitty รายละเอียดการดำเนินงานที่มีทรายที่มีจำนวนมากที่เกี่ยวข้องกับ API กรณีขอบปัญหาเริ่มต้น ฯลฯ เน้นหนักในการที่รายการภายใต้การทดสอบซึ่งเป็นสิ่งประดิษฐ์การดำเนินงาน

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

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

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

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

ฉันเดาว่าถ้าเรามุ่งเน้นไปที่แอพพลิเคชั่นทางธุรกิจแบบทั่วไปมากขึ้นแล้ว TDD ด้วยวิธีการทดลองและข้อผิดพลาดที่รวดเร็วที่สุดมักจะชนะในแง่ของประสิทธิภาพ

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

describe "Your API" do

  it "should foo" do
    pending "braindump from 4/2"
  end

  it "should bar" do
    pending "braindump from 4/2"
  end

  it "should not biz" do
    pending "braindump from 4/2"
  end

end