Hi,
To be clear, it’s for Editor UI Toolkit, not for Runtime UI Toolkit.
I want to be able to verify that UI state is as expected, but it doesn’t seem to be updating behind the scenes, which makes sense because there’s nothing rendering said UI.
Is there a way to write unit tests for UI Toolkit elements?
Thanks!
You want to verify your state variables then.
As they tell you, up and down the TDD world: don’t test the UI!
(*)
Your UI should be nothing more than a “dumb” presenter of the current UI state. The state itself you can put through rigoros tests. The state obviously mustn’t contain any UI references, after all it should only be values and lower-level types plus some business logic.
Testing the state already kills upwards of 98% of the issues you may encounter. Any UI issues will likely revolve around referencing the wrong state variable, or calling the wrong method when updating a value. Those are easy to spot with a once-only manual UI test as you finish your UI changes. Enter a value, see the state value change, check.
(*) Granted, there are some that say otherwise and there are special scenarios where it may be meaningful but oh boy there have also been instances where the entire layout of the UI was tested to match the design by the pixel! So at large, most sane developers would tell you not to test the UI.
I see what you mean, but there is benefit to testing UI. It’s just a matter of knowing what to test.
- Testing whether fields are correctly placed?

- Testing whether fields are of correct colour and size?

- Testing whether fields have correct values assigned to them?

- Testing whether certain elements are visible given the variable values?

The first three are expected to pass because that’s on UI framework maintainer (Unity in this case) to verify that these features work.
The visibility is controlled through my code, so it should be tested.
No. 
Because if you design the UI accordingly, the visibility of an element will be bound to a property in the UI state.
Nevertheless, the visibility of a UI element is the least I would test because it jumps out at you clearly during manual testing and development.
You can even go one step further and provide a testable class that changes its internal visibility state based on the UI state, and then UI then references this class and binds its own visible state to the visible state of the proxy class handling this business logic aspect of the UI (ie when visibility is a set of conditions testing various values). Then the connection of UI to VisibilityState is trivial, a bool to a bool, and you have tests for the non-UI class VisibilityState.
Is that even possible in UI Toolkit? I am locked to 2022.3 and I know for a fact that Unity 6 had some improvements around binding.
At the moment, I have to manually register callback to update the visibility of elements.
Not necessarily. If you make changes to the logic someplace else, or refactor, or test in different Unity versions, it won’t be as obvious. That’s what unit tests are for.
Yes, you’d always do red route checks, but that’s to verify that the whole application is usable, not for individual components.