Kodunuzu test etmek uzun zaman aldığında etkili bir şekilde nasıl program yaparsınız?

İş akışım her zaman bir mantıksal adım yazmak ve programı çalıştırmak ve çıktıyı incelemek olmuştur. Bu süreç bana üniversitedeki ödevler için inanılmaz derecede iyi hizmet etti. Ancak, daha fazla geliştirme yaptığım için, genellikle kodunuzu derleyip çalıştırmanın 1 ila 2 dakika sürdüğü zamanlar vardır. Örnek olarak, bir programın mikrodenetleyiciye yüklenmesi, harici bir sunucuyla etkileşim kurulması ve kimlik doğrulama, yazılım mimarisi veya karmaşıklık nedeniyle otomasyon uygulanamaması gösterilebilir.

Bu tür görevler genellikle nasıl programladığım için çok uygun değildir ve etkili bir şekilde kodlama konusunda zorluklar yaşıyorum. Genellikle bir çok sözdizimi hatası ve mantık hatası yaparım, bunların çoğu test ederek kolayca yakalarım. Ancak, bu kadar uzun bir bekleme süresi ile, bu yöntem çok zaman alıcıdır.

Öncelikle, her türlü etkileşimli hata ayıklama harika. Bunu araç setinizde istiyorsunuz, çünkü henüz değilse, bir gün gerçekten sahip olmaktan faydalanacaksınız. (Ayrıntılar dile, platforma ve IDE'ye göre değişir.)

harici bir sunucuyla etkileşim gerektiriyor ve kimlik doğrulama, yazılım mimarisi veya karmaşıklık nedeniyle otomasyon uygulanamıyor.

Sahte nesneleri kullanmak için bazı çerçevelere bakarım . Bunlar, test edilen bileşeni diğer bileşenlerin sahte bir ekosistemiyle kuşatmanıza izin verir, böylece testleriniz daha spesifik olarak hedeflenir ve her şeyi bir bütün olarak test etmekten kaçınabilirsiniz.

Buna ek olarak, sahte nesnelerin kendileri iddialarla programlanabilir, böylece test edilen bileşenin gerçekten belirli bir çağrı yaptığını kontrol edebilirsiniz.

Test süresini azaltmak için çok çalışacağım. Gömülü kod geliştiren birkaç şirkette çalıştım ve testler ağrılıydı, sunucu odasına ve manuel FTP'lere geziler ve test donanımına yeniden başlatma ve çoklu komutlar gerektiriyordu. Sonra gerçekten iyi bir gruba katıldım, burada masamda 'test yap' yazıp bir dakikadan kısa sürede sonuç alabilecektim. Bir dakika içinde:

• Kodum, gömülü donanım için yeni bir çekirdek görüntüsüne yerleştirildi.
• DHCP sunucusu yeni çekirdeği gösterecek şekilde güncelleştirildi.
• Test panosu yeniden başlatıldı.
• Test panosu çekirdeği bir NFS yuvası aracılığıyla iş istasyonumdan aldı.
• Test panosu yeni çekirdeğe yeniden başladı.
• Birim testleri yapıldı.
• Birim test çıktısı iş istasyonuma teslim edildi.

Tüm bu işleri yapmak biraz zaman aldı, ancak tüm bu adımları otomatikleştirme çabası, geliştirme personeli büyüdükçe yüz katına çıktı.

Otomatik testler inceleme ve anlama yerine geçmez.

Testi bir koltuk değneği olarak kullanıyor olabilirsiniz. Eğer bunu yapıyorsanız öğrenmenizi engelleyeceksiniz. Test etmeni savunmuyorum. Bunun yerine, testinizi çalıştırmadan önce yazdıklarınızı gözden geçirmenizi tavsiye ederim. Ne yazdığınızı anlayın, anlamlı olduğundan ve sözdiziminin doğru göründüğünden emin olun.

Cevabı zaten verdiniz: I usually make a lot of syntax errors and logic errors

Bu yüzden bunu geliştirmek için çok çalışarak, test süresini kısaltmanız gerekir. Sözdizimi hataları, azaltmanız gereken ilk şey olmalıdır. Çalışmanızda hiç kağıt ve kalemle programlama testi yapmadınız mı?

PHP'den Java'ya geçtiğimde de aynı şey vardı. Bazı değişkenleri yazdırmak yerine hata ayıklamayı öğrenmek ve tarayıcıda F5 tuşuna basmak zorunda kaldım ...

Tercihen arka planda sizin için testleri otomatik olarak çalıştırabilecek iyi bir Birim veya Fonksiyonel test platformuna ihtiyacınız vardır. Bu, yukarıda belirtildiği gibi Mock'ların kullanılmasını ve kullandığınız dile bağlı olarak bir çeşit bağımlılık enjeksiyonu gerektirecektir.

Nesnelerinizi mümkün olduğunca bağımsız hale getirerek ve sonra dış kısıtlamalar eklemek için enjeksiyon yöntemlerini kullanarak kodunuz için bir test platformu oluşturmak zor değildir.

Gerçek eğlence, kodunuzu öfkeyle kullanmak dışında test edemediğinizde gelir. Mevcut ticaret simülatörleri genellikle zayıf, var olmayan veya değişim yazılımı tedarikçilerinin söylediklerine bile uymadığından, bu işlem ticaret sistemlerinde oldukça fazla olur. Bu hayatın zengin gobleninin bir parçası. Korkarım. Yaklaşımım, işlemin en azından tarafımın iyi yazılmış ve iyi belgelenmiş olduğundan emin olmak, böylece kolayca değiştirilebilir.

Birim Testi; Sahte uygulamalar / simülatörler.

Bu zaman alacak, verilecek ve uygun maketler oluşturmak için örnek verileri toplamanız ve masaj yapmanız gerekebilir, ancak sonunda ödeyecek: Harici testlere karşı çalışırken karşılaştığınız her zaman ve sıkıntıdan kurtulacaksınız sistemleri.

Doğru kullanıldığında, bu araçlar harici sistemlerin yakınında herhangi bir yere gitmeden önce, kodunuz başarısız olursa, harici sistemde bir şey / ortamın neden olduğu, kendi kodunuzdaki bir hata olmadığından% 99,9 oranında emin olursunuz.

Bir süre profesyonel olarak okulda çalıştığınız şekilde çalıştım ve birçok durumda çok etkili oldu. Sonunda beni bu metodolojiden vazgeçmeye ve bunun yerine birim testi ve maketler kullanmaya zorlayan bazı insanlar altında çalıştım.

Şimdi, test aşamalarının uygulanması ile ünite testi, maketler, simülatörler, örnek veriler vb.

Genellikle çok fazla sözdizimi hatası ve mantık hatası yaparım

Belki bir Linter kullanmak size biraz yardımcı olabilir.

Önceki işverenimle benzer durumdaydım. Kod tabanımız gerçekten çok büyüktü ve kodlamak zorunda olduğum değişiklikleri yapmak için derledikten sonra .classbir dev sunucusundaki dosyaları değiştirin ve dev-sever'i yeniden başlatma komut dosyasıyla yeniden başlatın. Ve benim dehşete, dev-server tekrar kalkmak yaklaşık yarım saat sürecek.

Daha sonra Dev sunucusunda uzaktan hata ayıklamanın da mümkün olduğunu öğrendim.

İşte benim sürecimi optimize etmek için yaptığım şey

• Uzaktan hata ayıklamanın ilk turu, tam kod akışını ve değişkenlerin tam değerlerini / durumlarını görmemi sağladı.

• Nasıl ve ne gibi değişiklikler yapacağımı planlamak.

• Değişiklik Yapma ve ardından Farkları Karşılaştırma

• Hataları linter kullanarak veya derleyerek önbelleğe alma.

• .classDosyaları değiştirip yeniden başlatarak düzeltmeyi yapma .

Bazen yine kod akışını kontrol etmek ve değerleri / durumları kontrol etmek için bir sürü cehennem ifadeleri de eklerdim. Bu bana çok yardımcı oldu.

Ayrıca iyi oto-komplikasyonu olan bir IDE kullanmak, yazım hatalarının azaltılmasına büyük ölçüde yardımcı olabilir.

Bu yardımcı olur umarım.