•  

    Pros and cons of this approach to autotests

    Pros

    The tests are both native and cross-platform. Active framework support.

     

    Access to the architecture and entities allows you to set locators for the necessary elements yourself,

    without involving anyone.

     

    Changes to files in the mobile application are always visible to the autotester. Developers also see

    component and scenario tests and can fix their own bugs in time.

     

    Cons

    The new framework is updated on its own clock and is not always in sync with native tools. In fact, only

    native tools for autotesting do not have this minus. But Calabash or Appium has it.

     

    I would like to note that the Flutter community makes contact without any problems. They respond

    quickly and fix issues.

     

    The tests are inside the mobile application and are completely dependent on it. If the application breaks,

    the tests will break: for example, if the version of the package has been updated and the dependencies

    are broken.

     

    Changes in the code force you to constantly build (for E2E).


    votre commentaire
  •  

    Every element in Flutter is a Widget, so testing Widget elements maps to component tests that cover

    each element or screen in detail. Entire user scripts map well to E2E tests.

     

    I think it is now clearly clear why it is more convenient to write both types of tests for the QA department:

    all scripts are needed for manual activities. Widget and E2E tests are capable of facilitating the work of

    manual testing, such as regression or full testing.

     

    Benefits of our strategy

    Stable quick Widget tests. This allows them to be run on pull-requests and prevents bugs from getting

    into builds for testing. They are easy to maintain: you can always see if the test breaks when you change

    the code in the mobile application.

     

    E2E tests cover user scenarios. They can be run at night and make life easier for a manual tester by

    covering sanity or smoke runs.

     

    Component and integration testing. Two types of tests help to work with mock data and with a real

    server in one project. This approach allows you to measure the coverage of code, scripts and technical

    requirements.


    votre commentaire



    Suivre le flux RSS des articles
    Suivre le flux RSS des commentaires