AutoFixture always generate the same TimeZoneInfo

[TrymBeast]

Hello,

I have found yesterday that AutoFixture always generates the same TimeZoneInfo, I had to implement one specimen builder to get a new one from the available TimeZoneInfos in the system.

Is this something that should be bundled in AutoFixture?

[zvirja]

Hi,

This behavior happens because TimeZoneInfo doesn't have a public constructor. Therefore, AutoFixture tries to find first static method/property which returns TimeZoneInfo instance to support the Factory Method pattern. In our case it finds the TimeZoneInfo.Local property, which always returns the same time zone.

To get a random time zone for each time, add the following customization to your fixture:

fixture.Customizations.Add(new ElementsBuilder<TimeZoneInfo>(TimeZoneInfo.GetSystemTimeZones()));

That should help 😉

[Kralizek]

@zvirja do you think it would make sense to add registrations like this one to the base setup?

I have this one

fixture.Customizations.Add(new ElementsBuilder<Encoding>(Encoding.GetEncodings().Select(e => e.GetEncoding())));

If we look it from a mathematical point of view, we're telling AutoFixture what's the space of valid values of these types…

[TrymBeast]

@zvirja I didn't knew about the ElementsBuilder, the only difference i see from my implementation is that the ElementsBuilder returns a random TimeZoneInfo while I return sequentially, but for the sake of tests it doesn't really matter. I will use the ElementsBuilder, thanks!

But my intention with this issue is more like what @Kralizek is asking, is this something that should already be configured in the base setup of AutoFixture?

[zvirja]

@Kralizek @TrymBeast I don't mind adding this to the library, so it's supported natively. The only concern I have whether it might break the existing tests, as people might already rely on the TimeZoneInfo and Encoding values which are returned. Probably, it should be postponed till v5 to run it safely. @moodmosaic What do you think?

Additionally, we should consider implementing it in a way that it doesn't affect fixture construction performance. The call to TimeZoneInfo.GetSystemTimeZones() might be quite expensive. It would be especially a pity, if we never actually need to construct the TimeZoneInfo instances (as it usually happens). Likely, we should add some laziness around that - but should be investigated when it's implemented.

[Kralizek]

@zvirja Aren't registrations already evaluated only in case of need?

[moodmosaic]

@zvirja, generated TimeZoneInfos shouldn't be always the same, so I'd label it as a bug and fix it in this version rather than waiting for vNext.

[zvirja]

@moodmosaic Thanks for the feedback! Did as you suggested. Hope people don't rely on this behavior in their tests 🤞

[moodmosaic]

don't rely on this behavior in their tests

I've rarely seen someone rely on a bug 😊