การทดสอบหน่วยทีมมือใหม่ต้องทำการทดสอบหน่วย

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

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

แก้ไข

เพื่อความกระจ่างแจ้งไม่มีใครในทีม (นอกเหนือจากตัวเอง) ที่มีการเปิดรับ / ทดสอบหน่วยใด ๆ และเราวางแผนที่จะใช้ฟังก์ชั่นทดสอบหน่วยที่สร้างขึ้นใน Visual Studio

ฝึกเกี่ยวกับข้อบกพร่อง / ข้อบกพร่องที่มีอยู่

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

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

1. เงื่อนไขที่คาดหวังและ postcondition
2. ผลลัพธ์ที่ปัจจุบันไม่ใช่สิ่งที่คาดหวังและละเมิดเงื่อนไขเบื้องต้น / หลังเวลาที่กำหนด

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

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

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

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

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

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

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

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

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

ประเด็นสำคัญอื่น ๆ :

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

• ตรวจสอบให้แน่ใจว่าการทดสอบนั้นใช้งานง่ายและไม่ต้องใช้เวลานานในการจบ (หรือโกงเช่นโดยใช้ db ในหน่วยความจำสำหรับการทดสอบ)

• ติดตั้งซอฟต์แวร์รวมอย่างต่อเนื่องเพื่อให้พบการทดสอบที่เสียหายทันที

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

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

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

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

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

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

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

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

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

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