kevboh
Add Tests for Creating a New Project
I tried to keep this as small as possible, but I ended up creating a whole little ad-hoc integration test framework 😅
To summarize what's happening here:
- I extracted logic from store-vault-sync.ts and draft-utils.ts into the drafts.ts file to isolate it from the obsidian API. (re-exported functions in-place so preserve existing imports in the rest of the code)
- I created an interface that could be mocked between that logic and the obsidian API.
- Created unit tests for Creating a New Project (from both the plugin's API, and by creating a new index file)
- To ensure that the wrapper around the obsidian API (
VaultDirectory) worked the way I expected, and that the mocked version I'm using in unit tests worked the same way, I created a contract test and, well, an integration test framework. This allows us to actually run tests within obsidian, but only when we actually run the specific build config. In the normal dev and prod build configurations, the tests won't be imported by anything, and thus not included.
I recognize that this is still probably a lot to look over, so, if you'd prefer that I split this into two PRs: one for the int test framework stuff, and the other for actually adding the Create New Project unit tests, let me know :)
Give me a few days to find a good chunk of time to review this. Thanks for putting in all this effort!
Hey @kevboh I know this one was a really big chunk to try to review. My thoughts on testing in obsidian have changed a little since then, and I'd be happy to try to take another stab at this (and break it into smaller bits for you). Let me know if you'd like me to give that a go, or if you're still thinking about reviewing this one :)
@b-camphart sorry this ended up taking me a year to really look at! What are your thoughts now on testing in Obsidian?
😆 oh, it's all good @kevboh that's how it goes in open-source. No one's paying us for this stuff 😞 Saw you were working on a whole new plugin! Really cool 🙂
In response to your question, I think the idea of creating a whole testing framework is cool and will potentially avoid issues caused by the underlying obsidian behavior changing beneath us, but really, I think it's just too much to maintain. Instead, I'd say just isolate as much as possible from obsidian itself, and play with the specific APIs manually before each release.
I actually recommend just scrapping this PR and I'll take a stab at some of the isolation stuff I did here with some high-value tests that can be run outside of obsidian.