Skip to main content

Android - Module Testing

While developing your module, you can test your changes in two different ways. Locally, which will use the DevApp you are developing in to test your changes as you go. Once you get to a point where you are ready to test in a more 'production like' environment, we can then create release builds for you using either your own sandbox, or the Q2 SDX environment.

Before Testing​

Before you can test, make sure you have gone through the following steps:

Local Testing​

Local testing is as easy as running the DevApp application in android studio. Assuming you have supplied a sandbox url correctly, the application will open a web view pointed at the sandbox, and will allow you to test your modules there. Lifecycle and push receiver modules will start running right away. Method modules and UIModules can be called from your Tecton code deployed to that sandbox.

Certification Build Testing​

After you've created your module and verified it through local testing, we can provide builds that mirror official releases while still pointing to your sandbox or SDX environment. These builds utilize test data instead of production data, allowing for thorough validation.

To initiate this process, submit a merge request (MR) from your branch to the 'develop' branch. This signals that your code is ready for our review. Our primary focus at this stage is to ensure there are no major security concerns, rather than conducting an in-depth code review.

Before submitting your merge request, ensure your module adheres to these requirements:

  • Proguard Rules: Establish Proguard rules for your module, as it will be compiled with them. These rules should also be included in the consumer-rules file to ensure compatibility when used as a dependency.
  • No Debug Logic: Remove any debug-specific logic, such as Toast messages or intentionally thrown exceptions.
  • Correct settings.json: Configure your settings.json file with the values intended for the release build. We'll use this file to set up your artifact.
  • No Unused Modules: Remove any unused modules from the DevApp to maintain a clean and efficient project structure.

Once your merge request to the 'develop' branch is accepted, a Develop artifact will be automatically generated. This artifact will then be used to create Certification Builds configured for your specified sandbox or SDX environment.

If you need to request more builds at this point, you can put in a support ticket with the General ticket type, and Mobile SDK Q2 Product value.

Certification Build Testing With Notifications​

To test notifications in a Certification build, you should follow all the same steps as a normal Certification Build, but you must also send us a copy of your google-services.json. When we create the build, we will include it, so that the build will continue to use your firebase service.

See Android Firebase Testing for details on how to setup your module for Firebase Notifications, and how to get your google-services.json file.