I need to start the server inside the tests. I have read the advice at https://docs.cypress.io/guides/references/best-practices#Web-Servers, and I still need to start the server inside the tests (and possibly restart it mid-test). If I try to do that, I get the error "Cypress could not verify that this server is running:" and as far as I can see it never even tries to run the beforeEach that would start it. Is it possible to bypass that behaviour?
As far as I'm aware that's not exactly configurable, but you can leave out the baseUrl entirely. If Cypress doesn't know where your app is running, it won't do any pre-test polling to find out if it's up.
However note this also means you have to use the full URL in cy.visit and, because the main window is loaded on a random port on localhost (per the docs):
...Cypress then switches to the url of the main window to the url
specified in your visit. This can result in a 'flash' or 'reload' when
your tests first start.
Related
We use some third party enterprise software ("Container App"), which has an embedded Chromium browser, in which our webapp runs.
We use Cypress to test our webapp in a stand-alone browser outside of this container, however we would like to be able to test it inside, as it interacts with the container in various ways through javascript.
The only thing the container exposes is a "remote devtools-url" to the target (our) browser, which can be pasted to a native browser outside of the container and then debugged in devtools. Like this:
The Container provides 2 different url's for above debugging purposes, and they both work and seemingly similarly. They are something like the following (not precise, unfortunately I am not at work atm):
devtools://...inspector.html?id=xxx
http://ip/...inspector.html?id=xxx
Is it possible to setup Cypress to test "as normal", only having access to this remote devtools-url/port?
The target browser inside the container cannot be started by Cypress, as only the container can start and close it. So the target browser will already be running (with a --remote-debugging-port). I can get the devtools-id dynamically through a call to /json/list.
If not possible, any other way to achieve the goal of testing the browser/app running inside the container?
It is not possible. Testing with Cypress a web page in embedded Chromium running in your application means Cypress needs to connect to already running browser. Cypress doesn't have that possibility.
The documentation states:
When you run tests in Cypress, we launch a browser for you. This enables us to:
Create a clean, pristine testing environment.
Access the privileged browser APIs for automation.
There is a request in Cypress issue tracker to add the option to connect to already running browser. But there is no response on it from Cypress developers.
If I run a website using a http_deamon on a server is it possible to ssh into the server then open the prolog interface, run some queries, notably make and close the interface with the website still running?
Yes, it's possible to reload definitions with a running HTTP server.
Steps to reproduce:
Start a screen or tmux session. This lets you detach the terminal to log in later into the same session.
Start the server. With the HTTP daemon library, use the --interactive flag to get an interactive toplevel.
Detach the session.
Log out.
At any later time, to reload definitions while the server is still running, simply:
log in again
re-attach the session
run ?- make. as usual.
Caveat: With the HTTP Unix daemon, make/0 currently some issues, but you can always start an HTTP server also without using the http_unix_daemon library, and in that case make/0 works more nicely.
An alternative is to simply provide a special URL handler that runs make/0 within the server when that URL is accessed. Again, it may not work smoothly with the Unix daemon library, but typically when run without it.
I am wondering what would be the best practice for deploying updates to a (MVC) Go web application. Imagine the following scenario :
1) Code and test some changes for my Go Web Application
2) Deploy update without anyone currently using the previous version getting interrupted.
I don't know how to make sure point 2) can be covered - when somebody is sending a request to the server and I rebuild/restart it just in this moment, he gets an error - even if the request just uses a part of the code I did not touch or that is backwards-compatible, or if I just added a new Request-handler.
Maybe I'm missing something trivial or a well-known pattern as I am just in the process of learning go and my previous web applications were ASP.NET- or php-applications where this was no issue as I did not need to restart the webserver on code changes.
It's not just an issue with Go, but in general we can divide the problem into two separate ones:
Making sure current requests do not get terminated and affect user experience.
Making sure there is no down-time in which new requests cannot be handled.
The first one is easier to tackle: You just don't violently kill your server, but tell it to exit, causing a "Drain phase", in which it does not accept new requests and only finishes the currently running requests, and exits. This can be done by listening on signals for example, and entering the app into a special state.
It's not trivial with Go as the default http server doesn't support shutting it down, but you can start a server with a net.Listener, and then keep a reference to it an close it when the time is due.
Now, doing only approach one and then starting the service again will cause new requests not to be accepted while this is going on, and we all know this can take a number of seconds in extreme cases.
So what we need is another instance of the server already running with the new code, the instant the old one is not responding to new requests, right? That can be done in several ways:
Having more than one server, and a load-balancer on top of them, allowing one (or more) server to take the load while we restart another. That's the simplest way, and the way most people do it. If you need N servers to take the load of your users, just keep N+1 and restart one at a time.
Using socket sharing tricks. In Newer Linux kernels, Many processes can listen and accept on the same port. What you do is simply start the new instance and then tell the old one to finish and exit. This way there is no pause. This is done by setting SO_REUSEPORT on the listening socket.
The above can be automated with ready to ship solutions, like Einhorn, that deals with all the details for you, see https://github.com/stripe/einhorn
Another approach is documented in this blog post: http://blog.nella.org/?p=879
I'm currently working on a command line tool and since this is my first time designing a tool like this I have a few design questions, most notably how to handle a non lethal error.
The tool that I'm working on raises a main server on a configurable port and after that an optional web server on a non configurable port. If we then choose to do this again (while using a different port for the main server) we would obviously get an binding error when try to start up the optional web server.
Since this is a non lethal error (running the webserver is optional) and from UI experience my initial thoughts would be to print out a clear error and carry on with the program. However I've been told that from a scripting stand point print out the error and then existing is better practice.
So what is the better?
You might also want to consider that people might want to write scripts which expect the invocation to succeed even if the webserver is already running.
If you define a default behavior of 'fail if webserver already running', then such scripts will have to parse your error message, or read/understand your return value and figure out that the invocation failed for this particular reason (i.e. webserver already running).
Give them a way out of this and introduce a flag (argument) where they can decide which behavior they want. In the absence of the flag, do the safer thing maybe (i.e. error out if webserver is running).
I was just trying to perform a task after i stop the test run in QTP.
The actual scenario is like this:
I want to login into some site(project internal), perform some task and when i stop the test run, it should automatically logoff from the site.
There is a logoff button too on the web page.
But the challenge is that we have to logoff after we stop the test not before stopping the test run.
kindly help me out, i tried a lot but i am not able to do that.
Thanks in advance.
I'm not sure I understand why you would want to log off after the test stops, why not have the final step of the test log off?
Also from your question it sounds like you're talking about manually stopping the test
when i stop the test run, it should automatically logoff from the site
This seems to be an un-interesting case, if you're manually stopping the test then you can manually log-off and for automatic test runs (which is the point of automatic testing) behave as is required (log off at the last step etc.)
QTP does support closing a browser after the test run (when the test is closed) this is done from the Record and Run Settings dialog.
All that being said here's a hacky way to get what (I think) you're looking for, have this as the last step of your test:
Browser("Br").Navigate "javascript:setTimeout('document.getElementById(""logout"").click();', 5000); void(0)"
What this does is tell the browser to call a specific function after 5 seconds (5000 milliseconds) (using a bookmaklet), the code being called after 5 seconds clicks on the log off button (you'll have to use the correct id or otherwise locate the button of course).
As I said I'm not sure I understood your problem so I don't know how helpful this will be.