Flutter team defined an integration test similar to an end-to-end test: Run the real application in a real device or emulator, automate the user action (e.g. click on a button), and verify the actual result by reading the displayed information. A very slow process. The test is usually a long one to write too, involving a lot of different systems. Rigid with a high maintenance cost. Since GUI tends to change a lot.

However, passing the integration test gives a very high confident boost to the overall stability of the application. The application ran on a device. There is a button to click, and it went through every state change, called the remote service and finally displays the correct result on the screen. This is definitely more reassuring compared to the fleet of green unit tests about converting HTTP-responded JSON to an array which may be used in a table or list or console.log.

So, what about it? The integration test, am I doing it for the upcoming project?

Initially, no. I do not want anything to do with Flutter Test Driver, Selenium whatnot. The time waiting for those test to run and finish is too long for me. I like TDD. I loved the days I was developing b4the.date. I would write unit-tests for my functional core, pass them, and finally wire up the UI. Slow tests break the TDD momentum.

I do working on a lighter version of the integration test. The test would be as light as a unit test, but, very close to end-to-end coverage. 

Next time.