Add ScrubNumericIds

[SimonCropp]

No description provided.

[fiseni]

The Id scrubbing unfortunately turned out to be a bit more peculiar. Unlike Guid/Date which are globally unique, auto incrementing database Ids are a bit weird.

Let me describe the setup and the problem.

• If you create the database per each test, then the current approach works and the output is stable.
• If you create the database per collection fixture or even class fixture, then:
  • If you run the tests for the whole collection, it's still deterministic and stable. You may re-run them and will succeed.
  • Once you have accepted the snapshots, if you run a specific test only, then you may get different results.
  • The opposite is true as well.

Sample

public class VerifySampleTests
{
    [Fact]
    public async Task Test1()
    {
        var customers = new List<Customer>
        {
            new() {
                Id = 1,
                Addresses =
                [
                    new() { Id = 1, CustomerId = 1 },
                    new() { Id = 2, CustomerId = 1 }
                ]
            },
            new() {
                Id = 2,
            }
        };
        await Verify(customers);
    }


    class Address
    {
        public int Id { get; set; }
        public int CustomerId { get; set; }
    }

    class Customer
    {
        public int Id { get; set; }
        public List<Address> Addresses { get; set; } = [];
    }
}

Imagine the customers are fetched from DB. If you run this test in isolation, this will output:

[
  {
    Id: Id_1,
    Addresses: [
      {
        Id: Id_1,
        CustomerId: Id_1
      },
      {
        Id: Id_2,
        CustomerId: Id_1
      }
    ]
  },
  {
    Id: Id_2
  }
]

If you run the whole test suite, the second customer for instance may have Id = 3 (depending what other tests have inserted), and will result to the following output.

[
  {
    Id: Id_1,
    Addresses: [
      {
        Id: Id_1,
        CustomerId: Id_1
      },
      {
        Id: Id_2,
        CustomerId: Id_1
      }
    ]
  },
  {
    Id: Id_3
  }
]

I created this gist. It's not a sophisticated approach, meddling into the serializer. But, this will always be stable and the output will be as follows (regardless of what Id has the second customer). It's scoped per model. Yes, in this case, the counter for Id_ is different for Customer and Address, but.. not important?

https://gist.github.com/fiseni/aa78e0b6c3e51d41e0683e227ddc297c

[
  {
    Id: Id_1,
    Addresses: [
      {
        Id: Id_1,
        CustomerId: CustomerId_1
      },
      {
        Id: Id_2,
        CustomerId: CustomerId_1
      }
    ]
  },
  {
    Id: Id_2
  }
]

PS. Perhaps I have more specific use-case. Folks may find this useful as it is.

EDIT: For context, after each test ofc I restore the db state to a predefined state. I can perhaps reseed the identity id in this process, and that would solve these inconsistencies.

[SimonCropp]

@fiseni i took another pass at this. can u review again?

[fiseni]

Lovely! Do you have some alpha channel? Once you release it, I can test it more thoroughly. But as far as I can see it looks great now.

PS. I was thinking about the last sentence in my previous comment. If I make the outputs deterministic, then I wouldn't need scrubber at all. So, this feature indeed saves me from the hassle. Thank you!

[fiseni]

@SimonCropp

I tested 31.16.0-beta.1 more thoroughly. The output is stable. I have two small notes:

• The snippets in the docs are missing. Perhaps some job failed.
• The default behavior, I think, is that if the properties have default values you're not serializing them at all to the output. With this feature enabled, all Id properties are serialized regardless if they have default values (e.g. Customer.Id = 0 to Customer_Id1, CustomerId = 0 to CustomerId_1, Address.CountryId = null to CountryId_null, etc). I don't mind this, but not sure if it will break existing tests for users. It's worth noting it.

[SimonCropp]

@fiseni

The snippets in the docs are missing. Perhaps some job failed.

sorry. that is the doc template. the produced doc is https://github.com/VerifyTests/Verify/blob/main/docs/numeric-ids.md

[fiseni]

Ahh my bad

[SimonCropp]

@fiseni no need to apologise.

The default behavior, I think, is that if the properties have default values you're not serializing them at all to the output. With this feature enabled, all Id properties are serialized regardless if they have default values (e.g. Customer.Id = 0 to Customer_Id1, CustomerId = 0 to CustomerId_1, Address.CountryId = null to CountryId_null, etc). I don't mind this, but not sure if it will break existing tests for users. It's worth noting it.

i think this is only if people opt in to ScrubNumericIds, so not an issue?

[fiseni]

Yes, that's true. But imagine folks may have a lot of dto models (not only entities) with Id properties. All current snapshots won't have them serialized if they have default values. Once they add the scrubber, they may get many failing tests (which may be confusing if they weren't expecting them there).

I mean it's not a problem at all. They should just accept all new snapshots. Sometimes I'm just over cautious :)