การทดสอบหน่วยและการรวม: มันจะกลายเป็นภาพสะท้อนได้อย่างไร


27

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

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

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

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

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


7
น่าผิดหวังหากมีการเสนอให้บวกและลบคะแนนว่า OP ใช้แบบฟอร์มเพศที่เหมาะสมหรือไม่ แน่นอนคุณภาพของคำถามคือสิ่งที่ถูกถามและเกี่ยวข้องกับเว็บไซต์และไม่เกี่ยวกับทัศนะส่วนตัวว่าการรวมทั้งเขาและเธอจะต้องพิจารณาเรื่องเพศหรือไม่ การทะเลาะกันเองอย่างนี้จะไม่ช่วยชื่อเสียงของเว็บไซต์ ... หรือผู้ที่เกี่ยวข้อง (ฉันแค่พูด!)
S.Robins

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

2
@superM ฮ่า ๆ ! ฉันรู้คุณหมายถึงอะไร. ความถูกต้องทางการเมืองโดยลำพัง ฉันมักจะเขียนความเป็นกลางทางเพศทั้งหมดหรือใช้ "เขา" เพียงอย่างเดียวเพราะเป็นเรื่องธรรมดาที่จะเกี่ยวข้องกับการอ้างอิงดังกล่าวกับเพศของคุณ อย่างไรก็ตามความคิดเห็นของฉันมีวัตถุประสงค์เพื่อนำไปใช้โดยทั่วไปมากกว่าและไม่ได้เจาะจงเฉพาะบุคคลใดบุคคลหนึ่ง ;)
S.Robins

1
ฉันได้ลบความคิดเห็นบางส่วนแล้ว + -1 ความเห็นเป็นเสียงบริสุทธิ์และควรหลีกเลี่ยงเมื่อพวกเขาไม่ได้เพิ่มอะไรที่เป็นประโยชน์ในการโพสต์ - อ่านของเราหน้าสิทธิ์การแสดงความคิดเห็นสำหรับคำแนะนำและโปรดใช้การสนทนาดังกล่าวไปยังวิศวกรรมซอฟต์แวร์สำหรับการพูดคุย สำหรับความคิดเห็นที่ไม่เหมาะสมโปรดตั้งค่าสถานะพวกเขาเช่นนี้
yannis

คำตอบ:


13

พวกเราไม่มีใครรู้สึกแย่จริง ๆ เมื่อไม่ได้เขียนการทดสอบหน่วยในเวลาเดียวกันกับรหัสจริง

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

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


+1 สำหรับการเปลี่ยนแปลงทางวัฒนธรรมและฉันอยากให้ +1 อีกอันเพื่อให้คุณเป็นผู้นำ คำตอบที่ดี
Erik Dietrich

5

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

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

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

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

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


3

พวกเราไม่มีใครรู้สึกแย่จริง ๆ เมื่อไม่ได้เขียนการทดสอบหน่วยในเวลาเดียวกันกับรหัสจริง

ไม่แน่ใจว่าสิ่งที่คุณหมายถึง "ในเวลาเดียวกัน" แต่วิธีการเขียนพวกเขาก่อนรหัสจริงหรือไม่

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

จากประสบการณ์ของฉันการทดสอบครั้งแรก (สไตล์ TDD) เป็นสิ่งที่คุณสามารถติดได้อย่างรวดเร็วเพราะมีอย่างน้อย 2 ทันทีที่จับต้องได้และปล่อยเอนโดฟินประโยชน์:

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

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

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


3
ประโยชน์ที่ดีอีกประการหนึ่งสำหรับ TDD (โดยเฉพาะกับเครื่องมือทดสอบต่อเนื่อง) คือการตอบรับที่รวดเร็ว ในฐานรหัสขนาดใหญ่ที่สามารถสร้างและใช้งานซอฟต์แวร์ได้ตามคำสั่งของนาที TDD / CT จะเร่งความเร็วในการตอบกลับอย่างมากและเป็นการพัฒนา
Erik Dietrich

0

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

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

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


0

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

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


0

การมีกลุ่มโปรแกรมเมอร์ที่ทุกคนต้องการทำบางสิ่งบางอย่างเป็นสิ่งที่ดีเลิศ (โดยเฉพาะเมื่อพูดถึงกลุ่มใหญ่)

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

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

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

หากเป็นการยากที่จะเพิ่มมาตรฐานและกฎเกณฑ์อย่างน้อยก็ให้นึกถึงการเพิ่มเข้าไปในโครงการในอนาคต

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.