-
Notifications
You must be signed in to change notification settings - Fork 910
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
Code refactoring for extension testing #10529
Conversation
…into aasim/import/testing
…into aasim/import/testing
…into aasim/import/testing
…into aasim/import/testing
…into aasim/import/testing
…asily mockable -Added some unit tests for the import extension -Some code logic separations
|
||
export class ApiWrapper { | ||
|
||
public createOutputChannel(name: string): vscode.OutputChannel { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Whats the goal in introducing this? From what I can tell you are just adding integration tests, which makes this api wrapper unnecessary.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The naming is kind of weird in the test script but those are unit tests and not integration tests. I've created the wrapper just to mock those apis. Let me know if I those are integration tests.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What i'm saying is you don't need to mock them. they aren't true unit tests in that they run in their own context. Those tests get run in a ADS environment, vscode, ads, all that will exist.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@anthonydresser I think the plan is to test this feature without an active SQL connection, so I think some of the API calls will be mocked.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's a consistency thing too - just keeping all vscode/azdata calls through the api wrapper so that if we do care about mocking them out if we can. And adding them here doesn't really have any noticeable impact.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From a quick glance it seems fine, make sure to do e2e testing of this manually and check to see if the scenarios work as expected.
…into aasim/import/testing
-added unit tests -separted some logic for testing
…into aasim/import/testing
Can you @ me for a review when the changes have been finalized? |
@aaomidi I won't be making any more changes to this PR. I have written some additional tests but that's for another PR |
* Setting up tests on import extension * -Added API wrappers for all the azdata and vscode APIs to make them easily mockable -Added some unit tests for the import extension -Some code logic separations * -added code report for the import extension in ci * Did some more code refractoring * -Added json report generation * updated vscodetestcoverage to latest version in import extension. * -remove duplicate codecoverageConfig.json
I would like some inputs for more code refactoring. My end goal is to make the extension more unit testable by making it easy to mock the classes.