Bilimsel araştırma kodları için birim testleri yazmaya değer mi?

Otomatik bir regresyon testi seti de dahil olmak üzere, tam bir programı doğrulayan testleri (örneğin yakınsama testleri) kullanmanın değeri konusunda kesinlikle ikna oldum . Bazı programlama kitaplarını okuduktan sonra, birim testleri ( " tek bir işlevin doğruluğunu doğrulayan ve bir sorunu çözmek için tüm kodu çalıştırmaya yetmeyecek olan testler ") "yapmam" gerektiği gibi dürtme hissine kapıldım. . Bununla birlikte, birim testler her zaman bilimsel kurallara uymuyor gibi görünmekte ve sonuçta yapay veya zaman kaybı gibi görünmektedir .

Araştırma kodları için birim testleri yazmalı mıyız?

Uzun yıllar boyunca, kodum için birim testleri yazmak için yeterli zamanım olmadığından yanlış anlaşıldım. Testler yazarken, şişirilmişlerdi, beni ancak ihtiyaç duyduğumu bildiğimde sadece birim testleri yazmam gerektiğini düşünmem için cesaretlendiren ağır şeylerdi .

Sonra Test Driven Development kullanmaya başladım ve tam bir vahiy buldum. Şimdi, kesin olarak birim testleri yazmamaya vaktim olmadığına ikna oldum .

Tecrübelerime göre, akılda tutularak test geliştirerek daha temiz arayüzler, daha çok odaklanmış sınıflar ve modüller ve genellikle daha fazla SOLID , test edilebilir kod ile karşılaşırsınız.

Her ne zaman birim testine sahip olmayan ve bir şeyi manuel olarak test etmek zorunda olan eski kodla çalıştığımda, "bu kod zaten birim testlerine sahipse bu çok daha hızlı olacağını" düşünüyorum. Her ne zaman yüksek kuplajlı koda ünite testi işlevini denemek ve eklemek zorunda kalsam, "bunun çift bağlı bir şekilde yazılmış olsaydı daha kolay olacağını" düşünüyorum.

Desteklediğim iki deneysel istasyonu karşılaştırmak ve karşılaştırmak. Biri bir süredir buralarda ve bir sürü eski kural var, diğeri ise nispeten yeni.

Eski laboratuara işlevsellik eklerken, genellikle laboratuara inmek ve ihtiyaç duydukları işlevsellik ve diğer işlevselliklerini etkilemeden bu işlevselliği nasıl ekleyebileceğim üzerinde çalışmak için saatlerce zaman harcamak söz konusudur. Kod, çevrimdışı testlere izin verecek şekilde ayarlanmamış, bu nedenle hemen hemen her şeyin çevrimiçi olarak geliştirilmesi gerekiyor. Çevrimdışı geliştirmeyi denesem , makul olandan daha fazla sahte nesne ile karşılaşırdım .

Daha yeni laboratuvarda, hemen hemen gerekli olan şeyleri alay ederek ve daha sonra laboratuvarda kısa bir zaman harcayarak, çözülemeyen tüm sorunları ütülenerek masamda çevrimdışı hale getirerek işlevsellik ekleyebilirim. -hat.

Netlik için, ve @ naught101'den beri sordum ...

Bazı özel veri analizleriyle deneysel kontrol ve veri toplama yazılımları üzerinde çalışmaya meyilliyim, bu nedenle TDD'nin revizyon kontrolü ile kombinasyonu, hem temel deney donanımındaki değişiklikleri hem de zamanla veri toplama gereksinimlerindeki değişiklikleri belgelemeye yardımcı olur.

Bununla birlikte, keşif kodunun geliştirilmesi durumunda bile, varsayımların kodlanmasından ve bu varsayımların zaman içinde nasıl geliştiğini görebilme yeteneğimden önemli bir fayda görebiliyorum.

Bilimsel kodlar, genellikle problemin matematiksel yapısından dolayı üzerinde çalıştığım iş kodlarından daha sık birbirine bağlı fonksiyon takımyıldızlarına sahip olma eğilimindedir. Bu nedenle, bireysel fonksiyonlar için birim testlerinin çok etkili olduğunu düşünmüyorum. Ancak, etkili ve belirli bir işlevselliği hedefledikleri için bütün program testlerinden oldukça farklı olan bir birim test sınıfı olduğunu düşünüyorum.

Bu tür testlerle ne demek istediğimi kısaca tanımlarım. Regresyon testi , kodda değişiklik yapıldığında mevcut davranıştaki değişiklikleri (bir şekilde doğrulanır) arar. Ünite testi bir kod parçasını çalıştırır ve bir şartnameye göre istenen bir çıktı verdiğini kontrol eder. Orijinal regresyon testi gibi onlar, o farklı değildir idi ben çıkış geçerli olduğunu belirlemek zorunda beri bir birim testi.

Sayısal birim testine en sevdiğim örnek sonlu elemanlar uygulamasının yakınsama hızını test etmektir. Kesinlikle basit değildir, ancak bir PDE'ye bilinen bir çözümü alır, örgü boyutunda azalan çeşitli problemler uygular ve daha sonra hata normunu eğrisine uyar, burada yakınsama hızıdır. Bunu PETSc'deki Pyisson sorunu için Python kullanarak yapıyorum. Ben Regresyondaki gibi bir fark aramıyorum, ama özellikle oranı verilen elemanı için belirtilen.c h r r $h$$C h^r$$r$$r$

PyLith'ten gelen iki birim test örneği , birkaç işlevi içeren, ancak sınırlı bir parçaya hitap eden, bir ağda sıfır hacimli birleşik hücrelerin oluşturulması için sentetik sonuçların üretilmesi kolay olan tek bir fonksiyon olan nokta konumudur. koddaki işlevsellik.

Koruma ve tutarlılık testleri dahil olmak üzere bu tür birçok test vardır. İşlem, regresyondan farklı değildir (bir sınama yaparsınız ve çıktıyı bir standarda göre kontrol edersiniz), ancak standart çıktı önceki çalışmadan ziyade bir spesifikasyondan gelir.

Code Complete'te Test Odaklı Gelişim hakkında okuduğumdan beri , 2. baskı , bir birim test çerçevesi kullandımgelişim stratejimin bir parçası olarak ve hata ayıklama için harcadığım zamanı azaltarak verimliliğimi önemli ölçüde artırdım, çünkü yazdığım çeşitli testler tanısal. Yan yarar olarak, bilimsel sonuçlarıma çok daha güveniyorum ve sonuçlarımı savunmak için birim testlerimi birkaç kez kullandım. Birim testinde bir hata varsa, genellikle neden bu kadar çabuk olduğunu anlayabilirim. Uygulamam çökerse ve tüm birim testlerim geçerse, kodumun hangi kısımlarının kullanılmadığını görmek için kod kapsam analizi yapıyorum, ayrıca hatanın kaynağını belirlemek için kod ayıklayıcıyla adım adım ilerliyorum. Sonra hatanın sabit kaldığından emin olmak için yeni bir test yazarım.

Yazdığım testlerin çoğu saf birim testleri değil. Kesin olarak tanımlanmış, birim testlerinin bir fonksiyonun işlevselliğini kullanması beklenir. Sahte verileri kullanarak tek bir işlevi kolayca test edebildiğimde bunu yapıyorum. Diğer zamanlarda, verilen bir işlevin işlevselliğini uygulayan bir test yazmak için ihtiyaç duyduğum verilerle kolayca dalga geçemiyorum, bu yüzden bu işlevi diğerleriyle birlikte bir bütünleşme testinde test edeceğim. Entegrasyon testleriAynı anda birden fazla fonksiyonun davranışını test edin. Matt'in işaret ettiği gibi, bilimsel kodlar çoğu zaman birbirine kenetlenen fonksiyonların bir takımyıldızıdır, ancak çoğu zaman belirli fonksiyonlar sırayla çağrılır ve çıktıyı ara adımlarda test etmek için birim testleri yazılabilir. Örneğin, üretim kodum sırasıyla beş işlevi çağırırsa, beş test yazacağım. İlk test sadece ilk işlevi çağırır (bu bir ünite testidir). Ardından, ikinci test birinci ve ikinci işlevleri arayacak, üçüncü test ilk üç işlevi vb. Arayacak. Kodumdaki her bir fonksiyon için birim testleri yazabilseydim bile, yine de entegrasyon testleri yazdım çünkü bir programın çeşitli modüler parçaları birleştirildiğinde hatalar ortaya çıkabilir. Sonunda, tüm birim testlerini ve entegrasyon testlerini yazdıktan sonra ihtiyacım olduğunu düşünüyorum. Örnek olaylarımı birim testlerine sarıp bunları regresyon testi için kullanacağım çünkü sonuçlarımın tekrarlanabilir olmasını istiyorum. Tekrarlanabilirlerse ve farklı sonuçlar elde edersem, nedenini bilmek istiyorum. Bir regresyon testinin başarısızlığı gerçek bir sorun olmayabilir, ancak yeni sonuçların en azından eski sonuçlar kadar güvenilir olup olmadığını anlamam için beni zorlar.

Ayrıca, ünite testi ile birlikte, statik kod analizi, bellek hata ayıklayıcıları ve basit hataları ve kullanılmayan kodu yakalamak için derleyici uyarı bayraklarıyla derleme de faydalıdır.

Deneyimlerime göre, bilimsel araştırma kodlarının karmaşıklığı arttıkça, programlamada çok modüler bir yaklaşıma ihtiyaç duyulmaktadır. Bu, büyük ve eski temelli ( f77herkes?) Kodlar için acı verici olabilir , ancak ileriye doğru ilerlemek gerekir. Bir modül, kodun belirli bir yönüne göre oluşturulduğundan (CFD uygulamaları için, Sınır Koşulları veya Termodinamik'i düşünün), ünite testi, yeni uygulamayı doğrulamak ve sorunları izole etmek ve yazılım geliştirmelerini yapmak için çok değerlidir.

Bu ünite testleri kod doğrulamasının bir seviyesinin altında (dalga denklemimin analitik çözümünü geri alabilir miyim?) Ve kodun onaylanmasının altında iki seviye olmalıdır (türbülanslı boru akışımda doğru tepe RMS değerlerini tahmin edebilir miyim ?) (argümanlar doğru olarak iletildi mi, işaretçiler doğru olanı mı gösteriyor?) ve "matematik" (bu alt rutin sürtünme katsayısını hesaplar. Bir sayı kümesi girip çözümü el ile hesaplarsam, rutin aynı sonuçları verir mi? sonuç?) doğru. Temel olarak, derleyicilerin görebileceği seviyenin bir seviyesinin üstüne, yani temel sözdizimi hataları.

Uygulamanızdaki en azından bazı önemli modüller için kesinlikle tavsiye ederim. Bununla birlikte, kişi bunun son derece sıkıcı ve zaman alıcı olduğunu anlamalıdır, böylece sınırsız insan gücüne sahip olmadığınız sürece, bunu% 100 karmaşık bir kod için tavsiye etmem.

Bilimsel kodlar için birim testi, çeşitli nedenlerle faydalıdır.

Özellikle üç:

• Birim testleri, diğer kişilerin kodunuzun kısıtlamalarını anlamalarına yardımcı olur. Temel olarak, birim testleri bir dokümantasyon şeklidir.

• Ünite testleri, tek bir kod ünitesinin doğru sonuçlar döndürdüğünden emin olmak için kontrol eder ve ayrıntılar değiştirildiğinde bir programın davranışının değişmediğinden emin olun.

• Birim testlerini kullanmak, araştırma kodlarınızı modülerleştirmeyi kolaylaştırır. Kodunuzu yeni bir platformda hedeflemeye çalışıyorsanız, örneğin paralel hale getirmekle veya bir GPGPU makinesinde çalıştırmayı düşünüyorsanız, bu özellikle önemli olabilir.

Hepsinden önemlisi, birim testleri, kodlarınızı kullanarak ürettiğiniz araştırma sonuçlarının geçerli ve doğrulanabilir olduğuna güvenmenizi sağlar.

Sorunuzda regresyon testinden bahsettiğinizi unutmayın. Pek çok durumda, regresyon testi otomatik, düzenli birim testleri ve / veya entegrasyon testlerinin gerçekleştirilmesi (bu kod parçalarının birleştirildiğinde doğru çalıştığını test eden; bilimsel hesaplamada, genellikle deneysel verilere göre verileri karşılaştırarak yapılır) güvenilen önceki programların sonuçları). Başarılı bir şekilde büyük karmaşık bileşenler düzeyinde entegrasyon testleri veya birim testi kullanıyor gibi görünüyorsunuz.

Söyleyeceğim şey, araştırma kodlarının giderek daha karmaşık hale gelmesi ve diğer insanların kodlarına ve kütüphanelerine güvenmesi olarak, hatanın ne zaman gerçekleştiğini anlamak önemlidir. Birim testi, hatanın daha kolay tespit edilmesini sağlar.

Bilimsel Hesaplama için En İyi Uygulamalar üzerine yazdığım makalenin 7. Bölümündeki "Hatalar için Planla" bölümünde tanım, kanıt ve referansları yararlı bulabilirsiniz - ayrıca savunma programlamanın tamamlayıcı konseptini de tanıtmaktadır.

Benim deal.II sınıflarda ben düzgün çalışması (ve kasıtlı "dedi strese gitmez testleri yok yazılım öğretmek gelmez değil", düzgün çalışmayabilir" olabilir düzgün çalışmaz).

Tabii ki ben mantra ile yaşıyorum - işte bu kadar anlaşma. Her tesadüfen 2.500 test yapmaya geldim ;-)

Daha ciddiyim, bence Matt zaten iki test sınıfını iyi tanımlamıştır. Alt seviye eşyalar için birim testleri yazıyoruz ve doğal olarak üst seviye eşyalar için regresyon testlerine doğru ilerliyor. Testlerimizi bir tarafa ya da diğerine ayıracak net bir sınır çizebileceğimi sanmıyorum, kesinlikle birisinin çıktıya bakıp hattını büyük ölçüde makul bulduğu çizgiyi izleyen pek çok kişi var (birim testi?) Son doğruluk derecesine bakmadan (regresyon testi?).

Evet ve hayır. Yaşamınızı kolaylaştırmak için kullandığınız temel araç setinin temel rutini için kesinlikle en içindekiler, örneğin dönüşüm rutinleri, dizi eşlemeleri, temel fizik ve matematik vb. Bunları aslında birimler yerine fonksiyonel testler olarak test etmeyi tercih edebilirsiniz. Ayrıca, en içten olanı ve seviyesi ve kullanımı çok değişecek olan (örneğin optimizasyon amaçlı) veya iç detayları ne olursa olsun değişecek olan sınıfları ve varlıkları vurgulayın. En tipik örnek, diskten eşlenen büyük bir matrisi saran bir sınıftır.

Kesinlikle!

Bu senin için yeterli değil mi?

Bilimsel programlamada, diğer türlerden daha fazla, fiziksel bir sistemle eşleşmeye çalışarak geliştiriyoruz. Bunu testten başka yapıp yapmadığınızı nasıl bileceksiniz? Kodlamaya başlamadan önce, kodunuzu nasıl kullanacağınıza karar verin ve birkaç örnek deneme çalışın. Olası kenar davalarını yakalamaya çalışın. Modüler bir şekilde yapın - örneğin, sinir ağı için tek bir nöron için bir test seti ve tam bir sinir ağı için bir test seti yapabilirsiniz. Bu şekilde kod yazmaya başladığınızda, ağ üzerinde çalışmaya başlamadan önce nöronunuzun çalıştığından emin olabilirsiniz. Bu gibi aşamalarda çalışmak, bir sorunla karşılaştığınızda yalnızca test edilecek en yeni kod aşamasına sahip olduğunuz anlamına gelir; önceki aşamalar zaten test edilmiştir.

Ayrıca, testleri tamamladıktan sonra, kodu farklı bir dilde (örneğin CUDA'ya dönüştürme) yeniden yazmanız gerekiyorsa veya yalnızca güncellemiş olsanız bile, test testlerine sahip olursunuz ve bunları yapmak için kullanabilirsiniz. Programınızın her iki sürümünün de aynı şekilde çalıştığından emin olun.

Evet.

Herhangi bir kodun birim testleri olmadan yazılması fikri, bir anatemadır. Kodunuzu doğru ve kanıt ispat etmiyorsanız = P.

Bu soruya dogmatik olarak değil pratik olarak yaklaşırdım. Kendinize şu soruyu sorun: "X işlevinde ne yanlış gidebilir?" Kodda bazı tipik hatalar ortaya çıkardığınızda çıktıya ne olduğunu bir düşünün: yanlış bir ön faktör, yanlış bir dizin, ... Ve daha sonra bu tür bir hatayı algılaması muhtemel birim sınamaları yazın. Belirli bir fonksiyon için, fonksiyonun kodunu tekrarlamadan bu tür testleri yazmanın bir yolu yoksa, o zaman yapmayın - ama bir sonraki daha yüksek seviyedeki testleri düşünün.

Bilimsel koddaki birim testlerle (ya da aslında herhangi bir testle) ilgili çok daha önemli bir problem , kayan nokta aritmetiğindeki belirsizliklerle nasıl başa çıkılacağıdır. Bildiğim kadarıyla henüz iyi bir genel çözüm yok.

Tangurena için üzülüyorum - buralarda, mantra "Test edilmemiş kod bozuk kod" dür ve patrondan gelmiştir. Ünite testi yapmak için tüm iyi nedenleri tekrarlamak yerine, sadece birkaç özellik eklemek istiyorum.

• Hafıza kullanımı test edilmelidir. Hafızayı tahsis eden her fonksiyon, bu hafızaya veri depolayan ve alan fonksiyonların doğru olanı yaptığından emin olmak için test edilmelidir. Bu GPU dünyasında daha da önemlidir.
• Daha önce kısaca bahsedilse de, son test vakaları son derece önemlidir. Bu testleri, herhangi bir hesaplamanın sonucunu test ettiğiniz gibi düşünün. Giriş parametreleri veya veriler kabul edilebilir sınırların dışına çıktığında, kodun kenarlarda davrandığından ve inceliksizce başarısız olduğundan emin olun (ancak bunu simülasyonunuzda tanımlarsınız). Bu tür bir sınama yazmanın içerdiği düşünce, çalışmanızı keskinleştirmeye yardımcı olur ve ünite sınamaları yazan ancak nadiren bu işlemi yararlı bulmayan birini bulmanızın nedenlerinden biri olabilir.
• Bir test çerçevesi kullanın (güzel bir bağlantı sağlayan Geoff'in söylediği gibi). BOOST test çerçevesini CMake'nin CTest sistemi ile birlikte kullandım ve hızlı bir şekilde birim testleri (validasyon ve regresyon testleri gibi) yazmanın kolay bir yolu olarak önerebilirim.

Birim testini , parçacık fiziğindeki tez analiz kodumun üçüncü versiyonu da dahil olmak üzere birkaç küçük ölçekli (yani tek programcı) kodlar üzerinde iyi bir etki için kullandım .

İlk iki versiyon kendi ağırlıkları ve ara bağlantıların çarpımı altında çöktü.

Diğerleri modüller arasındaki etkileşimin çoğu zaman bilimsel kodlamanın bozulduğu yer olduğunu ve bu konuda haklı olduklarını yazmışlardır. Ama teşhis etmek çok daha kolay olanlar , her modül şunu kesin olarak gösterebilir sorunlara edilir bunu yapmak içindir yapıyor.

Kimyasal bir çözücü (karmaşık jeolojik alanlar için) geliştirirken kullandığımdan biraz farklı bir yaklaşım, Kopyalama ve Yapıştırma Parçacığı ile Birim Testi olarak adlandırdığınız şeydi .

Büyük bir kimyasal sisteme yerleştirilmiş orijinal kod için bir test demeti inşa etmek modeller zaman aralığında mümkün değildi.

Bununla birlikte, farklı ifadeler için birim testleri olarak (Boost Spirit) kimyasal formüller için nasıl ayrıştırıcı çalıştığını gösteren, gittikçe karmaşıklaşan bir snippet seti çalışabildim.

Son, en karmaşık birim testi, sistemde ihtiyaç duyulan koda çok yakındı, bu kodu değiştirilmek zorunda kalmadan değiştirdi. Böylece birim test kodumu kopyalayabildim.

Bunu bir öğrenme alıştırmasından ve gerçek bir regresyon odasından daha fazla yapan şey iki faktördür - ana kaynakta tutulan ünite testleri ve bu uygulama için diğer testlerin bir parçası olarak çalıştırıldı (ve evet, Boost’tan bir yan etki aldı. Ruhun 2 yıl sonra değişmesi) - kopyalanıp yapıştırılan kodun asıl uygulamada minimal olarak değiştirilmiş olması nedeniyle, birinin senkronize edilmesine yardımcı olmak için birim testlerine atıfta bulunan yorumlar olabilir.

Daha büyük kod tabanları için, yüksek seviyeli malzemeler için testler (mutlaka ünite testleri değil) faydalıdır. Bazı basit algoritmalar için birim testleri de, kodunuzun saçma olmadığından emin olmak için faydalıdır çünkü yardımcı işleviniz sinyerine kullanılır cos.

Ancak genel araştırma kodu için test yazmak ve sürdürmek çok zordur. Algoritmalar, belirgin testler yapabilen ve sonuç ortaya çıkmadan önce uzun süren anlamlı ara sonuçlar olmadan büyük olma eğilimindedir. Elbette iyi sonuç veren referans çalışmalarına karşı test edebilirsiniz, ancak bu birim test anlamında iyi bir test değildir.

Sonuçlar genellikle gerçek çözümün yaklaşıklarıdır. Basit fonksiyonlarınızı bazı epsilonlara kadar doğru olup olmadıklarını test edebilmenize rağmen, bazı sonuç ağlarının doğru olup olmadığını, daha önce kullanıcı (tarafından) tarafından görsel inceleme ile değerlendirilmiş olduğunu doğrulamak çok zor olacaktır.

Bu gibi durumlarda otomatik testler genellikle çok yüksek bir maliyet / fayda oranına sahiptir. Daha iyi bir şeyler öneriyorum: Test programları yaz. Örneğin, bir ağın kenar boyutları ve açıları histogramları, en büyük ve en küçük üçgenin alanı ve bunların oranı vb. Gibi sonuçlar hakkında veri oluşturmak için orta boyutlu bir python komut dosyası yazdım.

Normal çalışma sırasında, giriş ve çıkış kafes değerlendirmek için kullanabilir hem ve bir algoritma değiştirdikten sonra bir performans kontrolü için kullanın. Algoritmayı değiştirdiğimde yeni sonucun daha iyi olup olmadığını her zaman bilmiyorum, çünkü hangi yaklaşımın en iyi olduğu ile ilgili kesin bir ölçüm yoktur. Ancak bu tür ölçütler üreterek bazı faktörler hakkında "Ne var ki yeni değişken daha iyi bir açı oranına, ancak daha kötü bir yakınsama oranına" sahip olduğunu söyleyebilirim.