สถาปนิกซอฟต์แวร์มีบทบาทอะไรในกระบวนการพัฒนาที่ขับเคลื่อนด้วยการทดสอบ

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

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

หรือสถาปนิกซอฟต์แวร์เขียนข้อกำหนดแล้วส่งมอบให้กับนักพัฒนาเพื่อเขียนทดสอบหรือไม่

หรือคุณอนุญาตให้ข้อมูลจำเพาะเติบโตอย่างเป็นอินทรีย์โดยอนุญาตให้นักพัฒนาทั้งหมดเขียนการทดสอบของตนเองและลืมที่จะมี Software Architect?

architecture tdd

— โรเบิร์ตฮาร์วีย์
แหล่งที่มา

มีการถกเถียงกันเรื่องภาษาอังกฤษดูว่าคุณแปลว่า "เติบโตอย่างเป็นอินทรีย์" - english.stackexchange.com/questions/17853/ หรือไม่ - คุณต้องการยืนยัน :)

— JoseK

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

— Robert Harvey

คำตอบ:

Test-Driven Development เป็นเรื่องเกี่ยวกับการเขียนการทดสอบเพื่อกำหนดคุณสมบัติของโปรแกรม

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

หากต้องการตรวจสอบกระบวนการ TDD โดยย่อคือ:

กำหนดโครงการในแง่ของคุณสมบัติ
อธิบายถึงผู้มีส่วนได้เสียพฤติกรรมและเป้าหมายของแต่ละฟีเจอร์โดยใช้เรื่องราวของผู้ใช้
ระบุ givens ที่คาดไว้การเรียกเหตุการณ์ / เงื่อนไขและพฤติกรรม / ผลลัพธ์ที่เกี่ยวข้องกับเรื่องราวของผู้ใช้โดยใช้คำอธิบายการทดสอบ [และสิ่งนี้จะทำให้ 'ข้อมูลจำเพาะ' เสร็จสมบูรณ์]
เลือกชุดคุณสมบัติสำหรับการวนซ้ำแต่ละครั้ง การวนซ้ำควรสั้น [ฉันไม่ได้ทำตามขั้นตอนการวางแผนและการประมาณค่าสำหรับความกะทัดรัด]
- โค้ดการทดสอบสำหรับคุณสมบัติ (จะล้มเหลว แต่คุณต้องทำการตัดสินใจ API เพื่อให้โค้ดทดสอบ)
- ใช้คุณสมบัติเพียงพอเพื่อให้การทดสอบผ่านไป
- refactor รหัสถ้าจำเป็น
- ทำซ้ำกับการทดสอบถัดไปจนกว่าคุณสมบัติจะเสร็จสมบูรณ์
- ทำซ้ำด้วยคุณสมบัติถัดไปจนกว่าการวนซ้ำจะเสร็จสมบูรณ์
ทำซ้ำกับการทำซ้ำครั้งถัดไปจนกว่าโครงการจะเสร็จสมบูรณ์

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

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

ดังนั้นเมื่อพ้นไปแล้วคำถามเดิมก็คือ:

บทบาทของสถาปนิกซอฟต์แวร์ใน TDD คืออะไร?

และคำตอบสั้น ๆ คือ:

เช่นเดียวกับที่เคยเป็นเช่นเดียวกับที่เคยเป็น - David Byrne

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

แก้ไข 2: ขอโทษฉันพลาดจุดของคำถามย่อย! ทุกคนมีหน้าที่รับผิดชอบในการเขียนข้อกำหนด; ทั้งหมดของนักพัฒนารวมทั้งสถาปนิกถ้า / เมื่อเหมาะสมบวกลูกค้า นักพัฒนายังเขียนรหัสการทดสอบ

— Steven A. Lowe
แหล่งที่มา

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

— Robert Harvey

@ Robert hmmm ... เป็นคำถามที่ดี! ในทางเทคนิคกระสุนอื่น ๆ จะเป็น XP; ฉันเรียนรู้ XP และ TDD ในเวลาเดียวกันและไม่เคยคิดที่จะแยกพวกเขา จนถึงตอนนี้ ;-)

— Steven A. Lowe

@ Robert ได้อ่านทบทวนอีกครั้ง ดูการแก้ไข (FYI โดยใช้ XP ref extremeprogramming.orgและ TDD ref agiledata.org/essays/tdd.html#WhatIsTDD )

— Steven A. Lowe

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

— Robert Harvey

@Robert การแก้ไขช่วยให้ฉันเข้าใจคำถามได้ดีขึ้น ฉันใช้ D เป็นการพัฒนาและตีความว่าเป็นวงจรชีวิตทั้งหมดไม่ใช่แค่ส่วนของการเข้ารหัส TDDev เป็นวิธีที่ดีในการเรียนรู้ทักษะสถาปัตยกรรม - การปรับโครงสร้างมีแนวโน้มที่จะผลักดันไปในทิศทางนั้น

— Steven A. Lowe

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

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

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

— JB King
แหล่งที่มา