Replies: 1 comment 3 replies
-
@rhysm94 Thanks for starting the discussion. This is definitely a gap that ought to be filled, but as we haven't spent a ton of time testing view state transformations we don't know if our API design would be as informed. Do you have any suggestions? How would you like to test your view state? The simplest solution I could imagine is adding a let store = TestStore(…)
await store(.someAction) {
$0.isLoadingOneThing = true
}
XCTAssertTrue(ViewState(store.bindings).isLoading)) We've also talked about adding an await XCTAssertDifference(store.bindings) {
await store(.someAction) {
$0.isLoadingOneThing = true
}
} changes: {
$0.isLoading = true
} Any other ideas come to mind? |
Beta Was this translation helpful? Give feedback.
3 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
When writing tests, it’s possible to test
ViewState
if it is constructed directly from your feature state. e.g.When writing tests, it’s easy to assert on your
ViewState
:However, when using the new
Binding
features of TCA along withViewState
, if theViewState
is initialised using aBindingViewStore
, it’s no longer possible to write tests against theViewState
.e.g.
I can’t find a way to derive or construct a
BindingViewStore
from theTestStore
, so it’s no longer possible to write the above test code, as we can’t construct ourViewStore
any longer.I tried forking TCA and writing an extension on
TestStore where Action: BindableAction
to write something which exposed aBindingViewStore
, but I couldn’t quite get the types to line up for theAction
type, so I think I was doing something wrong there 😅Is there any chance that this is something that could be added, or are there any recommendations on alternative approaches? Ideally I’d like to avoid adding computed properties to my state and then assign them in the
ViewState
, but I guess this approach could work as a fallback.Thanks!
Beta Was this translation helpful? Give feedback.
All reactions