Use parameterized test

[apupier]

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?

[joshiraez]

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