how to retain multiple screenshot for one cucumber step? I need all screenshots for reporting purpose
const data18 = await driver.takeScreenshot()
const image18 = Buffer.from(data18, 'base64');
await world.attach(image18, 'image/png');
Using above code multiple time in same cucumber step is not retaining all screenshots but only the last or latest screenshot.
Related
I am trying to implement top level await in my react native & expo environment so I can pull data from AsyncStorage and store it in a variable to use globally in my app.
I'm running the app on an android emulator. All I want to do is get the data and use it in my application, but the the variable always returns an empty object when called outside the async function. It seems to apply a value to the variable before the data from AsyncStorage is done loading.
async function getData(){
try {
const value = await AsyncStorage.getItem('redditInsights')
console.log('----------- getStore insights ---------')
const insights = JSON.parse(value)
console.log(insights) // -------------> returns desired data
return insights
}
catch (error) {
console.log(error)
}
}
const outsights = getData()
console.log("-------------------- outsights---------------------")
console.log(outsights) // ----------------------> returns empty object
I know I can pull the data inside an async function, but I can't use that data anywhere except inside the async function. I can't call a variable declared inside async outside of the function without it trying to apply a value to the variable before the data is even pulled.
Ideally I would simply store the data into a variable to use wherever I want without an async function like so, but this requires top level await support:
const value = await AsyncStorage.getItem('redditInsights')
const insights = JSON.parse(value)
I tried implementing top level await through numerous flags (--harmony-top-level-await, --experimental-repl-await, --experimental-top-level-await) at npm start like so: npm start --flag to no avail. I also upgraded to node v14.15.1 which is suppose to support top level await, but I still get an error.
How do I implement top level await in my react native & expo environment so I can use the data in my AsyncStorage
Or if anyone knows a better way to get my data from AsynStorage, I'm more than willing to try it out!!
The simple answer is this is not possible.
There's a more detailed answer about top level await in react-native here which says that React Native doesn't meet the requirements for top level await (uses node modules not ECMAScript native modules).
But your code sample has a mistake, you could declare a top level variable insights and assign the result of your async data to it. Your mistake is using the return value of getData you would need to declare a top level variable with let and then assign the result to it (so instead of return insights) you would do something like topScopeInsights = insights after a let topScopeInsights.
But, this doesn't make any sense, because you won't know if the data has arrived yet. The app will boot with your variable undefined and then you'll need to check if it has arrived or not. That's what promises are for.
So, back to my original answer, this is not possible. :-(
I am trying to run a handfull of end-to-end (E2E) tests using Protractor and Jasmine. I am using Chrome as my browser of taste; and when I run the tests in full-flesh mode (i.e. not headless), the tests all run successfully. However, when I run the tests in headless mode, I keep getting an error that says the element I'm trying to click was intercepted by another element. The tool that seems to be getting in the way is WalkMe https://www.walkme.com/. I have used the following code to determine when my desired element is present, visible, enabled, and clickable, but this does not seem to help.
let isDisplayed;
let isEnabled;
let isPresent;
let EC = protractor.ExpectedConditions;
isDisplayed = await element(by.id(<locator-of-type-id>)).isDisplayed();
isEnabled = await element(by.id(<locator-of-type-id>)).isEnabled();
isPresent = await element(by.id(<locator-of-type-id>)).isPresent();
let elm = await element(by.id(<locator-of-type-id>));
await browser.wait(EC.elementToBeClickable(elm), 5000);
Thank you in advance for your time and effort.
Yes! You can't imagine how much I struggled with WalkMe... Here is the solution
// disable walkme for the session
await browser.executeScript(`
if (!!window.WalkMeAPI) {
window._walkMe.removeWalkMe();
(function() {
try {
var envName = "none";
document.cookie = "walkme_custom_user_settings_env=" + envName + ";path=/;";
window.localStorage.setItem("walkme_custom_user_settings_env", envName);
} catch(e) {
alert(e);
}
})();
}
`);
So basically you're disabling the integration, though by injecting a code to the browser's console
Though it's been a while since I used it last time, so hopefully not much is changed in their API
Another quick way to stop WalkMe from bugging you is to mock out your browser request to url /walkme/i, or whatever url your WalkMe script is sending API to(which you can check in your browser devtool network tab).
Quick example by myself in Cypress here https://liunate.medium.com/disable-walkme-to-avoid-flaky-cypress-end-to-end-tests-aaf73e213aed I think Protractor or other e2e testing framework should be able to intercept the same.
Using Jest, a testing library for JS, it is possible to have a "snapshot" as followed:
test('foo', () => {
expect(42).toMatchSnapshot("my_snapshot");
})
Basically, on first run this saves the tested value into a file. And on later runs, it compares the passed value with what was into the file. So that if the passed value differ from the value inside that file, the test fail.
This is quite useful because it allows to create tests easily.
Is there any way to do this using the testing framework provided by Flutter?
It is possible for widgets only, using testWidgets:
testWidgets('golden', (tester) async {
await tester.pumpWidget(Container(
color: Colors.red,
));
await expectLater(
find.byType(Container), matchesGoldenFile("red_container.png"));
});
First, you have to pump the widget you want to test (here a red container).
Then you can use matchesGoldenFile combined with expectLater. This will take a screen capture of the widget and compare it to the previously saved capture.
On the first run or when you want to update your goldens, you'll have to pass a flag to flutter test:
flutter test --update-goldens
Recently moved from utilising AWS to Azure for the location of our load test agents, thus making the transition to making full use of VSTS.
It was described that, for the moment, to get a load test file working with VSTS to using our own VMs for testing, we need to provide two context parameters, UseStaticLoadAgents and StaticAgentsGroupName in each loadtest file.
Our load test solution is getting very large, and we have multiple loadtest files where we have to set these two values each time. This leads us into the situation where, if we were to change our agents group name for example, we would have to update each individual load test file with the new information.
Im looking at a way to centralise this until a nicer way is implemented by Microsoft. The idea was to use a load test plugin, to add these context parameters with the plugin drawing the needed values from a centralised config file.
However, it seems that none of the hooks in the load test plugin or simply using the initialise method to manually set these values is working. Likely because they are set after full initialisation.
Has anyone got a nice, code focused solution to manage this and stop us depending on adding brittle values in the editor? Or even gotten the above approach to work?
The loadtest file is the XML file, so you can update it programmatically, for example:
string filePath = #"XXX\LoadTest1.loadtest";
XmlDocument doc = new XmlDocument();
doc.Load(filePath);
XmlNamespaceManager nsmgr = new XmlNamespaceManager(doc.NameTable);
nsmgr.AddNamespace("ns", "http://microsoft.com/schemas/VisualStudio/TeamTest/2010");
XmlNode root = doc.DocumentElement;
XmlNode nodeParameters = root.SelectSingleNode("//ns:RunConfigurations/ns:RunConfiguration[#Name='Run Settings1']/ns:ContextParameters", nsmgr);
if(nodeParameters!=null)
{
//nodeParameters.SelectSingleNode("//ns:ContextParameter[#Name='UseStaticLoadAgents']").Value = "agent1";
foreach (XmlNode n in nodeParameters.ChildNodes)
{
switch (n.Attributes["Name"].Value)
{
case "Parameter1":
n.Attributes["Value"].Value = "testUpdate";
break;
case "UseStaticLoadAgents":
n.Attributes["Value"].Value = "agent1";
break;
case "StaticAgentsGroupName":
n.Attributes["Value"].Value = "group1";
break;
}
}
}
doc.Save(filePath);
I started using Protractor and the first thing I've tried to do is to use Mocha and Chai instead of Jasmine. Although now I'm not sure if that was a good idea.
first I needed to make Chai accessible from all the spec files, without having to import everytime, I found it's possible to do in protractor.conf file:
onPrepare: ->
global.chai = require 'chai'
chai.use require 'chai-string'
chai.use require 'chai-as-promised'
global.expect = chai.expect
now in a spec like this:
it "when clicked should sort ",->
headerColumns.get(0).click()
firstCellText = $$(".first-cell").getText()
secondCellText = $$(".second-cell").getText()
# this won't work
expect(firstCellText).eventually.be.above(secondCellText)
to make it work I could do:
# now this works
$$(".second-cell").getText().then (secondCellText)->
expect(firstCellText).eventually.be.above(secondCellText)
but that's ugly, and I don't want to wrap stuff inside of .then all the time. I'm thinking there should be a better way(?)
I was having the same problem. The issue for me was to add a longer timeout to mocha through the Protractor config.js.
This works because Protractor tests take considerably longer relative to other modules like supertest since an actual browser is being interacted with.
I added
mochaOpts: {
timeout: 5000
}
to my protractor config and the tests passed.
Either you need to mention timeout for the whole test suite using "this.timeout(1000);" just below the describe block, or you can change it for individual test cases by explicitly defining timeout for each "it" block.
example for describe block:
describe("test-suite",function () {
this.timeout(5000);
it("test-case",function () {
//test case code goes here
});
});
example for it block:
it("test-case",function () {
this.timeout("20000");
});
I found this question while I was trying to do the same thing in TypeScript, but the approach in the protractor.conf.js is identical.
Making chai available globally
It appears to achieve this you're right that it needs to be done in the on prepare. a fairly terse example is below. As I understand it this is needed because chai is of course not apart of mocha but some additional candy that we can use with mocha. Unlike jasmine where everything is bundled into the framework.
protractor.conf.js fragment
onPrepare: function() {
var chai = require('chai'); // chai
var chaiAsPromised = require("chai-as-promised"); // deal with promises from protractor
chai.use(chaiAsPromised); // add promise candy to the candy of chai
global.chai = chai; // expose chai globally
}
example spec
Once you've got chai and chai-as-promised setup globally you need to add a "little" boiler plate to your spec to expose expect which comes from chai.
example.e2e-spec.ts fragment
const expect = global['chai'].expect; // obviously TypeScript
it('will display its title', () => {
pageObject.navigateTo();
const title = element(by.css('app-root h1')).getText();
expect(title).to.eventually.contain('An awesome title');
});
Avoiding then
I can't tell what your $$ references are, but if you're using the protractor components browser and by etc. then things clean up a little bit.
The call const title = element(by.css('app-root h1')).getText(); seems to return a promise which jasmine seems to deal with out of the box while mocha+chai doesn't. That's where chai-as-promised comes in.
using our additional syntax candy expect(title).to.eventually.contain('An awesome title'); resolves the promise quite neatly and we've avoided all those then calls, but we do need the eventually.
I've provided you a link to a working TypeScript example that might help demonstrate.