search

open-sauced / opengraph

OpenGraph dot Open Sauced is a general purpose social card generator
https://opengraph.opensauced.pizza
MIT License
6 stars 4 forks source link

feat: adding utilities for cards local generation & testing #34

Closed nightknighto closed 1 year ago

nightknighto commented 1 year ago

What type of PR is this? (check all applicable)

Description

Related Tickets & Documents

fixes #31 & #26

Mobile & Desktop Screenshots/Recordings

Added tests?

Added to documentation?

[optional] Are there any post-deployment tasks we need to perform?

[optional] What gif best describes this PR or how it makes you feel?

nightknighto commented 1 year ago

@0-vortex Hmm, well it was meant to be a form of manual standalone testing to check the appearance not automated testing.

Didn't have much luck getting jest to acknowledge the e2e test files in /test as well.

0-vortex commented 1 year ago

@0-vortex Hmm, well it was meant to be a form of manual standalone testing to check the appearance not automated testing.

Ok, other good folder ideas for the static output:

0-vortex commented 1 year ago

@0-vortex Hmm, well it was meant to be a form of manual standalone testing to check the appearance not automated testing.

A fix for avoiding the automated testing failures is to return status code 0 on the base test command and implement our own testing command as a separate script - that way we could keep the testing boilerplate code inside the test folder while avoiding CI issues 🍕

nightknighto commented 1 year ago

@0-vortex Hmm, well it was meant to be a form of manual standalone testing to check the appearance not automated testing.

A fix for avoiding the automated testing failures is to return status code 0 on the base test command and implement our own testing command as a separate script - that way we could keep the testing boilerplate code inside the test folder while avoiding CI issues 🍕

Yup added a separate command for running the generation file.

nightknighto commented 1 year ago

@0-vortex The reason I made UserCard.ts and not a unified file for all local dev is so that each different social card can be generated and tested on its own (highlight cards coming up next). This saves time by not generating other unneeded social cards when testing a specific one and making code more manageable. What do you think?

0-vortex commented 1 year ago

@0-vortex The reason I made UserCard.ts and not a unified file for all local dev is so that each different social card can be generated and tested on its own (highlight cards coming up next). This saves time by not generating other unneeded social cards when testing a specific one and making code more manageable. What do you think?

future social cards could pose some unknown requirements for which we could only make assumptions now; don't think the way we split the code should affect the way we run the testing commands or rather, limit ourselves to optimising those via code only; an example here is we could keep it with whatever name as long as it's in test folder, then split the test runner from the social cards or implement a parameter to the testing command like npm run test:local user. In the suggested changes my issue was the "local-dev" folder holding a single file 😅 🍕

nightknighto commented 1 year ago

@0-vortex Alright, no problem 👍 Can you push from your repo or do I need to do those changes in mine and push?

brandonroberts commented 1 year ago

I like the separate npm script command for usercards. We could make a static page with the sample usernames that fetch from the running backend also, but I think its good enough for now.

nightknighto commented 1 year ago

@0-vortex

github-actions[bot] commented 1 year ago

:tada: This PR is included in version 2.1.0-beta.1 :tada:

The release is available on:

Your semantic-release bot :package::rocket:

github-actions[bot] commented 1 year ago

:tada: This PR is included in version 2.1.0 :tada:

The release is available on:

Your semantic-release bot :package::rocket: