How to Not Break Your App After Migrating From Tipsi Stripe to Stripe React Native - Migration Guide, Part 4
The article is part of The Stripe React Native Migration Guide, focusing on best practices for developers migrating from "tipsi-stripe" to "stripe-react-native." It outlines key steps in the migration process, including understanding the purpose, writing end-to-end tests, and building the app at each stage. The emphasis is on thorough testing, with a specific focus on end-to-end tests to ensure the proper functioning of the code before and after migration.
About the Stripe React Native migration guide
If you have ever integrated payments with React Native, you may have encountered the popular community library “tipsi-stripe“. This project has been unmaintained for several years and the README now suggests migrating to the official Stripe React Native project.
To better support developers looking to migrate from “tipsi-stripe” to stripe-react-native, we’ve prepared The Stripe React Native Migration Guide to walk you through the core concepts and integration steps.
This article is the first part of the guide in which we go through the process of migrating from <rte-code>tipsi-stripe<rte-code> to <rte-code>stripe-react-native<rte-code>.
The guide is divided by 5 parts in which you'll learn about the following aspects of the migration process:
- Part 1 - How to migrate from Tipsi Stripe to the Stripe React Native SDK
- Part 2 - How to configure Stripe React Native
- Part 3 - A detailed description of Stripe React Native migration function by function
- Part 4 - How not to break your app after migrating from Tipsi Stripe to Stripe React Native (you are here)
- Part 5 - A collection of the most common questions related to Stripe React Native
As we learned in the previous posts, migrating from <rte-code>tipsi-stripe<rte-code> to <rte-code>stripe-react-native<rte-code> is fairly straightforward. But any time you make large-scale changes to your app, there is always the fear that you may have forgotten a parameter, used a new method incorrectly, or mishandled an error. Any of these mistakes could cause a regression in your app, so let’s see how all of these potential problems can be mitigated.
Best practices for API upgrades
When refactoring code, most of us tend to roughly follow some core steps in order to make sure we aren’t introducing new bugs or regressions into our code. This set of steps might look like:
- Understand the purpose and function of the legacy code
- Write unit tests
- Refactor code
- Regression test
There is a similar checklist we must follow for library upgrades, or when migrating from one library to another. However, there are some new steps introduced specifically for React Native apps
- Read any migration documentation or. guides
- Write or review end-to-end tests
- Migrate libraries
- Build the app on every supported platform
- Regression tests
- Setup crash reporting tools
Reading migration guide
Understanding the differences and the reasons behind why you are doing all this work to migrate libraries is a crucial point this process. If you’ve already read through our Stripe migration guide, then you can mark this point as “checked”!
Writing tests for your application is always a great way of making sure your code works as expected. But when it comes to code refactoring or a library migration it gives you even more advantages - specifically the possibility to test the code "before" and code "after" in exactly the same way. This is a perfect tool to make sure that even if the implementation has changed, the way your code works(and what your users will experience) is still the same.
You might be thinking that unit tests provide enough coverage, but unfortunately, if native modules come into play and our code is about long payment pipelines, unit tests are not enough. We need to test the whole integration and make sure that the app communicates properly with Stripe. End-to-end testing is the way to go here, so you can easily start a mocked server, build the app (on different platforms), run it and check most of the payment scenarios that exist in your app.
<p-bg-col>Remember that to make sure the migration won’t break anything you should create e2e tests before the whole migration process.<p-bg-col>
When you’re actually modifying your code, remember that it’s best to work in batches. Test after each atomic step, and do not wait to build your app until all the code changes are done.
To avoid having to correct a long list of build errors, it’s best to build your app each step of the way. This means ensuring you can build on all platforms before you start your migration, check-in and build throughout the migration process, and finally build and run the app at the end after all source code modification is complete.
After the first setup even before migrating the functionalities, it is good to run the app and check if it is not crashing.
Proper regression testing
After every big change like this regression testing is almost required. Investing in it could save you from a lot of potential issues in production in the future. Remember to test both success and failure scenarios because the error handling might differ a lot between different libraries. It differs also between <rte-code>tipsi<rte-code> and <rte-code>stripe-react-native<rte-code>.
If you don’t already have production crash reporting set up for your app, now is the time to do it. This can help in both identifying and tracking issues, and whether or not they are fixed. There are plenty of tools that give you insight into crashes and errors, here are some of the most popular ones for React Native apps:
Migrating to a new library, especially when it deals with something as important as payments, can be an overwhelming task. But by following these best practices, you’ll make the migration itself more pain-free, and ensure a better experience for your users
Remember that even if you won’t be able to follow all of them, doing a few and just being careful should make you covered.