Fix properties with undefined
value pass property assertion
#308
Conversation
+1 it looks like @devand123 stopped responding to comments in #210, happy to move discussion/work over to this PR |
return (typeof obj === 'object' || typeof obj === 'string' || typeof obj === 'function') | ||
&& name in (typeof obj !== 'string' ? obj : new String(obj)) | ||
} | ||
|
keithamus
Nov 18, 2014
Member
Can't this function be defined outside the addMethod anon function?
Can't this function be defined outside the addMethod anon function?
} | ||
|
||
var getPathParent = function(parsed) { | ||
return _getPathParent(parsed, obj); | ||
}; |
keithamus
Nov 18, 2014
Member
This feels a bit confusing to me. Why is getPathParent()
calling out to _getPathParent()
. Can't they be the same method?
This feels a bit confusing to me. Why is getPathParent()
calling out to _getPathParent()
. Can't they be the same method?
Good work @joshperry |
I wasn't handling array indexes terminating the path, I figured an array index isn't technically a property. However, it looks like the documentation sells this, so I added the code in the documentation to the unit tests and added this functionality. I also did some deduplication and cleanup of the code. |
((typeof obj === 'object' || typeof obj === 'string' || typeof obj === 'function') && | ||
name in (typeof obj !== 'string' ? obj : new String(obj))) | ||
} | ||
|
keithamus
Nov 19, 2014
Member
Still looks like this function could be defined outside of Assertion.addMethod('property', function (name, val, msg) {
(i.e. above line 765).
Still looks like this function could be defined outside of Assertion.addMethod('property', function (name, val, msg) {
(i.e. above line 765).
joshperry
Nov 19, 2014
Author
Contributor
I'm not against moving this outside, but it has no general applicability outside of this code. My own personal style is to put functions that are akin to variables inside of the scope where they are used, if it is more in-line with the project's style to have this outside then I'm cool with that.
I'm not against moving this outside, but it has no general applicability outside of this code. My own personal style is to put functions that are akin to variables inside of the scope where they are used, if it is more in-line with the project's style to have this outside then I'm cool with that.
logicalparadox
Nov 19, 2014
Member
What you have done here is quite clever, however it is not very maintainable as its logic is quite dense. By moving it out of .addProperty
you can provide first class documentation for its workings. Perhaps it might be relevant to add it as new utility and expose it for other plugin developers (just in case it has further use)?
Furthermore, any reason you are using typeof
instead of our type-detect
utility? I would also recommend just doing the type detection once to reduce overhead.
What you have done here is quite clever, however it is not very maintainable as its logic is quite dense. By moving it out of .addProperty
you can provide first class documentation for its workings. Perhaps it might be relevant to add it as new utility and expose it for other plugin developers (just in case it has further use)?
Furthermore, any reason you are using typeof
instead of our type-detect
utility? I would also recommend just doing the type detection once to reduce overhead.
joshperry
Nov 20, 2014
Author
Contributor
Thanks for the feedback guys. I honestly wasn't trying to be clever, just adding functionality as I added more and more tests.
Ok, here's my plan:
- A new util function
getPathInfo
that returns the property info struct including whether the property actually exists or not.
- Keep
getPathValue
for back compat, but it can easily be implemented by calling getPropertyInfo
to share the bulk of the code.
This will allow me to properly document the general functionality and make it available to others.
I'll take a look at the type utility you mentioned, I'm still getting introduced to the codebase.
Thanks for the feedback guys. I honestly wasn't trying to be clever, just adding functionality as I added more and more tests.
Ok, here's my plan:
- A new util function
getPathInfo
that returns the property info struct including whether the property actually exists or not. - Keep
getPathValue
for back compat, but it can easily be implemented by callinggetPropertyInfo
to share the bulk of the code.
This will allow me to properly document the general functionality and make it available to others.
I'll take a look at the type utility you mentioned, I'm still getting introduced to the codebase.
I think this wraps things up guys, let me know what you think. |
@@ -1,10 +1,12 @@ | |||
/*! | |||
* Chai - getPathValue utility | |||
* Chai - getPathInfo utility |
logicalparadox
Nov 21, 2014
Member
This is still getPathValue
...
This is still getPathValue
...
obj = new literals[ot](obj); | ||
|
||
return name in obj; | ||
}; |
logicalparadox
Nov 21, 2014
Member
Oh yeah, this looks much better!
Oh yeah, this looks much better!
I'd like @keithamus to get eyes on this as well, but you got my |
Sorry, must have missed this notification. Given it a thorough look over and it looks amazing to me. Great work @joshperry! |
Fix properties with `undefined` value pass property assertion
modify unit tests due to breaking changes from chai 1.10 -> 2.0 chaijs/chai#308 chaijs/chai#306
I was doing some interface assertions and noticed that properties that have a value of
undefined
assert as not existing. This is an initial hack at how I think this could be resolved. I just wanted to get this up and get some suggestions and comments to tighten this up.Fixes #184