Building a React Native Mobile Automated Test Framework

Thomas F. - T.J. - Maher, Jr.

Wednesday May 20, 2025 6:30-8:00 PM - in person (free pizza!) via Zoom (no pizza...)

Register Here


Check in between 6:00 and 6:30 to network

About the Presentation. . .

Writing automated tests for a React Native mobile application is notoriously difficult. Mobile components display on the page, but are not fully loaded. Lengthy animations and slow-loading components take a while to finish. Timing issues cause your automated tests to error out giving the appearance of flaky tests.

Thomas F. - T.J. - Maher, Jr. will be sharing his experience tackling these problems using the open-source mobile testing framework, Wix's Detox, designed specifically for testing React Native applications.

  • Setting up a mobile test automation framework.
  • Vibe-coding a toy React Mobile Login page app to test against ( tinyurl.com/detox-demo ).
  • How to reduce timing issues and flakiness in automated tests.
  • Refactoring code into tests, page objects & base pages, separating out credentials and message strings for easier maintainability.
  • Setting up automated tests in CI / CD for iOS simulators and Android emulators with GitHub Action Workflows.
  • How developers can test their code before they push it into the main branch.
About the Speaker. . .

A former organizer of Ministry of Testing - Boston, Thomas (T.J.) Maher is a Software Development Engineer in Test (SDET) based in the Boston/South Shore area of Massachusetts, with a decade of experience building web + mobile test automation frameworks. His recent work includes architecting a mobile automation framework from the ground up using Detox and TypeScript for a React Native application at SELF ID, a decentralized identity startup. Prior roles include MassMutual, Verily (Google), Threat Stack, Fitbit, and Intralinks.

April's Presentation . .

See the recording of April’s well-received presentation by SQGNE President Robin Goldsmith, “QA vs. QC vs. QM vs. QE,” in the www.SQGNE.org Calendar.

Professionals and their organizations suffer when their definitions of key quality functions are either wrong or differ from others' definitions. In this interactive session, Robin shared and analyzed common definitions for quality and related functions--from participants, a leading quality trainer, IEEE/ISO standards, and Robin's Proactive SQA™ methodology.

Robin showed how widely-accepted definitions of quality are problematic. For example, customer satisfaction may result from higher quality or meeting/exceeding expectations; but they’re not quality. Some are satisfied by or even expect low quality. Crosby’s conformance to requirements, Deming’s and Six Sigma’s statistical measures, and Juran’s fitness for use all must be conditioned on the relevance and accuracy of requirements and specifications.

Pointing out that overly-long or complicated definitions are self-defeating, Robin’s shorthand working definition of system quality is the extent to which it satisfies relevant REAL business requirements consistent with standards. That combines how much with how well. Quality is absolute and not a function of your budget, but how much quality you get is governed by resources, priorities, and other constraints. Value is the perceived benefit of quality received relative to the costs of producing and receiving it.

System quality results most from how well it is defined, less from how well it is implemented, and still less from how well testers detect defects that do exist. However, effort tends to be expended in reverse—mainly on testing.

Many, if not most, with Quality Assurance (QA) in their title or group name, actually do Quality Control (QC), typically testing. Those organizations miss the benefits of true QA. Most recognize that QC evaluates products, though many limit it to end products. Organizations that do both QA and QC, often say QC executes dynamic tests of code whereas QA reviews requirements, designs, or other documents. However, that’s QC because those documents are products too, just intermediate products in software development.

Robin agrees that QC evaluates products, but distinguishes QA as concerned with the processes that produce those products—that they can and do produce software products of suitable quality in light of risks and relevant constraints.

Proactive SQA™ Establishes an Environment that Promotes Quality: from conception through requirement; identify when, what, and how to do and test it; address requirements, design, workmanship, and management practices; identify ways to improve and prevent errors. Its six functions: define what to do and how to do it well, make sure it gets done right, keep track of it, learn from it, and encourage it. SQA professionals/groups often fail when they try to do it all themselves. Rather, assure by involving others with relevant skills and knowledge.

To Robin, Quality Engineering (QE) is applying mindsets, techniques, and tools that produce quality. Quality Management (QM) is project management of quality-related work. Robin’s Proactive SQA™ includes both QE and QM, so having separate functions for them should be unnecessary. Separate QM can reflect turf wars, though it may be reasonable to make a responsibility for an organization’s quality management system (QMS).

Grateful thanks to sponsors Microsoft and mabl for making SQGNE possible. Please let us know of any additional prospective sponsors.


Link to SQGNE Community Links Page

Home

Mission

Contacts

Join

Education

Calendar

Directions

Past Presentations

Other Events


May 2025