search

Shinmera / parachute

An extensible and cross-compatible testing framework.
https://shinmera.github.io/parachute
zlib License
94 stars 9 forks source link

Suggestion: ARE as an elegant IS-like alternative to IS-VALUES #5

Open Hexstream opened 5 years ago

Hexstream commented 5 years ago

Hello,

Thanks for Parachute, I've started using it for all my (ready-to-use) libraries.

Just a quick note to let you know that I always found is-values to be completely unusable because it's way too verbose. Which was tragic for someone like me who lives and dies by multiple values.

Fortunately, I quickly came up with are, which I find at least 10x more convenient. I love how trivial this was to implement thanks to Parachute's design.

(defmacro are (comp expected form &optional description &rest format-args)
  `(is ,comp ,expected (multiple-value-list ,form) ,description ,@format-args))

There are a bunch of usage examples here.

I hope you like it. I would love if this was integrated so that it can help other people and so that I don't have to copy/paste it in all of my test suites. (I don't really want to make my own personal "parachute-utils" library just for this either.)

Sorry, I'm pretty busy so I'm not too eager to make a proper pull request.

Shinmera commented 5 years ago

In this verison the comparator is applied to two lists, rather than being element-wise, though, so for instance (are = '(1 2) (values 1 2)) would fail. This seems like unexpected behaviour to me. If anything, it should expand to an is-values or to something that evaluates a multiple-value-comparison-result.

Hexstream commented 5 years ago

I use are with equal and equalp comparators only. I haven't needed more granularity than that thus far. It's very convenient.

edit: (are equal '(1 2) (values 1 2)) in your example.

phoe commented 5 years ago

I'd assume that are would need to call the comparator element-wise, while ensuring the lists are of the same length. I don't think that restricting the number of test functions to equal and equalp is a good idea here.

Hexstream commented 5 years ago

I wouldn't mind if support for element-wise comparison was added, but multiple values usually have heterogeneous semantics and types anyway, so I don't think it's that important in this case.

Shinmera commented 5 years ago

That's demonstrably false though.

Hexstream commented 5 years ago

I live and die by multiple values and that has been my general impression, if you could demonstrate it false that would be great.

phoe commented 5 years ago

but multiple values usually have heterogeneous semantics and types anyway

If that is true, then the proper way would be to multiple-value-bind these values and do multiple is calls with multiple predicates. You cannot reliably test something that has heterogenous semantics and types with a single generic predicate like equal or equalp.

Hexstream commented 5 years ago

Having to specify multiple comparison predicates is what I specifically want to avoid, since that's way too verbose.

Here are my most are-intensive test suites: place-utils, its, place-modifiers, multiple-value-variants, first-time-value.

You cannot reliably test something that has heterogenous semantics and types with a single generic predicate like equal or equalp.

Disagree, what you're missing is that I'm testing values against simple known static literal values.

You're asking to call the comparator element-wise, while ensuring the lists are of the same length, well guess what, equal does that, and even recursively, and I don't have to type out and then read multiple comparison predicates...