بهبود کیفیت جمی

آزمایشات واحد

انجام آزمایش واحد در پروژه Jami به دلیل شرایط مسابقه در وابستگی چند سطح دشوارتر است.
حدود 30 آزمایش واحد و پوشش 26٪ وجود دارد. به دلیل تقاضای زیاد Jami برای ارائه عملکردهای جدید به کاربر به سرعت، آنها توسط توسعه دهندگان یا یک بخش QA نگهداری نمی شوند.
ما از lcov برای پوشش استفاده می کنیم، شما می توانید پیکربندی lcov را در daemon Makefile.am پیدا کنید. همچنین، پوشش را می توانید در https://docs.jami.net/coverage/ پیدا کنید
سیستم ای لازم است که برای شروع متقاعد کردن تیم برای انجام یک آزمایش واحد برای کد جدید قبل از ادغام
شما می توانید آنها را با انجام make check در پوشه daemon یا به طور جداگانه در پوشه آزمون واحد با gdb: gdb ut_media_encoder راه اندازی کنید
محیط باید با --disable-shared در دستور./configure تنظیم شود

شما می توانید تست های چارچوبی را در Makefile.am و make integration پیدا کنید. این کار اسکریپت jami_test.py را در پوشه ابزار/dringctrl می نامد. از dringctrl.py و controller.py استفاده می کند که به شما اجازه می دهد Jami را از طریق bash کنترل کنید.
این باعث می شود که سری تماس ها برای اطمینان از شبکه باز jami's است.
در آینده باید آزمایش های دیگر چارچوبی برای آزمایش عملکردهای جامع در کل اجرا شود.

هر کمیت از طریق تست های ادغام در dockers در ماشین های ساخت می توانید جزئیات را در: jenkins.jami.net پیدا کنید
بررسی کد توسط یک توسعه دهنده دیگر انجام می شود، گاهی اوقات کد توسط همان توسعه دهنده بررسی می شود، این باید برای تاکید بر قانون لینوس اجتناب شود. برچسب Jenkins تایید شده گاهی اوقات کنار گذاشته می شود و توسط +1 از طرف یک توسعه دهنده جایگزین می شود، این نیز باید اجتناب شود.
سونارکوب به جینکینز اجازه می دهد که جامی را بسازد و لینتینگ را تأیید کند. شما می توانید فیلترها و نتایج را در: sonar- jami.savoirfairelinux.net Sonar از clang-tidy به عنوان یک سازنده لنتینگ پیش پردازنده استفاده می کند. شما می توانید فیلترهای clangs را در فایل.clang-tidy در پوشه daemon پیدا کنید.
در sflvault sonarqube می توان در سرویس m#2637 و ورود به سیستم در سرویس s#7169 پیدا کرد

یک اسکریپت هر 30 دقیقه در یک ماشین مجازی jami-monitorpeervm-01 خوانده می شود. شما می توانید آن را در sflvault سرویس s#7209 پیدا کنید و در حال تماس با یک مشتری دیگر virtual jami-monitorpeer-02 (خدمات s#7224). یک سری تماس ها انجام می شود و نرخ شکست را باز می گرداند. شما می توانید تمام جزئیات را در https://wiki.savoirfairelinux.com/wiki/Jami-monitorpeervm-01.mt.sfl پیدا کنید.
در صورت لزوم دستور دستی./script.sh peer 031acbb73f2a3385b2babc7161f13325be103431 است
این یک نمودار نقطه به نقطه در زمان واقعی را در https://monitoring.savoirfairelinux.com/grafana/dashboard/script/dyndash.js?host=jami-monitorpeervm-01.mtl.sfl&service=Check%20JamiCall&panelId=1&fullscreen&orgId=1

قبل از هر بازي هر مشتري بايد از يه ليست سناريوه ها عبور کنه

سناریوهای اینجا توصیف شده است: [تخت های دود جامی]

آنها توسط QA dpt بررسی می شوند قبل از اینکه در صورت لزوم به توسعه دهندگان ارسال شوند.

اگر یک نسخه شامل یک تعهد شبکه ای است که ترکیب شده است، بخش QA باید قادر به اتوماسیون آزمایش های مختلف اتصال باشد (مانند در زیر در پیکربندی های تماس)

این لیست از پیکربندی های شبکه است که باید آزمایش شود:

(IPv4\ IPv6) + (TURN!TURN) + (STUN!STUN) + (UPnP!UPnP) برای هر دو طرف.

اگر هر دو طرف فقط IPv4 بدون TURN/STUN/UPnP باشند، تماس باید فقط محلی باشد.

اسکریپت برای تولید MR در repo android client (fdroidMergeRequest.sh) است

پوشش را نزدیک به 60 درصد کنید
ایجاد یک سیستم در تیم برای تضمین نگهداری و ایجاد آزمایشات واحد.
هر عملکرد اصلی باید با اضافه کردن یک آزمون چارچوب (به عنوان مثال اطمینان از دریافت یک پیام، پایان تماس در هر دو طرف و غیره) به طور کامل آزمایش شود.
هر عملکرد جدید باید قبل از ادغام آن برای کاهش بازپسین در هر پلتفرم آزمایش شود.
سونوارکوب را در هر مشتری ادغام کنید
خودکار کردن آزمایش رفتار Jami در شبکیه مطابقت
یک اسکریپت make_ring.py را هم قابل تطبیق برای ویندوز بسازید