In every testing example I have seen with Stimulus the tricky part for me has been setting up the relevant DOM/HTML Fixtures. I question why you need to unit test the HTML in the first place.
I personally think unit testing HTML attributes a bad idea (opinionated), and a unnecessary step. When writing unit tests it’s common practice to only unit test first party code and expect third party code to have it’s own internal test suite, are the data-bindings first or third party?
All I’m saying is unit testing the DOM and Stimulus’s data-bindings adds unnecessary complexity and weight to your Controller unit tests. For example see AWaselnuk’s answer here.
As an example I’ve been writing unit tests for my controllers with Jest similar to this:
import { Controller } from 'stimulus';
export default class TestController extends Controller {
someMethodThatReturnsTrue() {
return true;
}
someMethodThatReturnsFalse() {
return false;
}
}
import TestController from '../src/controllers/test_controller';
describe('TestController', () => {
beforeEach(() => {
const controller = new TestController();
})
test('#someMethodThatReturnsTrue returns true', () => {
expect(controller.someMethodThatReturnsTrue()).toEqual(true);
});
test('#someMethodThatReturnsFalse returns false', () => {
expect(controller.someMethodThatReturnsFalse()).toEqual(false);
});
});
A simple example, but much cleaner, and unit tests the core logic without creating a new instance of Stimulus, or a new DOM with JSDOM, and HTMLFixtures. These kind of unit tests assume that Stimulus can find the relevant DOM elements and connects the controller and it’s methods to it.
I’d like to know peoples thoughts on this approach to unit testing and to help clarify not only for myself but the community on what to unit test as a user of Stimulus.
Note: I’m writing this as a user of Stimulus and agree that Stimulus should test DOM bindings internally.
PS: Great job with the project so far.