Улучшение качества Jami
Единичные испытания
Труднее сделать единичный тест на проекте Jami из-за условий гонки на многоуровневой зависимости.
We use lcov for the coverage, you can find the lcov’s configuration in the daemon’s Makefile.am. Also, the coverage can be found at https://docs.jami.net/coverage/ and https://dl.jami.net/docs/dhtnet/coverage
Необходима система, чтобы убедить команду провести единичный тест на новый код до слияния
Вы можете запустить их, делая проверку make в папке даемона или отдельно в папке единичного теста с gdb: gdb ut_media_encoder
В окружающей среде необходимо установить –disable-shared во время команды./configure
Clients also have tests (cf
jami-client-qt/testsfor Desktop,jami-client-android/jami-android/app/src/androidTestfor Android)
Тесты интеграции
Каждый коммит проходит тесты интеграции в докерах на машинах построения. Подробности можно найти на: jenkins.jami.net
Код-ревизия производится коллегой-разработчиком, иногда код пересматривается тем же разработчиком, это следует избегать, чтобы подчеркнуть закон Linus.
Sonarqube позволяет Дженкинсу создавать Jami и проверять линтинги. Вы можете найти фильтры и результаты на: sonar- jami.savoirfairelinux.net Sonar использует clang-tidy в качестве компилятора линтинга предпроцессора, вы можете найти фильтры clangs в файле.clang-tidy в папке daemon.
On SFLVault sonarqube can be found at service m#2637 and admin logins at service s#7169
Док и обратная связь:
Все документы можно найти на сайте docs.jami.net
Проблемы возникают у разработчиков или пользователей на git.jami.net
Агент.
Every night, hundred of calls are tested via 2 Agents and a message is posted every morning in the chat with the result (if all call succeeded or not)
Испытания дыма
Перед тем как каждый из них выйдет, каждый клиент должен пройти список сценариев.
Сценарии описаны здесь: [Тестовые дымные дымные дымные дымные дымные дымные дымные дымные дымные дымные дымные дымные дымные дымные дымные дымные дымные дымные дымные дымные дымные дымные дымные дымные дымные дымные дымные дымные дымные дымные дымные дымные дымные дымные дымные дымные дымные дымные дымные дымные дымные дымные дымные дымные дымные дымные дымные дымные дымные дымные дымные дымные дымные дымные дымные дымные дымные дымные дымные дымные дымные дымные дымные дымные дымные дымные дымные дымные дымные дымные дымные дымные дымные дымные дымные дымные дымные дымные дымные дымные дымные дымные дымные дымные дымные днем днем днем днем днем днем днем днем днем днем днем днем днем днем днем днем днем днем днем днем днем днем днем днем днем днем днем днем днем днем днем днем днем днем днем днем днем днем днем днем днем днем днем днем днем днем днем днем днем днем днем днем днем днем днем днем днем днем днем днем днем днем днем днем днем днем днем днем днем днем днем днем днем днем днем днем днем днем днем днем днем днем днем днем днем днем днем днем днем днем днем днем днем днем днем днем днем днем днем днем днем днем днем днем днем днем днем днем днем днем днем днем днем днем днем д
Они проверяются QA dpt. перед отправкой их разработчикам, если это необходимо.
Если в релизе есть сетевой коммит, который был слиян, отдел QA должен быть в состоянии автоматизировать различные тесты подключения (как описано ниже в конфигурациях Звонов)
Позвони конфигурации.
Это список конфигураций сети, которые должны быть протестированы:
(IPv4! IPv6) + (TURN!! TURN) + (STUN!! STUN) + (UPnP!! UPnP) для обеих сторон.
Если обе стороны являются IPv4 только без TURN/STUN/UPnP, звонок должен быть только локальным.
Что нужно сделать
Создать систему в составе команды, обеспечивающую содержание и создание единичных испытаний.
Each major functionality should be tested as whole by adding a test (i.e. making sure a message was received, the call was ended well on both side, etc…)
Каждая новая функциональность должна быть протестирована на каждой платформе перед ее слиянием для снижения регрессии.
Интегрировать сонаркв на каждом клиенте
Автоматизировать тестирование поведения Jami на совместимость сетей