Pourquoi ne pas println! travailler dans la Rouille des tests unitaires?

J'ai implémenté la méthode suivante et de test de l'unité:

use std::fs::File;
use std::path::Path;
use std::io::prelude::*;

fn read_file(path: &Path) {
    let mut file = File::open(path).unwrap();
    let mut contents = String::new();
    file.read_to_string(&mut contents).unwrap();
    println!("{}", contents);
}

#[test]
fn test_read_file() {
    let path = &Path::new("/etc/hosts");
    println!("{:?}", path);
    read_file(path);
}

Je lance le test de l'unité de cette façon:

rustc --test app.rs; ./app

Je pourrais également exécuter cette avec

cargo test

Je reçois un message disant que le test réussi, mais le println! n'est jamais affiché sur l'écran. Pourquoi pas?

InformationsquelleAutor ruipacheco | 2014-08-03

println rust

279

Cela se produit parce que la Rouille des programmes de test de masquer le stdout de la réussite des tests en vue de la sortie d'un test pour être rangé. Vous pouvez désactiver ce comportement, en passant par la --nocapture option binaire de test ou de cargo test:
```
#[test]
fn test() {
    println!("Hidden output")
}
```
Invoquant tests:
```
% rustc --test main.rs; ./main

running 1 test
test test ... ok

test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured

% ./main --nocapture

running 1 test
Hidden output
test test ... ok

test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured

% cargo test -- --nocapture

running 1 test
Hidden output
test test ... ok

test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured
```
Si les tests échouent, toutefois, leurs stdout sera imprimé, peu importe si cette option est présente ou non.
- Vous avez mentionné en passant le --nocapture option pour cargo test, mais le fret ne pas reconnaître ce drapeau pour moi (à l'aide de la dernière nightly de rustup.sh). Êtes-vous sûr que cela devrait fonctionner?
- en effet, il y a un problème sur que. En attendant, vous pouvez utiliser cargo test -- --nocapture, il devrait fonctionner.
- merci! aucun rapport avec cette question, mais qui m'a aussi aidé à comprendre comment obtenir cargo test [--] --bench à trop de travail!
- cargo test -- --no-capture ne fonctionne plus. J'obtiens l'erreur suivante: thread '<main>' panicked at '"Unrecognized option: \'no-capture\'."', ../src/libtest/lib.rs:249
- l'option est appelée nocapture, pas no-capture.
- Quelqu'un a trouvé comment imprimer lors du débogage de Code de Visual Studio sous windows? La tâche suivante n'a pas d'impression de la fenêtre contextuelle shell: "test de cargaison --no-run -- --nocapture" débogueur. Notez l'utilisation de la non-exécution de l'argument, bien qu'il ne semble pas faire une différence de toute façon. Tout ce que je vois est "en cours d'exécution 1 essai". Maladroit de l'outillage.
- Il est recommandé d'utiliser --package et --exact drapeau si vous avez une grosse base de code cargo test --package <package_name> <file_name>::<mod_name>::<test_name> -- --nocapture --exact.
InformationsquelleAutor Vladimir Matveev
67

TL;DR
```
$ cargo test -- --nocapture
```
Avec le code suivant:
```
#[derive(Copy, Clone, Debug, PartialEq, Eq)]
pub enum PieceShape {
    King, Queen, Rook, Bishop, Knight, Pawn
}

fn main() {
    println!("Hello, world!");
}

#[test]
fn demo_debug_format() {
    let q = PieceShape::Queen;
    let p = PieceShape::Pawn;
    let k = PieceShape::King;
    println!("q={:?} p={:?} k={:?}", q, p, k);
}
```
Puis exécutez la commande suivante:
```
 $ cargo test -- --nocapture
```
Et vous devriez voir
```
Running target/debug/chess-5d475d8baa0176e4

running 1 test
q=Queen p=Pawn k=King
test demo_debug_format ... ok

test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured
```
- cargo test -- --no-capture ne fonctionne plus. J'obtiens l'erreur suivante: thread '<main>' panicked at '"Unrecognized option: \'no-capture\'."', ../src/libtest/lib.rs:249
- Je me demande si ce problème github.com/rust-lang/cargo/issues/1377 est le problème?
- Comme cela a été souligné dans les commentaires précédents, l'option est --nocapture, pas --no-capture. Cependant, c'est tout à fait erreur évidente à faire étant donné la plupart de la ligne de commande conventions, nous avons tendance à venir à travers. J'ai simplement utilisé cette option exactement comme décrit dans la réponse à cette question de la rouille 1.1 (cargo 0.2.0) et cela a fonctionné exactement comme annoncé.
InformationsquelleAutor superlogical
6

Lors du test, la sortie standard n'est pas affiché. N'utilisez pas de texte de messages pour des tests, mais assert!, assert_eq!, et fail! à la place. La rouille de l'unité du système de test peut comprendre, mais pas des messages texte.

Le test que vous avez écrit va passer, même si quelque chose va mal. Voyons pourquoi:

read_to_endsignature de l'est
fn read_to_end(&mut self) -> IoResult<Vec<u8>>

Elle renvoie un IoResult pour indiquer le succès ou d'erreur. C'est juste un type de def pour un Result dont la valeur de l'erreur est un IoError. C'est à vous de décider comment une erreur doit être traitée. Dans ce cas, nous voulons que la tâche de l'échec, ce qui est fait en appelant la unwrap sur le Result.

Cela fonctionne:
```
let contents = File::open(&Path::new("message.txt"))
    .read_to_end()
    .unwrap();
```
unwrap ne doit pas être galvaudé bien.

InformationsquelleAutor A.B.
6

D'inclure des imprimés avec println!() et de garder les couleurs pour les résultats des tests, l'utilisation de la color et nocapture drapeaux dans cargo test.
```
$ cargo test -- --color always --nocapture
```
(version cargo: 0.13.0 tous les soirs)

InformationsquelleAutor nate

Vous devez vous connecter pour publier un commentaire.