I am trying to simulate an app purchase for my unit test using the following code:
currentApp.requestAppPurchaseAsync(false);
It does return the S_OK code indicating a successful purchase but my unit test is failing because licenseInformation.isTrial is coming back as true.
I am under the impression that it should change the isTrial to false as I just purchased it.
Thoughts??
Try calling
await currentApp.requestAppPurchaseAsync(false);
My guess is that your unit test is continuing before the asynchronous method completes and the license is actually purchased.
Related
We are using a custom logic automation. when checking checkUpkeep the boolean returns true (pic attached) but our perform upkeep doesn't run. It is calling another function to run that cost rougly 50k to 100k in gas (when run manually) What are we missing? (p.s. when we do a simple toggle function call the performUpkeep works - but not our function). I've even put the gas up to 2,500,000 for testing using a timebased option as well (calling a specific function to execute same logic). Here is the repo https://github.com/billyjitsu/expir3/tree/main/packages/backend/contracts
WE are expecting when the checkUpkeep returns true to execute the upkeep
In order to solve the problem like "Why Chainlink checkUpkeep does not execute", I suggest doing the following things to debug your upkeep.
Since checkUpkeep and performUpkeep are both triggered by Chainlink automation, you need to check your automation subscription first. In the automation app, double check the contract address is correct.
Because the chainlink node has to change the state of blockchain(call performUpkeep in your consumer contract), it has to pay the gas fee. It is important to make sure there is a minimum balance of LINK in your subscription.
Test if checkUpkeep works as expected. If the pre-defined condition for automation is satisfied in your smart contract, checkUpkeep should return true. Chainlink automation only calls performUpkeep when checkUpkeep returns true, so the upkeep does not work if checkUpkeep cannot return true. Call checkUpkeep by yourself to test if it works properly. If you cannot get true as returned value, automation cannot get true either.
Test if performUpkeep works as expected. The mechanism of Chainlink automation is to call performUpkeep when checkUpkeep returns true, so you must make sure the performUpkeep can be called by automation. Try to call the performUpkeep manually to see if it works properly.
Hope it helps!
We have a react-native app to which we have just added in-app purchases using the expo-in-app-purchases package. Everything seems to be working when testing development builds and TestFlight-distributed release builds on our own devices.
However, we find that the app is consistently not working when reviewed by App Store reviewers.
In the latest review, via our error logging mechanism we discovered that the following error was thrown:
"Must wait for promise to resolve before recalling function."
This was thrown because during review the reviewer caused the following code to be executed twice, 7 minutes apart:
import { getProductsAsync } from 'expo-in-app-purchases';
...
const { responseCode, results } = await getProductsAsync(iOSProductIdArray));
It turns out the initial call to getProductsAsync never resolved, meaning when we called it again, some logic in expo-in-app-purchases (linked above) threw an error.
But what we don't know is why that method doesn't resolve when Apple reviewers use our app, when it always works when we do. The reviewers are signing in to the iTunes Store using the same sandbox credentials we use, and using the same build that we use, but are never able to load product details, which means they can never view purchase options in-app.
Is there something special about the review environment that prevents this function from working? We have theorised that InAppPurchases.connectAsync(), which we call when the app first boots, is failing for reviewers, but we have no idea how or why. Does anyone know how the review environment or process could cause this?
With system under test, when adding a new user their initial password is emailed to them.
I could split my test into multiple sections with manual intervention but this is less than ideal.
Appreciate any suggestions on how to proceed using TestCafe as I am sure others have encountered this as well.
If you run full integration test with real email server, then you can use libraries like "mail-receive" to connect to this server and verify the email.
You can also run your backend/server logic in mock mode, and then verify the mock, that the send event happened, by calling some test-specific rest endpoint from your TestCafe test.
Alternatively, you could also use something like "smtp-receiver" to start your own email-server-mock in nodejs context, and receive event upon email arrival. However you will need to configure your app server/backend to point to this mocked email server.
Worklight 6.1 on both Windows (colleague) and Mac (me), building an a Hybrid app destined for Android device but to speed up development we do initial testing as Mobile Web App in Chrome browser on desktop.
We get a weird symptom that I'm trying to fine-down to a reproducible test case. I think I see different behaviours when stepping in debugger and just letting it run. Want to check whether a certain coding pattern could be the cause of the symptom before I go any further.
Fundamental question: should we wait for the resolution of a promise returned by a JSONSTore request for an action on a collection before issuing another request? more explanation below.
The overall intent is to load some data into the JSONStore, with some intelligent replace/merge action if a record is already present. Pseudo code:
for each record retrieved from back-end
if ( record already present in Store )
do some data merging
replace record
else
add record
The application code actually works like this, just considering the add() case, the problem manifests when the store is empty, all records need to be added
for each record to add
addPromise = store.get().add(record);
listOfPromises.insert(addPromise);
examine the list of promises recording any errors
That is there is no "wait" for add to finish before issuing the next add request. Hence in effect we've initiated a set of adds "in parallel" whatever that might mean in JavaScript in Chrome.
The code appears to run just fine, no errors reported. On android device it works reliably. In Chrome under normal running (no stepping in debugger) we end up with no reported errors but only one record inserted - indeed as though a snapshot of the initial "empty" store had been taken and each add is working on that "empty" copy.
After writing this I'm now pretty convinced that the coding pattern described above is vulnerable to a kind of race and that the better approach is build a list of documents to be added and insert them in a single operation.
A more detailed answer will be coming later, but I now know that this
the coding pattern described above is vulnerable to a kind of race and
that the better approach is build a list of documents to be added and
insert them in a single operation.
is true. In the browser the JSONStore does require that we wait for the result of one request before issuing another one. The recommended approach is
var dataToAdd = buildArrayOfDataToAdd(responseFromServer);
var dataToReplace = buildArrayOfDataToReplace(responseFromServer);
jsonstore.add( dataToAdd ).then( function() { jsonstore.replace( dataToReplace); })
We have a bank of tests that all start by logging in.
They're recorded by QA so are html tests.
However occasionally something goes wrong and the tests fails. When
that happens the logout at the end of the test doesn't get called, so
the next test tries to login again - using open ./Login
If you're logged out that works fine.
However if you didn't log out because the test fails, that command puts you in a different path and then the rest of the tests in that suite all fail.
How do I tell Selenium to log out if the test fails?
Or how do I tell Selenium if LogOut link is available logout else
continue?
From My point of view i would prefer Following steps
create lib with all test cases. create Suite which will call the required function from libraries. In Suite use following flow
Call login
if login function returns zero call required function to execute.
If the called function returns zero call logout.
::::::::::::::::::::::::::::::::::::::::::::::::
If one of the function returns non zero store it in some variable or array with function name and error.
If want more details let me know.
e.g. if function gives error returns non zero value call errorLogout
You can used below approach:
Approach 1: TestNg annotation.
Approach 2. Use try catch block in catch block call logout function and then throw exception
Let me know if you need more explanation.