Good point in avoiding logic on tests, thanks for contributing!
Are you referring to Mockito's verify function? If so, does it apply here as I'm dealing with a callback function? I have only used Mockito when testing abstract classes so far.
It actually does, I wrote a post on how to do that. There is a lot of missing information around testing with flutter right now and we are busy with a larger scale, long term white-label product and realized we have learnt a lot with little help from google.
The only thing I have not worked out yet is how to test the pull to refresh.
The shirt is, pop your callback function into a mock class, then pass that into your widget. You can then verify that.
You can simplify you test by using verify instead of running actual logic within the test to update a list.
You end up with the same quality of test by verifying the function was called instead of creating, modifying and expecting on a list.
Even though this is very simply logic, logic should be avoided in tests as there is no test to test that the logic in the test is correct.
Good point in avoiding logic on tests, thanks for contributing!
Are you referring to Mockito's verify function? If so, does it apply here as I'm dealing with a callback function? I have only used Mockito when testing abstract classes so far.
It actually does, I wrote a post on how to do that. There is a lot of missing information around testing with flutter right now and we are busy with a larger scale, long term white-label product and realized we have learnt a lot with little help from google.
The only thing I have not worked out yet is how to test the pull to refresh.
The shirt is, pop your callback function into a mock class, then pass that into your widget. You can then verify that.
Cool! I'll check it out. Thanks :)