This equality test is probably a little too simplistic: if you test this module interactively, say, by running

```
assertive% coffee
coffee> {hasType} = require './lib/assertive.js'
{ truthy: [Function],
  expect: [Function],
  equal: [Function],
  deepEqual: [Function],
  include: [Function],
  match: [Function],
  throws: [Function],
  hasType: [Function],
  falsey: [Function],
  notEqual: [Function],
  notDeepEqual: [Function],
  notInclude: [Function],
  notMatch: [Function],
  notThrows: [Function],
  notHasType: [Function] }
coffee> hasType Object, {}
```

...you get:

```
TypeError: hasType: expected arg is not one of String, Number, RegExp, Array, Function, Object; you used:
hasType "[object Undefined]", {}
    at assert.hasType (/Users/jsundstrom/assertive/lib/assertive.js:287:15)
    at repl:1:5
    at REPLServer.replDefaults.eval (/usr/local/lib/node_modules/coffee-script/lib/coffee-script/repl.js:33:28)
    at repl.js:248:12
    at Interface.inputStream.on.multiline.enabled (/usr/local/lib/node_modules/coffee-script/lib/coffee-script/repl.js:62:9)
    at Interface.EventEmitter.emit (events.js:126:20)
    at Interface._onLine (readline.js:200:10)
    at Interface._line (readline.js:518:8)
    at Interface._ttyWrite (readline.js:736:14)
    at ReadStream.onkeypress (readline.js:97:10)
    at ReadStream.EventEmitter.emit (events.js:126:20)
    at emitKey (readline.js:1058:12)
    at ReadStream.onData (readline.js:807:7)
    at ReadStream.EventEmitter.emit (events.js:96:17)
    at TTY.onread (net.js:397:14)
```

Do you have situations in mind where there's a type this function can't detect (and that it can detect that it can't detect – there are no ECMA standards provisions to reliably detect a native host object, say, vs any other js-level object, except detecting that they don't fully behave as normal objects do in various ways they aren't _required_ to, when a js engine exercises such laxity)?

I think that rather than trying to detect that, which is hard, we might as well just implement the last few types: `undefined`, `null` and `Boolean` should cover the rest, at this precision resolution.

I could see value in higher-resolution type handling (`hasType TypeError, e` for something like `actual instanceof TypeError`, say), but I think you are right to start from just doing basics, as there's a whole can of worm involved as soon as you start using equality or the instanceof operator, when js contexts from different global objects come into play, as probably happened in my manual test above.