Adakah yang melakukan TDD "nyata" dengan Visual-C ++, dan jika ya, bagaimana mereka melakukannya? [Tutup]

Pengembangan Didorong Tes menyiratkan penulisan tes sebelum kode dan mengikuti siklus tertentu :

• Tes Tulis
• Periksa Tes (jalankan)
• Tulis Kode Produksi
• Periksa Tes (jalankan)
• Bersihkan Kode Produksi
• Periksa tes (lari)

Sejauh yang saya ketahui, ini hanya mungkin jika solusi pengembangan Anda memungkinkan Anda untuk dengan cepat beralih antara kode produksi dan tes, dan untuk melaksanakan tes untuk bagian kode produksi tertentu dengan sangat cepat.

Sekarang, sementara ada banyak Kerangka Pengujian Unit untuk C ++ (saya menggunakan Bost.Test atm.) Tampaknya tidak benar-benar ada solusi Visual Studio (Plugin) yang layak (untuk C ++ asli ) yang membuat TDD siklus tertahankan terlepas dari kerangka yang digunakan.

"Bearable" berarti tindakan satu klik untuk menjalankan tes untuk file cpp tertentu tanpa harus secara manual mengatur proyek pengujian terpisah dll. "Bearable" juga berarti bahwa tes sederhana dimulai (menghubungkan!) Dan berjalan sangat cepat .

Jadi, alat (plugin) dan teknik apa di luar sana yang memungkinkan siklus TDD untuk pengembangan C ++ asli dengan Visual Studio?

Catatan: Saya baik-baik saja dengan alat gratis atau "komersial".

Harap : Tidak ada rekomendasi kerangka kerja. (Kecuali kerangka kerja memiliki plugin Visual Studio khusus dan Anda ingin merekomendasikan plugin.)

Sunting Catatan : Jawaban sejauh ini telah menyediakan tautan tentang bagaimana mengintegrasikan kerangka kerja Unit Testing ke dalam Visual Studio. Sumber daya lebih atau kurang menggambarkan bagaimana mendapatkan kerangka kerja UT untuk mengkompilasi dan menjalankan Tes pertama Anda. Ini bukan tentang pertanyaan ini. Saya berpendapat bahwa untuk benar-benar bekerja secara produktif, memiliki Unit Tests yang dikelola secara manual (!), Pisahkan vcproj dari kelas produksi Anda akan menambah banyak overhead sehingga TDD "tidak mungkin". Sejauh yang saya ketahui, Anda tidak menambahkan "proyek" tambahan ke Java atau C # untuk mengaktifkan Unit Test dan TDD, dan untuk alasan yang baik. Ini seharusnya dimungkinkan dengan C ++ diberikan alat yang tepat, tetapi tampaknya (pertanyaan ini adalah tentang) bahwa ada sangat sedikit alat untuk TDD / C ++ / VS.

Googling sekitar, saya telah menemukan satu alat, VisualAssert , yang tampaknya mengarah ke arah yang benar. Namun, afaiks, tampaknya tidak digunakan secara luas (dibandingkan dengan CppUnit, Boost.Test dll.).

Sunting: Saya ingin menambahkan komentar ke konteks untuk pertanyaan ini. Saya pikir ini ringkasan yang baik untuk menguraikan (bagian dari) masalah: (komentar oleh Billy ONeal )

Visual Studio tidak menggunakan "build scripts" yang dapat diedit oleh pengguna. Satu proyek menghasilkan satu biner. Selain itu, Java memiliki properti yang Java tidak pernah membangun biner lengkap - biner yang Anda buat hanyalah ZIP dari file kelas. Karena itu dimungkinkan untuk mengkompilasi secara terpisah kemudian JAR bersama secara manual (menggunakan misalnya 7z). C ++ dan C # keduanya sebenarnya menautkan binari mereka, jadi secara umum Anda tidak dapat menulis skrip seperti itu. Cara terdekat yang bisa Anda dapatkan adalah mengkompilasi semuanya secara terpisah dan kemudian melakukan dua tautan (satu untuk produksi, satu untuk pengujian).

Saya telah menulis seri blog 5-bagian tentang melakukan TDD dengan C ++ dan Visual Studio: bagian 1 , bagian 2 , bagian 3 , bagian 4 , bagian 5 .

Saya tidak yakin mengapa Anda mengatakan bahwa Anda tidak membuat proyek tambahan dalam C # untuk melakukan TDD, karena itulah yang selalu saya lakukan dengan NUnit dan sepertinya juga apa yang dilakukan orang lain dengan NUnit. Alasannya sederhana: selalu pisahkan kode uji dari kode produksi. Untuk C ++ dengan Visual Studio, ini berarti proyek yang terpisah seperti halnya untuk C # dan NUnit. Dari apa yang saya ketahui tentang dunia Jawa, ini juga umum di sana.

Jelas, setiap orang memiliki gagasan berbeda tentang apa yang "dapat ditanggung" untuk melakukan TDD. Saya telah mempraktikkan metode yang saya garis besarkan di posting blog saya selama beberapa tahun dan saya merasa sangat tertahankan. C ++ adalah bahasa yang dikompilasi dan mengkompilasi hal-hal bisa lambat ketika sistem yang diuji sangat digabungkan. Hanya saja tidak ada yang lolos dari itu tanpa refactoring ke desain yang lebih longgar digabungkan.

"Tindakan satu klik" saya adalah "Bangun Solusi". Jika itu membangun terlalu banyak, Anda selalu dapat membongkar proyek yang tidak relevan saat Anda sedang bekerja dan kemudian Build Solution akan membangun hanya subset minimal proyek yang perlu diperbarui sebagai hasil dari perubahan Anda.

Memang, sifat waktu kompilasi C ++ membuat ini membutuhkan waktu sedikit lebih lama dalam setiap siklus proses TDD daripada yang terjadi dengan NUnit dan C #, tetapi kepercayaan yang saya dapatkan dari kode C ++ yang teruji baik sangat berharga. Kalau tidak, saya akan menghabiskan lebih banyak waktu di debugger. Saya akan berhati-hati untuk menghemat penggunaan gmock karena dapat menambah secara substansial untuk menguji waktu kompilasi. Saya sejauh ini kebanyakan lolos dengan benda-benda "palsu" yang ringan dan jarang membutuhkan fungsi tiruan yang lengkap. Kerangka kerja mengejek untuk C ++ sangat berbasis template dan ini dapat meningkatkan waktu kompilasi secara signifikan, jadi mereka harus dicadangkan untuk tempat Anda benar-benar membutuhkan tiruan dan yang palsu tidak akan berhasil.

Saya telah mempertimbangkan membuat wizard proyek uji unit Boost.Test untuk mengotomatisasi beberapa sifat pelat ketel untuk membuat proyek uji untuk kode produksi, tetapi setelah Anda melakukannya beberapa kali benar-benar tidak terlalu sulit untuk dilakukan secara manual.

Adapun solusi dengan banyak (150?) Proyek, ada cara untuk mengatasinya juga. Salah satu yang jelas adalah menemukan kelompok proyek terkait dan menggabungkannya dan mulai menggunakannya / menerbitkannya sebagai satu unit. Jika Anda benar-benar perlu membangun kembali / menyentuh semua 150 proyek untuk perubahan kecil yang Anda buat selama siklus TDD, maka kode Anda juga sangat digabungkan sehingga unit test tidak mungkin membuat banyak perbedaan.

Melihat tautan IDE netbeans, saya menemukan permen mata yang memiliki sesuatu yang mem-parsing hasil tes dan menunjukkan baris tes kecil di jendela dengan simbol hijau atau merah di sebelahnya sesuatu yang saya pikir saya akan rindukan datang dari NUnit, tapi sebenarnya tidak ketinggalan. Saya menemukan itu lebih berguna untuk membangun hanya gagal dan kemudian saya bisa klik dua kali di jendela kesalahan untuk menempatkan kursor di lokasi pernyataan yang gagal.

Saya tidak menggunakan Visual-C ++, tapi saya melakukan TDD dengan C ++, menggunakan googletest dan googlemock, dengan QtCreator sebagai IDE saya. Beberapa tahun yang lalu saya memiliki pengaturan yang serupa dengan Visual-C ++ tetapi menggunakan kerangka kerja unit test yang berbeda.

Apa yang menurut saya bermanfaat adalah memisahkan proyek menjadi beberapa sub proyek.

1. Pustaka statis atau dinamis yang berisi 99% dari kode sumber proyek yang sebenarnya.
2. Sebuah proyek yang sebagian besar terdiri dari metode main () untuk menjalankan program normal.
3. Proyek uji yang berisi main () untuk menjalankan kerangka uji saya dan banyak file yang berisi objek pengujian dan tiruan.

Dengan pengaturan ini, IDE saya menangani penambahan file ke berbagai proyek dan jika dependensi ditentukan dengan benar, saya dapat menjalankan semua tes unit saya dengan pembangunan kembali parsial. Saya bahkan sudah menyiapkannya untuk menjalankan semua tes saya segera setelah saya membangun. Jenkins, CI yang saya gunakan saat ini, juga berjalan dan memberikan hasil tes dan data cakupan.

Dimungkinkan untuk menambahkan peluncur kustom di IDE Anda untuk file untuk menjalankan tes unit untuk file Foo.cpp jika Anda menamai semua tes unit untuk Foo di bawah perlengkapan tes TestFoo. Cara mengatur ini tepat untuk Visual-C ++ Saya tidak yakin tapi saya pikir itu mungkin.

Saya menggunakan MSTest untuk menguji kode C ++ asli.
Berikut adalah posting blog yang bagus tentang cara ini: http://blogs.msdn.com/b/jsocha/archive/2010/11/19/writing-unit-tests-in-visual-studio-for-native-c. aspx

Ya, akan ada setidaknya dua proyek - satu untuk aplikasi itu sendiri, satu untuk tes.
Alih-alih membuat proyek ketiga dengan perpustakaan statis, saya hanya menambahkan sumber aplikasi untuk menguji proyek, jadi solusinya terlihat seperti ini:

[-] 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

Mungkin agak terlambat, tetapi jika saya membaca pertanyaan Anda dengan benar, Anda mencari teknik untuk meningkatkan siklus TDD? Belum disebutkan di sini, tetapi apakah Anda sudah melihat acara pasca-pembangunan di VS?

Solusi kami biasanya diatur (dengan Ketergantungan Proyek ditampilkan) ...

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

Acara pasca-bangun MAIN-APP akan menjalankan UNIT-TEST-APP

Acara pasca-pembangunan UNIT-TEST-APP akan berjalan sendiri (cukup cantumkan '$ (TargetPath)' sebagai perintah untuk dijalankan dalam acara pasca-bangun).

(Ini berarti bahwa ketika membangun MAIN-APP, pengujian unit dapat berjalan dua kali, tetapi itu tidak benar-benar menjadi masalah dalam kasus kami!)

Seperti yang disebutkan, ya, ada sedikit usaha dalam mengatur struktur ini, tetapi begitu ada, menambahkan tes sederhana.

Jadi yang harus Anda lakukan adalah membangun aplikasi utama dan tes unit akan berjalan secara otomatis!

Ya, tidak tahu apakah ini membantu, tetapi ada beberapa video hebat tentang TDD dari Brett L. Schuchert. Sayangnya, ia tidak menunjukkan kombinasi "C ++" dan "VS", tetapi

TDD dengan C # dan VS: http://vimeo.com/album/210446

TDD dengan C ++ dan Eclipse: http://vimeo.com/13240481

Mungkin Anda bisa mengatasinya dari keduanya.

EDIT: video C ++ adalah tentang menggunakan kerangka kerja pengujian CppUTest dengan Eclipse, tentu saja. Ketika saya mempostingnya saya pikir itu harus mudah diadopsi untuk digunakan dalam VS. Jadi saya mencari di Google sedikit dan menemukan ini:

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

yang memberi Anda informasi cara menggunakan CppUTest di Visual Studio.

Googletest
Cara berintegrasi dengan vc ++

Anda tidak perlu plugin, tes hanyalah target lain. Tidak ada plugin untuk menghasilkan tes dengan c ++, meskipun Anda bisa menguji hal-hal yang tidak berguna seperti tugas

Tidak dapat mengomentari alat C ++ karena saya belum menyentuh sekitar 20 tahun (.NET dev hari ini) dan saya kira sebagian besar alat hari ini adalah untuk kode yang dikelola tetapi untuk teknik ...

Seperti yang telah disebutkan orang lain, kode uji selalu dalam proyek / perakitan yang sama sekali berbeda dari kode produksi dan ya Anda biasanya harus mempertahankan proyek itu sendiri, walaupun tentu saja dalam VS IDE ini bukan masalah besar karena Anda sering memiliki beberapa proyek sebagai tetap bagian dari solusi Anda.

Kode produksi adalah dan harus ditulis sedikit berbeda untuk TDD. Saat Anda menulis tes pertama Anda akhirnya harus merancang kode Anda untuk diuji. Ini adalah subjek lain secara keseluruhan dalam dirinya sendiri tetapi dapat memakan waktu dan tampak sangat frustasi pada awalnya terutama jika IDE / tools Anda tidak memberi Anda umpan balik cepat, keluar untuk menjalankan alat baris perintah untuk menjalankan tes hanya mengganggu.

Ada banyak teknik khusus untuk membuat kode dapat diuji, tetapi sebagian besar dari mereka memecah untuk membuat objek kecil yang tidak banyak berguna sehingga Anda dapat mengujinya secara terpisah dan dapat menyuntikkan versi uji beberapa perilaku ke dalam yang lebih kompleks. benda. Kerangka kerja IOC dapat banyak membantu di sini.

Buku yang menurut Anda bermanfaat adalah; Michael Feathers, Bekerja Efektif dengan Legacy Code. Ini menggunakan beberapa bahasa dalam contohnya dan dapat membantu Anda mengidentifikasi pendekatan spesifik untuk dengan aman mengadaptasi kode / teknik yang awalnya tidak dirancang untuk dapat diuji.

Peringatan kecil: Saya mabuk dari Agile Kool-Aid tahun lalu: D

Maven tidak digunakan secara luas dalam C ++ (namun, ini terutama digunakan untuk Java tetapi bahasa agnostik) tetapi merupakan alat yang sangat kuat dan memungkinkan Anda untuk menyimpan segala sesuatu dalam satu proyek (termasuk tes, pada kenyataannya, itulah yang direkomendasikan pendekatan dengan Maven). Saya hanya menyarankan sekarang karena dari jawaban sejauh ini sepertinya alternatif dengan plugin VS mungkin tidak ada.

Mencari plugin yang saya temukan:

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

tapi sepertinya belum matang. Dengan pengaturan Maven semua yang perlu Anda lakukan untuk menjalankan tes dijalankan mvn testdi baris perintah.

Jika Anda tertarik, Anda dapat mempelajarinya di sini dan (salah satu) plugin pendukung C ++ di sini (Maven memiliki arsitektur plugin sehingga semuanya adalah plugin).

Rekomendasi kerangka kerja: Di kantor kami, kami menggunakan TestDriven.NET yang terintegrasi dengan Visual Studio. Kelas unittest ditulis dalam C ++ / CLI, yang kemudian dapat memanggil untuk menggunakan kode asli apa pun yang Anda perlu uji. Ya, kelas C ++ / CLI masuk ke perakitan mereka sendiri, sehingga proyek "pengujian" ditambahkan ke solusi.