-
Notifications
You must be signed in to change notification settings - Fork 68
Open
Labels
Description
So, something like this is a pretty common pattern:
assert(typeof wrap === 'function')
AssertionError: # giraphe.es6.js:61
assert(typeof wrap === 'function')
| |
"object" false
--- [string] 'function'
+++ [string] typeof wrap
@@ -1,8 +1,6 @@
-function
+object
+ expected - actual
-false
+true
Although this works, I feel that this could easily be extended with more useful information: for instance, in most failing assertions, there's information about the object under test; but specifically in typeof's case, that gets lost, and it gets treated as a simple comparison of two static strings.
Here's something like what I'd expect to see (hastily cobbled together from the results for assert(wrap === 'function')
, because it was an easy change :P
:
AssertionError: # giraphe.es6.js:61
assert(typeof wrap === 'function')
| | |
| | false
| Object{}
"object"
[string] 'function'
=> "function"
[Object] wrap
=> Object{}
--- [string] 'function'
+++ [string] typeof wrap
@@ -1,8 +1,6 @@
-function
+object
+ expected - actual
-false
+true
Metadata
Metadata
Assignees
Labels
Type
Projects
Milestone
Relationships
Development
Select code repository
Activity
twada commentedon Jun 10, 2016
Thank you for your question.
Unfortunately, it's a limitation of current implementation of power-assert. I cannot support
typeof
UnaryExpression since it potentially causes ReferenceError.Let me explain. Given example.js,
results in ReferenceError when executed. Since
typeof
operator can take variable that does not defined.capt
function is the simplest mimic of what power-assert is doing internally, so when I tried to capturetypeof
UnaryExpression liketypeof foo
, it always result in ReferenceError.Since test tool should not change behavior of SUT (System Under Test), I gave up supporting
typeof
UnaryExpression.Sorry for inconvenience. I'll write about this limitation to FAQ section in REAME. Thanks!
ELLIOTTCABLE commentedon Jun 10, 2016
Wait, tho: can't you special-case typeof at the syntactic level?
i.e. anything else in JS becomes
expr(expr(expr))
tocapt(expr(capt(expr(capt(expr)))))
… of course, that makes sense; buttypeof is special, so it makes sense to special-case it:
expr(typeof expr))
tocapt(expr(capt(typeof expr !== 'undefined' && typeof capt(expr)
or something like thatSorry for being terse, am on phone. Let me know if confused, can re-explain
when at computer!
On Fri, Jun 10, 2016 at 4:08 AM Takuto Wada notifications@github.com
wrote:
ELLIOTTCABLE commentedon Jun 10, 2016
Ah, immediately realized a problem with that, so pulled out my laptop after sending.
Here's the two solutions I see:
That's fast, but the downside is that it evaluates
bar
twice; so it's only suitable for situations wherebar
is not a complicated expression: i.e. it's just a standalone identifier.Now, I'm not convinced anything except a standalone identifier can trigger a ReferenceError, will need to check the spec, but if it can, then more complicated expressions can be transformed to:
… or something like that, I got bogged down halfway through trying to construct it.
ELLIOTTCABLE commentedon Jun 8, 2017
Resurrecting — any input on my suggestions, @twada? I wouldn't mind submitting a pull-request for one of my solutions (whichever you prefer), if this behaviour is welcome.
twada commentedon Jun 8, 2017
@ELLIOTTCABLE Thank you for resurrecting this issue.
This is in my
someday
task. Sorry for my late response.I think the solution might be look like babel's
typeof
helper. Could be a bit simpler.