I'm currently working on a custom reporter that sends test results to Sauce Labs. The current version of the reporter can be found here.
The problem with it is that it doesn't send the data after the last session. For instance, if I have 2 browsers to test on, it will only send the results for the first browser tested, stopping before sending the second one.
The request is made at the 'session/end' topic from the ones available. From what I can tell the entire thing stops before the last request is made.
I made a more isolated custom reporter to show off the problem using setTimeout() instead of a request. See it here.
Thanks!
The Intern process exits explicitly immediately after all sessions are complete (after /runner/end is published), so an asynchronous operation like that is unlikely to have enough time to complete successfully.
Intern 1.2 will contain an improvement so it will wait until any outstanding operations complete, and this will work as you expect it to.
Related
I have a NightwatchJS test that requires a MSSQL Db call to complete before moving on to then verify the results of that db call. The test is 2 parts.
Part 1 fills out a form and submits it into our website and verifies via API in our CMS that the form successfully posted and saves the Guid in a table in another db specifically for Nightwatch testing for verification later.
Part 2 runs later in the day to allow another internal process to 'ingest' that form into a different department's db and return the ingestion results into our CMS for that form. Part 2 then needs to do a Db lookup into the Nightwatch db and get all Guids that happened in the last 24 hours and hit another API endpoint in our CMS to verify ingestion of that form occurred into that other department by checking a field that the other department's process updates on ingestion.
I had the same issue of waiting-to-complete with the API calls where I needed NightwatchJS to wait for the API call to complete in order to use the results in the assertion. To solve that, I used a synchronous http library called 'sync-request'. So, that part works fine.
However, I cannot seem to find a synchronous Db library that works in Nightwatch's world.
I am currently using 'tedious' as my Db library but there is no mechanism for awaiting. I tried promises and async/await to no avail since the async stuff is wrapped inside the library.
I tried Co-mssql but I keep getting an error
TypeError: co(...) is not a function
using their exact example code...
Any ideas or suggestions?
Any other synchronous MSSQL libraries that work in NightwatchJS?
Any way of using 'tedious' is a fashiopn that ensures await-ability?
I found a library called sync-request that blocks the thread which is what i need.
We have a WEBAPI service running on a windows asp.net MVC solution. There is a load method that takes about 40 minutes to complete and return status on the called page. During that time the browser window is tied up. What design options do we have if we want the web page to come back with submitted and the process to continue to run and complete. I don't care if page never shows complete, we can pull that from another status page.
I've done something similar in the past, even though in my case the delay was shorter - 40-50 seconds of loading of fresh data from multiple backend servers in a VPN. It was also in ASP.NET back then, but I believe that the approach is still feasible and you can get some ideas if I share my experience. I remember an old thread that I had favourited in the past and used the insight from it. You can check it out.
Here are some tips, but in short, because I don't remember the details anymore (excuse my google-assisted memory!):
You should start the task in a new thread and not wait for it in your main thread.
You should also make sure that the task is started only once and cannot be initiated infinite number of times by the user via refresh or via the UI. So, you better persist the state in the database, so at refresh, the new thread is created only if the database says that it has not been executed recently or it is not in progress.
Your page will be loaded and show its contents and you can display a .gif representing a progress bar, a loading wheel or something similar to the user.
The task you started will continue on the server. When it completes you can push and update the UI via ajax from within the code-behind to make the experience even smoother if you like.
On subsequent requests, you can just retrieve the state of your task from the database in order to display something like update completed at hh:mm:ss.
Hope this helps you and I wish you the best of luck!
Due to some limitations about the web services I am proxying, I have to inject some JS code so that it allows the iframe to access the parent window and perform some actions.
I have built a proxy system with node-http-proxy which works pretty nicely. However I have spent unmeasurable hours trying to modify the content (on my own, using harmon as well, etc) that is being sent to the user without any success. I have found some articles and even some questions here but all of them are outdated and are not useful anymore.
I was wondering if someone can give me an actual example about how to do this, because I am unable to do it and maybe it is just that it is impossible to do at this point?
I haven't tried harmon, but I did try cheerio and it works.
However, I used http-mitm-proxy and not node-http-proxy.
If you are using http-mitm-proxy, you need to return a promise in the response handler. Otherwise, the proxy continues to send the original response without picking up your changes.
I have recently written another proxy at:
https://github.com/noeltimothy/noelsproxy
I'm going to add response handling to this soon. This one uses a callback mechanism, which means it wont return the response until the caller signals it to.
You should be able to use 'cheerio' and alter the content in JQuery style.
What I mean is a kind of event or callback which is called when some cached value is expiring. Supposedly this callback should be given the currenlty cached value, for example, to store it somewhere else apart from caching.
To find such a way, I have reviewed Notifications option, but they look like they are applicable for explicit actions with cache like adding or removing, whereas expiration is a kind of thing that occurs implicitly. I found out that none of these callbacks is not called many minutes after cache value has expired and has become null, while it is called normally within polling interval if I call DataCache.Remove explicitly (wrong, see update below).
I find this behavior strange as ASP.Net has such callback. You can even find an explanation how to utilize it here on SO.
Also, I tried DataCache Events. It is writtent in MSDN that literally
This API supports the .NET Framework infrastructure and is not intended to be used directly from your code.
Nevertheless I created a handler for these event to see if I can test its args like CacheOperationStartedEventArgs.OperationType == CacheOperationType.ClearCache but it seemed to be in vain.
At the moment, I started to think about workarounds of this issue of the lack of required callback. So suggestions how to implement them are welcome too.
UPDATE. After more attentive and patient testing I found out that notification with DataCacheOperations.ReplaceItem is sent after expiration. Regrettably, I did not find the way to get the value that was cached before the expiration had occurred.
Does anyone have any information on where the HTTP Status Codes (200, 404, 500, etc) are first available in the IIS Pipeline? I'm trying to write a series of http modules and handlers for error handling purposes and I don't particularly want to duplicate requests/responses to get the values.
Take a look at any of the events here, and take your pick :)
http://msdn.microsoft.com/en-us/library/ms693685(v=vs.90).aspx
Theoretically, the status code can be changed by any of the http modules in the pipeline; it just depends on which events they are subscribed to.
For example, an authorization module may subscribe to the OnAuthorizeRequest method, and perform its logic at that time, and change the status code if needed. In another case, a classic ASP app may run as a handler, and you won't be able to determine if the status code is 500 until OnPostExecuteRequestHandler. Finally, an error in a logging module may generate a 500, which doesn't occur until the request processing is nearly finished (OnLogRequest)
Further complicating matters, some handlers may spit out unbuffered data during execution, so it could be in any of the OnSendResponse events, which don't come in any particular order, and the status code could have changed between responses.
So, it really depends on what you're trying to achieve in order to approach this effectively. If you could provide more detail, perhaps we could formulate a solution.