Continuation of https://github.com/serde-rs/serde/pull/2460 in new repo.

Instead of changing assert_de_tokens_error I've added a new function which does the same, but outputs deserialized value in case of failure

I found, that there are two ways to express how the enum should be serialized:

#[derive(Deserialize, Serialize, Debug, PartialEq)]
enum Enum {
  Unit,
}

assert_tokens(
  &Enum::Unit,
  &[
    Token::Enum { name: "Enum" },
    Token::Str("Unit"),
    Token::Unit,
  ],
);

assert_tokens(
  &Enum::Unit,
  &[
    Token::UnitVariant { name: "Enum", variant: "Unit" },
  ],
);

Surprisely, both of that asserts are passed, although is is obvious that serialization can give only one of that results. After examining code I've found this very confusing check: https://github.com/serde-rs/serde/blob/0c6a2bbf794abe966a4763f5b7ff23acb535eb7f/serde_test/src/ser.rs#L184-L190 That means that tester will change it's behavior depending on the testing data, that is not expected from the testing tool.

So the questions are:

• why both variants are exist?
• what one should use?
• isn't it necessary to keep only one of them?

By forwarding things like deserialize_bool to deserialize_any, the deserialize_bool behavior can then deserialize a string, for example. This is unexpected and lets through a ton of stuff that, in my opinion, shouldn't be. serde_test is for testing, not general purpose use, so it should remain strict in what it accepts. deserialize_bool should reject everything other than true or false, unless there's some reason I'm missing?

I found that test in the sources: https://github.com/serde-rs/serde/blob/e6f086d85edfa3bde3f4486142301962ec5f1c8c/test_suite/tests/test_annotations.rs#L1824-L1925

Can anybody explain, why deserialize tokens don't match the serialized one (Token::Some is missed)? For me that seems as an error, because non-flatten option can't be deserialized in the same manner:

use serde::Deserialize;
use serde_test::{assert_de_tokens, Token};

#[derive(Debug, PartialEq, Deserialize)]
struct Outer {
  #[serde(flatten)]
  inner: Inner,
}

#[derive(Debug, PartialEq, Deserialize)]
struct Inner {
  option: Option<u64>,
}

/// Failed with
/// tokens failed to deserialize: invalid type: integer `2`, expected option
#[test]
fn ordinal() {
  assert_de_tokens(
    &Inner {
      option: Some(2),
    },
    &[
      Token::Map { len: None },
      Token::Str("option"),
      Token::U64(2),
      Token::MapEnd,
    ],
  );
}
/// Success (!?)
#[test]
fn flatten() {
  assert_de_tokens(
    &Outer {
      inner: Inner {
        option: Some(2),
      },
    },
    &[
      Token::Map { len: None },
      Token::Str("option"),
      Token::U64(2),
      Token::MapEnd,
    ],
  );
}

I had a hard time finding out about how to use assert_de_tokens_error in combination with types having both readable and compact representation.

If one simply uses assert_de_tokens_error::<Foo> for a type Foo with both readable and compact representation, the following error message is provided:

Types which have different human-readable and compact representations 
must explicitly mark their test cases with `serde_test::Configure`

This makes sense in general but isn't really that helpful.

It took me way too long to realize that the correct calls to achieve this are assert_de_tokens_error::<Compact<Foo>> and assert_de_tokens_error::<Readable<Foo>>.

This, again, makes sense but isn't that obvious, especially given the original error message.

It would be nice to provide some examples for this use case in the documentation of assert_de_tokens_error.