มีใครทำ TDD "ของจริง" กับ Visual-C ++ และถ้าใช่พวกเขาจะทำอย่างไร [ปิด]

Test Driven Developmentหมายถึงการเขียนการทดสอบก่อนโค้ดและทำตามรอบที่แน่นอน :

• ทดสอบการเขียน
• ตรวจสอบการทดสอบ (เรียกใช้)
• เขียนรหัสการผลิต
• ตรวจสอบการทดสอบ (เรียกใช้)
• ทำความสะอาดรหัสการผลิต
• ตรวจสอบการทดสอบ (วิ่ง)

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

ตอนนี้ในขณะที่มีกรอบการทดสอบหน่วยจำนวนมากสำหรับ C ++ (ฉันใช้ Bost.Test atm.) ดูเหมือนว่าไม่มีอยู่จริง ๆ (สำหรับC ++ ) Visual Studio (ปลั๊กอิน) โซลูชันที่ทำให้ TDD ทนทานต่อการใช้งาน

"Bearable" หมายความว่าการคลิกครั้งเดียวเพื่อเรียกใช้การทดสอบสำหรับไฟล์ cpp บางไฟล์โดยไม่ต้องตั้งค่าการทดสอบแยกต่างหากด้วยตนเองเป็นต้น "Bearable" ยังหมายความว่าการทดสอบเริ่มต้นง่าย (การเชื่อมโยง!) และทำงานได้อย่างรวดเร็วมาก .

ดังนั้นมีเครื่องมือ (ปลั๊กอิน) และเทคนิคใดบ้างที่ทำให้วัฏจักร TDD เป็นไปได้สำหรับการพัฒนาภาษา C ++ ด้วย Visual Studio?

หมายเหตุ: ฉันสบายดีด้วยเครื่องมือฟรีหรือ "เพื่อการค้า"

กรุณา : ไม่มีคำแนะนำกรอบ (ยกเว้นว่ากรอบงานนั้นมีปลั๊กอิน Visual Studio เฉพาะและคุณต้องการแนะนำปลั๊กอิน)

แก้ไขหมายเหตุ : คำตอบที่ผ่านมาได้ให้ลิงก์เกี่ยวกับวิธีรวมกรอบการทดสอบหน่วยเข้ากับ Visual Studio ทรัพยากรมากขึ้นหรือน้อยลงอธิบายถึงวิธีการรับเฟรมเวิร์ก UT เพื่อรวบรวมและทดสอบการทำงานครั้งแรกของคุณ นี่ไม่ใช่สิ่งที่คำถามนี้เกี่ยวกับ ฉันเห็นว่าการทำงานอย่างมีประสิทธิผลจริง ๆ โดยการทดสอบหน่วยในการบำรุงรักษาด้วยตนเอง (!) vcproj ที่แยกจากคลาสการผลิตของคุณจะเพิ่มโอเวอร์เฮดที่ TDD "เป็นไปไม่ได้" เท่าที่ฉันทราบคุณไม่ได้เพิ่ม "โครงการ" พิเศษใน Java หรือ C # สิ่งเพื่อเปิดใช้งานการทดสอบหน่วยและ TDD และด้วยเหตุผลที่ดี สิ่งนี้ควร เป็นไปได้เมื่อ C ++ ได้รับเครื่องมือที่เหมาะสม แต่ดูเหมือนว่า (คำถามนี้เกี่ยวกับ) ว่ามีเครื่องมือน้อยมากสำหรับ TDD / C ++ / VS

ฉันพบเครื่องมือหนึ่งVisualAssertที่ดูเหมือนจะมุ่งไปในทิศทางที่ถูกต้อง อย่างไรก็ตามดูเหมือนว่ามันไม่ได้มีการใช้อย่างแพร่หลาย (เทียบกับ CppUnit, Boost.Test เป็นต้น)

แก้ไข: ฉันต้องการเพิ่มความคิดเห็นในบริบทของคำถามนี้ ฉันคิดว่ามันเป็นบทสรุปที่ดีของการสรุป (ส่วนหนึ่งของ) ปัญหา: (ความคิดเห็นโดยBilly ONeal )

Visual Studio ไม่ได้ใช้ "บิลด์สคริปต์" ที่ผู้ใช้สามารถแก้ไขได้อย่างสมเหตุสมผล โครงการหนึ่งผลิตหนึ่งไบนารี ยิ่งกว่านั้น Java มีคุณสมบัติที่ Java ไม่เคยสร้างไบนารีที่สมบูรณ์ - ไบนารีที่คุณสร้างเป็นเพียงไฟล์ ZIP ของไฟล์คลาส ดังนั้นจึงเป็นไปได้ที่จะรวบรวมแยกต่างหากจากนั้น JAR เข้าด้วยกันด้วยตนเอง (ใช้เช่น 7z) C ++ และ C # ทั้งคู่เชื่อมโยงไบนารีของพวกเขาดังนั้นโดยทั่วไปแล้วคุณจะไม่สามารถเขียนสคริปต์เช่นนั้นได้ สิ่งที่ใกล้เคียงที่สุดที่คุณจะได้รับคือรวบรวมทุกอย่างแยกจากกันและทำการเชื่อมโยงสองอัน (อันหนึ่งสำหรับการผลิตหนึ่งอันสำหรับการทดสอบ)

ผมเคยเขียนบล็อกซีรีส์ 5 ส่วนหนึ่งในการทำ TDD กับ C ++ และ Visual Studio: ตอนที่ 1 , ตอนที่ 2 , ส่วน 3 , ส่วน 4 , 5 ส่วนหนึ่ง

ฉันไม่แน่ใจว่าทำไมคุณบอกว่าคุณไม่ได้ทำโครงการพิเศษใน C # เพื่อทำ TDD เพราะนั่นคือสิ่งที่ฉันทำกับ NUnit เสมอและมันก็เป็นเรื่องปกติของสิ่งที่คนอื่นทำกับ NUnit เช่นกัน เหตุผลง่าย: เก็บรหัสทดสอบแยกต่างหากจากรหัสการผลิตเสมอ สำหรับ C ++ กับ Visual Studio นี่หมายถึงโปรเจ็กต์ที่แยกจากกันเช่นเดียวกับ C # และ NUnit จากสิ่งที่ฉันรู้เกี่ยวกับโลกของ Java สิ่งนี้ก็เหมือนกัน

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

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

จริงอยู่ที่เวลาในการคอมไพล์ของ C ++ นั้นใช้เวลานานขึ้นเล็กน้อยในแต่ละรอบของกระบวนการ TDD มากกว่าที่ทำกับ NUnit และ C # แต่ความมั่นใจที่ฉันได้รับจากรหัส C ++ ที่ผ่านการทดสอบเป็นอย่างดีนั้นคุ้มค่า มิฉะนั้นฉันจะใช้เวลามากขึ้นในการดีบัก ฉันจะระมัดระวังที่จะประหยัดในการใช้ gmock ของคุณเพราะมันสามารถเพิ่มเวลาทดสอบได้อย่างมาก ฉันได้รับส่วนใหญ่ไปกับวัตถุ "ปลอม" ที่มีน้ำหนักเบาและไม่ค่อยต้องการฟังก์ชั่นเต็มรูปแบบของ mocks เฟรมเวิร์กที่เยาะเย้ยสำหรับ C ++ นั้นเป็นเทมเพลตที่หนักหน่วงและสามารถเพิ่มเวลาในการคอมไพล์ได้อย่างมากดังนั้นจึงควรสงวนไว้สำหรับตำแหน่งที่คุณต้องการจำลองและตัวปลอมจะไม่ทำ

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

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

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

ฉันไม่ได้ใช้ Visual-C ++ แต่ฉันกำลังแสดง TDD กับ C ++ โดยใช้ googletest และ googlemock โดยมี QtCreator เป็น IDE ของฉัน ปีที่แล้วฉันมีการตั้งค่าที่คล้ายกันกับ Visual-C ++ แต่ใช้กรอบการทดสอบหน่วยที่แตกต่างกัน

สิ่งที่ฉันพบว่ามีประโยชน์คือการแยกโครงการออกเป็นโครงการย่อยสองสามโครงการ

1. ไลบรารีแบบสแตติกหรือไดนามิกที่มี 99% ของรหัสต้นฉบับของโครงการจริง
2. โครงการที่ประกอบด้วยวิธี main () ส่วนใหญ่ในการเรียกใช้โปรแกรมปกติ
3. โครงการทดสอบที่มี main () เพื่อรันกรอบการทดสอบของฉันและไฟล์จำนวนมากที่มีการทดสอบและวัตถุจำลอง

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

อาจเป็นไปได้ที่จะเพิ่มตัวเรียกใช้งานที่กำหนดเองใน IDE ของคุณสำหรับไฟล์เพื่อเรียกใช้การทดสอบหน่วยสำหรับไฟล์ Foo.cpp ถ้าคุณบังเอิญตั้งชื่อการทดสอบยูนิตทั้งหมดสำหรับ Foo ภายใต้ฟิกซ์เจอร์ทดสอบ TestFoo วิธีตั้งค่านี้อย่างแม่นยำสำหรับ Visual-C ++ ฉันไม่แน่ใจ แต่ฉันคิดว่ามันเป็นไปได้

ฉันใช้ MSTest สำหรับทดสอบโค้ดภาษา C ++
นี่คือโพสต์บล็อกที่ยอดเยี่ยมเกี่ยวกับวิธีนี้: http://blogs.msdn.com/b/jsocha/archive/2010/11/19/writing-unit-tests-in-visual-studio-for-native-c aspx

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

[-] Solution 'Foo'      Foo\Foo.sln
 |-[-] Foo              Foo\Foo\Foo.vcproj
 |  |-[-] include
 |  |  |- foo.h         Foo\Foo\foo.h
 |  |  |- bar.h         Foo\Foo\bar.h
 |  |
 |  |-[-] source
 |     |- foo.cpp       Foo\Foo\foo.cpp
 |
 |-[-] Foo.Tests        Foo\Foo.Tests\Foo.Tests.vcproj
    |                        (Additional include directory: "..\Foo")
    |-[-] include
    |  |- FakeBar.h     Foo\Foo.Tests\FakeBar.h
    |
    |-[-] source
       |-[-] app
       |  |- foo.cpp    Foo\Foo\foo.cpp    -- not in Foo.Tests\
       |
       |-[-] unit-tests
          |- foo_Tests.cpp   Foo\Foo.Tests\foo_Tests.cpp
          |- bar_Tests.cpp   Foo\Foo.Tests\bar_Tests.cpp

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

โดยทั่วไปโซลูชันของเราจะมีการจัดระเบียบ (โดยแสดงการอ้างอิงโครงการ) ...

MAIN-APP > LIB1, LIB2, UNIT-TEST-APP
UNIT-TEST-LIB1 > LIB1
UNIT-TEST-LIB2 > LIB2
UNIT-TEST-APP > UNIT-TEST-LIB1, UNIT-TEST-LIB2

กิจกรรมหลังการสร้างของ MAIN-APP จะเรียกใช้ UNIT-TEST-APP

กิจกรรม post-build ของ UNIT-TEST-APP จะเรียกใช้ตัวเอง (เพียงใส่ '$ (TargetPath)' เป็นคำสั่งเพื่อให้ทำงานในเหตุการณ์หลังการสร้าง

(นี่หมายความว่าเมื่อสร้าง MAIN-APP การทดสอบหน่วยสามารถรันสองครั้ง แต่นั่นไม่ใช่ปัญหาในกรณีของเรา!)

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

ดังนั้นสิ่งที่คุณต้องทำคือสร้างแอพหลักและการทดสอบยูนิตจะทำงานโดยอัตโนมัติ!

ไม่ทราบว่าจะช่วยได้หรือไม่ แต่มีวิดีโอยอดเยี่ยมเกี่ยวกับ TDD จาก Brett L. Schuchert น่าเสียดายที่เขาไม่ได้แสดงชุดค่าผสม "C ++" และ "VS" แต่

TDD พร้อม C # และ VS: http://vimeo.com/album/210446

TDD พร้อม C ++ และ Eclipse: http://vimeo.com/13240481

บางทีคุณสามารถทำงานจากสองสิ่งนี้ได้

แก้ไข: วิดีโอ C ++ เป็นเรื่องเกี่ยวกับการใช้กรอบการทดสอบ CppUTest กับ Eclipse แน่นอน เมื่อฉันโพสต์มันฉันคิดว่ามันควรจะนำมาใช้อย่างง่ายดายสำหรับใช้ใน VS ดังนั้นฉันจึงไปเล็กน้อยและพบสิ่งนี้:

http://schuchert.wikispaces.com/tdd.cpp.NotesOnCppUTest

ซึ่งให้ข้อมูลวิธีการใช้ CppUTest ใน Visual Studio

Googletest
วิธีผสานรวมกับ vc ++

คุณไม่จำเป็นต้องใช้ปลั๊กอินการทดสอบนั้นเป็นอีกเป้าหมายหนึ่ง ไม่มีปลั๊กอินในการสร้างการทดสอบด้วย c ++ ถ้าคุณสามารถทดสอบสิ่งที่ไม่มีจุดหมายเช่นการมอบหมาย

ไม่สามารถแสดงความคิดเห็นเกี่ยวกับเครื่องมือ C ++ ได้เนื่องจากฉันไม่ได้สัมผัสในเวลาประมาณ 20 ปี (. NET dev วันนี้) และฉันเดาว่าเครื่องมือส่วนใหญ่ทุกวันนี้เป็นรหัสที่จัดการ แต่สำหรับเทคนิค ...

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

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

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

หนังสือที่คุณอาจพบว่ามีประโยชน์คือ; Michael Feathers ทำงานอย่างมีประสิทธิภาพด้วยรหัสดั้งเดิม สิ่งนี้ใช้หลายภาษาในตัวอย่างและอาจช่วยให้คุณระบุวิธีการเฉพาะในการปรับใช้รหัส / เทคนิคที่ไม่ได้ออกแบบมาเพื่อให้สามารถทดสอบได้อย่างปลอดภัย

ข้อแม้เล็ก ๆ : ฉันเมาจาก Agile Kool-Aid เมื่อหลายปีก่อน: D

Maven ไม่ได้ใช้กันอย่างแพร่หลายใน C ++ (แต่ส่วนใหญ่จะใช้สำหรับ Java แต่เป็นผู้ไม่เชื่อเรื่องภาษา) แต่มันเป็นเครื่องมือที่ทรงพลังมากและช่วยให้คุณเก็บทุกอย่างไว้ในโครงการเดียว (รวมถึงการทดสอบในความเป็นจริง เข้าหาด้วย Maven) ฉันแนะนำเฉพาะตอนนี้ตั้งแต่คำตอบจนถึงตอนนี้ดูเหมือนว่าจะไม่มีตัวเลือก VS plugin

ค้นหาปลั๊กอินที่ฉันพบ:

http://incubator.apache.org/npanday/

แต่มันก็ดูไม่เป็นผู้ใหญ่มากนัก ด้วยการตั้งค่า Maven ทั้งหมดที่คุณต้องทำเพื่อเรียกใช้การทดสอบนั้นทำงานmvn testในบรรทัดคำสั่ง

หากคุณสนใจคุณสามารถเรียนรู้เกี่ยวกับมันได้ที่นี่และ (หนึ่งใน) ปลั๊กอินสนับสนุน C ++ ที่นี่ (Maven มีสถาปัตยกรรมปลั๊กอินดังนั้นทุกอย่างจึงเป็นปลั๊กอิน)

คำแนะนำกรอบการทำงาน: ที่สำนักงานของเราเราใช้ TestDriven.NET ซึ่งทำงานร่วมกับ Visual Studio คลาส unittest นั้นเขียนด้วย C ++ / CLI ซึ่งสามารถเรียกใช้แบบฝึกหัดที่คุณต้องการทดสอบได้ ใช่คลาส C ++ / CLI เข้าสู่ชุดประกอบของตนเองดังนั้นจึงมีการเพิ่มโครงการ "การทดสอบ" ลงในโซลูชัน