Более быстрый способ тестирования вашей прологовой программы

Question

Я новичок в Прологе, и задача запуска интерпретатора пролога из терминала, набора текста consult ('some_prolog_program.pl'), а затем тестирования только что написанного предиката занимает очень много времени, есть ли способ запустить тест для ускорения разработки?

Например, в C я могу написать main, где я буду использовать функции, которые я определил, тогда я могу выполнить:

make && ./a.out

чтобы проверить код, могу ли я сделать что-то подобное с Прологом?

Answer 1

1. Вы можете всегда открыть интерпретатор, а затем перекомпилировать файл.

2. Вы можете автоматически запустить предикат после компиляции файла:

   :- foo(4,2).
   

   Это будет выполнено foo(4,2) при обнаружении строки в файле.

3. Есть флаги, которые можно использовать при запуске (большинства) интерпретаторов Prolog, которые позволяют вам скомпилировать файл и запустить предикаты (проверьте страницу руководства). Таким образом, вы можете сделать скрипт Bash. Следующая команда свяжется с file.pl и запустит foo/0 с использованием SWI-Prolog:

   #!/bin/sh
   exec swipl -q  -f none -g "load_files([file],[silent(true)])" \
              -t foo -- $*
   

   Этот предикат объединит Аргументы со списком флагов, которые вы указали в командной строке:

   current_prolog_flag(argv, Arguments)
   

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

Лично мне очень нравится гибкость тестирования любого предиката в любое время с трассировкой или без нее (см. trace/0) без необходимости писать дополнительный код для их вызова (в отличие от C).

P.S. о перезагрузке файла без выхода из интерпретатора: у вас могут возникнуть некоторые проблемы, если вы используете динамические предикаты или глобальные переменные; вам придется сделать уборку.

Answer 2

В SWI вы можете загружать вещи как обычно. Затем, когда вы редактируете свои файлы, вы просто произносите make. на верхнем уровне, и он автоматически проверяет все зависимости и только перезагружает измененные файлы.

Для более крупных проектов имеет смысл использовать make-файлы. В частности делать юнит-тестирование. См. Пакет SWI plunit .

Answer 3

Вы можете вызвать тестовый файл из командной строки с помощью prolog +l <file>

Кроме того, вы можете создать один предикат run_tests, который выполняет серию вызовов и проверяет фактические результаты по сравнению с ожидаемыми. Вот статья с хорошим отработанным примером: http://kenegozi.com/blog/2008/07/24/unit-testing-in-prolog

Answer 4

Для простых скриптов в SWI-Prolog, , использующих REPL для проверки кода вручную, обычно достаточно хорошо. Измененные файлы могут быть перезагружены через make/0 (?- make. на верхнем уровне). Просто оставьте Prolog REPL включенным во время редактирования, затем сохраните изменения, запустите make. в REPL и нажмите ↑ , ↑ , Введите , чтобы выполнить последний запрос до make. из истории.

Основным преимуществом REPL является его интерактивность:

• Вы можете поиграть с аргументами.

• Переход к отладке или трассировке (как в командной строке, так и в графическом ) очень прост.

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

• Вы можете в интерактивном режиме выбрать, сколько замен вы хотите увидеть для цели, которая будет достигнута несколько раз.

• Очевидно, что после последнего результата, возвращенного недетерминированным предикатом, остается точка выбора, которую трудно наблюдать иначе. В этом случае false. печатается при возврате после последнего результата.

Если вам нужно сохранить тестовые вызовы, чтобы повторить их позже, создайте протокол (стенограмма или «журнал» интерактивного сеанса) и отредактируйте его, чтобы он стал сценарием или даже набором тестов ( увидеть ниже). Протокол представляет собой простой текстовый файл с escape-последовательностями для терминала, содержащий дословную копию того, что вы видите во время интерактивного сеанса. Просмотрите протокол, используя cat protocol.txt в Linux (и других * NIX) или type protocol.txt в Windows.

Если интерактивность не требуется, выполняет тестовые вызовы из командной строки неинтерактивно . Давайте проверим CLP (FD) пример факториала n_factorial/2, сохраненный в factorial.pl (не забудьте добавить :- use_module(library(clpfd)). при копировании кода):

$ swipl -q -t "between(0, 9, N), n_factorial(N, F), format('~D   ', F), fail." factorial.pl
1   1   2   6   24   120   720   5,040   40,320   362,880

В Windows вам может потребоваться указать полный путь к swipl.exe, поскольку его нет в переменной PATH, вероятно.

Если вызов всегда один и тот же, вы можете сохранить его в сценарии оболочки или Makefile (run будет хорошим именем для цели).

В вашем текущем рабочем процессе тестирования функций в C вы создаете новую программу и вызываете тестируемую функцию из ее точки входа (main function). Сценарии пролога также могут иметь точку входа. См. library(main). Пролог не требует компиляции, поэтому вы можете просто вызвать скрипт (./test.pl) без вызова Make сначала.

Для более крупных проектов вы можете создать менее специализированный набор тестов. Необходима структура модульного тестирования , как PlUnit Его использование выходит за рамки этого ответа; см. документацию.