Herhangi bir dil agnostik birim test çerçevesi var mı? [kapalı]

Ben her zaman çalışma kodu yeniden yazma şüpheci olmuştur - taşıma kodu bu bir istisna değildir. Bununla birlikte, TDD ve otomatik testin ortaya çıkmasıyla kodu yeniden yazmak ve yeniden düzenlemek çok daha mantıklıdır.

Herkes eski kodu taşımak için kullanılabilecek bir TDD aracı olup olmadığını biliyor mu? İdeal olarak aşağıdakileri yapabilirsiniz:

1. Geçen eski kod için dil agnostik birim testleri yazın (veya hata bulursanız başarısız olun!).
2. Başarısız olan diğer kod tabanınızda birim testleri çalıştırın.
3. Eski koda bakmadan testleri geçen yeni dilinize kod yazın.

Bunun alternatifi, 1. adımı "1. dildeki birim testlerini yaz" ve "2. birim testlerini dil 2'ye" bölmektir; bu da gerekli çabayı önemli ölçüde artırır ve eski kod tabanının, bağlantı noktası (yani, bu kod tabanında sürekli entegrasyondan yararlanamazsınız).

EDIT: StackOverflow bu soruyu belirtmeye değer .

Ünite testlerini farklı bir dilde yazmanın mümkün olduğunu sanmıyorum.

Ancak, yapabileceğiniz şey çok yüksek düzeyde olan ve yazılımınızın yazıldığı dile bağlı olmayan yazma entegrasyonu / kabul / kullanıcı arayüzü / whaterver_you_name_it testleri.

Uygulamanız bir web servisiyse, protokolünüzü desteklemesi şartıyla dilediğiniz dil ile test edebilirsiniz. Uygulamanız bir tarayıcıda çalışıyorsa, selenyum kullanabilirsiniz (aklıma ilk gelen budur, ancak başkaları da vardır. Vb. üzerinde çalıştığınız uygulama türü hakkında.

Tabii ki, birim seviyesi testlerinde sahip olduğunuzla aynı kapsama sahip olmayacaksınız (çok fazla zaman harcamadan), ama en azından bir test koşumunuz olacaktır.

Fikrinize en yakın olanın, Java VM gibi sanal makine tabanlı ekosistemlerde birim test çerçeveleri olduğunu düşünüyorum. En azından Scala (ve Groovy'a da inanıyorum - Clojure hakkında pek emin değilim) Java ile neredeyse mükemmel bir şekilde birlikte çalışabilir. Yani, Scala kodu JUnit ile test edilebilir ve Java kodu ScalaTest ile test edilebilir. Bu şekilde (yavaş yavaş veya bir kerede) Java kodunu Scala'da yeniden yazabilir ve doğruluğunu doğrulamak için aynı eski Java birimi testlerini kullanmaya devam edebilirsiniz. (Ya da tam tersi - Scala'dan Java'ya geri dönmek için geçerli bir neden hayal edemiyorum.)

Muhtemelen aynısı .NET CLI'deki diller için de geçerlidir, örneğin C #, F #, ASP.NET ve ark.

Bununla birlikte, bir VM / CLR dışında daha zordur. Teorik olarak, birim testleri ve / veya test edilen kodu C gibi başka bir dile derleyebilir (erken C ++ gibi yeni dillerle olduğu gibi yaygındır), ancak bunu özellikle deneyen kimseyi duymadım birim testleri.

Bu tür bir çerçeve mevcut değildir, çünkü kullanılan kodun dilinde yazılması gerekir.

Örneğin, c ++ kodunu test etmek için bir çerçevenin c veya c ++ ile yazılması gerekir. C ++ ile yazılmış çerçeveyi kullanmak olabilir, ancak c ++ özelliklerini kullanıyorsa ac kodunu test etmeyecektir.

Metodolojiler değişiklik gösterir, ancak benim durumumda TDD testlerimin büyük bir kısmı 'birim testin' aksine 'entegrasyon testi' stiline eğilimlidir. Yani, çoğu, uygun yanıtları kontrol ederek tüm programı neredeyse gerçek hayattaki sorgularda test ediyor.

Birkaç durumda, ağ tabanlı programlar (çoğunlukla uygulamaya özel protokoller) yazdığımda, iş için kolay hissettiren tam bir test çerçevem ​​yoktu, bu yüzden testlerin çoğunu 'ağ üzerinden' yaptım, kısacası, çok basit bir istemciyi başka bir dilde, ortak ve basit bir test çerçevesiyle yazdım ve testlerin çoğu sunucunun yanıtlarını kontrol etti.

Yine de, bu durumlarda bile, bazı ağ dışı parçaları test etmek için gerçek uygulamada birkaç elle haddelenmiş test enjekte ettim.

Dil agnostik test çerçevesi, kabul testi (bakış açısı) için uygun genel test çerçevesidir ve bu çerçevedeki test senaryoları KG tarafından yönetilir, örn. Robotframework