Open willcurry opened 1 year ago
Thanks for the PR!
One thing I learned when doing deep dives on other testing frameworks was to be careful about bloating the base library. To me, that means when reviewing additions like new expectations, mocking features, etc. - the question should be "Why?" rather than "Why not?". (The idea being that other parties can create and maintain more specific [or perhaps broader] libraries to extend the functionality of the project)
To that end, I wanted to ask you about the use case for this new expectation.
To accomplish this same thing with the current set of expectations, I might do something like this:
expect( tbl[key1] ).to.equal( value1 )
expect( tbl[key2] ).to.equal( value2 )
expect( tbl[key3] ).to.equal( value3 )
expect( tbl[key4] ).to.equal( value4 )
Or perhaps if I had a much larger table, I might do something like this (though I generally shy away from metaprogramming)
for key, value in pairs( expected ) do
expect( tbl[key] ).to.equal( value )
end
Doing it that way could be cumbersome for very large tables, granted, but this way you'd know exactly which key (albeit only one at a time) failed the expectation.
With your code, I believe you'd only see the table signature in the error message (which could be changed).
What's your reasoning or use case for such an expectation? Was there a specific problem you ran into that this helped alleviate?
Please don't get me wrong, I'm elated that you took the time to fork, read, and suggest additions to the code (seriously, thank you, it means a lot 🙏). I think a project like this will have the highest chance of success when more people get involved. I would be remiss, however, if I didn't do my due diligence as a maintainer.
Anyway, looking forward to hearing back from you!
Hello! Thanks for the PR
I'm swamped with work at the moment, but this is top-prio for me when I free up!