-
Notifications
You must be signed in to change notification settings - Fork 79
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
test: Add test for "needCheckForUpdates" #1145
test: Add test for "needCheckForUpdates" #1145
Conversation
scalameta#1144 This commit adds a test for `needCheckForUpdates`. For adding unit tests, this commit abstract away the logic that needs access to vscode APIs, becuase we need to run an integration test for accessing vscode APIs. see: microsoft/vscode-wordcount#5 (comment) microsoft/vscode#82471 (comment)
a2f1cd1
to
da8ac81
Compare
Copied from tanishiking#82
Yeah, adding an assertion library is good 👍 |
repo | ||
); | ||
expect(actual).false; | ||
expect(spy.getCall(0).args).to.eql([ |
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.
we can use spy.calledWith(...)
, but this way will show better error message if test fail (while calledWith
shows true or false)
cf2862e
to
8c28bbf
Compare
Actually I was wrong. |
Yeah, I also think mocha chai sinon would be noice in this repository (than jest) 👍 |
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.
You don't want to add chai as a dependency? I prefer to use chai because I like BDD style testing and it's small library.
It's ok, I just meant that I forgot that node's assert also provides good errors ;)
I think we're missing one important think (correct me if I' worng) - do we have some docs how to run single test file, single test from suite? That would be nice to have.
TBH, even yarn test
might be useful for people like don't do js day to day.
import { ExtensionContext, Memento } from "vscode"; | ||
import { ConfigurationTarget } from "../ConfigurationTarget"; | ||
|
||
type LastUpdated = { |
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.
I think it's more common to use interface for such data types
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.
I don't have a strong opinion, but I prefer to use type
over interface
for the data types that shouldn't be extended (by inheritance or declaration merging).
export interface CheckForUpdateRepo { | ||
getLastUpdated(target: ConfigurationTarget): LastUpdated; | ||
saveLastUpdated( | ||
serverVersion: string, | ||
lastUpdatedAt: string, | ||
target: ConfigurationTarget | ||
): void; | ||
} | ||
|
||
export class DefaultCheckForUpdateRepo implements CheckForUpdateRepo { |
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.
SO it's not a problem that interface is located in the same file which has imports from vscode
package as long as it doesn't use them, nice. Maybe I'll rewrite/write some unit tests for test explorer then :D
Thanks! Added docs on how to run tests b70d5b3 |
#1144
This commit adds a test for
needCheckForUpdates
.For adding unit tests, this commit abstract away the logic that needs
access to vscode APIs, becuase we need to run an integration test for
accessing vscode APIs.
see: microsoft/vscode-wordcount#5 (comment)
microsoft/vscode#82471 (comment)