Best Practice for Writing Unit Tests & Consuming Highland Streams?

I'm writing some mocha unit tests to test my reusable through pipeline files. However, I am not certain which is the best way to test them. The problem seems to stem from consuming the stream, ideally:

- My assertions should always fire
- Either the done callback from the unit test is called or a promise is returned

So far the best I have been able to come up with is:

```js
it('Should work really really well', (done) => {
_([ buildState ])
.through(createBuildStream)
.toCallback((err, state) => {
expect(err).toBe(null);
expect(state).toExist();
expect(state.get('id')).toBe(1);

done(err, state);
});
});
```

It's important that assertions run always because when I was using the `.each` or `.tap` method I was getting false positives if nothing made it down stream and the assertions were not run at all. That is at least where `.toCallback` helps however some of my streams return multiple items over time in which `.toCallback` will not work.

I've been able to simplify a little bit by monkey-patching in some custom methods to ease testing:

```js
it('Should work really really well', () => {
return _([ buildState ])
.through(createBuildStream)
.inspect((err, state) => {
expect(err).toBe(null);
expect(state).toExist();
expect(state.get('id')).toBe(1);
})
.toPromise();
});
```

Where inspect works a lot like toCallback except that it fires per each item coming down the stream and if no value was received it fires if it receives nil. Is there a better way to go about testing highland streams?

Start with the examples in the issue and review Highland's through, each, tap, toCallback, and stream-consumption behavior. Compare how completion, errors, assertions, and multiple emitted items are handled in the proposed Mocha patterns. Done means documenting a reliable testing approach that avoids false positives and supports both single- and multi-item streams.

Written by the indexing model from the issue text.