unexpectedjs/unexpected

to have properties: Consider supporting numerical properties

papandreou opened this issue · 2 comments

Back in Unexpected 9.something this passed, but now it doesn't:

> require('unexpected')({1: 123}, 'to have properties', [1]);
UnexpectedError: 
expected { 1: 123 } to have properties [ 1 ]

    at Array.forEach (native)
    at repl:1:22
    at sigintHandlersWrap (vm.js:32:31)
    at sigintHandlersWrap (vm.js:96:12)
    at ContextifyScript.Script.runInContext (vm.js:31:12)
    at REPLServer.defaultEval (repl.js:308:29)
    at bound (domain.js:280:14)
    at REPLServer.runBound [as eval] (domain.js:293:12)
    at REPLServer.<anonymous> (repl.js:489:10)
    set UNEXPECTED_FULL_TRACE=true to see the full stack trace

Now we require the property name to be a string:

> require('unexpected')({1: 123}, 'to have properties', [ '1' ]);
Promise (fulfilled)

I assume we want to reinstate the old behavior somehow? And if so, that raises the question about whether to always stringify the array elements. Like:

expect({ true: 123 }, 'to have properties', [ true ]);
expect({ foo: 123 }, 'to have properties', [ { toString: () => 'foo' } ]);

... the two above examples also pass in Unexpected 9.1.0, but especially the last one seems like overdoing it.

WDYT?

I think we should stringify numbers and fail on everything else.

Fixed in #414