TDD: ฉันทำถูกไหม?

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

ฉันกำลังทำอะไรอยู่:

1. คิดวิธีการใหม่ที่ฉันต้องการ
2. สร้างการทดสอบสำหรับวิธีการนั้น
3. การทดสอบล้มเหลว
4. วิธีการเขียน
5. ผ่านการทดสอบ
6. วิธีการ Refactor
7. ทำซ้ำ

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

แก้ไข

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

สิ่งที่คุณกำลังอธิบายว่าเป็นเวิร์กโฟลว์ไม่ได้อยู่ในความคิดของฉันวิญญาณของ TDD

บทสรุปของหนังสือ Kent Becks ใน Amazon พูดว่า:

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

ภาคปฏิบัติ TDD

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

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

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

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

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

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

- Edsger ดับบลิว Djikstra (เขียนในปี 1988 ดังนั้นจึงใกล้ถึง 4.5 ทศวรรษแล้ว)

ดูคำตอบนี้ด้วย

คุณสนิทมาก ลองคิดด้วยวิธีนี้แตกต่างกันเล็กน้อย

1. คิดถึงพฤติกรรมใหม่ที่ฉันต้องการ
2. สร้างแบบทดสอบสำหรับพฤติกรรมนั้น
3. การทดสอบล้มเหลว
4. เขียนใหม่หรือขยายวิธีการที่มีอยู่
5. ผ่านการทดสอบ
6. รหัส Refactor
7. ทำซ้ำ

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

ยังจำได้ลุงบ๊อบสามกฎของ TDD

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

มีบางสิ่งที่จะเพิ่มในการตอบกลับของผู้อื่น:

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

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

3. TDD มุ่งเน้นไปที่การส่งมอบคุณค่าในทันทีไม่เพียงทำให้แน่ใจว่าทุกฟังก์ชั่นสามารถทดสอบได้ เมื่อคุณเพิ่มฟังก์ชันการทำงานให้เริ่มจากการถามว่า "ไคลเอนต์ต้องการอะไร" จากนั้นกำหนดอินเทอร์เฟซเพื่อมอบสิ่งที่ลูกค้าต้องการ จากนั้นใช้สิ่งที่ต้องทำเพื่อผ่านการทดสอบ TDD นั้นเกือบจะเหมือนกับการทดสอบสถานการณ์กรณีการใช้งาน (รวมถึง "what-ifs" ทั้งหมด) แทนที่จะเขียนโค้ดฟังก์ชั่นสาธารณะและทดสอบแต่ละรายการ

4. คุณถามเกี่ยวกับการทดสอบรหัส GUI ค้นหารูปแบบ "Humble Dialog" และ "MVVM" แนวคิดเบื้องหลังทั้งสองนี้คือคุณสร้างชุดของคลาส "view model" ซึ่งไม่มีตรรกะเฉพาะ UI อย่างไรก็ตามคลาสเหล่านี้จะมีตรรกะทางธุรกิจทั้งหมดซึ่งโดยทั่วไปเป็นส่วนหนึ่งของ UI ของคุณและคลาสเหล่านี้ควรจะสามารถทดสอบได้ 100% สิ่งที่เหลือคือเปลือก UI ที่บางมากและใช่โดยทั่วไปแล้วเชลล์นั้นจะอยู่ทางด้านซ้ายโดยไม่มีการทดสอบครอบคลุม แต่ ณ จุดนั้นมันควรจะไม่มีเหตุผล

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

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

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

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

โดยทั่วไปคุณทำถูกต้องแล้ว

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

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

ความคิดเห็นของฉันเกี่ยวกับ TDD คือเครื่องมือได้สร้างโลกของนักพัฒนาสไตล์ 'จุดและคลิก' เพียงเพราะเครื่องมือสร้าง stub ทดสอบสำหรับแต่ละวิธีไม่ได้หมายความว่าคุณควรจะเขียนการทดสอบสำหรับทุกวิธี บางคนกำลัง 'เปลี่ยนชื่อ' TDD เป็น BDD (การพัฒนาพฤติกรรมที่ขับเคลื่อน) ซึ่งการทดสอบมีขนาดใหญ่กว่ามากและตั้งใจที่จะทดสอบพฤติกรรมของชั้นเรียนไม่ใช่วิธีการที่ยุ่งเหยิงเล็กน้อย

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

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

มีลิงค์ดีๆทางด้านขวาเกี่ยวกับ BDD v TDD ตรวจสอบพวกเขาออก

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

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

ฉันเชื่อว่าคุณ overtesting

ฉันฝึกฝน TDD มาหลายปีและจากประสบการณ์ของฉันเมื่อ TDD ทำงานได้อย่างมีประสิทธิภาพคุณจะได้รับประโยชน์หลักสองประการ:

• ให้ข้อเสนอแนะอย่างรวดเร็ว
• เปิดใช้งานการเปลี่ยนสถานะใหม่

ให้ข้อเสนอแนะอย่างรวดเร็ว

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

เปิดใช้งานการเปลี่ยนสถานะใหม่

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

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

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

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

หรืออย่างที่ Ian Cooper พูดในงานนำเสนอนี้(ฉันยกมาจากหน่วยความจำดังนั้นจึงอาจไม่สามารถอ้างอิงได้ถูกต้อง)

เหตุผลของคุณในการเขียนการทดสอบใหม่ควรเพิ่มพฤติกรรมใหม่ไม่ใช่การเพิ่มคลาสใหม่

คุณควรทดสอบทุกสาธารณะวิธี

การจับที่นี่คือถ้าวิธีการสาธารณะของคุณมีขนาดเล็กมากคุณอาจเปิดเผยข้อมูลมากเกินไป การปฏิบัติทั่วไปของการเปิดเผยทรัพย์สินทุกอย่างเป็นgetXXX()จริงแบ่ง encapsulation

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

แก้ไข: คำตอบของ pdrสมบูรณ์กว่าของฉันมาก