Micropilot

[monicachew]

This is just some placeholder code, but I could use some testing advice. Also please review the changes to the README to see if setup directions make sense.

[monicachew]

For testing, I'd like to somehow trigger the upload and check that the events emitted by the tests are what we expect. I guess I could expose forceUpload for testing purposes, then yield to the promise returned by monitor.upload. Is there a way to expose forceUpload only to the test?

[mozkeeler]

I was expecting this to automatically fetch micropilot for me. Too much to ask, or do I not have volo set up correctly?

[monicachew]

I think, but am not sure, that this means that if we use volo to install blushproof itself then volo will fetch packages/micropilot, e.g.

volo create myaddon micropilot-template

However, I'm not sure how/if we can take advantage of that in the development cycle.

@gregglind, any clues?

[monicachew]

This doesn't seem to be supported: volojs/volo#149

Seems like the intended workflow is to manually call volo add -f when you want to update the dependency.

[monicachew]

Hmm, figure out workflow by reading bugs: volojs/volo#22

@jrburke, is the expected workflow to contribute to a git-managed codebase with volo dependencies to

git clone myproject
cd myproject
volo add

?

[mozkeeler]

I don't know of a way to expose something only to the tests. There are already some testing-only custom events that are emitted that in theory regular code could listen for, so I don't think it's that bad to expose a testing-only thing to non-tests. Maybe we should add annotations? Also, it would be cool to have a way of replacing the micropilot server with localhost:4444 and registering a handler that will check that the data it receives is good (the latter part should be pretty easy - see https://developer.mozilla.org/en-US/docs/Httpd.js/HTTP_server_for_unit_tests ).

[monicachew]

So, if simulate = true in the upload then we get the data back in the response, which I think is good enough for testing we are recording what we expect. I think we should differentiate between

1. Testing that micropilot upload works correctly (https://github.com/gregglind/micropilot/blob/master/test/test-micropilot-upload.js)
2. Testing that we record what we expect

Otherwise unit tests devolve into integration tests.

[monicachew]

I ended up doing a massive rewrite of the test code to use promises instead of continuation callbacks. It is shorter and reads more synchronously, so I think it's easier to understand -- but I am sorry it ended up being so large.

This is more or less ready for review.

[mozkeeler]

This is something I have a question about that we should discuss during the meeting today.

[monicachew]

Fixed everything (I think) besides the prototype issue, which I still haven't figured out. OK to merge?