vak | Драйв-тестим консольное приложение

Навеяло недавним достижением

spamsink: восстановлением исходников игры "Посадка на Луну" с БЭСМ-6.

https://github.com/besm6/bega-re/blob/master/landing.pas

Пусть у нас есть диалоговое приложение на Си++ с текстовым интерфейсом. Приложение запрашивает построчный ввод из std::cin и выдаёт результаты на std::cout. Условно говоря, вызов выглядит следующим образом:

application(std::cin, std::cout);

Схематично, работает оно так:

void application(std::istream &input, std::ostream &output)
{
    output << "something\n";

    while (!input.eof()) {
        std::string line;
        getline(input, line);

        std::string result = something(line);
        output << result;
    }
}

Теперь стоит задача покрыть имеющуюся реализацию тестами. Я ж теперь адепт TDD. Хочется иметь возможность делать тесты (с применением Catch) вида:

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

Как бы вы стали решать эту задачу? Я имею в виду, как средствами Си++ привинтить одно к другому? Чтобы, не модифицируя исходники application(), вызывать и тестировать её из Catch?

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

Традиционно такие штуки принято делать через Expect, но выглядит такой подход слишком громоздко. Лучше найти решение средствами самого языка Си++.

Threaded | Top-Level Comments Only

From:

juan_gandhi

Ничо не понимаю. Казалось бы, делов-то: делаем в тесткейсах разные стримы из строк, и проверяем, шо она мне сказала. Окей, предположим, эта апликаци я вообще отдельно. Ну так стартуем ее, подавая на вход наши тесткейсы и забирая аутпут.

И чо?

From:

vak

Хорошо, мы её стартуем и подаём на вход - что? Ведь не std::cin и std::cout, наверное.

From:

spamsink

Ну есть же разнообразные stringstreams, причём им можно буфера на ходу переключать. Мы этим регулярно пользуемся.

From:

vak

Ну да, примерно в ту степь. Есть у тебя готовое решение?

From:

ircicq

application() в данном случае - это REPL.
В Unit-тестах надо вызывать внутренние функции something().

А если речь идёт о тестировании целого приложения, то вызвать его в отдельном процессе с редиректом STDIN, STDOUT в Pipe.
И в тестах вызывать что-то вроде:
Verify(pipeOut, pipeIn, "some input", "expected output").

From:

vak

Это и есть решение через Expect. Оно вполне работает, но навороты выглядят излишними. Приложение в отдельном процессе, устройство псевдо-терминал, вот это всё.

From:

vak

Да, в функциональных и скриптовых языках такое приложение часто называют REPL. Тогда задачу можно переформулировать как запуск REPL средствами Си++.

Edited Date: 2020-08-13 00:57 (UTC)

From:

ex0_planet

Как уже справедливо заметили, это не юнит-тесты. Это, в лучшем случае, — интеграционные. Для юнит тестов мокается всё что возможно, после этого вызывается минимально возможный черный ящик, который и хотим протестировать.

From:

juan_gandhi

Так это, из строки у вас там нельзя стрим сделать, что ли? Это как-то уж больно было бы странно. Это если мы можем вызвать функцию. А нет - так через ОС вызвать эту хрень и приклеить stdio и stdout. На джаве элементарно.

From:

vak

Как назвать - дело последнее. Не интеграционные, потому что тут ничто ни с чем не интегрируется. Можно назвать функциональными тестами. Главное убедиться, что что игра не сломалась в процессе рефакторинга. Я собираюсь переписать её на другой язык.

From:

vak

Можно стрим из строки, есть std:stringstream для этого. Но тут ведь диалог нужен. Не просто заслать ведь ввод и поймать весь вывод.

Вызывать через ОС - это можно, называется Expect. Но выходит из пушки по воробьям.

From:

juan_gandhi

Ха, много не надо. Для каждого кейса стрим с одним кейсом, и выход соответственно. А иначе корутины присобачивать... в джаве это можно, но нудно.

From:

vak

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

Корутины решают задачу, да. Вот я и ищу, наверняка кто-то сделал уже.

From:

spamsink

Не для тестирования. У нас, например, используется фальшивый streambuf, который ничего не буферизует, а только SHA считает - ради инкрементной компиляции. В твоем случае можно сделать класс над streambuf, в котором будет вся умность, и дать его обоим стримам.

From:

vak

Как сделать я знаю. Streambuf и std::async. На самом деле у меня уже есть работающее решение, причешу - выложу.

From:

spamsink

Я в данном случае не вижу необходимости в async. Общий streambuf для двух стримов оказывается моделью внешнего мира; получается эдакая инверсия контроля.

From:

vak

Не верю, покажи в действии.

From:

norian

коты для небольших проектов юзают тестовые классы для юнитов

внизу :

class EgLocationTests
{
public:

EgDataNodesType testDataNodes;

bool testCreateLocations();

bool testAddLocations();

bool testLoadLocationsData();

void testShowResult(bool res, const QString &theMessage)
{
if (res)
{
qDebug().noquote() << "PASS" << theMessage;
}
else
{
qDebug().noquote() << "FAILED" << theMessage;
}
}
};

наверху:

tmpRes = attrTests.testCreateAttributes();
res = res && tmpRes;

tmpRes = attrTests.testAddAttributes();
res = res && tmpRes;

tmpRes = attrTests.testLoadAttributes();
res = res && tmpRes;

if (res)
qDebug() << "\nAll tests PASSED\n";
else
qDebug() << "\nSome tests FAILED\n";

дальше можно запускать или лапгами или каким-нть скриптом и парсить на "FAIL"

бтв, а во что оборачивать чтобы сорцы на дриме нормально показывались ?

Edited Date: 2020-08-13 07:04 (UTC)

From:

spamsink

#include <iostream>
#include <streambuf>
#include <queue>

class Feedback : public std::streambuf {
    std::queue<char> q;
    char c;
public:

    Feedback() : std::streambuf() {
        setp(0, 0);
        setg(0, 0, 0);
        for (auto c : "1 1 ")
            if (c) q.push(c);
    }
    int underflow() {
        c = q.front();
        q.pop();
        setg(& c, & c, & c+1);
        return c;
    }
    int overflow(int c) {
        std::cout << char(c);
        q.push(c);
        return 0;
    }
};

void fib(std::istream & in, std::ostream & out) {
    int a, b;
    in >> a;
    for (int i = 0; i < 20; ++i) {
        in >> b;
        out << a + b << ' ';
        a = b;
    }
    out << '\n';
}

int main() {
    Feedback fb;
    std::istream in(&fb);
    std::ostream out(&fb);
    fib(in, out);
}

Edited (краткость) Date: 2020-08-13 07:40 (UTC)

From:

ircicq

Если средствами C++, то надо написать свою реализацию std::streambuf
и инициализировать ей std::istream, std::ostream с которыми вызовете application()

P.S. sorry, увеидел что уже ниже написали

Edited Date: 2020-08-13 07:29 (UTC)

From:

caztd

Здесь решение для google mock:
https://stackoverflow.com/questions/36119525/google-mock-mock-fstream-object-and-control-of-execution-in-test

Наверняка можно аналогично и для Catch смастерить.

From:

vak

Красиво, да. Надо будет перенять на будущее.

Но я не вижу, как этот подход решает поставленную задачу. Попробуй запустить landing.cc, посылая ввод через send() и принимая вывод через receive().

Edited Date: 2020-08-13 21:55 (UTC)

From:

vak

Я ставлю

<blockquote><pre>
code
</pre></blockquote>

From:

vak

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

From:

norian

коты для небольших проектов юзают тестовые классы для юнитов

внизу :

class EgLocationTests
{
public:

    EgDataNodesType testDataNodes;

    bool testCreateLocations();

    bool testAddLocations();

    bool testLoadLocationsData();

    void testShowResult(bool res, const QString &theMessage)
    {
        if (res)
        {
            qDebug().noquote() << "PASS" << theMessage;
        }
        else
        {
            qDebug().noquote() << "FAILED" << theMessage;
        }
    }
};

наверху:

    tmpRes = attrTests.testCreateAttributes();
    res = res && tmpRes;

    tmpRes = attrTests.testAddAttributes();
    res = res && tmpRes;

    tmpRes = attrTests.testLoadAttributes();
    res = res && tmpRes;

    if (res)
        qDebug() << "\nAll tests PASSED\n";
    else
        qDebug() << "\nSome tests FAILED\n";

дальше можно запускать или лапгами или каким-нть скриптом и парсить на "FAIL"

Edited Date: 2020-08-13 21:55 (UTC)

From:

norian

ага, тхенкс, так лучше видно

From:

caztd

Нужно же что-то вроде?

MyStreamMockClass mock;
MyAppClass app(mock); 
EXPECT_CALL(mock, GetInputString()).WillOnce(Return("input"));
std::string reply = app.receive();

Конечно вам нужен свой stream-interface wrapper так как ifstream.get() не виртуальный метод.

From:

vak

Но ведь нет никакого MyAppClass. Есть просто функция:

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

From:

vak

Да, но как приспособить это к запуску вышеуказанного REPL приложения?

From:

spamsink

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

Interact world;
world.send("foo\n");
application(std::istream(& world), std::ostream(& world));
std::string reply = world.receive();
REQUIRE(reply == "bar\n");

From:

vak

Так можно, если _весь_ ввод и _весь_ вывод статичный и известный заранее. Но приложение ведь диалоговое, и хочется иметь возможность реагировать на его вывод и вычислять нужный ввод. То, что ты делаешь в tries.cc.

From:

caztd

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

Или вам нужно менять ввод в зависимости от вывода?

From:

vak

Конечно нужно менять ввод в зависимости от вывода. Приложение-то диалоговое.

From:

caztd

Ну просто редко кто такую логику в unit test вставляет.
Если это тестовое приложение, тогда моки не помогут,
нужeн pipe или streambuf, как предложили выше.
Что-то типа такого:
https://stackoverflow.com/questions/28356629/connecting-two-streaming-functions-c

From:

spamsink

Вот объект world класса Interact и будет этим динамически заниматься после запуска application. Если угодно, внутри этого класса send эквивалентен вставке аргумента в очередь "ввода", а receive - доставанию результата из очереди "вывода". Из моего примера это должно вытекать.

From:

vak

Вот да, что-то типа такого и ищу.

From:

vak

Ты пытаешься вывернуть тест наизнанку. Событийная архитектура получается, не самый изящный способ делать тесты. Должно быть проще.

From:

vak

Вот тут смотри: https://vak.dreamwidth.org/664590.html

From:

norian

йа бы использовал адаптер - функция получает потоки как аргументы, а более верхний уровень либо назначает стандартные, либо подставляет кастомные для тестирования

а, ну собсно оно так уже написано (на третий день коты посмотрели на топик, ага), просто дёргать снаружи со своими стримами и сравнивать результаты с ожидаемыми

Edited Date: 2020-08-14 09:46 (UTC)

From:

norian

как-нть так

#include iostream
#include sstream

using namespace std;

void application( istream& input,  ostream &output)
{
    output << "Start" << endl;

    ostringstream local_str;
    local_str << input.rdbuf();

    output << local_str.str() + "_test";
}

int main() {

    stringstream in_str;
    stringstream out_str;

    in_str << "Hello";

    application( in_str, out_str );

    if (out_str.str() == "Start\nHello_test")
        cout << "PASS" << endl;
    else
        cout << "FAIL " << endl;

    return 0;
}

с функцией из топика тоже будет работать, только шаблон результата поменять на фактический
и третья строка не нужна, лишний копипаст был

Edited Date: 2020-08-14 14:15 (UTC)

From:

dememax

> Я имею в виду, как средствами Си++ привинтить одно к другому? Чтобы, не модифицируя исходники application(), вызывать и тестировать её из Catch?
Лучше найти решение средствами самого языка Си++.

Вот, хоть режьте меня, но я не понимаю, зачем в этом случае Си++.
Если я правильно понял, тестировать надо, что при определённом вводе есть определённый вывод.

> Традиционно такие штуки принято делать через Expect, но выглядит такой подход слишком громоздко.

А не боимся, что с Си++ может быть ещё более громоздко?

From:

vak

Глаза боятся, руки делают. :)

Если основной софт на Си++, то и тестовое хозяйство к нему логично вести на Си++.

Вовсе неплохо получилось, вот пример теста:

TEST_CASE("hello", "[interact]")
{
    Interact session(hello);
    auto reply = session.receive();

    SECTION("start") {
        REQUIRE(reply == "Hello!\n");
    }
    
    SECTION("exit") {
        session.send("q\n");
        reply = session.receive();
        REQUIRE(reply == "Bye!\n");
    }
        
    SECTION("reply") {
        session.send("foo\n");
        reply = session.receive();
        REQUIRE(reply == "Got: foo\n");
    }
}

Решение можно посмотреть здесь: https://vak.dreamwidth.org/664590.html

From:

dememax

:-)

Система конфигурации сбрки - тоже на Си++?
И система сборки - на Си++?
Логично же, нет?!
;-)

Тогда и

void next_step(const std::string & sec_name, 
        const std::string & cmd,
        const std::string & answer)
{
    SECTION(sec_name) {
        session.send(cmd + "\n");
        reply = session.receive();
        REQUIRE(reply == answer + "\n");
    }
}

неплохо бы ввести.

Threaded | Top-Level Comments Only

Профиль

Посетители