Apakah ada kerangka kerja pengujian unit agnostik bahasa? [Tutup]

11

Saya selalu ragu menulis ulang kode kerja - kode porting tidak terkecuali untuk ini. Namun, dengan munculnya TDD dan pengujian otomatis, jauh lebih masuk akal untuk menulis ulang dan kode refactor.

Adakah yang tahu kalau ada alat TDD yang bisa digunakan untuk porting kode lama? Idealnya Anda bisa melakukan hal berikut:

Tulis tes unit agnostik bahasa untuk kode lama yang lulus (atau gagal jika Anda menemukan bug!).
Jalankan tes unit pada basis kode Anda yang lain yang gagal.
Tulis kode dalam bahasa baru Anda yang lulus tes tanpa melihat kode lama.

Alternatifnya adalah dengan membagi langkah 1 menjadi "Menulis unit test dalam bahasa 1" dan "Port unit tes ke bahasa 2", yang secara signifikan meningkatkan upaya yang diperlukan dan sulit untuk dibenarkan jika basis kode lama akan berhenti dipertahankan setelah port (yaitu, Anda tidak mendapatkan manfaat dari integrasi berkelanjutan pada basis kode ini).

EDIT: Perlu dicatat pertanyaan ini di StackOverflow.

unit-testing language-agnostic porting

— Bringer128
sumber

Berikan protokol perintah teks murni, dan kemudian gunakan expectuntuk mengimplementasikan tes Anda.

— SK-logic

@ SK-logika saya belum pernah dengar expect. Jika Anda memiliki sistem warisan gaya Unix yang berkomunikasi dengan pipa menggunakan stdin dan stdout maka alat itu dapat digunakan dengan pasti. Bahkan, akan sangat mudah untuk menguji dengan bahasa scripting apa pun juga.

— Bringer128

mengapa warisan? Anda dapat memiliki sistem modern unix-style juga. Lagi pula, tidak pernah ada pembenaran yang valid untuk tidak menyediakan antarmuka skrip untuk setiap fungsi.

— SK-logic

@ SK-logic Maaf karena tidak jelas. Saya mengatakan "warisan" karena porting umumnya dilakukan dari legacy language xke fancy new language y. Saya tidak berusaha menyiratkan apa pun tentang Unix!

— Bringer128

@ Bringer123, omong-omong, trik kecil saya untuk melakukan semacam ini integrasi seperti unix tanpa dukungan Unix yang layak (misalnya, tidak ada pipa yang tepat) adalah untuk menanamkan bahasa scripting dan menyediakan akses ke REPL melalui port TCP (dengan REPL berjalan di utas terpisah). Ini adalah alat debugging yang kuat dan menguji mesin otomasi. Dan pendekatan ini bekerja dengan segala sesuatu secara harfiah (bahasa scripting tertanam bisa sangat kecil, bahkan bisa menjadi Keutamaan dalam skenario sumber daya terbatas).

— SK-logic

6

Saya rasa tidak mungkin untuk menulis unit test dalam bahasa yang berbeda.

Namun, yang dapat Anda lakukan adalah menulis tes integrasi / penerimaan / antarmuka pengguna / whaterver_you_name_it yang akan tingkat sangat tinggi dan tidak akan terikat dengan bahasa perangkat lunak Anda ditulis.

Jika aplikasi Anda adalah layanan web, Anda dapat mengujinya dengan bahasa apa pun yang Anda inginkan, asalkan mendukung protokol Anda. Jika aplikasi Anda berjalan di browser, Anda dapat menggunakan selenium (itu yang pertama kali muncul di benak saya, tetapi ada yang lain. Dll. Mungkin ada beberapa kasus di mana itu tidak akan berfungsi saya bayangkan (mungkin hal-hal perangkat keras), itu semua tergantung pada jenis aplikasi yang sedang Anda kerjakan.

Tentu saja, Anda tidak akan memiliki cakupan yang sama dengan yang Anda miliki dengan tes tingkat unit (kecuali menghabiskan banyak waktu), tetapi setidaknya, Anda akan memiliki test harness.

— David
sumber

+1 untuk tes tingkat tinggi otomatis. Ini pasti akan sepadan dengan usaha untuk menghasilkan.

— Bringer128

1

"Kurasa tidak mungkin menulis unit test dalam bahasa yang berbeda." : contoh counter: di .NET, Anda dapat menulis unit test C # di Visual Basic (atau bahasa lain yang mendukung .NET). Beberapa tahun yang lalu, ini bahkan dipromosikan oleh Microsoft sebagai praktik terbaik, karena ini menurunkan risiko membuat kode dan menguji kesalahan yang sama terkait dengan bahasa (dan khususnya kesalahpahaman relatif programmer tentang itu). Setuju, seseorang tidak akan menulis unit test dalam Fortran untuk menguji kode PHP.

— Arseni Mourzenko

2

Saya pikir apa yang paling dekat dengan ide Anda adalah kerangka unit test pada ekosistem berbasis mesin virtual seperti Java VM. Setidaknya Scala (dan saya percaya Groovy juga - saya tidak begitu yakin tentang Clojure) hampir sepenuhnya dapat dioperasikan dengan Java. Artinya, kode Scala dapat diuji dengan JUnit dan kode Java dapat diuji dengan ScalaTest. Dengan cara ini Anda dapat (secara bertahap atau sekaligus) menulis ulang kode Java di Scala dan tetap menggunakan tes unit Java yang sama untuk memverifikasi kebenarannya. (Atau sebaliknya - walaupun saya tidak dapat membayangkan alasan yang sah untuk bermigrasi dari Scala kembali ke Jawa.)

Mungkin hal yang sama berlaku untuk bahasa di. NET CLI, misalnya C #, F #, ASP.NET et al.

Di luar VM / CLR, bagaimanapun, itu lebih sulit. Secara teori, seseorang dapat mengkompilasi tes unit dan / atau kode yang diuji ke dalam bahasa lain seperti C (seperti dulu dan umum dengan bahasa baru seperti awal C ++ dll), tapi saya belum pernah mendengar ada orang yang mencoba ini secara khusus dengan tes unit.

— Péter Török
sumber

1

Saya kira ini menunjukkan masalah dengan pertanyaan saya. Jika mereka dapat beroperasi dengan mudah, mengapa harus port? Dan jika mereka tidak bisa, maka hambatan bahasa membuatnya tidak mungkin untuk melakukan tes unit lintas-bahasa.

— Bringer128

@ Bringer128, pendukung generasi baru bahasa JVM mengklaim bahwa masalah spesifik dapat diselesaikan lebih cepat, dengan kode yang jauh lebih sedikit dan lebih bersih daripada di Jawa. Pengalaman saya yang terbatas dengan Scala mengkonfirmasi hal ini sejauh ini.

— Péter Török

Groovy juga bekerja sama dengan Java.

— user281377

1

Kerangka kerja seperti itu tidak ada, karena itu perlu ditulis dalam bahasa kode yang digunakan.

Misalnya, kerangka kerja untuk menguji kode c ++ perlu ditulis dalam c atau c ++. Menggunakan kerangka kerja yang ditulis dalam c ++ mungkin, tetapi tidak akan menguji kode ac jika menggunakan fitur c ++.

— BЈовић
sumber

1

Metodologi bervariasi, tetapi dalam kasus saya sebagian besar dari tes TDD saya cenderung ke gaya 'tes integrasi', dibandingkan dengan 'tes unit'. Yaitu, sebagian besar dari saya menguji seluruh program dalam pertanyaan yang hampir nyata, memeriksa tanggapan yang sesuai.

Dalam beberapa kasus, ketika saya menulis program berbasis jaringan (kebanyakan protokol khusus aplikasi), saya tidak memiliki kerangka kerja pengujian lengkap yang terasa mudah untuk pekerjaan itu, jadi saya melakukan sebagian besar pengujian 'lintas jaringan', di singkatnya, saya menulis klien yang sangat sederhana dalam bahasa lain dengan kerangka uji umum dan sederhana, dan sebagian besar tes memeriksa respons server.

Namun, bahkan dalam kasus-kasus itu, saya menyuntikkan beberapa tes linting tangan dalam aplikasi nyata untuk menguji beberapa bagian non-jaringan.

— Javier
sumber

0

Kerangka uji agnostik bahasa adalah kerangka uji generik yang cocok untuk uji penerimaan (sudut pandang) dan testcases dalam kerangka itu dikelola oleh QA misalnya Robotframework

— rrsguru
sumber

2

ini tampaknya tidak menawarkan sesuatu yang substansial atas poin yang dibuat dan dijelaskan dalam 4 jawaban sebelumnya

— agas