Methods-Locales combinations throwing exceptions

[trdsolutions]

Please find attached a test file which can be integrated (added) to the test solutions and is ready to run, where (nearly) all methods for data generation are called for each supported locale (according to the documentation).

The tests demonstrates where exceptions are happing and unfortunatly there are a lot :-(.
Please don't see this with any anger. I really like and appreciate your effort and the package!

AllLocalizationTests.zip

[ManfredLange]

@trdsolutions Thank you for your feedback and opening this issue. The open-source community depends on contributions and filing and issue is such a contribution.

Thank you also for the source code. I'll definitely take it into consideration.

[ManfredLange]

@trdsolutions After having looked at the problem, I decided that it would be most useful to run each test for each locale, plus one that doesn't come out of the box to test that the package can use "en" as the fallback solution if needed.

NUnit has the concept of TestFixtureSourceAttribute that allows parameterizing fixtures. I'm exploring this option at the moment as it it appears that it would allow adding further data generators and methods while limiting the amount of code changes elsewhere.

[ManfredLange]

I just released Version 1.7.0 which fixes this issue for class AddressTests. More to follow.

Effectively, the tests in AddressTests are now executed for all locales except for 'no'. The file 'no.yml' is invalid. However, I don't intend to fix this since the locale files are a verbatim copy from https://github.com/faker-ruby/faker

[trdsolutions]

Thanks for your effort and thanks for the information regarding the NO locale.
My suggestion would be to exclude "no" from the supported locales and even remove the "no.yml" file from the package.
Someone who just starts using the package may have no notice about the invalidity of the file and so it might be weird to have it, but not being able to use it.
How do you see this?

(Or maybe other, than throwing an exception if "no" was set, just defaulting back to "en", with a warning log entry?)

[ManfredLange]

@trdsolutions I just released version 1.8.0 on nuget.org. This is expected to solve this issue. Unless I have overlooked something, all generators that make use of a locale file (usually embedded as a resource) are now tested for each of the built-in locales. As a result the number of tests has increased to a little over 10,000. This still doesn't guarantee absence of defects but hopefully resolves this issue.

As suggested by you, I also removed the locale file no.yml from the nuget package but kept it for the automated tests. The test ensures that an appropriate exeception is thrown if the locale file has an invalid format.

If you don't mind having a look and letting me know if this new release resolves the issues that you were observing. In my environment the tests you provided now pass after I commented out testing for locale no which is a locale for which the file format is invalid and needs to be fixed at the source (Ruby Faker Gem). Thank you!

In case I don't hear by 31 Dec 2020 I intend to close this issue as resolved.

[ManfredLange]

@trdsolutions Beyond the problems reported in this issue I found a few more problems with select locales. I just published version v1.9.0 at https://www.nuget.org/packages/RimuTec.Faker/ which I believe resolves those problems as well. In particular generator Name should now work for all built-in locales.

As mentioned before, I intend to close this issue as resolved on 31 Dec 2020 unless I hear otherwise.

[trdsolutions]

@ManfredLange
thanks for your work! From what I can see, all issues are solved 👍
Hope you had great christmas day and I wish you all the best for the next year!

[ManfredLange]

@trdsolutions Thank you for confirming that from perspective this issue has been resolved. Thank you again for reporting this issue. Your report was of great value in improving this nuget package.

Yes, thank you, I had a great Christmas and am now looking forward to 2021. All the best wishes to you, too!