Fix properties with undefined value pass property assertion

[joshperry]

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.

var obj = { foo: undefined };
Object.defineProperty(obj, 'bar', {
    get: function() { }
});
// These both assert without this change
obj.should.have.property('foo');
obj.should.have.property('bar');

Fixes #184

[FredKSchott]

+1 it looks like @devand123 stopped responding to comments in #210, happy to move discussion/work over to this PR

[keithamus]

Can't this function be defined outside the addMethod anon function?

[keithamus]

This feels a bit confusing to me. Why is getPathParent() calling out to _getPathParent(). Can't they be the same method?

[keithamus]

Good work @joshperry 😄. I'd like to see a couple of comments addressed above, but largely this is looking in better shape than #210

[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.

[keithamus]

Still looks like this function could be defined outside of Assertion.addMethod('property', function (name, val, msg) { (i.e. above line 765).

[joshperry]

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]

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]

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.

[joshperry]

I think this wraps things up guys, let me know what you think.

[logicalparadox]

This is still getPathValue...

[logicalparadox]

Oh yeah, this looks much better!

[logicalparadox]

I'd like @keithamus to get eyes on this as well, but you got my 👍

[keithamus]

Sorry, must have missed this notification. Given it a thorough look over and it looks amazing to me. Great work @joshperry!