fix #145 contains does not fail on string input

[smacker]

Also I added a check for number:

    it('should work with numbers', () => {
      const wrapper = shallow(<div>1</div>);

      expect(wrapper.contains(1)).to.equal(true);
      expect(wrapper.contains(2)).to.equal(false);
    });

[ljharb]

can you add a counter-test here, that in <div>1</div>, wrapper.contains('1') is false?

[smacker]

oh. Actually I did wrong comparison with numbers. Fixed it.

[lelandrichardson]

@ljharb I just noticed this, but should we use a lib for Object.keys instead of assuming it's available?

[blainekasten]

I think it's pretty safe to assume it's available.

Object.keys has really wide support. On the browser side you'd have to use less than IE9, https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/keys

On node side, it's been included since at least 0.10. I'm not sure exactly when it was added to V8, but I think being in 0.10 makes it more than safe to use natively

[ljharb]

It's part of ES5 - node 0.8 and higher, and IE 9 and higher have it.

However, if you want to support older engines (which I strongly recommend!) you can use the https://npmjs.com/object-keys module :-)

[lelandrichardson]

I suppose that since react requires ES5 and above, it is safe to conclude that at least an es5-shim will be loaded in any environment enzyme will be used...

[ljharb]

SGTM

[smacker]

Tests added. It's safe to assume Object.keys is available, if you run it inside IE8, you definitely have some polyfills. es5-shim, or babel-polyfill, because otherwise almost nothing will work.