Proposal : Tzatziki front module

[alexandrepa]

First draft of the new front module we want to develop for tzatziki can be found in wiki : https://github.com/Decathlon/tzatziki/wiki/Module-:-Tzatziki-front

Feel free to make suggestions or correction in comments.

I am open to discussion and I have possibly miss some use cases.

[PhilippeBabin53]

See the possibility to enable/disable the "take screenshot on error" and see how it's displayed in the report

[dkt-abarth]

What about mock operations steps ?

It would allow standalone testing rather than depending on a backend/BFF/etc and data consistency

[alexandrepa]

Thanks for your feedbacks, I've made the change in the proposal.

[brian-mulier-p]

Hello ! Tiny insights I can give:

What about mock operations steps ?

It would allow standalone testing rather than depending on a backend/BFF/etc and data consistency

Maybe reusing Mockfaster instead would be better and more resilient than rewriting the whole thing :thinking: Would only imply adding some environment variable so that the front targets the mocked API :thinking:

Do we offer the possibility to the user to access to the internal browser engine (like playwright browser) in case user has a specific need not covered by the module.

If you plan to have a large open-source solution which covers most usecase, I'd advise not to add such step as it would discourage people to open an issue on this repo or contribute directly to it. Moreover, it would encourage people to add hacks in their tests which will require a ton of maintainability issue as well as maybe some breaking change upon dependencies upgrades (while having such feature embed inside tzatziki would allow to detect failure before releasing it and only require a single change in tzatziki).

[dkt-abarth]

What about mock operations steps ? It would allow standalone testing rather than depending on a backend/BFF/etc and data consistency

Maybe reusing Mockfaster instead would be better and more resilient than rewriting the whole thing 🤔 Would only imply adding some environment variable so that the front targets the mocked API 🤔

It would also mean more coupling/deps to bring with for front testing, while it's a native Playwright feature. I feel like cover/wrap as much as possible Playwright's scope seems more logical.

Playwright's mock API has also a quite broad scope and covers feature that are not handled by Mockfaster implementation.

Moreover, as far I can see with some searches, it seems to be a better fit with front community way to go

[brian-mulier-p]

But then it would imply to provide an implementation for each front-testing modules so idk, I think both solutions have their counterpart.

If we see tzatziki as a whole, it's better to enhance Mockfaster to cover the need. Moreover it would bring easier context-switching from back to front and less headaches figuring out two syntaxes.

But no strong opinion and if you choose to go with Playwright's feature it's still a valid choice, just mind it may bring some overhead in maintainability and force to rewrite every mocking steps :+1:

[alexandrepa]

I propose to considered this feature as a "bonus". For now we can used Mockfaster to easily mock external calls, we can rediscuss it when the time comes if we have time and identify the needs to add this feature.