Spike: Camel case syntax

[papandreou]

This is a super inefficient proof-of-concept implementation so that we can discuss the syntax etc.

If we can achieve some kind of consensus, I promise to clean it up and optimize it :)

• [ ] Work through edge cases discovered by auto-converting the test suite to camel case: https://github.com/unexpectedjs/unexpected/commit/74903a47a2cebba95b61ad0bc0b89b1b659dfc55
• [ ] Think about how we might capture the full context in middle-rocket cases like expect([1, 2,3]).whenPassedAsParametersTo(Math.max).toEqual(4) -- right now that just fails with expected 3 to equal 4 here.
• [ ] Think about flag forwarding again (https://gitter.im/unexpectedjs/unexpected?at=5ce1417463dea422b4abaa6c)
• [ ] Figure out what expect.it(fn) should map to.

[alexjeffburke]

I took a look at this PR - some thoughts follow.

Implementation wise I think it is very straightforward - one thing I learnt from trying unassessed was that we may may not want to expose all the assertions like this. In it I had somewhat of a whitelist, although it was implemented by looking at the assertion string / type information and at least filtering out any that were middle-rocket.

On a perhaps more controversial point, I can't help but be in two minds about whether this should really be in unexpected core. It almost feels like it's might be something else if we expose the methods like this. From what I can tell, we can almost do this by making use of being able to hook unexpected - perhaps we should consider making that infrastructure work and putting this out under a new name?

[papandreou]

Implementation wise I think it is very straightforward - one thing I learnt from trying unassessed was that we may may not want to expose all the assertions like this. In it I had somewhat of a whitelist, although it was implemented by looking at the assertion string / type information and at least filtering out any that were middle-rocket.

This implementation preserves middle rocket support via this syntax:

expect([1, 2, 3]).whenPassedAsParametersTo(Math.max).toEqual(3);

Then we can have a separate conversation about whether to unsupport middle rocket altogether. Last time we talked about it, I remember that we were a bit back and forth about whether to part with it, and that especially unexpected-dom had some very attractive use cases for it.

We've also talked about requiring middle rocket assertions to declare the type of what they're expect.shifting, which has the potential for us to produce more precise typings. I would prefer to have a separate discussion about that, though.

On a perhaps more controversial point, I can't help but be in two minds about whether this should really be in unexpected core. It almost feels like it's might be something else if we expose the methods like this. From what I can tell, we can almost do this by making use of being able to hook unexpected

In my opinion the camel case syntax is superior to what we have now (and less controversial), so I think we should go all in on it, switch all the docs over to use it, and aim to remove the current assertion syntax. If we hook it in and keep it in a plugin, we'll be sending mixed signals and end up with a fragmented ecosystem.

perhaps we should consider making that infrastructure work and putting this out under a new name?

That's called unassessed, isn't it? 😼

In my opinion we've essentially already done that and proven that it's pleasant to work with, so I think now's the time to put it in core.

[pingvinen]

In my opinion the camel case syntax is superior to what we have now (and less controversial)

In my opinion the current assertion syntax is far superior to this DSL-chaining thing. It is one of the primary reasons why I use unexpected in the first place. If unexpected is used in the "exact" same way as the rest of the assertion frameworks, then why do we need unexpected at all?

[papandreou]

Hopefully because of the extensibility and quality of the output when an assertion fails? :)