• Automated testing methods

    An important clarification: let's say there are several steps that are similar to each other. One step entirely contains the other: "I tap the button" and "I tap the button twice." This causes a problem: the implementation of the step that was found first is determined. In this case, it is important to use regular expressions (as in other cross-platform tools). RegExp with $ at the end - RegExp('I'm pressing the $ button') - helps to avoid conflicts, and clearly shows where the end of the step is. There is no longer a situation where the matcher chose the wrong step definition.

     

    Widget script for implementation

    testWidgets('Max field length is 11 characters', (WidgetTester tester) async {

    // given

          await tester.pumpWidget(GeneralWidgetInit.defaultWrapper(

            const AuthLoginScreen(),

          ));

          await tester.pumpAndSettle();

          await tester.doEnterText(AuthScreen.phoneFld, randomNumber(12));

    // then

          final field = tester.widget<TextField>(AuthScreen.phoneFld);

          expect(field.controller.text.length, 11);

        });

    < . . . >

     }); // group('Authorization by phone')

    }

    < . . . >

    Previously, in order to refer to an element, it was impossible to determine it by a locator during quality assurance process, so that it was suitable for both the Widget test and the E2E test. Now it is available automatically.

     

    Conveniently, you can take an integer property of the Widget—like the length—and compare it to the expected result. When checking field restrictions, enter text greater than 11 characters. At the output, we check that only 11 was entered.


    Tags Tags : ,