Thanks for the PR.

I think it's great to have a sample plugin with testing framework integrated for people to use, but I would rather we don't further complicate the official sample plugin template.

In this case, I think it's best if we have your fork as a standalone fork, where people can choose to use if they'd like to write tests for their plugins. If you'd like to maintain the template for longer term we can look into adding links to your repo in our plugin developer docs.

@lishid thanks for the quick review! This seems a highly requested feature given the thumbs up in #37. Please consider opening up the PR again pending discussions in the feature request.

Please note that this is by far the simplest implementation of everything I tried out. If you look at how others solve testing obsidian plugins (obsidian-full-calendar, or excalidraw) the setup is either much harder to understand and use or obsidian can't be mentioned anywhere in the tests. This makes developing plugins hard to develop in my opinion. The official Obsidian docs suggest you refactor your code to be able to test it here. This does not seem user friendly to me and doesn't allow you to test things like "did I register my command?".

I want to chime in here to say thanks to @hjonasson and the Obsidian maintainers, but also to ask the maintainers to reconsider adding this functionality to the sample plugin.

As someone who is contributing to an Obsidian plugin to the first time, it took me a while to find this PR. Before that, I looked at various other Obsidian plugins of varying popularity, and they all have fairly different, often quite complicated test setups. I think the reason for this is that currently, everyone is reinventing the wheel when it comes to testing their Obsidian plugins.

Having an officially blessed way of writing tests would be amazing because

1. Many plugins created in the future might "automatically" have some tests, even if they are simple, just because it's part of the template. I think this is not currently the case because the effort of figuring out how to test the plugin is too high.
2. When making changes, Obsidian maintainers would notice whether this breaks the default testing setup.

🚀

Thanks @x3ro ! This was my feeling exactly. Both about everyone needing to reinvent it for each plugin, and most setups being more complicated. I (biasedly) think this PR or a similar one would be a great addition to the sample plugin.

After what just happened with toggle-list being disabled, adding simple Unit tests for side effects (like deleting global hot keys) would be super easy and valuable to the community.

@lishid you should deffo reconsider adding testing and linting configs. They don’t need to be run/mandated but should at the very least be available in this project. I’ve managed and maintained several large scale APIs and I will tell you that this will improve your team’s velocity and your product’s value. Mid to long term it will just also serve to make team-Obsidian look better, and can be part of your gate-keeping criteria. Those are some pretty high-value wins, and easy.

I would also, additionally, standardise on formatting ala AirBnB as there are a few other bugs/problems hidden in some plugins by inconsistent formatting and other code-readability issues.

Obviously some of the plugins are written by novice software engineers (which is a great testament to Obsidian’s API and this template!) and you don’t want to hinder creation, but helping them to not make mistakes only adds value to your core value proposition - instead of damaging it like Obsidian’s reaction to toggle-list did, which was unfortunate.

Trust me, you want to get ahead of this now before it becomes a really big headache.