Otomatik testler neden şirketimde başarısız oluyor?


178

Firmamda birkaç kez geliştirici otomatik testi yapmaya çalıştık. QA ekibimiz, UI testlerini otomatikleştirmek için Selenium kullanıyor, ancak her zaman birim testlerini ve entegrasyon testlerini tanıtmak istemişimdir. Geçmişte, her denediğimizde herkes ilk iki ay için heyecanlanmıştı. Sonra birkaç ay içinde insanlar bunu yapmayı bıraktı.

Birkaç gözlem ve soru:

  1. Otomatik test gerçekten işe yarıyor mu? Başka şirketlerde çalışan meslektaşlarımın çoğu, otomatik bir test stratejisi uygulamaya çalıştı. Hala onu kullanan ve sadece hakkında konuşmayan gerçek hayattan bir yazılım şirketi görmedim. Pek çok geliştirici otomatik testi teoride harika olan ancak gerçekte çalışmayan bir şey olarak görüyor. İş ekibimiz, geliştiricilerin% 30 ek ücret karşılığında bile yapmayı çok ister (en azından öyle diyorlar). Ancak geliştiriciler şüphecidir.

  2. Hiç kimse gerçekten otomatik testlerin nasıl yapıldığını bilmiyor. Evet, hepimiz internetteki birim test örneklerini okuduk, ancak bunları büyük bir proje için kullanmak tamamen farklı bir şey. Asıl suçlu, veritabanını veya önemsiz olmayan herhangi bir şeyi alay etmek / saplamak. Gerçek testler yazmaktan daha alaycı bir şekilde zaman geçiriyorsun. Sonra kod yazmak yerine testler yazmak daha uzun sürdüğünde, işte o zaman vazgeçersiniz.

  3. Karmaşık veri merkezli web uygulamalarında kullanılan birim testlerinin / sistem entegrasyon testlerinin iyi örnekleri var mı? Herhangi bir açık kaynaklı proje? Bizim uygulama veri merkezli ancak aynı zamanda bir çok etki alanı mantığı var. Depo yaklaşımını bir noktada denedim ve birim testi için oldukça iyi buldum, ancak veri erişimini kolayca optimize edebilme pahasına geldi ve başka bir karmaşıklık katmanı daha ekledi.

20 deneyimli geliştiricinin üstlendiği büyük bir projemiz var. Bu, ünite testi / entegrasyon testi yapmak için ideal bir ortam gibi görünmektedir.

Neden bizim için çalışmıyor? Şirketinizde nasıl çalışmasını sağladınız?


14
Teknoloji yığınınız nedir?
Florian Margaine

7
WebForms düzgün bir şekilde birim testi yapmak neredeyse imkansız. Sunum mantığını test edilebilir bir bileşene taşımak için bir MVP (Model / Görünüm / Presenter) modeli kullanabilirsiniz.
Pete

12
@MasonWheeler: Her iki durumda da, ilk etapta kabul edilmeyen mülkleri çürüten müthiş bir argüman inşa ettiniz: yani, doğruluk kanıtlamak için birim testlerinin var olduğu.
Steven Evers

10
@ MasonWheeler- Bu argümanı kullanarak, hiçbir zaman KG'yi denememeniz gerekir, çünkü hiçbir hata olmadığını asla ispat edemezsiniz. Hedef bu değil. İyi bir otomatik kullanıcı arayüzü ve birim sınama stratejisi, KG'yi yalnızca sınama sınamalarından kurtarmak ve keşif sınamalarına konsantre olmalarını sağlamaktır.
Alex,

15
Birkaç kişinin, birkaç aydan daha uzun süredir otomatikleştirilmiş testler görmediklerini belirttiği için şok oldum. Almanya'da yaklaşık beş büyük şirkette danışman olarak çalıştım ve test yazmazsanız sizi kovacaklardı. Otomatik Test teorik bir konu değildir, dünya çapında başarıyla uygulanır ve kod kalitesini (doğru yapılırsa) önemli ölçüde arttırır.

Yanıtlar:


89

Birim testini yapmanın en zor kısmı, disiplini ilk / erken testler yazmaktır. Çoğu geliştirici, sadece koda dalmak için kullanılır. Ayrıca, kod için nasıl bir test yazacağınızı anlamaya çalışırken, geliştirme sürecini de erken yavaşlatır. Ancak, testlerde daha iyi hale geldikçe, bu hızlanır. Ve yazma testleri nedeniyle, kodun başlangıç ​​kalitesi daha yüksek başlar.

Başlarken, sadece testler yazmayı deneyin. Başlangıçta olaylarla alay etme / saplama konusunda çok endişelenmeyin. Testleri basit tutun. Testler koddur ve yeniden yapılmalıdır / düzeltilmelidir. Bir şey test etmek zor olsa da bu hatlar boyunca tasarım da olabilir. TDD çoğu tasarım modelini kullanmaya yöneltir (deneyimlerime göre, özellikle Fabrika modelini).

Testlerin bir görünürlük seviyesi elde ettiğinden emin olun. Onları serbest bırakma işlemine entegre edin, kod incelemesi sırasında bunları sorun. Bulunan herhangi bir hata teste tabi tutulmalı. Bunlar TDD'nin parladığı yerler.

İşte faydalı bulduğum birkaç kaynak:

http://misko.hevery.com/attachments/Guide-Writing%20Testable%20Code.pdf

http://www.agitar.com/downloads/TheWayOfTestivus.pdf

Düzenle:

Test yazarken akılda tutulması gereken bir şey. Kodun uygulanmasıyla ilgili herhangi bir şey belirtmeye çalışmıyorsunuz, yalnızca davranışta bulunmaya çalışıyorsunuz. Kod yazarken, her zaman test edersiniz. Hata ayıklama ifadeleri ve benzeriyle çalıştırmaya çalışıyor. Test yazma, bunu resmileştirir ve sahip olduğunuz testlerin kaydını tutar. Bu şekilde, geliştirme sürecinin yarısında hatırladığınız bir test vakasını yanlışlıkla atlamadan işlevselliğinizi güvenle kontrol edebilirsiniz.


Bunu tanısal bir özellik olarak tanıtmanın bir başka yolu ... aka neredeyse müşteri kodunu gönderebilecek olan kendi kendini sınama gücü (POST) ... ve sadece bir sürü basit test değil, test ve fonksiyonların ne olması gerektiği.
JustinC,

Ayrıca, TDD Anti-Patterns'dan kaçının .
Gary Rowe

4
Misko Hevery ayrıca, youtube'da paha biçilmez bulduğum test edilebilir kodları yazma konusunda bazı harika videolar var. youtube.com/watch?v=acjvKJiOvXw
Despertar

"Testlerin görünürlük seviyesine sahip olduğundan emin olun" - bu başarı için kritik öneme sahiptir. Hiç kimse testlerinizin nasıl performans gösterdiğini göremiyorsa, değeri görmezler. Testler sürekli entegrasyonun bir parçası olarak otomatik olarak kontrol edilmeli ve daha sonra raporlanmalıdır. Tesults ( tesults.com ) 'da çalışıyorum ve bunun sebebi, testin görünürlüğünün sağladığı büyük etki yüzünden.
Beceri M2

77

Birçok yönden ekibinize katılıyorum.

  1. Çoğu birim testi değer bakımından sorgulanabilir. Çünkü testlerin büyük çoğunluğu çok basit görünüyor.

  2. İyi bir test edilebilir kod yazmak sadece çalışma kodundan daha zordur. Geliştirici topluluğunun kendi içinde kod / tasarım kalitesine karşı sadece çalışmasını sağladığına inanan büyük bir yüzdesi var. Ve kalite kodunun ne olduğunu bile bilmeyen daha büyük bir yüzde.

  3. Ünite test kodunu yazmak, gerçek kodun kendisinden çok daha uzun sürebilir.

  4. Daha karmaşık kodun (örneğin, tamamen test etmekle gerçekten ilgilendiğiniz şeyler) nasıl yeterince test edileceğini bulmak birçok geliştirici özelliğinin ötesindedir.

  5. Ünite testlerinin yapılması çok zaman alır. Küçük değişikliklerin büyük dalgalanma etkileri olabilir. Otomatik birim testlerinin temel amacı, değişikliklerin kodu ihlal edip etmediğini bulmaktır. Ancak, kırılma biten zamanların% 99'u kod değil testlerdir.

Yukarıdaki sorunların hepsinde, kod değişikliklerini yapmanın ve bir şeylerin testlerinizi otomatikleştirmekten ziyade beklenmedik bir şekilde bozmadığına dair bir miktar güven duymanın daha iyi bir yolu yoktur.

Yukarıdakilerin bir kısmı, ünite testi ders kitabına gitmeyerek bir dereceye kadar hafifletilebilir.

Birçok tasarım / uygulama türü, modül / paket seviyesindeki testleri otomatikleştirerek daha iyi test edilir. Tecrübelerime göre, çoğu kodlama hatası, bir sınıftaki kodun yanlış kodlanmasından değil, kodlayıcının sınıflarının diğer sınıflarla nasıl çalışması gerektiğini anlamadığındandır. Bu tür bir testte paranın karşılığını çok fazla gördüm. Ancak bir kez daha, bu testlerin yazılması, birim (sınıf seviyesi) testlerinden daha zordur.

Geliştiricilerin sürece inanıp inanmamaları gerçekten de kaynamaktadır. Bunu yaparlarsa, iyi birim testleri yazacaklar, hataları erken bulacaklar ve savunucu olacaklar. Bunu yapmazlarsa, ünite testleri yararsız olacak ve herhangi bir hata bulamayacak ve ünite testleri teorisinin işe yaramaz olduğu doğrulanacak (zihinlerinde).

Sonuç olarak, tam otomatik şişirilmiş ünite test yaklaşımını birkaç aydan daha uzun bir süredir çalıştığımı görmemiştim, fakat otomatik ünite testi fikri hala gerçekten test edilmesi gerekenleri seçmemize rağmen devam ediyor. Bu yaklaşım çok daha az eleştiriciye sahip olma eğilimindedir ve sadece birkaç kişi yerine tüm geliştiriciler tarafından daha fazla kabul görmektedir.


24
Bununla aynı fikirdeyim. Sadece bir şeyler kırıldıktan sonra testler yapma alışkanlığına girdik (bu kırılma gelişme sırasında bile olsa). Asla öne çıkma, çok az ödül için çok fazla zaman alır.
Izkata

5
@Ikata, başarılı bir şekilde gördüğüm diğer yaklaşımı Frobinate(), sistemin diğer servis araçları tarafından doğrulandıktan sonra, üst seviye metodu çağıran (aşağıda adı geçen onlarca küçük metot yerine), nispeten az sayıda yüksek seviye testi yazmaktır. Alt seviye değişikliklerinden hiçbirinin bir şey yapmadığı bir duman testi olarak. Genel olarak, bu testler, müşterinin sistemin istediğini yaptığını görebilmesi için sağlanan klavyenin kullanıcı testlerinde aynı paranın bir parçasıydı. Daha sonra, kod kapsamı araçları, kenar davalarının henüz kapsanmadığı yerlerin kimliğini belirleyebilir.
Dan Neely,

3
"Üflemeli tam otomatik test" demedim, "Üflemeli tam otomatik UNIT testi" dedim. Büyük fark. En azından bir on yıldır modül seviyesinde otomatik testler kullandım. Ünite testi sınıf düzeyindedir. Bireyler olarak değil, birbirleriyle birlikte çalışması gereken sınıfları test ederken para kazanma şansına sahip olduğuma inanıyorum. Bununla birlikte, orada bile, yine de pragmatik bir yaklaşım kullanıyoruz ve seçmeli olarak otomatik testlerin nerede / nerede yazılacağını seçiyoruz.
Dunk

2
İyi bir ünite testi kapsamı olmadan nasıl refactor yaparsınız? Veya yeniden yönlendirme yapmadan, kodun aşamalı olarak bozulmaz hale gelmemesini nasıl önlersiniz?
kevin cl

1
@Lardoardo Yapmamışlardı - hiçbir şeyi değiştiremeyecek kadar korkmuşlardı. Ya da tüm bu teknik borçları biriktirdiler ve birkaç hafta / ay sonra bir topluca ele almak için bir kenara koydular.
GraemeF

33

Asıl suçlu, Veritabanını veya basit olmayan herhangi bir şeyi alay etmek / saplamak.

Ve işte problemin.

Herkes ünite testini ortamınıza nasıl entegre edeceğiniz konusunda iyi puanlar alır. İnsanları yeterince pratik yapmaya değer bulmaları ve “yapışmaları” için yeterli zorlama. Fakat bunu yapmak çok acı verici ve / veya fayda sağlamazsa, yapışmaz.

Veritabanını çıkarmak çok basit olmalı. Arabiriminiz, sonuçlarını sağlamak için bazı DB yedeklemelerine gitmek yerine, basit bir sabit kodlanmış nesneyi koyarsınız. Bunu yapamıyorsanız, tasarım / mimarinizin problemleri vardır. Kodunuz bir veritabanına gideceğini veya onu değiştirmek için bir arayüz soyutlamasının bulunmadığını varsayar.

Bu sadece bir test / kalite kaygısı değildir. DB sağlayıcılarını değiştirmek istediğinizde veya bunun yerine buluta giderseniz veya bağlantısız mobil uygulamaları destekledikten sonra tasarımınız başarısız olur. En basit esneklik durumlarını destekleyemiyorsanız, işinizin kaçınılmaz olarak gerektireceği daha karmaşık şeyleri kesinlikle destekleyemezsiniz.


4
Sabit kodlama veritabanı, sahte bir nesnenin küçük bir saplamasından gelen değerleri, testi, veritabanındaki kodu değiştirebilecek ve bozabilecek herhangi bir şeyden yalıtmak için iyi bir yoldur (örn. Sütun isimleri). Belirli koşullar altında uygundur, ancak kullanımı kolay bir geçici test veritabanı, bir gün değiştirdiğinizde bir şeylerin bozulmasını istemediğiniz sürece sakınmanız önemlidir. Veritabanını çıkardığınızda kodunuz bozulursa, bu testin yakalaması gereken kodun bir hatasıdır (ve bundan kaçınmak istiyorsanız, test paketini birden çok veritabanında çalıştırmak isteyeceksiniz.)

8
@fennec - unit testler veritabanını test etmek için bulunmaz, işlevsellik için veritabanı değerlerine bağlı olan kodu test etmek için vardır.
Telastyn

3
Veritabanını yöneten kodu test edene kadar her şey yolunda. : P, birçok insan için kodlarının çoğu.

4
@fennec - Yazılarınızın doğru nesneyi yazdığından emin olmak için arayüzü kesmek, basitten ölüden biraz daha karmaşıktır. Yalnızca sınıflarınız doğrudan SQL'inizi arayüzünüzden aşağı göndermeye çalıştığında zorlaşır (okuma: korkunç bir tasarımınız var).
Telastyn

5
@Telastyn belki de yanlış anlıyorum ama sonunda bazı sınıfların aşağı inip kirli olması ve SQL'i yazması veya dosyayı yazması veya verileri veya arayüzü GPU ile göndermesi gerekiyor. Soyutlamaların çoğu bir düzeyde kaçınılmaz sızıntılara sahiptir; Onlar sadece pragmatik ve mutlaka korkunç değil.
Çırak Kuyrukları

21

Küçük, otomatikleştirmek için basit ve değeri yüksek bir şeyle başlamanız gerekir. Bazı tatlı, düşük asılı meyveler aşağı çekmek ve işlemi satmak mümkün olacak. Birinin gece ya da hafta sonu aramasını nasıl kurtardığını gösterin. O zaman oradan genişleyebilirsin.

Otomatik testleri iyi yapmak için, kaynak ve misyoner olan ve daha üst düzey yönetimlerden satın alan birisine ihtiyacınız var.

Otomatikleştirilmiş test geliştirmenize diğer çevik projeleriniz gibi davranın. Düzenli olarak tamamlanmış testler üretin.

Yorumdan ekleme: Bu daha çok bir yönetim sorunudur. Kod belgelenmeden önce "yapıldı" olarak kabul edilir mi? Giriş yapmadan önce? Birim testlerini içermeden ve geçmeden önce?

Buna nasıl yaklaştığınız gerçekten sizin rolünüze bağlı. Akran mısın? Öyleyse, başkalarına kodunuzu yeniden kullanma ve bakımlarını nasıl kolaylaştırdıklarını gösterin. Bir kurşun musun? En çok kod sorunu olan programcınızı seçin ve bu sorunlardan kaçınmak için testler eklemelerine yardımcı olun. Patron musun Standart olarak "ünite testleri yapılana ve başarılı olana kadar kod yapılmaz" olarak ayarlayın.


17
“Bazı tatlı, düşük asılı meyvaları aşağı çekin ve işlemi satabileceksiniz.”: Sanırım bu aşamaya çoktan başladılar (ünite testlerini kullanmada potansiyel avantajlar gördüler) ve bu yüzden vermeye ikna oldular. bir deneme. Sorun, düşük asılı meyvelerin sistematik olarak ünite testi yapması için nasıl ölçekleneceğidir. Sistem testlerinde sistematik olarak kullanıldığı tek proje, gerçek ürün kodundan daha fazla birim test koduna sahipti. Eğer bir ekip gerçek uygulama kodundan daha fazla kodlama birimi testine daha fazla zaman harcamak için hazırlıklı değilse, IMO yaklaşma muhtemelen işe yaramayacaktır.
Giorgio

4
Bu daha çok bir yönetim sorunudur. Kod belgelenmeden önce "yapıldı" olarak kabul edilir mi? Giriş yapmadan önce? Birim testlerini içermeden ve geçmeden önce? Buna nasıl yaklaştığınız gerçekten sizin rolünüze bağlı. Akran mısın? Öyleyse, başkalarına kodunuzu yeniden kullanma ve bakımlarını nasıl kolaylaştırdıklarını gösterin. Bir kurşun musun? En çok kod sorunu olan programcınızı seçin ve bu sorunlardan kaçınmak için testler eklemelerine yardımcı olun. Patron musun Standart olarak "ünite testleri yapılana ve başarılı olana kadar kod yapılmaz" olarak ayarlayın.
Huffman

1
@ SkipHuffman yorumunuz mevcut cevabınıza düzenleme olarak eklenmeli.
Radu Florescu,

15

Bu temel kuralları takip edin. Testler:

  1. düzenli çalışmalı! Her inşaatta, her check-inden önce / sonra veya sadece her sabah testler yapabilirsiniz. Otomatik olarak tetiklenen el ile tetiklenen için oldukça tercih edilir. Çünkü teoride takımdaki herkesin test yapmalarını sağlamaktan sorumlu olmasını sağlayabilirsiniz, eğer otomatik değilse, muhtemelen yeterince gerçekleşmiyordur! Ve eğer testlerinizi yeterince sık kullanmazsanız, ikisi de hataları çok geç buluyorlar, bu da 2.

  2. Hala sadece bu testler, şimdi düzenli olarak çalışan eğer yok, başaracağımızı şekilde olsun . Hangi testleri deniyoruz?

    a. Sağladıkları değerin (öznel olarak) kaçması çok uzun sürmemelidir! Testlerinizi hızlıca alevlendirin. İnsanların koşmalarına izin vermek için zamanınızı boşa harcayacak testleri kontrol etmelerine izin vermeyin!

    b. güvenilmez olmamalı. Mümkünse çok iş parçacıklı testlerden kaçının. Mühendislik uygulamalarını tıpkı diğer kodunuz gibi testlerinize uygulayın: özellikle - testlerinizi inceleyin!

    c. Tamir edilmesi ve bakımı yapılan kodlardan daha zor olmamalıdır. Kod tabanınızdaki küçük bir çizgi değişikliği, 10 farklı testi düzeltmenizi gerektiriyorsa, kodlama hızınız gerçekten çok kötü olacaktır.

Ve son olarak, kural 3 sayısı. Testler yalnızca kural 2'de olduğu gibi negatif değer sağlayamaz, pozitif değer sağlamalıdır. Testler ...

  1. Aslında , başarısız olduklarında umursadığın bir şey söylüyor olmalı ! (Belirsiz hata mesajlarıyla yapılan testler yok veya yalnızca 'Windows 2008 makinesinde testi yapmayı unuttuğunuz' gibi saçma şikayetleriniz yok, lütfen!).

Kural 3'ü ihlal etmenin popüler bir yolu yanlış şeyi sınamaktır . Bunun nedeni bazen testin çok büyük veya odaklanmamış olmasıdır. Ancak, genellikle bir müşterinin umursadığı bir şeyi sınamaktan ve alakasız uygulama ayrıntılarını sınamaktan gelir. (Ancak bazen uygulama ayrıntılarını test etmek de verimli bir test yapar - IMO hangisine karar vermeyi pratik yapar.)

Sonuç: bu temel kurallar , sizi umutsuzca arzu ettiğiniz şey olan sürdürülebilir bir test disiplininin genel yönüne işaret eder . Test yaparken, bu testin gerçekten sürdürülebilir ve sürdürülebilir olup olmadığını kendinize sorun. Hatırlamak:

  • eğer testler sürdürülebilir değilse, kullanılamaz hale gelir ve böylece boşa harcanır.
  • eğer testler sürdürülebilir değilse, testler yapmayı bırakırsınız ve ekibiniz testlerde daha iyi olmayı durdurur! Ve son nokta:

Test etmek gerçekten zor. Sen gerektiğini size yazma testleri başladığında ekibinizin testler temelde emmek bekliyoruz . Cesaretini kırma. Do onlar emmek fark ve sürdürülemez olduğu zaman, eski testler atmak.


12

1. Gerçekten işe yarıyor mu?

Evet, öyle - uygun şekilde yapılırsa. Mesele şu ki, mühendisler yeni özellikler uyguladıktan sonra test cihazlarının otomatik komut dosyalarını ayarlaması ve genişletmesi gerekiyor.

2. Hiç kimse gerçekten deneyimli değildir veya otomatikleştirilmiş testlerin nasıl yapıldığını bilmiyor.

Bir danışman alın (nasıl düzgün yapıldığını bilen biri). Veya daha fazla zaman harca. Alternatif, aynı testi manuel olarak yapan (hataya açık olan) daha büyük test ekibine sahip olmaktır.

3.Üzerinde çalışan 20 iyi deneyimli geliştirici ile büyük bir projemiz var. Bu nedenle birim test / entegrasyon testlerini tanıtmak için harika bir ortam olmalıdır. Neden bizim için çalışmıyor? Şirketinizde nasıl çalışmasını sağladınız?

Birim testlerini yapmayı reddederlerse onlara "iyi deneyimli geliştiriciler" demezdim. Testin olumlu faydalarının birçok harika makalesi vardır (hem ünite hem de entegrasyon testi) ve sonuçta bir hatanın şirketinize maliyeti ne kadar azalır . Örneğin, kalitenin önemli olduğu bir şirkette çalışıyorum, bu nedenle birim ve entegrasyon testlerinden kaçınılmaz. Ünite testlerinin sadece böcek sayısını% 30 azalttığını söyleyen makaleleri kolayca bulabilirsiniz! (Aslında,% 20-90 aralığında, ortalama% 30, ancak hala çok fazla.)

Şirketinizde çalışmasını sağlamak için ya bir danışman kiralayın ya da bu görevi üst düzey bir mühendise verin (bunu yapması biraz zaman alır). Ve sonra, herkesi kurallara uymaya zorla.


20
Neredeyse her şeyin işe yarayacağını belirtmeliyim "Doğru yapılırsa". Bununla birlikte, bu herhangi bir popülasyonun çok küçük bir azınlığı dışında herkes için çok yararlı değildir. Bir sürecin işe yaradığını iddia edebilmesi için, "çeşit" yapıldığında da çalışması gerekir.
Dunk

11
Herkesin durumunu kendinize aşırı genelleştirmenin (yani onlara "iyi tecrübeli geliştiriciler" demem. Kalite meseleleri) sadece tecrübedeki genişlik eksikliğinizi göstermez, aynı zamanda çok üretken değildir. Her sektörün kendi "eser" tanımı vardır; ve birim, entegrasyon ve sistem seviyelerinde ne derece test yapılması gerektiği. Birçok "son derece iyi" geliştirici, birim testlerinin otomatik entegrasyon testleriyle karşılaştırıldığında paranın karşılığını çok az aldığının farkına varmıştır. Ayrıca, bu olasılığın yalnızca kendi endüstrisi için geçerli olduğunun farkındalar.
Dunk

11
"Birim testlerini yapmayı reddederlerse, onlara 'iyi deneyimli geliştiriciler' demem." Bu sadece No True Scotsman'ın haksızlığıdır. Yazılım endüstrisi yıllarca ünite testi yapmadan geçindi ve bu endüstrinin çoğu bugün onsuz devam ediyor. İyi bir fikir olabilir, ancak zorunlu değildir.
Noah Yetter,

1
"birim testlerinde zaman kaybetmeyin": "yararsız birim testlerinde zaman kaybetmemek" olarak bunu tekrar yazardım. Her şeyin kör bir şekilde test edilmesi, çok fazla zaman kaybına neden olabilir.
Giorgio

1
@Dunk Test-ilk-her şey TDD fenomeninden gerçekten nefret ediyorum ama ilk ifadenize katılıyorum. Ya doğru bir şey yapıyorsun ya da değilsin. Bir birim sınamasını iyi yapabilir ve belki de bunun yararlarını görebilirsiniz, ancak hiçbir zaman yarım kıçta yapılan hiçbir şeyin özelliğini göremezsiniz.
Erik Reppen,

10

Otomatik sınamayı başlatmanın başarısız olmasının birçok nedeni vardır. Programcıların kodlama alışkanlıklarını değiştirme eğiliminde olmadıkları ve ünite testlerini tam olarak kullanamadıkları gerçeğine bağlı olduğunu düşünüyorum.

Otomatik sınamaya başlamak isteyen birçok kişi, bunları varolan bir kod tabanı için tanıtmaya çalışır. Mevcut uygulamanın birçok işlevselliğini bir kerede test eden entegrasyon testleri yazmaya çalışacaklar. Bu tür entegrasyon testleri ününü korumak için çok zor ve pahalıdır. Tavsiye: Yeni bir kod tabanı için otomatik testler yapın.

Birim testleri, otomatikleştirilecek iyi testlerdir. Yukarıdaki her şey (entegrasyon testleri, bileşen testleri, sistem testleri) otomatik olarak da test edilebilir, ancak maliyet-fayda oranı, bir kerede daha fazla işlevsellik test edildiğinde hızla düşer. Bu olumsuz etki, ünite testinde yetersiz işlevsellik üzerine bu tür testler yaparsanız yükseltilir. Tavsiye: Birim test seviyesinde otomatik testler yapın ve sağlam bir birim test temeli üzerinde otomatik entegrasyon testleri oluşturun .

Yukarıdaki noktalardan, otomatik testlerin başarısının büyük kısmı, birim testlerinin ne kadar etkili olduğuna bağlıdır. Ünite testlerinde üretken hissediyorsanız etkili ünite testleriniz vardır. İnsanlar birim testleriyle başladığında, mevcut kodlarını ve kodlama alışkanlıklarını birim testlerine uyarlama eğilimindedirler. İronik olarak, bu birim testini öğrenmenin en zor yoludur. Ayrıca birim testi, kodlama şeklinizi değiştirmenizi gerektirir (örneğin, SOLID ilkelerini uygulayarak ). Programcıların çoğu yakında ünite testleri yazmayı bırakıyorlar çünkü öğrenme eğrisinin çok dik olduğunu düşünüyorlar ve ünite testlerini test edilemeyen tasarlanmış bir kodun etrafına sarmayı zor buluyorlar. Tavsiye: Ünite testlerini sıfırdan başlayarak yeni bir kodla öğrenin ve kodlama alışkanlıklarınızı değiştirmeniz gerektiğine dikkat edin.

Başka birçok faktör var, ancak çoğu programcının kodlama yollarını değiştirmenin zor olduğunu gördüm. Test olmadan yazılmış kod sadece farklı görünüyor. Kodunuzu test edilebilir bir tasarıma sıkıştıramazsanız, etkili ünite testleri yazmanız çok muhtemeldir. Bu etkili otomatik test için zemin yok eder.

Bunu kendi başıma gördüm ve artık başarılı bir şekilde otomatik testler getiren bir şirkette çalışmaktan mutluyum. Diğer faktörler hakkında çok daha fazla yazabilirim, ancak kodlama alışkanlıklarının ve birim testlerinin en önemlisi olduğunu düşünüyorum. Neyse ki, benden daha fazla deneyime sahip olan ve kitapları kendi uzmanlıklarıyla dolduran başkaları da var. Bu kitaplardan biri , Microsoft teknoloji yığınını kullandığınızdan beri .NET'te gerçekten önerebileceğim Brownfield Uygulama Geliştirme .


Introduce automated tests on the unit test level and build automated integration tests on a solid foundation of unit tests.+1
c69

10

Yukarıdaki cevaplarda açıkça dile getirmediğim bir şey, birim testlerinin temelde kamu yararı ve özel bir maliyet olduğu. Bu konuda bir blog yazısı yazdım buraya .

Bir takım test takımı takıma veya bireysel bir geliştiriciye fayda sağlarken , testi yazmanın çoğu zaman bunu yapan kişinin maliyeti olduğu söylenebilir.

Kısacası, testi bir şekilde zorlamadıkça - ve yukarıdaki cevaplar bunu yapmanın birkaç farklı yolunu listeliyorsa - bireysel bir geliştiricinin bunu yapması için bir neden yoktur.

Çalıştığım bir şirkette birim testleri yazmak bir özellik sunmanın gerekli bir parçasıydı. Bir birim testi taahhüt veya yeni özelliğin bir parçası olmadıkça yeni kod kabul edilmedi - bir geliştiricinin verdiği her "görev" için kısa kod incelemeleri vardı. İşyerinizde benzer bir politika uygulamak faydalı olabilir.


8

İşin geliştiricilere göre daha pro-test olması ilginçtir! En büyük zorlukların, geliştiricilerin değişime karşı direncini yenmek; ünite testi dahil etmek için işlerini anlamalarını yeniden tanımlamaları gerekir.

Hiçbir şey, geliştiricilerinizin bu testleri yazma konusundaki direncini aşmasına yardımcı olmak için erken test testlerinden daha fazlasını yapmanıza yardımcı olamaz. Onları yeni bir şeyler yapmaya zorlarsanız, ilk önce neredeyse garanti edilmiş bir ödülü olan bir şey için bastırdığınızdan emin olun.

@ SkipHuffman bu konuya değindi, ama tam olarak söyleyeceğim. Bazı şeyler otomatik test için diğerlerine göre çok daha uygundur. İlk geçişte, ben ederim DEĞİL veritabanı veya UI test edin. Veritabanından giriş yapmak, kurmak ve yıkmak oldukça zor olabilir. UI çıktı testleri, testlerinizle tamamen ilgisiz olan görünüm ve his değişiklikleriyle hızlıca kırılma eğilimindedir.

"Orta katman" olarak adlandırdığım şey birim testi için mükemmel. Giriş ve çıkış koşullarını açıkça tanımlayan kod. DRY ilkesini izlerseniz (Kendinizi Tekrar Etmeyin), uygulamanız için benzersiz olan tekrarlayan sorunları çözmek için bazı küçük sınıflar veya işlevler yazmış olacaksınız.

Birim testi, mevcut dahili bileşenlerin değişim riskini sınırlamak için harika bir araçtır. Uzun süre çalışmış olan bir iç bileşeni değiştirmeden önce birim testlerini yazın. Bu testler şu anda çalışan işlevselliğin korunduğunu kanıtlamaktadır. Değişikliğinizi yaptığınızda ve tüm birim testlerini geçtiğinde, "aşağı yönde" hiçbir şey kırmadığınızı biliyorsunuzdur. Bir aşağı akış sorunu bulursanız, bunun için bir birim testi ekleyin!

Ron Heifitz, "insanların sahip oldukları değerlerdeki çatışmaları ele almak ya da insanların dayandığı değerler ile karşılaştıkları gerçeklik arasındaki boşluğu azaltmak için" diyebilirdi . Değişime karşı insan direncinin üstesinden geldikten sonra, uygun şekilde daha zor test alanlarına geçebilirsiniz.


6
"geliştiricilerin değişime karşı direncinin üstesinden gel": her direnişin bir nedeni yoktur ve biri "değişime direnç" argümanını kullanarak dürüst bir tartışmadan kaçınmamalıdır.
Giorgio

7

Otomatik test ile ilgili bir şey, test edilebilir olması için kod yazmanızı gerektiriyor olmasıdır. Bu, kendi başına kötü bir şey değildir (aslında, kurallardan kaçınılması gereken birçok uygulamayı engellediğinden dolayı iyidir), ancak mevcut test koduna ünite testini uygulamaya çalışıyorsanız, ihtimaller değil. test edilebilir bir şekilde yazılmıştır.

Singleton, statik yöntemler, sicil, servis yer belirleyicileri vb. Gibi şeyler, çözülmesi zor olan bağımlılıkları ortaya çıkarır. Demeter Yasası'nın ihlali, kod tabanınızın çok fazla bir kısmının kod tabanınızın diğer kısımlarının nasıl çalıştığı hakkında çok fazla şey bildiği ve kırılması zor olabilecek başka gizli bağımlılıklar getirdiği anlamına gelir. Tüm bunlar, bir modülü kod tabanının geri kalanından izole etmeyi zorlaştırıyor ve modüllerinizi yalıtılmış bir şekilde test edemiyorsanız, birim testleri değerlerinin çok büyük bir kısmını kaybediyor. Eğer bir test başarısız olursa, test edilen ünitedeki bir hatadan veya bağımlılıklarından birinde bir hatadan dolayı veya belki de bağımlı bir veri kaynağından alınan verilerin test yazarının beklediği gibi olmaması nedeniyle ? Yapabilirsen'

Kodlayıcılar, testler göz önünde bulundurularak yapılamadığını gördüm, kodlayıcılar, kodların kuplajı serbest bırakmak için gereken işi yapmaktan ziyade kodun beklendiği gibi çalışmasına odaklanmaya odaklanmaya meyilli olduğu için doğal olarak dengesiz olma eğilimindedir. . Ünite testi ile yazılmış kod, çok farklı görünme eğilimindedir.

Birçok insan ilk defa yapmaya başladığında ünite testine saf bir yaklaşımla yaklaşıyor, varolan bir kod temeli için sadece bir test yükü yazabileceklerini düşünüyor ve hepsi iyi olacak, yukarıda belirtilen konular. Ünite testlerinde bir miktar kurulum yapmaları gerektiğini keşfetmeye başlıyorlar ve hepsinin çalışmasını sağlamak için sık sık sorgulanabilirler çünkü koddaki izolasyon eksikliği bir test başarısızlığına neyin neden olduğunu izleyemeyeceğiniz anlamına geliyor. Ayrıca, sistemin nasıl çalışması gerektiğine dair oldukça soyut bir bakış açısı gösteren "zeki" testler yazmaya çalışmaya da başlıyorlar. Bu başarısız olma eğilimindedir, çünkü "akıllı" bir birim testi, potansiyel bir hata kaynağıdır. Test edilen modüldeki bir hata nedeniyle test başarısız oldu mu? veya testteki bir hata nedeniyle? Bir test o kadar basit olmalı ki, bir hatanın içinde saklanma olasılığı yoktur. Aslında, en iyi testler nadiren 2 satırdan fazladır, ilk satır test ünitesine bir şey yapması talimatını verirken, ikincisi yaptığı şeyin beklenenin ne olduğunu iddia eder.

Eğer ekibiniz ünite testini benimseme konusunda ciddiyse, mevcut bir projeyle başlamak akıllıca olmaz. Ekibinizin mevcut projeleri büyük çapta yeniden düzenleme yapılmadan denenemez. Çalışmak için temiz bir yazı tahtası olduğu için, birim testi hakkında bilgi edinmenin temeli olarak yeni bir proje kullanmaktan daha iyisin. Yeni kod tabanını singletonlar, kayıt defterleri ve diğer gizli bağımlılıklar üzerine bağımlılık enjeksiyonunu desteklemek için tasarlayabilirsiniz, uygulama yerine vb. Arayüzlere bağlı olarak yazabilirsiniz. Ayrıca, testleri sonradan test edilen kodun yanına da yazabilirsiniz (ve sonra yazmalısınız), çünkü testlerin yazılması, test edilen modülün yapmayı düşündüğünden ziyade yapabileceğini düşündüğünüz şeyi yaptığından emin olan ünite testlerinde sonuçlanır. özellikleri ne yapması gerektiğini söylüyor.

Birim testinde bir miktar güven kazanırsanız, ekibiniz muhtemelen mevcut kodlarındaki kusurları birim testlerine engel olacak şekilde anlamaya başlar. Bu, daha fazla test edilebilir hale getirmek için mevcut kodu yeniden düzenlemek için çalışmaya başlayabileceğiniz zamandır. İddialı olmayın ve hepsini bir kerede yapmaya çalışmayın ya da tamamen yeni bir sistemle çalışan bir sistemi değiştirmeye çalışın, sadece kolayca test edilebilecek kod tabanının parçalarını bularak başlayın. Herhangi bir bağımlılık veya bağımlılıkların açık olduğu yerler) ve bunlar için testler yazınız. Kodun yanında bir test yazmanın sonradan test yazmaya tercih edildiğini biliyorum, ancak daha sonra yazılan bir test bile bir başlangıç ​​noktası olarak değer taşıyor. Testleri, dersin nasıl çalıştığını, spesifikasyonlarının yapması gerekenden başka bir şey bilmiyormuşsunuz gibi yazın. Testleri çalıştırdığınızda ve hatalar aldığınızda, teknik özellikler veya uygulama yanlıştır. Hangisinin yanlış olduğunu belirlemek için her ikisini de kontrol edin ve buna göre testi veya kodu güncelleyin.

Asılı meyveyi çıkardıktan sonra, asıl işiniz başlıyor. Kod tabanınızdaki gizli bağımlılıkları bulmaya ve bunları birer birer düzeltmeye başlamanız gerekir. Bu noktada aşırı iddialı olmayın, sadece bir seferde bir modül yapmak, hatta bir modülde sadece bir tek konuya devam etmek, testin önündeki engeller giderilinceye ve bir sonraki aşamaya geçebilirsiniz.

TL: DR: Çoğu insan test etmenin kolay olduğunu düşünüyor ve testleri mevcut koda kolayca ekleyebiliyorsunuz. Bu varsayımların her ikisi de yanlıştır. Her iki gerçeği de göz önünde bulundurarak projelerinize birim testi yaptırmak için bir projeye başlarsanız, başarılı olmanız daha olasıdır.


ipucu: TL'yi koymak; DR: üstte - Sadece yazıyı okumak için tüm yazınızı okumak zorunda kaldım! (Bu tür nokta yener)
gbjbaanb

4
  • Şirketinizde otomatik testler yaparken geniş deneyime sahip biri var mı?

Aksi takdirde, otomatik test girişimleri muhtemelen başarısız olacaktır. Otomatik test, programlamadaki diğer birçok beceri gibi bir beceridir ve bunu yaparken tecrübesi olan bir kimseniz yoksa, otomatik bir testin gerçek değeri olan iyi bir otomatik test mi, yoksa kötü bir test mi olduğunu söylemek kolay değildir. rastgele başarısız / sık güncelleme gerektirir / aslında herhangi bir ilginç kod kullanmaz.

  • Bu birinin liderlik gücü var mı? Değişim talep edebiliyorlar mı?

Hiç kimse dinlemezse, testin iyi olmadığını söylemeleri farketmez. (Liderlik gücünün resmileştirilmesi gerekmediğine dikkat edin. Dikkatli bir ekibe sahip olmak da iyidir.)

  • Otomatik testlerin uygulanmasını ve geliştirme döngüsüne entegre edilmesini kolaylaştırmak için araçlar ve süreçler geliştiriyor musunuz?

Geliştiriciler tembel. Yapmalarını istemediklerinizi, başarmalarını kolaylaştırmalarını ve yapmalarını istemediklerinizi yapmalarını zorlaştırmanız gerekir. Test kitaplıklarının, test veritabanları veya benzeri gibi, özellikle de çevre ile ilgili kurulum gibi test kurulumu ve yırtılması ile ilgili görevleri yapmayı kolaylaştırdığından emin olmalısınız. (Veritabanını alay etmek, bu yorumların bazılarında tartışılmaktadır ancak dikkatli kullanılmalıdır. Gerçek bir veritabanının döndürülmesi kolay olmalı ve çoğu zaman birim testinden daha önemli ve daha etkili olan bileşenlerin ve işlem yaşam döngülerinin etkileşimini test etmenize olanak sağlar Bireysel veri erişimcisi.)

Ayrıca IDE'lerin test takımını başlatmak için iyi bir yolun olduğundan emin olmalısınız. Test paketini sık sık çalıştırmalısınız, böylece insanlar sefalete karışmak yerine başarısız olduklarında farkederler. Geliştiriciler ayrıca geri bildirime de iyi yanıt verir; örneğin, bir testi bozduğunda değişikliklerini geri alan otomatik bir entegrasyon sistemi. Ya da daha iyi, olumlu geri bildirimler: böcekleri yakalayan ve sizi parçalamaktan koruyan otomatik bir entegrasyon sistemi.


Geliştiricilerin tembel olduğunu söylemenin adil olduğunu sanmıyorum. Belki de tecrübelerindeki durum budur, ama kesinlikle evrensel bir gerçek değil.
Sam

4

Birincisi, geliştiricileriniz testlerinizin değerini görmüyorsa, bunun nedeni muhtemelen geliştiricilerinizin değerlerine veya genel olarak testlerin değerine karşı kör oldukları için testlerinizin değerli olmamasıdır. İnanççıları arasında, teste dayalı gelişimin başarısız olamayacağına, sadece tembel, tembel geliştiricilerin başarısız olabileceğine inanma eğilimi vardır. Bunun yanlış ve üretken olduğunu düşünüyorum.

Teste dayalı gelişimi test etmeye başladığımda, etkili bir şekilde, asla başarısız olmayacak bir yöntemin asla başarısız olamayacağını doğrulamak için bir test yazmak anlamına geliyordu. Hangisi güzel, ilk önce hoş bir yeşil çek ve başarı hissi alıyorsunuz. Daha sonra, kodu yeniden düzelttikten sonra, hiçbiri kodun değiştiğinden, testlerin artık geçerli olmadığını ve çok fazla zaman harcadığınızı söyleyen, onlarca çıldırtan kırmızı Xes'e sahipsiniz.

Bundan kaçınmak istiyorsun.

O zamandan beri testlere farklı bir yaklaşım getirdim. Bunun yerine bir bir arayüz uygulaması çifti , bir var üçlü arayüz, uygulama, test . Arabirim davranışı belirtir, uygulama davranışı gerçekleştirir, test davranışı denetler.

Sanırım bariz gözüküyor ama bana göre, kanıtlamanız gereken kod ile belirtilen şekilde çalıştığını ve uygun gördüğünüz kadar az veya çok az test edebileceğiniz kodu ayırıyor. Kanıtlamanız gereken kod, dışarıya sunduğunuz arayüzdür; Gerisi sadece senin endişen.

Bu durumda, geliştiricilere bu tür testlerin uygun olacağı kodda doğal bir bölünme görüp görmediklerini sorardım. A takımının uyguladığı ve B takımının kullandığı bir arayüz var mı? Bu durumda, arayüzün bekledikleri gibi davranmasını sağlamak B Takımının yararınadır. Ekip B'den bir test yazmasını isteyin, ardından Ekip A'ya uygulamalarının teste uygun olduğundan emin olmasını sağlayın; veya, eğer yapmazsa ve kasıtlı olarak yapmazsa, beklenmeyen değişimi diğer ekiple tartışmak ve buna hazırlanmak için.

Bunun testin değerini göstereceğini düşünüyorum. Başlı başına bir son değil, buna rağmen güzel yeşil çekler. Bir geliştiricinin diğerine verdiği sözü açıkça belirtmek ve bu sözün her ikisinin de memnuniyetine uygun olmasını sağlamak için var.


1
Birinin böyle minutiye doğru denenmesi gereken bir koddan daha iyi okuyabildiğim kodları severim.
Erik Reppen,

1
Benim hissettiğim güzel yeşil keneler sorun - bu bir tür oyunda denemeyi sağlıyor.
gbjbaanb

2

Önceden var olan büyük bir projeye çok sayıda birim testi eklemek zor iş. Zaten sizin için çalışan iyi bir alaycı çerçeve bulduysanız, o zaman en zor sorunu çözmeliydiniz.

Siz özellikler eklerken / hataları düzeltmeden testler eklemeye çalışmanızı öneririm. Hataların giderilmesi en kolay olanı. Hatanız nedeniyle başarısız olan bir test yazın ve hatayı düzeltin. Aynı zamanda muhtemelen kendinizden geçen bazı basit testler yazarken de bulacaksınız. Elbette bunun için küçük ve kolay bir şekilde test edilmiş bir kod parçası kullanmak istersiniz.

İnsanlar daha kolay şeyler için testler yazmaya alışmaya başladıklarında, daha test edilebilecek kodlar yazdıklarını umarım bulmalısınız.

Ayrıca, testlerinizin kod kapsamını ölçmenizi de tavsiye ederim ( Geçmişte Java için cobertura kullandım ). Testleri yürüten ve ölçümleri düzenli olarak üreten (sürekli olarak her gün, her gün check-in) bir bütünleştirme sunucusuna sahip olmak isteyeceksiniz. Eğer geliştirici üyeleriniz istekliyse, zamanla kapsamın arttığını görmek isteyeceklerdir ve bazılarınızdaki boşluk kapsama deliklerini görebilirler.


2

Bence uzun oyunu oynamak zorunda kalabilirsin. Biraz kabullenmek için yapabileceğiniz bir şey, yazdığınız bir sonraki özelliği ayrıntılı bir şekilde test etmeye çalışmak ve zaman içinde hata sayısını takip etmektir. Başlıca böceklerin erken yakalanacağını (özellikle Test-Driven Design ile bağlarsanız) ve gerileme sayısının çok düşük olması gerektiğini ummalısınız. Bir süre sonra, 1 yıl diyelim ki istatistikleri benzer karmaşıklıktaki birim dışı özelliklerle karşılaştırın. Yeni hataların ve gerilemelerin sayısının oldukça düşük olduğunu gösterebilirseniz, bunun için finansal bir gerekçe sunmuş olursunuz ve ürün ekibinin görmezden gelmesi zorlaşır.

Büyük bir özellik için TDD ve ünite testlerini kullanabildiğim bir durum vardı. Geliştirme aşamasının sona ermesinden sonra 5 yıl içinde rapor edilen tek bir hata yoktu. Yeni ve riskli bir geliştirme talep edildiğinde, onu uygulayıp birim testlerindeki tüm gerilemeleri yakaladım.


1

Birim testlerin değerinin, birçoğu zaten cevaplarda vurgulanan birkaç faktör nedeniyle birçok takım tarafından büyük ölçüde hafife alındığı kanısındayım.

Genellikle geliştiriciler “işleri halletmek” için baskı altındadır, bu nedenle bir kod bloğunun çalıştığını kanıtlamak müşteri için yeterli bir kanıtdır. Bu, hemen hemen her zaman danışmanlık şirketi ve insan odaklı KG için geçerlidir: müşteri birim testine ihtiyaç duymaz ve yeterli bir canlı demo görürse, müşteri arızaları gizleyebilecek kod için onay imzalayacağından tamamen başarısız olmuştur.

Genellikle geliştiriciler sinirlidir. Programcı olmak zor bir iştir: bir işi bitirip bir sonrakine geçmek tatmin edicidir, bu yüzden herkes acele etmek ve bitirmek ister. Orijinal KG'dan aylar sonra yükselen büyük bir böcekle dolu bir otobüse çarpıncaya kadar. Bu senaryoda, otomatik ve sürekli KG, geliştiriciden ziyade bir yönetimin sorunudur (çalışmaları için, belki fazla mesai için hala ödenir).

Ancak bir istisna var

Otomatikleştirilmiş test modelinin kabul edilmesinin, yapılan testlerin "insanlığın" bir fonksiyonu olduğuna inanıyorum. Bir web modülünü ön ucu ile test ediyorsanız, Selenyum gibi araçlara rağmen formu kendi başınıza doldurmanız, sonucu görmeniz ve determinizm'e inanmanız daha olasıdır. Testleri daha sonra tekrar çalıştırmayı unutacaksınız veya eski testleri tekrar yapmak için çok tembel olacaksınız ve bu yüzden böceklerin daha sonra keşfedilmesinin nedeni budur. Bunu güçlendirmek için, bankacılık ortamında (kişisel iş tecrübelerime göre) kodun güçlü bir modülerleşmesi ve "eski kodun değiştirilmesi" ile ilgili katı kuralların kabul edilebilir olduğu kanıtlanmıştır.

Bunun yerine, geliştirici yüksek derecede otomatik ve yüksek hacimli bir veri modülü geliştirmekle yükümlü ise, ayrıntılı testler yazma ve bunları test gruplarına gönderme olasılığı daha yüksektir. Bunun nedeni, büyük bir XML yükünü harici bir veri kaynağından dönüştürülen verilerle doldurmak (taklit edilmiş veya değil) insanlara yatkın bir iş değildir. Bazı test geliştiricileri bu tür testler için sonunda küçük ve eğlenceli bir ön uç oluşturacaktır. Yüksek lisans tezimde çalışırken saniyede 6000'den fazla syslog mesajı yapan bir günlük veri yolu üzerinde çalışıyordum ve paket kaybını ve bozulmasını ölçmek zorunda kaldım: Doğal olarak hemen hemen tüm bileşenler için, özellikle Syslog ayrıştırıcısı için birim ve stres testleri yazdım.

Geliştiricilerin daha fazla birim testine yatkın hale getirilmesi için

Zorunlu olmaları gerektiğine inanıyorum. Akıllı bir müşteriyseniz, danışmanlarınızın her QA'da test setinin tamamını çalıştırmasını istemeniz gerekir. İyi bir takım lideri iseniz, aşağıdaki görevi akıllı bir geliştiriciye vermeyi düşünebilirsiniz: bir iç test platformu oluşturun. Bunun iç etki platformu antipatteriyle görecek hiçbir şeyi yok, ancak bunun yerine geliştiricilerin derhal test yapmalarına yardımcı olacak bir dizi yardımcı sınıf, veritabanı alaycı, yapılandırma, ayrıştırıcı, dönüştürücüler, İsviçre ordusu bıçakları.

NUnit gibi mevcut test platformları genel amaçlıdır ve genel iddiaları doğrulamanıza izin verir. Bağımlılık enjeksiyonunun ve projeye özgü fabrikaların doğru kullanılması, geliştiricilerin testler için daha az kod yazmasına ve daha mutlu olmasına yardımcı olur. Bunu henüz tam bir proje üzerinde deneme şansım olmadı, gerçek hayattan geri bildirim alamıyorum.


1

Otomatik test, yazılım geliştirme gibidir. Maalesef test için kiraladığınız kişilerin başlangıçta test senaryoları, planlar, stratejiler, inceleme sürecini takip etme, hataları manuel olarak test etme ve kaydetme amaçlıdır.

Otomatik test sorumlulukları verildiğinde, bir miktar yazılım geliştirmeyi içerir. Buradaki tespit, kullandığınız araçlardan (ve cennetin uğruna bu noktadan bahsetmediğinizden bağımsız olarak) otomatik testlerin günlük olarak bakıma ve güncellenmeye ihtiyaç duymasıdır. Geliştiriciler kodu değiştirdikçe,

  • Testlerin devam etmesini sağlamanız gerekir.
  • Çalışılmadığından testlerin kaldırılmadığından emin olmanız gerekir.
  • Test metriklerinizin son derlemede ve bu derlemede ne koştuğunuzu göstermesi gerekir. Test vakalarınızın sayısının azalmamasını sağlamak için.
  • İnsanların karışmamasını sağlamak için test vakalarının bir gelişme gibi gözden geçirilmesi gerekiyor, sadece sayıları arttırmak için 1 testi 2'ye böldüm (bazen test dış kaynaklı, bu yüzden bu izleme önemlidir)
  • dev ve test arasında çok daha "sağlıklı" iletişim önemlidir
  • non-functionaltestleri ayrı tutun ve günlük olarak çalıştırmalarını beklemeyin, bu güncellemeleri sürdürmeleri zaman alır ve iyi olur. Ama pes etmeyin, onların korunmasını sağlayın.

Bu nedenlerden dolayı başarısız olursunuz.

  • Test mühendisleriniz analitik becerileri olmayan manuel test mühendisleridir. a ifve whileloop arasındaki farkı bilmiyorlar . Açıkçası hiçbir kurs otomatik test yapmayı öğretmediğinden, yalnızca manuel test öğretiyorlar.
  • Test mühendisleriniz, binalarınızı manuel olarak test etmekle ve günlük hatalarını manuel olarak test etmek için çok meşguller, böylece otomatik testlerin kaybedilmesi için
  • Test yöneticileriniz otomatik testlerden gelen ölçümleri önemsemezler, çünkü geçersiz veriler gösterdiklerinden (proje başladığında) ve günlük standuplarda ve toplantılarda otomasyonun ne kadar önemli olduğunu vurgulamak için çaba veya öncelik vermezler
  • Çok kısa bir raf ömrüne sahip mobil uygulamalar için testleri otomatikleştirmeyi seçtiniz. Yazdığınız zaman, uygulama gereksinimlerinizin değiştirdiği otomatik test paketini dengeleyin, bunun yerine uygulamanızı çalıştıran web servislerinizi test etmeye odaklanmalısınız.
  • otomatik test ekibinin aynı dönüm noktasını takip ettiğini anlamıyorsunuz, geliştirme ekibi, özellik tamamlandı, kod tamamlandı, kod kilitleme ve kod dondurma.
  • manuel test uzmanları ve otomatik test uzmanları arasında ayrım yapmazsınız.
  • Her ikisi de aynı maaşı alıyorlar ve aynı yöneticiye rapor veriyorlar, ideal olarak geliştiriciye rapor vermeli ve maaşları da kalkınma maaşlarıyla eşleşmelidir.
  • aslında, testlerin otomatik testler geliştirmek için yeterli olmadığına inanıyor ve inanıyorsunuz :).

Bunlar otomatik testi çok ciddiye alan ve dev'in otomatik test mühendisleri olarak önemli olduğunu anlayan şirketler için çalışan deneyimimden. Ve tecrübelerime göre, onlara ne kadar açıklarsanız söyleyin, bilmeyen insanlar için, farkı anlayın.


Birim ve entegrasyon testi söz konusu olduğunda, testleri yazması gereken kişiler "test mühendislerini" ayrı değil geliştiricilerdir. (
Soruda

Gerçekçi konuşmak gerekirse, otomatik testler yazan herkes geliştirme becerisine sahip olmalıdır.
Siddharth
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.