100% test coverage

[M123-dev]

What

• Smoothie is now a production app and we have to avoid something to break unexpectedly. Dart and our hard typed rules are a really good start but won't work in all cases.

• The question is how we want to achieve more test coverage.

• More testing of individual components, but this would mean lots of mocking

• integration testsz which has its own set of problems.

• More golden tests, similar problem in terms of mocking but we should do this regardless of the other tests.

Any opinions @monsieurtanuki @g123k @AshAman999

Tasks:

• Create a test for registration and login #1239
• Implement golden tests for Dialogs #2633

Part of

• 🧪 Add more tests (Tracker) #1176

[monsieurtanuki]

My views on the matter:

• we already have a sample product in the app, that should help the mocking
• perhaps we should refactor this way - some very stupid widgets that display data without provider or refresh, and on top widgets that just use the providers and call the stupid widgets. And the screenshots would be taken on the stupid widgets.
• it's a matter of priority. All the energy we put there we don't put it somewhere else. I would prefer to focus on crashes or terrible user reviews first. And refactor later, or "just-in-time", like "while I'm editing this widget, I can add unit/golden tests".
• We need instructions about unit tests - how far should we go and how little is enough - so that we don't reinvent the wheel each time. At least minimal instructions, that we make evolve as we encounter new cases.
• perhaps there is a typical way to write unit tests for flutter, like my suggestion of splitting in provider ad stupid widgets

If I take a widget of mine EditProductPage:

• I'm not sure I see the point of a unit test on its display
• it could be split in two - one part with the provider that handles the product refresh, and one stupid part with just a ListView

If I had to sum up my point of view, I don't see the point of a "100% test coverage" if the app crashes and the users complain (about the crashes or the UX/UI). That said, we should build bullet proof tests for known dangerous areas like barcode scan.

[AshAman999]

Yeah, why not
Currently i don't know much of this, but would follow up for the upcoming features we do
Implementing golden tests would be good way to start

[M123-dev]

A few days ago I read an article about the first (?) testing framework for flutter. Seems promising: https://patrol.leancode.co/

I won't have time to work on it for some time though if anyone is interested feel free to try it out and maybe even start imlepemeting, maybe @abughalib or @AshAman999 if you are interested

[abughalib]

I would definitly look into it, but for now, @AshAman999 and I have university examinations going on.
We should be free by 20 Oct.

[M123-dev]

I just got https://fluttium.dev/docs/getting-started/writing-your-first-flow recommend to me, but the test are written in yaml which is really dislike due to github actions

[g123k]

This is the same framework as Maestro, but far behind in termes of features