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

💡 [Feature]: for the love of god let's start writing tests #279

Open
Adam-it opened this issue Jul 27, 2024 · 3 comments
Open

💡 [Feature]: for the love of god let's start writing tests #279

Adam-it opened this issue Jul 27, 2024 · 3 comments
Assignees
Labels
Milestone

Comments

@Adam-it
Copy link
Member

Adam-it commented Jul 27, 2024

🎯 Aim of the feature

It's kinda embarrassing but yes we do not have unit tests as of now.
What initially started as a small VS Code extension oriented around ACEs and Viva Connections turned to this massive extension that extensively enhances VS Code with lot of SPFx development features, now even extends GitHub Copilot.
As we grow and grow we need to make sure we increase the quality and maintainability of our work. As first step we need to add unit tests.
The aim of this issue is to prototype this and kick of with a small portion of unit tests for a single provider or service.

📷 Images (if possible) with expected result

No response

🤔 Additional remarks or comments

No response

@Adam-it Adam-it added ⭐ enhancement New feature or request ✏️prototype labels Jul 27, 2024
@Adam-it Adam-it self-assigned this Jul 27, 2024
@Adam-it Adam-it added this to the v3.X milestone Jul 28, 2024
@Adam-it Adam-it modified the milestones: v3.X, v4.X Sep 8, 2024
@ervingayle
Copy link
Contributor

Hi @Adam-it. I did some research on this and see that it is possible to do some unit tests with Mocha or with a third party vscode-extension-tester that appears to be more suited to test aspects of an extension. What are your thoughts on approach? I would like to work on this implementation starting with prototype.

@Adam-it
Copy link
Member Author

Adam-it commented Jan 12, 2025

Hi @Adam-it. I did some research on this and see that it is possible to do some unit tests with Mocha or with a third party vscode-extension-tester that appears to be more suited to test aspects of an extension. What are your thoughts on approach? I would like to work on this implementation starting with prototype.

Thanks @ervingayle for your initiative 👏👍.
Unfortunately this issue is still not ready to be taken (it is not labeled as 'help wanted') and I am still thinking and prototyping on the best approach to go about this task.
TBH for the last couple of months I haven't found time fot this yet 🫤, there is always so much to do 😉.
That being said I am 100% open for feedback and suggestions. Till now I haven't picked an approach yet so if you had anything specific in mind or would like to point me to an example or article or tech you would use I would really appreciate it.
Till now I considered just writing standard unit tests using Mocha as I have some experience in it and this would work perfectly for services like CliActions.
On the other hand many parts of this extension is not ready for testing, like those that extend VS Code UI with web views, and here I wanted to do something like integration testing that would run the extension based on a scenario but top priority is to make it work in GH Actions.

@ervingayle do you want to share your research?

@ervingayle
Copy link
Contributor

Hi @Adam-it. I understand. I see that the Microsoft guidance is scarce and does not go into much detail about what can be tested even though it says that the components they offer are based on Mocha. The samples that are offered does not show the full extent of the unit tests. This is what my comments are based on thus far: Microsoft Docs. However, I saw a reference to this: vscode-extension-tester and I did some research on this and looked through the issues in to repo as I know the vscode-viva extension has webviews and this test suite seems to support testing this similar to how Jest has support for screen and expect xyz to be in the document/on screen.
Here is the approach for WebviewView's.
What do you think?

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

No branches or pull requests

2 participants