OSS projelerinde entegrasyon testleri - 3. şahısların kimlik doğrulaması ile nasıl ele alınabilir?

(Açık kaynaklı) hobi projelerimden biri, GitHub, Bitbucket vb. Kaynaklardan çevrimdışı yedeklemeler yapan bir yedekleme aracıdır. Depoların
bir listesini almak için ana bilgisayar API'sını çağırır ve sonra Git / Mercurial / klonlamak için her şeyi kullanır / depoları yerel bilgisayara çekin.

Bu yüzden GitHub API'sını aradığım kimlik doğrulama ile entegrasyon testlerim var.
(ve klonlama / çekme özelliği bittiğinde, muhtemelen GitHub'daki depoları klonlayan ve aynı zamanda kimlik doğrulaması gereken testler olacaktır)

Özellikle bu entegrasyon testlerinde kullanılmak üzere bir kullanıcı ve kuruluş oluşturdum .

Sorun: Açık kod olduğu ve kod GitHub'da herkese açık olduğu için kaynak kodun herhangi bir yerinde şifreleri kodlayamıyorum.

Şimdi ne yapıyorum

Testlerde, ortam değişkenlerinden tüm kullanıcı adlarını, şifreleri ve depo adlarını alıyorum.
İşte bir örnek :

config.Name = TestHelper.EnvVar("GithubApiTests_Name");
config.Password = TestHelper.EnvVar("GithubApiTests_PW");

( TestHelper.EnvVarortam değişkeninin değerini alan ve mevcut olmadığında istisna atan bir yardımcı yöntemdir)

Sonra, bu ortam değişkenlerini ayarlar bir toplu iş dosyası var. Yapı komut dosyamda ve testleri yürütmeden önce
gerçek olan ( environment-variables.bat) çağrılır, ancak kaynak kontrolünde yok sayılır, bu yüzden aslında depomda değildir.

Ne olduğunu kaynak denetimi olduğunu içinde environment-variables.bat.sampleama sahte şifreleri ile aynı ortam değişkenlerini ayarlar:

rem copy/rename this file to environment-variables.bat

echo Setting environment variables for integration tests...

set GithubApiTests_Name=scm-backup-testuser
set GithubApiTests_OrgName=scm-backup-testorg
set GithubApiTests_PW=not-the-real-password
set GithubApiTests_Repo=scm-backup

Bu yüzden havuzu makineme kopyalayabilir, bu dosyayı yeniden adlandırabilir environment-variables.bat, sahte şifreyi gerçek olanla değiştirebilirim ve tüm entegrasyon testleri işe yarayacaktır.

Bu, Sürekli Entegrasyon ile de çalışır - AppVeyor kullanıyorum ve bu ortam değişkenlerini web arayüzünde ayarlayabilirim .

Bu konuda sevmediğim şey

Bence bu bir OSS projesi için iyi bir çözüm değil, özellikle bu proje için değil :

Teorik olarak, projeme katkıda bulunan bir kişi şu anda entegrasyon testlerini şu şekilde yapabilir:

• GitHub'da kendi test kullanıcısını ve test organizasyonunu oluşturma
• bazı test havuzları oluşturma
• environment-variables.batfarklı değerlerle kendi versiyonunu yaratmak

Sorun, uygulamamın birden çok kaynak kodu barındırıcısını yedekleyebilmesidir.
Şu anda, yalnızca GitHub'ı destekliyor, ancak doğru arabirimleri uygulayan birkaç sınıf ekleyerek daha fazla sunucu için destek eklemek kolay olacak.

Daha sonra daha fazla ana bilgisayar için destek uyguladığımda, ortam değişkenlerinin sayısı artacaktır. Tüm entegrasyon testlerini
yürütebilmek için , potansiyel bir katılımcı GitHub, Bitbucket, GitLab, .... 'da kendi kullanıcılarını, kuruluşlarını ve test havuzlarını oluşturacak ve daha fazlasını kimin bileceğini ve hepsini sürümüne ekleyecektir . environment-variables.bat

Kodun halka açık olduğu bir projede bunu nasıl yapacağınız daha iyi bir çözüm var mı?

Diğer projelerin şu an yaptığım gibi bir şey yaptığını biliyorum.
Octokit.net , örneğin, sahip bir komut dosyası için kurulum ortam değişkenleri GitHub API aradığınız entegrasyon testleri için.
Ama sadece bir kullanıcıya ve bir organizasyona ihtiyaçları var ve daha fazlasına ihtiyacım olacak.

Belki bir katılımcının tüm entegrasyon testlerini gerçekten çalıştırabilmesini sağlayan bir çözüme ihtiyacım yok .
Örneğin, birisi projemin GitHub desteğine katkıda bulunmak isterse, yalnızca GitHub entegrasyon testlerini yapabilmesi gerekir.
Belki de entegrasyon testlerimi sonsuz sayıda "gruba" (?) Bölebilmem ve daha sonra "ve şimdi 'Github' grubuna ait olan tüm testleri gerçekleştirebilmem" için aklı başında bir yola ihtiyacım var.

Mevcut kurulumunuzun iyi olduğunu düşünüyorum, ancak birkaç ayar yapacağım.

Tüm entegrasyon testlerini yürütebilmek için, potansiyel bir katılımcı GitHub, Bitbucket, GitLab, .... 'da kendi kullanıcılarını, kuruluşlarını ve test havuzlarını oluşturacak ve bunların ne kadarını bilen ve hepsini çevre değişkenlerine ekleyecektir. .bat sürümü.

Evet, bu doğru, ancak katkıda bulunanlar projenizde bir PR oluşturmadan önce tüm entegrasyon testlerini yapmak zorunda değildir. Bir PR oluşturulduktan sonra, CI tüm test paketini çalıştırır.

Kolayca çalıştırılması bir şekilde mümkün olmayan bir test takımına sahip olmak yaygındır. Birçok kuruluş için çalıştırılması günler süren test paketlerini korurlar; bu nedenle geliştiriciler, çalıştırılması kolay testleri seçmeli olarak yürütmeli ve daha titiz testler için kodu ileriye doğru itmelidir. Aynı yaklaşımı öneriyorum.

Düzenli / güvenilir katılımcılar için, bir PR yapmadan önce kendi dallarında CI çalıştırmalarına izin verecek şekilde projenizde gerçek katkıda bulunanlar yapabilirsiniz .

Bununla birlikte, katkıda bulunanların testlerin tamamını kullanmasını engellemiyorsunuz . Kendi GitHub kimlik bilgilerini sağlayabilir veya kendi test hesaplarını oluşturabilirler ve düzenli katkıda bulunanlar muhtemelen bunu yapacaktır.

Önerdiğim ayarlamalar:

İlk olarak, test kapsamı birim testlerinizin çoğunu yapın. Bunlar kod tabanınızın tüm dallarını kapsamalıdır.

İkinci olarak, uç noktanın takıldığı yere entegrasyon testleri yazın. Sahte bir GitHub Rest hizmeti başlatarak bu API'nın taşıma katmanıyla alay edebilir ve HTTP istek / yanıt akışlarını simüle edebilirsiniz. Örneğin (sözde kodda):

// Test failed authentication to GitHub
val server = new WebServer("localhost", 9453, { request =>
    return Response(401, "unauthenticated")
})
server.start()
val backupService = new GitHubBackupService("http://localhost:9453")
backupService.backup must throw UnauthenticatedException()
server.stop()

Bu testler daha karmaşık olacak, ancak

1. Sahte hesaplar ve depolar oluşturmadan test edin
2. Gerçek GitHub ile simüle edilmesi zor olan arıza durumlarını test edin. Örneğin 502 yanıtları, bağlantı zaman aşımları, olağandışı / ayrıştırılamayan yanıt gövdeleri.

Üçüncüsü, özel bilgi gerektiren testleri normal bir yapı altında çalıştırarak devre dışı bırakın. Çoğu derleme yönetimi aracında entegrasyon testlerini ayırmanın veya testleri test etmenin ve bunları seçerek çalıştırmanın bir yolu vardır. Katkıda bulunanlar önceden herhangi bir yapılandırma yapmadan yazılımı oluşturabilmeli ve test edebilmelidir . Tam test paketi, CI'deki her derlemeden sonra çalışmalıdır.

Son olarak, katkıda bulunanların bunları yapmayı seçebilmeleri için testleri ve test belgelerinizde nasıl çalıştırılacağını belgeleyin.