Läs på engelska

Dela via

Bidra till MRTK3

  • Artikel

MRTK3 är ett projekt med öppen källkod under MIT-licensen. Community-bidrag är välkomna och uppskattade, både för nya funktioner och felkorrigeringar.

Det är enkelt att bidra till MRTK3. Vi rekommenderar att du använder MRTKDevTemplate Unity-projektet som en praktisk utvecklingstestbädd eftersom det redan innehåller alla MRTK3-paket som lokala beroenden på disk. Mer information finns i dokumentationen om PROJEKTET MRTKDevTemplate för mer information om exempelscener och lokala beroenden på disk.

Bidragsguide

  1. Förgrena MRTK-lagringsplatsen till ditt GitHub-konto.

  2. Klona din förgrenade MRTK-lagringsplats genom att följa vår guide om att starta från ett mallprojekt Se till att du har de verktyg som krävs, särskilt rätt Unity-version. Kontrollera att du är på rätt gren genom att klona med kommandot :

git clone --branch mrtk3 YOUR_GIT_URL
  1. Skapa en ny gren för dina ändringar eller korrigeringar.
git checkout -b yourchange_fix

  1. MRTKDevTemplate Öppna mallprojektet som finns i UnityProjects/MRTKDevTemplate. Du kan lägga till projektet i unity-hubben för enkel åtkomst.

  2. Gör önskade ändringar och skapa enhetstester som säkerställer att ändringarna fungerar som förväntat. Se till att testa i redigeringsprogrammet och distribuera till enheten. Checka in ändringarna i grenen. Publicera din gren till din förgrening uppströms.

  3. Öppna en pull-begäran på MRTK-lagringsplatsen för -grenen mrtk3 . Se till att beskriva de ändringar du har gjort och tillämpa relevanta etiketter på pull-begäran för bättre kategorisering och prioritering. Om du är en ny deltagare i MRTK kan du behöva underteckna vårt bidragsavtal.

  4. Åtgärda eventuella korrigeringar som begärs av communityn eller underhållsteamet och slå samman din pull-begäran efter godkännande.

Skriva tester

Tester är en viktig del av att se till att MRTK är en tillförlitlig grund för program med mixad verklighet av hög kvalitet. Alla nya funktioner som läggs till bör ha enhetstester för att säkerställa att deras funktioner förblir korrekta när andra ändringar görs i kodbasen i framtiden.

För att skriva enhetstester rekommenderar vi att du först tittar på de befintliga enhetstesterna och lär dig hur MRTK-testverktygen och simulatorn används för att simulera XR-indata. Du kan simulera handinmatning, blick, HMD-position och andra grundläggande indatarelaterade funktioner. Här är några allmänna råd för att skriva bra enhetstester:

  • Försök att skriva mer detaljerade tester som utvärderar mindre funktioner i stället för större monolitiska tester. Med fler detaljerade enhetstester kan projekthanterarna se vilken specifik funktion som har brutits. Mer allmänna funktionstester från slutpunkt till slutpunkt uppskattas också, men se till att varje mindre del av funktionen testas väl till att börja med.
  • Kontrollera att testet (och din funktion) inte gör några antaganden om användarens orientering eller plats. Dina tester och funktioner bör fungera vid godtycklig förskjutning eller rotation från världens ursprung.
  • Om testerna simulerar användarindata ser du till att underklassen av vår BaseRuntimeInputTests, vilket säkerställer att rätt testsel har konfigurerats och rivits.
  • Använd NUnit-parameterisering för att enkelt öka variationen och flexibiliteten i testet. Se dokumentationen för parametriserade NUnit-tester här.
  • Vissa indata eller interaktioner kan ta flera bildrutor att registrera. Du kan använda yield return RuntimeTestUtilities.WaitForUpdates() för att lägga till extra fördröjningsramar i testet om dina interaktioner inte registreras.
  • Försök att skriva enhetstester som körs så snabbt som möjligt för att undvika långsamma CI-iterationstider.
  • Se till att du lägger till relevanta testberoenden i package.json, och rätt referenser till testmappens sammansättningsdefinitionsfil.

Kontinuerlig integrering

Varje pull-begäran är föremål för automatiserade tester innan den kan sammanfogas. Andra ci-jobb (kontinuerlig integrering) körs också på den resulterande incheckningen på huvudutvecklingsgrenen för att säkerställa att brutna paket inte distribueras till feeden.

Om testerna skickas i redigeringsprogrammet men misslyckas i CI-körningen bör du köra testerna lokalt i batchläge. Vissa typer av tester kan oväntat misslyckas när de körs i batchläge utan grafik på grund av tidsskillnader eller andra Unity-egenskaper. Genom att köra dina tester lokalt i batchläge kan du identifiera dessa inkonsekventa tester innan CI:n gör det.

Använd skriptet Tooling/Tests/run_playmode_tests.ps1 för att köra tester lokalt i batchläge. Du måste stänga Unity-redigeraren för att göra det.

$ ./Tooling/Tests/run_playmode_tests.ps1

Skriptet genererar utdatafiler i /out mappen, inklusive både .log filer och testresultatet .xml. Du kan filtrera vilka tester som körs genom att skicka ett reguljärt uttryck till skriptet. Anpassade Unity-versioner och projektmappplatser kan också anges som argument.

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