Birim testi ve test odaklı geliştirme stratejileri

Bilimsel hesaplamada test odaklı geliştirmenin büyük bir savunucusuyum. Pratikte faydası sadece şaşırtıcı ve kod geliştiricilerin bildiği klasik sorunları gerçekten hafifletiyor. Bununla birlikte, genel programlamada karşılaşılmayan bilimsel kodları test etmede doğal zorluklar vardır, bu nedenle TDD metinleri öğreticiler olarak çok yararlı değildir. Örneğin:

Genel olarak, belirli bir karmaşık problem için a priori kesin bir cevap bilmiyorsunuz, bu yüzden nasıl bir test yazabilirsiniz?
Paralellik derecesi değişir; Geçenlerde MPI görevlerini 3'ün katları olarak kullanmanın başarısız olacağı, ancak 2'nin katlarının çalıştığı bir hatayla karşılaştım. Ek olarak, ortak test çerçeveleri MPI'nin doğası gereği çok MPI dostu görünmüyor - görev sayısını değiştirmek için bir test ikili dosyasını yeniden yürütmeniz gerekiyor.
Bilimsel kodlar çoğu zaman sıkıca bağlı, birbirine bağımlı ve değiştirilebilir parçalara sahiptir. Hepimiz eski kodu gördük ve iyi tasarımdan vazgeçmenin ve global değişkenleri kullanmanın ne kadar cazip olduğunu biliyoruz.
Genellikle sayısal bir yöntem bir "deney" olabilir veya kodlayıcı nasıl çalıştığını tam olarak anlamıyor ve anlamaya çalışıyor, bu nedenle sonuçları tahmin etmek imkansız.

Bilimsel kod için yazdığım bazı test örnekleri:

Zaman entegratörleri için, kesin bir çözümle basit bir ODE kullanın ve entegratörünüzün verilen bir doğrulukta çözdüğünü test edin ve doğruluk sırası, değişen adım boyutlarıyla test ederek doğrudur.
Sıfır kararlılık testleri: 0 sınır / başlangıç koşullarına sahip bir yöntemin 0'da kaldığını kontrol edin.
İnterpolasyon testleri: doğrusal bir fonksiyon verildiğinde, enterpolasyonun doğru olduğundan emin olun.
Eski doğrulama: doğru olduğu bilinen eski bir uygulamada bir kod parçasını izole edin ve test için kullanmak üzere bazı ayrık değerleri çekin.

Hala el ile deneme ve hata dışında, belirli bir kod yığınını nasıl düzgün bir şekilde test edemediğimi ortaya çıkıyor. Sayısal kod için yazdığınız bazı test örnekleri ve / veya bilimsel yazılımı test etmek için genel stratejiler sağlayabilir misiniz?

testing

— Aurelius
kaynak

İnterpolasyon testleri ile ne demek istediğinizi açıklığa kavuşturabilir misiniz?

— Dmitry Kabanov

Yanıtlar:

Üretilen çözeltiler yöntemi .

İyileştirme çalışmaları yoluyla yöntemin teorik doğruluk sırasına ulaştığını doğrulayın.

Cevabın korunması. Bit bilge ve norm bilge çözüm üretimi.

— Bill Barth
kaynak

Orijinal yazıda MMS'den bahsetmek istedim; kod doğrulaması için iyidir, ancak birim testi açısından bakıldığında tamamen değersizdir. Bu testler başarısız olursa, nerede veya neden olduğu hakkında hiçbir ipucu vermez.

— Aurelius

@Aurelius: Ama test odaklı geliştirme için harika bir strateji! PDE / ODE / Doğrusal cebir kodları için, bir saniyeden daha kısa sürede çalışabilen çok küçük MMS testleri yazmalısınız . Bir değişiklik yaptığınızda, onları çalıştırırsınız. Eğer kırılırlarsa, yanlış bir şey yaptınız! öğeli bir sorunun size (veya her neyse) ne kadar söyleyebileceğine şaşıracaksınız .

2 \times 2 \times 2

$2\times 2\times 2$

— Bill Barth

MMS'de gördüğüm literatürün çoğu temelde küresel çözümlerdir, örneğin CFD sorunları için üretilen bir çözüm bir kanat profili analizi olabilir. Bu test başarısız olduğunda, en iyi ihtimalle suçluyu 5.000 kod satırına daralttınız, bu yüzden TDD için oldukça değersizdir - asıl hatanın ortaya çıktığı hakkında hiçbir fikriniz yoktur. 2x2x2'lik bir sorunun son derece değerli olduğunu kabul ediyorum ve kişisel olarak çok kullanıyorum. Ancak, yalnızca daha büyük sistemlerde ortaya çıkan sorunlarla karşılaşmam oldukça yaygındır; Aslında son zamanlarda sadece büyük sorunlarda tezahür eden bir ifort derleyici hatası buldum.

— Aurelius

@Aurelius: Burada tartışma yok. Bir dizi testiniz olmalı ve hepsini sık sık çalıştırmalısınız.

— Bill Barth

@Aurelius Yüz değerinde MMS, bir birim test değil, bir işlevsel veya kabul testidir (yani tüm sistemin). Bununla birlikte, kodlar genellikle ayrı aşamalara sahiptir (veya bunlara bölünebilir). örneğin adveksiyon, basınç, viskozite. Daha sonra bu aşamalardan sadece biri test edilebilir (bir "birim"). Benzer şekilde, bir kod BC olmadan ve sonra da bir kodla test edilebilir. Bir arkadaşım birim testinde doktora yaptı ve büyük artısı ise bu yüzden, birimler halinde programınızı kırmak için zorladı oldu hesaba olabilir birim test edilmiş olmalı belki de bu ilk başta göründüğünden daha burada daha uygulanabilir ... (ve başka şekillerde bilmiyorum).

— hyperpallium

Bill, endişelerinizi ele alan birkaç yöntem zaten listeledi.

Üçüncü noktanıza hitap eden, hayır, parçalar arasında güçlü bağlantı sağlamak için hiçbir neden yoktur. Tam tersi: işlevleriniz veya sınıflarınız iyi tanımlanmış arabirimlere sahipse, örneğin doğrusal bir çözücüyü diğeriyle veya zaman atlama şemasıyla değiştirmek çok daha kolay olacaktır. Sadece direnç gösterin, ardından bu bileşenleri ayrı ayrı test edebilirsiniz. Bunu anlaşma ile yaptık. Onlarca yıldır.

Dördüncü noktanıza: yönteminiz bir deneyse, yöntemle yaptığınız denemeler bir test oluşturur. Analiziniz olmadığı sürece, bu test sonuçlarını mümkün olan en iyi şekilde almanız gerekecektir. Ancak genellikle, örneğin bir yöntemin sırası için bir beklentiniz vardır veya belirli bir çözüm sınıfı, örneğin belirli bir dereceye kadar polinomlar için kesin olduğunu bilirsiniz. Bunları doğrulamak denemelerinizin bir parçası olmalıdır ve analiz ilerledikçe testler eklenebilir.

— Guido Kanschat
kaynak

Guido'nun cevabına ek olarak, konuştuğu deneyim, her değişiklikten sonra anlaşma üzerinde gerçekleştirdiğimiz ~ 3.000 testte kodlanmıştır: ii.lilii.org/developer/development/… . Kesin cevabı bilmiyorsanız ne yapacağınız sorusu üzerine: Yine de bir test yazın ve bugünkü cevabı dün (veya testi yazdığınızda) karşılaştırın. Yanıtın yanlış yapılıp yapılmadığını veya daha önce yanlış olan bir yanıtı düzeltip düzeltmediklerini bilmeseniz bile, bir kodun çıktısındaki değişiklikleri tespit etmenin bir yolu vardır .

— Wolfgang Bangerth

Son zamanlarda Hesaplamalı Bilimlerde TDD üzerine bu tezi buldum. Henüz okumadım, bu yüzden iyi olup olmadığı hakkında hiçbir fikrim yok, ama umarım biraz yardımcı olabilir.

http://cyber.ua.edu/files/2014/12/u0015_0000001_0001551.pdf

— şarjör
kaynak

Giriş ve sonuçlardan bazılarını gözden geçirdim ve standart doktora tezi ile aynı seviyede bir kalite seviyesi olduğunu varsaydım, bu hem süreci açıklar (yüksek düzeyde) ve etkinliği ile ilgili gerçek ölçümler verir. Bence bu bir keşif.

— Godric Seer

Bağlantı öldü. Şunu mu demek istediniz: Nanthaamornphong, A. “Hesaplamalı bilim ve mühendislik yazılımı geliştirmede test odaklı geliştirme ve yeniden düzenleme tekniklerinin etkinliği”. Doktora tezi, Uni. Alabama (2014).

— AlQuemist