Решение для запуска REPL приложения

[vak]

Я придумал решение для запуска REPL приложения, упомянутое в предыдущем посте. Напомню формулировку: есть интерактивная процедура на Си++ со следующим интерфейсом.

void application(std::istream &input, std::ostream &output);

Процедура работает в стиле REPL: берет ввод из входного потока, обрабатывает, выдаёт результат в выходной поток и ждёт следующего ввода. Мы хотим запустить эту процедуру из нашей программы на Си++, посылать ей команды и получать результат. Это, в частности, полезно для автоматического тестирования. Примерно так:

send("foo\n");
std::string reply = receive();
REQUIRE(reply == "bar\n");

Решение выглядит в виде класса Interact и работает следующим образом:

#include "interact.h"

Interact session(application);
REQUIRE(session.receive() == "Hello!\n");

session.send("foo\n");
REQUIRE(session.receive() == "bar\n");

Исходники можно взять на Гитхабе: https://github.com/sergev/interact

• interact.h
• interact.cpp
• test.cpp

Реализация должна быть понятна из комментариев.

Comments

[ircicq]

Увидел, что Вы не используете "override specifier" ( https://en.cppreference.com/w/cpp/language/override)
В старом C++ его не было, а в других языках он обязателен.

Очень советую, помогает избежать ошибок из-за опечатки в имени метода или изменении типа аргумента.

[archaicos]

Ещё const полезен.

[vak]

Точно, добавлю override для virtual underflow() в следующей правке.
А const функций здесь не имеется.

[spamsink]

Класс!

[vak]

Вот теперь я могу автоматизировать поиск оптимального алгоритма посадки на Луну. :)

[spamsink]

Ещё можно так: сделать обёртку, чтобы при неудаче программа завершалась нормально, а при удаче, наоборот - крэшилась, и напустить на это дело fuzzing. :)

[vak]

Я не проверял, что тут происходит с exceptions. Позже поcмотрю.

Посадка посредством fuzzing это будет прикольно!

[spamsink]

Слишком простой алгоритм; за миллион с лишним прогонов нашлось меньше сотни разных путей выполнения, фаззингу не за что зацепиться. Хотя кратчайший ввод для достижения результата всего 20 байт: "\ntv0\n200\nt:0\n149\n20\n".

[vak]

Ого! Всего шесть команд. Такое без фаззинга вовек не найти.
А можешь отыскать такие же короткие решения для всех уровней, от 0 до 9?
Хотя для уровня 0 его нету, как я догадываюсь.

Мне нужен набор тестов с более-менее приличным покрытием, чтобы начать переписывать на Rust.

[spamsink]

Это было без фаззинга, моей программой. Всегда можно вручную заменить последовательность одинаковых команд на увеличенный интервал, лишь бы ASCII-диапазона хватило. В данном случае повезло, что нужно было ровно 70 секунд и на свободное падение, и на торможение.

Это решение годится для большинства уровней (кроме 1 и 2, если не ошибаюсь).

[vak]

А я надеялся, случайный поиск нас спасёт. :)

[juan_gandhi]

Ну это странный дизайн. А если я еще раз receive() вызову? Или это FSM, и каждый send изменяет статус, а потом receive возвращает аутпут в этом статусе? Не очевидно. По идее, это должна быть функция: вход -> выход, без всякого там state.

[vak]

Вызвать второй раз receive можно, но результат будет пустой. Ведь это диалоговое приложение: если вы ничего не ввели (нет send), не будет и вывода. Вы же в курсе, как работает REPL в Scala.

[juan_gandhi]

Ну в варианте send/receive это уже не выглядело как repl.

Так у нас же функция, так? Ну и смотреть на это как на функцию.

[vak]

Функция в терминологии Си, возвращающая void. В терминах Паскаля это процедура.

[juan_gandhi]

Я в чисто научном смысле. Как происходит обмен, не столь важно. Важно, что есть вход, и есть выход, и нет никакого внутреннего состояния.

[vak]

Чисто в научном смысле диалоговая процедура есть дискретный ряд функций:

f1(x1)
f2(x1,x2)
f3(x1,x2,x3)
...
fN(x1,x2,...,xN)

Здесь x1 - первый ввод, x2 - второй ввод и так далее.

Результат после ввода xN зависит как от xN, так и от всех предыдущих вводов.

Функция на каждом шаге тоже разная.

[juan_gandhi]

О, т.е. есть State. Ну окей. Можно рисовать как (S,I) => (S,O)

[vak]

Да, но надо учесть, что x2...xN тоже в свою очередь есть функции от предыдущих вводов и выводов:

x2 = g1(x1,f(x1))
x3 = g2(x1,x2,f1(x1),f2(x1,x2))

и так далее. Здесь g1(), g2() и т.д. есть реакция юзера на поведение процедуры.

То есть имеем два дискретных ряда функций со взаимной зависимостью.

[juan_gandhi]

Э не. Это тест будет генерировать в зависимости - если такой тест. Или такой юзер. Но для тестирования собственно функциональности такая гипотеза вредна.

[vak]

Это смотря с какой стороны глядеть. :)
Мы можем тестировать application, а можем тестировать сам тест.

Старая программистская шутка: тестирование есть процесс поиска ошибок в тестах.

[vak]

Причём процедура диалоговая, развёрнутая во времени. Как сварливая баба: ты ей слово, она тебе два.

[vlkamov]

> void application(std::istream &input, std::ostream &output);

> берет ввод из входного потока, обрабатывает, выдаёт результат в выходной поток и ждёт следующего ввода

Задумался о тупиках развития машинных языков. Второй вариант компилировался бы не хуже, а по понятности на 2..3 порядка лучше.