Option to use external fixtures/scenarios about fixtures

[gr2m]

yes sure, that’d be pretty cool! I’m traveling until Wednesday and won’t be much online until then. Let me know if you have any questions :)

May I ask what the wrapper will be doing? I’m curious :)

[martinb3]

Hi there -- that's great! The wrapper handles a few things, like a helper for pagination (probably could be contributed back), translation from team names to numerical IDs within an organization, and the ability to find organization members who aren't on any team. Most of it is probably outside the scope of this library, but I'd like to be able to test the same way, and pagination might be useful. Cheers!

[gr2m]

I’m back and happy to help you finding the right approach to load external fixtures.

I would suggest that we allow to pass in an array:

fixtures.mock(myCustomFixtures)

Would that work for you?

Would you like to utilize the recording/normalization feature, too?

[martinb3]

Hey there! I started to work on this, and ended up making a separate call for mockExternal and getExternal and then having them both call the underlying/original mock method. I ran into a few problems:

I'm writing for AWS Lambda which is still on Node 6.x. I noticed there's some compatibility code to make the actual library work with Node 4.x and greater. Would you be interested in something similar for the fixtures? I"d be happy to walk it back to be compatible with 6.x.

The biggest problem was the recording/normalization feature, and looking at trying to externalize it in a way where it could be a framework (it's got a lot of supporting code!). I'm new to Node, but familiar with other language environments and frameworks. It seems like Node doesn't have a lot of standard ways of doing this, unlike, e.g. VCR in Python -- there's nock.back() and many VCR-inspired libraries, but no standard for how to record and replay a large number of calls (this/your library chooses using the filesystem to grep out fixtures, but others expect you to set it up in your own project, so many others...).

I'd love to make a standard way for "so you want to mock GitHub... just use this." (I'm not ready to tackle the larger problem, and it seems like everyone who has, has ended up with a *-vcr library). What are your thoughts on at least making this easy for api.github.com?

[gr2m]

I’d love to chat :) If you are interested, can you send me a direct message on twitter to coordinate: https://twitter.com/gr2m

As far as I know, AWS Lambda will update to Node 8 soon, if possible I’d like to avoid back-porting to it. I can check with my friends there.

One thing that I do is to normalise fixtures, which means each time they get recorded, they have the same IDs, timestamps, etc. That way I was able to set up a daily cron job that recognises changes in the API and creates a pull request based on it, e.g. #65

I’d be happy to export the fixtures into a standardised format, too.

For the "so you want to mock GitHub... just use this." I was thinking to create standalone binaries for Windows, Linux and Mac which starts a server that serves the GitHub API mocks. That already exists and somewhat works, but we have yet to use it in a project: https://github.com/octokit/fixtures#standalone-mock-server

I think having a standalone server binary would be the simplest language agnostic solution. Folks might want to load custome fixtures for that, too, and there it makes definitely sense to use a standard that is used across different programming languages

[martinb3]

Hey there -- back in town after Thanksgiving, and ready to pick this up. I submitted a PR #81 that is a first pass doing what you described. I'd love your feedback.

As far as I know, AWS Lambda will update to Node 8 soon, if possible I’d like to avoid back-porting to it. I can check with my friends there.

I noticed there's a test in the current fixtures project for node-4-compatibilty.js -- it feels like it's in conflict with the 'node 8+' on the README. Maybe we need to clarify that?

After that PR I submitted, I'd like to figure out an easy way to adapt recording to external projects (maybe another optional path argument to bin/record.js?).

Let me know if you think I'm going in the wrong direction or should change anything. Happy to do so. Also happy to chat now that I'm back. Cheers!

[gr2m]

Thanks for the pull request, I’ll have a look in a moment!

I noticed there's a test in the current fixtures project for node-4-compatibilty.js -- it feels like it's in conflict with the 'node 8+' on the README. Maybe we need to clarify that?

Ah good catch! Yes I use the test to make sure that the library is compatible to consumers of the Node module

fixtures/.travis.yml

Lines 33 to 34 in 5e877e3

	- node_js: "4"
	env: COMMAND=test:node4

Only running e.g. the bin/record script requires Node 8 or above. Could you send a pull request to update that to Node 4+?

[gr2m]

I had a look at your PR and had just a few minor comments.

I’m still intrigued by your comment:

so you want to mock GitHub... just use this

I’d love to chat about how we can modularize the @octokit/fixtures module to make it usable for custom fixtures, too. One really cool feature / setup is the "self-updating fixtures". You can see one example of that working here: #82. So in your case, you would record the fixtures for the scope of your wrapper, and then once a day (or so) a cron job will execute your custom recording script and compare the normalised result with your normalised fixtures. If they differ, it will notify you about it, so you find problems before your users do.

Maybe this is all overkill, but I’d be happy to explore the possibilities if you are interested. And no worries that you are new to Node, I'm happy to point you to the right places and help you if you get blocked in any way

[martinb3]

Hey! I'd be glad to chat about how I think it's useful / that comment. I'll hit you up on Twitter like you mentioned 👍