PHPUnit ile nasıl iş teklifi yapabilirim?

Ben 15 yıldır web sitesi programlama ve son 5 yıldır PHP yapıyorum. Hep katı kod yazdım. Ancak, birim test edilen kodun% 80'i üzerinde ısrar eden bir istemcim var. İstemci DAİMA SAĞ olduğundan, kodumun doğru göründüğünden emin olmak için PHP_CodeSniffer ve birim testimi yapmak için PHPUnit kullanmayı planlıyorum. Bu deneyim sayesinde bir şeyler öğrenmeyi umuyorum.

Bunlar kullanılacak doğru araçlar mı? PHPUnit'in ayarlanması ve ek kodun yazılmasında ne kadar zaman vardır? Web sayfalarını yazmak ve geçmişte yaptığım gibi kendi kendini test etmek yaklaşık 8 hafta sürmeli. Birim testi (PHPUnit) için 4 gün ek (% 10) eklersem, bu yeterli mi? Düşünceler? Öneriler? Teşekkürler.

Tek satırda: nasıl çalıştığınıza bağlıdır. Ben honesly% 10 çok az olduğunu düşünüyorum. En az% 25,% 40 değilse,% 60 değilse, daha fazla değilse.

İlk olarak, orada müşteri ile çok katılıyorum. Birim testleri, sağlam, bakımı kolay, hata ayıklaması kolay bir ürünün önemli bir parçasıdır.

Bildiklerimden konuşacağım. Çoğu proje için TDD (Test Odaklı Geliştirme) kullanıyorum. TDD temel olarak testleri gerçek koddan önce yazmanızı sağlar. Son ürünün karşılaması gereken bir dizi kabul kriteri oluşturuyorlar. Genellikle, test yazma zamanınızın% 50 ila% 70'ini ve bunları geçmek için kalan kodları uygularsınız.

Kulağa saçma ve / veya muazzam gelse de, olmadığından emin olabilirim. İşte nedeni:

• Testleri yazarken kullanılacak en iyi mimari desen (ler) in ne olduğunu bulabileceksiniz. Bu şekilde, kodlamaya başladığınızda, uygulama mimarisi minimum düzeyde değişecektir (çünkü hepimiz bir uygulama mimarisini yeniden yapmanın ne kadar pahalı olduğunu biliyoruz).
• Yalnızca testleri geçmesi için kodlarsınız (bu nedenle son ürünü kabul edilebilir hale getirir). Yararsız / kapsam dışı özellikleri programlamak için zaman harcamazsınız.
• Daha az koda sahip olmak (yani: sadece gerçekten ihtiyacınız olan kod), daha az hataya açıktır. (Daha az kod = daha az hata).
• Bir hata yaparsanız ve yaparsanız, neden bir sorun olduğunu ve sorunun nerede olduğunu anlamak çok daha az zaman alacaktır. Testler doğru yazılırsa, tek bir hatanın zincir reaksiyonuna değil, tek bir hataya neden olacağı anlamına gelir. Bu şekilde, sorunun kaynağını saniyeler değil, birkaç dakika içinde kolayca belirleyebilirsiniz.
• Ünite testleri ile gerçek kodun uygulanması çok daha az zaman alacaktır. Test başarısız olur olmaz bir şeyin yanlış olduğunu bilirsiniz. Hataları düzeltmek için istemci ile ileri geri yapmanız gerekmez.
• Sonunda, hataları düzeltmek için istemci ile ileri geri yapmanız gerekecek, çünkü hiçbir şey hataların% 100'ünü yakalayamaz. Ancak, daha fazla değilse% 95'i kolayca yakalayabilirsiniz.

PHPUnit, PHP'yi birim test etmek için fiili bir araçtır ve bu konuda çok iyidir. PHP_CodeSniffer'ı fazla kullanmadım. Ancak, eğer yalnız çalışıyorsanız muhtemelen buna ihtiyacınız olmadığını düşünüyorum. Bir kodda, kimin kodladığına bakılmaksızın kodun aynı göründüğünden emin olmak daha yararlıdır.

Bu deneyimden bir şeyler öğreneceğiniz tavrına sahip olduğunuz için size yardımcı olur. Yapacağından eminim.

Öğrenmeniz gereken ilk şey , birim test zorunluluğunun ne kadar deneyimli olduğunuzla ilgisi olmamasıdır . En iyi geliştirici de en iyi birim test cihazlarından biri olacak:

Bill Venners: Kitabınızda Refactoring diyorsunuz: " Refactor istiyorsanız, temel ön koşul sağlam testler yapmaktır ." Bu testleriniz yoksa refactor olmamalı anlamına mı geliyor?

Martin Fowler: Bunu, ağsız bir ipte yürümek olarak düşünmelisiniz. Eğer bir ipte yürümekte iyiyseniz ve o kadar yüksek değilse, o zaman deneyebilirsiniz. Ama daha önce hiç ip geçmediyseniz ve Niagara Şelalesi'nin üzerindeyse, muhtemelen iyi bir ağ istersiniz.

^{Gönderen http://www.artima.com/intv/refactorP.html}

Birim testi yapmadan PHP yazıyordum. Sonra, yıllarca Java'da birim testi uyguladıktan sonra, birim testi olmadan PHP'deki tek sayfalardan çok daha karmaşık bir şey üzerinde çalışamayacağımı buldum. Sebep? Verimlilik . Birim testi olmadan, güvenle yeniden düzenleyemedim - bu, A) çok daha fazla yırtıp her şey üzerinde baştan çalışmam veya B) çirkin eski kodla uğraşmam gerektiği anlamına geliyordu .

Teklif verirken test etmek için zamanı hesaba katmanız gerekir mi? Evet . Bunun daha fazla zaman alacağı sezgisel mi görünüyor ? Evet, yine . Muhtemelen, diğer bazı cevapların kabaca tahmin ettiği gibi, birim testleri olmadan % 50-100 daha fazla tahmin etmeniz gerekecektir .

Ancak!...

• Şartname deliklerini daha önce yakalayacak ve ele alacaksınız
• Bu, daha temiz ve daha sağlam bir spesifikasyona sahip olacağınız anlamına gelir
• Spesifikasyon değişikliklerine hızlı ve güvenli bir şekilde yanıt verebileceksiniz
• Daha az hatanız olacak
• Hatalarınız daha erken yakalanacak ve düzeltilmesi daha kolay olacaktır

Sonuç olarak, tahminleriniz daha doğru olacaktır . Saatlik ücret alırsanız, müşterilerinizi daha fazla etkileyecek ve ücretlerinizi artırabileceksiniz. Sabit ücret alırsanız saatte daha fazla para kazanırsınız.

Test yapılmadan, tahminleriniz büyük olasılıkla bir crapshoot'tur. Hatalar, değişiklik emirleri ve yeniden tanımlamalar doğru tahmin için korkunç. Test, üçünün de etkisini en aza indirmenin anahtarıdır!

Sizi ne kadar süre alacağına dair kolay bir cevap yok.

Ancak, temel bir kural olarak, eğer kısa bir proje ise: İyi bir birim test ile birlikte gelişimin, birim test olmadan gelişimden 1,75-2 kat daha uzun süreceğini söyleyebilirim. Daha uzun projeler için belki% 25-30?

Kodunuzu yazmadan önce birim testleri yapmanızı öneririm . Bu şekilde ele alındığında, birim test iskelesinin oluşturulması aslında tasarım sürecinizin bir parçası haline gelir ve bu nedenle birim testine zaman kaybettiğinizi düşünmemelisiniz, daha ziyade birim test binasının bir harika bir ürün ve bu testin oluşturulduktan sonra varlığı, bu şekilde kalmasını sağlamanızı kolaylaştırır. İlk önce birim testleri yazmak zorunda kalmak, gerçek gereksinimlere odaklanmamıza yardımcı olmak için harika, bize yapılıp yapılmadığımızı (birim testlerini geçip geçmediğimizi) test etmenin net bir yolunu veriyor ve "erken test edip sık sık test etmemize" yardımcı oluyor.

PHPUnit gelince .... Ben kullandığımdan bu yana bir süre oldu, benim izlenim güçlü ama belki de gerçekten cilalı önce biraz daha çalışma gerektiriyor.

Burada iletişim kurmak istediğim bir şey varsa: Lütfen Birim Testini projenizin sonunda sadece bir formalite olarak görmeyin. Hepsi bu kadarsa, bence, değersiz.

Şimdiye kadar cevaplar oldukça kapsamlı, bu yüzden sadece kapsanmayan bir nokta ekleyeceğim: PHPUnit kullanımı nedeniyle ekstra zaman olacak

1. öğrendiğinizden beri daha yüksek ve
2. güven kazanırken test dışı geliştirme süresini azaltın.

Sunumla ilgilenmeyen birim test modeli sınıfları oldukça basittir. Her sınıf için bir test yazarsınız ve bu test durumlarda belirli bir yöntemi / özelliği test etmek için bir nesneyi doğrudan başlatabilir ve yapılandırabilirsiniz. PHPUnit kurulumunu yaptıktan ve çalıştırdıktan sonra, bu testleri hızlı bir şekilde çalıştırabilirsiniz.

Birim testi web sayfaları daha zor olabilir. Zend Framework, Symfony, Smarty veya başka bir MVC motoru kullanıyorsanız, PHPUnit'in onlarla güzelce oynaması daha fazla zaman alabilir. Zend Framework kullanıyoruz ve denetleyicileri test etmek ve komut dosyalarını görüntülemek için temel sınıfları oluşturmak için önemli miktarda zaman harcadım. Bu projenin büyüklüğü göz önüne alındığında, muhtemelenControllerTestCase .