Test verilerine ihtiyacımız var mı yoksa birim testlere ve manuel testlere güvenebilir miyiz?

Şu anda orta / büyük bir PHP / MySQL projesi üzerinde çalışıyoruz. PHPUnit & QUnit ile birim testi yapıyoruz ve uygulamayı manuel olarak test eden iki tam zamanlı testçimiz var. Test (sahte) verilerimiz şu anda SQL komut dosyalarıyla oluşturulmaktadır.

Test verileri için komut dosyalarını koruma konusunda sorun yaşıyoruz. İş mantığı oldukça karmaşıktır ve test verilerindeki bir "basit" değişiklik genellikle uygulamada birkaç hata üretir (bunlar gerçek hatalar değildir, sadece geçersiz verilerin ürünüdür). Bu, tüm takım için büyük bir yük haline geldi, çünkü sürekli olarak tablolar oluşturuyor ve değiştiriyoruz.

Komut dosyalarında test verilerini koruma noktasını gerçekten görmüyorum, çünkü her şey kullanıcı arayüzüyle yaklaşık 5 dakika içinde uygulamaya manuel olarak eklenebilir. Başbakanımız buna katılmıyor ve test verileriyle dağıtamayacağımız bir projeye sahip olmanın kötü bir uygulama olduğunu söylüyor.

Komut dosyalarının test verileriyle bakımından vazgeçmeli ve sadece test kullanıcılarının uygulamayı veri olmadan test etmesine izin vermeli miyiz? En iyi uygulama nedir?

İki farklı kavramı karıştırıyorsunuz. Bunlardan biri Birim Testi ve Hakem İncelemelerine dayanan doğrulamadır . Bu, test verileri olmadan geliştiricilerin kendileri tarafından yapılabilir ve amacı bir dizi gereksinimin karşılandığını doğrulamaktır.

İkincisi doğrulamadır ve bu QA (test kullanıcılarınız) tarafından yapılır. Bu adım için test verisine ihtiyacınız vardır, çünkü test cihazı uygulamadaki programlama hakkında herhangi bir bilgiye sahip olmak zorunda değildir, sadece amaçlanan kullanım durumlarıdır. Amacı, uygulamanın bir üretim ortamında tasarlandığı gibi davrandığını doğrulamaktır.

Her iki süreç de müşteriye kaliteli bir ürün sunmak için önemlidir ve gereklidir. Sadece birim testlere güvenemezsiniz. Anlamanız gereken, test verilerinizin geçerli olduğundan emin olmak için güvenilir bir yöntemdir.

EDIT: Tamam, istediğini alıyorum. Cevap evet, çünkü Test Cihazının işi test verilerini üretmek değil, sadece uygulamayı test etmek. Komut dosyalarınızı daha kolay bakım sağlayacak ve geçerli verilerin eklenmesini sağlayacak şekilde oluşturmanız gerekir. Test verileri olmadan, test cihazının test edecek hiçbir şeyi olmayacaktır. Bununla birlikte, test ortamına erişiminiz varsa , komut dosyalarını kullanmak yerine test verilerini neden manuel olarak ekleyemediğinizi anlamıyorum.

Evet, birim testlere ve veri maketlerine sahip olmak en iyi uygulamadır. Proje yöneticisi doğrudur. Test verilerinde "basit" bir değişiklik yapmak genellikle hatalar ürettiğinden, sorunun özü budur.

Kodun iyileştirilmesi gerekiyor. Bunu yapmamak (hey, testlere ihtiyacımız yok demek) bir düzeltme değildir, bu sadece teknik borç eklemek demektir . Kodu daha küçük, test edilebilir daha küçük birimlere ayırın, çünkü birimleri kırılmadan tanımlayamamak bir sorundur.

Refactor yapmaya başlayın. Geliştirmeleri yönetilebilir olması için küçük tutun. KURU, tek sorumluluk vb. Olmayan Tanrı sınıfları / yöntemleri gibi anti-kalıpları arayın ...

Son olarak, ekip için işe yarayıp yaramadığını görmek için TDD'ye bakın. TDD, tüm kodunuzun test edilebilir olmasını sağlamak için iyi çalışır (çünkü önce testleri yazıyorsunuz ) ve ayrıca testleri geçmek için yeterli kod yazarak (mühendislik üzerinde en aza indirgeyin) yalın kalmanızı sağlar .

Genel olarak, bir dizi karmaşık iş mantığı işlemi bir veri kümesi üretirse, bunu bir rapor olarak görüyorum. Raporu kapsülleyin. Raporu çalıştırın ve sonuçtaki nesneyi bir sonraki sınama için girdi olarak kullanın.

Bu çok yaygın ve çok zor bir sorundur. Bir veritabanına ( HSQLDB gibi bir bellek içi veritabanı bile) çalışan otomatik testler genellikle yavaş, belirleyici değildir ve bir test hatası yalnızca kodunuzda veya verilerinizde bir yerde bir sorun olduğunu gösterir. fazla bilgilendirici değil.

Deneyimlerime göre, en iyi strateji iş mantığı için birim testlere odaklanmaktır. Temel alan kodunuzu mümkün olduğunca kapsamaya çalışın. Bu bölümü doğru bulursanız, ki bu oldukça zor bir iştir, otomatik testler için en iyi maliyet-fayda ilişkisini elde edeceksiniz. Kalıcılık katmanına gelince, normalde otomatik testlere çok daha az çaba harcıyorum ve bunu özel manuel test kullanıcılarına bırakıyorum.

Ancak, kalıcılık testlerini otomatikleştirmek istiyorsanız (veya ihtiyacınız varsa) , Testler tarafından yönlendirilen Büyüyen Nesne Tabanlı Yazılımları okumanızı tavsiye ederim . Bu kitapta kalıcılık testlerine ayrılmış bir bölüm vardır.