Random state testing

[joelCHonor]

Hi all. I have a feature that calculates the position of some elements in the screen by using a Random algorithm. So, in order to test the state, it is imposible for me to determine what the position will be for every run. How I can use a TestStore to make a test that can skip that property? It is possible? Thanks in advance for the answers.

[mbrandonw]

Hey @joelCHonor, did you see the "non-exhaustive" test store feature that was released recently? It allows you to opt out of exhaustivity for a particular test:

let store = TestStore(...)
store.exhaustivity = .off(showSkippedAssertions: true)

store.send(.tap) {
  $0.count = 1
  // No need to assert on fields that were changed randomly
}

Alternatively, you could control your dependency on randomness. You could have a @Dependency(\.random) in your feature that in tests just returns a constant value.

[joelCHonor]

Thanks @mbrandonw I will check on the things you said. Will let you know about the results

[stephencelis]

Just a quick note, but TCA ships with a withRandomNumberGenerator dependency, which you can use to feed to APIs that take randomness:

@Dependency(\.withRandomNumberGenerator) var withRandomNumberGenerator

// ..

state.dieRolled = self.withRandomNumberGenerator { generator in
  Int.random(in: 1...6, using: &generator)
}

You'd need to override this dependency with a seedable generator, though.

Unless your app relies heavily on randomness using these APIs, you could simply store a () -> RandomResult function in your dependencies instead.

[joelCHonor]

Guys thank you both of you for answering so fast. @mbrandonw I tried the store.exhaustivity = .off(showSkippedAssertions: true), but still my test was failing because the state was different. I was unable to check just one part of the state. My state is kind of complex structure, with some nested structs. So, I don't know if because of that the 'exhaustivity' didn't work for me.
Another question I have is that, the TCA test store will check all the time for consistency with the state, meaning Success state. Is there a way to make a test where on purpose I want the test to success if the state is different?

[mbrandonw]

but still my test was failing because the state was different.

Can you share some code of what your test looks like?

If you don't mutate the field that has the random value then the non-exhaustive test store should ignore it:

await store.send(.tap) {
  $0.count = 1 // TestStore will assert against this
  // $0.randomInt  // TestStore will not assert against this

However, if you fully replaced a field with a new value and a subfield in that value had the randomness, then the test store will actually assert on the whole value:

await store.send(.tap) {
  $0.child = Child.State() // TestStore will assert on everything inside `child`.
}

Another question I have is that, the TCA test store will check all the time for consistency with the state, meaning Success state. Is there a way to make a test where on purpose I want the test to success if the state is different?

I'm not sure I understand. Can you sketch some code of what you are thinking?

[joelCHonor]

Ok, from what understand from your response, any mutated field will be take in consideration for the TCA function. So, even with 'store.exhaustivity = .off(showSkippedAssertions: true)' I wouldn't be able to skip a mutated field in the assert.
Is that right?
Regarding my second question, after thinking about the Success state, I realized I don't need the check different state as Success.

[mbrandonw]

Ok, from what understand from your response, any mutated field will be take in consideration for the TCA function. So, even with 'store.exhaustivity = .off(showSkippedAssertions: true)' I wouldn't be able to skip a mutated field in the assert.

Yes, that's correct, and that is how it has to be.

If it was possible to mutate a field to an incorrect value and still have the test pass, then what would the meaning of that test be? It wouldn't actually be asserting anything meaningful.

[joelCHonor]

Makes a lot of sense. Thank you again for looking into this.