Aracılığıyla paylaş

MRTK3'e katkıda bulunma

  • Makale

MRTK3, MIT lisansı kapsamındaki açık kaynaklı bir projedir. Topluluk katkıları, hem yeni özellikler hem de hata düzeltmeleri için memnuniyetle karşılanır ve takdir edilir.

MRTK3'e katkıda bulunmak kolaydır. Tüm MRTK3 paketlerini yerel disk içi bağımlılıklar olarak içerdiğinden Unity projesini kullanışlı bir geliştirme test yatağı olarak kullanmanızı MRTKDevTemplate öneririz. Daha fazla bilgi için örnek sahneler ve yerel disk içi bağımlılıklar hakkında daha fazla bilgi için MRTKDevTemplate projesinin belgelerine bakın.

Katkı kılavuzu

  1. MRTK deposunu GitHub hesabınıza çatal oluşturun.

  2. Şablon projesinden başlama kılavuzumuzu izleyerek çatallanmış MRTK deponuzu kopyalayın, gerekli araçlara, özellikle de doğru Unity sürümüne sahip olduğunuzdan emin olun. Doğru dalda olduğunuzdan emin olmak için komutunu kullanarak kopyalayın:

git clone --branch mrtk3 YOUR_GIT_URL
  1. Değişiklikleriniz veya düzeltmeleriniz için yeni bir dal oluşturun.
git checkout -b yourchange_fix

  1. konumundaki MRTKDevTemplate şablon projesini UnityProjects/MRTKDevTemplateaçın. Kolay erişim için projeyi Unity Hub'ınıza ekleyebilirsiniz.

  2. İstediğiniz değişiklikleri yapın ve değişikliklerinizin beklendiği gibi çalıştığından emin olmak için birim testleri oluşturun. Düzenleyicide test edip cihaza dağıtıldığından emin olun. Değişikliklerinizi dalınıza işleyin. Dalınızı çatal yukarı akışınızda yayımlayın.

  3. MRTK deposunda dalını hedefleyen mrtk3 bir çekme isteği açın. Yaptığınız değişiklikleri doğru şekilde açıkladığınızdan ve daha iyi kategorilere ayırma ve önceliklendirme için çekme isteğinize ilgili etiketleri uyguladığınızdan emin olun. MRTK'ye yeni katkıda bulunan biriyseniz, katkı sözleşmemizi imzalamanız gerekebilir.

  4. Topluluk veya bakım ekibi tarafından istenen düzeltmeleri giderin ve onaydan sonra çekme isteğinizi birleştirin.

Test yazma

Testler, MRTK'nin yüksek kaliteli karma gerçeklik uygulamaları için güvenilir bir temel olmasını sağlamanın kritik bir parçasıdır. Eklenen tüm yeni özellikler, gelecekte kod tabanında başka değişiklikler yapıldığından işlevlerinin doğru kalmasını sağlamak için birim testlerine sahip olmalıdır.

Birim testleri yazmak için önce mevcut birim testlerine bakmanızı ve MRTK test yardımcı programlarının ve simülatörünün XR girişinde sahte olarak nasıl kullanıldığını öğrenmenizi öneririz. El girişi, bakış, HMD konumu ve girişle ilgili diğer temel özellikleri taklit edebilirsiniz. İyi birim testleri yazmak için bazı genel öneriler aşağıdadır:

  • Daha büyük monolitik testler yerine daha küçük işlevsellik parçalarını değerlendiren daha ayrıntılı testler yazmayı deneyin. Daha ayrıntılı birim testleri bakımcıların hangi özelliğin bozulduğunu görmelerini sağlar. Daha genel uçtan uca işlevsellik testleri de beğenilir, ancak özelliğinizin her küçük bölümünün baştan başlamak için iyi test edilmiş olduğundan emin olun.
  • Testinizin (ve özelliğinizin) kullanıcının yönlendirmesi veya konumu hakkında herhangi bir varsayımda bulunmadığından emin olun. Testleriniz ve özellikleriniz, dünya kaynağından rastgele sapma veya döndürme işlemlerinde çalışmalıdır.
  • Testleriniz kullanıcı girişiyle dalga geçiyorsa, uygun test koşumunun ayarlanmasını ve yıkılmasını sağlayan bizim alt sınıfımızı BaseRuntimeInputTestsyaptığınızdan emin olun.
  • Testinizin çeşitliliğini ve esnekliğini kolayca artırmak için NUnit parametreleştirmesini kullanın. Parametreli NUnit testleri için buradaki belgelere bakın.
  • Bazı girişlerin veya etkileşimlerin kaydedilmesi birden çok kare alabilir. Etkileşimleriniz kaydedilmiyorsa testinize fazladan gecikme kareleri eklemek için kullanabilirsiniz yield return RuntimeTestUtilities.WaitForUpdates() .
  • Yavaş CI yineleme sürelerini önlemek için mümkün olan en kısa sürede yürütülen birim testleri yazmayı deneyin.
  • öğesine ilgili test bağımlılıklarını package.jsonve test klasörünün derleme tanım dosyasına doğru başvuruları eklediğinizden emin olun.

Sürekli tümleştirme

Her çekme isteği birleştirilmeden önce otomatikleştirilmiş testlere tabi tutulur. Diğer sürekli tümleştirme (CI) işleri, bozuk paketlerin akışa dağıtılmadığından emin olmak için ana geliştirme dalında sonuçta elde edilen işlemede de çalıştırılır.

Testleriniz düzenleyiciden geçiyor ancak CI çalıştırmasında başarısız olursa, testlerinizi toplu iş modunda yerel olarak çalıştırmanız gerekir. Zamanlama farklılıkları veya diğer Unity ilginçliklerinden dolayı bazı test türleri grafiksiz toplu iş modunda çalışırken beklenmedik şekilde başarısız olabilir. Testlerinizi toplu iş modunda yerel olarak çalıştırmak, CI'nin bunu yapmadan önce bu tutarsız testleri tanımlamanıza yardımcı olur.

Tooling/Tests/run_playmode_tests.ps1 Testleri toplu iş modunda yerel olarak çalıştırmak için betiği kullanın. Bunu yapmak için Unity düzenleyicinizi kapatmanız gerekir.

$ ./Tooling/Tests/run_playmode_tests.ps1

Betik, hem dosyalar hem de .log test sonuçları .xmldahil olmak üzere klasöründe çıkış dosyaları /out oluşturur. Betikte normal bir ifade geçirerek hangi testlerin çalıştırıldığına filtreleyebilirsiniz. Özel Unity sürümleri ve proje klasörü konumları bağımsız değişken olarak da sağlanabilir.

$ ./Tooling/Tests/run_playmode_tests.ps1 -unityVersion 2021.3.5f1 -projectPath ../my/project/path