Как отладить тесты модуля Rust в Windows?

Riduidel спросил: 12 мая 2018 в 05:14 в: windows

Я разрабатываю код для проблем с кодированием, используя VS Code в Windows с Rust и инструментальной цепочкой Visual Studio.

Я нашел несколько руководств, объясняющих, как отлаживать исполняемый файл, сгенерированный с помощью cargo build, лучшим из которых является Debug Rust на Windows с кодом Visual Studio и отладчиком MSVC.

Однако, когда я сталкиваюсь с проблемами, я склонен писать модульные тесты (я сделал это в Java, JavaScript, Ruby, ...), который затем отлаживаю. К сожалению, я не могу найти способ сделать это в Rust. Как настроить среду для отладки моих тестов?

Я не говорю о добавлении операторов println! в мои тесты, поскольку я уже знаю, как это сделать. Я также не говорю о добавлении новых утверждений, потому что они находятся в тесте, а не в проверенном коде.

Я хочу использовать VS Code Debugger для кода , называемого по моему тесту.

hellow ответил: 12 мая 2018 в 04:44

Что вы понимаете под "debug" println! debug? Прикрепление отладки отладки?

Riduidel ответил: 13 мая 2018 в 09:23

@hellow Я говорю о прикреплении отладчика, потому что println! - простая трассировка.

2 ответа

Shepmaster ответил: 13 мая 2018 в 02:09

Единичные тесты ржавчины компилируются как отдельные двоичные файлы, что означает, что вы отлаживаете их точно так же, как и любые другие двоичные файлы . После компиляции они находятся в ./target/debug/$name-$hash.

Код Visual Studio

Здесь приведены измененные версии файлов конфигурации VS Code, которые позволяют мне отлаживать модульный тест.

tasks.json

{
    "type": "shell",
    "label": "cargo test build",
    "command": "cargo",
    "args": [
        "test", "--no-run"
    ],
    "problemMatcher": [
        "$rustc"
    ]
}

launch.json

{
    "name": "Run Test Debugger",
    "type": "cppvsdbg",
    "request": "launch",
    "program": "${workspaceFolder}/target/debug/buggin-70708b3916187eeb.exe",
    "args": [],
    "stopAtEntry": false,
    "cwd": "${workspaceFolder}",
    "environment": [],
    "externalConsole": true,
    "preLaunchTask": "cargo test build",
}

Работа

Windbg

Создайте свои тесты:

cargo test --no-run

Откройте встроенный исполняемый файл в Windbg и откройте исходный файл.

Поиск хеша - самый неприятный аспект. Лучшее решение, о котором я знаю, это написать небольшой скрипт, который создает тесты, а затем находит тестовый исполняемый файл, основанный на том, что является самым новым. Мои способности Powershell не соответствуют задаче, и я не знаю, как напрямую интегрировать ее с VS Code или Windbg.

Есть открытые проблемы для Cargo, которые помогают идентифицировать файл:

производят детерминированные имена файлов для build --test и test --no-run (# 1924)

Позволяют запускать двоичные файлы, созданные непосредственно товаром (# 3670)

hellow ответил: 13 мая 2018 в 06:21

Вы можете либо использовать отладку println!

#[test]
fn test_false() {
    println!("This test is not OK");
    assert!(1 == 2);
}

Или использовать макрос assert для предоставления настраиваемых сообщений.

#[test]
fn test_complex() {
    let a = vec![1, 2];
    let b = vec![3, 4, 5];
    assert!(a.len() == b.len(), "Mismatch between vec lenghts! ({} - {})", a.len(), b.len());
}

Это приведет к

cargo test
    Finished dev [unoptimized + debuginfo] target(s) in 0.00s
     Running target/debug/deps/foo-3cf890b7dd22d797running 3 tests
test test_complex ... FAILED
test test_false ... FAILED
test test_true ... okfailures:---- test_complex stdout ----
thread 'test_complex' panicked at 'Mismatch between vec lenghts! (2 - 3)', src/main.rs:21:5
note: Run with `RUST_BACKTRACE=1` for a backtrace.---- test_false stdout ----
This test is not OK
thread 'test_false' panicked at 'assertion failed: 1 == 2', src/main.rs:14:5failures:
    test_complex
    test_falsetest result: FAILED. 1 passed; 2 failed; 0 ignored; 0 measured; 0 filtered outerror: test failed, to rerun pass '--bin foo'

Примечание. Третий, хороший случай также содержит println!, но он не будет отображаться, потому что тест будет успешным.

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