Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>After checking vow's source code, I think I know why. Vows always ensure that when you call <code>this.callback</code>, the resulting receiver function's first argument is always an error object. Vows interpret the callbacks by these rules:</p> <ol> <li><p>If the first argument of your originating callback is a boolean, use that to determine whether or not to append an error object to the receiving callback (e.g. <code>path.exists(boolean)</code> will emit <code>callback(error, exists)</code> instead)</p></li> <li><p>If the first argument is an object, assume it's an error object and use that to determine whether to add the originating callback to the "error" or "success" list. The reason this list exists is to support promise based tests I guess?</p></li> </ol> <p>While I can't confirm the above is correct, my experience is that vows' async style is made to support node-styled callbacks (e.g. err as the first arg), and 3rd party npm modules that don't conform to this standard will be hard to test.</p> <p>Please don't take my answer as gospel, as this is my own experience. Another gotcha is when you have async operations inside the function that you want to test - unless you provide a callback, vows won't be able to handle it properly.</p> <p>Personally, I think vows still make it hard to test async code. I wish it had some <code>waitFor()</code> or <code>until()</code> flow control functions though.</p> <p>My suggestion? When dealing with async code, use <a href="https://github.com/creationix/step" rel="nofollow">Step</a>. Don't let vows control your flow.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload