test(dataService): add basic tests for withDataService

[michael-small]

Prerequisite to feat: add support for observables to withDataService

I said that I would make tests for withDataService featuring support for observables. However, it would be good to have existing tests for the feature as it is currently with promises before the withDataService is further extended.

Once I have a test for each method of the interface DataService with promises stubbed out then I'll bump this from a draft to a full PR. Tests are not my strong suit, so please roast these.

edit:
Progress/TODO 9/29/2024

• Happy path state changes are done
• Still need to
  • Test loading state
  • Test error state

[rainerhahnekamp]

Good idea @michael-small, I'll wait for the removal of the draft status.

[michael-small]

@rainerhahnekamp

I am marking this as ready since it is basically done and covers most scenarios.

• I think a lot of this is probably overkill or repeated/redundant test code, but it seems to works as is. All the methods tested, with or without a named collection, for its basic state patching as well as loading state.
• I am a bit stuck on testing the error flow as I have not had any success with mocking it out. I tried either spying on the simple new Store() and mock implementing it throwing an error, or making a new StoreWithErrors that throw errors in the implementations, and other variations to no success. I am curious what you would suggest, or if you could please show me an example of how you might write one.

Perhaps this is too undercooked a submission as well but I think I may have overthought/overdone certain aspects and would appreciate feedback before going further in a fruitless direction.

[rainerhahnekamp]

Good work so far. I'd suggest that in the first round of review, we focus on slimming down the amount of code. Depending on where we end up, we could then maybe split the file into multiple files or everything is alright.

[rainerhahnekamp]

tick() should be sufficient. That applies to all your tests.

[rainerhahnekamp]

I'd create a factory function which generates you a flight. That function should use by a default an default flight object and increments the id automatically with every call.

Its signature could be createFlight(flight: Partial<Flight>): Flight. As you see, you then only need to provide those values of Flight which differ from the default one.

[michael-small]

That should slim down all these mocking helpers, good idea.

[michael-small]

Good work so far. I'd suggest that in the first round of review, we focus on slimming down the amount of code. Depending on where we end up, we could then maybe split the file into multiple files or everything is alright.

Sounds good, thanks. I'll slim it down with your suggestions and a couple things that have occurred to me since and then @ you when it's at that point.

[michael-small]

@rainerhahnekamp

A) I slimmed the test down from 857 lines to 561 lines, ~33%, with your factory function suggestion.

B) I also remembered these two TODO

  // TODO 3A: setting error state (without named collection)
  // TODO 3B: setting error state (with named collection)

I keep fumbling with mocking out forced errors and testing that. Any tips / snippets?

That lack of the error case tests aside, I think this PR is ready if you are fine with the outstanding size of the test suite.

[rainerhahnekamp]

We can go forward with that one.