คำถามติดแท็ก tdd

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

27 books  tdd 

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

27 java  unit-testing  tdd  eclipse 

ใน บริษัท ที่ฉันเคยทำงานให้ผู้บริหารยืนยันว่าการครอบคลุมโค้ดด้วยการทดสอบหน่วยต้องเป็น 99% หรือมากกว่า ส่งผลให้มีการเขียนการทดสอบมากกว่าโค้ด เราใช้เวลา 3 วันในการเขียนแบบทดสอบสำหรับชั้นเรียนเดียวที่ต้องใช้เวลาทั้งวัน อย่างไรก็ตามฉันได้เรียนรู้เกี่ยวกับ TDD เครื่องมือทดสอบแนวปฏิบัติและอื่น ๆ มากมาย ใน บริษัท ที่ฉันทำงานหลังจากนั้นการทดสอบหน่วยเป็นสิ่งที่ไม่รู้จัก มันเป็นสิ่งที่บางคนอาจเคยได้ยินมาก่อน ฉันพยายามที่จะแนะนำให้รู้จักกับแนวคิดของการทดสอบหน่วย แต่ไม่มีผล ตอนนี้เป็นของตนเองผมสงสัย - วิธีการมากเวลามันจำเป็นที่จะต้องใช้จ่ายในการทดสอบหน่วย? การพัฒนาส่วนใหญ่เป็น iPhone / Android ส่วนใดของรหัสที่ควรครอบคลุมในการทดสอบ

27 project-management  unit-testing  tdd  time 

ฉันกำลังเรียนรู้เกี่ยวกับ TDD และพยายามนำไปใช้ในโครงการส่วนตัวของฉัน ฉันยังใช้การควบคุมเวอร์ชันอย่างกว้างขวางในหลายโครงการเหล่านี้ ฉันสนใจในการทำงานร่วมกันของเครื่องมือทั้งสองนี้ในกระบวนการทำงานทั่วไปโดยเฉพาะอย่างยิ่งเมื่อมันมาถึงจุดสูงสุดเพื่อให้ความมุ่งมั่นเล็ก ๆ นี่คือตัวอย่างบางส่วนที่นึกถึง: ฉันเริ่มต้นโครงการใหม่และเขียนการทดสอบอย่างง่ายเพื่อสร้างคลาสแบบ as-yet-nonexistent ฉันควรจะทำแบบทดสอบก่อนเขียนชั้นแม้ว่าการทดสอบจะไม่ได้รวบรวม หรือฉันควรเริ่มต้นจำนวนขั้นต่ำของรหัสที่จำเป็นสำหรับการทดสอบเพื่อคอมไพล์ก่อนที่จะคอมมิท? ฉันพบข้อบกพร่องและเขียนการทดสอบเพื่อสร้างใหม่ ฉันควรคอมมิชชันทดสอบที่ล้มเหลวหรือใช้การแก้ไขข้อบกพร่องแล้วคอมมิท? เหล่านี้เป็นสองตัวอย่างที่มาถึงใจทันที อย่าลังเลที่จะให้ตัวอย่างเพิ่มเติมในคำตอบของคุณ แก้ไข: ฉันตั้งสมมติฐานในทั้งสองตัวอย่างว่าทันทีหลังจากเขียนการทดสอบฉันจะเขียนโค้ดเพื่อทำการทดสอบ สถานการณ์อื่นอาจเกิดขึ้น: ฉันทำงานในโครงการที่ใช้ TDD เป็นเวลาหลายชั่วโมงโดยไม่ต้องทำอะไร ในที่สุดเมื่อฉันลงมือทำฉันต้องการที่จะเลิกงานของฉันเป็นชิ้นเล็ก ๆ (Git ทำให้สิ่งนี้ค่อนข้างง่ายแม้ว่าคุณต้องการจะยอมรับการเปลี่ยนแปลงบางอย่างในไฟล์เดียว) ซึ่งหมายความว่าคำถามของฉันเป็นเรื่องเกี่ยวกับสิ่งที่จะกระทำตามที่เป็นอยู่เมื่อใดที่จะกระทำ

25 version-control  tdd  workflows  personal-projects 

คำถามนี้ถูกโยกย้ายจาก Stack Overflow เพราะสามารถตอบได้ใน Software Engineering Stack Exchange อพยพ 8 ปีที่แล้ว ในการเริ่มต้นผมไม่คิดว่านี่เป็นซ้ำของคำถามอื่น ๆในการทดสอบหน่วย สิ่งที่ฉันต้องการความช่วยเหลือคือการสื่อสารถึงคุณค่าของมันกับทีมโปรแกรมเมอร์นักวิเคราะห์ผู้จัดการและผู้ทดสอบ โดยการทดสอบอัตโนมัติฉันไม่คิดว่าฉันต้องแยกความแตกต่างระหว่างการทดสอบหน่วย (เช่น JUnit), BDD (เช่น JBehave, ฟิตเนส) และ UI (Selenium, Watir) เพราะฉันคิดว่าพวกเขาให้คุณค่าที่คล้ายคลึงกัน (แต่รู้สึกอิสระที่จะ เขียนคำตอบที่ไม่เห็นด้วย :)) ต่อไปนี้เป็นรายการที่ฉันระบุฉันกำลังมองหาคำตอบที่ช่วยขยายหรือปรับแต่ง: ประหยัดเวลา / ค่าใช้จ่าย : การเขียนแบบทดสอบอัตโนมัติอาจใช้เวลามากกว่ากรณีทดสอบแบบเป็นลายลักษณ์อักษร อย่างไรก็ตามการพิจารณาการทดสอบนั้นดำเนินการหลายครั้งงานส่วนเพิ่ม (เช่นราคา / เวลา) ในการดำเนินการทดสอบอัตโนมัตินั้นมีคำสั่งไม่มากนัก การทดสอบอัตโนมัตินั้นมีราคาถูกในการใช้งานช่วยให้การเปลี่ยนระบบเป็นไปอย่างสะดวก เอกสาร : ไม่มีวิธีที่แท้จริงที่จะรู้ว่าระบบทำงานอย่างไรกว่าการทดสอบ เอกสารอื่น ๆ มักจะล้าสมัยทันทีที่มีการเขียน แต่การทดสอบ (อย่างน้อยผู้ที่ผ่าน) เปิดเผยว่าสิ่งที่ใช้งานได้จริง …

25 unit-testing  selenium  tdd  bdd 

ฉันพยายามฝึกฝน TDD โดยใช้มันเพื่อพัฒนาวิเช่น Bit Vector ฉันบังเอิญใช้สวิฟท์ แต่นี่เป็นคำถามที่ไม่เชื่อเรื่องภาษา My BitVectoris คือตัวstructที่เก็บ single UInt64และนำเสนอ API เหนือมันที่ให้คุณปฏิบัติต่อมันเหมือนกับคอลเลกชัน รายละเอียดไม่สำคัญมาก แต่มันค่อนข้างง่าย 57 บิตสูงเป็นบิตหน่วยเก็บข้อมูลและ 6 บิตด้านล่างเป็นบิต "นับ" ซึ่งจะบอกคุณว่าบิตหน่วยเก็บข้อมูลจำนวนหนึ่งเก็บค่าที่มีอยู่จริงได้อย่างไร จนถึงตอนนี้ฉันมีความสามารถที่เรียบง่ายไม่กี่อย่าง: เครื่องมือเริ่มต้นที่สร้างเวกเตอร์บิตที่ว่างเปล่า countทรัพย์สินของประเภทInt isEmptyทรัพย์สินของประเภทBool ตัวดำเนินการความเสมอภาค ( ==) หมายเหตุ: นี่เป็นตัวดำเนินการค่าความเท่าเทียมกันObject.equals()ใน Java ไม่ใช่ตัวดำเนินการความเท่าเทียมกันอ้างอิงเช่น==ใน Java ฉันวิ่งเข้าไปในกลุ่มพึ่งพาพึ่งพาวงจร: BitVectorหน่วยทดสอบที่ทดสอบความจำเป็นในการเริ่มต้นของฉันที่จะตรวจสอบว่ามีการสร้างขึ้นใหม่ สามารถทำได้หนึ่งใน 3 วิธี: ตรวจสอบ bv.count == 0 ตรวจสอบ bv.isEmpty == true ตรวจสอบว่า bv == …

24 unit-testing  tdd  swift-language 

คุณเคยได้ยินหลายครั้งจากผู้ที่ไม่เข้าใจคุณค่าของการทดสอบอย่างแท้จริง เพียงเพื่อเริ่มต้นสิ่งต่าง ๆ ฉันเป็นผู้ติดตาม Agile และการทดสอบ ... ฉันเพิ่งมีการอภิปรายเกี่ยวกับการดำเนินการ TDD บนผลิตภัณฑ์เขียนใหม่ที่ทีมปัจจุบันไม่ฝึกการทดสอบหน่วยในระดับใดและอาจไม่เคยได้ยินเกี่ยวกับเทคนิคการฉีดพึ่งพาหรือรูปแบบการทดสอบ / การออกแบบ ฯลฯ (เราจะไม่ได้รับ เพื่อทำความสะอาดรหัส) ตอนนี้ฉันมีความรับผิดชอบอย่างเต็มที่สำหรับการเขียนซ้ำของผลิตภัณฑ์นี้และฉันบอกว่าการพยายามใช้มันในรูปแบบของ TDD จะทำให้มันเป็นฝันร้ายในการบำรุงรักษาและเป็นไปไม่ได้สำหรับทีมที่ดูแลรักษา นอกจากนี้เนื่องจากเป็นแอปพลิเคชันส่วนหน้า (ไม่ใช่บนเว็บ) การเพิ่มการทดสอบจึงไม่มีจุดหมายเนื่องจากการเปลี่ยนแปลงของไดรฟ์ทางธุรกิจ (โดยการเปลี่ยนแปลงหมายถึงการปรับปรุงแน่นอน) การทดสอบจะล้าสมัยนักพัฒนาอื่น ๆ ที่เข้ามา โครงการในอนาคตจะไม่รักษาและกลายเป็นภาระสำหรับพวกเขาในการแก้ไข ฯลฯ ฉันสามารถเข้าใจได้ว่า TDD ในทีมที่ไม่มีประสบการณ์การทดสอบใด ๆ ในขณะนี้ไม่ดี แต่ข้อโต้แย้งของฉันในกรณีนี้คือฉันสามารถสอนการฝึกฝนของฉันกับคนรอบตัวฉัน แต่ยิ่งกว่านั้นฉันรู้ว่า TDD ทำให้ดีขึ้น ซอฟต์แวร์. แม้ว่าฉันจะผลิตซอฟต์แวร์โดยใช้ TDD และส่งการทดสอบทั้งหมดไปมอบให้กับทีมซ่อมบำรุงมันจะเป็นวิธีที่ดีกว่าการไม่ใช้ TDD เลยตั้งแต่แรก? ฉันถูกยิงเพราะพูดถึงการทำ TDD ในโครงการส่วนใหญ่สำหรับทีมที่ไม่เคยได้ยินมาก่อน แนวคิดของ "ส่วนต่อประสาน" และตัวสร้าง DI ที่ดูแปลก …

24 testing  agile  tdd  bdd 

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

24 testing  unit-testing  tdd 

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

24 productivity  tdd 

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

23 c#  unit-testing  tdd 

ที่ บริษัท ของเราเรามักจะตรวจสอบให้แน่ใจว่าเราได้ทำการทดสอบแบบครบวงจรสำหรับเว็บไซต์ / แอพเว็บของเรา นั่นหมายความว่าเราเข้าถึง URL กรอกแบบฟอร์มส่งแบบฟอร์มไปยัง URL อื่นและตรวจสอบผลลัพธ์ของหน้า เราทำสิ่งนี้เพื่อทดสอบการตรวจสอบแบบฟอร์มทดสอบว่าเทมเพลต HTML มีตัวแปรบริบทที่ถูกต้อง ฯลฯ นอกจากนี้เรายังใช้มันเพื่อทดสอบตรรกะพื้นฐาน ฉันได้รับการบอกเล่าจากเพื่อนร่วมงานว่าสาเหตุของเรื่องนี้คือเราสามารถลอกออกและเปลี่ยนแปลงการใช้งานพื้นฐาน ณ จุดใดก็ได้ตราบใดที่การทดสอบแบบ end-to-end ผ่าน ฉันสงสัยว่าการแยกประเภทนี้เหมาะสมหรือไม่หรือเป็นเพียงวิธีหลีกเลี่ยงการเขียนการทดสอบสำหรับโค้ดที่เล็กลง?

23 unit-testing  tdd  acceptance-testing 

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

23 programming-practices  testing  code-quality  tdd 

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

23 testing  agile  unit-testing  tdd 

ที่ทำงานหนึ่งในโครงการของฉันส่วนใหญ่เกี่ยวกับการรับส่งข้อมูลจากไคลเอนต์ภายนอกและเก็บไว้ในฐานข้อมูล มันเป็นแอพพลิเคชั่นขององค์กร Java ที่ใช้ JPA และตรรกะส่วนใหญ่ของเราหมุนรอบการดำเนินการ CRUD ข้อบกพร่องส่วนใหญ่ของเราเกี่ยวข้องกับ JPA ไม่ทางใดก็ทางหนึ่ง ตัวอย่างที่ 1: ถ้าคุณคลิกปุ่มบันทึกสองครั้ง JPA อาจลองแทรกเอนทิตีเดียวกันในฐานข้อมูลเป็นครั้งที่สองทำให้เกิดการละเมิดคีย์หลัก ตัวอย่างที่ 2: คุณดึงเอนทิตีจากฐานข้อมูลแก้ไขและลองอัปเดตข้อมูล JPA อาจพยายามสร้างอินสแตนซ์ใหม่แทนการอัปเดตเก่า บ่อยครั้งที่โซลูชันต้องการเพิ่ม / ลบ / เปลี่ยนคำอธิบายประกอบ JPA บางครั้งก็เกี่ยวข้องกับการปรับเปลี่ยนตรรกะ DAO ฉันไม่สามารถหาวิธีที่จะมั่นใจในโค้ดของเราโดยใช้การทดสอบหน่วยและ TDD ฉันไม่แน่ใจว่าเป็นเพราะการทดสอบหน่วยและ TDD นั้นไม่เหมาะสมหรือถ้าฉันเข้าใกล้ปัญหาผิด การทดสอบหน่วยดูเหมือนจะไม่เหมาะสมเพราะฉันสามารถค้นพบปัญหาเหล่านี้ที่รันไทม์เท่านั้นและฉันจำเป็นต้องปรับใช้กับเซิร์ฟเวอร์แอปเพื่อสร้างปัญหาขึ้นมาใหม่ โดยปกติฐานข้อมูลจะต้องเกี่ยวข้องซึ่งฉันคิดว่าอยู่นอกนิยามของการทดสอบหน่วย: นี่คือการทดสอบการรวม TDD ดูเหมือนว่าไม่เหมาะสมเพราะการปรับใช้ + ข้อเสนอแนะการทดสอบช้ามากทำให้ฉันไม่ได้ผลมาก การปรับใช้ + ข้อเสนอแนะการทดสอบวนใช้เวลา 3 นาทีและนั่นก็ต่อเมื่อฉันรันการทดสอบเฉพาะเกี่ยวกับรหัสที่ฉันเขียน ในการรันการทดสอบการรวมระบบทั้งหมดจะใช้เวลา 30+ นาที มีรหัสอยู่นอกแม่พิมพ์นี้และฉันมักจะทดสอบหน่วยทุกครั้งที่ทำได้ แต่ข้อบกพร่องส่วนใหญ่ของเราและช่วงเวลาที่ยิ่งใหญ่ที่สุดมักเกี่ยวข้องกับ …

22 java  unit-testing  tdd  jpa 

ฉันเป็นวิศวกรซอฟต์แวร์ที่ บริษัท ขนาดกลาง เรามีแพลตฟอร์มการทดสอบที่ค่อนข้างแข็งแกร่งซึ่งใช้งานบน TeamCity มันทำการทดสอบหน่วยในการเช็คอินทุกครั้งและการทดสอบหน่วย / BVT รายวัน ปัญหาคือ - เรามีการทดสอบหน่วยแตกหัก บ่อยครั้งที่ฉันนำมาซึ่งความไม่มีจุดหมายของการทดสอบหน่วยหากพวกเขาแตกหักและไม่ทำความสะอาด การไม่สามารถดูได้ว่าการเปลี่ยนแปลงทำให้เกิดการถดถอยจะลบมูลค่าส่วนใหญ่ของแพลตฟอร์มการทดสอบหน่วย ฉันต้องการปลูกเมล็ดพันธุ์ที่จะสร้างวัฒนธรรมของนิสัยที่ดี - แก้ไขการทดสอบเมื่อพวกเขาแตกหักเห็นว่ามันมีค่าจัดลำดับความสำคัญของการแก้ไขการทดสอบพร้อมกับงานอื่น ๆ ฉันได้ลองติดสินบน (ขนมอบ) แล้วก็ถามธรรมดาและพูดกับหัวหน้าทีม ทุกคนบอกว่ามันเป็นความคิดที่ดี แต่ฉันเห็นว่าเป็นคนเดียวที่ทำอะไรเกี่ยวกับมัน วิธีที่ดีที่สุดในการเริ่มต้นกระตุ้นให้ผู้อื่นแก้ไขการทดสอบของพวกเขาคืออะไรและจัดลำดับความสำคัญการทดสอบภายในการวิ่งของพวกเขา หากมีวิธีอัตนัยน้อยกว่าที่จะถามสิ่งนี้ฉันยินดีที่จะยอมรับเคล็ดลับใด ๆ

22 testing  unit-testing  tdd  culture  leadership