Как отлаживать модульные тесты Rust в Windows? - PullRequest
0 голосов
/ 05 июня 2018

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

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

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

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

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

Ответы [ 2 ]

0 голосов
/ 06 июня 2018

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

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

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

#[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-3cf890b7dd22d797

running 3 tests
test test_complex ... FAILED
test test_false ... FAILED
test test_true ... ok

failures:

---- 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:5


failures:
    test_complex
    test_false

test result: FAILED. 1 passed; 2 failed; 0 ignored; 0 measured; 0 filtered out

error: test failed, to rerun pass '--bin foo'

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

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

0 голосов
/ 05 июня 2018

Модульные тесты Rust скомпилированы как отдельные двоичные файлы, что означает, что вы отлаживаете их точно так же, как и любой другой двоичный файл .После компиляции они располагаются по адресу ./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",
}

Рабочая

VS Code debugger running on a test

Windbg

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

cargo test --no-run

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

Windbg on Rust test


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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...