Nitra.Visualizer - требуется помощь в доработке
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.07.17 12:22
Оценка:
Всем привет!

На https://gitter.im/rsdn/nitra зашла речь о тестировании. Решил описать здесь текущее состояние и попросить помощь зала (тм) в вопросе доработки утилиты тестирования.

Еще в самом начале работы над Nitra я создал простенькую GUI-утилиту для тестирования алгоритмов Nitra. Ее функциональность развивалась и в итоге превратилась в полноценную утилиту тестирования — Nitra.Visualizer.exe.

Первая версия Nitra.Visualizer работала в одном процессе и позволяла просто создать текстовые файлы-тыесты и запустить на ней парсер нитры. Далее мы ее доработали и она получила возможность сравнивать преттипринт по дереву разбора (автоматически создаваемый Nitra) с так называемым .gold-файлом.

Еще чуть позже Nitra.Visualizer был разделен на две части:
* собственно Nitra.Visualizer.exe — GUI-утилиту.
* и Nitra.TestsLauncher.exe — ее консольный вариант, который позволял прогонять тесты пакетно.

При работе над новой версией IDE-плагина для Nitra мы создали еще одну версию Nitra.Visualizer.exe работающую в клиент-серверном режиме. Сама утилита только лишь выизуализирует данные приходящие с сервера. Сервер же общий для IDE-плагинов и Nitra.Visualizer.exe. На базе сервера можно вообще делать что угодно, от интеграций к другим IDE, до собственных решений вроде компиляторов и утилит семантического анализа.

К сожалению, так как наша основная задача была работа над сервером клиент-серверной архитектуры Nitra, функциональность новой версии Nitra.Visualizer.exe даже не дотягивает до функциональности предыдущей версии. В ней можно добавить тесты, прогнать их вручную (по одному) и детально рассмотреть выхлоп (дерево разбора, AST, prettiprint, сообщения об ошибках), но полностью утрачена возможность пакетного тестирования.

Кроме того даже в первой версии Nitra.Visualizer поддерживалось только тестирование выхлопа парсера (сравнение prettiprint с .gold-файлом).

На сегодня у нас уже есть возможность создавать AST, производить его типизацию и формировать символы (объекты описывающие сущности в программах).

Из чего состоит Nitra.Visualizer?

Новая версия Nitra.Visualizer находится в подпапке Visualizer солюшена Nitra-Stagt1.sln (или Nitra.sln) и состоит из двух частей:
1. Проекта Nitra.TestsLauncher — консольной части содержащей модельки (используемые в паттерне MVVM в проекте Nitra.Visualizer и для представления модели в пакетных тестах). Этот проект написан на Nemerle.
2. Проекта Nitra.Visualizer — это GUI-часть проекта. Данный проект написан на C# и использует WPF и модель MVVM.

Как скомпилировать?

Инструкция по сборке Nitra находится здесь.
В двух словах: нужно собрать Немерле, собрать бут (батник BuildBoot.cmd в корне проекта), открыть в студии Nitra-Stagt1.sln и произвести его сборку. При этом стоит выгрузить папку Nitra\Stage2.

Что нужно?

Nitra.Visualizer требуются следующие доработки:
1. Восстановить работоспособность пакетного тестирования как в GUI-ежиме (Nitra.Visualizer.exe), так и в консольном режиме (Nitra.TestsLauncher.exe).
2. Создать режимы пакетного тестирования для AST, символов и областей видимости. Здесь уже нужна не тупое кодирование, а проектирование. Тесты должны описываться как можно более просто.

Тесты в Nitra.Visualizer оформлены в иерархию:
* WorkspaceVm — описывает корневой уровень. Содержит список SuiteVm-ов.
* SuiteVm — описывает набор тестов для одного модуля поддержки проектов Nitra (упрощенно говоря — для одного языка).
* SolutionVm — содержит файлы для одного теста. По сути эмулирует солюшен Visual Studio. Содержит в себе 1 (по умолчанию) или более ProjectVm-ом.
* ProjectVm — описывает один проект в SolutionVm.
* FileVm — один файл в ProjectVm.

По умолчанию в тесте имеется один SolutionVm, в котором есть один ProjectVm, в котором есть один FileVm. Но для тестирования многофайловых проектов и многопроектных солюшенов есть возможность создать те и другие.

Что Nitra.Visualizer.exe, что Nitra.TestsLauncher.exe сами не взаимодействуют с Nitra напрямую. Вместо этого они используют Nitra.ClientServer.Client.dll (проект Nitra.ClientServer.Client.nproj) для общения с Nitra.ClientServer.Server.exe (проект Nitra.ClientServer.Server.nproj). При этом используются сообщения (структуры данных) объявленные в Nitra.ClientServer.Messages.dll (проект Nitra.ClientServer.Messages.nproj).

Иными словами Nitra.Visualizer.exe и Nitra.TestsLauncher.exe — это клиенты для Nitra.ClientServer.Server.exe общающиеся по средствам модели акторов (т.е. посылкой сообщений в очереди).

В клиентских процессах нет никаких структур данных Nitra. В них есть только очень простые, описанные в Nitra.ClientServer.Messages.dll структуры данных.

Все XxxVm-классы — это модели представлений хранящие данные нужные для визуализации информации о тестах.

Запросы к серверу описываются в варианте ClientMessage.

Запросы асинхронны. Так что получать ответ нужно в другой очереди. Сами очереди на сегодня являются просто именованными каналами, но могут быть легко заменены на любую другую технологию (например на сокеты или HTTP).

Ответ сервера условно разбивается на два типа:
ServerMessage — условно синхронные ответы (т.е. ответы, которые бессмысленно обрабатывать асинхронно, так как они требуют немедленного отклика).
AsyncServerMessage — совсем асинхронные ответы.

Выполнение тестов и т.п. должно производиться на сервере. Для этого в ClientMessage нужно будет добавлять сообщения начинающие тест и ServerMessage или AsyncServerMessage сообщения возвращающий результаты теста и информацию о ходе тестирования (о прогрессе).

Гуй и пакетный интерфейс должны посылать тесты, получать сообщения о их результате и визуализировать результат.

Нужно сделать как отдельный запуск тестов, так и пакетный.

Что нужно тестировать?

1. Нужно тестировать выхлоп prettiprint, т.е. то что печатается по дереву разбора. Эта функциональность уже была в первой (не клиентской версии визуалайзера). Тут все просто. У нас есть prettiprint в расширенный тестовый формат. Нужно производить тестирование, получать этот формат и сравнивать его с записанным ранее в .gold-файл образцом. Так же нужно сохранять в .gold-файл результат последнего выполнения (по командам из ГУЯ). Тут уже все продумано и нужно только реализовать ту функциональность, что была ранее.

2. Нужно придумать как тестировать сообщения "компилятора". Нитровские модули выдают сообщения. У них есть позиция в тексте и текст самого сообщения. Нужно доработать формат .gold-файла так, чтобы он содержал эту информацию (лучше всего в виде комментария). Так же нужно расширить формат текстового prettiprint-а, чтобы он печатал все сообщения компиляции, чтобы не приходилось долго и муторно вручную формировать .gold-файлы.

3. Надо придумать формат тестирования для AST и символов. Тут нужно хорошенько подумать. Опять же хотелось бы некой автоматизированности формирования эталонных данных (.gold-файла или чего-то еще), чтобы не приходилось формировать их вручную.

Особо подчеркну важность автоматического формирования эталонных данных (а-как .gold-файлов). У нас крайне мало сил и мы не можем выделить отдельных людей которые будут формировать и изменять (в случае изменения внутренностей) .gold-файлы и прочие эталонные данные. По этому к .gold-файлам у нас очень строгие требования:
1. Они должны формироваться автоматически.
2. Они не должны "ехать" при мелких изменениях в тексте тестов. Например, нельзя запоминать точные координаты элементов AST или символов, чтобы пара байтов вбитых перед этим местом не заставляла обновлять .gold-файл.

Общие мысли по тестированию информации об AST и символах

На мой взгляд для тестирования символов нужно сформировать некий DSL описывающий дополнительную информацию в виде комментариев. Причем этот DSL должен как читаться, так и писаться автоматически. В этом DSL-е должны описываться ожидания автора теста, а система тестирования должны считывать их и проверять с реальными результатами.

Продемонстрирую это на примере C#-кода:

/*Symbol:ExplicitNamespaceSymbol Kind:namespace FullName:Ns1*/namespace Ns1
{
  /*Symbol:TopClassSymbol FullName:Ns1.A*/class A
  {
    /*Symbol:Member.Property Name:Prop Flags:Public Type:int*/public int Prop => throw new Exception();
    s // E: Expected: (VariableDeclarator; ','  s  sm)+ ';'
  }
}


Т.е. в месте непосредственно за комментарием или после него до следующего не пробельного символа должен находиться ожидаемый объект. Symbol:TopClassSymbol — означает, что за комментарием должен находиться символ тип которого TopClassSymbol. "Kind:namespace FullName:Ns1" означает, что у этого символа свойство Kind должно иметь значение "namespace", а свойство FullName — "Ns1".

"E: Expected: (VariableDeclarator; ',' s sm)+ ';'" — означает, что в этом месте ожидается сообщение об ошибке с текстом "Expected: (VariableDeclarator; ',' s sm)+ ';'". Тут должны поддерживаться регулярные выражения и поиск подстроки.

Тестовая утилита должна препроцессировать такой формат, вытаскивать из него информацию, далее загружать тест на сервере, типизировать его (это уже все делается) и сравнивать полученные значения с выцепленными из ДСЛ-я. В случае, совпадения всех ожидаемых сзначений тест считается успешно пройденным. В случае, если значения не совпадают нужно выдать информацию об ошибке и обеспечить навигацию к месту где выявлено несоответствие (в ГУИ-версии утилиты).

Сами ДСЛ-коментарии должны перед выполнением теста заменяться на пробельные символы.

В ГУИ-версии утилиты должны быть средства полуавтоматического формирования таких комментариев. Скажем тыкнул в AST в некое значение, выбрал в контекстной менюшке пункт "Добавить в тест" и в текст вставляется комментарий содержащий значение свойства (само дерево уже есть).

ЗЫ

Задача не простоя, объемная но интересная. В курс дела я ввиду. Ну, и где-что не ясно подскажу.

К сожалению сам на нее переключаться не могу, так как и без того есть много вещей которые надо сделать.

Задача вполне подъемная для человека не сведущего в Нитре. Ну, и при успешной ее реализации будет чем гордиться и показывать в резюме.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: Nitra.Visualizer - требуется помощь в доработке
От: ifle  
Дата: 07.07.17 09:39
Оценка:
Установилось, запустилось всё с первого раза. Nitra.Visualizer контактирует с сервером. Ещё не уверен или хочу за это взятся, но не спеша изучаю код.
Re[2]: Nitra.Visualizer - требуется помощь в доработке
От: VladD2 Российская Империя www.nemerle.org
Дата: 07.07.17 12:18
Оценка:
Здравствуйте, ifle, Вы писали:

I>Установилось, запустилось всё с первого раза. Nitra.Visualizer контактирует с сервером. Ещё не уверен или хочу за это взятся, но не спеша изучаю код.


Если есть вопросы, не стесняйся, задавай их здесь или на https://gitter.im/rsdn/nitra
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.