Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make RandomizedTesting into a separate library #257

Closed
clambertus opened this issue Dec 25, 2019 · 1 comment · Fixed by #474
Closed

Make RandomizedTesting into a separate library #257

clambertus opened this issue Dec 25, 2019 · 1 comment · Fixed by #474

Comments

@clambertus
Copy link

clambertus commented Dec 25, 2019

We have ported the generators from RandomizedTesting that Lucene.NET needs to support its tests and added this code to the TestFramework (unlike Lucene), both as a static utility class and as extension methods. The generators we have now in the TestFramework are probably enough to cover most random testing use cases for end users.

That said, it would be useful for the .NET community at large if the random generators were made into a separate library so randomized test data can be easily generated without referencing the Lucene.NET test framework. The latest version of RandomizedTesting has more options for generating random data than what we have ported.

The library should be named after RandomizedTesting (possibly RandomizedTesting.Generators) so that someday if the test runner is also ported (see #264), there is a logical way to integrate it.

This task would make a great little project for anyone who wants to contribute to the Lucene.NET effort.

JIRA link - [LUCENENET-635] created by nightowl888

@clambertus clambertus added Lucene.Net.TestFramework testability up-for-grabs This issue is open to be worked on by anyone labels May 5, 2020
@NightOwl888 NightOwl888 added this to the Future milestone May 7, 2020
@NightOwl888 NightOwl888 modified the milestones: Future, 4.8.0-beta00015 Mar 15, 2021
@NightOwl888
Copy link
Contributor

I'm changing the priority of this because there are at least 3 different places where centralizing random generators would be useful:

Given the fact that these generators have evolved over time and don't likely have any breaking backward changes, porting the latest released version of the generators and their associated tests would probably be the right approach. Most likely any differences in behavior are bug fixes and important design changes that would be better to have than to not have.

In the case of benchmarks, using random generators is useful because it allows us to create repeatable benchmarks with large amounts of data without having to store the data in our repo.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants