Sayısal yazılım geliştirme için test çerçeveleri var mı

Hesaplamalı bilim programlamamın çoğunun standart test çerçeveleri kapsamında olmayan test gereksinimlerine sahip olduğunu buldum:

1. Hesaplama süresi testi

   • Algoritmaların yavaşlamadığından emin olmak için. Gibi bir şey yapabilirdim assureSmallerEqual(RuntimeWrapper(algorithm),53)ama algoritma üzerinde çalışırken 53 saniyelik eşiğin sürekli olarak azaltılmasını istiyorum, yaniassureSmallerEqual(RuntimeWrapper(algorithm),'previousbest+noisetolerance')

2. Performans testi

   • Daha önce analitik bir çözüme iyi bir yaklaşım bulan bir algoritmanın hala en azından iyi veya daha iyi bir çözüm bulmasını sağlamak için. Yine, bu standart bir entegrasyon testi ile taklit edilebilir, ancak algoritmanın daha iyi ve daha iyi hale gelmesiyle toleransın sürekli olarak küçülmesini istiyorum. Yerine düşünün assureAlmostEqual(foo(),1,places=3)tarafındanassureAlmostEqual(foo(),1,places='previousbest')

3. Fiziksel ihtiyaç testi

   • Algoritmaların aniden daha fazla bellek / sabit disk alanına ihtiyaç duymadığından emin olmak için. 1'e çok benzer.

4. Soyut gereksinim testi

   • Karesel yaklaşımlarla iyi sonuç veren bir algoritmanın aniden kübik yaklaşımlara ihtiyaç duymadığından veya zaman adımı 0.1 ile iyi sonuç veren bir algoritmanın aniden kararlılık için 0.01'e ihtiyaç duymadığından emin olmak için. Yine, bunlar standart entegrasyon testleri ile taklit edilebilir, ancak amaç, belirli bir hedefe ulaşan en küçük gereksinim parametresinin ne olduğunu hatırlamaktır, bu nedenle bu çok fazla manuel güncelleme gerektirir. Örneğin, foo(10)daha önce herhangi bir istisna atmadıysa, çerçevenin foo(10)hala çalıştığından emin olmak ve foo(9)şimdi çalışıp çalışmadığını da denemek istiyorum (bu durumda gelecekteki tüm testler foo(9)hala çalışmasını sağlayacaktır ).

İstediğim şey, ünite / entegrasyon testi anlamında testleri tanımlamıyor olabilir, çünkü artan çalışma süreleri, örneğin, diğer iyileştirmeler karşılığında kabul edilebilir olabilir.
Bununla birlikte, pratikte, yukarıdaki test işlevselliğine sahip olsaydım, hata ayıklama zamanından çok tasarruf edeceğimi biliyorum, çünkü vakaların% 95'inde getirdiğim hatalar nedeniyle gereksinimler ve performans kötüye gitti. Gerçekten de, harici sayısal yazılım kütüphaneleriyle bulduğum birçok hatanın (kendi kodumu kontrol etmek için çok fazla zaman harcadıktan sonra) yukarıdaki testlerin titizlikle uygulanması durumunda kaçınılmış olabileceğini biliyorum.

PS

Benzer adla adlandırılan /programming/34982863/framework-for-regression-testing-of-numerical-code , standart regresyon testi çerçevelerinde daha kolay ulaşılabilen işlevleri açıkladığı için bir kopya değildir.

Soru birim test ve test odaklı geliştirme stratejileri onları uygulamak yardımcı bir çerçeve (ve cevapları sağlanan benim görüşüme göre, burada tarif olandan farklıdır edilir / ifadesini sorar stratejiler) karşıt olarak stratejiler sorar.

1. Bu test türü bana kötü tanımlanmış gibi gözüküyor çünkü test durumu geliştirmede testler yaptığınız belirli bir makineye bağlı. Test noktalarından biri, testlerinizi dizüstü bilgisayarımda çalıştırmanın, kurduğum kodda veya ortamda yanlış bir şey olup olmadığını söylemesidir. 53 saniye geliştirme makinenize özeldir ve test makinesi diğer iş yüklerinden veya kullanıcılardan yük altındaysa çalışma süresi de artacaktır. Test çerçeveleri bunu ele almak için beklemezsiniz: "işlev 53 saniyenin altında girdi çalışır" sadece çok iyi bir doğruluk spec değil.

2. Aynı belirsiz sebeplerden dolayı yazılım testi açısından bu belirsiz ve istenmeyen bir durum olduğunu düşünüyorum 1 , yazılım testi için başarılı veya başarısız gerekçesini kaybedersiniz.

3. Bu oldukça yaygındır, bir çözümü açıklayayım. Bu bir test çerçevesinin işi değildir, ancak tek bir Linux işlemi için Unix SE sorusunu sınırla bellek sorusunu açıklandığı gibi ayrı bir araç kullanabilirsiniz . İlk denemek için standart bir araç , bir işlemi çalıştırmanıza ve örneğin çok fazla bellek ayırmaya çalıştığında çökmesini sağlamanıza izin veren ulimitkomuttur bash. runtestsKomut dosyasını bir bellek sınırıyla çalıştırırsanız, çökecektir ve test çerçevesi bunu normal bir test hatası olarak ele alabilmelidir.

4. ünitenin sanmıyorum çoğu test çerçeveler bu şekilde test hiç . Test takımı çalıştırılır (örneğin, yöneticiye kod vermeden önce veya dağıtmadan önce) ve sonuç, çalışıp çalışmadığını gösteren bir evet veya hayır olur. Test çerçeveleri, örneğin özellik ilerlemesini izlemek için işlerinin bir parçası olduğunu düşünmez ve test genellikle değildir. Burada yapacağınız iki test yazmanızdır expect_succeeds(foo(10)); expect_fails(foo(9)). Her seferinde her iki test de gerçekleştirilir ve başarılar ve beklenen başarısızlıklar geçer. Uyguladığınızda foo(9)ve başarılı olduğunuzda, beklenti-başarısızlık testi artık başarısız olur, bu nedenle yeniden yazarsınızexpect_succeeds(foo(9))ve bu tüm çerçevelerin kesinlikle standart bir özelliğidir. Ancak, hangi davranışı beklediğiniz konusunda açık olmalısınız, aksi takdirde yazılım testinin temel fikirlerine karşı çok fazla karşı karşıya kalır.

Bütün bunlara alternatif bir yaklaşım var. Kodunuzun yinelemeli ilerlemesini izlemek için ekstra iş yapmak için test çerçevesi almaya çalışıyorsunuz, ancak test çerçeveleri çalışıyor ve kodun anlık görüntülerinde başarılı veya başarısız yanıtlar vererek çalışması bekleniyor . algoritmasını almak , olduğu gibi bir test paketi oluşturmak , sonra adlı tam bir kopyasını oluşturmak , testler yapmak ve üzerinde çalışmaya devam etmek daha kolay olabilir . Şimdi (a) test çerçevesi ve karşılaştırmakta sorun yaşamaz.$A$$A$$A$$B$performs_better(foo_A(), foo_B())$B$$A$$B$ve (b) artık kodu eskisi gibi karşılaştırmanın bir anlamı yok, tüm kodlar ve testler şimdi değişmez ve açık. Bu, kişinin sistem yeniden yazımlarını nasıl ele alabileceğine benzer.