From b0ab80120f6e0b6e1009207c2bb7aabd7c1aaf57 Mon Sep 17 00:00:00 2001 From: Jesse Hines Date: Sun, 30 Mar 2025 10:13:57 -0400 Subject: [PATCH] Add guide for e2e testing with WebdriverIO --- ...How to test plugin code that uses Obsidian APIs.md | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/04 - Guides, Workflows, & Courses/Guides/How to test plugin code that uses Obsidian APIs.md b/04 - Guides, Workflows, & Courses/Guides/How to test plugin code that uses Obsidian APIs.md index 1433c4064..da2fd1ade 100644 --- a/04 - Guides, Workflows, & Courses/Guides/How to test plugin code that uses Obsidian APIs.md +++ b/04 - Guides, Workflows, & Courses/Guides/How to test plugin code that uses Obsidian APIs.md @@ -22,13 +22,22 @@ By far the easiest way to do this is to use an automated refactoring tool, such This technique is demonstrated in the talk [[Plugin Testing for Developers]]. +## End-to-end testing with WebdriverIO + +Since Obsidian runs on [Electron](https://www.electronjs.org/) it is possible to run end-to-end tests of your plugin against a real Obsidian instance using frameworks like [WebdriverIO](https://webdriver.io). + +One way to do this is using [wdio-obsidian-service](https://github.com/jesse-r-s-hines/wdio-obsidian-service) which configures WebdriverIO for Obsidian testing. You can see some examples of how to use it here: +- [wdio-obsidian-service docs](https://jesse-r-s-hines.github.io/wdio-obsidian-service/wdio-obsidian-service/README.html) +- [wdio-obsidian-service sample plugin](https://github.com/jesse-r-s-hines/wdio-obsidian-service-sample-plugin) +- [open-tab-settings](https://github.com/jesse-r-s-hines/obsidian-open-tab-settings) + ## Other people's suggestions There are some useful discussions and links in the Obsidian API issue [Error running tests #13](https://github.com/obsidianmd/obsidian-api/issues/13). - In [this comment](https://github.com/obsidianmd/obsidian-api/issues/13#issuecomment-819035670) [[renehernandez]] describes abstracting the usage of the filesystem capabilities from obsidian through an internal interface and depending on that interface instead of FileSystemAdapter directly. That way they can introduce a fake object during test to verify the logic they wanted in the FileDoc object. - In [this comment](https://github.com/obsidianmd/obsidian-api/issues/13#issuecomment-880504457) `@lishid` lists some test frameworks that have attempted to help with testing Obsidian plugins: - - [trashhalo/obsidian-plugin-e2e-test](https://github.com/trashhalo/obsidian-plugin-e2e-test): a sample repo with obsidian plugin e2e tests + - [trashhalo/obsidian-plugin-e2e-test](https://github.com/trashhalo/obsidian-plugin-e2e-test): a sample repo with obsidian plugin e2e tests using [spectron](https://github.com/electron-userland/spectron) - [[obsimian-exporter#Obsimian Exporter]]: an Obsidian simulation framework for testing Obsidian plugins - These are both many months old, and may not be being maintained - In [this comment](https://github.com/obsidianmd/obsidian-api/issues/13#issuecomment-1003880942) [[timhor]] reported that If anyone just needs to test editor-related functionality, he has had success substituting [CodeMirror](https://codemirror.net/doc/manual.html) as the editor on which his tests run (that's what Obsidian uses under the hood anyway). There are links showing how he did this.