Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Testing approach #76

Open
matthew-shaw opened this issue Feb 8, 2024 · 2 comments
Open

Testing approach #76

matthew-shaw opened this issue Feb 8, 2024 · 2 comments

Comments

@matthew-shaw
Copy link
Member

          Hi @matthew-shaw I work at Crown Commercial Service and look after the Digital Marketplace (which used to be managed by GDS).

We have a frontend repo for Digital Marketplace components (like GOV.UK Frontend) which contains Nunjucks components and the Flask apps would do some magic (as far as I'm concerned) to allow Jinja to parse the Nunjucks templates. Because this is not going to be maintainable long term I've created a project, inspired by this project, Digital Marketplace Jinja Templates which contains Jinja Templates.

Now I originally looked at forking govuk-frontend-diff and doing something similar for Digital Marketplace but I saw in the README that the GOV.UK Frontend package now includes fixtures (i.e. the expected HTML for the component with different params). So for the next release of Digital Marketplace Frontend, because it was not already, I made it generated fixtures with the HTML for all the components.

I've created an app which responds to requests to generate the components. Within the test it gets all of the fixtures from the node module and generates a set of pytest fixtures to test. It then sends the request to the app and then compares the response.

Now, because there can be difference in how things are rendered (i.e. the indent is slightly different or Nunjucks having true where as Jinja will have True) I have added a method html_to_one_line which "normalises" the results so they can be compared.

This not a perfect solution by any means and may not be what you want with this project but I thought it might be useful to share considering you seem to be at a bit of bottleneck with how you're going to test from v5 onward.

Originally posted by @tim-s-ccs in #70 (comment)

@matthew-shaw
Copy link
Member Author

Hi @tim-s-ccs Just wanted to let you know that I'm not ignoring you! I've had other higher priority work to do for a while now, so finding time to fit this in around the day job has been rather difficult. The testing approach is something that I've had on my mental backlog for a while. I'd like to not be reliant on the diff tool, and be able to generate pytest based test fixtures from the published yaml/json test fixtures in GOV.UK Frontend. A similar approach to that taken on GOV.UK Frontend WTForms, which has a generic pytest setup that reads in parameterised tests from config, with expected output, except in this case that's all been done for us by GDS.

Hopefully I can find some time to spend on this over the next couple of weeks. If I have any questions I'll get back to you. Thanks for your patience. Matt.

@tim-s-ccs
Copy link

Hi @matthew-shaw I understand and it's not a problem! If I can help with anything please let me know :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants