i'm using Cytoscape.js in combination with the Vaadin Framework.
Now i have a Problem during Testing.
i tried to measured the time, the load() function takes.
this is my code:
var start = new Date().getTime();
cy.load(eles);
cy.fit();
var end = new Date().getTime();
var time = end-start;
eles are my Elements.
I repeat this with an setInterval().
The Problem is, the function becomes slower and slower with each iteration.
Whats the Problem? Where is my error?
Thanks for your help :)
cy.load() is an asynchronous function, so you're going to run into issues if you try to load again before the previous load has finished. Have you tried using the callbacks on load done? It seems that using an interval is the wrong approach unless you have some method of keeping track of successive load progress.
Related
I maintain a complex Angular (1.5.x) application that is being E2E tested using Protractor (2.5.x). I am experiencing a problem with this approach, which presents primarily in the way the tests seem flaky. Tests that worked perfectly well in one pull request fail in another. This concerns simple locators, such as by.linkTest(...). I debugged the failing tests and the app is on the correct page, the links are present and accessible.
Has anyone else experienced these consistency problems? Knows of a cause or workaround?
Just Say No to More End-to-End Tests!
That said, here are the few things you can do to tackle our mutual merciless "flakiness" enemy:
update to the latest Protractor (currently 4.0.0) which also brings latest selenium and chromedriver with it
turn off Angular animations
use dragons browser.wait() with a set of built-in or custom Expected Conditions. This is probably by far the most reliable way to approach the problem. Unfortunately, this is use-case and problem specific, you would need to modify your actual tests in the problematic places. For example, if you need to click an element, wait for it to be clickable:
var EC = protractor.ExpectedConditions;
var elm = $("#myid");
browser.wait(EC.elementToBeClickable(elm), 5000);
elm.click();
maximize the browser window (to avoid random element not visible or not clickable errors). Put this to onPrepare():
browser.driver.manage().window().maximize();
increase the Protractor and Jasmine timeouts
slow Protractor down by tweaking the Control Flow (not sure if it works for 4.0.0, please test)
manually call browser.waitForAngular(); in problematic places. I am not sure why this helps but I've seen reports where it definitely helped to fix a flaky test.
use the jasmine done() callback in your specs. This may help to, for example, not to start the it() block until done is called in beforeEach()
return a promise from the onPrepare() function. This usually helps to make sure things are prepared for the test run
use protractor-flake package that would automatically re-run failed tests. More like a quick workaround to the problem
There are also other problem-specific "tricks" like slow typing into the text box, clicking via JavaScript etc.
Yes, I think all of us experienced such flakiness issue.
Actually, the flakiness is quite common issue with any browser automation tool. However, this is supposed to be less in case of Protractor as Protractor has built-in wait consideration which performs actions only after loading the dom properly. But, in few cases you might have to use some explicit waits if you see intermittent failures.
I prefer to use few intelligent wait methods like:
function waitForElementToClickable(locator) {
var domElement = element(by.css(locator)),
isClickable = protractor.ExpectedConditions.elementToBeClickable(domElement);
return browser.wait(isClickable, 2000)
.then(function () {
return domElement;
});
}
Where 2000 ms is used as timeout, you can make it configurable using a variable.Sometimes I also go with browser.sleep() when none of my intelligent wait works.
It's been my experience that some methods (eg. sendKeys()) do not always fire at the expected time, within the controlFlow() queue, and will cause tests to be flakey. I work around this by specifically adding them to the controlFlow(). Eg:
this.enterText = function(input, text) {
return browser.controlFlow().execute(function() {
input.sendKeys(text);
});
};
A workaround that my team has been using is to re-run only failed tests using the plugin protractor-errors. Using this tool, we can identify real failures versus flakey tests within 2-3 runs. To add the plugin, just add a require statement to the bottom of the Protractor config's onPrepare function:
exports.config = {
...
onPrepare: function() {
require('protractor-errors');
}
}
You will need to pass these additional parameters when to run your tests with the plugin:
protractor config.js --params.errorsPath 'jasmineReports' --params.currentTime (timestamp) --params.errorRun (true or false)
There is also a cli tool that will handle generating the currentTime if you don't have an easy way to pass in a timestamp.
please help me in understanding the following issue. please.
I have to get all links and check them later. I used the following code:
open(url);
List<String> links = new ArrayList<>();
for (SelenideElement link : $$("a"))
links.add(link.attr("href"));
when I used this with Linux with these api version:
Maven 3.1
Selenide v3.5
Selenium v2.53
Firefox v45.0.1
Then code can't take time enough to catch links from the page. Then I have to add driver wait before get links.
I Add the following (which is conditional wait):
WebDriverWait waitLog = new WebDriverWait(WebDriverRunner.getWebDriver(), 20);
waitLog.until(ExpectedConditions.visibilityOf($(By.tagName(Selector))));
And it worked fine and I run it more than one time.
I got surprised when running it yesterday, it didn't work and can't get time enough to get links!
So I replace the conditional wait with implicit wait, and add the following:
WebDriverRunner.getWebDriver().manage().timeouts().implicitlyWait(10, TimeUnit.SECONDS);
Now it is working fine.
What happened?
What is this thing make it work sometimes and sometimes can't work?
How to return back to the conditional wait with keeping the code working well?
So how to recover this problem? and prevent this problem from happens in the future.
There might be some delay in loading the url for the second time. Please try increasing the delay time for conditional wait. The main difference between explicit and implicit wait is as follows.
Explicit or conditional wait stops the WebDriver for the specified amount of time, till the mentioned element is available. Whereas implicit wait will skip execution of WebDriver for specified amount of time, for every element which is not found on the page.
Hope this helps.
I'm new to using this API and wasnt able to find an answer to what I'm running into.
When I use new webkitSpeechRecognition, and use the onresult event to find isFinal == true, it seems to take longer in finding the final result than using x-webkit-speech in an input tag.
Does anyone know if google is doing something specific to get a speedier result? Or do I need to set an attribute in the webkitSpeechRecognition object?
Thanks for any insight!
See my answer which explains how, in continuous mode results are triggered by new voice input, or otherwise will show up only after a timeout.
In non continuous mode, the result will show up much faster.
Using Ncqrs, is there a way to replay every single event ever happened (all aggregate types) and feed these through my denormalizers in order to recreate the whole read model from scratch?
Edit:
I though it's be good to provide a more specific use case. I'm building this inside a ASP.NET MVC application and using Entity Framework (Code first) for working with the read models. In order to speed up development (and because I'm lazy), I want to use a database initializer that recreates the database schemas once any read model changes. Then using the initializer's seed method to repopulate them.
There is unfortunately nothing built in to do this for you (though I haven't updated the version of ncqrs I use in quite a while so perhaps that's changed). It is also somewhat non-trivial to do it since it depends on exactly what you want to do.
The way I would do it (up to this point I have not had a need) would be to:
Call to the event store to get all relevant events
Depending on what you are doing this could be all events or just the events for one aggregate root, or a subset of events for one or more aggregate roots.
Re-create the read-model in memory from scratch (to save slow and unnecessary writing)
Store the re-created read-model in place of the existing one
Call to the event store one more time to get any events that may have been missed
Repeat until there are no new events being returned
One thing to note, if you are recreating the entire read-model database from scratch I would off-line the service temporarily or queue up new events until you finish.
Again there are different ways you could approach this problem, your architecture and scenarios will probably dictate how best to do it.
We use a MsSqlServerEventStore, to replay all the events I implemented the following code:
var myEventBus = NcqrsEnvironment.Get<IEventBus>();
if (myEventBus == null) throw new Exception("EventBus is not found in NcqesEnvironment");
var myEventStore = NcqrsEnvironment.Get<IEventStore>() as MsSqlServerEventStore;
if (myEventStore == null) throw new Exception("MsSqlServerEventStore is not found in NcqesEnvironment");
var myEvents = myEventStore.GetEventsAfter(GetFirstEventIdFromEventStore(), int.MaxValue);
myEventBus.Publish(myEvents);
This will push all the events on the eventbus and the denormalizers will process all the events. The function GetFirstEventIdFromEventStore just queries the eventstore and returns the first Id from the eventstore (where SequentialId = 1)
What I ended up doing is the following. At the service startup, before any commands are being processed, if the read model has changed, I throw it away and recreate it from scratch by processing all past events in my denormalizers. This is done in the database initializer's seed method.
This was a trivial task using the MS SQL event storage as there was a method for retrieving all events. However, I'm not sure about other event storages.
My main application form (WinForms) has a DataGridView, that uses DataBinding and Fluent NHibernate to display data from a SQLite database. This form is open for the entire time the application is running.
For performance reasons, I set the convention DefaultLazy.Always() for all DB access.
So far, the only way I've found to make this work is to keep a Session (let's call it MainSession) open all the time for the main form, so NHibernate can lazy load new data as the user navigates with the grid.
Another part of the application can run in the background, and Save to the DB. Currently, (after considerable struggle), my approach is to call MainSession.Disconnect(), create a disposable Session for each Save, and MainSession.Reconnect() after finishing the Save. Otherwise SQLite will throw "The database file is locked" exceptions.
This seems to be working well so far, but past experience has made me nervous about keeping a session open for a long time (I ran into performance problems when I tried to use a single session for both Saves and Loads - the cache filled up, and bogged down everything - see Commit is VERY slow in my NHibernate / SQLite project).
So, my question - is this a good approach, or am I looking at problems down the road?
If it's a bad approach, what are the alternatives? I've considered opening and closing my main session whenever the user navigates with the grid, but it's not obvious to me how I would do that - hook every event from the grid that could possibly cause a lazy load?
I have the nagging feeling that trying to manage my own sessions this way is fundamentally the wrong approach, but it's not obvious what the right one is.
Edit
It's been more than a year since I asked this question...and it turns out that keeping a main session open for the lifetime of the app has indeed led to performance problems.
There seem to be a lot more NH users on SO these days - anyone want to suggest a better approach?
yeah it's me again. ;-)
stumbling upon your new question reminds me of the following: Did you understand the principle of lazy loading or are you mistaking lazy loading for pagination? NHibernate also provides functionality for that.
If you just want to display some defined properties within your grid that are of course within the object graph i think you should retrieve the whole data at once using 'fetched joins'. If the rowcount of the data is to high you can think about pagination, as far as i know its also possible using DataGridView and Binding.
Lazy Loading results in multiple database calls - in your case i'ld think at least one per row. This seems not to be the best performing solution.
If instead you are using paging with FetchType.Join you can get rid of the long running session and all your problems should be solved. So how about that?
I had a project where there was a main grid for selection.
I had a class which paged through the set and i called session.Clear() everytime when i got a new page.
class MyList : IList<Data>
{
private int _pagesize = 50;
private int _session; // from ctor
private int _firstresult = int.MinValue;
private IList<Data> cached;
public Data this[int index]
get
{
if (!index.Between(_firstresult, _firstresult + cached.Count))
{
_firstresult = index;
GetData();
}
if (!index.Between(_firstresult, _firstresult + cached.Count))
throw new IndexOutOfRangeException();
return cachedData[index - _firstresult];
}
void GetData()
{
Session.Clear();
cached = Session.QueryOver<Data>()
.Skip(_firstresult)
.Take(_pagesize)
.List();
}
}
If you need Databinding maybe implement IBindingList