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

Use parameterized test #792

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

apupier
Copy link
Member

@apupier apupier commented Jul 19, 2022

precise test name is lost this way to have the more compact way of writing it.
Not sure what is the best. i'm wondering if the use case is clear enough when reading the value or we really need to provide a specific name. What do you think?

precise test name is lost this way to have the more compact way of
writing it.

Signed-off-by: Aurélien Pupier <[email protected]>
@joshiraez
Copy link
Contributor

joshiraez commented Jul 20, 2022

Using parameterized tests was my first jab at it but I disliked how it was done in JUnit

Ideally, if we are going the DDT way, it would be best to have "most of" the whole suite on the data driven part. So you'd have something like

[
       [<test_case_label>,[given],[expected]
]

So for example

[
      ['Works on empty YAML file', ['', FileType.YAML, beginningOfLastLine() (as a lambda, as you need the text I think)], [expectations]
]

Having it mixed is... I think it makes the tests harder to read, specially if it fails. Having all the tests following the same pattern is not bad and allows us to refactor to something like you did, but if we did that I'd like to go the whole way to make sure is consistent, readable and useful

One case where mixing it like this hurts readability is for a new user. Why do we test so many different things? What this input string aims to text? Can I remove it without using a use case? Which use case is affected? (Which has a simple solution by using labels but then you get half the tests with those labels and the others with their regular test names and you have to actually read the code to see in which part you are and figure it out... it just snowballs from there in my opinion)

A good example of what I'd like to do is on my blog: https://medium.com/@joshiraez/getting-creative-with-ruby-implementing-data-driven-testing-on-it-44f55b04683a. Right now the code is in the intermediate step but when trying to use parameterized I just didn't like I had to be casting objects and stuff and to get it right to use the correct data. And there were other options, but it seemed really complicated for complex test case registrys (for example, we have an array with multiple data types inside) and unreadable.

If you can figure out how to put everything in one data structure I'd be okay with it, but doing it mixed like this... I think it harms readability and I'd push back against it

Copy link
Contributor

@joshiraez joshiraez left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please see comment in thread because I didn't know I had to put one more here lol

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

Successfully merging this pull request may close these issues.

2 participants