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

Discussion: Use of data providers in test classes #755

Open
mk-mxp opened this issue Jun 17, 2024 · 1 comment
Open

Discussion: Use of data providers in test classes #755

mk-mxp opened this issue Jun 17, 2024 · 1 comment

Comments

@mk-mxp
Copy link
Contributor

mk-mxp commented Jun 17, 2024

Using data providers is a convenient way to reduce code and increase coherence inside the test classes. Having the test case data separated from the test code itself follows best practices and is encouraged in professional use.

But in Exercism it raises a bunch of problems:

  • In the test runner, data provider based tests must be handled separately
  • PHPUnit converts values to a different format (not like PHP code) to emit them in test names
  • For beginners, even when working with the CLI, the test data is not intuitively connected to the test code
  • It is much more inconvenient to connect UUIDs of practice exercises to test values in a data provider
  • In the test generator, data providers might add more complexity and so may not be used

So I would prefer to convert existing data provider based tests to flat test methods and not add new exercises with data providers.

Any opinions about that?

@tomasnorre
Copy link
Contributor

As there are limited tests, even thought they are more or less always looking the same. I'm OK with not using dataproviders, if that improves user experience in Online Editor.

I would always reach for data providers personally in a private project, with descriptive keys.

But I think user experience is key here. We will not need to tweak tests that often.

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

No branches or pull requests

2 participants