Add tests of MethodModelingViewProvider.viewLoaded#3444
Conversation
| let getStateForActiveDb: jest.Mock<DbModelingState | undefined, []>; | ||
| let getSelectedMethodDetails: jest.Mock< | ||
| SelectedMethodDetails | undefined, | ||
| [] | ||
| >; |
There was a problem hiding this comment.
Would it make sense to use the function definitions here rather than manually specifying the arguments and return types?
| let getStateForActiveDb: jest.Mock<DbModelingState | undefined, []>; | |
| let getSelectedMethodDetails: jest.Mock< | |
| SelectedMethodDetails | undefined, | |
| [] | |
| >; | |
| let getStateForActiveDb: jest.MockedFunction< | |
| ModelingStore["getStateForActiveDb"] | |
| >; | |
| let getSelectedMethodDetails: jest.MockedFunction< | |
| ModelingStore["getSelectedMethodDetails"] | |
| >; |
There was a problem hiding this comment.
Nice. I wasn't aware of jest.MockedFunction but that is a lot cleaner.
| mockedObject<WebviewViewResolveContext>({}), | ||
| new CancellationTokenSource().token, |
There was a problem hiding this comment.
It seems like it should be safe to remove these parameters from the resolveWebviewView method implementation so you don't need to pass these.
There was a problem hiding this comment.
resolveWebviewView is implementing a method from the WebviewViewProvider provider so that's why it had those unused arguments. They're there for documentation purposes, though personally I agree I think it's fine to not define them on our definition if we're not using them.
Previously it was just a matter of documentation preference with no other concerns, but now that we're calling this method ourselves in the tests it's making our testing harder as we have to mock more objects. So I think that's enough justification to remove them now.
2 participants
This PR is trying to add tests that would have caught the bug fixed in #3439
To do this we need to initialize a
MethodModelingViewProviderand send it a "viewLoaded" message. Then we can test that it does the right thing in variousModelingStorestates. I believe the only thing the test can verify is what messages are sent to the webview.I've focussed on what it does when the view is first loaded and haven't tried to add tests for all the other behaviours of
MethodModelingViewProvider. We could add more tests later if we think that would be useful.Checklist
ready-for-doc-reviewlabel there.