ประเภทของการทดสอบหน่วยตามประโยชน์

จากมุมมองค่าฉันเห็นการทดสอบหน่วยสองกลุ่มในทางปฏิบัติของฉัน:

1. การทดสอบที่ทดสอบตรรกะบางอย่างที่ไม่สำคัญ การเขียนพวกเขา (ไม่ว่าจะก่อนนำไปใช้หรือหลัง) เปิดเผยปัญหา / ข้อบกพร่องที่อาจเกิดขึ้นและช่วยให้มั่นใจในกรณีที่ตรรกะเปลี่ยนไปในอนาคต
2. การทดสอบที่ทดสอบตรรกะเล็กน้อยบางอย่าง การทดสอบเหล่านั้นเหมือนรหัสเอกสาร (โดยทั่วไปจะมี mocks) มากกว่าการทดสอบ เวิร์กโฟลว์การบำรุงรักษาของการทดสอบเหล่านั้นไม่ใช่ "ตรรกะบางอย่างเปลี่ยนไปการทดสอบกลายเป็นสีแดง - ขอบคุณพระเจ้าที่ฉันเขียนการทดสอบนี้" แต่ "การเปลี่ยนแปลงรหัสเล็กน้อยบางการทดสอบกลายเป็นลบเชิงลบ - ฉันต้องรักษา (เขียนใหม่) การทดสอบ . ส่วนใหญ่การทดสอบเหล่านั้นไม่คุ้มค่าที่จะรักษา และจากประสบการณ์ของฉันในหลาย ๆ ระบบการทดสอบเหล่านั้นก็เหมือนกับ 80% ของการทดสอบทั้งหมด

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

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

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

เมื่อคุณยอมรับว่าคุณดูดที่เขียนการทดสอบหน่วยและต้องการที่จะดีขึ้นคุณจะต้องเผชิญกับรูปแบบการทดสอบที่ทันสมัยหรือวิธีการที่แตกต่างกันในไม่ช้า โดยวิธีการทดสอบฉันหมายถึงการปฏิบัติเช่นการทดสอบครั้งแรกหรือสิ่งที่ Andrew Binstock ของ DrDobbs ทำซึ่งเขียนการทดสอบไปพร้อมกับรหัส ทั้งคู่มีข้อดีและข้อเสียของพวกเขาและฉันปฏิเสธที่จะลงรายละเอียดส่วนตัวใด ๆ เพราะนั่นจะกระตุ้นให้เกิดสงครามลุกเป็นไฟ หากคุณไม่สับสนเกี่ยวกับวิธีการเขียนโปรแกรมที่ดีกว่ารูปแบบของการทดสอบอาจจะเป็นการหลอกลวง คุณควรใช้ TDD, BDD, การทดสอบตามคุณสมบัติหรือไม่? JUnit มีแนวคิดขั้นสูงที่เรียกว่าทฤษฎีที่ทำให้เส้นแบ่งระหว่าง TDD และการทดสอบตามคุณสมบัติ จะใช้เมื่อใด

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

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

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

[1] ความเสียหายของเปรียวโดย Andrew Binstock

[2] การตอบสนองต่อการตอบสนองของบทความก่อนหน้า

[3] การตอบสนองต่อการทุจริตของเปรียวโดยลุงบ๊อบ

[4] การตอบสนองต่อการทุจริตของ Agile โดย Rob Myers

[5] ทำไมต้องกังวลกับการทดสอบแตงกวา?

[6] คุณกำลังคิดผิด

[7] ถอยห่างจากเครื่องมือ

[8] ความเห็นเกี่ยวกับ 'ตัวเลขโรมันกะตะพร้อมคำอธิบาย'

[9] ตัวเลขโรมันกะตะพร้อมคำอธิบาย

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

อย่างที่คุณพูดมีสองขั้วสุดขีดและฉันก็ไม่เห็นด้วยอย่างใดอย่างหนึ่งเช่นกัน

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

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

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

นี่คือสิ่งที่ฉันใช้: การทดสอบทั้งหมดมีค่าใช้จ่าย:

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

นอกจากนี้เรายังตั้งใจให้การทดสอบทั้งหมดนั้นให้ผลประโยชน์ (และจากประสบการณ์ของผมการทดสอบเกือบทั้งหมดให้ผลประโยชน์):

• สเปค
• เน้นมุมกรณี
• ป้องกันการถดถอย
• การตรวจสอบอัตโนมัติ
• ตัวอย่างการใช้ API
• การหาปริมาณของคุณสมบัติเฉพาะ (เวลาพื้นที่)

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

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

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

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

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

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

เป็นไปไม่ได้ที่จะกำจัดความซับซ้อนทั้งหมดออกจากระบบเหล่านี้ แต่งานของเราคือเท่าที่จะทำได้เพื่อลดและจัดการความซับซ้อนนั้น

หน่วยทดสอบการทดสอบที่ยืนยันตัวอย่างเช่นการจองถูกโพสต์เรียบร้อยแล้วในสามระบบที่แตกต่างกันรายการบันทึกจะถูกสร้างขึ้นและการยืนยันทางอีเมลจะถูกส่งออก?

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

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

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

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

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

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

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

ความคิดของ "การทดสอบหน่วย" การทดสอบตรรกะที่ไม่ซับซ้อนซับซ้อนและซับซ้อนคือฉันคิดว่าเป็นบิตของ oxymoron

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

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

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

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

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

แน่นอนว่านี่เป็นเพียงข้อคัดค้านของฉัน แต่การใช้เวลาสองสามเดือนที่ผ่านมาในการเรียนรู้การเขียนโปรแกรมฟังก์ชั่นใน fsharp (มาจากพื้นหลัง C #) ทำให้ฉันตระหนักถึงบางสิ่ง

ตามที่ระบุไว้ OP มักจะมี "การทดสอบหน่วย" สองประเภทที่เราเห็นในแต่ละวัน การทดสอบที่ครอบคลุมทั้งในและนอกของวิธีการซึ่งโดยทั่วไปจะมีค่ามากที่สุด แต่ยากที่จะทำเพื่อ 80% ของระบบซึ่งน้อยกว่าเกี่ยวกับ "อัลกอริทึม" และเพิ่มเติมเกี่ยวกับ "abstractions"

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

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

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