BCIT : InApp #956
BCIT : InApp #956
Conversation
Firebase setup md explains structure of integration test project and also required configuraiton to make it work Readme.md is integration test project's read indicating what all feature work is going to be included in the project. and eventually how to run those tests and requirements for those. build.gradle is added as a boiler plate code. It is non-checked generated files. A revisit to remove unncessary code should be done as needed. Current aim to to achieve end-to-end integration test workflow setup. Hence not targetting to line by line check if something better is availabel OR if a line is really needed or not google-service.json.template is added just for reference. can totally delete this file later. proguard rules added by Cursor. Not sure if we need this. There is a open issue created by developer indicating we dont need it anymore. But need to verify that. Super important part of this commit is the settings.gradle file which will now allow integration test to access the api and api-ui folders
Quite impressed by no touch approach. Basic acitivies provided by Cursor is quite good looking already
These are files which cover the test scenarios All of it is currently placeholders but they do abstract what exactly they are going to do. Its important that I mention what overacrhing prompt was to understand how these files were created. Business Critical Integration Testing setup for SDKs in general. The idea of this project is to have the SDK fort intact. As we make progress by adding new features and overcoming customer problems and bugs, its important the functionality that we promise and abide by does not break. Unit tests are there doing that job during the PRs pointing out certain faults. But this project will introduce Integration Test and we will carve out some use cases from the possibility of numerous permutation of use cases to help establish state of SDK at any given point. The over-encompassing ticket describes main features of SDK and have separate tickets to consider one in-depth flow with that feature. The project will have end to end integration test established with Iterable Backend. It means there will be a project created in production with API key which the test suite can refer from. Below we can discuss the feature and its test case and what all is needed for it. Integration Test Setup Have the setup ready for integration tests Iterable Project Setup Run the app/test project locally CI setup 2. Push Notification Implement Integration Test to verify: Push notification configuration on iOS and Android platform Device receives push notification Device has permission granted to show notification CI uses backend server keys to send notification. Push notification is displayed Push delivery metrics are captured Tapping on Push notification leads to trackPush opens Tapping on buttons with deep link invokes SDK handlers. 3. InApp messages Implement integration test to verify: Silent push works Confirm In App is displayed Track In App Open metric are validated Confirm In App is able to Deep link Handlers are called and app navigated to certain module 4. Embedded messages Implement Integration test to verify: Project to have eligibility and user list ready Receive eligible message for signed in user Embedded messages are displayed Embedded metrics are verified Deep linking works Things to consider - Silent push flow check User becomes ineligible to eligible > backend triggers push > and flow continues User profile details. On a button click / toggle between values > which should match the criteria> And after affirmation of embedded messages toggle it back to default value. 5. Deep linking Implement Integration to verify: SMS/Email Flow. Launch the app with the url. Project setting to have tracking and destination domain Associated domains setup > iOS Launch the app with certain link. Intent filters set on Android | Assetlinks configuration on iOS | Android App Links | iOS Universal Links Deep linking handler is invoked. We will start from top to bottom.
# Conflicts: # .gitignore
Emulator is launching and inapp is getting displayed Still a lot of mess. Next I will probably try to trash all the extra bloat and keep it laser focussed to just one task and remove all the other
- Instead of different activities, Test will reuse the app's activity which was intended for test case. - Test suite uses minimize and foreground approach to check if inapp is there as of now. - it is able to click a button and check if in-app dissappears - The activity used for testing, those components are now in integration app activity. - At this stage, we are able to test in app click and close functionality
- Local development is able to trigger campaign - Get inapp messsages on device. - The test mthod run through same steps to verify inapp (not push based yet) - Email is read from local.properties file now. On Github actions it will be from secrets. -
Might have to revert this commit
We need the test to use the MainActivity which can be ran locally as well. there are two config and initilzation happening. Hence adding condition for App's config to not launch when testing. Also removed additional config and init in InApp and moved it to BaseIntegrationTest
Server failing to trigger campaign cant be fixed by retrying 3 times. Sometimes it just doesnt work. Need to investigate that later
Ayyanchira
force-pushed
the
InApp-Display-E2E
branch
from
65fe325 to
816582b
Compare
| const val TEST_INAPP_CAMPAIGN_ID = 14332357 | ||
| const val TEST_PUSH_CAMPAIGN_ID = 14332358 | ||
| const val TEST_EMBEDDED_CAMPAIGN_ID = 14332359 |
There was a problem hiding this comment.
This will be configured once we have exact campaign finalized
Ayyanchira
force-pushed
the
InApp-Display-E2E
branch
2 times, most recently
from
1dda473 to
2d55979
Compare
There was a problem hiding this comment.
Should remove either this file or inapp-e2e-tests.yml. Duplicated thing. One can be finalized and kept.
@sumeruchat , I will have you decide this in your branch. If you have another yml, we may discard this both.
Also removing other unnecessary files
Ayyanchira
force-pushed
the
InApp-Display-E2E
branch
from
2d55979 to
e1cd37b
Compare
| } | ||
|
|
||
| @Test | ||
| fun testInAppMessageMVP() { |
There was a problem hiding this comment.
This is the main single method which actually does the InApp testing with granularity.
- Checks credentials exists, server key, api key etc
- Initializes, checks user exists, clears all existing inapps, navigates to the Inapp test page
- Triggers campaign
- Manually refreshes inapp and shows the inapp
- Verifies inapp is displayed
- Checks a button on inapp
- clicks on it
- Verifies urlhandler actually getting invoked
cc @sumeruchat
| import com.google.firebase.messaging.RemoteMessage | ||
| import com.iterable.integration.tests.utils.IntegrationTestUtils | ||
|
|
||
| class IntegrationFirebaseMessagingService : FirebaseMessagingService() { |
There was a problem hiding this comment.
This file is not actively engaged but requires to be there for now. As we work on Push module, this will be useful
Ayyanchira
left a comment
Ayyanchira
left a comment
There was a problem hiding this comment.
Pre-review check done. Will wait for SDK team members for approval
|
Reviewing now |
sumeruchat
left a comment
sumeruchat
left a comment
There was a problem hiding this comment.
Hey @Ayyanchira! Solid work on getting the E2E test infrastructure up and running. The foundation is really strong, but let me break down what's working and what needs attention to fully meet the ticket requirements.
✅ What's Working Great:
Excellent test infrastructure - BaseIntegrationTest setup is clean and well-architected
testInAppMessageMVP() flow - The core campaign trigger → sync → display → interaction flow works well
Error handling - Good logging and async handling
❌ Missing Requirements (SDK-13):
Looking at the original ticket requirements, we're missing some key pieces:
Are we testing silent push here? I dont see any test that sends a silent push and verifies its receipt. Maybe I missed it
The URL handler is logging it but we dont actually navigate to a module and test if the navigation worked. I would think it would be something important to test as well. What do you think ? @joaodordio
Overall: Great start, but needs the missing requirements implemented to fully satisfy SDK-13. The architecture is sound, just need to complete the feature coverage.
|
Yes, silent push isnt checked here. Manual refresh is what confirms the inapp behavior |
sumeruchat
left a comment
sumeruchat
left a comment
There was a problem hiding this comment.
LGTM if we can make a seperate ticket for silent push like we discussed :)
|
Separate ticket has been created. Merging this one |
🔹 Jira Ticket(s) if any
✏️ Description