Unit-tests in ECMAScript can only take you so far. Usually, it's the interaction with the underlying platform (i. e. FoundryVTT) where code fails, because assumptions are wrong, the API changes or underlying components and their interactions change.
Unit-tests cannot verify that these complex interactions continue to work. They only serve to assert that the API of a single controlled piece of code works as expected.
Therefore, a test suite that can be run within a FoundryVTT instance should yield much more insightful tests. But that also implies UI tests, which are notoriously brittle. But assuming the UI doesn't change too drastically too often, the effort of setting such tests up would be worth it.
And that is exactly what this issue is for. To set up the infrastructure for system tests, to execute at run-time.
Unit-tests in ECMAScript can only take you so far. Usually, it's the interaction with the underlying platform (i. e. FoundryVTT) where code fails, because assumptions are wrong, the API changes or underlying components and their interactions change.
Unit-tests cannot verify that these complex interactions continue to work. They only serve to assert that the API of a single controlled piece of code works as expected.
Therefore, a test suite that can be run within a FoundryVTT instance should yield much more insightful tests. But that also implies UI tests, which are notoriously brittle. But assuming the UI doesn't change too drastically too often, the effort of setting such tests up would be worth it.
And that is exactly what this issue is for. To set up the infrastructure for system tests, to execute at run-time.