отладка компонентов единицы
Развитие моего вопроса здесь, я хотел бы спросить о лучших практиках для отладки дополнений к компонентам единицы.
Интеграция приложений в единицу требует многих компонентов: сервисные файлы, файлы на рабочем столе, dbus клиенты, dbus серверы, и т.д. С таким количеством независимых включенных компонентов я испытываю немного затруднений при нахождении хорошего способа искать проблему, когда что-то не работает. Но так как многие разработчики, кажется, могут разработать в этой среде, существуют, вероятно, инструменты / рабочие процессы, которые я пропускаю.
Как пример: quickly debug, который открывается, отладчик Python не помогает вообще для разработки линзы, если проблема не находится непосредственно в коде линзы (который является легче найденный с простыми модульными тестами). Если проблема находится в сервисном файле, это не помогает вообще. У меня были проблемы, например, с пробелом в имени приложения в .desktop файл, которые приводят к программе, не перечисляемой в звуковом меню (я думаю, возможно, это было другое меню...).
Так: как Вы отлаживаете линзы, средства запуска, индикаторы, методы HUD...?
Есть ли инструмент для проверки целостности a .service файл?
Есть ли инструмент для проверки целостности a .desktop файл?
Есть ли инструмент, чтобы видеть, существует ли коллизия в .desktop/.service файлы? (например, несколько .service файлы, предоставляющие тот же dbus сервис)
Существует ли способ наблюдать коммуникацию между определенной линзой в тире и сервисом линзы поддержки?
Я могу протестировать линзы, не устанавливая их?
1 ответ
Вы не можете протестировать линзу, не устанавливая его. Если Вы не хотите делать это в своей системе, можно всегда использовать VM.
можно использовать DFeet для наблюдения то, что продолжается по DBus, но он действительно требует довольно хорошего понимания того, что должно продолжать по DBus понимать его.