Error running tests #13
Comments
|
@renehernandez This is a known problem and limitation of the existing obsidian API. Because the "obisidian" npm package only contains the declaration file To run unit tests, you would have to run the test code in the obsidian app, like a plugin. I don't really like this solution, and I think we should find a solution to be able to use testing frameworks from outside the obsidian app. |
|
If your code is using functions and classes from obsidian's package, then running it from within Obsidian as a plugin is currently the only way right now. You could tweak the codebase to isolate code that's purely functional and does not depend on Obsidian's API for your tests, or attempt to mock out the obsidian package. It's definitely not ideal, but designing a system that can accurately emulate the app's environment is fairly challenging. Perhaps we'll spend some time thinking about this later once the app is more mature and the API is more stable. |
|
I was able to abstract the usage of the filesystem capabilities from obsidian through an internal interface and depend on said interface instead of PR: renehernandez/obsidian-readwise#26 @lishid @SilentVoid13 Thanks for the feedback and suggestions |
|
There's a couple of ways to test plugins at this point. We might consider providing an official framework for testing in the future. Here are some samples of tests:
Frameworks: |
|
If anyone just needs to test editor-related functionality, I've had success substituting CodeMirror as the editor on which my tests run (that's what Obsidian uses under the hood anyway). For example:
|
That URL gives a 404 now It's now: |
|
For anyone else finding this issue when searching for help testing Obsidian plugin code, there's now a set of notes on the Obsidian Hub: for Plugin Developers to Automate Tests Amongst other things, the above links to ... How to test plugin code that uses Obsidian APIs .... which cribs heavily from this issue, and will - I hope - be updated over time as the community learns more about automated testing for plugin code. |
|
I found a way to mock interfaces with the library 'jest-mock-extended' here's an example: import { MockProxy, mock, mockDeep, DeepMockProxy } from 'jest-mock-extended';
import { labTest1 } from 'mock/labTest';
import { App, TFile } from 'obsidian';
test('test', () => {
const tfileArrayMock: MockProxy<TFile[]> = mock<TFile[]>();
tfileArrayMock
// @ts-ignore
const mockObj: DeepMockProxy<App> = mockDeep<App>();
global.app = mockObj;
mockObj.vault.getFiles.mockReturnValue(fakeGetFilesResponse);
expect(labTest1()).toEqual(fakeGetFilesResponse);
});
const fakeGetFilesResponse: TFile[] = [
{
"name": "file1",
"path": "path1",
"parent": {
"name": "folder1",
"children": [
{
"name": "file2",
"path": "path2",
"vault": null,
"parent": null,
},
],
"isRoot": () => true,
"vault": null,
"path": "path1",
"parent": null
},
"basename": "file1",
"vault": null,
"extension": "",
"stat": null
},
{
"name": "file2",
"path": "path2",
"parent": {
"name": "folder1",
"children": [
{
"name": "file2",
"path": "path2",
"vault": null,
"parent": null,
},
],
"isRoot": () => true,
"vault": null,
"path": "path1",
"parent": null
},
"basename": "file2",
"vault": null,
"extension": "",
"stat": null
},
];Where labTest1() is export function labTest1() {
return app.vault.getFiles()
}The current problem of this is a limitation of Typescript with recursive typing. You need to add rules: {
"@typescript-eslint/ban-ts-comment": [
"error",
{
"ts-ignore": false
}
],
},It works! |
|
How about we just include a simple mock with the obsidian API package that mocks the logic and return values behind these functions? Nothing graphical. Shouldn't be too hard and would at least restore some functionality. |
According to obsidianmd/obsidian-api#13, apply testing framework will be failed. So jest just can do some UT. And the e2e testing should choose another way, maybe obsidian official can supply this. Signed-off-by: edonyzpc <edonyzpc@yahoo.com>
According to obsidianmd/obsidian-api#13, apply testing framework will be failed. So jest just can do some UT. And the e2e testing should choose another way, maybe obsidian official can supply this. Signed-off-by: edonyzpc <edonyzpc@yahoo.com>
Currently, I import the
obsidianmodule in the fileDoc.ts as follows:As part of removing the
pathlibrary from the code, I have switched to usenormalizePathfunction as seen onfileDoc.tson branch remove-path-api as follows:With this changes, which eliminates the usage of
typefrom the import statement, my tests no longer work as seen in this Action run.The text was updated successfully, but these errors were encountered: