When working with cross-platform applications, it is important to be aware of the differences in operating systems and not to lose focus on platform specifics. To look for and see differences where they should be minimal in theory, to learn what you have not encountered before - such work increases professionalism.

When developing and testing native applications, it is not possible to build an iOS application from, for example, Android Studio or Visual Studio Code. When working with Flutter, the IDE is the same for both Android and iOS. This is great.

For us, the new framework is a plus: by solving non-standard problems, we broaden our horizons. We find many interesting and unique bugs that improve our skills and abilities when testing applications.

At the same time, developers from the Flutter framework community quickly give feedback on identified problems, improve the library and allow us to contribute to the project: we are moving forward together, which is nice.

The implicitTap method works using the handy pumpUntil* methods. implicitTap is an "implicit" tap. It will wait through the pumpUntilVisible method for its Finder and tap on it. If timeout - throws a test error.

Some quality assurance scenarios require data to be stored. For example: we opened the details of the map, hid the map and we want to find it in the hidden ones. To do this, you need to remember the product id - that is, the data for the search.

I wanted to store any parameters, so we created our own World - ContextualWorld. For convenience, there are two helper methods:

setContext sets the value for the key to the context.

getContext returns a value. It is important to do getContext with a generic, so as not to write each time in the steps, for example, as String. The context can be dynamic, so you need to cast types. Using the method, you can simply specify the type <String> in <T>.

By default flutter_test has:

pump() - A method that starts processing a frame after a given delay.

pumpAndSettle() - Waits for new frames to finish drawing before timeout. This method will loop endlessly if the animation has no end.

Such methods in quality assurance practice will generally work, but there are situations that do not work for them. Therefore, we have created several helper methods for convenience.

Such a method pumps until a certain condition or timeout occurs.

You may have noticed the _minimalPumpDelay variable. Once we encountered a situation where tests start seeing a button from another screen, although the transition animation to this screen has not yet completed. If you do pump () in a cycle with finding the Widget, this can clog the entire flow, and the application will start to go dumb. Tests take a long time and sometimes fluctuate. The logic does not have time to work out, because it is blocked by complex locators.

Solution: Added a 50ms delay to pump in cycles. Everything got better. Therefore, _mininalPumpDelay is needed so that the animations have time to complete after finding the Widget.