Bilimsel bir bilgi işlem kütüphanesi için birim testi

Daha önce birim test etme konusunda biraz tecrübe yaşadım, klasik yazılım mühendisliği projesinde (şımarık değil): bir kullanıcı GUI'sine, bir veritabanına, orta katmandaki iş mantığına vb. Sahip bir MVC. C # bilimsel bir bilgi işlem kitaplığı yazma m (evet, C # çok yavaş biliyorum, C kullanın, tekerlek yeniden icat etmeyin, ve tüm, ama biz C # fakültemde bilimsel hesaplama yapan bir sürü insan var, ve buna ihtiyacımız var). Yazılım geliştirme endüstrisi açısından küçük bir proje, çünkü çoğunlukla kendim ve zaman zaman birkaç meslektaşımın yardımıyla yazıyorum. Ayrıca, bunun için ödeme almıyorum ve en önemlisi akademik bir projedir. Yani, bir gün profesyonel kalitede olmasını bekliyorum, çünkü açık kaynak kullanmayı planlıyorum,

Her neyse, proje büyüyor (bir adamın projesi için büyük olduğunu düşündüğüm yaklaşık 18.000 satır kod) ve elimden çıkıyor. Git'i kaynak kontrolü için kullanıyorum ve bence oldukça iyiyim, ama eski okul gibi test ediyorum, yani, sistemin büyük bir bölümünü test eden tam konsol uygulamaları yazıyorum, çünkü esas olarak nasıl olduğunu bilmiyorum Bu senaryoda birim testi yapmak için yapmam gerekeni hissediyorum. Sorun kitaplığı çoğunlukla algoritmalar, örneğin, grafik algoritmaları, sınıflandırıcılar, sayısal çözücüler, rasgele dağıtımlar, vb olmasıdır. Ben sadece bu algoritmaların her biri için küçük test senaryoları belirtmek için nasıl bilmiyorum, ve bunların çoğu Stokastik Doğruluğu nasıl doğrulayacağımı bilmiyorum. Sınıflandırma için, örneğin, kesinlik ve hatırlama gibi bazı metrikler, ancak bu metrikler iki algoritmayı karşılaştırmak için tek bir algoritmayı değerlendirmekten daha iyidir. Peki, burada doğruluğu nasıl tanımlayabilirim?

Son olarak performans sorunu da var. Bunun tamamen farklı bir dizi test olduğunu biliyorum, ancak performans, kullanıcı memnuniyeti veya diğer yazılım mühendisliği metrikleri yerine bilimsel araçların önemli özelliklerinden biridir.

En büyük sorunumdan biri veri yapıları. Bir kd ağacı için gelebileceğim tek test bir stres testidir: çok sayıda rastgele vektör ekleyin ve daha sonra çok sayıda rastgele sorgu gerçekleştirin ve saf bir doğrusal arama ile karşılaştırın. Performans için de aynı şey geçerli. Sayısal iyileştiricilerle, test edebileceğim kıyaslama işlevlerim var, ancak daha sonra, bu bir stres testidir. Bu testlerin birim testler olarak sınıflandırılabileceğini ve en önemlisi sürekli çalıştıklarını düşünmüyorum, çünkü bunların çoğu oldukça ağır. Ama aynı zamanda bu testlerin yapılması gerektiğini düşünüyorum, sadece iki öğe ekleyemiyorum, kökü açamıyorum ve evet, 0-1-n davası için çalışıyor.

Öyleyse, bu tür bir yazılım için (birim) test yaklaşımı nedir? Ve birim testlerini ve ağır testleri kod-inşa-taahhüt-bütünleştirme döngüsünde nasıl düzenleyebilirim?

Bilimsel hesaplamanın aslında birim test için oldukça uygun olduğunu söyleyebilirim. Kesin giriş ve çıkışlarınız, bazı tasarımcıların hevesine göre muhtemelen haftada bir değişmeyecek açıkça tanımlanmış ön ve son koşullarınız var ve test edilmesi zor kullanıcı arayüzü gereksinimleri yok.

Soruna neden olabilecek bazı öğeleri adlandırırsınız; onlar hakkında ne yapmalı:

• rastgele algoritmalar: iki olasılık vardır. Rastgeleleştirmenin kendisini test etmek istiyorsanız, çok sayıda tekrarlama planlayın ve vakaların beklenen oranının istenen kriteri karşıladığını iddia edin, sahte test başarısızlıklarının oldukça nadir olacağı kadar büyük hata payları. (Hayalet hatalarını güvenilir olmayan bir şekilde işaret eden bir test paketi, akla gelebilecek her kusuru yakalamayandan çok daha kötüdür.) Alternatif olarak, yapılandırılabilir bir rastgele kaynak kullanın ve sistem saatini (veya kullandığınız her şeyi) bağımlılık yoluyla belirleyici bir kaynakla değiştirin enjeksiyonu ile testlerinizin tamamen öngörülebilir olmasını sağlayın.
• sadece kesinlik / hatırlama açısından tanımlanmış algoritmalar: hiçbir şey sizi bir dizi girdi vakası koymaktan ve hepsini toplayarak kesinlik ve hatırlamayı ölçmekten alıkoyamaz; bu sadece test verilerinin yarı otomatik olarak verimli bir şekilde üretilmesi sorunudur, böylece test verilerinin sağlanması üretkenliğinizin darboğazı haline gelmez. Alternatif olarak, makul bir şekilde seçilmiş bazı giriş / çıkış çiftlerini belirtmek ve algoritmanın tam olarak istenen girişi hesapladığını iddia etmek , rutin yeterince tahmin edilebilirse de işe yarayabilir.
• işlevsel olmayan gereksinimler: şartname gerçekten açık uzay / zaman gereksinimlerini verirse, o zaman temelde sahip giriş / çıkış çiftlerinin tüm süitler çalıştırmak ve doğrulamak için kaynak kullanımı uygundur yaklaşık gerekli kullanım şekline. Buradaki hile önce kendi test sınıfınızı kalibre etmektir, böylece farklı boyutlarda ölçmek için çok hızlı olan veya test paketini çalıştırmanın pratik olmayacağı kadar uzun süren on problemi ölçmezsiniz. PU'nun ne kadar hızlı çalıştığına bağlı olarak, farklı boyutlarda test senaryoları oluşturan küçük bir kullanım senaryosu jeneratörü bile yazabilirsiniz.
• hızlı ve yavaş çalışan testler: ister birim ister entegrasyon testleri olsun, genellikle çok hızlı testler ve birkaç çok yavaş testle sonuçlanırsınız. Testlerinizi düzenli olarak yapmak çok değerli olduğundan, genellikle pragmatik rotaya gidiyorum ve sahip olduğum her şeyi hızlı ve yavaş bir pakete ayırıyorum, böylece hızlı olanı mümkün olduğunca sık çalışabilir (kesinlikle her taahhütten önce) ve 'semantik olarak' iki test birbirine aittir ya da ait değildir.