[FEATURE] Addition of tests for the commands that depend on browser interaction.
Why do we need this improvement?
Currently none of the commands like the one related to studio can be tested properly as there is a lack of mechanism to test these command that open a browser.
How will this change help?
This change will allow us to properly test the commands like asyncapi start studio and another commands like asyncapi new which require interaction with browser.
Screenshots
No response
How could it be implemented/designed?
As this is browser interaction related we can use libraries like Puppeteer but first discussions with maintainers are required to figure out a correct approach.
🚧 Breaking changes
No
👀 Have you checked for similar open issues?
- [x] I checked and didn't find a similar issue
🏢 Have you read the Contributing Guidelines?
- [x] I have read the Contributing Guidelines
Are you willing to work on this issue?
Yes I am willing to submit a PR!
Good Enhancement for the Gsoc program, we can take during that time
Hey @AayushSaini101 @Shurtu-gal taking this up as in testing suit this is a major missing part.
Rest commands have some kind of test these lack that.
Thanks @neoandmatrix
@neoandmatrix can you define the scope of this issue ?
Hey @Shurtu-gal @AayushSaini101 did some research on this and here is what i believe can be covered in this :-
First as we need to increase test coverage with this one hence the testing needs to be integrated with current tests only. Now current tests use mocha so these tests will be needed to be integrated with that only.
Second i believe the following can be tested currently :-
- When we test studio with
start studiocommand the presence of elements such assidebar,editoretc. can be checked to confirm that correct mode is opened. - When we test studio with
start previewcommand absence of elements such aseditorand presence ofpreviewpanel can be tested to confirm that correct mode is opened.
One missing thing is testing websockets as they might be bit tricky to test. First to test websocket one would need to check that if files are modified correctly or not which involves reading from files and also comparing them and testing them both way might be bit difficult and in real-time during tests so these can be added later or after above are implemented in my opinion.
Another thing is what framework to use for this. Currently i explored cypress , puppeteer and playwright out of these I found cypress to be best supported with mocha and chai currently.
Puppeteer also have an example of usage with mocha but is quite outdated .
Also one needs to manage that the commands open up a browser instance and a http websocket server in same process which will required to be safely terminated and not the whole running test.
Let me know if i missed something or anything can be added to this.
CC:- @Souvikns
We can test websockets by mocking stuff if I am not wrong.
We can test websockets by mocking stuff if I am not wrong.
Thanks will try,
Anything else that i might have missed in scope for this @Shurtu-gal ?
Did some testing with puppeteer and worked good along with by default being in headless mode. Continuing the implementation with that only.