Bir algoritmik karmaşıklığı test etmeli mi? Öyleyse nasıl?

Diyelim ki sıralı bir listede / dizide arama yapmak gibi basit bir şey uyguluyorum. İşlev (c # 'da) şuna benzer:

static int FindIndex(int[] sortedList, int i);

Bunu işlevsellik açısından uygulayabilir ve test edebilirim, ancak bariz nedenlerle genellikle doğrusal bir arama veya kasıtlı olarak aptalca bir şey üzerinde ikili bir arama tercih ederim.

Benim sorum şu: Algoritmik karmaşıklık açısından performansı garanti eden testler yazmaya çalışmalı mıyız ve eğer öyleyse, nasıl?

Bu sorunun "yapmalısın" kısmının her iki tarafında da tartışmalar yapmaya başladım, ama tartışmalarım olmadan istemek için insanların söylediklerini görmek istiyorum.

"Nasıl" açısından, bu çok ilginç olur :) Karşılaştırma operatörünü parametreleştirdiğini ve karşılaştırma operatörü karşılaştırmaları veya bunun gibi bir şeyi sayan bir teste sahip olduğunu görebilirsiniz. Ama sadece yapabileceğiniz için yapmanız gerektiği anlamına gelmez ...

Başka kimse bunu düşündü mü (muhtemelen)? Teşekkürler.

Algoritmik karmaşıklık teorik bir yapıdır ve bu nedenle en iyi kalem ve kağıtla "test edilir". Mekanik olarak test edilemez.

Mutlak performans edebilir mekanik olarak test edilecek ve faydalı birim testleri yapabilirsiniz. Performans önemliyse, bir eşik belirtebilirsiniz: "bu sorgunun 10 ⁶ sayı üzerinde çalışması için 50ms'den fazla ve 10 ⁷ numaralarında 60ms'den fazla olmaması gerekir ." Yani yapabilirsiniz için bir birim test kurmak.

Son kullanıcı algoritmanızın doğrusal mı yoksa logaritmik mi olduğunu umursamıyor; uygulamada bir yıllık veri olduğunda bile kullanıcı arayüzlerinin hala anında yanıt verip vermediğini umursuyorlar.

Bu aracın birim testler için özellikle yararlı olup olmayacağından emin olmasam da, Goldsmith, Aiken ve Wilkerson'ın "Ampirik Hesaplama Karmaşıklığı" makalesi , kodun enstrümanı ve dinamik davranışını ampirik olarak çeşitli girdiler üzerinde gözlemlemek için bir yöntem açıklıyor asimptotik karmaşıklığını elde eder. Makalede açıklanan program açık kaynak kodludur ve burada mevcuttur .

Bu yardımcı olur umarım!

Ana şey, büyük verilerle deneyin ve çok uzun sürüp sürmediğine bakın.

Performans ayarlama deneyimimde, bu örnekte olduğu gibi, bazı algoritmalar (örneğin) O (n ^ 2) ise, sürenin yüzdesi asla radara girmediği sürece iyi olabilir.

Bununla birlikte, görülemeyen ancak yılda bir kez bir veri kümesi verildiğinde, bu algoritma tarafından emilen toplam sürenin felaketi felaketle baskın hale gelebilir.

Bunu testte yapabilirseniz, bu çok iyi bir şey, çünkü problemi gerçek bir sonsuz döngü gibi bulmak son derece kolaydır.

Ne yapmak istediğini düşünmüyorum Birim Test.

AFAIK, birim testi yalnızca kodun yapması gerekeni yaptığından ve performansa odaklanmadığından emin olmak içindir.

Gönderen Vikipedi : Test programında her hatayı yakalamak için beklenemez: hepsi her yürütme yolunu ama en önemsiz programları değerlendirmek mümkün değildir. Aynı şey birim testi için de geçerlidir. Ayrıca, tanım gereği birim testi yalnızca birimlerin işlevselliğini test eder. Bu nedenle, tümleştirme hatalarını veya daha geniş sistem düzeyi hatalarını (birden fazla birimde gerçekleştirilen işlevler veya performans gibi işlevsel olmayan test alanları gibi) yakalamaz. Birim testi, diğer yazılım test faaliyetleri ile birlikte yapılmalıdır. Tüm yazılım testi biçimleri gibi, birim testleri de yalnızca hataların varlığını gösterebilir; hataların olmadığını gösteremezler.

Performansı ölçmek için başka araçlar ve desenler vardır. Şimdi hatırlayabildiğim şeylerden biri, işlevsel olmayan gereksinimlere odaklanan Kabul testi .

Performans testi (stres testi, yük testi vb. Kullanan) gibi birkaç kişi daha vardır .

Ayrıca, dağıtım adımlarınızın bir parçası olarak (yaptığım şey) bir oluşturma aracı (karınca, otomatik yapı stüdyosu) ile birlikte bazı stres araçlarını da kullanabilirsiniz.

Yani kısa cevap hayır, birim kodu test ederken bunun için endişelenmemelisiniz.

Karşılaştırıcıyı geçmek ve kaç kez çağrıldığını takip etmek, sabit bir girişte (örneğin new int[] { 1,2,3, ... , 1024 }) arama yaparken karşılaştırma sayısının 10'un altında kalması gibi basit amaçlar için işe yarayacaktır . algoritmanın nasıl davranması gerektiği konusundaki niyetinizi netleştirin.

Birim testlerinin algoritmanızın O (log n) olduğunu doğrulamak için doğru yol olduğunu düşünmüyorum; bir grup veri noktasının beklenen çalışma süresine uyup uymadığını belirlemek için çok sayıda rastgele veri oluşturma, bazı eğri uydurma ve muhtemelen gnarly istatistiklere ihtiyaç duyacaktır. (Bu algoritma için muhtemelen yapılabilir, ancak sıralama vb. Almaya başlarsanız, en kötü durum senaryolarına tekrar tekrar vurmak zorlaşacaktır).