Sahne Arkası: Kabul Testini Nasıl Otomatikleştiriyoruz?

Kabul testleri yapmaktan hiç zevk aldınız mı? Delicious Brains'teki ekibimiz için, geçmişte sürümlerimizi test etmek, yapılacaklar listesindeki en korkunç görevlerden biriydi. Eklentilerimizi yüksek kalite standardında tutuyoruz, bu yüzden bu bir zorunluluktur, ancak manuel testler beyin uyuşturacak kadar sıkıcıdır ve geliştiricilerin saatlerce pahalı zaman almasına neden olabilir.

Son zamanlarda, bunu düzeltmenin tam zamanı olduğuna karar verdik.

Girin, ben + kabul testi sürecini otomatikleştirme başlangıçlarım.

Çalışacak mı? Bizi saatlerce beyin uyuşturan manuel testlerden kurtaracak mı? Daha iyi olacak mıyız? Hepsi sonuçsuz bir çaba mı olacak?

Eklentilerimizi yayınlamadan önce test etme otomasyonunun nasıl şekillendiği hakkında daha fazla bilgi için okumaya devam edin – geçmişte manuel olarak nasıl test ettiğimiz ve halihazırda uyguladığımız bazı otomatik kabul testlerine bir bakış dahil.

Dikkat, bu bir eğitim değil! Kabul testi oldukça karmaşık bir şey olabilir, bu yüzden bazı kodlar gösterecek olsam da, bu tam olmaktan çok uzak ve öncelikle size işleri nasıl kurduğumuza dair bir fikir vermek için burada.

Kabul Testi Nedir?

Peki kabul testi nedir ve neden yapıyoruz?

Delicious Brains için kabul testi, müşterilerimiz için hazır olduğundan emin olmak için yakında çıkacak bir eklenti sürümünün son yapısını test etme sürecidir. Diğer (daha büyük) şirketlerde, "müşteri" veya temsilcisi, sürüm adayını test ettiğinde ve umarız, sürümü "kabul ederek" sözleşmeyi imzalar. Kabul edildikten sonra üretime bırakılır (veya bizim durumumuzda sunucumuza yüklenir ve müşterilerimize sunulur).

Kabul testleri, yazılımı müşterinin bakış açısından test etmeniz, bir müşterinin gerçekleştirmesi ve başaramaması gereken tüm eylemleri ve senaryoları denemeniz açısından birim testlerinden çok farklıdır. Birim testi yaparken, yazılım için API'yi oluşturan bireysel sınıfları ve işlevleri test edersiniz. Kabul testi sırasında, düğmelere, bağlantılara tıklar, metin girer, istemleri okur ve genellikle bir kullanıcının yapacağı gibi yazılımla etkileşim kurarsınız.

Kabul testi olmadan, yazılımın bir son kullanıcı tarafından kullanıldığında beklendiği gibi çalışacağından emin olamazsınız. Müşterilerinize uygun kaliteli bir ürüne sahip olduğunuzdan emin olmanın en iyi yolu budur.

Manuel Yöntem

Son 3 yılda WP Migrate DB Pro ve WP Offload S3'ün birçok sürümünde yer aldım. Her biri, sürümü test etmek için dayanılmaz bir test dönemi içerir. Ekipteki hiç kimse bir sürümü test etmekten hoşlanmaz, çünkü bu, testlerin her adımını ayrıntılandıran ve sürekli büyüyen bir dizi komut dosyasından geçen, acı verici bir şekilde yavaş, manuel bir meseledir.

Yukarıdaki ekran görüntüsü, normalde WP Boşaltma S3 için kullandığımız sürüm testi komut dosyasının küçük bir bölümünü gösterir. Komut dosyası, genellikle S3'teki veritabanı verilerinin veya nesnelerinin manuel olarak daha fazla kontrol edilmesini gerektiren 116 manuel adıma sahiptir. Bir test başarısız olursa, "Sonuç" sütununuza hücreyi kırmızıya çeviren bir "X" veya geçerse hücreyi yeşile çeviren bir "P" koyarsınız.

Ekran görüntüsünde bu "PPP" hücrelerini görüyor musunuz? Komut dosyasının ilerisinde, etki alanı ve alt dizin tabanlı çoklu site kurulumları için geri dönüp tüm bu adımları tekrar yapmanızı söyleyen iki satır vardır! Ruh yok edici.

Ayrıca Amazon Web Servislerimiz, WP Offload S3 Lite ve WP Offload S3 Assets eklenti eklentileri ile Easy Digital Downloads, WooCommerce, Enable Media Replace, Meta Slider, Advanced Custom Forms ve WPML entegrasyonları için komut dosyalarımız var.

Ve bu sadece WP Boşaltma S3 ile ilgili komut dosyalarıdır. WP Migrate DB Pro ayrıca WP Migrate DB, WP Migrate DB Pro ve Medya Dosyaları, CLI ve Multisite Tools eklentilerini test etmek için bir dizi komut dosyasına sahiptir.

Bir sürümü test ederken, 2-3 geliştirici, ürünün tüm bileşenleri için tüm testlerden geçen yaklaşık tam bir hafta boyunca bağlanır. Genellikle bir geliştiricinin testi başlattığı, genellikle "Lite" sürümüyle başlayan bir "kovalama" biçimi kullanırız. Lite eklentisi için herhangi bir sorun giderildiğinde, "Lite" testine başlayan ikinci bir geliştiriciyle "Pro" sürümüne geçerler. 3. bir geliştiriciye ihtiyaç duyulursa, diğer eklenti ekiplerinden birinden bir gönüllü çağrılır, böylece özellik sürümüne aşina olmayan biri "lastikleri tekmelesin" ve 2. geliştirici Pro'ya geçtikten sonra Lite sürümünü test etmeye başlar. Bazen daha küçük bir hata düzeltme sürümünde, ilk geliştirici komut dosyalarının bir ucundan başlayıp ikinci geliştiricinin diğer ucundan başlayıp biraz zaman kazanmak için ortasından geçerek bir "çapraz geçiş" biçimi yaparız.

Muhtemelen anlayabileceğiniz gibi, bu, eklentilerimiz için yayın döngüsünün popüler bir parçası değil. Geliştirme süreci, sürüm testlerinden geçmek ve bunun yerine sürüm testi başlamadan önce yapılması gereken Çok Önemli Şeyleri ( öksürük bahaneleri öksürük ) bulmak konusunda biraz endişe duyduğumuz için muhtemelen olması gerekenden biraz daha uzun sürebilir. Bu, geliştirici için çok pahalıya mal olabilir, ancak bir şirket olarak kalite bizim için inanılmaz derecede önemlidir, bu nedenle bu düzeyde test gereklidir. Geçmişte, son derece teknik ürünlerimizin üstesinden gelebilecek profesyonel test uzmanlarını işe almakta zorlandık. Kendiniz başarı elde ettiyseniz, yorumlarda bunu duymayı çok isteriz!

Geçen yıl Viyana'da şirketimizin inziva yerinde Brad, yakın zamanda izlediği testlerle ilgili bir sunum yaptı ve bu, sorun hakkında büyük bir tartışmaya yol açtı. Yükün bir kısmını hafifletmek için otomatik kabul testini denemeye karar verdik. WP Offload S3 için bir şeyleri başlatmak için gönüllü oldum, çok sevindirici!

Nasıl Otomatikleştiriyoruz

Teknoloji Seçimi

Kabul testlerimizi yürütmek için Codeception kullanıyoruz. Ekibimizden bazıları Codeception ile zaten biraz deneyime sahipti ve açıkçası testlerinizi PHP'de yazmak istiyorsanız gerçekten başka seçenek yok, bu yüzden tek seçenek değilse de bu açıktı.

Codeception ile geçmişte yaşadığımız en büyük sorun, testleri çalıştırmak için gereken Selenium veya PhantomJS sunucularını kurmaktı. Selenium ve PhantomJS, test web sitenize bağlanmak ve bağlantılar ve düğmelerle etkileşim kurmak için "tıkla" gibi komutlara yanıt vermek, metin girmek veya alanların içeriğini veya DOM'yi bildirmek, JavaScript'i çalıştırmak için bir API aracılığıyla yönlendirilebilen başsız web tarayıcıları sağlar. ve bunun gibi. Bu sunucuların kurulumu biraz zor olabilir. Ayrıca, yüklemek istemeyebileceğiniz Java veya diğer bağımlılıkları da gerektirebilirler ve ideal olarak, testlerinizi çalıştırdığınız her zaman arka planda çalışıyor olmaları gerekir.

Kabul testlerini çalıştırmayla ilgili diğer bir sorun, temiz durumda olduğu bilinen bir veya iki test web sitenizin olmasını sağlamaktır. Aksi takdirde, testlerinizle ilgili bir sorunun tehlikeli bir test web sitesine bağlı olmadığından emin olamazsınız.

Yukarıdaki olası sorunları çözmek için tüm test sürecini Docker kapsayıcılarında çalıştırmayı seçtim, böylece her çalıştırmanın saniyeler içinde otomatik olarak çalıştırılabilen tutarlı bir ortamı olur.

Docker Oluştur

İşleri nispeten esnek tutmak için uyum içinde çalışan birkaç kapsayıcı çalıştırıyoruz, bunun için işleri düz tutmak için docker-compose kullanıyoruz.

Yukarıdaki özet, WP Offload S3'ün kabul testleri için geçerli docker-compose.yml dosyasını içerir. Burada çok ayrıntıya girmeyeceğim, ancak görebileceğiniz gibi, diğer web sunucusu, veritabanı sunucusu, Selenium/PhantomJS sunucuları, test çalıştırıcısı ve eklenti oluşturma hizmetleri için tutarlı bağlama noktaları sağlayan bir veri kapsayıcı kombinasyonu var. Bazı hizmetlerin çalışması diğerlerine bağlıdır, bu nedenle, örneğin Codeception testlerini çalıştıran varsayılan acceptance-tests hizmeti, web-server ve Selenium selenium-server-chrome hizmetlerine bağlanır, çünkü bunlar çalışır durumda olmadan hiçbir şey yapamaz. .

Yukarıda, WP Offload S3 deposundaki docker klasörünün yapısını görebilirsiniz. WordPress veya Codeception'ı çalıştırmak veya eklentilerimizi oluşturmak için gerekli olan data , php-cli ve php-server ile ilgili hizmetler için oluşturduğumuz özel Docker görüntülerimiz var.

Kabul testlerimiz, eklentilerin iki nedenden dolayı kullanılabilir olması için zip dosyalarına dayanır: bu nedenle, eklentileri yüklemeyi test edebiliyoruz ve böylece müşterilerimizin alacağı ürünü gerçekten test ediyoruz. Küçük bir bonus olarak, eklentilerimizi bir kap aracılığıyla oluşturan bir docker/build-plugins.sh betiği oluşturdum, yani bir geliştiricinin makinesine grunt , yarn veya compass gibi şeyler yüklemesine bile gerek yok. Kabul testlerini özel bir yapı sunucusunda veya belki de birim testlerimizi yaptığımız gibi Travis CI aracılığıyla çalıştırmamız için bizi ayarlar.

run-tests.sh docker

Komut satırında docker/run-tests.sh çalıştırmak, tüm kabul testi paketini çalıştırmak için yeterlidir. Bununla birlikte, varsayılan Selenium/Chrome'dan Selenium/Firefox veya PhantomJS gibi bir şeye geçmek için argümanlar verebilirsiniz. Örneğin, testleri Firefox ile çalıştırmak için şunu kullanırdık:

 docker/run-tests.sh -e firefox

Bir sonraki bölümde, kabul testlerini çalıştırırken çok sık kullandığımız en önemli argüman olan -t hakkında bilgi edineceksiniz.

kod algılama

Kabul testlerinizi çalıştırmak için Codeception'ı kullanırken, komut dosyalarınızı güzel bir klasör hiyerarşisi halinde yapılandırabilirsiniz ve alfabetik sırayla “-Cept.php” ile biten herhangi bir şey bulacaktır.

Kabul testlerimizi eklentiye özel klasörlere ayırdık ve istediğimiz sırayı elde etmek için klasörlerin önüne 2 basamaklı bir sayı ekledik. Klasörlerin içinde benzer: her testin, istediğimiz sırada çalıştıklarından emin olmak için 3 basamaklı bir ön eki vardır. 3 basamaklı ön ekler, test komut dosyalarını kurulum/kurulum, ayarlar, medya yükleme, medya düzenleme vb. gibi konu alanlarına gevşek bir şekilde gruplandırır.

Tüm bir eklentinin testlerini kendi başına çalıştırabiliriz:

 docker/run-tests.sh -t 01-amazon-s3-and-cloudfront

Veya tek bir test betiği çalıştırabiliriz:

 docker/run-tests.sh -t 01-amazon-s3-and-cloudfront/01-002-DeactivateParent-Cept

Komut dosyalarının çoğu, temel kurulum ön koşulları için diğer komut dosyalarına bağlıdır. Örneğin, acceptance/01-amazon-s3-and-cloudfront/01-002-DeactivateParent-Cept.php betiği şöyle görünür:

 <?php include '01-001-ActivatePlugin-Cept.php'; include COMMON_TESTS_DIR . 'DeactivateParentStd.php';

Temel kurulum için önceki 01-001-ActivatePlugin-Cept.php komut dosyasını kullanıyor ve farklı eklentiler arasında yeniden kullanılabilirlik için common klasörde bir DeactivateParentStd.php komut dosyası var.

Dahil 01-001-ActivatePlugin-Cept.php betiği de son derece basittir:

 <?php include '_bootstrap.php'; include COMMON_TESTS_DIR . 'ActivatePlugin.php';

Farkı yaratan, her eklenti klasörünün sahip olduğu _bootstrap.php dosyasıdır ve testler boyunca kullanılan bir dizi değişkeni ayarlar. İşte acceptance/01-amazon-s3-and-cloudfront/_bootstrap.php :

 <?php $slug = 'wp-offload-s3-lite'; $plugin_slug = 'amazon-s3-and-cloudfront'; $name = 'WP Offload S3 Lite'; $prefix = 'as3cf'; $tab = 'media'; $addon_name = 'WP Offload S3 Lite'; $plugin_site = "https://wordpress.org/plugins/{$plugin_slug}/"; $plugin_site_title = 'WP Offload S3 Lite'; $install = true; $parent = new stdClass(); $parent->slug = 'amazon-web-services'; $parent->basename = 'amazon-web-services'; $parent->name = 'Amazon Web Services'; $option_name = 'tantan_wordpress_s3'; $option_version = '5'; $option_version_name = 'post_meta_version'; $default_bucket = 'wpos3.acceptance.testing'; $default_region = ''; $default_cloudfront = 'xxxxxxxxxx.cloudfront.net'; $I = new AcceptanceTester( $scenario );

En önemli değişken, sonundaki $I one'dır, Codeception'ın tüm büyüsünü başlattığı yer burasıdır.

acceptance/common/DeactivateParentStd.php dosyasında, Codeception işlevlerini çağırmak için $I I'nin yaygın olarak nerede kullanıldığını görebilirsiniz:

 <?php $I->assertNotEmpty( $slug, 'slug not empty' ); $I->assertNotEmpty( $plugin_slug, 'plugin_slug not empty' ); $I->assertNotEmpty( $name, 'name not empty' ); $I->assertNotEmpty( $parent, 'parent not empty' ); $I->loginAsAdmin(); $I->amOnPluginsPage(); // Happy path for parent plugin... $I->seePluginActivated( $parent->slug ); // ... and target plugin. if ( ! $I->can( 'seePluginActivated', $slug ) && ! $I->can( 'seePluginActivated', $plugin_slug ) ) { $I->fail( 'Could not activate ' . $slug ); } // Parent plugin not installed notice. global $wp_plugin_dir; rename( $wp_plugin_dir . '/wp-content/plugins/' . $parent->basename, $wp_plugin_dir . '/wp-content/plugins/' . $parent->basename . '.bak' ); $I->amOnPluginsPage(); $I->seePluginDeactivated( $parent->slug ); $I->see( "{$name} has been disabled as it requires the {$parent->name} plugin. Install and activate it." ); rename( $wp_plugin_dir . "/wp-content/plugins/{$parent->basename}.bak", $wp_plugin_dir . "/wp-content/plugins/{$parent->basename}" ); // Activate parent plugin through notice. $I->amOnPluginsPage(); $I->seePluginDeactivated( $parent->slug ); $I->see( "{$name} has been disabled as it requires the {$parent->name} plugin. It appears to be installed already." ); $I->click( '#' . $plugin_slug . '-activate-parent' ); $I->seePluginActivated( $parent->slug );

Codeception, işlev adlarının, yaptığınız ve tanımlandığı gibi gerçekleşmesini beklediğiniz eylemler olarak okunabilir olmasını sever. Yani yukarıdaki kodda “Yönetici olarak giriş yapıyorum”, “Eklentiler sayfasındayım” veya “Eklentinin etkin olduğunu görüyorum” gibi şeyler görebilirsiniz.

Pekala, Codeception diyorum, ancak Codeception için en mükemmel wp-tarayıcı WordPress'e özgü uzantı setinin kapsamlı kullanımı var. Bu şekilde $I->amOnPluginsPage(); diyebiliriz. URL'yi bilmek zorunda kalmadan WordPress panosundaki yüklü eklentiler listesine gitmek için veya $I->seePluginActivated( $parent->slug ); Bir eklentinin aktif olduğunu test etmek için. wp-tarayıcı, bize bir sürü kod kazandıran birçok başka kolaylık işlevi içerir, teşekkürler Luca!

Yukarıdaki kod, en basit testlerimizden bazılarına aittir. Ayrıca, test edilen işlevselliğin farklı ortam değişkenleri vb. ile farklı eklentiler tarafından kullanılabileceği tüm çeşitli yolları kapsayacak şekilde farklı senaryolar için farklı parametrelerle somutlaştırdığımız sınıflardan çalıştırılan bazı oldukça karmaşık testler kurduk. gerçekten oldukça karmaşık ve şimdi eklentilerimizin bazı alanlarını manuel olarak yaptığımızdan çok daha kapsamlı bir şekilde ve çok daha kısa sürede test ediyor.

WP Offload S3 Assets için kabul testlerini oluşturan 11 betiğin 25 dakikalık çalışması 15 saniyeye sıkıştırılmış gibi görünüyor.

Başarısızlık kesinlikle kasıtlı olarak biraz renk vermek ve bir hatanın nasıl göründüğüne dair bir fikir vermekti ve kesinlikle sitemize yapılan bir yükseltmenin dokümanlar URL'si test edilirken aynı anda çalıştırılmasından kaynaklanmıyor. 😉

Test paketinin tam olarak çalıştırılması 50 komut dosyası içerir ve çalıştırılması yaklaşık 5 saat sürer!

Pürüzsüz Yelken Ha?

Otomatik kabul testinin kurulması, engelleri olmadan olmamıştır.

WP Offload S3 ve Jeff (şimdi WP Migrate DB Pro için testleri yazan) için bu kabul testlerini geliştirirken benim için en büyük sorun, inanılmaz derecede yavaş geri bildirim döngüsüdür. En kısa komut dosyalarımızın çalışması birkaç dakika sürer, ancak Amazon S3 ile kapsamlı etkileşime sahip daha uzun olanlardan bazılarının tüm senaryolarını tamamlaması 30 dakika sürebilir. Testleri gelecekte daha da bölerek muhtemelen bunu iyileştireceğiz; ancak testleri yazmanın nedeni, bir yayın döngüsünün sonunda bir kez çalışan ve bu döngü sırasında ara sıra arka planda çalışan bir şeye sahip olmaksa, komut dosyalarını çok fazla bölmek için büyük bir itici güç yoktur. Ayrıca, testleri geliştirirken bazı destek taleplerine yanıt vermek, ekibin geri kalanı tarafından yapılan bazı çekme isteklerini incelemek veya genellikle GitHub sorunlarında veya Slack'te sorunlara neden olmak için bolca zamanım oldu.

Diğer iki WP Offload S3 ekip üyesi yeni sürümlerle uğraşırken temel testleri yazmakla görevlendirildiğim için, geliştirmenin eklenti değiştiği için kabul testlerini meşru bir şekilde kıracağı durumlar oldu. Bu benim için oldukça acı vericiydi, ancak kabul testlerini mutlu tutmaktan tüm ekibin sorumlu olduğu noktada olduğumuza göre, her geliştiricinin testleri bozabilecek değişiklikler yaptıklarında testleri güncellemesi gerekiyor. Artık her geliştirici, yeni işlevler için de test komut dosyaları eklemelidir.

Şu anki Docker kurulumunda yakın zamanda bulduğum bir sorun, onu çok güvenli hale getirmem ve macOS için Docker'a güvenmem (ve Windows'un) yazmaları kapsayıcıdan birim montajlarına, çalışan kullanıcının kendi dosya sahipliğine ve izinlerine çevirme yeteneği. Testlerimizi Linux üzerinde çalıştırmayı denediğimde, web sitesini kuramadı veya npm veya besteci gereksinimlerini yükleyemedi, çünkü bağlama noktasına “www-data” kullanıcısı olarak yazamadı. Bunun üstesinden gelmek için Docker tabanlı Devilbox ile aynı yöntemi kullanacağımı ve kullanıcının UID ve GID'sinin belirtimine izin vermek için bir .env dosyası kullanacağımı umuyorum. Aslında, bir noktada, her geliştiricinin kabul testlerini farklı bir web sunucusu kombinasyonu ve .env dosyasında belirtilen PHP sürümü ile kolayca çalıştırabilmesi için Devilbox'ı kapsayıcılarımızla genişletmeye ve genişletmeye değer olabilir. çaba.

Yardım Ediyor mu?

Ah evet, kabul testini otomatikleştirmek kesinlikle bir sürümü test etmenin acısını azaltmaya yardımcı oluyor.

Şu anda Amazon Web Services ve WP Offload S3 Lite için manuel olarak çalıştırdığımız testlerin %75'i otomatik kabul testleri kapsamındadır . 🎉

Bu bizim için çok büyük bir kazanım. Tüm bu testleri manuel olarak geçme ihtiyacının ortadan kaldırılması, yalnızca WP Offload S3 Lite'ı test ederken zamandan tasarruf etmekle kalmaz, aynı zamanda testlerin çoğunun WP Offload S3 ve WP Offload S3 Assets için yeniden çalıştırılması gerektiğinden, onlar için zaman kazandırırız. fazla. Her sürüm için geliştirici başına en az birkaç günlük testten tasarruf ediyoruz (muhtemelen daha fazla olsa da). Bu, her sürümde kaydedilen dört ila altı günlük beyin uyuşturma testi demektir!

Otomatik kabul testleri, yaptığımız manuel testlerden daha kapsamlıdır. Kabul testlerimiz çok sayıda mevcut hatayı yakaladı, ancak muhtemelen daha da yararlı olan yeni hatalar, manuel olarak almakta zorlanacağımız son sürümlerde zaten ezildi.

Hem WP Offload S3 hem de WP Migrate DB Pro ekiplerimiz, en sıkıcı testlerin artık otomatik testler tarafından gerçekleştirildiğini bilerek artık çok daha mutlu.

Lütfen Efendim Biraz Daha İstiyorum!

Bu sahne arkası, bir kısmını otomatikleştirerek sürüm testimizi nasıl iyileştirdiğimize baktı mı, otomatik kabul testine olan ilginizi mi çekti? Öyleyse, WooCommerce için Otomatik Kabul Testi ile ilgili bu makaleye göz atın. Bu konuda daha fazlasını görmek ister misiniz, belki bazı eğitimler? Yorumlarda bana bildirin.

Projelerinizde nasıl testler yapıyorsunuz? Lütfen ipuçlarınızı ve püf noktalarınızı yorumlarda paylaşın, sizin için nasıl çalıştığını duymak isteriz.