Improve: Add test(s) and/or checks

[joshuatz]

With how often this is needing updates, it would be nice to establish some sort of test or simple check to verify the shape of the output.

This could be something like a real-life integration test with snapshot...

• dev puts cookie in .env file, extension runs via playwright, JSON Resume output is collected and compared to snapshot
• Would essentially test all parts, include LI API endpoints
• Downside: requires a static LI profile that never changes (or else not a true snapshot test)

... Or, to avoid needing a real LI profile and using real LI endpoints, could mock the LI API

• This would also make it easier to test specific parts of the code versus full integration test
• Avoid API throttling / quotas / flagging
• Downside: Would not catch LI APIs changing

[SKalt]

I'd vote for both. The end-to-end test w/ playwright could test whether the LI APIs break with assertions like expect(resume.projects).not.toBeEmpty(). A mocked API would be appropriate for testing the resume-forming logic against a known version of the API.

I'd be happy to set up mocked APIs for unit testing, and I'd be interested to see how end-to-end tests would work.

[joshuatz]

Coming back to this, I'm definitely less enthusiastic about the end-to-end browser test. There are just a lot of things that would make that really hard to set up:

• I haven't checked recently how long the client-side LI auth tokens are good for, but I can't imagine it is very long, which would mean that the .env file (or wherever the token is stored for tests) would have to be updated constantly, or else tests will start failing
• LI has a lot of security features that might interfere with automation tools like playwright
• I'm wary of adding anything that looks like true "scraping" to this tool, even as part of a test suite; LI is not exactly friendly towards this kind of use...

But, for API mocking, I think that would be great, and cover the parts of the tool most likely to break with code changes anyways. If you are going to work on them, I would suggest checking out my (WIP) notes on the unofficial API here.

[SKalt]

re: end-to-end browser testing: I took another look through LI's TOS. Turns out they forbid any automated access, so browser testing's out.

re: scraping: I think LI's disapproval of this software is near-inevitable.

This is not legal advice, but according to the LinkedIn User Agreement, section 8.2 b,

you agree that you will not:
Develop, support or use software, devices, scripts, robots or any other means or processes (including crawlers, browser plugins and add-ons or any other technology) to scrape the Services or otherwise copy profiles and other data from the Services;

Breaking the TOS might result in devs' accounts getting revoked at worst. That's within my comfort zone, but it might not be within yours.

To keep things copacetic with LI, I'd suggest requesting a dev API key that has the r_basicprofile permission, then write a SPA that uses that permission to fetch and render the profile as a JSON resume. In that case, LI would be more likely to revoke the dev API token rather than anyone's account if they disapprove of the tokens' usage.

re: API mocking: I'm going with jest, mocking just the profileView endpoint. To get functions into jest without using rewire, I've had to refactor to a module-based setup.

[joshuatz]

Yeah, re: TOS, that is why I choose to be very specific in my wording around this project (lol). To be fair, its intended use really is just for users to export their own data (that is why I built it, for my own personal JSON powered resume). I think going down the whole developer API route is not currently worth the trouble, and I'm good with just doing API mocking. I always do a "smoke test" for every release as well, where I sideload a fresh build and test it.

I'm good with jest. And refactoring is fine (and probably appreciated; this was one of my earlier programming projects, and it kind of shows 😅).