Unexpectedjs for assertions

[Munter]

I've been using unexpected as an assertion library for test for a while now and the concept of having types with specific assertions and being able to combine them in all sorts of ways is immensely powerful. The library has extremely good error messages, goes to great lengths to reduce the callstack to only the relevant parts, gives you great typo hints and, most importantly, is very extensible.

I wrote unexpected-dom, which adds dom types and assertions around them, further improving the quality of error messages.

Would it be possible to plug in high level assertion libraries into Skaro myself, or would it possibly even make sense to outsource the whole assertion part of Skaro to unexpected?

Just to give you an idea about the level of quality that goes into these error messages, this is the failure I get with an assertion that says:

expect(instance.getDOMNode().querySelector('select'), 'queried for', 'option', 'to satisfy', [
  expect.it('to have attributes', { value: 'mobile'}),
  expect.it('to have attributes', { value: 'work'}),
  expect.it('to have attributes', { value: 'home'}),
  expect.it('to have attributes', { value: 'main'}),
  expect.it('to have attributes', { value: 'wok_fax'}),
  expect.it('to have attributes', { value: 'private_fax'}),
  expect.it('to have attributes', { value: 'other'})
]);

[Munter]

ping @papandreou @sunesimonsen

[rodneyrehm]

Would it be possible to plug in high level assertion libraries into Skaro myself, or would it possibly even make sense to outsource the whole assertion part of Skaro to unexpected?

unclear. I assume a lot of wrapping would have to happen.

expect(instance.getDOMNode().querySelector('select'), 'queried for', 'option', 'to satisfy', [
  expect.it('to have attributes', { value: 'mobile'}),
  // …

that's exactly what we don't want users to have to write. we want the assertions and expectations to understand how they're being used so they can generate all the labeling for the user. In Dalek, we'd see above snippet written as:

assert.attribute('select > option', 'value', 'mobile')

The goal is to prevent the user from having to write a novel every time, if it can be done once in the plugins. This will be way less flexible than what unexpected can offer, but that's a trade we're fine with (for now).

Just to give you an idea about the level of quality that goes into these error messages, this is the failure I get with an assertion that says:

That's some serious output. I love it! I'm not sure Dalek needs hat kind of detail, though. Here's what we're generating currently:

I'm not interested in keeping the output the way it is right now. I am however interested in the user not having to write more than absolutely necessary.

[Munter]

I think it might still be possible to get a leg up from the work in unexpected. There have already been experiments with compatibility wrappers, like @gustavnikolaj's expect-the-unexpected to help migration from expect.js. A similar approach could be taken here. Implementing a subset is certainly easier than a superset.

If you like the output enough to want to use it, it's available in uninspected

[rodneyrehm]

I think we'd like to use chai, unexepected or whatever other library to do the heavy lifting, if that is in any way feasible. We're not suffering rom any NIH delusions, and it's not like our resources grow on trees… That said, we're willing to put the effort in, if it's necessary to achieve our core goal: making this testing shit easy, approachable and cheap.

I'd also like to talk about another direction we could take with uninspected. I like the output, but I think it's too massive for integration in the main reporter output. I wonder if we can provide this level of detail in a separate file linked to from the main reporter output. Does that sound reasonable?

I'd very much like to pick up the discussion again once we got the core to some sort of alpha stage.

[Munter]

Splitting outputs sounds doable with the right wrappers. I'm not the expert on error handling though, so maybe the others can chime in on that.

[sunesimonsen]

@Munter sorry for not reacting, I'm in Aarhus with the kids right now, but I'll look into the discussion after the weekend. Hope that is okay.

[sunesimonsen]

Hi @rodneyrehm and @Munter,

I'll like to start out by clearing a few things up, Unexpected at it's core knows nothing abort the DOM, that is just something @Munter provided in his plugin. Usually we aim for composability over initial ease of use, but that doesn't mean you can make a plugin that would be able to do the following:

expect('select > option', 'to have attribute', 'value', 'mobile');

The plugin would just have to know about where to find the DOM. The output is usually made from composable types that individually decides how things should be inspected. But you can also go completely custom if you like, that is just more work.

The plugins we have been involved with, have the filosofi that you want as much detail when an error happens as possible. But it would be possible to create another plugin that would turn down that detail level.

I think @Munter was trying to show how composible things are with his example. But you could easily imagine doing following instead:

var dom = instance.getDOMNode();
var select = dom.querySelector('select');
expect(select, 'to have option values', [
  'mobile', 'work', 'home' 'main', 'wok_fax', 'private_fax', 'other'
]);

About providing the detailed Unexpected output in addition to a simplified output, I think it is possible, but I also think you would have to do a lot of duplicate work.

I hope that helped explain a bit about what Unexpected is and how it might be useful. I completely understand if you guys, just want to perfect your own thing. But if you chose to base some part of Skaro on Unexpected, we'll of cause be at your service trying to help you with the challenges you will be facing.

Kind regards Sune