Do yourself a favor and split the business logic apart from the integration code.

That way you can make your integration code use the business logic, but you are not dependent on instantiating the integration code in a test.

Meaning, that if you have a Stimulus Controller, like in this example: the table with sortable table headers. You don't want to put the logic for changing the sort direction into the controller.

It will throw errors since it can't find the dom, can't be instantiated properly and even if, you will have trouble to trigger certain events.

You are better off creating a separate class that has way less dependencies. It will be easy to put to the test.

Not only that, but your tests will be much faster. You don't have to initialize a DOM, wait for pages to load, and so on.

We can test the frontend easily since the sorting class is just a plain old javascript class For example:

describe("Sort", () => {
  it("Given sortKey 'id' and 'ASC' sortOrder, when I call applySort with 'id', then the sortOrder should change to 'DESC'", () => {
    const sort = new Sort('id', 'ASC');
    sort.applySort('id');
    expect(sort.sortOrder).toEqual('DESC');
  })
  it("Given no sortKey and no sortOrder, when I applySort to id, the sortOrder will default to DESC", () => {
    const sort = new Sort(undefined, undefined);
    sort.applySort('id');
    expect(sort.sortOrder).toEqual('DESC');
  });
  it("Given sortKey 'id' and 'DESC' sortOrder, when I call applySort with 'id', then the sortOrder should change to 'ASC'", () => {
    const sort = new Sort('id', 'DESC');
    sort.applySort('id');
    expect(sort.sortOrder).toEqual('ASC');
  });
})