openlang

Как интеграционным тестам запустить бинарник другого крейта рабочего пространства?

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

Структура рабочего пространства такая:

workspace/
├── rillmere_probe/
│   └── tests/check.rs
└── rillmere_exec/
    ├── src/lib.rs
    └── src/main.rs

Крейт rillmere_probe указывает rillmere_exec в качестве dev-dependency. Его тестам также нужно запускать бинарник rillmere_exec. Раньше всё работало. Но изменение build-layout-v2 в rust-nightly переставило файлы, и assert_cmd-2.1.3 больше не находит исполняемую цель rillmere_exec. Диагностика assert_cmd-2.2.2 понятнее: CARGO_BIN_EXE_rillmere_exec is unset. После этого я засомневался, поддерживает ли assert_cmd такой сценарий вообще. Не думаю, что никто больше с этим не сталкивался. У кого-нибудь получилось решить проблему?

Переведено с английскогоПоказать оригинал

Разговор продолжается 4

Следуя доводам
  1. Ссылка на ответ

    Боюсь, выбор ограничивается такими вариантами

    -

    Перенесите по возможности всё из main.rs в lib.rs (насколько знаю, серьёзные проекты обычно уже так устроены). Пусть main.rs только вызывает этот код. Можно даже оставить в main.rs один однострочный вызов :v, чтобы другому проекту было проще использовать код

    -

    Тестируйте вручную, собирая исполняемый файл, запуская его и читая ошибки через std::command

    Переведено с английскогоПоказать оригинал
  2. Ссылка на ответ

    О, отлично! Это именно то, что я искал. Требование nightly для этого конкретного интеграционного теста меня устраивает. Но хотелось бы, чтобы остальная часть крейта по-прежнему собиралась стабильным Rust. Значит, осталось понять, как пропускать этот тест при стабильном компиляторе. Возможно, придётся вынести весь тест в отдельный крейт. Не идеально, но сойдёт. Мне это нравится больше, чем перенос всего содержимого бинарника в библиотеку.

    Переведено с английскогоПоказать оригинал
  3. Ссылка на ответ

    Требование nightly для этого конкретного интеграционного теста меня устраивает

    artifact dependencies являются нестабильной возможностью cargo, а не компилятора rustc.

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

    поэтому использование artifact dependencies требует отдельного пакета (точнее, отдельного рабочего пространства) для крейта интеграционного теста, с собственным Cargo.toml, отличным от манифестов остальных пакетов.

    Переведено с английскогоПоказать оригинал

Другие стороны того же вопроса

  1. Уменьшение шума в консоли docker-compose

    Когда docker-compose up запускает все сервисы в моей среде разработки, несколько контейнеров выдают сотни и сотни строк. Можн…

    Ответы 3Последняя активность bash
  2. Можно ли создавать модули расширения Python на языке D вместо C?

    Похоже, D умеет компоноваться с C. Я хочу написать модуль расширения Python на D. Не упускаю ли я какую-то причину, по которо…

    Ответы 2Последняя активность d
  3. Объявлять плагины Micro через Nix?🤔

    В python можно написать так: Python.withPackages (q: with q; [ fastapi ]) Есть ли аналогичный механизм для редактора Micro? М…

    Ответы 3Последняя активность nix